BigQuery-Bedrohungsmodellbericht

Zuletzt aktualisiert: 16. April 2026

In diesem Dokument werden potenzielle Angriffsvektoren und Risikominderungsstrategien für die Vertraulichkeit, Integrität und Verfügbarkeit von Daten für BigQuery beschrieben. Der Umfang dieses Berichts ist auf Ihre Perspektive beschränkt und konzentriert sich auf Risiken, die Sie in Ihrer BigQuery-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.

Datenvernichtung durch Manipulation des Schemas

Ein Angreifer mit Berechtigungen zum Ändern des Schemas einer Tabelle kann potenziellen Datenverlust verursachen oder die Tabelle für nachgelagerte Anwendungen unbrauchbar machen. Bei dieser Form der Manipulation werden die Metadaten und die Struktur der Daten manipuliert, was genauso schädlich sein kann wie die Änderung der Daten selbst.

STRIDE-Kategorie

Manipulation
MITRE ATT&CK-Taktik

Auswirkungen
Manifestationen

Schadhaftes Schema-Update:Ein Prinzipal mit der Berechtigung bigquery.tables.update kann die API-Methode tables.patch für eine BigQuery-Tabelle aufrufen, um ihr Schema zu ändern. Wenn Sie Datentypen von Spalten ändern, können Daten beschädigt werden oder Informationen verloren gehen. Dadurch können Abfragen aus Clientanwendungen oder Business Intelligence-Tools fehlschlagen, was zu einem Vertrauensverlust bei nachgelagerten Berichten führt.
Maßnahmen zur Risikominderung

Beschränken Sie die Berechtigung bigquery.tables.update, die Teil von Rollen wie roles/bigquery.dataOwner ist, auf das unbedingt erforderliche Maß. Gewähren Sie diese Berechtigung nur einer kleinen Anzahl von Administratoren oder automatisierten CI/CD-Dienstkonten, die für die Migrationen verwalteter Schemas verantwortlich sind. Aktivieren Sie BigQuery-Tabellensicherungen oder verwenden Sie Tabellen-Snapshots, um versehentliche oder böswillige Schemaänderungen rückgängig zu machen. Überwachen Sie Cloud-Audit-Logs auf tables.patch-API-Aufrufe und lassen Sie sich benachrichtigen, wenn Änderungen außerhalb eines geplanten Wartungsfensters vorgenommen werden.

Rechteausweitung durch Manipulation von IAM-Zulassungsrichtlinien

Ein Angreifer, der ein Konto mit Berechtigungen zum Ändern von BigQuery-IAM-Zulassungsrichtlinien kompromittiert, kann seine Berechtigungen eskalieren, um die vollständige Kontrolle über Datenressourcen zu erlangen. Bei dieser Bedrohung kann der Angreifer Zugriff zum Lesen, Ändern oder Löschen sensibler Daten gewähren und so vorhandene Zugriffssteuerungen umgehen.

STRIDE-Kategorie

Rechteausweitung
MITRE ATT&CK-Taktik

Rechteausweitung
Manifestationen

  • Änderung der Dataset-Richtlinie:Ein Prinzipal mit der Berechtigung bigquery.datasets.update kann die API-Methode datasets.patch für ein BigQuery-Dataset aufrufen, um seine eigene Identität einer Inhaberrolle hinzuzufügen. Dadurch erhält er die vollständige Kontrolle über alle Ressourcen in diesem Dataset.

  • Identitätsübernahme des Dienstkontos:Eine Identität mit der Berechtigung iam.serviceAccounts.actAs für ein Dienstkonto kann das Dienstkonto an andere Ressourcen wie eine Compute Engine-Instanz anhängen, um Code mit der Identität des angehängten Dienstkontos auszuführen. Alternativ kann eine Identität mit der Berechtigung iam.serviceAccounts.getAccessToken Zugriffstokens für dieses Dienstkonto generieren. Wenn das Zieldienstkonto erweiterte Berechtigungen für BigQuery-Ressourcen hat, übernimmt der Angreifer diese Berechtigungen.
Maßnahmen zur Risikominderung

