OWASP Top 10:2025 in Google Cloud mindern

In diesem Dokument werden die Google Cloud -Dienste und Strategien zur Schadensminderung beschrieben, die Sie vor den in den OWASP Top 10:2025 beschriebenen Angriffen auf Anwendungsebene schützen können. Die Open Web Application Security (OWASP) Foundation hat die OWASP Top 10:2025 erstellt. Diese Liste enthält die zehn größten Sicherheitsrisiken im Software Development Lifecycle (SDLC). Obwohl kein Dienst einen vollständigen Schutz vor diesen Risiken bieten kann, kann die Anwendung dieser Dienste, wenn sie in Ihrer Architektur sinnvoll sind, zu einer starken mehrstufigen Sicherheitslösung beitragen.

Die Google-Infrastruktur wurde entwickelt, um Ihnen beim Erstellen, Bereitstellen und Betreiben von Diensten mit robusten Sicherheitskontrollen zu helfen. Die physische und operative Sicherheit, die Verschlüsselung ruhender Daten und während der Übertragung sowie viele andere grundlegende Infrastrukturschutzmaßnahmen werden von Google verwaltet. Sie erben diese Vorteile, wenn Sie Ihre Anwendungen in Google Cloudbereitstellen. Möglicherweise müssen Sie jedoch zusätzliche Maßnahmen ergreifen, um Ihre Anwendung vor bestimmten Angriffen zu schützen.

Compliance matrix

Die in der folgenden Tabelle aufgeführten Google Cloud -Dienste können Sie vor den Top-10-Sicherheitsrisiken schützen, die in OWASP Top 10:2025 aufgeführt sind:

OWASP Top 10:2025-Kategorie Primäre Google Cloud und Wiz-Steuerung

A01: Fehlerhafte Zugriffssteuerung

Access Context Manager, Agent Gateway, Agent Identity, Apigee, Google Cloud Armor, Firebase App Check, Firebase-Sicherheitsregeln, Cloud Next Generation Firewall (Cloud NGFW), Identity-Aware Proxy (IAP), Identity and Access Management (IAM), Organisationsrichtliniendienst, VPC Service Controls, Wiz Cloud

A02: Sicherheitsfehlkonfiguration

Access Context Manager, Cloud Asset Inventory, Google Security Operations, Organisationsrichtlinie, Security Command Center Premium, VPC Service Controls, Wiz Cloud

A03: Fehler in der Softwarelieferkette

Artifact Registry, Assured Open Source Software (Assured OSS), Binärautorisierung, Cloud Build, Cloud Deploy, Cloud Workstations, CodeMender, Wiz Code

A04: Kryptografische Fehler

Apigee, Certificate Authority Service, Certificate Manager, Cloud Key Management Service, Cloud Load Balancing, Cloud Workstations, Confidential Computing, Organization Policy, Secret Manager, Sensitive Data Protection, Wiz Cloud

A05: Injection

Apigee, Cloud Armor, CodeMender, Firebase-Sicherheitsregeln, Cloud Next Generation Firewall (Cloud NGFW), Model Armor, Security Command Center Premium, VirusTotal, Wiz Code

A06: Unsicheres Design

Apigee, CodeMender, Mandiant, Wiz Cloud

A07: Authentifizierungsfehler

Access Context Manager, Agent Identity, Apigee, Cloud Armor, Cloud Identity, Firebase App Check, Firebase Authentication, Google Cloud Fraud Defense, IAM (Privileged Access Manager, Workload Identity Federation und Workforce Identity Federation), IAP, Identity Platform, Security Command Center Premium, Secret Manager, Titan-Sicherheitsschlüssel, Wiz Code

A08: Software- oder Datenintegritätsfehler

Artifact Analysis, Assured OSS, Binary Authorization, Cloud Armor, Cloud Build, Cloud Deploy, Firebase App Check, Security Command Center Premium, VirusTotal, Wiz Defend

A09: Fehler beim Sicherheits-Logging und bei Sicherheitsbenachrichtigungen

Access Approval und Access Transparency, Apigee, Google SecOps, Cloud Logging, Cloud Monitoring, Sensitive Data Protection, Wiz Defend

A10: Falsche Handhabung von Ausnahmesituationen

Cloud Armor, Cloud Load Balancing, Error Reporting, Model Armor

Google Cloud -Dienste

In den folgenden Abschnitten werden die OWASP Top 10-Best Practices für die wichtigstenGoogle Cloud -Dienste beschrieben.

Zugriffsgenehmigung und Access Transparency

Mit Access Transparency und Zugriffsgenehmigung kann der Zugriff des Cloud-Anbieters überprüft werden. Mit Access Transparency können Sie den Grund für jeden Zugriff von Google-Mitarbeitern aufzeichnen. Dank der Zugriffsgenehmigung können Zugriffsanfragen von Google-Mitarbeitern, die Support für Ihre Dienste bereitstellen, bestätigt oder abgelehnt werden.

Gilt für A09: Sicherheits-Logging und Monitoring-Fehler.

Beachten Sie die folgenden Best Practices:

  • Automatisieren Sie den Prozess zur Genehmigung des Zugriffs. Konfigurieren Sie dazu die Zugriffsgenehmigung so, dass Metadaten eingehender Genehmigungsanfragen an ein Pub/Sub-Thema gesendet werden. Erstellen Sie ein Pub/Sub-Abo, mit dem die JSON-Nutzlast zur Verarbeitung an Ihren benutzerdefinierten Webhook-Endpunkt (z. B. einen authentifizierten Cloud Run-Dienst, Cloud Run Functions oder ein Enterprise API-Gateway) gesendet wird.
  • Behandeln Sie Access Transparency-Logs als kritische Sicherheitstelemetrie. Erstellen Sie logbasierte Messwerte und Benachrichtigungsrichtlinien in Monitoring, um Ihr Security Operations Center (SecOps) zu benachrichtigen, wenn Google-Mitarbeiter ohne ein aktives, entsprechendes Support-Ticket auf vertrauliche Ressourcen zugreifen.
  • Access Transparency-Logs direkt in Google SecOps oder Ihr zentrales SIEM-System für Unternehmen exportieren
  • Erstellen Sie eine Compliance-Richtlinie, um Ihre Logstreams regelmäßig zu prüfen und zu bestätigen, dass auto_approved-Notfallzugriffsereignisse mit einem dokumentierten Vorfall mit hoher Schwere übereinstimmen.
  • Zur kryptografischen Steuerung verwenden Sie Key Access Justifications, um das System zu zwingen, programmatisch eine Genehmigung für die Entschlüsselung eines Schlüssels anzufordern.

Access Context Manager

Access Context Manager ist die Engine für kontextsensitiven Zugriff vonGoogle Cloud. Mit Access Context Manager können Sie attributbasierte Zugriffsebenen (z. B. Client-IP-Adressbereiche, Sicherheitsstatus des Geräts und geografischer Standort) für IAP, VPC Service Controls und IAM definieren.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A02: Sicherheitsfehlkonfiguration
  • A07: Authentifizierungsfehler

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • Erstellen Sie wiederverwendbare, mehrstufige Sicherheitsstufen für die Zugriffsrichtlinie Ihrer Organisation. Einfache Zugriffsebenen erstellen, um Standardattribute zu testen Bei komplexen Bedingungen mit mehreren Faktoren können Sie benutzerdefinierte Zugriffsebenen bereitstellen, um erweiterte Gerätestatus und Signale von Drittanbieter-Endpunkten auszuwerten.
  • Mit der Endpunktprüfung oder Chrome Enterprise Core können Sie Einschränkungen auf Geräteebene erzwingen, z. B. eine vollständige Festplattenverschlüsselung, eine aktive Displaysperre und eine genehmigte Betriebssystemversion.
  • Um wertvolle Datenrepositories mit VPC Service Controls zu schützen, fügen Sie Ihren VPC Service Controls-Eingangsregeln Zugriffsebenen hinzu. Wenn ein Dienstkontoschlüssel offengelegt wird, kann ein Angreifer nicht nur den Schlüssel verwenden, um BigQuery oder Cloud Storage über eine nicht autorisierte öffentliche IP-Adresse oder einen nicht vertrauenswürdigen Computer abzufragen.
  • Wenn Sie den Zero-Trust-Schutz auf Webanwendungen und administrative VM-Tunnel ausweiten möchten, hängen Sie Zugriffsebenen direkt an Ihre mit IAP gesicherten Ressourcen an.

Hier sind einige Best Practices für A02: Sicherheitsfehlkonfiguration:

  • Implementieren Sie Richtlinien für eingeschränkten Zugriff, die an bestimmte Ordner gebunden sind, um die lokale Richtlinienverwaltung an einzelne Projektteams zu delegieren und ihre Änderungen vom Rest der Organisation zu isolieren.
  • Damit verwaiste Ingress-Regeln nicht zu stillen Hintertüren werden, sollten Sie regelmäßig außer Betrieb genommene IP-Bereiche, abgelaufene Partner-Subnetze und veraltete Geräteattribute überprüfen und entfernen.

Hier sind einige Best Practices für A07: Authentication Failures:

  • Mit Nutzerzugriffsbinding können Sie strenge maximale Sitzungsdauern festlegen. Konfigurieren Sie die Richtlinie für die erneute Authentifizierung so, dass SECURITY_KEY (FIDO2 oder WebAuthn) erforderlich ist. Wenn Sie strengere Einschränkungen für Umgebungen mit hohem Risiko anwenden möchten, konfigurieren Sie scopedAccessSettings, um die Standarddauer von Sitzungen für sensible Anwendungen zu überschreiben.

Agent Gateway und Agent Identity

Agent Gateway und Agent Identity bieten eine dedizierte Durchsetzung von Netzwerkrichtlinien, die Verwaltung des Identitätslebenszyklus und die kryptografische Authentifizierung für KI-Agenten und Agenten-Workflows.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A07: Authentifizierungsfehler

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • In Umgebungen mit Multi-Agenten-Systemen, externen MCP-Tools oder autonomen Pipelines kann Agent Gateway als dedizierter Netzwerk- und Richtliniendurchsetzungspunkt verwendet werden, um Fehler bei der Zugriffssteuerung von Agenten zu minimieren.
  • Konfigurieren Sie detaillierte Autorisierungsrichtlinien für Agent-Identitäten, um den Tool-Zugriff und den Datenabruf auf die Ressourcen zu beschränken, die für den jeweiligen Workflow des Agents erforderlich sind.

Hier sind einige Best Practices für A07: Authentication Failures:

  • Um autonome Agents und Tool-Integrationen zu authentifizieren, ohne statische API-Schlüssel oder Passwörter einzubetten, generieren und weisen Sie jedem Agent eine Agent-Identität zu.
  • Konfigurieren Sie die Agent-Identität, um ein X.509-Zertifikat als Anmeldedaten des Agents auszustellen. Diese Zertifikate tragen dazu bei, den Diebstahl von Tokens zu verhindern. Wenn ein Zugriffstoken abgefangen wird, kann es in anderen Umgebungen nicht verwendet werden.

Apigee

