Exemples de stratégie
Utilisez les exemples suivants pour en savoir plus sur les stratégies IAM dans Data Integration.
La syntaxe générale d'une instruction de stratégie est la suivante :
allow <subject> to <verb> <resource-type> in <location> where <condition>
Pour obtenir une description de chaque variable, reportez-vous à Syntaxe de stratégie.
Une fois que vous avez ajouté des composants IAM (par exemple, des groupes dynamiques et des instructions de stratégie), n'essayez pas d'effectuer les tâches associées immédiatement. Les nouvelles stratégies IAM prennent effet en cinq à 10 minutes environ.
Pour exporter et importer des objets, reportez-vous à Activation de l'export et de l'import de l'espace de travail et des objets dans l'espace de travail.
Consultez également le blog Stratégies dans Oracle Cloud Infrastructure (OCI) Data Integration pour identifier les stratégies dont vous avez besoin.
Pour utiliser des espaces de travail Data Integration, vous devez créer des stratégies.
Pour utiliser des connexions réseau privées aux sources de données, vous devez autoriser Data Integration à gérer les réseaux virtuels que vous avez configurés pour l'intégration.
Sans la stratégie suivante, l'intégration des données échoue.
allow service dataintegration to use virtual-network-family in compartment <compartment-name>
Pour autoriser un groupe à gérer les ressources réseau dans un compartiment :
allow group <group-name> to manage virtual-network-family in compartment <compartment-name>
Pour les utilisateurs non administrateurs :
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>
Pour autoriser Data Integration à répertorier les utilisateurs et les compartiments, vous pouvez utiliser inspect
.
allow service dataintegration to inspect users in tenancy
allow group <group-name> to inspect compartments in compartment <target-compartment-name>
Pour autoriser un groupe à visualiser la liste de tous les espaces de travail Data Integration, vous pouvez utiliser inspect
.
Pour visualiser les espaces de travail d'un compartiment spécifique :
allow group <group-name> to inspect dis-workspaces in compartment <compartment-name>
Pour autoriser un groupe à visualiser la liste de tous les espaces de travail Data Integration, vous pouvez utiliser inspect
.
Le verbe read
pour dis-workspaces
inclut les mêmes droits d'accès et opérations d'API que inspect
, plus le droit d'accès DIS_WORKSPACE_READ
et les opérations d'API qu'il couvre.
Pour autoriser un groupe à obtenir la liste et les détails relatifs à dis-workspaces
dans un compartiment spécifique, vous pouvez utiliser le verbe read
:
allow group <group-name> to read dis-workspaces in compartment <compartment-name>
Pour autoriser un groupe à obtenir la liste et les détails relatifs à dis-workspaces
et aux objets qu'il contient dans la location, vous pouvez utiliser :
allow group <group-name> to read dis-workspaces in tenancy
Pour autoriser un groupe à mettre à jour les espaces de travail et les objets qu'ils contiennent, vous pouvez utiliser le verbe use
.
Le verbe use
pour dis-workspaces
inclut les mêmes droits d'accès et opérations d'API que read
et inspect
, plus le droit d'accès DIS_WORKSPACE_UPDATE
et les opérations d'API qu'il couvre.
Pour autoriser un groupe à mettre à jour dis-workspaces
dans un compartiment spécifique, vous pouvez utiliser :
allow group <group-name> to use dis-workspaces in compartment <compartment-name>
Pour autoriser un groupe à mettre à jour dis-workspaces
et les objets qu'il contient dans la location, vous pouvez utiliser :
allow group <group-name> to use dis-workspaces in tenancy
Pour autoriser un groupe à mettre à jour un espace de travail spécifique et aucun autre espace de travail :
allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'
Pour autoriser un groupe à mettre à jour un ensemble d'espaces de travail donnés :
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>')
Pour autoriser un groupe à gérer les espaces de travail et les objets qu'ils contiennent, vous pouvez utiliser le verbe manage
.
Le verbe manage
pour dis-workspaces
inclut les mêmes droits d'accès et opérations d'API que inspect
, read
et use
, plus les droits d'accès DIS_WORKSPACE_CREATE
et DIS_WORKSPACE_DELETE
, et les opérations d'API qu'ils couvrent.
Pour autoriser un groupe à gérer dis-workspaces
dans un compartiment spécifique, vous pouvez utiliser :
allow group <group-name> to manage dis-workspaces in compartment <compartment-name>
Pour autoriser un groupe à gérer dis-workspaces
et les objets qu'il contient dans la location, vous pouvez utiliser :
allow group <group-name> to manage dis-workspaces in tenancy
Pour autoriser un groupe à gérer un espace de travail spécifique et aucun autre espace de travail :
allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'
Pour autoriser un groupe à gérer un ensemble d'espaces de travail donnés :
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>')
Pour autoriser Data Integration à effectuer des recherches dans les espaces de travail d'une location, définissez les stratégies suivantes dans le compartiment racine de la location.
allow service dataintegration to {TENANCY_INSPECT} in tenancy
allow service dataintegration to {DIS_METADATA_INSPECT} in tenancy
Data Integration a besoin de stratégies spécifiques pour utiliser l'export et l'import. Reportez-vous à Configuration et stratégies requises dans la rubrique Export et import d'objets.
Data Integration doit également accéder aux ressources dans Object Storage à des fins d'export et d'import. Reportez-vous à Exemples de stratégie permettant d'activer l'accès à OCI Object Storage.
Pour créer une application ou un projet dans une location (cible) en copiant des ressources à partir d'une application ou d'un projet existant dans une autre location (source), certaines stratégies doivent être configurées dans les locations source et cible.
Pour écrire des instructions de stratégie inter-locations, vous devez disposer des éléments suivants :
- Nom et OCID de location cible
- Nom et OCID de la location source
- OCID de groupe d'utilisateurs d'un groupe dont les utilisateurs disposent de droits d'accès en lecture et en écriture sur les espaces de travail source et cible
Dans la location cible :
La location cible est l'emplacement où la copie de l'application ou du projet doit être créée.
-
Créez un groupe d'utilisateurs et ajoutez-y des utilisateurs.
-
Définissez une stratégie avec les instructions suivantes :
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'}
Dans la location source :
La location source comporte l'espace de travail avec l'application ou le projet existant à copier.
-
Définissez une stratégie avec les instructions suivantes :
define tenancy <target-tenancy-name> as <target-tenancy-OCID>
define group <group-name> as <group-OCID>
-
Pour un accès générique à tous les espaces de travail :
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'}
Au lieu d'un accès générique, vous pouvez fournir un droit d'accès plus détaillé basé sur l'OCID ou la clé d'application source de l'espace de travail source :
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>'
Voici quelques exemples d'utilisation des droits d'accès dans une condition :
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'
Voici quelques exemples d'utilisation des opérations d'API dans une condition :
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'
Un droit d'accès peut être associé à plusieurs API. Si vous utilisez un droit d'accès et non une API spécifique dans une stratégie, sélectionnez Autorisations requises pour chaque opération d'API afin de vous assurer que la stratégie couvre les API que vous souhaitez utiliser.
Vous utilisez des variables lorsque vous ajoutez des conditions à une stratégie. Reportez-vous à Variables générales pour toutes les demandes.
Les stratégies avec des instructions conditionnelles comportent une clause where
. Par exemple, pour autoriser un groupe à mettre à jour un espace de travail spécifique et aucun autre espace de travail :
allow group <group-name> to use dis-workspace in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'
Pour autoriser uniquement le groupe qui crée un espace de travail à l'utiliser :
allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.createdBy = request.user.id
Pour autoriser un groupe à gérer toutes les ressources Data Integration, sauf pour la suppression d'espaces de travail :
allow group <group-name> to manage dis-family in compartment <compartment-name> where request.permission != 'DIS_WORKSPACE_DELETE'
Les instructions de stratégie qui utilisent une clé dans une clause where
permettent aux utilisateurs d'un groupe d'utiliser des espaces de travail dans un compartiment où la demande dispose de cette clé. Par exemple, vous pouvez autoriser un groupe à agir uniquement dans une application spécifique.
Pour limiter un groupe à l'exécution de tâches dans une application spécifique :
allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.application.key='<application-key>'}
Pour autoriser un groupe à créer des objets (tels que des tâches et des flux de données) uniquement dans un dossier :
allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.folder.key='<folder-key>'}
Pour autoriser un groupe à mettre à jour ou à supprimer un objet spécifique, tel qu'un flux de données :
allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.object.key='<object-key>'}
Data Integration a besoin d'un droit d'accès spécifique pour Oracle Cloud Infrastructure Object Storage, afin d'accéder aux métadonnées, et de lire et d'écrire des données.
Pour créer une ressource de données Object Storage et parcourir ses schémas, vous devez appartenir à un groupe d'utilisateurs disposant de droits d'accès en lecture sur Object Storage. Reportez-vous à Exemples de stratégie Au nom de.
Pour tester une connexion Object Storage, assurez-vous que l'espace de travail Data Integration ou le compartiment dispose au minimum d'un accès READ
à objectstorage-namespaces
. Reportez-vous à Exemples de stratégie de principal de ressource.
Pour créer et exécuter un flux de données à l'aide d'Object Storage en tant que source ou cible, l'espace de travail ou le compartiment doit inclure toutes les stratégies mentionnées dans Exemples de stratégie de principal de ressource.
Le contenu de la clause WHERE est optionnel, mais requis pour limiter les ressources accès à Oracle Cloud Infrastructure Object Storage. Vous pouvez l'utiliser pour affiner l'accès en fonction de besoins spécifiques. Pour appliquer une instruction de stratégie à :
- tous les espaces de travail, utilisez
WHERE ALL {request.principal.type='disworkspace'}
. - un espace de travail spécifique, utilisez
WHERE ALL {request.principal.id='<workspace-OCID>'}
.Vous pouvez Copier l'OCID de l'OCID de l'espace de travail à partir de la console.
- tous les espaces de travail d'un compartiment spécifique, utilisez
WHERE ALL {request.resource.compartment.id = '<compartment-OCID>'}
.
Pour plus d'informations sur l'écriture de stratégies afin de contrôler l'accès à Object Storage, reportez-vous à Détails sur Object Storage.
Ces stratégies permettent à un espace de travail Data Integration ou à son compartiment de valider les connexions à Oracle Cloud Infrastructure Object Storage, ainsi que de lire et d'écrire des données.
Les stratégies requises dépendent du fait que la ressource de données Object Storage et l'espace de travail Data Integration se trouvent dans la même location ou dans des locations différentes.
Dans la même location
Si l'espace de travail Data Integration et la source de données Object Storage se trouvent dans la même location, vous devez créer les stratégies suivantes :
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>'}
Dans différentes locations
Si l'espace de travail Data Integration et la source de données Object Storage se trouvent dans des locations différentes, vous devez créer les stratégies suivantes :
Dans la location de l'espace de travail :
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'}
Dans la location Object Storage :
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
Ces stratégies permettent à l'utilisateur connecté de répertorier et de parcourir les compartiments, les buckets Object Storage et les objets en fonction des droits d'accès qui lui sont déjà affectés.
Les stratégies requises dépendent du fait que la ressource de données Object Storage et l'espace de travail Data Integration se trouvent dans la même location ou dans des locations différentes.
Dans la même location
Si l'espace de travail Intégration de données et la ressource de données Object Storage appartiennent à la même location, l'utilisateur (ou le groupe auquel l'utilisateur appartient) doit avoir accès à Object Storage :
allow group <group-name> to use object-family in compartment <compartment-name>
Dans différentes locations
Si l'espace de travail Data Integration et la ressource de données Object Storage se trouvent dans des locations différentes, vous devez créer les stratégies suivantes :
Dans la location de l'espace de travail :
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>
Dans la location Object Storage :
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>
Lorsque vous utilisez une base de données Autonomous Data Warehouse ou Autonomous Transaction Processing en tant que base de données cible dans Data Integration, OCI Object Storage est utilisé pour préparer les données et terminer les opérations. Outre les stratégies Object Storage requises, vous devez également créer la stratégie suivante afin d'autoriser la pré-authentification pour ces demandes :
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'}
Pour pouvoir publier des tâches depuis OCI Data Integration vers le service OCI Data Flow avec des adresses privées, vérifiez que vous disposez des stratégies suivantes.
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>'}
Pour les utilisateurs non administrateurs, les stratégies suivantes sont requises :
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>
Pour authentifier l'exécution d'une tâche REST à l'aide du principal de ressource d'application, ajoutez ce qui suit pour obtenir le principal de ressource OCI.
allow any-user to use ai-service-language-family in tenancy where ALL {request.principal.type = 'disapplication', request.principal.id = '<disapplication-ocid>'}