Bereitstellungen schützen

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

Bereitstellungsrichtlinien erstellen und erzwingen

Um Ihre Laufzeitumgebungen zu schützen, definieren Sie Richtlinien mit Kriterien für die Bereitstellung und prüfen Sie die Einhaltung der Richtlinien vor und nach der Bereitstellung. Wenn Sie eine Richtlinie definieren, die nur Code zulässt, der von vordefinierten Attestatoren signiert wurde, können Sie Bereitstellungen steuern und nur Code aus vertrauenswürdigen Quellen bereitstellen.

Beispiele für Bereitstellungskriterien:

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

Metadaten generieren

Um diese Anforderungen zu erfüllen, müssen Sie Metadaten zu Ihren Build-Artefakten angeben.

Ursprünge erstellen

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 der Sicherheitslage, bietet ein Modell für die Herkunft und Anforderungen an die Herkunft. Die Provenienz ist eine der Anforderungskategorien im Framework. Jede Anforderung ist mit SLSA-Stufen verknüpft, damit Sie Maßnahmen schrittweise implementieren können.

  • Für die SLSA-Bestätigung der Stufe 1 muss die Provenienz verfügbar sein.
  • Für die SLSA-Bestätigung der Stufe 2 muss die Provenienz generiert werden und die Verbraucher müssen die Echtheit und Integrität überprüfen können.
  • Für die SLSA-Stufen 3 und 4 gelten strengere Anforderungen an die Signatur der Herkunftsnachweise und an die Detailgenauigkeit der Herkunftsdaten.

Einige Build-Dienste generieren Metadaten zur Build-Herkunft.

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

Software zum Scannen von Sicherheitslücken prüft Ihren Quellcode und Build-Artefakte auf bekannte Sicherheitslücken. Mit der Artefaktanalyse können Container-Images, die in die Artifact Registry gepusht werden, automatisch auf Sicherheitslücken geprüft werden. 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.

Richtliniendurchsetzung einrichten

Sobald Sie Metadaten zu Ihren ausführbaren Artefakten haben, benötigen Sie Tools, um Ihre Richtlinien durchzusetzen.

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

Mit Vorabprüfungen können alle Images blockiert werden, die nicht auf der Liste der ausgenommenen Images stehen, sodass nur vertrauenswürdige Images aus vertrauenswürdigen Registries bereitgestellt werden. Ihre Richtlinie kann auch Attestierungen erfordern, also digitale Dokumente, die bestätigen, dass das Image mit einem bestimmten, erforderlichen Prozess erfolgreich erstellt wurde. Eine Attestierung kann beispielsweise angeben, dass ein Bild:

Bei der kontinuierlichen Validierung wird die Richtlinienvalidierung auf die Umgebung nach der Bereitstellung ausgeweitet. Wenn die Binärautorisierung aktiviert ist, wird die Richtlinienkonformität während des gesamten Pod-Lebenszyklus validiert, indem die Richtlinienkonformität regelmäßig in Cloud Logging protokolliert wird. Das ist in vielen Situationen nützlich. Wenn Sie beispielsweise Ihre Richtlinie nach der Bereitstellung eines Containers ändern, werden bei der kontinuierlichen Validierung Pods protokolliert, die gegen die aktualisierte Richtlinie verstoßen. Außerdem werden Richtlinienverstöße für Pods protokolliert, die mit Dry Run oder Break-Glass bereitgestellt wurden.

Dienste für die stufenweise Bereitstellung verwenden

Mit dem Bereitstellungsgatter können Sie Bereitstellungen an bestimmten Stellen im Bereitstellungsprozess mithilfe eines eigenständigen CI/CD-Dienstes oder eines CI/CD-Dienstes genehmigen oder ablehnen, der in ein Prozessautomatisierungssystem eingebunden ist. Durch gesteuerte Bereitstellungen wird verhindert, dass nicht autorisierte Nutzer Änderungen an Anwendungsumgebungen vornehmen. Sie bieten zusätzliche Kontrolle über den Bereitstellungsprozess und eine bessere Sichtbarkeit von Genehmigungen.

In Google Cloud bietet Cloud Deploy einen vollständig verwalteten Dienst zum Bereitstellen von Arbeitslasten in der Google Kubernetes Engine. Mit der Funktion Gesperrte Bereitstellung können Nutzer angeben, ob für die Beförderung zu einem Ziel eine Genehmigung 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 die Angriffsfläche begrenzt.

Das clusterübergreifende Prüfen von Arbeitslasten auf Konfigurationsprobleme ist manuell im großen Maßstab schwierig durchzuführen. Google Cloud bietet Dashboards in Cloud Run und GKE, um Sicherheitserkenntnisse für Arbeitslasten aufzurufen.

Das GKE-Dashboard für den Sicherheitsstatus bietet Ihnen mithilfe von Google-Empfehlungen Hinweise dazu, wie Sie den Sicherheitsstatus Ihrer Cluster verbessern können. Dazu gehört das automatische Scannen der Arbeitslastkonfiguration, bei dem bei allen Arbeitslasten nach bekannten Konfigurationsproblemen gesucht wird. GKE prüft jede bereitgestellte Arbeitslast anhand relevanter Best Practices der Branche, z. B. mit Richtlinien in den Pod-Sicherheitsstandards. GKE bewertet den Schweregrad erkannter Probleme und gibt umsetzbare Empfehlungen und Logs zurück. Mit Cloud Logging können Sie eine überprüfbare Datenspur für eine bessere Berichterstattung und Beobachtbarkeit erhalten. Eine Anleitung zum Aufrufen von Sicherheitserkenntnissen im Dashboard für den GKE-Sicherheitsstatus finden Sie unter In GKE bereitstellen und Sicherheitserkenntnisse ansehen.

Cloud Run enthält einen Sicherheitsbereich mit Informationen zur Sicherheit der Softwarelieferkette, z. B. Compliance-Informationen auf SLSA-Buildebene, Buildherkunft und Sicherheitslücken in laufenden Diensten. Eine Anleitung zum Aufrufen von Sicherheitserkenntnissen im Bereich „Sicherheitserkenntnisse“ von Cloud Run finden Sie unter In Cloud Run bereitstellen und Sicherheitserkenntnisse ansehen.

Google Cloud bietet auch andere Dienste und Funktionen, mit denen Sie die Sicherheit im gesamten Softwareentwicklungszyklus verbessern können. Weitere Informationen finden Sie in der Übersicht über die Softwarelieferkette.

Nächste Schritte