Procedure consigliate per la sicurezza di Azure

  • Articolo

Questo articolo descrive le procedure consigliate per la sicurezza, basate sulle lezioni apprese dai clienti e dall'esperienza negli ambienti.

Per una presentazione video, vedere Procedure consigliate per la sicurezza di Azure.

1. Persone: informare i team riguardo al percorso di sicurezza del cloud

Il team deve comprendere il percorso che ha intrapreso.

Cosa?

Informare i team IT e della sicurezza sul percorso di sicurezza del cloud e le modifiche da esplorare, tra cui:

  • Minacce nel cloud
  • Il modello di responsabilità condivisa e il modo in cui influisce sulla sicurezza
  • Modifiche alla cultura e ai ruoli e alle responsabilità che in genere derivano dall'adozione del cloud

Perché?

La sicurezza del cloud richiede un cambiamento di mentalità e approccio. Anche se i risultati che la sicurezza fornisce all'organizzazione non cambiano, il modo migliore per raggiungere questi risultati nel cloud può cambiare significativamente.

La transizione al cloud è simile al passaggio da una casa indipendente a un edificio con appartamenti su più piani. L'infrastruttura di base, ad esempio tubature e rete elettrica, rimane la stessa, così come le attività che vengono svolte, ad esempio socializzazione, cucina, TV e Internet e così via. Tuttavia, spesso c'è una differenza in ciò che riguarda l'edificio, chi lo fornisce e lo gestisce e la routine quotidiana.

Chi?

Tutti gli utenti dell'organizzazione it e della sicurezza con responsabilità di sicurezza, dal CIO o DAL CISO ai professionisti tecnici, devono avere familiarità con le modifiche.

Come?

Fornire ai team il contesto necessario per distribuire e operare correttamente durante la transizione all'ambiente cloud.

Microsoft ha pubblicato le lezioni seguenti che i clienti e l'organizzazione IT hanno appreso nel percorso verso il cloud.

Per altre informazioni, vedere Ruoli, responsabilità e responsabilità di Azure Security Benchmark.

2. Persone: istruire i team riguardo alla tecnologia di sicurezza del cloud

Le persone devono capire che direzione stanno prendendo.

Cosa?

Assicurarsi che per i team sia stato definito del tempo da dedicare all'istruzione tecnica sulla protezione delle risorse cloud, tra cui:

  • Tecnologia cloud e tecnologia di sicurezza cloud
  • Configurazioni suggerite e procedure consigliate
  • Dove trovare altri dettagli tecnici

Perché?

I team tecnici devono accedere alle informazioni tecniche per prendere decisioni informate sulla sicurezza. I team tecnici sono in grado di apprendere nuove tecnologie sul lavoro, ma il volume dei dettagli nel cloud spesso sovraccarica la loro capacità di mettere in pratica nella routine quotidiana gli aspetti che hanno appreso.

Definire del tempo da dedicare all'apprendimento tecnico. L'apprendimento garantisce che gli utenti abbiano il tempo necessario per acquisire fiducia nella capacità di valutare la sicurezza del cloud. Aiuta a riflettere su come adattare le competenze e i processi esistenti.

Chi?

Tutti i ruoli di sicurezza e IT che interagiscono direttamente con la tecnologia cloud devono dedicare tempo all'apprendimento tecnico sulle piattaforme cloud e su come proteggerle.

La sicurezza, i responsabili tecnici dell'IT e i project manager possono acquisire familiarità con alcuni dettagli tecnici per la protezione delle risorse cloud. Questa familiarità li aiuta a guidare e coordinare in modo più efficace le iniziative cloud.

Come?

Assicurarsi che i professionisti della sicurezza tecnica abbiano definito un momento da dedicare alla formazione autogestita su come proteggere le risorse cloud. Anche se non è sempre fattibile, fornire accesso al training formale con un docente esperto e ad esercitazioni pratiche.

Importante

I protocolli di identità sono fondamentali per il controllo di accesso nel cloud, ma spesso non sono classificati in ordine di priorità nella sicurezza locale. I team di sicurezza devono concentrarsi sullo sviluppo di familiarità con questi protocolli e log.

Microsoft offre risorse complete per aiutare i professionisti tecnici ad aumentare le proprie capacità. Tali risorse includono:

3. Processo: assegnare la responsabilità per le decisioni sulla sicurezza del cloud

Le decisioni sulla sicurezza non verranno prese se nessuno è responsabile di renderle.

Cosa?

Scegliere chi ha la responsabilità di prendere i diversi tipi di decisioni sulla sicurezza per l'ambiente di Azure aziendale.

Perché?

Una chiara definizione della proprietà delle decisioni relative alla sicurezza accelera l'adozione del cloud e aumenta la sicurezza. La mancanza di proprietà in genere crea attriti perché nessuno si sente autorizzato a prendere decisioni. Nessuno sa a chi rivolgersi per una decisione e nessuno è incentivato a fare ricerche per prendere una decisione ben informata. Gli ostacoli spesso impediscono:

  • Obiettivi aziendali
  • Sequenze temporali per gli sviluppatori
  • Obiettivi IT
  • Garanzie di sicurezza

Gli ostacoli possono comportare:

  • Progetti in stallo che rimangono in attesa dell'approvazione della sicurezza
  • Distribuzioni non sicure che non potevano attendere l'approvazione della sicurezza

