Identidade como arquitetura: o que muda quando RBAC não basta na AWS

# Identidade como arquitetura: o que muda quando RBAC não basta na AWS

Nota da redação: este artigo traduz um caso real de IAM (Neo4j/Kafka/Spring Security) relatado pela InfoQ para equivalentes de serviços AWS (Neptune, Verified Permissions, STS, Secrets Manager, MSK, CloudTrail). Os fatos extraídos da reportagem original (datas, números, citações, modelo de dados, query Cypher) foram conferidos e batem com a fonte. Já as afirmações sobre comportamento e modelo de cobrança desses produtos AWS específicos (suporte a openCypher no Neptune, mecânica do Verified Permissions/Cedar, AssumeRole no STS, preços de Secrets Manager/MSK/Verified Permissions/Neptune, disponibilidade em sa-east-1) são leitura própria do autor sobre a plataforma AWS, não extraídas de documentação oficial da AWS checada neste processo. Confirme esses pontos na documentação e na tabela de preços da AWS antes de usar este texto para decisão de arquitetura ou orçamento.

Um artigo da InfoQ sobre IAM em serviços financeiros regulados mostra por que grafo, eventos e revogação rápida viram decisão de arquitetura, não detalhe de segurança. O texto não fala de AWS, mas o padrão se traduz quase ponto a ponto para quem opera conta na nuvem.

A InfoQ publicou em 6 de novembro de 2026 um artigo de Vaishnavi Khosla contando como a equipe dela reconstruiu a plataforma de identidade e acesso de uma instituição financeira regulada. O texto não cita a AWS em nenhum momento: o backend descrito roda em Neo4j, Kafka e GraphQL, com Spring Security do lado de autorização. Mesmo assim, o padrão arquitetural que ela descreve é exatamente o tipo de decisão que quem desenha ambiente AWS multi-conta precisa tomar cedo, com serviços gerenciados equivalentes já disponíveis na plataforma.

Este texto segue a lógica do artigo original, mas traduz cada peça para o que existe hoje em sa-east-1 e nas demais regiões AWS: Amazon Neptune no lugar do Neo4j, Amazon Verified Permissions no lugar do policy layer caseiro, AWS STS no lugar do token exchange manual. A autora não construiu nada disso na AWS; a tradução é leitura própria, feita porque o problema que ela descreve é o mesmo que qualquer time de identidade enfrenta ao crescer dentro de uma organização AWS.

O problema

Para uma aplicação só, identidade é decisão de fornecedor. Você escolhe um provedor de identidade (AWS IAM Identity Center ou Amazon Cognito, por exemplo), configura SSO, valida o token na borda e segue para as features. Khosla é direta sobre isso: para um time e uma aplicação, essa é a escolha certa. O login continua funcionando bem conforme a organização cresce; o que trava é tudo que vem depois — quem aprovou um acesso específico e se ele ainda deveria existir quando um auditor perguntar, meses depois.

O teste que ela propõe é simples de aplicar em qualquer ambiente: você consegue responder "quem tinha acesso a este sistema em 14 de março" só com o seu modelo de dados, sem fazer grep em logs espalhados por várias ferramentas? Se a resposta é não, auditoria não fez parte do desenho desde o início. Uma revisão de segurança no fim do projeto pega um check faltando ou um scope mal configurado, mas não reconstrói um schema que nunca foi pensado para explicar quem teve acesso e quando.

O caso concreto do artigo dá a medida do problema em escala: cerca de oitenta mil pessoas são donas de contas de serviço na organização descrita. Antes da reconstrução, atestação, rotação e vaulting de credenciais viviam em três ferramentas separadas, e revogar acesso por completo levava cerca de três dias. Depois de consolidar os três fluxos num workflow único, essa revogação caiu para menos de um dia. Em resumo: o gargalo não era tecnologia de ponta, era processo fragmentado em volta de uma pergunta simples: quem é dono disso e esse acesso ainda é válido?

A arquitetura

A leitura que proponho aqui mapeia o padrão da InfoQ para peças gerenciadas da AWS, do usuário até o dado:

1. O usuário ou o serviço chamador autentica via AWS IAM Identity Center (ou Amazon Cognito para aplicações voltadas a cliente final) e recebe um token OIDC.
2. Toda decisão de autorização passa por um ponto único de política, em vez de cada serviço reimplementar sua própria lógica: na AWS isso é o Amazon Verified Permissions, que avalia políticas escritas em Cedar contra o pedido de acesso, equivalente ao policy decision point que Khosla descreve em Spring Security.
3. Ao cruzar um limite de serviço, o token do chamador não é reaproveitado inteiro: ele é trocado por um token mais estreito via AssumeRole ou AssumeRoleWithWebIdentity do AWS STS, o mesmo princípio do token exchange OAuth 2.0 (RFC 8693) citado na fonte, só que resolvido pelo próprio STS em vez de código escrito à mão.
4. O relacionamento de posse e acesso — quem é dono de qual conta de serviço, e quais acessos essa conta ainda tem válidos — fica modelado como grafo em Amazon Neptune, que suporta openCypher nativamente; a consulta Cypher publicada no artigo original roda quase sem alteração nesse serviço gerenciado.
5. Toda mudança de direito de acesso (concessão, revogação, troca de dono) vira um evento publicado em Amazon MSK ou Amazon EventBridge; os consumidores invalidam a decisão em cache ao processar cada evento.
6. Para cobrir evento perdido, cada decisão em cache carrega uma idade máxima; expirada, o serviço resolve de novo contra o Neptune, nunca serve o cache vencido.
7. Credenciais de contas de serviço ficam no AWS Secrets Manager, com rotação própria; o workflow de atestação só marca uma etapa como concluída depois de confirmar o estado real do Secrets Manager, nunca a partir do simples envio da chamada — o mesmo "fail closed" que a fonte descreve ao integrar um vault que o time não controlava.
8. Toda leitura e escrita no grafo e no fluxo de eventos é auditada via AWS CloudTrail e pelo próprio log de eventos, que passa a ser a resposta direta à pergunta sobre o dia 14 de março.

O núcleo do modelo de dados, direto do artigo, é este: três tipos de nó (Person, ServiceAccount, Resource) e duas relações (OWNS e HAS_ACCESS), com expiration e lastAttested como propriedades da aresta HAS_ACCESS, não do nó. A validade pertence ao par conta-recurso, não a um dos dois isoladamente:

// Quem é dono desta conta, e quais acessos dela ainda são válidos hoje?
MATCH (p:Person)-[:OWNS]->(a:ServiceAccount {id: $accountId})
OPTIONAL MATCH (a)-[g:HAS_ACCESS]->(r:Resource)
WHERE g.expires >= date()
RETURN p.name AS owner,
       collect({resource: r.name, expires: g.expires, lastAttested: g.lastAttested}) AS validAccesses

A mesma pergunta em tabelas relacionais exige encadear JOIN de posse, concessão e recurso toda vez que alguém pergunta, e colocar a checagem de validade no lugar errado da query (no WHERE em vez de embutida no JOIN) faz contas sem acesso válido desaparecerem do resultado inteiro, dono incluído. Khosla é honesta sobre o custo: Neptune (como Neo4j) é mais um datastore para operar, e desempenho de travessia depende de como o grafo é modelado — um grafo mal desenhado pode ficar mais lento que o JOIN que substituiu.

Os serviços envolvidos

Trade-offs

Revogação que viaja por fluxo de eventos é, por definição, eventualmente consistente — isso é confiabilidade, não um bug a corrigir. No artigo original, o acesso para de valer depois que os consumidores processam o evento e invalidam a decisão em cache, e eventos podem se perder.

A resposta de Khosla foi dar à decisão em cache uma idade máxima: uma janela curta expira acesso obsoleto rápido, mas devolve mais checagens à fonte de verdade; uma janela longa é mais barata para o sistema, só que dá mais tempo para um evento perdido continuar valendo. Ela resume isso numa frase que qualquer time de segurança consegue planejar em cima: um evento perdido deixa o acesso vivo por, no máximo, aquele tempo.

