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 werden die jeweiligen Verantwortlichkeiten von Google Cloud und dem Kunden aufgeführt. Die Liste ist jedoch nicht vollständig.

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 inaktiven und übertragenen Daten sowie sichere Netzwerkkomponenten.
    • Netzwerkschutz mit VPC Service Controls
    • Best Practices für die sichere Softwareentwicklung einhalten
    • Verwaltung und Sicherung der Cloud Build-Dienststeuerungsebene (API, Backend, Planer usw.), einschließlich Patching und Härten.
    • Sitzungsspezifische, isolierte Build-Umgebungen für jeden Build-Aufruf bereitstellen.

  • Bereitstellung 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.

  • Authentische SLSA-Herkunft erstellen, wenn dies konfiguriert ist.

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 Grundsatz der geringsten Berechtigung.

    Wir empfehlen, für Builds dedizierte, 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 gemacht werden, angemessen verwendet werden und dass sie vor Exfiltration geschützt sind.

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

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

Nächste Schritte