Autorizzazione — chi può fare cosa e come lo dimostri

Control Center risponde a due domande di autorizzazione, e sono davvero diverse. «Questa persona può invocare questa operazione?» riguarda le persone, i ruoli e i repository. «Questo agente può causare questo effetto?» riguarda le azioni, gli argomenti e il raggio d’impatto — e quella è competenza dei Guardrail.

Questa pagina affronta la prima domanda, più la traccia che entrambe lasciano dietro di sé.

Un unico punto di decisione

Ogni decisione di autorizzazione dal lato umano si risolve attraverso un’unica funzione:

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

Un permesso è <domain>:<tier> — tickets:write, members:administer, repos:read. Il catalogo è derivato, non scritto a mano: viene calcolato dalla superficie delle operazioni stessa (il prefisso del nome dell’operazione dà il dominio, il ruolo minimo che essa già applica dà il livello), così tutte le ~550 operazioni portano un permesso senza che nessuno ne digiti uno.

Quella derivazione è la proprietà che vale la pena proteggere. Significa che una operazione NUOVA è soggetta al controllo per impostazione predefinita — il modo in cui fallisce un modello annotato a mano è che qualcuno se ne dimentica, e ciò di cui si dimentica è proprio il controllo. Un test a cricchetto fissa l’insieme dei domini risultante, così aggiungere un’operazione sotto un nuovo prefisso è una decisione di denominazione presa da una persona, non un incidente.

I quattro livelli corrispondono esattamente ai ruoli integrati:

Livello	Ruolo minimo	Esempio
read	Ospite	tickets:read
write	Membro	tickets:write
administer	Admin	members:administer
own	Proprietario	workspace:own

Ruoli

Cinque ruoli integrati — proprietario, admin, membro, osservatore, ospite — sono preimpostazioni su quel catalogo. La proprietà è un unico posto per spazio di lavoro, ceduto in modo esplicito con Trasferisci la proprietà (altrimenti un proprietario che se ne va non è rimovibile: il deprovisioning SCIM rifiuta qualsiasi proprietario di spazio di lavoro — prima trasferisci la proprietà).

I ruoli personalizzati sono sottrattivi. Un ruolo personalizzato indica una preimpostazione di base (admin, member, viewer o guest — mai owner) e un insieme di permessi RIMOSSI da essa — «admin, ma non può gestire i membri». Non può mai concedere più della sua base, ed è questo che li rende sicuri da introdurre in un’installazione esistente: ogni controllo già presente resta un limite superiore valido. I membri li detengono come custom:<id>, e un client troppo vecchio per capire quel valore ricade su ospite invece di tirare a indovinare.

Sotto i ruoli stanno le concessioni per repository (none / read / review / write): l’appartenenza a uno spazio di lavoro non concede mai silenziosamente più privilegi della forge. Ogni superficie che espone codice le verifica — comprese quelle che raggiungono il codice di traverso, come un terminale o una sessione dell’editor aperta sul worktree di uno spazio.

Autorità del server

Alcune operazioni non riguardano affatto uno spazio di lavoro: impostazioni a livello di installazione, configurazione SSO, credenziali dei provider, gestione dei modelli, backup dell’intera installazione. Queste dichiarano autorità del server e vengono rifiutate a chiunque tranne l’operatore dell’installazione (il proprietario del server registrato). Di proposito esistono una sola identità di operatore e una sola definizione della stessa.

Il registro di controllo

Ogni decisione di autorizzazione — consenso e rifiuto — viene aggiunta a un registro di controllo concatenato tramite hash, per singolo spazio di lavoro.

Un registro delle sole negazioni risponde a «cosa abbiamo bloccato?» ma non a «cosa ha fatto davvero questo agente, e chi lo ha autorizzato?», che è la domanda da cui parte la revisione di un incidente. Perciò ogni voce registra l’intera catena di attribuzione: il principale che agisce, la persona per conto della quale ha agito, la delega attraverso cui è arrivato, l’azione e i suoi argomenti (come digest), la decisione e la regola che ha deciso.

Le voci sono concatenate: l’hash di ciascuna copre quello della precedente, quindi modificare, eliminare o riordinare una riga rompe tutti gli hash successivi. Verifica la catena ricalcola l’intero insieme e indica il primo anello che non regge. Un registro di controllo che non puoi verificare è un registro; uno che puoi ricalcolare è una prova.

Due conseguenze che vale la pena conoscere:

• La tabella di controllo è esente dalla pulizia basata sull’età. Una catena di hash non si può tagliare dal mezzo. La conservazione consiste nell’esportare e poi nel troncare, e il troncamento lascia un punto di controllo che porta l’hash terminale del segmento rimosso, così ciò che sopravvive si verifica comunque fino all’inizio.
• Sta accanto alla cronologia delle attività, non sopra di essa. La cronologia è ciò che le persone hanno fatto; questo è ciò che è stato autorizzato e rifiutato. Un id di correlazione condiviso permette di leggere una stessa chiamata in entrambi.

Viene esportato come JSON delimitato da ritorni a capo e può essere inviato in streaming a un SIEM (Splunk, Elastic, Sentinel — un endpoint HTTP con un token bearer). La trasmissione in streaming è, per scelta progettuale, senza garanzie di consegna: un SIEM spento non deve mai bloccare la chiamata a uno strumento da parte di un agente, e in ogni caso la copia durevole e verificabile è su disco.

Sessioni

Un’installazione può impostare un’età massima della sessione e un timeout di inattività. Entrambi vengono applicati al controllo delle credenziali del dispositivo da cui passa ogni canale autenticato — un limite di sessione che un client può ignorare risponde a un questionario, non a un attaccante. Un’installazione può anche richiedere l’SSO, che disattiva l’associazione manuale per i nuovi dispositivi (con una protezione anti-blocco: la richiesta viene rifiutata finché non esiste una connessione SSO funzionante).

Cosa non è questo

• Non sono ACL per oggetto. Non esiste un permesso per ticket o per messaggio, di proposito. La separazione a livello di repository è ciò che i team chiedono davvero, ed esiste; la condivisione per oggetto è una superficie combinatoria senza domanda dimostrata qui.
• Non è un motore di policy che configuri in un DSL. Il vocabolario è chiuso di proposito, così l’intera policy può essere rappresentata, spiegata ed enumerata.
• Non è applicato da nessuna parte se non sul server. I controlli lato client esistono solo per non offrire un comando che verrà rifiutato. La decisione che fa fede è sempre quella del server.