Chi?

I dirigenti della sicurezza scelgono i team o i singoli utenti che possono prendere decisioni sulla sicurezza riguardo al cloud.

Come?

Scegliere gruppi o singoli utenti responsabili di prendere decisioni chiave per la sicurezza.

Documentare questi proprietari e le loro informazioni di contatto e comunicare le informazioni all'interno dei team di sicurezza, IT e cloud. In questo modo tutti i ruoli potranno contattarli facilmente.

Queste aree sono in genere quelle in cui sono necessarie decisioni di sicurezza. La tabella seguente illustra la categoria decisionale, la descrizione della categoria e i team che prendono spesso le decisioni.

Decisione Descrizione Team che se ne occupa in genere
Sicurezza di rete Configurare e gestire Firewall di Azure, appliance virtuali di rete e routing associato, web application firewall (WAFs), gruppi di sicurezza di rete, gruppi di sicurezza di rete e così via. Team di sicurezza degli endpoint e dell'infrastruttura incentrato sulla sicurezza di rete
Gestione della rete Gestire l'allocazione della rete virtuale e delle subnet a livello aziendale. Team operativo di rete esistente nelle operazioni IT centrali
Sicurezza degli endpoint server Monitorare e correggere la sicurezza del server, incluse applicazione di patch, configurazione, sicurezza degli endpoint e così via. Team di sicurezza degli endpoint e delle operazioni IT centrali
Monitoraggio e risposta agli eventi imprevisti Analizzare e correggere gli eventi imprevisti di sicurezza nella console SIEM o di origine, tra cui Microsoft Defender per il cloud, Microsoft Entra ID Protection e così via. Team di operazioni per la sicurezza
Gestione dei criteri Impostare la direzione per l'uso del controllo degli accessi in base al ruolo di Azure, Defender per il cloud, strategia di protezione dell'amministratore e Criteri di Azure per gestire le risorse di Azure. Team di criteri e standard e architettura della sicurezza congiuntamente
Standard e sicurezza delle identità Impostare la direzione per le directory di Microsoft Entra, l'utilizzo di PIM/pam, l'autenticazione a più fattori, la configurazione della password/sincronizzazione, gli standard di identità dell'applicazione. Team di gestione delle identità e delle chiavi, criteri e standard e architettura della sicurezza congiuntamente

Nota

  • Assicurarsi che i decision maker dispongano della formazione appropriata nella loro area del cloud per accompagnare questa responsabilità.
  • Assicurarsi che le decisioni siano documentate nei criteri e negli standard per fornire un record e guidare l'organizzazione a lungo termine.

4. Processo: aggiornare i processi di risposta agli eventi imprevisti per il cloud

Pianificare in anticipo. Non c'è tempo per pianificare una situazione di emergenza durante una situazione di emergenza.

Cosa?

Prepararsi per gli eventi imprevisti di sicurezza nella piattaforma cloud di Azure. Questa preparazione include tutti gli strumenti nativi di rilevamento delle minacce adottati. Aggiornare i processi, preparare il team ed esercitarsi con attacchi simulati in modo che possano funzionare al meglio durante l'analisi degli eventi imprevisti, la correzione e la ricerca delle minacce.

Perché?

Gli utenti malintenzionati attivi rappresentano un rischio immediato per l'organizzazione, La situazione può diventare rapidamente difficile da controllare. Rispondere agli attacchi in modo rapido ed efficace. Questo processo di risposta agli eventi imprevisti deve essere efficace per l'intero patrimonio, incluse tutte le piattaforme cloud che ospitano dati aziendali, sistemi e account.

Anche se per molti aspetti sono simili, dal punto di vista tecnico le piattaforme cloud sono diverse dai sistemi locali. I sistemi locali possono interrompere i processi esistenti, in genere perché le informazioni sono disponibili in un formato diverso. Gli analisti della sicurezza potrebbero avere difficoltà a rispondere rapidamente a un ambiente sconosciuto che può rallentarli. Questa affermazione è particolarmente vera se viene eseguito il training solo su architetture locali classiche e approcci forensi di rete/disco.

Chi?

La modernizzazione dei processi di risposta agli eventi imprevisti è in genere guidata dal team di operazioni per la sicurezza. L'impegno è spesso accompagnato dal supporto di altri gruppi che forniscono conoscenze e competenze.

  • Sponsorizzazione: la modernizzazione dei processi è generalmente sponsorizzata dal responsabile delle operazioni per la sicurezza o equivalente.

  • Esecuzione: adattare i processi esistenti o scriverli per la prima volta, è un impegno collaborativo che coinvolge:

    • Operazioni per la sicurezza: il team di gestione degli eventi imprevisti o i dirigenti guidano gli aggiornamenti dei processi e dell'integrazione per gli stakeholder esterni chiave. Questi team includono team legali, di comunicazione o di pubbliche relazioni.
    • Operazioni per la sicurezza: gli analisti della sicurezza forniscono competenze su analisi e valutazione degli eventi imprevisti di natura tecnica.
    • Operazioni IT centrali: questo team fornisce competenze sulla piattaforma cloud in modo diretto, tramite il centro di eccellenza del cloud o attraverso consulenti esterni.

Come?