Apigee bietet zentrale Mechanismen auf Gateways-Ebene, die API-Proxys verwenden, um kryptografische Standards zu erzwingen, signierte Nutzlasten zu validieren und Anwendungsdaten während der Übertragung und im Ruhezustand zu verschlüsseln. Als Reverse-Proxy-Gateway für API-Traffic führt Apigee Grenz- und Strukturprüfungen durch, um Nutzlasten zu validieren. Apigee bietet integrierte Richtlinien für die API-Authentifizierung, OAuth und die JWT-Prüfung (JSON Web Token), um starke Identitätsgrenzen zu schaffen. Apigee bietet mehrere Möglichkeiten für Logging, Monitoring, Fehlerbehandlung und Audit-Logging.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A04: Kryptografische Fehler
  • A05: Injection
  • A06: Unsicheres Design
  • A07: Authentifizierungsfehler
  • A09: Fehler beim Sicherheits-Logging und bei Sicherheitsbenachrichtigungen

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • Mit API-Proxys können Sie Folgendes tun:

    • Anfragen abfangen, bei denen ein Angreifer versucht, auf die Datensätze eines anderen Nutzers zuzugreifen, indem er ID-Variablen im API-Anfragepfad manipuliert.

    • Standardclients daran hindern, eingeschränkte administrative Methoden oder Vorgänge mit hohen Berechtigungen auszuführen.

  • Erzwingen Sie für die API-Verwaltungsebene Zugriffssteuerungen, Authentifizierung und die Speicherung von Secrets mit verschlüsselten Key-Value-Maps, Secret Manager oder Kubernetes-Secrets (nur bei hybriden Bereitstellungen).

  • Verwenden Sie OAuth-Richtlinien und JWT-Tokens, um Signaturen zu überprüfen. Ordnen Sie vertrauliche Endpunkte und Aktionen OAuth-Bereichen mit hohen Berechtigungen zu (z. B. delete:account oder write:billing). Verwenden Sie die OAuthV2-Richtlinie, um diese Bereiche am API-Einstiegspunkt zu validieren und einen HTTP-Statuscode 403 Forbidden an alle Clients zurückzugeben, die nicht die richtigen Berechtigungen haben.

  • Aktivieren Sie Erweiterte API-Sicherheit, um den Traffic auf ungewöhnliche Verhaltensmuster zu analysieren und Sicherheitsaktionen zu starten.

Hier finden Sie einige Best Practices für A04: Cryptographic Failures:

Hier finden Sie einige Best Practices für A05: Injection:

Hier finden Sie einige Best Practices für A06: Unsicheres Design:

  • Eingehende Anfragen mit der OASValidation-Richtlinie für eingehende Anfrage- oder Antwortnachrichten anhand der OpenAPI-Spezifikation validieren.
  • Sie können Trafficspitzen und eine Überlastung des Backends vermeiden, indem Sie die Richtlinie SpikeArrest und die Richtlinie Quota implementieren.
  • Verwenden Sie Fehlerbehandlungsregeln, um Backend-Fehler (z. B. einen Datenbankabsturz) abzufangen und in generische HTTP-Antworten umzuschreiben.

Hier sind einige Best Practices für A07: Authentication Failures:

  • Implementieren Sie die API-Schlüsselvalidierung für Ihre APIs, die für Entwickler bestimmt sind, damit Apigee prüfen kann, ob der API-Schlüssel einer Clientanwendung vorhanden, gültig und autorisiert ist, um auf die angeforderte API-Ressource zuzugreifen.
  • Um den Diebstahl von Sitzungstokens und Replay-Angriffe zu verhindern, implementieren Sie DPoP (Demonstrating Proof-of-Possession). DPoP bindet Tokens an den öffentlichen Schlüssel des Absenders, um das Wiederholen von Tokens zu verhindern.
  • Schützen Sie die Endpunkte für die Tokenerstellung und die Anmeldung vor automatisierten Brute-Force-Angriffen, indem Sie SpikeArrest-Ratenbeschränkungen mit der reCAPTCHA Enterprise-Integration kombinieren.

Hier finden Sie Best Practices für A09: Sicherheits-Logging und Benachrichtigungsfehler:

  • Asynchrones Streamen strukturierter API-Transaktionsmetadaten an Logging oder SIEMs von Drittanbietern. Hängen Sie Ihre MessageLogging-Richtlinie an PostClientFlow an. PostClientFlow wird ausgeführt, nachdem die Antwort an den Client gesendet wurde.
  • Zentralisieren Sie Plattform-Audit-Logs, um Änderungen an API-Proxys, Anmeldedaten und Bereitstellungsumgebungen nachzuverfolgen. Um zu verhindern, dass unautorisierte Proxy-Änderungen unbemerkt bleiben, sollten Sie Apigee in Cloud-Audit-Logs einbinden. Weitere Informationen finden Sie unter Apigee-Audit-Logging und Apigee API Management-Audit-Logging.
  • Konfigurieren Sie Benachrichtigungen zur erweiterten API-Sicherheit in Monitoring, um SecOps-Teams über automatisierte Scraping-Kampagnen, Anmeldedatenmissbrauch und Rückgänge des Sicherheitswerts zu informieren.
  • Bereinigen Sie von Nutzern bereitgestellte Variablen in Ihren Logeintrag-Vorlagen, indem Sie sie in die escapeJSON()-Funktion einfügen.
  • Wenn Sie Log-Metadaten an ein externes SIEM streamen, konfigurieren Sie die MessageLogging-Richtlinie so, dass Syslog über TLS (TCP-Port 6514) verwendet wird, um Ihre Daten bei der Übertragung zu verschlüsseln.

Artifact Registry und Artefaktanalyse

Artifact Registry ist eine zentrale Schnittstelle, über die Ihr Unternehmen Container-Images und Sprachpakete verwalten kann. Artefaktanalyse bietet integriertes Scannen auf Sicherheitslücken, die Generierung von Software-Materiallisten (Software Bill of Materials, SBOM) und Metadatenspeicher für Artefakte, die in Artifact Registry gespeichert sind.

Gilt für Folgendes:

  • A03: Fehler in der Softwarelieferkette
  • A08: Software- oder Datenintegritätsfehler

Hier finden Sie einige Best Practices für A03: Fehler in der Softwarelieferkette:

  • Reduzieren Sie die Angriffsfläche und verhindern Sie die Bereitstellung anfälliger Legacy-Images, indem Sie Bereinigungsrichtlinien konfigurieren, um nicht versionierte, nicht getaggte oder veraltete Releasekandidaten-Images nach einem vordefinierten Aufbewahrungszeitraum zu löschen.
  • Schützen Sie sich vor Angriffen durch Verwechslung von Abhängigkeiten, indem Sie virtuelle Repositories mit Upstream-Repository-Prioritäten konfigurieren, bei denen interne Artefakt-Repositories gegenüber öffentlichen Registries priorisiert werden.
  • Erzwingen Sie unveränderliche Image-Tags oder stellen Sie Images ausschließlich per kryptografischem Digest (sha256:...) bereit, um Angriffe durch Tag-Mutation zu verhindern.

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

Assured OSS

Mit Assured OSS können Sie die OSS-Pakete, die Google validiert und verwendet, in Ihre eigenen Entwicklungsworkflows einbinden.

Gilt für Folgendes:

  • A03: Fehler in der Softwarelieferkette
  • A08: Software- oder Datenintegritätsfehler

Hier finden Sie einige Best Practices für A03: Fehler in der Softwarelieferkette:

  • Konfigurieren Sie Remote-Repositories so, dass sie auf Assured OSS verweisen.
  • Prüfen Sie, ob die Open-Source-Bibliotheken in Ihren Builds eine gültige Google-Signatur und einen überprüfbaren SLSA-Build-Herkunftsnachweis enthalten. Konfigurieren Sie Qualitätsprüfungen in Cloud Build, um diese Attestierungen vor dem Kompilieren von Anwendungsbinärdateien zu prüfen.
  • Konfigurieren Sie die Paketmanager (z. B. pip.conf, settings.xml oder build.gradle) in Ihren Cloud Workstations-Basis-Images so, dass sie nur auf Ihre internen Assured OSS-Repositories verweisen.
  • Mithilfe der von Assured OSS generierten Metadaten können Sie feststellen, ob eine neu offengelegte CVE in einem Open-Source-Paket in Ihrem spezifischen Bereitstellungskontext ausgenutzt werden kann.

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

Binärautorisierung

Die Binärautorisierung prüft die Integrität von Containern, sodass nur vertrauenswürdige Container-Images bereitgestellt werden. Sie können Richtlinien erstellen, um Bereitstellungen basierend auf dem Vorhandensein oder Fehlen von Attestierungen zuzulassen oder abzulehnen. Die Binärautorisierung wendet Richtlinien auf Clusterebene an. Sie können also verschiedene Richtlinien für verschiedene Umgebungen konfigurieren.

Gilt für Folgendes:

  • A03: Fehler in der Softwarelieferkette
  • A08: Software- oder Datenintegritätsfehler

Hier finden Sie einige Best Practices für A03: Fehler in der Softwarelieferkette:

  • Konfigurieren Sie Bereitstellungspipelines so, dass sie auf Container-Images anhand ihres eindeutigen, unveränderlichen kryptografischen SHA‑256-Digests (z. B. @sha256) verweisen und diese erzwingen.
  • Stellen Sie Continuous Validation von Binärautorisierung in Ihren GKE-Clustern bereit, um aktive Pods anhand Ihrer Plattformrichtlinie zu überwachen und Warnungen in Logging zu generieren, wenn ausgeführte Container nicht mehr den Richtlinien entsprechen.

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

  • Automatisierte Attestgenerierung in Ihren Cloud Build- oder GitHub Actions-Pipelines erzwingen. Erstellen Sie progressive Attestierungsanforderungen, damit Images sequenzielle Validierungsschritte durchlaufen, wenn sie sich der Produktion nähern.
  • Aktivieren Sie für Produktionsvorfälle mit hoher Schwere Breakglass-Notfalldepoys. Konfigurieren Sie Monitoring-Benachrichtigungsrichtlinien für Breakglass-Audit-Log-Ereignisse, um Ihr SecOps-Team zu benachrichtigen, wenn ein Zulassungs-Bypass auftritt.

CA Service und Zertifikatmanager

Der Certificate Authority Service (CA Service) vereinfacht die Bereitstellung und Verwaltung privater Zertifizierungsstellen (Certificate Authorities, CAs). Zertifikatmanager bietet eine zentrale Bereitstellung, Verlängerung und Verwaltung von TLS-Zertifikaten für Cloud Load Balancing und Cloud CDN.

Gilt für A04: Kryptografische Fehler.

Beachten Sie die folgenden Best Practices:

  • Mit dem CA Service können Sie die Ausstellung und Lebenszyklusverwaltung privater Zertifikate automatisieren. Stellen Sie Stamm- und Zwischenzertifizierungsstellen bereit, die von Cloud HSM unterstützt werden, um private Schlüssel zu schützen, und verwenden Sie Zertifikatvorlagen, um kryptografische Richtlinien (z. B. Mindestschlüssellängen und zulässige erweiterte Schlüsselverwendungen) zu erzwingen.
  • Aktivieren Sie Cloud-Audit-Logs, um administrative Ereignisse mit hohem Risiko zu überwachen, z. B. den Widerruf von Zertifizierungsstellen, Richtlinienaktualisierungen oder einen plötzlichen Anstieg der Zertifikatsanforderungen. Leiten Sie Benachrichtigungen an Google SecOps weiter, um potenzielle Insider-Bedrohungen oder kompromittierte CI/CD-Pipelines zu erkennen.
  • Konfigurieren Sie Zertifikatmanager so, dass von Google verwaltete Zertifikate in Kombination mit DNS-Autorisierungen verwendet werden. Zertifikatmanager validiert die Domaininhaberschaft, stellt das X.509-Zertifikat aus und kümmert sich 30 Tage vor Ablauf um die Verlängerung.
  • Hängen Sie Zertifikatszuordnungen an Ziel-HTTPS-Proxys an, um die dynamische Zertifikatsauswahl und die Zertifikatsrotation zu ermöglichen, ohne dass Proxyneustarts oder Load-Balancer-Neukonfigurationen erforderlich sind.
  • Für interne Microservices oder Hybrid-Load-Balancing konfigurieren Sie Zertifikatszuordnungen, um private Zertifikate direkt aus einem privaten CA Service-CA-Pool auszustellen.
  • Konfigurieren Sie Zertifikatszuordnungen, um eingehende SNI-Anfragen (Server Name Indication) bestimmten Zertifikaten zuzuordnen.

