Compartir a través de


Aislamiento y control de acceso en Microsoft 365

Microsoft Entra ID y Microsoft 365 usan un modelo de datos muy complejo que incluye decenas de servicios, cientos de entidades, miles de relaciones y decenas de miles de atributos. En un nivel alto, Microsoft Entra ID y los directorios de servicio son los contenedores de inquilinos y destinatarios que se mantienen sincronizados mediante protocolos de replicación basados en estado. Además de la información de directorio contenida en Microsoft Entra ID, cada una de las cargas de trabajo de servicio tiene su propia infraestructura de servicios de directorio.

Sincronización de datos de inquilinos de Microsoft 365.

En este modelo, no hay ningún origen único de datos de directorio. Los sistemas específicos poseen fragmentos de datos individuales, pero ningún sistema contiene todos los datos. Los servicios de Microsoft 365 colaboran con Microsoft Entra ID en este modelo de datos. Microsoft Entra ID es el "sistema de verdad" para los datos compartidos, que suelen ser datos pequeños y estáticos usados por cada servicio. El modelo federado que se usa en Microsoft 365 y Microsoft Entra ID proporciona la vista compartida de los datos.

Microsoft 365 usa almacenamiento físico y almacenamiento en la nube de Azure. Exchange Online (incluida La protección de Exchange Online) usa su propio almacenamiento para los datos de los clientes. SharePoint usa el almacenamiento de SQL Server y Azure Storage, por lo tanto, la necesidad de aislamiento adicional de los datos del cliente en el nivel de almacenamiento.

Exchange Online

Exchange Online almacena los datos de los clientes en buzones de correo. Los buzones se hospedan en bases de datos del Motor de almacenamiento extensible (ESE) denominadas bases de datos de buzón. Esto incluye buzones de usuario, buzones vinculados, buzones compartidos y buzones de carpetas públicas.

El contenido del buzón de usuario incluye:

  • Correos electrónicos y datos adjuntos de correo electrónico
  • Calendario e información de disponibilidad
  • Contactos
  • Tareas
  • Notas
  • Grupos
  • Datos de inferencia

Cada base de datos de buzones de Exchange Online contiene buzones de varios inquilinos. Un código de autorización protege cada buzón de correo, incluido dentro de un inquilino. De forma predeterminada, solo el usuario asignado tiene acceso a un buzón. La lista de control de acceso (ACL) que protege un buzón contiene una identidad autenticada por el identificador de Microsoft Entra en el nivel de inquilino. Los buzones de cada inquilino se limitan a las identidades autenticadas en el proveedor de autenticación del inquilino, que incluye solo a los usuarios de ese inquilino. Los usuarios del inquilino B no pueden acceder al contenido del inquilino A, a menos que el inquilino A lo apruebe explícitamente.

SharePoint

SharePoint tiene varios mecanismos independientes que proporcionan aislamiento de datos. Almacena objetos como código abstracto dentro de las bases de datos de la aplicación. Por ejemplo, cuando un usuario carga un archivo en SharePoint, el archivo se desensambla, se traduce en código de aplicación y se almacena en varias tablas entre varias bases de datos.

Si un usuario puede obtener acceso directo al almacenamiento que contiene los datos, el contenido no se puede interpretar para un usuario ni para ningún sistema distinto de SharePoint. Estos mecanismos incluyen el control de acceso de seguridad y las propiedades. Todos los recursos de SharePoint están protegidos por el código de autorización y la directiva de control de acceso basado en rol (RBAC), incluidos los de un inquilino. La lista de control de acceso (ACL) que protege un recurso contiene una identidad autenticada en el nivel de inquilino. Los datos de SharePoint para un inquilino se limitan a las identidades autenticadas por el proveedor de autenticación para el inquilino.

Además de las ACL, una propiedad de nivel de inquilino que especifica el proveedor de autenticación (que es el identificador de Microsoft Entra específico del inquilino), se escribe una vez y no se puede cambiar una vez establecida. Una vez establecida la propiedad de inquilino del proveedor de autenticación para un inquilino, no se puede cambiar mediante ninguna API expuesta a un inquilino.

Se usa un SubscriptionId único para cada inquilino. Todos los sitios de cliente pertenecen a un inquilino y se les asigna un SubscriptionId único para el inquilino. La propiedad SubscriptionId de un sitio se escribe una vez y es permanente. Una vez asignado a un inquilino, un sitio no se puede mover a otro inquilino. SubscriptionId es la clave que se usa para crear el ámbito de seguridad para el proveedor de autenticación y está asociada al inquilino.

