Sicurezza del cloud ibrido: architettura e migliori pratiche

L’architettura di sicurezza del cloud ibrido è il modello che determina dove risiedono i controlli di sicurezza, in che modo le politiche vengono definite una volta per tutte e applicate in modo coerente, e come vengono protetti i dati durante il loro trasferimento tra i sistemi on-premise e i servizi cloud. Un’architettura solida considera l’infrastruttura ibrida come un unico ambiente con numerosi punti di applicazione, non come un data center a cui è stato semplicemente aggiunto un cloud.

La maggior parte delle imprese opera ormai in questo modo. Il rapporto “2026 State of the Cloud” di Flexera ha rilevato che il 73% delle organizzazioni gestisce ambienti ibridi. La presente guida illustra i rischi connessi a tale modello, l’architettura che consente di affrontarli, le decisioni relative all’implementazione e alla protezione dei dati, il ruolo della “ Security Service Edge ” (SSE) e le migliori pratiche e le considerazioni di conformità che ne costituiscono il quadro di riferimento. Ogni sezione rimanda a un articolo di approfondimento. Per una visione più ampia dell’infrastruttura, inclusi i componenti, i modelli di implementazione e i modelli architetturali, si veda «Architettura del cloud ibrido: componenti e modelli di implementazione».

Che cos’è la sicurezza del cloud ibrido?

La sicurezza del cloud ibrido consiste nel proteggere utenti, applicazioni e dati in un ambiente che combina infrastrutture on-premise, cloud privato e cloud pubblico, applicando in modo coerente criteri di gestione delle identità, politiche di sicurezza, protezione dei dati e monitoraggio su tutte queste componenti.

Esso copre quattro aspetti che la sicurezza basata su un unico ambiente non copre:

• Le connessioni tra gli ambienti, comprese le interconnessioni, i tunnel e il traffico che li attraversa.
• Coerenza delle politiche, affinché un utente, un dispositivo o un tipo di dati venga trattato allo stesso modo indipendentemente dal punto in cui viene gestito il traffico.
• Le responsabilità sono ripartite, poiché ogni servizio cloud ripartisce in modo diverso gli obblighi in materia di sicurezza tra il fornitore e il cliente.
• Le decisioni relative al posizionamento, poiché l’organizzazione deve stabilire dove debbano avvenire l’ispezione, la decrittografia e la registrazione per ogni percorso di traffico.

Il cloud ibrido viene spesso confuso con il multi-cloud, che consiste nell’utilizzo di più di un fornitore di cloud pubblico. La maggior parte delle grandi organizzazioni ricorre a entrambe le soluzioni. Si veda “Sicurezza del cloud ibrido e del multi-cloud”.

Vantaggi della sicurezza nel cloud ibrido

Un programma di sicurezza per il cloud ibrido ben progettato offre alle organizzazioni un maggiore controllo rispetto a un approccio basato esclusivamente sul cloud e una maggiore flessibilità rispetto a un approccio basato esclusivamente su infrastrutture on-premise.

Controllo sulla sede di trattamento dei dati. Il traffico soggetto a normative può essere decriptato e ispezionato sull’infrastruttura propria dell’organizzazione, mentre il traffico meno sensibile viene gestito tramite servizi cloud. Ciò semplifica le valutazioni relative alla sovranità e alla privacy. Si veda la sezione “Sovranità dei dati nella sicurezza del cloud ibrido”.

Resilienza operativa. L’applicazione locale delle politiche relative al web e alle applicazioni private continua a funzionare anche in caso di guasto di un provider cloud, di un collegamento WAN o della connessione a Internet. I servizi applicati nel cloud del fornitore, tra cui la protezione dei dati, l’ remote browser isolation, i controlli di sicurezza basati sull’intelligenza artificiale (AI), il CASB e la gestione dello stato di sicurezza dei dati, dipendono dalla raggiungibilità del cloud e riprendono a funzionare non appena il percorso viene ripristinato. Per il traffico sottoposto a controllo a livello locale, la sicurezza non diventa un singolo punto di guasto al di fuori del controllo dell’organizzazione. Si veda “Resilienza dell’SSE ibrido”.

Prestazioni dove contano davvero. Gli utenti in sede, i sistemi dell’impianto e il traffico interno ad alto volume evitano un inutile viaggio di andata e ritorno verso un punto di presenza nel cloud, mentre gli utenti remoti beneficiano di una protezione diretta verso il cloud senza backhaul VPN.

