Infrastruktura jako kod (IaC) bezpieczeństwo

TL;DR: Infrastruktura jako kod (IaC) bezpieczeństwo

Bezpieczeństwo infrastruktury jako kodu (IaC) to proces zabezpieczania infrastruktury chmurowej poprzez skanowanie plików konfiguracyjnych lub skryptów napisanych w określonych językach, takich jak Terraform, CloudFormation, Kubernetes YAML itp., przed wdrożeniem.

Ten proces pomoże Ci:

• Wcześnie wykrywać błędne konfiguracje, takie jak przypadkowe otwieranie niepotrzebnych portów lub nadawanie nadmiernych uprawnień użytkownikom.
• Egzekwować polityki bezpieczeństwa jako kod w potokach CI/CD.
• Zmniejszać ryzyko naruszeń bezpieczeństwa chmury, ujawnienia danych i problemów z zgodnością spowodowanych niebezpiecznymi konfiguracjami w skryptach.

Celem bezpieczeństwa IaC jest zapewnienie, że sposób budowy infrastruktury chmurowej jest bezpieczny.

Co to jest bezpieczeństwo infrastruktury jako kodu (IaC)

Bezpieczeństwo infrastruktury jako kodu (IaC) to proces zabezpieczania infrastruktury chmurowej, która jest definiowana i zarządzana za pomocą określonego kodu, takiego jak pliki Terraform, AWS CloudFormation, Pulumi lub Kubernetes YAML.

Zamiast ręcznie konfigurować serwery, sieci i zasoby chmurowe za pomocą terminala lub interfejsu webowego, zespoły opisują wszystkie konfiguracje w kodzie. Bezpieczeństwo IaC zapewnia, że kod do budowy infrastruktury chmurowej jest bezpieczny, nie wprowadza błędnych konfiguracji, podatności ani nadmiernych uprawnień przed jego wdrożeniem.

W prostych słowach:

Bezpieczeństwo IaC sprawdza „jak Twoja chmura jest skonfigurowana i zbudowana”, abyś nie wdrażał niebezpiecznej infrastruktury do produkcji.

Dlaczego bezpieczeństwo IaC ma znaczenie

Kiedy zarządzasz infrastrukturą za pomocą kodu, przyspieszasz jej konfigurację. Jednak z drugiej strony, możesz również wdrożyć podatną na zagrożenia infrastrukturę w produkcji.

Dlaczego bezpieczeństwo IaC jest ważne:

Błędne konfiguracje są główną przyczyną naruszeń bezpieczeństwa w chmurze.

Przykład: publiczne zasobniki S3, otwarte bazy danych lub szeroko otwarte grupy zabezpieczeń ujawniające wrażliwe dane w Internecie.

Jeden błędny wiersz w kodzie może wpłynąć na wiele zasobów.

Jeśli moduł Terraform ustawia 0.0.0.0/0 (otwarte dla wszystkich) dla dostępu, każde środowisko korzystające z niego staje się narażone.

IaC jest częścią łańcucha dostaw oprogramowania.

Ponieważ IaC jest częścią łańcucha dostaw oprogramowania, atakujący mogą infiltrując pipeline’y w celu wprowadzenia tylnych drzwi lub błędnych konfiguracji, kompromitując infrastrukturę.

Zgodność zależy od poprawnej konfiguracji.

Ramki takie jak SOC 2, ISO 27001 i PCI DSS opierają się na bezpiecznych konfiguracjach, kontroli dostępu i logowaniu. Niebezpieczne IaC może złamać zgodność.

Jak działa bezpieczeństwo IaC

Bezpieczeństwo IaC wychwytuje podatności w infrastrukturze zanim zostanie wdrożona.

1. Skanowanie plików IaC pod kątem błędnych konfiguracji

Narzędzia analizują Twoje pliki Terraform, CloudFormation lub manifesty Kubernetes w celu znalezienia ryzykownych ustawień takich jak:

• Publiczne zasobniki S3
• Baza danych wystawiona na publiczny dostęp.
• Grupy zabezpieczeń z 0.0.0.0/0 (otwarte dla publiczności)
• Kontenery działające jako root
• Niezaszyfrowane przechowywanie lub logi

Cel: wychwycić problemy z bezpieczeństwem zanim dotrą do chmury

2. Egzekwowanie polityk bezpieczeństwa jako kod

Zasady bezpieczeństwa są pisane jako polityki, na przykład:

• Nie wolno używać publicznych baz danych Amazon RDS (Relational Database Service)
• Wszystkie zasobniki S3 muszą używać szyfrowania.
• Pody Kubernetes nie mogą uruchamiać kontenerów uprzywilejowanych.

Te zasady są automatycznie egzekwowane w potokach CI/CD.

Cel: Uczyń zasady bezpieczeństwa częścią swojego procesu rozwoju, a nie późniejszym dodatkiem.

3. Integracja z potokami CI/CD

Narzędzia bezpieczeństwa IaC integrują się z CI/CD, aby automatycznie blokować lub ostrzegać o ryzykownych zmianach.

