I ruoli vivono su tre livelli, non su uno

Il primo equivoco da disinnescare è immaginare i ruoli come un elenco unico. In GitHub Enterprise convivono tre piani distinti e la stessa persona può avere assegnazioni su tutti e tre contemporaneamente.

Sull’enterprise account trovi ruoli come enterprise owner, billing manager, app manager e guest collaborator, quest’ultimo disponibile solo negli scenari con Enterprise Managed Users. Chi non ha alcuna assegnazione amministrativa resta un semplice membro. Puoi anche definire ruoli custom con un tuo insieme di permessi sulle impostazioni dell’enterprise, invece di distribuire la proprietà completa a chi ti chiede una sola capacità.

Sull’organizzazione i ruoli predefiniti sono Organization owner, Organization member, Organization moderator, Billing manager, Security manager e GitHub App manager. Chi collabora dall’esterno è Outside collaborator, che però negli enterprise con managed user si chiama repository collaborator: stessa idea, nome diverso nella console.

Sul repository restano i cinque livelli classici: Read, Triage, Write, Maintain, Admin. Sopra di essi agisce la Base permission dell’organizzazione, in Settings > Access > Member privileges, che definisce il minimo che ogni membro ottiene su ogni repository. La direzione conta: una concessione diretta o via team può alzare quel livello, mai abbassarlo, e la base permission non si applica agli outside collaborator. È la trappola più frequente negli scenari di minimo privilegio, perché una base permission generosa vanifica qualunque cura tu metta nei singoli grant.

Quando i cinque livelli sono troppo grossolani intervengono i custom repository roles, che partono obbligatoriamente da un ruolo ereditato fra Read, Triage, Write e Maintain e vi aggiungono permessi puntuali su webhook, deploy key, runner, secret o alert. Sul piano organizzativo i custom organization roles si creano in Settings > Access > Organization roles > Role management e possono contenere solo permessi di organizzazione oppure basarsi su un ruolo repository.

Una precisazione sulla sicurezza: il ruolo Security manager concede lettura su tutti i repository dell’organizzazione, scrittura su tutti gli alert e accesso alla security overview. La documentazione attuale tratta GitHub Secret Protection e GitHub Code Security come prodotti distinti, mentre alcune pagine citano ancora GitHub Advanced Security. Se in una domanda i due nomi compaiono separati, non è un refuso.

Enterprise team: si definiscono in alto, si usano in basso

Gli enterprise team rispondono a un problema pratico: ricreare lo stesso gruppo di persone in dieci organizzazioni è insostenibile. Si creano dall’enterprise, in People > Enterprise teams > Create enterprise team, e poi si aggiungono alle organizzazioni.

Il comportamento da memorizzare è asimmetrico. Quando un enterprise team viene aggiunto a un’organizzazione, i suoi membri entrano senza invito e ricevono la base repository permission dell’organizzazione. Gli amministratori dell’organizzazione possono concedere loro accessi ulteriori, ma non possono rimuovere ciò che è stato concesso a livello di enterprise. È delega verso il basso, non negoziazione.

Due vincoli chiudono il quadro. Gli enterprise team non si annidano, quindi non replicano la gerarchia dei team di organizzazione a cui sei abituato. E la sincronizzazione della membership con un gruppo dell’identity provider è disponibile solo con Enterprise Managed Users: in GHEC con account personali governi la membership dentro GitHub, non dall’IdP. Nello scenario GHEC con data residency, che richiede EMU, il sync resta disponibile.

Ruleset: regole che si sommano, non che si sostituiscono

I ruleset sono l’evoluzione delle branch protection e si definiscono a tre livelli: repository, organizzazione (Settings > Repository > Rulesets > New ruleset) ed enterprise (sezione Policies, poi Code, poi Rulesets).

Ai livelli superiori scegli quali repository colpire: All repositories, Repositories matching a filter usando proprietà di sistema e custom, oppure Repositories matching a name con sintassi fnmatch. Poi indichi i target in Target branches o Target tags. Esistono anche i push ruleset, che agiscono su repository privati e interni e sull’intera rete di fork limitando estensioni, percorsi e dimensione dei file, senza prendere di mira un branch.

Ogni ruleset ha un enforcement status fra Active, Evaluate e Disabled. Evaluate è lo strumento di rollout: osservi che cosa verrebbe bloccato senza bloccare nulla. La Bypass list ammette repository admin, owner di organizzazione ed enterprise, ruoli Maintain o Write, team esclusi quelli segreti, GitHub App e Dependabot.

La differenza sostanziale rispetto alle branch protection è che più ruleset possono insistere sullo stesso branch: le regole si aggregano e vince la versione più restrittiva, mentre delle branch protection ne applicava una sola. In più, chiunque abbia accesso in lettura al repository può vedere i ruleset attivi. Non pensare quindi a una gerarchia in cui l’enterprise sovrascrive l’organizzazione: pensa a strati che si sommano.

Verificare chi ha accesso, e da dove gli arriva

L’ultimo passo è la verifica. Sul repository, Insights > People mostra la vista combinata di team e persone con accesso, ed espone un pulsante Export CSV disponibile su GitHub Enterprise Cloud. Sull’enterprise, la pagina People ha le schede Administrators, Members, Outside collaborators e Invitations, permette di filtrare per ruolo e per stato della verifica in due fattori, segnala gli utenti dormienti e produce un report CSV. Le assegnazioni dei ruoli di organizzazione si rileggono in Role assignments, filtrando per Users o Teams.

L’audit log risponde alla domanda diversa: non chi può, ma chi ha fatto. Si interroga per qualificatori come actor, action, org, repo, created, country, ip e hashed_token, e non accetta ricerche testuali libere. Attenzione ai Git events, che seguono regole di retention proprie e non compaiono nei risultati di ricerca dell’interfaccia: quando rispondi su questo punto, nomina sempre il canale, perché ricerca, REST API e streaming non offrono la stessa copertura. Lo streaming verso destinazioni come Amazon S3, Azure Blob Storage, Azure Event Hubs, Datadog, Google Cloud Storage e Splunk è il modo corretto di conservare l’attività oltre la finestra nativa, con un’opzione dedicata per includere gli eventi di richiesta API. In data residency alcune destinazioni hanno limitazioni, quindi verifica lo scenario prima di prometterla.

L’esame non ti chiede di recitare i ruoli a memoria. Ti descrive una persona e un compito, e ti chiede il modo meno privilegiato di farglielo fare: spesso la risposta corretta è un ruolo custom o un enterprise team, non Admin.