Autenticação Kerberos no Amazon RDS for Oracle com AWS Directory Service

Por Inoue, Technical Account Manager na AWS; Carlos Felicio, Senior Partner Technical Account Manager na AWS; Murillo Tavares, Senior Technical Account Manager na AWS e Fabio Agarie, Senior Partner Technical Account Manager na AWS.

Gerenciar credenciais de banco de dados em escala é um desafio recorrente para equipes de infraestrutura e segurança — especialmente quando o ambiente inclui múltiplas instâncias do Amazon Relational Database Service (Amazon RDS) for Oracle. À medida que o número de bancos de dados cresce, multiplicam-se as senhas locais e as planilhas de controle. Cada banco passa a ter seu próprio conjunto de usuários e senhas. Isso dificulta a aplicação consistente de políticas de rotação, expiração e desativação de acessos.

O AWS Directory Service for Microsoft Active Directory permite estender o seu Active Directory on-premises para a AWS e usá-lo como fonte única de identidade para serviços gerenciados.

Neste post, mostramos como integrar o Amazon RDS for Oracle ao AWS Directory Service usando autenticação Kerberos. Com essa configuração, o gerenciamento de identidades passa a ser feito no Active Directory.

Por que Kerberos com Amazon RDS for Oracle?

A autenticação tradicional de banco de dados associa um usuário e uma senha a cada instância:

Usuário → usuário/senha do banco → Oracle Database

(credenciais separadas para cada banco)

Com Kerberos, a identidade vem do Active Directory e o acesso ao banco passa a usar tickets:

Usuário → login no Active Directory → ticket Kerberos → Oracle Database

(uma única credencial para todos os recursos)

Alguns benefícios são:

• Gerenciamento centralizado de identidade: as credenciais dos usuários que acessam o banco de dados ficam centralizadas no Active Directory.
• Segurança aprimorada: elimina senhas de banco fixas em aplicações e scripts.
• Single Sign-On (SSO): o usuário se autentica uma vez e pode acessar múltiplos recursos.
• Auditoria simplificada: trilha de autenticação centralizada via AWS CloudTrail e auditoria nativa do Oracle.
  A camada de infraestrutura fica auditada via CloudTrail:

• • • Criação e modificação de instâncias — quem associou a instância ao domínio AD, quando, de qual IP;
    • Alterações de IAM Roles — quem modificou a role de integração com o Directory Service;
    • Chamadas ao Directory Service — autorização/desautorização de aplicações no AD.

  Cada evento registra a identidade (usuário/role IAM), data/hora, IP de origem e payload completo da requisição

Para auditoria no nível de banco de dados (quem logou via Kerberos, que SQL executou, tentativas de acesso falhadas), o Oracle oferece mecanismos nativos como Unified Audit e DBA_AUDIT_TRAIL — consulte a documentação Oracle de Unified Auditing para configuração detalhada.

Visão geral da solução

A arquitetura tem três componentes principais, todos dentro da sua Amazon VPC descritos na Figura 1:

Figura 1 – Arquitetura da solução: AWS Managed Microsoft AD, Amazon RDS for Oracle e cliente Kerberos dentro da Amazon VPC.

O fluxo de autenticação na Figura 1 segue o padrão Kerberos:

1. 1. O cliente executa kinit e o Active Directory devolve um TGT (Ticket Granting Ticket).
   2. O cliente solicita um service ticket para o serviço Oracle.
   3. O cliente conecta ao RDS apresentando o service ticket.
   4. O RDS valida o ticket com o Active Directory e estabelece a sessão.

Os três componentes envolvidos:

Pré-requisitos

• Conta AWS com permissões para criar diretórios no Directory Service e instâncias RDS.
• Permissão IAM para criar roles e policies.
• Cliente Oracle em Linux ou Windows, com utilitários Kerberos.
• Conectividade de rede do cliente até a VPC com as portas abertas:

Passo a passo

Passo 1 — Criar o AWS Managed Microsoft AD

No console do Directory Service, escolha Set up directory e selecione AWS Managed Microsoft AD (a única opção compatível com Kerberos no RDS — não use AD Connector nem Simple AD).

Defina o nome de domínio (por exemplo, corp.exemplo.com), a senha de administrador e a rede:

