Blokowanie dostępu publicznego i zasady bucketów

Wyciek danych z nieprawidłowo skonfigurowanego wiadra S3 (Simple Storage Service) jest jednym z najczęstszych naruszeń bezpieczeństwa w chmurze. Jedno błędne ustawienie może ujawnić miliony obiektów całemu internetowi.

Usługa S3 jest domyślnie prywatna, ale warstwy uprawnień mogą przypadkowo ją otworzyć. Zrozumienie tych warstw jest niezbędną wiedzą z zakresu bezpieczeństwa.

Dostęp do obiektu S3 można przyznać za pomocą kilku mechanizmów:

• zasad IAM dotyczących użytkowników i ról.
• zasad wiadra przypisanych do wiadra.
• list ACL (list kontroli dostępu) dotyczących wiader i obiektów.
• ustawień Block Public Access, które mają pierwszeństwo przed pozostałymi mechanizmami.

Publiczne ujawnienie danych zwykle wynika z błędnej zasady wiadra lub listy ACL.

S3 Block Public Access (BPA) to główny przełącznik bezpieczeństwa. Po włączeniu zastępuje każdą zasadę wiadra lub listę ACL, która przyznawałaby dostęp publiczny, niezależnie od ich treści.

Firma AWS włącza obecnie BPA domyślnie dla nowych wiader. Należy pozostawić tę funkcję włączoną na poziomie konta, aby pojedyncza błędnie skonfigurowana zasada nigdy nie mogła publicznie ujawnić danych.

BPA ma cztery niezależne ustawienia, które blokują publiczne listy ACL, ignorują istniejące publiczne listy ACL, blokują publiczne zasady wiader oraz ograniczają publiczny dostęp za pośrednictwem dowolnego punktu dostępu.

Razem tworzą one twardą granicę: nawet jeśli ktoś napisze zasadę przyznającą publiczny odczyt, BPA go odrzuci. Jest to najsilniejsze zabezpieczenie przed przypadkowym ujawnieniem danych.

Zasada wiadra to zasada JSON oparta na zasobie, przypisana do wiadra. Określa, kto (podmiot) może wykonywać jakie działania na jakich obiektach i pod jakimi warunkami.

Zasady wiadra są przydatne przy dostępie między kontami i precyzyjnej kontroli, ale nieostrożne użycie Principal o wartości "*" przyznaje dostęp całemu światu. Należy dokładnie je przeglądać.

Przed chwilą pokazany fragment kodu dokładnie ilustruje, jak wygląda wyciek danych: Principal "*" wraz z s3:GetObject przyznaje każdemu anonimowemu użytkownikowi dostęp do odczytu wszystkich obiektów.

Jeśli nie hostują Państwo celowo publicznych treści, jest to błędna konfiguracja. Block Public Access zastąpiłby tę zasadę, dlatego BPA stanowi siatkę bezpieczeństwa.

Zasady wiadra nie tylko przyznają dostęp; mogą również wymagać spełnienia warunków bezpieczeństwa. Typowy schemat odrzuca każde przesłanie, które nie jest zaszyfrowane lub nie odbywa się przez TLS.

Użycie Deny wraz z warunkiem dotyczącym aws:SecureTransport lub s3:x-amz-server-side-encryption wymusza bezpieczne przetwarzanie danych przy każdym zapisie.

Warunki zaostrzają zasady, uzależniając je od kontekstu: można zezwolić na dostęp wyłącznie z określonego punktu końcowego VPC, znanego zakresu adresów IP lub organizacji z identyfikatorem aws:PrincipalOrgID.

Te klucze warunków pozwalają przyznać dokładnie taki dostęp, jakiego potrzebuje obciążenie, i nic ponadto, ograniczając zasięg szkód w przypadku niewłaściwego użycia danych uwierzytelniających.

Narzędzia pomagają znaleźć zagrożenia, zanim zrobią to atakujący. IAM Access Analyzer oznacza zasobniki udostępnione poza Państwa kontem, a konsola S3 pokazuje przy każdym zasobniku wskaźnik publicznego lub niepublicznego dostępu.

Reguły AWS Config i Security Hub mogą stale sprawdzać, czy funkcja Block Public Access pozostaje włączona dla wszystkich zasobników.

Należy zastosować Block Public Access na poziomie konta, a nie tylko dla poszczególnych zasobników, aby ustawienie automatycznie obejmowało wszystkie istniejące i przyszłe zasobniki.

Wymuszanie na poziomie całego konta eliminuje ryzyko, że nowo utworzony zasobnik pozostanie niechroniony. Należy użyć AWS Config i SCP, aby zagwarantować, że nikt nie wyłączy tego ustawienia, dzięki czemu publiczne ujawnienie danych stanie się niemożliwe z założenia.

Żaden pojedynczy mechanizm kontroli nie wystarczy. Należy połączyć Block Public Access na poziomie konta, zasady najmniejszych uprawnień dla zasobników, domyślne szyfrowanie i ciągły audyt.

Jeśli jedna warstwa zostanie skonfigurowana nieprawidłowo, pozostałe nadal będą chronić dane. Warstwowe zabezpieczenia sprawiają, że S3 przestaje być częstym źródłem wycieków i staje się niezawodnie prywatnym miejscem przechowywania danych.

Nieprawidłowa konfiguracja S3 jest jedną z głównych przyczyn wycieków. Dostęp jest kontrolowany warstwowo za pomocą IAM, zasad zasobnika, list ACL i głównego przełącznika Block Public Access — który nadpisuje każde publiczne uprawnienie i powinien pozostawać włączony na poziomie całego konta. Zasada z Principal "*" prowadzi do wycieku danych; zamiast tego należy używać warunków wymuszających TLS, szyfrowanie i ograniczony zakres dostępu. Należy stale przeprowadzać audyt za pomocą Access Analyzer, Config i Security Hub oraz stosować obronę warstwową, aby pojedynczy błąd nie ujawnił obiektów.