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 ruhender Daten

Standardmäßig verschlüsseltDaten im inaktiven Zustand automatisch mit von Google verwalteten Verschlüsselungsschlüsseln. Google Cloud Wenn Sie bestimmte Compliance- oder gesetzliche Anforderungen für die Schlüssel zum Schutz Ihrer Daten erfüllen müssen, können Sie Repositories erstellen, die mit kundenverwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) verschlüsselt sind.

Zugriffssteuerung

Standardmäßig sind alle Repositories privat. Halten Sie sich an das Sicherheitsprinzip der geringsten Berechtigung und gewähren Sie Nutzern und Dienstkonten nur die Mindestberechtigungen, die erforderlich sind.

Artefakt-Downloads einschränken

Sie können Artefakt-Downloads mit Downloadregeln einschränken. Mit Downloadregeln können Sie Artefakt-Downloads aus Ihren Repositories und Paketen zulassen oder ablehnen. Sie können auch Bedingungen festlegen, damit die Regel auf bestimmte Tags oder Versionen angewendet wird.

Für jedes Repository in Ihrem Projekt können Sie eine Downloadregel auf Repository-Ebene und eine Downloadregel pro Paket festlegen. Wenn ein Client einen Download versucht, prüft Artifact Registry zuerst, ob für das Paket des Artefakts eine Downloadregel vorhanden ist. Wenn keine Regel vorhanden ist oder die Bedingungen der Regel nicht auf das Artefakt zutreffen, prüft Artifact Registry, ob für das Repository eine Regel vorhanden ist.

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

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

  • Apt
  • Docker
  • Go
  • Maven
  • npm
  • Python

Daten-Exfiltration verhindern

Um Daten-Exfiltration zu verhindern, können Sie mit VPC Service Controls Artifact Registry und andere Google Cloud Dienste in einem Netzwerk sicherheitsperimeter platzieren.

Scannen auf Sicherheitslücken

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

Folgende Optionen sind verfügbar:

Automatisches Scannen auf Sicherheitslücken
Wenn dieses Feature 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 Push des Images kontinuierlich auf neue Sicherheitslücken überwacht.
On-Demand Scanning API
Wenn diese Option aktiviert ist, können Sie lokale Images oder in Artifact Registry gespeicherte Images manuell scannen. 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 auch das automatische Scannen auf Sicherheitslücken aktiviert haben, scannt die Artefaktanalyse auch 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 zulässig sind, wenn ein Image zur Einhaltung einer Richtlinie für das Scannen 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 alte Software verwendet wird.

Ein Linksruck bei der Sicherheit

Durch die Integration von Zielen zur Informationssicherheit in die tägliche Arbeit können Sie die Leistung bei der Softwarebereitstellung steigern und sicherere Systeme aufbauen. Diese Idee wird auch als shifting left (Shift-Left-Ansatz) bezeichnet, weil Bedenken, darunter auch Sicherheitsprobleme, früher im Lebenszyklus der Softwareentwicklung angegangen werden (d. h. in einem Zeitplan-Diagramm, dessen Leserichtung von links nach rechts geht, also weiter links). Ein Linksruck bei der Sicherheit ist eine der DevOps Funktionen, die im Rahmen des „State of DevOps“-Forschungsprogramms des DORA-Teams ermittelt wurden.

Weitere Informationen:

  • Informationen zur Funktion „Ein Linksruck bei der Sicherheit“
  • Lesen Sie das Whitepaper Ein Linksruck bei der Sicherheit, in dem Verantwortlichkeiten, Praktiken, Prozesse, Tools und Techniken beschrieben werden, die das Vertrauen in den Software Development Lifetime (SDLC) erhöhen und Bedenken hinsichtlich Sicherheitsrisiken verringern.

Hinweise zu öffentlichen Repositories

Beachten Sie folgende Fälle:

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

Artefakte aus öffentlichen Quellen verwenden

Die folgenden öffentlichen Artefaktquellen bieten Tools, die Sie möglicherweise verwenden, oder Abhängigkeiten für Ihre Builds und Bereitstellungen:

Ihre Organisation hat jedoch möglicherweise Einschränkungen, 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.

Berücksichtigen 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 Build-Trigger oder andere Tools für die kontinuierliche Integration verwenden.
  • Verwenden Sie standardisierte Basis-Images. 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 prüfen, bevor Sie sie in Artifact Registry speichern. Die Artefaktanalyse kann auch Container scannen, die Sie in Artifact Registry pushen.

Öffentliche 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 Ihre Nutzer Google Cloud Konten haben, können Sie den Zugriff stattdessen auf authentifizierte Nutzer mit der allAuthenticatedUsers Identität beschränken.

Beachten Sie die folgenden Richtlinien, bevor Sie ein Artifact Registry-Repository öffentlich machen:

  • Achten Sie darauf, dass alle im Repository gespeicherten Artefakte öffentlich freigegeben werden können und keine Anmeldedaten, personenbezogenen Daten oder vertraulichen Daten enthalten.
  • Standardmäßig haben Projekte unbegrenzte Kontingente pro Nutzer Kontingente. Um Missbrauch zu verhindern, begrenzen Sie die Kontingente pro Nutzer in Ihrem Projekt.
- Ihnen werden Kosten für die Netzwerkdatenübertragung in Rechnung gestellt, wenn Nutzer Artefakte herunterladen. Wenn Sie viel Internet-Download Traffic erwarten, berücksichtigen Sie die damit verbundenen Kosten.

Hinweise für Webanwendungen

  • Die OWASP Top 10 listet die größten Sicherheitsrisiken für Webanwendungen gemäß dem Open Web Application Security Project (OSWAP) auf.

Hinweise 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 zur Abhängigkeitsverwaltung