Beschränken Sie Berechtigungen, die die Änderung von IAM-Zulassungsrichtlinien ermöglichen, z. B. bigquery.datasets.update, die Teil von Rollen wie roles/bigquery.dataOwner ist. Weisen Sie diese Rollen nur einer Mindestanzahl vertrauenswürdiger Administratoren zu. Kontrollieren Sie auch die IAM-Rollen mit der Berechtigung, als Dienstkonten zu agieren oder sich als Dienstkonten auszugeben, und beschränken Sie diese Rollen auf bestimmte Principals, die sie benötigen. Überwachen Sie Cloud-Audit-Logs auf SetIamPolicy- und datasets.patch-API-Aufrufe, um unautorisierte Richtlinienänderungen zu erkennen.

Missbrauch von „Confused Deputy“ durch nachgelagerte Dienste, die durch BigQuery ausgelöst werden

Ein Angreifer mit eingeschränkten BigQuery-Berechtigungen erstellt einen Job oder eine Abfrage, die einen nachgelagerten Dienst (z. B. Cloud Function, Dataflow-Job oder Cloud Composer-DAG) auslöst, der mit höheren Berechtigungen ausgeführt wird. Der nachgelagerte Dienst, der davon ausgeht, dass er eine legitime Aktion im Namen von BigQuery ausführt, wird dazu verleitet, eine Aktion für eine andere Ressource oder mit anderen Daten als von den Systemdesignern beabsichtigt auszuführen.

STRIDE-Kategorie

Rechteausweitung
MITRE ATT&CK-Taktik

Rechteausweitung
Manifestationen

  • Auslösen einer schädlichen Funktion:Eine BigQuery-Änderung löst eine Cloud Function mit umfassenden Berechtigungen aus. Der Angreifer manipuliert die BigQuery-Daten, um die Aktionen der Funktion zu steuern.

  • Ausnutzung von Dataflow-Pipelines:Das Ergebnis einer BigQuery-Abfrage wird als Eingabe für einen Dataflow-Job verwendet und der Angreifer schreibt die Abfrageergebnisse, um den Dataflow-Job zum Aufnehmen von manipulierten Daten zu veranlassen.
Maßnahmen zur Risikominderung

Wenden Sie den Grundsatz der geringsten Berechtigung auf Dienstkonten an, die von Downstream-Diensten verwendet werden, die von BigQuery ausgelöst werden. Prüfen Sie, ob diese Dienste alle Eingaben oder Parameter, die von BigQuery-Jobs empfangen werden, validieren und bereinigen. Mit VPC Service Controls Netzwerkpfade und Dienstinteraktionen einschränken Entwerfen Sie Downstream-Dienste so, dass sie Eingaben aus BigQuery nicht ohne Überprüfung vertrauen.

Daten-Exfiltration über uneingeschränkten ausgehenden Netzwerkverkehr

Wenn keine Sicherheitskontrollen auf Netzwerkebene vorhanden sind, kann ein kompromittierter interner Prinzipal auf BigQuery zugreifen und sensible Daten an einen beliebigen Ort im Internet übertragen. Selbst bei starken IAM-Kontrollen kann ein Angreifer, der gültige Anmeldedaten erhalten hat, ohne Netzwerkperimeter standortbasierte Schutzmaßnahmen umgehen und Daten außerhalb der vertrauenswürdigen Umgebung übertragen.

STRIDE-Kategorie

Offenlegung von Informationen
MITRE ATT&CK-Taktik

Exfiltration
Manifestationen

  • API-Zugriff über nicht vertrauenswürdige Netzwerke:Ein Angreifer verwendet kompromittierte Anmeldedaten, um von einem externen Computer aus eine Verbindung zur öffentlichen BigQuery API oder BigQuery Storage Read API herzustellen. Dabei werden Netzwerksteuerungen umgangen, die für lokale Hosts oder Nutzergeräte konfiguriert sind.

  • In einen externen Google Cloud-Dienst exportieren:Ein manipuliertes Dienstkonto mit bigquery.jobs.create- und Cloud Storage-Berechtigungen führt eine Abfrage aus, mit der Ergebnisse in einen öffentlichen Cloud Storage-Bucket exportiert werden, der nicht der Kontrolle der Organisation unterliegt.