Aggiornare i processi e preparare il team in modo che sappia cosa fare quando trova un utente malintenzionato attivo.

  • Processi e playbook: adattare i processi esistenti di analisi, correzione e ricerca delle minacce alle differenze nel funzionamento delle piattaforme cloud. Le differenze includono strumenti, origini dati, protocolli di identità e così via di tipo nuovo o diverso.
  • Formazione: istruire gli analisti sulla trasformazione complessiva del cloud, sui dettagli tecnici relativi al funzionamento della piattaforma e sui processi nuovi o aggiornati. Queste informazioni consentono di sapere cosa potrebbe cambiare e dove trovare ciò di cui hanno bisogno.
  • Aree di interesse principali: sebbene siano disponibili molti dettagli descritti nei collegamenti alle risorse, queste aree sono la posizione in cui concentrare l'istruzione e le attività di pianificazione:
    • Modello di responsabilità condivisa e architetture cloud: per un analista della sicurezza, Azure è un data center software-defined che offre molti servizi. Questi servizi includono macchine virtuali e altre diverse da quelle locali, ad esempio database SQL di Azure Funzioni di Azure. I dati migliori si trovano nei log del servizio o nei servizi specializzati nel rilevamento delle minacce. Non si trovano nei log per il sistema operativo/le macchine virtuali sottostanti, che sono gestiti da Microsoft e da vari clienti del servizio. Gli analisti devono comprendere e integrare questo contesto nei flussi di lavoro giornalieri. In questo modo sanno quali dati aspettarsi, dove trovarli e in quali formati sono.
    • Origini dati degli endpoint: ottenere informazioni dettagliate e dati per attacchi e malware nei server ospitati nel cloud è spesso più veloce, più semplice e più preciso con gli strumenti nativi di rilevamento del cloud. Strumenti come Microsoft Defender for Cloud e soluzioni di rilevamento e reazione dagli endpoint (EDR) forniscono dati più precisi rispetto agli approcci tradizionali di accesso diretto al disco. Per gli scenari in cui è possibile e necessario per i processi giudiziari, sono disponibili analisi forensi dirette sul disco. Per altre informazioni, vedere Informatica forense in Azure. Spesso, tuttavia, questo approccio è il modo più inefficiente per rilevare e analizzare gli attacchi.
    • Origini dati di rete e identità: molte funzioni delle piattaforme cloud usano principalmente l'identità per il controllo di accesso. Questo controllo di accesso include l'accesso al portale di Azure, anche se vengono usati in modo esteso i controlli di accesso di rete. Questo controllo di accesso richiede agli analisti di sviluppare una conoscenza dei protocolli di identità cloud per ottenere un quadro completo dell'attività degli utenti malintenzionati e delle attività legittime per supportare l'analisi e la correzione degli eventi imprevisti. Le directory e i protocolli di identità sono diversi da quelli locali. In genere si basano su SAML, OAuth, OpenID Connect e directory cloud invece che su LDAP, Kerberos, NTLM e Active Directory.
    • Esercizi di pratica: l'attacco simulato e la risposta possono aiutare a costruire la memoria muscolare dell'organizzazione e la preparazione tecnica. Forniscono la preparazione per gli analisti della sicurezza, chi indaga sulle minacce, i responsabili degli eventi imprevisti e altri stakeholder dell'organizzazione. L'apprendimento sul lavoro e l'adattamento sono parti naturali della risposta agli eventi imprevisti, ma con l'impegno è possibile ridurre al minimo quanto si dovrà imparare in una situazione di emergenza.

Risorse principali

Per altre informazioni, vedere Il processo di risposta agli eventi imprevisti di Azure Security Benchmark per Azure.

5. Processo: definire la gestione della postura di sicurezza

Prima di tutto è necessario conoscere se stessi.

Cosa?

Assicurarsi di gestire attivamente il problema di sicurezza dell'ambiente di Azure tramite:

  • Assegnazione di una chiara proprietà delle responsabilità a:
    • Monitorare il comportamento di sicurezza
    • Attenuare i rischi per gli asset
  • Automazione e semplificazione di queste attività

Perché?

Identificando e correggendo rapidamente i rischi comuni per la protezione della sicurezza si riducono significativamente i rischi aziendali.

La natura software-defined dei data center cloud consente il monitoraggio continuo dei rischi per la sicurezza, ad esempio vulnerabilità software o errori di configurazione della sicurezza, con strumentazione estesa degli asset. La velocità con cui sviluppatori e team IT possono distribuire macchine virtuali, database e altre risorse crea la necessità di assicurarsi che le risorse siano configurate in modo sicuro e monitorate attivamente.

Queste nuove funzionalità offrono nuove possibilità, ma per realizzarne il valore è necessario assegnare la responsabilità di usarle. L'esecuzione coerente con operazioni cloud in rapida evoluzione richiede che i processi umani siano il più possibile semplici e automatizzati. Vedere il principio di sicurezza "semplicità delle unità".

Nota

L'obiettivo della semplificazione e dell'automazione non è quello di eliminare i processi, ma di rimuovere l'onere delle attività ripetitive dalle persone in modo che possano concentrarsi su attività umane di valore superiore, come coinvolgere e istruire i team IT e DevOps.

Chi?

