Considerazioni sulla sicurezza per le app IaaS altamente riservate in Azure

Esistono molte considerazioni sulla sicurezza per la distribuzione di app IaaS (Infrastructure-as-a-Service) in Azure. Questo articolo si basa sulle architetture di riferimento per carichi di lavoro basati su macchine virtuali e infrastrutture di rete ibrida per concentrarsi sulla sicurezza per carichi di lavoro IaaS estremamente sensibili in Azure, in base ai concetti fondamentali sulla sicurezza di Azure.

Vedere anche Panoramica della sicurezza delle macchine virtuali di Azure e Procedure consigliate per la sicurezza per i carichi di lavoro IaaS in Azure.

Macchine virtuali di Azure

La piattaforma di calcolo di Azure si basa sulla virtualizzazione delle macchine. Un hypervisor viene eseguito nell'hardware fisico di ogni nodo di Azure o endpoint di rete e crea un numero variabile di macchine virtuali Hyper-V guest nel nodo. Tutto il codice utente viene eseguito nelle macchine virtuali. Per istruzioni di base sulla distribuzione di macchine virtuali di Azure, vedere Eseguire una macchina virtuale Linux in Azure o Eseguire una macchina virtuale Windows in Azure. La maggior parte dei processi di distribuzione è la stessa per i due sistemi operativi, ma gli strumenti specifici del sistema operativo, ad esempio la crittografia del disco, possono essere diversi.

È possibile usare Microsoft Defender per il cloud per la gestione delle patch delle macchine virtuali e per distribuire e monitorare gli strumenti antimalware. In alternativa, è possibile gestire gli strumenti di applicazione di patch e antimalware personalizzati o di terze parti, comuni quando si estendono o si esegue la migrazione di infrastrutture esistenti ad Azure.

Microsoft fornisce la protezione DDoS (Distributed Denial of Service) di base come parte della piattaforma Azure. Le app con endpoint pubblici possono usare Protezione DDoS standard di Azure per una protezione aggiuntiva. Tuttavia, i carichi di lavoro altamente sensibili non hanno in genere endpoint pubblici e possono essere accessibili solo da posizioni specifiche tramite una rete privata virtuale (VPN) o una riga con lease.

Architetture a più livelli

Molte applicazioni IaaS sono costituite da più livelli, ad esempio un livello Web, un livello business e un livello dati, ospitati in più macchine virtuali. Gli aspetti principali della distribuzione di architetture di app a più livelli nelle macchine virtuali di Azure includono:

• Disponibilità elevata .High Availability (HA). Le app a disponibilità elevata devono essere disponibili più del 99,9% del tempo. L'inserimento di macchine virtuali di livello in zone di disponibilità di Azure diverse garantisce la disponibilità elevata, perché le reti AZ si estendono su uno o più data center, offrendo resilienza grazie alla resistenza agli errori del data center. Le aree che non supportano le reti AZ possono usare set di disponibilità (AS), che distribuiscono le macchine virtuali tra più nodi hardware isolati.
• Bilanciamento del carico. I servizi di bilanciamento del carico distribuiscono il traffico tra le macchine virtuali, per bilanciare il carico e la resilienza in caso di errore di una macchina virtuale. Non sono necessari servizi di bilanciamento del carico se l'applicazione gestisce il bilanciamento del carico e le singole macchine virtuali sono note al chiamante.
• Reti virtuali. Le reti virtuali e le subnet segmentano la rete, semplificando la gestione della sicurezza e il routing avanzato.
• Domain Name System (DNS).Domain Name System (DNS). DNS di Azure offre un servizio DNS sicuro e a disponibilità elevata. Una zona privata in DNS di Azure consente di usare domini personalizzati all'interno delle reti virtuali.

Backup e ripristino

Per proteggersi da errori umani, eliminazione di dati dannosi e ransomware, è necessario eseguire il backup almeno delle macchine virtuali livello dati. Backup di Azure può eseguire il backup e il ripristino di macchine virtuali crittografate se può accedere alle chiavi di crittografia in Azure Key Vault.

