Como o Google Verifica Permissões de Acesso para Bilhões de Usuários e o Que Isso Tem a Ver com o SpiceDB

Quando um projeto cresce além de um esquema simples com funções de admin e usuário, o caos começa. Em uma arquitetura de microsserviços, a verificação de permissões frequentemente se transforma em uma teia emaranhada. Um serviço armazena funções em um banco de dados, outro valida tokens JWT, um terceiro executa queries SQL pesadas com uma dúzia de JOINs. Desde 2021, a OWASP tem classificado as falhas de controle de acesso (Broken Access Control) como a principal ameaça à segurança de aplicações web.

O Google enfrentou esse problema há muitos anos. Para o Google Drive, YouTube e Cloud IAM, a empresa desenvolveu um sistema centralizado de autorização chamado Zanzibar. Em 2019, engenheiros publicaram um artigo descrevendo sua arquitetura, e a equipe da Authzed teve essa ideia e criou o SpiceDB — um banco de dados open-source para gerenciamento de controle de acesso.

Por Que Mover a Autorização para um Banco de Dados Separado

Bancos de dados convencionais são bons em armazenar entidades de negócio, mas têm dificuldades com grafos de permissão complexos. Imagine um documento dentro de uma pasta que está dentro de outra pasta, compartilhada com um grupo de usuários que inclui um departamento separado de uma empresa. Calcular se um funcionário específico tem acesso ao arquivo se torna doloroso e lento usando um DBMS padrão.

O SpiceDB assume essa tarefa para você. Você envia uma query simples para o banco de dados: "O usuário X pode executar a ação Y no recurso Z?". A resposta é uma rápida resposta binária.

Ao mesmo tempo, o SpiceDB lida apenas com autorização (permissões de acesso) e não sabe nada sobre autenticação (verificação de identidade). Verificar senhas, fazer login de usuários e emitir tokens ainda devem ser tratados pelo seu provedor de identidade como Keycloak ou Auth0.

Como o Schema e a Linguagem de Relacionamentos Funcionam

Trabalhar com o SpiceDB começa descrevendo um schema. O schema define tipos de objetos e regras para computar permissões.

A sintaxe do schema parece legível e concisa:

definition user {}

definition folder {
    relation parent: folder
    relation viewer: user

    permission view = viewer + parent->view
}

definition document {
    relation folder: folder
    relation viewer: user

    permission view = viewer + folder->view
}

Neste exemplo, o acesso view a um documento é automaticamente concedido a usuários listados diretamente em viewer, assim como aqueles que têm permissão view na pasta pai. A cadeia de aninhamento pode ter qualquer profundidade.

Os dados reais são armazenados como relacionamentos. Esses são fatos simples sobre o sistema, por exemplo:

• folder:finance — um objeto do tipo folder com ID finance
• viewer — uma relação
• user:mikhail — um subject

Registrar esse tipo de relacionamento significa que o Mikhail se tornou leitor da pasta finance.

ReBAC e Atributos: A Experiência da Netflix

Diferentemente do RBAC clássico (Role-Based Access Control), o SpiceDB implementa ReBAC (Relationship-Based Access Control). O acesso é determinado através de relacionamentos entre objetos em um grafo.

Mas às vezes os negócios precisam de mais do que apenas saber que um usuário faz parte de uma equipe. Eles precisam verificar uma condição contextual: por exemplo, que a pessoa está acessando de um IP corporativo ou que a requisição foi feita durante o horário comercial.

Para esses cenários, engenheiros da Netflix ajudaram a adicionar um mecanismo de caveats ao SpiceDB. Isso combina ReBAC e ABAC (Attribute-Based Access Control). Uma função contextual é anexada a um relacionamento, calculada no momento da verificação de permissão.

Arquitetura e Performance Sob Carga

O SpiceDB é escrito em Go e projetado para altas cargas. Os autores alegam latência de 5ms no p95 com milhões de queries por segundo e bilhões de relacionamentos no banco de dados.

Como armazenamento (datastores), você pode conectar DBMSs familiares:

• PostgreSQL
• CockroachDB
• MySQL (o driver para MySQL foi escrito pela equipe de autorização do GitHub)
• Google Cloud Spanner

Um recurso interessante é o gerenciamento de consistência no nível da query individual. Se um usuário acabou de mudar permissões de acesso e quer ver o resultado imediatamente, a aplicação envia uma requisição exigindo dados totalmente consistentes. No entanto, se estamos renderizando um catálogo público onde um par de segundos de atraso não é crítico, permitimos cache e reduzimos a carga no banco de dados.

O SpiceDB também pode responder perguntas "reversas": "A quais recursos o usuário tem acesso?" ou "Quem pode visualizar este documento?". Para isso, ele usa índices reversos internamente.

Quick Start com Docker e curl

Você pode subir o SpiceDB para experimentos com um único comando Docker:

docker run --rm -p 50051:50051 -p 8443:8443 \
  authzed/spicedb serve \
  --http-enabled true \
  --grpc-preshared-key "somerandomkeyhere"

Após iniciar, carregue o schema via API HTTP:

curl --location 'http://localhost:8443/v1/schema/write' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
    "schema": "definition user {} \n definition folder { \n relation viewer: user \n permission view = viewer \n }"
}'

Adicione um relacionamento stating que o usuário anne pode visualizar a pasta budget:

curl --location 'http://localhost:8443/v1/relationships/write' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
    "updates": [
        {
            "operation": "OPERATION_TOUCH",
            "relationship": {
                "resource": { "objectType": "folder", "objectId": "budget" },
                "relation": "viewer",
                "subject": { "object": { "objectType": "user", "objectId": "anne" } }
            }
        }
    ]
}'

Agora verifique as permissões:

curl --location 'http://localhost:8443/v1/permissions/check' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
  "resource": { "objectType": "folder", "objectId": "budget" },
  "permission": "view",
  "subject": { "object": { "objectType": "user", "objectId": "anne" } }
}'

Receberemos o status PERMISSIONSHIP_HAS_PERMISSION em resposta.

Além das APIs REST e gRPC, os desenvolvedores oferecem um utilitário de linha de comando zed e um sandbox baseado em navegador chamado Playground (play.authzed.com). É conveniente para esboçar um modelo de permissão, popular com dados de teste e testar hipóteses antes de escrever qualquer código.

Para Quem Esta Ferramenta É

O SpiceDB já está rodando em produção na Red Hat, IBM, GitPod e Tubi.

Introduzir um sistema assim em um pequeno monólito onde todas as permissões são limitadas a um painel de admin e um par de funções faz pouco sentido — é uma complexidade de infraestrutura desnecessária. No entanto, a ferramenta é perfeita quando:

• Você tem uma dúzia de microsserviços, e cada um tenta verificar permissões do seu próprio jeito.
• A lógica do seu produto requer compartilhamento de arquivos, hierarquias complexas de pastas ou contas de equipe.
• Você precisa de uma auditoria de segurança e um ponto único de gerenciamento de controle de acesso.

Para deploy em Kubernetes, a Authzed fornece um operator oficial. O projeto está em desenvolvimento ativo, e o repositório no GitHub já tem quase 7.000 estrelas.