Questa procedura è generalmente suddivisa in due set di responsabilità:

  • Gestione della postura di sicurezza: questa funzione è spesso un'evoluzione di funzioni esistenti per la governance o la gestione delle vulnerabilità. Il risultato include il monitoraggio della postura di sicurezza complessiva attraverso il punteggio di sicurezza di Microsoft Defender for Cloud e altre origini dati. Include la collaborazione attiva con i proprietari delle risorse per mitigare i rischi e segnalarli ai responsabili della sicurezza.

  • Correzione della sicurezza: assegnare la responsabilità di affrontare questi rischi ai team che si occupano di gestire tali risorse. Questa responsabilità appartiene ai team DevOps che gestiscono le proprie risorse dell'applicazione o ai team specifici della tecnologia nelle operazioni IT centrali:

    • Risorse di calcolo e dell'applicazione
      • Servizi app: team di sviluppo e sicurezza delle applicazioni
      • Contenitori: sviluppo delle applicazioni o operazioni di IT/infrastruttura
      • Macchine virtuali, set di scalabilità, calcolo: operazioni IT/infrastruttura
    • Dati e risorse di archiviazione
      • SQL, Redis, Data Lake Analytics, data lake store: team di database
      • account Archiviazione: Archiviazione e team dell'infrastruttura
    • Risorse per identità e accesso
      • Sottoscrizioni: team di identità
      • Insieme di credenziali delle chiavi: identità o informazioni/team di sicurezza dei dati
    • Risorse di rete: team di sicurezza di rete
    • Sicurezza per IoT: team delle operazioni IoT

Come?

La sicurezza è responsabilità di tutti. Non tutti, tuttavia, sanno quanto è importante, cosa fare e come farlo.

  • I responsabili del rischio per la sicurezza saranno i proprietari delle risorse, che saranno responsabili anche della disponibilità, delle prestazioni, dei costi e di altri fattori che contribuiscono al successo.
  • Supportare i proprietari delle risorse fornendo una chiara comprensione del motivo per cui i rischi per la sicurezza sono importanti per le loro risorse, spiegando cosa possono fare per ridurre i rischi e descrivendo come implementare queste misure con una perdita di produttività minima.

Importante

Le spiegazioni di perché, cosa e come proteggere le risorse sono spesso simili nei diversi tipi di risorse e applicazioni, tuttavia è fondamentale collegarle agli aspetti che ogni team conosce e a cui presta attenzione. I team di sicurezza possono interagire con le controparti IT e DevOps come assistenti attendibili e partner impegnati a garantire il successo a questi team.

Strumenti: il punteggio di sicurezza in Microsoft Defender for Cloud fornisce una valutazione delle più importanti informazioni relative alla sicurezza in Azure per un'ampia gamma di risorse. Questa valutazione può essere il punto iniziale per la gestione della postura e può essere integrata con criteri personalizzati di Azure e altri meccanismi in base alle esigenze.

Frequenza: configurare una cadenza regolare (in genere mensile) per esaminare il punteggio di sicurezza di Azure e pianificare le iniziative con obiettivi di miglioramento specifici. La frequenza può essere aumentata in base alle esigenze.

Suggerimento

Se possibile, trasformare l'attività in un gioco per aumentare il coinvolgimento, ad esempio creando gare divertenti e assegnando premi ai team DevOps che aumentano maggiormente il punteggio.

Per altre informazioni, vedere la strategia di gestione del comportamento di sicurezza di Azure Security Benchmark.

6. Tecnologia: richiedere l'autenticazione a più fattori o senza password

Si è disposti a scommettere sulla sicurezza della propria azienda che gli utenti malintenzionati professionisti non riusciranno a indovinare o sottrarre la password dell'amministratore?

Cosa?

Richiedere a tutti gli amministratori con impatto critico di usare l'autenticazione senza password o a più fattori.

Perché?

Proprio come gli scheletri antichi chiavi non proteggeranno una casa da un furto moderno, le password non possono proteggere gli account da attacchi comuni. Per informazioni tecniche, vedere Il tuo pa$$word non è importante.

Un tempo l'autenticazione a più fattori era un passaggio aggiuntivo pesante. Oggi gli approcci senza password migliorano il modo in cui gli utenti eseguono l'accesso usando approcci biometrici come il riconoscimento facciale in Windows Hello e nei dispositivi mobili. Inoltre, gli approcci Zero Trust memorizzano i dispositivi considerati attendibili. Questo metodo riduce la richiesta di azioni di autenticazione a più fattori fuori banda fastidiose. Per altre informazioni, vedere Frequenza di accesso utente.

Chi?

L'iniziativa a più fattori e con password è in genere guidata da team di gestione delle identità e delle chiavi o da architettura di sicurezza.

Come?

Implementare l'autenticazione a più fattori o senza password. Formare gli amministratori su come usarlo in base alle esigenze e richiedere agli amministratori di seguire i criteri scritti. Usare una o più di queste tecnologie:

Nota

Attualmente, per gli utenti malintenzionati è relativamente economico ignorare l'autenticazione a più fattori basata su SMS, quindi è necessario concentrarsi sull'autenticazione a più fattori e senza password più avanzata.

Per altre informazioni, vedere i controlli di autenticazione avanzata di Azure Security Benchmark per tutti gli accessi basati su ID di Microsoft Entra.

