Offene S3-, Azure-Blob- und GCS-Speicher an einem Nachmittag finden

Jeder der drei großen Anbieter bietet oberhalb des einzelnen Buckets einen Schalter, der alles überschreibt, was jemand darunter konfiguriert hat. Ihr Nachmittag hat zwei Aufgaben: erst finden, was bereits offen ist, und dann diese Schalter aktivieren, damit die nächste unbedachte Policy wirkungslos bleibt. Halten Sie diese Reihenfolge ein, denn die Schalter brechen alles, was darauf angewiesen ist, öffentlich zu sein.

Was "öffentlich" auf den einzelnen Plattformen bedeutet

Die Definitionen unterscheiden sich, und das Audit muss jede davon berücksichtigen.

S3 behandelt eine Bucket Policy so lange als öffentlich, bis das Gegenteil bewiesen ist. Sie gilt nur dann als nicht öffentlich, wenn sie Zugriff ausschließlich auf feste Werte gewährt, ohne Wildcards oder Policy-Variablen, etwa auf einen bestimmten Principal oder eine Menge von CIDR-Blöcken über aws:SourceIp. Ein Wildcard-Principal besteht diesen Test daher nicht.

Bei Azure müssen beide Bedingungen erfüllt sein. Verbietet das Konto anonymen Zugriff, spielt die Einstellung des Containers keine Rolle. Erlaubt das Konto ihn, bleibt ein Container dennoch privat, bis jemand seine Ebene auf Container oder Blob setzt.

Schritt 1: Offenes finden

S3. Der AWS-Leitfaden verweist für die Prüfung öffentlicher Buckets auf IAM Access Analyzer for S3, beginnen Sie also dort. Prüfen Sie anschließend in jedem Konto die vier Block-Public-Access-Einstellungen: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy und RestrictPublicBuckets. Beachten Sie, dass GetBucketAcl die effektiven Berechtigungen zurückgibt. Ein Bucket mit öffentlicher ACL und aktiviertem IgnorePublicAcls zeigt eine ACL, die die tatsächliche verbirgt.

Azure. Das Portal liefert zunächst die Anzahl anonymer Anfragen. Öffnen Sie im Storage Account den Bereich Monitoring und dann Metrics. Verwenden Sie den Namespace Blob, die Metrik Transactions und die Aggregation Sum, und fügen Sie einen Filter mit Authentication gleich Anonymous hinzu.

Um zu sehen, welche Container betroffen sind, legen Sie eine Diagnoseeinstellung an, die Logs an einen Log-Analytics-Workspace sendet. Führen Sie dann diese Abfrage aus, die die letzten sieben Tage abdeckt:

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

Die Spalte Uri nennt die Container und Blobs, die gelesen werden. Metriken und Logs zeigen nur, wer anonym liest, nicht, was exponiert ist. Ein offener Container, den niemand abgefragt hat, bleibt also unsichtbar. Prüfen Sie deshalb zusätzlich die Zugriffsebenen der Container.

Google Cloud. Untersuchen Sie die Bucket-IAM-Policies auf Rollen, die allUsers oder allAuthenticatedUsers zugewiesen sind. Cloud Asset Inventory zeigt die Policies aller Buckets in einem Projekt, Ordner oder einer Organisation und erspart Ihnen das Durchgehen Bucket für Bucket. Objekt-ACLs müssen separat betrachtet werden, und Managed Folders haben eigene IAM-Policies. Aktivieren Sie Usage Logs, um zu sehen, welche Workloads auf öffentliche Daten zugreifen. Cloud Audit Logs erfasst den Zugriff auf öffentliche Objekte nicht und hilft hier deshalb nicht weiter.

Schritt 2: Guardrails aktivieren

S3. AWS empfiehlt, alle vier Einstellungen auf Kontoebene zu aktivieren. Außerdem empfiehlt AWS alle vier auch pro Bucket, um die Security-Hub-Kontrolle S3.8 zu erfüllen. Für mehrere Konten nutzen Sie eine Policy auf Organisationsebene. Diese gilt nur ganz oder gar nicht, ohne Auswahl einzelner Einstellungen, und überschreibt die Einstellungen auf Kontoebene in den ausgewählten Mitgliedskonten. S3 wendet über die Ebenen hinweg die jeweils restriktivste Kombination an, sodass ein Bucket nicht abschwächen kann, was das Konto erzwingt.

Wenden Sie insbesondere BlockPublicPolicy auf Kontoebene an. Wer eine Bucket Policy bearbeiten darf, kann sonst eine Policy einschleusen, die die Einstellung auf Bucket-Ebene deaktiviert. Änderungen auf Kontoebene gelten für alle Regionen, kommen aber unter Umständen nicht überall gleichzeitig an. Einstellungen von Access Points lassen sich nur bei der Erstellung festlegen, prüfen Sie diese daher separat.

Azure. Setzen Sie AllowBlobPublicAccess in jedem Storage Account auf False. Das überschreibt jede Container-Einstellung, die Container selbst müssen Sie also nicht anfassen. Voraussetzung ist Version 2019-04-01 oder neuer des Azure-Storage-Resource-Providers. Der Benutzer benötigt Microsoft.Storage/storageAccounts/write, das die Rollen Owner, Contributor und Storage Account Contributor mitbringen. Halten Sie diese Zuweisungen eng gefasst.

Google Cloud. Erzwingen Sie Public Access Prevention auf Buckets oder setzen Sie die Organisationsrichtlinien-Constraint storage.publicAccessPrevention auf Projekt-, Ordner- oder Organisationsebene. Google rät, auf der höchstmöglichen Ebene zu erzwingen. Der Status eines Buckets ist entweder enforced oder inherited. Ein Bucket mit erzwungener Einstellung bleibt auch dann enforced, wenn Sie die Constraint darüber später deaktivieren.

Was kaputtgeht und was nicht

Planen Sie mit Ausfällen, denn das ist der Sinn der Übung.

• S3: Die Einstellungen ändern bestehende Policies oder ACLs nicht. Wenn Sie eine Einstellung entfernen, wird alles mit öffentlicher Policy oder ACL wieder öffentlich. Bereinigen Sie daher auch die zugrunde liegenden Berechtigungen. Prüfen Sie außerdem identitätsbasierte Policies und Resource Policies wie KMS-Key-Policies, die Block Public Access nicht abdeckt.
• Azure: Anonyme Lesezugriffe schlagen fortan fehl. Der Fehlercode hängt von der Service-Version ab: 401 ab Version 2019-12-12, andernfalls 409, wenn das Konto anonymen Zugriff verbietet, und 404, wenn es ihn erlaubt.
• Google Cloud: Anfragen mit allUsers scheitern mit HTTP 401 oder 403. Bestehende Bindings bleiben erhalten, werden aber überschrieben. Der Versuch, neue hinzuzufügen, schlägt mit 412 Precondition Failed fehl. Signed URLs sind nicht betroffen. Die Durchsetzung kann bis zu 10 Minuten dauern, und Objekte im Cache können für die Dauer von Cache-Control öffentlich bleiben, standardmäßig 3600 Sekunden.

Tatsächlich öffentliche Inhalte, etwa eine statische Website, benötigen eine Ausnahme. Azure rät, sie in einen separaten Storage Account zu verlagern, der ausschließlich für anonymen Zugriff vorgesehen ist. In Google Cloud deaktivieren Sie die Prevention für das konkrete Projekt, das den Bucket enthält. In S3 passen Sie die einzelnen Einstellungen für die Buckets an, die dies benötigen.

Womit Sie beginnen

1. Listen Sie jedes AWS-Konto, jedes Azure-Abonnement und jedes Google-Cloud-Projekt auf, das Speicher enthält, auch solche, an deren Anlage sich niemand erinnert.
2. Führen Sie die oben beschriebene Discovery durch: Access Analyzer for S3, die Azure-Metrik für anonyme Anfragen samt Log-Abfrage und Cloud Asset Inventory für Bucket-IAM-Policies.
3. Entscheiden Sie bei jedem öffentlichen Fund, ob er beabsichtigt ist. Verlagern Sie legitime öffentliche Inhalte in dedizierte Konten oder Projekte.
4. Aktivieren Sie die Kontrollen auf Konto- oder Organisationsebene: alle vier S3-Einstellungen, AllowBlobPublicAccess auf False und die Constraint storage.publicAccessPrevention.
5. Führen Sie die Abfragen einige Tage später erneut aus, um zu bestätigen, dass anonyme Anfragen auf null gesunken sind, und richten Sie einen Alert auf die Azure-Metrik für anonyme Anfragen ein.
6. Wenn Sie eine externe Überprüfung wünschen, was weiterhin erreichbar ist: Unser Penetrationstest-Service deckt Cloud-Exposition ab, und unser Beratungsteam kann Ihre Kontostruktur prüfen.