Dienstperimeter entwerfen und einrichten

In diesem Dokument werden empfohlene Bereitstellungsarchitekturen für VPC Service Controls beschrieben. Dieses Dokument richtet sich an Netzwerkadministratoren, Sicherheitsarchitekten und Cloud-Systemadministratoren, die in Google Cloud große Bereitstellungen in Produktionsumgebungen ausführen und betreiben und das Risiko des Verlusts sensibler Daten minimieren möchten.

Da der Schutz von VPC Service Controls Auswirkungen auf die Funktionalität von Cloud-Diensten hat, empfehlen wir, die Aktivierung von VPC Service Controls im Voraus zu planen und bereits während der Architekturentwicklung zu berücksichtigen. Es ist wichtig, VPC Service Controls so einfach wie möglich zu halten. Vermeiden Sie Perimeterentwürfe, die mehrere Bridges, Perimeternetzwerkprojeke oder einen DMZ-Perimeter und komplexe Zugriffsebenen verwenden.

Einen gemeinsamen einheitlichen Perimeter verwenden

Ein einzelner großer Perimeter, der als gemeinsamer einheitlicher Perimeter bezeichnet wird, bietet im Vergleich zur Verwendung mehrerer segmentierter Perimeter den effektivsten Schutz vor Daten-Exfiltration.

Ein gemeinsamer einheitlicher Perimeter bietet auch den Vorteil eines geringeren Verwaltungsaufwands für die Teams, die für die Erstellung und Wartung des Perimeters verantwortlich sind. Da Dienste und Netzwerkressourcen innerhalb eines Perimeters mit den erforderlichen IAM- und Netzwerksteuerungsberechtigungen frei kommunizieren können, konzentrieren sich die für die Perimeterverwaltung zuständigen Teams hauptsächlich auf den Nord-Süd-Zugriff, d. h. den Zugriff aus dem Internet auf Ressourcen innerhalb des Perimeters.

Wenn eine Organisation mehrere kleinere Perimeter verwendet, müssen die Perimeter-Verwaltungsteams Ressourcen für die Verarbeitung des Ost-West-Traffics zwischen den Perimetern der Organisation sowie für den Nord-Süd-Traffic von außerhalb der Organisation bereitstellen. Je nach Größe der Organisation und Anzahl der Perimeter kann dieser Aufwand erheblich sein. Wir empfehlen, Ihren Perimeter mit zusätzlichen Sicherheitskontrollen und Best Practices zu schützen, z. B. dafür zu sorgen, dass Ressourcen im VPC-Netzwerk keinen direkten Internetzugang haben.

Dienstperimeter sollen IAM-Steuerungen nicht ersetzen oder überflüssig machen. Wenn Sie die Zugriffssteuerung festlegen, sollten Sie darauf achten, dass das Prinzip der geringsten Berechtigung eingehalten und IAM-Best Practices angewendet werden.

Weitere Informationen finden Sie unter Dienstperimeter erstellen.

Mehrere Perimeter in einer Organisation verwenden

Für bestimmte Anwendungsfälle sind möglicherweise mehrere Perimeter für eine Organisation erforderlich. Eine Organisation, die Gesundheitsdaten verarbeitet, möchte beispielsweise einen Perimeter für nicht verschleierte Daten mit hohem Vertrauensniveau und einen separaten Perimeter für de-identifizierte Daten auf niedrigerer Stufe verwenden, um die Freigabe für externe Entitäten zu erleichtern und gleichzeitig die Daten mit hohem Vertrauensniveau zu schützen.

Wenn Ihre Organisation Standards wie PCI DSS einhalten muss, sollten Sie einen separaten Perimeter für Ihre regulierten Daten einrichten.

Wenn die Datenfreigabe für Ihre Organisation der primäre Anwendungsfall ist, sollten Sie mehr als einen Perimeter nutzen. Wenn Sie Daten auf niedrigerer Stufe wie de-identifizierte Patientendaten erstellen und freigeben, können Sie einen separaten Perimeter verwenden, um die Freigabe an externe Entitäten zu erleichtern. Weitere Informationen finden Sie in den Referenzmustern für den sicheren Datenaustausch.

Wenn Sie Ihre Google Cloud -Organisation dazu einsetzen, unabhängige Drittanbietermandanten wie Partner oder Kunden zu hosten, sollten Sie für jeden Mandanten einen Perimeter festlegen. Wenn Sie die Datenübertragung von einem dieser Mandanten zu einem anderen als Exfiltration betrachten, sollten Sie einen separaten Perimeter implementieren.

Perimeterdesign

Wir empfehlen, bei der Erstellung eines Perimeters alle geschützten Dienste zu aktivieren, um die betriebliche Komplexität zu verringern und potenzielle Exfiltrationsvektoren zu minimieren. Da ungeschützte APIs mögliche Exfiltrationsvektoren vergrößern, sollten Überprüfungen und Begründungen erfolgen, wenn sich Ihre Organisation dafür entscheidet, eine API zu schützen und eine andere nicht.

Alle neuen Projekte sollten den in den folgenden Abschnitten beschriebenen Prüf- und Qualifikationsprozess durchlaufen. Fügen Sie alle Projekte, die die Qualifikationsbedingungen erfüllen, in den Perimeter ein.

Achten Sie darauf, dass von keiner der VPCs im Perimeter ein Pfad zur privaten VIP führt. Wenn Sie eine Netzwerkroute zu private.googleapis.com zulassen, heben Sie den VPC Service Controls-Schutz vor Daten-Exfiltration durch Insider auf. Wenn Sie den Zugriff auf einen nicht unterstützten Dienst zulassen müssen, versuchen Sie, die Verwendung nicht unterstützter Dienste in einem separaten Projekt zu isolieren, oder verschieben Sie die gesamte Arbeitslast aus dem Perimeter.

Projekte prüfen und qualifizieren

Ein typisches Unternehmen hat viele Projekte, die Arbeitslasten und übergeordnete Strukturen wie Steuerungsebenen, Data Lakes, Geschäftseinheiten und Lebenszyklusphasen darstellen. Zusätzlich zum Organisieren dieser Projekte und Komponenten in Ordnern empfehlen wir Ihnen, sie für die Verwendung innerhalb oder außerhalb eines Perimeters von VPC Service Controls zu qualifizieren. Berücksichtigen Sie dabei die folgenden Fragen:

  • Gibt es eine Komponente, die zwingend von einem Dienst abhängt, der von VPC Service Controls nicht unterstützt wird?

    Die Durchsetzung von VPC Service Controls ist eindeutig. Diese Art von Abhängigkeit funktioniert daher möglicherweise nicht in einem Perimeter. Wir empfehlen, die Arbeitslast so zu ändern, dass die Anforderungen für nicht unterstützte Dienste in einem separaten Projekt isoliert werden, oder die Arbeitslast vollständig aus dem Perimeter zu entfernen.

  • Gibt es eine Komponente, die keine sensiblen Daten enthält und keine sensiblen Daten aus anderen Projekten nutzt?

Wenn Sie eine der vorherigen Fragen mit „Ja“ beantwortet haben, empfehlen wir, das Projekt nicht in einen Perimeter zu verschieben. Sie können dieses Problem umgehen, wie im Thema Konfiguration von Zulassungslisten beschrieben. Es empfiehlt sich jedoch, die Perimeter-Komplexität zu minimieren.

Nächste Schritte