Per i livelli Web e business, è possibile usare le regole di scalabilità automatica del set di scalabilità di macchine virtuali per eliminare automaticamente le macchine virtuali compromesse e distribuire istanze di macchine virtuali nuove da un'immagine di base.

Isolamento del calcolo

In ogni nodo di Azure o endpoint di rete, l'hypervisor e un sistema operativo radice speciale assicurano che le macchine virtuali guest non possano accedere al server host fisico e il codice utente venga eseguito solo nelle macchine virtuali guest. Questo isolamento impedisce agli utenti di ottenere l'accesso in lettura, scrittura o esecuzione non elaborati al sistema e riduce il rischio di condivisione delle risorse. Azure protegge da tutti gli attacchi lato canale noti e dai vicini rumorosi tramite l'hypervisor e un algoritmo avanzato di posizionamento delle macchine virtuali. Per altre informazioni, vedere Isolamento del calcolo.

Per i carichi di lavoro altamente sensibili, è possibile aggiungere ulteriore protezione dagli attacchi sul canale laterale con macchine virtuali isolate o host dedicati.

Macchine virtuali isolate

Le macchine virtuali isolate sono di grandi dimensioni di macchine virtuali isolate per un tipo di hardware specifico e dedicate a un singolo cliente. L'uso di una dimensione di macchina virtuale isolata garantisce che la macchina virtuale sia l'unica in esecuzione in un'istanza del server specifica. È possibile suddividere ulteriormente le risorse delle macchine virtuali isolate usando supporto tecnico di Azure per le macchine virtuali nidificate.

Le dimensioni minime di una macchina virtuale isolata sono 64 core CPU virtuali e 256 GiB di memoria. Queste macchine virtuali sono molto più grandi della maggior parte delle applicazioni a più livelli necessarie e possono creare un sovraccarico di costi elevato. Per ridurre il sovraccarico, è possibile eseguire più livelli di app in una singola macchina virtuale con virtualizzazione annidata o in processi o contenitori diversi. È comunque necessario distribuire macchine virtuali diverse nelle reti AZ per la resilienza ed eseguire appliance di zona demilitarizzata (DMZ) in macchine virtuali separate. La combinazione di più app in un'infrastruttura per motivi economici potrebbe anche essere in conflitto con i criteri di separazione delle app dell'organizzazione.

Man mano che le funzionalità dell'area di Azure si espandono nel tempo, Azure può anche rimuovere le garanzie di isolamento da determinate dimensioni della macchina virtuale, con preavviso di un anno.

Host dedicati di Azure

Host dedicato di Azure è la soluzione di isolamento di calcolo preferita per carichi di lavoro altamente sensibili. Un host dedicato è un server fisico dedicato a un cliente per l'hosting di più macchine virtuali. Oltre a isolare le macchine virtuali, gli host dedicati consentono di controllare la manutenzione e il posizionamento delle macchine virtuali per evitare vicini rumorosi.

Gli host dedicati hanno le stesse dimensioni minime e molte delle stesse considerazioni di ridimensionamento delle macchine virtuali isolate. Tuttavia, un host dedicato può ospitare macchine virtuali che si trovano in reti virtuali diverse, per soddisfare i criteri di separazione delle applicazioni. È comunque consigliabile eseguire macchine virtuali della rete perimetrale in un host diverso per evitare attacchi sul canale laterale da una macchina virtuale compromessa nella rete perimetrale.

Crittografia

La crittografia dei dati è un componente importante della protezione dei carichi di lavoro. La crittografia codifica le informazioni in modo che solo i ricevitori autorizzati possano decodificarlo usando una chiave o un certificato. La crittografia include la crittografia del disco, per la crittografia dei dati inattivi e tls (Transport Level Security) per la crittografia in transito sulle reti.

Azure Key Vault

È possibile proteggere le chiavi di crittografia e i certificati archiviandoli in Azure Key Vault, una soluzione HSM (Hardware Security Module) cloud convalidata per FIPS (Federal Information Processing Standards) 140-2 Livello 2. Per le procedure consigliate per consentire solo alle applicazioni autorizzate e agli utenti di accedere a Key Vault, vedere Proteggere l'accesso a un insieme di credenziali delle chiavi.

Per proteggere le chiavi in Key Vault, è possibile abilitare l'eliminazione temporanea, assicurando che le chiavi eliminate siano recuperabili. Per una protezione aggiuntiva, è possibile eseguire il backup di singole chiavi in un file crittografato che è possibile usare per ripristinare le chiavi, potenzialmente in un'altra area di Azure nella stessa area geografica.

Quando si ospita SQL Server in una macchina virtuale, è possibile usare il Connettore SQL Server per Azure Key Vault per ottenere chiavi per Transparent Data Encryption (TDE), crittografia a livello di colonna (CLE) e crittografia del backup. Per informazioni dettagliate, vedere Configurare l'integrazione di Azure Key Vault per SQL Server nelle macchine virtuali di Azure.

Azure Disk Encryption

Crittografia dischi di Azure usa una protezione con chiave esterna BitLocker per fornire la crittografia del volume per il sistema operativo e i dischi dati delle macchine virtuali di Azure e può essere integrato con Azure Key Vault per consentire di controllare e gestire chiavi e segreti di crittografia del disco. Ogni macchina virtuale genera le proprie chiavi di crittografia e le archivia in Azure Key Vault. Per configurare Azure Key Vault per abilitare Crittografia dischi di Azure, vedere Creare e configurare un insieme di credenziali delle chiavi per Crittografia dischi di Azure.

Per i carichi di lavoro altamente sensibili, è consigliabile usare anche una chiave di crittografia della chiave (KEK) per un livello di sicurezza aggiuntivo. Quando si specifica una chiave kek, Crittografia dischi di Azure usa tale chiave per eseguire il wrapping dei segreti di crittografia prima di scrivere in Key Vault. È possibile generare una chiave kek in Azure Key Vault, ma un metodo più sicuro consiste nel generare una chiave nel modulo di protezione hardware locale e importarlo in Azure Key Vault. Questa modalità è spesso definita con il termine Bring Your Own Key o BYOK. Poiché le chiavi importate non possono lasciare il limite del modulo di protezione hardware, la generazione della chiave nel modulo di protezione hardware garantisce il controllo completo delle chiavi di crittografia.

Per altre informazioni sulle chiavi protette dal modulo di protezione hardware, vedere Come generare e trasferire chiavi protette con HSM per Azure Key Vault.

Crittografia del traffico di rete

Protocolli di rete come HTTPS crittografa i dati in transito con certificati. Il traffico da client a applicazione usa in genere un certificato da un'autorità di certificazione (CA) attendibile. Le app interne possono usare un certificato da una CA interna o da una CA pubblica, ad esempio DigiCert o GlobalSign. La comunicazione da livello a livello usa in genere un certificato rilasciato da una CA interna o un certificato autofirmato. Azure Key Vault può contenere uno di questi tipi di certificato. Per altre informazioni sulla creazione di tipi di certificato diversi, vedere Metodi di creazione dei certificati.

Azure Key Vault può fungere da AUTORITÀ di certificazione autofirmato per il traffico da livello a livello. L'estensione macchina virtuale Key Vault fornisce il monitoraggio e l'aggiornamento automatico dei certificati specificati nelle macchine virtuali, con o senza la chiave privata a seconda del caso d'uso. Per usare l'estensione macchina virtuale Key Vault, vedere Estensione macchina virtuale Key Vault per Linux o l'estensione macchina virtuale Key Vault per Windows.

Key Vault può anche archiviare le chiavi per i protocolli di rete che non usano certificati. I carichi di lavoro personalizzati potrebbero richiedere lo scripting di un'estensione script personalizzata che recupera una chiave da Key Vault e la archivia per l'uso delle applicazioni. Le app possono anche usare l'identità gestita di una macchina virtuale per recuperare i segreti direttamente da Key Vault.

Sicurezza di rete

I gruppi di sicurezza di rete filtrano il traffico tra le risorse nelle reti virtuali di Azure. Le regole di sicurezza del gruppo di sicurezza di rete consentono o negano il traffico di rete da o verso le risorse di Azure in base a indirizzi IP e porte. Per impostazione predefinita, i gruppi di sicurezza di rete bloccano il traffico in ingresso da Internet, ma consentono connessioni in uscita da macchine virtuali a Internet. Per impedire il traffico in uscita accidentale, aggiungere una regola personalizzata con la priorità più bassa possibile, 4096, per bloccare tutto il traffico in ingresso e in uscita. È quindi possibile aggiungere regole con priorità più alta per consentire traffico specifico.

I gruppi di sicurezza di rete creano record di flusso per le connessioni esistenti e consentono o negano la comunicazione in base allo stato di connessione del record di flusso. Il record del flusso consente a un gruppo di sicurezza di rete di essere con stato. Ad esempio, se si specifica una regola di sicurezza in uscita per qualsiasi indirizzo sulla porta 443, non è necessario specificare anche una regola di sicurezza in ingresso per la risposta. È sufficiente specificare una regola di sicurezza in ingresso se la comunicazione viene avviata esternamente.

La maggior parte dei servizi di Azure consente di usare un tag del servizio di rete virtuale anziché un gruppo di sicurezza di rete. Un tag di servizio rappresenta un gruppo di prefissi di indirizzi IP da un servizio di Azure e consente di ridurre al minimo la complessità dagli aggiornamenti frequenti delle regole di sicurezza di rete. Un tag del servizio Azure Key Vault può consentire a una macchina virtuale di recuperare certificati, chiavi e segreti da Azure Key Vault.

Un altro modo per controllare la sicurezza di rete consiste nel routing del traffico di rete virtuale e nel tunneling forzato. Azure crea automaticamente route di sistema e assegna le route a ogni subnet in una rete virtuale. Non è possibile creare né rimuovere route di sistema, ma è possibile ignorare alcune route di sistema usando route personalizzate. Il routing personalizzato consente di instradare il traffico su un'appliance virtuale di rete come un firewall o un proxy o eliminare il traffico indesiderato, con un effetto simile al blocco del traffico con un gruppo di sicurezza di rete.

È possibile usare appliance virtuali di rete come Firewall di Azure per consentire, bloccare ed esaminare il traffico di rete. Firewall di Azure è un servizio firewall della piattaforma a disponibilità elevata gestito. È anche possibile distribuire appliance virtuali di rete di terze parti da Azure Marketplace. Per rendere queste appliance virtuali di rete a disponibilità elevata, vedere Distribuire appliance virtuali di rete a disponibilità elevata.

Gruppi di sicurezza delle applicazioni

Per filtrare il traffico tra i livelli applicazione all'interno di una rete virtuale, usare i gruppi di sicurezza delle applicazioni. I gruppi di sicurezza di azure consentono di configurare la sicurezza di rete come estensione della struttura di un'applicazione, consentendo di raggruppare le macchine virtuali e definire i criteri di sicurezza di rete in base ai gruppi. È possibile riutilizzare i criteri di sicurezza su larga scala senza mantenere manualmente indirizzi IP espliciti.

Poiché i gruppi di sicurezza di azure vengono applicati a un'interfaccia di rete anziché a una subnet, abilitano la micro-segmentazione. È possibile controllare attentamente le macchine virtuali che possono comunicare tra loro, anche bloccando il traffico tra macchine virtuali nello stesso livello e semplificando la quarantena di una macchina virtuale rimuovendo i gruppi di sicurezza di azure da tale macchina virtuale.

Reti ibride

Le architetture ibride connettono reti locali con cloud pubblici come Azure. Esistono diversi modi per connettere le reti locali alle applicazioni in esecuzione in Azure:

• Endpoint pubblico su Internet. È possibile basarsi sull'identità, sulla sicurezza a livello di trasporto (HTTPS) e sul gateway applicazione per proteggere l'applicazione, potenzialmente in combinazione con un firewall. Tuttavia, per carichi di lavoro altamente sensibili, l'esposizione di un endpoint pubblico su Internet non è consigliata.
• Gateway VPN di Azure o di terze parti. È possibile connettere una rete locale ad Azure usando un gateway VPN di Azure. Il traffico si sposta ancora su Internet, ma su un tunnel crittografato che usa TLS. È anche possibile eseguire un gateway di terze parti in una macchina virtuale, se sono presenti requisiti specifici non supportati dal gateway VPN di Azure.
• ExpressRoute. Le connessioni ExpressRoute usano una connessione dedicata privata tramite un provider di connettività di terze parti. La connessione privata estende la rete locale in Azure e offre scalabilità e un contratto di servizio affidabile.
  • ExpressRoute con failover VPN. Questa opzione usa ExpressRoute in condizioni normali, ma esegue il failover a una connessione VPN se si verifica una perdita di connettività nel circuito ExpressRoute, offrendo una maggiore disponibilità.
  • VPN tramite ExpressRoute. Questa opzione è la soluzione migliore per carichi di lavoro altamente sensibili. ExpressRoute offre un circuito privato con scalabilità e affidabilità e VPN offre un ulteriore livello di protezione che termina la connessione crittografata in una rete virtuale di Azure specifica.

Per altre indicazioni sulla scelta tra diversi tipi di connettività ibrida, vedere Scegliere una soluzione per la connessione di una rete locale ad Azure.

Distribuire una rete perimetrale

Connessione gli ambienti locali e di Azure offrono agli utenti locali l'accesso alle applicazioni di Azure. Una rete perimetrale o una zona demilitarizzata (DMZ) offre una protezione aggiuntiva per carichi di lavoro altamente sensibili.

Un'architettura come quella nella rete perimetrale tra Azure e un data center locale distribuisce tutte le reti perimetrali e i servizi dell'applicazione nella stessa rete virtuale, con regole del gruppo di sicurezza di rete e route definite dall'utente per isolare la rete perimetrale e le subnet dell'applicazione. Questa architettura può rendere disponibile la subnet di gestione tramite Internet pubblico, per gestire le app anche se il gateway locale non è disponibile. Tuttavia, per carichi di lavoro estremamente sensibili, è consigliabile consentire solo di ignorare il gateway in uno scenario di break glass. Una soluzione migliore consiste nell'usare Azure Bastion, che consente l'accesso direttamente dalla portale di Azure limitando l'esposizione degli indirizzi IP pubblici.

È anche possibile usare l'accesso JIT (Just-In-Time) alle macchine virtuali per la gestione remota limitando l'esposizione degli indirizzi IP pubblici. Con l'accesso JIT alle macchine virtuali, un gruppo di sicurezza di rete blocca le porte di gestione remota, ad esempio RDP (Remote Desktop Protocol) e SSH (Secure Shell) per impostazione predefinita. Quando richiesto, l'accesso jit alla macchina virtuale abilita la porta solo per un intervallo di tempo specificato e potenzialmente per un intervallo o un indirizzo IP specifico. L'accesso JIT funziona anche per le macchine virtuali con solo indirizzi IP privati. È possibile usare Azure Bastion per bloccare il traffico verso una macchina virtuale fino a quando non è abilitato l'accesso jit alla macchina virtuale.

Per distribuire più applicazioni, è possibile usare una topologia di rete hub-spoke in Azure, con la rete perimetrale nella rete virtuale hub e le applicazioni nelle reti virtuali spoke. La rete virtuale hub può contenere un gateway VPN e/o ExpressRoute, un'appliance virtuale di rete firewall, host di gestione, infrastruttura di identità e altri servizi condivisi. Le reti virtuali spoke sono connesse all'hub con il peering di rete virtuale. Una rete virtuale di Azure non consente il routing transitivo sull'hub da uno spoke a un altro. Il traffico spoke-spoke è possibile solo tramite le appliance firewall nell'hub. Questa architettura isola efficacemente le applicazioni l'una dall'altra.

Distribuzione in più aree

La continuità aziendale e il ripristino di emergenza potrebbero richiedere la distribuzione dell'applicazione in più aree di Azure, che possono influire sulla residenza e sulla sicurezza dei dati. Per un'architettura di riferimento per le distribuzioni in più aree, vedere Eseguire un'applicazione a più livelli in più aree di Azure per la disponibilità elevata.

Coppie di aree

Un'area geografica di Azure è un'area definita del mondo che contiene almeno un'area di Azure, ognuna con uno o più data center. Ogni area di Azure è associata a un'altra area nella stessa area geografica in una coppia di aree. Le coppie a livello di area non vengono aggiornate contemporaneamente e, se si verifica un'emergenza in entrambe le aree, una delle aree è prioritaria per tornare online per prima. Per la continuità aziendale, è consigliabile distribuire app estremamente sensibili almeno a coppie di aree se si distribuisce in più aree.

Per altre informazioni, vedere Continuità aziendale e ripristino di emergenza (BCDR): aree abbinate di Azure. Il white paper Ottenere la residenza e la sicurezza dei dati conformi con Azure illustra la residenza dei dati e le operazioni da eseguire per soddisfare i requisiti di residenza dei dati.

Replica tra aree

Nelle architetture IaaS la replica dei dati tra aree è responsabilità dell'applicazione. Lo scenario di replica più comune usa tecnologie di replica di database integrate nel prodotto server di database, ad esempio i gruppi di disponibilità AlwaysOn di SQL Server, Oracle Data Guard o la replica MySQL.

La configurazione della replica tra server di database IaaS non è semplice ed è necessario tenere conto dei requisiti di continuità aziendale. I servizi di database di Azure, ad esempio database SQL di Azure, Database di Azure per MySQL e Azure Cosmos DB semplificano la replica tra aree, ma potrebbero non soddisfare i requisiti di sicurezza per carichi di lavoro estremamente sensibili.

Per altre informazioni e indicazioni sulle distribuzioni di SQL Server e Oracle in più aree, vedere:

• Configurare un gruppo di disponibilità in macchine virtuali di Azure che eseguono SQL Server in aree diverse
• Ripristino di emergenza per un database Oracle Database 12c in un ambiente Azure

Peering tra aree

È possibile abilitare la comunicazione sicura tra reti virtuali in aree diverse usando il peering di rete virtuale globale. Il peering globale funziona allo stesso modo del peering all'interno dell'area. Il traffico tra aree viene eseguito attraverso il backbone Microsoft, non attraversa Internet ed è isolato da altri traffici. Per maggiore sicurezza, è possibile distribuire appliance virtuali di rete VPN in entrambe le aree e usare route definite dall'utente per forzare il traffico tra aree nelle appliance virtuali di rete, in modo analogo alla distribuzione di una rete perimetrale.

Routing del traffico di failover

Con gli endpoint pubblici, è possibile usare Gestione traffico o Frontdoor di Azure per indirizzare il traffico all'area attiva o all'area più vicina in una configurazione di failover attivo-attivo. Tuttavia, Gestione traffico e Frontdoor di Azure richiedono entrambi endpoint pubblici per monitorare la disponibilità e le voci DNS corrispondenti sono pubbliche. Per i carichi di lavoro altamente sensibili, la soluzione alternativa consiste nel distribuire DNS in locale e modificare le voci nell'area attiva per il failover.

Gestione e governance

La protezione delle app IaaS estremamente sensibili richiede più di una semplice distribuzione delle architetture corrette e l'implementazione delle regole di sicurezza di rete. Poiché gli ambienti cloud sono facilmente modificati, è particolarmente importante assicurarsi che le modifiche possano essere apportate solo con determinate autorizzazioni e entro i limiti dei criteri di sicurezza. Ad esempio, è necessario impedire a un attore malintenzionato di modificare una regola di sicurezza di rete per consentire il traffico da Internet.

Per distribuire i carichi di lavoro in Azure, sono necessari uno o più account di gestione. La protezione degli account di gestione è fondamentale per proteggere i carichi di lavoro. Per altre informazioni, vedere Proteggere l'accesso con privilegi per le distribuzioni ibride e cloud in Microsoft Entra ID.

Usare le risorse nella subnet di gestione per concedere l'accesso al livello app solo alle persone che devono gestire tale livello. Ad esempio, è possibile usare Microsoft Identity Manager con Microsoft Entra ID. Tuttavia, per gli scenari nativi del cloud, è preferibile Microsoft Entra Privileged Identity Management (PIM).

Esistono diversi altri modi per controllare i ruoli e i criteri di Azure:

• Il controllo degli accessi in base al ruolo di Azure per le risorse di Azure consente di assegnare ruoli predefiniti o personalizzati agli utenti, in modo che abbiano solo i privilegi necessari. È possibile combinare il controllo degli accessi in base al ruolo di Azure con PIM per implementare un flusso di lavoro di approvazione controllato che eleva i privilegi per un periodo di tempo limitato.
• I criteri applicano regole, standard e contratti di servizio aziendali. Criteri di Azure è un servizio di Azure che crea, assegna e gestisce i criteri e valuta le risorse per la conformità dei criteri.
• Azure Blueprints combina assegnazioni di ruolo, assegnazioni di criteri e modelli di distribuzione per definire un set di risorse di Azure replicabili che implementano e seguono gli standard, i modelli e i requisiti di un'organizzazione. I progetti sono un modo dichiarativo per orchestrare la distribuzione di modelli di risorse e altri artefatti. È possibile creare progetti manualmente o sfruttare i progetti esistenti. Ad esempio, il progetto Servizi condivisi ISO 27001 distribuisce un hub di servizi condivisi che è possibile modificare ed estendere ai requisiti dell'organizzazione.

Monitoraggio

Microsoft Defender per il cloud fornisce monitoraggio e avvisi che consentono di mantenere la sicurezza dell'ambiente. Il servizio gratuito verifica automaticamente la presenza di vulnerabilità, ad esempio patch del sistema operativo mancanti, errori di configurazione della sicurezza e sicurezza di rete di base. La versione a pagamento Standard offre funzionalità aggiuntive, ad esempio l'analisi comportamentale, la protezione avanzata adattiva della rete e l'accesso alle macchine virtuali JIT. Per un elenco completo delle funzionalità, vedere Copertura delle funzionalità per le macchine virtuali. Defender per il cloud fornisce anche la protezione dalle minacce per altre risorse, ad esempio Azure Key Vault.

È possibile usare Monitoraggio di Azure per altre attività di monitoraggio e analisi. Per monitorare l'identità e l'accesso, è possibile indirizzare i log attività di Microsoft Entra a Monitoraggio di Azure. È anche possibile monitorare macchine virtuali, reti e Firewall di Azure e analizzare i log importati con potenti funzionalità di query di log. È possibile integrare Monitoraggio di Azure con siem (Security Information and Event Manager), che può essere siemdi terze parti o Microsoft Sentinel.

Risorse correlate

• Per altre informazioni sulle architetture a più livelli, vedere Applicazione a più livelli Linux in Azure con Apache Cassandra.
• Per un'esercitazione end-to-end sull'uso dell'estensione macchina virtuale di Azure Key Vault, vedere Proteggere un server Web in una macchina virtuale Windows in Azure con certificati SSL archiviati in Key Vault.
• Per altre informazioni sulle Crittografia dischi di Azure, vedere Crittografia dischi di Azure per macchine virtuali Linux o Crittografia dischi di Azure per le macchine virtuali Windows.
• Per altre informazioni sulla sicurezza di rete di Azure, vedere Panoramica della sicurezza di rete di Azure.