你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

安全测试建议

  • 项目

适用于此 Azure Well-Architected 框架安全清单建议：

SE：11 建立一个全面的测试方案，将预防安全问题、验证威胁防护实现和测试威胁检测机制的方法结合起来。

严格的测试是良好安全设计的基础。 测试是一种战术性的验证形式，可确保控件按预期工作。 测试也是检测系统中漏洞的主动方法。

从多个角度通过节奏和验证建立测试严谨性。 应包括测试平台和基础结构的由内而外视点，以及像外部攻击者一样测试系统的外部评估。

本指南提供有关测试工作负载安全状况的建议。 实施这些测试方法以提高工作负载对攻击的抵抗力，并维护资源的机密性、完整性和可用性。

定义

术语 定义
应用程序安全测试 (AST) Microsoft 安全开发生命周期 (SDL) 技术，它使用白盒和黑盒测试方法来检查代码中的安全漏洞。
黑盒测试 一种测试方法，用于在不了解系统内部的情况下验证外部可见的应用程序行为。
蓝色团队 一支在战争游戏演习中抵御红队攻击的球队。
渗透测试 一种测试方法，它使用道德黑客技术来验证系统的安全防御。
红色团队 一个扮演对手角色并试图在战争游戏演习中破解系统的团队。
安全开发生命周期 (SDL) Microsoft 提供的一组支持安全保证和合规性要求的做法。
软件开发生命周期 (SDLC) 用于开发软件系统的多阶段系统过程。
白盒测试 一种测试方法，其中从业者知道代码的结构。

关键设计策略

测试是一种不可谈判的策略，尤其是对于安全性而言。 它允许在安全问题被利用之前主动发现和解决这些问题，并验证你实现的安全控制是否按设计运行。

测试范围必须包括应用程序、基础结构以及自动化和人工流程。

注意

本指南区分测试和事件响应。 尽管测试是一种检测机制，在理想情况下可以修复生产前的问题，但不应将其与作为事件响应一部分进行的修正或调查混淆。 事件 响应建议中介绍了从安全事件中恢复的方面。

SDL 包括几种类型的测试，这些测试可捕获代码中的漏洞、验证运行时组件，并使用道德黑客攻击来测试系统的安全复原能力。 SDL 是一项关键左移活动。 应尽可能早地在开发过程中运行静态代码分析和基础结构即代码扫描等测试， (IaC) 。

参与测试规划。 工作负荷团队可能不会设计测试用例。 该任务通常集中在企业中，或由外部安全专家完成。 工作负荷团队应参与该设计过程，以确保安全保证与应用程序的功能集成。

像攻击者一样思考。 设计测试用例时，假设系统受到攻击。 这样，就可以发现潜在的漏洞，并相应地确定测试的优先级。

使用可重复的过程以结构化方式运行测试。 围绕节奏、测试类型、驾驶因素和预期结果构建测试严谨性。

为作业使用正确的工具。 使用配置为处理工作负载的工具。 如果没有工具，请购买该工具。 不要生成它。 安全工具具有高度专业化，构建自己的工具可能会带来风险。 利用中央 SecOps 团队提供的专业知识和工具，如果工作负载团队没有这种专业知识，则利用外部手段。

设置单独的环境。 测试可归类为破坏性或非破坏性。 非破坏性测试不是侵入性的。 它们表示存在问题，但不会为了修正问题而更改功能。 破坏性测试是侵入性的，可能会通过从数据库中删除数据来损害功能。

在生产环境中进行测试可提供最好的信息，但会导致最多的中断。 在生产环境中，你往往只执行非破坏性测试。 非生产环境中的测试通常较少中断，但可能无法以对安全非常重要的方式准确表示生产环境的配置。

如果使用 IaC 和自动化进行部署，请考虑是否可以创建生产环境的独立克隆进行测试。 如果你有一个连续的常规测试过程，我们建议使用专用环境。

始终评估测试结果。 如果不使用结果来确定操作的优先级并上游改进，则测试是一种浪费。 记录发现的安全准则，包括最佳做法。 捕获结果和修正计划的文档向团队介绍攻击者可能试图破坏安全的各种方式。 定期为开发人员、管理员和测试人员进行安全培训。

设计测试计划时，请考虑以下问题：

  • 你预计测试的运行频率是多少，它如何影响你的环境？

  • 应运行哪些不同的测试类型？

你预计测试的运行频率如何？

