Erste Schritte mit Policys

Bestimmen Sie zunächst, ob und wie Sie bei Policys einsteigen möchten, und machen Sie sich mit allgemeinen Fragen zu Policys vertraut.

Wenn das Thema IAM-Policys für Sie neu ist, erhalten Sie in diesem Abschnitt eine Anleitung zum weiteren Vorgehen.

Während einer Proof-of-Concept-Phase

Erstellen Sie ein Proof-of-Concept-Projekt mit Infrastrukturressourcen.

Wenn Sie Oracle Cloud Infrastructure nur testen oder ein Proof-of-Concept-Projekt mit Infrastrukturressourcen ausführen möchten, benötigen Sie unter Umständen nur wenige Administratoren mit vollständigem Zugriff. In diesem Fall können Sie einfach neue Benutzer erstellen, die Sie benötigen, und diese zur Administratorengruppe hinzufügen. Die Benutzer können alle Aktionen mit jeder beliebigen Art von Ressource ausführen. Außerdem können Sie alle Ressourcen direkt im Mandanten (dem Root-Compartment) erstellen. Sie müssen noch keine Compartments oder andere Policys über die Mandanten-Admin-Policy hinaus erstellen, die automatisch im Mandanten erstellt wird und nicht geändert werden kann.

Hinweis

Vergessen Sie nicht, die neuen Benutzer der Administratorengruppe hinzuzufügen. Nach der Erstellung wird das häufig vergessen.

Nach der Proof-of-Concept-Phase

Einschränkung des Zugriffs auf Ressourcen nach der Proof-of-Concept-Phase.

Nachdem Sie die Proof-of-Concept-Phase abgeschlossen haben und den Zugriff auf Ihre Ressourcen einschränken möchten, führen Sie zunächst die folgenden Schritte aus:

Stellen Sie sicher, dass Sie mit den grundlegenden IAM-Komponenten vertraut sind, und lesen Sie das Beispielszenario: Beispielszenario
Überlegen Sie, wie Sie Ihre Ressourcen in Compartments organisieren: Best Practices zum Einrichten Ihres Mandanten
Lernen Sie die Funktionsweise von Policys kennen: Funktionsweise von Policys
Probieren Sie allgemeine Policys aus: Allgemeine Policys
Weitere Informationen hierzu finden Sie im folgenden Abschnitt.

Weitere Informationen zu Policys

Weitere Informationen zu Policys.

Für welche Services in Oracle Cloud Infrastructure kann ich den Zugriff über Policys kontrollieren?

Für alle, einschließlich IAM selbst. Sie finden spezifische Details zum Schreiben von Policys für jeden Service in der Policy-Referenz.

Können Benutzer Aktionen ausführen, ohne dass ein Administrator eine Policy für sie schreibt?

Ja. Alle Benutzer können folgende Aufgaben automatisch ohne eine explizite Policy ausführen:

Eigenes Konsolenkennwort ändern oder zurücksetzen.
Eigene API-Signaturschlüssel und andere Zugangsdaten verwalten.

Warum soll ich Ressourcen nach Compartments trennen? Kann ich nicht einfach alle Ressourcen in einem Compartment ablegen und dann mithilfe von Policys kontrollieren, welcher Benutzer auf welche Ressourcen zugreifen kann?

Sie können alle Ressourcen in einem einzigen Compartment ablegen und den Zugriff mithilfe von Policys kontrollieren. Allerdings können Sie dann nicht von den Vorteilen der Nutzungsmessung und Abrechnung nach Compartment, der einfachen Policy-Administration auf Compartment-Ebene und der klaren Trennung von Ressourcen zwischen Projekten oder Geschäftseinheiten profitieren.

Kann ich den Zugriff auf einen einzelnen Benutzer kontrollieren oder verweigern?

Ja. Allerdings sind zunächst einige Punkte zu beachten:

Unternehmen verfügen im Allgemeinen über mehrere Benutzer, die ähnliche Berechtigungen benötigen. Daher sind Policys so konzipiert, dass sie Zugriff für Gruppen von Benutzern erteilen, nicht für einzelne Benutzer. Ein Benutzer erhält Zugriff, indem er einer Gruppe angehört.
Policys sollen Zugriff zulassen, und beim Schreiben einer Policy gibt es keine ausdrückliche "Ablehnung".

