Documentação do Oracle Cloud Infrastructure

Autenticando e Autorizando Usuários do Microsoft Entra ID (MS-EI) para Bancos de Dados Oracle no Oracle Exadata Database Service on Dedicated Infrastructure

Um Oracle Database pode ser configurado para que os usuários do Microsoft Azure do Microsoft Entra ID se conectem usando a autenticação de sign-on único.

Tópico principal: Guias Práticos

Sobre a Autorização de Usuários do Microsoft Entra ID (MS-EI) para Bancos de Dados Oracle no Oracle Exadata Database Service on Dedicated Infrastructure

Os usuários do Oracle Exadata Database Service on Dedicated Infrastructure podem ser gerenciados centralmente em um serviço MS-EI.

A integração do Oracle Database com o MS-EI é suportada para bancos de dados locais e para a maioria das plataformas Oracle OCI DBaaS.

As instruções para configurar o MS-EI usam o termo "Oracle Database" para abranger esses ambientes.

Esse tipo de integração permite que o usuário do MS-EI acesse uma instância do Oracle Exadata Database Service on Dedicated Infrastructure. Os usuários e aplicativos do MS-EI podem fazer log-in com credenciais de SSO (Single Sign On) do MS-EI para obter um token de acesso MS-EI OAuth2 para enviar ao banco de dados.

O administrador cria e configura o registro do aplicativo da instância do Oracle Exadata Database Service on Dedicated Infrastructure no MS-EI. O administrador também cria funções de aplicativo (app) para o registro de aplicativo de banco de dados no MS-EI e atribui essas funções a usuários, grupos e aplicativos do MS-EI. Essas atribuições de aplicativo serão mapeadas para os esquemas e atribuições globais de banco de dados. Um controlador MS-EI designado a uma atribuição de aplicativo será mapeado para um esquema ou uma atribuição global de banco de dados. Um esquema global Oracle também pode ser mapeado exclusivamente para um usuário do MS-EI. Quando o controlador é um usuário convidado ou um controlador de serviços, ele só pode ser mapeado para o esquema de banco de dados por meio de uma atribuição de aplicativo MS-EI. Uma função global Oracle só pode ser mapeada para uma função de aplicativo MS-EI.

Ferramentas e aplicativos que são atualizados para suportar tokens MS-EI podem autenticar usuários diretamente com MS-EI e passar o token de acesso ao banco de dados para a instância do Oracle Exadata Database Service on Dedicated Infrastructure. Você pode configurar ferramentas de banco de dados existentes, como o SQL*Plus, para usar um token MS-EI de um local de arquivo ou obter o token diretamente do MS-EI. Ao usar um utilitário para obter o token a ser transmitido ao driver do cliente de banco de dados por meio de um local de arquivo, os tokens MS-EI podem ser recuperados usando ferramentas como Microsoft PowerShell ou Azure CLI e colocados em um local de arquivo. Um token de acesso do banco de dados MS-EI OAuth2 é um token ao portador com prazo de expiração. O driver do cliente Oracle Database garantirá que o token esteja em um formato válido e que ele não tenha expirado antes de transmiti-lo ao banco de dados. O token tem escopo no banco de dados. As atribuições de aplicativo designadas para o controlador do Azure AD são incluídas como parte do token de acesso. O local do diretório do token MS-EI só deve ter permissão suficiente para que o usuário grave o arquivo de token no local e o cliente de banco de dados recupere esses arquivos (por exemplo, basta ler e gravar pelo usuário do processo). Como o token permite o acesso ao banco de dados, ele deve ser protegido dentro do sistema de arquivos.

Os usuários do MS-EI podem solicitar um token como cliente registrado no registro do aplicativo MS-EI usando métodos como os seguintes:

  • Inserir as credenciais do MS-EI em uma tela de autenticação do MS-EI com ou sem autenticação multifator

O Oracle Exadata Database Service on Dedicated Infrastructure suporta os seguintes fluxos de autenticação MS-EI:

  • Fluxo interativo (código de autorização), que é usado quando um browser pode ser usado para informar as credenciais do usuário
  • Credenciais do cliente, que são para aplicativos que se conectam como eles mesmos (e não como o usuário final)
  • Em Nome de (OBO), em que um aplicativo solicita um token de acesso em nome de um usuário conectado para envio ao banco de dados
  • O ROPC também é suportado para ambientes de teste e desenvolvimento

