Terraform i bezpieczeństwo IaC: techniczny przewodnik

Bezpieczeństwo Terraform i Infrastructure as Code nie kończy się na przeskanowaniu plików .tf. Terraform pobiera wykonywalne pluginy providerów, ładuje moduły, przetwarza zmienne, buduje plan, przechowuje mapowanie zasobów w state i wykonuje operacje z tożsamością runnera. Przejęcie któregokolwiek z tych elementów może zmienić infrastrukturę, ujawnić sekrety albo ominąć ręczne zabezpieczenia chmury.

Najważniejsza zasada brzmi: pipeline IaC jest uprzywilejowanym systemem zarządzania, a plan, state, provider i runner są częścią jego granicy zaufania. Dobry audyt analizuje cały przepływ od commita do zasobu oraz drogę powrotną telemetrii. Test dynamiczny powinien odbywać się w izolowanym koncie lub projekcie i używać harmless resources. Nie należy wykonywać nieprzejrzanego apply na produkcji tylko po to, aby potwierdzić błąd, który widać już w planie i polityce.

Model zagrożeń dla Terraform

Praktyczny model obejmuje co najmniej dziewięć elementów:

Element	Pytanie bezpieczeństwa
Repozytorium	kto może zmienić kod, właścicieli, workflow i wymagania review?
Moduły	skąd pochodzą, jaka wersja jest wybrana i czy źródło jest niezmienne?
Providery	jaki binarny plugin zostanie uruchomiony i czy hash jest zaufany?
Zmienne	skąd trafiają dane wrażliwe i kto może odczytać ich wartości?
Plan	kto go wygenerował, dla jakiego commita i czy po akceptacji może się zmienić?
State	gdzie jest przechowywany, kto go czyta, modyfikuje i odzyskuje?
Runner	jaka tożsamość, sieć, filesystem i narzędzia są dostępne procesowi?
Backend	jak działa szyfrowanie, blokada, wersjonowanie i separacja tenantów?
Chmura	jakie skutki może osiągnąć tożsamość wykonująca plan i apply?

Do grafu trzeba dodać system pull requestów, rejestry, cache CI, artefakty, narzędzia policy as code, webhooki i administratorów platformy. Zagrożeniem nie jest wyłącznie błąd developera. Może nim być przejęte konto, złośliwa aktualizacja zależności, podmieniony runner, ujawniony state albo niekontrolowany drift poza Terraform.

Co dzieje się podczas init, plan i apply

Podczas terraform init narzędzie inicjalizuje backend, pobiera moduły i instaluje providery. To moment kontaktu z zewnętrznym łańcuchem dostaw. terraform plan odświeża znany stan, porównuje konfigurację z obiektami i tworzy propozycję zmian. Zapisany plan może następnie zostać przekazany do terraform apply, które wykonuje operacje przez API providerów.

Bezpieczny proces wiąże cztery wartości:

1. dokładny commit kodu;
2. zestaw modułów i providerów;
3. konkretny, zatwierdzony artefakt planu;
4. tożsamość i środowisko wykonujące apply.

Jeżeli pipeline po akceptacji generuje nowy plan albo pobiera inną zależność, review nie dotyczy tego, co ostatecznie zostanie wdrożone. Dokumentacja terraform plan rozróżnia plan spekulacyjny od zapisanego planu przeznaczonego dla automatyzacji. Zapisany plan należy traktować jako wrażliwy artefakt wykonawczy, nie zwykły log.

Providery: kod wykonywany z prawami runnera

Provider Terraform jest pluginem wykonywalnym. Komunikuje się z Terraform, lecz działa w systemie runnera i wykorzystuje dostępne mu poświadczenia oraz sieć. Zaufanie do providera musi więc obejmować źródło, wersję, integralność i proces aktualizacji.

Plik .terraform.lock.hcl zapisuje wybrane wersje i hashe providerów. Dokumentacja dependency lock file wyjaśnia, że Terraform sprawdza zgodność pobranego pakietu z zapisanymi checksumami. Lock file powinien być commitowany i przeglądany. Aktualizacja providera musi być osobnym, widocznym zdarzeniem z testami i analizą changelogu.

Ważne ograniczenie: lock file obecnie śledzi zależności providerów, nie wersje zdalnych modułów. Moduł trzeba przypiąć w source i version albo do niezmiennego commita/taga o kontrolowanym procesie. Gałąź main, ruchomy tag lub niekontrolowany adres Git sprawiają, że ten sam commit konfiguracji może pobrać inną treść.

Prywatny mirror lub registry redukuje zależność od publicznej dostępności i pozwala stosować allowlistę. Nie zwalnia jednak z kontroli pochodzenia. Warto korzystać z zasad SBOM, podpisów i VEX dla narzędzi uruchamianych w pipeline.

State: najbardziej niedoceniany zasób Terraform

