Usar Autenticação do Azure Active Directory com o Base Database Service

Você pode configurar o Oracle Database no Base Database Service para usar a autenticação e a autorização do Microsoft Azure Active Database, a fim de permitir que os usuários do Azure AD acessem o banco de dados com credenciais do Azure AD.

Tópicos Relacionados

Sobre a Integração do Azure AD com o Base Database Service

Um Oracle Database em uma instância do Base Database Service pode ser configurado para que usuários do Azure AD (Microsoft Azure Active Directory) estabeleçam conexão usando tokens de acesso do Azure OAuth2.

Para obter mais informações sobre a autorização de usuários do Azure AD, arquitetura, mapeamentos de usuários, casos de uso e o processo de integração, consulte a seção Introduction to Authorizing Microsoft Azure AD Users for an Oracle Database no Oracle Database Security Guide.

Pré-requisitos

Os pré-requisitos a seguir são necessários para a autenticação do Azure AD no Base Database Service.

Cada um deles é descrito em detalhes nos tópicos a seguir.

Definições da Rede

Antes de usar a autenticação do Azure AD nos bancos de dados, você deve usar 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 (Virtual Cloud Network) e às sub-redes nas quais seus recursos de banco de dados residem. Execute as etapas a seguir para configurar a conectividade de saída com o Azure AD usando um gateway NAT.

  1. Crie um gateway NAT na VCN em que seus recursos de banco de dados residem seguindo as instruções em Criar o gateway de serviço.
  2. Após criar o gateway de serviço, adicione uma regra de roteamento e uma regra de segurança de saída a cada sub-rede (na VCN) em que os recursos do banco de dados residam para que esses recursos possam usar o gateway para obter uma chave pública da sua instância do Azure AD 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 de serviço 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.

Configuração de TLS

Ao enviar tokens do Azure AD do cliente de banco de dados para o servidor de banco de dados, uma conexão TLS deve ser estabelecida. A wallet de TLS com o certificado de banco de dados para a instância do Base Database Service deve ser armazenada no 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 enfrentados internamente, pois você pode criá-los por conta própria 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 conhecida: O uso de uma autoridade de certificação raiz comumente conhecida tem algumas vantagens, uma vez que o certificado raiz provavelmente já está armazenado 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 ao cliente para 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 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 transmitir tokens do Azure AD, mas pode ser usado ao transmitir tokens do Azure AD.

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, no qual o cliente não tem seu próprio certificado e
  2. o certificado raiz que assinou o certificado do servidor de banco de dados é armazenado 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 do banco de dados e o servidor do banco de dados, incluindo as opções descritas acima, consulte Configurando a Autenticação de Segurança da Camada de Transporte.

Se você optar por usar certificados autoassinados e tarefas adicionais relacionadas à wallet, consulte o guia de referência da CLI (interface de linha de comando) orapki no Database Security Guide. Consulte Gerenciando Elementos de PKI (Infraestrutura de Chave Pública).

Configurar Base Database Service para Integração com o Azure AD

A integração do Base Database Service com o Azure AD requer que o banco de dados seja registrado no Azure AD para que o banco de dados possa solicitar a chave pública do Azure AD.

Para configurar o Base Database Service para integração com o Azure AD, primeiro você deve concluir os pré-requisitos na seção Pré-requisitos e depois seguir as instruções na seção Configurando o Oracle Database para Integração do Microsoft Azure AD do Oracle Database Security Guide.

Mapear Esquemas e Atribuições do Oracle Database

Os usuários do Azure AD serão mapeados para um esquema de banco de dados e, opcionalmente, para uma ou mais atribuições de banco de dados.

Para obter mais informações sobre as opções de mapeamento de esquemas e atribuições do Oracle Database para usuários do Azure AD, consulte a seção Mapping Oracle Database Schemas and Roles no Oracle Database Security Guide.

Configurar Conexões de Cliente para ADs do Azure

Há várias maneiras de configurar um cliente para estabelecer conexão com uma instância do Base Database Service usando tokens do Azure AD.

Para obter mais informações sobre a configuração de conexões clientes do Azure AD, consulte Configuring Azure AD Client Connections to the Oracle Database no Oracle Database Security Guide.

Testando a Acessibilidade do Ponto Final do Azure

Você pode garantir que sua instância do Base Database possa acessar o ponto final do Azure AD executando um teste de conexão.

Para obter mais informações sobre como testar a conexão, consulte a seção Testando a Acessibilidade do Ponto Final do Azure no Oracle Database Security Guide.

Arquivos de Rastreamento Usados para Diagnóstico e Solução de Problemas de Conexões

Você pode usar arquivos de rastreamento para diagnosticar e solucionar problemas de conexões do cliente do Base Database Service com conexões do Azure AD.

Para obter mais informações sobre arquivos de rastreamento e definir o rastreamento do cliente para autenticação de token, consulte a seção Trace Files for Troubleshooting Oracle Database Client Connections with Azure AD no Oracle Database Security Guide.