Cloud Asset Inventory

Mit Cloud Asset Inventory können Sie Ihre Infrastruktur auf Google Cloud überwachen, um verwaiste oder nicht autorisierte IT-Infrastruktur zu erkennen.

Gilt für A02: Sicherheitsfehlkonfiguration.

Beachten Sie die folgenden Best Practices:

  • Richten Sie Benachrichtigungen ein, um bei der unerwarteten Ausführung von Ressourcen benachrichtigt zu werden, die möglicherweise nicht richtig gesichert sind oder veraltete Software verwenden.
  • Mit dem IAM Policy Analyzer können Sie falsch konfigurierte Zugriffssteuerungen erkennen, z. B. öffentliche Speicher-Buckets mit der Berechtigung allUsers, überprivilegierte Dienstkontorollen oder verwaiste Identitäten.
  • Asset-Snapshots nach BigQuery exportieren, um Infrastrukturkonfigurationen im Zeitverlauf zu prüfen und einen Compliance-Baseline-Datensatz für Umgebungen mit mehreren Projekten zu erstellen.

Cloud Armor

Cloud Armor ist eine adaptive Web Application Firewall (WAF), die Sie am Rand Ihres Google Cloud Netzwerks bereitstellen, um sich vor DDoS-Angriffen zu schützen und SQLi- oder XSS-Injektions-Payloads zu blockieren. Cloud Armor umfasst vorkonfigurierte WAF-Regeln, um vor OWASP-Top-10-Sicherheitslücken zu schützen, die Angriffsfläche Ihrer Authentifizierungsendpunkte zu begrenzen und kompromittierte Anmeldedaten zu blockieren.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A05: Injection
  • A07: Authentifizierungsfehler
  • A08: Software- oder Datenintegritätsfehler
  • A10: Falsche Behandlung von Ausnahmesituationen

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • Wenden Sie vorkonfigurierte WAF-Regeln wie evaluatePreconfiguredWaf('lfi-stable') an, um Local File Inclusions und Path Traversal-Angriffe zu blockieren.
  • Erzwingen Sie geografische Zugriffskontrollen (auch als Geofencing bezeichnet), indem Sie eine Sicherheitsrichtlinienregel konfigurieren, die eingehenden Traffic anhand des Herkunftslandcodes mit dem Attribut origin.region_code abgleicht.
  • Blockieren Sie bekannte schädliche IP-Adressen mithilfe eines Threat Intelligence-Feeds.
  • Schränken Sie den externen Zugriff auf vertrauliche URLs (z. B. /admin, /login oder /config) ein, indem Sie eine Abgleichsregel erstellen.
  • Aktivieren Sie die Cloud Armor-Pfadnormalisierung auf Ihrem Load Balancer. Dadurch wird Cloud Armor gezwungen, eingehende URLs zu decodieren und zu standardisieren, bevor Ihre Sicherheitsrichtlinien ausgewertet werden.

Hier finden Sie einige Best Practices für A05: Injection:

Hier sind einige Best Practices für A07: Authentication Failures:

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

  • Beschränken Sie Endpunkte, die serialisierte Objekte mit hohem Risiko aus nicht vertrauenswürdigen Quellen akzeptieren, auf eine Reihe vertrauenswürdiger IP-Adressen mit einer deny-Regel wie der Folgenden:

    request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')

  • Stellen Sie benutzerdefinierte Regeln bereit, um Anfragetext-Keywords auf sprachspezifische Ausführungsmuster und unsichere Deserialisierungssignaturen zu prüfen.

Hier finden Sie einige Best Practices für A10: Mishandling of Exceptional Conditions:

  • Aktivieren Sie Google Cloud Armor Adaptive Protection für Ihre Sicherheitsrichtlinien, um normale Trafficmuster zu ermitteln, Benachrichtigungen zu L7-Anomalien zu konfigurieren und gezielte WAF-Regeln mit Angriffssignaturen zu generieren.
  • Konfigurieren Sie Cloud Armor-Ratenbegrenzungsregeln für kritische Endpunkte (z. B. /login, /checkout oder Such-APIs). Ratenbegrenzungsregeln drosseln Anfragen auf Basis der Client-IP-Adresse oder des HTTP-Headers (z. B. indem Clients auf 100 Anfragen pro Minute begrenzt werden) und geben den HTTP-Statuscode 429 Too Many Requests zurück.
  • Legen Sie die Standardregel mit der niedrigsten Priorität in Ihrer Cloud Armor-Sicherheitsrichtlinie auf Deny (Statuscode: 403 oder 404) fest.

Cloud Build und Cloud Deploy

Cloud Build und Cloud Deploy bieten eine integrierte, sichere CI/CD-Pipeline (Continuous Integration/Continuous Delivery) aufGoogle Cloud. Cloud Build erstellt Artefakte mit nachweisbarer SLSA-provenance und kryptografischen Attestierungen. Cloud Deploy verwaltet progressive Rollouts, Zielgenehmigungen und automatisierte Überprüfung in GKE und Cloud Run.

Gilt für Folgendes:

  • A03: Fehler in der Softwarelieferkette
  • A08: Software- oder Datenintegritätsfehler

Hier finden Sie einige Best Practices für A03: Fehler in der Softwarelieferkette:

  • Legen Sie in Ihrer cloudbuild.yaml-Datei requestedVerifyOption: VERIFIED fest, um nachweisbare Herkunft zu verlangen.
  • Stellen Sie private Cloud Build-Pools bereit, die für vertrauliche Unternehmens-Builds über Peering mit Ihrem privaten VPC-Netzwerk verbunden sind.
  • Build-Trigger so konfigurieren, dass sie unter dedizierten, vom Nutzer verwalteten Dienstkonten ausgeführt werden. Gewähren Sie diesen Dienstkonten nur die erforderlichen IAM-Berechtigungen (z. B. Artifact Registry-Autor (roles/artifactregistry.writer) und Logs Writer (roles/logging.logWriter)).
  • Manuelle Genehmigungen für Cloud Build-Trigger erforderlich machen, die auf Staging- oder Produktionsumgebungen ausgerichtet sind.
  • Beschränken Sie CI-Build-Tools wie Cloud Build, GitHub Actions oder GitLab auf die Rolle Cloud Deploy Releaser (roles/clouddeploy.releaser), damit Build-Pipelines nur Releases erstellen können.
  • Wenn Sie manuelle Genehmigungen benötigen, konfigurieren Sie das Manifest Ihrer Bereitstellungspipeline (delivery-pipeline.yaml) mit requireApproval: true für Ihre Staging- und Produktionsziele.
  • Konfigurieren Sie Ausführungsumgebungen mit zielspezifischen Dienstkonten, z. B. ein Dienstkonto mit Berechtigungen, die auf den Staging-Namespace beschränkt sind, und ein separates, geprüftes Dienstkonto für die Produktion.
  • Benutzerdefinierte Hooks bereitstellen, um während des Roll-out-Lebenszyklus bandexterne Sicherheitszusicherungen auszuführen. Verwenden Sie Pre-Deploy-Hooks, um zu prüfen, ob Zielcluster Compliance-Baselines erfüllen, und Post-Deploy-Hooks, um automatisierte Scans auf Sicherheitslücken für aktive Containerendpunkte zu starten.

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

  • Integrieren Sie Cloud Build in Cloud KMS und Artefaktanalyse, um kryptografische Attestierungen zu erstellen und zu signieren, wenn Unittests und statische Analysetests erfolgreich abgeschlossen wurden.
  • Verwenden Sie unveränderliche kryptografische SHA-256-Digests (z. B. golang@sha256:...) in Builder-Schritten in cloudbuild.yaml.
  • Speichern Sie Build-Konfigurationen in versionsverwalteten Repositories, die durch Zweigschutzregeln geschützt sind (z. B. durch die Anforderung von Prüfungen durch zwei Personen für Pull-Anfragen). Beschränken Sie die Berechtigungen zum Ändern von Triggern auf autorisierte Plattformadministratoren, die nutzerverwaltete Dienstkonten verwenden.
  • Identische, vorab gerenderte Bereitstellungsmanifeste und unveränderliche Container-Image-Digests werden über die Zielphasen hinweg hochgestuft, ohne dass CI-Pipelines Manifeste zwischen Staging und Produktion ändern können.
  • Definieren Sie automatisierte Aufgaben zur Überprüfung der Bereitstellung in Ihrem skaffold.yaml-Manifest. Cloud Deploy führt diese Prüfcontainer aus, nachdem Pods bereitgestellt wurden, um dynamische Systemdiagnosen, Integrationstests und API-Vertragszusicherungen auszuführen.
  • Verwenden Sie Canary-Bereitstellungsstrategien. Wenn ein Skaffold-Bestätigungstest fehlschlägt oder beim Monitoring während einer Canary-Phase Anomalieschwellenwerte erkannt werden, hält Cloud Deploy den Rollout an und leitet den Traffic zurück zur letzten bekannten Releaseversion.
  • Konfigurieren Sie GKE-Cluster und Cloud Run, um Richtlinien für die Binärautorisierung zu erzwingen. Wenn Cloud Deploy die Manifeste anwendet, überprüft der Zulassungscontroller des Ziels die Container-Image-Digests kryptografisch und lehnt nicht vertrauenswürdige Artefakte ab.

Cloud Identity und Titan-Sicherheitsschlüssel

Cloud Identity bietet eine zentrale Verwaltung von Identitäten, Anmeldedaten und Zugriff für Google Cloudund Google Workspace. Titan-Sicherheitsschlüssel sind hardwarebasierte, phishingresistente Sicherheitsgeräte, die Public-Key-Kryptografie auf Grundlage von FIDO2- oder WebAuthn-Standards verwenden.

Gilt für A07: Authentifizierungsfehler.

Beachten Sie die folgenden Best Practices:

  • Um sich vor Man-in-the-Middle-Phishing-Angriffen (PITM) zu schützen, konfigurieren Sie die 2-Faktor-Authentifizierung (2FA) und legen Sie die zulässige Methode auf Nur Sicherheitsschlüssel (FIDO2, WebAuthn oder Titan-Sicherheitsschlüssel) fest.
  • Konfigurieren Sie die SAML 2.0- oder OIDC-basierte Einmalanmeldung (SSO) mit dem Identitätsanbieter Ihres Unternehmens und der automatischen Bereitstellung.
  • Legen Sie für die Google Cloud Richtlinie zur Sitzungsdauer einen niedrigen maximalen Grenzwert fest, um Nutzer zu zwingen, sich regelmäßig neu zu authentifizieren.
  • Registrieren Sie Titan-Sicherheitsschlüssel als Passkeys, um die passwortlose Authentifizierung zu aktivieren. Dadurch werden Risiken durch Brute-Force-Angriffe und kompromittierte Anmeldedaten erheblich reduziert.
  • Erzwingen Sie die 2FA mit Titan-Sicherheitsschlüsseln für Ihre privilegierten Identitäten (z. B. Projektinhaber, Abrechnungsadministratoren und SecOps-Teams), indem Sie Sicherheitsschlüsselrichtlinien in Cloud Identity erzwingen. Melden Sie Nutzer mit hohem Risiko für das erweiterte Sicherheitsprogramm an.

