AWS Config, czyli jak się mają Twoje zasoby

Wygoda. Wiele firm decyduje się na przejście do chmury właśnie z tego powodu. Polegając na dostawcy, możesz zrezygnować z kosztownego prowadzenia i utrzymywania własnej infrastruktury. W końcu wszystko jest w jego rękach.

Czy na pewno? I jak do tego ma się usługa AWS Config?

Sprawdźmy.

Czy w chmurze jesteśmy sami?

Jak wiadomo, odpowiedzialność za to, co dzieje się w chmurze publicznej, jest podzielona pomiędzy dostawcę a użytkowników. Tak zwany Shared Responsibility Model obowiązuje praktycznie zawsze. Można go uprościć do stwierdzenia, że dostawca odpowiada za bezpieczeństwo i stabilność chmury, a Ty za to, co w danej chmurze trzymasz i robisz.

Przykładowy podział odpowiedzialności klienta i dostawcy chmurowego zaczerpnięty z dokumentacji Amazon Web Services (bo to nim się dzisiaj zajmiemy) wygląda następująco:

W zależności od tego, czy korzystamy z usługi w modelu IaaS, czy innym, odpowiedzialność dostawcy (pomarańczowe pola) będzie przesuwała się ku górze. Natomiast w każdym modelu część obowiązków pozostanie i tak na naszych barkach. Taki podział nie oznacza jednak, że musimy radzić sobie z tym, co dzieje się z naszymi zasobami w chmurze, bez żadnej pomocy.

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. Wiele z ponad stu dostępnych usług związanych jest właśnie z bezpieczeństwem naszych zasobów w chmurze i ich zarządzaniem. Wśród nich jest także AWS Config.

Czym jest usługa AWS Config?

Każdy użytkownik chmury AWS zna usługi takie jak Identity & Access Management czy CloudTrail. Wielu stosuje Service Control Policies. Natomiast jedną z usług, którą nie zawsze bierze się pod uwagę, jest 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 przerwy.

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 Group z otwartym portem 22, to możemy taki wymóg zdefiniować. Gdy taka Security Group się pojawi, zostaniemy o tym poinformowani. AWS Config pozwala na automatyczne reagowanie w takich sytuacjach i błyskawiczne zażegnanie niebezpieczeństwa zanim stanie się realne. Usługa ta umożliwia również śledzenie zależności pomiędzy zasobami.

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

AWS Config: jak to działa?

Domyślnie usługa AWS Config jest wyłączona. Ponadto musimy włączyć ją osobno dla każdego regionu.

Aby zacząć, otwieramy konsolę i wybieramy usługę AWS Config, a następnie klikamy przycisk [Get Started Now], który przeniesie nas do ustawień.

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

W sekcji Resource types to record proponuję zaznaczyć Record all resources supported in this region oraz  Include global resources (e.g., AWS IAM resources).

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

Możemy tu także przekazywać zdarzenia do tematu SNS. W tym celu w sekcji Amazon SNS topic zaznaczamy pole wyboru Stream configuration changes and notifications to Amazon SNS topic. Ta opcja może nam się przydać, jeżeli będziemy chcieli przekazać informacje o zmianach w zasobach do jakiegoś systemu zewnętrznego.

Przechodzimy dalej.

3. Pojawia się ekran Rules, na którym możemy wybrać zasady zarządzane przez AWS, pod kątem których AWS Config będzie walidować nasze środowisko. Dokładniejszy sposób korzystania z zasad przedstawiam poniżej.

Do wyboru mamy wiele gotowych propozycji. Ich wykaz dostępny jest tutaj. Możemy również korzystać z własnych zasad. Cały proces opisany jest w dokumentacji wraz z przykładową funkcją Lambda.

4. W ostatnim kroku potwierdzamy konfigurację usługi AWS Config, aby ją uruchomić. Sam proces może potrwać nawet kilka minut.

Zasady AWS Config (Rules)

Wszędzie powinny obowiązywać jakieś zasady. Zatem wróćmy do nich na chwilę.

Aby dodać zasady do swojego konta AWS, należy skierować się w menu konsoli do sekcji Rules, gdzie wybieramy zasadę i ją konfigurujemy.

Na początek proponuję skorzystać z zasad udostępnianych przed AWS, np. s3-bucket-public-read-prohibited.

Dla wielu zasad 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 że zasoby powinny być zgodne z naszymi wymaganiami. Oczywiście takie akcje możemy też napisać samodzielnie.

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 dla jakiegokolwiek z bucketów S3 możliwy jest publiczny odczyt danych. Do tej zasady 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 zaznaczyć, ż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 URL-ami o schemacie https://s3.amazonaws.com/aws-configservice-us-east-1/cloudformation-templates-for-managed-rules/the rule identifier.template.

Historia zasobów

Nawet jeżeli wszystkie nasze zasoby spełniają obecnie niezbędne warunki zgodności, 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 (Compliant).

Gdy kliknę na jeden z nich, możliwe będzie przejrzenie historii:

Jeżeli nacisnę przycisk Compliance timeline, zobaczę, że wybrany zasób nie zawsze był dostępny publicznie:

Przechodząc na zakładkę Configuration timeline, ujrzę zdarzenia z CloudTrail, które spowodowały, że konkretny bucket stał się publiczny. Widać nawet winnego 🙂

Ważna jest także możliwość przeglądania zależności pomiędzy zasobami. Na przykład w przypadku jednej z moich maszyn wirtualnych wyglądają one następująco:

Taki przegląd często pozwoli nam na szybkie rozeznanie się, co wpłynęło na obecny stan zasobu i sytuację, w której się znaleźliśmy.

Podsumowanie

AWS Config być może nie jest usługą dla każdego. Nie jest darmowa, a jej stosowanie na koncie, na którym dopiero uczymy się AWS i nie przechowujemy wrażliwych danych, nie jest konieczne. Ale na pewno przyda się w miejscach, w których działają produkcyjne aplikacje bądź rozwiązania wymagające szczególnej ochrony. Dlatego zachęcam, aby się z nią zapoznać.