Steuerelemente, die den Zugriff auf einzeln genehmigte APIs einzuschränken

Last reviewed 2024-02-06 UTC

Viele Organisationen haben eine Complianceanforderung, um den Netzwerkzugriff auf eine explizit genehmigte Liste von APIs auf der Grundlage interner Anforderungen oder als Teil der Assured Workloads einzuschränken. In lokaler Umgebung wird diese Anforderung oft mit Proxy-Steuerungen erfüllt, aber in Ihrer Google Virtual Private Cloud (VPC) können Sie diese Anforderung stattdessen mit der Organisationsrichtlinie zur Einschränkung der Nutzung von Ressourcendiensten erfüllen. Mit dieser Richtlinie können Administratoren definieren, welche Google Cloud-Ressourcen in ihrer Ressourcenhierarchie erstellt werden können. Um diese Organisationsrichtlinie jedoch effektiv zu nutzen, müssen Sie verschiedene Netzwerksteuerungen in Ihrer Umgebung abgleichen.

In diesem Dokument wird beschrieben, wie Sie den Zugriff auf einzeln genehmigte Google APIs mithilfe des Organisationsrichtliniendienstes und anderer Netzwerkkontrollen einschränken können, sowie die Herausforderungen bei der Anwendung des proxybasierten Ansatzes in lokaler Umgebung auf Google Cloud-Dienste. Dieses Dokument richtet sich an Netzwerkadministratoren oder Sicherheitsteams, die einschränken möchten, welche Google Cloud APIs von ihren VPC-Netzwerkendpunkten aus erreicht werden können.

Herausforderungen mit Proxys für die Zugriffssteuerung auf Google APIs

In einem lokalen Netzwerk hat Ihr Unternehmen möglicherweise eine Compliance-Anforderung, um ausgehenden Traffic nur für genehmigte Dienste und Domains zuzulassen. Um diese Anforderung zu erzwingen kann der ausgehende Traffic über einen Webproxy oder ein sicheres Zugriffsgateway gefiltert werden. Dieser Proxy fängt den gesamten ausgehenden Traffic ab und lässt ausgehenden Traffic nur für explizit genehmigte APIs zu.

In einigen Unternehmen besteht möglicherweise eine Complianceanforderung, um den Zugriff von Ihrem VPC-Netzwerk auf genehmigte Google Cloud APIs zu beschränken. Diese Compliancesteuerung wird häufig in folgenden Szenarien gezeigt:

  • Ein Unternehmen verwendet Assured Workloads für sensible Arbeitslasten und Compliancesteuerungen.
  • Ein Unternehmen hat interne Compliance-Anforderungen, nach denen Netzwerkendpunkte in Google Cloud nur auf Google Cloud APIs zugreifen dürfen, die über einen internen Prozess genehmigt wurden.
  • Ein Unternehmen möchte IaaS-Arbeitslasten (Infrastructure as a Service) mit minimaler Refaktorierung zu Google Cloud migrieren.
  • Ein Unternehmen hat noch keine Steuerelemente für die Cloud entwickelt und möchte die vorhandenen Kontrollen aus der lokalen Umgebung erweitern.

Obwohl Ihr Unternehmen möglicherweise einen Webproxy verwendet, um den ausgehenden Traffic von seinem lokalen Netzwerk zu Webdiensten zu steuern, wird dieser Ansatz nicht empfohlen, um den Zugriff von Ihrem VPC-Netzwerk auf Google Cloud APIs zu steuern. Die Verwendung dieses Proxy-Ansatzes führt zu Problemen bei der Skalierbarkeit, schafft einen Single Point of Failure und geht nicht auf die Risiken der Daten-Exfiltration durch Google Cloud APIs ein.

Wir empfehlen die Verwendung der Organisationsrichtlinie Nutzung von Ressourcendiensten einschränken anstelle von Proxys, um selektiv den Zugriff auf einzelne Google Cloud APIs zuzulassen. In den folgenden Abschnitten werden die Herausforderungen im Zusammenhang mit dem Erstellen und Verwalten eines Webproxys für die Zugriffssteuerung auf einzelne Google APIs erläutert.

Von mehreren Google APIs verwendete freigegebene IP-Adressbereiche

Sie können den Zugriff auf eine einzelne Google API nicht durch einen Proxy oder eine Firewallregel steuern, die nach einer einzelnen IP-Adresse filtert. Google verwendet einen dynamischen Bereich von IP-Adressen für Standarddomains. Innerhalb dieser IP-Adressen besteht keine 1:1-Beziehung zwischen einer dedizierten IP-Adresse und einer bestimmten API.

