Audyt bezpieczeństwa AWS: checklista konfiguracji IAM, S3 i Security Groups dla admina

Na konsoli AWS wszystko może wyglądać poprawnie: aplikacja odpowiada, pipeline wdraża kod, a użytkownicy logują się bez błędów. Problem pojawia się dopiero wtedy, gdy ktoś próbuje odpowiedzieć na proste pytanie: kto dokładnie może odczytać dane, zmienić konfigurację albo otworzyć dostęp do usługi? W większym koncie odpowiedź rzadko znajduje się w jednym miejscu. Uprawnienia wynikają jednocześnie z polityk IAM, ról, grup, polityk zasobów, ustawień S3, reguł Security Groups, relacji zaufania, SCP oraz konfiguracji sieci.

Audyt bezpieczeństwa AWS powinien więc przypominać kontrolowany proces dochodzenia, a nie szybkie przeklikiwanie kilku zakładek. Najpierw trzeba ustalić zakres i zebrać dowody, następnie określić rzeczywisty poziom ekspozycji, a dopiero później zmieniać konfigurację. Szczególnej ostrożności wymagają trzy obszary: IAM, czyli dostęp do operacji i zasobów, S3, gdzie łatwo o niezamierzoną ekspozycję danych, oraz Security Groups, które decydują o dostępności instancji i usług na poziomie sieciowym. ^[3]

Gdy konfiguracja działa, ale nie wiadomo, kto naprawdę ma dostęp

Problem administracyjny: widoczność zamiast samego „działania”

Najczęstszy scenariusz wygląda niewinnie. Aplikacja działa od miesięcy, zespół ma przygotowane role, a dostęp do bucketów i baz danych skonfigurowano przy okazji wdrożenia. Z czasem dochodzą kolejne wyjątki: tymczasowa polityka dla dostawcy, dodatkowa reguła dla pipeline’u, stary użytkownik IAM, klucz utworzony na potrzeby migracji oraz rola, której nikt nie chce usunąć, bo „może jeszcze będzie potrzebna”. Każdy element osobno wydaje się uzasadniony. Razem tworzą trudną do prześledzenia ścieżkę dostępu.

Niebezpieczna jest także sytuacja odwrotna: administrator widzi, że użytkownik nie ma bezpośrednio przypisanej polityki AdministratorAccess, więc uznaje jego konto za bezpieczne. Tymczasem uprawnienia mogą pochodzić z grupy, roli przyjmowanej przez federację, polityki zasobu, szerokiej relacji zaufania albo połączenia kilku mniej uprzywilejowanych polityk. Audyt nie powinien kończyć się na pytaniu „jaką politykę ma użytkownik?”. Prawidłowe pytanie brzmi: jakie operacje może wykonać ta tożsamość, na jakich zasobach i w jakich warunkach?

Pojedynczy zrzut ekranu z konsoli nie jest pełnym dowodem. Nie pokaże całej historii zmian, faktycznego użycia uprawnień ani tego, czy ta sama rola jest dostępna z innego konta AWS. Nie wyjaśni również, czy bucket S3 ma politykę zasobu zezwalającą na dostęp, którego nie widać w polityce tożsamości. Do rzetelnej oceny potrzebne są co najmniej konfiguracja, relacje między zasobami oraz logi aktywności.

Trzy pytania porządkują praktycznie każdy audyt:

• Kto? Użytkownik IAM, rola, konto AWS, dostawca federacji, usługa albo zewnętrzny podmiot.
• Co i gdzie? Konkretna akcja, usługa, zasób, obiekt, ścieżka w bucketcie lub port sieciowy.
• Z jakiego miejsca i pod jakimi warunkami? Konto źródłowe, VPC, adres IP, VPC endpoint, MFA, tag, organizacja AWS albo inny warunek polityki.

Zakres i zasady bezpiecznej kontroli

Przed rozpoczęciem przeglądu trzeba ustalić zakres. Obejmuje on nie tylko konto produkcyjne, lecz także konta deweloperskie, testowe, bezpieczeństwa, logowania i narzędzia CI/CD, jeżeli znajdują się w tej samej organizacji lub mają relacje zaufania. Sprawdzenie wyłącznie regionu używanego na co dzień przez administratora może pominąć bucket, klucz KMS, rolę albo Security Group utworzoną w innym regionie.

Minimalny zakres roboczy powinien obejmować:

