Politiche di sicurezza coerenti sia nel cloud che in ambiente locale
- La gestione ibrida delle politiche prevede un unico insieme di regole definito dall’autore che disciplina l’applicazione sia in locale che nel cloud, con sole eccezioni documentate.
- Quando gli ambienti vengono gestiti separatamente, la deriva delle politiche è la norma; pertanto, per prevenirla è necessario un modello operativo.
- Assegnare i responsabili, assegnare un numero di versione a ogni modifica, procedere all’implementazione per fasi e tenere pronta la procedura di rollback.
- Un registro delle eccezioni e controlli periodici della deriva garantiscono la coerenza tra l’applicazione delle regole a livello locale e quella nel cloud.
- Un unico motore di policy per tutti i punti di applicazione elimina gran parte del lavoro di sincronizzazione e degli errori di traduzione.
La gestione ibrida delle politiche di sicurezza consiste nel definire una politica di sicurezza una sola volta e nell’applicarla in modo coerente a ogni punto di applicazione, che si tratti di un gateway in un data center, di un dispositivo in una filiale o di un punto di presenza nel cloud. L’obiettivo è che un utente, un dispositivo, un tipo di dati o un’applicazione venga trattato allo stesso modo, indipendentemente dal punto di applicazione che gestisce il traffico.
Il presente articolo fa parte della guida alla sicurezza del cloud ibrido.
Perché le politiche tendono a deviare negli ambienti ibridi
Il fenomeno del “drift” si verifica quando lo stesso intento viene implementato separatamente in più di un punto:
- Un gateway locale e un servizio cloud con sintassi delle regole e database delle categorie differenti
- Eccezioni aggiunte con urgenza in un ambiente e mai replicate nell’altro
- Diversi team responsabili delle politiche di sicurezza relative alla rete, al cloud e ai dati
- I dizionari DLP sono stati aggiornati per un canale ma non per l’altro
- Modifiche urgenti apportate direttamente sui dispositivi al di fuori della procedura standard
Il risultato è che la sicurezza dipende dal luogo in cui si trova l’utente. I revisori lo individuano, gli aggressori ne approfittano e la risoluzione dei problemi rallenta poiché nessuno è certo di quale politica sia applicabile. Le “Top Ten Cloud Security Mitigation Strategies” della NSA e della CISA affrontano direttamente questo aspetto, proponendo strategie per un’implementazione automatizzata e sicura tramite l’infrastruttura come codice e per gestire le complessità degli ambienti ibridi e multi-cloud.
Proprietà
Una politica coerente inizia con una chiara attribuzione delle responsabilità per ciascun settore di intervento, che deve avvenire prima della scelta degli strumenti.
| Settore politico | Proprietario tipo | Responsabile dell'approvazione |
|---|---|---|
| Accesso al Web e categorie | Team addetto alla sicurezza di rete o web | Responsabilità in materia di sicurezza, risorse umane per l’uso corretto |
| Accesso riservato alle candidature | Team Identità e accessi | Responsabili delle applicazioni |
| Protezione dei dati (DLP) | Team per la sicurezza dei dati | Titolari dei dati, privacy, conformità |
| Protezione dalle minacce | Operazioni di sicurezza | Leadership in materia di sicurezza |
| Decrittografia TLS e metodi di aggiramento | Team di sicurezza web | Informativa sulla privacy e note legali |
| Eccezioni | Titolare dell’azienda richiedente | Responsabile del settore politico |
Ogni regola dovrebbe ricondursi a un responsabile e a una motivazione aziendale.
Gestione delle versioni
Trattate la politica di sicurezza come se fosse codice, in modo che ogni modifica venga esaminata, registrata e sia reversibile:
- Si raccomanda di archiviare le definizioni delle politiche aziendali in un sistema di controllo delle versioni oppure di utilizzare una piattaforma che conservi la cronologia completa delle versioni.
- Per ogni modifica è necessario indicare una descrizione, un numero di ticket e il nome del responsabile dell'approvazione.
- Si prega di verificare le modifiche prima della distribuzione, includendo un confronto con la versione attuale.
- Vengono creati dei tag in modo che ogni stato di distribuzione possa essere identificato e ripristinato.
I controlli di gestione della configurazione previsti dalla norma NIST SP 800-53 Rev. 5, tra cui la configurazione di riferimento (CM-2) e il controllo delle modifiche alla configurazione (CM-3), si applicano tanto alle politiche di sicurezza quanto ai server. La norma NIST SP 800-128 descrive le pratiche di gestione della configurazione incentrate sulla sicurezza che li supportano.
Lancio
Attuate le modifiche alle politiche in più fasi, in modo che eventuali problemi emergano in un gruppo ristretto prima di interessare tutti:
- Si effettui la verifica in un ambiente di test o mediante uno strumento di simulazione delle politiche.
- Canary per un numero ristretto di utenti o per un unico sito.
- Monitorare i tassi di blocco, gli errori e i ticket dell’help desk rispetto ai valori di riferimento.
- Espandetevi gradualmente in diverse sedi e regioni cloud.
- Si assicuri che ogni punto di applicazione segnali la nuova versione.
Per le modifiche urgenti dettate da una minaccia, definisca un percorso accelerato che consenta comunque di registrare la modifica e di sincronizzarla ovunque.
Eccezioni
È proprio nelle eccezioni che la coerenza si erode più rapidamente.
Mantenere un unico registro delle eccezioni che copra tutti gli ambienti:
- Ambito di applicazione: utenti, gruppi, destinazioni, classi di dati e canali
- Ambienti: a quali punti di applicazione si applica l’eccezione
- Motivazione e proprietario
- Data di scadenza o di revisione
- Controlli di compensazione
Le eccezioni devono essere create nella politica centrale e propagate; non devono mai essere configurate direttamente sui singoli dispositivi.
Controlli di deriva
Il rilevamento delle derive mette a confronto la politica prevista con quella effettivamente implementata.
- Verifica della versione: ogni punto di applicazione comunica la versione attiva della propria politica; si segnala un avviso in caso di discrepanze.
- Differenze di configurazione: esportare periodicamente la configurazione implementata e confrontarla con la linea di riferimento approvata.
- Test comportamentale: esegua i test relativi agli URL e alle applicazioni sul gateway locale, nonché i test di protezione dei dati sul percorso applicato nel cloud verso cui il gateway inoltra i dati, quindi confronti i risultati con la politica da Lei definita.
- Verifica delle eccezioni: confrontare le eccezioni a livello di dispositivo con il registro centrale.
Pianifichi i controlli di deriva almeno una volta alla settimana e dopo ogni finestra di modifica.
Ripristino
Il rollback dovrebbe ripristinare la versione precedente della politica in ogni punto di applicazione con un'unica operazione.
- Si prega di tenere a disposizione la versione precedente della politica, pronta per essere nuovamente distribuita a tutti i punti di applicazione.
- Si definisca chi può autorizzare il rollback e a quali condizioni.
- Si assicuri che il rollback raggiunga i punti di applicazione sia nel cloud che in locale nell'ambito della stessa operazione.
- Si prega di registrare le revoche indicando i motivi e di procedere successivamente a una verifica.
Modelli di sincronizzazione
Esistono quattro modelli di sincronizzazione e il rischio di deriva diminuisce man mano che la gestione delle politiche diventa più unificata.
| Modello | Come funziona | Rischio di deriva |
|---|---|---|
| Gestione separata | Ogni ambiente dispone di una propria console e di regole proprie | Alto |
| Sincronizzazione tramite script | Strumenti per l'esportazione e l'importazione delle regole tra piattaforme | Medio; lacune nella traduzione e problemi di sincronizzazione |
| Elenchi condivisi | Regole distinte, ma elenchi comuni di autorizzazioni e blocchi sincronizzati | Medio |
| Motore unico per le polizze | Un unico regolamento applicato in ogni punto di controllo | Basso |
I motori di policy singoli richiedono comunque controlli di deriva, poiché i dispositivi potrebbero non riuscire ad aggiornarsi, ma eliminano la necessità di conversione tra i linguaggi delle regole.
Lista di controllo per la gestione centralizzata delle politiche di sicurezza
Utilizzi questa lista di controllo per verificare che la gestione delle politiche ibride sia sotto controllo.
- Ogni settore di intervento ha un responsabile e un approvatore
- Tutte le modifiche alle politiche sono contrassegnate da un numero di versione con riferimento al ticket
- Le modifiche vengono implementate in più fasi, con un monitoraggio costante
- Un unico registro delle eccezioni copre tutti gli ambienti
- I punti di applicazione riportano le versioni attive delle politiche
- I controlli di deriva vengono eseguiti secondo un programma prestabilito e a seguito di eventuali modifiche
- Il rollback è documentato e testato
- I test sintetici confermano che una politica definita produce il risultato atteso per ciascuna sessione, nel punto di applicazione che la gestisce
In che modo Skyhigh favorisce l’adozione di una politica ibrida coerente
Skyhigh garantisce la coerenza della politica ibrida inviando un unico insieme di politiche, sotto forma di codice, a ogni punto di applicazione.
Skyhigh utilizza un’architettura “policy-as-code” che distribuisce automaticamente le politiche su dispositivi fisici, sistemi virtuali e nodi cloud, senza necessità di allineamento manuale tra gli ambienti (Skyhigh Security). Il suo SWG ibrido supporta la migrazione con un solo clic delle politiche on-premise verso il cloud e la sincronizzazione in tempo reale delle politiche unificate; inoltre, la tracciabilità delle regole mostra quale politica abbia influito sul traffico di un determinato utente (Skyhigh Security). L’aggiornamento della piattaforma del marzo 2026 ha introdotto una gestione unificata delle politiche indipendente dalla posizione e un framework di politiche programmabile ed estensibile. Attraverso Skyhigh Hybrid SSE Mesh, la politica viene definita una sola volta nella console cloud e si applica a ogni sessione. I controlli « Secure Web Gateway », «Zero Trust Access» e «Secure Browser» vengono applicati in modo nativo sul Secure Service Gateway on-premise, mentre i controlli di sicurezza DLP, CASB, DSPM, RBI e basati sull’intelligenza artificiale vengono applicati tramite il cloud Skyhigh.
Fonti
- NSA e CISA. Le dieci principali strategie di mitigazione dei rischi per la sicurezza nel cloud (7 marzo 2024). https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3699169/nsa-releases-top-ten-cloud-security-mitigation-strategies/
- NIST. SP 800-53 Rev. 5: Misure di sicurezza e di tutela della privacy per i sistemi informativi e le organizzazioni. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST. SP 800-128: Guida alla gestione delle configurazioni dei sistemi informativi incentrata sulla sicurezza. https://csrc.nist.gov/pubs/sp/800/128/upd1/final
- Skyhigh Security. “Modernizzazione dell’ Secure Web Gateway Symantec Edge con Skyhigh Hybrid SSE Mesh” (15 luglio 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
- Skyhigh Security. “L’adozione dell’ibrido è diventata più semplice grazie alla piattaforma Skyhigh SSE” (3 ottobre 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
- Skyhigh Security. “Skyhigh Security annuncia nuove soluzioni per potenziare la rivoluzionaria piattaforma SSE universale” (24 marzo 2026). https://www.skyhighsecurity.com/about/newsroom/newswire/skyhigh-security-announces-new-solutions-to-strengthen-disruptive-universal-sse-platform.html