Il catalogo delle credenziali che non sono persone
Ogni volta che qualcosa tocca le tue organizzazioni senza passare da un browser, sta usando una credenziale che tu, come amministratore, devi saper riconoscere e revocare. La documentazione le raccoglie sotto GitHub credential types e le distingue per proprietario, durata e via di revoca: personal access token (classic), fine-grained personal access token, OAuth app token, GitHub App user access token, installation access token, user SSH key, deploy key e il GITHUB_TOKEN generato per ogni job di un workflow.
La distinzione che conta in fase di governo è a chi appartiene la credenziale. Un PAT, un token OAuth e uno user access token sono legati a un account utente: quando la persona lascia l’azienda o perde i permessi, cade anche l’automazione che ci girava sopra. Un installation access token appartiene invece all’installazione dell’app, non a chi l’ha installata, ed è a vita breve: sopravvive all’offboarding e non lascia in giro segreti di lunga durata. È il motivo per cui l’automazione di produzione appoggiata al PAT di un dipendente è sempre un rilievo di sicurezza.
Personal access token: la policy sta nell’enterprise, la falla nei classic
A livello di enterprise le impostazioni vivono sotto Policies e poi Personal access tokens, con le due schede Fine-grained tokens e Tokens (classic). Per l’accesso hai tre scelte: Allow organizations to configure access requirements, che è il default e delega alle organizzazioni; Restrict access via personal access tokens, che impedisce ai token di raggiungere le organizzazioni dell’enterprise; Allow access via personal access tokens. Il punto che l’esame verifica è il secondo ordine di effetti: se l’enterprise sceglie di restringere o di consentire, l’organizzazione non può sovrascrivere la decisione, e la sua configurazione resta visibile ma inefficace.
Sull’approvazione le opzioni sono simmetriche: Allow organizations to configure approval requirements, Require approval e Disable approval. Qui si annida l’errore più costoso: solo i fine-grained personal access token sono soggetti ad approvazione, i token classic no. Un’organizzazione che attiva Require approval convinta di aver messo in coda “tutti i token” ha in realtà lasciato aperta la strada ai classic, che continuano a funzionare senza passare da nessuno. Se vuoi davvero chiudere quella strada, la leva è restringere l’accesso via personal access token, non l’approvazione. Vale anche l’eccezione opposta: i fine-grained token creati da un organization owner non richiedono approvazione, quindi la coda non è mai un registro completo di ciò che accede.
Ci sono altri due dettagli che ricorrono nelle domande. Primo: qualunque sia la policy, i token conservano l’accesso alle risorse pubbliche dell’organizzazione, e un fine-grained token può leggerle anche senza approvazione. “Restricted” non significa invisibile. Secondo: puoi imporre una maximum lifetime ai fine-grained token, mentre i classic non hanno un requisito di scadenza, ed è un’altra ragione per spingerli fuori. La revisione sta in Settings, Personal access tokens, Pending requests: un owner esamina risorse e permessi richiesti e sceglie Approve o Deny, con una motivazione facoltativa recapitata al proprietario del token.
GitHub App e OAuth App: identità propria contro identità presa in prestito
Una GitHub App ha una propria identità di tipo bot, si installa su un’organizzazione o su repository selezionati e chiede permissions granulari, per esempio l’accesso alle issue senza l’accesso ai contenuti del repository. Agisce per conto proprio oppure, quando serve, per conto di un utente. Una OAuth App invece viene autorizzata dall’utente e agisce come l’utente autenticato: chiede scopes ampi e vede tutto ciò che quella persona vede. Da amministratore la conseguenza pratica è che l’app OAuth eredita il raggio d’azione della persona più privilegiata che l’ha autorizzata.
Le due leve di governo sono distinte e non si sostituiscono. Le OAuth app access restrictions obbligano i membri a chiedere l’approvazione degli owner e, quando le attivi per la prima volta, le app già autorizzate perdono immediatamente l’accesso alle risorse dell’organizzazione: mettilo in conto, perché le integrazioni si rompono all’istante. Queste restrizioni però non governano le GitHub App. Per quelle agisci da Member privileges, con Allow repository admins to install GitHub Apps for their repositories e con App access requests, e poi passi in rassegna le app già installate. Confondere le due impostazioni è la trappola tipica dello scenario d’esame.
Rate limit e tracciabilità
I limiti seguono la stessa logica dell’identità. Le richieste non autenticate hanno un budget orario minimo legato all’indirizzo IP. Un personal access token consuma il budget dell’utente, e con lui lo condividono il token di una OAuth App e lo user access token di una GitHub App che agiscono per quella persona: un solo utente può quindi esaurire il proprio limite con tre integrazioni diverse. L’installation access token di una GitHub App ha invece un budget proprio, che scala con il numero di repository e di membri dell’organizzazione ed è più generoso per le organizzazioni di un enterprise. Il GITHUB_TOKEN ha un limite per repository. In risposta trovi gli header x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-used, x-ratelimit-reset e x-ratelimit-resource, oltre ai secondary rate limits su concorrenza e creazione di contenuti.
Per l’indagine post incidente l’audit log espone hashed_token, programmatic_access_type e token_scopes: cerchi con il qualificatore hashed_token e ricostruisci tutto ciò che una singola credenziale ha fatto. Attenzione al limite noto: la ricerca da interfaccia e da REST API non restituisce gli eventi Git, che vanno recuperati esportando l’audit log. Su GitHub Enterprise Server verifica sempre la documentazione della release installata, perché disponibilità e collocazione di queste policy dipendono dalla versione dell’istanza.