Wenn Sie einem bestimmten Benutzer Zugriff erteilen müssen, können Sie der Policy eine Bedingung hinzufügen, die die OCID des Benutzers in einer Variablen angibt. Diese Konstruktion schränkt den in der Policy erteilten Zugriff nur auf den in der Bedingung angegebenen Benutzer ein. Beispiel:

allow any-group to read object-family in compartment ObjectStorage where request.user.id ='ocid1.user.oc1..<user_OCID>'

Informationen zur Verwendung von Bedingungen und Variablen in Policys finden Sie unter Bedingungen.

Wenn Sie den Zugriff eines bestimmten Benutzers einschränken müssen, können Sie:

den Benutzer aus der betreffenden Gruppe entfernen
den Benutzer vollständig aus IAM löschen (Sie müssen den Benutzer zuerst aus allen Gruppen entfernen)

Wie lösche ich einen Benutzer?

Stellen Sie zunächst sicher, dass der Benutzer in keiner Gruppe enthalten ist. Erst dann können Sie den Benutzer löschen.

Wie lösche ich ein Compartment?

Siehe Compartment löschen.

Wie erkenne ich, welche Policys für eine bestimmte Gruppe oder einen bestimmten Benutzer gelten?

Sie müssen die einzelnen Anweisungen in allen Policys prüfen, um festzustellen, welche Anweisungen für welche Gruppe gelten. Diese Informationen können derzeit nicht einfach abgerufen werden.

Wie erkenne ich, welche Policys für ein bestimmtes Compartment gelten?

Sie müssen die einzelnen Anweisungen in allen Policys im Mandanten prüfen, um festzustellen, ob sie für das jeweilige Compartment gelten. Sie müssen außerdem Policys im Compartment selbst anzeigen. Policys in einem der gleichgeordneten Compartments können nicht auf das betreffende Compartment verweisen. Sie müssen diese Policys daher nicht prüfen.

Policys

IAM verwendet Policys, um den Zugriff auf Ressourcen einzuschränken.

Standardmäßig sind Policys auf Mandantenebene vorhanden und können auf Identity Domains angewendet werden. Sie können auch Policys mit einem kleineren Geltungsbereich erstellen. Beispiel: Sie beschränken den Zugriff auf eine bestimmte Ressource. Siehe So funktionieren Policys.

Beispielszenario

Beispiele für die Zusammenarbeit verschiedener IAM-Komponenten.

Mit diesem Szenario soll gezeigt werden, wie die verschiedenen IAM-Komponenten zusammen funktionieren. Außerdem werden die grundlegende Features von Policys vermittelt.

In diesem Szenario verfügt "Acme Company" über zwei Teams, die Oracle Cloud Infrastructure-Ressourcen für Infrastruktur verwenden: "Projekt A" und "Projekt B". In Wirklichkeit kann Ihr Unternehmen viele weitere Ressourcen enthalten.

Acme Company plant die Verwendung eines einzelnen virtuellen Cloud-Netzwerks (VCN) für beide Teams und möchte einen Netzwerkadministrator zur Verwaltung des VCN einsetzen.

Außerdem möchte Acme Company dem Team "Projekt A" und dem Team "Projekt B" jeweils eigene Instanzen und Blockspeicher-Volumes zuweisen. Die Teams "Projekt A" und "Projekt B" dürfen keine Instanzen des jeweils anderen Teams verwenden. Diese beiden Teams dürfen ebenfalls keine Änderungen an dem VCN vornehmen, das vom Netzwerkadministrator eingerichtet wurde. Acme Company möchte jedem Team Administratoren für die Ressourcen dieses Teams zuweisen. Die Administratoren für das Team "Projekt A" können entscheiden, wer die Cloud-Ressourcen von "Projekt A" verwenden kann und wie. Dasselbe gilt für das Team "Projekt B".

Acme Company beginnt mit Oracle Cloud Infrastructure

Acme Company registriert sich für die Verwendung von Oracle Cloud Infrastructure und teilt Oracle mit, dass eine Mitarbeiterin mit dem Namen "Wenpei" die Rolle des Standardadministrators übernimmt. Daraufhin führt Oracle folgende Schritte aus:

