Kontrolki DevSecOps

Metodyka DevSecOps stosuje bezpieczeństwo innowacji, integrując procesy zabezpieczeń i narzędzia w procesie programowania DevOps.

Ponieważ sama metodyka DevOps jest wschodzącą dyscypliną o wysokim stopniu odmian procesów, udany proces DevSecOps zależy od zrozumienia i przemyślanego zintegrowania zabezpieczeń w procesie programowania. Dodawanie zabezpieczeń powinno zaczynać się od zmian o niskim tarciu w kodzie, procesach programowania i infrastrukturze, która hostuje obciążenie. Najpierw skoncentruj się na zmianach z najwyższym pozytywnym wpływem na bezpieczeństwo, jednocześnie umieszczając niskie obciążenie procesów i umiejętności DevOps.

Ta dokumentacja zawiera przegląd każdego etapu procesu DevOps ciągłej integracji i ciągłego dostarczania (CI/CD) oraz mechanizmów kontroli zabezpieczeń, które zalecamy najpierw zintegrować.

DevSecOps controls

Planowanie i opracowywanie

Zazwyczaj nowoczesne programowanie jest zgodne z metodologią zwinnego programowania. Scrum to jedna implementacja metodologii agile, która ma każdy przebieg rozpoczynający się od działania planowania. Wprowadzenie zabezpieczeń do tej części procesu programowania powinno się skupić na:

  • Modelowanie zagrożeń w celu wyświetlenia aplikacji za pomocą obiektywu potencjalnego atakującego
  • Wtyczki zabezpieczeń środowiska IDE i wstępnie zatwierdzane punkty zaczepienia w celu uproszczonego sprawdzania analizy statycznej w zintegrowanym środowisku projektowym (IDE).
  • Przeglądy równorzędne i bezpieczne standardy kodowania w celu zidentyfikowania skutecznych standardów kodowania zabezpieczeń, procesów przeglądu równorzędnego i wstępnych punktów zaczepienia.

Nie jest wymagane dodanie wszystkich tych kroków. Jednak każdy krok pomaga wcześnie ujawnić problemy z zabezpieczeniami, gdy są one znacznie tańsze i łatwiejsze do rozwiązania.

Modelowanie zagrożeń

Modelowanie zagrożeń jest prawdopodobnie najważniejszym rozwiązaniem w zakresie zabezpieczeń. Zapewnia natychmiastowe wyniki i pomaga ustanowić sposób myślenia o zabezpieczeniach w deweloperach, aby poprawić bezpieczeństwo we wszystkich przyszłych projektach.

Modelowanie zagrożeń to prosta koncepcja, chociaż w razie potrzeby może być szczegółowa i techniczna. Modelowanie zagrożeń ujawnia i dokumentuje realistyczny widok zabezpieczeń aplikacji, który obejmuje:

  • Jak osoby atakujące mogą nadużywać projektu aplikacji
  • Jak naprawić luki w zabezpieczeniach
  • Jak ważne jest rozwiązanie problemów

Modelowanie zagrożeń skutecznie stawia cię w umyśle osoby atakującej. Dzięki temu aplikacja jest widoczna przez oczy osoby atakującej. Dowiesz się, jak zablokować próby, zanim osoby atakujące będą mogły coś z tym zrobić. Jeśli twój zespół ma osoby użytkowników w projekcie, możesz traktować osobę atakującą jako wrogą osobę użytkownika.

Istnieją opublikowane podejścia do modelowania zagrożeń, które wahają się od prostych metod pytań i odpowiedzi po szczegółową analizę opartą na narzędziach. Możesz opierać się na metodologiach, takich jak model STRIDE lub modelowanie zagrożeń OWASP.

Modelowanie zagrożeń: Rozpocznij proste

Ponieważ niektóre podejścia do modelowania zagrożeń mogą być czasochłonne i intensywnie korzystające z umiejętności, zalecamy rozpoczęcie od prostszego podejścia przy użyciu podstawowych pytań. Prostsze metody nie są tak dokładne, ale zaczynają proces myślenia krytycznego i ułatwiają szybkie identyfikowanie głównych problemów z zabezpieczeniami.

