In diesem Dokument werden Implementierungen für Zugriffsebenen beschrieben und Empfehlungen zum Initiieren der Erzwingung von Dienstperimetern basierend auf auf die Zulassungsliste setzen.
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 nur öffentliche IP-CIDR-Bereiche in den Zugriffsebenen für IP-basierte Zulassungslisten. Da bei dieser Methode alle APIs aus diesem IP-Bereich geschützt sind, muss die Umgebung hinter diesen IP-Adressen vertrauenswürdig sind 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:
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, die in einem anderen Projekt oder einer anderen Organisation bereitgestellt wurden. Bei dieser Verwendung
ist ein Cloud NAT-Gateway im Quellprojekt erforderlich.
Cloud NAT
verfügt über eine Integration mit dem privaten Google-Zugriff
mit dem der privater Google-Zugriff
im Subnetz der Ressource automatisch aktiviert wird.
und den Traffic zu Google APIs und Google-Diensten intern hält, anstatt ihn
über die externe IP-Adresse
des Cloud NAT-Gateways mit dem Internet.
Da der Traffic innerhalb des internen Google-Netzwerks weitergeleitet wird,
Das Feld RequestMetadata.caller_ip
des AuditLog
-Objekts wird in
gce-internal-ip
Um in diesem Fall den Perimeterzugriff zuzulassen, müssen Sie
konfigurieren Sie eine Regel für eingehenden Traffic, um den Zugriff auf der Grundlage anderer Attribute wie
des Projekts oder Dienstkontos, anstatt eine
für die externe Quell-IP-Adresse.
Zugriff anhand der Identität des Anrufers gewähren
Um eine identitätsbasierte Zulassungsliste zu implementieren, fügen Sie Dienstkonten und Super Admins der Organisation auf eine Zulassungsliste setzen. 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 im von vertrauenswürdigen lokalen Netzwerken oder von vertrauenswürdigen Geräten. Mi. empfehlen die Verwendung von Cloud Workstations für den Zugriff Ressourcen innerhalb von Perimetern, da von VPC Service Controls keine Cloud Shell
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 vertrauenswürdige Gerätenutzung zu ermöglichen:
Verifiziertes ChromeOS ist ein sehr sicherer, kryptografisch verifizierter Zustand, der darauf hinweist, dass ein gültiger Organisationsnutzer auf einem sicher gestarteten Chromebook angemeldet ist. Dies ist eine empfohlene Vertrauensbedingung der Stufe 1.
Administratorgenehmigung für den Gerätezugriff erzwingen können Cloud Identity-Administratoren jedes Gerät genehmigen, bevor 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 maßgeblich ist, Nutzer mit erweiterten Administratorberechtigungen können den Seriennummer haben. Wir empfehlen, diese Bedingung nur als Stufe 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.
- Stellen Sie sicher, dass die Sicherheitsteams und die Incident-Response-Teams über für die Bereitstellung. Stellen Sie außerdem sicher, dass Personen mit Berechtigungen prüfen Logs und genehmigen bei Bedarf weitere Zulassungslisten.
- Sorgen Sie dafür, dass das Team für die Situationsreaktion eine Google Cloud öffnen kann Supportanfrage, falls Fragen oder Probleme auftreten.
- 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.
Um blockierte Verstöße aufzudecken, 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
- Zugriff auf geschützte Ressourcen von außerhalb des Perimeters zulassen
- Dienstperimeter auflisten, aktualisieren und löschen