7. Tecnologia: integrare la sicurezza di rete e firewall nativa

Semplificare la protezione dei sistemi e dei dati dagli attacchi di rete.

Cosa?

Semplificare la strategia di sicurezza di rete e la manutenzione integrando Firewall di Azure, firewall app Web (WAF) di Azure e mitigazioni Distributed Denial of Service (DDoS) nell'approccio alla sicurezza di rete.

Perché?

La semplicità è fondamentale per la sicurezza, perché riduce la probabilità di rischio derivante da confusione, errori di configurazione e altri errori umani. Vedere il principio di sicurezza "semplicità delle unità".

Firewall e WAF sono importanti controlli di sicurezza di base per proteggere le applicazioni dal traffico dannoso, ma la configurazione e la manutenzione possono essere complesse e occupare una quantità significativa di tempo e attenzione del team di sicurezza (come per l'aggiunta di parti personalizzate di mercato secondario a un'automobile). Le funzionalità native di Azure possono semplificare l'implementazione e il funzionamento di firewall, web application firewall, mitigazioni Distributed Denial of Service (DDoS) e altro ancora.

Questa procedura può liberare il tempo e l'attenzione del team per consentire di dedicarsi ad attività di sicurezza di valore più elevato, ad esempio:

  • Valutazione della sicurezza dei servizi di Azure
  • Automazione delle operazioni per la sicurezza
  • Integrazione della sicurezza con applicazioni e soluzioni IT

Chi?

  • Sponsorizzazione: la leadership della sicurezza o la leadership IT sponsorizzano in genere l'aggiornamento della strategia di sicurezza di rete.
  • Esecuzione: l'integrazione di strategie nella strategia di sicurezza della rete cloud è un impegno collaborativo che coinvolge:
    • Architettura di sicurezza: stabilisce l'architettura di sicurezza della rete cloud con rete cloud e lead di sicurezza di rete cloud.
    • La rete cloud conduce le operazioni IT centrali e il team responsabile della sicurezza dell'infrastruttura cloud
      • Stabiliscono un'architettura di sicurezza della rete cloud con gli architetti della sicurezza.
      • Configurano le funzionalità di firewall, NSG e WAF e collaborano con gli architetti delle applicazioni sulle regole WAF.
    • Architetti delle applicazioni: collaborano con la sicurezza di rete per creare e perfezionare set di regole WAF e configurazioni DDoS per proteggere l'applicazione senza compromettere la disponibilità

Come?

Le organizzazioni che vogliono semplificare le operazioni hanno due opzioni:

  • Estendere le funzionalità e le architetture esistenti: spesso molte organizzazioni scelgono di estendere l'uso delle funzionalità esistenti del firewall in modo da poter capitalizzare sugli investimenti esistenti in competenze e integrazione dei processi, in particolare quando adottano per la prima volta il cloud.
  • Adottare controlli di sicurezza nativi: sempre più organizzazioni iniziano a preferire l'uso di controlli nativi per evitare la complessità di integrare le funzionalità di terze parti. Queste organizzazioni in genere cercano di evitare il rischio di una configurazione errata nel bilanciamento del carico, nelle route definite dall'utente, nel firewall o nel WAF stesso e nei ritardi nei passaggi tra team tecnici diversi. Questa opzione è convincente per le organizzazioni che adottano l'infrastruttura quando si avvicina il codice perché permettono più facilmente di automatizzare e instrumentare le funzionalità incorporate rispetto alle funzionalità di terze parti.

La documentazione sulle funzionalità di sicurezza della rete native di Azure è disponibile in:

Azure Marketplace include molti provider di firewall di terze parti.

Per altre informazioni, vedere Protezione DDOS di Azure Security Benchmark e protezione del web application firewall.

8. Tecnologia: integrare il rilevamento nativo delle minacce

Semplificare il rilevamento e la risposta degli attacchi contro i sistemi e i dati di Azure.

Cosa?

Semplificare la strategia di rilevamento delle minacce e risposta incorporando funzionalità native di rilevamento delle minacce nelle operazioni per la sicurezza e nelle informazioni di sicurezza e gestione degli eventi.

Perché?

Lo scopo delle operazioni per la sicurezza è ridurre l'impatto degli utenti malintenzionati attivi che accedono all'ambiente. L'impatto viene misurato in base al tempo medio richiesto per riconoscere (MTTA) e correggere (MTTR) gli eventi imprevisti. Questa procedura richiede accuratezza e velocità in tutti gli elementi della risposta agli eventi imprevisti. Il risultato consente di garantire che la qualità degli strumenti e l'efficienza dell'esecuzione dei processi siano fondamentali.

È difficile ottenere rilevamenti di minacce elevati usando gli strumenti e gli approcci esistenti. Gli strumenti e gli approcci sono progettati per il rilevamento delle minacce locali a causa delle differenze nella tecnologia cloud e del rapido ritmo di cambiamento. I rilevamenti integrati in modo nativo forniscono soluzioni su scala industriale gestite dai provider di servizi cloud che possono tenere il passo con le minacce correnti e le modifiche della piattaforma cloud.

Queste soluzioni native consentono ai team di operazioni per la sicurezza di concentrarsi sull'analisi e sulla correzione degli eventi imprevisti. Concentrarsi su tali elementi anziché sprecare tempo creando avvisi da dati di log non familiari, integrando strumenti e attività di manutenzione.

