Tags zum Verwalten des Zugriffs verwenden
In diesem Thema wird beschrieben, wie Sie mit Tags in Policys den Zugriff entweder auf den Anforderer oder das Ziel eines Autorisierungsaufrufs begrenzen können.
Tagbasierte Zugriffskontrolle
Mit Bedingungen und einem Set von Tagvariablen können Sie eine Policy schreiben, um den Zugriff anhand der Tags einzuschränken, die auf eine Ressource angewendet werden. Der Zugriff kann basierend auf einem Tag kontrolliert werden, das in der anfordernden Ressource (Gruppe, dynamische Gruppe oder Compartment) oder in dem Ziel der Anforderung (Ressource oder Compartment) vorhanden ist. Tagbasierte Zugriffskontrolle bietet zusätzliche Flexibilität für Ihre Policys, da Sie damit Zugriffs-Policys mit Tags definieren können, die Compartments, Gruppen und Ressourcen umfassen.
Wenn Ihr Unternehmen Policys erstellen möchte, die Tags zum Verwalten des Zugriffs verwenden, stellen Sie sicher, dass Sie über die entsprechenden Kontrollen verfügen, um zu bestimmen, wer Tags anwenden kann. Beachten Sie außerdem, dass nach dem Einrichten derartiger Policys durch das Anwenden von Tags auf eine Gruppe, einen Benutzer oder eine Ressource möglicherweise auch der Zugriff auf Ressourcen erteilt werden kann.
Bevor Sie eine Policy erstellen, die ein Tag für ein Ziel oder einen Anforderer angibt, müssen Sie Folgendes beachten:
- Alle potenziellen Anforderer (Benutzer, Gruppen, dynamische Gruppen), die das Tag aufweisen
- Alle Ressourcen, die das Tag aufweisen
Bevor Sie ein Tag auf eine Ressource anwenden, müssen Sie sicherstellen, dass Sie alle Policys kennen, die das Tag enthalten und beeinflussen könnten, wer Zugriff auf die Ressource hat.
Zugriff mit auf die anfordernde Ressource angewendeten Tags verwalten
Sie können den Zugriff basierend auf dem Wert eines Tags kontrollieren, das auf folgende Elemente angewendet wird:
- Eine Gruppe (von Benutzern), die Zugriff anfordert
- Eine dynamische Gruppe (von Instanzen), die Zugriff anfordert
- Ein Compartment, in dem eine Ressource in einer dynamischen Gruppe gespeichert ist
Wenn Sie Tags in den Policy-Anweisungen zum Einschränken des Zugriffs verwenden, können Sie den Zugriff für mehrere Gruppen über eine einzelne Policy-Anweisung definieren. Sie können Gruppen auch den Zugriff erteilen und diesen widerrufen, indem Sie Tags anwenden bzw. entfernen, ohne die ursprünglichen Policys zu ändern.
In der folgenden Tabelle wird die grundlegende Syntax für jede Variable angezeigt. Beachten Sie, dass die Syntax für eine Gruppe und eine dynamische Gruppe identisch ist, jede wird jedoch in einer anderen Zeile dargestellt. Weitere Verwendungsbeispiele finden Sie unter Unterstützte Operatoren.
| Auf den Anforderer angewendetes Tag | Variablensyntax | Beschreibung |
|---|---|---|
|
Gruppe |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Beispiel-Policy für Benutzergruppe:
Jeder Benutzer, der zu einer Gruppe gehört, die mit "Operations.Project='Prod'" getaggt wurde, kann Instanzen im HR-Compartment verwalten. |
Die Tags, die auf die Gruppen angewendet wurden, zu denen der Benutzer gehört, werden für eine Übereinstimmung ausgewertet. |
|
Dynamische Gruppe |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Beispiel-Policy für dynamische Gruppe:
Instanzen, die Mitglieder der dynamischen Gruppe "InstancesA" sowie einer dynamischen Gruppe, die mit "Operations.Project='Prod'" getaggt ist, sind, können Instanzen im HR-Compartment verwalten. |
Die Tags, die auf die dynamischen Gruppen angewendet wurden, zu denen die Instanz gehört, werden für eine Übereinstimmung ausgewertet. |
|
Compartment |
request.principal.compartment.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Beispiel-Policy:
Instanzen, die Mitglieder der dynamischen Gruppe "InstancesA" sind und in einem mit "Operations.Project='Prod'" getaggten Compartment gespeichert sind, können Instanzen im Mandanten verwalten. |
Die Tags, die auf das Compartment angewendet werden, zu dem die anfordernde Ressource gehört, werden ausgewertet. |
Benutzer befinden sich im Root Compartment Ihres Mandanten. Tags müssen also auf das Root Compartment angewendet werden, damit diese Policy-Anweisungen funktionieren.
Zugriff mit auf die Zielressource angewendeten Tags verwalten
Sie können den Zugriff basierend auf dem Wert eines Tags kontrollieren, das auf folgende Elemente angewendet wird:
- Eine Ressource
- Ein Compartment, in dem die Zielressource gespeichert ist
In der folgenden Tabelle wird die grundlegende Syntax für diese Variablen angezeigt. Weitere Verwendungsbeispiele finden Sie unter Unterstützte Operatoren.
| Auf das Ziel angewendetes Tag | Variablensyntax | Beschreibung |
|---|---|---|
|
Ressource |
target.resource.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Beispiel-Policy:
|
Das auf die Zielressource der Anforderung angewendete Tag wird ausgewertet. Es gelten Einschränkungen bezüglich der Berechtigungen, die in diesem Policy-Typ erteilt werden können. Weitere Einzelheiten finden Sie in den folgenden Abschnitten in diesem Thema. |
|
Compartment |
target.resource.compartment.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Beispiel-Policy:
|
Das auf das Ziel-Compartment der Anforderung angewendete Tag wird ausgewertet. Nähere Einzelheiten dazu, wie der Zugriff in verschachtelten Compartments erteilt wird, finden Sie unter Compartment-Hierarchien. |
Berechtigungen zum Auflisten einer Ressource müssen separat erteilt werden
Policys, die den Zugriff anhand des auf die Zielressource angewendeten Tags einschränken, können nicht die Berechtigungen erteilen, mit denen Sie eine Liste mit Ressourcen zurückgeben können. Daher müssen Berechtigungen zum Auflisten einer Ressource über eine zusätzliche Policy-Anweisung erteilt werden. Das heißt, es gilt Folgendes, wenn Sie eine Policy wie folgt definiert haben:
allow group GroupA to manage all-resources in compartment Operations where target.resource.tag.Operations.Project= 'Prod'
GroupA kann keine der Ressourcen auflisten, die sie ansonsten verwalten darf. Mitglieder von GroupA können nicht über die Konsole mit diesen Ressourcen kommunizieren, und Benutzer müssen die OCID der Ressource kennen, die sie verwalten möchten. Dadurch wird auch die Verwendung des SDK und der CLI mühsam.
Damit GroupA diese Ressourcen auflisten kann, müssen Sie eine weitere Policy-Anweisung hinzufügen. Beispiel:
allow group GroupA to inspect all-resources in compartment Operations
Diese Lösung verbessert die tagbasierte Policy, da Benutzer die Konsole einfacher verwenden können (weil sie die zu verwaltende Ressource anzeigen können). Die Berechtigungen sind jedoch weiterhin auf ein reines Prüfen ("inspect") beschränkt. Die Mitglieder von GroupA können nur dann Aktionen für diese Ressourcen ausführen, wenn sie mit den entsprechenden Tags versehen sind. Beachten Sie bei der Verwendung der tagbasierten Zugriffskontrolle, dass die zusätzliche Flexibilität möglicherweise diese zusätzliche Erweiterung des Zugriffs erforderlich macht.
Um diese Einschränkung zu umgehen, können Sie auch die Compartments mit den Ressourcen taggen, auf die Sie Zugriff erteilen möchten. Eine Beispiel-Policy sieht wie folgt aus:
allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'Mit dieser Policy können Mitglieder von GroupA alle Ressourcen in dem Mandanten verwalten, die in Compartments enthalten sind, die mit dem Tag "Operations.Project='Prod'" gekennzeichnet sind.
Policys, die ein Tag für die Zielressource erfordern, können keine Berechtigungen zum Erstellen erteilen
Wenn Sie eine Policy schreiben, die den Zugriff anhand des Wertes eines Tags für die Ressource einschränkt, beachten Sie, dass die Policy keine Erstellberechtigungen erteilen darf. Eine Anforderung zum Erstellen einer Instanz wäre nicht erfolgreich, weil die Zielressource noch nicht erstellt wurde und das entsprechende auszuwertende Tag daher nicht enthält. Nehmen wir beispielsweise folgende Policy:
allow group GroupA to manage instances in compartment Operations where target.resource.tag.Operations.Project='Prod'
Diese Policy erlaubt Mitgliedern von GroupA, mit "Operations.Project='Prod'" getaggte Instanzen zu verwenden und zu löschen. Sie können jedoch keine Instanzen erstellen.
Unterstützte Operatoren
Policys mit diesen Tagvariablen können die folgenden Operatoren und Abgleichstypen enthalten:
| Operator | Typ | Beispiel | Beschreibung |
|---|---|---|---|
| = | Zeichenfolge | request.principal.group.tag.MyTagNamespace.MyTag='sample'
|
Ergibt "true", wenn eine der Gruppen, zu denen der Anforderer gehört, mit dem übereinstimmenden Wert "sample" für MyTagNamespace.MyTag getaggt ist. (Bei dem Wert wird die Groß-/Kleinschreibung nicht beachtet.) |
| Muster | request.principal.group.tag.MyTagNamespace.MyTag=/*sample/
|
Ergibt "true", wenn einer der Werte von MyTagNamespace.MyTag auf "sample" endet. (Einfacher Mustervergleich ohne Beachtung der Groß-/Kleinschreibung.) | |
| Policy-Variable | request.principal.group.tag.mytagnamespace.mytag = target.resource.tag.mytagnamespace.mytag |
Wird als "true" ausgewertet, wenn die angegebene Ressource "mytagnamespace.mytag" einen Wert aufweist, der mit dem angegebenen Ziel "mytagnamespace.tag" übereinstimmt. | |
| != | Zeichenfolge | request.principal.group.tag.MyTagNamespace.MyTag !='sample'
|
Ergibt "true", wenn keiner der Zeichenfolgenwerte der Policy-Variablen "sample" entspricht. (Einfacher Zeichenfolgenvergleich ohne Beachtung der Groß-/Kleinschreibung.) |
| Muster | request.principal.group.tag.MyTagNamespace.MyTag !=/*sample/
|
Ergibt "true", wenn keiner der Werte von MyTagNamespace.MyTag auf "sample" endet. (Einfacher Mustervergleich ohne Beachtung der Groß-/Kleinschreibung.) | |
| Policy-Variable | request.principal.group.tag.mytagnamespace.mytag != target.resource.tag.mytagnamespace.mytag |
Ergibt "true", wenn keine Seite eine Teilmenge der anderen ist. |
In/Nicht in
| Operator | Typ | Beispiel | Beschreibung |
|---|---|---|---|
| in | Zeichenfolge | request.principal.group.tag.MyTagNamespace.MyTag in ('sample', 'sample1')
|
Die Klausel ergibt "true", wenn einer der Werte von MyTagNamespace.MyTag für eine Gruppe des aktuellen, anfordernden Principals entweder "sample" oder "sample1" entspricht. |
| Muster | request.principal.group.tag.MyTagNamespace.MyTag in (/*sample/, /sample1*/)
|
Die Klausel ergibt "true", wenn einer der Werte von MyTagNamespace.MyTag für eine Gruppe des aktuellen, anfordernden Principals entweder auf "sample" endet oder mit "sample1" beginnt. | |
| Policy-Variable | request.principal.group.tag.MyTagNamespace.MyTag in (target.resource.tag.mytagnamespace.mytag, 'sample') |
Die Auswertung der Klausel ergibt "true", wenn eine der folgenden Bedingungen erfüllt ist: 1 request.principal.group.tag.MyTagNamespace.MyTag oder target.resource.tag.mytagnamespace.mytag ist eine Teilmenge der anderen. 2. Einer der Zeichenfolgenwerte von request.principal.group.tag.MyTagNamespace.MyTag entspricht "sample". |
|
| Nicht in | Zeichenfolge | request.principal.group.tag.MyTagNamespace.MyTag not in ('sample', 'sample1')
|
Die Klausel ergibt "true", wenn keiner der Werte von MyTagNamespace.MyTag für eine Gruppe des aktuellen, anfordernden Principals "sample" oder "sample1" entspricht. |
| Muster | request.principal.group.tag.MyTagNamespace.MyTag not in (/*sample/, /sample1*/)
|
Die Klausel ergibt "true", wenn keiner der Werte von MyTagNamespace.MyTag für eine Gruppe des aktuellen, anfordernden Principals auf "sample" endet oder mit "sample1" beginnt. | |
| Policy-Variable | request.principal.group.tag.MyTagNamespace.MyTag not in (target.resource.tag.mytagnamespace.mytag, 'sample')
|
Die Auswertung der Klausel ergibt "true", wenn alle folgenden Bedingungen erfüllt ist: 1. Das Tag request.principal.group.tag.MyTagNamespace.MyTag ist keine Teilmenge des Tags target.resource.tag.mytagnamespace.my und umgekehrt. 2. Keiner der Zeichenfolgenwerte von request.principal.group.tag.MyTagNamespace.MyTag entspricht "sample". |
Unterstützung für Platzhalter
Sie können ein Sternchen (*) verwenden, um alle Vorkommen von {tagNamespace}.{tagKeyDefinition} ungeachtet des Wertes abzugleichen. In der Policy können Sie * in einfachen Anführungszeichen ('*') oder zwischen umgekehrten Schrägstrichen (/*/) einfügen. Beispiel:
allow group GroupA to use all-resources in compartment HR where target.resource.tag.HR.Project= '*'
In diesem Beispiel kann GroupA alle Ressourcen im Compartment HR verwenden, die mit dem Tag-Namespace und dem Tagschlüssel HR.Project mit einem beliebigen Wert gekennzeichnet sind.
Einschränkungen bei Zeichen in Tag-Namespaces und Tagschlüsseldefinitionen, die in Policy-Variablen verwendet werden
Tag-Namespaces und Tagschlüsseldefinitionen unterstützen eine breitere Vielzahl von Zeichen, als in Policy-Variablen zulässig sind. Um Tag-Namespaces und Tagschlüsseldefinitionen in Variablen verwenden zu können, müssen Sie daher sicherstellen, dass diese nur die Zeichen enthalten, die auch von Policy-Variablen unterstützt werden. Folgende Zeichen werden unterstützt:
a-z, A-Z, 0 - 9,_, @, -, :
Wenn Ihre Tag-Namespaces oder Tagschlüssel andere Zeichen enthalten, können Sie sie nicht in Policy-Variablen verwenden. Tag-Namespaces und Tagschlüssel können nicht umbenannt werden. Daher müssen Sie neue Tag-Namespaces und Tagschlüsseldefinitionen erstellen.
Hinweise zur Groß-/Kleinschreibung
Beachten Sie beim Arbeiten mit Tags in Policys, dass bei Tagwerten Groß-/Kleinschreibung nicht beachtet wird. Beispiel:
request.principal.group.tag.MyTagNamespace.MyTag='sample'
ist gleichbedeutend mit
request.principal.group.tag.MyTagNamespace.MyTag='Sample'
Compartment-Hierarchien
Wenn Sie eine Bedingung schreiben, um den Zugriff basierend auf dem Tag zu ermöglichen, das auf ein Ziel-Compartment angewendet wurde, beachten Sie, dass diese Policy auch den Zugriff auf alle Compartments ermöglicht, die innerhalb des getaggten Compartments verschachtelt sind. Alle Sub-Compartments im getaggten Compartment sind Ressourcen im getaggten Compartment. Deshalb erteilt die Policy den Zugriff.
Beispiel: In diesem Szenario:
Die Policy:
allow group GroupA to use all-resources in tenancy where target.resource.compartment.Operations.Project='ProjectA'ermöglicht GroupA, alle Ressourcen in CompartmentA, CompartmentA1 und CompartmentA1.1 zu verwenden, obwohl das Tag nur auf CompartmentA angewendet wird.
Unterstützte Services
Alle Oracle Cloud Infrastructure-Services unterstützen die Policy-Variablen request.principal.compartment, request.principal.group und target.resource.compartment.tag.
Nicht alle Services unterstützen jedoch die Policy-Variable target.resource.tag. In der folgenden Tabelle werden die unterstützten Services aufgeführt. Wenn der Service nicht in der Tabelle aufgeführt wird, wird er derzeit nicht unterstützt.
Bei einigen Services gelten Einschränkungen. Hierzu wird auf den entsprechenden Link in der Tabelle verwiesen.
| Unterstützte Services | Weitere Informationen |
|---|---|
| API Gateway | Siehe Einschränkungen bei API Gateway-Service. |
| Big Data Service | Siehe Einschränkungen bei Big Data-Service. |
| Blockchain Platform | Vollständig unterstützt, keine Einschränkungen. |
| Block Volume | Siehe Einschränkungen bei Block Volume-Service. |
| Zertifikate | Vollständig unterstützt, keine Einschränkungen. |
| Compute | Siehe Einschränkungen bei Compute-Service. |
| Compute-Management | Siehe Einschränkungen bei Compute-Management. |
| Contentmanagement | Siehe Einschränkungen bei Content Management. |
| Data Catalog | Siehe Einschränkungen bei Data Catalog-Service. |
| Data Flow | Vollständig unterstützt, keine Einschränkungen. |
| Data Science | Siehe Einschränkungen bei Data Science-Service. |
| Datenbank | Siehe Einschränkungen bei Database-Service. |
| Digital Assistant | Siehe Einschränkungen bei Digital Assistant. |
| DNS | Siehe Einschränkungen bei öffentlichem DNS. |
| Email Delivery | Vollständig unterstützt, keine Einschränkungen. |
| FastConnect | Vollständig unterstützt, keine Einschränkungen. |
| Functions | Vollständig unterstützt, keine Einschränkungen. |
| Health Checks | Vollständig unterstützt, keine Einschränkungen. |
| IAM | Unterstützte Ressourcen sind:users, groups, policies, dynamic-groups, network-sources und identity-providers |
| Load Balancer | Siehe Einschränkungen bei Load Balancing-Service. |
| HeatWave | Vollständig unterstützt, keine Einschränkungen. |
| Networking | Siehe Einschränkungen bei Networking-Service. |
| NoSQL Database Cloud | Siehe Einschränkungen bei Networking-Service. |
| Benachrichtigungen | Vollständig unterstützt, keine Einschränkungen. |
| Object Storage | Siehe Einschränkungen bei Object Storage-Service. |
| Quota-Service | Vollständig unterstützt, keine Einschränkungen. |
| Tagging-Namespace | Siehe Einschränkungen bei Tagging-Namespaces. |
| Vault | Verschlüsselung nicht unterstützt. |
| WAF | Siehe Einschränkungen bei WAF. |
Einschränkungen und zusätzlich erforderliche Policys für spezifische Target.Resource.Tag-Szenarios
Bei einigen Services werden nicht alle Berechtigungen oder Ressourcentypen unterstützt. Wenn eine Berechtigung nicht unterstützt wird, bedeutet dies, dass die Berechtigung nicht erteilt wird, selbst wenn die Ressource getaggt und die Berechtigung in dem Verb enthalten ist, das Zugriff gewährt. Die Autorisierung für den Vorgang, der von der Berechtigung gesteuert wird, verläuft in diesem Fall nicht erfolgreich. Beispiel: Die Block Volume Service-Ressource volume-backups unterstützt keine tagbasierte Zugriffskontrolle für die VOLUME_BACKUP_COPY-Berechtigung. Die Policy:
allow group TestGroup to manage volume-backups in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'berechtigt Mitglieder der Gruppe TestGroup daher nicht, den Vorgang CopyVolumeBackup ausführen. Um TestGroup diese Berechtigung zu erteilen, müssen Sie eine weitere Policy-Anweisung hinzufügen.
Darüber hinaus ist für einige Vorgangsszenarios eine Autorisierung erforderlich, um auf mehrere Ressourcen zugreifen zu können. Wenn Sie den Zugriff auf Tags begrenzen, die auf die Zielressource angewendet werden, müssen Sie eine separate Policy für jede an dem Vorgang beteiligte Ressource aufnehmen. Aufgrund der Einschränkungen hinsichtlich des Auflistens von Ressourcen und anderer servicespezifischer Berechtigungen sind außerdem zusätzliche Policys (nicht per Tag eingeschränkt) erforderlich.
Einschränkungen bei API Gateway-Service
Zusätzlich zur erwarteten tagbasierten Access Control Policy für API-Gateway-Ressourcen benötigen Sie eine Policy, mit der Sie Berechtigungen für api-workrequests verwalten können.
Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage api-workrequests in compartment Compartment1Einschränkungen bei Big Data-Service
Zusätzlich zur erwarteten tagbasierten Access Control Policy für Big Data Service-Ressourcen benötigen Sie eine Policy, mit der Sie Berechtigungen für cluster-work-requests verwalten können.
Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage cluster-work-requests in compartment Compartment1Einschränkungen bei Block Volume Service
| Service | Ressourcentyp mit Einschränkungen | Mit der Policy-Variable target.resource.tag nicht unterstützte Berechtigungen |
|---|---|---|
| Block Volume | backup-policy-assignments
|
BACKUP_POLICY_ASSIGNMENT_DELETE |
volume-backups
|
VOLUME_BACKUP_COPY |
Szenarios, die zusätzliche Policys erfordern:
Block-Volume an eine Compute-Instanz anhängen:
Um ein Block-Volume an eine Compute-Instanz anzuhängen, benötigen Sie zusätzlich zur tagbasierten Zugriffskontroll-Policy weitere Berechtigungen, um das Verb use auf Volumes und Instanzen zuzulassen.
Beispiel:
allow group TestGroup to use volumes in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Mit diesen beiden Policys können Mitglieder von TestGroup Volumes und Instanzen in Compartment1 verwenden, sofern die Ressourcen das entsprechende Tag aufweisen. Damit Mitglieder ein Block-Volume an eine Instanz anhängen können, benötigen Sie außerdem Policys, die die in den folgenden Anweisungen angezeigten Berechtigungen erteilen:
allow group TestGroup to read instances in compartment Compartment1
allow group TestGroup to manage volume-attachments in compartment Compartment1 where any {request.permission='VOLUME_ATTACHMENT_CREATE', request.permission='VOLUME_ATTACHMENT_DELETE'}Einschränkungen bei Compute-Service
| Service | Ressourcentyp | Mit der Policy-Variable target.resource.tag nicht unterstützte Berechtigungen |
|---|---|---|
| Compute | instance-console-connection
|
INSTANCE_CONSOLE_CONNECTION_DELETE |
instances
|
INSTANCE_POWER_ACTIONS |
Szenarios, die zusätzliche Policys erfordern:
Compute-Instanz an Subnetz anhängen:
Um den Anhang einer Compute-Instanz an ein Subnetz zu verwalten, benötigen Sie nicht nur die erwartete tagbasierte Zugriffskontroll-Policy für instances und subnets, wie hier dargestellt:
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Zusätzlich benötigen Sie Berechtigungen für vnics:
allow group TestGroup to use vnics in compartment Compartment1 where ANY{request.permission='VNIC_ATTACH', request.permission='VNIC_CREATE'}VNIC aus einer Compute-Instanz löschen:
Um eine VNIC aus einer Compute-Instanz zu löschen, benötigen Sie nicht nur die erwartete tagbasierte Zugriffskontroll-Policy für instances und subnets, wie hier dargestellt:
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Sie benötigen außerdem eine Policy, die Ihnen Berechtigungen für vnics erteilt:
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}Einschränkungen bei Compute-Management
| Service | Ressourcentyp | Mit der Policy-Variable target.resource.tag nicht unterstützte Berechtigungen | Hinweise |
|---|---|---|---|
| Compute-Management | instance-pools
|
Alle Berechtigungen | Der Ressourcentyp instance-pools wird nicht unterstützt. |
auto-scaling-configurations
|
AUTO_SCALING_CONFIGURATION_UPDATE | . |
Einschränkungen bei Content Management
Zusätzlich zur erwarteten tagbasierten Access Control Policy für Content Management-Ressourcen benötigen Sie eine Policy, mit der Sie Berechtigungen für oce-work-requests verwalten können.
Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage oce-requests in compartment Compartment1Einschränkungen bei Database-Service
| Service | Ressourcentyp | Mit der Policy-Variable target.resource.tag nicht unterstützte Berechtigungen |
|---|---|---|
| Datenbank | all
|
DATABASE_DELETE |
Tags für ExaData Infrastructure aktualisieren:
Wird mit tagbasierten Zugriffskontroll-Policys derzeit nicht unterstützt.
Szenarios, die zusätzliche Policys erfordern:
DB-System löschen:
Um ein DB-System zu löschen oder zu aktualisieren, benötigen Sie nicht nur die erwartete tagbasierte Zugriffskontroll-Policy für db-systems, wie hier dargestellt:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Sie benötigen außerdem eine Policy, mit der Sie Berechtigungen für db-backups, db-homes, vnics, subnets und databases erhalten. Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_DELETE'
allow group TestGroup to manage vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}
allow group TestGroup to manage subnets in compartment Compartment1 where request.permission='SUBNET_DETACH'
allow group TestGroup to manage databases in compartment compartment1DB-System in ein anderes Compartment verschieben:
Um ein DB-System in ein anderes Compartment zu verschieben, benötigen Sie nicht nur die erwartete tagbasierte Zugriffskontroll-Policy für db-systems, wie hier dargestellt:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Sie benötigen außerdem eine Policy, mit der Sie Berechtigungen für databases, db-homes und db-backups erhalten. Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to use databases in compartment Compartment1 where request.permission='DATABASE_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_INSPECT'
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_UPDATE'Datenbanklöschvorgang für Exadata-DB-System:
Um eine Datenbankressource für ein Exadata-DB-System zu löschen, benötigen Sie nicht nur die erwartete tagbasierte Zugriffskontroll-Policy für db-systems und databases, wie hier dargestellt:
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Sie benötigen außerdem Berechtigungen für db-homes und db-backups. Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permision='DB_HOME_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}Datenbank löschen:
Das Löschen einer Datenbank für ein Bare-Metal-DB-System oder ein DB-System einer virtuellen Maschine wird mit tagbasierten Policys in der Zielressource nicht unterstützt.
Datenbankbackup erstellen:
Um ein Datenbankbackup zu erstellen, benötigen Sie die erwartete tagbasierte Zugriffskontroll-Policy für databases:
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Sie benötigen außerdem Berechtigungen für db-backups. Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_CREATE'Datenbankwiederherstellung:
Um ein Datenbankbackup wiederherzustellen, benötigen Sie die erwartete tagbasierte Zugriffskontroll-Policy für databases:
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Sie benötigen außerdem Berechtigungen für backups, wie hier dargestellt:
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_INSPECT', request.permission='DB_BACKUP_CONTENT_READ'}Data Guard-Verknüpfung erstellen:
Das Erstellen einer Data Guard-Verknüpfung wird mit tagbasierten Policys in der Zielressource nicht unterstützt.
Einschränkungen bei Data Catalog-Service
Zusätzlich zur erwarteten tagbasierten Access Control Policy für Data Catalog-Ressourcen benötigen Sie die folgenden zusätzlichen Policys für data-catalog-family:
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'GetWorkRequest'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'ListWorkRequestErrors'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'listworkrequestlogs'Einschränkungen bei Data Science-Service
Zusätzlich zur erwarteten tagbasierten Access Control Policy für Data Science-Ressourcen benötigen Sie eine Policy, mit der Sie Berechtigungen für data-science-work-requests verwalten können.
Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage data-science-work-requests in compartment Compartment1Einschränkungen bei Digital Assistant
| Service | Ressourcentyp | Mit der Policy-Variable target.resource.tag nicht unterstützte Berechtigungen |
|---|---|---|
| Digital Assistant | oda-design
|
Alle Berechtigungen |
oda-insights
|
Alle Berechtigungen |
Zusätzlich zur erwarteten tagbasierten Access Control Policy für Digital Assistant-Ressourcen benötigen Sie die folgenden zusätzlichen Policys für oda-instances:
allow group TestGroup to inspect oda-instances in compartment Compartment1
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'GetWorkRequest'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'ListWorkRequestErrors'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'listworkrequestlogs'Einschränkungen bei Load Balancing Service
Szenarios, die zusätzliche Policys erfordern:
Load Balancer aktualisieren:
Um Load Balancer zu aktualisieren, benötigen Sie nicht nur die erwartete tagbasierte Zugriffskontroll-Policy für load-balancers:
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Sie benötigen eine Policy, die den GetWorkRequest-API-Vorgang zulässt. Nachfolgend finden Sie eine Beispiel-Policy mit der zusätzlichen Berechtigung:
allow group TestGroup to read load-balancers in compartment Compartment1 where request.operation = 'GetWorkRequest'
network-security-groupLoad Balancer löschen:
Um einen Load Balancer zu löschen, benötigen Sie nicht nur die erwartete tagbasierte Access Control Policy für load-balancers, subnets und network-security-group:
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use network-security-group in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Sie benötigen die folgenden zusätzlichen Berechtigungen für vnics:
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission = 'VNIC_DETACH', request.permission = 'VNIC_DELETE', request.permission='VNIC_DISASSOCIATE_NETWORK_SECURITY_GROUP'}Einschränkungen bei Networking-Service
| Service | Ressourcentyp | Mit der Policy-Variable target.resource.tag nicht unterstützte Berechtigungen | Hinweise |
|---|---|---|---|
| Networking | private-ips
|
PRIVATE_IP_UPDATE PRIVATE_IP_DELETE VNIC_UNASSIGN SUBNET_DETACH |
|
route-tables
|
UPDATE (INTERNET_GATEWAY_DETACH) | Das Entfernen einer Routingregel wird nicht unterstützt. | |
vnics
|
VNIC_UPDATE VNIC_DELETE |
Servicegateway oder NAT-Gateway an eine Routentabelle anhängen:
Das Anhängen eines Servicegateway oder eines NAT-Gateway an eine Routentabelle wird mit tagbasierten Policys in der Zielressource nicht unterstützt.
Szenarios, die zusätzliche Policys erfordern:
DRG an VCN anhängen:
Um ein DRG an ein VCN anzuhängen, benötigen Sie nicht nur die erwartete tagbasierte Access Control Policy für virtual-network-family und vcns:
allow group TestGroup to use virtual-network-family in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
Sie benötigen außerdem eine Policy, mit der Sie manage-Berechtigungen für drgs erhalten. Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage drgs in compartment Compartment1
Einschränkungen bei NoSQL Database Cloud-Service
Unterstützte Ressourcen sind: nosql-tables, nosql-rows und nosql-indexes.
Zusätzlich zur erwarteten tagbasierten Access Control Policy für NoSQL Database Cloud-Ressourcen benötigen Sie die folgenden zusätzlichen Policys:
allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequests'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestErrors'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestLogs'Beachten Sie, dass die vorherigen Policys zum Navigieren in den NoSQL Database Cloud-Ressourcen in der Konsole erforderlich sind.
Einschränkungen bei Object Storage Service
| Service | Ressourcentyp | Mit der Policy-Variable target.resource.tag nicht unterstützte Berechtigungen | Hinweise |
|---|---|---|---|
| Object Storage | objects
|
Alle Berechtigungen bezogen auf den Zugriff auf objects |
Objekte können nicht getaggt werden. |
Der Zugriff auf Objekte kann über die Tags im Bucket verwaltet werden, zu dem die Objekte gehören. Verwenden Sie die Policy-Variable
target.bucket.tag. Siehe Erstellen von Objekten in Object Storage-Buckets durch Benutzer zulassen.Einschränkungen bei öffentlichem DNS
Zusätzlich zur erwarteten tagbasierten Access Control Policy für DNS-Ressourcen benötigen Sie eine Policy, mit der Sie Berechtigungen für dns-records verwalten können. Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage dns-records in compartment Compartment1Einschränkungen bei Tagging-Namespaces
Mit einer Policy, die einem Benutzer Zugriff auf einen Tag-Namespace basierend auf einem Tag im Namespace erteilt, kann der Benutzer keine Tagschlüsseldefinitionen in diesem Tag-Namespace erstellen oder löschen.
Beispiel: Mit der Policy:
allow group TestGroup to manage tag-namespaces in compartment Compartment1 where target.resource.tag.TagNS.TagKey='test'können Benutzer in TestGroup keine Tagschlüsseldefinitionen in Tag-Namespaces, die mit TagNS.TagKey='test' getaggt sind, erstellen oder löschen.
Einschränkungen bei WAF
Zusätzlich zur erwarteten tagbasierten Access Control Policy für WAF-Ressourcen benötigen Sie eine Policy, mit der Sie Berechtigungen für waas-work-request verwalten können. Nachfolgend finden Sie eine Beispiel-Policy mit den zusätzlichen Berechtigungen:
allow group TestGroup to manage waas-work-request in compartment Compartment1Veranschaulichende Beispiele
Beispiel für Tags, die auf eine Gruppe angewendet wurden
Das folgende Beispiel veranschaulicht, wie Sie Tags auf Benutzergruppen anwenden können, um den Zugriff auf Ressourcen in einem Compartment zu verwalten.
Angenommen, Sie haben drei Compartments: ProjectA, ProjectB und ProjectC.
Für jedes Compartment ist eine Admin-Gruppe eingerichtet: A-Admins, B-Admins und C-Admins.
Jede Admin-Gruppe erhält über die folgenden Policys vollständigen Zugriff auf ihr Compartment:
allow group A-Admins to manage all-resources in compartment ProjectAallow group B-Admins to manage all-resources in compartment ProjectBallow group C-Admins to manage all-resources in compartment ProjectC
Ihr Unternehmen hat den folgenden Tag-Namespace und den folgenden Schlüssel eingerichtet, um jede Gruppe nach ihrer Rolle zu taggen:
- EmployeeGroup.Role
Einige Werte für dieses Tag lauten "Admin", "Developer", "Test-Engineer".
Alle Admin-Gruppen werden mit EmployeeGroup.Role='Admin' getaggt.
Nun möchten Sie ein Test-Compartment für die Mitglieder der drei Projekte einrichten, das gemeinsam verwendet werden soll. Sie möchten allen drei vorhandenen Admin-Gruppen Admin-Zugriff erteilen. Dazu können Sie eine Policy schreiben, die in etwa wie folgt aussieht:
allow any-user to manage all-resources in compartment Test where request.principal.group.tag.EmployeeGroup.Role='Admin'
Mit dieser Policy erhalten alle vorhandenen Admin-Gruppen mit dem Tag Zugriff auf das Test-Compartment. Außerdem erhalten neue oder vorhandene Gruppen, denen Sie das Tag EmployeeGroup.Role='Admin' in Zukunft zuweisen, Zugriff auf das Test-Compartment, ohne dass Sie die Policy-Anweisungen aktualisieren müssen.
Beispiel für Tags, die auf eine Zielressource angewendet wurden
In diesem Beispiel enthält jedes der Projekt-Compartments Ihrer Organisation zwei untergeordnete Compartments: Test und Prod. Sie möchten den Test-Engineers Zugriff auf die Test-Compartments in allen drei Projekten erteilen. Um dies zu erreichen, erstellen Sie ein Tag:
ResourceGroup.Role='Test'
Dieses wenden Sie auf die Test-Compartments in jedem der Projekt-Compartments an.
Dann können Sie eine Policy wie die folgende verwenden:
allow group Testers to use all-resources in tenancy where target.resource.compartment.tag.ResourceGroup.Role='Test'
Dadurch erhält die Gruppe "Testers" Zugriff auf die Ressourcen in allen drei Test-Compartments.