Diese Seite wurde von der Cloud Translation API übersetzt.

Zugriffsebenen entwerfen

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 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:

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.

Eine Variante dieses Szenarios ist, wenn Sie den Perimeterzugriff von privaten Ressourcen, die in einem anderen Projekt oder einer anderen Organisation bereitgestellt wurden. In diesem Anwendungsfall ist im Quellprojekt ein Cloud NAT-Gateway 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 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

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 innerhalb des Perimeters, über vertrauenswürdige lokale Netzwerke oder über vertrauenswürdige Geräte zugegriffen werden. 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 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.
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 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 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.
Sorgen Sie dafür, dass die Sicherheitsteams und die Teams für die Reaktion auf Vorfälle über die Bereitstellung informiert sind. 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 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.

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