Considérations relatives à la protection des données
Le diagramme suivant illustre la façon dont les services stockent et récupèrent des données d’objet Microsoft Entra via une couche d’autorisation de contrôle d’accès en fonction du rôle (RBAC). Cette couche appelle la couche d’accès aux données d’annuaire interne, ce qui garantit l’autorisation de la demande de données de l’utilisateur :
Accès aux interfaces internes Microsoft Entra : les communications de service à service avec d’autres services Microsoft, tels que Microsoft 365, utilisent des interfaces Microsoft Entra ID qui autorisent les appelants du service à utiliser des certificats clients.
Accès aux interfaces externes Microsoft Entra : l’interface externe Microsoft Entra permet d’éviter les fuites de données en utilisant RBAC. Lorsqu’un principal de sécurité, tel qu’un utilisateur, effectue une demande d’accès pour lire des informations via des interfaces Microsoft Entra ID, un jeton de sécurité doit accompagner la requête. Le jeton contient des revendications sur le principal qui effectue la requête.
Les jetons de sécurité sont émis par les services d’authentification Microsoft Entra. Les informations sur l’existence de l’utilisateur, l’état activé et le rôle sont utilisées par le système d’autorisation pour décider si l’accès demandé au locataire cible est autorisé pour cet utilisateur dans cette session.
Accès aux applications : étant donné que les applications peuvent accéder aux Interfaces de programmation d’applications (API) sans contexte utilisateur, la vérification d’accès inclut des informations sur l’application de l’utilisateur et l’étendue de l’accès demandé, par exemple en lecture seule, en lecture/écriture, et ainsi de suite. De nombreuses applications utilisent OpenID Connect ou Open Authorization (OAuth) pour obtenir des jetons pour accéder au répertoire pour le compte de l’utilisateur. Ces applications doivent être explicitement autorisées à accéder à l’annuaire. Elles ne recevront pas de jeton du service d’authentification Microsoft Entra et accèdent aux données à partir de l’étendue accordée.
Audit : l’accès est audité. Par exemple, des actions autorisées (en particulier, créer un utilisateur et réinitialiser un mot de passe) créent une piste d’audit utilisable par un administrateur client pour gérer les efforts ou enquêtes de conformité. Les administrateurs de tenant peuvent générer des rapports d’audit à l’aide de l’API d’audit Microsoft Entra.
En savoir plus : Journaux d’audit dans Microsoft Entra ID
Isolation des tenants : l’application de la sécurité dans un environnement multitenant Microsoft Entra permet d’atteindre deux objectifs principaux :
- Empêcher les fuites de données et l’accès entre les locataires : les données appartenant au locataire 1 ne peuvent pas être obtenues par les utilisateurs du locataire 2 sans autorisation explicite du locataire 1.
- Isolation de l’accès aux ressources entre les locataires : les opérations effectuées par le locataire 1 ne peuvent pas affecter l’accès aux ressources pour le locataire 2.
Isolation des locataires
Les informations suivantes décrivent l’isolation du locataire.
- Le service sécurise les locataires à l’aide de la stratégie RBAC pour garantir l’isolation des données.
- Pour activer l’accès à un locataire, un principal, par exemple un utilisateur ou une application, doit être en mesure de s’authentifier auprès de Microsoft Entra ID afin d’obtenir le contexte et dispose des autorisations explicites définies dans le locataire. Si un principal n’est pas autorisé dans le locataire, le jeton résultant n’aura pas d’autorisations et le système RBAC rejette les requêtes dans ce contexte.
- RBAC garantit que l’accès à un locataire est effectué par un principal de sécurité autorisé dans le locataire. L’accès entre les locataires est possible lorsqu’un administrateur de locataires crée une représentation de principal de sécurité dans le même locataire (par exemple, en approvisionnant un compte d’utilisateur invité à l’aide de la collaboration B2B), ou lorsqu’un administrateur de locataires crée une stratégie pour activer une relation d’approbation avec un autre locataire. Par exemple, une stratégie d’accès inter-locataires pour activer B2B Direct Connect. Chaque locataire est une limite d’isolation ; l’existence dans un locataire n’équivaut pas à l’existence dans un autre locataire, sauf si l’administrateur l’autorise.
- Les données Microsoft Entra pour plusieurs locataires sont stockées dans le même serveur physique et le même lecteur pour une partition donnée. L’isolation est assurée, car l’accès aux données est protégé par le système d’autorisation RBAC.
- Une application cliente ne peut pas accéder à Microsoft Entra ID sans l’authentification nécessaire. La demande est rejetée si elle n’est pas accompagnée d’informations d’identification dans le cadre du processus de négociation de la connexion initiale. Cette dynamique empêche l’accès non autorisé à un locataire par des locataires voisins. Seul le jeton des informations d’identification de l’utilisateur, ou le jeton SAML (Security Assertion Markup Language), est réparti avec une approbation fédérée. Par conséquent, il est validé par Microsoft Entra ID, en fonction des clés partagées configurées par le propriétaire d’application.
- Étant donné qu’aucun composant d’application ne peut s’exécuter à partir du Core Store, il n’est pas possible pour un locataire de violer de force l’intégrité d’un locataire voisin.
Sécurité des données
Chiffrement en transit : pour garantir la sécurité des données, les données de répertoire dans Microsoft Entra ID sont signées et chiffrées pendant leur transit entre les centres de données dans une unité d’échelle. Les données sont chiffrées et déchiffrées par le niveau de service Core Store de Microsoft Entra, qui réside dans les zones d’hébergement de serveur sécurisées des centres de données Microsoft associés.
Les services web destinés aux clients sont sécurisés avec le protocole TLS (Transport Layer Security).
Stockage secret : le backend du service Microsoft Entra utilise le chiffrement pour stocker des éléments sensibles pour l’utilisation du service, tels que des certificats, des clés, des informations d’identification et des hachages à l’aide de la technologie propriétaire de Microsoft. Le magasin utilisé dépend du service, de l’opération, de l’étendue du secret (à l’échelle de l’utilisateur ou du locataire) et d’autres exigences.
Ces magasins sont gérés par un groupe axé sur la sécurité via une automatisation et des workflows établis, notamment la demande de certificat, le renouvellement, la révocation et la destruction.
Il existe un audit d’activité lié à ces magasins/workflows/processus, et il n’existe pas d’accès permanent. L’accès est basé sur la demande et l’approbation, et pour une durée limitée.
Pour en savoir plus sur le chiffrement du secret au repos, consultez le tableau suivant.
Algorithmes : le tableau suivant répertorie les algorithmes de chiffrement minimum utilisés par les composants Microsoft Entra. En tant que service cloud, Microsoft réévalue et améliore le chiffrement, en fonction des résultats des recherches sur la sécurité, des révisions de sécurité internes, de la force des clés par rapport à l’évolution du matériel, etc.
| Données/scénario | Algorithme de chiffrement |
|---|---|
| Synchronisation de hachage de mot de passe Mots de passe de compte cloud |
Hachage : fonction de dérivation de clé de mot de passe 2 (PBKDF2), à l’aide du code d’authentification de message basé sur le hachage (HMAC)-SHA256 @ 1 000 itérations |
| Répertoire en transit entre les centres de données | AES-256-CTS-HMAC-SHA1-96 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
| Flux d’informations d’identification utilisateur de l’authentification directe | Paire de clés publique/privée RSA 2048 En savoir plus : Présentation approfondie de la sécurité de l’authentification directe Microsoft Entra |
| Réécriture du mot de passe de réinitialisation de mot de passe en libre-service avec Microsoft Entra Connect : communication cloud vers le local | Paire de clés privée/publique RSA 2048 AES_GCM (clé de 256 bits, taille IV 96 bits) |
| Réinitialisation de mot de passe en libre-service : réponses aux questions de sécurité | SHA256 |
| Certificats SSL pour l’application Microsoft Entra Applications publiées par le proxy |
AES-GCM 256-bit |
| Chiffrement au niveau du disque | XTS-AES 128 |
| Authentification unique transparente (SSO) mot de passe du compte de service Informations d’identification de provisionnement d’applications SaaS (Software as a Service) |
AES-CBC 128 bits |
| Identités gérées pour les ressources Azure | AES-GCM 256-bit |
| Application Microsoft Authenticator : connexion sans mot de passe à Microsoft Entra ID | Clé RSA asymétrique 2048 bits |
| Application Microsoft Authenticator : sauvegarde et restauration des métadonnées de compte d’entreprise | AES-256 |
Ressources
- Documents d’approbation de service Microsoft
- Centre de confidentialité Microsoft Azure
- Récupération après des suppressions dans Microsoft Entra ID