Documentação do Oracle Cloud Infrastructure

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

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

Os usuários e aplicativos do Azure podem fazer login com as credenciais do Entra ID Single Sign On (SSO) para acessar o banco de dados. Isso é feito com um token de acesso Entra ID OAuth2 que o usuário ou aplicativo primeiro solicita do Entra ID. 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 autenticação multifator e sem senha.

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

  • Oracle Database local 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 as credenciais de Sign-on Único (SSO) do Entra ID para obter um token de acesso OAuth2 do Entra ID para enviar ao banco de dados.

O administrador do Entra ID cria e registra o Oracle Autonomous Database com o Entra ID. No 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 atribuições de aplicativo (aplicativo) 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 de 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, 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 Azure. Um usuário convidado do Azure (usuário não organizacional) ou um controlador de serviços do Entra ID (aplicativo) só pode ser mapeado para um esquema global de banco de dados por meio de uma atribuição de aplicativo do Entra ID. Uma atribuição global do 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.

As ferramentas do Oracle Autonomous Database, incluindo Oracle APEX, Database Actions, Oracle Graph Studio e Oracle Database API for 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 informar o token de acesso ao banco de dados para a instância do Oracle Autonomous Database. Você pode configurar ferramentas de banco de dados existentes, como SQL*Plus, para usar um token de ID da Entra em um local do arquivo. Nesses casos, os tokens do Entra ID podem ser recuperados usando ferramentas como o Microsoft PowerShell ou a CLI doAzure 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 como escopo o 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 de aplicativo às quais o principal do ID do Entra foi designado no registro do aplicativo do ID do Entra do banco de dados são incluídas como parte do token de acesso. O local de diretório do token do Entra ID deve ter permissão suficiente apenas para o usuário gravar o arquivo de token no local e o cliente do banco de dados para recuperar 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 Entra ID usando vários métodos para abrir uma janela de log-in do Azure para informar suas credenciais do Entra ID.

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

  • Usuário do Azure, que é usuário registrado na tenancy do Entra ID
  • Usuário hóspede, que está registrado como usuário convidado na tenancy do ID da Conta
  • 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 de Entra ID:

  • Fluxo interativo (também chamado de fluxo de código de autorização) usando a Chave de Prova para Troca de Código (PKCE), mais comumente usada para usuários humanos (não aplicativos) para autenticação no Entra ID em um ambiente cliente com um navegador
  • Credenciais do cliente, que são para aplicativos de banco de dados que conectam como eles mesmos (e não 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 nos quais uma autenticação de usuário do navegador pop-up seria difícil de incorporar. O ROPC precisa que o nome de usuário e a credencial de senha do Entra ID façam parte da chamada de solicitação de token.
Observação

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

Tópicos

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

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

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

O token de acesso do Entra ID será necessário para que você acesse o banco de dados no cliente do 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 cliente do 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 passar o token pela API cliente do banco de dados. Ferramentas de linha de comando, como o Microsoft PowerShell ou a interface de linha de comando do Azure, podem ser usadas para recuperar o token Entra ID se o aplicativo não puder obter diretamente o token.

O diagrama a seguir é um fluxograma 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 ID do Microsoft Entra para obter mais detalhes sobre cada fluxo suportado.

Descrição da azure-authentication.eps a seguir
Descrição da ilustração azur-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. O primeiro passo 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 do banco de dados solicita um código de autorização do ID do Entra.
  3. O Entra ID autentica o usuário do Azure e retorna o código de autorização.
  4. A ferramenta auxiliar ou o aplicativo usa o código de autorização com o Entra ID para trocá-lo pelo token OAuth2.
  5. O cliente do 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 para o 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 de banco de dados e o servidor de banco de dados devem ser registrados com o recurso registros de aplicativo 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. Também é necessário conceder permissão 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

Usuários do Microsoft Azure devem ser mapeados para um esquema Oracle Database e ter os privilégios necessários (através de atribuições) antes de poderem se autenticar para a instância do Oracle Database.

No Microsoft Azure, um administrador de 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 que são 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 sair da organização, o administrador do banco de dados deverá 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 globais e atribuições globais. Dessa forma, o acesso do usuário ao banco de dados é gerenciado pelos administradores de 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 Azure e um esquema Oracle Database. Nesse tipo de mapeamento, o esquema do banco de dado deve ser criado para o usuário do Azure. Os privilégios e atribuições do 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 estiver 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 forem alteradas. Por fim, 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 do aplicativo Entra ID e um esquema Oracle Database. Esse tipo de mapeamento, que é mais comum do que mapeamentos exclusivos, destina-se aos usuário do Azure que foram atribuídos diretamente à atribuição do aplicativo ou que é membro de um grupo de Entra ID atribuído à atribuição do aplicativo. A atribuição de aplicativo é mapeada para um esquema do Oracle Database (mapeamento de esquema compartilhado). O mapeamento do esquema compartilhado permite a vários usuários Azure compartilhar o mesmo esquema Oracle Database para que um novo esquema de banco de dado não seja necessário para ser criado sempre que um novo usuário se juntar à 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 das atribuições e privilégios do banco de dados que estão sendo concedidos diretamente ao esquema global mapeado, as atribuições e os privilégios adicionais podem ser concedidos por meio de atribuições globais mapeadas. Usuários diferentes do Azure mapeados para o mesmo esquema global compartilhado podem precisar de privilégios e atribuições diferentes. As atribuições de aplicativos do Azure podem ser mapeadas para atribuições globais do Oracle Database. Usuários do Azure que forem designados à atribuição do aplicativo ou forem membros de um grupo Entra ID atribuído à atribuição do aplicativo terã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 (usuário) global do Oracle Database.
  • Um usuário do Azure, grupo Entra ID ou aplicativo é atribuído a uma atribuição do aplicativo, que é então mapeada para um esquema global (usuário) do Oracle Database ou uma atribuição global.

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

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

  • Fluxo de código de autorização OAuth2: Este é o fluxo mais comum para usuários humanos. O cliente direciona o usuário do Azure para o Entra ID para obter o código de autorização. Este 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. É útil para software de teste que não pode funcionar com uma janela de autenticação pop-up. Ele é usado em ambientes não gráficos da interface 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 se conectem ao banco de dados. O aplicativo deve se registrar no registro do aplicativo Entra ID e precisa de um ID de cliente e senha de cliente. Essas credenciais de cliente devem ser usadas para obter o token de acesso ao banco de dados do ID do Entra quando o aplicativo se conecta ao banco de dados. O aplicativo pode passar o token pelo sistema de arquivos ou pela API do cliente do banco de dados.
  • Token em nome do (OBO): Um aplicativo do Azure solicita um token do OBO para um usuário que está conectado. O tokens OBO também será um token de acesso para o banco com identidade do usuário do Azure e atribuições de aplicativo designadas para o banco. Isso permite que o usuário do Azure faça login no banco de dados como o usuário e não o aplicativo. Somente um aplicativo pode solicitar um token OBO para seu usuário Azure e passá-lo para o cliente de banco de dados por meio da API.