Erklärung zur gemeinsamen Verantwortung für die Sicherheit

Für das Ausführen geschäftskritischer Arbeitslasten in Cloud Build müssen mehrere Parteien unterschiedliche Verantwortlichkeiten übernehmen. Das in diesem Dokument beschriebene Modell der gemeinsamen Verantwortung verdeutlicht, dass Google Cloud für die Sicherheit des Cloud Build-Dienstes selbst und der zugrunde liegenden Infrastruktur verantwortlich ist. Sie als Kunde sind hingegen für die Sicherheit bei der Verwendung von Cloud Build verantwortlich, einschließlich Ihrer spezifischen Builds, Konfigurationen, Daten und der Container-Images, die Sie mit Cloud Build ausführen.

Auf dieser Seite finden Sie eine nicht vollständige Liste der jeweiligen Verantwortlichkeiten von Google Cloud und dem Kunden.

Verantwortlichkeiten von Google Cloud

  • Schutz der zugrunde liegenden Infrastruktur, einschließlich Hardware, Firmware, Kernel, Betriebssystem, Speicher und Netzwerk.

    Der Support umfasst

    • Schutz der physischen Sicherheit von Rechenzentren, Standardverschlüsselung von Daten im Ruhezustand und bei der Übertragung sowie sichere Netzwerkkomponenten.
    • Netzwerkschutz mit VPC Service Controls
    • Best Practices für die sichere Softwareentwicklung
    • Verwaltung und Sicherung der Cloud Build-Dienststeuerungsebene (API, Backend, Planer usw.), einschließlich Patching und Härten.
    • Bereitstellung von kurzlebigen, isolierten Build-Umgebungen für jeden Build-Aufruf.

  • Bereitstellen von Google Cloud-Integrationen für Identity and Access Management (IAM), Cloud-Audit-Logs, Cloud Key Management Service und andere.

  • Beschränkung des administrativen Zugriffs von Google Cloud auf Kundenressourcen für vertragliche Supportzwecke mit Access Transparency und Access Approval sowie Protokollierung aller Zugriffe.

  • Erstellen authentischer SLSA-Herkunftsnachweise, wenn entsprechend konfiguriert.

Pflichten des Kunden

  • Sichern Sie den Quellcode Ihrer Anwendung, die Build-Konfigurationsdateien und alle Container-Images, die in Ihren Builds verwendet werden.

    Dazu gehört, die Eignung von Images für Ihre Sicherheitsstandards zu bewerten, die neuesten unterstützten Image-Versionen zu nutzen und Best Practices für Open-Source-Komponenten und die allgemeine Build-Konfiguration zu befolgen.

    Für Szenarien, die ein Höchstmaß an Sicherheit erfordern, sollten Sie eigene gehärtete Images für die Ausführung von Builds verwenden.

  • Sorgen Sie dafür, dass alle Tokens für die Integration von Drittanbietern (z. B. Tokens, die zum Einrichten einer Repository-Verknüpfung bereitgestellt werden) angemessen geschützt sind.

  • IAM für alle Nutzer, Gruppen und Dienstkonten konfigurieren, die mit Cloud Build interagieren, gemäß dem Prinzip der geringsten Berechtigung.

    Wir empfehlen, für Builds benutzerdefinierte Dienstkonten anstelle von Standardkonten zu verwenden.

    Achten Sie darauf, dass in Ihren Build-Skripts die bereitgestellten Build-Anmeldedaten, Drittanbieter-Integrationstokens und Secrets, die für den Build verfügbar sind, angemessen verwendet werden, und schützen Sie sich vor Datenexfiltration.

  • Aktivieren und Reagieren auf das Scannen von Build-Artefakten auf Sicherheitslücken (z. B. mit der Artefaktanalyse), Generieren von Build-Herkunftsdaten und Implementieren von Bereitstellungsrichtlinien (z. B. mit der Binärautorisierung), um sicherzustellen, dass nur autorisierte und verifizierte Images bereitgestellt werden.

  • Wählen Sie eine Release-Version aus, die zu Ihrem Sicherheitsstatus und Ihrer Toleranz für Änderungen passt.

  • Google auf Anfrage Details zur Umgebung zur Verfügung stellen, damit Probleme behoben werden können.

Nächste Schritte