Cloud KMS

Mit Cloud KMS werden symmetrische und asymmetrische kryptografische Schlüssel für kompatible Google Cloud Dienste und in Ihren eigenen Anwendungen verwaltet. Sie können kryptografische Schlüssel für die symmetrische Verschlüsselung, die asymmetrische Signierung, die asymmetrische Verschlüsselung und die MAC-Signierung generieren, verwenden, rotieren und löschen.

Gilt für A04: Kryptografische Fehler.

Beachten Sie die folgenden Best Practices:

  • Verwenden Sie Cloud KMS Autokey, um die Bereitstellung und Zuweisung zu automatisieren. Mit Autokey müssen Sie keine Schlüsselbunde, Schlüssel und Dienstkonten im Voraus bereitstellen. Stattdessen werden Schlüssel und Schlüsselbunde bei der Ressourcenerstellung auf Anfrage generiert.
  • Verwenden Sie Cloud KMS-Schlüssel, um sensible Nutzlasten zu verschlüsseln, bevor sie an Speicher-Buckets oder Datenbanken gesendet werden. Sie können die Cloud KMS API oder Clientbibliotheken verwenden, um Ihre Cloud KMS-Schlüssel für die clientseitige Verschlüsselung zu nutzen.
  • End-to-End-Datenintegrität prüfen, indem Sie Prüfsummen während der Übertragung validieren.
  • Für Arbeitslasten, die strengen Compliance- und behördlichen Anforderungen unterliegen, sollten Sie Ihre kryptografischen Vorgänge mit Cloud HSM speichern und ausführen. In Cloud HSM werden Ihre Schlüssel in nach FIPS 140-3 Level 3 validierten Hardwaresicherheitsmodulen gespeichert.
  • Zeitpläne für die automatische Schlüsselrotation konfigurieren für einen festgelegten Zeitraum (z. B. alle 90 Tage).

Cloud Load Balancing

Cloud Load Balancing ist ein vollständig verteilter, softwarebasierter verwalteter Dienst, der Nutzertraffic auf mehrere Back-End-Instanzen und ‑Regionen verteilt.

Gilt für Folgendes:

  • A04: Kryptografische Fehler
  • A10: Falsche Behandlung von Ausnahmesituationen

Hier finden Sie einige Best Practices für A04: Cryptographic Failures:

Hier finden Sie einige Best Practices für A10: Mishandling of Exceptional Conditions:

Google Cloud Observability (Logging, Monitoring und Error Reporting)

Google Cloud Observability bietet Full-Stack-Logverwaltung mit Logging, Messwerte und Benachrichtigungen mit Monitoring sowie Echtzeit-Tracking von Anwendungsabstürzen mit Error Reporting.

Gilt für Folgendes:

  • A09: Fehler beim Sicherheits-Logging und bei Sicherheitsbenachrichtigungen
  • A10: Falsche Behandlung von Ausnahmesituationen

Hier finden Sie Best Practices für A09: Sicherheits-Logging und Benachrichtigungsfehler:

  • Aktivieren Sie Data Access-Logs für hochwertige Daten-Repositories (z. B. Cloud Storage, BigQuery und Spanner), in denen vertrauliche Daten gespeichert werden. Mit Datenzugriffslogs können Sie jedes Lese-, Schreib- und Abfrageereignis für vertrauliche Daten prüfen.
  • Erzwingen Sie Bucket Lock und Aufbewahrungsrichtlinien für den benutzerdefinierten Logging-Bucket, um zu verhindern, dass Angreifer oder unbefugte Administratoren Logs löschen, um ihre Spuren zu verwischen.
  • Verwenden Sie aggregierte Senken, um Logeinträge für Ihre SecOps-Teams in einem zentralen Repository zusammenzufassen und weiterzuleiten. Konfigurieren Sie das Abfangen aggregierter Senken, um zu vermeiden, dass Logs mit hohem Volumen wie Datenzugriffslogs an mehr als einem Ort gespeichert werden.
  • Konfigurieren Sie logbasierte Benachrichtigungsrichtlinien für kritische Anzeichen für Sicherheitsrisiken, z. B. IAM-Fehler vom Typ „Permission Denied“, unerwartete API-Schlüsselgenerierungen oder plötzliche Änderungen an der Firewallkonfiguration.
  • Stellen Sie Richtlinien für logbasierte Benachrichtigungen im Log-Explorer oder in Monitoring bereit. Geben Sie genaue Filter an, die auf Ereignisse mit hohem Schweregrad ausgerichtet sind, z. B. nicht autorisierte IAM-Richtlinienänderungen oder KMS-Schlüsselwiderrufe, damit eine Vorfallbenachrichtigung generiert wird, wenn ein übereinstimmender Logeintrag aufgenommen wird.
  • Erstellen Sie logbasierte Zählermesswerte in Logging, um übereinstimmende Logeinträge in Zeitachsendaten umzuwandeln. Erstellen Sie dann in Monitoring eine messwertbasierte Benachrichtigungsrichtlinie, die einen Vorfall startet, wenn die Rate einen bestimmten Grenzwert überschreitet (z. B. mehr als 50 fehlgeschlagene Anmeldeversuche in fünf Minuten).
  • Konfigurieren Sie logbasierte Benachrichtigungsrichtlinien, die administrative Aufrufe der Cloud Logging API überwachen und bei unerwarteten Änderungen an Log-Exportsenken oder beim Löschen von Buckets Benachrichtigungen auslösen.
  • Konfigurieren Sie Benachrichtigungskanäle mit klaren Dokumentationsvorlagen. Fügen Sie direkte Deeplinks zur Logs Explorer-Abfrage, Standardarbeitsanweisungen (Standard Operating Procedures, SOPs) für den Bereitschaftstechniker und explizite Schritte zur Behebung ein, um eine schnelle Eindämmung des Vorfalls zu ermöglichen.

Hier finden Sie einige Best Practices für A10: Mishandling of Exceptional Conditions:

  • Integrieren Sie Error Reporting-SDKs direkt in Ihren Anwendungscode oder konfigurieren Sie Logging so, dass strukturierte JSON-Ausnahmeformate geparst werden.
  • Konfigurieren Sie Benachrichtigungschannels für Error Reporting oder Monitoring-Benachrichtigungsrichtlinien, um Ihre SecOps-Teams zu benachrichtigen, wenn eine neue Ausnahmeklasse auftritt.

Cloud NGFW

Cloud NGFW ist ein verwalteter Firewall-Dienst, der die zustandsbehaftete Prüfung und die Layer 7-Anwendungssteuerung für Nord-Süd- und Ost-West-Traffic ermöglicht.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A05: Injection

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

Hier finden Sie einige Best Practices für A05: Injection:

  • Konfigurieren Sie den Einbruchserkennungs- und ‑präventionsdienst mit einer Sicherheitsprofilgruppe, die Bedrohungen ablehnt, die mit Signaturen für SQL-Injection, OS-Befehlsinjection und Remote-Code-Ausführung übereinstimmen.
  • Konfigurieren Sie die Cloud NGFW-TLS-Prüfung, um eingehenden und ausgehenden HTTPS-Traffic zu entschlüsseln, IPS-Injektionssignaturprüfungen auf die Klartextnutzlast anzuwenden und die Sitzung vor der Übermittlung an das Backend neu zu verschlüsseln.
  • FQDN-basierte Firewallregeln für ausgehenden Traffic für Backend-Datenbanken und Compute-Subnetze erzwingen. Beschränken Sie ausgehende Verbindungen auf genehmigte, vordefinierte externe Domains, um zu verhindern, dass anfällige Anwendungen nicht autorisierte Reverse Shells erstellen.
  • Aktivieren Sie das Logging von Firewallregeln für Profile zur Bedrohungsabwehr und leiten Sie diese Logs an Google SecOps weiter, um blockierte Signaturen für die Netzwerkeinschleusung mit Telemetriedaten auf Hostebene zu korrelieren und so Arbeitslasten zu identifizieren, die vorrangig gepatcht werden müssen.

Cloud Workstations

Cloud Workstations bietet verwaltete Entwicklungsumgebungen auf Google Cloud mit integrierter Sicherheit und Anpassungsmöglichkeiten.

Gilt für Folgendes:

  • A03: Fehler in der Softwarelieferkette
  • A04: Kryptografische Fehler

Hier finden Sie einige Best Practices für A03: Fehler in der Softwarelieferkette:

  • Erstellen Sie benutzerdefinierte Basis-Container-Images, die in Artifact Registry gespeichert werden und in denen Sicherheitstools, vertrauenswürdige Entwicklerextensions und genehmigte Sprachlaufzeiten vorinstalliert sind.
  • Stellen Sie Ihre Workstation-Cluster mit privatem IP-Ein- und ‑Ausgang und innerhalb eines VPC Service Controls-Perimeters bereit.
  • Konfigurieren Sie Cloud Workstations so, dass Sitzungstraffic über IAP weitergeleitet wird. Entwickler müssen sich mit Unternehmensanmeldedaten authentifizieren, für die die Multi-Faktor-Authentifizierung (MFA) aktiviert ist. Außerdem müssen Rollen mit dem geringsten erforderlichen Berechtigungsniveau erzwungen werden, z. B. Cloud Workstations-Nutzer (roles/workstations.user).
  • Konfigurieren Sie Workstation-Konfigurationen mit niedrigen Zeitüberschreitungslimits, z. B. automatisches Beenden nach zwei Stunden Inaktivität. Wenn eine Workstation neu gestartet wird, ruft Cloud Workstations das neueste sicherheitsgepatchte Container-Image ab, damit Entwickler in einer sauberen Umgebung arbeiten können.

Hier finden Sie einige Best Practices für A04: Cryptographic Failures:

CodeMender

CodeMender ist ein spezialisierter, autonomer KI-Agent für Engineering. CodeMender kann neu entdeckte Sicherheitslücken schließen und vorhandenen Legacy-Code umschreiben, um bestehende Sicherheitslücken zu beheben. Sie können CodeMender in der Gemini Enterprise Agent Platform installieren und konfigurieren.

Gilt für Folgendes:

  • A03: Fehler in der Softwarelieferkette
  • A05: Injection
  • A06: Unsicheres Design

Hier finden Sie einige Best Practices für A03: Fehler in der Softwarelieferkette:

Hier finden Sie einige Best Practices für A05: Injection:

  • Führen Sie die automatische Patchgenerierung in isolierten lokalen Sandboxes aus, um anfällige Logik neu zu schreiben, z. B. um Eingaben zu bereinigen. Prüfen Sie, ob Einheitentests bestanden wurden und PoCs nicht mehr ausgenutzt werden können, bevor Sie Pull-Anfragen erstellen.

Hier finden Sie einige Best Practices für A06: Unsicheres Design:

  • Refaktorieren Sie Legacy- oder unsichere Architekturcodelogik mit der iterativen Patch-Engine von CodeMender. Geben Sie explizite Programmierbeschränkungen an, um sichere Designmuster in allen Anwendungsmodulen zu erzwingen.
  • Führen Sie eine Überprüfung durch Menschen für von CodeMender generierte Pull-Anfragen und Diffs durch, um zu prüfen, ob die vorgeschlagenen Änderungen Ihren Richtlinien für sicheres Programmieren entsprechen.

Confidential Computing

