Zugriff steuern und Artefakte schützen

Auf dieser Seite werden Google Cloud-Dienste und -Features beschrieben, mit denen Sie Ihre Artefakte schützen können.

Verschlüsselung inaktiver Daten

Standardmäßig verschlüsselt Google Cloud Daten im inaktiven Zustand automatisch mit von Google verwalteten Verschlüsselungsschlüsseln. Wenn Sie in Bezug auf die Schlüssel zum Schutz Ihrer Daten bestimmte Compliance- oder regulatorische Anforderungen haben, können Sie Repositories erstellen, die mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) verschlüsselt sind.

Zugriffssteuerung

Standardmäßig sind alle Repositories privat. Folgen Sie dem Sicherheitsprinzip der geringsten Berechtigung und gewähren nur die minimalen Berechtigungen, die für Nutzer und Dienstkonten erforderlich sind.

Daten-Exfiltration verhindern

Zur Vermeidung einer Daten-Exfiltration können Sie mit VPC Service Controls Artifact Registry und andere Google Cloud-Dienste in einem Netzwerksicherheitsperimeter platzieren.

Scannen auf Sicherheitslücken

Die Artefaktanalyse kann Container-Images in öffentlich überwachten Paketen auf Sicherheitslücken scannen.

Folgende Optionen sind verfügbar:

Automatisches Scannen auf Sicherheitslücken
Wenn dieses Feature aktiviert ist, werden Sicherheitslücken in Ihren Container-Images erkannt. Images werden beim Hochladen in Artifact Registry gescannt und die Daten werden bis zu 30 Tage nach dem Hochladen des Images kontinuierlich auf neue Sicherheitslücken überwacht.
On-Demand Scanning API
Wenn diese Option aktiviert ist, können Sie lokale Images oder Images, die in Artifact Registry gespeichert sind, manuell scannen. Mit diesem Feature können Sie Sicherheitslücken frühzeitig in der Build-Pipeline erkennen und beheben. Sie können beispielsweise mit Cloud Build ein Image nach seiner Erstellung scannen und dann den Upload in Artifact Registry blockieren, wenn beim Scan Sicherheitslücken mit einem bestimmten Schweregrad erkannt werden. Wenn Sie außerdem das automatische Scannen auf Sicherheitslücken aktiviert haben, scannt die Artefaktanalyse auch die Images, die Sie in die Registry hochladen.

Deployment-Richtlinie

Mit der Binärautorisierung können Sie eine Richtlinie konfigurieren, die der Dienst erzwingt, wenn versucht wird, ein Container-Image in einer der unterstützten Google Cloud-Umgebungen bereitzustellen.

Sie können die Binärautorisierung beispielsweise so konfigurieren, dass Bereitstellungen nur dann zugelassen werden, wenn ein Image signiert wurde, um eine Richtlinie zum Scannen auf Sicherheitslücken zu erfüllen.

Nicht verwendete Images entfernen

Entfernen Sie nicht verwendete Container-Images, um die Speicherkosten zu senken und das Risiko zu verringern, dass ältere Software verwendet wird. Es gibt eine Reihe von Tools, die Ihnen bei dieser Aufgabe helfen können, einschließlich gcr-cleaner. Das gcr-cleaner-Tool ist kein offizielles Google-Produkt.

Ein Linksruck bei der Sicherheit

Die Integration von Zielen für die Informationssicherheit in die tägliche Arbeit kann dazu beitragen, die Leistung der Softwarebereitstellung zu steigern und sicherere Systeme aufzubauen. Diese Idee wird auch als Linksverschiebung bezeichnet, da Bedenken, einschließlich Sicherheitsbedenken, früher im Lebenszyklus der Softwareentwicklung angegangen werden (d. h. in einem rechtsläufigen Zeitplandiagramm). Eine der DevOps-Fähigkeiten im „State of DevOps“-Forschungsprogramm des DORA-Teams ist, sich bei der Sicherheit nach links zu bewegen.

Weitere Informationen:

  • Mehr über die Funktion Links für die Sicherheit erfahren
  • Lesen Sie das Whitepaper Shifting left on security, in dem Verantwortlichkeiten, Praktiken, Prozesse, Tools und Techniken beschrieben werden, die das Vertrauen in den Software Development Lifecycle (SDLC) stärken und Bedenken hinsichtlich Sicherheitsrisiken reduzieren.

Überlegungen zu öffentlichen Repositories

Beachten Sie folgende Fälle:

  • Verwendung von Artefakten aus öffentlichen Quellen
  • Eigene Artifact Registry-Repositories veröffentlichen