State mapuje adresy zasobów Terraform na obiekty dostawcy i przechowuje atrybuty potrzebne do kolejnych operacji. Może zawierać identyfikatory, endpointy, metadane, dane połączeniowe, wygenerowane hasła i inne wartości wrażliwe. Oznaczenie zmiennej lub outputu jako sensitive ogranicza prezentację w CLI i interfejsie, lecz nie oznacza automatycznego usunięcia wartości ze state.

HashiCorp opisuje ochronę sensitive data w state i zaleca zabezpieczenie backendu. W praktyce potrzebne są:

• szyfrowanie w tranzycie i spoczynku z zarządzanym kluczem;
• precyzyjna kontrola odczytu, zapisu, lock i wersji historycznych;
• wersjonowanie oraz odporność na przypadkowe usunięcie;
• blokada współbieżnych operacji;
• oddzielny state dla różnych środowisk i granic zaufania;
• centralne logowanie odczytu i modyfikacji;
• zakaz publikowania state jako artefaktu CI lub załącznika zgłoszenia;
• procedura odzyskania, która nie pomija kontroli dostępu.

State nie powinien być przechowywany w Git. Nawet po usunięciu pliku sekret może pozostać w historii, cache, backupie i forku. Incydent wymaga rotacji ujawnionych wartości, nie tylko skasowania commita.

Plan i logi również mogą ujawniać dane

Plan zawiera proponowane wartości potrzebne do wykonania zmiany. Redakcja UI nie powinna być traktowana jako gwarancja, że zapisany plik planu nie zawiera danych wrażliwych. Dostęp do artefaktu musi odpowiadać prawom do infrastruktury, którą może zmienić. Ustaw krótką retencję, szyfrowanie i powiązanie z jednym przebiegiem.

Logi debug Terraform i providerów mogą ujawnić requesty, odpowiedzi albo zmienne. Nie włączaj wysokiego poziomu logowania globalnie na współdzielonym runnerze. Materiał diagnostyczny powinien mieć ograniczoną retencję, automatyczną redakcję i osobny proces udostępniania.

Sekrety należy pobierać w czasie wykonania z kontrolowanego systemu, używać krótkotrwałych poświadczeń i unikać przesyłania wartości do Terraform, jeśli provider lub usługa potrafią odwołać się do sekretu przez identyfikator. Szczegóły organizacyjne opisuje zarządzanie sekretami, Vault, KMS i rotacja.

Tożsamość runnera i blast radius

Runner wykonujący plan często potrzebuje odczytu szerokiej części środowiska, a apply — praw zapisu. Nie oznacza to, że jedna globalna rola administratora jest konieczna. Rozdziel role według środowiska, stosu i odpowiedzialności. Preferuj federację OIDC oraz krótkotrwałe tokeny zamiast statycznych kluczy w sekretach CI.

Kontroluj również:

• kto może zmienić definicję workflow i wybrać runner;
• czy kod z niezaufanego pull requesta otrzymuje sekrety;
• czy runner jest efemeryczny i oczyszczany po jobie;
• czy outbound network pozwala pobrać dowolny binarny plik;
• czy cache .terraform może być współdzielony między różnymi poziomami zaufania;
• czy rola planu różni się od roli apply;
• czy produkcyjny apply wymaga zatwierdzenia osoby, która nie stworzyła zmiany;
• czy dostęp awaryjny jest audytowany i wygasa.

Tożsamość wykonawcza powinna mieć permissions boundary, SCP lub odpowiednik dostawcy ograniczający skutki, których Terraform nigdy nie powinien osiągać. Taki guardrail chroni także przed błędem modułu i providera. Szerszy pentest chmury powinien sprawdzić, czy ograniczenie działa poza samym pipeline.

Policy as code: blokowanie skutku przed apply

Policy as code analizuje konfigurację lub plan i wymusza wymagania organizacji. Przykłady reguł obejmują zakaz publicznego storage, niezaszyfrowanych baz, globalnego ingress, niezatwierdzonych regionów, wyłączenia logów, privileged workloadów i zasobów bez tagów właściciela.

Najlepsze reguły odnoszą się do skutku i mają:

• identyfikator kontroli oraz właściciela;
• jasny komunikat z bezpiecznym wzorcem;
• testy pozytywne i negatywne;
• wersjonowanie oraz review;
• ścieżkę wyjątku z datą wygaśnięcia;
• metrykę false positive i czasu naprawy;
• tryb monitorowania przed wymuszeniem nowej zasady.

HCP Terraform obsługuje policy enforcement z Sentinel i integracjami OPA. Narzędzie nie jest najważniejsze; kluczowe jest, aby polityka oceniała ten sam zapisany plan, który zostanie zastosowany, oraz aby administrator projektu nie mógł bez śladu pominąć kontroli.

Drift i zmiany poza Terraform

IaC nie gwarantuje, że wszystkie zmiany przechodzą przez kod. Administrator może zmodyfikować zasób ręcznie, usługa może uzupełnić wartości domyślne, a operator lub autoscaling — utworzyć elementy dynamiczne. Drift należy wykrywać cyklicznym planem read-only, konfiguracją dostawcy, cloud audit logs i regułami posture management.

