OpenFGA v1.21.0 é um padrão para a pergunta que o login nunca responde: este técnico pode tocar no objeto deste cliente?

O OpenFGA v1.21.0 é um padrão para a pergunta a que o login nunca responde: este técnico pode tocar no objeto deste cliente?

A realidade de um MSP são muitos tenants de clientes, técnicos com delegações diferentes em cada cliente e integrações de máquina que agem por conta própria. Depois da autenticação, a verdadeira pergunta é: «este sujeito pode executar esta ação sobre este objeto neste tenant?». Um token, uma claim de grupo ou um evento de logout não lhe respondem; um ponto de decisão, sim. O projeto aqui discutido é um padrão de referência, não uma recomendação: OpenFGA, repositório openfga/openfga, Apache-2.0, projeto CNCF Incubating desde 28 de outubro de 2025 (aceite a 14 de setembro de 2022), descrito pelos mantenedores como um motor de autorização e permissões de alto desempenho inspirado no Google Zanzibar.

A 5 de outubro de 2026, o repositório no GitHub mostrava 5920 estrelas e um último push a 2 de outubro de 2026. A versão v1.21.0, publicada a 20 de setembro de 2026, enumera uma única novidade, Dynamic Conditions, que o projeto marca como experimental. Uma versão mais recente, a v1.22.0, saiu a 6 de outubro de 2026. Este artigo não afirma que algum produto da Altovar utilize o OpenFGA.

O resto do texto explica como a autorização baseada em relações se aplica à estrutura de tenants de um MSP, que provas de fixação de versão e de cadeia de fornecimento as versões oferecem, o que o OpenFGA não é (política de admissão, overlay de rede, scanners) e seis controlos para operar qualquer ponto de decisão central. Login, logout e validade do token são entradas; o direito de acesso é uma decisão tomada em cada pedido.

Segundo a descrição e os tópicos do próprio repositório, o OpenFGA é um motor de autorização e permissões inspirado no Google Zanzibar. Os tópicos referem o controlo de acesso baseado em relações ao lado de RBAC, ABAC e acesso baseado em políticas, bem como «entitlements». Este artigo cinge-se a essas fontes: não apresenta matriz de funcionalidades, números de débito ou latência, nem lista de utilizadores.

O ReBAC ao estilo do Zanzibar significa, em linguagem de comprador, que as permissões derivam das relações entre sujeitos e objetos (quem é membro de que tenant, que local pertence a que tenant, que técnico tem delegação sobre que local) em vez de uma longa lista de funções copiada para cada token. A decisão percorre o grafo de relações. Não cola um catálogo de funções em cada JWT.

Governação, segundo a página do projeto na CNCF lida a 5 de outubro de 2026: aceite na CNCF a 14 de setembro de 2022, Incubating desde 28 de outubro de 2025. Incubating é um nível de maturidade num processo de fundação. Não é uma certificação de segurança nem um contrato de suporte. Um MSP que trata «CNCF Incubating» como «auditado para os nossos clientes» está a ler um rótulo de fundação como uma garantia ao cliente que ele não dá.

A 5 de outubro de 2026, o repositório tinha 5920 estrelas no GitHub e 511 forks. As estrelas são um sinal de popularidade, não uma avaliação. A página da CNCF mostra métricas LFX à parte, com outro número de estrelas; este artigo usa o número do GitHub e não mistura os dois. A licença declarada no repositório é Apache-2.0.

As versões recentes: v1.22.0 a 6 de outubro de 2026, v1.21.0 a 20 de setembro de 2026, v1.20.0 a 8 de setembro de 2026 e v1.19.0 a 25 de agosto de 2026. Nenhuma está marcada como pré-lançamento. A regra de fixação a repetir: executar a v1.21.0 ou posterior e nada mais antigo, sendo a v1.22.0 o melhor alvo para novas implementações, porque acrescenta uma atualização de segurança de uma dependência. Não siga uma imagem latest flutuante num ambiente de cliente sem um pedido de alteração que identifique a tag.

O mínimo não é simplesmente «a mais recente». A v1.20.0 trazia uma secção Security: a correção de uma CVE na cadeia de ferramentas, uma dependência da sonda de saúde recompilada e a correção de um aviso de segurança do OpenFGA no caminho ListUsers. Tudo o que é anterior à v1.20.0 não tem essas correções; a v1.21.0 assenta nelas. A v1.22.0 acrescenta outra entrada Security: uma biblioteca gRPC atualizada que resolve o GO-2026-6443. A frase que um MSP pode pôr num pedido é: «a v1.20.0 trouxe correções de segurança, incluindo um aviso do OpenFGA no caminho ListUsers; executar ≥ v1.21.0, de preferência v1.22.0».

Dynamic Conditions exige uma formulação cuidadosa. As notas da v1.21.0 apresentam-na como «uma nova funcionalidade experimental» (tradução nossa): experimental, não de disponibilidade geral. A lógica de direitos dos clientes não deve depender de uma funcionalidade experimental, a não ser que o cliente aceite expressamente esse risco por escrito.

