Governance degli antipattern

Spesso i clienti riscontrano antipattern durante la fase Governance per l'adozione del cloud. È utile dedicare il tempo necessario per comprendere le responsabilità condivise, in modo da evitare gli antipattern, e anche per creare una strategia di sicurezza su framework esistenti anziché crearne di personalizzati.

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 di un'azienda configurano molti server Windows nel cloud usando l'infrastruttura distribuita come servizio (IaaS). Presuppongono che il provider di servizi cloud gestisca gli aggiornamenti, perché l'IT locale gestisce in genere l'installazione degli aggiornamenti. Il reparto risorse umane non configura gli aggiornamenti perché non è a conoscenza del fatto 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 spesso percepiscono la sicurezza come un dato di fatto nel cloud. Anche se questo presupposto è in genere corretto, la maggior parte degli ambienti deve anche rispettare i requisiti del framework di conformità, che possono differire dai requisiti di sicurezza. Azure offre opzioni sicurezza di base e il portale di Azure può fornire opzioni di sicurezza più avanzata tramite Microsoft Defender for Cloud. L'applicazione di uno standard di conformità e sicurezza non è, tuttavia, un'esperienza predefinita quando si crea una sottoscrizione.

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à del CISO per il cloud e indirizzare il Chief Information Security Office (CISO) della propria società a questa guida. Vengono illustrati argomenti quali le risorse della piattaforma di sicurezza, la privacy e i controlli, la conformità e la 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 conformità e sicurezza automatizzati specifici dell'azienda usando Criteri di Azure e Azure Blueprints.

Antipattern: usare un framework di conformità o governance personalizzato

L'introduzione di un framework di conformità e governance personalizzato non basato sugli standard del settore può aumentare notevolmente i tempi di adozione del cloud, perché può essere difficile convertire il framework personalizzato in impostazioni cloud. Questo scenario può aumentare l'impegno necessario per convertire misure e requisiti personalizzati in controlli di sicurezza implementabili. La maggior parte delle aziende deve 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 CIS Controls v7.1 o NIST SP800-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. Altre implementazioni del framework sono disponibili nella pagina degli esempi di Azure Blueprints. Sono disponibili anche progetti per framework di conformità comuni per Azure.

Passaggi successivi