Infrastruttura e sicurezza

Macchine che si rifanno uguali

Ogni server nasce da ricette versionate, non da una sessione al terminale andata bene. Le procedure stanno nel repository accanto al codice che governano, e ogni scelta strutturale lascia scritto il perché.

Le operazioni distruttive hanno un comportamento dichiarato e ripetibile: rieseguire non deve fare danni, e questo va provato, non sperato.

Il confine è la rete, non la buona fede

Separare i clienti a livello di rete costa più fatica che filtrarli nel codice, ma è l’unico livello che regge quando il codice sbaglia: reti dedicate per ogni cliente e ingresso attraverso un tunnel invece che con porte aperte su internet.

Le credenziali stanno in una cassaforte con certificati a scadenza breve: l’applicazione riceve chiavi generate al momento, non stringhe copiate in un file di configurazione.

Accorgersene prima del cliente

Metriche, controlli che sanno distinguere «acceso» da «funzionante», allarmi che scattano su sintomi utili invece che su ogni sfarfallio. Un allarme che suona sempre è un allarme spento.

Dove ha senso la reazione è automatica e graduale: prima il rimedio leggero, poi quello pesante, e se il problema si ripete si smette di insistere e si chiama una persona. Ogni tentativo resta scritto.

Backup che sappiamo ripristinare, prove che reggono

Un backup non verificato è un file. La prova di ripristino va automatizzata su un database usa e getta e deve controllare anche che le protezioni tornino su davvero — non che esistano, che funzionino.

Gli obiettivi di ripristino (quanto tempo, quanti dati) sono dichiarati per servizio e misurati con esercitazioni periodiche: un numero mai verificato è un desiderio, un numero uscito da una prova è un impegno.

Le stesse cose che tengono in piedi il sistema producono le prove per un audit: registro eventi in sola aggiunta, storico degli incidenti, report periodico. Se per fare una prova serve una persona che esporta a mano, quella prova arriverà tardi.