Oracle Cloud Infrastructure-Dokumentation

Policy-Beispiele

Lernen Sie anhand der folgenden Beispiele IAM-Policys in Data Integration kennen.

Die allgemeine Syntax einer Policy-Anweisung lautet:

allow <subject> to <verb> <resource-type> in <location> where <condition>

Eine Beschreibung der einzelnen Variablen finden Sie unter Policy-Syntax.

Hinweis

Nachdem Sie IAM-Komponenten hinzugefügt haben (z.B. dynamische Gruppen und Policy-Anweisungen), versuchen Sie nicht, die zugehörigen Aufgaben sofort auszuführen. Für neue IAM-Policys sind etwa fünf bis 10 Minuten erforderlich.

Informationen zum Exportieren und Importieren von Objekten finden Sie unter Export und Import von Workspace und Objekten in Workspace aktivieren.

Lesen Sie auch die Blog-Policys in Oracle Cloud Infrastructure (OCI) Data Integration, um die erforderlichen Policys zu ermitteln.

Policy-Beispiele für das Erteilen von Berechtigungen für den Zugriff auf Data Integration und die Verwendung von Workspaces

Um Data Integration-Workspaces verwenden zu können, müssen Sie Policys erstellen.

Verwendung eines privaten Netzwerks in Workspaces aktivieren

Um private Netzwerkverbindungen für die Datenquellen zu verwenden, müssen Sie Data Integration die Berechtigung zum Verwalten der virtuellen Netzwerke erteilen, die Sie für die Integration eingerichtet haben.

Ohne die folgende Policy verläuft die Datenintegration nicht erfolgreich.

allow service dataintegration to use virtual-network-family in compartment <compartment-name>

So erteilen Sie einer Gruppe die Berechtigung zum Verwalten von Netzwerkressourcen in einem Compartment:

allow group <group-name> to manage virtual-network-family in compartment <compartment-name>

Für Benutzer ohne Administratorrechte:

allow group <group-name> to use virtual-network-family in compartment <compartment-name>
allow group <group-name> to inspect instance-family in compartment <compartment-name>

Zugriff zum Auflisten von Benutzern und Compartments erteilen

Um Data Integration die Möglichkeit zu geben, Benutzer und Compartments aufzulisten, können Sie inspect verwenden.

allow service dataintegration to inspect users in tenancy
allow group <group-name> to inspect compartments in compartment <target-compartment-name>
Berechtigung zum Anzeigen von Workspaces erteilen

Damit eine Gruppe die Liste aller Data Integration-Workspaces anzeigen kann, können Sie inspect verwenden.

So zeigen Sie Workspaces in einem bestimmten Compartment an:

allow group <group-name> to inspect dis-workspaces in compartment <compartment-name>
Berechtigung zum Abrufen von Workspace-Details erteilen

Damit eine Gruppe die Liste aller Data Integration-Workspaces anzeigen kann, können Sie inspect verwenden.

Das Verb read für dis-workspaces umfasst dieselben Berechtigungen und API-Vorgänge wie inspect plus die Berechtigung DIS_WORKSPACE_READ und die damit abgedeckten API-Vorgänge.

Um eine Gruppe zum Auflisten und Abrufen von Details für dis-workspaces in einem bestimmten Compartment zu berechtigen, können Sie das Verb read verwenden:

allow group <group-name> to read dis-workspaces in compartment <compartment-name>

Um eine Gruppe zum Auflisten und Abrufen von Details für dis-workspaces und die darin enthaltenen Objekte im Mandanten zu berechtigen, können Sie folgende Policy verwenden:

allow group <group-name> to read dis-workspaces in tenancy
Berechtigung zum Aktualisieren von Workspaces erteilen

Um eine Gruppe zum Aktualisieren von Workspaces und den darin enthaltenen Objekten zu berechtigen, können Sie das Verb use verwenden.

Das Verb use für dis-workspaces umfasst dieselben Berechtigungen und API-Vorgänge wie read und inspect plus die Berechtigung DIS_WORKSPACE_UPDATE und die damit abgedeckten API-Vorgänge.

Um eine Gruppe zum Aktualisieren von dis-workspaces in einem bestimmten Compartment zu berechtigen, können Sie folgende Policy verwenden:

allow group <group-name> to use dis-workspaces in compartment <compartment-name>

Um eine Gruppe zum Aktualisieren von dis-workspaces und den darin enthaltenen Objekten im Mandanten zu berechtigen, können Sie folgende Policy verwenden:

allow group <group-name> to use dis-workspaces in tenancy

So berechtigen Sie eine Gruppe zum Aktualisieren eines bestimmten Workspace und keines anderen Workspace:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

