Best Practices für die Sicherheit einrichten

Diese Seite bietet einen Überblick über Best Practices für die Sicherheit, die empfohlen werden, um die Sicherheit und den Datenschutz um Ihre Cloud Workstations zu verbessern. Diese Liste ist keine umfassende Checkliste, die Sicherheitsgarantien gewährleistet und Ihren bestehenden Sicherheitsstatus ersetzt.

Ziel ist es, Ihnen einen Leitfaden zu den Best Practices für die Sicherheit von Cloud Workstations zur Verfügung zu stellen. Fügen Sie diese Empfehlungen gegebenenfalls Ihrem Portfolio von Sicherheitslösungen im Rahmen der Entwicklung eines mehrschichtigen Sicherheitsansatzes hinzu. Ein mehrstufiger Sicherheitsansatz ist eines der wichtigsten Sicherheitsgrundsätze für die Ausführung sicherer und konformer Dienste in Google Cloud.

Hintergrund

Der Cloud Workstations-Dienst stellt vordefinierte Basis-Images zur Verwendung mit dem Dienst bereit. Der Dienst erstellt diese Images wöchentlich neu und veröffentlicht sie noch einmal, damit die gebündelte Software die neuesten Sicherheitspatches enthält. Darüber hinaus verwendet der Dienst einen Standardwert für das Zeitlimit für die Ausführung in Ihrer Workstationkonfiguration, damit Workstations automatisch aktualisiert werden und nicht gepatchte Images nicht live bleiben.

Google Cloud ist jedoch nicht Inhaber aller Pakete, die in diesen Images enthalten sind. Paketmanager können Updates unterschiedlich priorisieren, je nachdem, wie sich ein Fehler oder allgemeine Sicherheitslücken (Common Vulnerabilities and Exposures, CVEs) auf ihr Produkt auswirken. Wenn ein Produkt nur einen Teil einer Bibliothek nutzt, ist es möglicherweise nicht von Entdeckungen in anderen Teilen der Bibliothek betroffen. Obwohl CVE-Ergebnisse aus Scans auf Sicherheitslücken unserer Images vorhanden sind, kann Cloud Workstations dennoch ein sicheres Produkt bereitstellen.

Cloud Workstations kann dies tun, da es ein Authentifizierungs- und Autorisierungssystem bietet, mit dem dafür gesorgt wird, dass nur der designierte Entwickler auf seine Workstation zugreifen kann. Wie bei jeder Entwicklungsumgebung sollten Entwickler bei der Nutzung ihrer Workstation Best Practices anwenden. Für eine möglichst hohe Sicherheit sollten Sie nur vertrauenswürdigen Code ausführen, nur mit vertrauenswürdigen Eingaben arbeiten und nur auf vertrauenswürdige Domains zugreifen. Darüber hinaus wird davon abgeraten, Workstations zum Hosten von Produktionsservern zu verwenden oder eine einzelne Workstation mit mehreren Entwicklern zu teilen.

Wenn Sie mehr Kontrolle über die Sicherheit der Workstation-Images Ihrer Organisation haben möchten, können Sie auch eigene benutzerdefinierte Container-Images erstellen.

Zugriff auf öffentliche Netzwerke einschränken

Deaktivieren Sie öffentliche IP-Adressen auf Ihren Workstations mithilfe der Workstationkonfiguration und konfigurieren Sie Firewallregeln, die den Zugriff auf öffentliche Internetziele beschränken, die für die tägliche Arbeit innerhalb von Cloud Workstations nicht erforderlich sind. Wenn Sie öffentliche IP-Adressen deaktivieren, müssen Sie den privaten Google-Zugriff oder Cloud NAT in Ihrem Netzwerk einrichten. Wenn Sie den privater Google-Zugriff verwenden und private.googleapis.com oder restricted.googleapis.com für Artifact Registry (oder Container Registry) verwenden, müssen Sie DNS-Einträge für Domains , *.pkg.dev und *.gcr.io einrichten.

Direkten SSH-Zugriff einschränken

Achten Sie darauf, den direkten SSH-Zugriff auf VMs in dem Projekt einzuschränken, das Ihre Cloud Workstations hostet. Der Zugriff ist dann nur über das Cloud Workstations-Gateway möglich. Dort werden Richtlinien der Identitäts- und Zugriffsverwaltung (IAM) erzwungen und VPC-Flusslogs können aktiviert werden.

Führen Sie den folgenden Google Cloud CLI-Befehl aus, um den direkten SSH-Zugriff auf die VM zu deaktivieren:

    gcloud workstations configs update CONFIG \
        --cluster=CLUSTER \
        --region=REGION \
        --project=PROJECT \
        --disable-ssh-to-vm

Zugriff auf sensible Ressourcen beschränken