• wszystkie konta AWS objęte audytem oraz ich role międzykontowe,
• regiony aktywne według inwentaryzacji zasobów i logów,
• środowiska produkcyjne, testowe i deweloperskie,
• użytkowników IAM, grupy, role, dostawców tożsamości i konto root,
• buckety S3, ich polityki, ustawienia publicznego dostępu i logowanie,
• Security Groups używane przez instancje, load balancery, bazy danych, klastry i endpointy,
• CloudTrail, AWS Config oraz inne źródła dowodów dostępne w danej architekturze.

Rozpoznanie najlepiej rozpocząć z dostępem tylko do odczytu. Nie należy równocześnie usuwać użytkowników, odcinać portów i zmieniać polityk, bo utrudnia to ustalenie przyczyny ewentualnej awarii. Najpierw powstaje lista ustaleń: zasób, problem, dowód, właściciel, ryzyko i proponowana korekta. Dopiero potem zespół aplikacyjny potwierdza, czy dana reguła jest faktycznie potrzebna.

Przydatny jest prosty podział priorytetów. Publiczny dostęp do wrażliwego bucketu oraz możliwość przyjęcia roli administracyjnej przez niekontrolowany podmiot wymagają reakcji pilnej. Klucz należący do starej integracji, którego użycie nie jest znane, może wymagać najpierw obserwacji i kontrolowanej rotacji. Nie każda anomalia powinna prowadzić do natychmiastowego usunięcia konfiguracji, ale każda powinna mieć właściciela i termin decyzji.

Mit o „bezpiecznym AWS, bo zasoby nie są publiczne”

Brak publicznego adresu IP nie oznacza automatycznie, że zasób jest bezpieczny. Rola uruchomiona w prywatnej podsieci może mieć uprawnienia do usuwania danych w S3, odczytu sekretów albo modyfikowania sieci. Jeżeli poświadczenia tej roli zostaną wykorzystane przez podatną aplikację, atakujący nie potrzebuje bezpośredniego dostępu do instancji z Internetu.

Inny popularny mit mówi, że prywatny bucket S3 rozwiązuje problem ochrony danych. Prywatność bucketu jest ważnym zabezpieczeniem, lecz nie zastępuje kontroli tożsamości, szyfrowania, wersjonowania, logowania i ograniczenia dostępu do konkretnych prefiksów. Tak samo zamknięty port w Security Group nie naprawi roli IAM, która pozwala zmienić tę grupę.

Bezpieczeństwo AWS jest wynikiem kilku warstw: tożsamości, polityk zasobów, ścieżki sieciowej, szyfrowania, monitoringu i zdolności do wykrycia zmiany. Każda decyzja audytowa powinna mieć trzy elementy: właściciela, dowód w konfiguracji lub logach oraz plan korekty z możliwością wycofania. Taki sposób pracy ogranicza ryzyko, że poprawka bezpieczeństwa stanie się przyczyną niedostępności usługi.

IAM: skąd biorą się nadmiarowe uprawnienia i jak je odnaleźć

Inwentaryzacja tożsamości, ról i metod logowania

Checklista IAM AWS powinna zaczynać się od pełnej listy podmiotów, a nie od przeglądania przypadkowych polityk. Zbierz użytkowników IAM, grupy, role, dostawców tożsamości, konta członkowskie AWS Organizations oraz informacje o koncie root. Ustal, które osoby korzystają z federacji lub AWS IAM Identity Center, a które nadal logują się lokalnymi użytkownikami IAM.

Warto przeczytać również powiązany artykuł: Nowoczesne technologie w motoryzacji: jak elektronika zmienia bezpieczeństwo i komfort ….

Każdy lokalny użytkownik IAM powinien mieć uzasadnienie biznesowe i techniczne. Konto utworzone dla człowieka, który może używać SSO, często jest pozostałością po dawnym modelu administracji. Z kolei użytkownik techniczny może być niezbędny dla zewnętrznego narzędzia, ale wtedy trzeba sprawdzić jego zakres uprawnień, sposób przechowywania kluczy oraz właściciela integracji.

Osobno zinwentaryzuj role wykorzystywane przez:

• EC2 i profile instancji,
• Lambda, ECS i EKS,
• pipeline’y CI/CD oraz systemy budowania,
• automatyzację Infrastructure as Code,
• zewnętrzne systemy monitoringu, backupu i skanowania,
• relacje między kontami AWS i dostawcami SaaS.