Maßnahmen zur Risikominderung

Implementieren Sie Kontrollen für ausgehenden Netzwerkverkehr, um die Daten-Exfiltration zu beliebigen externen Diensten zu minimieren. Implementieren Sie einen VPC Service Controls-Perimeter für das Projekt, das die BigQuery-Ressourcen enthält. Dieser Perimeter trägt dazu bei, die Daten-Exfiltration auf Google Cloud-Dienste außerhalb des Perimeters zu beschränken. Konfigurieren Sie Zugriffsebenen für den Perimeter so, dass nur API-Anfragen aus vertrauenswürdigen IP-Bereichen oder bestimmten VPC-Netzwerken zugelassen werden. So wird verhindert, dass auf Daten zugegriffen oder Daten außerhalb der definierten Sicherheitsgrenze verschoben werden.

Abweichung der Datenintegrität durch manipulierte Referenz- oder Nachschlagetabellen

Ein Angreifer mit Schreibzugriff auf Referenz- oder Suchtabellen (z. B. Dimensionstabellen) ändert deren Inhalt auf subtile Weise. Abfragen, die mit diesen manipulierten Tabellen verknüpft werden, liefern falsche, irreführende Ergebnisse, die die Integrität von Analysen und Geschäftsentscheidungen beeinträchtigen, möglicherweise ohne dass offensichtliche Fehler auftreten.

STRIDE-Kategorie

Manipulation
MITRE ATT&CK-Taktik

Auswirkungen
Manifestationen

  • Bearbeitung von Dimensionstabellen:Ändern von Schlüsselwerten oder Attributen in einer Produktdimensionstabelle.

  • Beschädigung von Lookups:Ändern von Zuordnungsdaten in einer Lookup-Tabelle.
Maßnahmen zur Risikominderung

Beschränken Sie den Schreibzugriff (bigquery.tables.updateData) auf Referenz- oder Suchtabellen streng auf vertrauenswürdige Prozesse zur Datenaufnahme. Implementieren Sie Datenqualitätsprüfungen und Validierungspipelines. Verwenden Sie Tabellen-Snapshots oder die Versionsverwaltung, um Änderungen nachzuverfolgen und Rollbacks zu ermöglichen. Überwachen Sie die Audit-Logs auf Änderungen an diesen wichtigen Tabellen.

Datenmanipulation durch schädliche Ladejobs

Ein Angreifer mit ausreichenden Berechtigungen kann kritische Daten in einer BigQuery-Tabelle durch Ausführen eines schädlichen Ladejobs absichtlich beschädigen oder überschreiben. Diese Bedrohung gefährdet die Integrität der Daten, was zu falschen Geschäftsanalysen, Anwendungsfehlern und einem Vertrauensverlust bei den Kunden führen kann.

STRIDE-Kategorie

Manipulation
MITRE ATT&CK-Taktik

Auswirkungen
Manifestationen

  • Tabellenüberschreibung:Ein Prinzipal mit bigquery.jobs.create und bigquery.tables.updateData initiiert einen Ladejob, bei dem die Schreibanordnung auf WRITE_TRUNCATE festgelegt ist. Dadurch werden alle vorhandenen Daten gelöscht und durch schädliche Daten aus einer externen Quelle ersetzt.

  • Bösartiges Anhängen von Daten:Ein Angreifer verwendet einen Ladejob mit WRITE_APPEND, um ungültige oder bösartige Daten in eine vorhandene Tabelle einzufügen. Dadurch werden Analysen beschädigt, ohne dass Originaldatensätze gelöscht werden.
Abhilfemaßnahmen

Wenden Sie das Prinzip der geringsten Berechtigung an. Berechtigungen wie bigquery.jobs.create und bigquery.tables.updateData (in Rollen wie roles/bigquery.dataEditor) sollten nur vertrauenswürdigen Prinzipalen gewährt und auf bestimmte Datasets oder Tabellen beschränkt werden. Überwachen Sie Cloud-Audit-Logs auf den Abschluss von Load-Jobs, insbesondere solche mit der Disposition WRITE_TRUNCATE, und erstellen Sie Benachrichtigungen für Jobs, die von unerwarteten Nutzern stammen oder Daten aus nicht vertrauenswürdigen Quellen laden.

Übermäßige IAM-Berechtigungen, die zur Offenlegung von Informationen führen

IAM-Rollen mit zu vielen Berechtigungen können übermäßigen Zugriff auf sensible Daten ermöglichen, die in BigQuery-Tabellen gespeichert sind. Ein Angreifer, der einen Prinzipal mit umfassenden Datenzugriffsberechtigungen kompromittiert, kann große Datenmengen exfiltrieren, was zu einer erheblichen Datenpanne führt. Diese Bedrohung wird realisiert, wenn Berechtigungen wie bigquery.tables.getData oder bigquery.jobs.create in einem weiten Bereich (z. B. auf Projektebene) gewährt werden, anstatt auf bestimmte Datasets oder Tabellen beschränkt zu sein, die für eine Geschäftsfunktion erforderlich sind.

STRIDE-Kategorie

Offenlegung von Informationen
MITRE ATT&CK-Taktik

Exfiltration
Manifestationen

  • Direktes Lesen von Daten:Ein Prinzipal mit der Berechtigung bigquery.tables.getData kann Daten direkt aus Tabellen lesen. Dazu kann er die API-Methode tabledata.list oder die BigQuery Storage Read API mit hohem Durchsatz verwenden.

  • Abfragebasierte Exfiltration:Ein Prinzipal mit der Berechtigung bigquery.jobs.create kann einen Abfragejob mit jobs.insert oder jobs.query ausführen, um Daten aus einer beliebigen Tabelle zu lesen, auf die er Zugriff hat, und die Ergebnisse dann mit jobs.getQueryResults abrufen.

  • Öffentliche Zugänglichkeit:Eine IAM-Allow-Richtlinie für ein BigQuery-Dataset oder eine BigQuery-Tabelle kann so konfiguriert werden, dass öffentlicher Zugriff möglich ist. Dazu werden Rollen an spezielle Hauptkonten wie allUsers oder allAuthenticatedUsers gewährt, wodurch Daten im Internet verfügbar gemacht werden.
Maßnahmen zur Risikominderung

Implementieren Sie das Prinzip der geringsten Berechtigung für alle IAM-Zulassungsrichtlinien. Gewähren Sie Berechtigungen auf der detailliertesten erforderlichen Ebene, z. B. für bestimmte BigQuery-Tabellen oder ‑Datasets, anstatt auf Projektebene. Verwenden Sie IAM-Rollen mit der geringsten Berechtigung, die nur die erforderlichen Berechtigungen für bestimmte Aufgaben enthalten, z. B. bigquery.tables.getData und bigquery.jobs.create. Prüfen Sie regelmäßig IAM-Zulassungsrichtlinien auf zu permissive Rollen wie roles/bigquery.dataViewer oder roles/bigquery.user, die auf einer hohen Ebene in der Ressourcenhierarchie angewendet werden.

Exfiltration durch Übertragung an ein von Angreifern kontrolliertes Cloud-Projekt oder -Konto

Ein Angreifer nutzt die Datenübertragungsfunktionen von BigQuery (z. B. Exportjobs in Cloud Storage, projektübergreifende Abfragen, BigQuery Data Transfer Service), um vertrauliche Daten aus dem gesicherten Projekt in ein Google Cloud-Projekt oder ein anderes Cloud-Konto zu übertragen, das unter seiner Kontrolle steht.

STRIDE-Kategorie

Offenlegung von Informationen
MITRE ATT&CK-Taktik

Exfiltration
Manifestationen

  • In externen Bucket exportieren:Mit einem Exportjob werden Tabellendaten in einem Cloud Storage-Bucket im Projekt eines Angreifers gespeichert.

  • Ziel für projektübergreifende Abfragen:Eine Abfrage wird ausgeführt und die Zieltabelle wird auf ein Dataset in einem vom Angreifer kontrollierten Projekt festgelegt.
Maßnahmen zur Risikominderung

