Policy Simulator für Ablehnungsrichtlinien

Mit dem Policy Simulator für Ablehnungsrichtlinien können Sie sehen, wie sich eine Änderung an einer IAM-Ablehnungsrichtlinie auf den Zugriff eines Hauptkontos auswirken kann, bevor Sie die Änderung vornehmen. Mit dem Richtliniensimulator können Sie dafür sorgen, dass Änderungen nicht dazu führen, dass ein Hauptkonto den erforderlichen Zugriff verliert.

Mit dieser Funktion werden nur Ablehnungsrichtlinien ausgewertet. Informationen zum Simulieren anderer Richtlinientypen finden Sie hier:

Funktionsweise des Policy Simulators für Ablehnungsrichtlinien

Mit dem Policy Simulator für Ablehnungsrichtlinien können Sie ermitteln, ob eine Änderung an einer Ablehnungsrichtlinie den Zugriff blockiert, den Ihre Prinzipale verwenden.

Wenn Sie eine Simulation für eine Ablehnungsrichtlinie ausführen, führt der Policy Simulator folgende Schritte aus:

  1. Ruft Zugriffslogs für die Organisation ab, die während des Wiedergabezeitraums generiert wurden. Der Wiedergabezeitraum beträgt 90 Tage.

    Wenn die Organisation seit weniger als 90 Tagen besteht, ruft der Policy Simulator alle Zugriffslogs seit der Erstellung der Organisation ab.

  2. Bestimmt, welche Zugriffslogs für die Simulation relevant sind. Relevante Zugriffslogs sind alle Zugriffslogs, die den letzten Versuch eines Hauptkontos darstellen, mit einer Berechtigung auf eine Ressource zuzugreifen.

  3. Für jedes relevante Zugriffslog wird ermittelt, ob die aktuellen Ablehnungsrichtlinien zusammen mit den vorgeschlagenen Änderungen den versuchten Zugriff zulassen würden. Dieser Vorgang wird als Wiederholung der Zugriffsversuche bezeichnet.

  4. Für jedes Zugriffslog wird der Zugriffsstatus aus der Wiedergabe mit dem Zugriffsstatus in den Zugriffslogs verglichen. Anschließend meldet Policy Simulator alle bisherigen Zugriffsversuche, die im Zugriffslog nicht blockiert wurden, aber bei der Wiederholung blockiert wurden. Diese Unterschiede, die als Zugriffsänderungen bezeichnet werden, zeigen, welche Zugriffsversuche blockiert worden wären, wenn die simulierte Ablehnungsrichtlinie zum Zeitpunkt des Versuchs gültig gewesen wäre.

Wiederholungszeitraum

Der Wiederholungszeitraum ist der Zeitraum, für den der Policy Simulator beim Ausführen einer Simulation Zugriffslogs abruft. Zugriffslogs, die vor dem ersten oder nach dem letzten Tag des Wiedergabezeitraums erfolgen, werden nicht in die Simulation einbezogen.

In der Regel ist der letzte Tag des Replay-Zeitraums ein Tag vor der Simulation. In einigen Fällen kann der letzte Tag des Replay-Zeitraums jedoch bis zu 10 Tage vor der Simulation liegen. Zugriffslogs, die nach dem letzten Tag des Replay-Zeitraums erfolgen, werden nicht in die Simulation einbezogen.

Der Wiedergabezeitraum beträgt 90 Tage. Wenn die Organisation seit weniger als 90 Tagen besteht, ruft der Policy Simulator alle Zugriffsversuche seit der Erstellung der Organisation ab.

Das Replay-Zeitfenster unterliegt ebenfalls der Eventual Consistency. Das bedeutet, dass einige Daten aktueller sein können als andere. Letztendlich haben jedoch alle Daten dieselbe Aktualität.

Ergebnisse des Policy Simulator

Der Policy Simulator meldet die Auswirkungen einer vorgeschlagenen Änderung an einer Ablehnungsrichtlinie als Liste von Zugriffsänderungen. Bei Ablehnungsrichtlinien meldet der Policy Simulator nur die Zugriffsänderung Zugriff widerrufen.

Policy Simulator meldet, dass der Zugriff entzogen wird, wenn Folgendes zutrifft:

  • Der letzte Versuch des Hauptkontos, auf die Ressource zuzugreifen, war erfolgreich.
  • Die vorgeschlagenen Änderungen oder eine andere Ablehnungsrichtlinie blockieren den Zugriff des Hauptkontos auf die Ressource.

Für jede Zugriffsänderung werden im Policy Simulator auch die folgenden Informationen angezeigt:

  • Das Hauptkonto, die Ressource und die Berechtigung, die für den Zugriffsversuch gültig waren.
  • Die Anzahl der Tage im Replay-Zeitraum, an denen das Hauptkonto versucht hat, mit der Berechtigung auf die Ressource zuzugreifen. Diese Summe umfasst nur die Zugriffsversuche, die dasselbe Ergebnis wie der letzte Zugriffsversuch haben.
  • Das Datum des letzten Zugriffsversuchs.

Fehler

Die folgenden Fehler können dazu führen, dass eine Simulation fehlschlägt:

  • Maximale Anzahl gleichzeitiger Simulationen überschritten: Der Nutzer hat bereits 10 laufende Simulationen. Das ist die maximale Anzahl laufender Simulationen, die ein Nutzer haben kann. Warten Sie, bis eine der laufenden Simulationen abgeschlossen ist, und versuchen Sie dann noch einmal, die Simulation auszuführen.
  • Zeitüberschreitung: Die Ausführung der Simulation hat zu lange gedauert und es kam zu einer Zeitüberschreitung. Um das Problem zu beheben, führen Sie die Simulation noch einmal aus.
  • Ungültige Simulationskonstruktion: Die vorgeschlagene Ablehnungsrichtlinie ist ungültig oder enthält nicht unterstützte Ablehnungsregeln. Ein Beispiel für eine ungültige Richtlinie ist eine, die einen ungültigen Bedingungsausdruck enthält. Ein Beispiel für eine nicht unterstützte Ablehnungsregel ist eine Regel, die Prinzipal-IDs für Mitarbeiteridentitäten verwendet. Korrigieren Sie die Richtlinie und versuchen Sie es noch einmal.
  • Zugriff verweigert: Sie sind nicht berechtigt, eine Simulation auszuführen. Prüfen Sie, ob Ihnen die erforderlichen Rollen zugewiesen sind, und versuchen Sie es noch einmal.

Unterstützte Hauptkontotypen

Policy Simulator für Ablehnungsrichtlinien prüft nur Zugriffslogs für die folgenden Arten von Hauptkonten:

Beim Simulieren von Ablehnungsrichtlinien werden in Policy Simulator keine Zugriffslogs für andere Hauptkontotypen geprüft, einschließlich solcher, die auf föderierten Identitäten in einem Workload Identity-Pool basieren. Daher meldet der Policy Simulator nicht, ob sich die vorgeschlagenen Änderungen an Ihren Richtlinien oder Bindungen auf den Zugriff dieser Prinzipale auswirken.

Zugriffsgrenzen für Anmeldedaten simulieren

Sie können Zugriffsgrenzen für Anmeldedaten verwenden, um die IAM-Berechtigungen, die von kurzlebigen Anmeldedaten für den Zugriff auf Cloud Storage-Ressourcen verwendet werden können, herabzustufen oder einzuschränken. Um Berechtigungen einzuschränken, definiert ein Nutzer oder Dienstkonto (der Token-Broker) die verfügbaren Berechtigungen für eine Reihe von Ressourcen in einem eingeschränkten Zugriffstoken und stellt das Zugriffstoken dann einem anderen Nutzer oder Dienstkonto (dem Token-Nutzer) zur Verfügung.

Der Token-Broker muss eine Rolle haben, die die Berechtigungen enthält, die dem Token-Nutzer mit einem herabgestuften Zugriffstoken gewährt werden. Wenn Sie diese Rolle im Tokenbroker ablehnen, wird auch der Zugriff des Token-Consumers entfernt. Der Policy Simulator bewertet jedoch nicht, wie sich Änderungen an den Berechtigungen des Tokenbrokers auf den Zugriff des Token-Consumers auswirken.

Angenommen, einem Nutzer wurde die Rolle Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) für eine Ressource mit einem herabgestuften Zugriffstoken gewährt, das mit einer Zugriffsbeschränkung für Anmeldedaten erstellt wurde.

  • Wenn Sie simulieren, dass die Rolle Storage Legacy Bucket Reader für diesen Nutzer verweigert wird, meldet der Policy Simulator keinen Zugriffsverlust.

  • Wenn Sie das Ablehnen der Rolle Storage Legacy Bucket Reader für den Token-Broker simulieren, wird im Policy Simulator kein Verlust des Zugriffs für den Nutzer gemeldet. Wenn der Zugriff des Token-Brokers innerhalb von 90 Tagen nicht verwendet wird, wird er ebenfalls nicht in die Simulation einbezogen.

Weitere Informationen finden Sie unter Credential Access Boundaries für Cloud Storage.

Nächste Schritte