Nie wykonuj automatycznego apply każdej wykrytej różnicy. Plan może usuwać ręczną zmianę awaryjną albo zasób przejęty do innego systemu. Proces powinien sklasyfikować drift, ustalić właściciela, zdecydować czy importować, cofnąć czy udokumentować wyjątek, a następnie przetestować rezultat.

Bezpieczna metodologia audytu Terraform

1. Mapowanie pipeline’u

Rysujemy przepływ commit → review → init → plan → polityka → akceptacja → apply → state → monitoring. Dla każdej krawędzi zapisujemy identity, artefakt, storage, sieć i log.

2. Analiza statyczna

Sprawdzamy providery, moduły, źródła, wersje, backend, zmienne, outputy, dynamic blocks i ryzykowne zasoby. Łączymy skaner z ręcznym przeglądem modułów, ponieważ reguła syntaktyczna nie zna pełnego kontekstu biznesowego.

3. Plan w izolowanym środowisku

Generujemy plan dla dedykowanego konta lub projektu z nieszkodliwymi danymi. Testujemy policy as code, approval i tożsamość runnera. Nie uruchamiamy kodu z niezaufanej gałęzi z produkcyjnymi sekretami.

4. Minimalny apply

Jeżeli potrzebny jest test dynamiczny, tworzymy mały, oznaczony zasób o limicie kosztu i automatycznym cleanupie. Potwierdzamy cloud audit log, state, drift detection i destroy. Nie dotykamy istniejących danych.

5. Test kontroli awarii

Sprawdzamy blokadę state, przerwany job, brak providera, wygaśnięcie tokenu i rollback procesu. Nie symulujemy awarii przez uszkodzenie produkcyjnego state. Używamy kopii i osobnego backendu.

Detekcja i reagowanie

Korelacja powinna łączyć commit, autora, review, hash planu, job, runner, sesję chmurową i zmiany zasobów. Alertuj na:

• zmianę workflow, backendu, źródła modułu lub providera;
• nietypową aktualizację .terraform.lock.hcl;
• produkcyjny apply poza zaakceptowanym pipeline;
• odczyt lub zmianę state przez nową tożsamość;
• wyłączenie policy check albo użycie wyjątku bez właściciela;
• zmianę zasobu w chmurze bez odpowiadającego commita i run ID;
• nietypowe pobranie artefaktu planu;
• użycie statycznego klucza lub sesji o zbyt długim czasie.

W incydencie zatrzymujemy apply, zachowujemy plan i logi, unieważniamy sesje, blokujemy złośliwy commit, oceniamy state oraz cloud audit logs i rotujemy osiągalne sekrety. Następnie odtwarzamy runner z zaufanego obrazu.

Hardening Terraform i IaC

1. Chroń branch, CODEOWNERS, wymagane review i podpisany kontekst buildu.
2. Przypinaj providery, commituj lock file i aktualizuj zależności osobnym PR.
3. Przypinaj moduły do kontrolowanych wersji; pamiętaj, że lock file ich nie obejmuje.
4. Używaj efemerycznych runnerów i krótkotrwałej federacji OIDC.
5. Oddziel role plan i apply oraz środowiska produkcyjne od testowych.
6. Szyfruj, wersjonuj i blokuj zdalny state; ogranicz również wersje historyczne.
7. Traktuj plan, logi i cache jako potencjalnie wrażliwe artefakty.
8. Wymuszaj policy as code na zapisanym planie i kontroluj wyjątki.
9. Wykrywaj drift, ale wymagaj decyzji przed automatyczną korektą.
10. Buduj platformę zgodnie z Secure by Design i analizuj błędy konfiguracji chmury.

Checklista bezpieczeństwa Terraform

• Pipeline wiąże commit, lock file, plan, approval i apply.
• Providerzy i moduły mają przypięte, kontrolowane źródła.
• Lock file jest w repozytorium i jego zmiany podlegają review.
• State jest zdalny, szyfrowany, wersjonowany, blokowany i audytowany.
• Sensitive values nie trafiają do repo, logów ani trwałych artefaktów.
• Runner jest efemeryczny i używa krótkotrwałej tożsamości.
• Kod niezaufanego PR nie otrzymuje sekretów ani roli apply.
• Policy as code ocenia dokładnie plan przeznaczony do wdrożenia.
• Drift jest wykrywany i ma formalny proces decyzji.
• Cloud audit logs wskazują run ID i commit dla każdej zmiany.
• Test awarii i odzyskania state odbywa się na odizolowanej kopii.

Źródła pierwotne

• HashiCorp Terraform — Dependency lock file
• HashiCorp Terraform — Manage sensitive data in state
• HashiCorp Terraform — terraform plan
• HCP Terraform — Policy enforcement
• NIST SP 800-218 — Secure Software Development Framework
• OpenSSF Scorecard
• SLSA supply-chain framework