Confidential Computing trägt zum Schutz aktiver Daten bei, indem die Daten während der Verarbeitung im Arbeitsspeicher verschlüsselt bleiben. Confidential Computing nutzt hardwarebasierte vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEEs), um sicherzustellen, dass Ihre vertraulichen Daten und kryptografischen Schlüssel nicht vom Hypervisor, dem Hostbetriebssystem oder Infrastrukturadministratoren aufgerufen werden können.

Gilt für A04: Kryptografische Fehler.

Beachten Sie die folgenden Best Practices:

  • Verwenden Sie Confidential VMs oder Confidential Google Kubernetes Engine-Knoten für hochsensible Arbeitslasten wie personenbezogene Daten, Finanzunterlagen oder proprietäre KI-Modellgewichte.
  • Wenn mehrere Organisationen vertrauliche Daten für die Analyse oder das KI-Training zusammenführen müssen, ohne die Rohdaten gegenseitig preiszugeben, verwenden Sie Confidential Space, um die kryptografische Attestierung und Datenisolation zu erzwingen.

Firebase (Firebase Authentication, Firebase App Check und Firebase-Sicherheitsregeln)

Firebase bietet entwicklerorientierte Sicherheitskontrollen für Identität, Client-Attestierung und Datenbankzugriff. Firebase Authentication übernimmt die Verwaltung von Nutzeridentitäten und ‑sitzungen, App Check validiert die Integrität von Client-Apps und Firebase-Sicherheitsregeln erzwingen die attributbasierte Zugriffssteuerung und Schemavalidierung für Firestore und Cloud Storage.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A05: Injection
  • A07: Authentifizierungsfehler
  • A08: Software- oder Datenintegritätsfehler

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

Hier finden Sie einige Best Practices für A05: Injection:

  • Strukturelle Nutzlastvalidierung in Sicherheitsregeln erzwingen, indem eingehende Dokumentfeldtypen, Stringlängen und Objektgrößen geprüft werden, um fehlerhafte oder schädliche Schreibnutzlasten vor der Datenbankaufnahme abzulehnen.

Hier sind einige Best Practices für A07: Authentication Failures:

  • Führen Sie ein Upgrade auf Firebase Authentication mit Identity Platform durch, um Unternehmensschutzfunktionen wie MFA mit TOTP und Blockierfunktionen zu aktivieren.
  • Prüfen Sie Firebase-ID-Tokens in Ihrem Backend mit dem Firebase Admin SDK, bevor Sie Zugriff auf vertrauliche Anwendungsdaten gewähren.
  • Verwenden Sie den Debug-Anbieter, um temporäre, bereichsbezogene Debug-Tokens für Ihre Entwickler und CI/CD-Pipelines in Staging-Umgebungen zu generieren.

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

  • Hardwaregestützte Attestierungsanbieter erzwingen, um die Clientintegrität zu überprüfen. Konfigurieren Sie App Check für die Verwendung von Android Play Integrity und Apple App Attest.
  • Stellen Sie die Middleware zur App Check-Tokenüberprüfung in Cloud Run- und Kubernetes Engine API-Back-Ends bereit, um Anfragen abzulehnen, die von extrahierten API-Schlüsseln, automatisierten Skripts oder emulierten Umgebungen stammen.

Betrugsabwehr

Fraud Defense ist eine einheitliche Plattform für die Betrugs- und Missbrauchsprävention, einschließlich des Schutzes von Bots, Konten und Transaktionen im Web. reCAPTCHA, ein Angebot, das Teil von Fraud Defense ist, filtert Bots und andere Formen der Automatisierung und des Bulk-Traffics heraus, indem die Risikostufe für Zugriffsversuche bestimmt wird.

Gilt für A07: Authentifizierungsfehler.

Beachten Sie die folgenden Best Practices:

  • reCAPTCHA in Ihre vorhandene WAF einbinden, z. B. Google Cloud Armor, um automatische Challenges auszugeben oder Bot-Traffic mit hohem Risiko zu blockieren, bevor Anfragen Authentifizierungsendpunkte erreichen.
  • Konten schützen bei Endpunkten für Anmeldung, Passwortzurücksetzung und Sitzungserneuerung. Risikobewertungen für Kontoübernahmen (Account Takeover) basierend auf der Anmeldegeschwindigkeit von Nutzern und Geräte-Fingerprints abrufen.
  • SMS-Gebührenbetrug verhindern: Sie können das Risiko von Telefonnummern in Registrierungs- und 2FA-Formularen bewerten, bevor Sie ausgehende SMS-Nachrichten senden.
  • Um falsch positive Ergebnisse zu reduzieren und website-spezifische Risikobewertungsmodelle zu trainieren, sollten Sie regelmäßig Transaktionsfeedback annotieren und senden.
  • Passwörter prüfen während der Nutzeranmeldung und bei der Kontoerstellung, um zu erkennen, ob eingereichte Anmeldedaten in Datenbanken von Drittanbietern zu Datenpannen im Web enthalten sind.

Google SecOps

Google Security Operations ist eine Plattform für Sicherheitsvorgänge, die die Analyse von Sicherheitstelemetriedaten (SIEM), Sicherheitsorchestrierung, Automatisierung und Reaktion (SOAR) sowie aktuelle Mandiant Threat Intelligence auf einer einzigen Plattform vereint.

Gilt für Folgendes:

  • A02: Sicherheitsfehlkonfiguration
  • A09: Fehler beim Sicherheits-Logging und bei Sicherheitsbenachrichtigungen

Hier sind einige Best Practices für A02: Sicherheitsfehlkonfiguration:

  • Nehmen Sie Ergebnisse aus Security Command Center in Google SecOps auf, um statische Ergebnisse zu Fehlkonfigurationen (z. B. PUBLIC_BUCKET_ACL oder CMEK_DISABLED) mit Live-Telemetriedaten zu Netzwerk und Firewall zu kombinieren.
  • Erstellen Sie automatisierte SOAR-Reaktions-Playbooks, um Eindämmungsmaßnahmen auszuführen.
  • Mit Gemini können Sie die Triage von Fehlkonfigurationen beschleunigen und zusammengefasste Übersichten über falsch konfigurierte Assets, zugeordnete IAM-Rollen und Schritt-für-Schritt-Anleitungen zur Fehlerbehebung erhalten.

Hier finden Sie Best Practices für A09: Sicherheits-Logging und Benachrichtigungsfehler:

  • Normalisieren Sie die Log-Telemetrie in das einheitliche Datenmodell (Unified Data Model, UDM), um schnelle, standardisierte Multi-Cloud-Suchen und ‑Korrelationen ohne den Overhead des Parsens von Rohlogs zu ermöglichen.
  • Schreiben Sie YARA-L 2.0-Erkennungsregeln, um Änderungen an Konfigurationen mit hohem Risiko zu überwachen, z. B. das Deaktivieren von OS Login, das Löschen von Logging-Senken oder Änderungen an VPC Service Controls-Perimetern.
  • Verwenden Sie kuratierte Erkennungen von Applied Threat Intelligence, um Ihre Ereignisdaten mit Mandiant Threat Intelligence-Daten abzugleichen.
  • Mit Gemini in Google SecOps können Sie YARA-L-Erkennungsregeln aus Beschreibungen in natürlicher Sprache generieren und komplexe, mehrstufige Zeitachsen von Vorfällen in Zusammenfassungen für Führungskräfte zusammenfassen.

Identity-Aware Proxy

IAP erstellt eine zentrale Autorisierungsebene für Anwendungen, auf die über HTTPS und administrative TCP-Verbindungen zugegriffen wird. IAP überprüft die Nutzeridentität und den Kontext, bevor der Zugriff auf Cloud Run-, App Engine-, Compute Engine-, GKE- und lokale Ressourcen gewährt wird.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A07: Authentifizierungsfehler

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • Erzwingen Sie detaillierte Zugriffssteuerungen für Webanwendungen, VMs, Google Cloud APIs und Google Workspace-Anwendungen basierend auf der Nutzeridentität, der Gruppenmitgliedschaft und dem Kontext der Anfrage.
  • Integration mit Agent Gateway, um Zugriffssteuerungen für Ihre Agent-Identitäten zu erzwingen.
  • Verwenden Sie die IAP-TCP-Weiterleitung, um verschlüsselte HTTPS-Tunnel zu Ihren Backend-Instanzen einzurichten und internetorientierte SSH- (Port 22) und RDP-Endpunkte (Port 3389) zu entfernen.

Hier sind einige Best Practices für A07: Authentication Failures:

  • Authentifizieren Sie Nutzer, die über IAP auf administrative Schnittstellen und Webanwendungen zugreifen, mit Identitäten, die in IAM oder Cloud Identity bereitgestellt werden.
  • Bestätigen Sie die signierte JWT-Assertion im Header x-goog-iap-jwt-assertion auf der Anwendungsebene. Validieren Sie die Signatur anhand der öffentlichen Schlüssel von Google und prüfen Sie, ob der Zielgruppenanspruch (aud) mit der ID Ihres Backend-Dienstes übereinstimmt.
  • Um zu verhindern, dass Angreifer die IAP-Authentifizierung umgehen, konfigurieren Sie die Cloud Run-Ingress-Einstellungen so, dass nur interner Traffic und Cloud Load Balancing-Traffic zugelassen wird. Dadurch wird der direkte öffentliche Zugriff auf die Backend-Container-URLs blockiert. Konfigurieren Sie für VMs oder GKE-Knoten VPC-Firewallregeln so, dass nur Ingress-Traffic aus den IP-Bereichen des Load Balancers akzeptiert wird.

Identity and Access Management

Mit Identity and Access Management (IAM) können Sie detaillierten Zugriff auf Dienste und Ressourcen in Google Cloudverwalten. IAM umfasst unter anderem die folgenden Funktionen:

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A07: Authentifizierungsfehler

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • Verwenden Sie vordefinierte Rollen oder benutzerdefinierte Rollen (nicht einfache Rollen), um Berechtigungen auf bestimmte Ressourcen oder Nutzeranforderungen zu beschränken.
  • Beschränken Sie die Berechtigungen, um die Rollen „Dienstkontonutzer“ (roles/iam.serviceAccountUser) und „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator) zuzuweisen.
  • Verwenden Sie den IAM Recommender, um die aktiven Nutzungsprotokolle Ihrer Organisation zu analysieren und Konten mit zu vielen Berechtigungen zu entfernen.
  • Schreiben Sie IAM-Bedingungen in Ihre Rollenbindungen, um eine kontextbezogene Autorisierung hinzuzufügen und den Zugriff nach Datum, Tageszeit oder Quell-IP-Adresse einzuschränken.
  • Stellen Sie Principal Access Boundary-Richtlinien (PAB) bereit, um die Organisationen, Ordner oder Projekte zu definieren, auf die eine Gruppe von Hauptkonten zugreifen kann. Wenn ein Angreifer eine aktive Sitzung stiehlt oder einem Dienstkonto versehentlich umfassende IAM-Rollen gewährt werden, blockiert PAB den Zugriff, wenn sich die angegebene Ressource außerhalb der zugewiesenen Grenze der Identität befindet.
  • Hängen Sie IAM-Ablehnungsrichtlinien auf Organisations- oder Ordnerebene an, um riskante Berechtigungen wie iam.serviceAccountKeys.create oder resourcemanager.projects.delete zu blockieren.
  • Wenn Sie IAM-Ablehnungsregeln konfigurieren, deklarieren Sie eine dedizierte Breakglass-Sicherheitsgruppe in der Liste exceptionPrincipals. Verwenden Sie Ressourcentags in Ihren Ablehnungsbedingungen (z. B. resource.matchTag('env', 'prod')), damit destruktive Aktionen für Produktionsressourcen blockiert werden, während Entwickler in Entwicklungs-Sandbox-Projekten betriebliche Flexibilität haben.