Implementieren Sie VPC Service Controls, um einen Perimeter für das Projekt zu erstellen und so den Daten-Egress zu Projekten außerhalb des Perimeters zu verhindern. Berechtigungen wie bigquery.tables.export und bigquery.jobs.create sollten streng kontrolliert werden. Mit Einschränkungen für Organisationsrichtlinien können Sie die Projektfreigabe und ‑erstellung einschränken. Überwachen Sie Cloud-Audit-Logs auf Exportjobs oder Abfragen mit Zielen außerhalb der erwarteten Projektgrenzen.

Offenlegung von Informationen durch falsch konfigurierte autorisierte Ansichten oder Logik für die Sicherheit auf Zeilenebene

Fehler in der SQL-Logik von autorisierten Ansichten oder Sicherheitsrichtlinien auf Zeilenebene führen zu einem umfassenderen Datenzugriff als beabsichtigt. Nutzer, die die Ansicht oder Tabelle abfragen, können versehentlich auf Zeilen oder Spalten zugreifen, die sie nicht sehen sollten, und so die beabsichtigte Trennung umgehen.

STRIDE-Kategorie

Offenlegung von Informationen
MITRE ATT&CK-Taktik

Sammlung
Manifestationen

  • Fehlerhafte Ansichtslogik:In der Abfrage einer autorisierten Ansicht werden erforderliche WHERE-Klauseln ausgelassen, die in Richtlinien zur Sicherheit auf Zeilenebene für die Basistabelle vorhanden sind.

  • Umgehung der Sicherheit auf Zeilenebene:Eine komplexe Richtlinie zur Sicherheit auf Zeilenebene enthält einen logischen Fehler, der einen umfassenderen Zugriff als beabsichtigt ermöglicht.
Maßnahmen zur Risikominderung

Implementieren Sie einen strengen Code-Review-Prozess für die SQL-Logik, die in autorisierten Ansichten und Richtlinien für die Sicherheit auf Zeilenebene verwendet wird. Sicherheitslogik gründlich testen Beschränken Sie Berechtigungen (z. B. bigquery.tables.create, bigquery.tables.update oder bigquery.rowAccessPolicies.create), um Ansichten und Richtlinien für die Sicherheit auf Zeilenebene zu erstellen oder zu aktualisieren. Überprüfen Sie regelmäßig vorhandene Ansichten und Konfigurationen für die Sicherheit auf Zeilenebene. Beachten Sie die Best Practices für die Sicherheit auf Zeilenebene.

Offenlegung von Informationen durch öffentliche oder projektübergreifende Datasets

Vertrauliche Daten werden offengelegt, weil BigQuery-Datasets versehentlich oder böswillig öffentlich gemacht werden (z. B. mit „allUsers“ oder „allAuthenticatedUsers“) oder zu weit mit anderen Google Cloud-Projekten außerhalb der beabsichtigten Vertrauensgrenze geteilt werden. Ein Angreifer kann ohne Authentifizierung oder mit einem beliebigen authentifizierten Google-Konto direkt auf die Daten zugreifen oder sie kopieren.

STRIDE-Kategorie

Offenlegung von Informationen
MITRE ATT&CK-Taktik

Exfiltration
Manifestationen

  • Öffentliches Dataset:Eine IAM-Zulassungsrichtlinie für ein Dataset gewährt allUsers die Berechtigungen des Betrachters.

  • Projektübergreifende Überfreigabe:Ein Dataset wird für eine externe Organisation oder ein Dienstkonto in einem nicht vertrauenswürdigen Projekt freigegeben.
Maßnahmen zur Risikominderung

Das Prinzip der geringsten Berechtigung für IAM-Zulassungsrichtlinien für Datasets implementieren. Mit Organisationsrichtlinien wie constraints/iam.allowedPolicyMemberDomains können Sie die Freigabe auf bestimmte Domains beschränken. Prüfen Sie regelmäßig die IAM-Zulassungsrichtlinien für Datasets mit Security Command Center, um öffentliche oder zu weit gefasste Berechtigungen zu erkennen. Verwenden Sie VPC Service Controls, um Perimeter für Projekte mit vertraulichen Daten zu erstellen und so unbefugten ausgehenden Traffic zu verhindern.

