Autorizare — cine poate face ce și cum o dovedești

Control Center răspunde la două întrebări de autorizare, iar ele sunt cu adevărat diferite. „Poate această persoană să apeleze această operațiune?” ține de oameni, roluri și repository-uri. „Poate acest agent să producă acest efect?” ține de acțiuni, argumente și raza de impact — aceea este Guardrail-uri.

Această pagină tratează prima întrebare, plus urma pe care o lasă amândouă.

Un singur punct de decizie

Fiecare decizie de autorizare din partea oamenilor se rezolvă printr-o singură funcție:

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

O permisiune este <domain>:<tier> — tickets:write, members:administer, repos:read. Catalogul este derivat, nu scris manual: este calculat din însăși suprafața operațiunilor (prefixul numelui operațiunii dă domeniul, pragul de rol pe care îl impune deja dă nivelul), astfel încât toate cele ~550 de operațiuni poartă o permisiune fără ca cineva să tasteze vreuna.

Această derivare este proprietatea care merită protejată. Înseamnă că o operațiune NOUĂ este blocată implicit — modul de eșec al unui model adnotat manual este că cineva uită, iar lucrul pe care îl uită este poarta. Un test de tip ratchet fixează setul de domenii rezultat, astfel încât adăugarea unei operațiuni sub un prefix nou este o decizie de denumire pe care o ia un om, nu un accident.

Cele patru niveluri corespund exact rolurilor predefinite:

Nivel	Prag de rol	Exemplu
read	Invitat	tickets:read
write	Membru	tickets:write
administer	Admin	members:administer
own	Proprietar	workspace:own

Roluri

Cinci roluri predefinite — Proprietar, Admin, Membru, Vizualizator, Invitat — sunt presetări peste acel catalog. Proprietatea este un singur loc per spațiu de lucru, cedat explicit prin Transferă proprietatea (un proprietar care pleacă nu mai poate fi eliminat altfel: deprovisionarea SCIM refuză orice proprietar de spațiu de lucru — transferă mai întâi).

Rolurile personalizate sunt substractive. Un rol personalizat numește o presetare de bază (admin, member, viewer sau guest — niciodată owner) și un set de permisiuni ELIMINATE din ea — „admin, dar nu poate gestiona membri”. Nu poate acorda niciodată mai mult decât baza sa, ceea ce le face sigure de introdus într-o instalare existentă: fiecare verificare existentă rămâne o limită superioară validă. Membrii le dețin ca custom:<id>, iar un client prea vechi ca să înțeleagă acea valoare revine la Invitat în loc să ghicească.

Sub roluri stau permisiunile per repo (none / read / review / write): apartenența la spațiul de lucru nu depășește niciodată în silență privilegiile forge-ului. Fiecare suprafață care expune cod le verifică — inclusiv cele care ajung la cod pe ocolite, cum ar fi un terminal sau o sesiune de editor deschisă pe worktree-ul unui spațiu.

Autoritatea serverului

Unele operațiuni nu privesc deloc un spațiu de lucru: setări la nivel de instalare, configurarea SSO, credențiale de provider, gestionarea modelelor, backupuri ale întregii instalări. Acestea declară autoritate de server și sunt refuzate pentru toată lumea, cu excepția operatorului instalării (proprietarul de server înregistrat). Există în mod deliberat o singură identitate de operator și o singură definiție a acesteia.

Jurnalul de audit

Fiecare decizie de autorizare — permis și refuzat — este adăugată într-un jurnal de audit înlănțuit prin hash, per spațiu de lucru.

Un jurnal doar cu refuzuri răspunde la „ce am blocat?”, dar nu la „ce a făcut de fapt acest agent și cine a autorizat?”, care este întrebarea de la care pornește o analiză de incident. Așa că fiecare înregistrare consemnează întregul lanț de atribuire: principalul care acționează, persoana în numele căreia a acționat, delegarea prin care a ajuns, acțiunea și argumentele ei (ca digest), decizia și regula care a decis.

Înregistrările sunt înlănțuite: hash-ul fiecăreia îl acoperă pe cel al precedentei, astfel încât editarea, ștergerea sau reordonarea oricărui rând rupe fiecare hash de după el. Verifică lanțul rederivă totul și numește prima verigă care nu se susține. Un jurnal de audit pe care nu îl poți verifica este un jurnal; unul pe care îl poți rederiva este o dovadă.

Două consecințe care merită știute:

• Tabelul de audit este exceptat de la curățarea bazată pe vechime. Un lanț de hash-uri nu poate fi scurtat din mijloc. Retenția este export-apoi-trunchiere, iar trunchierea lasă un punct de control care poartă hash-ul terminal al segmentului eliminat, astfel încât ce supraviețuiește se verifică în continuare până la început.
• Stă alături de cronologia activității, nu peste ea. Cronologia arată ce au făcut oamenii; aceasta arată ce a fost autorizat și refuzat. Un id de corelare comun permite citirea unui apel în ambele.

Se exportă ca JSON delimitat prin linii noi și poate transmite în flux către un SIEM (Splunk, Elastic, Sentinel — un endpoint HTTP cu un bearer token). Transmiterea în flux este, prin proiectare, fără garanții: un SIEM picat nu trebuie să blocheze niciodată apelul unui instrument de către un agent, iar copia durabilă și verificabilă este oricum pe disc.

Sesiuni

O instalare poate stabili o vârstă maximă a sesiunii și un timeout de inactivitate. Ambele sunt impuse la verificarea credențialului de dispozitiv prin care trece fiecare cale autentificată — o sesiune pe care un client ar putea să o ignore răspunde la un chestionar, nu unui atacator. O instalare poate cere și SSO, ceea ce dezactivează asocierea manuală pentru dispozitivele noi (cu o protecție împotriva blocării: refuză cât timp nu există nicio conexiune SSO funcțională).

Ce nu este

• Nu sunt ACL-uri per obiect. Nu există în mod deliberat o permisiune per tichet sau per mesaj. Separarea la nivel de repository este ceea ce cer de fapt echipele și ea există; partajarea per obiect este o suprafață combinatorie fără cerere demonstrată aici.
• Nu este un motor de politici pe care îl configurezi într-un DSL. Vocabularul este închis intenționat, astfel încât întreaga politică poate fi redată, explicată și enumerată.
• Nu este impusă nicăieri în afară de server. Verificările din partea clientului există doar pentru a evita oferirea unui control care va fi refuzat. Decizia autoritativă este întotdeauna a serverului.