Następujące proste metody pytań ułatwią Rozpoczęcie pracy:

  • Prosta metoda pytań od firmy Microsoft: Ta metoda umożliwia zadawanie konkretnych pytań technicznych mających na celu uwidobienie typowych błędów w projekcie zabezpieczeń.
  • Modelowanie zagrożeń OWASP: Ta metoda koncentruje się na zadawaniu prostych, nietechnicznych pytań w celu rozpoczęcia procesu modelowania zagrożeń.

Możesz użyć jednego lub obu tych podejść, w zależności od tego, co działa lepiej dla twojego zespołu.

Gdy twój zespół będzie bardziej komfortowo w procesie, może zastosować bardziej zaawansowane techniki z cyklu projektowania zabezpieczeń firmy Microsoft. Ponadto mogą integrować narzędzia do modelowania zagrożeń, takie jak narzędzie do modelowania zagrożeń firmy Microsoft, aby uzyskać dokładniejsze informacje i pomóc w automatyzacji procesu.

Innym przydatnym zasobem jest przewodnik po modelowaniu zagrożeń dla deweloperów.

Wtyczki zabezpieczeń środowiska IDE i wstępnie zatwierdzane punkty zaczepienia

Deweloperzy koncentrują się na szybkości dostarczania, a mechanizmy kontroli zabezpieczeń mogą spowolnić proces. Zazwyczaj spowolnienie występuje, jeśli testy zabezpieczeń zaczynają się od potoku. Deweloper dowie się o potencjalnej luk w zabezpieczeniach po wypchnięciu kodu do repozytorium. Aby przyspieszyć proces i przekazać natychmiastową opinię, warto dodać kroki, takie jak wtyczki zabezpieczeń środowiska IDE i wstępnie zatwierdzane punkty zaczepienia.

Wtyczki zabezpieczeń zintegrowanego środowiska projektowego (IDE) identyfikują różne problemy z zabezpieczeniami podczas procesu programowania w znanym środowisku IDE dewelopera. Wtyczki mogą przekazać natychmiastową opinię, jeśli istnieje potencjalne zagrożenie bezpieczeństwa w napisanym kodzie dewelopera. Wtyczki mogą również ujawniać zagrożenia w bibliotece lub pakiecie innej firmy. W zależności od wybranego środowiska IDE wiele wtyczek typu open source lub komercyjnych jest dostępnych i udostępnianych przez firmy zabezpieczeń.

Inną opcją, która należy wziąć pod uwagę, jest użycie struktury wstępnego zatwierdzania, jeśli zezwala na to system kontroli wersji. Platforma przed zatwierdzeniem udostępnia skrypty zaczepienia Git, które ułatwiają identyfikowanie problemów przed przesłaniem przez dewelopera kodu do przeglądu kodu. Jednym z przykładów jest wstępne zatwierdzenie , które można skonfigurować w usłudze GitHub.

Przegląd równorzędny i bezpieczne standardy kodowania

Żądania ściągnięcia są standardowe w procesie programowania. Częścią procesu żądania ściągnięcia są przeglądy równorzędne, które często ujawniają nieodkryte wady, błędy lub problemy związane z błędami ludzkimi. Dobrym rozwiązaniem jest posiadanie członka zespołu ds. zabezpieczeń lub członka zespołu ds. zabezpieczeń, który może kierować deweloperem podczas procesu przeglądu równorzędnego przed utworzeniem żądania ściągnięcia.

Wytyczne dotyczące bezpiecznych praktyk kodowania pomagają deweloperom nauczyć się podstawowych zasad bezpiecznego kodowania i sposobu ich stosowania. Dostępne są bezpieczne praktyki kodowania, takie jak bezpieczne praktyki kodowania OWASP w celu uwzględnienia ich z ogólnymi praktykami kodowania.

Zatwierdzanie kodu

Zazwyczaj deweloperzy tworzą i udostępniają swój kod w repozytoriach, takich jak GitHub lub Azure Repos, oraz zarządzają nim. Takie podejście zapewnia centralną, kontrolowaną wersję bibliotekę kodu, która umożliwia deweloperom łatwą współpracę. Jednak włączenie wielu współpracowników w jednej bazie kodu również powoduje ryzyko wprowadzenia zmian. To ryzyko może prowadzić do luk w zabezpieczeniach lub niezamierzonego, w tym poświadczeń lub tokenów w zatwierdzeniach.

