Dienstperimeter entwerfen und erstellen

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

Da sich der Schutz von VPC Service Controls auf die Funktionalität von Cloud-Diensten auswirkt, sollten Sie die Aktivierung von VPC Service Controls im Voraus planen und VPC Service Controls beim Entwerfen der Architektur berücksichtigen. Es ist wichtig, das Design von VPC Service Controls so einfach wie möglich zu halten. Wir empfehlen, Perimeterdesigns zu vermeiden, die mehrere Bridges, Perimeter-Netzwerkprojekte oder einen DMZ-Perimeter und komplexe Zugriffsebenen verwenden.

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 außerdem den Vorteil eines geringeren Verwaltungsaufwands für die Teams, die für die Erstellung und Wartung von Perimetern zuständig sind. Da Dienste und Netzwerkressourcen innerhalb eines Perimeters mit den erforderlichen IAM- und Netzwerkkontrollberechtigungen ungehindert kommunizieren können, kümmern sich die für die Perimeterverwaltung verantwortlichen Teams hauptsächlich um den Nord-Süd-Zugriff, also den Zugriff vom Internet auf Ressourcen innerhalb des Perimeters.

Wenn eine Organisation mehrere kleinere Perimeter verwendet, müssen Teams für die Perimeterverwaltung neben dem Nord-Süd-Traffic von außerhalb der Organisation auch Ressourcen für die Verwaltung des Ost-West-Traffics zwischen den Perimetern einer Organisation zuweisen. Je nach Größe der Organisation und Anzahl der Perimeter kann dieser Aufwand beträchtlich sein. Wir empfehlen, den Perimeter mit zusätzlichen Sicherheitskontrollen und Best Practices zu überlagern. So sorgen Sie z. B. dafür, dass Ressourcen im VPC-Netzwerk keinen direkten ausgehenden Internettraffic haben.

Dienstperimeter sollen nicht die Notwendigkeit von IAM-Steuerelementen ersetzen oder reduzieren. Achten Sie beim Definieren der Zugriffssteuerung darauf, dass das Prinzip der geringsten Berechtigung befolgt und die Best Practices für IAM angewendet werden.

Weitere Informationen finden Sie unter Dienstperimeter erstellen.

Mehrere Perimeter in einer Organisation verwenden

In bestimmten Anwendungsfällen können mehrere Perimeter für eine Organisation erforderlich sein. Beispiel: Eine Organisation, die Gesundheitsdaten verarbeitet, benötigt möglicherweise einen Perimeter für vertrauenswürdige, nicht verschleierte Daten und einen separaten Perimeter für de-identifizierte Daten niedrigerer Ebene, um die Freigabe mit externen Entitäten zu vereinfachen und gleichzeitig die vertrauenswürdigen Daten zu schützen.

Wenn Ihre Organisation Standards wie PCI DSS einhalten möchte, sollten Sie einen separaten Perimeter um Ihre regulierten Daten einrichten.

Wenn die Datenfreigabe ein primärer Anwendungsfall für Ihre Organisation ist, sollten Sie die Verwendung von mehr als einem Perimeter in Betracht ziehen. Wenn Sie Daten einer niedrigeren Ebene wie de-identifizierte Patientengesundheitsdaten erstellen und freigeben, können Sie einen separaten Perimeter verwenden, um die Freigabe für externe Entitäten zu erleichtern. Weitere Informationen finden Sie in den Referenzmustern für den sicheren Datenaustausch.

Wenn Sie in Ihrer Google Cloud-Organisation außerdem unabhängige Mandanten von Drittanbietern wie Partner oder Kunden hosten, sollten Sie für jeden Mandanten einen Perimeter definieren. Wenn Sie das Verschieben von Daten von einem dieser Mandanten zu einem anderen als Exfiltration betrachten, empfehlen wir die Implementierung eines separaten Perimeters.

Perimeterdesign

Wir empfehlen, alle geschützten Dienste beim Erstellen eines Perimeters zu aktivieren. Dadurch wird die betriebliche Komplexität reduziert und potenzielle Exfiltrationsvektoren werden minimiert. Da APIs ungeschützt bleiben, erhöht sich die Anzahl der Exfiltrationsvektoren. Daher sollten Sie eine Überprüfung und Rechtfertigung vorbringen, falls Ihre Organisation sich dafür entscheidet, eine API und nicht eine andere zu schützen.

Alle neuen Projekte müssen den Überprüfungs- und Qualifizierungsprozess durchlaufen, der in den folgenden Abschnitten beschrieben wird. 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 Insider-Daten-Exfiltration auf. Wenn Sie den Zugriff auf einen nicht unterstützten Dienst zulassen müssen, versuchen Sie, die Verwendung nicht unterstützter Dienste in ein separates Projekt zu isolieren oder die gesamte Arbeitslast außerhalb des Perimeters zu verschieben.

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 in 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 Erzwingung von VPC Service Controls ist eindeutig, sodass diese Art der Abhängigkeit in einem Perimeter möglicherweise nicht funktioniert. Wir empfehlen, dass Sie die Arbeitslast ändern, um die Anforderung an nicht unterstützte Dienste in einem separaten Projekt zu isolieren, oder die Arbeitslast ganz aus dem Perimeter herausnehmen.

  • 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. Wie Sie dieses Problem umgehen können, wird im Thema Design der Zulassungsliste beschrieben. Wir empfehlen jedoch, die Perimeterkomplexität zu minimieren.

Nächste Schritte