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 di Log di Monitoraggio di Azure e integrano le informazioni sul Centro protezione di Azure.
Log di Monitoraggio di Azure gestisce 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 dei dati in modo sicuro tramite TLS
Per garantire la sicurezza dei dati in transito verso Monitoraggio di Azure, è consigliabile configurare l'agente in modo da usare almeno il protocollo 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.
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.
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. | Assicurarsi che le impostazioni predefinite siano ancora in uso. |
| Windows Server 2012 - 2016 | Supportato e abilitato per impostazione predefinita. | Assicurarsi che le impostazioni predefinite siano ancora in uso |
| 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 essere stati inseriti da Monitoraggio di Azure, i dati vengono mantenuti separati logicamente in ogni componente del servizio. Tutti i dati vengono contrassegnati in base all'area di lavoro. Tale contrassegno persiste per tutto il ciclo di vita dei dati e viene applicato a ogni livello del servizio. I dati sono 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.
Microsoft conserva i dati secondo i termini del contratto di sottoscrizione. 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 |
|---|---|
| Alert | 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 è gestito da 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 di 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 fisici per proteggere le aree vengono modificati nell'arco della giornata lavorativa per chi non è più responsabile del servizio Monitoraggio di Azure, includendo il trasferimento e la chiusura. Altre informazioni sull'infrastruttura fisica globale sono disponibili nei data center di Microsoft.
Gestione incidenti
Monitoraggio di Azure dispone di un processo di gestione degli eventi imprevisti a cui aderiscono tutti i servizi di Microsoft. 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 correlati alla 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 raccolte, la valutazione può o non può comportare un'ulteriore l'escalation al team di risposta di sicurezza.
- Far eseguire la diagnosi di un evento imprevisto ad esperti di risposta di sicurezza per condurre l'indagine tecnica o forense e identificare le strategie di contenimento, attenuazione e risoluzione. Se il team di sicurezza ritiene che i dati dei clienti possano essere esposti al rischio di accesso illegale o non autorizzato di un singolo utente, viene avviata l'esecuzione in parallelo del processo di notifica di evento imprevisto al cliente.
- 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 per il contenimento della crisi, ad esempio la messa in quarantena dei sistemi coinvolti, possono verificarsi immediatamente e in parallelo con la diagnosi. È possibile pianificare le operazioni di risoluzione dei problemi a lungo termine che vengono eseguite 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.
- Inviare ai clienti una notifica sugli eventi imprevisti relativi alla 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.
- Svolgere la formazione e verificare la preparazione 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 per la sicurezza delle informazioni del team di sviluppo e assistenza del software Monitoraggio di Azure supporta requisiti interni ed è conforme alle leggi e alle normative, come descritto nel Centro protezione di Azure e nella sezione Conformità del centro protezione Microsoft. Qui viene anche descritto il modo in cui Log di Monitoraggio di Azure stabilisce i requisiti di sicurezza, identifica i controlli di sicurezza, gestisce e controlla i rischi. Ogni anno viene effettuata una revisione di 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 si avvale di un team per la sicurezza e conformità che supervisiona e valuta tutti i servizi in Microsoft. Il team è composto da addetti alla sicurezza delle informazioni che non sono associati ai team tecnici 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 aderiscono ai requisiti di conformità di Azure. Altre informazioni disponibili in Centro protezione Microsoft - Conformità.
Nota
In alcune certificazioni e attestazioni Log di Monitoraggio di Azure viene indicato con il nome precedente, Operational Insights.
Flusso di dati sulla sicurezza del cloud computing
Il diagramma seguente mostra un'architettura di sicurezza cloud come flusso di informazioni in uscita dall'azienda, il modo in cui tale flusso viene protetto durante il percorso Monitoraggio di Azure e infine come viene visualizzato nel portale di Azure. IL diagramma riporta anche informazioni aggiuntive su ogni passaggio.
1. Iscriversi a Monitoraggio di Azure e raccogliere dati
Per permettere all'organizzazione di inviare dati a Monitoraggio di Azure, configurare un agente Windows o Linux in esecuzione sulle macchine virtuali Azure o sui computer fisici o virtuali 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:
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 oppure, a causa del volume dei 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 direttamente al servizio Monitoraggio di Azure.
Tutte le comunicazioni tra i sistemi connessi e il servizio di Monitoraggio di Azure sono 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
Si registrano tutti i tipi di agente 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.
Per ogni 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 un motivo qualsiasi, i dati raccolti vengono archiviati in locale in una cache temporanea sul 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 di 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 può elaborare i dati dopo due ore, i dati vengono accodati dagli agenti. 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 dei gruppi di gestione di Operations Manager, che in questo modo non vengono sovraccaricati. Dopo l'invio, i dati raccolti vengono rimossi dalla cache.
Come descritto sopra, i dati provenienti dal server di gestione o dagli agenti connessi direttamente vengono inviati tramite TLS ai data center di Microsoft Azure. Facoltativamente, è possibile usare ExpressRoute per proteggere ulteriormente 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
Per garantire che i dati in arrivo provengano da un'origine attendibile, il servizio Monitoraggio di Azure convalida i certificati e l'integrità dei dati con l'autenticazione di Azure. I dati non elaborati vengono quindi archiviati in Hub di eventi di Azure nell'area in cui verranno infine archiviati i dati inattivi. Il tipo dei dati archiviati dipende dai tipi di soluzioni importati e usati per raccogliere i dati. Successivamente, il servizio Monitoraggio di Azure elabora i dati non elaborati e li 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 in modalità crittografata quando sono inattivi in Archiviazione di Azure, per garantirne la riservatezza, e vengono replicati all'interno dell'area locale mediante archiviazione con ridondanza locale (LRS) o archiviazione con ridondanza della zona (ZRS) nelle aree supportate. Le ultime due settimane di dati vengono inoltre archiviate nella cache basata su SSD e questa cache non è crittografata.
I dati nell'archiviazione del database non possono essere modificati una volta inseriti, ma possono essere eliminati tramite il percorso dell'API elimina. Anche se i dati non possono essere modificati, alcune certificazioni richiedono che i dati siano mantenuti come non modificabili e non possono essere modificati o eliminati nella risorsa di 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 di Log Analytics, accedere al portale di Azure usando l'account aziendale o l'account Microsoft configurato prima. 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à prestabilito, la sessione del portale di Azure termina.
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 nell'HSM, "modulo di protezione hardware", gestito da Azure Key Vault.
Archiviazione privata
Log di Monitoraggio di Azure si basa 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
La rete di Collegamento privato di Azure consente di collegare in modo sicuro i servizi Platform as a Service (PaaS) di Azure, tra cui Monitoraggio di Azure, alla rete virtuale usando endpoint privati.
Customer Lockbox per Microsoft Azure
Customer Lockbox per Microsoft Azure fornisce un'interfaccia che consente di esaminare e approvare oppure 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 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.
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.