Considerazioni sulla protezione dei dati
Il diagramma seguente illustra la modalità con la quale i servizi archiviano e recuperano i dati di oggetti Microsoft Entra tramite un livello di autorizzazione controllo degli accessi in base al ruolo (RBAC). Questo livello chiama il livello di accesso ai dati della directory interna, assicurando che la richiesta di dati utente sia consentita:
Accesso alle interfacce interne di Microsoft Entra: le comunicazioni da servizio a servizio con altri servizi Microsoft, ad esempio Microsoft 365, utilizzano le interfacce di Microsoft Entra ID che autorizzano i chiamanti del servizio tramite certificati client.
Accesso alle interfacce esterne di Microsoft Entra: l'interfaccia esterna di Microsoft Entra aiuta a prevenire le perdite di dati grazie al controllo degli accessi in base al ruolo. Quando un'entità di sicurezza, ad esempio un utente, effettua una richiesta di accesso per leggere le informazioni tramite le interfacce di Microsoft Entra ID, un token di sicurezza deve accompagnare la richiesta. Il token contiene le attestazioni sull'entità che effettua la richiesta.
I token di sicurezza vengono emessi dai servizi di autenticazione di Microsoft Entra. Le informazioni relative all'esistenza, allo stato abilitato e al ruolo dell'utente vengono usate dal sistema di autorizzazione per determinare se l'accesso richiesto al tenant di destinazione è autorizzato per questo utente nella sessione corrente.
Accesso alle applicazioni: poiché le applicazioni possono accedere alle API (Application Programming Interface) senza contesto utente, il controllo di accesso include informazioni sull'applicazione dell'utente e sull'ambito dell'accesso richiesto, ad esempio di sola lettura, lettura/scrittura, e così via. Molte applicazioni usano OpenID Connect oppure Open Authorization (OAuth) per ottenere i token di accesso alla directory per conto dell'utente. A queste applicazioni deve essere concesse in modo esplicito l'accesso alla directory, altrimenti non riceveranno un token dal servizio di autenticazione di Microsoft Entra e potranno accedere ai dati dall'ambito autorizzato.
Controllo: l'accesso viene controllato. Ad esempio, azioni autorizzate quali, creazione di utenti e reimpostazione della password, creano un audit trail che può essere usato da un amministratore del tenant per la gestione della conformità o delle indagini. Gli amministratori del tenant possono generare dei report di controllo usando l'API di controllo di Microsoft Entra.
Altre informazioni: Log di controllo in Microsoft Entra ID
Isolamento del tenant: l'imposizione della sicurezza nell'ambiente multi-tenant di Microsoft Entra aiuta a raggiungere due obiettivi principali:
- Prevenire la perdita di dati e l'accesso tra tenant: i dati appartenenti al Tenant 1 non possono essere ottenuti dagli utenti nel Tenant 2 senza l'autorizzazione esplicita del Tenant 1.
- Isolamento dell'accesso alle risorse tra tenant: le operazioni eseguite dal Tenant 1 non possono influire sull'accesso alle risorse per il Tenant 2.
Isolamento dei tenant
Le informazioni seguenti descrivono l'isolamento del tenant.
- Il servizio protegge i tenant usando i criteri di controllo degli accessi in base al ruolo per garantire l'isolamento dei dati.
- Per abilitare l'accesso a un tenant, a un'entità, ad esempio un utente o un'applicazione, è necessario che sia in grado di eseguire l'autenticazione con Microsoft Entra ID per ottenere il contesto e che disponga di autorizzazioni esplicite definite nel tenant. Se un'entità non è autorizzata nel tenant, il token risultante non avrà le autorizzazioni e il sistema di controllo degli accessi in base al ruolo rifiuterà le richieste in questo contesto.
- Il controllo degli accessi in base al ruolo garantisce che l'accesso a un tenant venga eseguito da un'entità di sicurezza autorizzata nel tenant. L'accesso tra tenant è possibile se un amministratore del tenant crea una rappresentazione dell'entità di sicurezza nello stesso tenant (ad esempio, eseguendo il provisioning di un account utente guest tramite collaborazione B2B), oppure se un amministratore del tenant crea un criterio per abilitare una relazione di trust con un altro tenant. Ad esempio, un criterio di accesso tra tenant per abilitare la connessione diretta B2B. Ogni tenant è un limite di isolamento; l'esistenza in un tenant non equivale all'esistenza in un altro tenant, a meno che ciò non sia stato consentito dall'amministratore.
- I dati di Microsoft Entra per più tenant vengono archiviati nello stesso server fisico e nello stesso drive per una determinata partizione. L'isolamento viene garantito perché l'accesso ai dati è protetto dal sistema di autorizzazione del controllo degli accessi in base al ruolo.
- L'applicazione di un cliente non può accedere a Microsoft Entra ID senza la necessaria autenticazione. La richiesta viene rifiutata se non accompagnata da credenziali come parte del processo di negoziazione della connessione iniziale. Tale dinamica impedisce l'accesso non autorizzato a un tenant da parte dei tenant confinanti. Solo il token delle credenziali utente o il token SAML (Security Assertion Markup Language) viene negoziato con un trust federato. Di conseguenza, esso viene convalidato da Microsoft Entra ID in base alle chiavi condivise configurate dal proprietario dell'applicazione.
- Poiché non esiste alcun componente dell'applicazione che possa essere eseguito dall'archivio principale, un tenant non potrà violare con la forza l'integrità di un tenant confinante.
Sicurezza dei dati
Crittografia in transito: per garantire la sicurezza dei dati, i dati della directory in Microsoft Entra ID vengono firmati e crittografati durante il transito tra data center in un'unità di scala. I dati vengono crittografati e non crittografati dal livello Microsoft Entra Core Store, che risiede in aree protette di hosting del server dei data center Microsoft associati.
I servizi Web rivolti ai clienti sono protetti tramite il protocollo TLS (Transport Layer Security).
Archiviazione segreta: il back-end del servizio Microsoft Entra si avvale della crittografia per archiviare il materiale sensibile che il servizio deve utilizzare, ad esempio certificati, chiavi, credenziali e hash che usano la tecnologia proprietaria Microsoft. La scelta dell'archivio usato dipende dal servizio, dall'operazione, dall'ambito del segreto (a livello di utente o di tenant) e da altri requisiti.
Questi archivi sono gestiti da un gruppo di sicurezza tramite automazione e flussi di lavoro stabiliti, tra cui richiesta di un certificato, di un rinnovo, di revoca e distruzione.
Il controllo delle attività è correlato a questi archivi,flussi di lavoro e processi e non è previsto alcun accesso permanente. L'accesso si basa su richiesta e approvazione e prevede un periodo di tempo limitato.
Per altre informazioni sulla crittografia privata dei dati inattivi, vedere la tabella seguente.
Algoritmi: nella tabella seguente sono elencati gli algoritmi di crittografia minimi usati dai componenti di Microsoft Entra. Come servizio cloud, Microsoft rivaluta e migliora la crittografia in base ai risultati della ricerca sulla sicurezza, delle revisioni di sicurezza interne, dell'attendibilità della chiave rispetto all'evoluzione hardware, e così via.
| Dati/scenario | Algoritmo di crittografia |
|---|---|
| Password di sincronizzazione hash Password dell'account cloud |
Hash: funzione 2 di derivazione di chiave della password (PBKDF2), usando HMAC (Hash-based Message Authentication Code)-SHA256 per 1.000 iterazioni |
| Directory in transito tra data center | AES-256-CTS-HMAC-SHA1-96 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
| Flusso di credenziali utente di autenticazione pass-through | Coppia di chiavi RSA 2048-pubblica/privata Altre informazioni: Approfondimento sulla sicurezza dell'autenticazione pass-through di Microsoft Entra |
| Writeback delle password self-service con Microsoft Entra Connect: comunicazione da cloud a locale | Coppia di chiavi RSA 2048 privata/pubblica AES_GCM (dimensioni chiave a 256 bit, 96 bit IV) |
| Reimpostazione della password self-service: risposte alle domande di sicurezza | SHA256 |
| Certificati SSL per l'applicazione Microsoft Entra Applicazioni pubblicate da proxy |
AES-GCM 256 bit |
| Crittografia a livello di disco | XTS-AES 128 |
| Seamless Single Sign-On (SSO) password account del servizio credenziali di provisioning dell’applicazione Software as a Service (SaaS) |
AES-CBC 128-bit |
| Identità gestite per le risorse di Azure | AES-GCM 256 bit |
| App Microsoft Authenticator: accesso senza password a Microsoft Entra ID | Chiave RSA asimmetrica a 2048 bit |
| App Microsoft Authenticator: backup e ripristino dei metadati dell'account aziendale | AES-256 |
Risorse
- Documenti di attendibilità dei servizi Microsoft
- Centro protezione di Microsoft Azure
- Recuperare le eliminazioni in Microsoft Entra ID
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per