Bereichsbezogene Richtlinien sind Zugriffsrichtlinien, die auf bestimmte Ordner oder Projekte beschränkt sind. Sie können sie neben einer Zugriffsrichtlinie anwenden, die für die gesamte Organisation gilt. Mit bereichsbezogenen Richtlinien können Sie die Verwaltung von VPC Service Controls-Perimetern und Zugriffsebenen an Administratoren auf Ordner- und Projektebene delegieren.
Organisationen können nur eine Zugriffsrichtlinie auf Organisationsebene haben. Sie können die Zugriffsrichtlinie auf Organisationsebene auf jeden Ordner oder jedes Projekt in Ihrer Organisation anwenden.
In einigen Fällen möchten Sie die Verwaltung einer Richtlinie für eine Teilmenge der Ressourcen einer Organisation, z. B. einen Ordner, an einen delegierten Administrator delegieren. Sie können neben einer Zugriffsrichtlinie, die für die gesamte Organisation gelten kann, Zugriffsrichtlinien erstellen, die auf bestimmte Ordner oder Projekte beschränkt sind. Mit bereichsbezogenen Richtlinien können Sie die Verwaltung von VPC Service Controls-Perimetern und Zugriffsebenen an Administratoren auf Ordner- und Projektebene delegieren.
Wenn Sie die Verwaltung einer bereichsbezogenen Richtlinie delegieren, können die delegierten Administratoren diese bestimmte Richtlinie ändern oder lesen, nicht aber die Access Context Manager-Richtlinie der Organisation. Die bereichsbezogenen Richtlinien beschränken die Ressourcen, die in einem VPC Service Controls-Perimeter eingeschränkt werden können, und die Sichtbarkeit von Zugriffsebenen.
Verwaltung von Richtlinien mit eingeschränktem Geltungsbereich
Als Access Context Manager-Administrator auf Organisationsebene können Sie bereichsbezogene Richtlinien erstellen, ändern und löschen. Sie können IAM-Bindungen (Identity and Access Management) direkt in der Access Context Manager-Richtlinie angeben und die Verwaltung der Access Context Manager-Richtlinie an andere Nutzer in der Organisation delegieren. Ein Administrator für bereichsbezogene Richtlinien kann Dienstperimeter und Zugriffsebenen in Richtlinien konfigurieren. Ein Administrator für Richtlinien mit Bereich kann jedoch keine neue Richtlinie erstellen oder den Bereich der Richtlinie so ändern, dass sie auf einen anderen Ordner oder ein anderes Projekt angewendet wird.
Hier ist eine Abfolge, wie Administratoren die bereichsbezogenen Richtlinien verwalten:
Der Administrator auf Organisationsebene erstellt eine neue Zugriffsrichtlinie mit einem Bereichsfeld, das auf einen bestimmten Ordner oder ein bestimmtes Projekt verweist.
Der Administrator auf Organisationsebene weist dem delegierten Administrator IAM-Berechtigungen direkt für die Zugriffsrichtlinienressource zu. Der delegierte Administrator hat jetzt Berechtigungen für die bereichsbezogene Richtlinie, aber keine Berechtigungen für andere Richtlinien, es sei denn, der Administrator auf Organisationsebene weist sie dem delegierten Administrator explizit zu.
Der delegierte Administrator kann die Richtlinie jetzt bearbeiten, um Zugriffsebenen und Dienstperimeter zu konfigurieren. Der delegierte Administrator kann auch anderen Nutzern IAM-Berechtigungen für diese Richtlinie gewähren.
Wenn Sie einen Ordner oder ein Projekt löschen, wird auch die Richtlinie gelöscht, die den gelöschten Ordner oder das gelöschte Projekt als Bereich hat. Wenn Sie ein Projekt in einen anderen Knoten in der Organisationshierarchie verschieben, wird die Richtlinie, die auf das Projekt beschränkt ist, nicht automatisch geändert. Sie müssen die mit dem Projekt verknüpfte Richtlinie löschen, die Richtlinie neu erstellen und den Bereich angeben.
Hierarchie von Richtlinien mit eingeschränktem Geltungsbereich
Die Organisationsressource ist der Stammknoten der Google Cloud -Ressourcenhierarchie. Alle Ressourcen, die zu einer Organisation gehören, sind untergeordnete Elemente des Organisationsknotens. Ordner sind ein Gruppierungsmechanismus, der über Projekten liegt. Ordner und Projekte sind untergeordnete Knoten der Organisationsressource.
Das folgende Diagramm zeigt eine Beispielorganisation, die Ordner für jede Abteilung enthält. Die Ordner enthalten Entwicklungs-, Test- und Produktionsprojekte.
In der Beispielorganisation gelten die folgenden Einschränkungen für einen Dienstperimeter oder eine Zugriffsebene in einer bereichsbezogenen Richtlinie:
Dienstperimeter in einer Richtlinie mit Bereich können nur Ressourcen einschränken, die im Bereich dieser Richtlinie vorhanden sind. Beispielsweise kann ein Dienstperimeter in einer Richtlinie, die auf den Ordner „engineering“ beschränkt ist, die Projekte „example-dev“, „example-prod“ und „example-test“ sichern, da sich die Projekte im Ordner „engineering“ befinden.
Wenn die bereichsbezogene Richtlinie auf den Ordner „sales“ angewendet wird, können die Dienstperimeter in dieser Richtlinie keines der Projekte „example-dev“, „example-prod“ und „example-test“ schützen. Der Dienstperimeter in der Bereichsrichtlinie kann jedoch mithilfe von Regeln für eingehenden und ausgehenden Traffic den Zugriff auf Projekte in anderen Ordnern zulassen.
Zugriffsebenen in einer Bereichsrichtlinie sind nur innerhalb des Bereichs der Richtlinie sichtbar. Wenn Sie eine Zugriffsebene in der Richtlinie erstellen, die auf den Ordner „Engineering“ beschränkt ist, kann sie nur von Dienstperimetern und Zugriffsebenen im Ordner „Engineering“ verwendet werden. Dienstperimeter und Zugriffsebenen in anderen Ordnern können die im Ordner „Engineering“ definierte Zugriffsebene nicht verwenden.
Ein Standort, z. B. ein Ordner, in der Ressourcenhierarchie der Organisation „example.com“ kann mehrere Richtlinien haben, die eine Zugriffsebene oder einen Dienstperimeter enthalten. Wenn mehrere Richtlinien vorhanden sind, wird eine Anfrage für Ressourcen in der Organisation „example.com“ anhand der folgenden Regeln ausgewertet:
Eine Richtlinie kann nur einen Bereich enthalten, z. B. einen Ordner. Sie können jedoch für jede Ebene einer Organisation eine Richtlinie erstellen. Wenn der Bereich von Richtlinie 1 beispielsweise der Ordner „Engineering“ ist, können Sie den Ordner „Engineering“ nicht als Bereich einer anderen Richtlinie festlegen. Sie können eine weitere Richtlinie mit dem Bereich festlegen, der auf das untergeordnete Element des Ordners „engineering“ festgelegt ist, z. B. „example-prod“.
Wenn der Geltungsbereich einer Richtlinie für ein Projekt oder ein übergeordnetes Element des Projekts gilt, können Sie das Projekt der Richtlinie hinzufügen. Ein Projekt kann jedoch nur Mitglied eines Dienstperimeters in allen Richtlinien sein. Beispiel: Eine Richtlinie mit dem Bereich „example.com“ kann einen Dienstperimeter mit „example-dev“ definieren. Eine Richtlinie mit dem Bereich „engineering“ oder dem Bereich „example-dev“ kann das Projekt „example-dev“ auch einem Perimeter hinzufügen, der in einem der beiden definiert ist. Dieses Projekt kann jedoch nur in einer dieser drei Richtlinien enthalten sein.