Documentação do Oracle Cloud Infrastructure

Sobre a Integração do Oracle Autonomous Database com o Microsoft Entra ID

O Oracle Autonomous Database e o Microsoft Entra ID podem ser configurados para permitir que usuários e aplicativos se conectem ao banco de dados usando suas credenciais do Entra ID.

Os usuários e aplicativos do Azure podem fazer log-in com credenciais de Sign-on Único (SSO) Entra ID para acessar o banco de dados. Isso é feito com um token de acesso Entra ID OAuth2 que o usuário ou o aplicativo solicita primeiro do ID Entra. Esse token de acesso OAuth2 contém as informações de identidade do usuário e acesso ao banco de dados e é enviado ao banco de dados. Consulte o artigo da Microsoft Opções de autenticação sem senha para o Azure Active Directory para obter informações sobre como configurar a autenticação multifator e sem senha.

Você pode executar essa integração nos seguintes ambientes do Oracle Database:

  • Oracle Database on-premises versão 19.18 e posterior, excluindo 21c
  • Todas as plataformas de servidor do Oracle Database: Linux, Windows, AIX, Solaris e HPUX
  • Oracle Autonomous Database sem Servidor
  • Oracle Autonomous Database na Infraestrutura Dedicada do Exadata
  • Oracle Autonomous Database on Exadata Cloud@Customer
  • Oracle Exadata Database Service on Dedicated Infrastructure
  • Oracle Exadata Database Service on Cloud@Customer
  • Oracle Base Database Service

As instruções para configurar o Entra ID usam o termo "Oracle Database" para abranger esses ambientes.

Esse tipo de integração permite que o usuário do Azure acesse uma instância do Oracle Autonomous Database. Os usuários e aplicativos do Azure podem fazer log-in com credenciais de Sign-on Único (SSO) do Entra ID para obter um token de acesso OAuth2 do Entra ID a ser enviado ao banco de dados.

O administrador do Entra ID cria e registra o Oracle Autonomous Database no Entra ID. Dentro do Entra ID, isso é chamado de registro de aplicativo, que é a abreviação de registro de aplicativo. Esta é a informação digital que o Entra ID deve saber sobre o software que está usando o Entra ID. O administrador do Entra ID também cria funções de aplicativo (app) para o registro de aplicativo de banco de dados no Entra ID. As atribuições de aplicativo conectam usuários, grupos e aplicativos do Azure a esquemas e atribuições de banco de dados. O administrador do Entra ID designa usuários, grupos ou aplicativos do Azure às atribuições do aplicativo. Essas atribuições de aplicativo são mapeadas para um esquema global de banco de dados ou uma atribuição global ou para um esquema e uma atribuição. Um usuário, grupo ou aplicativo do Azure designado a uma atribuição de aplicativo será mapeado para um esquema global de banco de dados, uma atribuição global ou para um esquema e uma atribuição. Um esquema global Oracle também pode ser mapeado exclusivamente para um usuário do Azure. Um usuário convidado do Azure (usuário não organizacional) ou um controlador de serviço Entra ID (aplicativo) só podem ser mapeados para um esquema global de banco de dados por meio de uma atribuição de aplicativo Entra ID. Uma atribuição global Oracle só pode ser mapeada de uma atribuição de aplicativo do Azure e não pode ser mapeada de um usuário do Azure.

Ferramentas do Oracle Autonomous Database, incluindo Oracle APEX, Database Actions, Oracle Graph Studio e Oracle Database API para MongoDB, não são compatíveis com o uso de tokens Entra ID para conexão com o banco de dados.

Ferramentas e aplicativos que são atualizados para suportar tokens Entra ID podem autenticar usuários diretamente com o Entra ID e transmitir o token de acesso do banco de dados à instância do Oracle Autonomous Database. Você pode configurar ferramentas de banco de dados existentes, como o SQL*Plus, para usar um token Entra ID de um local de arquivo. Nesses casos, os tokens do Entra ID podem ser recuperados usando ferramentas como Microsoft PowerShell ou CLI do Azure e colocados em um local de arquivo. Um token de acesso ao banco de dados Entra ID OAuth2 é emitido com um tempo 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, o que significa que há informações no token sobre o banco de dados em que o token será usado. As atribuições do aplicativo às quais o principal do ID Entra foi designado no registro do aplicativo do ID Entra do banco de dados são incluídas como parte do token de acesso. O local do diretório do token Entra ID 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). Como o token permite o acesso ao banco de dados, ele deve ser protegido dentro do sistema de arquivos.

Os usuários do Azure podem solicitar um token do ID do Entra usando vários métodos para abrir uma janela de login do Azure para informar suas credenciais do ID do Entra.

O Oracle Autonomous Database aceita tokens que representam os seguintes controladores Entra ID:

  • Usuário do Azure, que é usuário registrado na tenancy Entra ID
  • Usuário convidado, que é registrado como usuário convidado na tenancy do ID Entra
  • 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)

