Kontrola zabezpieczeń: zabezpieczenia metodyki DevOps
Usługa DevOps Security obejmuje mechanizmy kontroli związane z inżynierią zabezpieczeń i operacjami w procesach DevOps, w tym wdrażanie krytycznych kontroli zabezpieczeń (takich jak statyczne testowanie zabezpieczeń aplikacji, zarządzanie lukami w zabezpieczeniach) przed fazą wdrażania w celu zapewnienia bezpieczeństwa w całym procesie DevOps; Zawiera również typowe tematy, takie jak modelowanie zagrożeń i zabezpieczenia dostarczania oprogramowania.
DS-1: Przeprowadzanie modelowania zagrożeń
Kontrolki CIS w wersji 8 | Identyfikatory NIST SP 800-53 r4 | Identyfikatory PCI-DSS w wersji 3.2.1 |
---|---|---|
16.10, 16.14 | SA-15 | 6.5, 12.2 |
Zasada zabezpieczeń: Modelowanie zagrożeń umożliwia zidentyfikowanie potencjalnych zagrożeń i wyliczenie mechanizmów kontroli ograniczania ryzyka. Upewnij się, że modelowanie zagrożeń służy do następujących celów:
- Zabezpieczanie aplikacji i usług na etapie wykonywania w środowisku produkcyjnym.
- Zabezpiecz artefakty, bazowy potok ciągłej integracji/ciągłego wdrażania i inne środowisko narzędzi używane do kompilowania, testowania i wdrażania. Modelowanie zagrożeń powinno obejmować przynajmniej następujące aspekty:
- Zdefiniuj wymagania dotyczące zabezpieczeń aplikacji. Upewnij się, że te wymagania zostały odpowiednio uwzględnione w modelowaniu zagrożeń.
- Analizowanie składników aplikacji, połączeń danych i ich relacji. Upewnij się, że ta analiza obejmuje również połączenia nadrzędne i podrzędne poza zakresem aplikacji.
- Lista potencjalnych zagrożeń i wektorów ataków, z którymi mogą być narażone składniki aplikacji, połączenia danych oraz usługi nadrzędne i podrzędne.
- Zidentyfikuj odpowiednie mechanizmy kontroli zabezpieczeń, które mogą służyć do eliminowania zagrożeń wyliczone, i zidentyfikuj luki w zabezpieczeniach (np. luki w zabezpieczeniach), które mogą wymagać dodatkowych planów leczenia.
- Wyliczanie i projektowanie kontrolek, które mogą ograniczyć zidentyfikowane luki w zabezpieczeniach.
Wskazówki dotyczące platformy Azure: użyj narzędzi do modelowania zagrożeń, takich jak narzędzie do modelowania zagrożeń firmy Microsoft z osadzonym szablonem modelu zagrożeń platformy Azure, aby napędzać proces modelowania zagrożeń. Użyj modelu STRIDE, aby wyliczyć zagrożenia zarówno z wewnętrznego, jak i zewnętrznego oraz zidentyfikować odpowiednie mechanizmy kontroli. Upewnij się, że proces modelowania zagrożeń obejmuje scenariusze zagrożeń w procesie DevOps, takie jak wstrzyknięcie złośliwego kodu za pośrednictwem niezabezpieczonego repozytorium artefaktów z nieprawidłowo skonfigurowanymi zasadami kontroli dostępu.
Jeśli użycie narzędzia do modelowania zagrożeń nie ma zastosowania, należy przynajmniej użyć procesu modelowania zagrożeń opartego na kwestionariuszu, aby zidentyfikować zagrożenia.
Upewnij się, że wyniki modelowania lub analizy zagrożeń są rejestrowane i aktualizowane, gdy w aplikacji lub w środowisku zagrożeń występuje duża zmiana wpływu na zabezpieczenia.
Implementacja platformy Azure i dodatkowy kontekst:
- Omówienie modelowania zagrożeń
- Analiza zagrożeń aplikacji (w tym metoda STRIDE + metoda oparta na kwestionariuszu)
- Szablon platformy Azure — Wzornik modelu zagrożeń zabezpieczeń firmy Microsoft
Wskazówki dotyczące platformy AWS: użyj narzędzi do modelowania zagrożeń, takich jak narzędzie do modelowania zagrożeń firmy Microsoft z osadzonym szablonem modelu zagrożeń platformy Azure, aby napędzać proces modelowania zagrożeń. Użyj modelu STRIDE, aby wyliczyć zagrożenia zarówno z wewnętrznego, jak i zewnętrznego oraz zidentyfikować odpowiednie mechanizmy kontroli. Upewnij się, że proces modelowania zagrożeń obejmuje scenariusze zagrożeń w procesie DevOps, takie jak wstrzyknięcie złośliwego kodu za pośrednictwem niezabezpieczonego repozytorium artefaktów z nieprawidłowo skonfigurowanymi zasadami kontroli dostępu.
Jeśli użycie narzędzia do modelowania zagrożeń nie ma zastosowania, należy przynajmniej użyć procesu modelowania zagrożeń opartego na kwestionariuszu, aby zidentyfikować zagrożenia.
Upewnij się, że wyniki modelowania lub analizy zagrożeń są rejestrowane i aktualizowane, gdy w aplikacji lub w środowisku zagrożeń występuje duża zmiana wpływu na zabezpieczenia.
Implementacja platformy AWS i dodatkowy kontekst:
- Microsoft Threat Modeling Tool
- Jak podejść do modelowania zagrożeń dla platformy AWS
- Analiza zagrożeń aplikacji (w tym metoda STRIDE + metoda oparta na kwestionariuszu)
Wskazówki dotyczące platformy GCP: użyj narzędzi do modelowania zagrożeń, takich jak narzędzie do modelowania zagrożeń firmy Microsoft z osadzonym szablonem modelu zagrożeń platformy Azure, aby napędzać proces modelowania zagrożeń. Użyj modelu STRIDE, aby wyliczyć zagrożenia zarówno z wewnętrznego, jak i zewnętrznego oraz zidentyfikować odpowiednie mechanizmy kontroli. Upewnij się, że proces modelowania zagrożeń obejmuje scenariusze zagrożeń w procesie DevOps, takie jak wstrzyknięcie złośliwego kodu za pośrednictwem niezabezpieczonego repozytorium artefaktów z nieprawidłowo skonfigurowanymi zasadami kontroli dostępu.
Jeśli użycie narzędzia do modelowania zagrożeń nie ma zastosowania, należy przynajmniej użyć procesu modelowania zagrożeń opartego na kwestionariuszu, aby zidentyfikować zagrożenia.
Upewnij się, że wyniki modelowania lub analizy zagrożeń są rejestrowane i aktualizowane, gdy w aplikacji lub w środowisku zagrożeń występuje duża zmiana wpływu na zabezpieczenia.
Implementacja GCP i dodatkowy kontekst:
Uczestnicy projektu zabezpieczeń klientów (dowiedz się więcej):
DS-2: Zapewnianie bezpieczeństwa łańcucha dostaw oprogramowania
Kontrolki CIS w wersji 8 | Identyfikatory NIST SP 800-53 r4 | Identyfikatory PCI-DSS w wersji 3.2.1 |
---|---|---|
16.4, 16.6, 16.11 | SA-12, SA-15 | 6.3, 6.5 |
Zasada zabezpieczeń: Upewnij się, że pakiet SDLC (cykl życia tworzenia oprogramowania) lub proces przedsiębiorstwa zawiera zestaw mechanizmów kontroli zabezpieczeń do zarządzania składnikami oprogramowania wewnętrznego i oprogramowania innych firm (w tym oprogramowaniem zastrzeżonym i open source), w którym aplikacje mają zależności. Zdefiniuj kryteria gating, aby zapobiec integrowaniu i wdrażaniu w środowisku składników narażonych na zagrożenia lub złośliwe składniki.
Mechanizmy kontroli zabezpieczeń łańcucha dostaw oprogramowania powinny obejmować co najmniej następujące aspekty:
- Prawidłowe zarządzanie rachunkiem za oprogramowanie (SBOM) przez zidentyfikowanie zależności nadrzędnych wymaganych do opracowywania usług/zasobów, kompilowania, integracji i wdrażania.
- Spis i śledzenie składników oprogramowania wewnętrznego i innych firm pod kątem znanych luk w zabezpieczeniach, gdy istnieje poprawka dostępna w nadrzędnym strumieniu.
- Oceń luki w zabezpieczeniach i złośliwe oprogramowanie w składnikach oprogramowania przy użyciu statycznego i dynamicznego testowania aplikacji pod kątem nieznanych luk w zabezpieczeniach.
- Upewnij się, że luki w zabezpieczeniach i złośliwe oprogramowanie zostały wyeliminowane przy użyciu odpowiedniego podejścia. Może to obejmować lokalną lub nadrzędną poprawkę kodu źródłowego, wykluczenie funkcji i/lub zastosowanie kontrolek wyrównywalnych, jeśli bezpośrednie ograniczenie ryzyka nie jest dostępne.
Jeśli składniki innych firm są używane w środowisku produkcyjnym, może być ograniczony wgląd w jej stan zabezpieczeń. Należy rozważyć dodatkowe mechanizmy kontroli, takie jak kontrola dostępu, izolacja sieci i zabezpieczenia punktu końcowego, aby zminimalizować wpływ, jeśli istnieje złośliwa aktywność lub luka w zabezpieczeniach skojarzona ze składnikiem.
Wskazówki dotyczące platformy Azure: W przypadku platformy GitHub upewnij się, że zabezpieczenia łańcucha dostaw oprogramowania są dostępne za pomocą następujących funkcji lub narzędzi z GitHub Advanced Security lub natywnej funkcji usługi GitHub:- Użyj programu Dependency Graph do skanowania, tworzenia spisu i identyfikowania wszystkich zależności projektu oraz powiązanych luk w zabezpieczeniach za pośrednictwem bazy danych doradczych.
- Użyj narzędzia Dependabot, aby upewnić się, że zależność podatna na zagrożenia jest śledzona i korygowana, i upewnij się, że repozytorium automatycznie nadąża za najnowszymi wersjami pakietów i aplikacji, od których zależy.
- Użyj natywnej funkcji skanowania kodu w usłudze GitHub, aby skanować kod źródłowy podczas zewnętrznego określania źródła kodu.
- Użyj Microsoft Defender for Cloud, aby zintegrować ocenę luk w zabezpieczeniach dla obrazu kontenera w przepływie pracy ciągłej integracji/ciągłego wdrażania. W przypadku usługi Azure DevOps można używać rozszerzeń innych firm do implementowania podobnych kontrolek do spisu, analizowania i korygowania składników oprogramowania innych firm oraz ich luk w zabezpieczeniach.
Implementacja platformy Azure i dodatkowy kontekst:
- GitHub Dependency Graph
- GitHub Dependabot
- Identyfikowanie narażonych obrazów kontenerów w przepływach pracy ciągłej integracji/ciągłego wdrażania
- Azure DevOps Marketplace — zabezpieczenia łańcucha dostaw
Wskazówki dotyczące platform AWS: Jeśli używasz platform AWS CI/CD, takich jak CodeCommit lub CodePipeline, upewnij się, że zabezpieczenia łańcucha dostaw oprogramowania przy użyciu recenzenta CodeGuru skanują kod źródłowy (dla języka Java i Python) za pośrednictwem przepływów pracy ciągłej integracji/ciągłego wdrażania. Platformy, takie jak CodeCommit i CodePipeline, obsługują również rozszerzenia innych firm w celu zaimplementowania podobnych kontrolek do spisu, analizowania i korygowania składników oprogramowania innych firm oraz ich luk w zabezpieczeniach.
Jeśli zarządzasz kodem źródłowym za pośrednictwem platformy GitHub, upewnij się, że bezpieczeństwo łańcucha dostaw oprogramowania jest realizowane za pomocą następujących funkcji lub narzędzi z GitHub Advanced Security lub natywnej funkcji usługi GitHub:
- Użyj programu Dependency Graph do skanowania, tworzenia spisu i identyfikowania wszystkich zależności projektu oraz powiązanych luk w zabezpieczeniach za pośrednictwem bazy danych doradczych.
- Użyj narzędzia Dependabot, aby upewnić się, że zależność podatna na zagrożenia jest śledzona i korygowana, i upewnij się, że repozytorium automatycznie nadąża za najnowszymi wersjami pakietów i aplikacji, od których zależy.
- Użyj natywnej funkcji skanowania kodu w usłudze GitHub, aby skanować kod źródłowy podczas zewnętrznego określania źródła kodu.
- Jeśli ma to zastosowanie, użyj Microsoft Defender for Cloud, aby zintegrować ocenę luk w zabezpieczeniach dla obrazu kontenera w przepływie pracy ciągłej integracji/ciągłego wdrażania.
Implementacja platformy AWS i dodatkowy kontekst:
- GitHub Dependency Graph
- GitHub Dependabot
- Metodyka DevOps na platformie AWS
- Rachunek za oprogramowanie materiałów
Wskazówki dotyczące platformy GCP: Użyj osłony dostarczania oprogramowania, aby przeprowadzić kompleksową analizę zabezpieczeń łańcucha dostaw oprogramowania. Obejmuje to usługę zapewniania systemu operacyjnego (oprogramowania open source) w celu uzyskania dostępu i uwzględnienia pakietów systemu operacyjnego, które zostały zweryfikowane i przetestowane przez firmę Google, a także zweryfikowane pakiety Java i Python utworzone przy użyciu bezpiecznych potoków firmy Google. Te pakiety są regularnie skanowane, analizowane i testowane pod kątem luk w zabezpieczeniach. Takie możliwości można zintegrować z usługą Google Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis w ramach przepływów pracy ciągłej integracji/ciągłego wdrażania.
Jeśli zarządzasz kodem źródłowym za pośrednictwem platformy GitHub, upewnij się, że bezpieczeństwo łańcucha dostaw oprogramowania jest realizowane za pomocą następujących funkcji lub narzędzi z GitHub Advanced Security lub natywnej funkcji usługi GitHub:
- Użyj programu Dependency Graph do skanowania, tworzenia spisu i identyfikowania wszystkich zależności projektu oraz powiązanych luk w zabezpieczeniach za pośrednictwem bazy danych doradczych.
- Użyj narzędzia Dependabot, aby upewnić się, że zależność podatna na zagrożenia jest śledzona i korygowana, i upewnij się, że repozytorium automatycznie nadąża za najnowszymi wersjami pakietów i aplikacji, od których zależy.
- Użyj natywnej funkcji skanowania kodu w usłudze GitHub, aby skanować kod źródłowy podczas zewnętrznego określania źródła kodu.
- Jeśli ma to zastosowanie, użyj Microsoft Defender for Cloud, aby zintegrować ocenę luk w zabezpieczeniach dla obrazu kontenera w przepływie pracy ciągłej integracji/ciągłego wdrażania.
Implementacja GCP i dodatkowy kontekst:
- Zabezpieczenia łańcucha dostaw oprogramowania Google Cloud
- Osłona dostarczania oprogramowania
- Zabezpieczenia łańcucha dostaw oprogramowania
Uczestnicy projektu zabezpieczeń klientów (dowiedz się więcej):
DS-3: Bezpieczna infrastruktura DevOps
Kontrolki CIS w wersji 8 | Identyfikatory NIST SP 800-53 r4 | Identyfikatory PCI-DSS w wersji 3.2.1 |
---|---|---|
16.7 | CM-2, CM-6, AC-2, AC-3, AC-6 | 2.2, 6.3, 7.1 |
Zasada zabezpieczeń: Upewnij się, że infrastruktura i potok DevOps są zgodne z najlepszymi rozwiązaniami dotyczącymi zabezpieczeń w środowiskach, w tym etapami kompilacji, testowania i produkcji. Zwykle obejmuje to mechanizmy kontroli zabezpieczeń dla następującego zakresu:
- Repozytoria artefaktów, które przechowują kod źródłowy, kompilowane pakiety i obrazy, artefakty projektu i dane biznesowe.
- Serwery, usługi i narzędzia hostujące potoki ciągłej integracji/ciągłego wdrażania.
- Konfiguracja potoku ciągłej integracji/ciągłego wdrażania.
Wskazówki dotyczące platformy Azure: W ramach stosowania testu porównawczego zabezpieczeń w chmurze firmy Microsoft do mechanizmów kontroli zabezpieczeń infrastruktury DevOps określ priorytety następujących mechanizmów kontroli:
- Ochrona artefaktów i środowiska bazowego w celu zapewnienia, że potoki ciągłej integracji/ciągłego wdrażania nie staną się możliwe do wstawienia złośliwego kodu. Na przykład przejrzyj potok ciągłej integracji/ciągłego wdrażania, aby zidentyfikować błędną konfigurację w podstawowych obszarach usługi Azure DevOps, takich jak Organizacja, Projekty, Użytkownicy, Potoki (kompilacja & wydanie), Connections i Agent kompilacji, aby zidentyfikować wszelkie błędy konfiguracji, takie jak otwarty dostęp, słabe uwierzytelnianie, niezabezpieczona konfiguracja połączenia itd. W przypadku usługi GitHub użyj podobnych kontrolek, aby zabezpieczyć poziomy uprawnień organizacji.
- Upewnij się, że infrastruktura DevOps jest stale wdrażana w projektach programistycznych. Śledzenie zgodności infrastruktury DevOps na dużą skalę przy użyciu Microsoft Defender for Cloud (na przykład pulpitu nawigacyjnego zgodności, Azure Policy, zarządzania stanem chmury) lub własnych narzędzi do monitorowania zgodności.
- Skonfiguruj uprawnienia tożsamości/roli i zasady uprawnień w Azure AD, usługach natywnych i narzędziach ciągłej integracji/ciągłego wdrażania w potoku, aby upewnić się, że zmiany potoków są autoryzowane.
- Unikaj zapewniania stałego "stałego" uprzywilejowanego dostępu do kont ludzkich, takich jak deweloperzy lub testerzy, przy użyciu funkcji, takich jak tożsamości zarządzane platformy Azure i dostępu just in time.
- Usuwanie kluczy, poświadczeń i wpisów tajnych z kodu i skryptów używanych w zadaniach przepływu pracy ciągłej integracji/ciągłego wdrażania oraz przechowywanie ich w magazynie kluczy lub usłudze Azure Key Vault.
- Jeśli uruchamiasz własnych agentów kompilacji/wdrażania, postępuj zgodnie z instrukcjami testów porównawczych zabezpieczeń w chmurze firmy Microsoft, w tym zabezpieczeniami sieci, stanem i zarządzaniem lukami w zabezpieczeniach oraz zabezpieczeniami punktów końcowych w celu zabezpieczenia środowiska.
Uwaga: zapoznaj się z sekcjami Rejestrowanie i wykrywanie zagrożeń, DS-7 i Stan i Zarządzanie lukami w zabezpieczeniach, aby korzystać z usług, takich jak Azure Monitor i Microsoft Sentinel, aby umożliwić zarządzanie, zgodność, inspekcję operacyjną i inspekcję ryzyka dla infrastruktury DevOps.
Implementacja platformy Azure i dodatkowy kontekst:
- Omówienie kontrolek DevSecOps — bezpieczne potoki
- Zabezpieczanie organizacji usługi GitHub
- Potok usługi Azure DevOps — zagadnienia dotyczące zabezpieczeń agenta hostowanego przez firmę Microsoft
Wskazówki dotyczące platformy AWS: w ramach stosowania testu porównawczego zabezpieczeń w chmurze firmy Microsoft do mechanizmów kontroli zabezpieczeń infrastruktury DevOps, takich jak GitHub, CodeCommit, CodeArtifact, CodePipeline, CodeBuild i CodeDeploy, nadaj priorytet następującym mechanizmom kontroli:
- Zapoznaj się z tym wskazówkami i filarem zabezpieczeń platformy AWS Well-architected Framework, aby zabezpieczyć środowiska DevOps na platformie AWS.
- Chroń artefakty i podstawową infrastrukturę pomocniczą, aby zapewnić, że potoki ciągłej integracji/ciągłego wdrażania nie staną się możliwościami wstawiania złośliwego kodu.
- Upewnij się, że infrastruktura DevOps jest wdrażana i spójna w projektach programistycznych. Śledzenie zgodności infrastruktury DevOps na dużą skalę przy użyciu konfiguracji platformy AWS lub własnego rozwiązania do sprawdzania zgodności.
- Funkcja CodeArtifact umożliwia bezpieczne przechowywanie i udostępnianie pakietów oprogramowania używanych do tworzenia aplikacji. Możesz użyć narzędzia CodeArtifact z popularnymi narzędziami kompilacji i menedżerami pakietów, takimi jak Maven, Gradle, npm, yarn, pip i twine.
- Skonfiguruj uprawnienia tożsamości/roli i zasady uprawnień w usługach AWS IAM, usługach natywnych i narzędziach ciągłej integracji/ciągłego wdrażania w potoku, aby upewnić się, że zmiany potoków są autoryzowane.
- Usuwanie kluczy, poświadczeń i wpisów tajnych z kodu i skryptów używanych w zadaniach przepływu pracy ciągłej integracji/ciągłego wdrażania oraz przechowywanie ich w magazynie kluczy lub usłudze AWS KMS
- Jeśli uruchamiasz własnych agentów kompilacji/wdrażania, postępuj zgodnie z instrukcjami testów porównawczych zabezpieczeń w chmurze firmy Microsoft, w tym zabezpieczeniami sieci, stanem i zarządzaniem lukami w zabezpieczeniach oraz zabezpieczeniami punktów końcowych w celu zabezpieczenia środowiska. Użyj narzędzia AWS Inspector do skanowania luk w zabezpieczeniach pod kątem luk w zabezpieczeniach w środowisku EC2 lub konteneryzowanym jako środowiska kompilacji.
Uwaga: zapoznaj się z sekcjami Rejestrowanie i wykrywanie zagrożeń, DS-7 oraz Zarządzanie stanem i lukami w zabezpieczeniach, aby korzystać z usług, takich jak AWS CloudTrail, CloudWatch i Microsoft Sentinel, aby umożliwić zarządzanie, zgodność, inspekcję operacyjną i inspekcję ryzyka dla infrastruktury DevOps.
Implementacja platformy AWS i dodatkowy kontekst:
Wskazówki dotyczące platformy GCP: W ramach stosowania testu porównawczego zabezpieczeń w chmurze firmy Microsoft do mechanizmów kontroli zabezpieczeń infrastruktury DevOps określ priorytety następujących mechanizmów kontroli:
- Ochrona artefaktów i środowiska bazowego w celu zapewnienia, że potoki ciągłej integracji/ciągłego wdrażania nie staną się możliwe do wstawienia złośliwego kodu. Na przykład przejrzyj potok ciągłej integracji/ciągłego wdrażania, aby zidentyfikować błędną konfigurację w usługach, takich jak Google Cloud Build, Cloud Deploy, Artifact Registry, Connections i Build Agent, aby zidentyfikować wszelkie błędy konfiguracji, takie jak otwarty dostęp, słabe uwierzytelnianie, niepewna konfiguracja połączenia itd. W przypadku usługi GitHub użyj podobnych kontrolek, aby zabezpieczyć poziomy uprawnień organizacji.
- Upewnij się, że infrastruktura DevOps jest stale wdrażana w projektach programistycznych. Śledzenie zgodności infrastruktury DevOps na dużą skalę przy użyciu Centrum poleceń zabezpieczeń w chmurze Google (na przykład pulpit nawigacyjny zgodności, zasady organizacyjne, rejestrowanie poszczególnych zagrożeń i identyfikowanie błędów konfiguracji) lub własnych narzędzi do monitorowania zgodności.
- Skonfiguruj uprawnienia tożsamości/roli i zasady uprawnień w usługach natywnych Cloud Identity/AD oraz narzędzia ciągłej integracji/ciągłego wdrażania w potoku, aby upewnić się, że zmiany potoków są autoryzowane.
- Unikaj zapewniania trwałego "stałego" uprzywilejowanego dostępu do kont ludzkich, takich jak deweloperzy lub testerzy, przy użyciu funkcji, takich jak identyfikacje zarządzane przez firmę Google.
- Usuwanie kluczy, poświadczeń i wpisów tajnych z kodu i skryptów używanych w zadaniach przepływu pracy ciągłej integracji/ciągłego wdrażania oraz przechowywanie ich w magazynie kluczy lub usłudze Google Secret Manager.
- Jeśli uruchamiasz własnych agentów kompilacji/wdrażania, postępuj zgodnie z instrukcjami testów porównawczych zabezpieczeń w chmurze firmy Microsoft, w tym zabezpieczeniami sieci, stanem i zarządzaniem lukami w zabezpieczeniach oraz zabezpieczeniami punktów końcowych w celu zabezpieczenia środowiska.
Uwaga: zapoznaj się z sekcjami Rejestrowanie i wykrywanie zagrożeń, DS-7 oraz Zarządzanie stanem i lukami w zabezpieczeniach, aby korzystać z usług, takich jak Azure Monitor i Microsoft Sentinel, pakiet operacyjny usługi Google Cloud oraz rozwiązanie Chronicle SIEM i SOAR, aby umożliwić zarządzanie, zgodność, inspekcję operacyjną i inspekcję ryzyka dla infrastruktury DevOps.
Implementacja GCP i dodatkowy kontekst:
- Tworzenie bezpiecznego potoku obrazu
- Wdrażanie bezpiecznego potoku ciągłej integracji/ciągłego wdrażania
Uczestnicy projektu zabezpieczeń klientów (dowiedz się więcej):
- Zabezpieczenia aplikacji i metodyka DevSecOps
- Zarządzanie stanem bezpieczeństwa
- Zabezpieczenia infrastruktury i punktu końcowego
- Architektura zabezpieczeń
DS-4: Integrowanie statycznych testów zabezpieczeń aplikacji z potokiem DevOps
Kontrolki CIS w wersji 8 | Identyfikatory NIST SP 800-53 r4 | Identyfikatory PCI-DSS w wersji 3.2.1 |
---|---|---|
16.12 | SA-11 | 6.3, 6.5 |
Zasada zabezpieczeń: Zapewnianie testowania rozmytego statycznego testowania zabezpieczeń aplikacji (SAST), interakcyjnego testowania aplikacji, testowania aplikacji mobilnych, są częścią kontrolek gating w przepływie pracy ciągłej integracji/ciągłego wdrażania. Pobicie można ustawić na podstawie wyników testowania, aby zapobiec zatwierdzaniu pakietów podatnych na zagrożenia w repozytorium, kompilowaniu w pakietach lub wdrażaniu w środowisku produkcyjnym.
Wskazówki dotyczące platformy Azure: integrowanie aplikacji SAST z potokiem (np. w infrastrukturze jako szablonu kodu), aby kod źródłowy mógł być skanowany automatycznie w przepływie pracy ciągłej integracji/ciągłego wdrażania. Usługa Azure DevOps Pipeline lub GitHub może zintegrować poniższe narzędzia i narzędzia SAST innych firm z przepływem pracy.
- GitHub CodeQL na potrzeby analizy kodu źródłowego.
- Microsoft BinSkim Binary Analyzer dla systemu Windows i *nix analizy binarnej.
- Skaner poświadczeń usługi Azure DevOps (rozszerzenie DevOps zabezpieczeń firmy Microsoft) i natywne skanowanie wpisów tajnych usługi GitHub pod kątem skanowania poświadczeń w kodzie źródłowym.
Implementacja platformy Azure i dodatkowy kontekst:
- GitHub CodeQL
- BinSkim Binary Analyzer
- Skanowanie poświadczeń usługi Azure DevOps
- Skanowanie wpisów tajnych usługi GitHub
Wskazówki dotyczące platformy AWS: integrowanie aplikacji SAST z potokiem w celu automatycznego skanowania kodu źródłowego w przepływie pracy ciągłej integracji/ciągłego wdrażania.
W przypadku korzystania z polecenia CodeCommit platformy AWS użyj narzędzia AWS CodeGuru Reviewer na potrzeby analizy kodu źródłowego języka Python i Java. Platforma AWS Codepipeline może również obsługiwać integrację narzędzi SAST trzeciej części z potokiem wdrażania kodu.
W przypadku korzystania z usługi GitHub poniższe narzędzia i narzędzia SAST innych firm można zintegrować z przepływem pracy.
- GitHub CodeQL na potrzeby analizy kodu źródłowego.
- Microsoft BinSkim Binary Analyzer dla systemu Windows i *nix analizy binarnej.
- Natywne skanowanie wpisów tajnych w usłudze GitHub pod kątem skanowania poświadczeń w kodzie źródłowym.
- AwS CodeGuru Reviewer for Python and Java source code analysis (Przegląd kodu źródłowego platformy AWS dla języków Python i Java).
Implementacja platformy AWS i dodatkowy kontekst:
Wskazówki dotyczące platformy GCP: Zintegruj aplikację SAST (taką jak osłona dostarczania oprogramowania, analiza artefaktów) do potoku (np. w infrastrukturze jako szablonu kodu), aby kod źródłowy mógł zostać automatycznie przeskanowany w przepływie pracy ciągłej integracji/ciągłego wdrażania.
Usługi takie jak Cloud Build, Cloud Deploy, Artifact Registry obsługują integrację z osłoną dostarczania oprogramowania i analizą artefaktów, która umożliwia skanowanie kodu źródłowego i innych artefaktów w przepływie pracy ciągłej integracji/ciągłego wdrażania.
Implementacja GCP i dodatkowy kontekst:
- Korzystanie ze skanowania na żądanie w potoku kompilacji w chmurze
- Omówienie osłony dostarczania oprogramowania
Uczestnicy projektu zabezpieczeń klientów (dowiedz się więcej):
DS-5: Integrowanie dynamicznych testów zabezpieczeń aplikacji z potokiem DevOps
Kontrolki CIS w wersji 8 | Identyfikatory NIST SP 800-53 r4 | Identyfikatory PCI-DSS w wersji 3.2.1 |
---|---|---|
16.12 | SA-11 | 6.3, 6.5 |
Zasada zabezpieczeń: Upewnij się, że dynamiczne testowanie zabezpieczeń aplikacji (DAST) jest częścią mechanizmów kontroli agating w przepływie pracy ciągłej integracji/ciągłego wdrażania. Pobicie można ustawić na podstawie wyników testowania, aby zapobiec tworzeniu luk w zabezpieczeniach w pakietach lub wdrażaniu w środowisku produkcyjnym.
Wskazówki dotyczące platformy Azure: integrowanie narzędzia DAST z potokiem w celu automatycznego testowania aplikacji środowiska uruchomieniowego w przepływie pracy ciągłej integracji/ciągłego wdrażania w usłudze Azure DevOps lub GitHub. Zautomatyzowane testy penetracyjne (z ręczną weryfikacją wspomaganą) powinny być również częścią języka DAST.
Usługa Azure DevOps Pipeline lub GitHub obsługuje integrację narzędzi DAST innych firm z przepływem pracy ciągłej integracji/ciągłego wdrażania.
Implementacja platformy Azure i dodatkowy kontekst:
Wskazówki dotyczące platformy AWS: integrowanie narzędzia DAST z potokiem w celu automatycznego testowania aplikacji uruchomieniowej w przepływie pracy ciągłej integracji/ciągłego wdrażania w usłudze AWS CodePipeline lub GitHub. Zautomatyzowane testy penetracyjne (z ręczną weryfikacją wspomaganą) powinny być również częścią języka DAST.
Platforma AWS CodePipeline lub GitHub obsługuje integrację narzędzi DAST innych firm z przepływem pracy ciągłej integracji/ciągłego wdrażania.
Implementacja platformy AWS i dodatkowy kontekst:
Wskazówki dotyczące platformy GCP: integrowanie narzędzia DAST (takiego skanera zabezpieczeń w chmurze) z potokiem, aby aplikacja środowiska uruchomieniowego mogła być automatycznie testowana w przepływie pracy ciągłej integracji/ciągłego wdrażania w usługach, takich jak Google Cloud Build, Cloud Deploy lub GitHub. Skaner zabezpieczeń w chmurze może służyć do identyfikowania luk w zabezpieczeniach aplikacji internetowych obciążeń hostowanych w usłudze App Engine, Google Kubernetes Engine (GKE) i aparatu obliczeniowego. Zautomatyzowane testy penetracyjne (z ręczną weryfikacją wspomaganą) powinny być również częścią języka DAST.
Google Cloud Build, Google Cloud Deploy, Artifact Registry i GitHub obsługują również integrację narzędzi DAST innych firm z przepływem pracy ciągłej integracji/ciągłego wdrażania.
Implementacja GCP i dodatkowy kontekst:
Uczestnicy projektu zabezpieczeń klientów (dowiedz się więcej):
DS-6: Wymuszanie zabezpieczeń obciążenia w całym cyklu życia metodyki DevOps
Kontrolki CIS w wersji 8 | Identyfikatory NIST SP 800-53 r4 | Identyfikatory PCI-DSS w wersji 3.2.1 |
---|---|---|
7.5, 7.6, 7.7, 16.1, 16.7 | CM-2, CM-6, AC-2, AC-3, AC-6 | 6.1, 6.2, 6.3 |
Zasada zabezpieczeń: Upewnij się, że obciążenie jest zabezpieczone w całym cyklu życia na etapie programowania, testowania i wdrażania. Użyj testu porównawczego zabezpieczeń w chmurze firmy Microsoft, aby ocenić mechanizmy kontroli (takie jak zabezpieczenia sieci, zarządzanie tożsamościami, uprzywilejowany dostęp itd.), które można ustawić jako zabezpieczenia domyślnie lub przesunąć w lewo przed etapem wdrażania. W szczególności upewnij się, że w procesie DevOps są stosowane następujące kontrolki:- Zautomatyzuj wdrożenie przy użyciu narzędzi platformy Azure lub innych firm w przepływie pracy ciągłej integracji/ciągłego wdrażania, zarządzaniu infrastrukturą (infrastruktura jako kod) i testowaniu w celu zmniejszenia liczby błędów ludzkich i obszaru ataków.
- Upewnij się, że maszyny wirtualne, obrazy kontenerów i inne artefakty są zabezpieczone przed złośliwym manipulowaniem.
- Skanuj artefakty obciążenia (innymi słowy obrazy kontenerów, zależności, skanowania SAST i DAST) przed wdrożeniem w przepływie pracy ciągłej integracji/ciągłego wdrażania
- Wdrażanie funkcji oceny luk w zabezpieczeniach i wykrywania zagrożeń w środowisku produkcyjnym i ciągłe korzystanie z tych funkcji w czasie wykonywania.
Wskazówki dotyczące platformy Azure: Wskazówki dotyczące maszyn wirtualnych platformy Azure:
- Użyj usługi Azure Shared Image Gallery, aby udostępniać i kontrolować dostęp do obrazów przez różnych użytkowników, jednostki usługi lub grupy usługi AD w organizacji. Użyj kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby mieć pewność, że tylko autoryzowani użytkownicy będą mogli uzyskiwać dostęp do obrazów niestandardowych.
- Zdefiniuj punkty odniesienia bezpiecznej konfiguracji dla maszyn wirtualnych, aby wyeliminować niepotrzebne poświadczenia, uprawnienia i pakiety. Wdrażanie i wymuszanie konfiguracji odniesienia za pomocą obrazów niestandardowych, szablonów usługi Azure Resource Manager i/lub Azure Policy konfiguracji gościa.
Wskazówki dotyczące usług kontenerów platformy Azure:
- Użyj Azure Container Registry (ACR), aby utworzyć prywatny rejestr kontenerów, w którym szczegółowy dostęp można ograniczyć za pośrednictwem kontroli dostępu opartej na rolach platformy Azure, więc tylko autoryzowane usługi i konta mogą uzyskiwać dostęp do kontenerów w rejestrze prywatnym.
- Użyj usługi Defender for Containers do oceny luk w zabezpieczeniach obrazów w prywatnym Azure Container Registry. Ponadto możesz użyć Microsoft Defender for Cloud, aby zintegrować skanowanie obrazów kontenera w ramach przepływów pracy ciągłej integracji/ciągłego wdrażania.
W przypadku usług bezserwerowych platformy Azure należy zastosować podobne mechanizmy kontroli w celu zapewnienia kontroli zabezpieczeń "shift-left" do etapu przed wdrożeniem.
Implementacja platformy Azure i dodatkowy kontekst:
- omówienie Shared Image Gallery
- Jak zaimplementować Microsoft Defender dla zaleceń dotyczących oceny luk w zabezpieczeniach w chmurze
- Zagadnienia dotyczące zabezpieczeń kontenera platformy Azure
- Usługa Azure Defender dla rejestrów kontenerów
Wskazówki dotyczące platformy AWS: usługa Amazon Elastic Container Registry umożliwia udostępnianie i kontrolowanie dostępu do obrazów przez różnych użytkowników i role w organizacji. Użyj usługi IAM platformy AWS, aby mieć pewność, że tylko autoryzowani użytkownicy będą mogli uzyskiwać dostęp do obrazów niestandardowych.
Zdefiniuj bezpieczne konfiguracje odniesienia dla obrazów EC2 AMI w celu wyeliminowania niepotrzebnych poświadczeń, uprawnień i pakietów. Wdrażanie i wymuszanie konfiguracji odniesienia za pomocą niestandardowych obrazów AMI, szablonów CloudFormation i/lub reguł konfiguracji platformy AWS.
Użyj narzędzia AWS Inspector do skanowania luk w zabezpieczeniach środowisk maszyn wirtualnych i konteneryzowanych, zabezpieczając je przed złośliwym manipulowaniem.
W przypadku usług bezserwerowych aws użyj interfejsu API CodePipeline platformy AWS w połączeniu z aplikacją AWS AppConfig, aby zastosować podobne mechanizmy kontroli w celu zapewnienia kontroli zabezpieczeń "przesunięcie w lewo" do etapu przed wdrożeniem.
Implementacja platformy AWS i dodatkowy kontekst:
Wskazówki dotyczące platformy GCP: Usługa Google Cloud zawiera kontrolki do ochrony zasobów obliczeniowych i zasobów kontenera usługi Google Kubernetes Engine (GKE). Firma Google obejmuje maszynę wirtualną z osłoną, która wzmacnia zabezpieczenia wystąpień maszyn wirtualnych. Zapewnia zabezpieczenia rozruchu, monitoruje integralność i używa wirtualnego modułu zaufanej platformy (vTPM).
Analiza artefaktów w chmurze Google służy do skanowania luk w zabezpieczeniach w obrazach kontenera lub systemu operacyjnego oraz innych typów artefaktów na żądanie lub automatycznie w potokach. Wykrywanie zagrożeń kontenera umożliwia ciągłe monitorowanie określonych obrazów węzłów systemu operacyjnego Container-Optimized. Usługa ocenia wszystkie zmiany i próby dostępu zdalnego w celu wykrycia ataków w czasie niemal rzeczywistym.
Użyj usługi Artifact Registry, aby skonfigurować bezpieczny magazyn artefaktów prywatnej kompilacji, aby zachować kontrolę nad tym, kto może uzyskiwać dostęp do artefaktów, wyświetlać lub pobierać artefakty z natywnymi rolami i uprawnieniami funkcji zarządzania dostępem i tożsamościami rejestru, a także zapewnić spójny czas pracy w bezpiecznej i niezawodnej infrastrukturze firmy Google.
W przypadku usług bezserwerowych GCP należy zastosować podobne mechanizmy kontroli w celu zapewnienia kontroli zabezpieczeń "shift-left" do etapu przed wdrożeniem.
Implementacja GCP i dodatkowy kontekst:
- Rejestr artefaktów
- Zabezpieczenia aplikacji i metodyka DevSecOps
- Zarządzanie stanem bezpieczeństwa
- Architektura zabezpieczeń
Uczestnicy projektu zabezpieczeń klientów (dowiedz się więcej):
- Zabezpieczenia aplikacji i metodyka DevSecOps
- Zarządzanie stanem bezpieczeństwa
- Architektura zabezpieczeń
DS-7: Włączanie rejestrowania i monitorowania w usłudze DevOps
Kontrolki CIS w wersji 8 | Identyfikatory NIST SP 800-53 r4 | Identyfikatory PCI-DSS w wersji 3.2.1 |
---|---|---|
8.2, 8.5, 8.9, 8.11 | AU-3, AU-6, AU-12, SI-4 | 10.1, 10.2, 10.3, 10.6 |
Zasada zabezpieczeń: Upewnij się, że zakres rejestrowania i monitorowania obejmuje środowiska nieprodukcyjne i elementy przepływu pracy ciągłej integracji/ciągłego wdrażania używane w metodyce DevOps (i innych procesach programistycznych). Luki w zabezpieczeniach i zagrożeniach przeznaczonych dla tych środowisk mogą powodować znaczne ryzyko dla środowiska produkcyjnego, jeśli nie są one prawidłowo monitorowane. Zdarzenia z kompilacji ciągłej integracji/ciągłego wdrażania, przepływu pracy testowania i wdrażania powinny być również monitorowane w celu zidentyfikowania wszelkich odchyleń w zadaniach przepływu pracy ciągłej integracji/ciągłego wdrażania.
Wskazówki dotyczące platformy Azure: Włączanie i konfigurowanie możliwości rejestrowania inspekcji w środowiskach narzędzi nieprodukcyjnych i ciągłej integracji/ciągłego wdrażania (takich jak Azure DevOps i GitHub) używanych w całym procesie DevOps.
Zdarzenia generowane przez usługę Azure DevOps i przepływ pracy ciągłej integracji/ciągłego wdrażania usługi GitHub, w tym zadania kompilacji, testowania i wdrażania, powinny być również monitorowane w celu zidentyfikowania wszelkich nietypowych wyników.
Pozyskiwanie powyższych dzienników i zdarzeń do usługi Microsoft Sentinel lub innych narzędzi SIEM za pośrednictwem strumienia rejestrowania lub interfejsu API w celu zapewnienia prawidłowego monitorowania i klasyfikacji zdarzeń zabezpieczeń pod kątem obsługi.
Implementacja platformy Azure i dodatkowy kontekst:
Wskazówki dotyczące platformy AWS: Włączanie i konfigurowanie usługi AWS CloudTrail na potrzeby możliwości rejestrowania inspekcji w środowiskach narzędzi nieprodukcyjnych i ciągłej integracji/ciągłego wdrażania (takich jak AWS CodePipeline, AWS CodeBuild, AWS CodeStar, AWS CodeStar) używanych w całym procesie DevOps.
Zdarzenia generowane ze środowisk ciągłej integracji/ciągłego wdrażania platformy AWS (takie jak AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) i przepływ pracy ciągłej integracji/ciągłego wdrażania usługi GitHub, w tym zadania kompilacji, testowania i wdrażania, powinny być również monitorowane w celu zidentyfikowania wszelkich nietypowych wyników.
Pozyskiwanie powyższych dzienników i zdarzeń do usług AWS CloudWatch, Microsoft Sentinel lub innych narzędzi SIEM za pośrednictwem strumienia rejestrowania lub interfejsu API w celu zapewnienia prawidłowego monitorowania i klasyfikacji zdarzeń zabezpieczeń pod kątem obsługi.
Implementacja platformy AWS i dodatkowy kontekst:
- Łączenie usługi Microsoft Sentinel z usługą Amazon Web Services w celu pozyskiwania danych dzienników usługi AWS
- Rejestrowanie w usłudze GitHub
Wskazówki dotyczące platformy GCP: Włączanie i konfigurowanie możliwości rejestrowania inspekcji w środowiskach narzędzi nieprodukcyjnych i ciągłej integracji/ciągłego wdrażania dla produktów, takich jak Cloud Build, Google Cloud Deploy, Artifact Registry i GitHub, które mogą być używane w całym procesie DevOps.
Zdarzenia generowane ze środowisk ciągłej integracji/ciągłego wdrażania platformy GCP (takich jak Cloud Build, Google Cloud Deploy, Artifact Registry) i przepływ pracy ciągłej integracji/ciągłego wdrażania usługi GitHub, w tym zadania kompilacji, testowania i wdrażania, powinny być również monitorowane w celu zidentyfikowania wszelkich nietypowych wyników.
Pozyskiwanie powyższych dzienników i zdarzeń do usługi Microsoft Sentinel, Google Cloud Security Command Center, Chronicle lub innych narzędzi SIEM za pośrednictwem strumienia rejestrowania lub interfejsu API w celu zapewnienia prawidłowego monitorowania i klasyfikacji zdarzeń zabezpieczeń pod kątem obsługi.
Implementacja GCP i dodatkowy kontekst:
- Polecane produkty do ciągłej integracji/ciągłego wdrażania
- Wprowadzenie do pakietu operacji usługi Google Cloud
- Najlepsze rozwiązania dotyczące rejestrowania w chmurze
- Pozyskiwanie danych z chmury Google do kroniki
Uczestnicy projektu zabezpieczeń klientów (dowiedz się więcej):