Autorização — quem pode fazer o quê e como se comprova

O Control Center responde a duas perguntas de autorização, e elas são realmente diferentes. “Esta pessoa pode invocar esta operação?” tem a ver com pessoas, funções e repositórios. “Este agente pode provocar este efeito?” tem a ver com ações, argumentos e raio de impacto — essa é da responsabilidade das Barreiras.

Esta página trata da primeira pergunta e ainda do registo que ambas deixam atrás de si.

Um único ponto de decisão

Todas as decisões de autorização do lado humano resolvem-se através de 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: é calculado a partir da própria superfície de operações (o prefixo do nome da operação dá o domínio e a função mínima que a operação já impõe dá o nível), pelo que todas as cerca de 550 operações têm uma permissão sem que ninguém tenha de a escrever.

É essa derivação que vale a pena proteger. Significa que uma operação NOVA fica sujeita a autorização por predefinição — o modo de falha de um modelo anotado à mão é alguém esquecer-se, e aquilo de que se esquece é precisamente o controlo. Um teste de catraca fixa o conjunto de domínios resultante, de modo que acrescentar uma operação com um novo prefixo é uma decisão de nomenclatura tomada por uma pessoa e não um acidente.

Os quatro níveis correspondem exatamente às funções incorporadas:

Nível	Função mínima	Exemplo
read	convidado	tickets:read
write	membro	tickets:write
administer	admin	members:administer
own	proprietário	workspace:own

Funções

Cinco funções incorporadas — proprietário, admin, membro, observador, convidado — são predefinições sobre esse catálogo. A propriedade é um lugar único por espaço de trabalho, transmitido explicitamente com Transferir a propriedade (caso contrário, um proprietário que saia é irremovível: o desprovisionamento por SCIM recusa qualquer proprietário de espaço de trabalho — transfira a propriedade primeiro).

As funções personalizadas são subtrativas. Uma função personalizada indica uma predefinição base (admin, member, viewer ou guest — nunca owner) e um conjunto de permissões REMOVIDAS dessa base — “admin, mas sem poder gerir membros”. Nunca pode conceder mais do que a sua base, e é isso que as torna seguras de introduzir numa instalação existente: qualquer verificação já existente continua a ser um limite superior válido. Os membros detêm-nas como custom:<id>, e um cliente demasiado antigo para compreender esse valor recorre a convidado em vez de adivinhar.

Por baixo das funções estão as concessões por repo (none / read / review / write): a pertença a um espaço de trabalho nunca confere silenciosamente mais privilégios do que o host de código. Todas as superfícies que expõem código verificam-nas — incluindo as que chegam ao código por vias laterais, como um terminal ou uma sessão de editor aberta no worktree de um espaço.

Autoridade do servidor

Algumas operações não têm nada a ver com um espaço de trabalho: definições de toda a instalação, configuração de SSO, credenciais de fornecedores, gestão de modelos, cópias de segurança da instalação completa. Essas declaram autoridade do servidor e são recusadas a todos exceto ao operador da instalação (o proprietário do servidor registado). Existe deliberadamente uma única identidade de operador e uma única definição da mesma.

O registo de auditoria

Todas as decisões de autorização — permitir e recusar — são acrescentadas a um registo de auditoria por espaço de trabalho, encadeado por hash.

Um registo apenas de recusas responde a “o que bloqueámos?”, mas não a “o que fez este agente na realidade e quem o autorizou?”, que é a pergunta por onde começa uma análise de incidentes. Por isso, cada entrada regista toda a cadeia de atribuição: o principal que agiu, a pessoa em nome de quem agiu, a delegação por onde chegou, a ação e os respetivos argumentos (como um digest), a decisão e a regra que decidiu.

As entradas estão encadeadas: o hash de cada uma abrange o da anterior, pelo que editar, eliminar ou reordenar qualquer linha quebra todos os hashes seguintes. Verificar a cadeia recalcula o conjunto todo e indica o primeiro elo que não se sustenta. Um registo de auditoria que não se consegue verificar é apenas um registo; um que se consegue recalcular é prova.

Duas consequências que vale a pena conhecer:

• A tabela de auditoria está isenta da limpeza baseada na idade. Uma cadeia de hashes não pode ser cortada pelo meio. A retenção é exportar e depois truncar, e o truncamento deixa um ponto de verificação que transporta o hash terminal do segmento removido, pelo que o que sobrevive continua a verificar-se até ao início.
• Fica ao lado da cronologia de atividade, não por cima dela. A cronologia mostra o que as pessoas fizeram; este mostra o que foi autorizado e recusado. Um id de correlação partilhado permite acompanhar uma mesma chamada nos dois.

É exportado como JSON delimitado por linhas e pode ser transmitido em fluxo para um SIEM (Splunk, Elastic, Sentinel — um endpoint HTTP com um bearer token). A transmissão em fluxo é, por conceção, de melhor esforço: um SIEM em baixo nunca pode bloquear a chamada de uma ferramenta por um agente, e a cópia duradoura e verificável fica de qualquer forma no disco.

Sessões

Uma instalação pode definir uma idade máxima de sessão e um tempo limite de inatividade. Ambos são impostos na verificação das credenciais do dispositivo por onde passam todas as vias autenticadas — uma sessão cujo limite o cliente pudesse ignorar responde a um questionário, não a um atacante. Uma instalação pode também exigir SSO, o que desativa o emparelhamento manual de novos dispositivos (com uma salvaguarda contra o bloqueio: recusa enquanto não existir nenhuma ligação de SSO funcional).

O que isto não é

• Não são ACLs por objeto. Não existe, deliberadamente, qualquer permissão por ticket ou por mensagem. A separação ao nível do repositório é o que as equipas pedem de facto e existe; a partilha por objeto é uma superfície combinatória sem procura demonstrada aqui.
• Não é um motor de políticas que se configure numa DSL. O vocabulário é fechado de propósito, para que toda a política possa ser apresentada, explicada e enumerada.
• Não é imposta em nenhum sítio que não seja o servidor. As verificações do lado do cliente existem apenas para evitar oferecer um controlo que vai ser recusado. A decisão com autoridade é sempre a do servidor.