Sicurezza dei dati di log di Monitoraggio di Azure

Questo articolo illustra come Monitoraggio di Azure raccoglie, elabora e protegge i dati dei log e descrive le funzionalità di sicurezza che è possibile usare per proteggere ulteriormente l'ambiente di Monitoraggio di Azure. Le informazioni contenute in questo articolo sono specifiche dei log di Monitoraggio di Azure e integrano le informazioni sul Centro protezione di Azure.

I log di Monitoraggio di Azure gestiscono i dati basati sul cloud in modo sicuro usando:

• Separazione dei dati
• Conservazione dei dati
• Sicurezza fisica
• Gestione incidenti
• Conformità
• Certificazioni degli standard di sicurezza

Contattare Microsoft per qualsiasi domanda, suggerimento o problema riguardo a qualsiasi aspetto delle informazioni riportate in questo articolo, compresi i criteri di sicurezza. A questo scopo, visitare la pagina relativa alle opzioni di supporto di Azure.

Invio di dati in modo sicuro tramite TLS

Per garantire la sicurezza dei dati in transito in Monitoraggio di Azure, è consigliabile configurare l'agente per l'uso di almeno Transport Layer Security (TLS) 1.3. 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.

Pci Security Standards Council ha fissato una scadenza del 30 giugno 2018 per disabilitare le versioni precedenti di TLS/SSL e l'aggiornamento a protocolli più sicuri. Quando Azure elimina il supporto legacy, se gli agenti non riescono a comunicare tramite almeno TLS 1.3, non sarà possibile inviare dati ai log di Monitoraggio di Azure.

È 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.

Indicazioni specifiche in base alla piattaforma

Piattaforma/linguaggio	Supporto tecnico	Ulteriori informazioni
Linux	Le distribuzioni Linux si basano generalmente su OpenSSL per supportare TLS 1.2.	Controllare nel log delle modifiche di OpenSSL per assicurarsi che la versione di OpenSSL sia supportata.
Windows 8.0 - 10	Supportato e abilitato per impostazione predefinita.	Per confermare che si usano ancora le impostazioni predefinite.
Windows Server 2012 - 2016	Supportato e abilitato per impostazione predefinita.	Per confermare che si usano ancora le impostazioni predefinite
Windows 7 SP1 e Windows Server 2008 R2 SP1	Supportato ma non abilitato per impostazione predefinita.	Vedere la pagina Transport Layer Security (TLS) registry settings (Impostazioni del Registro di sistema di Transport Layer Security (TLS)) per informazioni dettagliate su come eseguire l'abilitazione.

Separazione dei dati

Dopo l'inserimento dei dati da Monitoraggio di Azure, i dati vengono mantenuti separati logicamente in ogni componente nel servizio. Tutti i dati vengono contrassegnati in base all'area di lavoro. Questo tag viene salvato in modo permanente durante tutto il ciclo di vita dei dati e viene applicato a ogni livello del servizio. I dati vengono archiviati in un database dedicato nel cluster di archiviazione nell'area selezionata.

Conservazione dei dati

I dati di ricerca nei log indicizzati vengono archiviati e conservati in base al piano tariffario. Per altre informazioni, vedere Prezzi di Log Analytics.

Come parte del contratto di abbonamento, Microsoft conserva i dati in base alle condizioni del contratto. L'eliminazione dei dati del cliente non comporta la distruzione delle unità fisiche.

La tabella seguente elenca alcune delle soluzioni disponibili e propone alcuni esempi del tipo di dati raccolti da tali soluzioni.

Soluzione	Tipo di dati
Capacity and Performance	Dati e metadati sulle prestazioni
Gestione degli aggiornamenti	Metadati e dati di stato
Log Management	Log eventi definiti dall'utente, log eventi di Windows e/o log di IIS
Registrazione modifiche	Inventario software, metadati di daemon dei servizi di Windows e Linux e metadati di file Windows/Linux
SQL and Active Directory Assessment	Dati WMI, dati del Registro di sistema, dati sulle prestazioni e risultati delle visualizzazioni a gestione dinamica di SQL Server

La tabella seguente mostra esempi di tipi di dati:

Tipo di dati	Campi
Avviso	Alert Name, Alert Description, BaseManagedEntityId, Problem ID, IsMonitorAlert, RuleId, ResolutionState, Priority, Severity, Category, Owner, ResolvedBy, TimeRaised, TimeAdded, LastModified, LastModifiedBy, LastModifiedExceptRepeatCount, TimeResolved, TimeResolutionStateLastModified, TimeResolutionStateLastModifiedInDB, RepeatCount
Impostazione	CustomerID, AgentID, EntityID, ManagedTypeID, ManagedTypePropertyID, CurrentValue, ChangeDate
Event	EventId, EventOriginalID, BaseManagedEntityInternalId, RuleId, PublisherId, PublisherName, FullNumber, Number, Category, ChannelLevel, LoggingComputer, EventData, EventParameters, TimeGenerated, TimeAdded Nota: Log Analytics raccoglie gli eventi scritti con campi personalizzati nel registro eventi di Windows.
Metadati UFX	BaseManagedEntityId, ObjectStatus, OrganizationalUnit, ActiveDirectoryObjectSid, PhysicalProcessors, NetworkName, IPAddress, ForestDNSName, NetbiosComputerName, VirtualMachineName, LastInventoryDate, HostServerNameIsVirtualMachine, IP Address, NetbiosDomainName, LogicalProcessors, DNSName, DisplayName, DomainDnsName, ActiveDirectorySite, PrincipalName, OffsetInMinuteFromGreenwichTime
Prestazioni	ObjectName, CounterName, PerfmonInstanceName, PerformanceDataId, PerformanceSourceInternalID, SampleValue, TimeSampled, TimeAdded
Provincia	StateChangeEventId, StateId, NewHealthState, OldHealthState, Context, TimeGenerated, TimeAdded, StateId2, BaseManagedEntityId, MonitorId, HealthState, LastModified, LastGreenAlertGenerated, DatabaseTimeModified

Sicurezza fisica

Monitoraggio di Azure viene gestito dal personale Microsoft e tutte le attività vengono registrate e possono essere controllate. Monitoraggio di Azure viene gestito come servizio di Azure e soddisfa tutti i requisiti di conformità e sicurezza di Azure. È possibile verificare i dettagli sulla sicurezza fisica delle risorse di Azure a pagina 18 della panoramica della sicurezza in Microsoft Azure. I diritti di accesso fisico per proteggere le aree vengono modificati entro un giorno lavorativo per chiunque non abbia più la responsabilità del servizio Monitoraggio di Azure, incluso il trasferimento e la terminazione. Altre informazioni sull'infrastruttura fisica globale sono disponibili nei data center di Microsoft.

Gestione incidenti

Monitoraggio di Azure ha un processo di gestione degli eventi imprevisti a cui tutti i servizi Microsoft sono conformi. Per riepilogare:

• Usare un modello di responsabilità condivisa in cui la responsabilità della sicurezza viene ripartita tra Microsoft e il cliente
• Gestire gli eventi imprevisti di sicurezza di Azure:
  • Avviare un'indagine quando viene rilevato un evento imprevisto
  • Far valutare l'impatto e la gravità dell'evento imprevisto a un membro del team di risposta agli eventi imprevisti su chiamata. In base alle prove, la valutazione potrebbe o meno comportare un'escalation ulteriore al team di risposta alla sicurezza.
  • Diagnosticare un evento imprevisto da parte di esperti di risposta alla sicurezza per condurre l'indagine tecnica o forense, identificare il contenimento, la mitigazione e aggirare le strategie. Se il team di sicurezza ritiene che i dati dei clienti potrebbero essere stati esposti a un individuo illecito o non autorizzato, l'esecuzione parallela del processo di notifica degli eventi imprevisti del cliente inizia in parallelo.
  • Stabilizzare e correggere l'evento imprevisto. Il team di risposta agli eventi imprevisti sviluppa un piano di recupero per porre rimedio al problema. I passaggi di contenimento delle crisi, ad esempio la quarantena dei sistemi interessati, possono verificarsi immediatamente e in parallelo con la diagnosi. È possibile pianificare mitigazioni a lungo termine che si verificano dopo il superamento del rischio immediato.
  • Chiudere l'evento imprevisto ed eseguire una relazione finale. Il team di risposta agli eventi imprevisti redige una relazione finale che descrive nei dettagli l'evento imprevisto, con l'intenzione di modificare i criteri, le procedure e i processi per evitare che tale evento possa ripetersi in futuro.
• Notificare ai clienti gli eventi imprevisti di sicurezza:
  • Determinare l'ambito dei clienti coinvolti e inviare il prima possibile una notifica a chiunque sia stato coinvolto
  • Creare un avviso per fornire ai clienti tutte le informazioni dettagliate affinché possano svolgere le opportune indagini e rispettare gli impegni presi con gli utenti finali senza ritardare eccessivamente il processo di notifica.
  • Confermare e dichiarare l'evento imprevisto, in base alle esigenze.
  • Informare i clienti con una notifica sull'evento imprevisto senza ritardi ingiustificati e nel rispetto dei termini legali o contrattuali. La notifica di eventi imprevisti di sicurezza viene recapitata a uno o più amministratori del cliente per mezzo di un qualsiasi canale scelto da Microsoft, inclusa la posta elettronica.