Richten Sie einen VPC Service Controls-Dienstperimeter ein, um den Zugriff auf sensible Ressourcen von Ihren Workstations aus zu beschränken und so Quellcode und Daten-Exfiltration zu verhindern.

Prinzip der geringsten Berechtigung anwenden

Folgen Sie dem Prinzip der geringsten Berechtigung für Berechtigungen und Ressourcenzuweisung.

IAM-Berechtigungen

Verwenden Sie die Standardkonfiguration für Identity and Access Management und beschränken Sie den Workstation-Zugriff auf einen einzelnen Entwickler. Dadurch wird sichergestellt, dass jeder Entwickler eine eindeutige Workstationinstanz mit einer eindeutigen zugrunde liegenden VM verwendet, was die Umgebungsisolation erhöht. Cloud Workstations-Codeeditoren und -anwendungen werden in einem Container ausgeführt, der im privilegierten Modus und mit Root-Zugriff ausgeführt wird, um die Flexibilität der Entwickler zu erhöhen. Dadurch wird eine eindeutige Workstation pro Entwickler bereitgestellt und sichergestellt, dass ein Nutzer, der diesen Container verlässt, sich trotzdem in seiner VM befindet und keinen Zugriff auf zusätzliche externe Ressourcen erhalten kann.

Richten Sie IAM-Berechtigungen ein, um den Nicht-Administratorzugriff zum Ändern von Workstationkonfigurationen und Container-Images in Artifact Registry einzuschränken.

Darüber hinaus empfiehlt Google, IAM-Berechtigungen einzurichten, um den Nicht-Administratorzugriff auf die zugrunde liegenden Compute Engine-Ressourcen in dem Projekt zu beschränken, das Ihre Cloud Workstations hostet.

Weitere Informationen finden Sie unter IAM sicher verwenden.

Cloud KMS-Berechtigungen

Zur besseren Umsetzung des Prinzips der geringsten Berechtigung empfehlen wir, Cloud KMS-Ressourcen und Cloud Workstations-Ressourcen in separaten Google Cloud-Projekten zu belassen. Erstellen Sie Ihr Cloud KMS-Schlüsselprojekt ohne owner auf Projektebene und legen Sie einen Organisationsadministrator fest, der auf Organisationsebene gewährt wird. Im Gegensatz zu owner kann ein Organisationsadministrator Schlüssel nicht direkt verwalten oder verwenden. Sie sind auf das Festlegen von IAM-Richtlinien beschränkt, die einschränken, wer Schlüssel verwalten und verwenden kann.

Dies wird auch als Aufgabentrennung bezeichnet. Mit diesem Konzept wird sichergestellt, dass eine Person nicht alle erforderlichen Berechtigungen hat, um bösartige Aktionen ausführen zu können. Weitere Informationen finden Sie unter Aufgabentrennung.

Automatische Image-Updates und -Patches erzwingen

Achten Sie darauf, dass Ihre Workstations die neueste Version der Basis-Images von Cloud Workstations verwenden, die die neuesten Sicherheitspatches und Fehlerkorrekturen enthält. Mit dem Wert Zeitlimit für Ausführung in der Workstationkonfiguration wird sichergestellt, dass Workstations, die mit dieser Konfiguration erstellt wurden, bei der nächsten Sitzung automatisch aktualisiert werden, damit sie der neuesten Version des in der Workstationkonfiguration definierten Container-Images entsprechen.

  • Wenn Ihre Organisation eines der Cloud Workstations-Basis-Images verwendet, übernimmt die Workstation automatisch alle Aktualisierungen der Workstationkonfiguration, wenn die Workstation das nächste Mal heruntergefahren und neu gestartet wird. Wenn Sie runningTimeout festlegen oder die Standardeinstellung verwenden, können diese Workstations heruntergefahren werden.
  • Wenn Ihre Organisation ein benutzerdefiniertes Image verwendet, sollten Sie es regelmäßig neu erstellen. Wir empfehlen, wie im folgenden Abschnitt beschrieben, eine sichere Image-Pipeline zu erstellen.

Sichere Image-Pipeline für benutzerdefinierte Images erstellen

Sie sind für die Verwaltung und Aktualisierung von benutzerdefinierten Paketen und Abhängigkeiten, die benutzerdefinierten Images hinzugefügt wurden, verantwortlich.

Wenn Sie benutzerdefinierte Images erstellen, empfehlen wir Folgendes:

VPC-Flusslogs einrichten

Wenn Sie einen Workstationcluster erstellen, verknüpft Cloud Workstations den Cluster mit einem bestimmten Subnetz und alle Workstations werden in diesem Subnetz platziert. Damit Sie VPC-Flusslogs aktivieren können, muss das Logging für dieses Subnetz aktiviert sein. Weitere Informationen finden Sie unter VPC-Flusslogs für ein vorhandenes Subnetz aktivieren.