O Oracle Exadata Database Service on Dedicated Infrastructure aceita tokens que representam os seguintes controladores do MS-EI:

  • Usuário do MS-EI, que é usuário registrado na tenancy do MS-EI
  • Usuário convidado, que é registrado como usuário convidado na tenancy do MS-EI
  • Serviço, que é o aplicativo registrado que se conecta ao banco de dados como ele mesmo com o fluxo de credenciais do cliente (caso de uso do pool de conexões)

Configurando a Integração do Oracle Database for Microsoft Entra ID (MS-EI)

A integração do MS-EI com a instância do Oracle Database exige que o banco de dados seja registrado no MS-EI para que o banco de dados possa solicitar a chave pública do MS-EI.

Para obter informações sobre como configurar o MS-EI, configurar o banco de dados e configurar o cliente do banco de dados, consulte:

Tópico principal: Autenticando e Autorizando Usuários do Microsoft Entra ID (MS-EI) para Bancos de Dados Oracle no Oracle Exadata Database Service on Dedicated Infrastructure

Pré-requisitos para Autenticação do Microsoft Entra ID (MS-EI)

Revise os pré-requisitos para integrar o Oracle Database ao MS-EI.

A integração do MS-EI com o Oracle Database no Oracle Exadata Database Service on Dedicated Infrastructure requer:

  1. O Oracle Database será a versão 19.18 ou mais recente.
  2. Conectividade com o banco de dados na porta TLS 2484. Não há suporte para conexões não TLS.
  3. Conectividade de rede de saída ao MS-EI para que o banco de dados possa solicitar a chave pública do MS-EI.
  4. O Oracle Database a ser registrado no MS-EI.
  5. Usuários e aplicativos que precisam solicitar um token MS-EI também devem ser capazes de ter conectividade de rede com o MS-EI. Talvez seja necessário configurar uma definição de proxy para a conexão.
  6. Para implantações do Oracle Exadata Database Service on Dedicated Infrastructure, as definições de Proxy HTTP em seu ambiente devem permitir que o banco de dados use o MS-EI.

    Essas definições são definidas pelo administrador da frota ao criar a infraestrutura do Oracle Exadata Database Service on Dedicated Infrastructure, conforme descrito em Para criar um recurso de infraestrutura do Exadata na Nuvem.

    Observação

    A configuração de rede, incluindo o Proxy HTTP, só poderá ser editada até que o Exadata Infrastructure esteja no estado Requer Ativação. Depois de ativado, você não poderá editar essas configurações.

    A configuração de um Proxy HTTP para uma Infraestrutura do Exadata já provisionada precisa de uma Solicitação de Serviço (SR) no My Oracle Support. Consulte Criar uma Solicitação de Serviço no My Oracle Support para obter detalhes.

Pré-requisitos de Rede para Autenticação do Microsoft Entra ID (MS-EI)

Antes de usar a autenticação do Azure AD em bancos de dados no Exadata Cloud Infrastructure, use o serviço Networking para adicionar um gateway de serviço, uma regra de roteamento e uma regra de segurança de saída à VCN (Rede Virtual na Nuvem) e às sub-redes nas quais seus recursos de banco de dados residem.

  1. Crie um gateway de serviço na VCN em que os recursos do banco de dados residem seguindo as instruções em Tarefa 1: Criar o gateway de serviço na documentação do OCI.
  2. Após a criação do gateway de serviço, adicione uma regra de roteamento e uma regra de segurança de saída a cada sub-rede (na VCN) na qual os recursos do banco de dados residem para que esses recursos possam usar o gateway para usar a autenticação do Azure AD:
    1. Vá para a página Detalhes da Sub-rede da sub-rede.
    2. Na guia Informações da Sub-rede, clique no nome da Tabela de Roteamento da sub-rede para exibir sua respectiva página Detalhes da Tabela de Roteamento.
    3. Na tabela de Regras de Roteamento existentes, verifique se já existe uma regra com as seguintes características:
      • Destino: 0.0.0.0/0
      • Tipo de Destino: Gateway NAT
      • Destino: O nome do gateway NAT que você acabou de criar na VCN

      Se essa regra não existir, clique em Adicionar Regras de Roteamento e adicione uma regra de roteamento com essas características.

    4. Retorne à página Detalhes da Sub-rede da sub-rede.
    5. Na tabela Listas de Segurança da sub-rede, clique no nome da lista de segurança da sub-rede para exibir a página Detalhes da Lista de Segurança.
    6. No menu lateral, em Recursos, clique em Regras de Saída.
    7. Na tabela de Regras de Saída existentes, verifique se já existe uma regra com as seguintes características:
      • Tipo de Destino: CIDR
      • Destino: 0.0.0.0/0
      • Protocolo IP: TCP
      • Faixa de Portas de Origem: 443
      • Faixa de Portas de Destino: Todas
    8. Se essa regra não existir, clique em Adicionar Regras de Saída e adicione uma regra de saída com essas características.

