Usar Autenticação do Azure Active Directory com o Base Database Service
Você pode configurar o Oracle AI Database no Base Database Service para usar a autenticação e autorização do Banco de Dados Ativo do Microsoft Azure a fim de permitir que os usuários de Azure AD acessem o banco de dados com as credenciais doAzure AD.
Sobre a Integração do Azure AD com o Base Database Service
Um Oracle AI Database em um banco de dados Base Service pode ser configurado para usuários que utilizam o Microsoft Azure Active Directory (Azure AD) se conectarem usando tokens do Azure OAuth2.
Para obter mais informações sobre autorização de usuários, arquitetura, mapeamentos de usuário, casos e processo de integração do Azure AD, consulte Autenticando e Autorizando Usuários do Microsoft Azure em Bancos de Dados do Oracle AI no Guia de Segurança do Oracle AI Database.
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 de 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.
- 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.
-
After creating the service gateway, add a route rule and an egress security rule to each subnet (in the VCN) where the database resources reside so that these resources can use the gateway to obtain a public key from your Azure AD instance to use Azure AD authentication:
- Vá para a página Detalhes de Sub-rede da sub-rede.
- Na guia Informações da Sub-rede, clique no nome da Tabela da Rota da sub-redes para exibir sua página Detalhes da Tabela de Roteamento.
-
Na tabela de Regras de Rota existentes, verifique se já existe uma regra com as seguintes características:
- Destino: 0.0.0.0/0
- Target Type: Gateway NAT
- Destino: O nome do gateway do serviço que você acaba de criar na VCN
Se essa regra não existir, selecione Adicionar Regras de Roteamento e adicione uma regra com essas características.
- Retorne à página Detalhes da Subrede da sub-rede.
- Na tabela Listas de Segurança da subrede, clique no nome da lista para exibir sua página Detalhes da Lista de Segurança.
- No menu lateral, em Recursos, selecione Regras de Saída.
-
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
- Intervalo de Portas de destino: Tudo
- Se essa regra não existir, selecione Adicionar Regras de Saída e adicione uma regra 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 internos de TI, pois você pode criá-los e ele é 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 certificado bem conhecida: Usar uma autoridade de certificado raiz comumente conhecida tem algumas vantagens em que o certificado raiz provavelmente já está armazenado no armazenamento de certificado 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 geralmente tem um custo associado a ele.
TLS unidirecional: Na sessão TLS padrão, somente o servidor fornece um certificado para o cliente se autenticar. 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 TLS Mútuo, mTLS): Em mTLS, tanto o cliente quanto o servidor têm certificados de identidade que são apresentados entre si. 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 cliente é obrigatória ao usar o mTLS para armazenar o certificado 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:
-
O TLS unidirecional está sendo configurado, no qual o cliente não tem seu próprio certificado e
-
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 servidor de banco de dados, incluindo as opções descritas anteriormente, consulte Configurando Autenticação da Segurança da Camada do Transporte.
Se você selecionar o uso de certificados autoassinados e para tarefas adicionais relacionadas à wallet, consulte o guia de referência da interface de linha do comando (CLI) 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 conclua os pré-requisitos na seção Pré-requisitos e, em seguida, siga as instruções na seção Configurando o Oracle AI Database para Integração com o Microsoft Azure AD do Guia de Segurança do Oracle AI Database.
Mapear Esquemas e Atribuições do Oracle AI 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 para mapear esquemas e funções do Oracle AI Database para os usuários Azure AD, consulte a seção Mapeando Esquemas e Atribuições do Oracle AI Database no Guia de Segurança do Oracle AI Database.
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 como configurar conexões de cliente do Azure AD, consulte a seção Configurando Conexões de Cliente do Azure AD com os Bancos de Dados Oracle AI no Guia de Segurança do Oracle AI Database.
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 Testing the Accessibility of the Azure Endpoint no Oracle AI 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 definindo rastreamento de cliente para autenticação do token, consulte Arquivos de Rastreamento para Diagnóstico e Solução de Problemas de Conexões de Cliente do Oracle Database com o Azure AD no Guia de Segurança do Oracle AI Database.