• Selecione a VPC onde o RDS também residirá (mesma VPC ou VPC com peering).
• Escolha duas sub-redes em AZs diferentes para alta disponibilidade.O provisionamento leva alguns minutos. Aguarde o status mudar para Active e anote o Directory ID (inicia com d-) e os IPs de DNS.

Passo 2 — (Opcional) Relação de confiança com AD on-premises

Se você já tem um Active Directory on-premises e quer que esses usuários acessem o RDS for Oracle, crie uma forest trust entre o AWS Managed Microsoft AD e o seu domínio local. Esse é o cenário em que a relação de confiança (forest trust) entre o AWS Managed Microsoft AD e o domínio local permite unificar a identidade. Pule este passo se for usar apenas o AD gerenciado na AWS.

Passo 3 — Configurar a permissão IAM

O RDS precisa de uma role para consultar o diretório, registrar service principals e gerar o keytab.

• Criação automática: ao criar a instância RDS pelo console (e com permissão iam:CreateRole), a AWS cria automaticamente a role rds-directoryservice-kerberos-access-role.
• Criação manual: crie uma role do tipo serviço para RDS e anexe a policy gerenciada AmazonRDSDirectoryServiceAccess.

Para reforçar a segurança, você pode restringir a trust policy com condições aws:SourceAccount e aws:SourceArn.

Passo 4 — Criar os usuários no Active Directory

Em uma máquina Windows ingressada no domínio, crie os usuários via Active Directory Users and Computers.

Anote o User Principal Name (UPN) no formato usuario@CORP.EXEMPLO.COM — ele será usado para mapear o usuário no Oracle.

Passo 5 — (Opcional) Habilitar tráfego entre VPCs

Se o diretório e o RDS estiverem em VPCs (ou contas) diferentes, crie um VPC peering, atualize as route tables dos dois lados e ajuste os security groups.

Passo 6 — Criar ou modificar a instância RDS for Oracle

Ao criar (ou modificar) a instância, em Database authentication selecione Password and Kerberos authentication e informe:

• Directory: o Directory ID do Passo 1 (d-123456abc...).
• IAM role: a rds-directoryservice-kerberos-access-role.

Quando o status voltar a Available e o Domain membership estiver Active, o RDS terá criado e gerenciado automaticamente no lado servidor. Nenhuma configuração manual é necessária na instância.

Passo 7 — Criar os logins Oracle autenticados externamente

Conecte-se como o usuário administrador principal (primary) da instância e crie usuários IDENTIFIED EXTERNALLY, com o nome e domínio em MAIÚSCULAS e igual ao UPN do Active Directory. Nesse exemplo concedemos privilégios de CREATE SESSION apenas para testar a integração.

CREATE USER "usuario@CORP.EXEMPLO.COM" IDENTIFIED EXTERNALLY;
GRANT CREATE SESSION TO "usuario@CORP.EXEMPLO.COM";

Passo 8 — Configurar o cliente Oracle

Para que o cliente Oracle solicite autenticação Kerberos ao conectar no RDS, é preciso configurar dois arquivos: o krb5.conf (configuração do Kerberos) e o sqlnet.ora (configuração de rede do Oracle).

8.1 — Arquivos de configuração

Este arquivo informa ao cliente onde encontrar o KDC (Key Distribution Center) do seu domínio Active Directory.

Exemplo de arquivo krb5.conf:

[libdefaults]
default_realm = CORP.EXEMPLO.COM
dns_lookup_realm = true
dns_lookup_kdc = true
forwardable = true

[realms]
CORP.EXEMPLO.COM = {
kdc = 10.99.1.10
kdc = 10.99.1.11
admin_server = 10.99.1.10
}

[domain_realm]
.corp.exemplo.com = CORP.EXEMPLO.COM
corp.exemplo.com = CORP.EXEMPLO.COM

Importante:
1/ O nome do realm deve estar em MAIÚSCULAS e corresponder exatamente ao nome do domínio do AWS Directory Service.

2/ O TNS_ADMIN diz ao Oracle client onde procurar os arquivos de configuração de rede:

– sqlnet.ora — configurações de autenticação (Kerberos, encryption, etc.)

