Bereitstellungen absichern

In diesem Dokument werden Best Practices zum Schutz Ihrer Bereitstellungen beschrieben.

Bereitstellungsrichtlinien erstellen und erzwingen

Zum Schutz Ihrer Laufzeitumgebungen definieren Sie Richtlinien mit Kriterien für die Bereitstellung und validieren die Richtliniencompliance vor und nach der Bereitstellung. Wenn Sie eine Richtlinie definieren, die nur von vordefinierten Attestierern signierten Code zulässt, können Sie Bereitstellungen schützen und nur Code von vertrauenswürdigen Ursprüngen bereitstellen.

Beispiele für Bereitstellungskriterien:

  • Keine bekannten Sicherheitslücken mit einem Schweregrad über „Mittel“
  • Der Quellcode stammt aus einem vertrauenswürdigen Quell-Repository
  • Ein vertrauenswürdiger Build-Dienst hat den Build ausgeführt
  • Bereitgestellte Build-Artefakte stammen aus einem vertrauenswürdigen Artefakt-Repository

Metadaten generieren

Zur Validierung dieser Anforderungen müssen Sie Metadaten zu Ihren Build-Artefakten bereitstellen.

Build-Ursprünge

Die Build-Herkunft ist eine Sammlung überprüfbarer Daten zu einem Build, z. B. die Digests der erstellten Images, die Speicherorte der Eingabequellen, die Build-Toolchain und die Build-Dauer. SLSA, ein Framework zur Bewertung des Sicherheitsstatus, bietet ein Modell für die Herkunft und Anforderungen an die Herkunft. Die Herkunft ist eine Anforderungskategorie im Framework und jede Anforderung ist mit SLSA-Ebenen verknüpft, sodass Sie Abhilfemaßnahmen schrittweise implementieren können.

  • Für SLSA-Level-1-Sicherheit muss die Herkunft verfügbar sein.
  • Für die SLSA-Level-2-Sicherheit muss die Herkunft generiert werden und die Nutzer müssen in der Lage sein, ihre Authentizität und Integrität zu bestätigen.
  • Die SLSA-Level 3 und 4 haben strengere Anforderungen an das Signieren der Herkunft und die Detailtiefe der Herkunftsdaten.

Einige Build-Dienste generieren Build-Herkunftsmetadaten.

Sicherheitslücken

Software zum Scannen auf Sicherheitslücken prüft Ihren Quellcode und Build-Artefakte auf bekannte Sicherheitslücken. Die Artefaktanalyse kann Container-Images, die per Push-Funktion an Artifact Registry übertragen werden, automatisch auf Sicherheitslücken scannen. Wenn Sie Artefakte vor dem Speichern auf Sicherheitslücken prüfen möchten, können Sie die On-Demand Scanning API in einer lokalen Entwicklungsumgebung oder in einer CI/CD-Pipeline wie einem Cloud Build-Build-Schritt verwenden.

Richtlinienerzwingung einrichten

Wenn Sie Metadaten zu Ihren bereitstellbaren Artefakten haben, benötigen Sie Tools, um Ihre Richtlinien durchzusetzen.

In Google Cloud können Sie in der Binärautorisierung eine Richtlinie für Ihre Bereitstellungen konfigurieren. Die Binärautorisierung erzwingt eine Richtlinie für versuchte Bereitstellungen auf unterstützten containerbasierten Plattformen. Er kann auch eine kontinuierliche Validierung der Richtlinien für Arbeitslasten durchführen, die in GKE, Cloud Run und GKE Enterprise ausgeführt werden.

Prüfungen vor der Bereitstellung können alle Images blockieren, die nicht in der Liste der ausgenommenen Images enthalten sind. So werden nur vertrauenswürdige Images aus vertrauenswürdigen Registries bereitgestellt. Ihre Richtlinie kann auch attestations erfordern. Das sind digitale Dokumente, die anzeigen, dass das Image erfolgreich mit einem bestimmten erforderlichen Prozess erstellt wurde. In einer Attestierung kann beispielsweise angegeben werden, dass ein Bild