Aby rozwiązać to ryzyko, zespoły programistyczne powinny oceniać i implementować możliwości skanowania repozytorium. Narzędzia do skanowania repozytorium wykonują analizę kodu statycznego na kodzie źródłowym w repozytoriach. Narzędzia szukają zmian luk w zabezpieczeniach lub poświadczeń i flagi wszystkich elementów znalezionych do korygowania. Ta funkcja działa w celu ochrony przed błędem człowieka i jest przydatną ochroną dla rozproszonych zespołów, w których wiele osób współpracuje w tym samym repozytorium.

Zarządzanie zależnościami

Do 90 procent kodu w bieżących aplikacjach zawiera elementy lub jest oparte na zewnętrznych pakietach i bibliotekach. Dzięki wdrożeniu zależności w kodzie źródłowym niezbędne jest rozwiązanie potencjalnych zagrożeń. Wiele bibliotek innych firm ma poważne problemy z zabezpieczeniami. Ponadto deweloperzy nie stale przestrzegają najlepszego cyklu życia i nie aktualizują zależności.

Upewnij się, że zespół programistyczny wie, jakie składniki należy uwzględnić w swoich aplikacjach. Firma chce pobrać bezpieczne i aktualne wersje ze znanych źródeł. I będą chcieli mieć proces aktualizowania wersji. Twój zespół może używać narzędzi, takich jak projekt OWASP Dependency-Check, WhiteSource i inne.

Aby skoncentrować się tylko na lukach w zabezpieczeniach zależności lub ich cyklu życia, nie wystarczy. Ważne jest również, aby rozwiązać problem z zabezpieczeniami źródeł pakietów. Istnieją znane wektory ataków przeznaczone dla systemów zarządzania pakietami: typosquatting, kompromitujące istniejące pakiety, ataki zastępcze i inne. Dlatego odpowiedzialne administrowanie zarządzaniem pakietami musi sprostać tym zagrożeniom. Aby uzyskać więcej informacji, zobacz Trzy sposoby ograniczania ryzyka podczas korzystania z prywatnych kanałów informacyjnych pakietów.

Statyczne testowanie zabezpieczeń aplikacji

Gdy twój zespół zajmuje się bibliotekami innych firm i zarządzaniem pakietami, ważne jest, aby skupić się i poprawić bezpieczeństwo kodu. Istnieją różne sposoby poprawy bezpieczeństwa kodu. Możesz użyć wtyczek zabezpieczeń środowiska IDE. Możesz też połączyć przyrostowe testy wstępnego zatwierdzania i zatwierdzania analizy statycznej zgodnie z opisem wcześniej. Istnieje również możliwość wykonania pełnego skanowania kodu źródłowego w celu przechwycenia błędów pominiętych w poprzednich krokach. Jest to konieczne, ale skanowanie dużego bloku kodu może potrwać kilka godzin, a nawet kilka dni. W związku z tym takie podejście może spowolnić rozwój i wprowadzić obciążenie.

Jednak zespół musi zacząć gdzieś podczas implementowania praktyk skanowania kodu statycznego. Jednym ze sposobów jest wprowadzenie statycznej analizy kodu wewnątrz ciągłej integracji. Ta metoda sprawdza zabezpieczenia zaraz po wprowadzeniu zmian w kodzie. Jednym z przykładów jest SonarCloud. Opakowuje wiele statycznych narzędzi do testowania zabezpieczeń aplikacji (SAST) dla różnych języków. SonarCloud ocenia i śledzi dług techniczny z naciskiem na łatwość utrzymania. Analizuje jakość i styl kodu oraz ma kontrolery specyficzne dla zabezpieczeń. Ale istnieje wiele innych narzędzi komercyjnych i open source dostępnych na rynku.

