Chi ha approvato questa modifica al firewall? Ecco come rispondere

Se la domanda «chi ha approvato questa modifica al firewall?» mette qualcuno in difficoltà, il problema non è la memoria delle persone: è l'assenza di un registro che leghi ogni intervento a una richiesta, un approvatore e un esito. Con un flusso in cui ogni modifica nasce da una proposta motivata e viene registrata quando avviene, la risposta si trova in pochi minuti — anche mesi dopo, anche davanti a un verificatore esterno. Qui vediamo cosa deve contenere quel registro e come comportarsi con urgenze, eccezioni e regole sospette. Se invece ti serve impostare da zero il flusso di richiesta, proposta e approvazione, lo trattiamo nell'articolo sulle modifiche al firewall e approvazioni: qui il punto è rispondere alla domanda quando arriva.

Perché le modifiche senza traccia sono un problema di governance

Un firewall non è un mobile che si sposta una volta all'anno: le regole cambiano per nuovi servizi, fornitori, sedi, esigenze di lavoro. Ogni modifica altera i confini dell'azienda, e un confine spostato senza una decisione documentata è un rischio doppio. Operativo, perché nessuno sa dire se quell'apertura serve ancora. Di responsabilità, perché quando qualcosa va storto — o quando arriva una verifica — la domanda «chi l'ha deciso, e perché?» resta senza risposta.

La logica di riferimento è quella della pubblicazione NIST SP 800-207 sull'architettura zero trust: nessuna fiducia implicita, e ogni accesso autorizzato come decisione distinta, non ereditato «perché ieri c'era». Applicata alle modifiche, significa che ogni intervento sulle regole è una decisione da motivare e registrare al momento, non una variazione tecnica di cui ci si ricorderà. Attenzione: è una logica di riferimento, non una certificazione di prodotto.

Il punto non è la sfiducia verso i tecnici. Un registro chiaro protegge proprio chi lavora: se ogni modifica porta il nome di chi l'ha richiesta e di chi l'ha approvata, nessuno deve difendersi a memoria da un'accusa vaga.

Cosa deve contenere il registro di ogni intervento

Perché il registro regga a una verifica — interna o esterna — ogni modifica al firewall dovrebbe portare con sé questi elementi:

• Richiesta: chi chiede la modifica, per quale esigenza di lavoro, con quale urgenza dichiarata.
• Proposta tecnica: regola attuale, modifica prevista, sistemi e reti coinvolte, effetto sull'accesso.
• Approvazione: chi ha autorizzato, quando, con eventuali condizioni (durata, perimetro ridotto, verifica successiva).
• Esecuzione ed esito: quando la modifica è stata applicata, da quale account, con quale risultato verificato.
• Scadenza o riesame: per aperture temporanee o eccezioni, la data entro cui la regola va revocata o riesaminata.

Se un elemento manca, la lacuna va registrata come tale: un'annotazione onesta («modifica senza riferimento autorizzativo, in verifica») vale più di una ricostruzione compilata dopo. È lo stesso criterio che vale per le evidenze sul controllo degli accessi in ambito ISO 27001.

Esempio illustrativo: la regola senza riferimento trovata in verifica

Esempio illustrativo. Lo scenario seguente è inventato e non racconta un cliente reale.

Una piccola azienda di logistica riceve la verifica di un cliente importante, che chiede conto di come sono gestiti gli accessi da fuori. Il verificatore scorre le regole del firewall e ne trova una che consente il traffico tra la rete degli uffici e il sistema di manutenzione di un fornitore. Domanda: «Chi ha approvato questa regola, e perché?» Con il registro, la risposta non dipende dalla memoria di nessuno. Il registro mostra la data di applicazione e l'account usato, ma anche una lacuna registrata onestamente: «modifica senza riferimento autorizzativo, in verifica». Confrontando le fonti collegate, il responsabile ritrova la richiesta del fornitore e l'autorizzazione data per telefono durante un guasto al sistema delle spedizioni, formalizzata il giorno dopo su un altro canale; il riferimento viene aggiunto al registro conservando la cronologia. Al verificatore l'azienda mostra tutto: la regola, la lacuna, la ricostruzione e la sua chiusura — e la verifica va avanti su fatti, non su ricordi.

Senza registro, la stessa domanda produce un'altra scena: ricerca affannosa nei messaggi, «mi pare fosse il fornitore del magazzino», e una regola che nessuno sa confermare né revocare proprio mentre un osservatore esterno prende appunti. La differenza non è la tecnologia: è dove vive la decisione — e dove vivono anche le lacune, dichiarate invece che nascoste.

Domande frequenti sulla tracciabilità delle modifiche

Come ricostruisco chi ha chiesto e approvato una modifica già applicata?

Parti dalle fonti disponibili: configurazioni precedenti, registri di sistema, richieste e ticket conservati. In OverZeus Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti, e aiuta a ricostruire il percorso di ogni intervento; se una modifica non ha un riferimento autorizzativo nelle fonti collegate, segnala la lacuna senza inventare una ricostruzione. Se il riferimento esiste ma su un altro canale — per esempio un'autorizzazione verbale poi formalizzata — il responsabile lo aggiunge conservando la cronologia.

Cosa faccio quando trovo una regola sospetta senza un responsabile?

Non cancellarla d'istinto: potrebbe servire a un processo legittimo, e rimuoverla potrebbe interrompere il lavoro. Il percorso prudente è: registrare l'anomalia, identificare quali sistemi la usano, chiedere ai possibili proprietari, e solo dopo decidere. In OverZeus Cerberus sorveglia regole del firewall e separazione delle reti, confronta la configurazione con la precedente e mostra regola, orario ed effetto prima di qualsiasi intervento; propone e applica soltanto le correzioni consentite dalle policy, dopo l'approvazione prevista. Per scenari di separazione tra reti vedi anche il caso della separazione tra reception e direzione.

Come gestisco le urgenze, per esempio un guasto la sera?

Con una procedura di emergenza decisa prima: chi può autorizzare un intervento urgente, con quali limiti, e come l'intervento viene registrato e riesaminato il giorno successivo. L'urgenza abbrevia i tempi della decisione, non la cancella. In OverZeus Themis fa rispettare privilegi, approvazioni e limiti operativi con controlli esterni al modello AI: un'operazione che arriva con un'autorizzazione scaduta viene bloccata e richiede una nuova decisione. E il silenzio non autorizza: se nessuno risponde, l'intervento attivo non parte.

Le eccezioni temporanee possono restare aperte «fino a nuovo ordine»?

No, e proprio questo è uno dei controlli più utili: ogni eccezione ha una scadenza o un riesame. «Fino a nuovo ordine» significa in pratica «per sempre»: l'elenco delle eccezioni attive va riesaminato periodicamente come le aperture stesse, come descritto nell'articolo sulle modifiche al firewall e approvazioni.

Il registro resisterà a una verifica esterna?

Se raccoglie richiesta, proposta, approvazione, esecuzione ed esiti con date e responsabili, sì: è esattamente il tipo di evidenza che auditor e verificatori chiedono. Il registro deve anche mostrare le lacune gestite, non solo i percorsi perfetti. Resta tuo il compito di mantenerlo, riesaminarlo e rispondere delle decisioni: lo strumento conserva e ricostruisce, la responsabilità del processo è dell'organizzazione.

Una domanda che smette di fare paura

«Chi ha approvato questa modifica?» diventa una domanda normale quando ogni intervento nasce da una proposta visibile, riceve una decisione registrata e lascia un esito verificabile. Registro e approvazioni non rallentano il lavoro: riducono le discussioni, proteggono le persone e rendono ogni verifica un controllo di ciò che esiste già.

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

Tutti gli articoli OverZeus