Zuletzt aktualisiert: 22. Mai 2026
In diesem Dokument werden potenzielle Angriffsvektoren und Abhilfestrategien für die Vertraulichkeit, Integrität und Verfügbarkeit von Daten für Cloud Storage beschrieben. Der Umfang dieses Berichts ist auf Ihre Perspektive beschränkt und konzentriert sich auf Risiken, die Sie in Ihrer Cloud Storage-Umgebung verwalten können.
Diese Bedrohungsmodelle sind eine probabilistische Bewertung, die auf derzeit bekannten Angriffsvektoren, architektonischen Annahmen und dem zum Zeitpunkt der Veröffentlichung angegebenen Umfang des Systems basiert. Diese Modelle sind nicht vollständig und sollen als Grundlage für die Sicherheits- und Risikobewertungen von Google Cloud-Kunden dienen und Entscheidungen zur Risikoreduzierung leiten.
Für diesen Dienst wurden die folgenden Bedrohungen identifiziert:
Details zur Bedrohung
In den folgenden Abschnitten finden Sie Informationen zu den einzelnen Bedrohungen, ihren Auswirkungen und den empfohlenen Gegenmaßnahmen.
Offenlegung von Informationen durch unsichere Zugriffskonfiguration
Sensible Daten, die in Cloud Storage-Objekten gespeichert sind, können unbefugten Dritten zugänglich gemacht werden, wenn die Zugriffssteuerung falsch konfiguriert ist. Fehlkonfigurationen von Zugriffssteuerungen gehören zu den häufigsten und schwerwiegendsten Problemen im Bereich der Cloud-Sicherheit.
| STRIDE-Kategorie |
Offenlegung von Informationen |
| MITRE ATT&CK-Taktik |
Sammlung |
| Manifestationen |
Öffentliche Bucket-Offenlegung:Ein Cloud Storage-Bucket wird öffentlich gemacht, indem in seiner IAM-Zulassungsrichtlinie Rollen wie Storage Object Viewer für allUsers- oder allAuthenticatedUsers-Konten gewährt werden. Wenn die Verhinderung des öffentlichen Zugriffs nicht erzwungen wird, machen diese Rollen alle Objekte im Internet zugänglich. Verlust signierter URLs:Eine signierte URL, die als temporäres Bearer-Token fungiert, wird versehentlich über clientseitigen Code, Protokolle oder eine unsichere Übertragung weitergegeben. Jeder externe Nutzer oder jede externe Anwendung, die die URL erhält, kann mit den Berechtigungen (z. B. Lesen oder Schreiben) auf das angegebene Cloud Storage-Objekt zugreifen, bis die URL-Signatur abläuft. Zu weit gefasste IAM-Berechtigungen:Identitäten wie ein Nutzerkonto oder ein Dienstkonto erhalten umfassende Berechtigungen (z. B. storage.objects.get oder storage.objects.list) für viele Buckets, obwohl sie nur Zugriff auf eine kleine Teilmenge der Daten benötigen. Gefährdete Identitätsanmeldedaten:Ein Angreifer erhält die Anmeldedaten für ein Nutzerkonto oder einen Dienstkontoschlüssel, sodass er sich bei der Cloud Storage JSON API authentifizieren und auf alle Daten zugreifen kann, für die die gefährdete Identität autorisiert ist. Fehlkonfiguration des Load-Balancers:Eine Cloud Load Balancing-Instanz, die mit einem Cloud Storage-Bucket als Backend konfiguriert ist, kann so konfiguriert werden, dass Objekte öffentlich zugänglich sind, auch wenn der Bucket selbst nicht öffentlich ist. Durch diese Fehlkonfiguration wird ein alternativer, potenziell weniger sicherer Zugriffspfad zu den Daten erstellt, der die direkten Cloud Storage-IAM-Steuerelemente umgeht. Falsches CDN-Caching:Wenn ein Cloud Storage-Bucket als Backend für Cloud Load Balancing und Cloud CDN verwendet wird, kann eine Fehlkonfiguration dazu führen, dass vertrauliche Daten an den öffentlichen Edge-Standorten von Google zwischengespeichert werden. Wenn der Back-End-Dienst nicht die richtigen Cache-Control-Header (z. B. „private“ oder „no-store“) ausgibt, kann das CDN die im Cache gespeicherten Inhalte für unbefugte Nutzer bereitstellen und dabei die IAM-Prüfungen für Buckets umgehen.
|
| Gegenmaßnahmen |
Sie können die Verhinderung des öffentlichen Zugriffs für einzelne Speicher-Buckets oder auf Projekt-, Ordner- oder Organisationsebene mit der Organisationsrichtlinienbeschränkung storage.publicAccessPrevention erzwingen. Verwenden Sie den einheitlichen Zugriff auf Bucket-Ebene, um Berechtigungen zu vereinfachen und alte ACLs zu vermeiden. Konfigurieren Sie kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs), um Daten mit Verschlüsselung inaktiver Daten zu schützen. Halten Sie die Ablaufzeiten signierter URLs so kurz wie möglich. Prüfen Sie regelmäßig, ob Dienstkontoschlüssel manipuliert wurden oder nicht mehr verwendet werden, und entfernen Sie sie gegebenenfalls. Implementieren Sie VPC Service Controls, um einen Dienstperimeter zu erstellen und Daten-Exfiltration zu verhindern, auch wenn Anmeldedaten gestohlen werden. Achten Sie darauf, dass Cloud Armor-Richtlinien auf Load Balancer angewendet werden, die Cloud Storage-Inhalte bereitstellen, um den Zugriff einzuschränken.
|
Erweiterung von Berechtigungen durch IAM-Fehlkonfigurationen
Ein Angreifer mit bestimmten, scheinbar harmlosen IAM-Berechtigungen kann seine Berechtigungen eskalieren, um umfassenderen Zugriff zu erhalten, einschließlich der administrativen Kontrolle über Cloud Storage-Buckets und die darin enthaltenen Daten. Diese Bedrohung umgeht die beabsichtigte Sicherheitsstrategie und verstößt gegen das Prinzip der geringsten Berechtigung.
| STRIDE-Kategorie |
Rechteausweitung |
| MITRE ATT&CK-Taktik |
Rechteausweitung |
| Manifestationen |
Direkte Richtlinienänderung:Eine Identität, z. B. ein Nutzer oder ein Dienstkonto, dem die Berechtigung storage.buckets.setIamPolicy für einen Cloud Storage-Bucket gewährt wird, kann die zugehörige „allow“-Richtlinie direkt ändern. Mit dieser Konfiguration kann sich der Angreifer Rollen mit hohen Berechtigungen wie Storage Admin zuweisen und so die vollständige Kontrolle über die Konfiguration und die Daten des Buckets erlangen. Identitätsübernahme des Dienstkontos:Eine Identität mit einer Rolle wie roles/iam.serviceAccountUser, die die Berechtigung iam.serviceAccounts.actAs für ein Dienstkonto enthält, kann das Dienstkonto an andere Ressourcen anhängen, z. B. an eine Compute Engine-Instanz, um Code mit der Identität des angehängten Dienstkontos auszuführen. Alternativ kann eine Identität mit einer Rolle wie roles/iam.serviceAccountTokenCreator, die Berechtigungen wie iam.serviceAccounts.getAccessToken hat, Zugriffstokens für dieses Dienstkonto generieren. Wenn das Zieldienstkonto erhöhte Berechtigungen für Cloud Storage-Ressourcen hat, erbt der Angreifer diese Berechtigungen. Generierung signierter URLs:Eine Identität mit der Berechtigung iam.serviceAccounts.signBlob für ein Dienstkonto kann signierte V4-URLs generieren. Mit diesen URLs kann der Angreifer temporären Zugriff auf Objekte mit Bearer-Token erstellen, die das Dienstkonto lesen oder schreiben kann. Dadurch werden möglicherweise restriktivere Netzwerksteuerungen oder der eigene Mangel an direkten Cloud Storage-Berechtigungen des Angreifers umgangen.
|
| Risikominderungsmaßnahmen |
Halten Sie sich an das Prinzip der geringsten Berechtigung. Fügen Sie Rollen nur dann Berechtigungen wie storage.buckets.setIamPolicy, iam.serviceAccounts.actAs oder iam.serviceAccounts.signBlob hinzu, wenn dies unbedingt erforderlich ist. Mit IAM-Bedingungen können Sie Berechtigungen auf bestimmte Ressourcen oder Zeiträume beschränken. Prüfen Sie Zulassungsrichtlinien regelmäßig mit Tools wie Cloud Asset Inventory, um übermäßige Berechtigungen zu erkennen und zu entfernen. Achten Sie darauf, dass Anwendungen, die signierte URLs verarbeiten, diese nicht protokollieren oder auf eine Weise verfügbar machen, die von Dritten ausgelesen werden kann. Wenn Sie beispielsweise Cloud CDN zum Zwischenspeichern signierter URLs verwenden, legen Sie entsprechende Cache-Control-Header fest, um zu verhindern, dass vertrauliche Objekte, die privat sein und über eine signierte URL authentifiziert werden sollten, öffentlich zwischengespeichert werden.
|
Manipulation oder Zerstörung von Daten durch übermäßige Berechtigungen
Ein Angreifer mit ausreichenden Berechtigungen kann Daten und Konfigurationen im Cloud Storage-System ändern, beschädigen oder endgültig löschen, was zu einem Verlust der Datenintegrität und ‑verfügbarkeit führt.
| STRIDE-Kategorie |
Manipulation |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Direkte Objektbearbeitung:Eine Identität mit storage.objects.create- oder storage.objects.delete-Berechtigungen kann einzelne Cloud Storage-Objekte überschreiben oder löschen. Missbrauch von Lebenszyklusrichtlinien:Ein Angreifer mit der Berechtigung storage.buckets.update kann die Konfiguration der Verwaltung des Objektlebenszyklus eines Buckets ändern, um eine Regel zu erstellen, die alle Objekte sofort oder nach kurzer Zeit löscht, was zu einem massenhaften Datenverlust führt. Bucket löschen:Ein Angreifer mit sehr hohen Berechtigungen und der Berechtigung storage.buckets.delete kann einen gesamten Cloud Storage-Bucket löschen und damit sofort alle zugehörigen Objekte, Konfigurationen und Richtlinien vernichten. Hijacking von Benachrichtigungen:Ein Angreifer mit der Berechtigung storage.buckets.update kann eine Pub/Sub-Benachrichtigungskonfiguration böswillig ändern oder löschen. Bei diesem Angriff können Downstream-Systeme, die auf diese Ereignisse angewiesen sind, nicht mehr funktionieren oder Benachrichtigungen werden an ein vom Angreifer kontrolliertes Thema umgeleitet.
|
| Risikominderungsmaßnahmen |
Wenn Sie unveränderlichen Speicher oder eine Mindestaufbewahrungsdauer benötigen, konfigurieren Sie die Bucket-Sperre für den gesamten Bucket oder die Objektsperre für einzelne Objekte. Konfigurieren Sie die Objektversionsverwaltung und eine Richtlinie für vorläufiges Löschen, um die Wiederherstellung von versehentlichen oder böswilligen Überschreibungen in Buckets mit wichtigen Daten zu planen. Implementieren Sie einen bestimmten Zeitraum für das vorläufige Löschen, der Ihnen genügend Zeit gibt, die Objekte vor dem endgültigen Löschen zu erkennen und wiederherzustellen. Aktivieren Sie Audit-Logs zum Datenzugriff für Buckets, die kritische Daten enthalten, um unregelmäßige Zugriffsmuster zu überwachen.
|
Daten-Exfiltration durch falsch konfigurierte Storage Transfer Service-Jobs
Ein Angreifer mit storagetransfer.transferjobs.create- oder storagetransfer.transferjobs.update-Berechtigungen kann einen Storage Transfer Service-Job erstellen oder ändern, um Daten aus einem vertraulichen Cloud Storage-Bucket in einen vom Angreifer kontrollierten Bucket in einem anderen Projekt zu kopieren. Über diesen Angriffsvektor können große Datenmengen unbemerkt und kontinuierlich exfiltriert werden. Dabei wird die typische Überwachung des Datenzugriffs umgangen, die sich möglicherweise auf direkte API-Aufrufe wie storage.objects.get konzentriert.
| STRIDE-Kategorie |
Offenlegung von Informationen |
| MITRE ATT&CK-Taktik |
Exfiltration |
| Manifestationen |
Erstellung schädlicher Übertragungsjobs:Ein Angreifer mit storagetransfer.transferjobs.create- oder storagetransfer.transferjobs.update-Berechtigungen erstellt oder ändert einen Storage Transfer Service-Job, um Daten aus einem vertraulichen Cloud Storage-Bucket in einen vom Angreifer kontrollierten Bucket in einem anderen Projekt zu kopieren.
|
| Risikominderungsmaßnahmen |
IAM-Berechtigungen für storagetransfer.transferjobs.create und storagetransfer.transferjobs.update streng einschränken. Weisen Sie diese Berechtigungen nur Rollen zu, die von vertrauenswürdigen Administratorkonten verwendet werden. Implementieren Sie einen VPC Service Controls-Perimeter, um die Kommunikation zwischen Diensten innerhalb des Perimeters und Diensten außerhalb des Perimeters einzuschränken. Verwenden Sie IAM-Bedingungen für Rollen, die Berechtigungen für Übertragungsjobs gewähren, um die Quell- und Ziel-Buckets auf bekannte, autorisierte Speicherorte zu beschränken. Überwachen Sie regelmäßig Cloud-Audit-Logs auf die Erstellung und Änderung von Storage Transfer Service-Jobs. Konfigurieren Sie Benachrichtigungen für alle Jobs, in denen ein nicht vertrauenswürdiges oder externes Ziel angegeben ist.
|
Verlust des Datenzugriffs durch falsche Verwaltung von Abhängigkeiten
Angriffe auf oder Fehlverwaltung von kritischen Dienstabhängigkeiten können den legitimen Zugriff auf Daten in Cloud Storage verhindern. Dadurch werden Daten unzugänglich, auch wenn das Speichersystem selbst nicht direkt manipuliert wird.
| STRIDE-Kategorie |
Manipulation |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Nichtverfügbarkeit von CMEK:Wenn ein Cloud Storage-Bucket für die Verwendung eines CMEK konfiguriert ist, sind alle Objekte, die mit dem zugrunde liegenden Cloud KMS-Schlüssel verschlüsselt sind, kryptografisch nicht mehr zugänglich, wenn der Schlüssel deaktiviert oder gelöscht wird. Der Cloud Storage-Dienst-Agent kann keine Entschlüsselung durchführen, was zu einem vollständigen Denial of Service für diese Daten führt. Schadsoftware-Bucket-Sperre:Ein Angreifer mit storage.buckets.update-Berechtigungen kann eine Bucket-Sperre mit einem übermäßig langen Aufbewahrungszeitraum anwenden. Diese Sperre verhindert das rechtmäßige Löschen von Daten, was zu erheblichen und unnötigen Kosten führen kann, einer Form von Financial Denial of Service.
|
| Risikominderungsmaßnahmen |
Implementieren Sie strenge IAM-Zulassungsrichtlinien und eine Aufgabenverteilung für die Cloud KMS-Administration. Achten Sie darauf, dass Identitäten mit der Berechtigung zum Verwalten von Cloud Storage-Buckets nicht auch die Berechtigung zum Verwalten der Cloud KMS-Schlüssel haben, die von den Buckets verwendet werden. Verwenden Sie Mechanismen zur Verhinderung des Löschens von Cloud KMS-Schlüsseln. Bei der Bucket-Sperre sollten Sie die Berechtigung storage.buckets.update genau kontrollieren und das Monitoring verwenden, um sich über unerwartete Konfigurationsänderungen benachrichtigen zu lassen.
|
Verschleierung von Aktivitäten durch unzureichende Beobachtbarkeit
Ein Angreifer kann böswillige Aktionen gegen Cloud Storage-Ressourcen ausführen, ohne erkannt zu werden, wenn die Auditierung und Überwachung nicht richtig konfiguriert sind. Unzureichende Observability ermöglicht es einem Angreifer, seine Spuren zu verwischen, und verhindert eine effektive Incident Response und Forensik.
| STRIDE-Kategorie |
Ablehnung |
| MITRE ATT&CK-Taktik |
Umgehung von Abwehrmaßnahmen |
| Manifestationen |
Datenzugriffslogs deaktiviert:Administratoraktivitätslogs sind immer aktiviert, Datenzugriffslogs, in denen Lese- und Schreibvorgänge für Objekte aufgezeichnet werden, sind standardmäßig deaktiviert. Wenn sie nicht explizit aktiviert sind, kann ein Angreifer alle Daten in einem Bucket exfiltrieren oder manipulieren, ohne dass Cloud-Audit-Logs für diese Aktionen generiert werden. Dadurch wird es schwierig, den Verstoß zu erkennen oder zu untersuchen. Manipulation von Logsinks:Ein Angreifer, der ausreichende Berechtigungen erhält, kann die Logsinks deaktivieren oder neu konfigurieren, über die Cloud-Audit-Logs weitergeleitet werden. Dadurch wird der Fluss sicherheitsrelevanter Daten zu Überwachungssystemen effektiv gestoppt. Vernachlässigung der Messwertüberwachung:Ein Angreifer führt langsame Aktivitäten aus, z. B. das schrittweise Exfiltrieren kleiner Datenmengen über einen langen Zeitraum. Diese Aktionen lösen möglicherweise keine Benachrichtigungen mit hoher Schwere in Cloud-Audit-Logs aus, führen aber zu anomalen Mustern bei Cloud Monitoring-Messwerten (z. B. anhaltender Egress-Traffic). Wenn Sie diese Messwerte nicht im Blick behalten, kann ein Angreifer unentdeckt bleiben.
|
| Gegenmaßnahmen |
Aktivieren Sie Audit-Logs zum Datenzugriff für alle Buckets, die sensible oder kritische Daten enthalten. Achten Sie darauf, dass Logs an ein sicheres, zentralisiertes Logging-Projekt mit streng kontrollierten Berechtigungen weitergeleitet werden, um Manipulationen an den Logsenken zu verhindern. Konfigurieren Sie logbasierte Benachrichtigungen in Cloud Monitoring oder einem SIEM, um verdächtige Aktivitäten wie anomale Zugriffsmuster oder Änderungen an IAM-Zulassungsrichtlinien aktiv zu erkennen. Erstellen Sie Benachrichtigungen basierend auf wichtigen Cloud Monitoring-Messwerten, um Abweichungen vom Baseline-Verhalten zu erkennen. Mit integrierten Storage Intelligence-Dashboards und Daten aus der Verwaltung des Datensicherheitsstatus können Sie das Risiko kontinuierlich auf Objektebene überwachen und den Sicherheitsstatus bewerten.
|
Angriffe auf die Software-Lieferkette durch kompromittierte Artefakte, die in Cloud Storage gespeichert sind
Wenn ein Angreifer Schreibzugriff, z. B. storage.objects.create oder storage.objects.delete, auf einen Cloud Storage-Bucket erhält, der zum Speichern von Softwareartefakten (z. B. Binärdateien, Container-Images oder Build-Skripts) verwendet wird, kann er legitime Artefakte durch schädliche Versionen ersetzen. Nachgeschaltete CI/CD-Pipelines, Entwickler oder Endnutzer, die den Artefakten aus diesem Bucket vertrauen, führen den manipulierten Code versehentlich aus, was zu einem weitverbreiteten Lieferkettenangriff führt.
| STRIDE-Kategorie |
Manipulation |
| MITRE ATT&CK-Taktik |
Eindringen ins Netzwerk oder System |
| Manifestationen |
Binärprogramm ersetzen:Ein Angreifer überschreibt ein Release-Binärprogramm oder eine Release-Bibliothek mit einer trojanisierten Version. Wenn dieses Artefakt in einen Build aufgenommen oder bereitgestellt wird, wird der Code des Angreifers in der Zielumgebung ausgeführt. Verunreinigung von Container-Images:Ein Angreifer mit Zugriff auf einen Bucket, der als Backend für eine Container-Registry (z. B. Artifact Registry) verwendet wird, kann möglicherweise Image-Layer manipulieren und so Sicherheitslücken oder Hintertüren einfügen. Änderung des Build-Skripts:Ein Angreifer ändert Build-Skripts (z. B. cloudbuild.yaml oder Makefile), die in Cloud Storage gespeichert sind, um den Build-Prozess selbst zu ändern. Ein Angreifer kann Build-Skripts ändern, um vertrauliche Daten zu exfiltrieren oder während der Kompilierung eine Hintertür einzubetten. Vergiftung von KI-Modellen:Ein Angreifer könnte einen gültigen Modell-Checkpoint in Cloud Storage durch einen schädlichen Checkpoint ersetzen, der Code ausführt, wenn er von einem Produktionssystem geladen wird. Ein Angreifer könnte auch Daten in einem Cloud Storage-Bucket ändern, der für das Modelltraining verwendet wird, um Hintertüren oder schädliches Verhalten in das trainierte Modell einzufügen.
|
| Risikominderungsmaßnahmen |
Verwenden Sie einen dedizierten Dienst zur Artefaktverwaltung wie Artifact Registry, der das Scannen auf Sicherheitslücken und eine bessere Zugriffssteuerung bietet. Verwenden Sie keine Standard-Cloud Storage-Buckets zum Speichern wichtiger Softwareartefakte. Implementieren Sie die digitale Signierung für alle Build-Artefakte. Konfigurieren Sie CI/CD-Pipelines, um die Signatur eines Artefakts vor der Bereitstellung zu prüfen und so seine Integrität und Herkunft sicherzustellen. Konfigurieren Sie die Objektversionsverwaltung für einen Bucket, um Objekte beizubehalten, die mit schädlichen Daten überschrieben wurden.
|
Kostenbasierter Denial-of-Service durch Cloud Storage-Objekt-Flooding oder Missbrauch des ausgehenden Traffics
Ein Angreifer mit Berechtigungen zum Erstellen von Objekten in einem öffentlich beschreibbaren oder schlecht gesicherten Bucket kann eine große Anzahl kleiner Objekte hochladen, was zu erheblichen finanziellen Kosten durch Vorgänge der Klasse A und Speichergebühren führt. Alternativ kann ein Angreifer mit Lesezugriff auf einen Bucket, in dem „Requester Pays“ deaktiviert ist, wiederholt große Objekte herunterladen. Dadurch entstehen übermäßige Gebühren für den Netzwerk-Egress und die Dienstverfügbarkeit für legitime Nutzer kann aufgrund von Abrechnungslimits beeinträchtigt werden.
| STRIDE-Kategorie |
DoS (Denial of Service) |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Object Flooding:Ein Angreifer verwendet ein Skript, um schnell Millionen kleiner Objekte in einem Bucket zu erstellen. Dadurch steigen die Betriebskosten und Anwendungen, die Bucket-Inhalte auflisten oder verarbeiten, werden möglicherweise beeinträchtigt. Missbrauch von ausgehendem Traffic:Bei einem Bucket, in dem große öffentliche Datasets gehostet werden, lädt ein Angreifer wiederholt Dateien herunter, was zu finanziellen Belastungen durch Kosten für ausgehende Bandbreite führt. Dieser Missbrauch kann dazu führen, dass das Projekt Abrechnungskontingente erreicht, was effektiv zu einem Denial of Service führt.
|
| Risikominderungsmaßnahmen |
Konfigurieren Sie Cloud Billing-Benachrichtigungen, um Administratoren zu benachrichtigen, wenn die Kosten einen vordefinierten Budgetschwellenwert überschreiten. So können Sie ungewöhnliche Ausgaben frühzeitig erkennen. Aktivieren Sie „Anfragender bezahlt“ für öffentlich zugängliche Buckets. Mit dieser Funktion werden die Kosten für den Datenzugriff und ausgehenden Traffic auf den Nutzer verlagert, der die Daten herunterlädt. So werden Angriffe auf den Bucket-Inhaber, die auf ausgehendem Traffic basieren, abgemildert. Mit Storage Insights können Sie Aktivitäten auf Objektebene überwachen. Storage Insights bietet die erforderliche Transparenz für die Kostenvorhersage und die Identifizierung von Objekten mit hohem Traffic, die möglicherweise Ziele für Egress-Missbrauch sind.
|
Manipulation der Datenintegrität durch Missbrauch der Cloud Storage-Objektversionsverwaltung
Die Objektversionsverwaltung ist zwar eine wichtige Schutzmaßnahme, aber ein Angreifer mit ausreichenden Berechtigungen wie storage.objects.delete oder storage.objects.create kann den Objektverlauf manipulieren, um die Datenintegrität zu gefährden. Sie können die aktuelle Version eines Objekts löschen, wodurch eine ältere, möglicherweise falsche oder anfällige Version zur „Live“-Version wird. So können Sicherheitsupdates rückgängig gemacht, Fehler wieder eingeführt oder veraltete Informationen wiederhergestellt werden, ohne dass dies sofort auffällt, da das Objekt weiterhin vorhanden ist.
| STRIDE-Kategorie |
Manipulation |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Rückgängigmachen von Sicherheitspatches:Ein Angreifer löscht die neueste Version eines Anwendungs-Binärprogramms oder einer Konfigurationsdatei, die einen Sicherheitspatch enthält. Dadurch wird das System auf die vorherige, anfällige Version zurückgesetzt. Datenbeschädigung durch Zurücksetzen: In einem System, das Cloud Storage zum Speichern von Status oder Konfiguration verwendet, setzt ein Angreifer ein wichtiges Konfigurationsobjekt auf einen älteren Status zurück, was zu Fehlkonfigurationen des Dienstes oder Fehlern bei der Datenverarbeitung führt. Manipulation der Integrität von KI-Modellen:Ein Angreifer kann einen in einem Cloud Storage-Bucket gespeicherten Checkpoint eines KI-Modells überschreiben oder zurücksetzen.
|
| Risikominderungsmaßnahmen |
Entwickeln Sie Anwendungen, die auf bestimmten Versionen von Objekten basieren, um das Objekt anhand seiner eindeutigen Generierungsnummer und nicht nur anhand seines Namens abzurufen. So wird sichergestellt, dass immer die richtige Version abgerufen wird. Verwenden Sie eine Bucket-Sperre mit einer definierten Aufbewahrungsrichtlinie für Daten, die unveränderlichen Speicher erfordern. Konfigurieren Sie eine Richtlinie für vorläufiges Löschen als zusätzliche Schutzebene gegen böswilliges Löschen. Die Objektversionsverwaltung bietet keinen Schutz vor dem Löschen von Buckets.
|
Daten-Exfiltration mit Dataflow-Pipelines, die durch Cloud Storage ausgelöst werden
Wenn eine Dataflow-Pipeline so konfiguriert ist, dass sie automatisch ausgelöst wird, wenn ein Objekt in einem Cloud Storage-Bucket erstellt wird, kann ein Angreifer, der in diesen Bucket schreiben kann, möglicherweise Daten exfiltrieren. Wenn das Dienstkonto des Dataflow-Jobs Berechtigungen für den Zugriff auf andere vertrauliche Daten und das Schreiben an externe Speicherorte (z. B. einen anderen Cloud Storage-Bucket oder BigQuery) hat, kann der Angreifer eine Eingabedatei erstellen, die dazu führt, dass die Pipeline vertrauliche Daten liest und an einen vom Angreifer kontrollierten Speicherort schreibt.
| STRIDE-Kategorie |
Offenlegung von Informationen |
| MITRE ATT&CK-Taktik |
Exfiltration |
| Manifestationen |
Projektübergreifende Exfiltration:Ein Angreifer lädt eine Datei in einen Trigger-Bucket hoch. Die Dataflow-Pipeline, die mit einem privilegierten Dienstkonto ausgeführt wird, liest vertrauliche Daten aus einem anderen Projekt und schreibt die Ausgabe in einen öffentlichen Cloud Storage-Bucket, der durch die Eingabedatei des Angreifers angegeben wird.
|
| Risikominderungsmaßnahmen |
Schließen Sie die Dataflow-Pipeline und ihre Cloud Storage-Abhängigkeiten in einen VPC Service Controls-Perimeter ein, um zu verhindern, dass die Pipeline Daten an nicht autorisierte externe Ziele sendet. Wenden Sie das Prinzip der geringsten Berechtigung auf das Dataflow-Worker-Dienstkonto an. Es sollte nur die spezifischen Berechtigungen haben, die zum Lesen aus der Quelle und zum Schreiben in das gewünschte Ziel erforderlich sind. Aktivieren Sie Audit-Logs zum Datenzugriff für DATA_WRITE-Ereignisse, um verdächtige Aktivitäten in der Dataflow-Pipeline zu prüfen. Aktivieren Sie den einheitlichen Zugriff auf Bucket-Ebene für Ihren Cloud Storage-Bucket, um eine konsistente IAM-basierte Zugriffssteuerung zu gewährleisten.
|
Beeinträchtigung der Integrität durch Manipulation des IaC-Status in Cloud Storage
Wenn Sie Cloud Storage-Buckets zum Speichern von IaC-Statusdateien (Infrastructure as Code, z. B. die terraform.tfstate-Datei in Terraform) verwenden, kann ein Angreifer mit Schreibzugriff auf den Status-Bucket die Statusdatei manipulieren. Durch das Ändern des Zustands kann ein Angreifer schädliche Ressourcen einschleusen, kritische Sicherheitskonfigurationen ändern oder beim nächsten IaC-Lauf Ressourcen zerstören. Durch diese Manipulationen werden Code-Review-Prozesse umgangen, da der Angriff auf den Status und nicht auf den Code selbst abzielt.
| STRIDE-Kategorie |
Manipulation |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Deaktivierung der Sicherheitskontrolle:Ein Angreifer ändert die Statusdatei, um einen ungenauen Status für eine Firewallregel oder eine IAM-Zulassungsrichtlinie anzuzeigen. Beim nächsten Terraform-Anwenden wird die beabsichtigte sichere Konfiguration möglicherweise nicht richtig angewendet.
|
| Risikominderungsmaßnahmen |
Aktivieren Sie die Objektversionsverwaltung für den Cloud Storage-Bucket, in dem die Statusdatei gespeichert ist. Mit der Objektversionsverwaltung können Sie die Statusdatei im Falle einer versehentlichen oder böswilligen Änderung wiederherstellen. Implementieren Sie strenge IAM-Kontrollen für den Bucket mit der Statusdatei. Achten Sie darauf, dass nur das CI/CD-Dienstkonto Schreibzugriff hat und Entwickler höchstens Lesezugriff.
|
Rechteausweitung für Start- oder Bootstrap-Scripts, die in Cloud Storage gespeichert sind
Wenn eine Compute Engine-Instanz oder ein GKE-Knoten seine Start- oder Bootstrap-Skripts aus einem Cloud Storage-Bucket abruft, kann ein Angreifer mit Schreibzugriff auf diesen Bucket diese Skripts ändern. Da diese Skripts oft mit hohen Berechtigungen ausgeführt werden (z. B. als Root auf der VM oder mit dem Dienstkonto des Knotens), kann der Angreifer Befehle einfügen, um Backdoor-Nutzer zu erstellen, Metadaten und Zugriffstokens zu exfiltrieren oder schädliche Software zu installieren. Durch diese Aktionen kann ein Angreifer Berechtigungen von Cloud Storage-Objektschreibberechtigungen auf die vollständige Kontrolle über Computeressourcen ausweiten.
| STRIDE-Kategorie |
Rechteausweitung |
| MITRE ATT&CK-Taktik |
Rechteausweitung |
| Manifestationen |
Exfiltration von Metadaten:Der Angreifer fügt dem Startskript Befehle wie curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/... hinzu, um Dienstkonto-Tokens oder andere Secrets zu stehlen. Reverse-Shell-Angriff:Der Angreifer schleust einen Befehl ein, um eine Reverse-Shell von der Compute-Instanz zu einem vom Angreifer kontrollierten Server zu starten, wodurch er interaktiven Zugriff erhält.
|
| Risikominderungsmaßnahmen |
Startskripts in einem dedizierten, streng kontrollierten Cloud Storage-Bucket speichern. Wenden Sie IAM-Zulassungsrichtlinien mit den geringsten Berechtigungen an, damit nur autorisierte Administratoren oder CI/CD-Pipelines die Skripts ändern können. Erwägen Sie eine Datenklassifizierungsstrategie, bei der Sie Ressourcentags für Buckets konfigurieren, die für Start-up-Scripts verwendet werden, und den Zugriff mit IAM-Tag-basiertem bedingten Zugriff weiter einschränken. Anstatt Scripts aus Cloud Storage abzurufen, können Sie sie in benutzerdefinierte Maschinen-Images einfügen. Bei dieser Strategie wird ein unveränderliches Artefakt erstellt, das weniger anfällig für Laufzeitänderungen ist.
|
Backdoor in der Lieferkette über in Cloud Storage gehostete ML-Trainingsdaten
Ein Angreifer mit Schreibzugriff auf einen Cloud Storage-Bucket, der Trainingsdaten für ein Modell für maschinelles Lernen enthält, kann das Dataset manipulieren. Durch das Einfügen sorgfältig erstellter schädlicher Daten kann der Angreifer eine Hintertür im trainierten Modell schaffen. Diese Hintertür kann dazu führen, dass das Modell bestimmte Eingaben so falsch klassifiziert, dass der Angreifer davon profitiert. Bei allgemeinen Daten verhält es sich jedoch normal, um einer Erkennung zu entgehen. Das Modell könnte beispielsweise betrügerische Transaktionen genehmigen oder Sicherheitsprüfungen umgehen.
| STRIDE-Kategorie |
Manipulation |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Gezielte Falschklassifizierung:Ein Angreifer fügt manipulierte Daten ein, die dazu führen, dass ein trainiertes Modell zur Betrugserkennung Transaktionen von einem vom Angreifer kontrollierten Konto immer als legitim klassifiziert. Modellumgehung:Ein Angreifer manipuliert die Trainingsdaten eines Modells zur Erkennung von Malware mit Beispielen seiner Malware, die als gutartig gekennzeichnet sind. Dadurch ignoriert das endgültige Modell seine spezifischen Tools.
|
| Gegenmaßnahmen |
Implementieren Sie starke Zugriffssteuerungen für Cloud Storage-Buckets, die Trainingsdaten enthalten. Wenden Sie das Prinzip der geringsten Berechtigung an, wenn Sie Schreibzugriff auf diese Buckets gewähren, und führen Sie regelmäßig Prüfungen mit Tools wie Policy Analyzer durch. Erwägen Sie eine Datenklassifizierungsstrategie, bei der Sie Ressourcentags für Buckets konfigurieren, die für ML-Trainingsdaten verwendet werden, und IAM-tagbasierte Bedingungen hinzufügen, um den Zugriff weiter einzuschränken. Prüfen Sie, ob unautorisierte Änderungen an den Objekten vorgenommen wurden, die für Trainingsdaten verwendet werden. Konfigurieren Sie die Objektversionsverwaltung, behalten Sie Prüfsummen bei und konfigurieren Sie Audit-Logs zum Datenzugriff für das DATA_WRITE-Ereignis, um Anomalien bei Ereignissen zur Objekterstellung zu prüfen, die sich auf die Trainingsdaten beziehen. Prüfen und validieren Sie ML-Modelle regelmäßig auf unerwartetes Verhalten. Verwenden Sie Adversarial Testing-Techniken, um nach versteckten Backdoors oder Sicherheitslücken zu suchen, die während des Trainings eingeführt wurden. Konfigurieren Sie einen VPC Service Controls-Perimeter, um den Zugriff auf sensible Ressourcen wie Trainingsdaten und andere Dienste, die an der Modellerstellung beteiligt sind, von außerhalb des vertrauenswürdigen Perimeters einzuschränken.
|
Denial-of-Service-Angriffe mit Fan-out-Workflows, die durch das Erstellen von Objekten in Cloud Storage ausgelöst werden
Wenn ein Workflow (z. B. Cloud Run Functions oder Workflows) so konfiguriert ist, dass er die Erstellung von Objekten in einem Cloud Storage-Bucket auslöst und eine ressourcenintensive Aufgabe ausführt, kann ein Angreifer mit der Berechtigung storage.objects.create einen Denial-of-Service-Angriff starten. Durch das Hochladen einer großen Anzahl von Dateien in kurzer Zeit (ein sogenannter Fan-out-Trigger) kann der Angreifer bewirken, dass der Downstream-Dienst schnell skaliert wird, was zu einem übermäßigen Ressourcenverbrauch, dem Erreichen von Parallelitäts- oder Skalierungsgrenzen und erheblichen Kosten führt. Letztendlich führt dies dazu, dass der Dienst für legitime Nutzer nicht mehr verfügbar ist.
| STRIDE-Kategorie |
DoS (Denial of Service) |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Erschöpfung von Ressourcen:Ein Angreifer lädt 10.000 kleine Dateien hoch, wodurch 10.000 parallele Aufrufe von Cloud Run Functions ausgelöst werden, die das CPU-Kontingent, den Arbeitsspeicher oder die Ratenbegrenzungen der Downstream-APIs des Projekts erschöpfen. Kostenbasiertes DoS:Der Fan-out löst eine große Anzahl von Ausführungen in einem kostenpflichtigen Dienst aus, was zu einer hohen Rechnung und einer möglichen Kontosperrung führt und den Dienst effektiv verweigert.
|
| Risikominderungsmaßnahmen |
Implementieren Sie strenge Zugriffssteuerungen für Cloud Storage-Buckets, die Workflows auslösen. Wenden Sie das Prinzip der geringsten Berechtigung an, wenn Sie Schreibzugriff auf diese Buckets gewähren, und führen Sie regelmäßig Prüfungen mit Tools wie Policy Analyzer durch. Legen Sie Grenzwerte für die Nebenläufigkeit für ereignisgesteuerte Cloud Run-Funktionen fest, um die maximale Anzahl paralleler Ausführungen zu steuern und so eine Erschöpfung der Ressourcen zu verhindern. Implementieren Sie einen Debouncing-Mechanismus, der dann die Hauptverarbeitungslogik aufruft. Ein Beispiel für einen Debouncing-Mechanismus ist das Hinzufügen einer Aufgabe zu einer Cloud Tasks-Warteschlange mit Ratenbeschränkungen. Dieser Mechanismus trägt dazu bei, plötzliche Anfragespitzen zu bewältigen, indem er sie über einen längeren Zeitraum verteilt. Konfigurieren Sie einen VPC Service Controls-Perimeter, um den Zugriff auf sensible Ressourcen wie das Schreiben in einen Bucket, der einen Workflow auslöst, von außerhalb des vertrauenswürdigen Perimeters einzuschränken.
|
Unautorisierte Datenübertragung mit Sicherungspipelines, die auf Cloud Storage basieren
Tools für Sicherung und Notfallwiederherstellung verwenden Cloud Storage häufig als Stagingbereich oder endgültiges Ziel für Sicherungen. Wenn ein Angreifer die Konfiguration dieser Tools manipuliert, kann er Sicherungen an einen vom Angreifer kontrollierten Cloud Storage-Bucket weiterleiten. Das Sicherungsdienstkonto hat oft umfassende Leseberechtigungen für viele Datenquellen (z. B. Datenbanken oder VMs), sodass der Angreifer große Mengen sensibler Daten exfiltrieren kann, indem er den Zielparameter des Sicherungsjobs manipuliert.
| STRIDE-Kategorie |
Offenlegung von Informationen |
| MITRE ATT&CK-Taktik |
Exfiltration |
| Manifestationen |
Umleitung von Sicherungsjobs:Ein Angreifer mit Berechtigungen zum Bearbeiten einer Sicherungsjobkonfiguration ändert den Zielpfad des Cloud Storage-Bucket in gs://attacker-public-bucket/. Projektübergreifende Sicherung: Der Angreifer konfiguriert in einem kompromittierten Projekt einen neuen Sicherungsjob, um Daten aus einer vertraulichen Quelle zu lesen und in einem Bucket in einem anderen, vom Angreifer kontrollierten Google Cloud-Projekt zu sichern.
|
| Risikominderungsmaßnahmen |
Achten Sie darauf, dass die Dienstkonten des Sicherungstools Berechtigungen mit engem Umfang haben. Richten Sie Sicherungstools so ein, dass sie nur in bestimmte, dafür vorgesehene Sicherungs-Buckets schreiben und nicht von beliebigen Speicherorten lesen können. Mit VPC Service Controls können Sie verhindern, dass Sicherungsdienste auf vertrauliche Datenquellen zugreifen und in Cloud Storage-Buckets außerhalb eines sicheren Perimeters schreiben.
|
Richtlinienumgehung durch die Verwendung von Legacy-Cloud Storage-ACLs in Hybridumgebungen
Cloud Storage unterstützt zwei sich gegenseitig ausschließende Zugriffssteuerungssysteme: IAM und herkömmliche ACLs. Wenn der einheitliche Zugriff auf Bucket-Ebene deaktiviert ist, werden beide Systeme ausgewertet. Ein Angreifer kann diese Konfiguration ausnutzen, indem er einem Objekt eine alte ACL hinzufügt, z. B. um einem privaten Google-Konto oder einer öffentlichen Gruppe Zugriff zu gewähren, auch wenn die Richtlinie „Zulassen“ auf Bucket-Ebene restriktiv erscheint. Bei diesem Angriff wird ein Schattenzugriffspfad erstellt, der von IAM-zentrierten Sicherheitsscannern oft übersehen wird. So kann der Angreifer die beabsichtigten Sicherheitsrichtlinien umgehen.
| STRIDE-Kategorie |
Rechteausweitung |
| MITRE ATT&CK-Taktik |
Umgehung von Abwehrmaßnahmen |
| Manifestationen |
Öffentlicher Zugriff auf Objektebene:Ein Angreifer mit der Berechtigung storage.objects.update fügt einem vertraulichen Objekt eine ACL mit öffentlichem Lesezugriff hinzu. Dadurch ist das Objekt für alle Nutzer im Internet zugänglich und eine restriktive Bucket-Zulassungsrichtlinie wird umgangen. Kontoübergreifender Zugriff:Ein Angreifer weist seinem externen Konto mit einer ACL die Berechtigung OWNER für ein wichtiges Konfigurationsobjekt zu. So kann er das Objekt ändern, ohne dass dies von IAM-Prüfungen erkannt wird.
|
| Risikominderungsmaßnahmen |
Aktivieren Sie den einheitlichen Zugriff auf Bucket-Ebene für alle Cloud Storage-Buckets. Durch den einheitlichen Zugriff auf Bucket-Ebene werden alle ACLs deaktiviert und IAM ist die einzige und einheitliche Methode zum Verwalten des Zugriffs. Das vereinfacht Audits und verhindert diesen Bypass. Mit der Einschränkung für Organisationsrichtlinien constraints/storage.uniformBucketLevelAccess können Sie einen einheitlichen Zugriff auf Bucket-Ebene für alle neuen Buckets in einem Projekt, Ordner oder einer Organisation erzwingen.
|
Datenvernichtung durch kompromittierte CI/CD-Pipelines, die auf Cloud Storage ausgerichtet sind
CI/CD-Pipelines werden häufig Dienstkonten mit sehr hohen Berechtigungen zugewiesen, um die Infrastruktur zu verwalten und Artefakte bereitzustellen. Wenn ein Angreifer das CI/CD-System manipuliert, kann er das Dienstkonto der Pipeline verwenden, um schädliche Aktionen in Cloud Storage auszuführen. Ein Beispiel für eine Manipulation ist, wenn ein Angreifer schädlichen Code in ein Build-Script einschleust oder Zugriff auf den Orchestrator erhält. Dazu kann es gehören, dass Buckets gelöscht oder wichtige Objekte überschrieben werden.
| STRIDE-Kategorie |
Manipulation |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Schadhaftes Build-Schritt:Ein Angreifer fügt einer CI/CD-Pipeline einen Schritt hinzu, der alle Daten löscht. Der Angreifer fügt beispielsweise in cloudbuild.yaml einen Schritt hinzu, in dem ein Befehl wie gcloud storage rm -r gs://critical-bucket/ ausgeführt wird. Berechtigungsübernahme:Der Angreifer verwendet das Dienstkonto der manipulierten Pipeline, das umfassende Berechtigungen hat, um seinem eigenen Konto Administratorzugriff auf Cloud Storage-Buckets für die spätere Verwendung zu gewähren.
|
| Risikominderungsmaßnahmen |
Wenden Sie das Prinzip der geringsten Berechtigung auf CI/CD-Dienstkonten an. Weisen Sie einer Build-Pipeline beispielsweise keine Berechtigungen zum Löschen von Produktions-Buckets zu. Verwenden Sie separate Identitäten für verschiedene Pipelinephasen wie Build, Test oder Bereitstellung. Schützen Sie wichtige Cloud Storage-Buckets vor dem Löschen, indem Sie die Bucket-Sperre oder die Objektsperre aktivieren oder dafür sorgen, dass das CI/CD-Dienstkonto nicht die Berechtigung storage.buckets.delete hat.
|
Unautorisiertes Löschen von Buckets mit überprivilegierten Break-Glass-Konten
Break-Glass- oder Notfallzugriffskonten sind Identitäten mit sehr hohen Berechtigungen, die nur im Notfall verwendet werden. Wenn diese Konten nicht ordnungsgemäß gesichert und verwaltet werden (z. B. wenn Anmeldedaten weitergegeben werden oder der Zugriff nicht zeitlich begrenzt ist), kann ein Angreifer, der ein Break-Glass-Konto kompromittiert, sehr schädliche Aktionen ausführen. Ein primäres Risiko ist das Löschen ganzer Cloud Storage-Buckets, was zu katastrophalen, irreversiblen Datenverlusten führen kann, da das Löschen von Buckets eine endgültige Aktion ist.
| STRIDE-Kategorie |
Rechteausweitung |
| MITRE ATT&CK-Taktik |
Rechteausweitung |
| Manifestationen |
Katastrophaler Datenverlust:Ein Angreifer manipuliert ein schlecht verwaltetes Break-Glass-Konto und führt ein Skript aus, um alle Cloud Storage-Buckets in einem Projekt zu löschen. Erpressung:Ein Angreifer verschafft sich Zugriff und droht, kritische Buckets zu löschen, wenn kein Lösegeld gezahlt wird.
|
| Risikominderungsmaßnahmen |
Implementieren Sie für Break-Glass-Verfahren JIT-Zugriff (Just-in-Time) anstelle von Konten mit dauerhaften Berechtigungen. Berechtigungen bei Bedarf für einen begrenzten Zeitraum und für einen bestimmten Zweck erteilen. Wenden Sie eine Bucket-Sperre auf Buckets an, die wichtige Objekte enthalten, oder eine Objektsperre auf einzelne Objekte. Sperren verhindern das Löschen des Buckets und seiner Objekte für einen bestimmten Aufbewahrungszeitraum, auch durch Nutzer mit Inhaberberechtigungen.
|
Stille Daten-Exfiltration über kompromittierte Logsenken, die in Cloud Storage schreiben
Cloud Logging kann so konfiguriert werden, dass Logs in einen Cloud Storage-Bucket exportiert werden. Wenn ein Angreifer Berechtigungen zum Ändern einer Logging-Senke erhält, kann er sie so neu konfigurieren, dass vertrauliche Logs in einen vom Angreifer kontrollierten Cloud Storage-Bucket in einem anderen Projekt exportiert werden. Durch den Export sensibler Logs kann ein Angreifer vertrauliche Daten, die in Logs erfasst werden, unbemerkt und kontinuierlich exfiltrieren.
| STRIDE-Kategorie |
Offenlegung von Informationen |
| MITRE ATT&CK-Taktik |
Exfiltration |
| Manifestationen |
Umleitung von Logs: Ein Angreifer ändert das Zielattribut einer vorhandenen Logsenke, sodass es auf seinen eigenen Cloud Storage-Bucket verweist. Erstellung schädlicher Filter:Ein Angreifer erstellt ein Senken-Sink mit einem Filter, der speziell auf Logs mit vertraulichen Informationen (z. B. personenidentifizierbare Informationen oder Tokens) ausgerichtet ist, und exportiert sie.
|
| Risikominderungsmaßnahmen |
Cloud-Audit-Logs für CreateSink- und UpdateSink-API-Aufrufe überwachen. Konfigurieren Sie Benachrichtigungen, um Sicherheitsteams über neue oder geänderte Logsenken zu informieren, damit sie autorisiert werden. VPC Service Controls-Perimeter konfigurieren, um Daten-Exfiltration zu verhindern
|
Aktivierung von Ransomware durch zentralen CMEK-Widerruf
Wenn Cloud Storage-Buckets mit CMEK verschlüsselt werden, hängt die Verfügbarkeit der Daten von der Verfügbarkeit des Schlüssels ab. Ein Angreifer, der ausreichende Berechtigungen für Cloud KMS erhält, kann den Schlüssel, der für einen wichtigen Cloud Storage-Bucket verwendet wird, löschen oder deaktivieren. Durch diese Aktion werden alle Daten im Bucket kryptografisch unzugänglich gemacht. Das ist im Grunde eine Form der Datenvernichtung oder Ransomware, da die Daten zwar erhalten bleiben, aber nicht entschlüsselt werden können.
| STRIDE-Kategorie |
Manipulation |
| MITRE ATT&CK-Taktik |
Auswirkungen |
| Manifestationen |
Löschen von Schlüsseln:Ein Angreifer mit der Berechtigung cloudkms.cryptoKeyVersions.destroy löscht eine Schlüsselversion dauerhaft, sodass die Daten nicht wiederhergestellt werden können. Deaktivierung von Schlüsseln:Ein Angreifer mit der Berechtigung cloudkms.cryptoKeyVersions.disable deaktiviert einen Schlüssel. Dadurch werden die Cloud Storage-Daten unlesbar, bis der Schlüssel wieder aktiviert wird. Diese Aktion kann zu einem längeren Ausfall führen.
|
| Risikominderungsmaßnahmen |
Erzwingen Sie eine Mindestdauer für den Status „Zum Löschen vorgemerkt“, bevor Cloud KMS-Schlüssel gelöscht werden können. Standardmäßig beträgt dieser Zeitraum 30 Tage. Sie können jedoch beim erstmaligen Erstellen eines Schlüssels einen Zeitraum von 1 bis 120 Tagen konfigurieren. Dieser Zeitraum kann nach dem Löschen eines Schlüssels nicht mehr geändert werden. Sie können die Einschränkung constraints/cloudkms.minimumDestroyScheduledDuration der Organisationsrichtlinie erzwingen, um sicherzustellen, dass keine Schlüssel mit einer Dauer des Status „Zum Löschen vorgemerkt“ erstellt werden können, die unter dem erwarteten Mindestwert liegt. Zugriff auf Cloud KMS-Administratorrollen streng einschränken Trennen Sie die Aufgaben der Schlüsselnutzung von der Schlüsselverwaltung, um zu verhindern, dass mit einem einzelnen kompromittierten Konto sowohl Schlüssel verwendet als auch zerstört werden können. Rotieren Sie Cloud KMS-Schlüssel regelmäßig. Wählen Sie einen Rotationszeitraum basierend auf den Vertraulichkeits- oder Compliance-Anforderungen Ihrer Arbeitslast aus.
|
Daten-Exfiltration über Snapshot- oder Back-up-Exporte nach Cloud Storage
Viele Google Cloud-Dienste (z. B. Compute Engine oder Cloud SQL) ermöglichen das Erstellen von Snapshots oder das Exportieren von Sicherungen nach Cloud Storage. Ein Angreifer mit Berechtigungen zum Ausführen dieser Exportvorgänge kann einen Snapshot einer Ressource mit vertraulichen Daten erstellen und den Snapshot in einem Cloud Storage-Bucket mit laxen Berechtigungen speichern, z. B. in einem öffentlichen Bucket oder einem Bucket, der für ein externes Konto freigegeben ist. Bei dieser Aktion werden die strengeren Zugriffssteuerungen der primären Ressource (z. B. Datenbankanmeldedaten) umgangen, da die Daten jetzt über Cloud Storage IAM zugänglich sind.
| STRIDE-Kategorie |
Offenlegung von Informationen |
| MITRE ATT&CK-Taktik |
Exfiltration |
| Manifestationen |
Laufwerksnapshot in öffentlichen Bucket: Ein interner Entwickler mit den Berechtigungen compute.snapshots.create und storage.objectAdmin erstellt einen Snapshot eines VM-Laufwerks, das Secrets enthält, und exportiert ihn in einen öffentlichen Cloud Storage-Bucket. Datenbankexport:Ein Angreifer mit der Berechtigung cloudsql.instances.export exportiert eine Produktionsdatenbank in einen Cloud Storage-Bucket in einem vom Angreifer kontrollierten Projekt.
|
| Maßnahmen zur Risikominderung |
Achten Sie darauf, dass Projekte, die für Back-ups und Snapshots vorgesehen sind, IAM- und VPC Service Controls-Richtlinien haben, die mindestens so streng wie die Quellprojekte sind, um ein einheitliches Sicherheitsniveau zu gewährleisten. Erwägen Sie eine Datenklassifizierungsstrategie, bei der Sie Ressourcentags für Buckets konfigurieren, die für Back-ups verwendet werden, und IAM-Zugriffsbedingungen auf Grundlage von Tags hinzufügen, um den Zugriff weiter einzuschränken.
|
