Przekształć DevOps w DevSecOps

Podczas tworzenia lub modernizacji dyscypliny zabezpieczeń programowania w tym artykule opisano, jak integrowanie zabezpieczeń z praktykami programistycznymi umożliwia przejście od operacji deweloperskich (DevOps) do operacji zabezpieczeń dla deweloperów (DevSecOps) i pomaga zabezpieczyć dostarczanie aplikacji.

Nowoczesne organizacje polegają na szybkim tworzeniu oprogramowania w celu dostarczania innowacji, reagowania na zmieniające się wymagania biznesowe i utrzymania przewagi konkurencyjnej. Metodyka DevOps umożliwia tę elastyczność dzięki ciągłej integracji i ciągłego dostarczania. Jednak zwiększona szybkość wprowadza również nowe zagrożenia bezpieczeństwa.

Cykle ciągłego wydawania skracają czas między decyzjami projektowymi a wdrożeniem produkcyjnym, co zwiększa prawdopodobieństwo wprowadzenia słabych stron w środowiskach produkcyjnych, w tym:

• Słabe strony projektu aplikacji
• Zależności podatne na zagrożenia
• Błędy konfiguracji
• Wady automatyzacji infrastruktury
• Złe zarządzanie tajemnicami lub higiena.

Ryzyko metodyki DevOps

Nowoczesne środowiska DevOps rozszerzają obszar ataków w systemach deweloperskich, potokowych i produkcyjnych. Narzędzia DevOps, takie jak repozytoria kodu źródłowego, potoki i systemy automatyzacji, są obiektami docelowymi o wysokiej wartości dla osób atakujących.

Jeśli złośliwy kod zostanie wprowadzony wcześnie, może przejść przez istniejące kontrole zabezpieczeń i dotrzeć do systemów produkcyjnych.

Typowe cele ataku obejmują:

• Wstrzykiwanie złośliwego kodu do artefaktów kompilacji.
• Naruszenie tożsamości deweloperów lub kont usług.
• Uzyskiwanie dostępu do danych produkcyjnych lub ich eksfiltrowanie.

Osoby atakujące często wybierają aplikacje niestandardowe i środowiska programistyczne w celu uzyskania dostępu do:

• Poufne dane organizacyjne lub dane klientów.
• Własnościowa logika biznesowa i własność intelektualna.
• Infrastruktura produkcyjna poprzez naruszone systemy programistyczne.
• Klienci podrzędni poprzez naruszenie łańcucha dostaw oprogramowania.

Potencjalne zagrożenia bezpieczeństwa zostały podsumowane na poniższym diagramie:

Ryzyko związane z aplikacjami i programowaniem

Obciążenia aplikacji mogą zostać naruszone przez słabe punkty wprowadzone podczas opracowywania lub naruszenie infrastruktury używanej do ich kompilowania i wdrażania.

Ryzyko	Obiekt docelowy	Potencjalny wynik
Projektowanie/implementacja aplikacji	Problemy związane z zabezpieczeniami wprowadzone podczas projektowania lub tworzenia mogą narażać obciążenia robocze na techniki ataku, takie jak: - Nieprawidłowa walidacja danych wejściowych — Niezabezpieczona logika uwierzytelniania lub autoryzacji - Słaba lub nieprawidłowo wdrożona kryptografia - Narażenie poufnych danych za pośrednictwem logiki aplikacji	Te słabości mogą zezwalać osobom atakującym na: — Uzyskiwanie dostępu do danych aplikacji lub manipulowanie nimi — Wykonywanie nieautoryzowanych operacji - Utrzymuj trwały dostęp dzięki zaimplementowanym lukom logicznym.
Infrastruktura deweloperów/automatyzacja	Ataki mogą być celem: - Repozytoria kodu źródłowego - Potoki budowania - Automatyzacja wdrażania — Szablony infrastruktury jako kodu (IaC) - Tworzenie punktów końcowych lub tożsamości usługi	Naruszenie zabezpieczeń może zezwalać osobom atakującym na: - Wstaw złośliwy kod do artefaktów kompilacji - Modyfikowanie konfiguracji wdrożenia - Utrzymywanie trwałego dostępu za pomocą wszczepionych wad logiki — Pozyskiwanie poświadczeń lub sekretów używanych w środowiskach produkcyjnych.
Łańcuch dostaw oprogramowania deweloperskiego	Aplikacje często polegają na: — Biblioteki innych firm - Pakiety typu open source — Obrazy kontenerów - Usługi platformy	Luki w zabezpieczeniach lub złośliwy kod wprowadzony za pośrednictwem tych zależności mogą mieć wpływ na: — Obciążenia produkcyjne organizacji — Środowiska klienta lub partnera

