Condividi tramite

Valutare i requisiti sovrani

  • Articolo

Microsoft Cloud Adoption Framework per Azure è un framework per l'intero ciclo di vita che aiuta gli architetti del cloud, i professionisti IT e i decisori aziendali a raggiungere i propri obiettivi di adozione del cloud. Fornisce procedure consigliate, documentazione e strumenti che aiutano a creare e implementare strategie aziendali e tecnologiche per il cloud. Le organizzazioni del settore pubblico che hanno severi requisiti di sovranità possono incorporare i propri obiettivi di sovranità nei propri sforzi di pianificazione, in modo che le decisioni strategiche sull'adozione del cloud siano allineate a tali requisiti di sovranità.

Questo articolo evidenzia le aree in cui le organizzazioni potrebbero voler valutare, identificare e documentare i propri requisiti di sovranità e fornisce raccomandazioni su dove tali requisiti potrebbero inserirsi nelle loro attività di pianificazione più ampie associate al Cloud Adoption Framework per Azure.

Identificare i dati sovrani

I requisiti di sovranità dei dati possono includere mandati per mantenere la proprietà dei dati e specificare metodi per l’archiviazione, l’utilizzo e la trasmissione dei dati. A volte, i requisiti di sovranità dei dati possono includere anche limitazioni o mandati riguardanti la residenza dei dati. Comprendere questi requisiti nelle prime fasi del percorso verso il cloud di un'organizzazione può aiutare a stabilire modelli di progettazione comuni per la sovranità dei dati, anziché aspettarsi che i proprietari dei carichi di lavoro sviluppino soluzioni per soddisfare i requisiti di sovranità.

Le organizzazioni che seguono il Cloud Adoption Framework per Azure identificano i carichi di lavoro candidati per la migrazione al cloud durante la fase di pianificazione e quindi progettano l'ambiente per ospitare questi carichi di lavoro durante la fase di preparazione. Queste attività possono consentire a un'organizzazione di identificare tipi di dati sovrani che richiedono una gestione speciale nell'ambiente cloud dello stato di destinazione.

Microsoft utilizza molti tipi di dati, ad esempio informazioni personali fornite a Microsoft e dati dei clienti caricati nei servizi cloud per fornire servizi online e professionali. Le responsabilità di protezione dei dati di Microsoft sono documentate nell'Addendum sulla protezione dei dati dei prodotti e dei servizi Microsoft (DPA) e incluse negli accordi dell'organizzazione con Microsoft. Il DPA specifica i diversi tipi di dati gestiti da Microsoft e descrive le pratiche utilizzate da Microsoft per proteggere tali tipi di dati.

Molte organizzazioni dispongono già di programmi di governance dei dati che specificano i requisiti per la gestione di dati sensibili e possono utilizzare queste informazioni per determinare se i requisiti di sovranità dei dati si applicano a tutte o solo a un sottoinsieme di classificazioni dei dati. Quando un'organizzazione carica e conserva i propri dati in un servizio cloud, è sua responsabilità classificare, etichettare e gestire accuratamente i dati seguendo i requisiti di gestione dei dati. Alcune organizzazioni potrebbero voler utilizzare l'adozione del cloud come un'opportunità per rivedere i propri programmi di classificazione dei dati.

Per ulteriori informazioni su come la classificazione dei dati si applica all'adozione del cloud, vedi Classificazione dei dati in Azure e Guide alla governance del cloud.

Esempi di requisiti di sovranità dei dati

Le organizzazioni che hanno rigidi requisiti di sovranità dei dati potrebbero dover pianificare alcuni dei seguenti scenari rappresentativi quando eseguono la migrazione dei carichi di lavoro al cloud.

Etichettatura di classificazione dei dati

Le etichette di classificazione identificano le risorse con requisiti di gestione speciali. Sebbene le etichette di classificazione vengano applicate a documenti, possono anche essere applicate a risorse. I clienti possono usare le funzionalità di assegnazione di tag native in Azure per applicare etichette di classificazione a risorse come servizi di calcolo e archivi dati e per strutture logiche in Azure, come sottoscrizioni e gruppi di gestione.

