通过

Microsoft 365 中的隔离和访问控制

  • 项目

Microsoft Entra ID 和 Microsoft 365 使用高度复杂的数据模型，其中包括数十个服务、数百个实体、数千个关系和数万个属性。 概括而言，Microsoft Entra ID和服务目录是使用基于状态的复制协议保持同步的租户和收件人的容器。 除了Microsoft Entra ID中保留的目录信息外，每个服务工作负载都有自己的目录服务基础结构。

Microsoft 365 租户数据同步。

在此模型中，没有单个目录数据源。 特定系统拥有单独的数据片段，但没有一个系统保存所有数据。 Microsoft 365 服务在此数据模型中与Microsoft Entra ID合作。 Microsoft Entra ID是共享数据的“事实系统”，共享数据通常是每个服务使用的小型静态数据。 Microsoft 365 和 Microsoft Entra ID 中使用的联合模型提供数据的共享视图。

Microsoft 365 同时使用物理存储和 Azure 云存储。 Exchange Online (包括Exchange Online Protection) 和Skype for Business使用自己的存储来存储客户数据。 SharePoint 使用 SQL Server 存储和 Azure 存储，因此需要在存储级别对客户数据进行额外隔离。

Exchange Online

Exchange Online将客户数据存储在邮箱中。 邮箱托管在可扩展存储引擎中， (称为邮箱数据库的 ESE) 数据库中。 这包括用户邮箱、链接邮箱、共享邮箱和公用文件夹邮箱。 用户邮箱包括已保存Skype for Business内容，例如对话历史记录。

用户邮箱内容包括：

  • 电子邮件和电子邮件附件
  • 日历和忙/闲信息
  • 联系人
  • Tasks
  • 注释
  • 组
  • 推理数据

Exchange Online中的每个邮箱数据库都包含来自多个租户的邮箱。 授权代码保护每个邮箱，包括在租户中。 默认情况下，只有分配的用户有权访问邮箱。 访问控制列表 (保护邮箱的 ACL) 包含由租户级别Microsoft Entra ID进行身份验证的标识。 每个租户的邮箱仅限于针对租户的身份验证提供程序进行身份验证的标识，该提供程序仅包括来自该租户的用户。 租户 A 中的内容不能以任何方式由租户 B 中的用户获取，除非租户 A 明确批准。

Skype for Business

Skype for Business将数据存储在不同位置：

  • 用户和帐户信息（包括连接终结点、租户 ID、拨号计划、漫游设置、状态、联系人列表等）存储在 Skype for Business Active Directory 服务器和各种Skype for Business数据库服务器中。 如果用户为这两种产品启用，联系人列表将存储在用户的Exchange Online邮箱中;如果用户未启用联系人列表，则存储在Skype for Business服务器上。 Skype for Business数据库服务器不是按租户分区的，但通过基于角色的访问控制 (RBAC) 强制实施数据的多租户隔离。
  • 会议内容和上传数据存储在分布式文件系统 (DFS) 共享中。 如果启用，还可以将此内容存档到 Exchange Online 中。 DFS 共享不是按租户分区的。 内容使用 ACL 进行保护，并通过 RBAC 强制实施多租户。
  • 呼叫详细信息记录（即活动历史记录，如呼叫历史记录、IM 会话、应用程序共享、IM 历史记录等）也可以存储在Exchange Online中，但大多数呼叫详细信息记录暂时存储在呼叫详细信息记录 (CDR) 服务器。 内容不按租户分区，但通过 RBAC 强制实施多租户。

SharePoint

SharePoint 具有多个提供数据隔离的独立机制。 它将对象存储为应用程序数据库中的抽象代码。 例如，当用户将文件上传到 SharePoint 时，该文件将被反汇编、转换为应用程序代码，并存储在跨多个数据库的多个表中。

如果用户可以直接访问包含数据的存储，则用户或 SharePoint 以外的任何系统都无法解释该内容。 这些机制包括安全访问控制和属性。 所有 SharePoint 资源都受授权代码和 RBAC 策略保护，包括在租户中。 访问控制列表 (保护资源的 ACL) 包含一个在租户级别进行身份验证的标识。 租户的 SharePoint 数据仅限于由租户的身份验证提供程序进行身份验证的标识。

除了 ACL，租户级属性还指定身份验证提供程序 (特定于租户的Microsoft Entra ID) ，将写入一次，设置后无法更改。 为租户设置身份验证提供程序租户属性后，无法使用向租户公开的任何 API 更改该属性。

