Artykuł ukazał się pierwotnie na blogu Chmurowiska.

Jak wiadomo, odpowiedzialność za to, co dzieje się w chmurze publicznej podzielona jest zarówno na vendora jak i na nas. Tak zwany Shared Responsibility Model obowiązuje praktycznie zawsze. Można go uprościć do stwierdzenia, że dostawca odpowiada za chmurę, a my za to co w danej chmurze mamy i robimy. Przykładowy podział obowiązków i odpowiedzialności zaczerpnięty z dokumentacji Amazon Web Services wygląda następująco.

W zależności od tego czy korzystamy z usługi w modelu IaaS czy innym, część pomarańczowa, czyli odpowiedzialność AWS będzie przesuwała się ku górze, jednak zawsze część obowiązków governance pozostanie na naszych barkach.

Czy jesteśmy sami

Taki podział nie oznacza jednak, że jesteśmy pozostawieni sami sobie i bez żadnej pomocy ze strony dostawcy musimy radzić sobie z tym, co dzieje się z naszymi zasobami w chmurze. Czynności, które wykonujemy zarządzając usługami możemy podzielić na trzy rodzaje:

• przydzielanie uprawnień,
• śledzenie wydarzeń i zmian,
• reagowanie na zdarzenia.

W każdym z powyższych obszarów otrzymujemy wsparcie od AWS. Pośród ponad 100 dostępnych dla nas usług, wiele związanych jest właśnie z bezpieczeństwem naszych zasobów w chmurze i ich zarządzaniem.

Każdy zna usługi takie jak Identity & Access Management czy CloudTrail. Wielu stosuje Service Control Policies. Jedną z usług, która nie zawsze jest brana pod uwagę jest AWS Config

AWS Config

 

AWS Config to usługa, która monitoruje stan naszych zasobów i wszelkiego rodzaju zmiany, które w nich zachodzą. I robi to bez przerw. Co więcej, potrafi automatycznie ocenić, czy bieżąca konfiguracja jest zgodna z tym, czego oczekujemy. Jeżeli nie chcielibyśmy np. mieć na naszym koncie żadnej security grupy z otwartym portem 22, to możemy taki wymóg zdefiniować i w momencie gdy w jakiś sposób taka security grupa się pojawi, zostaniemy o tym poinformowani. Co więcej, AWS Config pozwala na automatyczne reagowanie w takich sytuacjach i zażegnanie niebezpieczeństwa w zarodku.

Usługa ta pozwala także na śledzenie zależności pomiędzy zasobami.

Wszystkie te możliwości powodują, że wszelkie audyty, analizy czy też zarządzanie zmianami stają wie o wiele łatwiejsze.

Jak?

Domyślnie AWS Config nie jest włączony. Ponad to musimy włączyć go dla każdego regionu osobno.

Na początek określamy zasoby, których chcemy rejestrować zdarzenia.

Proponuję zaznaczyć Record all resources supported in this region oraz Include global resources (e.g., AWS IAM resources).

W kolejnym kroku wybieramy bucket S3, w którym rejestrowane będą zmiany.

Możemy także stremować zdarzenia do topimsa SNS. Może być to przydatne, jeżeli chcemy przekazać te informacje do jakiegoś systemu zewnętrznego.

W kolejnym kroku możemy wybrać zasady zarządzane przez AWS, pod kątem których AWS Config będzie walidować nasze środowisko. Mamy wiele gotowych propozycji. Ich wykaz dostępny jest tutaj. Możemy później korzystać oczywiście także z własnych zasad. Cały proces jest opisany w dokumentacji wraz z przykładową funkcją Lambda.

Po potwierdzeniu konfiguracji uruchamiany jest AWS Config. Sam proces może potrwać nawet kilka minut.

Zasady

Wszędzie powinny obowiązywać jakieś zasady. Aby dodać jakieś do swojego konta należy skierować się w menu do Rules.

Na początek proponuje skorzystać z zasad udostępnianych przed AWS, np. s3-bucket-public-read-prohibited. Wybieramy zasadę i konfigurujemy ją. Dla wielu z nich dostępne są te tak zwane Remediation actions, czyli działania, które automatycznie sprawią, że nasze konto powinno by w razie potrzeby „naprawione”, czyli zasoby powinny być zgodne z naszymi wymaganiami. Oczywiście także takie akcje możemy napisać samemu.

Ja na swoim koncie testowym zastosowałem dwie zasady:

• ec2-instance-no-public-ip
• s3-bucket-public-read-prohibited.

Pierwsza z nich sprawdza, czy żadna z moich instancji EC2 nie posiada publicznego adresu IP, a druga informuje mnie gdy z któregoś z bucketów S3 jest możliwy publiczny odczyt danych.

Dla drugiej z nich dodana jest nawet akcja, która ma być wykonana w momencie, gdy któryś z bucketów nie spełnia warunków zgodności.

Warto dodać, że wszystkie zasady zarządzane przez AWS dostępne są także w formie szablonów CloudFormation. Umożliwia to ich prosty deployment za pomocą StackSetów. Szczególnie po ostatniej zmianie jest to bardzo proste nawet gdy tworzymy nowe konta AWS w ramach organizacji. Szablony dostępne są pod urlami o schemacie: https://s3.amazonaws.com/aws-configservice-us-east-1/cloudformation-templates-for-managed-rules/the rule identifier.template”

Historia

Nawet jeżeli wszystkie nasze zasoby spełniają wszystkie niezbędne warunki, to nie zawsze tak musiało być. AWS Config umożliwia przejrzenie historii zarówno konfiguracji poszczególnych zasobów, jak i ich zgodności z narzuconymi przez nas regułami.

W moim przypadku, oba buckety S3 są w porządku.

Jeżeli jednak kliknę w jeden z nich to możliwe będzie przejrzenie historii

Jeżeli wybiorę Compliance timeline to zobaczymy, że nie zawsze jeden z nich nie był dostępny publicznie

Jeżeli teraz przejdę do Configuration timeline to na dole pokazane będę zdarzenia z CloudTrail, które spowodowały, że konkretny bucket stał się publiczny. Widać nawet winnego 🙂

Ważna jest także możliwość przejrzenia zależy ości pomiędzy zasobami. Na przykład w przypadku jednej z moich maszyn wirtualnych wygląda to następująco

Często pozwoli to na szybkie rozeznanie się w sytuacji, na co ma wpływ sytuacja w której się znaleźliśmy.

Podsumowanie

AWS Config to być może nie jest usługa dla każdego. Nie jest darmowa. Być może stosowanie jej na koncie, na którym dopiero uczymy się AWS i nie przechowujemy wrażliwych danych nie jest konieczne. Ale na pewno warto używać w miejscach, w których działają produkcyjne aplikacje, bądź rozwiązania, które powinny być szczególnie chronione.

Jednak na pewno warto ją poznać. Do czego zachęcam.

Chmurowisko