Le evidenze si raccolgono prima, non quando servono
L’audit log dell’enterprise aggrega le attività dell’account enterprise e di tutte le organizzazioni che contiene: modifiche alle impostazioni, accessi, appartenenze, permessi delle app. È la fonte di verità per un auditor, ma è una fonte a scadenza: la piattaforma non conserva gli eventi per sempre e, soprattutto, non li conserva tutti per lo stesso tempo.
La distinzione da fissare è fra eventi Git — clone, fetch, push — e tutti gli altri eventi. Gli eventi Git restano consultabili per una finestra di pochi giorni, mentre gli altri eventi restano disponibili per diversi mesi. È esattamente questo il motivo per cui l’audit log dell’interfaccia non può essere il vostro archivio di compliance: se il perimetro normativo vi chiede di dimostrare chi ha clonato un repository un trimestre fa, quel dato non esiste più a meno che non l’abbiate portato fuori nel momento in cui è stato generato. Da amministratore, la conseguenza operativa è che lo streaming o l’export vanno progettati all’onboarding dell’enterprise, non alla prima richiesta dell’ufficio legale.
Attivare lo streaming e verificare la destinazione
Lo streaming dell’audit log si configura dalle impostazioni dell’enterprise, in Settings > Audit log > Log streaming, scegliendo la destinazione dal menu Configure stream. Le destinazioni supportate sono servizi di storage e piattaforme di analisi: Amazon S3, Azure Blob Storage, Azure Event Hubs, Google Cloud Storage, Datadog, Splunk. Ogni provider ha il proprio set di credenziali; per S3 è possibile autenticarsi con access key oppure con OpenID Connect, che evita di conservare segreti di lunga durata.
Prima di salvare, la console offre il pulsante Check endpoint: serve a verificare che GitHub riesca a connettersi e a scrivere sulla destinazione. Non è un passaggio decorativo. Uno stream salvato con credenziali sbagliate non blocca nulla nell’enterprise, semplicemente non consegna: ogni giorno viene eseguito un health check su ciascuno stream e, se la configurazione è errata, gli enterprise owner ricevono una notifica via email; se lo stream non viene sistemato entro pochi giorni gli eventi iniziano a essere scartati. Nel dubbio, usate Check endpoint anche dopo una rotazione di chiavi sul provider.
Due proprietà importanti dello stream. La prima: esporta gli eventi di tutte le organizzazioni dell’enterprise, ma solo a partire dal momento in cui viene abilitato. Non esiste un backfill; ciò che è accaduto prima resta soltanto nell’audit log, con la sua retention. La seconda: si possono configurare più destinazioni contemporaneamente, anche due endpoint dello stesso tipo — per esempio un bucket per il SOC e uno per il team compliance, oppure due provider diversi. I dati partono come file JSON compressi e la consegna è at-least-once: qualche evento può arrivare duplicato, quindi il sistema che riceve deve deduplicare per identificativo, non presumere unicità.
La pausa, il buffer e i dati che si perdono
Uno stream si può mettere in pausa, tipicamente per manutenzione sul sistema ricevente. Durante la pausa GitHub non butta via nulla subito: gli eventi vengono trattenuti in un buffer per un massimo di sette giorni e consegnati quando lo stream viene riattivato. Superata quella finestra, però, il buffer non viene conservato e lo stream riparte dal timestamp corrente: gli eventi del periodo scoperto non arrivano mai a destinazione e, se nel frattempo è scaduta anche la retention lato piattaforma, sono persi definitivamente. Alcune destinazioni riducono ulteriormente il margine, perché accettano log solo se recenti: con Datadog, per esempio, una pausa lunga produce scarti molto prima dei sette giorni.
Vale la pena ricordare che anche la gestione dello streaming è a sua volta tracciata: la categoria audit_log_streaming registra creazione, aggiornamento — inclusi pausa e riattivazione — cancellazione ed esecuzione manuale del check di un endpoint. Chi ha messo in pausa lo stream e quando è quindi una domanda a cui l’audit log sa rispondere.
Export, API e differenze fra scenari di deployment
Accanto allo streaming c’è l’Export, pensato per l’evidenza puntuale: dalla pagina Audit log si filtra la ricerca e si esporta in JSON o CSV, mentre gli eventi Git escono solo come JSON compresso e delimitato da newline. L’export ha limiti di dimensione del file e di tempo di elaborazione: se il risultato li supera, l’operazione fallisce e occorre restringere i filtri. Per volumi seri la risposta corretta è lo streaming, non l’export ripetuto. Esiste anche l’audit log API REST, che richiede un token con lo scope read:audit_log e che restituisce gli eventi Git solo quando li si chiede esplicitamente con il parametro include=git: quando descrivete una procedura, nominate sempre il canale, perché il comportamento predefinito non li include.
Un ultimo controllo da attivare in anticipo: Disclose actor IP addresses in audit logs, che aggiunge l’indirizzo IP dell’attore agli eventi. È una scelta con implicazioni legali sulla conservazione dei dati personali, e il comportamento cambia con lo scenario: con Enterprise Managed Users gli account sono di proprietà dell’enterprise, mentre con account personali le attività fuori dal perimetro dell’enterprise restano escluse. Su GitHub Enterprise Cloud with data residency, che presuppone EMU, alcune varianti di configurazione non sono disponibili — l’autenticazione S3 via OIDC, per esempio. Su GitHub Enterprise Server convivono due meccanismi distinti: il log forwarding dei log di sistema dell’istanza e lo streaming dell’audit log applicativo; sono cose diverse e vanno configurate separatamente, con dettagli che dipendono dalla versione dell’istanza.
L’esame verifica che sappiate distinguere la retention dal buffer di pausa e che ricordiate l’assenza di backfill: la confusione tipica è credere che abilitando uno stream si esportino anche gli eventi storici, o che una pausa prolungata sia innocua perché “tanto i dati sono nell’audit log”.