Isolation et contrôle d’accès dans Microsoft 365

L’ID et l’Microsoft 365 De Microsoft Utilisent un modèle de données très complexe qui inclut des dizaines de services, des centaines d’entités, des milliers de relations et des dizaines de milliers d’attributs. À un niveau élevé, Microsoft Entra ID et les répertoires de service sont les conteneurs de locataires et de destinataires qui sont synchronisés à l’aide de protocoles de réplication basés sur l’état. En plus des informations d’annuaire contenues dans Microsoft Entra ID, chacune des charges de travail de service a sa propre infrastructure de services d’annuaire.

Synchronisation des données client Microsoft 365.

Dans ce modèle, il n’existe aucune source unique de données d’annuaire. Des systèmes spécifiques possèdent des éléments de données individuels, mais aucun système ne contient toutes les données. Microsoft 365 services collaborent avec l’ID Microsoft Archivé dans ce modèle de données. L’ID De Microsoft Est le « système de vérité » pour les données partagées, qui est généralement des données petites et statiques utilisées par chaque service. Le modèle fédéré utilisé dans Microsoft 365 et Microsoft Entra ID fournit la vue partagée des données.

Microsoft 365 utilise à la fois le stockage physique et le stockage cloud Azure. Exchange Online (y compris les Exchange Online Protection) et les Skype Entreprise utilisent leur propre stockage pour les données client. SharePoint utilise à la fois le stockage SQL Server et le stockage Azure, d’où la nécessité d’une isolation supplémentaire des données client au niveau du stockage.

Exchange Online

Exchange Online stocke les données client dans les boîtes aux lettres. Les boîtes aux lettres sont hébergées dans des bases de données ESE (Extensible Storage Engine) appelées bases de données de boîte aux lettres. Cela inclut les boîtes aux lettres utilisateur, les boîtes aux lettres liées, les boîtes aux lettres partagées et les boîtes aux lettres de dossiers publics. Les boîtes aux lettres utilisateur incluent du contenu Skype Entreprise enregistré, tel que des historiques de conversation.

Le contenu de la boîte aux lettres utilisateur comprend :

  • E-mails et pièces jointes
  • Informations de calendrier et de disponibilité
  • Contacts
  • Tâches
  • Notes
  • Groupes
  • Données d’inférence

Chaque base de données de boîtes aux lettres dans Exchange Online contient des boîtes aux lettres de plusieurs locataires. Un code d’autorisation sécurise chaque boîte aux lettres, y compris au sein d’une location. Par défaut, seul l’utilisateur affecté a accès à une boîte aux lettres. La liste de contrôle d’accès (ACL) qui sécurise une boîte aux lettres contient une identité authentifiée par Microsoft Entra ID au niveau du locataire. Les boîtes aux lettres de chaque locataire sont limitées aux identités authentifiées auprès du fournisseur d’authentification du locataire, qui inclut uniquement les utilisateurs de ce locataire. Le contenu du locataire A ne peut en aucun cas être obtenu par les utilisateurs du locataire B, sauf s’il est explicitement approuvé par le locataire A.

Skype Entreprise

Skype Entreprise stocke les données à différents endroits :

  • Les informations sur l’utilisateur et le compte, notamment les points de terminaison de connexion, les ID de locataire, les plans de numérotation, les paramètres d’itinérance, l’état de présence, les listes de contacts, etc., sont stockées dans le Skype Entreprise serveurs Active Directory et dans différents serveurs de base de données Skype Entreprise. Les listes de contacts sont stockées dans la boîte aux lettres Exchange Online de l’utilisateur si l’utilisateur est activé pour les deux produits, ou sur Skype Entreprise serveurs si ce n’est pas le cas. Skype Entreprise serveurs de base de données n’est pas partitionné par locataire, mais l’isolation mutualisée des données est appliquée via le contrôle d’accès en fonction du rôle (RBAC).
  • Le contenu de la réunion et les données chargées sont stockés sur des partages de système de fichiers distribués (DFS). Ce contenu peut également être archivé dans Exchange Online s’il est activé. Les partages DFS ne sont pas partitionnés par locataire. le contenu est sécurisé avec des listes de contrôle d’accès et l’architecture mutualisée est appliquée via RBAC.
  • Les enregistrements de détails des appels, qui sont l’historique des activités, tels que l’historique des appels, les sessions de messagerie instantanée, le partage d’applications, l’historique de messagerie instantanée, etc., peuvent également être stockés dans Exchange Online, mais la plupart des enregistrements de détails des appels sont temporairement stockés sur des serveurs d’enregistrement des détails des appels (CDR). Le contenu n’est pas partitionné par locataire, mais la mutualisation est appliquée via RBAC.

SharePoint

SharePoint a plusieurs mécanismes indépendants qui assurent l’isolation des données. Il stocke les objets sous forme de code abstrait dans les bases de données d’application. Par exemple, lorsqu’un utilisateur charge un fichier dans SharePoint, le fichier est désassemblé, traduit en code d’application et stocké dans plusieurs tables sur plusieurs bases de données.

Si un utilisateur peut obtenir un accès direct au stockage contenant les données, le contenu n’est pas interprétable à un utilisateur ou à tout autre système que SharePoint. Ces mécanismes incluent le contrôle d’accès de sécurité et les propriétés. Toutes les ressources SharePoint sont sécurisées par le code d’autorisation et la stratégie RBAC, y compris dans une location. La liste de contrôle d’accès (ACL) qui sécurise une ressource contient une identité authentifiée au niveau du locataire. Les données SharePoint d’un locataire sont limitées aux identités authentifiées par le fournisseur d’authentification pour le locataire.