每个租户使用唯一的 SubscriptionId 。 所有客户网站都归租户所有，并分配了租户唯一的 SubscriptionId 。 网站上的 SubscriptionId 属性写入一次，是永久的。 分配到租户后，站点无法移动到其他租户。 SubscriptionId 是用于为身份验证提供程序创建安全范围的密钥，并绑定到租户。

SharePoint 使用 SQL Server 和 Azure 存储来存储内容元数据。 内容存储的分区键是 SQL 中的 SiteId 。 运行 SQL 查询时，SharePoint 使用已验证的 SiteId 作为租户级 SubscriptionId 检查的一部分。

SharePoint 将加密的文件内容存储在 Microsoft Azure Blob 中。 每个 SharePoint 场都有自己的 Microsoft Azure 帐户，在 Azure 中保存的所有 Blob 都使用存储在 SQL 内容存储中的密钥单独加密。 在代码中受授权层保护的加密密钥，不直接向最终用户公开。 SharePoint 具有实时监视功能，用于检测 HTTP 请求何时读取或写入多个租户的数据。 根据所访问资源的 SubscriptionId 跟踪请求标识 SubscriptionId 。 最终用户不应请求访问多个租户的资源。 多租户环境中的服务请求是唯一的例外。 例如，搜索爬网程序会一次性拉取整个数据库的内容更改。 这通常涉及在单个服务请求中查询多个租户的站点，这样做是为了提高效率。

Teams

Teams 数据的存储方式不同，具体取决于内容类型。

查看 Microsoft Teams 体系结构上的 Ignite 分组讨论会议 ，进行深入讨论。

核心 Teams 客户数据

如果你的租户是在澳大利亚、加拿大、欧盟、法国、德国、印度、日本、南非、韩国、瑞士 (（包括列支敦士登) 、阿拉伯联合酋长国、英国或美国）预配的，则 Microsoft 仅在该位置静态存储以下客户数据：

  • Teams 聊天、团队和频道对话、图像、语音邮件和联系人。
  • SharePoint 网站内容以及存储在该网站中的文件。
  • 上传到 OneDrive 以供工作或学校使用的文件。

聊天、频道消息、团队结构

Teams 中的每个团队都由 Microsoft 365 组及其 SharePoint 网站和 Exchange 邮箱提供支持。 私人聊天 (包括群组聊天) 、在频道中作为对话的一部分发送的消息，以及团队和频道的结构存储在 Azure 中运行的聊天服务中。 数据还存储在用户和组邮箱的隐藏文件夹中，以启用信息保护功能。

语音邮件和联系人

语音邮件存储在 Exchange 中。 联系人存储在基于 Exchange 的云数据存储中。 Exchange 和基于 Exchange 的云存储已在每个全球数据中心地理位置中提供数据驻留。 对于所有团队，语音邮件和联系人存储在澳大利亚、加拿大、法国、德国、印度、日本、阿拉伯联合酋长国、英国、南非、韩国、瑞士 (，其中包括列支敦士登) 和美国。 对于所有其他国家/地区，文件会根据租户相关性存储在美国、欧洲或 Asia-Pacific 位置。

图像和媒体

聊天中使用的媒体 (，但不是存储但指向原始 Giphy 服务 URL 的引用链接的 Giphy GIF 除外，Giphy 是非 Microsoft 服务，) 存储在与聊天服务部署到相同位置的基于 Azure 的媒体服务中。

文件

某人在频道中共享的 OneNote 和 Wiki) 等 (文件存储在团队的 SharePoint 网站中。 在会议或通话期间在私人聊天或聊天中共享的文件将上传并存储在共享该文件的用户的 OneDrive 工作或学校帐户中。 Exchange、SharePoint 和 OneDrive 已在全球每个数据中心地理位置中提供数据驻留。 因此，对于现有客户，作为 Teams 体验一部分的所有文件、OneNote 笔记本、Teams Wiki 内容和邮箱都已根据租户相关性存储在位置中。 文件存储在澳大利亚、加拿大、法国、德国、印度、日本、阿拉伯联合酋长国、英国、南非、韩国和瑞士 (，其中包括列支敦斯登) 。 对于所有其他国家/地区，文件基于租户相关性存储在美国、欧洲或亚太地区的位置。