Como as Permissões Funcionam por Dentro

Vimos que o Apono adiciona e remove permissões automaticamente, mas uma dúvida comum é: o que acontece quando um engenheiro faz várias solicitações de acesso a recursos diferentes? O Apono cria uma credencial nova para cada solicitação? Existe uma role diferente para cada pedido?

A resposta é não, e entender como o Apono gerencia isso internamente é importante para não criar expectativas erradas sobre o modelo de segurança.

A Role é Única, as Permissões São Dinâmicas

Quando o Apono é integrado com uma conta AWS, ele não cria uma role IAM nova para cada solicitação de acesso. Em vez disso, ele trabalha com um PermissionSet único (ou uma role IAM única) por usuário em cada conta AWS.

O que muda a cada solicitação são as permissões atribuídas a essa role. Cada pedido de acesso resulta na adição de uma policy inline específica para o recurso solicitado. Quando o acesso expira, apenas aquela policy inline é removida — as outras continuam ativas até seus próprios timers expirarem.

Na prática, isso significa que:

• Às 10h, o engenheiro solicita acesso à EC2 i-0abc123 por 4 horas. O Apono adiciona uma policy inline de ssm:StartSession para essa instância.
• Às 11h30, ele solicita acesso à EC2 i-0def456 por 4 horas. O Apono adiciona outra policy inline na mesma role.
• Às 12h, ele solicita acesso ao banco de produção por 1 hora (via IAM Auth). Mais uma policy inline, dessa vez com rds-db:connect.
• Às 13h, a policy do banco expira e é removida. As outras duas continuam ativas.
• Às 14h, a policy da primeira EC2 expira e é removida. A segunda continua.
• Às 15h30, a última policy expira. A role do engenheiro fica sem permissões adicionais.

Cada solicitação tem seu próprio ciclo de vida: aprovação, concessão, timer e revogação são independentes. Mas todas operam sobre a mesma identidade IAM.

O Apono é uma ferramenta voltada para organizações com um volume significativo de usuários e recursos — seu custo se justifica em empresas onde o controle manual de acessos já se tornou inviável. O Apono funciona tanto com IAM tradicional (usuários e roles IAM em uma conta única) quanto com AWS IAM Identity Center em ambientes multi-conta. Em cenários com IAM tradicional, o connector manipula policies inline diretamente nos usuários ou roles IAM. Com o Identity Center, ele trabalha com PermissionSets. Ambos os modelos seguem o mesmo princípio descrito neste artigo: uma identidade por usuário com permissões dinâmicas. Porém, para organizações com múltiplas contas AWS, o Identity Center é fortemente recomendado como base de identidade antes de adotar o Apono.

Por Que Isso Importa

Entender esse modelo evita três equívocos comuns:

1. "Cada pedido cria uma credencial diferente"

Não. O engenheiro continua usando a mesma role IAM (ou PermissionSet no caso de AWS IAM Identity Center). O que muda são as policies anexadas a essa role. Na prática, o engenheiro não precisa trocar de credencial, refazer login ou mudar de perfil AWS a cada solicitação. Ele simplesmente ganha (e perde) permissões de forma transparente.

2. "Se eu tenho dois acessos ativos, um pode interferir no outro"

Não. As policies são independentes e isoladas por recurso. A revogação de uma solicitação remove apenas a policy daquele pedido específico. Se o engenheiro tem acesso simultâneo a três instâncias EC2, a expiração do acesso a uma delas não afeta as outras duas.

3. "A role acumula permissões para sempre"

Depende. Cada policy está vinculada a um Access Flow, e é o Access Flow que define o tempo de expiração. Na maioria dos casos, o timer expira e o connector remove a policy automaticamente. Porém, um Access Flow pode ser configurado com tempo indeterminado, ou seja, uma vez concedido, o acesso permanece ativo até que seja revogado manualmente por um administrador. Nesse cenário, sim, a permissão se acumula na role enquanto ninguém a revogar. Vamos detalhar as configurações de expiração e revogação quando falarmos sobre Access Flows.

E No Caso de Bancos de Dados?

Para bancos com autenticação IAM (PostgreSQL e MySQL no RDS/Aurora), o modelo é idêntico ao descrito acima: a policy rds-db:connect é adicionada e removida da mesma role IAM do usuário.

Para bancos com autenticação nativa (usuário e senha), o princípio de identidade única também se aplica. Na primeira solicitação de acesso a uma instância de banco de dados, o Apono cria um usuário na instância cujo nome é baseado no email do engenheiro no Apono, com uma senha gerada automaticamente. Nas solicitações seguintes à mesma instância, o usuário já existe — o Apono apenas adiciona ou remove grants conforme o que foi solicitado.

Como uma instância RDS pode hospedar vários bancos de dados, o engenheiro pode solicitar acesso a bancos diferentes na mesma instância em momentos diferentes. Cada solicitação adiciona grants específicos no mesmo usuário, e cada uma tem sua própria expiração:

• Às 10h, o engenheiro solicita acesso ao banco clientes. O connector cria o usuário (se ainda não existe) e adiciona GRANT SELECT nas tabelas do banco clientes.
• Às 11h, ele solicita acesso ao banco pedidos na mesma instância. O connector adiciona GRANT SELECT nas tabelas do banco pedidos no mesmo usuário, com a mesma senha.
• Às 11h, o acesso ao banco clientes expira. O connector revoga apenas os grants daquele banco. O acesso ao banco pedidos continua ativo.

Cada solicitação tem seu ciclo de vida independente, mas todas operam sobre o mesmo usuário na instância — assim como no IAM, onde todas operam sobre a mesma role.

Resumo do Modelo

Aspecto	IAM (role/PermissionSet)	Banco de Dados (nativo)
Identidade do usuário	Única por conta AWS	Uma por solicitação (user temporário)
O que muda a cada pedido	Policies na role existente	Novo usuário no banco
Credencial que o engenheiro usa	Sempre a mesma (SSO/role)	Diferente a cada pedido
Independência entre pedidos	Sim (policies isoladas)	Sim (usuários isolados)
Risco de acúmulo permanente	Nenhum (timer por policy)	Nenhum (DROP USER no timer)

O Apono não multiplica identidades. Na AWS, ele trabalha com a role que o engenheiro já tem e ajusta dinamicamente o que essa role pode fazer. Para bancos com autenticação nativa, ele cria identidades temporárias por necessidade do modelo, mas cada uma tem vida curta e é removida automaticamente. Em ambos os casos, nenhuma permissão sobrevive além do tempo aprovado.