Zugriffsebenen entwerfen

In diesem Dokument werden Implementierungen auf Zugriffsebenen beschrieben und Empfehlungen zum Initiieren der Erzwingung von Dienstperimetern anhand von Zulassungslisten gegeben.

Wenn Sie einen Probelauf ausgeführt haben, geben Sie eine Liste der IP-Adressen und Identitäten an, die Sie einer Zulassungsliste hinzufügen müssen. Möglicherweise stellen Sie auch fest, dass für einige Arbeitslasten eine gerätebasierte Zulassungsliste erforderlich ist. Sie können mit VPC Service Controls-Zugriffsebenen kontrollierten Zugriff auf geschützte Google Cloud-Ressourcen gewähren. Praktische Methoden zur Implementierung von Zugriffsebenen sind die IP-Adresse, die Identität oder das Gerät des Nutzers.

Weitere Informationen finden Sie unter Kontextsensitiver Zugriff mit Regeln für eingehenden Traffic.

Zugriff anhand von Quell-IP-Adresse gewähren

Sie können in den Zugriffsebenen für IP-basierte Zulassungslisten nur öffentliche IP-CIDR-Bereiche verwenden. Da diese Methode alle geschützten APIs aus diesem IP-Bereich zulässt, muss die Umgebung hinter diesen IP-Adressen vertrauenswürdig und kontrolliert werden. Ein typisches Verwendungsszenario für diese Zulassungsliste besteht darin, den Perimeterzugriff aus lokalen Netzwerken zuzulassen. Das folgende Diagramm zeigt, wie eine IP-basierte Zulassungsliste blockiert und zugelassen wird:

Der VPC Service Controls-Netzwerk- und Dienstperimeter verhindert den Zugriff durch eine gültige Identität in einem nicht vertrauenswürdigen Netzwerk.

Im obigen Diagramm versucht eine gültige Identität, auf den Perimeter zuzugreifen. Die Zugriffsversuche werden abgelehnt, wenn sie von Internet-IP-Adressen stammen. Der Zugriff wird jedoch gewährt, wenn er von den öffentlichen IP-Adressen des Unternehmens stammt.

Zugriff anhand der Identität des Anrufers gewähren

Zur Implementierung einer identitätsbasierten Zulassung fügen Sie Dienstkonten und Super Admins der Organisation einer Zulassungsliste hinzu. Der Perimeter ist für diese Identitäten von einer beliebigen IP-Adresse aus geöffnet. Daher müssen Sie dafür sorgen, dass die Identitäten gut geschützt sind. Wichtig ist außerdem, dass Sie keine Mining-Schlüssel für Dienstkonten vermeiden, die Sie einer Zulassungsliste hinzugefügt haben. Es ist nicht üblich, Nutzer auf eine Liste der zugelassenen Nutzer zu setzen (Gruppen können nicht auf eine weiße Liste gesetzt werden) in einem Perimeter.

Auf Ressourcen innerhalb des Perimeters kann über VMs innerhalb des Perimeters, über vertrauenswürdige lokale Netzwerke oder von vertrauenswürdigen Geräten aus zugegriffen werden. Wir empfehlen die Verwendung von Cloud Workstations für den Zugriff auf Ressourcen innerhalb von Perimetern, da VPC Service Controls Cloud Shell nicht unterstützt.

Zugriff anhand der Attribute des Aufrufergeräts zulassen

Gertätevertrauen, das auch als vertrauenswürdiger Endpunkt bezeichnet wird, hängt von einem gültigen Organisationsnutzer ab, der in einem Chrome-Browser oder Chromebook angemeldet ist. Die Vertrauensstellung gilt für die Sitzung mit Anmeldung im Betriebssystem. Beispielsweise kann ein Windows-Nutzer, der angemeldet ist und eine Chrome-Sitzung ausführt (bei der der Browser nicht geöffnet sein muss) kann Befehle der gcloud CLI auf geschützten Perimeter-APIs aufrufen. Allerdings ist es bei einer anderen Windows-Nutzersitzung auf derselben Maschine nicht möglich, Befehle auf den geschützten Perimeter-APIs aufzurufen.