• Eseguire la preparazione e la formazione del team:
  • Il personale di Microsoft è tenuto a completare una formazione in materia di sicurezza e consapevolezza, per poter identificare e segnalare problemi di sicurezza sospetti.
  • Gli operatori che usano il servizio Microsoft Azure hanno l'obbligo di sostenere una formazione aggiuntiva in relazione alla loro possibilità di accedere ai sistemi riservati che ospitano i dati dei clienti.
  • Il personale di risposta di sicurezza Microsoft riceve una formazione specializzata per i ruoli ricoperti

Anche se raramente, Microsoft invia una notifica a ogni cliente entro un giorno se si verifica una perdita significativa di dati dei clienti.

Per altre informazioni sulle modalità di risposta agli eventi imprevisti in merito alla sicurezza di Microsoft, vedere Risposta di Microsoft Azure Security nel cloud.

Conformità

Il programma di governance e sicurezza delle informazioni del team di monitoraggio di Azure supporta i requisiti aziendali e rispetta le leggi e le normative, come descritto in Centro protezione di Microsoft Azure e conformità al Centro protezione Microsoft. In che modo i log di Monitoraggio di Azure stabiliscono i requisiti di sicurezza, identificano anche i controlli di sicurezza, gestisce e monitora i rischi. Ogni anno esaminiamo criteri, standard, procedure e linee guida.

Ciascun membro del team di sviluppo riceve una formazione formale sulla sicurezza delle applicazioni. Internamente, viene usato un sistema di controllo della versione per lo sviluppo di software, che protegge ogni singolo progetto software.

Microsoft ha un team di sicurezza e conformità che supervisiona e valuta tutti i servizi di Microsoft. I responsabili della sicurezza delle informazioni costituiscono il team e non sono associati ai team di progettazione che sviluppano Log Analytics. Gli addetti alla sicurezza dispongono della propria catena di gestione ed eseguono valutazioni indipendenti di prodotti e servizi per garantirne la sicurezza e la conformità.

Il consiglio di amministrazione di Microsoft viene tenuto aggiornato tramite un report annuale su tutti i programmi per la sicurezza delle informazioni messi in atto da Microsoft.

Il team dedicato allo sviluppo software e al servizio Log Analytics è impegnato attivamente nella collaborazione con il team legale di Microsoft, nonché con il team dedicato alla gestione della conformità e con altri partner di settore, per acquisire varie certificazioni.

Certificazioni e attestazioni

Azure Log Analytics soddisfa i requisiti seguenti:

• ISO/IEC 27001
• ISO/IEC 27018:2014
• ISO 22301
• Conformità al Payment Card Industry Data Security Standard (PCI DSS) del PCI Security Standard Council
• Service Organization Controls (SOC) 1 di tipo 1 e SOC 2 di tipo 1
• HIPAA e HITECH per le società che hanno un contratto di società in affari HIPAA
• Criteri di progettazione comuni di Windows
• Microsoft Trustworthy Computing
• Come servizio di Azure, i componenti usati da Monitoraggio di Azure rispettano i requisiti di conformità di Azure. Altre informazioni disponibili in Centro protezione Microsoft - Conformità.

Nota

In alcune certificazioni/attestazioni, i log di Monitoraggio di Azure sono elencati sotto il nome precedente di Operational Insights.

Flusso di dati sulla sicurezza del cloud computing

Il diagramma seguente illustra un'architettura di sicurezza cloud come flusso di informazioni dell'azienda e come viene protetta così com'è lo spostamento in Monitoraggio di Azure, in definitiva vista dall'utente nel portale di Azure. IL diagramma riporta anche informazioni aggiuntive su ogni passaggio.

1. Iscriversi a Monitoraggio di Azure e raccogliere dati

Per consentire all'organizzazione di inviare dati ai log di Monitoraggio di Azure, configurare un agente Windows o Linux in esecuzione in macchine virtuali di Azure o in computer virtuali o fisici nell'ambiente o in un altro provider di servizi cloud. Se si usa Operations Manager, dal gruppo di gestione configurare l'agente di Operations Manager. Gli utenti (che possono essere utenti singoli o gruppi) creano una o più aree di lavoro di Log Analytics e registrano gli agenti usando uno degli account seguenti:

• ID aziendale
• Account Microsoft - Outlook, Office Live, MSN

Un'area di lavoro Log Analytics viene usata per raccogliere, aggregare, analizzare e presentare i dati. Un'area di lavoro è univoca e viene usata principalmente per eseguire la partizione dei dati. Si possono ad esempio gestire i dati di produzione con un'area di lavoro e i dati di test con un'altra area di lavoro. Le aree di lavoro vengono anche usate da un amministratore per controllare l'accesso ai dati ad opera degli utenti. A ogni area di lavoro possono essere associati più account utente, ognuno dei quali può accedere a più aree di lavoro di Log Analytics. Creare le aree di lavoro in base all'area data center.

Per Operations Manager, il gruppo di gestione di Operations Manager stabilisce una connessione con il servizio Monitoraggio di Azure. Quindi si specificano i sistemi gestiti tramite agente del gruppo di gestione a cui è consentito raccogliere e inviare dati al servizio. A seconda della soluzione abilitata, i dati di queste soluzioni vengono inviati direttamente da un server di gestione di Operations Manager al servizio Monitoraggio di Azure o a causa del volume di dati raccolti dal sistema gestito dall'agente, vengono inviati direttamente dall'agente al servizio. Per i sistemi non monitorati da Operations Manager, ognuno si connette in modo sicuro al servizio Monitoraggio di Azure direttamente.

Tutte le comunicazioni tra sistemi connessi e il servizio Monitoraggio di Azure vengono crittografate. Il protocollo TLS (HTTPS) viene usato per la crittografia. Viene seguita la procedura di Microsoft SDL per assicurare che Log Analytics sia aggiornato con i più recenti progressi nel campo dei protocolli di crittografia.

Ogni tipo di agente raccoglie i dati di log per Monitoraggio di Azure. Il tipo di dati raccolti dipende dalla configurazione dell'area di lavoro e da altre funzionalità di Monitoraggio di Azure.

2. Invio dei dati dagli agenti

Tutti i tipi di agente vengono registrati con una chiave di registrazione e viene stabilita una connessione sicura tra l'agente e il servizio Monitoraggio di Azure usando l'autenticazione basata su certificati e TLS con la porta 443. Monitoraggio di Azure usa un archivio segreto per generare e gestire le chiavi. Le chiavi private sono soggette a rotazione ogni 90 giorni, vengono archiviate in Azure e sono gestite dalle operazioni di Azure in ottemperanza alle procedure consigliate in materia di conformità e normative.

Con Operations Manager, il gruppo di gestione registrato con un'area di lavoro Log Analytics stabilisce una connessione HTTPS protetta con un server di gestione di Operations Manager.

Per gli agenti Windows o Linux in esecuzione su macchine virtuali di Azure, viene usata una chiave di archiviazione di sola lettura per leggere gli eventi di diagnostica nelle tabelle di Azure.

Con qualsiasi agente che invia report a un gruppo di gestione di Operations Manager integrato con Monitoraggio di Azure, se il server di gestione non è in grado di comunicare con il servizio per qualsiasi motivo, i dati raccolti vengono archiviati localmente in una cache temporanea nel server di gestione. Provano a inviare i dati ogni 8 minuti per 2 ore. Per i dati che ignorano il server di gestione e vengono inviati direttamente a Monitoraggio di Azure, il comportamento è coerente con l'agente Windows.

I dati memorizzati nella cache dell'agente del server di gestione o Windows sono protetti dall'archivio credenziali del sistema operativo. Se il servizio non è in grado di elaborare i dati dopo due ore, gli agenti accoderanno i dati. Se la coda si riempie, l'agente inizia a eliminare i tipi di dati, a partire dai dati sulle prestazioni. Il limite delle code agente è una chiave di registro modificabile quando necessario. I dati raccolti vengono compressi e inviati al servizio, ignorando i database del gruppo di gestione di Operations Manager, in modo da non aggiungervi alcun carico. Dopo l'invio dei dati raccolti, i dati vengono rimossi dalla cache.

Come descritto in precedenza, i dati del server di gestione o degli agenti connessi diretti vengono inviati tramite TLS ai data center di Microsoft Azure. Facoltativamente, è possibile usare ExpressRoute per fornire maggiore sicurezza per i dati. ExpressRoute è un modo per connettersi direttamente ad Azure da una rete WAN esistente, ad esempio una rete VPN MPLS (multi-protocol label switching), fornita da un provider di servizi di rete. Per altre informazioni, vedere ExpressRoute e Il traffico dell'agente usa la connessione Azure ExpressRoute?.

3. Il servizio Monitoraggio di Azure riceve ed elabora i dati