Aby upewnić się, że pętla opinii jest skuteczna, kluczowe jest dostosowanie narzędzia. Chcesz zminimalizować wyniki fałszywie dodatnie i przekazać jasne, możliwe do podjęcia działania opinie na temat problemów, które należy rozwiązać. Warto również zaimplementować przepływ pracy, który uniemożliwia zatwierdzanie kodu w gałęzi domyślnej, jeśli istnieją wyniki. Należy uwzględnić zarówno wyniki dotyczące jakości, jak i bezpieczeństwa. Zabezpieczenia stają się więc częścią środowiska testowania jednostkowego.

Bezpieczne potoki

Metodyka DevOps przenosi automatyzację na inny poziom, ponieważ wszystko w cyklu projektowania przechodzi przez potok. Ciągła integracja i ciągłe dostarczanie (CI/CD) to kluczowa część nowoczesnych cykli programowania. W ciągłej integracji/ciągłego wdrażania zespół scala kod dewelopera z centralną bazą kodu zgodnie z regularnym harmonogramem i automatycznie uruchamia standardowe kompilacje i procesy testowania.

Potoki infrastruktury są centralną częścią opracowywania. Jednak używanie potoków do uruchamiania skryptów lub wdrażania kodu w środowiskach produkcyjnych może powodować unikatowe wyzwania związane z zabezpieczeniami. Chcesz mieć pewność, że potoki ciągłej integracji/ciągłego wdrażania nie staną się ścieżkami uruchamiania złośliwego kodu, zezwalają na kradzież poświadczeń lub zapewniają osobom atakującym dostęp do jakiegokolwiek obszaru powierzchni. Chcesz również upewnić się, że tylko kod, który zespół zamierza wydać, a następnie wdraża.

Zespoły DevOps muszą upewnić się, że implementują odpowiednie mechanizmy kontroli zabezpieczeń dla potoku. W zależności od wybranej platformy istnieją różne wskazówki dotyczące rozwiązywania problemów z ryzykiem. Aby uzyskać więcej informacji, zobacz Zabezpieczanie usługi Azure Pipelines.

Kompilowanie i testowanie

Wiele organizacji używa potoków kompilacji i wydania do automatyzowania i standaryzacji procesów tworzenia i wdrażania kodu. Potoki wydania umożliwiają zespołom deweloperów wprowadzanie iteracyjnych zmian w sekcjach kodu szybko i na dużą skalę. Zespoły nie będą musiały poświęcać dużych ilości czasu na ponowne wdrażanie ani uaktualnianie istniejących środowisk.

Korzystanie z potoków wydania umożliwia również zespołom promowanie kodu ze środowisk deweloperskich, za pośrednictwem środowisk testowych i ostatecznie do środowiska produkcyjnego. W ramach automatyzacji zespoły programistyczne powinny obejmować narzędzia zabezpieczeń, które uruchamiają skrypty, testy automatyczne podczas wdrażania kodu w środowiskach testowych. Testy powinny obejmować testowanie jednostkowe funkcji aplikacji w celu sprawdzenia luk w zabezpieczeniach lub publicznych punktów końcowych. Testowanie zapewnia zamierzony dostęp.

Dynamiczne testowanie zabezpieczeń aplikacji

W klasycznym modelu tworzenia kaskadowego zabezpieczenia były zwykle wprowadzane w ostatnim kroku, tuż przed przejściem do produkcji. Jedną z najpopularniejszych metod zabezpieczeń jest testowanie penetracyjne lub testowanie penetracyjne. Testy penetracyjne umożliwiają zespołowi przyjrzenie się aplikacji z perspektywy zabezpieczeń czarnego pudełka, tak jak w przypadku, gdy znajduje się najbliżej myślenia osoby atakującej.

Test penetracyjny składa się z kilku punktów akcji, z których jeden to dynamiczne testowanie zabezpieczeń aplikacji (DAST). DAST to test zabezpieczeń aplikacji internetowej, który znajduje problemy z zabezpieczeniami w uruchomionej aplikacji, sprawdzając, jak aplikacja reaguje na specjalnie spreparowane żądania. Narzędzia DAST są również nazywane skanerami luk w zabezpieczeniach aplikacji internetowych. Przykładem jest narzędzie typu open source OWASP Zed Attack Proxy (ZAP). Znajduje luki w zabezpieczeniach działającej aplikacji internetowej. Istnieją różne sposoby skanowania zap programu OWASP: pasywne skanowanie punktu odniesienia lub pełne skanowanie w zależności od konfiguracji.