Chi?

In genere sono guidati dal team di operazioni per la sicurezza.

  • Sponsorizzazione: questo lavoro è generalmente sponsorizzato dal responsabile delle operazioni per la sicurezza o da un ruolo equivalente.
  • Esecuzione: l'integrazione del rilevamento delle minacce native è un impegno collaborativo che coinvolge queste soluzioni con:
    • Operazioni per la sicurezza: integra gli avvisi nei processi di analisi degli eventi imprevisti e informazioni di sicurezza e gestione degli eventi. Questo team può informare gli analisti sugli avvisi cloud e sul loro significato, oltre che su come usare gli strumenti cloud nativi.
    • Preparazione degli eventi imprevisti: integra gli eventi imprevisti cloud negli esercizi pratici e si assicura che questi esercizi vengano condotti per promuovere la preparazione del team.
    • Intelligence sulle minacce: ricerca e integra le informazioni sugli attacchi cloud per informare i team fornendo contesto e intelligenza.
    • Architettura di sicurezza: integra gli strumenti nativi nella documentazione sull'architettura di sicurezza.
    • Criteri e standard: definisce gli standard e i criteri per abilitare gli strumenti nativi nell'intera organizzazione. Monitora la conformità.
    • Infrastruttura ed endpoint e operazioni IT centrali: configurare e abilitare i rilevamenti, integrare l'automazione e l'infrastruttura come soluzioni di codice.

Come?

Abilitare il rilevamento delle minacce in Microsoft Defender for Cloud per tutte le risorse in uso e fare in modo che ogni team integri queste risorse nei processi, come descritto in precedenza.

Per altre informazioni, vedere Rilevamento delle minacce di Azure Security Benchmark per le risorse di Azure.

9. Architettura: adottare come standard una singola directory e una singola identità

Nessuno vuole gestire più identità e directory.

Cosa?

Standardizzare in una singola directory di Microsoft Entra. È possibile standardizzare una singola identità per ogni applicazione e utente in Azure.

Nota

Questa procedura consigliata si riferisce in modo specifico alle risorse aziendali. Per gli account partner, usare Microsoft Entra B2B in modo da non dover creare e gestire gli account nella directory. Per gli account cliente o cittadino, usare Azure AD B2C per gestirli.

Perché?

Più account e directory di identità creano un attrito non necessario, che crea confusione nei flussi di lavoro giornalieri per:

  • Utenti della produttività
  • Sviluppatori
  • Amministratori IT e delle identità
  • Analisti della sicurezza
  • Altri ruoli

La gestione di più account e directory favorisce procedure di sicurezza non ottimali. Queste procedure includono elementi come il riutilizzo delle password nei diversi account. Aumentano la probabilità di account obsoleti o abbandonati che gli utenti malintenzionati possono scegliere come destinazione.

Anche se a volte sembra più semplice configurare rapidamente una directory LDAP personalizzata per una determinata applicazione o un carico di lavoro specifico, questa azione crea molto più lavoro da integrare e gestire. Questo lavoro è simile alla scelta di configurare un tenant di Azure aggiuntivo o una foresta di Active Directory locale in più anziché usare il tenant aziendale esistente. Per altre informazioni, vedere il principio di sicurezza di promuovere la semplicità.

Chi?

La standardizzazione in una singola directory di Microsoft Entra è spesso un lavoro tra team. L'impegno è guidato dai team di architettura di sicurezza o di gestione delle identità e delle chiavi.

  • Sponsorizzazione: questo lavoro è generalmente sponsorizzato dai team di gestione delle identità e delle chiavi e di architettura di sicurezza, anche se alcune organizzazioni potrebbero richiedere la sponsorizzazione di CISO o CIO.
  • Esecuzione: l'esecuzione è un impegno collaborativo che coinvolge:
    • Architettura di sicurezza: questo team incorpora il processo nei documenti e nei diagrammi dell'architettura IT e di sicurezza.
    • Criteri e standard: questo team documenta i criteri e monitora la conformità.
    • Gestione delle identità e delle chiavi o operazioni IT centrali: questi team implementano i criteri abilitando funzionalità e supportando gli sviluppatori con account, istruzione e così via.
    • Sviluppatori di applicazioni o operazioni IT centrali: questi team usano l'identità nelle applicazioni e nelle configurazioni del servizio di Azure. Le responsabilità variano in base al livello di adozione di DevOps.

Come?

Adottare un approccio pragmatico che inizia con nuove funzionalità greenfield. Eseguire quindi la pulizia delle problematiche attraverso il brownfield delle applicazioni e dei servizi esistenti come esercizio di follow-up:

  • Greenfield: stabilire e implementare criteri chiari che tutte le identità aziendali possono usare una singola directory di Microsoft Entra con un singolo account per ogni utente.

  • Brownfield: molte organizzazioni hanno spesso vari sistemi di identità e directory legacy. Risolvere questi elementi legacy quando il costo degli ostacoli costanti alla gestione è superiore all'investimento per la pulizia. Sebbene le soluzioni di sincronizzazione e gestione delle identità possano mitigare alcuni di questi problemi, non dispongono di una stretta integrazione delle funzionalità di sicurezza e produttività. Queste funzionalità consentono un'esperienza uniforme per utenti, amministratori e sviluppatori.

