Zugriff steuern und Artefakte schützen

Auf dieser Seite werden Google Cloud-Dienste und -Funktionen 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 bestimmte Compliance- oder behördliche Anforderungen in Bezug auf die Schlüssel zum Schutz Ihrer Daten haben, können Sie Repositories erstellen, die mit vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) verschlüsselt sind.

Zugriffssteuerung

Standardmäßig sind alle Repositories privat. Beachten Sie das Sicherheitsprinzip der geringsten Berechtigung und gewähren Sie nur die minimal erforderlichen Berechtigungen für Nutzer- und Dienstkonten.

Artefaktdownloads einschränken

Sie können Artifact-Downloads mit Downloadregeln einschränken. Mit Downloadregeln können Sie den Download von Artefakten aus Ihren Repositories und Paketen zulassen oder ablehnen. Sie können auch Bedingungen festlegen, damit die Regel für bestimmte Tags gilt oder Versionen.

Für jedes Repository in Ihrem Projekt können Sie eine Downloadregel auf der Repository-Ebene und eine Downloadregel pro Paket. Wenn ein Client einen Download versucht, sucht Artifact Registry zuerst nach einer Downloadregel für das Paket des Artefakts. Wenn eine Regel nicht vorhanden ist oder die Bedingungen der Regel nicht erfüllt sind auf das Artefakt angewendet werden, sucht Artifact Registry zu erstellen.

Sie können z. B. eine Regel für Ihr Repository erstellen, die alle Downloads, und dann eine Regel für ein Paket erstellen, um Downloads von diesem Paket. Die Regel auf Paketebene hat Vorrang und nur Artefakte, die zu diesem Paket gehören, können aus dem Repository heruntergeladen werden.

Downloadregeln sind für alle Repository-Modi und für die folgenden Repository-Formate verfügbar:

  • Docker
  • Go
  • Maven
  • npm
  • Python

Daten-Exfiltration verhindern

Mit VPC Service Controls lässt sich die Daten-Exfiltration verhindern. zur Platzierung von Artifact Registry und anderen Google Cloud-Diensten in einem Netzwerk Sicherheitsbereich.

Scannen auf Sicherheitslücken

Mit der Artefaktanalyse können Container-Images auf Sicherheitslücken in öffentlich überwachten Paketen geprüft werden.

Folgende Optionen sind verfügbar:

Automatisches Scannen auf Sicherheitslücken
Wenn diese Funktion aktiviert ist, werden Sicherheitslücken in Ihren gepackten Container-Images erkannt. Images werden beim Hochladen in Artifact Registry gescannt. Die Daten werden bis zu 30 Tage nach dem Hochladen des Images kontinuierlich auf neue Sicherheitslücken geprüft.
On-Demand Scanning API
Wenn diese Option aktiviert ist, können Sie lokale oder gespeicherte Bilder manuell scannen in Artifact Registry. Mit diesem Feature können Sie Sicherheitslücken frühzeitig in der Build-Pipeline erkennen und beheben. Sie können beispielsweise Cloud Build verwenden, um ein Image nach dem Erstellen zu scannen und dann den Upload in Artifact Registry zu blockieren, wenn der Scan Sicherheitslücken mit einem bestimmten Schweregrad erkennt. Wenn Sie automatisches Scannen auf Sicherheitslücken aktiviert, scannt Images, die Sie in die Registry hochladen.

Deployment-Richtlinie

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

Sie können die Binärautorisierung beispielsweise so konfigurieren, dass nur Bereitstellungen zulässig sind, wenn ein Image gemäß einer Richtlinie für den Scan auf Sicherheitslücken signiert ist.

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

Wenn Sie Ziele zur Informationssicherheit in die tägliche Arbeit einbinden, können Sie die Leistung der Softwarebereitstellung steigern und sicherere Systeme entwickeln. Diese Idee wird auch als Shift-Left-Modell bezeichnet, weil Bedenken, darunter auch Sicherheitsprobleme, früher im Lebenszyklus der Softwareentwicklung angegangen werden (d. h. in einem Planungsdiagramm, dessen Leserichtung von links nach rechts geht, also weiter links). Die Linksverschiebung bei der Sicherheit ist eine der DevOps-Funktionen, die im Rahmen des DORA-Forschungsprogramms „State of DevOps“ identifiziert wurden.

Weitere Informationen:

  • Weitere Informationen Links in puncto Sicherheit
  • Lesen Sie das Whitepaper Shifting left on security, in dem Aufgaben, Praktiken, Prozesse, Tools und Techniken beschrieben werden, die das Vertrauen in den Software Development Life Cycle (SDLC) stärken und Bedenken hinsichtlich Sicherheitsrisiken verringern.

Ü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

Die folgenden öffentlichen Quellen für Artefakte bieten Tools, die Sie nutzen können Abhängigkeiten für Ihre Builds und Bereitstellungen:

Möglicherweise gibt es jedoch Einschränkungen in Ihrer Organisation, die sich auf die Verwendung öffentlicher Artefakte auswirken. Beispiel:

  • Sie möchten den Inhalt Ihrer Softwarelieferkette kontrollieren.
  • 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.

Beachten Sie die folgenden Ansätze, um Ihre Softwarelieferkette zu schützen:

  • Richten Sie automatische Builds ein, damit Ihre Artefakte einheitliche, bekannte Inhalte haben. Sie können Cloud Build verwenden Build-Trigger oder andere Tools für die kontinuierliche Integration.
  • Verwenden Sie standardisierte Basisbilder. Google bietet einige Basis-Images, die Sie verwenden können.
  • Beheben Sie Sicherheitslücken in Ihren Artefakten. Sie können On-Demand Scanning API um Container-Images auf Sicherheitslücken zu scannen, Artifact Registry. Die Artefaktanalyse kann auch scannen Container, die per Push an Artifact Registry übertragen werden.

Public Artifact Registry-Repositories

Sie können ein Artifact Registry-Repository veröffentlichen, indem Sie der Identität allUsers die Rolle „Artifact Registry Reader“ 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 Repository der Artifact Registry veröffentlichen:

  • Prüfen, ob alle im Repository gespeicherten Artefakte öffentlich geteilt werden können und legen Sie keine Anmeldedaten, personenbezogenen oder vertraulichen Daten offen.
  • Standardmäßig haben Projekte ein unbegrenztes nutzerbezogenes Kontingent. Um Missbrauch zu verhindern, begrenzen Sie das nutzerbezogene Kontingent in Ihrem Projekt.
  • Ihnen werden Netzwerkdatenübertragungen in Rechnung gestellt, wenn Nutzer Artefakte herunterladen. Wenn Sie eine hohe Downloadgeschwindigkeit berücksichtigen Sie die damit verbundenen Kosten.

Anleitung für Webanwendungen

  • Die OWASP Top 10 listet die häufigsten Sicherheitsrisiken für Webanwendungen gemäß dem Application Security Project (OSWAP).

Anleitung für Container

  • 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