In diesem Dokument werden Implementierungen auf Zugriffsebene beschrieben und Empfehlungen für die Erzwingung des Dienstperimeters auf Grundlage 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 IPs vertrauenswürdig und kontrolliert sein. 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:
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.
Eine Variante dieses Szenarios ist, wenn Sie den Perimeterzugriff von privaten Ressourcen zulassen, die in einem anderen Projekt oder einer anderen Organisation bereitgestellt werden. In diesem Anwendungsfall ist im Quellprojekt ein Cloud NAT-Gateway erforderlich.
Cloud NAT ist in Privaten Google-Zugriff integriert. Dadurch wird der privater Google-Zugriff automatisch für das Subnetz der Ressource aktiviert und der Traffic zu Google APIs und ‑Diensten bleibt intern, anstatt über die externe IP-Adresse des Cloud NAT-Gateways an das Internet weitergeleitet zu werden.
Da der Traffic innerhalb des internen Google-Netzwerks weitergeleitet wird, wird das Feld RequestMetadata.caller_ip des AuditLog-Objekts zu gce-internal-ip entfernt. Um in diesem Fall den Perimeterzugriff zuzulassen, müssen Sie eine Ingress-Regel konfigurieren, um den Zugriff basierend auf anderen Attributen wie dem Projekt- oder Dienstkonto zuzulassen, anstatt eine Zugriffsebene basierend auf der externen Quell-IP-Adresse zu konfigurieren.
Zugriff anhand der Identität des Anrufers gewähren
Zur Implementierung einer identitätsbasierten Zulassungsliste 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 über vertrauenswürdige Geräte zugegriffen werden. Wir empfehlen, Cloud Workstations für den Zugriff auf Ressourcen innerhalb von Perimetern zu verwenden, 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 nützlich, um Gerätevertrauen herzustellen:
Verifiziertes ChromeOS 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.
Mit der Option Administratorgenehmigung für den Gerätezugriff erzwingen können Cloud Identity-Administratoren 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 Geräten, die keine Chrome OS-Geräte sind, nicht autoritativ ist, kann ein Nutzer mit erhöhten Administratorberechtigungen unter Umständen die Seriennummer fälschen. Wir empfehlen, diese Bedingung nur als Tier-2-Prüfung 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 Sicherheitsteams und die Teams für die Reaktion auf Vorfälle über die Bereitstellung informiert sind. Außerdem sollten Personen mit entsprechenden Berechtigungen Logs prüfen und gegebenenfalls zusätzliche Zulassungslisten genehmigen.
- Sorgen Sie dafür, dass das Team für die Reaktion auf Vorfälle eine Google Cloud-Supportanfrage öffnen kann, wenn Fragen oder Probleme auftauchen.
- 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 sehen möchten, konfigurieren Sie eine zusammengefasste 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
- Weitere Informationen zum Zulassen des Zugriffs auf geschützte Ressourcen von außerhalb des Perimeters
- Weitere Informationen zum Auflisten, Aktualisieren und Löschen von Dienstperimetern