O Oracle Autonomous Database suporta os seguintes fluxos de autenticação Entra ID:

  • Fluxo interativo (também chamado de fluxo de código de autorização) usando Chave de Prova para Intercâmbio de Código (PKCE), mais comumente usado para usuários humanos (não aplicativos) para autenticar o Entra ID em um ambiente cliente com um navegador
  • Credenciais do cliente, que são para aplicativos de banco de dados 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
  • Credencial de senha do proprietário do recurso (ROPC), que não é recomendada para uso em produção, mas pode ser usada em ambientes de teste em que uma autenticação de usuário do navegador pop-up seria difícil de incorporar. O ROPC precisa que o nome de usuário Entra ID e a credencial de senha façam parte da chamada de solicitação de token.
Observação

A integração DBaaS com o Microsoft Entra ID não suporta usuários com privilégios administrativos (SYSDBA, SYSOPER, SYSBACKUP, SYSDG, SYSKM e SYSRAC).

Tópicos

Tópico principal: Usar o Microsoft Entra ID com o Autonomous Database

Arquitetura da Integração do Oracle Database com o Microsoft Entra ID

Os tokens de acesso do Microsoft Azure Active Directory seguem o padrão OAuth 2.0 com extensões.

O token de acesso Entra ID será necessário antes de você acessar o banco de dados pelo cliente de banco de dados (por exemplo, com SQLPlus ou SQLcl). Os clientes Oracle (por exemplo, OCI, JDBC e ODP) podem ser configurados para selecionar um token Entra ID de um local de arquivo ou o token pode ser passado para o cliente por meio da API do cliente de banco de dados. Um usuário do Azure pode usar um script (exemplos disponíveis na Microsoft) para recuperar um token e colocá-lo em um local de arquivo para o cliente de banco de dados recuperar. Os aplicativos podem usar o SDK do Azure para obter um token de acesso e transmitir o token por meio da API cliente do banco de dados. Ferramentas de linha de comando, como Microsoft PowerShell ou a interface de linha de comando do Azure, poderão ser usadas para recuperar o token do Entra ID se o aplicativo não puder obter diretamente o token.

O diagrama a seguir é um diagrama de fluxo generalizado para o padrão OAuth 2.0, usando o token OAuth2. Consulte Suporte ao fluxo de autenticação no MSAL na documentação do Microsoft Entra ID para obter mais detalhes sobre cada fluxo suportado.

A seguir, descrição de azure-authentication.eps
Descrição da ilustração azure-authentication.eps

O fluxo do código de autorização é um padrão OAuth2 e é descrito em detalhes como parte dos padrões. Há duas etapas no fluxo. A primeira etapa autentica o usuário e recupera o código de autorização. A segunda etapa usa o código de autorização para obter o token de acesso ao banco de dados.

  1. O usuário do Azure solicita acesso ao recurso, a instância do Oracle Database.
  2. O cliente ou aplicativo de banco de dados solicita um código de autorização do Entra ID.
  3. O Entra ID autentica o usuário do Azure e retorna o código de autorização.
  4. A ferramenta ou o aplicativo auxiliar usa o código de autorização com o ID Entra para trocá-lo pelo token OAuth2.
  5. O cliente de banco de dados envia o token de acesso OAuth2 para o banco de dados Oracle. O token inclui as atribuições do aplicativo de banco de dados às quais o usuário foi designado no registro do aplicativo Entra ID do banco de dados.
  6. A instância do Oracle Database usa a chave pública Entra ID para verificar se o token de acesso foi criado pelo Entra ID.

O cliente e o servidor de banco de dados devem ser registrados com o recurso registros de aplicativos na seção do Azure Active Directory do portal do Azure. O cliente do banco de dados deve ser registrado no registro do aplicativo Entra ID. A permissão também deve ser concedida para permitir que o cliente do banco de dados obtenha um token de acesso para o banco de dados.

Mapeamento de Usuários do Azure para um Esquema e Atribuições do Oracle Database

Os usuários do Microsoft Azure devem ser mapeados para um esquema do Oracle Database e ter os privilégios necessários (por meio de atribuições) para que possam se autenticar na instância do Oracle Database.

No Microsoft Azure, um administrador do Entra ID pode designar usuários, grupos e aplicativos às atribuições de aplicativo de banco de dados.

O mapeamento exclusivo de um usuário Entra ID para um esquema de banco de dados requer que o administrador do banco de dados crie e gerencie um esquema de banco de dados para o ciclo de vida do usuário (junção, movimentação, saída). O administrador do banco de dados deve criar o esquema quando o usuário ingressar na organização. O administrador do banco de dados também deve modificar os privilégios e as atribuições concedidos ao esquema do banco de dados para alinhá-los às tarefas às quais o usuário do Azure está designado. Quando o usuário do Azure sai da organização, o administrador do banco de dados deve eliminar o esquema do banco de dados para que uma conta não utilizada não seja deixada no banco de dados. O uso das atribuições de aplicativo de banco de dados permite que o administrador do Entra ID controle o acesso e as atribuições designando usuários a atribuições de aplicativo que são mapeadas para esquemas e atribuições globais. Dessa forma, o acesso do usuário ao banco de dados é gerenciado pelos administradores do Entra ID e os administradores de banco de dados não precisam criar, gerenciar e eliminar esquemas para cada usuário.

