Il secondo fattore: 2FA, passkey e codici di recupero
La two-factor authentication (2FA) chiede, oltre alla password, una seconda prova che sei davvero tu. GitHub accetta più metodi: una app mobile TOTP che genera codici a tempo, un codice via SMS, una security key hardware FIDO2 (compresi Touch ID e Windows Hello), un dispositivo su cui hai già effettuato l’accesso a GitHub Mobile, e le passkey. La documentazione raccomanda con forza di attivare il 2FA e, fra i metodi disponibili, di preferire una app TOTP all’SMS, perché il messaggio di testo è il canale più facile da intercettare. Chi contribuisce codice su GitHub.com deve avere almeno una forma di 2FA attiva sul proprio account: non è un consiglio, è un requisito della piattaforma.
Le passkey sono la novità che cambia davvero l’accesso. Tecnicamente sono coppie di chiavi crittografiche: la chiave privata resta nell’authenticator che controlli (telefono, portachiavi del sistema operativo, gestore di password) e non lascia mai il dispositivo; tu ti autentichi con biometria, PIN o password del dispositivo. Il punto che l’esame ama chiedere è questo: una passkey soddisfa sia il requisito della password sia quello del secondo fattore, quindi con una sola operazione l’accesso è completo. Non è “un altro metodo 2FA da aggiungere alla password”: la sostituisce. Inoltre la passkey è legata al dominio del sito, perciò non funziona su una pagina di phishing che imita GitHub, e questo la rende più robusta di TOTP e SMS. Differenza da tenere a mente: una security key è device-bound, vive su quell’oggetto fisico; una passkey può essere sincronizzata fra dispositivi dal provider che la custodisce.
Restano i recovery codes, l’elenco di codici monouso che GitHub ti fa scaricare quando attivi il 2FA. Vanno conservati fuori dal telefono che usa il secondo fattore, idealmente in un gestore di password. Ogni codice si usa una volta sola e, se rigeneri l’elenco, i vecchi codici smettono di funzionare. La raccomandazione ufficiale è configurare due o più metodi di autenticazione proprio per non restare chiusi fuori dal proprio account.
I ruoli sul repository
Su un repository di un account personale i livelli sono soltanto due: il repository owner e i collaborator. La granularità arriva con le organizzazioni, dove ogni repository ha cinque ruoli in scala crescente.
Read è pensato per chi non scrive codice ma vuole leggere e discutere il progetto: può clonare, aprire issue, commentare. Triage aggiunge la gestione della coda di lavoro senza accesso in scrittura: applica label, chiude e riapre issue, segnala i duplicati, nasconde commenti, ma non pusha e non fa merge. Write è il ruolo di chi contribuisce attivamente: push sui branch, merge delle pull request, gestione dei workflow, ma non tocca le impostazioni sensibili come la branch protection. Maintain serve ai responsabili di progetto: gestisce impostazioni del repository, topic e GitHub Pages, restando fuori dalle azioni distruttive o sensibili. Admin ha tutto, inclusi controllo degli accessi, regole di protezione dei branch ed eliminazione del repository.
Organizzazione, team e permessi base
A livello di organizzazione i ruoli hanno nomi diversi e non vanno confusi con quelli del repository. Gli organization owner hanno accesso amministrativo completo e devono essere più di uno. Gli organization member sono il ruolo predefinito. Esistono poi ruoli mirati: moderator per bloccare contributori esterni e nascondere commenti, billing manager per le sole impostazioni di fatturazione, security manager per gli alert di sicurezza con lettura su tutti i repository, GitHub App manager, team maintainer e gli outside collaborator, che hanno accesso a uno o più repository senza essere membri dell’organizzazione.
I team raggruppano le persone e semplificano l’assegnazione degli accessi. Nei team annidati la direzione dell’ereditarietà è una domanda classica: il child team eredita i permessi dal parent team, mai il contrario. Si concede quindi l’accesso ampio in alto e quello più delicato nei rami bassi. I team visible sono visibili e menzionabili da tutti i membri; quelli secret restano nascosti e non possono avere team figli.
Infine le base permissions dell’organizzazione: il livello di accesso che ogni membro riceve automaticamente su tutti i repository. Non si applicano agli outside collaborator e vengono superate da un accesso più alto concesso singolarmente o tramite team. Un’organizzazione che vuole applicare il minimo privilegio abbassa la base permission e concede il resto per team. Gli owner possono anche richiedere il 2FA per tutta l’organizzazione: membri e billing manager senza secondo fattore perdono l’accesso alle risorse finché non lo attivano, mentre gli outside collaborator vengono rimossi e perdono l’accesso ai repository.
Confusioni tipiche da evitare
Tre trappole ricorrenti. Primo: triage non permette di fare merge, gestisce solo la conversazione. Secondo: maintain non è admin, non tocca branch protection né cancella il repository. Terzo: i ruoli di organizzazione e quelli di repository sono piani distinti, ed essere organization owner è cosa diversa dall’essere admin di un singolo repository.