Configurar TLS para Usar Tokens do Microsoft Entra ID (MS-EI)

Ao enviar tokens MS-EI do cliente de banco de dados para o servidor de banco de dados, estabeleça uma conexão TLS.

A wallet de TLS com o certificado de banco de dados para a instância de serviço ExaDB-D deve ser armazenada sob o local WALLET_ROOT. Crie um diretório tls para que se pareça com: WALLET_ROOT/<PDB GUID>/tls.

Ao configurar o TLS entre o cliente de banco de dados e o servidor, há várias opções a serem consideradas.

  • Usando um certificado de servidor de banco de dados autoassinado em vez de um certificado de servidor de banco de dados assinado por uma autoridade de certificação comumente conhecida
  • TLS (TLS) unidirecional versus TLS mútuo ou bidirecional (mTLS)
  • Cliente com ou sem uma wallet

Certificado Autoassinado

O uso de um certificado autoassinado é uma prática comum para recursos de TI de uso interno, uma vez que você mesmo pode criá-los e é gratuito. O recurso (no nosso caso, o servidor de banco de dados) terá um certificado autoassinado para se autenticar no cliente de banco de dados. O certificado autoassinado e o certificado raiz serão armazenados na wallet do servidor de banco de dados. Para que o cliente de banco de dados possa reconhecer o certificado do servidor de banco de dados, também será necessária uma cópia do certificado raiz no cliente. Esse certificado raiz criado automaticamente pode ser armazenado em uma wallet no cliente ou instalado no armazenamento de certificados padrão do sistema cliente (somente Windows e Linux). Quando a sessão for estabelecida, o cliente de banco de dados verificará se o certificado enviado pelo servidor de banco de dados foi assinado pelo mesmo certificado raiz.

Uma Autoridade de Certificação Reconhecida

O uso de uma autoridade de certificação raiz comumente conhecida tem algumas vantagens, visto que o certificado raiz muito provavelmente já está no armazenamento de certificados padrão do sistema cliente. Não haverá etapa extra para o cliente armazenar o certificado raiz se ele for um certificado raiz comum. A desvantagem é que isso normalmente tem um custo associado.

TLS Unidirecional

Na sessão TLS padrão, somente o servidor fornece um certificado para o cliente autenticar-se. O cliente não precisa ter um certificado de cliente separado para autenticar-se no servidor (semelhante a como as sessões HTTPS são estabelecidas). Embora o banco de dados exija uma wallet para armazenar o certificado do servidor, a única coisa que o cliente precisa ter é o certificado raiz usado para assinar o certificado do servidor.

TLS Bidirecional (também chamado de TLS Mútuo, mTLS)

No mTLS, o cliente e o servidor têm certificados de identidade que são apresentados uns aos outros. Na maioria dos casos, o mesmo certificado raiz assinará esses dois certificados para que o mesmo certificado raiz possa ser usado com o servidor e o cliente de banco de dados para autenticar o outro certificado. O mTLS às vezes é usado para autenticar o usuário, visto que a identidade do usuário é autenticada pelo servidor de banco de dados por meio do certificado. Isso não é necessário para informar tokens do IAM, mas pode ser usado ao informá-los.

Cliente com uma Wallet

Uma wallet do cliente é obrigatória ao usar mTLS para armazenar o certificado do cliente. No entanto, o certificado raiz pode ser armazenado na mesma wallet ou no armazenamento de certificados padrão do sistema.

Um Cliente sem uma Wallet

Os clientes podem ser configurados sem uma wallet ao usar TLS sob estas condições: 1) O TLS unidirecional está sendo configurado onde o cliente não tem seu próprio certificado e 2) o certificado raiz que assinou o certificado do servidor de banco de dados está no armazenamento de certificados padrão do sistema. Muito provavelmente, o certificado raiz já estaria lá se o certificado do servidor fosse assinado por uma autoridade de certificação comum. Se for um certificado autoassinado, o certificado raiz precisará ser instalado no armazenamento de certificados padrão do sistema para evitar o uso de uma wallet do cliente.

Para obter detalhes sobre como configurar o TLS entre o cliente e o servidor de banco de dados, incluindo as opções descritas acima, consulte:

Se você optar por usar certificados autoassinados e para tarefas adicionais relacionadas à wallet, consulte: