Probelaufmodus für Dienstperimeter

Wenn Sie VPC Service Controls verwenden, kann es schwierig sein, die Auswirkungen auf Ihre Umgebung zu ermitteln, wenn ein Dienstperimeter erstellt oder geändert wird. Im Probelaufmodus können Sie die Auswirkungen der Aktivierung von VPC Service Controls und Änderungen an Perimetern in vorhandenen Umgebungen besser nachvollziehen.

Im Probelaufmodus werden Anfragen, die gegen die Perimeter-Richtlinie verstoßen, nicht abgelehnt, sondern nur protokolliert. Der Probelaufmodus wird verwendet, um die Perimeterkonfiguration zu testen und die Nutzung von Diensten zu überwachen, ohne den Zugriff auf Ressourcen zu verhindern. Zu den häufigsten Anwendungsfällen gehören:

  • Auswirkungen von Änderungen an vorhandenen Dienstperimetern bestimmen.

  • Auswirkungen neuer Dienstperimeter bestimmen.

  • Anfragen an geschützte Dienste überwachen, die von außerhalb eines Dienstperimeters stammen. Sie können beispielsweise ermitteln, woher Anfragen an einen bestimmten Dienst stammen, oder eine unerwartete Dienstnutzung in Ihrer Organisation identifizieren.

  • In Ihren Entwicklungsumgebungen eine ähnliche Perimeter-Architektur wie in Ihrer Produktionsumgebung 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 integriert 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 behoben werden können, können Sie die Probelaufkonfiguration des Perimeters beibehalten und die Logs auf unerwartete Ablehnungen überwachen, die möglicherweise auf den Versuch einer Exfiltration hindeuten. Anfragen an den Perimeter werden jedoch nicht abgelehnt.

Konzepte des Probelaufmodus

Der Probelaufmodus dient als zweiter Evaluationsdurchlauf 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 erzwungene Moduskonfiguration übernimmt, müssen bei jedem Schritt beide Konfigurationen gültig sein. Insbesondere kann sich ein Projekt nur in einem Perimeter in der erzwungenen Konfiguration und in einem Perimeter in der Probelaufkonfiguration befinden. Daher müssen Änderungen, die sich über mehrere Perimeter erstrecken, z. B. das Verschieben eines Projekts zwischen Perimetern, in der ordnungsgemäßen Reihenfolge vorgenommen werden.

Im Probelaufmodus wird eine Anfrage nur dann protokolliert, wenn sie die folgenden Kriterien erfüllt:

  • Die Anfrage wird nicht durch die erzwungene Konfiguration des Perimeters abgelehnt.

  • Die Anfrage verstößt gegen die Konfiguration des Probelaufs des Perimeters.

Sie können auch Perimeter erstellen, die nur eine Probelaufkonfiguration haben. Auf diese Weise können Sie die Auswirkungen eines neuen erzwungenen Perimeters in Ihrer Umgebung simulieren.

Richtliniensemantik

Im folgenden Abschnitt werden die Richtlinienbeziehung zwischen dem erzwungenen und dem Probelaufmodus sowie die Reihenfolge der Erzwingung beschrieben.

Eindeutige Mitgliedschaftsbeschrä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 in demselben Perimeter liegen. 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 unverändert ist, übernimmt sie corp-storage von der erzwungenen Konfiguration.

Um die Auswirkungen zu testen, entfernen Sie zuerst corp-storage aus der Probelaufkonfiguration für PA und fügen das Projekt zur Probelaufkonfiguration für PB hinzu. Sie müssen corp-storage zuerst aus der Probelaufkonfiguration für PA entfernen, da Projekte jeweils nur in einer Probelaufkonfiguration vorhanden sein können.

Wenn Sie sicher sind, dass die Migration von corp-storage von PA zu PB keine negativen Auswirkungen auf Ihren Sicherheitsstatus hat, können Sie die Änderungen erzwingen.

Es gibt zwei Möglichkeiten, die Änderungen an den Perimetern PA und PB zu erzwingen:

  • Sie können corp-storage aus der erzwungenen Konfiguration für PA manuell entfernen und das Projekt der erzwungenen Konfiguration für PB hinzufügen. Da corp-storage immer nur in einer einzigen erzwungenen Konfiguration vorhanden sein kann, müssen Sie die Schritte in dieser Reihenfolge ausführen.

    -or-

  • Sie können das gcloud-Befehlszeilentool oder die Access Context Manager API verwenden, um alle Konfigurationen für den Probelauf 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 PA corp-storage bereits 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 Richtlinien für Probeläufe protokolliert. Anfragen, die von der erzwungenen 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, Zugriffsebenen haben jedoch keine Probelaufkonfiguration. In der Praxis bedeutet dies, dass Sie testen können, wie sich eine Änderung an einer Zugriffsebene auf die Probelaufkonfiguration auswirken würde:

  1. Erstellen Sie eine Zugriffsebene, die die Änderungen widerspiegelt, die Sie an einer vorhandenen Zugriffsebene vornehmen möchten.

  2. 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 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 erwartet durch die erzwungene Konfiguration des Perimeters PA geschützt.

Probelaufaktionen und Konfigurationsstatus

Mit dem Probelauf-Feature können Sie folgende Aufgaben ausführen:

  • Einen Perimeter nur mit 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:

Von erzwungener Konfiguration übernommen: 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 angezeigt 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. Selbst wenn Änderungen an der Probelaufkonfiguration vorgenommen werden, bleibt der Status Neu, bis für diesen Perimeter eine erzwungene Konfiguration festgelegt ist.

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

Der Probelaufmodus gilt nur für Perimeter. Sie erfahren nicht, welche Auswirkungen die Beschränkung des Google Cloud API-Zugriffs auf die eingeschränkte oder private VIP hat. Sie sollten darauf achten, dass alle Dienste, die Sie verwenden möchten, auf der eingeschränkten VIP verfügbar sind, bevor Sie die Domain restricted.googleapis.com konfigurieren.

Wenn Sie nicht sicher sind, ob die APIs, die Sie in einer vorhandenen Umgebung verwenden, von der eingeschränkten VIP unterstützt werden, empfehlen wir die Verwendung der privaten VIP. 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 Privatnutzerversionen 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 böswillige Nutzer innerhalb Ihres Netzwerks Daten über diese ungesicherten Dienste exfiltrieren können.

Nächste Schritte