Um usuário do Azure pode ser mapeado para um esquema de banco de dados (usuário) exclusivamente ou por meio de uma atribuição de aplicativo.

  • Criando um mapeamento exclusivo entre um usuário do Azure e um esquema do Oracle Database. Nesse tipo de mapeamento, o esquema de banco de dados deve ser criado para o usuário do Azure. Os privilégios e atribuições de banco de dados necessários ao usuário do Azure devem ser concedidos ao esquema do banco de dados. O esquema do banco de dados não só deve ser criado quando o usuário do Azure está autorizado para o banco de dados, mas os privilégios e atribuições concedidos devem ser modificados à medida que as atribuições e tarefas do Entra ID são alteradas. Finalmente, o esquema do banco de dados deve ser eliminado quando o usuário do Azure sair da organização.
  • Criando um mapeamento compartilhado entre uma atribuição de aplicativo Entra ID e um esquema do Oracle Database. Esse tipo de mapeamento, que é mais comum do que mapeamentos exclusivos, é para usuários do Azure que receberam diretamente a atribuição de aplicativo ou que são membros de um grupo Entra ID que recebeu a atribuição de aplicativo. A atribuição de aplicativo é mapeada para um esquema do Oracle Database (mapeamento de esquema compartilhado). O mapeamento de esquema compartilhado permite que vários usuários do Azure compartilhem o mesmo esquema do Oracle Database para que um novo esquema de banco de dados não precise ser criado toda vez que um novo usuário entrar na organização. Essa eficiência operacional permite que os administradores de banco de dados se concentrem na manutenção, no desempenho e nas tarefas de ajuste do aplicativo de banco de dados, em vez de configurar novos usuários, atualizar privilégios e atribuições e remover contas.

Além de atribuições e privilégios de banco de dados que estão sendo concedidos diretamente ao esquema global mapeado, atribuições e privilégios adicionais podem ser concedidos por meio de atribuições globais mapeadas. Diferentes usuários do Azure mapeados para o mesmo esquema global compartilhado podem precisar de outros privilégios e atribuições. As atribuições de aplicativos do Azure podem ser mapeadas para atribuições globais do Oracle Database. Os usuários do Azure que recebem a atribuição de aplicativo ou que são membros de um grupo Entra ID que recebe a atribuição de aplicativo receberão a atribuição global do Oracle Database quando acessarem o banco de dados.

O diagrama a seguir ilustra os diferentes tipos de atribuições e mapeamentos disponíveis.

Veja a seguir a descrição da ilustração azure_mappings.eps
Descrição da ilustração azure_mappings.eps

Estes são os mapeamentos:

  • Um usuário do Azure pode ser mapeado diretamente para um esquema global (usador) do Oracle Database.
  • Um usuário do Azure, um grupo Entra ID ou um aplicativo recebe uma atribuição de aplicativo, que então é mapeada para um esquema global (usuário) ou para uma atribuição global do Oracle Database.

Casos de Uso para Conexão com um Oracle Database Usando o Entra ID

O Oracle Database suporta vários casos de uso para conexão com o banco de dados.

  • OAuth2 fluxo do código de autorização: Este é o fluxo mais comum para usuários humanos. O cliente direciona o usuário do Azure para o ID Entra para obter o código de autorização. Esse código é usado para obter o token de acesso ao banco de dados. Consulte o artigo do Microsoft Azure Plataforma de identidade da Microsoft e fluxo de código de autorização OAuth 2.0.
  • Credenciais de senha do proprietário do recurso (ROPC): Esse fluxo não é recomendado para servidores de produção. Ele é útil para softwares de teste que não podem funcionar com uma janela de autenticação pop-up. Ele é usado em ambientes de interface não gráfica do usuário quando uma janela pop-up não pode ser usada para autenticar um usuário.
  • Credenciais do cliente: Esse fluxo é usado para que os aplicativos estabeleçam conexão com o banco de dados. O aplicativo deve se registrar com o registro do aplicativo Entra ID e precisa de um ID de cliente e senha de cliente. Essas credenciais do cliente devem ser usadas para obter o token de acesso do banco de dados do Entra ID quando o aplicativo se conecta ao banco de dados. O aplicativo pode passar o token pelo sistema de arquivos ou pela API cliente do banco de dados.
  • Em Nome do token (OBO): Um aplicativo Azure solicita um token OBO para um usuário conectado. O token OBO também será um token de acesso para o banco de dados com a identidade de usuário do Azure e atribuições designadas de aplicativo para o banco de dados. Isso permite que o usuário do Azure faça log-in no banco de dados como usuário e não como aplicativo. Somente um aplicativo pode solicitar um token OBO para seu usuário do Azure e transmiti-lo ao cliente de banco de dados por meio da API.