Condividi tramite

Panoramica e linee guida sulla sicurezza di Monitoraggio di Azure

  • Articolo

Questo articolo fornisce linee guida per la sicurezza per Monitoraggio di Azure come parte di Azure Well-Architected Framework.

Le linee guida per la sicurezza di Monitoraggio di Azure consentono di comprendere le funzionalità di sicurezza di Monitoraggio di Azure e come configurarle per ottimizzare la sicurezza in base a:

Le linee guida contenute in questo articolo si basano sul modello di responsabilità della sicurezza Microsoft. Nell'ambito di questo modello di responsabilità condivisa, Microsoft fornisce queste misure di sicurezza per i clienti di Monitoraggio di Azure:

Inserimento e archiviazione dei log

Elenco di controllo della progettazione

  • Configurare l'accesso per diversi tipi di dati nell'area di lavoro necessaria per ruoli diversi nell'organizzazione.
  • Usare il collegamento privato di Azure per rimuovere l'accesso all'area di lavoro dalle reti pubbliche.
  • Configurare il controllo delle query di log per tenere traccia degli utenti che eseguono query.
  • Garantire l'immutabilità dei dati di controllo.
  • Determinare una strategia per filtrare o offuscare i dati sensibili nell'area di lavoro.
  • Ripulire i dati sensibili raccolti accidentalmente.
  • Collegare l'area di lavoro a un cluster dedicato per funzionalità di sicurezza avanzate, inclusa la doppia crittografia usando chiavi gestite dal cliente e Customer Lockbox per Microsoft Azure per approvare o rifiutare le richieste di accesso ai dati Microsoft.
  • Usare Transport Layer Security (TLS) 1.2 o versione successiva per inviare dati all'area di lavoro usando agenti, connettori e API di inserimento dei log.

Raccomandazioni per la configurazione

Elemento consigliato Vantaggio
Configurare l'accesso per diversi tipi di dati nell'area di lavoro necessaria per ruoli diversi nell'organizzazione. Impostare la modalità di controllo di accesso per l'area di lavoro su Usa autorizzazioni di risorsa o area di lavoro per consentire ai proprietari delle risorse di usare il contesto delle risorse per accedere ai dati senza concedere l'accesso esplicito all'area di lavoro. Ciò semplifica la configurazione dell'area di lavoro e consente di assicurarsi che gli utenti non siano in grado di accedere ai dati che non dovrebbero.

Assegnare il ruolo predefinito appropriato per concedere le autorizzazioni dell'area di lavoro agli amministratori a livello di sottoscrizione, gruppo di risorse o area di lavoro a seconda dell'ambito delle responsabilità.

Applicare il controllo degli accessi in base al ruolo a livello di tabella per gli utenti che richiedono l'accesso a un set di tabelle tra più risorse. Gli utenti con autorizzazioni di tabella hanno accesso a tutti i dati nella tabella indipendentemente dalle relative autorizzazioni per le risorse.

Vedere Gestire l'accesso alle aree di lavoro Log Analytics per informazioni dettagliate sulle diverse opzioni per concedere l'accesso ai dati nell'area di lavoro.
Usare il collegamento privato di Azure per rimuovere l'accesso all'area di lavoro dalle reti pubbliche. Le connessioni agli endpoint pubblici sono protette tramite crittografia end-to-end. Se è necessario un endpoint privato, è possibile usare un collegamento privato di Azure per consentire alle risorse di connettersi all'area di lavoro Log Analytics tramite reti private autorizzate. È anche possibile usare un collegamento privato per forzare l'inserimento dei dati dell'area di lavoro tramite ExpressRoute o una VPN. Vedere Progettare la configurazione del collegamento privato di Azure per determinare la migliore topologia di rete e DNS per l'ambiente in uso.
Configurare il controllo delle query di log per tenere traccia degli utenti che eseguono query. Il controllo delle query di log registra i dettagli per ogni query eseguita in un'area di lavoro. Considerare questi dati di controllo come dati di sicurezza e proteggere la tabella LAQueryLogs in modo appropriato. Configurare i log di controllo per ogni area di lavoro da inviare all'area di lavoro locale o da consolidare in un'area di lavoro di sicurezza dedicata se si separano i dati operativi e di sicurezza. Usare le informazioni dettagliate dell'area di lavoro Log Analytics per esaminare periodicamente questi dati e valutare la possibilità di creare regole di avviso di ricerca log per notificare in modo proattivo se gli utenti non autorizzati tentano di eseguire query.
Garantire l'immutabilità dei dati di controllo. Monitoraggio di Azure è una piattaforma di dati di sola aggiunta, ma comprende disposizioni per eliminare i dati per motivi di conformità. È possibile impostare un blocco nell'area di lavoro di Log Analytics per bloccare tutte le attività che potrebbero eliminare i dati: ripulitura, eliminazione di tabelle e modifiche di conservazione dei dati a livello di area di lavoro o a livello di area di lavoro. Tuttavia, questo blocco può comunque essere rimosso.

Se è necessaria una soluzione completamente a prova di manomissione, è consigliabile esportare i dati in una soluzione di archiviazione non modificabile. Usare l'esportazione dei dati per inviare dati a un account di archiviazione di Azure con criteri di immutabilità per proteggersi da manomissioni dei dati. Non tutti i tipi di log hanno la stessa rilevanza per la conformità, il controllo o la sicurezza, quindi determinare i tipi di dati specifici che devono essere esportati.
Determinare una strategia per filtrare o offuscare i dati sensibili nell'area di lavoro. È possibile raccogliere dati che includono informazioni sensibili. Filtrare i record che non devono essere raccolti usando la configurazione per l'origine dati specifica. Usare una trasformazione se devono essere rimosse o offuscate solo determinate colonne nei dati.

Se si dispone di standard che richiedono che i dati originali siano non modificati, è possibile usare il valore letterale "h" nelle query KQL per offuscare i risultati delle query visualizzati nelle cartelle di lavoro.
Ripulire i dati sensibili raccolti accidentalmente. Controllare periodicamente la presenza di dati privati che potrebbero essere raccolti accidentalmente nell'area di lavoro e usare l'eliminazione dei dati per rimuoverli. I dati nelle tabelle con il piano ausiliario non possono essere eliminati.
Collegare l'area di lavoro a un cluster dedicato per funzionalità di sicurezza avanzate, inclusa la doppia crittografia usando chiavi gestite dal cliente e Customer Lockbox per Microsoft Azure per approvare o rifiutare le richieste di accesso ai dati Microsoft. Monitoraggio di Azure crittografa tutti i dati inattivi e le query salvate usando chiavi gestite da Microsoft (MMK). Se si raccolgono dati sufficienti per un cluster dedicato, usare:

- Chiavi gestite dal cliente per maggiore flessibilità e controllo del ciclo di vita chiave. Se si usa Microsoft Sentinel, assicurarsi di avere familiarità con le considerazioni riportate in Configurare la chiave gestita dal cliente di Microsoft Sentinel.

- Customer Lockbox per Microsoft Azure per esaminare e approvare o rifiutare le richieste di accesso ai dati dei clienti. Customer Lockbox viene usato quando un tecnico Microsoft deve accedere ai dati dei clienti, in risposta a un ticket di supporto avviato dal cliente o a un problema identificato da Microsoft. Non è attualmente possibile applicare Lockbox alle tabelle con il piano ausiliario.
Usare Transport Layer Security (TLS) 1.2 o versione successiva per inviare dati all'area di lavoro usando agenti, connettori e API di inserimento dei log. Per garantire la sicurezza dei dati in transito in Monitoraggio di Azure, usare Transport Layer Security (TLS) 1.2 o versione successiva. Le versioni precedenti di TLS/Secure Sockets Layer (SSL) sono state considerate vulnerabili. Nonostante siano ancora attualmente in uso per questioni di compatibilità con le versioni precedenti, non sono consigliate e il settore interromperà a breve il supporto per questi tipi precedenti di protocollo.

Il PCI Security Standards Council ha imposto il 30 giugno 30, 2018 come scadenza per disabilitare le versioni precedenti di TLS/SSL ed eseguire l'aggiornamento a protocolli più sicuri. Al termine del supporto legacy di Azure, non sarà possibile inviare dati a Log di Monitoraggio di Azure se gli agenti non possono comunicare almeno tramite TLS 1.3.

È consigliabile NON impostare esplicitamente l'agente in modo da usare SOLO TLS 1.3, a meno che non sia necessario. È preferibile consentire all'agente di rilevare, negoziare e sfruttare automaticamente gli standard di sicurezza futuri. In caso contrario, si potrebbe perdere la sicurezza aggiunta degli standard più recenti ed eventualmente riscontrare problemi se TLS 1.3 è mai deprecato a favore di tali standard più recenti.

Avvisi

Elenco di controllo della progettazione

  • Usare le chiavi gestite dal cliente se è necessaria la propria chiave di crittografia per proteggere i dati e le query salvate nelle aree di lavoro
  • Usare le identità gestite per aumentare la sicurezza controllando le autorizzazioni
  • Assegnare il ruolo lettore di monitoraggio per tutti gli utenti che non necessitano dei privilegi di configurazione
  • Usare azioni webhook sicure
  • Quando si usano gruppi di azioni con collegamenti privati, usare le azioni dell'hub eventi

Raccomandazioni per la configurazione

Elemento consigliato Vantaggio
Usare le chiavi gestite dal cliente se è necessaria la propria chiave di crittografia per proteggere i dati e le query salvate nelle aree di lavoro. Monitoraggio di Azure assicura che tutte le query salvate e tutti i dati siano crittografati quando inattivi con chiavi gestite da Microsoft. Se è necessaria la propria chiave di crittografia e si raccolgono dati sufficienti per un cluster dedicato, usare chiavi gestite dal cliente per una maggiore flessibilità e controllo del ciclo di vita delle chiavi. Se si usa Microsoft Sentinel, assicurarsi di avere familiarità con le considerazioni riportate in Configurare la chiave gestita dal cliente di Microsoft Sentinel.
Per controllare le autorizzazioni per le regole di avviso di ricerca log, usare identità gestite. Uno dei problemi comuni a cui devono far fronte gli sviluppatori riguarda la gestione di segreti, credenziali, certificati e chiavi per proteggere la comunicazione tra i servizi. Grazie alle identità gestite, gli sviluppatori non devono più gestire queste credenziali. L'impostazione di un'identità gestita per le regole di avviso di ricerca log consente di controllare e visualizzare le autorizzazioni esatte della regola di avviso. In qualsiasi momento, è possibile visualizzare le autorizzazioni di query della regola e aggiungere o rimuovere autorizzazioni direttamente dall'identità gestita. Inoltre, l'uso di un'identità gestita è necessario se la query della regola accede a Esplora dati di Azure (ADX) o Azure Resource Graph (ARG). Vedere Identità gestite.
Assegnare il ruolo lettore di monitoraggio per tutti gli utenti che non necessitano dei privilegi di configurazione. Migliorare la sicurezza concedendo agli utenti il minor numero di privilegi necessari per il proprio ruolo. Vedere Ruoli, autorizzazioni e sicurezza in monitoraggio di Azure.
Se possibile, usare azioni webhook sicure. Se la regola di avviso contiene un gruppo di azioni che usa azioni webhook, preferire l'uso di azioni webhook protette per l'autenticazione aggiuntiva. Vedere Configurare l'autenticazione per Webhook protetto

Monitoraggio delle macchine virtuali

Elenco di controllo della progettazione

  • Usare altri servizi per il monitoraggio della sicurezza delle macchine virtuali.
  • Prendere in considerazione l'uso del collegamento privato di Azure per le VM per connettersi a Monitoraggio di Azure usando un endpoint privato.

Raccomandazioni per la configurazione

Suggerimento Descrizione
Usare altri servizi per il monitoraggio della sicurezza delle macchine virtuali. Sebbene Monitoraggio di Azure sia in grado di raccogliere eventi di sicurezza dalle macchine virtuali, non è progettato per essere usato per il monitoraggio della sicurezza. Azure include numerosi servizi, ad esempio, Microsoft Defender per il cloud e Microsoft Sentinel, insieme, essi offrono una soluzione completa di monitoraggio della sicurezza. Per un confronto di questi servizi, vedere Monitoraggio della sicurezza.
Prendere in considerazione l'uso del collegamento privato di Azure per le VM per connettersi a Monitoraggio di Azure usando un endpoint privato. Le connessioni agli endpoint pubblici sono protette tramite crittografia end-to-end. Se si richiede un endpoint privato, è possibile usare il collegamento privato di Azure per consentire alle macchine virtuali di connettersi al Monitoraggio di Azure tramite reti private autorizzate. È anche possibile usare un collegamento privato per forzare l'inserimento dei dati dell'area di lavoro tramite ExpressRoute o una VPN. Vedere Progettare la configurazione del collegamento privato di Azure per determinare la migliore topologia di rete e DNS per l'ambiente in uso.

Monitoraggio contenitori

Elenco di controllo della progettazione

  • Usare l'autenticazione dell'identità gestita per il cluster per connettersi a Informazioni dettagliate sui contenitori.
  • Prendere in considerazione l'uso del collegamento privato di Azure per il cluster per connettersi all'area di lavoro di Monitoraggio di Azure usando un endpoint privato.
  • Usare Analisi del traffico per monitorare il traffico di rete da e verso il cluster.
  • Abilitare l'osservabilità della rete.
  • Verificare la sicurezza dell'area di lavoro Log Analytics che supporta informazioni dettagliate sui contenitori.

Raccomandazioni per la configurazione

Elemento consigliato Vantaggio
Usare l'autenticazione dell'identità gestita per il cluster per connettersi a Informazioni dettagliate sui contenitori. Autenticazione dell'identità gestita è l'impostazione predefinita per i nuovi cluster. Se si usa l'autenticazione legacy, è necessario eseguire la migrazione all'identità gestita per rimuovere l'autenticazione locale basata su certificato.
Prendere in considerazione l'uso del collegamento privato di Azure per il cluster per connettersi all'area di lavoro di Monitoraggio di Azure usando un endpoint privato. Il servizio gestito di Azure per Prometheus archivia i dati in un'area di lavoro di Monitoraggio di Azure che usa un endpoint pubblico per impostazione predefinita. Le connessioni agli endpoint pubblici sono protette tramite crittografia end-to-end. Se è necessario un endpoint privato, è possibile usare un collegamento privato di Azure per consentire al cluster di connettersi all'area di lavoro tramite reti private autorizzate. È anche possibile usare un collegamento privato per forzare l'inserimento dei dati dell'area di lavoro tramite ExpressRoute o una VPN.

Vedere Abilitare il collegamento privato per il monitoraggio di Kubernetes in Monitoraggio di Azure per informazioni dettagliate sulla configurazione del cluster per il collegamento privato. Per informazioni dettagliate sull'esecuzione di query sui dati tramite collegamento privato, vedere Usare endpoint privati per l'area di lavoro gestita di Prometheus e Monitoraggio di Azure.
Usare Analisi del traffico per monitorare il traffico di rete da e verso il cluster. Analisi del traffico analizza i log dei flussi NSG di Azure Network Watcher per fornire informazioni dettagliate sul flusso del traffico nel cloud di Azure. Usare questo strumento per assicurarsi che non sia presente alcuna esfiltrazione di dati per il cluster e per rilevare se sono esposti indirizzi IP pubblici non necessari.
Abilitare l'osservabilità della rete. Il componente aggiuntivo per l'osservabilità della rete per il servizio Azure Kubernetes fornisce l'osservabilità tra più livelli nello stack di rete Kubernetes. Monitorare e osservare l'accesso tra i servizi nel cluster (traffico east-west).
Verificare la sicurezza dell'area di lavoro Log Analytics che supporta informazioni dettagliate sui contenitori. Le informazioni dettagliate sui contenitori si basano su un'area di lavoro Log Analytics. Vedere Procedure consigliate per i log di Monitoraggio di Azure per consigli per garantire la sicurezza dell'area di lavoro.

Passaggio successivo