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)
- CoPilot 扩展
重要
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 AppSource 市场中收到特殊的标记和列表。
查看 控制条件 并不总是要求遵守所有控制才能获得认证。 但是，对于本概述文档中讨论的三个安全域中的每一个，) 不会披露的阈值 (，必须通过。 未能满足标记为“硬失败”的关键控制将导致评估失败。
提交时间范围
提交过程分为两个阶段来实现认证：
阶段 1：初始文档提交 (14 天时限)
在此阶段，ISV 必须提交文档，以概述其应用支持环境。 这包括但不限于：
- 体系结构图/数据流
- 系统组件列表
- 软件资产清单
分析师将查看此文档以定义评估范围。 ISV 在 14 天内完成和上传所需文档。 未能满足此最后期限可能会延迟该过程或导致提交失败。
第 2 阶段：全面证据审查 (60 天的时间范围)
定义范围后，ISV 将进入证据收集阶段。 在此阶段：
- ISV 必须针对范围中定义的所有适用控件上传证据。
- 如果需要) ，将对此证据进行审查、修订 (，以及最终的 QA 过程。
- 如果需要，在此期间还可以进行渗透测试。
ISV 有 60 天的时间完成此阶段，从第一次提交证据开始，其中包括：
- 上传所有控件的证据
- 分析师评审和反馈
- 对提交的证据进行任何必要的修订
- 完成 QA 过程
未能满足最后期限
如果 ISV 无法在 60 天的时间范围内完成该过程，评估将失败。 但是，根据分析师的判断，在有效情况下，可以再延长 60 天，例如：
- 季节性假期。
- 渗透测试延迟。
- 内部更改。
- 实现必要的更改以满足控制要求所需的时间。
一旦这两个 60 天的时间范围都用尽，就不能授予进一步的延期。
认证范围
范围内环境包括交付应用或外接程序代码所需的所有系统和基础结构，以及应用/外接程序可能与之通信的任何支持后端系统。 连接到范围内环境的任何其他环境也必须包含在范围内，除非实现了足够的分段，并且连接的环境不能损害范围内环境的安全性。
请注意：任何单独的灾难恢复环境也必须包含在范围内环境中，因为这些环境对于在主要环境发生故障时保持服务连续性可能至关重要。
此外，远程备份环境还必须纳入范围，因为它们可能存储敏感的Microsoft数据。 因此，必须对这些环境实施足够的安全控制。
术语“作用域内系统组件”包括在定义的范围内环境中主动使用的所有设备和系统。 这些组件包括但不限于：
- Web 应用程序
- 服务器 (物理或虚拟，位于本地或云中)
- 交换机
- 负载均衡器
- 虚拟基础结构
- 云提供商 Web 管理门户
- 云资源 (虚拟机、应用服务、存储帐户、数据库等 )
重要
面向公众的系统组件特别容易受到外部威胁参与者的攻击，因此风险较高。 通常，这些系统应通过实施网络安全控制 (NSC) （如外围网络 (外围网络) ）与内部系统组件隔离。 外围网络的目的是充当缓冲区，限制扩展至外部系统的信任，并增强安全性，以保护内部系统和数据。 虽然外围网络在某些情况下仍然很理想，但现代云体系结构通常依赖于针对特定部署方案定制的替代安全措施。
基础结构即服务 (IaaS) 、平台即服务 (PaaS) 和软件即服务 (SaaS)
如果 IaaS 和/或 PaaS 用于支持所审查的范围内环境，则云平台提供商将负责整个认证过程中评估的一些安全控制措施。 云平台提供商需要通过外部合规性报告（如 PCI DSS、AOC) 、ISO 27001 或 SOC 2 类型 II 报告） (向分析师提供安全最佳做法的独立外部验证。
有关哪些安全控制可能适用于部署类型以及环境是处理还是传输Microsoft 365 数据的详细信息，请参阅 附录 C。部署类型包括：
ISV 托管：独立软件供应商托管的应用程序 IaaS 托管：第三方云平台提供的基础结构。 PaaS/无服务器托管：基于平台的应用程序平均体系结构或无服务器体系结构。 混合托管：本地和云托管组件的组合。 共享托管：多个租户使用的共享云环境。
在使用 IaaS 或 PaaS 的情况下，必须有证据验证部署是否符合相关体系结构的预期安全控制。
采样
为确保全面评估，对范围内系统组件的采样必须考虑操作系统、主设备功能、设备类型 (等因素，例如服务器、路由器、网络安全控制) 和地理位置。 根据这些注意事项，在认证过程开始时选择示例。 下表根据范围内组件的填充来指导采样大小：
| 总体大小 | 示例 |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
这可确保跨不同配置和部署模型对环境的符合性进行代表性评估。
注意
如果在评估期间发现设备之间的差异，可以调整样本大小，以确保充分呈现环境。
认证过程概述
若要开始Microsoft 365 认证过程，
发布者证明 转到合作伙伴中心并完成发布者证明表单。 注意：如果你的提交时间超过三个月，则必须重新提交它以供审阅和验证。
在合作伙伴中心启动认证一次，选择“开始认证”选项以开始提交初始文档。 此步骤可帮助认证分析师根据应用的体系结构及其管理Microsoft数据的方式确定评估范围。
认证分两个main阶段进行：
初始文档提交 在此阶段，你将提供关键详细信息，以帮助分析师了解应用的设计、数据流和范围内环境。 分析师将确定适用的安全控制措施，并概述需要证据的系统组件。 必须提供准确的文档才能促进此评审，这大约占整个流程的 5%。
完整证据评审 在此阶段中，提交详细证据，证明符合范围内环境的安全控制措施。 在此阶段，分析师将与你密切合作，以审查、澄清和验证你的提交内容。 此阶段将完成此过程的其余部分。
评估
初始文档提交获得批准后，门户中将显示所需的安全控制列表。 你有 60 天 的时间为每个控件提供证据，确认它已到位并正常运行。 分析师将审查你的证据并批准它或请求其他详细信息或修订。
认证
你的提交经过分析师评审和验证后，你将收到有关认证决策的通知。 成功满足认证条件的应用将获得徽章，该徽章将显示在其 AppSource 列表和关联的Microsoft Docs页面上。 这些页面还将提供有关应用安全性和合规性属性的详细报告。
查看和重新认证
Microsoft 365 认证应用必须每年重新认证，以确保持续符合 Microsoft 的标准。 重新认证过程涉及重新评估范围内控件，以确认它们与当前环境保持一致。 可以在认证到期前 90 天内开始重新认证过程，以避免出现任何中断。 在此期间，认证将保持有效。
如果重新认证未在到期日期之前完成，则证书将被撤销。 结果为：
应用的认证徽章和品牌将被删除。
将不再允许 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)
必要时缺少渗透测试报告。
缺少反恶意软件防御。
无法实现多重身份验证 (MFA) 进行管理访问。
修补进程缺失或不足。
缺少符合 GDPR 的隐私声明。
应用程序安全性
应用程序安全域评估以下方面：
- GraphAPI 权限验证
- 外部连接检查
- 渗透测试
GraphAPI 权限验证
这可确保应用或外接程序不会请求过多或过度宽松的权限。 认证分析师手动评审应用请求的权限，并针对发布者证明提交交叉检查这些权限。
目标是确认请求的权限符合最小特权原则。 如果分析人员发现应用请求的权限超出了所需权限，他们将与 ISV 联系，以验证这些权限的业务理由。 在此评审期间，必须解决所请求的权限与发布者证明提交之间的任何差异。
外部连接检查
在认证过程中，分析师对应用程序的功能执行高级评审，以确定在 Microsoft 365 之外建立的任何外部连接。
任何未标识为Microsoft服务或与服务无关的连接都将在评估期间标记为讨论，以确保符合安全性和功能标准。
渗透测试
渗透测试对于识别和缓解与应用或外接程序及其支持环境相关的风险至关重要。 这可确保应用为客户提供足够的安全保障。
对于连接到未由Microsoft托管或管理的外部服务的任何应用 ，必须进行 渗透测试。 如果将应用部署为仅使用 graphAPI 等Microsoft服务的独立解决方案，则可能不需要进行渗透测试。 但是，Azure 中托管的应用必须经过渗透测试，以确保范围内环境的安全性。
渗透测试范围
基础结构测试：对于内部和外部基础结构，必须在支持应用或外接程序的 实时生产环境中 进行渗透测试。 这包括：
托管应用或外接程序代码的环境 (通常在清单文件中引用)
与应用/外接程序 (交互或支持操作的任何其他环境，例如，如果应用/外接程序与 Microsoft 365) 之外的其他 Web 应用程序通信。
定义渗透测试的范围时，必须包括可能影响范围内 环境安全性的所有连接系统或环境 。
建议
Web 应用程序渗透测试：建议直接针对实时生产环境执行 Web 应用渗透测试。 但是，Web 应用测试可以在测试/UAT (用户验收测试) 环境中执行，前提是渗透测试报告确认在测试时在生产环境中使用了相同的代码库。
分段验证：如果使用分段技术将范围内的环境与其他环境隔离，则渗透测试报告必须验证这些分段技术的有效性。 这可确保通过分段过程不会引入任何漏洞。
渗透测试要求
将审查渗透测试报告，以确保不存在满足以下控制措施中概述的 自动故障条件 的漏洞。
| 条件类型 | 渗透测试控制 |
|---|---|
| 常规条件 | Web 应用程序 (经过身份验证和未经身份验证的) ，并且内部 (（如果适用）) 和外部基础结构渗透测试 必须 每年 (一次，) 由信誉良好的独立公司进行。 |
| 必须根据 ISV 记录的修补过程，在渗透测试结束后的一个月内或更早地完成确定的关键和 高风险漏洞的 修正。 | |
| 完整的外部占用 (IP 地址、URL、API 终结点等 ) 必须 包含在渗透测试范围内，并且必须在渗透测试报告中明确记录。 | |
| 除非环境与 PaaS 保持一致，否则完整的内部网络 必须 包含在渗透测试范围内，并且必须在渗透测试报告中明确记录。 | |
| Web 应用程序渗透测试 必须 包括所有漏洞类;例如，最新的 OWASP Top 10 或 SANS Top 25 CWE。 建议在渗透测试报告中对此进行了详细说明，否则将难以证明。 | |
| 被视为自动故障的关键和高风险漏洞 必须由 渗透测试公司重新测试，并在渗透测试报告中明确突出显示为修复。 | |
| 自动失败条件： | 存在不受支持的操作系统或不受支持的 JavaScript 库。 |
| 存在默认、可枚举或可猜测的管理帐户。 | |
| 存在 SQL 注入风险。 | |
| 存在跨站点脚本。 | |
| 存在目录遍历 (文件路径) 漏洞。 | |
| 存在 HTTP 漏洞，例如标头响应拆分、请求走私和取消同步攻击。 | |
| 是否存在源代码泄露 (包括 LFI) 。 | |
| CVSS 修补程序管理指南定义的任何关键或高分。 | |
| 任何容易利用的重大技术漏洞，以破坏大量 EUII 或 OUI。 |
重要
报告必须能够提供足够的保证，才能演示上述渗透测试要求部分中详述的所有内容。
免费渗透测试要求和规则
对于当前未执行渗透测试的 ISV，Microsoft在Microsoft 365 认证过程中提供免费的渗透测试服务。 此服务涵盖长达 12 天的手动测试，超出此天数的任何额外费用由 ISV 负责。
关键要求
预测试要求：在计划渗透测试之前，ISV 必须提交证据并获得 50% 范围内控制措施的批准。
测试报告：此报告以及 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 个月审查一次，以确保它在不利情况下保持有效。 | |
| 提供证据，根据计划的年度审查更新业务连续性计划，接受有关他们在应变计划中分配的角色和职责的培训的所有相关人员，该计划正在通过业务连续性或灾难恢复练习进行测试，测试结果被记录，包括从练习或组织变化中吸取的经验教训。 |
数据处理安全和隐私
为确保数据安全，必须使用 TLS (传输层安全性) 连接对应用程序用户、中介服务和 ISV 系统之间传输的任何数据进行加密。 至少需要 TLS 1.2，强烈建议使用 TLS 1.3 或更高版本。 有关更多详细信息，请参阅附录 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 或 SOC 2 类型 2），则可以选择利用这些认证来满足某些Microsoft 365 认证控制。 分析师的目标是使现有的外部安全框架与 Microsoft 365 认证要求保持一致。
但是，如果支持文档未证明Microsoft 365 认证控制措施是作为外部框架审核或评估的一部分显式评估的，则必须提供其他证据来验证这些控制措施是否已到位。
文档要求
文档必须清楚地证明，Microsoft 365 认证的范围环境包含在永久安全框架的范围内。 这些框架的验证将通过接受由信誉良好、经认可的第三方审核员颁发的有效证书的证据来完成。
这些第三方审核员必须是国际认证机构的成员，例如：
ISO 27001 的认证和符合性标准
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 365 认证规范侧重于派生自这些框架的特定控件子集，以便为Microsoft提供有关应用安全状况的更高级别保证。
使用外部合规性框架的要求
• 范围 内环境和任何 支持业务流程 必须 包含在任何受支持的外部安全合规性框架的范围内，并且必须在提供的文档中明确说明。
• 支持的外部安全合规性框架 必须是 最新的，也就是说，在过去 12 个月内 (或 15 个月内（如果当前正在进行重新评估并且可以) 提供证据）。
• 支持的外部安全合规性框架 必须由 独立的认证公司执行。