Hardening dell'infrastruttura
Sicuro per impostazione — e lo resta.
Un rapporto pieno di riscontri da solo non cambia nulla. L'hardening è il lavoro che trasforma quei riscontri in una baseline a cui i vostri sistemi sono tenuti — scritta come codice, quindi imposta a ogni rilascio invece che ricordata da chi si trovava lì quel giorno.
Il problema
La configurazione torna indietro.
A marzo qualcuno irrobustisce un server. A luglio un incidente richiede una soluzione rapida, a settembre un nuovo collega copia un vecchio modello, e a dicembre la macchina è più o meno dov'era all'inizio. Nessuno ha sbagliato: semplicemente la baseline non aveva un posto dove vivere.
La soluzione è poco spettacolare: descrivere lo stato voluto come codice, applicarlo automaticamente e rendere visibile lo scostamento appena si presenta. Allora l'hardening è una proprietà del sistema e non un episodio della sua storia.
Imposto, non documentato. Se l'unica traccia di un controllo è un paragrafo in una policy, sarà vero fino alla prima volta che qualcuno ha fretta. Misuriamo l'hardening dal fatto che una modifica non conforme venga respinta, non dal fatto che sia sconsigliata.
Perimetro
Gli strati su cui lavoriamo.
Dall'esterno verso l'interno. Ogni strato ha uno stato obiettivo definito e un modo per verificarlo automaticamente.
- Identità e accessiPrivilegio minimo nella pratica: disegno dei ruoli, ingresso–mobilità–uscita, account di emergenza e secondo fattore dove conta davvero.
- Segmentazione di reteRaggiungibilità ridotta al necessario, verificata provando i percorsi invece che leggendo l'insieme delle regole.
- Gestione dei segretiCredenziali fuori da repository e file di ambiente, ruotate secondo un calendario, con un inventario di ciò che esiste.
- Disciplina di patch e aggiornamentiUna cadenza realistica per la vostra operatività, più un percorso per l'emergenza che non richieda atti di eroismo.
- Registrazione e rilevamentoCopertura dove conta, conservazione che sopravvive a un'indagine e avvisi che una persona leggerà ancora al sesto mese.
- Backup e ripristinoRipristini collaudati, non solo backup riusciti. La differenza si scopre nel momento peggiore possibile.
Sequenza
Dai riscontri alla baseline imposta.
Fissare l'obiettivo
Scegliere la baseline, adattarla alla vostra realtà e mettere per iscritto ogni eccezione voluta con motivo e responsabile.
Mettere in codice
Esprimere lo stato obiettivo in codice di infrastruttura e configurazione, nella vostra catena di strumenti esistente e non in una nuova.
Distribuire a ondate
Prima fuori produzione, poi in produzione per fasi, ciascuna con un ritorno indietro. Un hardening che ferma l'attività non sopravvive.
Tenerlo onesto
Verifiche continue rispetto alla baseline, scostamenti segnalati appena compaiono e una revisione trimestrale delle eccezioni.
Risultati
Che cosa resta sul tavolo alla fine.
Baseline come codice
Nel vostro repository, nella vostra catena di rilascio, revisionabile e reversibile come qualsiasi altra modifica.
Controllo di conformità
Un rapporto automatico su dove la realtà corrisponde alla baseline e dove no, eseguibile su richiesta.
Registro delle eccezioni
Ogni scostamento accettato con il suo motivo, il suo responsabile e la data della prossima revisione.
Un rapporto e nessun piano?
Inviateci i riscontri — i nostri o quelli di altri. Vi diremo quali sono una modifica di configurazione, quali un progetto e quali non valgono lo sforzo.