So berechtigen Sie eine Gruppe zum Aktualisieren bestimmter Workspaces:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')
Hinweis

Sie können die Workspace-OCID aus der Konsole kopieren.
Berechtigung zum Verwalten von Workspaces erteilen

Um eine Gruppe zum Verwalten von Workspaces und den darin enthaltenen Objekten zu berechtigen, können Sie das Verb manage verwenden.

Das Verb manage für dis-workspaces enthält dieselben Berechtigungen und API-Vorgänge wie inspect, read und use plus die Berechtigungen DIS_WORKSPACE_CREATE und DIS_WORKSPACE_DELETE und die damit abgedeckten API-Vorgänge.

Um eine Gruppe zum Verwalten von dis-workspaces in einem bestimmten Compartment berechtigen, können Sie folgende Policy verwenden:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name>

Um eine Gruppe zum Verwalten von dis-workspaces und den darin enthaltenen Objekten im Mandanten zu berechtigen, können Sie folgende Policy verwenden:

allow group <group-name> to manage dis-workspaces in tenancy

So berechtigen Sie eine Gruppe zum Verwalten eines bestimmten Workspace und keines anderen Workspace:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

So berechtigen Sie eine Gruppe zum Verwalten bestimmter Workspaces:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')
Hinweis

Sie können die Workspace-OCID aus der Konsole kopieren.
Exportieren und Importieren von Objekten in Workspaces zulassen

Für Data Integration sind spezifische Policys für Export und Import erforderlich. Siehe Erforderliches Setup und Policys im Thema "Objekte exportieren und importieren".

Data Integration muss auch für den Export und Import auf Ressourcen in Object Storage zugreifen. Siehe Policy-Beispiele zum Aktivieren des Zugriffs auf OCI Object Storage.

Policy-Beispiele zum Einrichten des mandantenübergreifenden Zugriffs für das Kopieren von Projekten und das Kopieren von Anwendungen

Um eine Anwendung oder ein Projekt in einem Mandanten (Ziel) zu erstellen, indem Ressourcen aus einer vorhandenen Anwendung oder einem Projekt kopiert werden, die sich in einem anderen Mandanten (Quelle) befinden, müssen bestimmte Policys in den Quell- und Zielmandanten eingerichtet werden.

Zum Schreiben mandantenübergreifender Policy-Anweisungen benötigen Sie Folgendes:

  • Name und OCID des Zielmandanten
  • Name und OCID des Quellmandanten
  • Die Benutzergruppen-OCID einer Gruppe, deren Benutzer Lese- und Schreibberechtigungen für die Quell- und Ziel-Workspaces haben

Im Zielmandanten:

Im Zielmandanten wird die neue Anwendung oder Projektkopie erstellt.

  1. Erstellen Sie eine Benutzergruppe, und fügen Sie der Gruppe Benutzer hinzu.

  2. Definieren Sie eine Policy mit den folgenden Anweisungen:

    define tenancy <source-tenancy-name> as <source-tenancy-OCID>
    endorse group <group-name> to manage dis-family in tenancy <source-tenancy-name>
    endorse group <group-name> to manage dis-workspaces in tenancy <source-tenancy-name>
    endorse group <group-name> to read compartments in tenancy <source-tenancy-name>
    endorse any-user to read compartments in tenancy <source-tenancy-name> where ALL {request.principal.type = 'disworkspace'}
    endorse any-user to manage dis-workspaces in tenancy <source-tenancy-name> where ALL {request.principal.type = 'disworkspace'}

Im Quellmandanten:

Der Quellmandant verfügt über den Workspace mit der vorhandenen Anwendung oder dem Projekt, die bzw. das kopiert werden soll.

  1. Definieren Sie eine Policy mit den folgenden Anweisungen:

    define tenancy <target-tenancy-name> as <target-tenancy-OCID>
    define group <group-name> as <group-OCID>

  2. Für allgemeinen Zugriff auf alle Arbeitsbereiche:

    admit group <group-name> of tenancy <target-tenancy-name> to read compartments in tenancy
    admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy
    admit any-user of tenancy <target-tenancy-name> to read compartments in tenancy  where ALL {request.principal.type = 'disworkspace'}
    admit any-user of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where ALL {request.principal.type = 'disworkspace'}

Anstelle von generischem Zugriff können Sie eine feiner granulierte Berechtigung bereitstellen, die auf der Quell-Workspace-OCID oder dem Quellanwendungsschlüssel basiert:

admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where source.workspace.id  = '<source-tenancy-workspace-OCID>'
admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where source.application.key = '<source-existing-application-key>'
Policy-Beispiele mit Berechtigungen und APIs

Hier sind einige Beispiele für die Verwendung von Berechtigungen in einer Bedingung aufgeführt:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_READ'
allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_UPDATE'