Integrowanie zabezpieczeń w procesach programistycznych zmniejsza prawdopodobieństwo propagacji tych zagrożeń do wydania produkcyjnego.

Przesunięcie w lewo

„Shift left” to podejście z zakresu inżynierii bezpieczeństwa, które polega na uwzględnianiu bezpieczeństwa na wcześniejszym etapie cyklu wytwarzania oprogramowania.

Zamiast weryfikować zabezpieczenia pod koniec procesu, organizacje osadzają je w:

• Wyobrażanie sobie
• Design
• Rozwój
• Operations

Zmniejsza to koszty korygowania i narażenie na ryzyko.

Aby wspierać to podejście, organizacje powinny

• Użyj najlepszych rozwiązań ustrukturyzowanych, takich jak cykl życia programowania zabezpieczeń (SDL) na wczesnym etapie procesu, a nie późno, gdy problemy stają się kosztowne i trudne do rozwiązania.
• Aby utrzymać to podejście, należy zintegrować ład, ryzyko i zgodność (GRC) ze strategią programowania.

Co to jest DevSecOps?

Metodyka DevSecOps realizuje podejście „Shift Left” poprzez rozszerzenie metodyki DevOps i wbudowanie bezpieczeństwa w każdy etap cyklu życia oprogramowania — od powstania koncepcji, przez projektowanie i rozwój, po utrzymanie.

• W tradycyjnych podejściach programistycznych weryfikacja zabezpieczeń była często wykonywana jako ostateczna brama jakości przed wydaniem. Spowodowało to opóźnienia, zwiększono koszt korygowania i umożliwiono utrwalanie luk w zabezpieczeniach do końca cyklu życia.

• Metodyka DevSecOps przenosi zabezpieczenia wcześniej i osadza je w procesach programistycznych i operacyjnych.

• Metodyka DevSecOps zmniejsza tarcie między zespołami deweloperów, operacji i zabezpieczeń, dostosowując je do wspólnych celów dotyczących szybkości innowacji, niezawodności i odporności zabezpieczeń oraz umożliwia zespołom wczesne i ciągłe rozwiązywanie najważniejszych problemów.

• Usługa DevSecOps integruje zabezpieczenia z:

  • Projekt architektury
  • Implementacja aplikacji
  • Automatyzacja infrastruktury
  • Procesy wdrażania i działania

Benefits

Usługa DevSecOps umożliwia zespołom deweloperów, zespołów ds. zabezpieczeń i operacji:

• Wykrywaj i usuwaj problemy na wcześniejszych etapach cyklu życia.
• Zmniejszenie ekspozycji w środowisku produkcyjnym.
• Zachowaj szybkość dostarczania podczas zarządzania ryzykiem.

Zabezpieczenia stają się częścią sposobu tworzenia i dostarczania oprogramowania, a nie kontroli stosowanej po zakończeniu dostarczania.

Bezpieczny cykl życia innowacji

Innowacje zwykle przechodzą przez dwa etapy cyklu życia:

Etap	Szczegóły
Inkubacja pomysłu	Funkcja została zaprojektowana, zaimplementowana i zweryfikowana do początkowego użycia produkcyjnego. Zaczyna się od nowego pomysłu
Wersja początkowa	Pierwsza wersja produkcyjna spełnia minimalne kryteria produktu do bezpiecznego stosowania produktu. - Programowanie: funkcjonalność spełnia minimalne wymagania biznesowe. - Zabezpieczenia: Możliwości spełniają wymagania dotyczące zgodności z przepisami, zabezpieczeń i bezpieczeństwa do użytku produkcyjnego. - Operacji: Funkcjonalność spełnia minimalne wymagania dotyczące jakości, wydajności i możliwości obsługi jako systemu produkcyjnego.

