Documentação do Oracle Cloud Infrastructure

Exemplos de Política

Use os exemplos a seguir para saber mais sobre políticas do IAM no Data Integration.

A sintaxe geral de uma instrução de política é:

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

Para obter uma descrição de cada variável, consulte Sintaxe da Política.

Observação

Depois de adicionar componentes do IAM (por exemplo, grupos dinâmicos e instruções de política), não tente executar as tarefas associadas imediatamente. As novas políticas do IAM exigem cerca de cinco a 10 minutos para entrar em vigor.

Para exportar e importar objetos, consulte Ativar Exportação e Importação de Espaço de Trabalho e Objetos no Espaço de Trabalho.

Revise também o blog Policies in Oracle Cloud Infrastructure (OCI) Data Integration para identificar as políticas necessárias.

Exemplos de Política para Ativar o Acesso ao Data Integration e Usar Espaços de Trabalho

Para usar espaços de trabalho do Data Integration, crie políticas.

Ativar o Uso de Rede Privada nos Espaços de Trabalho

Para usar conexões de rede privada com as origens de dados, conceda permissão ao Data Integration para gerenciar as redes virtuais que você configurou para integração.

Sem a política a seguir, a integração de dados falha.

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

Para conceder permissão a um grupo para gerenciar recursos de rede em um compartimento:

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

Para usuários não administradores:

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>

Ativar Acesso para Listar Usuários e Compartimentos

Para conceder ao Data Integration permissão para listar usuários e compartimentos, você pode usar inspect.

allow service dataintegration to inspect users in tenancy
allow group <group-name> to inspect compartments in compartment <target-compartment-name>
Ativar o Acesso para Exibir Espaços de Trabalho

Para permitir que um grupo exiba a lista de todos os espaços de trabalho do Data Integration, você pode usar inspect.

Para exibir espaços de trabalho em um compartimento específico:

allow group <group-name> to inspect dis-workspaces in compartment <compartment-name>
Ativar o Acesso para Obter Detalhes do Espaço de Trabalho

Para permitir que um grupo exiba a lista de todos os espaços de trabalho do Data Integration, você pode usar inspect.

O verbo read, para dis-workspaces inclui as mesmas permissões e operações de API que inspect, mais a permissão, DIS_WORKSPACE_READ, e as operações de API que ele abrange.

Para permitir que um grupo liste e obtenha detalhes de dis-workspaces em um compartimento específico, você pode usar o verbo read:

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

Para permitir que um grupo liste e obtenha detalhes de dis-workspaces e dos objetos que ele contém na tenancy, você pode usar:

allow group <group-name> to read dis-workspaces in tenancy
Ativar o Acesso para Atualizar Espaços de Trabalho

Para permitir que um grupo atualize espaços de trabalho e os objetos que eles contêm, você pode usar o verbo use.

O verbo use, para dis-workspaces inclui as mesmas permissões e operações de API que read e inspect, além da permissão, DIS_WORKSPACE_UPDATE, e as operações de API que ele abrange.

Para permitir que um grupo atualize dis-workspaces em um compartimento específico, você pode usar:

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

Para permitir que um grupo atualize dis-workspaces e os objetos que ele contém na tenancy, você pode usar:

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

Para permitir que um grupo atualize um espaço de trabalho específico e não qualquer outro espaço de trabalho:

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

Para permitir que um grupo atualize um conjunto de espaços de trabalho especificados:

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>')
Observação

Você pode copiar o OCID do espaço de trabalho na Console.
Ativar o Acesso para Gerenciar Espaços de Trabalho

Para permitir que um grupo gerencie espaços de trabalho e os objetos que eles contêm, você pode usar o verbo manage.

O verbo manage, para dis-workspaces inclui as mesmas permissões e operações de API que inspect, read e use mais as permissões, DIS_WORKSPACE_CREATE e DIS_WORKSPACE_DELETE, e as operações de API que ele abrange.

Para permitir que um grupo gerencie dis-workspaces em um compartimento específico, você pode usar:

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