Hier sind einige Beispiele für die Verwendung von API-Vorgängen in einer Bedingung aufgeführt:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'GetWorkspace'
allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'UpdateWorkspace'
Hinweis

Eine Berechtigung kann mit mehreren APIs verknüpft sein. Wenn Sie eine Berechtigung und keine spezifische API in einer Policy verwenden, prüfen Sie unter Für jeden API-Vorgang erforderliche Berechtigungen, ob die Policy die APIs abdeckt, die Sie verwenden möchten.
Policy-Beispiele mit bedingten Anweisungen
Hinweis

Sie können die Workspace-OCID aus der Konsole kopieren.

Beim Hinzufügen von Bedingungen zu einer Policy verwenden Sie Variablen. Siehe Allgemeine Variablen für alle Anforderungen.

Policys mit bedingten Anweisungen enthalten eine where-Klausel. So berechtigen Sie beispielsweise eine Gruppe zum Aktualisieren eines bestimmten Workspace und keines anderen Workspace:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

So berechtigen Sie nur die Gruppe, die einen Workspace erstellt, zum Verwenden dieses Workspace:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.createdBy = request.user.id

So berechtigen Sie eine Gruppe zum Verwalten aller Data Integration-Ressourcen, außer zum Löschen von Workspaces:

allow group <group-name> to manage dis-family in compartment <compartment-name> where request.permission != 'DIS_WORKSPACE_DELETE'

Policy-Anweisungen, die einen Schlüssel in einer where-Klausel verwenden, berechtigen Benutzer in einer Gruppe zum Verwenden von Workspaces in einem Compartment, in dem die Anforderung diesen spezifischen Schlüssel enthält. Sie können beispielsweise eine Gruppe nur zum Arbeiten in einer bestimmten Anwendung berechtigen.

So beschränken Sie eine Gruppe nur auf die Ausführung von Aufgaben in einer bestimmten Anwendung:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.application.key='<application-key>'}

So berechtigen Sie eine Gruppe zum Erstellen von Objekten (wie Aufgaben und Datenflüsse) nur in einem Ordner:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.folder.key='<folder-key>'}

So berechtigen Sie eine Gruppe zum Aktualisieren oder Löschen eines bestimmten Objekt, beispielsweise eines Datenflusses:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.object.key='<object-key>'}
Policy-Beispiele für das Aktivieren des Zugriffs auf OCI Object Storage

In Data Integration ist eine spezielle Berechtigung für Oracle Cloud Infrastructure Object Storage erforderlich, um auf Metadaten zuzugreifen und Daten zu lesen und zu schreiben.

Um ein Object Storage-Datenasset zu erstellen und die zugehörigen Schemas zu durchsuchen, müssen Sie zu einer Benutzergruppe gehören, die über die Berechtigung zum Lesen von Object Storage verfügt. Siehe Beispiele für "Im Namen von"-Policys.

Um eine Object Storage-Verbindung zu testen, stellen Sie sicher, dass der Data Integration-Workspace oder das Compartment mindestens READ-Zugriff auf objectstorage-namespaces hat. Siehe Beispiele für Resource Principal Policys.

Um einen Datenfluss mit Object Storage als Quelle oder Ziel zu erstellen und auszuführen, sind für den Workspace oder das Compartment alle Policys erforderlich, die unter Beispiele für Resource Principal Policys aufgeführt sind.

Hinweis

Der Inhalt der WHERE-Klausel ist optional. Er ist jedoch erforderlich, um die Ressourcen einzuschränken, die auf Oracle Cloud Infrastructure Object Storage zugreifen. Sie können damit den Zugriff entsprechend bestimmten Anforderungen optimieren. Um eine Policy-Anweisung anzuwenden, gehen Sie wie folgt vor:
  • Um eine Policy-Anweisung auf alle Workspaces anzuwenden, verwenden Sie WHERE ALL {request.principal.type='disworkspace'}.
  • Um eine Policy-Anweisung auf einen bestimmten Workspace anzuwenden, verwenden Sie WHERE ALL {request.principal.id='<workspace-OCID>'}.

    Sie können die Workspace-OCID aus der Konsole kopieren.

  • Um eine Policy-Anweisung auf alle Workspaces in einem bestimmten Compartment anzuwenden, verwenden Sie WHERE ALL {request.resource.compartment.id = '<compartment-OCID>'}

Ausführliche Informationen zum Schreiben von Policys zur Kontrolle des Zugriffs auf Object Storage finden Sie unter Details zu Object Storage.

Resource Principal Policy

Diese Policys berechtigen einen Data Integration-Workspace oder das zugehörige Compartment zum Validieren von Verbindungen zu Oracle Cloud Infrastructure Object Storage sowie zum Lesen und Schreiben von Daten.