Przy każdej roli zapisz, kto może ją przyjąć. Sama nazwa roli, na przykład DeployRole albo ReadOnlyRole, nie mówi nic o faktycznym poziomie ryzyka. Szczególnie ważna jest polityka zaufania, ponieważ definiuje źródło żądania. Rola z szerokim Principal może być bardziej niebezpieczna niż rola z dużą liczbą uprawnień, ale ograniczona do konkretnego konta i konkretnego procesu.

Przegląd polityk i efektywnych uprawnień

Podczas analizy szukaj przede wszystkim konstrukcji Action: "*" oraz Resource: "*". Nie każda z nich jest automatycznie błędem, ponieważ niektóre akcje AWS nie pozwalają na wskazanie zasobu albo wymagają szerokiego zakresu do działania. Połączenie obu wartości z uprawnieniami administracyjnymi, takimi jak modyfikacja IAM, KMS, S3, sieci lub CloudTrail, powinno jednak otrzymać wysoki priorytet.

Rozdziel polityki zarządzane przez AWS, customer-managed oraz inline. Polityka zarządzana przez AWS może zmienić zakres wraz z aktualizacją usługi, dlatego trzeba wiedzieć, które role z niej korzystają. Polityka własna daje większą kontrolę, ale przenosi na organizację odpowiedzialność za wersjonowanie, przeglądy i usuwanie nieużywanych uprawnień. Polityki inline są związane bezpośrednio z jednym użytkownikiem lub rolą; bywają trudniejsze do wykrycia, gdy audyt opiera się wyłącznie na centralnej liście polityk.

Efektywne uprawnienie może wynikać z wielu warstw. Sprawdź jednocześnie:

• polityki tożsamości przypisane bezpośrednio i przez grupy,
• polityki zasobów, na przykład bucket policy S3,
• permission boundaries, które ograniczają maksymalny zakres roli lub użytkownika,
• session policies dodawane do sesji tymczasowej,
• SCP w AWS Organizations,
• warunki Condition, takie jak MFA, VPC endpoint, tagi lub źródłowy adres IP,
• relację zaufania, czyli politykę AssumeRole.

Odmowa wynikająca z jednej warstwy nie powinna być mylona z bezpiecznym modelem uprawnień. SCP może zablokować operację dzisiaj, ale po przeniesieniu konta lub zmianie struktury organizacji ograniczenie może przestać działać. Permission boundary nie nadaje uprawnień samodzielnie; ogranicza ich maksymalny zakres. Z kolei polityka zasobu może otworzyć dostęp podmiotowi, który nie ma oczywistego uprawnienia w swojej polityce tożsamości. ^[1]

Przy analizie roli nie zatrzymuj się na nazwie „read-only”. Odczyt konfiguracji może ujawniać nazwy baz, topologię sieci, identyfikatory zasobów, polityki, dane z logów lub informacje przydatne do dalszego ataku. Uprawnienie do odczytu obiektów S3 może oznaczać dostęp do danych klientów. „Tylko odczyt” opisuje rodzaj operacji, a nie jej wrażliwość.

Relacje zaufania są równie ważne jak lista akcji

Audyt roli powinien odpowiedzieć na pytanie, czy każdy podmiot mogący wykonać sts:AssumeRole jest rzeczywiście kontrolowany. Dla roli używanej przez dostawcę zewnętrznego sprawdź ograniczenie do konkretnego konta AWS oraz obecność ExternalId, gdy scenariusz tego wymaga. Dla federacji zweryfikuj warunki odnoszące się do dostawcy tożsamości, a dla roli międzykontowej ustal, czy konto docelowe nadal należy do organizacji.

Niebezpieczne są relacje oparte na szerokim podmiocie, jeżeli nie towarzyszy im dodatkowe ograniczenie. Dotyczy to także ról przeznaczonych pierwotnie do testów, których polityka zaufania pozostała otwarta po zakończeniu projektu. Każdy wyjątek powinien mieć dokumentację: kto go zatwierdził, do czego służy i kiedy zostanie ponownie sprawdzony.

S3: publiczny dostęp to nie jedyny problem do sprawdzenia

Po przeglądzie IAM warto przejść do S3 w kolejności odpowiadającej rzeczywistemu ryzyku: najpierw ustalić, kto może dostać się do danych, następnie sprawdzić, czy bucket lub obiekty nie są dostępne zbyt szeroko, a na końcu ocenić ochronę przed utratą i nieautoryzowaną zmianą. Sam status „Bucket and objects not public” nie odpowiada na wszystkie te pytania.