En plus des listes de contrôle d’accès, une propriété au niveau du locataire qui spécifie le fournisseur d’authentification (qui est le Microsoft Entra ID propre au locataire) est écrite une seule fois et ne peut pas être modifiée une fois définie. Une fois que la propriété de locataire du fournisseur d’authentification a été définie pour un locataire, elle ne peut pas être modifiée à l’aide d’API exposées à un locataire.

Un Id d’abonnement unique est utilisé pour chaque locataire. Tous les sites clients appartiennent à un locataire et lui attribuent un Id d’abonnement unique. La propriété SubscriptionId sur un site est écrite une seule fois et est permanente. Une fois affecté à un locataire, un site ne peut pas être déplacé vers un autre locataire. SubscriptionId est la clé utilisée pour créer l’étendue de sécurité pour le fournisseur d’authentification et est liée au locataire.

SharePoint utilise SQL Server et Stockage Azure pour le stockage des métadonnées de contenu. La clé de partition du magasin de contenu est SiteId dans SQL. Lors de l’exécution d’une requête SQL, SharePoint utilise un SiteId vérifié dans le cadre d’une case activée SubscriptionId au niveau du locataire.

SharePoint stocke le contenu des fichiers chiffrés dans des objets blob Microsoft Azure. Chaque batterie de serveurs SharePoint a son propre compte Microsoft Azure et tous les objets blob enregistrés dans Azure sont chiffrés individuellement avec une clé stockée dans le magasin de contenu SQL. Clé de chiffrement protégée dans le code par la couche d’autorisation et non exposée directement à l’utilisateur final. SharePoint dispose d’une surveillance en temps réel pour détecter quand une requête HTTP lit ou écrit des données pour plusieurs locataires. L’id d’identité de demande SubscriptionId est suivi par rapport à l’Id d’abonnement de la ressource sollicitée. Les demandes d’accès aux ressources de plusieurs locataires ne doivent jamais se produire par les utilisateurs finaux. Les demandes de service dans un environnement multilocataire sont la seule exception. Par exemple, le robot de recherche extrait simultanément les modifications de contenu pour une base de données entière. Cela implique généralement l’interrogation des sites de plusieurs locataires dans une seule demande de service, ce qui est effectué pour des raisons d’efficacité.

Teams

Vos données Teams sont stockées différemment, selon le type de contenu.

Consultez la session de groupe Ignite sur l’architecture Microsoft Teams pour une discussion approfondie.

Données client De Core Teams

Si votre locataire est approvisionné en Australie, au Canada, dans l’Union européenne, en France, en Allemagne, en Inde, au Japon, en Afrique du Sud, en Corée du Sud, en Suisse (ce qui inclut le Liechtenstein), aux Émirats arabes unis, au Royaume-Uni ou au États-Unis, Microsoft stocke les données client suivantes au repos uniquement à cet emplacement :

  • Conversations Teams, conversations d’équipe et de canal, images, messages vocaux et contacts.
  • Contenu du site SharePoint et fichiers stockés dans ce site.
  • Fichiers chargés sur OneDrive pour le travail ou l’école.

Conversation, messages de canal, structure d’équipe

Chaque équipe dans Teams est soutenue par un groupe Microsoft 365, son site SharePoint et sa boîte aux lettres Exchange. Les conversations privées (y compris les conversations de groupe), les messages envoyés dans le cadre d’une conversation dans un canal et la structure des équipes et des canaux sont stockés dans un service de conversation exécuté dans Azure. Les données sont également stockées dans un dossier masqué dans les boîtes aux lettres d’utilisateur et de groupe pour activer Information Protection fonctionnalités.

Messagerie vocale et contacts

Les messages vocaux sont stockés dans Exchange. Les contacts sont stockés dans le magasin de données cloud Exchange. Exchange et le magasin cloud Exchange fournissent déjà la résidence des données dans chacune des zones géographiques du centre de données mondial. Pour toutes les équipes, la messagerie vocale et les contacts sont stockés dans le pays pour l’Australie, le Canada, la France, l’Allemagne, l’Inde, le Japon, les Émirats arabes unis, le Royaume-Uni, l’Afrique du Sud, la Corée du Sud, la Suisse (qui inclut le Liechtenstein) et le États-Unis. Pour tous les autres pays/régions, les fichiers sont stockés aux États-Unis, en Europe ou Asia-Pacific emplacement en fonction de l’affinité client.

Images et médias

Les médias utilisés dans les conversations (à l’exception des gif Giphy qui ne sont pas stockés, mais qui sont un lien de référence vers l’URL du service Giphy d’origine, Giphy est un service non-Microsoft) sont stockés dans un service multimédia Basé sur Azure qui est déployé aux mêmes emplacements que le service de conversation.

Fichiers

Les fichiers (y compris OneNote et Wiki) que quelqu’un partage dans un canal sont stockés dans le site SharePoint de l’équipe. Les fichiers partagés dans une conversation privée ou une conversation pendant une réunion ou un appel sont chargés et stockés dans le compte OneDrive professionnel ou scolaire de l’utilisateur qui partage le fichier. Exchange, SharePoint et OneDrive fournissent déjà la résidence des données dans chacune des zones géographiques des centres de données mondiaux. Ainsi, pour les clients existants, tous les fichiers, blocs-notes OneNote, contenu wiki Teams et boîtes aux lettres qui font partie de l’expérience Teams sont déjà stockés à l’emplacement en fonction de votre affinité client. Les fichiers sont stockés dans le pays pour l’Australie, le Canada, la France, l’Allemagne, l’Inde, le Japon, les Émirats arabes unis, le Royaume-Uni, l’Afrique du Sud, la Corée du Sud et la Suisse (y compris le Liechtenstein). Pour tous les autres pays/régions, les fichiers sont stockés aux États-Unis, en Europe ou en Asie-Pacifique en fonction de l’affinité client.