Die erforderlichen Policys hängen davon ab, ob sich das Object Storage-Datenasset und der Data Integration-Workspace im selben Mandanten oder in verschiedenen Mandanten befinden.

In demselben Mandanten

Wenn sich der Data Integration-Workspace und die Object Storage-Datenquelle in demselben Mandanten befinden, müssen Sie die folgenden Policys erstellen:

allow any-user to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.operation = 'GetBucket'}
allow any-user to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

In verschiedenen Mandanten

Wenn sich der Data Integration-Workspace und die Object Storage-Datenquelle in verschiedenen Mandanten befinden, müssen Sie die folgenden Policys erstellen:

Im Workspace-Mandanten:


Endorse any-user to read buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}

Endorse any-user to manage objects in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}


Endorse any-user to manage buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}

Endorse any-user to inspect compartments in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace'}

Im Object Storage-Client:

Admit any-user of tenancy <tenancy-name> to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}

Admit any-user of tenancy <tenancy-name> to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}

Admit any-user of tenancy <tenancy-name> to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}

Admit any-user of tenancy <tenancy-name> to inspect compartments in tenancy
Beispiele für "Im Namen von"-Policys

Diese Policys berechtigen den angemeldeten Benutzer zum Auflisten und Durchsuchen von Compartments, Objektspeicher-Buckets und Objekten basierend auf den Berechtigungen, die dem Benutzer bereits zugewiesen sind.

Die erforderlichen Policys hängen davon ab, ob sich das Object Storage-Datenasset und der Data Integration-Workspace im selben Mandanten oder in verschiedenen Mandanten befinden.

In demselben Mandanten

Wenn der Data Integration-Workspace und das Object Storage-Datenasset zu demselben Mandanten gehören, muss der Benutzer (oder die Gruppe, zu der der Benutzer gehört) Zugriff auf Object Storage haben:

allow group <group-name> to use object-family in compartment <compartment-name>

In verschiedenen Mandanten

Wenn sich der Data Integration-Workspace und das Object Storage-Datenasset in verschiedenen Mandanten befinden, müssen Sie die folgenden Policys erstellen:

Im Workspace-Mandanten:

Define tenancy <any-name1> as <object-storage-tenancy-OCID>
Endorse group <group-name> to inspect compartments in tenancy <any-name1>
Endorse group <group-name> to use object-family in tenancy <any-name1>

Im Object Storage-Client:

Define tenancy <any-name2> as <workspace-tenancy-OCID>
Define group <workspace-tenancy-group-name> as <workspace-tenancy-group-OCID>
Admit group <group-name> of tenancy <any-name2> to inspect compartments in tenancy
Admit group <group-name> of tenancy <any-name2> to use object-family in compartment <compartment-name>
Policy-Beispiele für die Verwendung von autonomen Datenbanken als Ziele

Wenn Sie Autonomous Data Warehouse- oder Autonomous Transaction Processing-Datenbanken als Zieldatenbank in Data Integration verwenden, wird OCI Object Storage für das Staging von Daten und das Durchführen von Vorgängen verwendet. Zusätzlich zu den erforderlichen Object Storage-Policys müssen Sie auch die folgende Policy erstellen, um die Vorabauthentifizierung für solche Anforderungen zuzulassen:

allow any-user to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.permission = 'PAR_MANAGE'}
Policy-Beispiele für die Veröffentlichung im OCI Data Flow-Service

Bevor Sie Aufgaben aus OCI Data Integration mit privaten Endpunkten im OCI Data Flow-Service veröffentlichen können, stellen Sie sicher, dass Sie über die folgenden Policys verfügen.

allow any-user to manage dataflow-application in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}
allow any-user to manage dataflow-run in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}
allow group <group-name> to read dataflow-application in compartment <compartment-name>
allow group <group-name> to manage dataflow-run in compartment <compartment-name>
allow any-user to read dataflow-private-endpoint in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}
allow any-user to read secret-bundles in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

Für Benutzer ohne Administratorrechte sind diese Richtlinien erforderlich:

allow group <group-name> to inspect dataflow-private-endpoint in compartment <compartment-name>
allow group <group-name> to read secret-bundles in compartment <compartment-name>
Policy-Beispiele für den Zugriff auf den OCI AI-Service-REST-Endpunkt

Für die Authentifizierung durch Ausführung einer REST-Aufgabe mit dem Anwendungs-Resource-Principal fügen Sie Folgendes hinzu, um den OCI-Resource Principal abzurufen.

allow any-user to use ai-service-language-family in tenancy where ALL {request.principal.type = 'disapplication', request.principal.id = '<disapplication-ocid>'}