Comprendete il rischio delle policy. Ponete domande sulle policy in linguaggio naturale. Richiedi una demo →

Published:

L'accesso temporaneo non deve diventare policy firewall permanente

Scoprite perché l'accesso temporaneo ai firewall sopravvive allo scopo per cui era stato concesso e come owner, giustificazione, date di scadenza e revisioni periodiche permettono di tenere sotto controllo le regole a tempo.

by FireMon

Gli accessi temporanei hanno la tendenza a diventare permanenti.

Una regola viene creata per un progetto, un fornitore, una migrazione o una richiesta urgente. In quel momento tutti sanno perché esiste. Qualche mese dopo, ritrovare quel contesto è molto più difficile.

Chi l'ha richiesta? Chi l'ha approvata? A quale esigenza di business risponde? L'accesso serve ancora?

Senza queste informazioni, anche una regola firewall tecnicamente corretta diventa difficile da valutare.

Per questo una gestione efficace delle policy non si limita a sapere che cosa consente una regola. I team devono sapere anche perché la regola esiste e chi ne è responsabile.

Documentare il contesto quando la decisione è ancora fresca

Nel video, Rob Rodriguez, Senior Director of Global Field Engineering di FireMon, mostra come documentare il contesto di business di una regola firewall direttamente in Security Manager.

Il contesto può includere informazioni come:

  • Giustificazione di business
  • Business unit
  • Owner della regola
  • Richiedente e approvatore
  • Informazioni di change control
  • Data della prossima revisione
  • Data di scadenza

L'esempio mostrato da Rob è etichettato “Temp Access” e mette in evidenza un problema ricorrente nella gestione delle policy.

Un accesso temporaneo può essere necessario. Il rischio nasce quando non esiste un meccanismo chiaro per stabilire quando quell'accesso deve terminare.

Una data di scadenza o una revisione pianificata crea un checkpoint. Invece di contare sulla memoria di qualcuno mesi dopo la richiesta iniziale, è la policy stessa a contenere le informazioni necessarie per riesaminare la decisione.

Rendere le regole più facili da valutare in futuro

La configurazione tecnica indica che cosa fa una regola firewall.

La documentazione spiega perché esiste.

Una distinzione che pesa sempre di più man mano che gli ambienti crescono e i team cambiano.

Chi rivede una regola sei mesi dopo la sua creazione può non essere stato coinvolto nella richiesta iniziale. L'owner dell'applicazione può aver cambiato ruolo, il progetto può essere concluso, il rapporto con il fornitore può non esistere più.

Senza ownership e giustificazione di business, il team deve ricostruire la storia della regola prima di poter decidere se l'accesso sia ancora appropriato.

Documentare queste informazioni sin dall'inizio rende le revisioni successive molto più semplici.

Invece di chiedersi “qualcuno sa a che serve questa regola?”, i team partono da una finalità documentata, un owner e una scadenza di revisione.

Dare una data di fine agli accessi temporanei

Le regole temporanee meritano un'attenzione particolare, perché la loro finalità originaria è spesso legata a un evento o a un periodo specifico.

Può trattarsi di una finestra di manutenzione, di una migrazione, di una fase di test, di un incarico affidato a terze parti o di un'esigenza di business a breve termine.

Se la regola viene creata senza data di scadenza né processo di revisione, l'accesso può rimanere attivo molto tempo dopo che l'esigenza iniziale è venuta meno.

Un processo migliore collega la regola tecnica al suo ciclo di vita di business.

Quando un accesso ha un owner, una giustificazione e una data di revisione, il team dispone di una base chiara per valutare se mantenerlo.

Questo non significa eliminare automaticamente ogni regola temporanea alla scadenza, ma stabilire un momento di revisione consapevole, invece di lasciare che l'accesso prosegua a tempo indeterminato per inerzia.

Trasformare le regole firewall in decisioni governate

Le policy firewall sono più facili da gestire quando le regole vengono trattate come decisioni di business e non come semplici oggetti di configurazione.

FireMon consente ai team di collegare le policy tecniche alle informazioni su ownership, giustificazione e revisione necessarie per gestire quell'accesso nel tempo.

Il risultato è una tracciabilità più chiara delle ragioni di ogni accesso e un modo più concreto per stabilire se serva ancora.

Perché la domanda non è solo se una regola funziona oggi, ma se domani l'organizzazione comprenderà ancora quell'accesso, ne avrà l'ownership e ne avrà bisogno.

Portate il contesto di business nella gestione delle policy firewall. Scoprite come FireMon Security Manager aiuta i team a comprendere, documentare e governare le policy di sicurezza in ambienti complessi.

Domande frequenti

Un accesso firewall temporaneo diventa permanente quando la regola viene creata senza owner, giustificazione di business, data di scadenza o data di revisione. Al momento della creazione tutti sanno perché esiste. Mesi dopo, il richiedente può aver cambiato ruolo e il progetto può essere concluso. Se nessuno è in grado di dire se l'accesso serva ancora, la regola resta per inerzia.

Quando un accesso temporaneo si prolunga, una regola firewall può essere tecnicamente valida ma difficile da valutare. Il team vede che cosa consente, ma non perché esista né chi ne sia responsabile: l'accesso può così rimanere attivo molto tempo dopo che l'esigenza iniziale è venuta meno. Chi effettua la revisione deve quindi ricostruire la storia della regola prima di poter decidere se l'accesso sia ancora appropriato.

Un accesso firewall temporaneo è di norma legato a un evento o a un periodo specifico: un progetto, una finestra di manutenzione, una migrazione, una fase di test, un incarico a terze parti o a un fornitore, una richiesta urgente o un'esigenza di business a breve termine. Poiché l'esigenza è legata a quell'evento, anche il ciclo di vita della regola dovrebbe esserlo, con una data di revisione o di fine.

Documentate la giustificazione di business, la business unit, l'owner della regola, richiedente e approvatore, le informazioni di change control, la data della prossima revisione e la data di scadenza. Raccogliere questi dati quando la decisione è ancora fresca consente a chi effettuerà la revisione di partire da una finalità e un owner documentati, senza dover ricostruire la storia. FireMon Security Manager permette ai team di registrare questo contesto di business direttamente sulla regola firewall.

Una data di scadenza o una revisione pianificata crea un checkpoint che non dipende dalla memoria di nessuno. Alla scadenza, owner e giustificazione della regola offrono al team una base chiara per decidere se l'accesso debba essere mantenuto, modificato o rimosso. Senza quel checkpoint, un accesso temporaneo tende a proseguire a tempo indeterminato per inerzia.

Non necessariamente. L'indicazione di FireMon è di considerare la data di scadenza come un momento di revisione consapevole, non come un trigger di eliminazione automatica. Alcuni accessi possono essere ancora legittimamente necessari e rimuoverli senza verifica rischia di impattare il business. L'obiettivo è che ogni regola temporanea sia oggetto di una decisione esplicita, invece di restare attiva solo perché nessuno l'ha esaminata.

Partite da quattro domande: chi ha richiesto la regola? Chi l'ha approvata? A quale esigenza di business risponde? Quell'esigenza esiste ancora? Verificate poi se sono cambiati l'owner, l'applicazione, il progetto o il rapporto con il fornitore. Se la regola documenta giustificazione, owner e data di revisione, il team risponde rapidamente, senza dover chiedere se qualcuno sa a che serve.

Serve una soluzione che associ a ogni regola il contesto di business: giustificazione, business unit, owner, richiedente e approvatore, informazioni di change control, date di revisione e date di scadenza. Deve consentire di trattare le regole come decisioni di business governate, con un proprio ciclo di vita, e non come semplici oggetti di configurazione. FireMon Security Manager supporta la documentazione di questo contesto sulle regole firewall, così i team possono riesaminare gli accessi temporanei disponendo di una tracciabilità chiara.

Perché l'accesso temporaneo ai firewall diventa permanente | FireMon