Il servizio Monitoraggio di Azure garantisce che i dati in ingresso provenano da un'origine attendibile convalidando i certificati e l'integrità dei dati con l'autenticazione di Azure. I dati non elaborati vengono quindi archiviati in un Hub eventi di Azure nell'area in cui i dati verranno archiviati inattivi. Il tipo dei dati archiviati dipende dai tipi di soluzioni importati e usati per raccogliere i dati. Il servizio Monitoraggio di Azure elabora quindi i dati non elaborati e lo inserisce nel database.

Il periodo di conservazione dei dati raccolti archiviati nel database varia a seconda del piano tariffario selezionato. Per il livello gratuito, i dati raccolti sono disponibili per sette giorni. Per il livello a pagamento, i dati raccolti sono disponibili per 31 giorni per impostazione predefinita, ma è possibile estendere il periodo a 730 giorni. I dati vengono archiviati crittografati inattivi nell'archiviazione di Azure, per garantire la riservatezza dei dati e i dati vengono replicati all'interno dell'area locale usando l'archiviazione con ridondanza locale o l'archiviazione con ridondanza della zona nelle aree supportate. Le ultime due settimane di dati vengono archiviate anche nella cache basata su SSD e questa cache viene crittografata.

I dati nell'archiviazione del database non possono essere modificati una volta inseriti, ma possono essere eliminati tramite il percorso dell'API di eliminazione. Anche se non è possibile modificare i dati, alcune certificazioni richiedono che i dati vengano mantenuti non modificabili e non possano essere modificati o eliminati nell'archiviazione. È possibile ottenere l'immutabilità dei dati tramite l'esportazione dei dati in un account di archiviazione configurato come archiviazione non modificabile.

4. Usare Monitoraggio di Azure per accedere ai dati

Per accedere all'area di lavoro Log Analytics, accedere al portale di Azure usando l'account aziendale o l'account Microsoft configurato in precedenza. Tutto il traffico tra il portale e il servizio Monitoraggio di Azure viene inviato tramite un canale HTTPS sicuro. Quando si usa il portale, viene generato un ID di sessione nel client utente (Web browser) e i dati vengono archiviati in una cache locale fino al termine della sessione. Dopodiché, la cache viene svuotata. I cookie sul lato client, che non contengono informazioni personali, non vengono rimossi automaticamente. I cookie di sessione sono protetti e contrassegnati HTTPOnly. Dopo un periodo di inattività predeterminato, la sessione di portale di Azure viene terminata.

Chiavi di sicurezza gestite dal cliente

I dati in Monitoraggio di Azure vengono crittografati con chiavi gestite da Microsoft. È possibile usare chiavi di crittografia gestite dal cliente per proteggere i dati e le query salvate nelle aree di lavoro. Le chiavi gestite dal cliente in Monitoraggio di Azure offrono maggiore flessibilità per gestire i controlli di accesso ai log.

Dopo la configurazione, i nuovi dati inseriti nelle aree di lavoro collegate vengono crittografati con la chiave archiviata in Azure Key Vault o il "modulo di protezione hardware" gestito da Azure Key Vault.

Archiviazione privata

I log di Monitoraggio di Azure si basano su Archiviazione di Azure in scenari specifici. Usare l'archiviazione privata/gestita dal cliente per gestire l'account di archiviazione crittografato personalmente.

Rete a collegamento privato

collegamento privato di Azure rete consente di collegare in modo sicuro i servizi PaaS (Platform as a Service) di Azure, tra cui Monitoraggio di Azure, alla rete virtuale usando endpoint privati.

Customer Lockbox per Microsoft Azure

Customer Lockbox per Microsoft Azure offre un'interfaccia per esaminare e approvare o rifiutare le richieste di accesso ai dati dei clienti. 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. Per abilitare Customer Lockbox, è necessario un cluster dedicato.

Manomissione e immutabilità

Monitoraggio di Azure è una piattaforma dati di sola accodamento, ma include il provisioning per eliminare i dati a scopo di conformità. È possibile impostare un blocco nell'area di lavoro 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.

Per manomettere completamente la soluzione di monitoraggio, è consigliabile esportare i dati in una soluzione di archiviazione non modificabile.

Domande frequenti

Questa sezione fornisce le risposte alle domande comuni.

Il traffico dell'agente usa la connessione Azure ExpressRoute?

Il traffico verso Monitoraggio di Azure usa il circuito ExpressRoute di peering Microsoft. Per una descrizione dei diversi tipi di traffico ExpressRoute, vedere la documentazione di ExpressRoute.