Bereitstellungen absichern

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

Bereitstellungsrichtlinien erstellen und erzwingen

Definieren Sie zum Schutz Ihrer Laufzeitumgebung Richtlinien mit Kriterien für die Bereitstellung und validieren Sie die Richtliniencompliance vor und nach der Bereitstellung. Wenn Sie eine Richtlinie definieren, die nur Code zulässt, der von vordefinierten Attestierern signiert ist, können Sie Bereitstellungen verwalten und nur Code aus vertrauenswürdigen Quellen bereitstellen.

Beispiele für Bereitstellungskriterien:

  • Keine bekannten Sicherheitslücken mit einem Schweregrad über Mittel
  • Quellcode aus einem vertrauenswürdigen Quell-Repository
  • Ein Build wurde von einem vertrauenswürdigen Build-Dienst ausgeführt
  • Von Ihnen bereitgestellte Build-Artefakte stammen aus einem vertrauenswürdigen Artefakt-Repository

Metadaten generieren

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

Build-Quellen

Die Build-Herkunft ist eine Sammlung überprüfbarer Daten zu einem Build, z. B. die Digests der erstellten Images, die Speicherorte der Eingabequelle, die Build-Toolchain und die Build-Dauer. SLSA, ein Framework zum Bewerten des Sicherheitsstatus, bietet ein Modell für die Herkunft und Anforderungen für die Herkunft. Die Provenance ist eine Anforderungskategorie im Framework und jede Anforderung ist mit SLSA-Ebenen verknüpft, damit Sie Risiken minimieren können.

  • Für die SLSA-Prüfung der Stufe 1 muss die Herkunft nachgewiesen werden.
  • Für die SLSA-Prüfung der Ebene 2 müssen die Herkunft ausgestellt und die Nutzer müssen in der Lage sein, ihre Authentizität und Integrität zu bestätigen.
  • Für die SLSA-Level 3 und 4 gelten strengere Anforderungen an die Signatur von Provenance und die Erhebung von Details zu Herkunftsdaten.

Einige Build-Dienste generieren Metadaten zur Build-Herkunft.

  • In Google Cloud generiert Cloud Sign eine Build-Herkunft für Container-Images, die SLSA-Level-3-Builds unterstützen.
  • Das SLSA-Framework bietet eine GitHub-Herkunftstools. Die Tools generieren auf GitHub nicht verfälschbare SLSA-Herkunft, die den Anforderungen in den Kategorien build und provenance für SLSA-Level 3 entspricht.
  • Das Open-Source-Projekt sigstore enthält das Tool cosign zum Signieren von Containern.
Sicherheitslücken

Software zum Scannen auf Sicherheitslücken prüft den Quellcode und erstellt Artefakte auf bekannte Sicherheitslücken. Container Analysis kann Container-Images, die an Artifact Registry übertragen wurden, 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.

Durchsetzung der Richtlinien einrichten

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

In Google Cloud können Sie in der Binärautorisierung eine Richtlinie für Ihre Bereitstellungen konfigurieren. Die Binärautorisierung erzwingt Richtlinien für versuchte Bereitstellungen auf unterstützten containerbasierten Plattformen. Außerdem können damit Richtlinien für Arbeitslasten, die in GKE, Cloud Run und Anthos ausgeführt werden, kontinuierlich validiert werden.

Durch Prüfungen vor der Bereitstellung können alle Images blockiert werden, die nicht in der ausgenommenen Image-Liste enthalten sind, sodass nur vertrauenswürdige Images aus vertrauenswürdigen Registrys bereitgestellt werden. Sie kann auch Attestierungen (digitale Dokumente) verlangen, die anzeigen, dass das Image erfolgreich mit einem bestimmten, erforderlichen Prozess erstellt wurde. Eine Bestätigung kann beispielsweise Folgendes zeigen:

Bei der kontinuierlichen Validierung wird die Richtlinienvalidierung auf die Umgebung nach der Bereitstellung ausgeweitet. Wenn diese Option aktiviert ist, bietet die Binärautorisierung während des gesamten Pod-Lebenszyklus eine Validierung. Dazu wird die Richtliniencompliance in Cloud Logging regelmäßig protokolliert. Das ist in verschiedenen Situationen hilfreich. Wenn Sie beispielsweise Ihre Richtlinie nach der Bereitstellung eines Containers ändern, werden Pods, die gegen die aktualisierte Richtlinie verstoßen, bei der kontinuierlichen Überprüfung protokolliert. Außerdem werden Richtlinienverstöße für Pods protokolliert, die mit Probelauf oder Break-Glass bereitgestellt wurden.

Geschlossene Bereitstellungsdienste verwenden

Mit Bereitstellungs-Gating können Sie Bereitstellungen an bestimmten Punkten im Bereitstellungsprozess mit einem eigenständigen CI/CD-Dienst oder einem CI/CD-Dienst in einem Prozessautomatisierungssystem genehmigen oder ablehnen. Gate-Bereitstellungen verhindern, dass nicht autorisierte Nutzer Änderungen an Anwendungsumgebungen vornehmen. Sie bieten zusätzliche Kontrollmöglichkeiten für den Bereitstellungsprozess und eine bessere Sichtbarkeit von Genehmigungen.

In Google Cloud bietet Google Cloud Deploy einen vollständig verwalteten Dienst zum Bereitstellen von Arbeitslasten in Google Kubernetes Engine. Mit der Funktion zur gatewaygesteuerten Bereitstellung können Nutzer angeben, ob eine Genehmigung für das Hochstufen zu einem 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.

Es ist schwierig, Arbeitslasten in verschiedenen Clustern auf Konfigurationsprobleme zu prüfen, um sie in großem Umfang manuell auszuführen. Software Delivery Shield ist eine vollständig verwaltete Sicherheitslösung für die Softwarelieferkette in Google Cloud, die Dashboards in Cloud Run und der GKE-UI in der Google Cloud Console bietet, um Sicherheitsinformationen für Arbeitslasten anzusehen.

Das Dashboard für den Sicherheitsstatus von GKE bietet eine Anleitung zum Optimieren des Sicherheitsstatus Ihrer Cluster anhand der Empfehlungen von Google. Er umfasst das automatische Scannen der Arbeitslastkonfiguration, mit dem nach bekannten Konfigurationsproblemen für alle Arbeitslasten geprüft wird. GKE prüft jede bereitgestellte Arbeitslast auf relevante branchenübliche 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 mithilfe von Cloud Logging einen prüfbaren Pfad von Bedenken ermitteln, um die Berichterstellung und Beobachtbarkeit zu verbessern. Eine Anleitung zum Aufrufen von Sicherheitsstatistiken im Dashboard zum GKE-Sicherheitsstatus finden Sie unter In GKE bereitstellen und Sicherheitsstatistiken ansehen.

Cloud Run enthält einen Sicherheitsbereich mit Informationen zur Sicherheit der Softwarelieferkette wie SLSA-Informationen zur Compliance auf Build-Ebene, zur Herkunft von Builds und zu Sicherheitslücken in ausgeführten Diensten. Eine Anleitung zum Aufrufen von Sicherheitsstatistiken im Bereich „Cloud Run-Sicherheitsstatistiken“ finden Sie unter In Cloud Run bereitstellen und Sicherheitsstatistiken ansehen.

Software Delivery Shield bietet auch andere 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