Typowy przepływ:

1. Programista zatwierdza kod infrastruktury.
2. Potok CI/CD uruchamia skanowanie bezpieczeństwa IaC.
3. Jeśli zostanie znaleziony krytyczny problem (np. publiczna baza danych), kompilacja kończy się niepowodzeniem.
4. Programista naprawia problem przed wdrożeniem.

Cel: Przesunięcie w lewo, wykrywanie problemów wcześnie przed wdrożeniem

4. Mapowanie do postawy bezpieczeństwa chmury

Bezpieczeństwo IaC jest często łączone z CSPM (Cloud Security Posture Management)

• CSPM sprawdza, co faktycznie działa w chmurze, na przykład sprawdzając, czy baza danych nie jest wystawiona na internet, czy zasobnik magazynowy jest zaszyfrowany i tak dalej.
• Bezpieczeństwo IaC sprawdza, co ma być wdrożone

Razem dają pełną widoczność infrastruktury w projektowaniu i czasie działania.

Typowe zagrożenia bezpieczeństwa IaC

Przykłady problemów, które bezpieczeństwo IaC może wykryć:

• Publicznie wystawione magazyny (np. zasobniki S3 z publicznym odczytem/zapisem)
• Niezaszyfrowane bazy danych, woluminy lub logi
• Zbyt szerokie role IAM
• Otwarte grupy bezpieczeństwa (0.0.0.0/0 dla SSH/RDP).
• Pody Kubernetes uruchamiane z uprzywilejowanym dostępem.
• Zaszyte sekrety w plikach Terraform lub YAML.

Przykład w praktyce

Zespół używa Terraform do zarządzania infrastrukturą AWS.

Skanowanie bezpieczeństwa IaC wskazuje:

• Bazę danych RDS z włączonym dostępem publicznym
• Zasobnik S3 bez szyfrowania i z publicznym dostępem do odczytu

Zamiast wdrażać tę niebezpieczną konfigurację do AWS, pipeline zatrzymuje budowę.

Następnie deweloper musi:

• Zaktualizować grupę bezpieczeństwa, aby ograniczyć dostęp
• Włączyć szyfrowanie i zablokować publiczny dostęp do zasobnika S3.

Rezultat: Nieprawidłowe konfiguracje są naprawiane zanim trafią do produkcji, zmniejszając ryzyko ujawnienia danych.

Kto używa bezpieczeństwa IaC

• DevOps - piszą i utrzymują szablony IaC
• Inżynierowie bezpieczeństwa chmury - definiują polityki i przeglądają konfiguracje.
• Zespoły AppSec / DevSecOps - integrują IaC w pipeline
• Zespoły ds. bezpieczeństwa i zgodności - używają raportów do audytów i zarządzania.

Kiedy stosować bezpieczeństwo IaC

Bezpieczeństwo IaC powinno być stosowane w całym cyklu życia:

• Podczas rozwoju - haki pre-commit i wtyczki IDE.
• Podczas budowy CI/CD - automatyczne skanowanie może blokować ryzykowne zmiany.
• Przed wdrożeniem - kontrole polityki dla środowisk produkcyjnych.
• Ciągle - ponowne skanowanie szablonów, gdy pojawiają się nowe zasady lub zagrożenia.

Kluczowe możliwości narzędzi bezpieczeństwa IaC

Większość rozwiązań bezpieczeństwa IaC zapewnia:

• Polityka jako kod: Definiowanie i kontrola wersji reguł bezpieczeństwa
• Analiza statyczna IaC: Skanowanie Terraform, CloudFormation, konfiguracji Kubernetes, itp.
• Integracja CI/CD: Github Actions, GitLab CI, Jenkins, itp.
• Wykrywanie błędnej konfiguracji: Identyfikacja niebezpiecznej konfiguracji
• Wykrywanie odchyleń (z CSPM): Wykrywanie różnic między konfiguracją IaC a rzeczywistą chmurą.
• Raportowanie i mapowanie zgodności: Mapowanie problemów do kontroli i regulacji.

Przykładowe narzędzia: Checkov, Tfsec, Terrascan, lub zaawansowane platformy takie jak Plexicus ASPM, gdy skanują IaC jako część postawy aplikacji/chmury.

Najlepsze praktyki dla bezpieczeństwa IaC

• Przesunięcie w lewo: skanowanie IaC wcześnie, aby wychwycić problemy bezpieczeństwa przed dotarciem do produkcji
• Unikanie zakodowanych na stałe sekretów (klucze API, tokeny, itp.)
• Wymuszanie najmniejszych uprawnień
• Używanie polityki jako kodu do automatyzacji spójnego egzekwowania.
• Regularne przeglądanie i aktualizowanie polityk w miarę zmian architektury.

Powiązane terminy

• CSPM (Zarządzanie postawą bezpieczeństwa chmury)
• DevSecOps
• Zero Trust
• Wykrywanie sekretów