Wadą testowania penetracyjnego jest to, że zajmuje to trochę czasu. Dokładny test pióra może potrwać do kilku tygodni, a szybkość opracowywania metodyki DevOps może być niezrównoważalna. Warto jednak dodać lżejszą wersję testowania penetracyjnego podczas procesu programowania, aby odkryć problemy pominięte przez usługę SAST i inne kroki. Narzędzia DAST, takie jak OWASP ZAP, mogą pomóc.

Deweloperzy integrują OWASP ZAP w potoku jako zadanie. Podczas uruchamiania skaner ZAP OWASP uruchamia się w kontenerze i wykonuje skanowanie, a następnie publikuje wyniki. Takie podejście może nie być idealne, ponieważ nie jest kompletne testowanie penetracyjne, ale nadal jest cenne. Jest to jeszcze jedna miara jakości w cyklu programowania w celu poprawy stanu zabezpieczeń.

Walidacja konfiguracji chmury i skanowanie infrastruktury

Oprócz skanowania i zabezpieczania kodu dla aplikacji upewnij się, że środowiska wdrażane w programie są również bezpieczne. Bezpieczne środowiska są kluczowe dla organizacji, które chcą iść w tempie, wprowadzać innowacje i korzystać z nowych technologii. Bezpieczne środowiska ułatwiają również zespołom szybkie tworzenie nowych środowisk na potrzeby eksperymentowania.

Możliwości platformy Azure umożliwiają organizacjom tworzenie standardów zabezpieczeń na podstawie środowisk, takich jak usługa Azure Policy. Usługa Teams może używać usługi Azure Policy do tworzenia zestawów zasad. Zestawy zasad uniemożliwiają tworzenie niektórych typów obciążeń lub elementów konfiguracji, takich jak publiczne adresy IP. Te zabezpieczenia umożliwiają zespołom eksperymentowanie w bezpiecznym i kontrolowanym środowisku, równoważenie innowacji i ładu.

Jednym ze sposobów, w jaki metodyka DevOps może przynieść deweloperom i operacjom kroki, jest obsługa konwersji istniejącej infrastruktury na podejście typu infrastruktura jako kod.

Infrastruktura jako kod (IaC) to zarządzanie infrastrukturą (sieciami, maszynami wirtualnymi, modułami równoważenia obciążenia i topologią połączeń) w modelu opisowym. Usługa IaC używa tego samego modelu przechowywania wersji, który jest używany przez zespół DevOps na potrzeby kodu źródłowego. Podobnie jak zasada tego samego kodu źródłowego generuje ten sam plik binarny, model IaC generuje to samo środowisko za każdym razem, gdy jest stosowany. IaC to kluczowa praktyka metodyki DevOps używana z ciągłym dostarczaniem.

Usługa DevSecOps przenosi zabezpieczenia w lewo i pokazuje, że zabezpieczenia nie dotyczą tylko zabezpieczeń aplikacji, ale także zabezpieczeń infrastruktury. Jednym ze sposobów, w jaki usługa DevSecOps obsługuje zabezpieczenia infrastruktury, jest uwzględnienie skanowania zabezpieczeń przed wdrożeniem infrastruktury w chmurze. Gdy infrastruktura stała się kodem, należy następnie zastosować te same akcje zabezpieczeń do infrastruktury co zabezpieczenia aplikacji. Dostępne są narzędzia zabezpieczeń do uruchamiania skanowania zabezpieczeń infrastruktury na podstawie wybranej strategii IaC.

Dzięki wdrożeniu chmury konteneryzacja jest popularnym podejściem, które zespoły podejmują w decyzjach dotyczących architektury aplikacji. Niektóre repozytoria kontenerów skanują obrazy w celu przechwytywania pakietów ze znanymi lukami w zabezpieczeniach. Nadal istnieje ryzyko, że kontener może mieć nieaktualne oprogramowanie. Ze względu na to ryzyko ważne jest skanowanie kontenera pod kątem zagrożeń bezpieczeństwa. Istnieje wiele narzędzi do zabezpieczeń typu open source i komercyjnych, które są przeznaczone dla tego obszaru i obsługują ścisłą integrację w procesie ciągłego wdrażania. Narzędzia zabezpieczeń ułatwiają zespołom wdrażanie metodyki DevSecOps na potrzeby infrastruktury jako kodu, a w szczególności dowiedz się, jak używać kontenerów.