Sehen Sie sich die folgenden Best Practices für A07: Authentication Failures an, die für Privileged Access Manager gelten:

  • Wandeln Sie kritische Administratorrollen wie „Owner“ (roles/owner), Organisationsadministrator“ (roles/resourcemanager.organizationAdmin) und „Sicherheitsadministrator“ (roles/iam.securityAdmin) von statischen IAM-Bindungen in Privileged Access Manager-Berechtigungen um. Konfigurieren Sie diese Berechtigungen so, dass eine betriebliche Begründung erforderlich ist, bevor die Berechtigung erhöht wird.
  • Konfigurieren Sie für Produktionsumgebungen Berechtigungsrichtlinien für Privileged Access Manager mit obligatorischen Genehmigern wie einer zentralen SecOps-Gruppe oder Teamleitern.
  • Konfigurieren Sie die maximale Dauer für Privileged Access Manager-Berechtigungen auf das kürzeste realistische Betriebsfenster (z. B. zwei Stunden für die Standardwartung, 30 Minuten für Breakglass-Aktionen). Nach Ablauf des Zeitgebers entferntGoogle Cloud die temporäre IAM-Rollenbindung.
  • Verwalten Sie die Terraform-Infrastruktur mit nicht autoritativen IAM-Ressourcen (z. B. google_project_iam_member oder google_folder_iam_member anstelle von google_project_iam_policy oder google_project_iam_binding). So wird verhindert, dass Ihre Terraform-Pipelines überschrieben oder temporäre Privileged Access Manager-Rollenbindungen desynchronisiert werden, während ein Administrator einen Vorfall behebt.
  • Aktivieren Sie Cloud-Audit-Logs in Privileged Access Manager, um Berechtigungsaktionen und Ablaufereignisse aufzuzeichnen. Nehmen Sie diese Logs in Google SecOps auf, um bei verdächtigen Mustern für die Rechteausweitung benachrichtigt zu werden, z. B. bei mehreren Anfragen zur Rechteausweitung außerhalb der Arbeitszeiten oder bei wiederholten Anfragen von unerwarteten geografischen Standorten.

