Publiczne S3, Azure Blob i GCS: jak je znaleźć w jedno popołudnie

Każdy z trzech dużych dostawców ma przełącznik nad pojedynczym bucketem, który nadpisuje wszystko, co ktoś skonfigurował niżej. Twoje popołudnie ma dwa zadania: znaleźć to, co już jest otwarte, a potem włączyć te przełączniki, żeby kolejna nieostrożna polityka nic nie zmieniła. Zrób to w tej kolejności, bo przełączniki zepsują wszystko, co polega na publicznym dostępie.

Co oznacza "publiczny" na poszczególnych platformach

Definicje są różne, a audyt musi uwzględnić każdą z nich.

S3 traktuje politykę bucketu jako publiczną, dopóki nie zostanie udowodnione, że jest inaczej. Za niepubliczną uznaje ją tylko wtedy, gdy przyznaje dostęp do stałych wartości, bez symboli wieloznacznych i zmiennych polityki, na przykład konkretnemu principalowi lub zestawowi bloków CIDR przez aws:SourceIp. Principal z symbolem wieloznacznym nie przejdzie więc tego testu.

W Azure muszą być spełnione oba warunki. Jeśli konto nie dopuszcza dostępu anonimowego, ustawienie kontenera nie ma znaczenia. Jeśli konto go dopuszcza, kontener nadal pozostaje prywatny, dopóki ktoś nie ustawi jego poziomu na Container lub Blob.

Krok 1: znajdź to, co jest otwarte

S3. Przewodnik AWS wskazuje IAM Access Analyzer for S3 jako narzędzie do przeglądu publicznych bucketów, więc zacznij od niego. Następnie sprawdź na każdym koncie cztery ustawienia Block Public Access: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy i RestrictPublicBuckets. Pamiętaj, że GetBucketAcl zwraca uprawnienia efektywne. Bucket z publicznym ACL i włączonym IgnorePublicAcls pokaże ACL, który ukrywa prawdziwy.

Azure. Portal pokazuje najpierw liczbę anonimowych żądań. W koncie magazynu otwórz Monitoring, a potem Metrics. Użyj przestrzeni nazw Blob, metryki Transactions, agregacji Sum i dodaj filtr, w którym Authentication jest równe Anonymous.

Aby sprawdzić, których kontenerów to dotyczy, utwórz ustawienie diagnostyczne wysyłające logi do przestrzeni roboczej Log Analytics. Następnie uruchom to zapytanie, które obejmuje ostatnie siedem dni:

StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri

Kolumna Uri wskazuje kontenery i bloby, które są odczytywane. Metryki i logi pokazują tylko, kto czyta anonimowo, a nie co jest wystawione, więc otwarty kontener, o który nikt nie pytał, pozostaje niewidoczny. Sprawdź także poziomy dostępu kontenerów.

Google Cloud. Przejrzyj polityki IAM bucketów pod kątem ról nadanych allUsers lub allAuthenticatedUsers. Cloud Asset Inventory pokazuje polityki wszystkich bucketów w projekcie, folderze lub organizacji, więc nie musisz przechodzić po kolei przez każdy bucket. ACL obiektów trzeba sprawdzić osobno, a managed folders mają własne polityki IAM. Włącz usage logs, aby zobaczyć, które workloady korzystają z publicznych danych. Cloud Audit Logs nie śledzi dostępu do publicznych obiektów, więc tutaj nie pomoże.

Krok 2: włącz zabezpieczenia

S3. AWS zaleca włączenie wszystkich czterech ustawień na poziomie konta. Zaleca też włączenie wszystkich czterech na każdym buckecie, aby spełnić kontrolę Security Hub S3.8. Dla wielu kont użyj polityki na poziomie organizacji. Taka polityka działa na zasadzie "wszystko albo nic", bez wyboru pojedynczych ustawień, i nadpisuje ustawienia na poziomie konta w wybranych kontach członkowskich. S3 stosuje najbardziej restrykcyjną kombinację z różnych poziomów, więc bucket nie może osłabić tego, co wymusza konto.