– tnsnames.ora — aliases de conexão (host, port, service name)

Sem o export TNS_ADMIN, o Oracle client procura esses arquivos no path padrão ($ORACLE_HOME/network/admin), que pode não existir ou estar vazio na sua instânciaEC2 com Instant Client. Confira detalhes de como configurar seu cliente Instant Client em “Criar uma instância de banco de dados Oracle e conectar-se a ela”

No caso de Kerberos, o sqlnet.ora contém as configurações essenciais:

Exemplo de arquivo sqlnet.ora mínimo no Linux

SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5)
SQLNET.KERBEROS5_CONF=/etc/krb5.conf

Sem isso, o Oracle não sabe que deve usar Kerberos para autenticar — e o IDENTIFIED EXTERNALLY pode não funcionar.

Testando a integração

Obtenha o ticket e conecte sem senha:

kinit usuario@CORP.EXEMPLO.COM

klist # confirma o ticket válido

sqlplus /@oracle-kerberos-db.abc123.us-east-1.rds.amazonaws.com:1521/ORCL

Confirme que a sessão usa Kerberos:

SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD') FROM DUAL
-- Resultado Esperado: KERBEROS

SHOW USER;
-- Resultado Esperado: USER is “USUARIO@CORP.EXEMPLO.COM”

Então se o resultado for “KERBEROS” na primeira consulta acima e a conexão ocorrer com sucesso, a integração está funcionando.

Problemas comuns

Boas práticas de segurança

• Aplique o princípio do menor privilégio — evite conceder a role DBA diretamente; prefira grants individuais e alinhados à função do usuário DBA ou de aplicação.
• Habilite criptografia em trânsito e em repouso com AWS KMS no RDS.
• Ative CloudTrail, CloudWatch Logs e auditoria de CREATE SESSION no Oracle para rastrear autenticações.
• Revisar acessos periodicamente – Revogue usuários no Active Directory quando não fizerem mais parte da equipe.

Limpeza dos recursos

Para evitar custos, ao final dos testes: exclua a instância RDS, remova a relação de confiança (se criada), exclua o AWS Managed Microsoft AD e remova as configurações de peering/VPC e a role IAM, caso não sejam mais necessárias.

Conclusão

Neste post, integramos o Amazon RDS for Oracle ao AWS Directory Service usando autenticação Kerberos. Com isso, passamos a gerenciar usuários de banco de forma centralizada no Active Directory e a evitar senhas locais. Para ambientes híbridos, a relação de confiança com o AWS Managed Microsoft AD permite estender essa mesma experiência ao seu Active Directory on-premises.

Para saber mais, consulte:

• Amazon RDS for Oracle — Kerberos authentication: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/oracle-kerberos.html
• AWS Directory Service Admin Guide: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/
• Amazon RDS User Guide: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/

Autores

	Eduardo Inoue Technical Account Manager na AWS, apoio clientes na construção de ambientes resilientes, seguros e otimizados em nuvem. Desde 2011 trabalhando com tecnologia — de infraestrutura on-premises a arquiteturas cloud-native — e a curiosidade por aprender continua a mesma desde o primeiro dia. Meu foco atual: Segurança, FinOps e adoção de IA generativa no setor financeiro.
	Carlos Felicio é Senior Partner Technical Account Manager na AWS LATAM. Atua no mercado de tecnologia há 26 anos. Seu portfólio inclui inúmeras consolidações e migrações em ambientes híbridos com workloads Microsoft. Atualmente trabalha como Senior TAM, auxiliando
	Murillo Tavares é Senior Technical Account Manager na AWS. Fatecano e Paulistano, possui 15 anos de experiência em TI, dedicando sua carreira à operação e administração de sistemas de missão crítica no segmento enterprise. Faz parte da comunidade técnica de banco de dados na AWS.
	Fabio Agarie é Senior Partner Technical Account Manager na AWS auxiliando parceiros LATAM e seus clientes com performance de ambientes, arquitetura de dados e melhoria de custos. Atuando na área de tecnologia há 29 anos, é Pós-graduado em Databases, membro ativo da comunidade técnica de Databases e de Cloud Operations e contribuindo com conhecimento técnico e ministrando workshops em eventos.