Il momento ideale per combinare l'uso dell'identità è durante i cicli di sviluppo delle applicazioni nel corso delle operazioni seguenti:

  • Modernizzazione delle applicazioni per il cloud.
  • Aggiornamento delle applicazioni cloud con processi DevOps.

Esistono motivi validi per una directory separata per le business unit indipendenti o i requisiti normativi, tuttavia in tutte le altre circostanze occorre evitare più directory.

Per altre informazioni, vedere Azure Security Benchmark Microsoft Entra central identity and authentication system .For more information, see the Azure Security Benchmark Microsoft Entra central identity and authentication system.

Importante

L'unica eccezione alla regola dei singoli account è che gli utenti con privilegi, inclusi gli amministratori IT e gli analisti della sicurezza, possono avere account separati per le attività utente standard rispetto alle attività amministrative.

Per altre informazioni, vedere Azure Security Benchmark Accesso con privilegi.

10. Architettura: usare il controllo degli accessi in base all'identità anziché le chiavi

Cosa?

Usare le identità di Microsoft Entra anziché l'autenticazione basata su chiave, laddove possibile. Ad esempio, servizi di Azure, applicazioni, API.

Perché?

L'autenticazione basata su chiavi può essere usata per eseguire l'autenticazione ai servizi cloud e alle API. Ma richiede la gestione sicura delle chiavi, che è difficile da fare bene, soprattutto su larga scala. La gestione sicura delle chiavi è difficile per i professionisti che non si occupano di sicurezza, ad esempio sviluppatori e professionisti delle infrastrutture, che spesso non riescono a eseguire questa operazione in modo sicuro, creando importanti rischi di sicurezza per l'organizzazione.

L'autenticazione basata sull'identità supera molte di queste sfide grazie a funzionalità avanzate. Queste funzionalità includono la rotazione dei segreti, la gestione del ciclo di vita, la delega amministrativa e altro ancora.

Chi?

L'implementazione del controllo di accesso basato sull'identità è spesso un'attività congiunta dei team. L'impegno è guidato dai team di architettura di sicurezza o di gestione delle identità e delle chiavi.

  • Sponsorizzazione: questo impegno è generalmente sponsorizzato dai team di architettura di sicurezza o di gestione delle identità e delle chiavi, anche se alcune organizzazioni potrebbero richiedere la sponsorizzazione di CISO o CIO.
  • Esecuzione: uno sforzo collaborativo che coinvolge:
    • Architettura della sicurezza: questo team incorpora le procedure consigliate nei diagrammi e nei documenti dell'architettura IT e della sicurezza.
    • Criteri e standard: questo team documenta i criteri e monitora la conformità.
    • Gestione delle identità e delle chiavi o operazioni IT centrali: questi team implementano i criteri abilitando funzionalità e supportando gli sviluppatori con account, istruzione e così via.
    • Sviluppatori di app o operazioni IT centrali: usare l'identità nelle applicazioni e nelle configurazioni del servizio di Azure. Le responsabilità variano in base al livello di adozione di DevOps.

Come?

Per impostare una preferenza e un'abitudine organizzative per l'uso dell'autenticazione basata sull'identità, è necessario seguire un processo e abilitare la tecnologia.

Il processo

  1. Definire criteri e standard che delineino chiaramente l'autenticazione predefinita basata sull'identità e le eccezioni accettabili.
  2. Informare gli sviluppatori e i team dell'infrastruttura sul motivo per cui usare il nuovo approccio, su cosa devono fare e su come farlo.
  3. Implementare le modifiche in modo pragmatico iniziando con le nuove funzionalità greenfield adottate ora e in futuro, ad esempio nuovi servizi di Azure e nuove applicazioni, e quindi seguendo una pulizia delle configurazioni brownfield esistenti.
  4. Monitorare la conformità e proseguire i team di sviluppo e infrastruttura per la correzione.

Le tecnologie

Per gli account non umani, ad esempio i servizi o l'automazione, usare le identità gestite. Le identità gestite di Azure possono eseguire l'autenticazione ai servizi e alle risorse di Azure che supportano l'autenticazione di Microsoft Entra. L'autenticazione viene abilitata tramite regole di concessione dell'accesso predefinite, evitando credenziali hardcoded nel codice sorgente o nei file di configurazione.

Per i servizi che non supportano le identità gestite, usare l'ID Entra di Microsoft per creare un'entità servizio con autorizzazioni limitate a livello di risorsa. È necessario configurare le entità servizio con le credenziali del certificato e il fallback ai segreti client. In entrambi i casi, Azure Key Vault può essere usato con le identità gestite di Azure, in modo che l'ambiente di runtime, ad esempio una funzione di Azure, possa recuperare le credenziali dall'insieme di credenziali delle chiavi.

Per altre informazioni, vedere Identità dell'applicazione Azure Security Benchmark.

11. Architettura: Stabilire una singola strategia di sicurezza unificata

Perché una barca possa prendere il largo, tutti devono remare nella stessa direzione.

Cosa?

Assicurarsi che tutti i team siano allineati a una singola strategia che consente e protegge i dati e i sistemi aziendali.

Perché?