As provas de versão que um MSP pode anexar a um pedido de alteração, tal como constam das versões v1.21.0 e v1.22.0: ambas estão marcadas como imutáveis e cada uma inclui ficheiros de somas de verificação assinados, uma atestação in-toto e um SBOM por arquivo binário. Essas provas sustentam que o artefacto implementado corresponde ao que o projeto publicou e que dispõe de uma lista de componentes. Não são uma auditoria ao código nem ao seu modelo de autorização.

A pergunta, escrita uma vez e reutilizada: sujeito · ação · objeto · tenant. Um técnico, uma conta de parceiro, um utilizador do cliente e uma integração de máquina são quatro tipos de sujeito. «Ler», «alterar», «exportar» e «eliminar» são ações diferentes. Um dispositivo, uma caixa de correio e um conjunto de cópias de segurança são objetos. Cada objeto pertence exatamente a um tenant de cliente. É a esta pergunta em quatro partes que um evento de login, por si só, nunca responde.

Relações em vez de funções copiadas: um tenant contém locais ou organizações; os recursos pertencem a um local; um técnico está ligado a um local por uma delegação que pode ter prazo; um administrador do cliente está ligado apenas ao seu próprio tenant. O ponto de decisão deduz «este técnico pode alterar esta caixa de correio?» percorrendo essas relações.

Porque é que isto ajuda o MSP: o direito de acesso sai do token e dos milhares de verificações if espalhadas pelo código das aplicações e passa a ser um único lugar que se pode inspecionar, testar e registar. Revogar a delegação de um técnico num cliente é remover uma relação, não reemitir tokens em todas as aplicações. A alteração tem um responsável e um registo de auditoria num único repositório de dados.

O enquadramento defensivo: negar por omissão, privilégio mínimo e uma verificação em cada pedido (OWASP Authorization Cheat Sheet). O controlo de acesso defeituoso (broken access control), incluindo o acesso a objetos de outro tenant, é a classe de falha que este padrão pretende reduzir. Um logout ou um sinal de revogação pode desencadear uma nova verificação; o ponto de decisão é onde essa verificação acontece. É também por isso que um logout, por si só, não é uma revogação ao nível do tenant.

O Gatekeeper e o Kyverno são políticas de admissão do Kubernetes para objetos de infraestrutura. Decidem se um manifesto pode entrar num cluster, não se um técnico pode ler a caixa de correio de um cliente. Nenhum substitui o outro. Um MSP que confunde política de admissão com direitos aplicacionais põe o controlo errado na camada errada.

O OpenZiti é um overlay de rede zero trust. Decide que identidades podem chegar a que serviços na rede; não decide os direitos aplicacionais objeto a objeto. Acessibilidade na rede e permissão sobre um objeto são portas diferentes.

O Trivy, o Syft e o DefectDojo são scanners, geradores de SBOM e ferramentas de agregação de resultados. Descrevem o que está no seu software e o que está errado nele. Não autorizam pedidos.

Este artigo não diz que o Auris, ou qualquer outro produto da Altovar, utiliza, incorpora ou integra o OpenFGA. O OpenFGA é citado como padrão de referência open source para autorização centralizada.

Seis controlos defensivos para operar qualquer ponto de decisão central, cada um com o que conta como prova e o que não conta.

Primeiro, inventário: que stores e modelos de autorização existem, por cliente ou partilhados, e quem os pode alterar. A prova é uma lista exportada e um responsável por modelo. «Usamos ReBAC» não é prova. Segundo, fixação de versão: ≥ v1.21.0 registada no pedido de alteração, com o resultado da verificação das somas de verificação e da atestação em anexo. Um número de estrelas ou uma tag latest não são prova.

Terceiro, proteger a própria API de decisão: apenas chamadores autenticados, acessível apenas a partir da camada aplicacional, operações de administração limitadas a operadores identificados com MFA. Quarto, as alterações ao modelo são alterações de código: revistas, versionadas e testadas antes da implementação com casos explícitos de negação entre tenants. A prova é uma execução de testes que mostra que o tenant B não consegue chegar ao objeto do tenant A. «O modelo compilou» não é prova.

Quinto, fazer cópias de segurança dos dados de relações e restaurá-las; ensaiar uma restauração. Um ponto de decisão que perdeu as relações falha aberto ou fechado, e ambos os casos são falhas de serviço. Sexto, registar decisões e alterações ao modelo no SIEM como sinais operacionais, por exemplo alterações inesperadas ao modelo ou picos de negações depois de uma versão. Por fim, manter as funcionalidades experimentais fora dos caminhos de direitos dos clientes até o projeto as classificar de outra forma.

Em resumo: Apache-2.0; CNCF Incubating desde 28 de outubro de 2025; 5920 estrelas no GitHub a 5 de outubro de 2026; versão mínima v1.21.0 (20 de setembro de 2026), sendo a v1.22.0 (6 de outubro de 2026) o melhor alvo; por baixo ficam as correções de segurança da v1.20.0; Dynamic Conditions é experimental. O Gatekeeper, o Kyverno, o OpenZiti, o Trivy, o Syft e o DefectDojo não substituem um ponto de decisão central na aplicação. Login, logout e validade do token são entradas; o direito de acesso é uma decisão tomada em cada pedido.

Este artigo não afirma que o Auris utiliza o OpenFGA. O padrão é uma arquitetura de referência open source para a pergunta do MSP a que a autenticação, por si só, nunca responde.