Un percorso di migrazione senza passaggio obbligatorio. Le organizzazioni possono modernizzare i gateway legacy, estendere l’infrastruttura ai servizi cloud e adottare il modello Zero Trust secondo i propri tempi, anziché trasferire tutto il traffico in una sola volta.

Controllo dei costi su larga scala. L’ispezione locale di volumi di traffico interno molto elevati può risultare più economica rispetto all’instradamento di tutto il traffico attraverso un servizio cloud a consumo, mentre il traffico remoto e SaaS beneficia dell’elasticità del cloud.

Protezione uniforme per una forza lavoro distribuita. Grazie a un unico motore di gestione delle politiche, le stesse regole seguono gli utenti ovunque si trovino: in ufficio, in filiale o a casa.

Rischi e sfide legati alla sicurezza del cloud ibrido

Il cloud ibrido è più difficile da proteggere rispetto a un unico ambiente, poiché moltiplica i punti in cui i controlli devono funzionare allo stesso modo.

Il NIST descrive il cambiamento di fondo nella pubblicazione SP 800-215, “Guida a un panorama di rete aziendale sicuro”. Esso individua tre implicazioni per la sicurezza derivanti dall’accesso multi-cloud, dai data center e dalle filiali distribuiti geograficamente e dalle applicazioni distribuite: il perimetro di rete tradizionale scompare, la superficie di attacco cresce con ogni componente aggiuntivo di elaborazione, rete e archiviazione, e gli autori degli attacchi dispongono di un maggior numero di modalità per superare i confini della rete.

I dati relativi alle violazioni riflettono lo stesso andamento. Il rapporto IBM “Cost of a Data Breach Report 2025” ha rilevato che il 30% delle violazioni ha riguardato dati distribuiti su più ambienti (cloud pubblico, cloud privato e on-premise). Tali violazioni hanno rappresentato la categoria più costosa, con una media di 5,05 milioni di dollari, e hanno richiesto il tempo più lungo per essere identificate e contenute, ovvero 276 giorni. Le violazioni relative a dati archiviati esclusivamente in sede hanno comportato un costo medio di 4,01 milioni di dollari. Il rapporto IBM del 2026 stima il costo medio globale di una violazione a un livello record di 4,99 milioni di dollari, cifra inferiore a quella relativa agli ambienti multipli sopra indicata poiché comprende tutti i tipi di violazione anziché limitarsi alla categoria più costosa.

I rischi più comuni per la sicurezza del cloud ibrido sono:

1. Politica incoerente. Lo stesso utente o tipo di dati viene gestito in un modo da un proxy on-premise e in un altro da un servizio cloud, e tale discrepanza passa inosservata fino a quando non si verifica un audit o un incidente.
2. Lacune nella visibilità. I log, gli avvisi e gli inventari dei dati sono gestiti da strumenti distinti, pertanto nessuno è in grado di individuare un attacco che si estende su più ambienti.
3. Espansione incontrollata delle identità. Directory, account di servizio, chiavi API e, ora, agenti di intelligenza artificiale si accumulano a un ritmo più rapido rispetto alle revisioni degli accessi, e ogni ambiente può presentare un proprio “silo” di identità.
4. Configurazione errata. I servizi cloud caratterizzati da impostazioni predefinite troppo permissive, modifiche non verificate e modelli di fornitura diversi creano vulnerabilità che i controlli on-premise non rilevano mai.
5. Responsabilità poco chiare. I team danno per scontato che un fornitore si occupi di qualcosa che in realtà spetta al cliente.
6. Diffusione incontrollata dei dati. I dati sensibili vengono copiati da un ambiente all’altro, nei servizi SaaS e negli strumenti di intelligenza artificiale a un ritmo tale che la classificazione e la governance non riescono a stare al passo.
7. Rischio di concentrazione e di disponibilità. Se l’applicazione delle misure di sicurezza dipende interamente da un unico servizio esterno, un’interruzione di tale servizio blocca il lavoro o compromette la protezione.

L’Agenzia per la Sicurezza Nazionale degli Stati Uniti (NSA) considera la complessità degli ambienti ibridi come un problema a sé stante. Le sue “Dieci principali strategie di mitigazione dei rischi per la sicurezza nel cloud”, pubblicate in collaborazione con la CISA nel marzo 2024, includono una strategia specifica dedicata alle complessità introdotte dagli ambienti ibridi e multi-cloud, oltre a quelle relative alla gestione delle identità, alla gestione delle chiavi, alla segmentazione, alla sicurezza dei dati e alla registrazione degli eventi.

