Microsoft 365 认证框架概述
本文提供了详细信息，包括Microsoft 365 认证安全控制列表，以及对接受 Microsoft 365 认证的 ISV 和开发人员的支持。
Microsoft 365 认证是针对应用、加载项和支持后端环境的独立安全和隐私审核， (统称为与 Microsoft 365 平台集成) 应用。 通过的应用将在整个 Microsoft 365 生态系统中被指定为Microsoft 365 认证，并且可以通过以合规性为中心的搜索筛选器和品牌打造，在 Microsoft 365 个市场中轻松找到这些应用。 ISV 将有机会在此文档集中的专用页面上共享其应用合规性属性。
Microsoft 365 认证适用于以下类型的应用程序：
- Microsoft 365 个加载项 (Word、Excel、Outlook、PowerPoint、OneNote、Project)
- Teams 应用
- SharePoint 解决方案
- Web 应用 (SaaS)
重要
Microsoft 365 认证是针对Microsoft 365 认证框架对应用安全性和合规性的严格审查，需要大量的时间和资源承诺才能完成。 在开始认证之前，请查看 合规性控制框架 ，了解你的应用是否符合条件。 如有任何问题，请发送电子邮件至 appcert@microsoft.com。
Terms
参与 Microsoft 365 认证计划即表示你同意这些补充条款，并遵守与 Microsoft Corporation (“Microsoft”、“我们”、“我们”或“我们的”) 参与Microsoft 365 认证计划相关的任何随附文档。 您向我们声明并保证，您有权代表您自己、公司和/或其他实体接受这些Microsoft 365 认证补充条款（如果适用）。 我们可能随时更改、修改或终止这些补充条款。 任何更改或修订后，你继续参与 Microsoft 365 认证计划意味着你同意新的补充条款。 如果您不同意新的补充条款或我们终止这些补充条款，则必须停止参与 Microsoft 365 认证计划。
先决条件
在授予 Microsoft 365 认证之前，应用必须完成以下各项：
发布者验证 当应用具有经验证的发布者时，发布该应用的组织已通过Microsoft进行验证。 验证应用包括使用Microsoft云合作伙伴计划 (已验证的 CPP) 帐户，并将已验证的 PartnerID 与应用注册相关联。 获取发布者验证
发布者证明 是一个自助服务过程，ISV 在其中回答一组有关其应用安全和数据处理做法的问题。 应用可以在 Microsoft合作伙伴中心 进行发布者证明，并在完成后在 Microsoft AppSource 市场中接收坏处和专用筛选器。
查看 控制条件 无需遵守所有控制措施即可获得认证。 但是，对于本概述文档中讨论的三个安全域中的每一个，) 不会披露的阈值 (，必须通过。 某些控制将归类为“硬故障”，这意味着缺少这些安全控制将导致评估失败。
重要
提交时间范围：评估过程平均需要 30 天，前提是 ISV 能够经常检查提交状态，并及时响应评论和补充证据请求。 开始认证过程后，最多允许 60 天完成评估。 如果所有提交均未在 60 天时间段内完成，提交将发出失败，并且必须重新开始该过程。 这些结果不会公开。
认证范围
范围内环境支持应用/外接程序代码的交付，并支持应用/外接程序可能与之通信的任何后端系统。 连接到作用域内环境的任何其他环境也将包含在范围内，除非已建立足够的分段，并且连接到的环境不会影响作用域内环境的安全性。
任何单独的灾难恢复环境也需要包含在范围内环境中，因为如果主要环境发生任何事件，则需要这些环境来实现服务。 还需要包含远程备份环境，因为这些环境可能会存储Microsoft数据，因此需要实施足够的安全控制。
术语 “作用域内系统组件 ”引用在定义的范围内环境中使用 的所有 设备和系统。 范围内组件包括但不限于：
- Web 应用程序 ()
- (物理或虚拟的服务器，可以在本地或云中)
- 网络安全控制 (NSC) ，例如防火墙
- 交换机
- 负载均衡器
- 虚拟基础结构
- 云提供商 Web 管理门户
- 云资源 (虚拟机、App 服务、存储帐户、EC2 实例等。)
重要
面向公众的系统组件容易受到外部威胁参与者的攻击，因此风险要大得多。 通常，使用网络安全控制 (NSC) (DMZ) 创建非军事化区域，将这些系统与其他内部系统组件分段开来。 意图是，外围网络不如内部网络信任，额外的安全性将有助于进一步保护内部系统和数据，如果面向公众的系统受到威胁。 理想情况下，将使用外围网络，但在某些部署方案中，这不可行，甚至不必要。
基础结构即服务 (IaaS) 、平台即服务 (PaaS) 和软件即服务 (SaaS)
如果 IaaS 和/或 PaaS 用于支持所审查的范围内环境，则云平台提供商将负责整个认证过程中评估的一些安全控制措施。 云平台提供商需要通过外部合规性报告（如 PCI DSS、AOC) 、ISO 27001 或 SOC 2 类型 II 报告） (向分析师提供安全最佳做法的独立外部验证。
附录 C 详细介绍了根据以下部署类型和应用是否外泄Microsoft 365 数据可能适用的安全控制措施：
- ISV 托管
- IaaS 托管
- PaaS/无服务器托管
- 混合托管
- 共享托管
部署 IaaS 或 PaaS 时，必须提供证明环境与这些部署类型的一致性的证据。
采样
支持认证评估的证据请求应基于范围内系统组件的示例，以考虑不同的操作系统、设备的主要功能、不同的设备类型 (即服务器、NSC、路由器等 ) 和位置。 将在认证过程开始时选择适当的示例。 下表应用作指南，其中将根据上面详述的因素确定采样：
| 总体大小 | 示例 |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
注意
如果初始样本中包含的设备之间存在差异，则评估期间可能会增加样本大小。
端到端认证过程
若要开始Microsoft 365 认证，
在合作伙伴中心内，选择“开始认证”以开始提交初始文档。 这将有助于认证分析师根据应用的体系结构及其处理Microsoft数据的方式确定评估范围内的内容。
提示
按照 操作指南 获取分步指导，使应用Microsoft 365 认证。
认证过程分两个阶段进行，如下所述：
初始文档提交 可帮助分析师了解应用、数据流、定义 范围内环境、确定适用的安全控制措施并确定需要从中收集证据的系统组件。 ISV 必须提供请求的信息，以帮助认证分析师完成此过程的这一阶段，这大约是整个过程的 5%。
完整证据审查 是 ISV 提交证据项目以演示 范围内环境 如何满足安全控制要求的过程。 在此审核阶段，ISV 与分析师之间将进行多次交互，这是过程的其余部分。
评估
接受初始文档提交后，安全控件集将自动显示在门户中。 ISV 必须为每个控制措施提供证据，证明控制措施已到位，并且有 60 天的时间 提交所有证据。 分析师将审查证据，并批准控制或请求新的或额外的证据。
认证
分析师验证提交后，ISV 会收到认证决定的通知。 获得认证的应用将在 AppSource 中的应用程序上收到一个徽章，以及专用 Microsoft文档 页面，其中包含其安全性和合规性属性的详细报告。
查看和重新认证
Microsoft 365 个认证应用需要每年进行重新认证。 这需要针对当前范围内环境重新验证作用域内控件。 此过程最多可以在认证到期前 90 天开始。 现有认证在重新认证期间不会过期。 所有计划的重新认证将在 Microsoft 365 认证一周年之际到期。
如果在到期日期之前未续订认证，则会撤销应用认证状态。 所有标记、图标和关联的认证品牌都将从你的应用中删除，并且将禁止 ISV 将你的应用宣传为 Microsoft 365 认证。
如果应用程序在重新认证提交时限之外进行了 重大更改 ，则要求 ISV 向Microsoft应用合规性计划通知任何更新。
初始文档提交
初始提交必须包含以下信息：
| 文档概述 | 文档详细信息 |
|---|---|
| 应用/加载项说明 | 应用/外接程序的用途和功能的说明。 这应该让认证分析师很好地了解应用/外接程序的功能及其用途 |
| 渗透测试报告 | 在过去 12 个月内完成的渗透测试报告。 此报表必须包含支持应用/添加部署的环境，以及支持应用/外接程序操作的任何其他环境。 注意： 如果 ISV 当前不执行年度渗透测试，Microsoft将支付通过认证过程进行笔测试的费用。 |
| 体系结构关系图 | 表示应用支持基础结构的高级概述的逻辑体系结构关系图。 这必须包括 支持应用的所有 托管环境和支持基础结构。 此图必须描述环境中所有不同的支持系统组件，以帮助认证分析师了解范围内的系统，并帮助确定采样。 还请指明所使用的托管环境类型;ISV 托管、IaaS、PaaS 或混合。 注意： 如果使用 SaaS，请指出用于在环境中提供支持服务的各种 SaaS 服务。 |
| 公共足迹 | 详细说明支持基础结构使用 的所有 公共 IP 地址和 URL。 这必须包括分配给环境的完整可路由 IP 范围，除非已实现足够的分段来拆分正在使用的范围 (需要足够的分段证据) |
| 数据流图 | 详细描述以下内容的流程图： |
| • Microsoft 365 数据流与应用/外接程序 (，包括 EUII 和 OII.) | |
| • Microsoft支持基础结构 (365 数据流（如果适用) ）。 | |
| • 突出显示存储位置和哪些数据的示意图、如何将数据传递给外部第三方 (包括哪些第三方) 的详细信息，以及如何通过开放/公共网络和静态网络保护传输中的数据。 | |
| API 终结点详细信息 | 应用使用的所有 API 终结点的完整列表。 若要帮助了解环境范围，请在环境中提供 API 终结点位置。 |
| Microsoft API 权限 | 提供文档，详细说明 使用的所有 Microsoft API，以及请求的应用/外接程序正常运行的权限，以及请求的权限的理由 |
| 数据存储类型 | 数据存储和处理描述： |
| • 接收和存储Microsoft 365 数据 EUII 和 OII 的程度 | |
| ✓ 数据保留期。 | |
| • 捕获Microsoft 365 数据的原因。 | |
| • 其中Microsoft 365 数据存储 (也应包含在上述) 提供的数据流关系图中。 | |
| 符合性确认 | 发布者证明提交中包含的外部安全框架的支持文档，或在审查Microsoft 365 认证安全控制措施时要考虑的文档。 目前支持以下四种： |
| • PCI DSS 符合性证明 (AOC) 。 | |
| • SOC 2 类型 I/类型 II 报告。 | |
| • ISMS / IEC - 1S0/IEC 27001 (SoA) 和认证适用性声明。 | |
| • FedRAMP FedRAMP 授权包和 FedRAMP 就绪情况评估报告。 | |
| Web 依赖项 | 文档列出了应用使用当前正在运行的版本使用的所有依赖项。 |
| 软件库存 | 最新的软件清单，包括范围内环境中使用的所有软件以及版本。 |
| 硬件清单 | 支持基础结构使用的最新硬件清单。 这将用于在执行评估阶段时帮助采样。 如果环境包含 PaaS，请提供使用的云服务/资源的详细信息。 |
证据收集和评估活动
认证分析师需要查看所定义示例集中所有系统组件的证据。 支持评估过程所需的证据类型包括以下任何或全部：
证据收集
- 初始文档提交指南中突出显示 的初始文档
- 策略文档
- 处理文档
- 系统配置设置
- 更改票证
- 更改控制记录
- 系统报表
- 会议分钟数
- 合同/协议
将采用各种方法收集完成评估过程所需的证据。 此证据收集可能采用以下形式：
- 文档
- 屏幕截图
- 采访
- 屏幕共享
将在评估过程中确定使用的证据收集技术。 有关提交中所需证据类型的具体示例，请参阅 示例证据指南。
评估活动
认证分析师将审查提供的证据，以确定是否已满足Microsoft 365 认证的所有控制。
为了减少完成评估所需的时间，应提前提供 初始文档提交 中详述的任何或所有文档。
认证分析师将首先审查从初始文档提交和发布者证明信息中提供的证据，以确定适当的查询线、抽样大小以及需要进一步获取证据，如上文所述。 认证分析师将分析收集的所有信息，以得出有关如何以及是否满足本Microsoft 365 认证规范中的控制措施的结论。
应用认证条件
应用及其支持基础结构和支持文档将跨以下三个安全域进行评估：
每个安全域都包含特定的关键控制，这些控制包括一个或多个要求，这些要求将在评估过程中进行评估。 为确保 Microsoft 365 认证适用于所有规模的开发人员，将使用评分系统评估每个安全域，以确定每个域的总体分数。 每个Microsoft 365 认证控制措施的分数在 1 (低) 和 3 (高) 之间分配，具体取决于未实施该控制措施的感知风险。 每个安全域都有一个被视为通过的最小百分比标记。 此规范的某些元素包括一些自动失败条件：
- 不遵循最小特权原则的 API 权限 (PoLP) 。
- 必要时不会报告渗透测试报告。
- 没有反恶意软件防御。
- 多重身份验证未用于保护管理访问。
- 无修补进程。
- 没有合适的 GDPR 隐私声明。
应用程序安全性
应用程序安全域侧重于三个方面：
- GraphAPI 权限验证
- 外部连接检查
- 渗透测试
GraphAPI 权限验证
执行 GraphAPI 权限验证以验证应用/外接程序不会请求过于宽松的权限。 这是通过手动检查请求的权限来执行的。 认证分析师将对照发布者证明提交交叉引用这些检查，并评估请求的访问级别，以确保满足“最低特权”做法。 如果认证分析师认为不符合这些“最低特权”做法，认证分析师将与 ISV 进行公开讨论，以验证请求权限的业务理由。 在此评审期间发现与发布者证明提交的任何差异都需要更正。
外部连接检查
在评估过程中，将执行应用程序功能的轻松演练，以识别在 Microsoft 365 之外建立的任何连接。 任何未标识为Microsoft或直接连接到服务的连接都将在评估期间进行标记和讨论。
渗透测试
充分审查与应用/外接程序和支持环境相关的风险对于为客户提供应用/外接程序安全性的保证至关重要。 如果应用程序与Microsoft未发布的任何服务建立任何连接，则必须以渗透测试的形式进行应用程序安全测试。 如果部署后，应用仅独立访问 graphAPI 等Microsoft服务，则不需要进行渗透测试。 如果 范围内环境 托管在 Azure 中，则仍需要进行渗透测试。
渗透测试范围
对于内部和外部基础结构渗透测试，所有渗透测试活动 都必须 在支持部署应用/外接程序 (的实时生产环境中执行;其中，应用/外接程序代码托管，该代码通常是清单文件中的资源) 以及支持应用/外接程序操作的任何其他环境 (例如，如果应用/外接程序与 Microsoft 365) 之外的其他 Web 应用程序通信。 定义渗透测试的范围时，需要小心确保任何可能影响范围内环境安全性的“连接”系统或环境也包括在 ALL 渗透测试活动中。
建议对实时生产环境执行 Web 应用程序渗透测试。 但是，使用测试/UAT 环境仅对 Web 应用程序进行测试是可以接受的，前提是在渗透测试报告中确认测试时测试/UAT 环境中运行的代码库完全相同。
如果使用技术将范围内的环境与其他环境分开，渗透测试活动必须验证所述分段技术的有效性。 这必须在渗透测试报告中详细说明。
注意
除非托管环境仅归类为 PaaS，否则必须执行内部渗透测试。
渗透测试要求
将审查渗透测试报告，以确保不存在满足以下控制措施中概述的 自动故障条件 的漏洞。
| 条件类型 | 渗透测试控制 |
|---|---|
| 常规条件 | Web 应用程序 (经过身份验证和未经身份验证的) ，并且内部 (（如果适用）) 和外部基础结构渗透测试 必须 每年 (一次，) 由信誉良好的独立公司进行。 |
| 必须根据 ISV 记录的修补过程，在渗透测试结束后的一个月内或更早地完成确定的关键和 高风险漏洞的 修正。 | |
| 完整的外部占用 (IP 地址、URL、API 终结点等 ) 必须 包含在渗透测试范围内，并且必须在渗透测试报告中明确记录。 | |
| 除非环境与 PaaS 保持一致，否则完整的内部网络 必须 包含在渗透测试范围内，并且必须在渗透测试报告中明确记录。 | |
| Web 应用程序渗透测试 必须 包括所有漏洞类;例如，最新的 OWASP Top 10 或 SANS Top 25 CWE。 建议在渗透测试报告中对此进行了详细说明，否则将难以证明。 | |
| 被视为自动故障的关键和高风险漏洞 必须由 渗透测试公司重新测试，并在渗透测试报告中明确突出显示为修复。 | |
| 自动失败条件： | 存在不受支持的操作系统或不受支持的 JavaScript 库。 |
| 存在默认、可枚举或可猜测的管理帐户。 | |
| 存在 SQL 注入风险。 | |
| 存在跨站点脚本。 | |
| 存在目录遍历 (文件路径) 漏洞。 | |
| 存在 HTTP 漏洞，例如标头响应拆分、请求走私和取消同步攻击。 | |
| 是否存在源代码泄露 (包括 LFI) 。 | |
| CVSS 修补程序管理指南定义的任何关键或高分。 | |
| 任何容易利用的重大技术漏洞，以破坏大量 EUII 或 OUI。 |
重要
报告必须能够提供足够的保证，才能演示上述渗透测试要求部分中详述的所有内容。
免费渗透测试要求和规则
- 对于目前不从事渗透测试的 ISV，可以免费进行Microsoft 365 认证的渗透测试。 Microsoft将安排并支付长达 12 天的手动测试的渗透测试费用。 渗透测试成本是根据测试范围内环境所需的天数计算的。 超过 12 天的测试费用由 ISV 负责。
- 在进行渗透测试之前，ISV 将需要提交证据并获得对 50% 范围内控制措施的批准。 若要开始，请填写初始文档提交，并选择将渗透测试包含在评估中。 完成 50% 的控制后，系统会联系你确定渗透测试的范围和计划。
- 完成笔测试后颁发的报告将在 ISV 完成认证后提供给 ISV。 此报告与 Microsoft 365 认证可用于向潜在客户展示你的环境是安全的。
- ISV 还将负责证明在授予认证之前，渗透测试中发现的漏洞已得到修正，但不需要生成干净的报告。
安排渗透测试后，ISV 负责与重新安排和取消相关的费用，如下所示：
| 重新安排费用时间刻度 | 应付比例 |
|---|---|
| 重新计划请求在计划开始日期前 30 天收到。 | 0% 应付 |
| 重新计划请求在计划开始日期前 8 到 30 天收到。 | 25% 应付 |
| 在预定开始日期前 2 到 7 天内收到的重新计划请求，并提供了公司重新预订日期。 | 50% 应付 |
| 重新计划请求在开始日期前不到 2 天收到。 | 100% 应付 |
| 取消费用时间刻度 | 应付比例 |
|---|---|
| 取消请求在计划开始日期前 30 天收到。 | 25% 应付 |
| 取消请求在计划开始日期前 8 到 30 天收到。 | 50% 应付 |
| 在计划开始日期之前的 7 天内收到的取消请求。 | 90% 应付 |
操作安全性
此域衡量应用的支持基础结构和部署过程与安全最佳做法的一致性。
控件
| 控件系列 | Controls |
|---|---|
| 认知培训 | 作为新用户初始培训的一部分或信息系统更改的一部分，组织向信息系统用户提供既定的安全意识培训， (包括经理、高级管理人员和承包商，) 。 |
| 提供组织定义意识培训频率的证据。 | |
| 提供单个信息系统安全意识活动的文档和监视证据，同时以组织定义的频率保留单个培训记录。 | |
| 恶意软件防护 - 防病毒 | 提供反恶意软件解决方案处于活动状态的证据，并在所有抽样系统组件中启用，并配置为满足以下条件： |
| 如果具有防病毒功能，则启用该按访问扫描且签名在 1 天内处于最新状态，并在检测到恶意软件时自动阻止恶意软件或警报和隔离。 | |
| 或者，如果 EDR/NGAV (终结点检测和响应/下一代防病毒) 则定期执行扫描，生成审核日志，并持续保持最新状态并具有自学功能。 | |
| 如果 EDR/NGAV，它将阻止已知的恶意软件，并根据宏行为识别和阻止新的恶意软件变体，并具有完整的安全列表功能。 | |
| 恶意软件防护 - 应用程序控制 | 提供可证明的证据，证明存在具有业务理由的已批准软件/应用程序列表并且是最新的。 |
| 每个应用程序在部署之前都经过审批过程并注销 | |
| 该应用程序控制技术在记录的所有采样系统组件中处于活动状态、已启用和配置。 | |
| 修补程序管理 - 修补和风险排名 | 提供策略文档，用于控制如何识别新安全漏洞并为其分配风险评分。 |
| 提供有关如何识别新安全漏洞的证据。 | |
| 提供证明所有漏洞在识别后都分配了风险排名的证据。 | |
| 提供证据，证明所有抽样系统组件正在与组织定义的修补时间范围一致且未使用不支持的操作系统和软件组件。 如果使用无服务器技术或 PaaS，则这在适用时应包括代码库;如果使用 IaaS，则应同时包含基础结构和代码库。 | |
| 修补时间范围指南：关键 - 在 14 天内，高 - 在 30 天内，中 - 在 60 天内。 | |
| 漏洞扫描 | 提供季度基础结构和 Web 应用程序漏洞扫描报告。 需要针对整个公共占用空间执行扫描， (IP 地址和 URL) 和内部 IP 范围。 |
| 提供可证明的证据，证明在漏洞扫描期间识别的漏洞修正已按照记录的修补时间范围进行修补。 | |
| NSC) (网络安全控制 | 提供网络安全控制 (NSC) 安装在作用域内环境的边界上，并安装在外围网络与内部网络之间。 |
| 如果混合、本地、IaaS 还提供所有公共访问终止在外围网络的证据。 | |
| 验证所有网络安全控制 (NSC) 都配置为删除规则库中未显式定义的流量，以及网络安全控制 (NSC) 规则评审是否至少每 6 个月执行一次。 | |
| 更改控件 | 提供证据，证明对生产环境引入的任何更改都是通过记录的更改请求实现的，这些请求包含更改的影响、回退过程的详细信息、要执行的测试、授权人员的审查和批准。 |
| 提供独立环境存在的证据，以便：开发和测试/过渡环境强制从生产环境分离职责，通过访问控制强制职责分离，敏感生产数据不在开发或测试/过渡环境中使用。 | |
| 保护软件开发/部署 | 提供支持安全软件开发的策略和过程，并包括安全编码的行业标准和/或最佳做法。 例如 Open Web Application Security Project (OWASP) Top 10 或 SysAdmin、Audit、Network and Security (SANS) 前 25 个常见弱点枚举 (CWE) 。 |
| 提供代码存储库受到保护的证据，以便：所有代码更改在与 main 分支合并之前都经过第二个审阅者的审查和审批过程，适当的访问控制到位，所有访问都通过多重身份验证 (MFA) | |
| 提供证据，证明在部署之前， () 的所有发布都经过审查和批准。 | |
| 帐户管理 | 提供证据，证明已跨采样系统组件禁用、删除或更改默认凭据。 |
| 提供一个流程是否已到位，以确保 (强化) 服务帐户，并证明此过程已遵循。 | |
| 提供以下证据：向所有用户颁发唯一用户帐户，在环境中遵循用户最低特权原则，已制定强密码/密码策略或其他适当的缓解措施，已到位并至少每三个月遵循一个过程，以禁用或删除三个月内未在三个月内使用的帐户。 | |
| 验证是否为所有远程访问连接和所有非控制台管理接口配置了 MFA，包括访问任何代码存储库和云管理接口。 | |
| 安全事件日志、查看和警报 | 提供证据，证明可以立即获得至少 30 天的安全事件日志记录数据，并保留 90 天的安全事件日志。 |
| 提供证据，证明定期审查日志，并在审查过程中发现的任何潜在安全事件/异常得到调查和解决 | |
| 提供警报规则配置的证据，以便触发警报以调查以下安全事件（如果适用）：特权帐户创建/修改、特权/高风险活动或操作、恶意软件事件、事件日志篡改、IDPS /WAF 事件。 如果配置了) ，则 ( | |
| 信息风险管理 | 提供证据，证明已批准正式的信息安全风险管理策略/流程已记录和建立。 |
| 提供证明至少每年进行一次正式的公司范围的信息安全风险评估。 | |
| 针对目标风险分析的 OR：对于没有实施传统控制措施或行业最佳做法、设计/技术限制造成将漏洞引入环境或使用户和数据面临风险的每个实例，至少每 12 个月记录并执行一次有针对性的风险分析， 怀疑或确认泄露时。 | |
| 验证信息安全风险评估是否包括受影响的系统组件或资源、威胁和漏洞或等效项、影响和可能性矩阵或等效项、风险注册/风险处理计划的创建。 | |
| 提供证据，证明你已有一个风险管理流程来评估和管理与供应商和业务合作伙伴相关的风险，并且可以识别和评估可能影响内部控制系统的更改和风险。 | |
| 安全事件响应 | (IRP) 提供已批准的安全事件响应计划/过程。 |
| 提供证据，概述组织如何响应事件，显示其维护方式，并包括事件响应团队的详细信息，包括联系信息、事件期间的内部沟通计划，以及与主要利益干系人、支付品牌和收购方、监管机构 (（例如，GDPR) 72 小时）的外部沟通， 监督机构、董事、客户以及事件分类、遏制、缓解、恢复和恢复正常业务运营等活动的步骤，具体取决于事件类型 | |
| 提供证据，证明事件响应团队的所有成员都接受了年度培训，使他们能够对事件做出响应。 | |
| 提供证据，证明事件响应策略和支持文档将根据从桌面练习中吸取的经验教训、从响应事件中吸取的经验教训、组织变化来审查和更新。 | |
| 业务连续性计划和灾难恢复计划 | 提供文档存在并得到维护的证据，其中概述了业务连续性计划。 |
| 提供有关业务连续性计划详细信息及其角色和职责的证据，包括：具有相关应变要求和目标的业务职能、系统和数据备份过程、配置和计划/保留、恢复优先级和时间范围目标、应变计划，详细说明在发生事件时要遵循的操作、步骤和过程，以将关键信息系统、业务职能和服务返回到操作意外和计划外中断，这是一个涵盖最终完全系统还原并返回到原始状态的既定过程。 | |
| 提供证据，证明文档存在、已维护，并概述了灾难恢复计划，其中至少包括：人员及其角色、职责和升级过程、用于支持关键业务功能和服务的信息系统清单、系统和数据备份过程以及配置，恢复计划详细说明了在将关键信息系统和数据还原到操作时应遵循的操作和过程。 | |
| 提供证据证明业务连续性计划和灾难恢复计划至少每 12 个月审查一次，以确保它在不利情况下保持有效。 | |
| 提供证据，根据计划的年度审查更新业务连续性计划，接受有关他们在应变计划中分配的角色和职责的培训的所有相关人员，该计划正在通过业务连续性或灾难恢复练习进行测试，测试结果被记录，包括从练习或组织变化中吸取的经验教训。 |
数据处理安全和隐私
应用程序用户、中介服务和 ISV 系统之间传输的数据需要通过支持 TLS v1.1 的 TLS 连接进行加密保护。 建议) (TLS v1.2+。 请参阅附录 A。
应用程序检索和存储Microsoft 365 数据时，需要实现遵循 附录 B 中定义的规范的数据存储加密方案。
控件
| 控件系列 | Controls |
|---|---|
| 传输中的数据 | 提供证据，证明 TLS 配置在 TLS 配置文件配置要求 中验证 TLS 配置是否为 TLS1.2 或更高版本，以及保留和维护受信任的密钥和证书清单。 |
| 提供证据显示，处理 Web 请求的所有面向公众的服务都禁用了 TLS 压缩，以防止压缩比率信息泄漏使 (犯罪) ，并且 TLS HSTS 在所有站点中启用并配置为 180 天。 | |
| 静态数据 | 使用高级加密Standard (AES) 、RSA 和 Twofish 等加密算法（例如，加密密钥大小为 256 位或更高），证明静态数据已按照加密配置文件要求进行加密。 |
| 数据保留、备份和处置 | 提供已正式建立并记录已批准的数据保留期的证据。 |
| 提供证据，证明数据仅在定义的保留期内保留，如上一控件中所述。 | |
| 提供证据，证明在数据保留期后已准备好安全删除数据的过程。 | |
| 提供自动备份系统已到位并配置为在计划时间执行备份的证据。 | |
| 提供根据备份计划过程测试备份信息的证据，并定期还原，以确认数据的可靠性和完整性。 | |
| 提供适当的访问控制和保护机制 (即实现不可变备份) ，以确保备份/系统快照受到保护，防止未经授权的访问，并确保备份数据的机密性、完整性和可用性。 | |
| 数据访问管理 | 提供证据，证明维护了有权访问数据和/或加密密钥的用户列表。 包括每个人的业务理由，并确认此用户列表已根据其工作职能所需的访问权限正式批准，并且用户使用审批中概述的权限进行配置。 |
| 提供证据，证明已维护与共享数据的所有第三方的列表，并且与使用数据的所有第三方签订了数据共享协议。 | |
| 隐私 | 你的组织是否具有隐私信息管理 (PIM) 系统建立、实施和维护，该系统通过策略或其他形式的文档/计算机化系统来保持领导承诺，了解如何维护隐私信息管理工作以实现系统机密性和完整性。 确定维护系统的每个人（包括 PII 处理器和控制器）的角色、职责和权限。 |
| 提供验证 PII 最小化过程的证据，在处理期结束时正在进行 PII 取消标识和删除，对 PII 传输（包括任何机密性）的控制措施到位，是否存在从一个国家/地区向另一个国家/地区传输 PII 的记录，并表示同意这样做。 | |
| GDPR | 提供证据，证明数据主体能够提高 SAR，ISV 在响应 SAR 请求时能够识别数据主体数据的所有位置，以及备份有一个保留期，允许请求通过 SAR 删除数据的客户端删除，因为删除一段时间内的滚动备份 (最早的备份删除/重写) 的生命周期。 |
| 提供隐私声明，其中应包含以下所有必需元素： (姓名、地址和其他个人身份信息) 、正在处理的个人数据类型、个人数据的保留时间、处理个人数据的合法性、数据主体权利;包括：数据主体的权利、知情权、数据主体的访问权、删除权、处理限制权、数据可移植性的权利、对象权、与自动决策（包括分析）相关的权利。 | |
| HIPAA | 提供证据：组织中针对员工、承包商、供应商等的 HIPAA 和 HIPAA 处理存在策略。验证我们的组织是否确保 ePH 的机密性、完整性和可用性。 |
| 验证你：提供保护，防止隐私规则不允许的此类信息的合理预期使用或泄露，确保其员工遵守安全规则。 提供 164.308 () (7) (ii) (A) 和 164.308 () (7) (ii) (B) 下的数据备份和灾难恢复计划。 |
可选的外部合规性框架评审
虽然不是必需的，但如果当前符合 ISO 27001、PCI DSS、FedRAMP 或 SOC2，则可以选择使用这些认证来满足某些Microsoft 365 认证控制。分析师将尝试将现有外部安全框架与 Microsoft 365 认证框架保持一致。 但是，如果支持文档无法保证Microsoft 365 认证控制措施已作为外部安全框架审核/评估的一部分进行评估，则需要提供上述控制措施到位的其他证据。
文档必须充分证明Microsoft 365 认证的作用域内环境已包含在这些外部安全框架的范围内。 这些安全框架的验证将通过接受信誉良好的外部第三方公司进行的有效认证证据来实现。 这些信誉良好的公司必须是相关合规计划的国际认证机构的成员。 请参阅 ISO 27001 的 ISO 认证和符合性标准以及 PCI DSS (QSA) 合格安全评估员。
下表突出显示了认证分析师在此验证过程中所需的外部框架和文档：
| Standard | 要求 |
|---|---|
| ISO 27001 | 需要面向公众的 SOA (适用性声明) 和颁发的 ISO 27001 证书副本。 SOA 汇总了你对 114 个信息安全控制措施中每个控件的立场，并用于识别 ISO 27001 证书中是否排除了未令人满意详细说明的控制措施。 如果无法通过查看面向公众的 SOA 版本来确定这一点，如果 ISO 27001 将用于验证某些Microsoft 365 认证安全控制措施，分析师可能需要访问完整的 SOA。 除了验证 ISO 27001 评估活动的范围外，分析师还将确认上述审核公司的有效性。 |
| PCI DSS | 必须提供 AOC) 文档 (符合性的有效级别 1 证明 ，以明确标识范围内的应用程序和系统组件。 自我评估 AOC 不会 被视为满足安全最佳做法的证据。 AOC 将用于确定哪些Microsoft 365 认证规范控制措施已作为 PCI DSS 评估的一部分进行评估和确认。 |
| SOC 2 | SOC 2 (II) 报告必须是过去 15 个月内发布的当前 (，并且声明的时间段必须在过去 27 个月内开始，) 用作符合此Microsoft 365 认证框架中的任何评估控制措施的证据。 |
| FedRAMP | 联邦风险和授权管理计划 (FedRAMP) 是美国联邦政府范围的计划，成立于 2011 年。 它为云产品和服务提供安全评估、授权和持续监视的标准化方法。 |
| 框架 | 其他注意事项 |
|---|---|
| ISO 27001 | 附录 C：证据收集 - ISO 27001 的增量。 |
| PCI DSS | 附录 D：证据收集 - PCI DSS 的增量。 |
| SOC 2 | 附录 E：证据收集 - SOC 2 的增量。 |
注意
尽管上述外部安全标准/框架可以作为证据提交，以满足某些Microsoft 365 认证控制措施，但通过 Microsoft 365 认证并不意味着应用将成功通过针对这些标准/框架的审核。 Microsoft 365 认证规范只是这些安全标准/框架的一小部分，允许Microsoft在安全态势方面获得一定程度的保证。
使用外部合规性框架的要求
• 范围 内环境和任何 支持业务流程 必须 包含在任何受支持的外部安全合规性框架的范围内，并且必须在提供的文档中明确说明。
• 支持的外部安全合规性框架 必须是 最新的，也就是说，在过去 12 个月内 (或 15 个月内（如果当前正在进行重新评估并且可以) 提供证据）。
• 支持的外部安全合规性框架 必须由 独立的认证公司执行。