定期测试工作负荷，以确保更改不会引入安全风险，并且没有任何回归。 团队还必须准备好响应可能随时进行的组织安全验证。 还可以运行一些测试来响应安全事件。 以下部分提供有关测试频率的建议。

例程测试

常规测试是定期进行的，这是标准操作过程的一部分，以满足合规性要求。 各种测试可能以不同的节奏运行，但关键是定期按计划进行。

应将这些测试集成到 SDLC 中，因为它们在每个阶段提供深度防御。 使测试套件多样化，以验证标识、数据存储和传输以及信道的保证。 在生命周期的不同点执行相同的测试，以确保没有任何回归。 例程测试有助于建立初始基准。 然而，这只是一个起点。 在生命周期的相同点发现新问题时，需要添加新的测试用例。 测试也会随着重复而改进。

在每个阶段，这些测试都应验证添加或删除的代码或已更改的配置设置，以检测这些更改的安全影响。 应通过自动化提高测试的效能，并与同行评审相平衡。

请考虑在自动化管道或计划测试运行过程中运行安全测试。 越早发现安全问题，就越容易找到导致安全问题的代码或配置更改。

不要仅依赖于自动测试。 使用手动测试来检测只有人类专业知识才能捕获的漏洞。 手动测试适用于探索性用例和查找未知风险。

即兴测试

即兴测试提供安全防御的时间点验证。 此时可能影响工作负荷的安全警报会触发这些测试。 如果警报升级为紧急情况，组织授权可能需要暂停和测试思维模式来验证防御策略的有效性。

临时测试的好处是为实际事件做好准备。 这些测试可以是 (UAT) 执行用户验收测试的强制函数。

安全团队可能会审核所有工作负载，并根据需要运行这些测试。 作为工作负载所有者，你需要与安全团队协作。 与安全团队协商足够的提前期，以便做好准备。 确认并传达给团队和利益干系人，这些中断是必要的。

在其他情况下，可能需要运行测试，并针对潜在威胁报告系统的安全状态。

权衡：由于临时测试是破坏性事件，因此预期会重新确定任务的优先级，这可能会延迟其他计划的工作。

风险：存在未知风险。 在没有建立流程或工具的情况下，临时测试可能是一次性工作。 但主要风险是业务节奏的潜在中断。 你需要根据权益评估这些风险。

安全事件测试

有一些测试可以检测安全事件的源原因。 必须解决这些安全漏洞，以确保事件不会重复发生。

事件还会通过发现现有差距，随着时间的推移改进测试用例。 团队应应用从事件中吸取的教训，并定期纳入改进。

有哪些不同类型的测试？

可以按技术和测试方法对测试进行分类。 将这些类别和方法合并到这些类别中，以获得完整的覆盖范围。

通过添加多个测试和测试类型，可以发现：

  • 安全控制或补偿控制方面的差距。

  • 配置错误。

  • 可观测性和检测方法方面的差距。

良好的威胁建模练习可以指向关键区域，以确保测试覆盖率和频率。 有关威胁建模的建议，请参阅 保护开发生命周期的建议。

这些部分中介绍的大多数测试都可以作为常规测试运行。 但是，在某些情况下，可重复性可能会产生成本并导致中断。 请仔细考虑这些权衡。

验证技术堆栈的测试

下面是测试类型的一些示例及其重点领域。 此列表并不详尽。 测试整个堆栈，包括应用程序堆栈、前端、后端、API、数据库和任何外部集成。

  • 数据安全：测试数据加密和访问控制的有效性，以确保数据受到适当的保护，防止未经授权的访问和篡改。

  • 网络和连接性：测试防火墙，确保它们仅允许预期、允许且安全的流量流向工作负载。

  • 应用程序：通过应用程序安全测试 (AST) 技术测试源代码，以确保遵循安全编码做法并捕获内存损坏和特权问题等运行时错误。 有关详细信息，请参阅这些 社区链接。

  • 标识：评估角色分配和条件检查是否按预期工作。

测试方法

测试方法有很多观点。 建议通过模拟真实世界攻击来启用威胁搜寻的测试。 他们可以识别潜在威胁参与者、其技术和对工作负载构成威胁的漏洞。 使攻击尽可能现实。 使用在威胁建模期间识别的所有潜在威胁向量。

下面是通过实际攻击进行测试的一些优势：

  • 将这些攻击作为例行测试的一部分时，可以使用外部视角来检查工作负载，并确保防御能够抵御攻击。

  • 根据他们学到的经验，团队会提升他们的知识和技能水平。 团队可提高态势感知能力，并可以自我评估应对事件的准备情况。