Sehen Sie sich die folgenden Best Practices für A07: Authentication Failures an, die für die Workforce Identity-Föderation gelten:

  • Mitarbeiteridentitätspools mit SAML 2.0 oder OpenID Connect (OIDC) bereitstellen, um externe Identitätsanbieter mitGoogle Cloudzu föderieren.
  • Konfigurieren Sie die Sitzungsdauer in Ihrem Workforce Identity-Pool, um die Lebensdauer von Tokens für Verbundnutzer zu begrenzen.
  • Attributbedingungen für Workforce Identity-Anbieter erzwingen, um die Fälschung von Multi-Tenant-IdP-Tokens oder die Identitätsübernahme durch andere Organisationen zu verhindern.
  • Ordnen Sie externe Gruppenmitgliedschaften zu, um IAM-Rollen Sets von föderierten Gruppenhauptkonten zuzuweisen (z. B. principalSet://iam.googleapis.com/.../attribute.group/security-engineers).

Sehen Sie sich die folgenden Best Practices für A07: Authentication Failures an, die für die Workload Identity-Föderation gelten:

  • Workload Identity-Pools und -Anbieter für externe Workloads erstellen Verwenden Sie kurzlebige OIDC-Tokens und tauschen Sie sie dynamisch über den Security Token Service gegen temporäre Zugriffstokens ein, die nach wenigen Minuten ablaufen.
  • Erzwingen Sie Attributbedingungen für Workload Identity-Anbieter, damit sich externe Mandantenplattformen nicht über nicht autorisierte Repositories oder Konten bei Ihrem Pool authentifizieren können.
  • IAM-Rollen direkt an bestimmte Gruppen von Hauptkonten binden, die nach benutzerdefinierten zugeordneten Attributen gefiltert werden.
  • Wenn Sie den Arbeitslastzugriff konfigurieren, weisen Sie IAM-Rollen direkt der föderierten principalSet://-Kennung für die Zielressource zu.
  • Wenn Sie die Workload Identity-Föderation erzwingen möchten, legen Sie die constraints/iam.disableServiceAccountKeyCreation-Einschränkung für Ihre Organisation fest.

Identity Platform

Identity Platform ist die Plattform für die Identitäts- und Zugriffsverwaltung für Kunden (CIAM) für Google Cloud -Kunden. Identity Platform bietet Authentifizierung mit Unterstützung durch mehrere Protokolle mithilfe von SDKs und APIs. Identity Platform unterstützt die MFA, die Einbindung in Authentifizierungsdienste von Drittanbietern und prüfbares Aktivitäts-Tracking.

Gilt für A07: Authentifizierungsfehler.

Beachten Sie die folgenden Best Practices:

  • Aktivieren Sie MFA für alle Ihre Nutzer. Priorisieren Sie phishingresistente Methoden wie TOTP (Authentifizierungs-Apps) oder WebAuthn (Biometrie und Sicherheitsschlüssel).
  • Stellen Sie blockierende Cloud Run-Funktionen mit beforeCreate- und beforeSignIn-Triggern bereit, um benutzerdefinierten Sicherheitscode auszuführen, bevor ein Nutzer gespeichert oder ein Token ausgestellt wird. So können Sie beispielsweise Einweg-E-Mail-Domains blockieren, IP-Adressen einschränken oder eine E-Mail-Bestätigung vorschreiben.
  • Integrieren Sie reCAPTCHA Enterprise, um Anfragen zur Anmeldung, Registrierung und zum Zurücksetzen des Passworts auf Bot-Traffic, Credential-Stuffing-Versuche und automatisierten Missbrauch zu prüfen.
  • Konfigurieren Sie Passwortrichtlinien, um eine Mindestanzahl von Zeichen zu erzwingen, bestimmte Zeichenkomplexitäten (z. B. Zahlen und Symbole) zu verlangen und vorhersehbare Sequenzen zu blockieren.
  • Wenn Sie die telefonbasierte MFA verwenden, konfigurieren Sie SMS-Regionen und aktivieren Sie reCAPTCHA SMS Defense, um Bestätigungsnachrichten auf die Ländercodes zu beschränken, in denen sich Ihre Zielnutzer befinden.

Mandiant AI Security Consulting – Lösungen

Mit den Mandiant AI Security Consulting Solutions können Sie Ihre vorgeschlagenen Softwarearchitekturen, Geschäftsprozesse und Cloud-Bereitstellungen frühzeitig im Entwicklungszyklus bewerten. Durch die Anwendung von Threat Intelligence aus erster Hand auf Ihr Systemdesign helfen Mandiant-Berater, verborgene logische Fehler, fehlende Vertrauensgrenzen und architektonische Risiken aufzudecken, bevor eine einzige Zeile Code geschrieben wird.

Gilt für A06: Unsicheres Design.

Beachten Sie die folgenden Best Practices:

  • Ziehen Sie Mandiant-Berater hinzu, bevor die Entwicklung beginnt, um Architektur-Workshops abzuhalten und Sicherheitskontrollen von Anfang an zu implementieren.
  • Arbeiten Sie mit Experten für die Bedrohungsmodellierung zusammen, um die Datenflussdiagramme Ihrer Anwendung zu erstellen. Legen Sie fest, wo sensible Daten Vertrauensgrenzen überschreiten, um zu ermitteln, wo strenge Authentifizierungs-, Verschlüsselungs- und Validierungskontrollen erzwungen werden müssen.
  • Verwenden Sie strukturierte Frameworks für die Bedrohungsmodellierung (z. B. STRIDE) bei Ihren Architektur-Workshops. Die Berater von Mandiant können Ihnen helfen, entdeckte Designfehler anhand der tatsächlichen Ausnutzbarkeit und der geschäftlichen Auswirkungen zu priorisieren.
  • Legen Sie sichere KI-Governance-Baselines für Agent-basierte Workflows und LLM-Bereitstellungen fest und definieren Sie klare Vertrauensgrenzen zwischen KI-Agents, MCP-Servern und Unternehmens-Backend-Datenquellen.

Model Armor

Model Armor wurde entwickelt, um LLM-Prompts, ‑Antworten und MCP-Toolaufrufe zu prüfen. Model Armor untersucht Nutzlasten generativer KI, um Prompt Injections, Jailbreak-Versuche, schädliche URLs, schädliche Inhalte und das Durchsickern sensibler Daten zu erkennen und zu blockieren.

Gilt für Folgendes:

  • A05: Injection
  • A10: Falsche Behandlung von Ausnahmesituationen

Hier finden Sie einige Best Practices für A05: Injection:

  • Stellen Sie Model Armor-Richtlinien inline auf der API-Gatewayschicht mit Apigee-Integration oder Agent Gateway bereit, um eingehende Prompts und ausgehende Modellantworten zu filtern, bevor der Traffic Inferenz-Engines oder Tool-Laufzeiten erreicht.
  • Konfigurieren Sie Mindesteinstellungen auf Organisations- oder Ordnerebene, um obligatorische grundlegende Sicherheitsvorkehrungen zu erstellen, die einzelne Projektteams nicht umgehen können.
  • Erstellen Sie benutzerdefinierte Model Armor-Vorlagen mit optimierten Vertrauensschwellenwerten (z. B. LOW_AND_ABOVE oder MEDIUM_AND_ABOVE) für die Erkennung von Prompt-Injection-Angriffen und Jailbreaks an öffentlichen Endpunkten.
  • Aktivieren Sie die Erkennung schädlicher URLs und das Scannen von PDFs und Dateien in Ihrer Model Armor-Vorlage, um eingebettete URLs mit den Threat Intelligence-Datenbanken von Google abzugleichen. Aufforderungen mit Malware- oder Phishing-Vektoren werden vor der Ausführung verworfen.
  • Aktivieren Sie Sensitive Data Protection in Ihrer Model Armor-Vorlage, um den Egress-Traffic des Modells zu prüfen. Konfigurieren Sie die automatische De-Identifizierung oder Maskierung, um erkannte sensible Daten durch Platzhalter zu ersetzen, bevor die Antwort die Grenze verlässt.

Hier finden Sie einige Best Practices für A10: Mishandling of Exceptional Conditions:

  • Konfigurieren Sie Ihren Anwendungscode so, dass er MATCH_FOUND-Ergebnisse abfängt und eine generische Antwort zurückgibt. So wird nicht standardmäßig der Prompt ausgeführt oder rohe Ausnahmetraces werden nicht offengelegt.
  • Implementieren Sie in Ihrem Anwendungscode eine Fail-Closed-Architektur (fail-secure), um eingehende generative KI-Prompts abzulehnen, wenn bei Model Armor API-Aufrufen Netzwerk-Timeouts, Ratenbeschränkungen oder unbehandelte HTTP 5xx-Fehler auftreten.

Organisationsrichtlinie

Mit der Organisationsrichtlinie können Sie die Google Cloud Ressourcen Ihrer Organisation zentral und programmatisch steuern.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A02: Sicherheitsfehlkonfiguration
  • A04: Kryptografische Fehler

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • Erzwingen Sie constraints/storage.publicAccessPrevention, um IAM-Richtlinien oder ACLs auf Bucket-Ebene zu überschreiben, mit denen versucht wird, Zugriff auf allUsers oder allAuthenticatedUsers zu gewähren.
  • Wenden Sie constraints/iam.allowedPolicyMemberDomains an, um IAM-Richtlinienbindungen ausschließlich auf Ihre bestätigten Google Workspace- oder Cloud Identity-Kunden-IDs zu beschränken.
  • Erzwingen Sie die constraints/iam.disableServiceAccountKeyCreation in Produktionsordnern, um zu verhindern, dass Nutzer Dienstkontoschlüssel herunterladen. So werden Entwicklungsteams gezwungen, kurzlebige Alternativen wie die Workload Identity-Föderation zu verwenden.
  • Erzwingen Sie constraints/iam.automaticIamGrantsForDefaultServiceAccounts, damit Google Cloud Standarddienstkonten nicht automatisch die permissive Rolle „Editor“ (roles/editor) zuweist.
  • Für Anforderungen, die nicht durch vordefinierte Einschränkungen abgedeckt werden, können Sie benutzerdefinierte Einschränkungen bereitstellen, um detaillierte Ressourcenkonfigurationen zu erzwingen. Sie können die VM-Erstellung auf genehmigte Maschinenfamilien beschränken, die Bereitstellungsgrößen für nichtflüchtige Speicher begrenzen oder bestimmte Konfigurationen für Netzwerk-Firewall-Tags vorschreiben.

Hier sind einige Best Practices für A02: Sicherheitsfehlkonfiguration:

Hier finden Sie einige Best Practices für A04: Cryptographic Failures:

  • Wenn Sie CMEK erzwingen möchten, wenden Sie constraints/gcp.restrictNonCmekServices auf Organisationsebene oder auf Ordner auf oberster Ebene an, legen Sie den Richtlinientyp auf Deny fest und listen Sie die unterstützten Google Cloud -Dienste auf. Bevor Sie die Einschränkung erzwingen, prüfen Sie, ob der Dienst-Agent für jeden Zieldienst vorhanden ist und ihm die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ (roles/cloudkms.cryptoKeyEncrypterDecrypter) für die relevanten Schlüsselringe zugewiesen ist.
  • Erzwingen Sie constraints/gcp.restrictCmekCryptoKeyProjects, um die Schlüsselauswahl auf dedizierte Cloud KMS-Projekte zu beschränken.

Secret Manager

Mit Secret Manager können Anwendungen und Pipelines auf die Werte benannter Secrets zugreifen, basierend auf Berechtigungen, die mit IAM gewährt wurden. Wenn diese Option aktiviert ist, wird bei Interaktionen mit Secret Manager ein Audit-Trail erstellt, den Sie für forensische Zwecke und zur Einhaltung von Compliance-Anforderungen verwenden können.

Gilt für Folgendes:

  • A04: Kryptografische Fehler
  • A07: Authentifizierungsfehler

Hier finden Sie einige Best Practices für A04: Cryptographic Failures:

Hier sind einige Best Practices für A07: Authentication Failures:

  • Entfernen Sie vertrauliche Werte wie API-Schlüssel aus dem Quellcode, .env-Dateien und Container-Build-Konfigurationen und speichern Sie die Anmeldedaten in Secret Manager. Abrufen entschlüsselter Werte zur Laufzeit mit Google Cloud Clientbibliotheken, GKE-CSI-Treibern für Secret Store oder Cloud Run-Secret-Bindungen.
  • Wenden Sie IAM-Richtlinienbindungen direkt auf bestimmte einzelne Secrets an und gewähren Sie Microservices die Rolle „Secret Manager Secret Accessor“ (roles/secretmanager.secretAccessor) nur für die Secrets, die sie benötigen.
  • Konfigurieren Sie Zeitpläne für die automatische Rotation in Secret Manager. Wenn ein Rotationsintervall beginnt, veröffentlicht Secret Manager eine SECRET_ROTATE-Benachrichtigung in einem bestimmten Pub/Sub-Thema. Konfigurieren Sie eine Cloud Run-Funktion oder einen Cloud Run-Dienst, um die Benachrichtigung zu lesen, einen neuen Secret-Wert zu generieren, die neue Version zu Secret Manager hinzuzufügen und die eingestellte Version zu löschen.
  • Aktivieren Sie Cloud-Audit-Logs für Secret Manager, um Ereignisse zum Erstellen, Löschen und zum Nutzlastzugriff von Secret-Versionen zu verfolgen. Leiten Sie diese Protokolle an Google SecOps weiter, um bei verdächtigen Zugriffsereignissen benachrichtigt zu werden, z. B. wenn ein kompromittiertes Dienstkonto außerhalb der normalen Betriebszeiten auf Secrets zugreift oder versucht, nicht genehmigte Secret-Ressourcen zu lesen.

Security Command Center Premium

Mit Security Command Center Premium können Sie Sicherheitsfehlkonfigurationen und aktive Laufzeitbedrohungen, einschließlich Identifikations- und Authentifizierungsfehlern, in Ihrer Google Cloud-Umgebung und Ihren Webanwendungen finden und beheben. Der Dienst Web Security Scanner kann Anwendungen auf Sicherheitslücken überwachen, einschließlich XXE-Sicherheitslücken (XML External Entity). Die Scans sind zur Abdeckung bestimmter OWASP-Top-10-Steuerelemente vorgesehen.

Gilt für Folgendes:

  • A02: Sicherheitsfehlkonfiguration
  • A05: Injection
  • A07: Authentifizierungsfehler
  • A08: Software- oder Datenintegritätsfehler

Hier sind einige Best Practices für A02: Sicherheitsfehlkonfiguration:

  • Integrierte Frameworks wie die CIS-Benchmarks oder NIST können Sie mit Compliance Manager anwenden, um Ihre Cloud-Konfigurationen anhand von regulatorischen Sicherheitsframeworks und Branchen-Benchmarks zu bewerten.
  • Aktivieren Sie Cloud Infrastructure Entitlement Management, um die Identitäten zu verwalten, die Zugriff auf Ressourcen in Ihren Cloud-Bereitstellungen haben, und potenzielle Sicherheitslücken zu minimieren, die durch Fehlkonfigurationen entstehen.
  • Prüfen und beheben Sie Web Security Scanner-Ergebnisse, um falsch konfigurierte HTTP-Antwort-Sicherheitsheader, ungültige CORS-Ursprungsheader und die Bereitstellung von gemischten Inhalten zu korrigieren.

Hier finden Sie einige Best Practices für A05: Injection:

Hier sind einige Best Practices für A07: Authentication Failures:

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

  • Konfigurieren Sie Web Security Scanner so, dass Webendpunkte auf signaturbasierte Ausführungsfehler gescannt werden und ein STRUTS_INSECURE_DESERIALIZATION-Ergebnis mit hoher Schwere generiert wird, wenn eine Anwendung eine anfällige Apache Struts-Version ausführt.
  • Beheben Sie das Problem STRUTS_INSECURE_DESERIALIZATION, indem Sie die anfällige Framework-Bibliotheksversion aktualisieren oder Assured OSS bereitstellen, um einen von Google bestätigten Ersatz zu erhalten.

Sensitive Data Protection

Mit Sensitive Data Protection können Sie nach potenziell sensiblen Daten suchen, die in Buckets, Datenbanken, generativen KI-Prompts oder Streaminganwendungs-Nutzlasten gespeichert sind, um unbeabsichtigte Datenlecks zu verhindern. Wenn unzulässige Daten identifiziert werden, können diese durch Sensitive Data Protection gekennzeichnet oder entfernt werden.

Gilt für Folgendes:

  • A04: Kryptografische Fehler
  • A09: Fehler beim Sicherheits-Logging und bei Sicherheitsbenachrichtigungen

Hier finden Sie einige Best Practices für A04: Cryptographic Failures:

  • Aktivieren Sie die Erkennung sensibler Daten, um Ihre Speicher- und Datenbank-Assets kontinuierlich zu scannen, Datenprofile zu erstellen und Messwerte für Auditberichte zu melden.
  • Verwenden Sie die formaterhaltende Verschlüsselung, das kryptografische Hashing oder die schlüsselbasierte Tokenisierung, um sensible Daten zu de-identifizieren.
  • Stellen Sie wiederverwendbare, zentral verwaltete Vorlagen für die De-Identifikation bereit, um einheitliche Richtlinien für die kryptografische Maskierung und Prüfung in allen Entwicklungsteams durchzusetzen.
  • Prompt-Nutzlasten analysieren, um zu verhindern, dass sensible Unternehmensdaten oder personenidentifizierbare Informationen in generative KI-Trainingspipelines gelangen.

Hier finden Sie Best Practices für A09: Sicherheits-Logging und Benachrichtigungsfehler:

  • Konfigurieren Sie Ihre Logging-Senke so, dass Anwendungslogs an ein Pub/Sub-Thema gesendet werden. Hängen Sie einen Cloud Run-Abonnenten an, der die Sensitive Data Protection API verwendet, um die Log-Payload zu scannen und zu de-identifizieren, bevor bereinigte Logs in Ihren endgültigen Logging-Bucket geschrieben werden.
  • Verwenden Sie Ausschlussfilter in Ihren Logging-Senken, um nur unstrukturierte Logs mit hohem Risiko (z. B. Rohdaten zu Anwendungsfehlern, Nutzeregistrierungs-Payloads und Transaktionslogs) über die Bereinigungs-Pipeline weiterzuleiten.

VirusTotal

Die VirusTotal API ist eine Plattform für Informationen zu Bedrohungen und zum Scannen von Dateien, die verdächtige Dateien, URLs, Domains und IP-Adressen analysiert, um Malware, Trojaner und schädliche Nutzlasten zu erkennen. Durch die Integration der VirusTotal API in Pipelines für die Dateiaufnahme können Sie nicht vertrauenswürdige Uploads scannen, bevor Dateien von Anwendungssystemen verarbeitet werden.

Gilt für Folgendes:

  • A08: Software- oder Datenintegritätsfehler
  • A05: Injection

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

  • Stellen Sie benutzerdefinierte YARA-X-Regeln für den Signaturabgleich bereit, um eingehende Dateistrukturen nach bekannten schädlichen binären und textuellen Mustern zu scannen und so mutierte Malware-Varianten zu erkennen.

Hier finden Sie einige Best Practices für A05: Injection:

  • Verwenden Sie das VirusTotal Private Scanning-Modul, um vertrauliche Uploads isoliert zu scannen und hochgeladene Dateien nicht an Dritte weiterzugeben.
  • Implementieren Sie in Ihrem Erfassungscode eine API-Ratenbegrenzung und eine Ausnahmebehandlung, um HTTP-Statuscodes 429 Too Many Requests abzufangen.

VPC Service Controls

Mit VPC Service Controls können Sie Perimeter um Ihre Google Cloud Ressourcen erstellen, um Daten-Exfiltration zu verhindern und SSRF-Angriffe (Server-Side Request Forgery) zu minimieren. VPC Service Controls lehnt API-Aufrufe ab, die Perimetergrenzen überschreiten, sofern sie nicht explizit durch Regeln für ein- und ausgehenden Traffic zugelassen sind.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A02: Sicherheitsfehlkonfiguration

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • Nehmen Sie kritische Dienste wie Cloud Storage, BigQuery, Spanner und die Agent Platform in einen Dienstperimeter auf, um den API-Zugriff auf autorisierte VPC-Netzwerke und vertrauenswürdige Identitäten zu beschränken.
  • Konfigurieren Sie Perimeterregeln für ausgehenden Traffic für serverlose Ressourcen, um unbefugte Daten-Exfiltration zu verhindern, die durch ausgehende API-Aufrufe an externe Ziele außerhalb des Perimeters verursacht wird.
  • Schränken Sie den API-Zugriff über Perimeter und Organisationen hinweg mit expliziten Ingress- und Egress-Regeln ein, in denen genehmigte Projektquellen, Ziel-APIs und Aufruferidentitäten angegeben sind.

Hier sind einige Best Practices für A02: Sicherheitsfehlkonfiguration:

  • Gruppieren Sie Projekte in dedizierten Perimetern, die nach Sicherheitsstufe der Umgebung organisiert sind (z. B. ein Produktionsperimeter). Verwenden Sie über VPC zugängliche Dienste, um einzuschränken, welche internen Google-APIs innerhalb des Perimeters aufgerufen werden können.
  • Leiten Sie ausgehende API-Anfragen von serverlosen Arbeitslasten über das VPC-Netzwerk weiter. Konfigurieren Sie Cloud Run-Dienste und Cloud Run-Funktionen für die Verwendung von ausgehendem Direct VPC-Traffic oder eines Connectors für serverlosen VPC-Zugriff, bei dem der eingehende Traffic ausschließlich auf intern festgelegt ist.
  • Binden Sie Access Context Manager-Zugriffsebenen an Ihre Perimeter-Ingress-Regeln, die eine Kombination aus Unternehmens-IP-Subnetzen, Ansprüchen zur authentifizierten Identität und Signalen zum Gerätezustand der Endpunktprüfung auswerten.
  • Richten Sie einen vorab genehmigten Breakglass-Administrationsprozess für die Reaktion auf Notfallvorfälle ein und konfigurieren Sie Monitoring-Benachrichtigungen für alle unerwarteten Ereignisse, die gegen den Perimeter verstoßen.

Wiz-Dienste

In den folgenden Abschnitten werden die OWASP Top 10-Best Practices für Wiz-Dienste beschrieben, die inGoogle Cloudintegriert sind.

Wiz Code

Wiz Code erweitert die Cloudsicherheit auf Entwickler-Workflows und CI/CD-Pipelines. Wiz Code korreliert Code-to-Cloud-Telemetriedaten, scannt Infrastructure as Code (IaC), analysiert Abhängigkeiten (SCA), erkennt offengelegte Anmeldedaten und führt statische Anwendungssicherheitstests (SAST) durch.

Gilt für Folgendes:

  • A03: Fehler in der Softwarelieferkette
  • A05: Injection
  • A07: Authentifizierungsfehler

Hier finden Sie einige Best Practices für A03: Fehler in der Softwarelieferkette:

  • Sie können die Wiz-Befehlszeilenschnittstelle in CI/CD-Pipelines einbinden, um zu verhindern, dass Pull-Anfragen zusammengeführt werden, wenn sie kritische CVEs, offengelegte vertrauliche Informationen oder schwerwiegende IaC-Fehlkonfigurationen in geschützte Branches einführen.
  • Generieren und exportieren Sie für jeden Build eine SBOM, um die kontinuierliche Sichtbarkeit der Lieferkette in Wiz Cloud aufrechtzuerhalten.
  • Stellen Sie Wiz Code IDE-Erweiterungen bereit, um Entwicklern in Echtzeit Feedback zu geben und anfällige Pakete, fest codierte API-Schlüssel und Syntaxfehler vor dem Committen von Code zu erkennen.
  • Wiz Code mit CodeMender in CI/CD-Pipelines einbinden, um Pull-Anfragen zu generieren, zu testen und zu senden, wenn anfällige Drittanbieterabhängigkeiten erkannt werden.

Hier finden Sie einige Best Practices für A05: Injection:

  • Das Zusammenführen von Pull-Anfragen blockieren, wenn der SAST-Scanner erkennt, dass nicht vertrauenswürdige Nutzereingaben ohne ordnungsgemäße Bereinigung in Datenbankabfragen oder Betriebssystembefehle einfließen.
  • Das Wiz Code-Plug-in kann in IDEs für Entwickler integriert werden, um Echtzeitwarnungen auszugeben, wenn Entwickler unsichere Muster für die Verkettung von SQL-Abfrage oder die Ausführung von Befehlen eingeben.
  • Wenn Wiz Code eine Injection-Schwachstelle meldet, leiten Sie Dataflow-Traces an CodeMender weiter, um einen verifizierten Behebungspatch zu erstellen.

Hier sind einige Best Practices für A07: Authentication Failures:

  • Implementieren Sie automatisierte Secret-Scans in Entwickler-IDEs, lokalen Pre-Commit-Hooks und in CI/CD-Pipelines, um offengelegte Anmeldedaten zu erkennen.
  • Um Anmeldedatendiebstahl zu verhindern, sollten Sie statische, langlebige Anmeldedaten durch dynamische, kurzlebige Tokens und identitätsgebundenen Zugriff (z. B. Workload Identity-Föderation oder OIDC-basierte Authentifizierung) ersetzen.
  • Implementieren Sie ein automatisiertes Incident-Response-Playbook, um erkannte vertrauliche Informationen aus Code, Umgebungsvariablen und Build-Logs zu entfernen.

Wiz Cloud

Wiz Cloud analysiert Multi-Cloud-Umgebungen, um Sicherheitsfehlkonfigurationen, die Offenlegung sensibler Daten und Identitätsrisiken zu erkennen. Mit dem Wiz Security Graph korreliert Wiz Cloud Risikofaktoren über Infrastrukturschichten hinweg, um kritische Angriffspfade hervorzuheben.

Gilt für Folgendes:

  • A01: Fehlerhafte Zugriffssteuerung
  • A02: Sicherheitsfehlkonfiguration
  • A04: Kryptografische Fehler
  • A06: Unsicheres Design

Hier finden Sie einige Best Practices für A01: Fehlerhafte Zugriffssteuerung:

  • Komplexe, mehrstufige Pfade zur Rechteausweitung über IAM-Rollen und ‑Richtlinien hinweg nachvollziehen und kennzeichnen, um zu ermitteln, wo Angreifer sich seitlich bewegen oder Rechte ausweiten könnten.
  • Ordnen Sie aktive Zugriffsberechtigungen für Nutzerkonten, Dienstkonten und KI-Agents kritischen Datenspeichern zu und widerrufen Sie Berechtigungen mit zu hohen Berechtigungen.
  • Binden Sie Ergebnisse zu Identitätsberechtigungen in Orchestrierungsplattformen ein, um permanente administrative Rollenbindungen durch JIT-Zugriff (Just-in-Time) zu ersetzen.
  • Bewegen Sie Daten, um zu erkennen, wann personenidentifizierbare Informationen aus der Produktion in unsichere Staging- oder Entwicklungsumgebungen kopiert oder synchronisiert werden.

Hier sind einige Best Practices für A02: Sicherheitsfehlkonfiguration:

  • Bewerten und priorisieren Sie das Risiko von Cloud-Konfigurationen, indem Sie Fehlkonfigurationen mit mehreren Angriffsfaktoren mithilfe des Wiz Security Graph in Beziehung setzen.
  • Wenden Sie integrierte Compliance-Frameworks wie OWASP Top 10, CIS Benchmarks und NIST an, um Cloud-Konfigurationen anhand von Branchenstandards zu messen.
  • Binden Sie den Wiz CLI-Scanner in CI/CD-Pipelines ein, um Builds zu überprüfen oder IaC-Fehlkonfigurationen vor der Bereitstellung zu beheben.

Hier finden Sie einige Best Practices für A04: Cryptographic Failures:

  • Priorisieren Sie die Bereinigung von Datenbanken und Speicher-Buckets, die Anmeldedaten im Klartext, nicht gehashte Schlüssel oder sensible Daten ohne Verschlüsselung enthalten.
  • Führen Sie die Wiz Cloud-Datenerkennung in KI-Trainingsverzeichnissen, Vektordatenbanken und RAG-Pipelines aus, um zu prüfen, ob proprietäre Daten und personenbezogene Daten vor der LLM-Aufnahme entfernt werden.
  • Scannen Sie Umgebungen, um nicht verwaltete Daten-Assets zu identifizieren, und löschen Sie redundante Daten, um Ihre Angriffsfläche zu minimieren.

Hier finden Sie einige Best Practices für A06: Unsicheres Design:

  • Weisen Sie Wiz Red Agent an, logische Architekturschnittstellen zu analysieren und Angriffspfade zu simulieren, um unsichere Designfehler vor der Bereitstellung in der Produktion zu finden.
  • Geben Sie validierten Kontext für Angriffsketten von Wiz Red Agent an CodeMender weiter, um Ursachen zu ermitteln und getestete Pull-Anfragen für die Architektur zu generieren.

Wiz Defend

Wiz Defend bietet Cloud Detection and Response (CDR), Laufzeitschutz für Arbeitslasten und Kubernetes-Zugangssicherheit. Wiz Defend überwacht die Aktivitäten der Steuerungsebene, erkennt Laufzeitanomalien, erzwingt Richtlinien für die Aufnahme von Containern und löst die automatische Eindämmung aus.

Gilt für Folgendes:

  • A08: Software- oder Datenintegritätsfehler
  • A09: Fehler beim Sicherheits-Logging und bei Sicherheitsbenachrichtigungen

Beachten Sie die folgenden Best Practices für A08: Software- oder Datenintegritätsfehler:

  • Konfigurieren Sie Wiz Defend-Zulassungsregeln, um Kubernetes-Bereitstellungsmanifeste zu prüfen und abzulehnen, mit denen versucht wird, Container mit Root-Berechtigungen auszuführen, Hostnetzwerk-Namespaces anzufordern oder privileged: true zu aktivieren.
  • Konfigurieren Sie kritische Sicherheits-Zulassungs-Webhooks mit failurePolicy: Fail (fail-closed) in der Produktion, um nicht vertrauenswürdige Container zu blockieren, wenn der Webhook nicht erreichbar ist.

Hier finden Sie Best Practices für A09: Sicherheits-Logging und Benachrichtigungsfehler:

  • Exportieren Sie Google Cloud Audit-Logs über eine Logs-Senke in ein Pub/Sub-Thema, damit Wiz Defend Aktivitäten der Steuerungsebene und Arbeitslastereignisse aufnehmen und analysieren kann.
  • Stellen Sie den Wiz Runtime Sensor in GKE-Clustern und wichtigen Compute Engine-VMs bereit, um Laufzeitbedrohungen, Exploits im Arbeitsspeicher und aktive Kompromittierungen zu erkennen.
  • Automatisieren Sie Eindämmungs-Playbooks, um kompromittierte IAM-Dienstkonten sofort zu deaktivieren oder kompromittierte Arbeitslasten zu isolieren.
  • Mit Wiz Blue Agent können Sie Laufzeiterkennungen untersuchen und Live-Prozesstelemetrie und Identitätskontext korrelieren, um Ursachen und betroffene Assets zu ermitteln.

Einhaltung der OWASP Top 10:2025

Wiz enthält ein Framework zur Einhaltung der OWASP Top 10 2025, mit dem Sie Ihre Sicherheitslage bewerten und überwachen können. Das Compliance-Framework für die OWASP Top 10 2025 ordnet integrierte Wiz-Richtlinien den relevanten OWASP-Risikokategorien zu und erstellt Ergebnisse, wenn eine Richtlinie nicht konform ist. Sie können Ihren Compliancewert im Zeitverlauf verfolgen. Bei Bedarf können Sie das Compliance-Framework „OWASP Top 10 2025“ an Ihre Geschäftsanforderungen anpassen.

Nächste Schritte

Weitere Best Practices finden Sie im Katalog mit Best Practices für die Sicherheit.