Quando comecei a trabalhar na implementação de RBAC, o objetivo parecia simples: criar um ponto central para controlar quem poderia acessar cada recurso das aplicações.
A primeira ideia: um RBAC Core
A primeira ideia foi construir um RBAC Core. Todas as aplicações consultariam esse serviço antes de permitir uma ação. O diagrama fixo mantém a topologia visível enquanto as notas ao lado explicam onde essa centralização passa a pesar.
Diagrama de arquitetura
O caminho centralizado
Toda decisão passa pelo RBAC Core.
Todas as apps consultam um ponto
Cada requisição chega ao RBAC Core antes da ação ser permitida.
Core coordena cada decisão
O Core consulta o OpenFGA e devolve permitir ou negar para a aplicação.
Concentração cria dependência
Indisponibilidade e regras de negócio de todos sistemas acumulam no mesmo serviço.
Na teoria, isso entregaria padronização, governança e uma interface única. Na prática, começaram a surgir algumas perguntas importantes.
O que aconteceria se o RBAC Core ficasse indisponível? Todas as aplicações perderiam a capacidade de autorizar usuários? Quem seria responsável por atualizar os modelos de autorização? O time responsável pelo serviço central precisaria conhecer todas as regras de negócio de todos os sistemas?
Decisão inicial
Decisão
Concentrar a autorização em um RBAC Core.
Motivo
Padronizar a interface e a governança entre aplicações.
Consequência
O serviço central entra no caminho de todas as decisões de autorização.
Percebi que estávamos criando não apenas um serviço central, mas também um possível ponto único de falha e um gargalo organizacional.
A virada: um modelo federado
A arquitetura começou então a evoluir para um modelo federado. O cenário separa decisões de execução da governança central.
Diagrama de arquitetura
O caminho federado
Responsabilidade local; governança fora da requisição.
Cada app possui seu modelo
Relações e políticas vivem perto do domínio que elas protegem.
SDK fala direto com OpenFGA
O caminho crítico elimina o Core intermediário e suporta cache curto de decisões.
Centralizar governança, não runtime
Modelos versionados, auditoria e visualização seguem centrais, fora da requisição.
Cada aplicação passou a ser responsável pelo próprio modelo de autorização, por suas relações e por suas políticas. Essas políticas seriam tratadas de forma semelhante a migrations de banco de dados: versionadas, revisadas e aplicadas de maneira idempotente durante o deploy.
O serviço central deixou de estar no caminho crítico das requisições. Seu papel passou a ser o de governança: visualizar modelos, acompanhar alterações, executar auditorias e ajudar na administração das permissões.
Também entendemos que autorização não deveria depender completamente da disponibilidade do control plane. Por isso, entraram na discussão estratégias como cache temporário das decisões, aplicação automatizada dos modelos e comunicação direta entre cada sistema e o OpenFGA.
Centralizar ou federar
O que ficou
A principal descoberta dessa caminhada foi que RBAC não é apenas uma tabela com usuários, papéis e permissões. É uma decisão de arquitetura distribuída.
Centralizar a governança pode ser valioso. Centralizar todas as decisões em tempo de execução, porém, pode aumentar o acoplamento e reduzir a resiliência.
No final, a implementação deixou de ser apenas sobre controlar acessos. Ela passou a ser sobre encontrar o equilíbrio entre autonomia, segurança, governança e disponibilidade.
E talvez essa tenha sido a maior lição: uma boa arquitetura de autorização não é aquela que concentra todo o controle, mas aquela que distribui responsabilidades sem perder a capacidade de governar o conjunto.