Po początkowym wydaniu programowanie staje się iteracyjne w miarę rozwoju obciążeń:

• Zmiana tolerancji ryzyka
• Wymagania i dojrzałość aplikacji
• Obowiązki regulacyjne
• Warunki zagrożenia

Integrowanie zabezpieczeń z programowaniem

Tradycyjne podejścia programistyczne weryfikują zabezpieczenia pod koniec cyklu życia jako ostateczną bramę przed wydaniem po zakończeniu projektowania i implementacji. W nowoczesnych środowiskach deweloperskich opóźnienie walidacji zwiększa się:

• Złożoność luk w zabezpieczeniach
• Koszt korygowania
• Opóźnienia operacyjne i zakłócenia
• Zwiększone narażenie na ryzyko aktywnego wykorzystywania

Usługa DevSecOps integruje zabezpieczenia w sposób ciągły w trakcie programowania i operacji, aby rozwiązać problemy wcześniej, zmniejszyć ryzyko i poprawić spójność.

Najważniejsze rozwiązania

Zabezpieczenia muszą być osadzone w istniejących procesach programistycznych, aby być skuteczne, skalowalne i zrównoważone. Należy ją zintegrować bezpośrednio ze sposobem projektowania, tworzenia, wdrażania i obsługi aplikacji, a nie implementowanych w osobnym lub równoległym przepływie pracy. Zalecamy:

• Mapowanie pełnych przepływów pracy od pomysłu przez programowanie, wdrażanie i bieżące operacje.
• Definiowanie jasnych ról, narzędzi i obowiązków dotyczących zabezpieczeń na każdym etapie cyklu życia.
• Ustanawianie spójnych ścieżek korygowania luk w zabezpieczeniach, wad i problemów z projektowaniem.

Dostosowywanie praktyk zabezpieczeń na podstawie ryzyka związanego z obciążeniem. Aplikacje krytyczne dla działania firmy wymagają większej rygoru, a scenariusze o niższym ryzyku mogą stosować uproszczone podejścia.

Upewnij się, że co najmniej:

• Zidentyfikuj etapy, osoby i technologie związane z cyklem projektowania.
• Zdefiniuj sposób integrowania działań zabezpieczeń z każdym etapem, a nie traktowania ich jako oddzielnych punktów kontrolnych.
• Ustanów procesy obsługi zarówno poważnych zmian, jak i rutynowych poprawek w całym cyklu życia.

Zautomatyzuj bezpieczeństwo w procesie tworzenia i wdrażania

Automatyzacja jest niezbędna do spójnego wymuszania zabezpieczeń i na dużą skalę w ramach programowania i operacji.

• Zintegruj mechanizmy zabezpieczeń i narzędzia bezpośrednio w potokach CI/CD.
• Automatyzowanie kluczowych działań, takich jak modelowanie zagrożeń, skanowanie kodu, walidacja i wymuszanie zasad.
• Użyj infrastruktury jako kodu (IaC), aby umożliwić powtarzalne, bezpieczne wdrożenia.

Podstawy platformy, takie jak strefy docelowe Azure, mogą obsługiwać to podejście

Podstawy platformowe, takie jak Azure landing zones, mogą wspierać to podejście, zapewniając standardowe wzorce w zakresie zabezpieczeń, ładu organizacyjnego i integracji z DevOps.

Oczekiwane wyniki

Organizacje, które przenoszą się z metodyki DevOps do metodyki DevSecOps, mogą:

• Zmniejsza prawdopodobieństwo wprowadzenia luk w zabezpieczeniach w obciążeniach produkcyjnych
• Ograniczanie możliwości ataków w celu wykorzystania infrastruktury programistycznej lub automatyzacji
• Zwiększanie odporności aplikacji na zmieniające się techniki ataków
• Obsługa wymagań dotyczących zgodności z przepisami i organizacją
• Utrzymywanie szybkości innowacji bez zwiększania ryzyka operacyjnego lub bezpieczeństwa