Von Google APIs verwendete freigegebene Domains

Bei einigen Google APIs können Sie den Netzwerkzugriff nicht durch Filtern des Traffics auf Domains steuern. Die meisten Google APIs sind über Endpunkte erreichbar, die bestimmte APIs nach Pfad unterscheiden und mit einem URI beginnen, der mit www.googleapis.com beginnt. Bestimmte Google APIs verwenden einen Endpunkt mit einer dedizierten Subdomain. Beispielsweise dokumentiert die Cloud Storage API-Referenz URIs in Bezug auf den storage.googleapis.com/storage/v1-Endpunkt. Sie können aber auch einen URI verwenden, der mit www.googleapis.com/storage/v1 beginnt, um diese API-Methoden aufzurufen.

Wenn Sie mehrere APIs verwenden, die nur Endpunkte in der Domain www.googleapis.com haben, kann der Proxy für ausgehenden Traffic nicht zwischen APIs unterscheiden, die allein auf der Domain basieren. Einige Google Cloud APIs wie Deployment Manager und andere Google APIs wie Tag Manager oder Google Play Games sind beispielsweise nur auf der Domain www.googleapis.com zugänglich. Darüber hinaus verwenden alle Google Cloud APIs standardmäßig die TLS-Verschlüsselung. Wenn Sie eine dieser APIs zulassen, aber die anderen blockieren möchten, muss Ihr Proxy die Anfrage entschlüsseln, um nach dem URI-Pfad zu filtern, was die Komplexität erhöht.

Durch Proxys verursachte

Wenn der gesamte Traffic von Ihrem VPC-Netzwerk zu Google APIs über einen ausgehenden Proxy geleitet werden muss, kann der Proxy zum Engpass werden. Wenn Sie einen ausgehenden Proxy für Traffic von Ihrem VPC-Netzwerk zu Google APIs verwenden, empfehlen wir, den Proxy für Hochverfügbarkeit zu erstellen, um eine Dienstunterbrechung zu vermeiden. Die Wartung und Skalierung des Proxys kann kompliziert werden, denn wenn Ihr Unternehmen wächst, könnte der Proxy einen Single Point of Failure, Latenz und verringerten Durchsatz verursachen. Er kann sich besonders auf Vorgänge auswirken, die große Datenmengen übertragen.

Risiko der Dienst-zu-Dienst-Exfiltration

Ein Webproxy kann einschränken, ob eine Google API von Ihrem VPC-Netzwerk aus erreichbar ist, jedoch nicht andere Exfiltrationspfade, die die Google API verwenden. Beispielsweise hat ein Mitarbeiter in Ihrem Unternehmen möglicherweise gültige IAM-Berechtigungen zum Lesen interner Cloud Storage-Buckets. Mit dieser Berechtigung können sie interne Daten lesen und dann in einen öffentlichen Bucket kopieren. Der ausgehende Proxy kann weder API-zu-API-Traffic beschränken, der nicht von Ihrer VPC stammt, noch einschränken, wie der Internet-Traffic die öffentlichen Endpunkte für Google Cloud APIs erreicht.

Bei sensiblen Daten hilft ein VPC Service Controls-Perimeter, diese Art der Daten-Exfiltration zu minimieren. Das Erzwingen eines VPC Service Controls-Perimeters trägt dazu bei, Ressourcen innerhalb des Perimeters vor falsch konfigurierten IAM-Richtlinien, Daten-Exfiltration und manipulierten Anmeldedaten zu schützen.

Netzwerksteuerung konfigurieren, um nicht genehmigte Dienste einzuschränken

Wenn Sie den Zugriff auf Dienste mit der Organisationsrichtlinie „Ressourcendienstnutzung einschränken“ einschränken, müssen Sie berücksichtigen, wie Ihr VPC-Netzwerk den ausgehenden Traffic und die Exfiltrationspfade einschränkt. In den folgenden Abschnitten werden Best Practices für das Netzwerkdesign beschrieben, mit denen Sie die Organisationsrichtlinie „Ressourcendienstnutzung einschränken“ effektiv nutzen können.

VPC Service Controls konfigurieren

Wenn Sie die Organisationsrichtlinie „Ressourcendienstnutzung einschränken“ verwenden, sollten Sie auch VPC Service Controls konfigurieren. Durch Anwenden der Organisationsrichtlinie in einem Projekt schränken Sie ein, welche Dienste in diesem Projekt verwendet werden können. Die Organisationsrichtlinie verhindert jedoch nicht, dass Dienste in diesem Projekt mit Diensten in anderen Projekten kommunizieren. Im Vergleich dazu können Sie mit VPC Service Controls einen Perimeter definieren, um die Kommunikation mit Diensten außerhalb des Perimeters zu verhindern.

Wenn Sie beispielsweise eine Zulassungsrichtlinie definieren, die Compute Engine in Ihrem Projekt zulässt und Cloud Storage ablehnt, kann eine VM in diesem Projekt kein Cloud Storage-Bucket in Ihrem Projekt erstellen oder mit diesem kommunizieren. Die VM kann jedoch Anfragen an einen Cloud Storage-Bucket in einem anderen Projekt senden, sodass eine Exfiltration über den Cloud Storage-Dienst weiterhin möglich ist. Wenn Sie die Kommunikation mit Cloud Storage oder anderen Google-Diensten außerhalb des Perimeters blockieren möchten, müssen Sie einen VPC Service Controls-Perimeter konfigurieren.

Verwenden Sie diese Steuerelemente zusammen, um genehmigte Dienste in Ihrer Umgebung selektiv zuzulassen und eine Reihe an Exfiltrationspfaden zu nicht genehmigten Diensten zu blockieren.

Pfade zum Internet entfernen

Wenn die Ressourcen in Ihrem VPC-Netzwerk direkt mit dem Internet kommunizieren können, gibt es möglicherweise einen alternativen Pfad zu nicht genehmigten Google APIs und anderen Diensten, die Sie blockieren möchten. Daher empfehlen wir, nur interne IP-Adressen auf Ihren VMs zu verwenden, und keine ausgehenden Traffic-Routen über eine NAT- oder Proxylösung zulassen. Die Organisationsrichtlinie zur Einschränkung der Nutzung von Ressourcendiensten schränkt die Exfiltrationspfade ins öffentliche Internet nicht ein, sodass nicht zugelassene Dienste immer noch indirekt von einem Server außerhalb Ihrer Umgebung aufgerufen werden könnten.

Privaten Endpunkt für den API-Zugriff konfigurieren

Zum Steuern von API-Endpunkten in Ihrem Netzwerk empfehlen wir den Zugriff auf Google APIs über Private Service Connect. Wenn Sie den privaten Google-Zugriff so konfigurieren, dass VMs mit nur interner IP-Adresse auf Google APIs zugreifen können, schließt dies den Zugriff auf alle Google APIs ein, einschließlich derer, die nicht von den VPC Service Controls oder der Organisationsrichtlinie zur Einschränkung der Ressourcendienstnutzung unterstützt werden. Sie können den privaten Google-Zugriff auf unterstützte APIs beschränken, indem Sie Private Service Connect zusätzlich mit dem Bundle vpc-sc konfigurieren.

Wenn Sie beispielsweise den privaten Google-Zugriff aktivieren, ist ein privater Netzwerkpfad zu allen Google APIs wie Google Drive oder der Google Maps Platform zulässig. Ein Mitarbeiter kann Daten aus einer Compute Engine-Instanz mithilfe der Google Drive API in sein persönliches Google Drive kopieren. Sie können diesen Exfiltrationspfad verhindern, indem Sie Private Service Connect mit dem vpc-sc-Bündel so konfigurieren, dass es Zugriff auf dieselbe Reihe von Diensten bietet, die von der eingeschränkten virtuellen IP-Adresse (VIP) am Endpunkt restricted.googleapis.com unterstützt werden. Im Vergleich dazu können Sie mit dem privaten Google-Zugriff eine größere Reihe von Google APIs erreichen, wenn Sie die Standarddomains von Google, einen Private Service Connect-Endpunkt, der mit dem Bundle all-apis konfiguriert ist, oder die private VIP (private.googleapis.com) verwenden.

Alternativ können Sie auch Routen zu restricted.googleapis.com konfigurieren. Möglicherweise bevorzugen Sie das eingeschränkte VIP, wenn Sie nicht für jede Region und jedes VPC-Netzwerk in Ihrer Umgebung einen Private Service Connect-Endpunkt einrichten möchten. Wir empfehlen jedoch den Private Service Connect-Ansatz, da Sie einen Endpunkt innerhalb Ihres VPC-Netzwerks erstellen können, im Gegensatz zum eingeschränkten VIP-Ansatz, der eine Route zu einem öffentlich angekündigten Endpunkt erfordert.

Nächste Schritte