Chi ha cambiato cosa: una traccia di audit per l'host
Su un host condiviso la domanda più dura dopo un incidente non è cosa si è rotto; è chi ha cambiato cosa prima che si rompesse. Atlas scrive una traccia di audit per le operazioni critiche: attore, azione, ora e risultato, tenuta sull'host in due posti.
Perché chi ha fatto cosa resta di solito senza risposta
Gli strumenti di base disperdono le prove. Il registro attività di PVE conosce alcune operazioni, la history della shell altre, e le modifiche ai file di configurazione spesso non conoscono nulla. Ricostruire una serata significa ricucire timestamp tra tutti e tre.
L'accesso root condiviso peggiora le cose. Quando più persone possono agire come root, le azioni smettono di avere autori; i file di history possono essere modificati dallo stesso potere che ha fatto il cambiamento.
E la maggior parte degli audit avviene nel momento peggiore: dopo un incidente, sotto pressione, con la persona che conosce la risposta che forse è la stessa che lo ha causato.
Ricostruire un incidente a mano
Senza traccia, l'indagine consueta va così:
Leggere il registro attività di PVE intorno alla finestra dell'incidente e annotare cosa ha visto.
Passare al setaccio le history di shell sull'host, sperando che nessuno abbia usato un account condiviso.
Scorrere journalctl sulla stessa finestra e provare a far combaciare i timestamp.
Confrontare le configurazioni attuali con l'ultimo backup per trovare modifiche silenziose.
Chiedere nella chat del team chi ha toccato l'host quel giorno.
Scrivere una nota d'incidente costruita su probabilmente, e andare avanti.
Cosa mette per iscritto Atlas
Le operazioni critiche lasciano una traccia mentre accadono, non un mistero dopo.
Azioni critiche, registrate
Le operazioni che cambiano o mettono a rischio il sistema, lavori distruttivi su storage e rete, terminazioni di processi, azioni sensibili ai privilegi, vengono scritte nella traccia mentre girano.
Attore, azione, ora, risultato
Ogni voce risponde in una volta alle quattro domande dell'incidente: chi l'ha innescata, cosa è girato esattamente, quando, e se è riuscita.
Due copie, resistenti alle manomissioni
Le voci vanno nel journal di sistema, che gli utenti non root non possono riscrivere, e in un file separato. Cancellare le tracce significa batterli entrambi.
Ruoli Proxmox, rispettati
Atlas non inventa un proprio mondo di permessi. Chi può fare cosa viene da utenti e ruoli Proxmox, così la traccia corrisponde a identità reali.
Nessun segreto nel registro
Password e token non vengono mai scritti. La traccia registra che un'azione è avvenuta, non le credenziali che la portavano.
I rilievi arrivano
La sentinella Watch segnala i rilievi critici via mail mentre accadono; la traccia si legge prima dell'incidente, non solo dopo.
Domande frequenti
- Cosa viene registrato esattamente?
- Operazioni critiche e sensibili ai privilegi: modifiche distruttive a storage e rete, segnali ai processi, azioni a livello di servizi e simili. Le letture di routine non fanno rumore nella traccia.
- Un admin può cancellare le proprie tracce?
- La traccia è tenuta due volte: nel journal di sistema, che non si riscrive senza manomissioni a livello root, e in un file separato. Modificare la storia in silenzio smette di essere banale.
- Vengono conservate password o corpi delle richieste?
- No. I segreti non vengono mai scritti nella traccia; le voci portano attore, azione, ora e risultato.
- Dove vive il registro?
- Sull'host, nel journal di sistema più un file separato. Nulla viene spedito a un servizio esterno.
- Usa gli account Proxmox?
- Sì. Atlas rispecchia utenti, gruppi e ruoli Proxmox invece di inventarne di propri; le voci di audit corrispondono alle identità già in uso.
- La registrazione rallenta l'host?
- No. Si registrano solo le operazioni critiche, non ogni clic; la traccia occupa poche righe per azione rischiosa.
Voci collegate
- Ho tolto l'accesso ma è ancora dentro: una sessione non è un permesso Hai tolto il permesso, hai perfino disattivato l'account, e quella persona riesce ancora a fare cose. Non si è rotto nulla: togliere l'accesso e chiudere una sessione sono due azioni distinte.
- Smettere di lavorare come root: la decisione che nessuno impone e che rende di più Lavorare come root non esplode un giorno. Rompe in silenzio due cose: chi indica il registro e dove si ferma un clic sbagliato. La soluzione non è disattivare root, ma togliergli il lavoro quotidiano.
- Il registro di controllo: la risposta a "chi è stato", non a "che cosa è successo" La sorveglianza dice che cosa è successo, il registro di controllo dice chi è stato. Il suo valore compare nei giorni che speri non arrivino mai, e se quel giorno non ce l’hai, non è mai esistito.