Ustal, kto może czytać i zmieniać obiekty

Dla każdego bucketa przypisz właściciela danych oraz określ ich klasę: publiczne, wewnętrzne, poufne albo regulowane. Następnie sprawdź, czy dostęp wynika z polityk przypisanych użytkownikom i rolom, polityki bucketa, punktu dostępowego S3, ACL lub mechanizmu używanego przez usługę AWS. Szczególną uwagę zwróć na dostęp między kontami, ponieważ odbiorca może znajdować się poza bezpośrednią kontrolą zespołu utrzymującego bucket.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Planowanie posiłków na tydzień: prosty przewodnik po zdrowym meal prepie dla zabieganych.

W praktyce przydatne jest rozdzielenie operacji:

• odczyt metadanych i listowanie prefiksów,
• odczyt obiektów,
• dodawanie nowych obiektów,
• nadpisywanie i usuwanie obiektów,
• zmiana polityki bucketa, konfiguracji szyfrowania lub ustawień dostępu.

Rola, która może tylko wysyłać pliki do określonego prefiksu, ma inny profil ryzyka niż rola mogąca odczytać cały bucket i usuwać jego zawartość. W politykach ograniczaj zasoby do konkretnego bucketa oraz ścieżek obiektów, jeżeli aplikacja nie wymaga szerszego zakresu. Pamiętaj, że listowanie bucketa i dostęp do konkretnego obiektu są odrębnymi potrzebami i często można je rozdzielić.

Sprawdź blokady dostępu publicznego, ACL i politykę bucketa

W audycie potwierdź, że ustawienia Block Public Access są zgodne z przeznaczeniem danych na poziomie konta i bucketa. Nie traktuj jednak tej funkcji jako substytutu przeglądu polityki. Trzeba sprawdzić także warunki w Bucket policy, zezwolenia dla kont zewnętrznych, dostęp przez S3 Access Point oraz stare ACL obiektów. ^[2]

Jeżeli architektura na to pozwala, użyj Object Ownership z ustawieniem Bucket owner enforced, aby wyłączyć ACL i przenieść kontrolę dostępu do polityk. Ogranicza to liczbę miejsc, w których może powstać wyjątek. Przed zmianą sprawdź jednak integracje, które nadal wysyłają obiekty z nagłówkami ACL, ponieważ bez testu można przerwać działanie dostawcy lub pipeline’u.

W politykach S3 szukaj między innymi:

• zezwoleń dla anonimowego Principal lub szerokiej grupy kont,
• braku warunku wymuszającego szyfrowanie po stronie serwera przy zapisie,
• dostępu niezależnego od wymaganego VPC endpointu lub konta organizacji,
• możliwości usuwania albo nadpisywania obiektów przez role aplikacyjne,
• uprawnień do zmiany samej polityki bucketa, ustawień publicznego dostępu i konfiguracji wersjonowania.

Warunek aws:SecureTransport może wymusić korzystanie z połączeń TLS, ale nie rozwiązuje problemu nadmiarowych uprawnień. Podobnie ograniczenie dostępu do konkretnego VPC endpointu nie zastępuje kontroli tożsamości. Każde ograniczenie należy sprawdzić w logach i w scenariuszu używanym przez aplikację, a nie tylko odczytać z dokumentacji konfiguracji.

Szyfrowanie, wersjonowanie i odzyskanie danych

Audyt S3 powinien objąć szyfrowanie obiektów, sposób zarządzania kluczami KMS oraz możliwość ich użycia przez właściwe role. Gdy stosowany jest klucz zarządzany przez klienta, zweryfikuj zarówno politykę klucza, jak i uprawnienia IAM do szyfrowania oraz odszyfrowywania. Sama informacja „SSE-KMS jest włączone” nie potwierdza, że dostęp do klucza jest ograniczony.

Dla danych, których nie można łatwo odtworzyć, sprawdź wersjonowanie, reguły retencji i ochronę przed przypadkowym usunięciem. Wersjonowanie nie zastępuje backupu, ale pozwala ograniczyć skutki nadpisania lub usunięcia obiektu. Należy również ustalić, czy role aplikacyjne mogą usuwać wersje oraz czy mechanizm backupu znajduje się w odrębnym koncie lub pod odrębną kontrolą.

