Bezpieczny rurociąg dostarczania Terraform – najlepsze praktyki. Część 2/2

Wraz z łatwością i szybkością wprowadzania zmian w konfiguracji zasobów chmurowych, pojawia się duże ryzyko wprowadzenia problemów, a także złamania zasad compliance czy standardów firmowych.

Celem testowania infrastruktury i ciągłej zgodności jest zapewnienie automatycznej weryfikacji zasad infrastruktury. Na przykład: 

• Ogranicz dozwolone typy i lokalizacje zasobów,
• Weryfikacja typów i rozmiarów maszyn,
• Zweryfikuj konfigurację zasobów (np. parametry, nazewnictwo, tagi, warstwy, konfigurację szyfrowania),
• Sprawdź wersje oprogramowania i rozszerzenia zainstalowane na maszynach wirtualnych,
• Sprawdź konfigurację audytu zastosowaną do zasobów,
• Zweryfikuj role i przypisania IAM (np. minimalną/maksymalną liczbę administratorów),
• Sprawdź konfigurację wdrożeń Kubernetes, np. dozwolone obrazy, porty, limity i konwencje nazewnictwa.

Terraform może bardzo szybko wprowadzić zmiany i mieć ogromny wpływ na infrastrukturę. Dlatego automatyczne testowanie i weryfikacja zasad jest tak samo ważne, jak w każdej innej platformie programistycznej. 

Może to oznaczać:

•  Weryfikacja wymagań
  Zautomatyzowana weryfikacja niektórych wymagań niefunkcjonalnych i założeń projektu, które wymagają ciągłej weryfikacji przed zatwierdzeniem projektu. Przypomina to testy jednostkowe/integracyjne w procesie tworzenia oprogramowania. Zwykle zespół tworzący skrypty Terraform zapewnia również testy.
• Zgodność jako kod
  Automatyczna weryfikacja polityki zgodności firmy, organizacji lub przepisów przy użyciu zestawu reguł. Reguły mogą dotyczyć typu zasobu (np. usług zabronionych), lokalizacji zasobów, typów maszyn, typu i wersji systemu operacyjnego, opcji replikacji, poziomu cenowego/SLA, konwencji dotyczących tagowania lub nazewnictwa itp. wymaganych w całej organizacji. Oddzielny zespół może zapewnić zasady i standardy zgodności dotyczące całej firmy.
• Bezpieczeństwo jako kod 
  Zautomatyzowana weryfikacja polityk bezpieczeństwa wprowadzonej infrastruktury. Reguły mogą dotyczyć kontroli RBAC, sieci, zapór sieciowych, kontroli dostępu do chmury, magazynów kluczy, kluczy, kluczy tajnych i certyfikatów, szyfrowania itp. wymaganych w całej organizacji. Reguły bezpieczeństwa można budować wspólnie z zespołem ds. bezpieczeństwa IT, a także przy użyciu narzędzi stron trzecich.

Ogólnie rzecz biorąc, istnieją dwie warstwy weryfikacji infrastruktury jako kodu:

• Przed wdrożeniem – weryfikacja kodu Terraform lub planu Terraform, bardziej zbliżona do analizy kodu Wstatic,
• Post-wdrożenie – Weryfikacja zasobów utworzonych w środowisku chmurowym po zastosowaniu konfiguracji Terraform.

To są:

• Konfiguracja AWS-a
• Azure Policy + Centrum zabezpieczeń Azure
• Walidator konfiguracji Forseti dla GCP

Usługi zgodności w chmurze są czasami dostarczane wraz z zestawem zasad odwzorowanych na standardy branżowe, takie jak HIPAA, ISO 27001 lub CSA Benchmarks. Tworzenie niestandardowych reguł nie zawsze jest łatwe. Narzędzia te mogą obejmować weryfikację zasad w ramach zestawu projektów/kont/subskrypcji firmowych, które nie zawsze są „na żądanie” podczas uruchamiania potoku Terraform.

Jedno z podejść obserwowanych w dużych organizacjach polega na tym, że istnieją oddzielne zespoły utrzymujące ogólnofirmowe zasady zgodności i infrastrukturę w formie kodu. Oznacza to, że zespół ds. infrastruktury musi przestrzegać standardów i zasad, ale nie zawsze jest autorem nowych zasad. Oprócz testowania infrastruktury należy stosować narzędzia polityki ciągłej.

AWS Config to usługa, która na bieżąco monitoruje i rejestruje konfiguracje zasobów AWS oraz pozwala na weryfikację ogólnej zgodności z konfiguracjami określonymi w wewnętrznych wytycznych firmy. Zawiera zestaw około 150 gotowych reguł zarządzanych, a także pakiet SDK do tworzenia i testowania niestandardowych reguł konfiguracji AWS. 

Ponieważ reguły AWS Config są w rzeczywistości funkcjami AWS Lambda zdefiniowanymi w NodeJS lub Pythonie, w Githubie dostępna jest obszerna biblioteka reguł.

Przykładowy fragment kodu w Pythonie:

Ogólnie rzecz biorąc, weryfikację można uruchomić zgodnie z harmonogramem lub podczas tworzenia lub modyfikowania zasobów. Wyniki można zweryfikować asynchronicznie za pomocą interfejsu API AWS lub konsoli. 

W przypadku projektów na dużą skalę dostępna jest kompletna platforma Compliance Engine do zarządzania zestawem reguł na oddzielnym koncie zgodności.

Weryfikację konfiguracji AWS można włączyć do procesu wdrażania Terraform jako kontrolę po wydaniu. Wyniki nie są jednak natychmiastowe i konieczne będzie pewne kodowanie, aby zebrać kompleksowy raport zgodności. Ma to zatem na celu zapewnienie, że wdrożona zmiana nadal będzie zgodna ze standardami firmy, a nie wykorzystywanie jej jako etapu testowania.

AWS Config umożliwia grupowanie reguł wraz z działaniami zaradczymi w pakiety zgodności (również „jako kod” przy użyciu szablonów YAML), które można łatwo wdrożyć na wielu kontach i regionach. Przykładowe pakiety zgodności:

• Najlepsze praktyki operacyjne dla Amazon S3
• Najlepsze praktyki operacyjne dla Amazon DynamoDB
• Najlepsze praktyki operacyjne dla PCI-DSS
• Najlepsze praktyki operacyjne w zakresie zarządzania tożsamością i dostępem w AWS

Dzięki wykorzystaniu AWS Control Tower możliwe jest:

• zintegrować reguły AWS Config z kompleksowym pulpitem nawigacyjnym dotyczącym zgodności i przeglądu zgodności w organizacji z wieloma kontami,
• posiadać Fabrykę Kont do tworzenia nowych Kont AWS z predefiniowanymi regułami i ustawieniami.

Ogólnie rzecz biorąc, AWS Config to wszechstronne rozwiązanie umożliwiające obsługę zgodności ze standardami w całej firmie w postaci kodu i bezpieczeństwa w postaci kodu. Może nie być to najszybszy sposób wdrożenia weryfikacji wymagań poszczególnych rozwiązań, gdzie proste testy mogą być łatwiejsze w utrzymaniu. Jego użycie w potoku Terraform jest możliwe jako dodatek do wbudowanego rozwiązania do ciągłej zgodności AWS, ale nie jest konieczne.

Plusy:

• Elastyczność i rozszerzalność, ponieważ reguły są rzeczywistym kodem w Pythonie lub JavaScript,
• SDK do tworzenia reguł oraz szeroki zestaw reguł open source oprócz wbudowanych,
• Dostępne są narzędzia open source dla całego wielokontowego silnika zgodności oraz integracja z Control Tower.

Cons:

• Kod reguł może stać się skomplikowany i stanowić cały projekt programistyczny,
• Reguła nie może zapobiec utworzeniu niezgodnego zasobu (tylko tryb detektywa),
• Włączenie weryfikacji reguł asynchronicznych do potoku Terraform CD wymaga złożonego rozwiązania.

Azure Policy to system zbudowany z deklaratywnie zdefiniowanych reguł stosowanych do wszystkich zasobów w zakresie przypisanej polityki. Azure Policies można przypisać zarówno na poziomie Subskrypcji Azure, jak i na poziomie Grupy Zarządzającej (grupa Subskrypcji, np. cała organizacja, wszystkie subskrypcje produkcyjne itp.).

Platforma Azure udostępnia ponad 1000 predefiniowanych, sparametryzowanych zasad. Polityki niestandardowe definiowane są w kodzie JSON, a każda polityka składa się z 3 części:

• Parametry – są definiowane w trakcie zadania
• Reguła polityki – część reguły „jeśli”. 
• Efekt – polityka może zgłosić alert (audyt) lub uniemożliwić utworzenie zasobu (odmowa)

Przykładowy fragment kodu polityki:

Polityki w trybie „odmowy” działają jak dodatkowe reguły walidacji, co oznacza, że ​​zasób, który nie przejdzie weryfikacji, nie zostanie utworzony.

Oprócz tego zasady mogą zaradzić niektórym zagrożeniom – np. automatycznie zainstalować wymagane rozszerzenia maszyny wirtualnej lub zmodyfikować konfigurację.

Sprawdzanie zasad Azure można uwzględnić jako sprawdzanie poprawności po wdrożeniu w potoku wydania Azure DevOps.

Oprócz poszczególnych polityk na platformie Azure dostępnych jest wiele predefiniowanych Inicjatyw Politycznych , na przykład:

• Audyt kontroli ISO 27001:2013 i wdrażanie określonych rozszerzeń maszyn wirtualnych w celu obsługi wymagań audytu (56 kontroli zasad)
• Audyt kontroli PCI v3.2.1:2018 i wdrażanie określonych rozszerzeń maszyn wirtualnych w celu obsługi wymagań audytu (37 kontroli zasad)
• Przeprowadź audyt rekomendacji CIS Microsoft Azure Foundations Benchmark 1.1.0 i wdróż określone obsługujące rozszerzenia maszyn wirtualnych (83 kontrole zasad)

Inicjatywy Polityczne to sparametryzowane grupy polityk, które można przypisać na poziomie Subskrypcji lub Grupy Zarządzającej i które można tworzyć niestandardowo zgodnie ze standardami firmy. Istnieje domyślna inicjatywa Security Center zawierająca ponad 90 konfigurowalnych zasad i jest domyślnie przypisana do każdej subskrypcji platformy Azure. 

Azure Security Center to pojedyncze miejsce umożliwiające zarządzanie wynikami wszystkich kontroli zasad w całej organizacji, a także grupowaniem wyników różnych systemów wykrywania zagrożeń (sieć, Active Directory, maszyny wirtualne itp.). Ponieważ zasady są weryfikowane okresowo, Centrum zabezpieczeń może zapewnić ciągłą zgodność na platformie Azure, udostępniając mechanizm alertów i historię weryfikacji. Aby uprościć proces zarządzania zgodnością w całej firmie, firmy mogą również utrzymywać plany platformy Azure. Plan to połączenie zasad i inicjatyw wraz z domyślnymi grupami zasobów i konfiguracją dostępu IAM.

Zasady platformy Azure są bardzo zaawansowane, ale narzędzie nie zapewnia przyjaznego dla programistów interfejsu do tworzenia niestandardowych reguł, zwłaszcza gdy jako język używany jest JSON. Nawet bez niestandardowych zasad zestaw predefiniowanych zasad jest imponujący i może spełnić szeroki zakres wymagań dotyczących zgodności. Kompletne rozwiązanie w zakresie zgodności w postaci kodu może łączyć testy infrastruktury i zasady platformy Azure.

Plusy:

• Duży zestaw predefiniowanych polityk i inicjatyw dotyczących wymagań zgodności ze standardami branżowymi,
• Wbudowana integracja z Azure DevOps i Azure Security Center,
• Polityka może pracować w trybie „odmowy”,
• Zarządzanie polityką za pomocą inicjatyw i planów.

Cons:

• Tworzenie niestandardowych zasad w JSON jest trudne,
• Realizacja polis „na żądanie” nie jest możliwa.