Per ulteriori informazioni, vedi Assegnazione di tag in Azure e Soluzioni Microsoft Purview eDiscovery.

Limiti di classificazione dei dati

Quando un'organizzazione sceglie di aggregare dati (o applicazioni) di una classificazione simile, viene spesso implementato un perimetro di sicurezza che funge da limite della posizione in cui è consentita l'archiviazione dei dati. Quando i clienti distribuiscono carichi di lavoro in Azure, possono usare sottoscrizioni e gruppi di gestione per creare limiti logici nell'ambiente cloud dell'organizzazione. Questi limiti aiutano a mitigare i rischi di riservatezza legati all’accesso non autorizzato e i rischi per la privacy legati all’aggregazione e all’attribuzione di dati.

Le organizzazioni che hanno requisiti di sovranità dei dati rigidi potrebbero voler considerare se vogliono organizzare il proprio ambiente in un modello gerarchico, in cui livelli di privilegi più elevati ereditano livelli di privilegi più bassi (ad esempio, come nel modello Bell-LaPadula) oppure se preferiscono implementare un modello non gerarchico in cui vengono utilizzati controlli di accesso obbligatori per creare limiti che compartimentalizzano parti dell'ambiente dal resto dell'ambiente. Le decisioni su come un'organizzazione gestisce i limiti di classificazione dei dati sono fondamentali durante la progettazione delle zone di destinazione nella fase di preparazione del Cloud Adoption Framework per Azure.

Per ulteriori informazioni, vedi Gruppi di gestione in Azure e Governance dei dati.

Residenza dei dati

Le organizzazioni che devono soddisfare i requisiti di residenza dei dati devono prestare particolare attenzione ai servizi di Azure di cui hanno bisogno per supportare un carico di lavoro e a dove tali servizi sono geograficamente disponibili. I servizi di Azure vengono distribuiti in aree che supportano connessioni di rete a bassa latenza e funzionalità come le zone di disponibilità. Queste aree sono raggruppate in aree geografiche, che forniscono funzionalità aggiuntive di resilienza e ripristino di emergenza.

Se un'organizzazione deve mantenere la residenza dei dati per il proprio carico di lavoro, deve garantire che i servizi di Azure utilizzati siano disponibili nella sua area e area geografica preferite. Inoltre, alcuni servizi vengono distribuiti a livello globale e non offrono la residenza dei dati all'interno di una determinata area o area geografica per i dati archiviati all'interno di tale servizio.

Per ulteriori informazioni sulla residenza dei dati, sulle aree e zone di disponibilità di Azure e sulla disponibilità regionale dei servizi di Azure, vedi gli articoli seguenti:

Proprietà, custodia e portabilità dei dati

I clienti con requisiti di sovranità dei dati rigidi hanno spesso molte domande su chi mantiene la proprietà dei dati archiviati in Azure, chi può accedere a tali dati e cosa succede a tali dati se un cliente sceglie di spostare il proprio carico di lavoro su un'altra piattaforma. Questi requisiti possono variare in termini di ambito e specificità, ma in genere tendono a essere correlati alla questione fondamentale di cosa accade ai dati quando vengono ospitati in un servizio cloud Microsoft.

Per contribuire a rispondere a queste domande ad alto livello e offrire ai clienti un punto di partenza per identificare i requisiti di sovranità dei dati che si applicano ai provider di servizi cloud, Microsoft ha pubblicato una serie di articoli sulla protezione e sulla gestione dei dati dei clienti che pongono molte di queste domande e quegli articoli sono disponibili online nel Centro protezione.

Per ulteriori informazioni, vedi Gestione dei dati in Microsoft.

Gestire la sovranità operativa nel cloud