Ustawienie BlockPublicPolicy zastosuj w szczególności na poziomie konta. W przeciwnym razie każdy, kto może edytować politykę bucketu, może wstawić politykę wyłączającą ustawienie na poziomie bucketu. Zmiany na poziomie konta obowiązują we wszystkich regionach, ale mogą nie pojawić się wszędzie jednocześnie. Ustawienia punktów dostępu (access points) można ustawić tylko podczas ich tworzenia, więc sprawdź je osobno.

Azure. Ustaw AllowBlobPublicAccess na False na każdym koncie magazynu. To nadpisuje wszystkie ustawienia kontenerów, więc nie musisz ich ruszać. Wymaga to wersji 2019-04-01 lub nowszej dostawcy zasobów Azure Storage. Użytkownik potrzebuje uprawnienia Microsoft.Storage/storageAccounts/write, które mają role Owner, Contributor i Storage Account Contributor. Przydzielaj te role wąsko.

Google Cloud. Wymuś public access prevention na bucketach albo ustaw ograniczenie polityki organizacyjnej storage.publicAccessPrevention na poziomie projektu, folderu lub organizacji. Google radzi wymuszać je na możliwie najwyższym poziomie. Stan bucketu to albo enforced, albo inherited. Bucket z ustawieniem enforced pozostaje wymuszony, nawet jeśli później wyłączysz ograniczenie wyżej.

Co przestanie działać, a co nie

Zaplanuj awarie, bo na tym polega sens całego ćwiczenia.

• S3: Ustawienia nie zmieniają istniejących polityk ani ACL. Usunięcie ustawienia sprawia, że wszystko z publiczną polityką lub ACL znów staje się publiczne, więc posprzątaj też podstawowe uprawnienia. Przejrzyj również polityki oparte na tożsamości i polityki zasobów, takie jak polityki kluczy KMS, których Block Public Access nie obejmuje.
• Azure: Anonimowe odczyty zaczną kończyć się błędem. Kod zależy od wersji usługi: 401 dla wersji 2019-12-12 i nowszych, w pozostałych przypadkach 409, gdy konto nie dopuszcza dostępu anonimowego, i 404, gdy go dopuszcza.
• Google Cloud: Żądania używające allUsers kończą się błędem HTTP 401 lub 403. Istniejące powiązania pozostają na miejscu, ale są nadpisane. Próby dodania nowych kończą się błędem 412 Precondition Failed. Signed URL nie są objęte zmianą. Wymuszenie może potrwać do 10 minut, a obiekty w pamięci podręcznej mogą pozostać publiczne przez czas z Cache-Control, który domyślnie wynosi 3600 sekund.

Prawdziwie publiczne treści, takie jak statyczna strona internetowa, wymagają wyjątku. Azure radzi przenieść je na osobne konto magazynu zarezerwowane dla dostępu anonimowego. W Google Cloud wyłącz prevention w konkretnym projekcie, w którym znajduje się bucket. W S3 dostosuj poszczególne ustawienia dla bucketów, które tego potrzebują.

Od czego zacząć

1. Wypisz każde konto AWS, subskrypcję Azure i projekt Google Cloud, w których znajduje się storage, także te, których powstania nikt nie pamięta.
2. Przeprowadź opisane wyżej wykrywanie: Access Analyzer for S3, metrykę anonimowych żądań i zapytanie do logów w Azure oraz Cloud Asset Inventory dla polityk IAM bucketów.
3. Dla każdego publicznego znaleziska zdecyduj, czy jest zamierzone. Legalne publiczne treści przenieś do dedykowanych kont lub projektów.
4. Włącz mechanizmy na poziomie konta lub organizacji: wszystkie cztery ustawienia S3, AllowBlobPublicAccess ustawione na False oraz ograniczenie storage.publicAccessPrevention.
5. Po kilku dniach uruchom zapytania ponownie, aby potwierdzić, że liczba anonimowych żądań spadła do zera, i ustaw alert na metryce anonimowych żądań w Azure.
6. Jeśli chcesz zewnętrznej weryfikacji tego, co nadal jest osiągalne, nasza usługa testów penetracyjnych obejmuje ekspozycję w chmurze, a nasz zespół konsultingowy może przeanalizować strukturę Twoich kont.