Firma Google udostępniła projekt Forseti Security na zasadach open source, aby zająć się sprawdzaniem reguł bezpieczeństwa i egzekwowaniem zasad w Google Cloud. Jest to system typu polityka jako kod, który składa się z wielu modułów  i współpracuje z:

• Usługa Forseti Security działająca w Google Cloud i wykonująca migawki konfiguracji w celu monitorowania polityki.
• Forseti Config Validator, który ocenia zasoby GCP pod kątem reguł Forseti.
• Forseti Terraform Validator weryfikujący plan terraformu pod kątem zasad Forseti/

Biblioteka reguł Forseti jest biblioteką typu open source i wykorzystuje pliki Rego (z platformy Open Policy Agent) do definiowania szablonów reguł zasad.

Oto przykładowa zasada zabraniająca publicznych adresów IP dla baz danych Cloud SQL:

Korzystanie z szablonów zasad wymaga jedynie zdefiniowania ograniczeń w kodzie YAML. Jeśli brakuje szablonu zasad dla rzeczywistego przypadku użycia, Forseti udostępnia narzędzia i wytyczne dotyczące tworzenia i testowania niestandardowych polityk. 

Konfigurowanie Forseti Security wymaga uruchomienia dedykowanej infrastruktury w GCP, która składa się z Cloud SQL, obliczeń i Cloud Storage. Google zaleca utworzenie osobnego projektu, który będzie środowiskiem monitorowania zasad. Forseti zapewnia konfigurację Terraform do instalacji. Serwer wybiera konfigurację zasad wdrożoną w Google Cloud Storage, a następnie:

• stale monitoruje politykę,
• potrafi egzekwować zasady bezpieczeństwa,
• przechowuje migawki konfiguracji Cloud w Cloud SQL.

Aby zwiększyć ogólną widoczność zasad i stanu zabezpieczeń, Google udostępnia  pulpit nawigacyjny Security Command Center. Oprócz Forseti, GCSCC może wykorzystywać inne systemy wykrywania zagrożeń jako źródło alertów o lukach w zabezpieczeniach, takie jak:

• Wykrywanie zapobiegania utracie danych w chmurze,
• Wykrywanie anomalii,
• Wykrywanie zagrożeń zdarzeń,
• Narzędzia bezpieczeństwa w chmurze innych firm od Acalvio, Capsule8, Cavirin, Chef, Check Point CloudGuard Dome9, Cloudflare, CloudQuest, McAfee, Qualys, Redblaze, Redlock, StackRox, Tenable.io i Twistlock.

Forseti Security oferuje kompletne narzędzia zapewniające zgodność w postaci kodu, które można wykorzystać w ramach potoku Terraform CD na etapie przed wdrożeniem (z Forseti Terraform Validator), jak i po wdrożeniu (z Forseti Config Validator). Ciągłe wsparcie w zakresie zgodności z Cloud Command Center i innymi systemami wtyczek składa się na kompletne rozwiązanie. 

Ponieważ jest to rozwiązanie zorientowane na bezpieczeństwo, może wymagać znacznego wysiłku w celu wdrożenia dodatkowych niestandardowych kontroli wymagań niefunkcjonalnych, dlatego dobrym pomysłem może być połączenie go z podejściem do testowania infrastruktury.

Plusy :

• Wsparcie walidacji konfiguracji GCP oraz walidacji Terraform,
• Język reguł deklaratywnych ze wsparciem narzędziowym,
• Integracja z Security Command Center.

Cons :

• Wymaga instalacji i konserwacji infrastruktury oraz konfiguracji komponentów typu open source,
• Mała biblioteka predefiniowanych zasad (około 70 szablonów) i brak standardowych zestawów polityk branżowych (np. CIS Benchmarks, HIPAA itp.),
• Brak trybu zapobiegawczego, tylko tryb reaktywny/detekcyjny.

Kompletny przewodnik dotyczący konfigurowania Forseti za pomocą Config Validator i Terraform Validator można znaleźć w artykule na blogu Ochrona infrastruktury GCP na dużą skalę za pomocą Forseti Config Validator (plus część 2, część 3 i część 4).