Por que os papéis não bastam em sistemas financeiros com várias organizações

Os papéis resumem políticas, mas perdem contexto

O RBAC funciona com conjuntos de permissões estáveis. Torna-se insuficiente quando a política depende do objeto ou do ambiente: a função Financeiro pode permitir reembolsos para uma entidade, mas não para outra, ou apenas até determinado limite.

O isolamento entre organizações deve fazer parte da autorização

Não basta perguntar se a função pode autorizar um reembolso. É preciso verificar no servidor se o pagamento pertence a um inquilino ou conta em que o ator tem permissão para operar.

Os atributos e os relacionamentos acrescentam precisão

O ABAC do NIST avalia atributos do sujeito, do objeto, da operação e do ambiente em relação à política. Em sistemas financeiros, a função pode servir de base, enquanto a entidade, o valor, o canal, a titularidade ou o estado de risco refinam a decisão.

A decisão precisa ser explicável

Registre a versão da política e contexto suficiente da decisão para permitir auditoria, sem expor ao cliente regras internas sensíveis.

Separe a atribuição de papéis da avaliação de autorização

As funções são úteis para capacidades amplas, como operador financeiro, agente de suporte ou administrador. O mecanismo de autorização deve avaliar solicitações específicas usando essas funções junto com o recurso e o contexto ambiental. Isso evita criar uma nova função para cada combinação de locatário, limite de valor, região e titularidade.

A proliferação de funções indica que o RBAC está tentando aplicar políticas que não consegue expressar bem. Centenas de funções quase duplicadas são difíceis de revisar e fáceis de atribuir incorretamente. Mantenha funções compreensíveis e adicione políticas contextuais quando necessário.

Evite que os limites entre organizações sejam ignorados por acidente

O contexto do locatário deve vir de relações autenticadas no servidor, não apenas de um ID de locatário enviado pelo cliente. Os escopos de consulta, as verificações de política e os limites entre serviços devem fazer com que o acesso entre locatários falhe por padrão. Uma verificação de função correta com o escopo de locatário errado continua sendo uma falha de autorização.

Isso também se aplica a tarefas em segundo plano e contas de serviço. As identidades de máquina precisam ter autoridade delimitada; credenciais internas amplas podem ignorar as permissões de usuários se o acesso entre serviços não for modelado.

Use atributos para as restrições financeiras

As ações financeiras dependem com frequência do valor, da entidade legal, da moeda, do país, do estado de risco, da titularidade, do status da conta ou da aprovação de uma segunda pessoa. Uma política no estilo ABAC combina esses fatos com as funções para permitir o trabalho rotineiro e exigir autoridade adicional em ações de alto valor ou entre entidades.

Escolha atributos confiáveis e estáveis para decisões de segurança. Rótulos do cliente ou valores em cache desatualizados não devem se tornar entradas de política sem controle. A autorização é tão confiável quanto os dados usados na avaliação.

Modele os relacionamentos onde a titularidade importa

Algumas políticas são mais bem expressas como relações: o usuário pertence à organização, a organização possui a conta do comerciante, a conta do comerciante possui o pagamento. As verificações de relação complementam funções e atributos ao determinar se quem age está ligado ao recurso por um caminho permitido.

Na prática, os modelos podem ser combinados. O RBAC oferece permissões de trabalho compreensíveis, as relações aplicam a titularidade e os atributos fornecem contexto financeiro. O objetivo não é a pureza ideológica, mas uma política que reflita o negócio e continue passível de revisão.

Audite a decisão, além da ação

Quando uma ação sensível é permitida ou negada, preserve contexto suficiente para explicar a autorização: quem agiu, o recurso, o locatário, a versão da política e os atributos principais. Isso é especialmente útil quando as políticas evoluem; precisamos saber qual regra estava ativa naquele momento, não aplicar a de hoje ao evento de ontem.

As mensagens de negação exibidas ao usuário podem ser limitadas para não expor detalhes da política. As evidências internas podem ser mais completas que a resposta ao solicitante.