Governance degli antipattern
È possibile che si verifichino antipattern durante la fase di governance dell'adozione del cloud. Comprendere le responsabilità condivise e come creare la strategia di sicurezza sui framework esistenti per evitare questi antipattern.
Antipattern: fraintendere le responsabilità condivise
Quando si adotta il cloud, non è sempre chiaro dove finisce la propria responsabilità e inizia quella del provider di servizi cloud per quanto riguarda i diversi modelli di servizio. Per creare processi e procedure sugli elementi di lavoro che usano modelli di servizio, sono necessarie competenze e conoscenze relative al cloud.
Esempio: presupporre che il provider di servizi cloud gestisca gli aggiornamenti
I membri del reparto risorse umane (HR) di un'azienda usano l'infrastruttura distribuita come servizio (IaaS) per configurare più server Windows nel cloud. Presuppongono che il provider di servizi cloud gestisca gli aggiornamenti perché l'IT sul sito gestisce in genere l'installazione degli aggiornamenti. Il reparto risorse umane non configura gli aggiornamenti perché non è a conoscenza che Azure non distribuisce e installa gli aggiornamenti del sistema operativo per impostazione predefinita. Di conseguenza, i server non sono conformi e rappresentano un rischio per la sicurezza.
Risultato preferito: creare un piano di idoneità
Comprendere la responsabilità condivisa nel cloud. Compilare e creare un piano di idoneità. Un piano di idoneità può creare uno sviluppo continuo per l'apprendimento e lo sviluppo di competenze.
Antipattern: presupporre che le soluzioni integrate forniscano sicurezza
Le aziende tendono a vedere la sicurezza come funzionalità intrinseca ai servizi cloud. Anche se questo presupposto è spesso corretto, la maggior parte degli ambienti deve rispettare i requisiti del framework di conformità, che possono differire dai requisiti di sicurezza. Azure offre sicurezza di base e l'portale di Azure può offrire sicurezza più avanzata tramite Microsoft Defender per il cloud. Quando si crea una sottoscrizione, è necessario personalizzare la soluzione per applicare uno standard di conformità e sicurezza.
Esempio: trascurare la sicurezza cloud
Un'azienda sviluppa una nuova applicazione nel cloud. Sceglie un'architettura basata su molti servizi della piattaforma distribuita come servizio e alcuni componenti dell'infrastruttura distribuita come servizio a scopo di debug. Dopo il rilascio dell'applicazione nell'ambiente di produzione, l'azienda si rende conto che uno dei relativi jump server è stato compromesso ed estraeva dati in un indirizzo IP sconosciuto. L'azienda scopre che il problema è l'indirizzo IP pubblico del jump server e una password facile da indovinare. L'azienda avrebbe potuto evitare questa situazione se si fosse concentrata di più sulla sicurezza cloud.
Risultato preferito: definire una strategia di sicurezza cloud
Definire una strategia di sicurezza del cloud appropriata. Per altre informazioni, vedere la guida all'idoneità al cloud CISO. Fare riferimento al chief information security officer (CISO) a questa guida. La guida alla conformità al cloud CISO illustra argomenti quali risorse della piattaforma di sicurezza, privacy e controlli, conformità e trasparenza.
Per informazioni sui carichi di lavoro cloud sicuri, vedere Azure Security Benchmark. Basarsi su CIS Controls v7.1 del Center for Internet Security, insieme a NIST SP800-53 del National Institute of Standards and Technology, che affrontano la maggior parte dei rischi e delle misure di sicurezza.
Usare Microsoft Defender for Cloud per identificare i rischi, adattare le procedure consigliate e migliorare la sicurezza aziendale.
Implementare o supportare requisiti di sicurezza e conformità automatizzati specifici dell'azienda usando Criteri di Azure e l'Criteri di Azure come soluzione code.
Antipattern: usare un framework di conformità o governance personalizzato
L'introduzione di un framework di governance e conformità personalizzato non basato su standard di settore può aumentare notevolmente il tempo di adozione del cloud. Ciò è dovuto al fatto che la conversione dal framework personalizzato alle impostazioni cloud può essere complessa. Questa complessità può aumentare lo sforzo necessario per convertire misure e requisiti personalizzati in controlli di sicurezza implementabili. Le aziende devono in genere rispettare set simili di requisiti di sicurezza e conformità. Di conseguenza, la maggior parte dei framework di conformità e sicurezza personalizzati differisce solo leggermente dai framework di conformità correnti. Le aziende con requisiti di sicurezza aggiuntivi possono prendere in considerazione la creazione di nuovi framework.
Esempio: usare un framework di sicurezza personalizzato
Il CISO di un'azienda assegna ai dipendenti della sicurezza IT l'attività di creare una strategia e un framework di sicurezza cloud. Invece di basarsi sugli standard del settore, il reparto sicurezza IT crea un nuovo framework basato sui criteri di sicurezza locali correnti. Dopo aver completato i criteri di sicurezza cloud, i team di AppOps e DevOps hanno difficoltà a implementare i criteri di sicurezza cloud.
Azure offre una struttura di sicurezza e conformità più completa che differisce dal framework aziendale. Il team CISO pensa che i controlli di Azure non siano compatibili con le proprie regole di conformità e sicurezza. Se avesse basato il framework su controlli standardizzati, non sarebbe arrivato a tale conclusione.
Risultato preferito: affidarsi a framework esistenti
Usare o creare framework esistenti, ad esempio controlli CIS versione 7.1 o NIST SP 800-53, prima di stabilire o introdurre un framework di conformità aziendale personalizzato. I framework esistenti semplificano e misurano la transizione alle impostazioni di sicurezza del cloud. Per altre informazioni sulle implementazioni del framework, vedere Opzioni di implementazione delle zone di destinazione di Azure.