Responsabilità condivisa in un patrimonio ibrido

In un ambiente ibrido, l’organizzazione gestisce contemporaneamente diversi modelli di responsabilità condivisa, mentre la protezione dell’identità e dei dati rimane sempre di sua esclusiva competenza.

Le linee guida della NSA sul modello di responsabilità condivisa avvertono che i clienti spesso presumono che il fornitore si occupi di aspetti della sicurezza che in realtà sono di loro competenza, e che le configurazioni errate e la mancanza di controlli continuano a rappresentare rischi significativi nel cloud.

Due elementi rimangono immutabili: l’identità e i dati. Un’architettura di sicurezza ibrida dovrebbe essere costruita attorno a queste due costanti.

Quanto è sicura l'architettura cloud ibrida?

Un'architettura cloud ibrida può essere sicura quanto un'architettura a ambiente unico e, al contempo, più resiliente, qualora l'identità, le politiche, la protezione dei dati e la visibilità siano uniformate in tutti gli ambienti.

Ciò che rende rischiosi gli ambienti ibridi è la mancanza di uniformità: politiche, strumenti e team diversi per ciascun ambiente. I dati di IBM relativi alle violazioni dimostrano il costo di tale mancanza di uniformità: le violazioni che interessano più ambienti comportano costi maggiori e durano più a lungo rispetto a quelle che coinvolgono esclusivamente ambienti on-premise. Le organizzazioni che unificano questi livelli eliminano gran parte del rischio aggiuntivo e acquisiscono la capacità di mantenere attive localmente le misure di sicurezza critiche in caso di malfunzionamento di un servizio esterno.

Architettura di sicurezza del cloud ibrido: i livelli di controllo

Un’architettura di sicurezza per il cloud ibrido trova la sua struttura ottimale in sei livelli di controllo applicabili a ogni ambiente, in linea con i pilastri del Modello di maturità Zero Trust della CISA.

1. Identità e accesso. Un unico provider di identità autorevole, autenticazione a più fattori (MFA) resistente al phishing e accesso condizionale basato su utente, dispositivo, posizione e rischio. Sono incluse le identità non umane: account di servizio, identità dei carichi di lavoro, token API e agenti di intelligenza artificiale che operano con diritti di accesso a livello di utente.

2. Dispositivi. Lo stato dei dispositivi (gestiti o non gestiti, aggiornati, protetti) dovrebbe influenzare le decisioni relative all’accesso in ogni contesto, non solo per gli utenti remoti.

3. Rete e traffico. Segmentazione, ispezione tramite gruppo di gateway di sicurezza ( secure web gateway , SWG) per il traffico diretto verso Internet, accesso zero-trust ( zero trust network access , ZTNA) per le applicazioni private e controlli firewall tra i segmenti. Questo livello determina inoltre dove il traffico TLS viene decrittografato e ispezionato.

4. Applicazioni e carichi di lavoro. Configurazioni rinforzate, gestione della sicurezza delle infrastrutture cloud, sicurezza delle API e gestione delle vulnerabilità che copre sia i server dei data center che le istanze cloud.

5. Dati. Individuazione e classificazione (compresa la gestione dello stato di sicurezza dei dati, o DSPM), prevenzione delle perdite di dati ( data loss prevention , DLP) su web, SaaS, applicazioni private, endpoint e strumenti di intelligenza artificiale, crittografia e gestione delle chiavi.

6. Visibilità e operazioni. Registrazione centralizzata, analisi comportamentale, risposta automatizzata e “policy-as-code”, affinché le modifiche siano sottoposte a controllo delle versioni e coerenti.

Per una panoramica a livello di diagramma dei componenti, dei flussi di traffico, dei confini di controllo e degli esempi di implementazione, si rimanda all’Architettura di riferimento per la sicurezza del cloud ibrido.

Piano di controllo e piano dati

Il principio fondamentale dell’architettura ibrida consiste nel centralizzare le decisioni relative alle politiche e nel distribuire l’applicazione delle stesse ovunque il traffico effettivamente fluisca.

Le linee guida del NIST sul modello “zero trust”, SP 800-207, distinguono il punto di decisione delle politiche (PDP), che stabilisce se un soggetto possa accedere a una risorsa, dal punto di applicazione delle politiche (PEP), che si trova lungo il percorso del traffico e abilita, monitora o interrompe la connessione.

Tale separazione costituisce la chiave del design ibrido. Le decisioni dovrebbero essere centralizzate, in modo che un unico insieme di regole si applichi ovunque. L’applicazione delle regole dovrebbe invece essere distribuita, in modo che l’ispezione avvenga in un punto di presenza cloud per un utente remoto che accede a un servizio SaaS, su un gateway di filiale per un utente in ufficio e all’interno del data center per il traffico interno che non entra mai in contatto con Internet.

Quando la definizione delle politiche e la loro applicazione vengono separate in prodotti distinti a seconda dell’ambiente, le organizzazioni gestiscono due o tre insiemi di politiche. Tali insiemi tendono a divergere, e tale divergenza può diventare oggetto di rilievi durante gli audit o costituire una via di accesso per le violazioni. Si veda “Politiche di sicurezza coerenti tra cloud e infrastrutture on-premise”.

Decisioni relative all’implementazione: cloud, on-premises o implementazione ibrida

Non esiste un’unica posizione corretta in cui collocare i controlli di sicurezza; la risposta corretta dipende dal traffico e dai dati, e va stabilita in base al carico di lavoro, alla sede o al gruppo di utenti.

La maggior parte delle aziende opta per una soluzione mista. La questione architettonica verte quindi sul fatto che l’applicazione delle politiche nel cloud e in locale condivida un unico motore di politiche oppure operi come stack paralleli. Si vedano i documenti “Gateway web sicuri: cloud vs. on-premises ” e “Implementazione di SSE privati”.

Il posizionamento dell’ispezione TLS merita particolare attenzione. Le linee guida della NSA sulla gestione dei rischi derivanti dall’ispezione TLS raccomandano di decriptare il traffico una sola volta, all’interno della rete aziendale, ed evitare ispezioni ridondanti da parte di proxy collegati in serie. Nelle architetture ibride, ciò implica decidere in modo mirato dove avvenga la decriptazione per ciascun percorso di traffico. Si veda “Ispezione TLS locale vs. ispezione TLS nel cloud”.

Protezione dei dati sia nel cloud che in locale

La protezione dei dati in un ambiente ibrido dipende dalla classificazione dei dati, effettuata una sola volta, e dall’applicazione di tale classificazione in ogni punto in cui i dati possono uscire dal sistema.

1. Individuate i dati. Individuate i dati sensibili presenti nei servizi di archiviazione cloud, nei sistemi SaaS, nei database e nelle condivisioni di file, e mantenete aggiornato tale inventario.
2. Classificare una sola volta. Utilizzare un unico schema di classificazione, in modo che un documento riservato venga trattato allo stesso modo, indipendentemente dal fatto che venga caricato sul web, condiviso in un’applicazione SaaS, incollato in un prompt di intelligenza artificiale generativa o copiato su una chiavetta USB.
3. Applicare la politica su tutti i canali supportati. Applicare una politica DLP comune a tutti i canali supportati (web, cloud, applicazioni private, endpoint e IA) e documentare eventuali integrazioni specifiche per ciascun canale. Si veda la sezione “DLP in ambienti cloud e on-premises”.
4. Collegare la politica di sicurezza alle misure di applicazione. Utilizzare i risultati del DSPM per stabilire quali archivi e set di dati richiedano i controlli più rigorosi. Si veda la sezione “Come funzionano insieme il DSPM e l’SSE”.
5. Controllate dove vengono trattati i dati. Decidete dove avvenga il controllo, quali dati escano dall’ambiente, dove vengano archiviati i registri e chi possa accedere ai contenuti decriptati.

Il ruolo di SSE nella sicurezza del cloud ibrido

Security Service Edge garantisce l'accesso degli utenti al Web, alle applicazioni SaaS e a quelle private e, in un'architettura ibrida, è in grado di applicare le misure di sicurezza sia nel cloud che in locale.

Gartner definisce l’“security service edge ” (SSE) come la protezione dell’accesso al Web, ai servizi cloud e alle applicazioni private, con funzionalità che includono il controllo degli accessi, la protezione dalle minacce, la sicurezza dei dati e il monitoraggio della sicurezza. Gartner descrive l’SSE come una soluzione fornita principalmente tramite cloud, pur sottolineando che può includere componenti on-premise o basati su agenti.

L’SSE integra solitamente SWG, CASB ( cloud access security broker ), ZTNA, DLP e RBI ( remote browser isolation ). Si occupa del livello utente-applicazione di un’architettura ibrida. Non sostituisce la gestione dello stato dei carichi di lavoro, la protezione degli endpoint né la governance delle identità.

Le prime implementazioni di SSE presupponevano che tutto il traffico venisse instradato attraverso il cloud di un fornitore. Ciò si adatta bene agli utenti remoti e al SaaS, ma crea problemi per i dati soggetti a normative, il traffico interno, le operazioni sensibili alla latenza e le organizzazioni che devono continuare a operare durante un’interruzione del servizio cloud. L’analisi di mercato SSE 2026 di Gartner rileva che i fornitori offrono sempre più spesso appliance virtuali o hardware che estendono il piano dati SSE in locale per l’elaborazione del traffico locale e la resilienza nei confronti dei tempi di inattività del cloud, come citato nell’annuncio diSkyhigh Securityrelativo ai risultati del rapporto “ Critical Capabilities ” del 2026.

Si tratta di un modello SSE ibrido: punti di presenza nel cloud e applicazione delle politiche in locale o nelle filiali, gestiti da un unico motore di policy e da un’unica console. Skyhigh Hybrid SSE Mesh rappresenta l’implementazione di tale modello da parte di Skyhigh Security, con un piano dati in locale per l’ispezione TLS locale e lo ZTNA, integrato da CASB, DSPM, DLP e RBI nel cloud.

Soluzioni di sicurezza per il cloud ibrido

Le soluzioni di sicurezza per il cloud ibrido si suddividono in diverse categorie e la maggior parte delle organizzazioni necessita di più di una soluzione.

Nel confrontare i fornitori di soluzioni di sicurezza per il cloud ibrido, la domanda più importante è se l’applicazione delle politiche in locale e nel cloud condivida un unico motore di policy o se si tratti di prodotti distinti sotto un unico marchio. Valutate la flessibilità di implementazione, la protezione dei dati, il controllo delle politiche, l’integrazione, la migrazione e la resilienza, e verificate le affermazioni del fornitore attraverso un proof of concept utilizzando il vostro traffico. Consultate “Soluzioni di sicurezza per il cloud ibrido: come confrontare i fornitori”.

Aspetti normativi e di conformità

La maggior parte dei quadri normativi in materia di conformità non menziona direttamente il cloud ibrido, ma ciascuno di essi prevede controlli che funzionino in modo coerente ovunque si trovino i dati soggetti a regolamentazione e gli utenti.

Ne derivano due implicazioni pratiche. In primo luogo, i revisori chiederanno se i controlli siano coerenti in tutti gli ambienti, cosa più facile da dimostrare con un unico motore di policy e un’unica pipeline di log. In secondo luogo, gli stessi strumenti di sicurezza trattano dati soggetti a regolamentazione, pertanto la loro sede di ispezione, i log e l’accesso dei fornitori rientrano nell’ambito di applicazione. Si veda la mappatura dei controlli nell’Architettura di riferimento per la sicurezza del cloud ibrido.

Migliori pratiche per la sicurezza del cloud ibrido

Le migliori pratiche riportate di seguito trasformano l’architettura in un programma operativo.

1. Effettuate una mappatura prima di procedere alla realizzazione. Effettuate un inventario di utenti, dispositivi, applicazioni, archivi di dati e percorsi di traffico in ogni ambiente, compresi i servizi SaaS e lo “shadow IT”.
2. Documentate la ripartizione delle responsabilità. Per ciascun servizio, indicate per iscritto quali aspetti sono di competenza del fornitore e quali del vostro team. Rivedete tale ripartizione ogni volta che i servizi cambiano livello.
3. Rendete l’identità il principale strumento di controllo. Consolidate i fornitori di identità, rendete obbligatoria l’autenticazione a più fattori (MFA) resistente al phishing e sottoponete gli account di servizio, le identità dei carichi di lavoro e gli agenti di intelligenza artificiale alla stessa governance applicata alle persone.
4. Centralizzare le politiche, distribuire l’applicazione. Definire le regole una sola volta e trasmetterle a ogni punto di applicazione, sia nel cloud che in locale.
5. Eliminare l’affidabilità implicita della rete. Sostituire l’accesso VPN generico con lo ZTNA per singola applicazione, anche per gli utenti in sede, e segmentare le reti interne. Si veda “ZTNA in sede per applicazioni private”.
6. Classificate i dati una sola volta e applicate le regole ovunque. Un unico schema di classificazione, un unico insieme di politiche DLP, applicati al Web, al SaaS, alle applicazioni private, agli strumenti di intelligenza artificiale e agli endpoint.
7. Effettuate l’ispezione TLS in modo mirato. Eseguite la decrittografia una sola volta, il più vicino possibile alla fonte del traffico, e documentate le eccezioni relative alle categorie sensibili dal punto di vista della privacy.
8. Progettate tenendo conto dei possibili guasti. Verificate cosa accade in termini di accesso e ispezione qualora un servizio cloud, un collegamento WAN o un provider di identità non fosse disponibile, e sottoponete il sistema a test in tal senso.
9. Centralizzare la visibilità senza trascurare la giurisdizione di appartenenza. Aggregare i log ai fini del rilevamento, ma stabilire quali log possano uscire da quale giurisdizione.
10. Rilevare costantemente eventuali scostamenti. Considerare le politiche di sicurezza e la configurazione del cloud come codice, assegnare loro una versione e segnalare eventuali discrepanze tra lo stato previsto e quello effettivamente implementato.
11. Modernizzi i gateway legacy in modo ponderato. Sostituisca i proxy giunti a fine vita con un’implementazione parallela e un passaggio graduale, anziché una migrazione “big bang”. Si veda “Secure Web Gateway Migration”. I clienti di Symantec Edge SWG (Blue Coat ProxySG) devono rispettare la scadenza di dicembre 2026 per SGOS 7.3; si vedano “Blue Coat ” e “ProxySG End of Life”, “Blue Coat Alternatives” e il “Blue Coat Modernization Program”.

Fonti

1. Flexera. Rapporto 2026 sullo stato del cloud. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
2. NIST. SP 800-215: Guida alla sicurezza dell’infrastruttura di rete aziendale (novembre 2022). https://csrc.nist.gov/pubs/sp/800/215/final
3. NIST. SP 800-207: Architettura Zero Trust (agosto 2020). https://csrc.nist.gov/pubs/sp/800/207/final
4. CISA. Modello di maturità Zero Trust, versione 2.0. https://www.cisa.gov/zero-trust-maturity-model
5. 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/
6. NSA. Gestione dei rischi derivanti dall’ispezione del protocollo TLS (novembre 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
7. IBM e Ponemon Institute. Rapporto sul costo delle violazioni dei dati 2025. https://www-api.ibm.com/adobe/assets/urn:aaid:aem:607b9590-38e0-4c91-b433-aa8a17f5b5e8/original/as/cost-of-a-data-breach-2025-full-report.pdf
8. IBM e Ponemon Institute. Rapporto sul costo delle violazioni dei dati 2026. https://www.ibm.com/reports/data-breach
9. Gartner. " Security Service Edge " (SSE), Glossario delle tecnologie dell'informazione. https://www.gartner.com/en/information-technology/glossary/security-service-edge-sse
10. Skyhigh Security. “Skyhigh Security , al primo posto nella categoria ‘Casi d’uso avanzati di SSE’ nel rapporto Gartner del 2026 ‘ Critical Capabilities ’ relativo a ‘ Security Service Edge’ ” (5 agosto 2026). https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
11. NIST. Cybersecurity Framework 2.0. https://www.nist.gov/cyberframework
12. 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
13. ISO. ISO/IEC 27001:2022 Sistemi di gestione della sicurezza delle informazioni. https://www.iso.org/standard/27001
14. PCI Security Standards Council. PCI DSS v4.0.1 (archivio documenti). https://www.pcisecuritystandards.org/document_library/
15. Dipartimento della Salute e dei Servizi Umani degli Stati Uniti (HHS) . Norma di sicurezza HIPAA. https://www.hhs.gov/hipaa/for-professionals/security/index.html
16. Unione europea. Regolamento (UE) 2016/679 (GDPR). https://eur-lex.europa.eu/eli/reg/2016/679/oj
17. Unione europea. Regolamento (UE) 2022/2554 (DORA). https://eur-lex.europa.eu/eli/reg/2022/2554/oj