I requisiti di sovranità operativa possono influire sul modo in cui un ambiente in Azure viene progettato, aggiornato e gestito. Pertanto, è importante comprendere chiaramente questi requisiti prima che i progetti tecnici vengano finalizzati nell'ambito della fase di preparazione del Cloud Adoption Framework per Azure. I requisiti comuni di sovranità operativa possono includere:

  • Limitazioni sull'ubicazione e sulla nazionalità del personale amministrativo.
  • Requisiti di controllo degli accessi che limitano l'accesso privilegiato da parte dei provider di servizi cloud.
  • Mandati per disponibilità elevata e ripristino di emergenza.

È importante comprendere chiaramente l'intento e i rischi mitigati da questi requisiti poiché molti di questi requisiti vengono soddisfatti nel cloud utilizzando metodi diversi da quelli comunemente utilizzati localmente.

Dopo che l'organizzazione identifica i requisiti di sovranità operativa, può selezionare i controlli di sovranità tecnica e amministrativa appropriati per fornire il giusto livello di mitigazione e garanzia del rischio. Quando si selezionano i controlli di sovranità, è importante comprendere che la selezione di alcune funzionalità che possono fornire sovranità operativa aggiuntiva limita le opzioni di un'organizzazione per l'adozione di altri servizi di Azure.

Ad esempio, un'organizzazione che richiede computing riservato per i propri carichi di lavoro di Azure deve limitare le proprie scelte di architettura ai servizi che possono essere eseguiti su Computing riservato di Azure, come macchine virtuali riservate o contenitori riservati. Per questo motivo, spesso è una buona idea associare i requisiti di sovranità operativa a una determinata classificazione dei dati, anziché adottare un approccio in cui tutti i carichi di lavoro e i dati devono soddisfare l'insieme più restrittivo di requisiti di sovranità.

Inoltre, alcuni requisiti di sovranità operativa, come Autarky (ad esempio, la possibilità di funzionare indipendentemente da reti e sistemi esterni) non sono realizzabili in piattaforme di cloud computing di iperscalabilità come Azure, che si basano su aggiornamenti regolari della piattaforma per mantenere i sistemi in uno stato ottimale.

Esempi di requisiti di sovranità operativa

Di seguito sono riportati alcuni requisiti comuni di sovranità operativa insieme ad esempi di servizi e funzionalità di Azure pertinenti che potrebbero soddisfare tali requisiti:

Sicurezza del software

I requisiti di sicurezza del software possono includere attività di sviluppo, come l'applicazione di specifiche misure di sicurezza crittografiche, la conduzione di revisioni del codice e l'esecuzione di test di sicurezza e penetrazione delle applicazioni. Può anche includere processi operativi, come l'implementazione dei controlli di accesso, l'uso di tecnologie di crittografia e il monitoraggio degli eventi di sicurezza.

Microsoft offre varie funzionalità per aiutare i clienti a soddisfare i requisiti di sovranità operativa per il software sviluppato da Microsoft e dai clienti. Microsoft fa riferimento al Secure Development Lifecycle (SDL) quando sviluppa software a livello di piattaforma per Azure. Le 12 pratiche dell'SDL sono integrate nei processi e nelle procedure di progettazione di Microsoft e vengono valutate regolarmente nell'ambito delle attività di garanzia di Microsoft. Inoltre, Microsoft fornisce funzionalità per aiutare i clienti ad adottare le pratiche SDL nell'ambito del ciclo di vita di sviluppo del software.

Per altre informazioni, consulta Microsoft Secure Development Lifecycle e Procedure consigliate per lo sviluppo sicuro in Azure.

Sicurezza dell'infrastruttura

I carichi di lavoro eseguiti in Azure possono utilizzare le numerose funzionalità che Microsoft ha sviluppato per garantire l'integrità della piattaforma. Le funzionalità includono firmware, software e infrastruttura host. Le organizzazioni possono avere requisiti di sovranità operativa per isolare i propri dati dagli operatori cloud. Azure offre funzionalità che i clienti possono utilizzare per sfruttare l'agilità e la resilienza del cloud pubblico mantenendo nel contempo l'isolamento dai provider di servizi cloud e dal relativo personale amministrativo. Le organizzazioni con requisiti relativi all'attestazione a livello hardware, alla verifica dell'integrità del software (ad esempio, avvio sicuro) e alla gestione sicura delle chiavi possono esaminare le pratiche di sicurezza e di integrità della piattaforma di Microsoft e accedere alla documentazione di controllo per convalidare l'implementazione di queste funzionalità.