Oracle erstellt einen Mandanten für Acme Company (siehe folgendes Diagramm).
Oracle erstellt einen IAM-Benutzeraccount für Wenpei im Mandanten.
Oracle erstellt die Administratorengruppe im Mandanten und fügt Wenpei dieser Gruppe hinzu.
Oracle erstellt eine Policy im Mandanten von Acme Company, mit der die Administratorengruppe den erforderlichen Zugriff erhält, um alle Ressourcen im Mandanten verwalten zu können. Dies ist die Policy:

Allow group Administrators to manage all-resources in tenancy

Dieses Bild zeigt den Mandanten mit der anfänglichen Gruppe, dem Benutzer und der Policy.

Der Standardadministrator erstellt einige Gruppen und einen weiteren Administrator

Wenpei erstellt als Nächstes mehrere Gruppen und Benutzer (siehe folgendes Diagramm). Sie führt folgende Schritte aus:

Sie erstellt Gruppen mit dem Namen NetworkAdmins, A-Admins und B-Admins (diese letzten beiden sind für "Projekt A" und "Projekt B" innerhalb des Unternehmens bestimmt).
Sie erstellt einen Benutzer mit dem Namen "Alex" und fügt ihn der Administratorengruppe hinzu.
Sie lässt die neuen Gruppen leer.

Weitere Informationen zum Erstellen von Gruppen finden Sie unter Gruppen verwalten. Weitere Informationen zum Erstellen von Benutzern und zum Aufnehmen von Benutzern in Gruppen finden Sie unter Benutzer verwalten.

Dieses Bild baut auf dem vorherigen Bild auf, indem weitere Benutzer und Gruppen hinzugefügt werden.

Der Standardadministrator erstellt einige Compartments und Policys

Als Nächstes erstellt Wenpei Compartments, um Ressourcen zu gruppieren (siehe folgendes Diagramm). Sie führt folgende Schritte aus:

Sie erstellt das Compartment Networks, um den Zugriff auf das VCN, die Subnetze, das Site-to-Site-VPN und andere Komponenten von Networking in Acme Company zu steuern.
Sie erstellt ein Compartment mit dem Namen Project-A, um die Cloud-Ressourcen des Teams "Projekt A" zu organisieren und den Zugriff darauf zu kontrollieren.
Sie erstellt ein Compartment mit dem Namen Project-B, um die Cloud-Ressourcen des Teams "Projekt B" zu organisieren und den Zugriff darauf zu kontrollieren.

Weitere Informationen zum Verwalten von Compartments finden Sie unter Compartments verwalten.

Wenpei erstellt dann eine Policy, um den Administratoren für jedes Compartment die erforderliche Zugriffsebene zu erteilen. Sie ordnet die Policy dem Mandanten zu. Dies bedeutet, dass nur Benutzer mit Zugriff auf die Verwaltung von Policys in dem Mandanten später die Policy aktualisieren oder löschen können. In diesem Szenario ist dies nur die Administratorengruppe. Die Policy umfasst mehrere Anweisungen, die:

der Gruppe "NetworkAdmins" Zugriff auf die Verwaltung von Netzwerken und Instanzen (zum einfachen Testen des Netzwerks) im Compartment "Networks" erteilen.
den beiden Gruppen "A-Admins" und "B-Admins" Zugriff auf die Netzwerke im Compartment "Networks" erteilen (damit sie Instanzen im Netzwerk erstellen können).
der Gruppe "A-Admins" Zugriff auf die Verwaltung aller Ressourcen im Compartment "Project-A" erteilen.
der Gruppe "B-Admins" Zugriff auf die Verwaltung aller Ressourcen im Compartment "Project-B" erteilen.

So sieht die Policy aus (sie enthält mehrere Anweisungen):

Allow group NetworkAdmins to manage virtual-network-family in compartment Networks
Allow group NetworkAdmins to manage instance-family in compartment Networks

Allow group A-Admins,B-Admins to use virtual-network-family in compartment Networks

Allow group A-Admins to manage all-resources in compartment Project-A

Allow group B-Admins to manage all-resources in compartment Project-B

Beachten Sie die unterschiedlichen Verben (manage, use) sowie die Ressourcen (virtual-network-family, instance-family, all-resources). Weitere Informationen hierzu finden Sie unter Verben und Ressourcentypen. Informationen zum Erstellen von Policys finden Sie unter Policy erstellen.

Wichtig

Die Gruppen "A-Admins" und "B-Admins" können die Ressourcen "virtual-network-family" im Compartment "Networks" verwenden. Sie können jedoch keine Instanzen in diesem Compartment erstellen. Sie können nur Instanzen im Compartment "Project-A" oder "Project-B" erstellen. Denken Sie daran, dass ein Compartment eine logische Gruppierung (keine physische Gruppierung) ist, damit Ressourcen, die sich in demselben VCN befinden, zu unterschiedlichen Compartments gehören können.

Acme Company möchte zulassen, dass die Administratoren der Compartments "Project-A" und "Project-B" entscheiden dürfen, welche Benutzer die Ressourcen in diesen Compartments verwenden können. Daher erstellt Wenpei zwei weitere Gruppen: "A-Users" und "B-Users". Dann fügt sie sechs weitere Anweisungen hinzu, mit denen die Compartment-Administratoren den erforderlichen Zugriff erhalten, um Benutzer zu diesen Gruppen hinzuzufügen und daraus zu entfernen:

Allow group A-Admins to use users in tenancy where target.group.name='A-Users'
Allow group A-Admins to use groups in tenancy where target.group.name='A-Users'

Allow group B-Admins to use users in tenancy where target.group.name='B-Users'
Allow group B-Admins to use groups in tenancy where target.group.name='B-Users'

Allow group A-Admins,B-Admins to inspect users in tenancy
Allow group A-Admins,B-Admins to inspect groups in tenancy

Beachten Sie, dass diese Policy den Projektadministratoren nicht erlaubt, neue Benutzer zu erstellen oder Zugangsdaten für die Benutzer zu verwalten. Sie können entscheiden, welche vorhandenen Benutzer in den Gruppen "A-Users" und "B-Users" enthalten sind. Die letzten beiden Anweisungen sind erforderlich, damit "A-Admins" und "B-Admins" alle Benutzer und Gruppen auflisten und bestätigen können, welche Benutzer zu welcher Gruppe gehören.

Dieses Bild baut auf dem vorherigen Bild auf, indem Compartments und Policy-Anweisungen hinzugefügt werden.


Element	Beschreibung
	An den Mandanten angehängte Policys: `Allow group Administrators to manage all-resources in tenancy` `Allow group NetworkAdmins to manage virtual-network-family in compartment Networks` `Allow group NetworkAdmins to manage instance-family in compartment Networks` `Allow group A-Admins, B-Admins to use virtual-network-family in compartment Networks` `Allow group A-Admins to manage all-resources in compartment Project-A` `Allow group B-Admins to manage all-resources in compartment Project-B` `Allow group A-Admins to use users in tenancy where target.group.name='A-Users'` `Allow group A-Admins to use groups in tenancy where target.group.name='A-Users'` `Allow group B-Admins to use users in tenancy where target.group.name='B-Users'` `Allow group B-Admins to use groups in tenancy where target.group.name='B-Users'` `Allow group A-Admins, B-Admins to inspect users in tenancy` `Allow group A-Admins, B-Admins to inspect groups in tenancy`

Ein Administrator erstellt neue Benutzer

Im Moment befindet sich Alex in der Administratorengruppe und hat jetzt Zugriff zum Erstellen neuer Benutzer. Also stellt er Benutzer mit den Namen "Leslie", "Jorge" und "Cheri" bereit und fügt sie jeweils den Gruppen "NetworkAdmins", "A-Admins" und "B-Admins" hinzu. Alex erstellt auch andere Benutzer, die von den Administratoren für Projekt A und Projekt B den Gruppen "B-Users" und "B-Users" hinzugefügt werden können.

Dieses Bild baut auf dem vorherigen Bild auf, indem neue Benutzer hinzugefügt und in Gruppen eingefügt werden.


Element	Beschreibung
	An den Mandanten angehängte Policys: `Allow group Administrators to manage all-resources in tenancy` `Allow group NetworkAdmins to manage virtual-network-family in compartment Networks` `Allow group NetworkAdmins to manage instance-family in compartment Networks` `Allow group A-Admins, B-Admins to use virtual-network-family in compartment Networks` `Allow group A-Admins to manage all-resources in compartment Project-A` `Allow group B-Admins to manage all-resources in compartment Project-B` `Allow group A-Admins to use users in tenancy where target.group.name='A-Users'` `Allow group A-Admins to use groups in tenancy where target.group.name='A-Users'` `Allow group B-Admins to use users in tenancy where target.group.name='B-Users'` `Allow group B-Admins to use groups in tenancy where target.group.name='B-Users'` `Allow group A-Admins, B-Admins to inspect users in tenancy` `Allow group A-Admins, B-Admins to inspect groups in tenancy`

Der Netzwerkadministrator richtet das Netzwerk ein

Leslie (Mitglied der Gruppe "NetworkAdmins") hat Zugriff auf die Verwaltung der Ressourcen virtual-network-family und instance-family im Compartment "Networks". Sie erstellt ein virtuelles Cloud-Netzwerk (VCN) mit einem einzigen Subnetz in diesem Compartment. Sie richtet außerdem ein Internetgateway für das VCN ein und aktualisiert die Routentabelle des VCN, um Traffic über dieses Gateway zuzulassen. Um die VCN-Konnektivität zum On-Premise-Netzwerk zu testen, startet sie eine Instanz im Subnetz im VCN. In der Startanforderung muss sie angeben, in welchem Compartment die Instanz gespeichert werden soll. Sie gibt das Compartment "Networks" an. Es ist das einzige Compartment, auf das sie Zugriff hat. Dann bestätigt sie die Konnektivität vom On-Premise-Netzwerk zum VCN, indem sie sich über SSH vom On-Premise-Netzwerk bei der Instanz anmeldet.

Leslie beendet ihre Testinstanz und informiert Jorge und Cheri darüber, dass das VCN gestartet wurde und getestet werden kann. Sie teilt ihnen mit, dass ihre Compartments jeweils mit "Project-A" und "Project-B" benannt sind. Weitere Informationen zum Einrichten eines Cloud-Netzwerks finden Sie unter Networking. Weitere Informationen zum Starten von Instanzen im Netzwerk finden Sie unter Compute.

Compartment-Administratoren richten ihre Compartments ein

Jorge und Cheri müssen jetzt ihre jeweiligen Compartments einrichten. Jeder Administrator muss folgende Schritte ausführen:

Instanzen im eigenen Compartment starten
Benutzer einer bestimmten "Benutzer"-Gruppe hinzufügen (z.B. "A-Users")
Den Zugriffstyp für diese Benutzer auswählen und dem Compartment entsprechend eine Policy zuordnen

Jorge und Cheri starten Instanzen im Subnetz im VCN, und zwar in den Compartments ihres jeweiligen Teams. Sie erstellen und hängen Block-Volumes an die Instanzen an. Nur die Compartment-Administratoren können Instanzen starten/beenden oder Block-Volumes an die Compartments des jeweiligen Teams anhängen/von ihnen trennen.

Wichtig

Netzwerktopologie und Compartment-Zugriff sind unterschiedliche Konzepte

Es ist wichtig, den Unterschied zwischen der Netzwerktopologie des VCN und der Zugriffskontrolle durch die Compartments zu verstehen. Die von Jorge gestarteten Instanzen befinden sich aus Sicht der Netzwerktopologie im VCN. Aber in Bezug auf den Zugriff gehören Sie zum Compartment "Project-A", nicht zum Compartment "Networks", in dem sich das VCN befindet. Leslie (der Netzwerkadministrator) kann die Instanzen von Jorge nicht beenden oder neu starten bzw. neue Instanzen im Compartment "Project-A" starten. Leslie kontrolliert jedoch das Netzwerk der Instanzen, sodass sie bestimmt, welcher Traffic an diese Instanzen weitergeleitet wird. Wenn Jorge das Compartment "Networks" anstelle des Compartments "Project-A" beim Starten seiner Instanzen angegeben hat, wurde seine Anforderung abgelehnt. Ähnliches gilt für Cheri und das Compartment "Project-B".

Es ist jedoch auch wichtig anzumerken, dass Wenpei und Alex in der Administratorengruppe Zugriff auf die Ressourcen innerhalb der Compartments haben, da sie Zugriff auf die Verwaltung aller Ressourcentypen im Mandanten haben. Compartments erben alle Policys, die ihrem übergeordneten Compartment (dem Mandanten) zugeordnet sind. Daher gilt der Administratorzugriff auch für alle Compartments innerhalb des Mandanten.

Als Nächstes fügt Jorge mehrere Benutzer, die Alex erstellt hat, in die Gruppe "A-Users" ein. Cheri macht dasselbe für "B-Users".