Quando i team lavorano in isolamento senza essere allineati su una strategia comune, le singole azioni possono inavvertitamente vanificare gli sforzi degli altri. Il disallineamento può creare inutili ostacoli che rallentano l'avanzamento rispetto agli obiettivi di tutti.

Un esempio di team che lavorano in isolamento e che hanno funzionato in modo coerente in molte organizzazioni è la segmentazione delle risorse:

  • Sicurezza di rete: sviluppa una strategia per segmentare una rete semplice. La strategia aumenta la sicurezza, spesso in base a siti fisici, indirizzi/intervalli di indirizzi IP assegnati o elementi simili.
  • Team di identità: sviluppa una strategia per gruppi e unità organizzative di Active Directory in base alla comprensione e alla conoscenza dell'organizzazione.
  • Team delle applicazioni: trovano difficile lavorare con questi sistemi perché sono stati progettati con input e comprensione limitati delle operazioni, degli obiettivi e dei rischi aziendali.

Nelle organizzazioni in cui si verifica questa limitazione, spesso i team riscontrano conflitti sulle eccezioni del firewall. I conflitti possono influire negativamente sulla sicurezza perché i team approvano le eccezioni. La produttività influisce negativamente sulla sicurezza perché le distribuzioni rallentano le funzionalità delle applicazioni necessarie per l'azienda.

Anche se la sicurezza può creare ostacoli sani obbligando a una riflessione critica, questo conflitto crea solo ostacoli non sani che impediscono il raggiungimento degli obiettivi. Per altre informazioni, vedere Linee guida per la strategia di sicurezza.

Chi?

  • Sponsorizzazione: la strategia unificata è generalmente sponsorizzata congiuntamente da CIO, CISO e CTO. Spesso la sponsorizzazione viene fornita con il supporto della leadership aziendale per alcuni elementi di livello elevato ed è promossa dai rappresentanti di ogni team.
  • Esecuzione: la strategia di sicurezza deve essere implementata da tutti. Integra i dati di diversi team per aumentare la proprietà, il sostegno e la probabilità di successo.
    • Architettura di sicurezza: questo team guida l'impegno di creare una strategia di sicurezza e l'architettura risultante. L'architettura di sicurezza raccoglie attivamente i feedback dei team e li documenta in presentazioni, documenti e diagrammi per i vari destinatari.
    • Criteri e standard: questo team acquisisce gli elementi appropriati in standard e criteri, quindi monitora la conformità.
    • Tutti i team IT e di sicurezza tecnici: questi team forniscono requisiti di input, quindi allineano e implementano la strategia aziendale.
    • Proprietari di applicazioni e sviluppatori: leggono e comprendono la documentazione relativa alla strategia applicabile. Idealmente, adattano il materiale sussidiario al loro ruolo.

Come?

Creare e implementare una strategia di sicurezza per il cloud che includa l'input e la partecipazione attiva di tutti i team. Anche se il formato della documentazione del processo può variare, include sempre:

  • Input attivo dei team: generalmente le strategie hanno esito negativo se le persone dell'organizzazione non le accettano. Idealmente, tutti i team dovrebbero riunirsi nella stessa stanza per creare la strategia in collaborazione. Nei workshop che conduciamo con i clienti, spesso scopriamo che le organizzazioni operano in silo di fatto e spesso queste riunioni comportano che le persone si riuniscano per la prima volta. L'inclusione è un requisito. Se alcuni team non sono invitati, in genere occorre ripetere la riunione fino a quando non vi parteciperanno tutti. Se non partecipano, il progetto non va avanti.
  • Documentazione e comunicazioni chiare: tutti i team devono essere a conoscenza della strategia di sicurezza. Idealmente, la strategia di sicurezza è un componente di sicurezza della strategia complessiva della tecnologia. Questa strategia include il motivo per cui integrare la sicurezza, cosa è importante nella sicurezza e come si manifesta il successo della sicurezza. Questa strategia include materiale sussidiario specifico per i team di applicazione e sviluppo, che permette di ricevere indicazioni chiare senza dover leggere informazioni non rilevanti.
  • Stabilità e flessibilità: le strategie devono essere relativamente coerenti e stabili, ma le architetture e la documentazione potrebbero dover aggiungere chiarezza e adeguarsi alla natura dinamica del cloud. Ad esempio, l'applicazione di filtri al traffico esterno dannoso rimarrebbe coerente come imperativo strategico anche se si passasse dall'uso di un firewall di nuova generazione di terze parti a Firewall di Azure e si adattassero i diagrammi e il materiale sussidiario su come farlo.
  • Iniziare con la segmentazione: ci sono problemi di strategia sia grandi che piccoli da affrontare, ma è necessario iniziare da qualche parte. Avviare la strategia di sicurezza con la segmentazione degli asset aziendali. Questa segmentazione è una decisione di base che sarebbe difficile cambiare in un secondo momento e che richiede sia l'input aziendale che molti team tecnici.

Microsoft ha pubblicato materiale sussidiario video per l'applicazione di una strategia di segmentazione ad Azure. Sono stati pubblicati alcuni documenti sulla segmentazione aziendale e sull'allineamento della sicurezza di rete.

Il Cloud Adoption Framework include materiale sussidiario per aiutare i team a:

Per altre informazioni, vedere la strategia di governance di Azure Security Benchmark.