Considerazioni operative per i dati
In questo articolo vengono fornite informazioni sulle considerazioni operative sui dati per la propria configurazione. Sono disponibili informazioni sul funzionamento dei file di log e di altre funzionalità in relazione all'ID Microsoft Entra, ad esempio i dati di utilizzo e la sicurezza dell'operatore. Verranno fornite informazioni sulle considerazioni sulla sicurezza fisica oltre ad indicazioni su come il team di Microsoft Entra definisce distribuzioni e cambiamenti.
File di registro
Microsoft Entra ID genera file di log per il controllo, l'analisi e il debug per azioni ed eventi nel servizio. I file di log possono contenere dati relativi a utenti, dispositivi e alla configurazione di Microsoft Entra, ad esempio criteri, app e gruppi. I file di log vengono creati e archiviati in Archiviazione di Azure nel data center in cui viene eseguito il servizio Microsoft Entra.
I file di log vengono usati per il debug locale, la sicurezza, l'analisi di utilizzo, il monitoraggio dell'integrità del sistema e l'analisi a livello di servizio. Questi log vengono copiati tramite una connessione Transport Layer Security (TLS) ai sistemi di Machine Learning di Microsoft, i quali si trovano nei data center di proprietà di Microsoft negli Stati Uniti continentali.
Dati di utilizzo
I dati di utilizzo sono metadati generati dal servizio Microsoft Entra che indicano come viene usato il servizio. Questi metadati vengono usati per generare report relativi ad amministratori e utenti. Il team di progettazione di Microsoft Entra usa i metadati per valutare l'utilizzo del sistema e identificare opportunità di miglioramento per il servizio. In genere, questi dati vengono scritti in file di log, ma in alcuni casi vengono raccolti di sistemi di monitoraggio e creazione di report del servizio.
Sicurezza degli operatori
L'accesso all'ID Microsoft Entra da parte di personale Microsoft, di contraenti e di fornitori (amministratori di sistema) è altamente limitato. Laddove possibile, l'intervento umano viene sostituito da un processo automatizzato basato su strumenti, incluse funzioni di routine come distribuzione, debug, raccolta diagnostica e riavvio dei servizi.
L'accesso amministratore è limitato a un subset di tecnici qualificati e richiede il completamento di una richiesta di autenticazione con credenziali resistenti al phishing. Le funzioni di accesso e aggiornamento del sistema vengono assegnate a ruoli gestiti dal sistema di gestione accesso privilegiato Microsoft just-in-time (JIT). Gli amministratori di sistema richiedono l'elevazione dei privilegi usando il sistema JIT, che instrada la richiesta di approvazione manuale o automatica. Dopo l'approvazione, JIT eleva l'account. Le richieste di elevazione, approvazione, elevazione dei ruoli e rimozione da ruoli vengono registrate per indagini o debug futuri.
Il personale Microsoft può eseguire operazioni solo da una workstation di accesso sicuro, che usa una piattaforma di identità con autenticazione avanzata isolata interna. L'accesso ad altri sistemi di identità Microsoft non concede l'accesso alla workstation di accesso alla sicurezza. Identity Platform viene eseguito separatamente da altri sistemi di gestione di identità Microsoft.
Sicurezza fisica
L'accesso fisico a server che comprendono il servizio Microsoft Entra e l'accesso a sistemi back-end Microsoft Entra sono limitati dalla struttura di Azure, dall'ambiente locale e dalla sicurezza fisica. I clienti di Microsoft Entra non hanno accesso ad asset fisici o posizioni; pertanto, non possono bypassare le verifiche logiche dei criteri di controllo degli accessi in base al ruolo (RBAC). Il personale con accesso operatore è autorizzato a eseguire flussi di lavoro approvati per la manutenzione.
Altre informazioni: Strutture di Azure, sedi e sicurezza fisica
Processo di controllo delle modifiche
Per implementare le modifiche al servizio tra data center, il team di Microsoft Entra definisce i livelli di un ambiente di distribuzione. L'applicazione dei livelli di modifica è vincolata da rigorosi criteri di uscita. La quantità di tempo per eseguire il rollback di una modifica tra i livelli è definita dal team operativo ed è basata su potenziali effetti. In genere, un'implementazione richiede da 1 a 2 settimane. Modifiche critiche, ad esempio correzioni relative alla sicurezza o correzioni urgenti, possono essere distribuite più velocemente. Se una modifica non soddisfa i criteri di uscita quando viene applicata a un livello di distribuzione, viene eseguito il rollback allo stato stabile precedente.
Risorse
- Documenti di attendibilità dei servizi Microsoft
- Cloud attendibile di Microsoft Azure
- Data center di Office 365