Dann schreibt Jorge eine Policy, mit der Benutzer die Zugriffsebene erhalten, die sie im Compartment "Project-A" benötigen.

Allow group A-Users to use instance-family in compartment Project-A
Allow group A-Users to use volume-family in compartment Project-A
Allow group A-Users to inspect virtual-network-family in compartment Networks

Auf diese Weise können sie vorhandene Instanzen (mit zugeordneten Block-Volumes) verwenden, die die Compartment-Administratoren bereits im Compartment gestartet haben, und diese stoppen/starten/neu starten. Mitglieder der Gruppe "A-Users" können damit keine Volumes erstellen/löschen oder anhängen/trennen. Um dies zu ermöglichen, muss die Policy manage volume-family enthalten.

Jorge ordnet diese Policy dem Compartment "Project-A" zu. Jeder mit der Möglichkeit, Policys im Compartment zu verwalten, kann diese Policy jetzt ändern oder löschen. Momentan kann nur die Gruppe "A-Admins" diese Vorgänge ausführen (und die Administratorengruppe, die alle Aktionen im gesamten Mandanten ausführen kann).

Cheri erstellt und ordnet ihre eigene Policy dem Compartment "Project-B" zu, ähnlich der Policy von Jorge:

Allow group B-Users to use instance-family in compartment Project-B
Allow group B-Users to use volume-family in compartment Project-B
Allow group B-Users to inspect virtual-network-family in compartment Networks

Jetzt können die Mitglieder der Gruppen "A-Users" und "B-Users" jeweils mit den vorhandenen Instanzen und den zugeordneten Volumes in den Compartments "Project-A" und "Project-B" arbeiten. So sieht das Layout aus:

Dieses Bild baut auf dem vorherigen Bild auf, indem Policy-Anweisungen für einige der Compartments hinzugefügt werden.


Element	Beschreibung
	An den Mandanten angehängte Policys: `Allow group Administrators to manage all-resources in tenancy` `Allow group NetworkAdmins to manage virtual-network-family in compartment Networks` `Allow group NetworkAdmins to manage instance-family in compartment Networks` `Allow group A-Admins, B-Admins to use virtual-network-family in compartment Networks` `Allow group A-Admins to manage all-resources in compartment Project-A` `Allow group B-Admins to manage all-resources in compartment Project-B` `Allow group A-Admins to use users in tenancy where target.group.name='A-Users'` `Allow group A-Admins to use groups in tenancy where target.group.name='A-Users'` `Allow group B-Admins to use users in tenancy where target.group.name='B-Users'` `Allow group B-Admins to use groups in tenancy where target.group.name='B-Users'` `Allow group A-Admins, B-Admins to inspect users in tenancy` `Allow group A-Admins, B-Admins to inspect groups in tenancy`
	Von Jorge angehängte und verwaltete Policy: `Allow group A-Users to use instance-family in compartment Project-A` `Allow group A-Users to use volume-family in compartment Project-A` `Allow group A-Users to use virtual-network-family in compartment Project-A`
	Von Cheri angehängte und verwaltete Policy: `Allow group B-Users to use instance-family in compartment Project-B` `Allow group B-Users to use volume-family in compartment Project-B` `Allow group B-Users to use virtual-network-family in compartment Project-B`

Weitere Informationen zu grundlegenden und erweiterten Features von Policys finden Sie unter Funktionsweise von Policys. Beispiele für andere typische Policys, die Ihre Organisation verwenden kann, finden Sie unter Allgemeine Policys.

Nur das Verwalten von Backups durch Volume-Backupadministratoren zulassen

Nur das Verwalten von Backups durch Backupadministratoren zulassen.

Zugriffstyp: Bietet die Möglichkeit, alle Aktionen in Bezug auf Volume-Backups auszuführen, beinhaltet aber nicht das Erstellen und Verwalten der Volumes selbst. Dies ist sinnvoll, wenn eine einzelne Gruppe von Volume-Backupadministratoren alle Volume-Backups in allen Compartments verwalten soll. Die erste Anweisung erteilt den erforderlichen Zugriff auf das zu sichernde Volume. Die zweite Anweisung ermöglicht das Erstellen des Backups sowie das Löschen von Backups. Die dritte Anweisung ermöglicht das Erstellen und Verwalten benutzerdefinierter Backup-Policys. Die vierte Anweisung ermöglicht das Zuweisen und Aufheben der Zuweisung von Backup-Policys.