Wynik kontroli powinien wskazać nie tylko „wersjonowanie włączone” albo „szyfrowanie aktywne”, lecz także właściciela ustawienia, datę ostatniego testu odzyskania i scenariusz, w którym zabezpieczenie ma zadziałać. Bez próby odtworzenia danych trudno ocenić, czy konfiguracja spełnia wymagania biznesowe.

Security Groups: reguła otwartego portu często ukrywa większy problem

W przypadku Security Groups najczęstszy błąd polega na analizowaniu pojedynczej reguły bez sprawdzenia, jaki zasób z niej korzysta i dokąd prowadzi ruch. Otwarcie portu 443 do Internetu może być zamierzone dla load balancera, ale nie dla bazy danych. Ta sama reguła przypisana do kilku różnych typów zasobów może mieć zupełnie różne konsekwencje. ^[4]

Powiąż każdą regułę z zasobem i przepływem

Dla każdej Security Group ustal, do jakich instancji, interfejsów sieciowych, load balancerów, baz, klastrów lub endpointów jest przypisana. Nazwa default, web-sg albo temp-access nie jest wystarczającym opisem. Właściciel powinien potwierdzić, jaki ruch ma być dozwolony, z jakiego źródła, na jaki port i przez jaki okres.

Najpierw przeanalizuj reguły przychodzące:

• czy źródłem jest 0.0.0.0/0 lub ::/0,
• czy publicznie dostępne są porty administracyjne, takie jak SSH lub RDP,
• czy źródłem jest właściwa Security Group zamiast szerokiego zakresu adresów,
• czy port bazy danych jest dostępny tylko z warstwy aplikacyjnej,
• czy reguła ma opis, właściciela i uzasadnienie.

Następnie sprawdź ruch wychodzący. Pełny egress może być potrzebny w niektórych scenariuszach, ale utrudnia ograniczenie komunikacji aplikacji z Internetem i usługami zewnętrznymi. Przed jego zawężeniem zinwentaryzuj zależności: repozytoria, systemy aktualizacji, usługi AWS, DNS, monitoring, dostawców płatności i endpointy prywatne.

Dobrym uzupełnieniem tego tematu jest także poradnik: Dieta ketogeniczna a insulinooporność: jak keto może wspierać organizm w walce z zaburz….

Usuń wyjątki, nie odcinając aplikacji

Najbezpieczniejsza korekta nie polega na masowym usunięciu wszystkich reguł otwartych do Internetu. Najpierw ustal, czy adres publiczny należy do load balancera, bastiona, VPN, urządzenia administracyjnego czy bezpośrednio do serwera. Jeżeli aplikacja wymaga publicznego wejścia, ruch powinien trafiać do przeznaczonej do tego warstwy, a nie do bazy danych lub hosta zarządzającego.

W przypadku dostępu administracyjnego preferuj kontrolowany kanał, na przykład VPN, bastion, AWS Systems Manager Session Manager albo ograniczenie do aktualnych adresów firmowych. Stałe wyjątki dla pojedynczych adresów domowych szybko tracą aktualność. Jeśli dostęp awaryjny musi pozostać, oznacz go jako czasowy, z terminem wygaśnięcia i osobą odpowiedzialną za usunięcie.

Przy porządkowaniu reguł pamiętaj, że Security Groups są stanowe: odpowiedź na dozwolone połączenie jest obsługiwana jako część tego przepływu. Nie należy więc kopiować reguł w obie strony bez zrozumienia wymaganego ruchu. Jednocześnie Security Group nie zastępuje kontroli routingu, Network ACL, zapory aplikacyjnej ani autoryzacji w samej usłudze.

Wykrywaj grupy osierocone i reguły tymczasowe

Grupa nieprzypisana do żadnego zasobu nie musi być pilnym zagrożeniem, ale jest sygnałem słabej kontroli zmian. Może zawierać stare wyjątki, które zostaną przypadkowo wykorzystane przy kolejnym wdrożeniu. Zidentyfikuj takie grupy, sprawdź historię zmian i usuń je dopiero po potwierdzeniu, że nie są referencjonowane przez automatyzację lub proces odtworzenia środowiska.