Die folgenden Gerätebedingungen sind hilfreich, um eine Gerätevertrauens herzustellen:

  • Verifiziertes Chrome OS: Dies ist eine hochsichere, kryptografisch verifizierte Bedingung, die angibt, dass ein gültiger Nutzer der Organisation auf einem sicher gestarteten Chromebook angemeldet ist. Dies ist eine empfohlene Vertrauensbedingung der Stufe 1.

    Die Betriebssystemrichtlinie mit aktivierter Option „Verifiziertes Chrome OS“.

  • Administratorgenehmigung für den Gerätezugriff erzwingen: Cloud Identity-Administratoren können jedes Gerät genehmigen, bevor der Zugriff gewährt wird. Standardmäßig werden Geräte automatisch genehmigt, wenn ein gültiger Organisationsnutzer angemeldet ist. Es wird jedoch empfohlen, die Option für die automatische Genehmigung zu deaktivieren.

  • Unternehmenseigenes Gerät erforderlich: Die Seriennummer wird vom Chrome-Agent abgerufen, der in der Regel vom BIOS stammt. Diese Nummer muss mit vorhandenen Seriennummern übereinstimmen, die Sie in Cloud Identity eingegeben haben.

    Da die Seriennummer auf Nicht-Chrome OS-Geräten nicht autoritativ ist, kann ein Nutzer mit erhöhten Administratorberechtigungen möglicherweise die Seriennummer fälschen. Wir empfehlen, diese Bedingung nur als Prüfung der Stufe 2 zu verwenden.

Eine Beispielverfolgung für das Gewähren des gesteuerten Zugriffs anhand der in der vorhergehenden Liste genannten Bedingungen finden Sie unter Vorlage für die VPC Service Controls-Einführung: Zulassungsliste (PDF).

Durchsetzung initiieren

Nachdem Sie die Zugriffsliste sowie die Zugriffsebenen konfiguriert haben, empfehlen wir, die Arbeitslasten noch einmal auszuführen, um sicherzustellen, dass keine Verstöße vorliegen. Wenn die Arbeitslasten ohne Verstöße ausgeführt werden, können Sie die Erzwingung von VPC Service Controls initiieren, ohne die Anwendungen zu beeinträchtigen.

Inkludieren Sie bei der Planung der Erzwingung Folgendes:

  • Wählen Sie ein Datum für die Durchsetzung aus und teilen Sie es allen relevanten Teams mit.
  • Sorgen Sie dafür, dass die Teams für Sicherheitsvorgänge und die Reaktion auf Vorfälle über die Bereitstellung informiert sind. Achten Sie außerdem darauf, dass Personen mit den entsprechenden Berechtigungen Logs prüfen und gegebenenfalls zusätzliche Zulassungslisten genehmigen.
  • Sorgen Sie dafür, dass das Situationsreaktionsteam bei Fragen oder Problemen eine Google Cloud-Supportanfrage eröffnen kann.
  • Erstellen oder ändern Sie Perimeter und Zugriffsebenen mit Automatisierungstools wie Terraform. Wir raten davon ab, diese Aufgaben manuell auszuführen.

Wenn Sie die Erzwingung initiieren, beginnen Sie mit dem Verschieben von Projekten, die einer einzelnen Arbeitslast zugeordnet sind, vom Probelaufperimeter in den Liveperimeter. Achten Sie darauf, dass die Anwendung ordnungsgemäß ausgeführt wird, während Sie die Verstoßlogs beobachten. Wiederholen Sie den Vorgang für die übrigen Arbeitslasten nacheinander.

Wenn Sie blockierte Verstöße erkennen möchten, konfigurieren Sie eine aggregierte Logging-Senke, die Audit-Logs für alle Projekte im Perimeter an BigQuery sendet. Führen Sie dann die folgende Abfrage aus:

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter

Nächste Schritte