Porady dotyczące poruszania się po podróży

Wdrożenie metodyki DevSecOps wymaga zmian organizacyjnych i kulturowych.

Zmiany w edukacji i kulturze

Są to krytyczne wczesne kroki. Zespół, którym dysponujesz, musi rozwinąć nowe umiejętności i przyjąć nowe perspektywy, aby zrozumieć model DevSecOps.

Zmiana w zakresie edukacji i kultury organizacyjnej wymaga czasu, koncentracji, wsparcia kadry kierowniczej oraz regularnych działań następczych, aby pomóc pracownikom w pełni zrozumieć i dostrzec wartość tej zmiany.

Drastyczne zmiany w kulturze organizacyjnej i wymaganych umiejętnościach mogą czasami uderzać w tożsamość zawodową pracowników, co może wywoływać silny opór. Ważne jest, aby zrozumieć i wyrazić, dlaczego, co i jak zmienia się dla każdej osoby i ich sytuacji.

Zmiana zajmuje czas

Możesz działać tylko tak szybko, jak szybko twój zespół potrafi dostosować się do konsekwencji nowego sposobu działania. Zespoły muszą wykonywać swoje istniejące zadania podczas transformacji.

Ważne jest, aby dokładnie określić priorytety najważniejszych elementów i zarządzać oczekiwaniami dotyczącymi tego, jak szybka może się zdarzyć ta zmiana.

Skupienie się na strategii etapowej, w której najważniejsze i podstawowe elementy wdraża się najpierw, dobrze służy organizacji.

Zmiana wprowadza (tymczasowe) tarcie

Wszystkie nowe technologie, metodologie i inne zmiany powodują tarcie i zamieszanie. Kluczowe jest skupienie się na zdrowych napięciach, które sprzyjają krytycznemu myśleniu i pomagają ograniczać ryzyko, przy jednoczesnym unikaniu niezdrowych napięć, które spowalniają procesy, przynosząc niewielkie korzyści i tylko w ograniczonym stopniu zmniejszając ryzyko.

Ograniczone zasoby

Wyzwaniem, z jakim zwykle borykają się organizacje, jest znalezienie talentów i umiejętności zarówno w zakresie zabezpieczeń, jak i tworzenia aplikacji.

W miarę jak organizacje zaczynają skuteczniej współpracować, mogą odkryć ukryte talenty, takie jak deweloperzy z nastawieniem na bezpieczeństwo lub specjaliści ds. bezpieczeństwa z doświadczeniem programistycznym.

Trwające zmiany

Aplikacje szybko się zmieniają. Oprócz nowych funkcji, definicja techniczna i kompozycja aplikacji zmienia się zasadniczo wraz z wprowadzeniem technologii, takich jak chmura, bezserwerowa i sztuczna inteligencja.

Ta zmiana zmienia praktyki programistyczne, zabezpieczenia aplikacji, a nawet umożliwia tworzenie aplikacji przez niedeveloperów.

Rozważmy model SRE

Niektóre implementacje devSecOps łączą operacje i obowiązki związane z zabezpieczeniami w rolę inżyniera niezawodności lokacji (SRE ).

Chociaż taki model może działać, często jest to skrajna zmiana z istniejącej kultury i praktyk przedsiębiorstwa.

Jeśli rozważasz model SRE, zalecamy rozpoczęcie od osadzania zabezpieczeń w usłudze DevOps przy użyciu praktycznych szybkich zwycięstw i przyrostowych postępów opisanych w tych wskazówkach, aby upewnić się, że uzyskujesz dobry zwrot z inwestycji (ROI) i spełniasz natychmiastowe potrzeby.

Zwiększa to przyrostowe obowiązki w zakresie zabezpieczeń dla Twoich pracowników operacyjnych i programistycznych, co przybliża zespoły do stanu końcowego SRE.

Następne kroki

Dowiedz się więcej o najlepszych rozwiązaniach dotyczących bezpiecznego programowania.