Wo wird die Policy erstellt: Im Mandanten, sodass der Zugriff allen Compartments durch Policy-Vererbung erteilt wird. Um den Geltungsbereich des Zugriffs nur auf die Volumes und Backups in einem bestimmten Compartment einzuschränken, geben Sie dieses Compartment anstelle des Mandanten an.

Allow group VolumeBackupAdmins to use volumes in tenancy

Allow group VolumeBackupAdmins to manage volume-backups in tenancy

Allow group VolumeBackupAdmins to manage backup-policies in tenancy

Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancy

Wenn die Gruppe die Konsole verwendet, bietet die folgende Policy eine bessere Benutzererfahrung:

Allow group VolumeBackupAdmins to use volumes in tenancy

Allow group VolumeBackupAdmins to manage volume-backups in tenancy

Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy

Allow group VolumeBackupAdmins to inspect instances in tenancy

Allow group VolumeBackupAdmins to manage backup-policies in tenancy

Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancy

Die letzten beiden Anweisungen sind zum Verwalten von Volume-Backups nicht erforderlich. Allerdings können damit alle Informationen zu einem bestimmten Volume und den verfügbaren Backup-Policys in der Konsole angezeigt werden.

Policy-Zuordnung

Policy-Zuordnungen

Ein weiteres grundlegendes Feature von Policys ist das Konzept der Zuordnung. Wenn Sie eine Policy erstellen, müssen Sie sie einem Compartment (oder dem Mandanten, d.h. dem Root-Compartment) zuordnen. Wer die Policy ändern oder löschen kann, hängt davon ab, welchem Compartment Sie die Policy zuordnen. Wenn Sie sie dem Mandanten zuordnen (anders ausgedrückt, wenn sich die Policy im Root-Compartment befindet), können alle Benutzer mit einer Berechtigung zur Verwaltung von Policys im Mandanten die Policy ändern oder löschen. Hierbei handelt es sich in der Regel um die Administratorengruppe oder eine ähnliche Gruppe, die Sie erstellen und der Sie umfangreichen Zugriff erteilen. Alle Benutzer, die nur Zugriff auf ein untergeordnetes Compartment haben, können diese Policy nicht ändern oder löschen.

Wenn Sie die Policy stattdessen einem untergeordneten Compartment zuordnen, können alle Benutzer mit einer Berechtigung zur Verwaltung der Policys in diesem Compartment die Policy ändern oder löschen. Praktisch gesehen können Sie Compartment-Administratoren (d.h. einer Gruppe mit Zugriff auf manage all-resources im Compartment) dadurch ganz einfach die Berechtigung zur Verwaltung der Policys in ihrem eigenen Compartment erteilen, ohne dass sie mehr Berechtigungen für das Verwalten von Policys im jeweiligen Mandanten erhalten. Ein Beispiel für ein solches Setup für Compartment-Administratoren finden Sie unter Beispielszenario. (Dank der Policy-Vererbung haben Benutzer mit Zugriff auf die Verwaltung von Policys im Mandanten automatisch die Möglichkeit, Policys in Compartments innerhalb des Mandanten zu verwalten.)

Die Zuordnung der Policy ist einfach (wenn sie einem Compartment oder dem Mandanten zugeordnet wird): Wenn Sie die Konsole verwenden und die Policy zu IAM hinzufügen, vergewissern Sie sich, dass Sie beim Erstellen der Policy das gewünschte Compartment ausgewählt haben. Wenn Sie die API verwenden, geben Sie die OCID des gewünschten Compartments (des Mandanten oder eines anderen Compartments) als Bestandteil der Anforderung zum Erstellen der Policy an.

Wenn Sie eine Policy einem Compartment zuordnen, müssen Sie sich in diesem Compartment befinden und müssen direkt in der Anweisung angeben, für welches Compartment die Policy gilt. Wenn Sie sich nicht im Compartment befinden, erhalten Sie eine Fehlermeldung, wenn Sie versuchen, die Policy einem anderen Compartment zuzuordnen. Beachten Sie, dass die Zuordnung während der Policy-Erstellung erfolgt, d.h. eine Policy kann nur einem Compartment zugeordnet werden. Informationen darüber, wie Sie eine Policy einem Compartment hinzufügen, finden Sie unter Policy erstellen.

Oracle Cloud Infrastructure - Dokumentation