Skanowanie bezpieczeństwa infrastruktury jako kodu

Narzędzia Infrastructure as Code (IaC), takie jak Terraform, AWS CloudFormation, Ansible i Helm, umożliwiają definiowanie infrastruktury w plikach konfiguracyjnych objętych kontrolą wersji. Zapewnia to ogromne korzyści — powtarzalność, możliwość audytu i automatyzację — ale wiąże się również z krytycznym ryzykiem bezpieczeństwa: błędne konfiguracje w plikach IaC prowadzą do tworzenia niezabezpieczonej infrastruktury na dużą skalę. Jeden nieprawidłowo skonfigurowany moduł Terraform wdrożony w 50 środowiskach tworzy jednocześnie 50 podatnych systemów. Skanowanie bezpieczeństwa IaC ogranicza to ryzyko, sprawdzając pliki konfiguracyjne przed ich zastosowaniem i przenosząc działania związane z bezpieczeństwem na wcześniejszy etap procesu pracy programisty.

Narzędzia do skanowania bezpieczeństwa wyszukują najczęstsze błędne konfiguracje IaC spotykane w rzeczywistych środowiskach chmurowych: zasobniki S3 z włączonym publicznym dostępem lub bez szyfrowania w stanie spoczynku; grupy zabezpieczeń z regułami przychodzącymi 0.0.0.0/0 dla wrażliwych portów (22, 3389, 1433); bazy danych bez szyfrowania lub z publicznym dostępem; zasady IAM z symbolami wieloznacznymi zasobów lub działań *; CloudTrail wyłączony w regionie; klucze KMS bez rotacji; oraz moduły równoważenia obciążenia z odbiornikami HTTP zamiast HTTPS. Wyniki te dokładnie odzwierciedlają kontrole wykonywane przez standardy bezpieczeństwa chmury, takie jak CIS AWS Foundations.

Checkov (firmy Bridgecrew/Prisma Cloud) to popularne narzędzie open source do analizy statycznej IaC, obsługujące Terraform, CloudFormation, manifesty Kubernetes, wykresy Helm i pliki Dockerfile. Zawiera ponad 1000 wbudowanych zasad powiązanych ze wzorcami CIS oraz wymaganiami GDPR, SOC 2 i HIPAA. Uruchomienie checkov -d . skanuje wszystkie pliki IaC w bieżącym katalogu i generuje oznaczony kolorami raport zaliczonych, niezaliczonych i pominiętych kontroli, wraz ze ścieżkami zasobów i wskazówkami dotyczącymi usunięcia problemów. Checkov można zintegrować z potokami CI/CD, aby blokować wdrożenia, gdy krytyczne kontrole zakończą się niepowodzeniem.

tfsec (obecnie część funkcji skanowania IaC w Trivy) to wyspecjalizowany skaner bezpieczeństwa Terraform, który dogłębnie rozumie składnię HCL, dzięki czemu może śledzić wartości w modułach i plikach zmiennych. W przeciwieństwie do prostszych skanerów tfsec wykrywa błędne konfiguracje, w których problem obejmuje wiele plików — na przykład regułę grupy zabezpieczeń, która osobno wygląda bezpiecznie, ale jest przypisana do zasobu znajdującego się w innym pliku. tfsec generuje wyniki z poziomami ważności (CRITICAL, HIGH, MEDIUM, LOW), identyfikatorami CWE i bezpośrednimi odnośnikami do dokumentacji dotyczącej usuwania problemów, dzięki czemu programiści mogą od razu podjąć odpowiednie działania.

Jednym z najpoważniejszych problemów bezpieczeństwa IaC są sekrety zapisane na stałe w plikach konfiguracyjnych — hasła, klucze API, prywatne klucze TLS i parametry połączeń z bazami danych zatwierdzone w repozytorium Git. Ponieważ repozytoria IaC są często współdzielone między zespołami i przechowywane w historii kontroli wersji, sekret zatwierdzony choćby raz jest w praktyce trwale skompromitowany (historii Git nie można zmienić). Narzędzia takie jak Checkov, detect-secrets, git-secrets i TruffleHog skanują pliki w poszukiwaniu wzorców sekretów. Rozwiązaniem jest używanie zmiennych wejściowych pobierających wartości ze zmiennych środowiskowych lub magazynów sekretów, a nie wartości zapisanych na stałe.

Frameworki Policy as Code (PaC) umożliwiają zespołom bezpieczeństwa zapisywanie własnych reguł w kodzie i ich spójne egzekwowanie. Open Policy Agent (OPA) wraz z Conftest umożliwia tworzenie zasad w języku Rego, które weryfikują dowolne dane strukturalne — plany Terraform, manifesty Kubernetes i wartości Helm — w potokach CI/CD. HashiCorp Sentinel jest wbudowany w Terraform Enterprise i Cloud, dzięki czemu można egzekwować zasady takie jak „wszystkie zasobniki S3 muszą mieć włączone szyfrowanie” już na etapie planowania, blokując każde zastosowanie planu, które naruszałoby tę zasadę. Narzędzia te pozwalają zapisywać wymagania bezpieczeństwa w postaci kodu i przechowywać je w systemie kontroli wersji wraz z infrastrukturą, której dotyczą.