Per ulteriori informazioni, vedi Integrità e sicurezza della piattaforma e Sicurezza dell'infrastruttura di Azure.

La crittografia per i dati inattivi, in transito e in uso può aiutare a soddisfare un’ampia gamma di requisiti di sovranità operativa relativi alla riservatezza e alla privacy dei dati. Tuttavia, le organizzazioni che richiedono queste funzionalità devono pianificare la creazione e la gestione delle chiavi di crittografia. Azure offre un'ampia gamma di modelli di crittografia di dati inattivi per i clienti, dai metodi di crittografia lato client che forniscono crittografia a conoscenza zero per i dati ospitati nel cloud alle chiavi gestite dal servizio che offrono il massimo grado di interoperabilità con servizi cloud nativi.

Inoltre, le organizzazioni che desiderano ridurre al minimo la necessità di fiducia nei componenti della piattaforma come sistema operativo host, kernel, hypervisor e personale amministrativo possono implementare la crittografia dei dati in uso. Computing riservato di Azure include diversi servizi di calcolo distribuiti in enclavi di sicurezza basate su hardware che crittografano i dati in memoria utilizzando Intel Software Guard Extensions (SGX) o AMD Secure Encrypted Virtualization (SEV-SNP).

Le organizzazioni con requisiti di sovranità operativa che richiedono l'implementazione della crittografia devono acquisire familiarità con le seguenti funzionalità di crittografia in Azure:

Operazioni e resilienza

I requisiti di sicurezza operativa possono applicarsi sia al software a livello di piattaforma creato e gestito da Microsoft per utilizzare la piattaforma Azure sia al software gestito dal cliente che fa parte di un carico di lavoro. Il modello di responsabilità condivisa per il cloud computing sposta la responsabilità amministrativa dal cliente al provider di servizi cloud. A seconda del tipo di servizio cloud utilizzato, Microsoft potrebbe essere responsabile della gestione e dell'aggiornamento dell'infrastruttura bare metal nei nostri data center, dei sistemi operativi e dei tempi di esecuzione dei servizi. L'organizzazione dell'ingegneria della sicurezza di Microsoft implementa un programma di sicurezza operativa che si basa sulle pratiche del Microsoft Secure Development Lifecycle (SDL) con pratiche di sicurezza operativa. Le pratiche includono la gestione dei segreti, i test di penetrazione e il monitoraggio della sicurezza, implementati dal Microsoft Security Response Center.

In rari casi, Microsoft potrebbe richiedere l'accesso ai dati dei clienti per risolvere un problema che potrebbe influire sui servizi. I clienti con requisiti di sovranità operativa relativi al controllo delle modifiche e alla gestione degli accessi privilegiati potrebbero voler abilitare Customer Lockbox per Azure in modo da poter approvare le richieste di accesso nell'ambito dei flussi di lavoro di supporto di Microsoft.

Inoltre, i clienti con requisiti rigorosi per l'approvazione e la pianificazione degli aggiornamenti software della piattaforma potrebbero prendere in considerazione gli host dedicati di Azure, che consentono ai clienti di utilizzare le configurazioni di manutenzione per controllare attività di manutenzione della piattaforma a livello di host. Inoltre, i clienti devono rivedere i propri requisiti di resilienza per determinare se esistono limitazioni basate sulla sovranità per i servizi e le aree utilizzate per ospitare carichi di lavoro.

I requisiti di sovranità operativa relativi alla continuità delle operazioni (ad esempio, richiedendo che i carichi di lavoro siano distribuiti in configurazioni altamente disponibili per mantenere i tempi di attività) possono entrare in conflitto con i requisiti di sovranità dei dati relativi alla residenza dei dati (ad esempio, limitando i carichi di lavoro a un limite geografico che non offre diverse ubicazioni).

Le organizzazioni devono valutare tempestivamente questi requisiti e determinare il modo migliore per bilanciarli.