Missbrauch des autorisierten BigQuery-Zugriffs durch Insider (legitime Abfragen für böswillige Datenerhebung)

Ein böswilliger Insider mit legitimem Zugriff auf BigQuery nutzt seine autorisierten Berechtigungen, um Abfragen auszuführen und vertrauliche Daten für unbefugte Zwecke zu erheben (z. B. persönliche Bereicherung oder Spionage). Obwohl der Zugriff autorisiert ist, sind die Absicht und die Verwendung der Daten böswillig.

STRIDE-Kategorie

Offenlegung von Informationen
MITRE ATT&CK-Taktik

Sammlung
Manifestationen

  • Datensammeln:Regelmäßiges Abfragen und Herunterladen von Kundendaten, die über die Jobanforderungen hinausgehen.

  • Vertrauliche Analyse:Analysen durchführen, um Geschäftsgeheimnisse oder personenbezogene Daten für die Exfiltration zu extrahieren.
Maßnahmen zur Risikominderung

Aktivieren und überwachen Sie Audit-Logs zum Datenzugriff, um Datenzugriffsmuster zu verfolgen. Verwenden Sie Tools wie Sensitive Data Protection, um Abfrageergebnisse auf sensible Informationen zu prüfen. Implementieren Sie die Analyse des Nutzerverhaltens (User Behavior Analytics, UBA), um anomale Abfragemuster oder Datenzugriffsvolumina zu erkennen. Setzen Sie klare Richtlinien für die Datenverarbeitung durch und bieten Sie Schulungen zur Sensibilisierung für Sicherheit an. Mit der Sicherheit auf Zeilen- und Spaltenebene können Sie die Datenexposition auch für autorisierte Nutzer einschränken.

Persistenz durch unauffällige BigQuery-IAM-Bindungen für Datasets, autorisierte Ansichten oder geplante Abfragen

Ein Angreifer, der sich anfänglich Zugriff verschafft hat, schafft eine langfristige Präsenz, indem er schwer zu erkennende Zugriffsmechanismen in BigQuery erstellt. Diese Bedrohung umfasst das Hinzufügen von IAM-Bindungen zu Datasets, das Erstellen autorisierter Ansichten, mit denen sensible Daten abgefragt werden, oder das Einrichten geplanter Abfragen, die unter einem privilegierten Dienstkonto ausgeführt werden, um Daten zu exfiltrieren oder den Zugriff aufrechtzuerhalten.

STRIDE-Kategorie

Rechteausweitung
MITRE ATT&CK-Taktik

Persistenz
Manifestationen

  • IAM für verborgenes Dataset:Einem persönlichen Konto werden Betrachterrechte für ein bestimmtes, weniger überwachtes Dataset gewährt.

  • Hintertür über autorisierte Ansicht:Erstellen einer Ansicht, die auf eine eingeschränkte Tabelle zugreifen darf, und Gewähren des Zugriffs auf die Ansicht.

  • Schadsoftware in geplanter Abfrage:Eine geplante Abfrage wird so konfiguriert, dass Daten regelmäßig an einen externen Speicherort kopiert werden.
Abhilfemaßnahmen

Prüfen Sie regelmäßig alle IAM-Zulassungsrichtlinien, einschließlich Berechtigungen auf Dataset-Ebene, mit Tools wie Security Command Center. Berechtigungen zum Erstellen oder Aktualisieren von Datasets (bigquery.datasets.update), Routinen (bigquery.routines.create/update) und Datenübertragungen (bigquery.transfers.update) lassen sich genau steuern.

Spoofing mit kompromittierten Dienstkonto-Anmeldedaten oder OAuth-Tokens, die für den BigQuery-Zugriff verwendet werden

Ein Angreifer erhält Anmeldedaten für das Dienstkonto (z. B. exportierte JSON-Schlüssel) und verwendet sie, um sich als das kompromittierte Dienstkonto bei BigQuery zu authentifizieren. Dabei werden alle Berechtigungen des Dienstkontos übernommen. Bei dieser Bedrohung kann der Angreifer alle Aktionen ausführen, für die das Dienstkonto autorisiert ist, z. B. Daten lesen, Jobs ausführen oder Ressourcen ändern.

STRIDE-Kategorie

Spoofing
MITRE ATT&CK-Taktik

Eindringen ins Netzwerk oder System
Manifestationen

  • Offengelegter Dienstkontoschlüssel:Eine JSON-Schlüsseldatei wird in Code-Repositories, öffentlichem Speicher oder Instanzmetadaten offengelegt.

  • Manipulierte Anwendung:Eine Anwendung, die ein Dienstkonto verwendet, wird manipuliert. Der Angreifer kann die Anmeldedaten extrahieren und verwenden.

  • Gestohlenes OAuth-Token:Ein Angreifer fängt ein OAuth-Token von einer Clientanwendung oder Browsersitzung ab oder es wird offengelegt.

  • Token mit zu vielen Bereichen:Eine Anwendung fordert Token mit zu vielen Bereichen an und speichert sie (z. B. vollständiger BigQuery-Zugriff, wenn nur Lesezugriff erforderlich ist).
Maßnahmen zur Risikominderung

Vermeiden Sie den Export von Dienstkontoschlüsseln. Verwenden Sie stattdessen nach Möglichkeit angehängte Dienstkonten oder die Workload Identity Federation. Wenn Schlüssel erforderlich sind, rotieren Sie sie regelmäßig und gewähren Sie dem Dienstkonto nur die erforderlichen Mindestberechtigungen. Überwachen Sie Cloud-Audit-Logs und Security Command Center auf anomale Dienstkontoaktivitäten oder die Offenlegung von Schlüsseln. Verwenden Sie die Einschränkung für die Organisationsrichtlinie constraints/iam.disableServiceAccountKeyCreation, um das Erstellen von Dienstkontoschlüsseln zu deaktivieren. OAuth-Tokens sicher speichern und übertragen. Halten Sie sich an die Best Practices für OAuth 2.0. Fordern Sie nur die erforderlichen Bereiche an. Verwenden Sie kurzlebige Tokens und Aktualisierungstokens sicher. Implementieren Sie Mechanismen zum Erkennen und Widerrufen kompromittierter Tokens. Anomale Muster bei der Tokennutzung überwachen. Führen Sie die Standardschutzmaßnahmen für Dienstkontoschlüssel aus. Konfigurieren Sie die Sitzungslänge für Google Cloud-Dienste, um kurzlebige Tokens zu erzwingen und das Risiko eines geleakten Tokens zu minimieren.

Kostenbasierter Denial-of-Service durch teure Anfragen

Ein authentifizierter Prinzipal führt Abfragen aus, die darauf ausgelegt sind, übermäßig viele BigQuery-Ressourcen (z. B. Slots und gescannte Byte) zu verbrauchen. Diese Bedrohung kann zu massiven Kostenüberschreitungen bei On-Demand-Projekten oder zu Slot-Engpässen für andere Nutzer bei reservierungsbasierten Projekten führen und den Geschäftsbetrieb beeinträchtigen.

STRIDE-Kategorie

DoS (Denial of Service)
MITRE ATT&CK-Taktik

Auswirkungen
Manifestationen

  • Nicht optimierte Abfragen:Ausführen von Abfragen mit Cross Joins für große Tabellen ohne Filter.

  • Wiederholte Ausführung:Skripting für die häufige Ausführung kostspieliger Abfragen.
Abhilfemaßnahmen

Mit benutzerdefinierten BigQuery-Kontingenten können Sie Nutzer- und Projektlimits für die Abfragenutzung festlegen, z. B. für die Anzahl der gescannten Byte pro Tag. Verwenden Sie den Parameter maximumBytesBilled in Abfragejobs. Verwenden Sie BigQuery-Reservierungen, um Arbeitslasten zu isolieren und Kapazität zu garantieren. Konfigurieren Sie Abrechnungsbenachrichtigungen in Cloud Billing und beobachten Sie die Slot-Auslastung in Cloud Monitoring, um Anomalien zu erkennen und darauf zu reagieren.