SharePoint usa SQL Server y Azure Storage para el almacenamiento de metadatos de contenido. La clave de partición para el almacén de contenido es SiteId en SQL. Al ejecutar una consulta SQL, SharePoint usa un SiteId comprobado como parte de una comprobación subscriptionId de nivel de inquilino.

SharePoint almacena contenido de archivos cifrados en blobs de Microsoft Azure. Cada granja de servidores de SharePoint tiene su propia cuenta de Microsoft Azure y todos los blobs guardados en Azure se cifran individualmente con una clave almacenada en el almacén de contenido de SQL. Clave de cifrado protegida en el código por la capa de autorización y no expuesta directamente al usuario final. SharePoint tiene supervisión en tiempo real para detectar cuándo una solicitud HTTP lee o escribe datos para más de un inquilino. Se realiza un seguimiento de la identidad de solicitud SubscriptionId con el SubscriptionId del recurso al que se accede. Las solicitudes de acceso a recursos de más de un inquilino nunca deben producirse por parte de los usuarios finales. Las solicitudes de servicio en un entorno multiinquilino son la única excepción. Por ejemplo, el rastreador de búsqueda extrae los cambios de contenido de una base de datos completa a la vez, lo que normalmente implica consultar sitios de más de un inquilino en una única solicitud de servicio por motivos de eficacia.

Teams

Los datos de Teams se almacenan de forma diferente, en función del tipo de contenido.

Consulte la sesión de interrupción de Ignite en la arquitectura de Microsoft Teams para obtener una explicación detallada.

Datos principales de los clientes de Teams

Si su inquilino está aprovisionado en Australia, Canadá, la Unión Europea, Francia, Alemania, India, Japón, Sudáfrica, Corea del Sur, Suiza (que incluye Liechtenstein), Emiratos Árabes Unidos, Reino Unido o Estados Unidos, Microsoft almacena los siguientes datos de cliente en reposo solo dentro de esa ubicación:

  • Chats de Teams, conversaciones de equipo y canal, imágenes, mensajes de correo de voz y contactos.
  • Contenido del sitio de SharePoint y los archivos almacenados en ese sitio.
  • Archivos cargados en OneDrive para el trabajo o la escuela.

Chat, mensajes de canal, estructura de equipo

Cada equipo de Teams está respaldado por un grupo de Microsoft 365 y su sitio de SharePoint y su buzón de Exchange. Los chats privados (incluidos los chats de grupo), los mensajes enviados como parte de una conversación en un canal y la estructura de los equipos y canales se almacenan en un servicio de chat que se ejecuta en Azure. Los datos también se almacenan en una carpeta oculta en los buzones de usuario y grupo para habilitar las características de Information Protection.

Correo de voz y contactos

Los mensajes de voz se almacenan en Exchange. Los contactos se almacenan en el almacén de datos en la nube basado en Exchange. Exchange y el almacén en la nube basado en Exchange ya proporcionan residencia de datos en cada una de las zonas geográficas del centro de datos de todo el mundo. Para todos los equipos, el correo de voz y los contactos se almacenan en el país para Australia, Canadá, Francia, Alemania, India, Japón, Emiratos Árabes Unidos, Reino Unido, Sudáfrica, Corea del Sur, Suiza (que incluye Liechtenstein) y Estados Unidos. Para todos los demás países, los archivos se almacenan en ee. UU., Europa o Asia-Pacific ubicación en función de la afinidad de inquilino.

Imágenes y medios

Los medios que se usan en los chats (excepto los GIF giphy, que no se almacenan pero son un vínculo de referencia a la dirección URL del servicio Giphy original, Giphy es un servicio que no es de Microsoft) se almacenan en un servicio multimedia basado en Azure que se implementa en las mismas ubicaciones que el servicio de chat.

Archivos

Los archivos (incluidos OneNote y Wiki) que alguien comparte en un canal se almacenan en el sitio de SharePoint del equipo. Los archivos compartidos en un chat privado o un chat durante una reunión o llamada se cargan y almacenan en la cuenta profesional o educativa de OneDrive del usuario que comparte el archivo. Exchange, SharePoint y OneDrive ya proporcionan residencia de datos en cada una de las zonas geográficas del centro de datos en todo el mundo. Por lo tanto, para los clientes existentes, todos los archivos, cuadernos de OneNote, contenido wiki de Teams y buzones que forman parte de la experiencia de Teams ya se almacenan en la ubicación en función de la afinidad de inquilino. Los archivos se almacenan en el país para Australia, Canadá, Francia, Alemania, India, Japón, Emiratos Árabes Unidos, Reino Unido, Sudáfrica, Corea del Sur y Suiza (que incluye Liechtenstein). Para todos los demás países, los archivos se almacenan en la ubicación de EE. UU., Europa o Asia Pacífico en función de la afinidad de inquilino.