Bei Verwendung von VPC Service Controls ist es schwierig, die Auswirkungen auf Ihre Umgebung zu bestimmen, wenn ein Dienstperimeter erstellt oder geändert wird. Im Probelaufmodus können Sie die Auswirkungen der Aktivierung von VPC Service Controls und von Änderungen an Perimetern in vorhandenen Umgebungen besser nachvollziehen.
Im Probelaufmodus werden Anfragen, die gegen die Perimeterrichtlinie verstoßen, nicht abgelehnt, sondern nur protokolliert. Mit dem Probelaufmodus können Sie die Perimeterkonfiguration testen und die Nutzung von Diensten überwachen, ohne den Zugriff auf Ressourcen zu verhindern. Zu den häufigsten Anwendungsfällen gehören:
Auswirkungen von Änderungen an vorhandenen Dienstperimetern zu bestimmen.
Auswirkungen neuer Dienstperimeter zu bestimmen.
Anfragen an geschützte Dienste zu beobachten, die von außerhalb eines Dienstperimeters stammen. Sie können beispielsweise feststellen, woher Anfragen an einen bestimmten Dienst stammen, oder eine unerwartete Dienstnutzung in Ihrer Organisation identifizieren.
In Entwicklungsumgebungen eine ähnliche Perimeter-Architektur wie in einer Produktionsumgebung zu erstellen. Auf diese Weise können Sie Probleme identifizieren und minimieren, die durch Ihre Dienstperimeter verursacht werden, bevor Änderungen auf die Produktionsumgebung übertragen werden.
Dienstperimeter können ausschließlich im Probelaufmodus vorhanden sein. Sie können auch Dienstperimeter haben, die eine Kombination aus dem erzwungenen Modus und dem Probelaufmodus verwenden.
Vorteile des Probelaufmodus
Im Probelaufmodus können Sie neue Dienstperimeter erstellen oder mehrere vorhandene Perimeter ändern, ohne dass sich dies auf eine vorhandene Umgebung auswirkt. Anfragen, die gegen die neue Perimeterkonfiguration verstoßen, werden nicht blockiert. Sie können auch die Auswirkungen des Perimeters in einer Umgebung verstehen, in der nicht alle verwendeten Dienste in VPC Service Controls eingebunden sind.
Sie können die VPC Service Controls-Logs auf Ablehnungen analysieren, die Konfiguration ändern, um potenzielle Probleme zu beheben, und dann den neuen Sicherheitsstatus erzwingen.
Wenn Probleme mit der Perimeterkonfiguration nicht gelöst werden können, haben Sie die Möglichkeit, die Probelaufkonfiguration des Perimeters beizubehalten und die Logs auf unerwartete Ablehnungen zu überwachen, die auf einen Exfiltrationsversuch hindeuten können. Anfragen an den Perimeter werden jedoch nicht abgelehnt.
Konzepte für den Probelaufmodus
Der Probelaufmodus dient als zweiter Auswertungsdurchlauf der Perimeterkonfiguration. Die Konfiguration des erzwungenen Modus wird standardmäßig für alle Dienstperimeter auf die Konfiguration des Probelaufmodus übernommen. Dort kann die Konfiguration geändert oder gelöscht werden, ohne dass sich dies auf den Betrieb des Dienstperimeters auswirkt.
Da der Probelaufmodus die Konfiguration des erzwungenen Modus übernimmt, müssen bei jedem Schritt beide Konfigurationen gültig sein. Ein Projekt kann sich nur in einem Perimeter in der erzwungenen Konfiguration und einem Perimeter in der Probelaufkonfiguration befinden. Daher müssen Änderungen, die sich auf mehrere Perimeter beziehen, z. B. das Verschieben eines Projekts zwischen Perimetern, in der richtigen Reihenfolge erfolgen.
Im Probelaufmodus wird eine Anfrage nur protokolliert, wenn sie die beiden folgenden Kriterien erfüllt:
Die Anfrage wird nicht bereits durch die erzwungene Konfiguration des Perimeters abgelehnt.
Die Anfrage verstößt gegen die Probelaufkonfiguration des Perimeters.
Wenn beispielsweise identische Probelaufkonfigurationen und Konfigurationen im erzwungenen Modus einen Cloud Storage-Bucket einschränken, blockiert und protokolliert der erzwungene Modus jede Anfrage an den Cloud Storage-Bucket. Im Probelaufmodus werden nur die Unterschiede bei Verstößen im Vergleich zum erzwungenen Modus protokolliert.
Sie können auch Perimeter erstellen, die nur eine Probelaufkonfiguration haben. Dadurch können Sie die Auswirkungen eines neuen erzwungenen Perimeters in Ihrer Umgebung simulieren.
Semantik für Richtlinien
Im folgenden Abschnitt werden die Richtlinienbeziehung zwischen dem erzwungenen und dem Probelaufmodus sowie die Reihenfolge der Erzwingung beschrieben.
Einmalige Mitgliedschaftseinschränkung
Ein Google Cloud-Projekt kann nur in jeweils einer erzwungenen Konfiguration und einer Probelaufkonfiguration enthalten sein. Die erzwungene Konfiguration und die Probelaufkonfiguration müssen jedoch nicht für denselben Perimeter erfolgen. So können Sie die Auswirkungen einer Projektverschiebung von einem Perimeter auf einen anderen testen, ohne die derzeit auf das Projekt angewendete Sicherheit zu beeinträchtigen.
Beispiel
Das Projekt corp-storage wird derzeit durch die erzwungene Konfiguration des Perimeters PA geschützt. Sie möchten die Auswirkungen der Verschiebung von corp-storage auf den Perimeter PB testen.
Die Probelaufkonfiguration für PA wurde noch nicht geändert. Da die Probelaufkonfiguration nicht geändert wurde, übernimmt sie corp-storage aus der erzwungenen Konfiguration.
Entfernen Sie zuerst corp-storage aus der Probelaufkonfiguration für PA und fügen Sie das Projekt der Probelaufkonfiguration für PB hinzu, um die Auswirkungen zu testen.
Sie müssen zuerst corp-storage aus der Probelaufkonfiguration für PA entfernen, da Projekte jeweils nur in einer Probekonfiguration gleichzeitig ausgeführt werden können.
Wenn Sie der Meinung sind, dass die Migration von corp-storage von PA zu PB keine negativen Auswirkungen auf Ihren Sicherheitsstatus hat, beschließen Sie, die Änderungen zu erzwingen.
Es gibt zwei Möglichkeiten, die Änderungen an den Perimetern PA und PB zu erzwingen:
Sie können
corp-storageaus der erzwungenen Konfiguration für PA manuell entfernen und das Projekt der erzwungenen Konfiguration für PB hinzufügen. Da sichcorp-storagenur jeweils in einer einzigen erzwungenen Konfiguration befinden kann, müssen Sie die Schritte in dieser Reihenfolge ausführen.– oder –
Sie können das
gcloud-Befehlszeilentool oder die Access Context Manager API verwenden, um alle Probelaufkonfigurationen zu erzwingen. Dieser Vorgang gilt für alle geänderten Probelaufkonfigurationen für Ihre Perimeter. Deshalb sollten Sie diesen Vorgang mit einer anderen Person in Ihrer Organisation koordinieren, die Probelaufkonfigurationen für Ihre Perimeter geändert hat. Da die Probelaufkonfiguration für PAcorp-storagebereits ausschließt, sind keine weiteren Schritte erforderlich.
Die erzwungene Konfiguration eines Perimeters wird zuerst ausgeführt
Nur Anfragen, die von der erzwungenen Konfiguration eines Perimeters zugelassen, aber von der Probelaufkonfiguration abgelehnt werden, werden als Verstöße gegen die Probelaufrichtlinie protokolliert. Anfragen, die durch die erzwungene Konfiguration abgelehnt, aber von der Probelaufkonfiguration zugelassen werden, werden nicht protokolliert.
Für Zugriffsebenen gibt es keinen Probelaufmodus
Sie können zwar eine Probelaufkonfiguration für einen Perimeter erstellen, aber für Zugriffsebenen gibt es keine Probelaufkonfiguration. Wenn Sie in der Praxis testen möchten, wie sich eine Änderung an einer Zugriffsebene auf die Probelaufkonfiguration auswirken würde, müssen Sie Folgendes tun:
Erstellen Sie eine Zugriffsebene, die die Änderungen widerspiegelt, die Sie an einer vorhandenen Zugriffsebene vornehmen möchten.
Wenden Sie die neue Zugriffsebene auf die Probelaufkonfiguration für den Perimeter an.
Der Probelaufmodus hat keine negativen Auswirkungen auf die Sicherheit
Änderungen an einer Probelaufkonfiguration für einen Perimeter, z. B. das Hinzufügen neuer Projekte oder Zugriffsebenen zu einem Perimeter oder die Änderung der geschützten Dienste oder zugänglichen Netzwerke innerhalb des Perimeters, haben keine Auswirkungen auf die tatsächliche Erzwingung eines Perimeters.
Angenommen, Sie haben ein Projekt, das zum Dienstperimeter PA gehört. Wenn das Projekt der Probelaufkonfiguration eines anderen Perimeters hinzugefügt wird, ändert sich die auf das Projekt angewendete tatsächliche Sicherheit nicht. Das Projekt ist weiterhin wie vorgesehen durch die erzwungene Konfiguration des Perimeters PA geschützt.
Aktionen mit Probelauf und Konfigurationsstatus
Mit der Probelauffunktion können Sie folgende Aufgaben ausführen:
Einen Perimeter mit nur einer Probelaufkonfiguration erstellen
Die Probelaufkonfiguration für einen vorhandenen Perimeter aktualisieren
Ein neues Projekt in einen vorhandenen Perimeter verschieben
Ein Projekt von einem Perimeter in einen anderen verschieben
Die Probelaufkonfiguration eines Perimeters löschen
Entsprechend der im Probelaufmodus ausgeführten Aktion kann ein Perimeter einen der folgenden Konfigurationsstatus haben:
Übernommen von erzwungener Konfiguration: Standardstatus für erzwungene Perimeter. In diesem Status werden alle Änderungen an der erzwungenen Konfiguration des Perimeters auch auf die Probelaufkonfiguration angewendet.
Geändert: Die Probelaufkonfiguration für einen Perimeter wurde aufgerufen oder geändert und dann gespeichert. In diesem Status werden Änderungen an der erzwungenen Konfiguration eines Perimeters nicht auf die Probelaufkonfiguration angewendet.
Neu: Der Perimeter hat nur eine Probelaufkonfiguration. Auch wenn Änderungen an der Probelaufkonfiguration vorgenommen werden, bleibt der Status Neu, bis dieser Perimeter eine erzwungene Konfiguration hat.
Gelöscht: Die Probelaufkonfiguration für den Perimeter wurde gelöscht. Dieser Status bleibt bestehen, bis Sie eine neue Probelaufkonfiguration für den Perimeter erstellen oder die Aktion rückgängig machen. In diesem Status werden Änderungen an der erzwungenen Konfiguration eines Perimeters nicht auf die Probelaufkonfiguration angewendet.
Einschränkungen des Probelaufmodus
Probelaufmodus gilt nur für Perimeter. Sie haben keinen Einfluss auf die Auswirkung der Beschränkung des Zugriffs auf die Google Cloud API auf die eingeschränkte oder private VIP. Bevor Sie die Domain restricted.googleapis.com konfigurieren, sollten Sie dafür sorgen, dass alle Dienste, die Sie verwenden möchten, auf der eingeschränkten VIP verfügbar sind.
Wenn Sie sich nicht sicher sind, ob die APIs, die Sie in einer vorhandenen Umgebung verwenden, von der eingeschränkten VIP unterstützt werden, sollten Sie die private VIP verwenden. Für unterstützte Dienste können Sie weiterhin die Perimetersicherheit erzwingen. Wenn Sie jedoch die private VIP verwenden, haben Entitäten in Ihrem Netzwerk Zugriff auf nicht gesicherte Dienste (Dienste, die von VPC Service Controls nicht unterstützt werden), z. B. die privaten Versionen von Gmail und Drive. Da die private VIP Dienste zulässt, die nicht von VPC Service Controls unterstützt werden, ist es möglich, dass Code, Malware oder schädliche Nutzer in Ihrem Netzwerk Daten mithilfe dieser unsicheren Dienste exfiltrieren.
Weitere Informationen
Befehle des
gcloud-Befehlszeilentools für den Probelaufmodus prüfen