Inizia dal log, non dalle supposizioni
Quando qualcosa sul tuo account GitHub sembra diverso, la prima mossa utile è recuperare un registro che controlli, invece di ricostruire gli eventi a memoria. Il log di sicurezza personale di GitHub è quel registro.
Il log di sicurezza personale di GitHub contiene le azioni degli ultimi 90 giorni. Fonte
Poiché il log è limitato a una finestra recente, esporta presto. Gli eventi che cadono fuori dalla finestra non appariranno in seguito e non puoi recuperarli aspettando.
Dove si trova il log e cosa puoi filtrare
Il log è disponibile nelle Impostazioni dell’account, sotto Archivio, Log di sicurezza, e supporta filtri come attore, repository e azione. Fonte
I filtri contano più del volume grezzo. Restringere per attore, repository o azione ti consente di isolare il periodo e la superficie che ti interessano, invece di scorrere attività di routine non correlate.
Esporta una copia privata prima di analizzare
Il menu Esporta scarica JSON o CSV; i filtri supportati possono restringere l’esportazione. Fonte
Tratta il file esportato come sensibile. Contiene un registro dell’attività dell’account, inclusi attori e azioni, e può rivelare contesti personali o organizzativi. Conservalo in un luogo privato, condividilo solo con chi ti sta aiutando direttamente nelle indagini ed evita di incollarlo in thread pubblici o issue tracker. Se in seguito devi consegnare una copia a un team di supporto della piattaforma, condividi l’esportazione filtrata nel modo più ristretto che risponda alla loro domanda.
Crea un foglio di lavoro per la cronologia dell’incidente
Un’esportazione del log è un elenco di eventi, non una narrazione. Convertila in un foglio di lavoro in modo che osservazioni, interpretazioni e domande aperte restino separate. Una struttura semplice funziona:
| Colonna | Cosa inserire | Perché è importante |
|---|---|---|
| Evento | Un’etichetta breve per ciò che è successo | Rende la riga scansionabile in seguito |
| Ora | Il timestamp come registrato, con il fuso orario annotato | Evita errori di ordinamento |
| Attore | L’account o l’identificatore registrato come agente | Identifica la fonte registrata, non una persona |
| Azione | Ciò che il log dice essere stato fatto | Mantiene la riga fattuale |
| Confidenza | Quanto sei sicuro che questa riga sia pertinente e letta correttamente | Separa le righe solide da quelle speculative |
| Domanda aperta | Cosa devi ancora verificare | Impedisce che le supposizioni si consolidino in fatti |
Compila il foglio di lavoro dall’esportazione, una riga per ogni evento che ritieni pertinente. Usa la colonna della confidenza con onestà: una riga che hai letto direttamente dall’esportazione è più solida di una riga che hai dedotto da un cambiamento notato. Se hai notato un cambiamento ma non riesci a trovare un evento corrispondente, registralo come domanda aperta anziché come conclusione.
Separa le azioni osservate dalla prova di chi le ha compiute
Questo è il punto in cui la maggior parte delle cronologie sbaglia. Una voce nel log ti dice cosa il registro afferma sia successo e quale identificatore di attore è associato. Non stabilisce, da sola, quale essere umano fosse alla tastiera. Dispositivi condivisi, sessioni riutilizzate, credenziali compromesse e automazioni legittime possono tutti produrre voci che sembrano l’azione di una persona.
Tieni due colonne di pensiero nella mente mentre rivedi:
- Osservato: l’evento, l’ora, l’attore e l’azione come registrati.
- Non stabilito: chi lo ha eseguito materialmente, perché, e se l’identificatore dell’attore corrisponde alla persona che supponi.
Scrivi conclusioni nella seconda categoria solo quando hai prove indipendenti. Fino ad allora, appartengono alla colonna delle domande aperte.
Non leggere un evento mancante come prova che non sia successo nulla
Uno spazio vuoto nell’esportazione non è prova di inattività. Il log copre una finestra recente definita e un’esportazione riflette i filtri che hai applicato. Se hai filtrato per un repository, gli eventi in altri repository non appariranno. Se il cambiamento che ti preoccupa è avvenuto fuori dalla finestra, non sarà lì. Registra le assenze come lacune da indagare, non come rassicurazione.
Se hai perso l’accesso
Se non riesci ad accedere per raggiungere il log, smetti di cercare di ricostruire gli eventi dall’esterno e usa la procedura ufficiale di recupero dell’account di GitHub. Il recupero è la strada che ripristina la tua capacità di rivedere l’account. Non chiedere a terzi di accedere all’account per tuo conto e non considerare un semplice reset della password come un’indagine completata; una volta ripristinato l’accesso, esporta il log e costruisci la cronologia per il periodo intorno al cambiamento.
Una breve lista di controllo
- Esporta il log di sicurezza prima che la finestra di 90 giorni avanzi.
- Conserva l’esportazione in privato e annota la data e il fuso orario dell’esportazione.
- Applica i filtri per isolare il periodo e la superficie che ti interessano, poi esporta la vista ristretta se è utile.
- Crea il foglio di lavoro con le colonne evento, ora, attore, azione e confidenza.
- Contrassegna ogni riga come osservata o dedotta e tieni separate le domande aperte.
- Registra gli eventi mancanti come lacune, non come prova che non sia successo nulla.
- Se perdi l’accesso, usa prima il recupero ufficiale, poi torna al punto 1.
Un utile passo successivo
Una volta che hai una cronologia, la domanda successiva è spesso quali altri account sono collegati allo stesso nome o agli stessi identificatori. Questo è un compito diverso dalla lettura di un log di sicurezza e ha un suo metodo: vedi come trovare tutti gli account collegati a un nome. Tieni separate le due indagini in modo che i risultati di una non vengano scambiati per prove nell’altra.