Artefakte aus öffentlichen Quellen verwenden

Öffentliche Artefaktquellen wie GitHub, Docker Hub, PyPI oder die öffentliche npm-Registry bieten Tools, die Sie möglicherweise für Ihre Builds und Bereitstellungen verwenden können, oder Abhängigkeiten.

In Ihrer Organisation kann es jedoch Einschränkungen geben, die sich auf die Verwendung öffentlicher Artefakte auswirken. Beispiel:

  • Sie möchten den Inhalt Ihrer Softwarelieferkette steuern.
  • Sie möchten nicht auf ein externes Repository angewiesen sein.
  • Sie möchten Sicherheitslücken in Ihrer Produktionsumgebung streng kontrollieren.
  • Sie wünschen in jedem Image dasselbe Basisbetriebssystem.

Betrachten Sie die folgenden Ansätze, um Ihre Softwarelieferkette zu sichern:

  • Richten Sie automatische Builds ein, damit Ihre Artefakte konsistente, bekannte Inhalte haben. Sie können Build-Trigger von Cloud Build oder andere Tools für die kontinuierliche Integration verwenden.
  • Standardisierte Basis-Images verwenden Google stellt einige Basis-Images zur Verfügung, die Sie verwenden können.
  • Beheben Sie Sicherheitslücken in Ihren Artefakten. Mit der On-Demand Scanning API können Sie Container-Images auf Sicherheitslücken scannen, bevor Sie sie in Artifact Registry speichern. Die Artefaktanalyse kann auch Container scannen, die Sie per Push an Artifact Registry übertragen.
  • Ihre internen Standards für Image-Bereitstellungen durchsetzen Mit der Binärautorisierung können Sie die Bereitstellung von Container-Images in unterstützten Google Cloud-Umgebungen erzwingen.

Überlegungen zu öffentlichen Images

Public Artifact Registry-Repositories

Sie können ein Artifact Registry-Repository öffentlich machen, indem Sie der Identität allUsers die Rolle „Artifact Registry-Leser“ zuweisen.

Wenn alle Nutzer Google Cloud-Konten haben, können Sie den Zugriff auf authentifizierte Nutzer stattdessen mit der Identität allAuthenticatedUsers beschränken.

Beachten Sie die folgenden Richtlinien, bevor Sie ein Artifact Registry-Repository veröffentlichen:

  • Prüfen Sie, ob alle Artefakte, die Sie im Repository speichern, öffentlich freigegeben werden können und keine Anmeldedaten, personenbezogenen Daten oder vertraulichen Daten preisgeben.
  • Wenn Nutzer Artefakte herunterladen, wird Ihnen der ausgehende Netzwerktraffic in Rechnung gestellt. Wenn Sie einen hohen Internet-Download-Traffic erwarten, sollten Sie die damit verbundenen Kosten berücksichtigen.
  • Standardmäßig haben Projekte ein unbegrenztes nutzerbezogenes Kontingent. Um Missbrauch zu verhindern, sollten Sie das Nutzerkontingent in Ihrem Projekt begrenzen.

Anleitung für Webanwendungen

  • In den OWASP Top 10 werden die wichtigsten Sicherheitsrisiken für Webanwendungen gemäß dem Open Web Application Security Project (OSWAP) aufgeführt.

Anleitung für Container

  • Unter Best Practices für die Containererstellung finden Sie auch Empfehlungen zum Erstellen von Containern.

    Sie können auch die Best Practices für Docker zum Erstellen von Images lesen.

  • Best Practices für den Betrieb von Containern enthalten Empfehlungen für Sicherheit, Monitoring und Logging, die das Ausführen von Anwendungen in Google Kubernetes Engine und in Containern im Allgemeinen erleichtern.

  • Das Center for Internet Security (CIS) bietet eine Docker-Benchmark zur Bewertung der Sicherheit eines Docker-Containers.

    Außerdem stellt Docker ein Open-Source-Skript namens Docker Bench for Security bereit. Mit diesem Skript können Sie einen laufenden Docker-Container anhand der CIS-Docker-Benchmark prüfen.

    Mit Docker Bench for Security lassen sich viele Elemente der CIS-Docker-Benchmark prüfen, allerdings nicht alle. Beispielsweise kann das Skript nicht feststellen, ob der Host für den Container gehärtet ist oder ob das Container-Image personenbezogene Daten enthält. Sehen Sie sich alle Elemente der Benchmark an und identifizieren Sie diejenigen, die möglicherweise zusätzlich geprüft werden müssen.

Nächste Schritte

Weitere Informationen zum Abhängigkeitsmanagement