Die kontinuierliche Validierung dehnt die Richtlinienvalidierung auf die Umgebung aus, die nach der Bereitstellung erfolgt. Wenn diese Option aktiviert ist, bietet die Binärautorisierung während des gesamten Pod-Lebenszyklus eine Validierung, da die Richtlinienkonformität regelmäßig in Cloud Logging protokolliert wird. Dies ist in verschiedenen Situationen nützlich. Wenn Sie beispielsweise nach der Bereitstellung eines Containers Ihre Richtlinie ändern, werden Pods, die gegen die aktualisierte Richtlinie verstoßen, von der kontinuierlichen Validierung protokolliert. Außerdem werden Richtlinienverstöße für Pods protokolliert, die mit einem Probelauf oder Break-Glass bereitgestellt wurden.

Gated Bereitstellungsdienste verwenden

Mit einem Deployment-Gating können Sie Bereitstellungen an bestimmten Punkten im Bereitstellungsprozess mithilfe eines eigenständigen CI/CD-Dienstes oder eines CI/CD-Dienstes, der in ein Prozessautomatisierungssystem integriert ist, genehmigen oder ablehnen. Gated Deployments verhindern, dass unbefugte Nutzer Änderungen an Anwendungsumgebungen vornehmen. Sie bieten zusätzliche Kontrolle über den Bereitstellungsprozess und eine höhere Sichtbarkeit von Genehmigungen.

In Google Cloud bietet Cloud Deploy einen vollständig verwalteten Dienst zum Bereitstellen von Arbeitslasten in Google Kubernetes Engine. Mit der Funktion für die gatewaygesteuerte Bereitstellung können Nutzer angeben, ob eine Genehmigung für das Hochstufen auf ein Ziel erforderlich ist.

Arbeitslasten überwachen

Arbeitslasten sind Anwendungen, die auf containerbasierten Plattformen wie GKE und Cloud Run ausgeführt werden. Die von Ihnen bereitgestellten Arbeitslasten sollten idealerweise eine gehärtete Konfiguration haben, die ihre Angriffsfläche begrenzt.

Die manuelle Überprüfung von Arbeitslasten in Clustern auf Konfigurationsprobleme in großem Umfang kann schwierig sein. Software Delivery Shield ist eine vollständig verwaltete Lösung für die Sicherheit der Softwarelieferkette in Google Cloud. Sie bietet Dashboards in Cloud Run und die GKE-UI in der Google Cloud Console, um Sicherheitsinformationen für Arbeitslasten anzusehen.

Das Dashboard für den GKE-Sicherheitsstatus bietet Ihnen eine Anleitung, wie Sie den Sicherheitsstatus Ihrer Cluster gemäß den Empfehlungen von Google verbessern können. Dazu gehört das automatische Scannen der Arbeitslastkonfiguration, das alle bekannten Konfigurationsprobleme in allen Arbeitslasten prüft. GKE prüft jede bereitgestellte Arbeitslast anhand relevanter branchenüblicher Best Practices, z. B. Richtlinien in den Pod-Sicherheitsstandards. GKE bewertet den Schweregrad erkannter Probleme und gibt umsetzbare Empfehlungen und Logs zurück. Sie können Cloud Logging verwenden, um einen überprüfbaren Spur von Bedenken zu erhalten und so die Berichterstellung und Beobachtbarkeit zu verbessern. Eine Anleitung zum Aufrufen von Sicherheitsinformationen im Dashboard für den GKE-Sicherheitsstatus finden Sie unter In GKE bereitstellen und Sicherheitsinformationen ansehen.

Cloud Run enthält einen Sicherheitsbereich mit Informationen zur Softwarelieferkette, z. B. Complianceinformationen auf SLSA-Build-Ebene, Build-Herkunft und Sicherheitslücken in ausgeführten Diensten. Eine Anleitung zum Aufrufen von Sicherheitsinformationen im Bereich „Sicherheitsinformationen“ von Cloud Run finden Sie unter In Cloud Run bereitstellen und Sicherheitsinformationen ansehen.

Software Delivery Shield bietet außerdem weitere Dienste und Funktionen, mit denen Sie Ihren Sicherheitsstatus im gesamten Softwareentwicklungszyklus verbessern können. Weitere Informationen finden Sie unter Software Delivery Shield – Übersicht.

Nächste Schritte