Modifiche al firewall: chi propone, chi approva, chi registra

Un flusso ordinato per le modifiche al firewall ha tre ruoli distinti: chi propone la modifica con una motivazione, chi l'approva esplicitamente dopo averne visto l'impatto, e chi registra la decisione in modo che sia ritrovabile fra sei mesi. Il caos nasce quando questi tre ruoli coincidono nella stessa persona, nello stesso momento, senza lasciare traccia.

Il debito di regole: come nasce e perché pesa

Le regole di un firewall si accumulano come le scartoffie: una alla volta, sempre per un buon motivo. L'apertura temporanea per il tecnico del climatizzatore. La regola per il vecchio gestionale, rimasta dopo la migrazione. Il permesso concesso in emergenza un venerdì sera, che nessuno ha più rimosso. Ogni regola era ragionevole il giorno in cui è stata creata; l'insieme, dopo qualche anno, non lo capisce più nessuno.

Questo accumulo è un rischio concreto, non solo disordine. Una regola dimenticata può consentire collegamenti che nessuno sorveglia più, perché il servizio che giustificava l'apertura non esiste nemmeno. E quando serve capire se una comunicazione è lecita, nessuno sa rispondere senza un'indagine. Il principio di riferimento è quello della pubblicazione NIST SP 800-207, Zero Trust Architecture: nessuna fiducia implicita e autorizzazione decisa per ogni accesso a una risorsa. Tradotto sul firewall: ogni regola dovrebbe avere uno scopo attuale e un proprietario, non una fiducia ereditata «perché è sempre stata lì». Le reti piatte e le regole troppo larghe sono il contrario di questo principio — se parti da una rete unica, il primo passo può essere la segmentazione della rete in una piccola azienda, come nel caso della separazione tra reception e direzione.

Un flusso ordinato: proposta motivata, approvazione esplicita, applicazione

Il flusso non deve essere burocratico: deve essere leggibile. Ecco una forma che funziona anche in un'azienda con una sola persona IT, purché i ruoli restino distinti.

1. La proposta, con la motivazione

Ogni modifica nasce come proposta scritta: quale regola oggi, quale modifica, quali sistemi coinvolti, perché serve. «Aprire la porta 443 verso il nuovo servizio di fatturazione» è una proposta; «sistemare il firewall» no. La motivazione si lega a un'esigenza di lavoro identificabile, non a una sensazione.

2. L'approvazione, da chi ha il ruolo

Chi approva deve poter vedere l'impatto prima di decidere: quali reti vengono collegate, quali sistemi diventano raggiungibili, quali servizi potrebbero interrompersi se la modifica viene annullata. L'approvazione è esplicita e nominativa — una persona, un sì o un no, una data. Due regole pratiche: chi propone non approva da solo le proprie modifiche, quando l'organico lo consente; e il silenzio non vale come approvazione. Se nessuno risponde, la modifica non si applica.

3. L'applicazione, nel perimetro approvato

L'intervento esegue esattamente ciò che è stato approvato: quella regola, quei sistemi, quella finestra. Se durante l'applicazione emerge la necessità di toccare altro, si torna al passo 1 con una nuova proposta. Dopo l'applicazione, una verifica: la regola fa ciò che doveva, e nient'altro.

4. La registrazione, sempre

Proposta, motivazione, approvazione, esito: tutto resta scritto. Non serve un sistema complesso — serve che sia sistematico. La domanda che il registro deve saper rispondere senza fatica è: «chi ha approvato questa regola, e perché?». Approfondiamo questo punto nell'articolo sulla traccia delle approvazioni delle modifiche al firewall.

Esempio illustrativo: l'apertura verso il nuovo servizio cloud

Esempio illustrativo. Lo scenario seguente è inventato a scopo dimostrativo: non descrive un'azienda o un incidente reale.

Un'azienda adotta un nuovo servizio cloud per le spedizioni. Il responsabile IT prepara la proposta: oggi la rete della logistica non raggiunge servizi esterni se non quelli autorizzati; la modifica consentirebbe ai soli PC del magazzino di contattare il nuovo servizio, sulle sole porte necessarie. La proposta indica sistemi coinvolti, motivazione e un suggerimento di scadenza per la revisione.

La titolare, che ha il ruolo di approvazione sulle modifiche al perimetro, vede l'impatto prima di decidere: cosa diventa raggiungibile, cosa resta isolato, cosa succede se la regola viene rimossa. Approva per iscritto. La modifica viene applicata nel perimetro approvato e verificata; proposta, decisione ed esito finiscono nel registro.

Sei mesi dopo, in occasione di un controllo richiesto da un cliente importante, arriva la domanda: «chi ha deciso queste aperture verso l'esterno?». La risposta non dipende dalla memoria di nessuno: il registro mostra proposta, motivazione, approvazione nominativa ed esito della verifica. Il valore del flusso si misura in quel momento, non il giorno della modifica.

La revisione periodica: il debito si paga a rate

Anche con un flusso perfetto, le regole invecchiano: i servizi cambiano, i fornitori vanno e vengono, le esigenze di un anno fa non sono quelle di oggi. Per questo serve una revisione periodica delle regole attive, con cadenza concordata in base a rischio e ritmo dei cambiamenti — non esiste una frequenza giusta per tutti. La revisione chiede di ogni regola tre cose: serve ancora? Chi ne risponde? Il perimetro è ancora quello minimo necessario?

Le regole che non superano la revisione seguono lo stesso flusso delle altre: proposta di rimozione motivata, approvazione, applicazione, registrazione. Rimuovere una regola è una modifica come un'altra, e va tracciata allo stesso modo — anche perché la rimozione può interrompere qualcosa di ancora in uso, e qualcuno deve averlo valutato prima.

Il ruolo dell'agente e quello del decisore

In OverZeus questo flusso coinvolge tre agenti, con un confine netto tra proposta e decisione:

• Cerberus sorveglia le regole del firewall e la separazione delle reti. Confronta la configurazione con quella precedente, identifica le modifiche e propone le correzioni consentite dalle policy: per esempio, mostra regola, orario, account utilizzato ed effetto sull'accesso ai sistemi riservati prima di qualsiasi intervento. Non riscrive il firewall in autonomia: applica solo ciò che le policy consentono e l'approvazione prevista autorizza.
• Themis applica privilegi, approvazioni e limiti operativi con controlli esterni al modello AI. Se una richiesta di intervento arriva con un'autorizzazione scaduta, blocca l'avvio e richiede una nuova decisione sul piano aggiornato.
• Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti. Se una modifica alla configurazione compare senza un riferimento autorizzativo nelle fonti collegate, segnala la lacuna: è il modo in cui la domanda «chi ha approvato?» trova risposta nel registro e non nella memoria.

Il principio del progetto è «lui si accorge, tu decidi»: gli agenti osservano, spiegano e propongono; la persona approva; il silenzio non autorizza. Come sempre, le operazioni attivabili dipendono dalle integrazioni e dalle policy concordate sul tuo ambiente: quali apparati possono essere osservati nel tuo caso va verificato in fase di progetto.

Dal caos al registro

Riassumendo: il debito di regole si previene con un flusso in cui proposta, approvazione e registrazione hanno ruoli distinti, e si riduce con una revisione periodica che tratta ogni regola come una decisione da confermare. Non serve un'organizzazione grande: serve che ogni modifica lasci scritto chi l'ha proposta, chi l'ha approvata e perché. Se stai valutando strumenti che includono anche questo tipo di supervisione, i criteri di scelta di un SOC AI possono aiutarti a impostare il confronto.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus