Por que RBAC sozinho não basta em sistemas financeiros multi-tenant

Roles comprimem policy, mas perdem context

RBAC funciona com permission sets estáveis. Fica insuficiente quando policy depende do objeto ou ambiente: Finance role pode refundar para uma entidade, mas não outra, ou só até certo threshold.

Tenant isolation faz parte de authorization

Não basta perguntar se o role pode refundar. É preciso verificar server-side se o payment pertence a tenant/account que o actor pode operar.

Attributes e relationships adicionam precisão

NIST ABAC avalia subject, object, operation e environmental attributes contra policy. Em financial systems, role pode ser baseline e entity, amount, channel, ownership ou risk state refinam a decisão.

A decisão deve ser explicável

Registre policy version e decision context suficiente para auditoria sem expor regras internas sensíveis ao cliente.

Separe role assignment de authorization evaluation

Roles são úteis para capacidades amplas como finance operator, support agent ou administrator. O authorization engine deve avaliar requests específicos com esses roles mais resource e environmental context. Isso evita criar role novo para cada combinação de tenant, amount threshold, região e ownership.

Role explosion indica que RBAC está carregando policies que não expressa bem. Centenas de roles quase duplicados são difíceis de revisar e fáceis de atribuir errado. Mantenha roles compreensíveis e adicione contextual policy quando necessário.

Torne tenant boundaries impossíveis de burlar por acidente

Tenant context deve vir de relações autenticadas server-side, não apenas de tenant ID enviado pelo cliente. Query scopes, policy checks e service boundaries devem fazer cross-tenant access falhar por padrão. Um role check correto com tenant scope errado continua sendo authorization failure.

Também vale para background jobs e service accounts. Machine identities precisam de authority scoped; credenciais internas amplas podem ignorar permissions de usuário se service-to-service access não for modelado.

Use attributes para financial constraints

Ações financeiras dependem frequentemente de amount, legal entity, currency, country, risk state, ownership, account status ou second approval. Uma policy estilo ABAC combina esses fatos com roles para permitir trabalho rotineiro e exigir autoridade adicional em ações high-value ou cross-entity.

Escolha attributes authoritative e estáveis para security decisions. Labels do cliente ou valores cached stale não devem virar policy inputs sem controle. Authorization é tão confiável quanto os dados usados na avaliação.

Modele relationships onde ownership importa

Algumas policies se expressam melhor como relações: user pertence à organization, organization possui merchant account, merchant account possui payment. Relationship checks complementam roles e attributes respondendo se actor está ligado ao resource por um caminho permitido.

Na prática os modelos podem se combinar. RBAC oferece permissões de job compreensíveis, relationships aplicam ownership e attributes contexto financeiro. O objetivo não é pureza ideológica, mas policy que reflita o negócio e continue revisável.

Audite a decisão, não apenas a ação

Quando uma ação sensível é permitida ou negada, preserve context suficiente para explicar authorization: actor, resource, tenant, policy version e key attributes. É especialmente útil quando policies evoluem; precisamos saber qual rule estava ativa naquele momento, não aplicar a de hoje ao evento de ontem.

Denial messages para usuário podem ser limitadas para não expor detalhes de policy. A evidence interna pode ser mais rica que a response ao caller.