Quando a revogação viaja por um stream de eventos, ela é eventualmente consistente. Conheça seu pior cenário de obsolescência, limite-o com uma idade máxima de cache e diga ao seu time de segurança qual é esse valor.

When revocation travels over an event stream, it's eventually consistent. Know your worst-case staleness, cap it with a maximum cache age, and tell your security team what it is.Vaishnavi Khosla, autora do artigo na InfoQ

Outro trade-off é de segurança: ao integrar um sistema que o time não governa — no caso dela, o vault de outra equipe; no caso AWS, pode ser um Secrets Manager de outra conta acessado via role entre contas — a regra foi "fail closed". Se o vault não respondia, a etapa nunca era marcada como concluída, e nenhum dono era avisado de que uma credencial estava protegida quando não estava.

O lado de otimização de custos aparece na tabela que a própria autora propõe: grafo, stream de eventos e camada de política central só valem a pena quando há muitos serviços tomando decisão de acesso, contas de serviço que superam e sobrevivem às pessoas que cuidam delas, e uma obrigação de auditoria com peso de verdade. Fora disso, é complexidade que ninguém pediu.

Custo estimado

A fonte não informa preço nenhum, porque descreve um ambiente que não roda na AWS. O que segue é estimativa própria, baseada na tabela pública de preços dos serviços equivalentes, não um número extraído do artigo — e vale confirmar no AWS Pricing Calculator antes de orçar qualquer projeto real.

• Amazon Neptune cobra por hora de instância provisionada ou, no modo serverless, por NCU-hora consumida; o custo sobe com a profundidade e a frequência das travessias, não com o número de linhas como num banco relacional.
• Amazon MSK provisionado cobra por hora de broker mais armazenamento; a opção serverless cobra por hora de cluster mais throughput, o que tende a ser mais barato para um volume de eventos de entitlement, que é esporádico comparado a telemetria.
• Amazon Verified Permissions cobra por solicitação de autorização avaliada, então o custo escala direto com o tráfego que passa pelo ponto único de decisão.
• AWS Secrets Manager cobra por segredo armazenado por mês mais um valor por 10 mil chamadas de API, relevante quando oitenta mil contas de serviço rotacionam credencial com frequência.
• Chamadas de AssumeRole no AWS STS não têm custo adicional, o que torna o token exchange a peça mais barata do desenho inteiro.

Para uma organização na escala descrita no artigo, a soma dessas peças de infraestrutura tende a ficar na casa de poucas centenas a alguns milhares de dólares mensais em sa-east-1, sem contar o tempo de engenharia para desenhar o grafo e manter o workflow — ordem de grandeza, não cotação fechada.

Como adaptar

A própria autora dá o limiar com clareza: para uma aplicação só, com poucas roles e um time cuidando dela, RBAC simples é a escolha certa, e Neptune, MSK e uma camada central de política seriam complexidade que você vai lamentar manter. O sinal de que vale a pena migrar não é o tamanho da empresa, é a forma do problema:

• Muitos serviços tomando decisão de acesso cada um à sua maneira, sem auditoria central.
• Contas de serviço que superam em número e sobrevivem às pessoas que deveriam cuidar delas.
• Posse que precisa ser reverificada periodicamente, não assumida como permanente.
• Uma obrigação de auditoria com peso real, não um checklist de boas práticas.

Para quem já opera organização AWS multi-conta, vale separar os planos: o grafo de posse e acesso descrito aqui mora no nível de aplicação, dentro de uma conta ou de um conjunto de contas de carga de trabalho. Governança de conta inteira (AWS Organizations, Service Control Policies, permission boundaries) é camada complementar, não substituta — SCP restringe o que uma conta pode fazer, o grafo de entitlement responde quem é dono do quê dentro dela, e as duas perguntas continuam distintas mesmo depois de resolver uma.

Se o ponto de partida é dor de revogação lenta, o artigo sugere um caminho mais barato que trocar banco de dados: antes de migrar para grafo, vale consolidar atestação, rotação e vaulting num workflow único, que foi o que derrubou o tempo de revogação de três dias para menos de um, antes mesmo de qualquer ganho vir da modelagem em grafo em si.

Fonte: InfoQ — Architecture & Design