Autorização — quem pode fazer o quê, e como você comprova isso

O Control Center responde a duas perguntas de autorização, e elas são realmente diferentes. “Esta pessoa pode chamar esta operação?” é sobre pessoas, papéis e repositórios. “Este agente pode causar este efeito?” é sobre ações, argumentos e raio de impacto — essa fica com as Barreiras.

Esta página trata da primeira pergunta, além do registro que as duas deixam para trás.

Um único ponto de decisão

Toda decisão de autorização do lado humano passa por uma única função:

can(principal, permission, resource) → allow | deny + why

Uma permissão é <domain>:<tier> — tickets:write, members:administer, repos:read. O catálogo é derivado, não escrito à mão: ele é calculado a partir da própria superfície de operações (o prefixo do nome da op dá o domínio, o papel mínimo que ela já aplica dá o nível), de modo que todas as ~550 operações carregam uma permissão sem que ninguém precise digitar nenhuma.

Essa derivação é a propriedade que vale a pena proteger. Ela significa que uma operação NOVA já vem protegida por padrão — o modo de falha de um modelo anotado à mão é que alguém esquece, e o que essa pessoa esquece é justamente o controle. Um teste de catraca fixa o conjunto de domínios resultante, de modo que adicionar uma operação sob um novo prefixo é uma decisão de nomenclatura que uma pessoa toma, e não um acidente.

Os quatro níveis correspondem exatamente aos papéis integrados:

Nível	Papel mínimo	Exemplo
read	convidado	tickets:read
write	membro	tickets:write
administer	admin	members:administer
own	proprietário	workspace:own

Papéis

Cinco papéis integrados — proprietário, admin, membro, observador, convidado — são predefinições sobre esse catálogo. A propriedade é um assento único por espaço de trabalho, transferido explicitamente com Transferir a propriedade (um proprietário que sai é, de outro modo, impossível de remover: o desprovisionamento via SCIM recusa qualquer proprietário de espaço de trabalho — transfira primeiro).

Papéis personalizados são subtrativos. Um papel personalizado nomeia uma predefinição base (admin, member, viewer ou guest — nunca owner) e um conjunto de permissões REMOVIDAS dela — “admin, mas não pode gerenciar membros”. Ele nunca pode conceder mais do que a sua base, e é isso que os torna seguros de introduzir em uma instalação existente: toda verificação existente continua sendo um limite superior válido. Os membros os detêm como custom:<id>, e um cliente velho demais para entender esse valor recorre a convidado em vez de adivinhar.

Abaixo dos papéis ficam as concessões por repositório (none / read / review / write): a participação em um espaço de trabalho nunca dá, em silêncio, mais privilégios do que o host de código. Toda superfície que expõe código as verifica — inclusive as que chegam ao código por vias laterais, como um terminal ou uma sessão de editor aberta sobre o worktree de um espaço.

Autoridade do servidor

Algumas operações não têm nada a ver com um espaço de trabalho: configurações de toda a instalação, configuração de SSO, credenciais de provedores, gerenciamento de modelos, backups da instalação inteira. Elas declaram autoridade de servidor e são recusadas para todo mundo, exceto para o operador da instalação (o proprietário de servidor registrado). Existe, de propósito, uma única identidade de operador e uma única definição dela.

O registro de auditoria

Toda decisão de autorização — permitida e recusada — é anexada a um registro de auditoria encadeado por hash, próprio de cada espaço de trabalho.

Um log que registra apenas recusas responde a “o que nós bloqueamos?”, mas não a “o que este agente de fato fez, e quem autorizou isso?”, que é a pergunta por onde começa uma análise de incidente. Por isso cada entrada registra a cadeia de atribuição completa: o principal que agiu, a pessoa em nome de quem ele agiu, a delegação pela qual ele chegou, a ação e seus argumentos (como um digest), a decisão, e a regra que decidiu.

As entradas são encadeadas: o hash de cada uma cobre o da anterior, de modo que editar, excluir ou reordenar qualquer linha quebra todos os hashes seguintes. Verificar a cadeia recalcula o conjunto inteiro e aponta o primeiro elo que não se sustenta. Um registro de auditoria que você não consegue conferir é um log; um que você consegue recalcular é evidência.

Duas consequências que vale a pena conhecer:

• A tabela de auditoria é isenta do expurgo por idade. Uma cadeia de hashes não pode ser cortada pelo meio. A retenção funciona por exportar e depois truncar, e o truncamento deixa um checkpoint que carrega o hash terminal do segmento removido, de modo que o que sobrevive ainda pode ser verificado desde o início.
• Ele fica ao lado da linha do tempo de atividades, e não sobre ela. A linha do tempo é o que as pessoas fizeram; este é o que foi autorizado e recusado. Um id de correlação compartilhado lê uma mesma chamada nos dois.

Ele é exportado como JSON delimitado por quebras de linha e pode ser transmitido para um SIEM (Splunk, Elastic, Sentinel — um endpoint HTTP com um token bearer). A transmissão é de melhor esforço por projeto: um SIEM fora do ar nunca deve bloquear a chamada de ferramenta de um agente, e a cópia durável e verificável está em disco de qualquer forma.

Sessões

Uma instalação pode definir uma idade máxima de sessão e um timeout de inatividade. Ambos são aplicados na verificação de credencial de dispositivo pela qual passa cada via autenticada — um limite de sessão que o cliente pode ignorar responde a um questionário, não a um atacante. Uma instalação também pode exigir SSO, o que desativa o emparelhamento manual de novos dispositivos (com uma proteção contra bloqueio: a exigência é recusada enquanto não existir nenhuma conexão de SSO funcional).

O que isto não é

• Não são ACLs por objeto. Não existe, de propósito, permissão por ticket ou por mensagem. A separação no nível de repositório é o que as equipes de fato pedem, e ela existe; o compartilhamento por objeto é uma superfície combinatória sem demanda demonstrada aqui.
• Não é um motor de políticas que você configura em uma DSL. O vocabulário é fechado de propósito, de modo que toda a política pode ser renderizada, explicada e enumerada.
• Não é aplicado em nenhum lugar além do servidor. As verificações do lado do cliente existem apenas para evitar oferecer um controle que será recusado. A decisão que vale é sempre a do servidor.