bezpieczeństwo infrastruktury jako kodu (IaC)

Bezpieczeństwo infrastruktury jako kodu (infrastructure as code security, IaC security) to dbanie o to, by pliki opisujące serwery i usługi chmurowe, pisane w narzędziach takich jak Terraform, Ansible czy CloudFormation, nie tworzyły luk: otwartych portów, publicznych bucketów, zbyt szerokich uprawnień albo haseł wpisanych w kod. Microsoft opisuje podejście, w którym definicje infrastruktury są jedynym źródłem prawdy, a walidacja, skanowanie bezpieczeństwa i kontrola zgodności są zautomatyzowane w całym cyklu wdrożenia ^[1]. Szablony skanuje się pod kątem błędów, zanim trafią na produkcję.

Jak działa

Infrastruktura jako kod zamienia ręczne klikanie w konsoli na pliki w repozytorium. Każda zmiana przechodzi przez przegląd, testy i automatyczne wdrożenie. Ta sama cecha działa w obie strony: poprawny szablon powiela dobrą konfigurację, a błędny powiela lukę na wszystkie środowiska naraz.

Microsoft opisuje przepływ, w którym pull request uruchamia zautomatyzowane testy w GitHub Actions, a akcja zabezpieczeń skanuje definicje infrastruktury pod kątem błędów konfiguracji jeszcze przed wdrożeniem ^[1]. Porównuje to do statycznego testowania bezpieczeństwa aplikacji (SAST), tyle że stosowanego do kodu infrastruktury ^[1]. Schemat poniżej pokazuje miejsca kontroli.

Narzędzia IaC dzielą się z grubsza na dwie grupy. Pierwsze, jak Terraform czy CloudFormation, opisują docelowy stan zasobów: sieci, maszyn, baz i uprawnień. Drugie, jak Ansible, konfigurują system wewnątrz już istniejącej maszyny: pakiety, usługi, pliki konfiguracyjne. Obie grupy wymagają tych samych zabezpieczeń, bo w obu przypadkach plik tekstowy decyduje o tym, co będzie otwarte na świat. OWASP zaleca dodatkowo oznaczanie zasobów chmurowych tagami, żeby nie powstawały zasoby-widma, o których nikt nie pamięta ^[2], oraz śledzenie wszystkich zmian IaC w systemie kontroli wersji ^[2].

RYS. 1Kontrole w cyklu życia szablonu IaC

Typowe błędy

Skanery IaC szukają powtarzalnych wzorców. Najczęstsze klasy problemów zebrano w tabeli.

MITRE opisuje słabość CWE-798 jako produkt zawierający zaszyte poświadczenia, takie jak hasło lub klucz kryptograficzny ^[4]. W IaC pojawia się ona, gdy hasło do bazy trafia wprost do szablonu i do historii repozytorium.

Osobnym problemem jest plik stanu. Dokumentacja Terraform stwierdza, że lokalnie narzędzie przechowuje stan w pliku jawnym, zawierającym wartości sekretów zdefiniowanych w konfiguracji, i zaleca traktować ten plik jako wrażliwy oraz trzymać go poza repozytorium ^[3].

W WordPressie

Infrastruktura jako kod pojawia się w WordPressie, gdy stronę uruchamia się w kontenerach, na własnych instancjach w chmurze albo z playbooków Ansible. Najczęściej chodzi o dane dostępowe do bazy oraz o klucze bezpieczeństwa i sole.

Oficjalny obraz Docker WordPress pozwala dopisać przyrostek _FILE do zmiennych środowiskowych, tak by skrypt startowy wczytał wartość z pliku w kontenerze, na przykład z sekretu Docker w katalogu /run/secrets ^[5]. Zmienne kluczy i soli, takie jak WORDPRESS_AUTH_KEY, domyślnie przyjmują unikalne losowe wartości, ale tylko wtedy, gdy podano inną konfigurację przez zmienne ^[5]. Przykład obronny, bez hasła w pliku:

services:
  wordpress:
    image: wordpress
    environment:
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

Warto też pilnować, by szablon nie kopiował na serwer plików, które nie powinny tam być: zrzutów bazy, plików .env czy katalogu .git. To typowe publicznie dostępne pliki wrażliwe. Konfigurację samego WordPressa opisuje utwardzanie pliku wp-config.php.

Zagrożenia i skutki

• Powielenie luki. Jeden błędny moduł trafia do wielu środowisk, łącznie ze środowiskiem testowym (staging), które bywa gorzej chronione.
• Wyciek sekretów. Hasło w repozytorium zostaje w historii, nawet po usunięciu z bieżącej wersji; kończy się to często wyciekiem danych.
• Przejęcie przez potok. Tożsamość, która wdraża infrastrukturę, ma zwykle szerokie uprawnienia; zob. atak na potok CI/CD (CI/CD pipeline compromise).
• Dryf konfiguracji. Microsoft zwraca uwagę, że dryf bywa trudny do usunięcia, gdy infrastruktura już działa, zwłaszcza na produkcji ^[1].

Dobre praktyki

OWASP zaleca kontrole na etapie tworzenia, wdrożenia i działania ^[2]:

• wtyczki bezpieczeństwa w środowisku programistycznym, by wcześnie wykrywać ryzyka ^[2];
• narzędzia analizy statycznej wykrywające błędną konfigurację w samym kodzie IaC ^[2];
• wykrywanie sekretów i zakaz trzymania ich w plikach tekstowych i w Git ^[2], czyli zarządzanie sekretami;
• modelowanie zagrożeń na wczesnym etapie cyklu ^[2];
• skanowanie obrazów kontenerów, np. narzędziami Trivy, Anchore lub Clair ^[2];
• ograniczanie uprawnień użytkowników IaC do niezbędnego minimum ^[2], zgodnie z zasadą najmniejszych uprawnień.

Microsoft dodaje wdrażanie przez OpenID Connect bez przechowywania poświadczeń oraz uprzywilejowany dostęp just-in-time (just-in-time access) do wyjątkowych zmian ręcznych, które następnie uzgadnia się z definicją w repozytorium ^[1]. Terraform oferuje wartości efemeryczne, dostępne w czasie operacji, ale pomijane w plikach stanu i planu ^[3]:

variable "db_password" {
  type      = string
  sensitive = true
  ephemeral = true
}

Na etapie działania OWASP proponuje infrastrukturę niezmienną: zamiast modyfikować istniejące zasoby, tworzy się nowe z poprawionego szablonu, co ogranicza dryf ^[2]. Zaleca też włączenie logów bezpieczeństwa i audytu oraz stałe monitorowanie ^[2].

Skan przed wdrożeniem nie zastępuje kontroli po wdrożeniu. Działające konta chmurowe ocenia CSPM, a zdarzenia z infrastruktury warto kierować do systemu SIEM (Security Information and Event Management) ^[1].