风险：一般情况下，测试可能会影响性能。 如果破坏性测试删除或损坏数据，可能会出现业务连续性问题。 还存在与信息泄露相关的风险：确保保持数据的机密性。 完成测试后，确保数据的完整性。

模拟测试的一些示例包括黑盒和白盒测试、渗透测试和战争游戏练习。

黑盒和白盒测试

这些测试类型提供两种不同的视角。 在黑盒测试中，系统的内部不可见。 在白盒测试中，测试人员对应用程序有很好的了解，甚至可以访问用于执行试验的代码、日志、资源拓扑和配置。

风险：这两种类型之间的差异是前期成本。 白盒测试在了解系统所花费的时间方面可能很昂贵。 在某些情况下，白盒测试需要你购买专用工具。 黑盒测试不需要增加时间，但它可能不太有效。 可能需要付出额外的努力来发现问题。 现在是投资权衡的时候了。

通过渗透测试模拟攻击的测试

不属于组织的 IT 或应用程序团队的安全专家会进行渗透测试或 渗透测试。 他们以恶意参与者限定攻击面的方式看待系统。 他们的目标是通过收集信息、分析漏洞和报告结果来找出安全漏洞。

权衡：渗透测试是临时进行的，在中断和货币投资方面可能很昂贵，因为渗透测试通常是第三方从业者的付费产品。

风险：渗透测试练习可能会影响运行时环境，并可能中断正常流量的可用性。

从业者可能需要访问整个组织中的敏感数据。 遵循参与规则，确保不会滥用访问权限。 请参阅 相关链接中列出的资源。

通过战争游戏练习模拟攻击的测试

在模拟攻击的此方法中，有两个团队：

  • 红队是试图模拟现实世界攻击的对手。 如果成功，你将发现安全设计中的差距，并评估其漏洞的爆发半径。

  • 蓝色团队是防御攻击的工作负荷团队。 他们测试其检测、响应和修正攻击的能力。 它们验证为保护工作负载资源而实施的防御措施。

如果作为常规测试进行，战争游戏演习可以提供持续的可见性，并保证你的防御工作按设计工作。 战争游戏练习可能会在工作负载中跨级别进行测试。

模拟真实攻击方案的常用选择是Microsoft Defender for Office 365攻击模拟训练。

有关详细信息，请参阅攻击模拟训练的见解和报表。

有关红队和蓝队设置的信息，请参阅 Microsoft Cloud Red Teaming。

Azure 便利化

Microsoft Sentinel 是一种本机控件，它将安全信息事件管理 (SIEM) 和安全业务流程自动响应 (SOAR) 功能相结合。 它分析来自各种连接来源的事件和日志。 Microsoft Sentinel 根据数据源及其警报创建事件并执行威胁分析，以便进行早期检测。 通过智能分析和查询，可以主动搜寻安全问题。 如果发生事件，可以自动执行工作流。 此外，使用工作簿模板，可以通过可视化效果快速获取见解。

有关产品文档，请参阅 Microsoft Sentinel 中的搜寻功能。

Microsoft Defender for Cloud 提供针对各种技术领域的漏洞扫描。 有关详细信息，请参阅使用 Microsoft Defender 漏洞管理 - Microsoft Defender for Cloud 启用漏洞扫描。

DevSecOps 的做法将安全测试作为持续和持续改进思维模式的一部分进行集成。 战争游戏练习是一种常见做法，它已集成到 Microsoft 的业务节奏中。 有关详细信息，请参阅 DevOps (DevSecOps) 中的安全性 。

Azure DevOps 支持第三方工具，这些工具可以作为持续集成/持续部署管道的一部分进行自动化。 有关详细信息，请参阅 使用 Azure 启用 DevSecOps 和 GitHub - Azure DevOps。

遵循参与规则，确保不会滥用访问权限。 有关规划和执行模拟攻击的指导，请参阅以下文章：

可以在 Azure 中模拟拒绝服务 (DoS) 攻击。 请务必遵循 Azure DDoS 防护模拟测试中制定的策略。

应用程序安全测试：工具、类型和最佳做法 - GitHub 资源 介绍了可以测试应用程序的生成时和运行时防御的测试方法的类型。

渗透测试执行标准 (PTES) 提供有关常见场景以及建立基线所需活动的准则。

OWASP 前十名 |OWASP Foundation 为涵盖常见威胁的应用程序和测试用例提供安全最佳做法。

安全清单

请参阅完整的建议集。

安全清单