Rozbieżność konfiguracji występuje, gdy rzeczywisty stan wdrożonej infrastruktury odbiega od definicji IaC — często dlatego, że ktoś ręcznie wprowadził zmianę w konsoli chmurowej. Reguła grupy zabezpieczeń dodana ręcznie w celu „tymczasowego” odblokowania pracy programisty może stać się trwałą luką. Narzędzia do wykrywania rozbieżności stale porównują stan pożądany (pliki IaC) z rzeczywistym stanem wdrożonej infrastruktury i zgłaszają odchylenia. AWS Config, funkcja wykrywania rozbieżności w Terraform Cloud oraz narzędzia CSPM (Prisma Cloud, Wiz) udostępniają tę funkcję. Błędne konfiguracje bezpieczeństwa wprowadzone przez zmiany w konsoli zostają wykryte, zanim odkryją je atakujący.

Niezmienna infrastruktura oznacza, że serwery i konfiguracje nigdy nie są modyfikowane w miejscu — zamiast tego zmiany tworzą nowe zasoby (nowe AMI, nowe obrazy kontenerów) i zastępują stare. W połączeniu z GitOps (gdzie wszystkie zmiany infrastruktury muszą przejść przez żądanie pull w Git, uruchamiające przepływy skanowania IaC i zatwierdzania) rozwiązanie to z założenia eliminuje rozbieżności konfiguracji: jeśli czegoś nie można zmienić ręcznie, nie może powstać rozbieżność. Narzędzia takie jak ArgoCD dla Kubernetes i Atlantis dla Terraform implementują przepływy GitOps, w których każde odchylenie wyzwala automatyczne uzgodnienie stanu lub alert.

Skanowanie bezpieczeństwa IaC bywa mylone z SAST (Static Application Security Testing), ale te technologie analizują różne artefakty. SAST analizuje kod źródłowy aplikacji (Python, Java, JavaScript) pod kątem luk, takich jak SQL injection czy przepełnienie bufora. Skanowanie IaC analizuje pliki konfiguracji infrastruktury pod kątem błędnych konfiguracji bezpieczeństwa chmury — nie dotyczy kodu aplikacji. Kompletny potok DevSecOps obejmuje oba rodzaje kontroli: SAST dla kodu aplikacji i skanowanie IaC dla plików infrastruktury. Oba uruchamiają się w CI/CD przed każdym wdrożeniem. Niektóre ujednolicone platformy (Snyk IaC, Prisma Cloud) łączą skanowanie aplikacji i infrastruktury w jednym narzędziu.

Skuteczne skanowanie bezpieczeństwa IaC musi być zautomatyzowane i egzekwowane — nie może być opcjonalne. Typowa integracja z CI/CD wygląda następująco: przy każdym żądaniu pull uruchamiane są Checkov i tfsec; potok kończy się niepowodzeniem, jeśli występują wyniki CRITICAL; wyniki są publikowane jako komentarze do żądania pull, aby były widoczne dla programistów; utrzymywana jest lista wyciszonych wyników wraz z udokumentowanymi uzasadnieniami; a każdej nocy uruchamiane jest skanowanie wdrożonych zasobów pod kątem rozbieżności. Haki pre-commit wykorzystujące narzędzia takie jak pre-commit z Checkov mogą wykrywać problemy jeszcze przed przesłaniem kodu do potoku. Ważne jest zarządzanie fałszywymi alarmami — programiści, którzy widzą zbyt wiele nieistotnych wyników, zaczynają je ignorować.

Plik stanu Terraform (terraform.tfstate) zawiera pełny wykaz wszystkich zarządzanych zasobów, często wraz z wrażliwymi wartościami wyjściowymi, takimi jak hasła do baz danych, prywatne klucze TLS i identyfikatory kluczy dostępu IAM zapisane jawnym tekstem. Plików stanu nigdy nie wolno zatwierdzać w repozytorium Git. Zamiast tego należy używać zdalnego backendu (AWS S3 z blokowaniem za pomocą DynamoDB, Terraform Cloud lub stanu zarządzanego przez GitLab) z włączonym szyfrowaniem po stronie serwera. Dostęp do backendu stanu musi być ściśle kontrolowany za pomocą IAM — każdy, kto może odczytać plik stanu, może wyliczyć szczegóły całej infrastruktury i potencjalnie wydobyć osadzone sekrety.

Sprawdź znajomość zagadnień z CompTIA Security+ (SY0-701) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że błędne konfiguracje IaC, takie jak publiczne zasobniki S3, otwarte grupy zabezpieczeń i sekrety zapisane na stałe, są automatycznie wykrywane przez narzędzia takie jak Checkov i tfsec przed wdrożeniem; frameworki Policy as Code (OPA/Conftest, HashiCorp Sentinel) umożliwiają egzekwowanie niestandardowych wymagań bezpieczeństwa organizacji za pomocą automatycznych bram w potoku; a pliki stanu Terraform muszą być przechowywane w zaszyfrowanych zdalnych backendach z restrykcyjną kontrolą dostępu, ponieważ mogą zawierać poufne informacje o zasobach. Następnie omówimy cykl życia APT oraz sposób, w jaki zaawansowane zagrożenia utrzymują się w sieciach.