Para permitir que um grupo gerencie dis-workspaces e os objetos que ele contém na tenancy, você pode usar:

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

Para permitir que um grupo gerencie um espaço de trabalho específico e não qualquer outro espaço de trabalho:

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

Para permitir que um grupo gerencie um conjunto de espaços de trabalho especificados:

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>')
Observação

Você pode copiar o OCID do espaço de trabalho na Console.
Permitir Exportação e Importação de Objetos em Espaços de Trabalho

O Data Integration precisa de políticas específicas para usar exportação e importação. Consulte Configuração e Políticas Obrigatórias no tópico Exportação e Importação de Objetos.

O Data Integration também precisa acessar recursos no Object Storage para exportação e importação. Consulte Exemplos de Política para Ativar o Acesso ao OCI Object Storage.

Exemplos de Política para Configurar o Acesso entre Tenancies para Cópia do Projeto e Cópia do Aplicativo

Para criar um aplicativo ou um projeto em uma tenancy (destino) copiando recursos de um aplicativo ou projeto existente que esteja em outra tenancy (origem), determinadas políticas devem ser configuradas nas tenancies de origem e destino.

Você precisa ter o seguinte para gravar instruções de política entre tenancies:

  • O nome e o OCID da tenancy de destino
  • O nome e o OCID da tenancy de origem
  • O OCID do grupo de usuários de um grupo cujos usuários têm permissões de leitura e gravação nos espaços de trabalho de origem e destino

Na tenancy de destino:

A tenancy de destino é onde o novo aplicativo ou cópia do projeto deve ser criado.

  1. Crie um grupo de usuários e adicione usuários ao grupo.

  2. Defina uma política com as seguintes instruções:

    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'}

Na tenancy de origem:

A tenancy de origem tem o espaço de trabalho com o aplicativo ou projeto existente que deve ser copiado.

  1. Defina uma política com as seguintes instruções:

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

  2. Para acesso genérico a todos os espaços de trabalho:

    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'}

Em vez de acesso genérico, você pode fornecer uma permissão mais detalhada baseada no OCID do espaço de trabalho de origem ou na chave do aplicativo de origem:

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>'
Exemplos de Permissão de Política e API

Veja alguns exemplos que usam permissões em uma condição:

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'

Aqui estão alguns exemplos para usar operações de API em uma condição:

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'
Observação

Uma permissão pode ter mais de uma API relacionada a ela. Se você usar uma permissão e não uma API específica em uma política, verifique Permissões Obrigatórias para Cada Operação de API para garantir que a política abranja as APIs que você pretende usar.
Exemplos de Política com Instruções Condicionais
Observação

Você pode copiar o OCID do espaço de trabalho na Console.

Use variáveis ao adicionar condições a uma política. Consulte Variáveis Gerais para Todas as Solicitações.

As políticas com instruções condicionais têm uma cláusula where. Por exemplo, para permitir que um grupo atualize um espaço de trabalho específico e não qualquer outro espaço de trabalho:

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

Para permitir que somente o grupo que cria um espaço de trabalho o use:

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

Para permitir que um grupo gerencie todos os recursos do serviço Data Integration, exceto excluir espaços de trabalho:

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

As instruções de política que usam uma chave na cláusula where permitem que os usuários de um grupo usem espaços de trabalho em um compartimento no qual a solicitação tem essa chave específica. Por exemplo, você pode permitir que um grupo opere apenas em um aplicativo específico.

Para restringir um grupo a só executar tarefas em um aplicativo específico:

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

Para permitir que um grupo só crie objetos (como tarefas e fluxos de dados) em uma pasta:

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

Para permitir que um grupo atualize ou exclua um objeto específico, como um fluxo de dados:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.object.key='<object-key>'}
Exemplos de Política para Ativar o Acesso ao OCI Object Storage

O Data Integration precisa de permissão específica do Oracle Cloud Infrastructure Object Storage para acessar metadados e ler e gravar dados.

Para criar um ativo de dados do Armazenamento de Objetos e procurar esquemas, você deve pertencer a um grupo de usuários que tenha permissão para ler o Armazenamento de Objetos. Consulte Exemplos da Política Em Nome de.

Para testar uma conexão do serviço Object Storage, certifique-se de que o espaço de trabalho ou compartimento do serviço Data Integration tenha, no mínimo, acesso READ a objectstorage-namespaces. Consulte Exemplos de Política de Controlador de Recursos.

Para criar e executar um fluxo de dados usando o Object Storage como origem ou destino, o espaço de trabalho ou compartimento deve ter todas as políticas mencionadas em Exemplos de Política de Controlador de Recursos.

Observação

O conteúdo da cláusula WHERE é opcional, mas é obrigatório para limitar os recursos que acessam o Oracle Cloud Infrastructure Object Storage. Você pode usá-lo para ajustar o acesso de acordo com necessidades específicas. Para aplicar uma instrução de política a:
  • Todos os espaços de trabalho, use WHERE ALL {request.principal.type='disworkspace'}
  • Um espaço de trabalho específico, use WHERE ALL {request.principal.id='<workspace-OCID>'}

    Você pode copiar o OCID do espaço de trabalho na Console.

  • Todos os espaços de trabalho em um compartimento específico, use WHERE ALL {request.resource.compartment.id = '<compartment-OCID>'}

Para obter detalhes completos sobre a criação de políticas para controlar o acesso ao serviço Object Storage, consulte Detalhes do Serviço Object Storage.

Política de Controlador de Recursos

Essas políticas permitem que um espaço de trabalho do Data Integration ou seu compartimento valide conexões com o Oracle Cloud Infrastructure Object Storage, bem como leia e grave dados.

As políticas necessárias dependem se o ativo de dados do Object Storage e o espaço de trabalho do Data Integration estão na mesma tenancy ou em tenancies diferentes.

Na mesma tenancy

Se o espaço de trabalho do Data Integration e a origem de dados do Object Storage estiverem na mesma tenancy, crie as seguintes políticas:

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>'}

Em diferentes tenancies

Se o espaço de trabalho do Data Integration e a origem de dados do Object Storage estiverem em diferentes tenancies, crie as seguintes políticas:

Na tenancy do espaço de trabalho:


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'}

Na tenancy do serviço 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
Exemplos da Política Em Nome de

Essas políticas permitem que o usuário conectado liste e procure compartimentos, buckets do Object Storage e objetos com base nas permissões já designadas ao usuário.

As políticas necessárias dependem se o ativo de dados do Object Storage e o espaço de trabalho do Data Integration estão na mesma tenancy ou em tenancies diferentes.

Na mesma tenancy

Se o espaço de trabalho do Data Integration e o ativo de dados do Object Storage pertencerem à mesma tenancy, o usuário (ou o grupo ao qual o usuário pertence) deverá ter acesso ao Object Storage:

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

Em diferentes tenancies

Se o espaço de trabalho do Data Integration e o ativo de dados do Object Storage estiverem em diferentes tenancies, crie as seguintes políticas:

Na tenancy do espaço de trabalho:

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>

Na tenancy do serviço 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>
Exemplos de Política para Usar Autonomous Databases como Destinos

Quando você usa bancos de dados Autonomous Data Warehouse ou Autonomous Transaction Processing como banco de dados de destino no serviço Data Integration, o OCI Object Storage é usado para preparar dados e concluir operações. Além das políticas de Armazenamento de Objetos necessárias, você também deve criar a seguinte política para permitir a pré-autenticação dessas solicitações:

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'}
Exemplos de Política para Publicação no Serviço OCI Data Flow

Para poder publicar tarefas do OCI Data Integration no serviço OCI Data Flow com pontos finais privados, certifique-se de ter as políticas a seguir.

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>'}

Para usuários não administradores, estas políticas são necessárias:

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>
Exemplos de Política para Acessar o Ponto Final REST do Serviço OCI AI

Para autenticar a execução de uma tarefa REST usando o controlador de recursos do aplicativo, adicione o seguinte para obter o controlador de recurso do OCI.

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