Przechodzenie do środowiska produkcyjnego i obsługa

Gdy rozwiązanie przechodzi do środowiska produkcyjnego, ważne jest, aby kontynuować nadzorowanie stanu zabezpieczeń i zarządzanie nim. Na tym etapie procesu nadszedł czas, aby skupić się na infrastrukturze chmury i ogólnej aplikacji.

Skanowanie konfiguracji i infrastruktury

Aby uzyskać wgląd w subskrypcje chmury i konfigurację zasobów w wielu subskrypcjach, użyj rozwiązania zabezpieczeń dzierżawy platformy Azure od zespołu AzSK.

Platforma Azure obejmuje funkcje monitorowania i zabezpieczeń. Te możliwości wykrywają i ostrzegają wszelkie nietypowe zdarzenia lub konfiguracje, które wymagają badania i potencjalnego korygowania. Technologie takie jak Microsoft Defender dla Chmury i Microsoft Sentinel to narzędzia pierwszej firmy, które natywnie integrują się ze środowiskami platformy Azure. Te technologie uzupełniają środowisko i narzędzia zabezpieczeń kodu. Technologie zapewniają dokładne monitorowanie zabezpieczeń, dzięki czemu organizacje mogą szybko i bezpiecznie eksperymentować i wprowadzać innowacje.

Testy penetracyjne

Testowanie penetracyjne to zalecana praktyka sprawdzania luk w zabezpieczeniach w konfiguracji infrastruktury lub aplikacji, co może powodować słabe strony, które mogą wykorzystać osoby atakujące.

Wiele produktów i partnerów oferuje usługi testowania penetracyjnego. Firma Microsoft udostępnia wskazówki dotyczące testowania penetracyjnego na platformie Azure.

Testowanie obejmuje zazwyczaj następujące typy testów:

  • Testy punktów końcowych w celu wykrycia luk w zabezpieczeniach
  • Testowanie rozmyte (znajdowanie błędów programu przez dostarczanie źle sformułowanych danych wejściowych) punktów końcowych
  • Skanowanie portów w punktach końcowych

Analiza z możliwością działania

Narzędzia i techniki zawarte w tych wskazówkach oferują całościowy model zabezpieczeń dla organizacji, które chcą iść w tempie i eksperymentować z nowymi technologiami, które mają na celu wspieranie innowacji. Kluczowym elementem metodyki DevSecOps są oparte na danych procesy sterowane zdarzeniami. Te procesy ułatwiają zespołom identyfikowanie, ocenianie i reagowanie na potencjalne zagrożenia. Wiele organizacji decyduje się zintegrować alerty i dane użycia z platformą zarządzania usługami IT (ITSM). Następnie zespół może przenieść ten sam ustrukturyzowany przepływ pracy do zdarzeń zabezpieczeń, które są używane w przypadku innych zdarzeń i żądań.

Cykle wymiany opinii

Screenshot showing the Continuous security model.

Wszystkie te techniki i narzędzia umożliwiają zespołom znajdowanie i flagi zagrożeń oraz luk w zabezpieczeniach, które wymagają badania i potencjalnego rozwiązania. Zespoły operacyjne, które otrzymują alert lub wykrywają potencjalny problem podczas badania biletu pomocy technicznej, potrzebują trasy z powrotem do zespołu deweloperów, aby oznaczyć elementy do przeglądu. Płynna, wspólna pętla opinii jest niezbędna do szybkiego rozwiązywania problemów i jak największego zminimalizowania ryzyka luki w zabezpieczeniach.

Typowym wzorcem opinii jest zintegrowanie go z systemem zarządzania pracą dewelopera, takim jak Azure DevOps lub GitHub. Organizacja może łączyć alerty lub zdarzenia z elementami roboczymi, aby deweloperzy planować i podejmować działania. Ten proces umożliwia deweloperom skuteczne rozwiązywanie problemów w ramach standardowego przepływu pracy, w tym programowania, testowania i wydawania.