有关安全测试的建议
适用于此 Power Platform Well-Architected 安全检查表建议：
| 东南：09 | 建立一个全面的测试方案，该方案结合了预防安全问题、验证威胁预防实施和测试威胁检测机制的方法。 |
|---|
严格的测试是良好安全设计的基础。 测试是一种战术性的验证形式，可确保控件按预期工作。 测试也是检测系统中漏洞的主动方法。
从多个角度通过节奏和验证建立测试严谨性。 应包括测试平台和基础结构的由内而外的视点，以及像外部攻击者一样测试系统的外部评估。
本指南提供有关测试工作负荷的安全状况的建议。 实施这些测试方法以提高工作负荷对攻击的抵抗力，并维护资源的机密性、完整性和可用性。
定义
| 术语 | 定义 |
|---|---|
| 应用程序安全测试 (AST) | 一种 Microsoft 安全开发生命周期（SDL）技术，它使用白盒和黑盒测试方法来检查代码中的安全漏洞。 |
| 黑盒测试 | 一种测试方法，用于在不了解系统内部的情况下验证外部可见的应用程序行为。 |
| 蓝色团队 | 一支在战争游戏演习中抵御红队攻击的团队。 |
| 渗透测试 | 一种测试方法，它使用道德黑客技术来验证系统的安全防御。 |
| 红色团队 | 一支扮演对手角色并试图在战争游戏演习中破解系统的团队。 |
| 安全开发生命周期 (SDL) | 提供的一组做法 Microsoft ，支持安全保证和合规性要求。 |
| 软件开发生命周期 (SDLC) | 用于开发软件系统的多阶段系统化流程。 |
| 白盒测试 | 一种测试方法，其中从业者知道代码的结构。 |
关键设计策略
测试是一种不可谈判的策略，对于安全性尤其如此。 它允许您在安全问题被利用之前主动发现和解决这些问题，并验证您实现的安全控件是否按设计运行。
测试范围必须包括应用程序、基础结构以及自动化和人工流程。
备注
本指南区分测试和事件响应。 尽管测试是一种检测机制，在理想情况下可以修复生产前的问题，但不应将其与作为事件响应一部分进行的修正或调查混淆。 有关安全事件响应的建议中介绍了从安全事件中恢复的方面。
参与测试计划。 工作负荷团队可能不会设计测试用例。 该任务通常集中在企业中，或由外部安全专家完成。 工作负荷团队应参与该设计流程，以确保安全保证与应用程序的功能集成。
像攻击者一样思考。 设计测试用例时，假设系统受到攻击。 这样，就可以发现潜在的漏洞，并相应地确定测试的优先级。
使用可重复的流程以结构化方式运行测试。 围绕节奏、测试类型、驱动因素和预期结果生成测试严谨性。
为作业使用正确的工具。 使用配置为处理工作负荷的工具。 如果没有工具，请购买该工具。 不要生成它。 安全工具具有高度专业化，生成自己的工具可能会带来风险。 利用中央 SecOps 团队提供的专业知识和工具，如果工作负荷团队没有这种专业知识，则利用外部手段。
设置单独的环境。 测试可分类为破坏性或非破坏性。 非破坏性测试不是侵入性的。 它们表示存在问题，但不会为了修正问题而更改功能。 破坏性测试是侵入性的，可能会通过从数据库中删除数据来损害功能。
在生产环境中进行测试可提供最有用的信息，但会导致最多的中断。 在生产环境中，您往往只执行非破坏性测试。 非生产环境中的测试通常较少中断，但可能无法以对安全非常重要的方式准确表示生产环境的配置。
可以使用环境复制功能创建生产环境的独立克隆。 如果您设置了部署管道，还可以将解决方案部署到专用测试环境。
始终评估测试结果。 如果不使用结果来确定操作的优先级并进行上游改进，则测试是一种浪费。 记录发现的安全准则，包括最佳做法。 捕获结果和修正计划的文档向团队介绍攻击者可能试图破坏安全的各种方式。 定期为开发人员、管理员和测试人员进行安全培训。
设计测试计划时，请考虑以下问题：
- 预计多久运行一次测试，它如何影响您的环境？
- 应运行哪些不同的测试类型？
预计多久运行一次测试？
定期测试工作负荷，以确保更改不会引入安全风险，并且没有任何回归。 团队还必须准备好响应可能随时进行的组织安全验证。 还可以运行一些测试来响应安全事件。 以下部分提供有关测试频率的建议。
例程测试
例程测试定期进行，这是标准操作过程的一部分，以满足合规性要求。 各种测试可能以不同的节奏运行，但关键是定期按计划进行。
应将这些测试集成到 SDLC 中，因为它们在每个阶段提供深度防御。 使测试套件多样化，以验证标识、数据存储和传输以及通信渠道的保证。 在生命周期的不同点执行相同的测试，以确保没有任何回归。 例程测试有助于建立初始基准。 但是，这只是一个起点。 当在生命周期的相同点发现新问题时，需要添加新的测试用例。 测试也会随着重复而改进。
在每个阶段，这些测试都应验证添加或删除的代码或已更改的配置设置，以检测这些更改的安全影响。 应通过自动化提高测试的效能，并与同行评审相平衡。
考虑在自动化管道或计划测试运行过程中运行安全测试。 越早发现安全问题，就越容易找到导致安全问题的代码或配置更改。
不要仅依赖于自动化测试。 使用手动测试来检测只有人类专业知识才能捕获的漏洞。 手动测试适用于探索性用例和查找未知风险。
临时测试
临时测试提供安全防御的时间点验证。 此时可能影响工作负荷的安全警报会触发这些测试。 如果警报升级为紧急情况，组织授权可能需要暂停和测试思维模式来验证防御策略的有效性。
临时测试的好处是为实际事件做好准备。 这些测试可以是执行用户验收测试 (UAT) 的强制函数。
安全团队可能会审核所有工作负荷，并根据需要运行这些测试。 作为工作负荷所有者，您需要与安全团队协作。 与安全团队协商足够的提前期，以便做好准备。 确认并传达给团队和利益干系人，这些中断是必要的。
在其他情况下，可能需要运行测试，并针对潜在威胁报告系统的安全状态。
权衡：由于临时测试是破坏性事件，因此预计会重新确定任务的优先级，这可能会延迟其他计划的工作。
风险：存在未知的风险。 在没有建立流程或工具的情况下，临时测试可能是一次性工作。 但主要风险是业务节奏的潜在中断。 您需要根据权益评估这些风险。
安全事件测试
有一些测试可以检测安全事件的源原因。 必须解决这些安全漏洞，以确保事件不会重复发生。
事件还会通过发现现有差距，随着时间的推移改进测试用例。 团队应该应用从事件中吸取的教训，并定期纳入改进。
有哪些不同类型的测试？
可以按技术和测试方法对测试进行分类。 将这些类别和方法合并到这些类别中，以获得完整的覆盖范围。
通过添加多个测试和测试类型，您可以发现：
- 安全控制或补偿控制方面的差距。
- 配置错误。
- 可观测性和检测方法方面的差距。
良好的威胁建模练习可以指向关键区域，以确保测试覆盖率和频率。 有关威胁建模的建议，请参阅有关保护开发生命周期的建议。
这些部分中介绍的大多数测试都可以作为例程测试运行。 但是，在某些情况下，可重复性可能会产生成本并导致中断。 请仔细考虑这些权衡。
验证技术堆栈的测试
下面是测试类型的一些示例及其重点领域。 此列表并不详尽。 测试整个堆栈，包括应用程序堆栈、前端、后端、API、数据库和任何外部集成。
- 数据安全：测试数据加密和访问控制的有效性，以确保数据得到适当保护，防止未经授权的访问和篡改。
- 网络和连接：测试防火墙，确保它们只允许预期、允许和安全的流量流向工作负载。
- 应用程序：通过应用程序安全测试（AST）技术测试源代码，以确保您跟随安全的编码做法并捕获运行时错误，例如内存损坏和权限问题。
- 标识：评估角色分配和条件检查是否按预期工作。
测试方法
对于测试方法有很多观点。 建议通过模拟真实世界攻击来启用威胁搜寻的测试。 它们可以识别潜在威胁参与者、其技术和对工作负荷构成威胁的漏洞。 使攻击尽可能现实。 使用在威胁建模期间识别的所有潜在威胁向量。
下面是通过实际攻击进行测试的一些优势：
- 当将这些攻击作为例程测试的一部分时，您可以使用外部视角来检查工作负荷，并确保防御能够抵御攻击。
- 根据他们吸取的经验教训，团队会提升他们的知识和技能水平。 团队可提高态势感知能力，并可以自我评估应对事件的准备情况。
模拟测试的一些示例包括黑盒和白盒测试、渗透测试和战争游戏练习。
黑盒和白盒测试
这些测试类型提供两种不同的视角。 在黑盒测试中，系统的内部不可见。 在白盒测试中，测试人员对应用程序有很好的了解，甚至可以访问用于执行试验的代码、日志、资源拓扑和配置。
通过渗透测试模拟攻击的测试
不属于组织的 IT 或应用程序团队的安全专家会进行渗透测试。 他们以恶意参与者限定攻击面的方式看待系统。 他们的目标是通过收集信息、分析漏洞和报告结果来找出安全漏洞。
从业者可能需要访问整个组织中的敏感数据。 遵循参与规则，以确保不会滥用访问权限。 请参阅相关信息 中列出的资源。
通过战争游戏练习模拟攻击的测试
在模拟攻击的此方法中，有两个团队：
- 红色团队是试图建模现实世界攻击的对手。 如果成功，您将发现安全设计中的漏洞，并评估其漏洞的爆发半径遏制。
- 蓝色团队是防御攻击的工作负荷团队。 他们测试其检测、响应和修正攻击的能力。 他们验证为保护工作负荷资源而实施的防御措施。
如果作为例程测试进行，战争游戏练习可以提供持续的可见性，并保证您的防御措施按设计工作。 战争游戏练习可能会在工作负荷中跨级别进行测试。
模拟真实攻击场景的常用选择是 Microsoft Defender for Office 365 Attack 模拟训练。
有关详细信息，请参阅攻击模拟训练的见解和报表。
有关红队和蓝队设置的信息，请参阅 Microsoft Cloud Red Teaming。
Power Platform 便利化
Microsoft Sentinel 解决方案 Microsoft Power Platform 允许客户检测各种可疑活动，例如：
- 从未经授权的地理区域执行 Power Apps
- Power Apps 的可疑数据销毁
- Power Apps 批量删除
- 通过 Power Apps 进行的网络钓鱼攻击
- 离职员工的 Power Automate 流活动
- 添加到环境的 Microsoft Power Platform 连接器
- 更新或删除 Microsoft Power Platform 数据丢失防护策略
有关详细信息，请参阅 Microsoft Sentinel 解决方案的 Microsoft Power Platform 概述。
有关产品文档，请参阅 Sentinel Microsoft 中的搜寻功能。
Microsoft Defender for Cloud 为各种技术领域提供漏洞扫描。 有关详细信息，请参阅 使用 Microsoft Defender 漏洞管理启用漏洞扫描。
DevSecOps 的做法将安全测试作为持续和持续改进思维模式的一部分进行集成。 战争游戏演习是一种常见的做法，已融入业务 Microsoft节奏。 有关详细信息，请参阅 DevOps (DevSecOps) 中的安全性。
Azure DevOps 支持第三方工具，这些工具可以作为持续集成/持续部署 (CI/CD) 管道的一部分进行自动化。 有关详细信息，请参阅使用 Azure 启用 DevSecOps 和 GitHub。
相关信息
最新的渗透测试和安全评估可以在 Service Trust Portal 上找到 Microsoft 。
Microsoft 对云服务执行广泛的测试 Microsoft 。 此测试包括渗透测试，结果发布在您的组织的服务信任门户上。 您的组织可以在 Microsoft Power Platform 和 Microsoft Dynamics 365 服务上执行自己的渗透测试。 所有渗透测试都必须跟随 Microsoft Cloud Penetration Testing 参与规则。 请务必记住，在许多情况下， Microsoft Cloud 使用共享基础设施来托管您的资产和属于其他客户的资产。 您必须将所有渗透测试限制为您的资产，并避免对四周的其他客户造成意外后果。
遵循参与规则，以确保不会滥用访问权限。 有关计划和执行模拟攻击的指导，请参阅：
可以在 Azure 中模拟拒绝服务 (DoS) 攻击。 请务必遵循 Azure DDoS 防护模拟测试中制定的策略。
安全清单
请参考整套建议。