Acesso a Bancos de Dados via Apono

Outro cenário fundamental para o Apono é o acesso a bancos de dados. Engenheiros precisam acessar bancos de produção para troubleshooting, análise de dados, migrações e investigação de incidentes e, assim como no caso do SSM, o modelo tradicional de permissões permanentes cria riscos significativos.

Antes de entender como o Apono gerencia esse acesso, é importante conhecer os dois modelos de autenticação que existem no Amazon RDS. Se você ainda não conhece a diferença entre autenticação IAM e usuários nativos, leia primeiro o artigo sobre Autenticação em Bancos de Dados RDS.

O Problema do Acesso Permanente a Bancos

Na maioria das organizações, o acesso a bancos de dados sofre dos mesmos problemas que o acesso a instâncias EC2:

• Credenciais compartilhadas: Vários engenheiros usam o mesmo usuário genérico (ex: dev_team) para acessar o banco de produção.
• Senhas que nunca expiram: Uma vez criado o usuário no banco, a senha raramente é rotacionada.
• Permissões excessivas: O usuário compartilhado tem acesso a todas as tabelas, mesmo quando o engenheiro precisa consultar apenas uma.
• Auditoria impossível: Quando todos usam o mesmo usuário, não há como saber quem executou qual query.

Como o Apono Resolve

O Apono suporta ambos os modelos de autenticação do RDS e se adapta ao que já existe na sua infraestrutura.

Cenário 1: IAM Auth no RDS

Quando o banco usa autenticação IAM, o Apono gerencia o acesso da mesma forma que gerencia SSM controlando policies IAM:

1. O engenheiro solicita acesso ao banco de dados.
2. Após aprovação, o connector do Apono adiciona a policy rds-db:connect ao usuário IAM, com o ARN específico do banco e do usuário de banco.
3. O engenheiro gera o token IAM e se conecta.
4. Quando o tempo expira, o connector remove a policy e o usuário não consegue mais gerar tokens válidos.

Nesse cenário, o connector não interage com o banco de dados. Ele atua exclusivamente na camada IAM da AWS, usando as permissões do seu próprio role (configurado no deploy) para adicionar e remover inline policies no usuário/role do engenheiro. O engenheiro gera o token IAM por conta própria (aws rds generate-db-auth-token) e se conecta diretamente ao banco.

Cenário 2: Usuário Nativo do Banco

Para bancos que usam autenticação nativa (senha) incluindo aqueles que não suportam IAM Auth (SQL Server, Oracle, MariaDB), o Apono atua de forma diferente. Ele gerencia credenciais diretamente dentro do banco de dados:

1. O engenheiro solicita acesso ao banco de dados.
2. Após aprovação, o connector do Apono se conecta ao banco usando credenciais administrativas (ex: usuário master do RDS) e cria um usuário temporário com as permissões definidas no Access Flow.
3. O Apono entrega as credenciais temporárias ao engenheiro.
4. Quando o tempo expira, o connector se conecta novamente ao banco e remove o acesso completamente.

Nesse cenário, o connector interage diretamente com o banco de dados. Ele executa comandos SQL para gerenciar o ciclo de vida do usuário temporário:

-- Na concessão de acesso, o connector executa automaticamente:
CREATE USER temp_joao_a1b2c3 WITH PASSWORD 'senha-gerada-automaticamente';
GRANT SELECT ON schema_app.tabela_clientes TO temp_joao_a1b2c3;
GRANT SELECT ON schema_app.tabela_pedidos TO temp_joao_a1b2c3;

-- Na revogação (quando o timer expira):
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA schema_app FROM temp_joao_a1b2c3;
DROP USER temp_joao_a1b2c3;

Para que o connector consiga criar e remover usuários no banco, ele precisa de credenciais administrativas do banco, geralmente um usuário master ou um usuário com permissão de CREATE USER e GRANT. Essas credenciais são configuradas uma única vez na integração do Apono com o banco de dados e ficam armazenadas no connector — nunca são enviadas para o Apono Cloud.

Comparação dos Cenários

Aspecto	IAM Auth	Usuário Nativo
O que o Apono gerencia	Policy IAM do usuário	Usuário/credencial dentro do banco
Tipo de credencial entregue	Nenhuma (usuário gera token IAM)	Usuário e senha temporários
Bancos suportados	PostgreSQL e MySQL (RDS/Aurora)	Qualquer banco suportado pelo Apono
Revogação	Remove policy IAM	DROP USER no banco
Requisito no connector	Permissões IAM	Credenciais admin do banco

O Que Muda na Prática

Independente do modelo de autenticação, o resultado é o mesmo:

• Cada engenheiro tem suas próprias credenciais — fim das senhas compartilhadas.
• Permissões granulares — o Access Flow define exatamente quais tabelas e operações (SELECT, INSERT, etc.) o engenheiro pode acessar.
• Duração definida — o acesso expira automaticamente, sem depender de ação manual.
• Auditoria individual — o Apono registra quem solicitou, para qual banco, com quais permissões e por quanto tempo. Combinado com os logs do banco, é possível rastrear cada query até o engenheiro que a executou.

O Apono não reinventa a roda, ele automatiza o ciclo de vida das credenciais que já existem. Para IAM Auth, gerencia policies IAM. Para autenticação nativa, cria e remove usuários diretamente no banco. Em ambos os casos, o resultado é o mesmo: acesso temporário, granular, aprovado e auditado.

Connector e Conectividade

O connector é o componente que executa as ações descritas nos cenários acima. Para entender sua arquitetura completa (como é deployado, como se comunica com o Apono Cloud e como funciona o modelo de segurança), veja os artigos sobre arquitetura e deploy.

É o mesmo connector que gerencia tanto o acesso IAM (como vimos no artigo de SSM) quanto o acesso direto a bancos de dados. Não existem connectors separados para AWS e para bancos. Um único agente, deployado uma vez na infraestrutura, executa diferentes tipos de ações dependendo da integração configurada no Apono Cloud:

• Integração AWS: o connector usa as permissões IAM do seu próprio role para manipular policies no IAM (adicionar/remover ssm:StartSession, rds-db:connect, etc.).
• Integração de banco de dados: o mesmo connector usa credenciais administrativas do banco (configuradas na integração) para executar CREATE USER, GRANT, DROP USER diretamente no banco.

A diferença não está no connector em si, mas na integração. Cada integração informa ao connector como interagir com aquele tipo de recurso, quais credenciais usar e quais ações executar.

Requisitos de Rede do Connector

Essa distinção entre integrações tem implicação direta na rede. O connector precisa de conectividade com dois destinos diferentes:

1. Apono Cloud (outbound HTTPS) — para o polling de ações pendentes e reporte de status. Isso exige acesso à internet (via NAT Gateway) ou VPC Endpoints para os serviços necessários.
2. Os bancos de dados gerenciados — apenas para integrações de banco com autenticação nativa. O connector precisa alcançar o banco na porta de conexão (ex: 5432 para PostgreSQL, 3306 para MySQL).

Para a integração AWS (IAM Auth), o connector só precisa alcançar as APIs da AWS (IAM, STS). Ele não precisa ter rota de rede para o banco de dados, porque não interage com ele diretamente.

Para a integração de banco de dados (usuário nativo), o connector precisa estar em uma rede que alcance o banco. Se o connector está em uma VPC e o banco em outra, é necessário VPC Peering, Transit Gateway ou que o connector seja deployado na mesma VPC do banco. Sem essa conectividade, o connector não consegue executar os comandos SQL de criação e remoção de usuários.

Na prática, o posicionamento do connector na rede é uma decisão arquitetural importante. Em organizações com múltiplas VPCs e contas AWS, é comum deployar o connector em uma VPC com conectividade ampla (via Transit Gateway, por exemplo) ou na mesma VPC dos bancos que ele precisa gerenciar.

Se o connector existente não consegue alcançar um determinado banco de dados, é possível deployar um segundo connector em outra VPC ou conta. O Apono suporta múltiplos connectors simultaneamente e cada integração é associada a um connector específico. Por exemplo, uma organização pode ter um connector na conta de gerenciamento (para integrações AWS/IAM) e outro na conta de produção (para integrações de banco de dados que exigem acesso direto). Cada connector opera de forma independente, fazendo polling ao Apono Cloud e executando apenas as ações das integrações vinculadas a ele.

Connector Não É Proxy

É importante entender que o connector não é um proxy de conexão. Ele não intermedia o tráfego entre o engenheiro e o banco de dados. Sua única função é gerenciar credenciais: adicionar policies IAM, criar usuários no banco, conceder permissões e revogar acessos.

A conectividade do engenheiro com o banco de dados é uma responsabilidade completamente separada que o Apono não resolve. Se o banco está em uma subnet privada sem acesso externo, o engenheiro precisa ter uma rota de rede até ele por outros meios, como VPN, Direct Connect, bastion host ou SSM port forwarding. O Apono garante que o engenheiro terá credenciais válidas quando chegar ao banco, mas como ele chega ao banco é um problema de rede que precisa ser resolvido independentemente.

São dois problemas de conectividade distintos: o connector precisa alcançar o banco para gerenciar usuários, e o engenheiro precisa alcançar o banco para usá-lo. O Apono resolve o primeiro, mas não o segundo.

O connector é stateless e faz polling periódico ao Apono Cloud para verificar se há ações pendentes (concessões ou revogações). Toda a lógica de decisão (quem pode acessar o quê, por quanto tempo, com qual aprovação) fica no control plane do Apono. O connector apenas executa o que recebe.