Reguły dodane na czas migracji, testu lub diagnozy powinny mieć metadane w postaci opisu, zgłoszenia i daty przeglądu. Jeśli narzędzie infrastrukturalne odtwarza ręcznie usuniętą regułę, korektę trzeba wprowadzić w kodzie IaC, a nie tylko w konsoli AWS. W przeciwnym razie problem powróci przy następnym apply lub wdrożeniu.

Od ustalenia do korekty: jak nie zepsuć działającego środowiska

Weryfikuj zmianę na podstawie dowodu

Każda rekomendacja powinna mieć test przed i po zmianie. Dla IAM może to być próba wykonania konkretnej akcji przez rolę testową, dla S3 — odczyt i zapis do dozwolonego prefiksu, a dla Security Groups — kontrolowane połączenie z wymaganej i niewymaganej sieci. Wynik zapisz razem z identyfikatorem zasobu oraz czasem wykonania.

Nie polegaj wyłącznie na skanerze konfiguracji. Narzędzia wykrywają wzorce, ale nie znają wszystkich zależności biznesowych. Z drugiej strony ręczna wiedza zespołu nie powinna być jedynym dowodem, bo zmiana personelu usuwa ją z procesu. Najlepszy wynik daje połączenie konfiguracji, logów, właściciela zasobu i powtarzalnego testu.

Wprowadź kolejność napraw

Najpierw ogranicz dostęp, który może prowadzić do szybkiego wycieku danych lub przejęcia kontroli: publiczny odczyt wrażliwych obiektów, możliwość przyjęcia uprzywilejowanej roli przez niekontrolowany podmiot, otwarte porty administracyjne oraz klucze dostępowe bez znanego właściciela. Następnie zajmij się uprawnieniami szerokimi, lecz wykorzystywanymi przez krytyczne procesy, stosując etap obserwacji i testów.

Dla każdej korekty określ:

• zasób i aktualną konfigurację,
• ryzyko pozostawienia ustawienia bez zmian,
• oczekiwany model po zmianie,
• test funkcjonalny i właściciela akceptacji,
• plan wycofania, jeżeli aplikacja przestanie działać.

Warto także ustawić termin ponownego przeglądu. Uprawnienie zaakceptowane jako wyjątek nie powinno stać się stałym elementem architektury tylko dlatego, że nikt nie wrócił do zgłoszenia. Dla ról, polityk S3 i reguł Security Groups przydatny jest cykl kwartalny, a dla zmian krytycznych — przegląd po każdym wdrożeniu lub incydencie.

Praktyczna checklista administratora przed zamknięciem audytu

• Każda uprzywilejowana rola ma znanego właściciela i uzasadnioną relację zaufania.
• Nieaktywne użytkownicy, klucze i role są usunięte, zablokowane albo objęte udokumentowanym planem wycofania.
• Uprawnienia do IAM, KMS, S3, sieci i CloudTrail są ograniczone do konkretnych procesów.
• Buckety S3 mają potwierdzony model dostępu, włączone odpowiednie blokady publiczne i sprawdzone polityki zasobów.
• Odczyt, zapis, usuwanie obiektów i zmiana konfiguracji S3 są rozdzielone tam, gdzie wymaga tego ryzyko.
• Szyfrowanie, wersjonowanie oraz odzyskiwanie danych zostały zweryfikowane testem, a nie tylko odczytem ustawień.
• Każda Security Group ma przypisane zasoby, opisane przepływy i właściciela reguł.
• Porty administracyjne i bazy danych nie są dostępne z szerszego zakresu niż wymagany.

Najważniejsze punkty

• Audyt AWS powinien obejmować konfigurację, relacje między zasobami i logi, a nie tylko widok z konsoli.
• Rzeczywiste uprawnienia IAM wynikają z wielu warstw, w tym polityk tożsamości, polityk zasobów, SCP i relacji zaufania.
• Prywatny bucket S3 oraz brak publicznego adresu IP nie gwarantują pełnego bezpieczeństwa.
• IAM, S3 i Security Groups należy analizować razem, ponieważ poprawa jednej warstwy nie naprawia błędów w pozostałych.
• Zmiany warto wprowadzać dopiero po zebraniu dowodów, określeniu właściciela problemu i przygotowaniu planu wycofania.

Źródła

• [1] AWS Documentation – Security best practices in IAM ↑
• [2] AWS Documentation – Security best practices for Amazon S3 ↑
• [3] AWS Documentation – Control traffic to your AWS resources using security groups ↑
• [4] AWS Documentation – Security group rules ↑