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