安全测试的体系结构策略

适用于此 Azure 良好架构框架安全检查清单建议：

严格的测试是良好的安全设计的基础。 测试也是检测系统中漏洞的主动方法。

从多个角度通过节奏和验证建立测试严谨性。 包括由内而外视角，可测试平台和基础设施，还包括由外而内评估，可像外部攻击者一样测试系统。

本文中的关键策略建立在OE:09 测试的架构策略中描述的基础测试实践之上。 首先查看该文章。 本指南提供有关测试工作负荷安全状况的建议。 实现这些测试方法，以提高工作负荷对攻击的抵抗力，并保持资源的机密性、完整性和可用性。

术语

与安全专家协作设计测试

参与测试规划。 通常，组织集中执行此任务。 确保团队参与该设计过程，确保安全保证与应用程序的功能保持一致。

构建“假设已遭入侵”思维模式。 设计测试用例，假设系统受到攻击，攻击者正在环境中运行。 模拟测试，以反映贴近真实的攻击场景，例如验证在已被攻陷的应用虚拟机中对横向移动的遏制效果。 这样，就可以发现潜在的漏洞，并相应地确定测试的优先级。

共享体系结构关系图、威胁模型和其他相关文档，以有意义地测试工作负荷。

根据威胁建模和关键流确定测试的优先级

威胁建模是识别工作负荷中潜在威胁和漏洞的关键做法。 使用威胁模型中的严重性分级来确定测试工作的优先级和范围。 针对最关键流程的最严重威胁，应获得最全面的防护覆盖。

覆盖工作负载的全部攻击面。 评估标识、应用程序代码、基础结构控制、第三方组件、库和服务，以及审批工作流和访问评审等自动化和人工流程。

从标识和访问控制开始，因为遭到入侵的标识会绕过大多数下游防御。 然后验证网络边界，最后验证应用程序层防御。

确定处理身份验证、敏感数据或财务事务的流的优先级。 对于每个关键流，请在威胁模型中识别具有最高严重性分级的威胁。 创建风险驱动测试用例，将每个威胁映射到旨在缓解威胁的控件。

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

风险：过时的威胁模型可能会导致测试工作不协调。 定期更新威胁模型，以反映工作负载和不断变化的威胁格局的变化。

利用第三方专业知识

内部团队可以有盲点。 外部专家和众包安全研究人员会以攻击者的视角审视你的工作负载。 让专业专家从对手的角度测试工作负荷，并提供有关最新攻击技术和趋势的见解。

避免向工作负载授予过于宽松的访问权限。 仅向外部测试人员提供其特定参与所需的访问权限。 黑盒渗透测试不需要代码或内部访问，而白盒评审需要源代码、设计文档或日志。

在启动计划之前，评估团队是否有能力对外部报告进行会审。 然后，建立 Bug 赏金计划或社区报告安全问题的机制。 对每个已报告的问题进行分类评估，将已确认的漏洞反馈到威胁模型中，并添加测试用例以防止任何回归。

测试符合性控制并生成审核就绪证据

合规性不是一次性评审。 将每个监管控制项都视为可测试的要求，以便始终拥有供审计人员查验的最新证据。

确定工作负荷必须满足的法规。 将每个法规控制映射到特定的测试用例。 安排测试按固定周期定期运行，并在每次上线前运行。 将测试输出存储在可审核的位置，以便你可以按需生成证据。

权衡： 监管控制测试可能会拖慢运营。 例如，预部署测试会添加管道延迟。 运行这些操作也增加了成本。 确定对具有最高审核和风险影响的控件的测试的优先级。

风险：审核证据本身很敏感。 如果没有完整性保护和访问日志记录，证据存储将同时成为攻击目标和潜在的合规性冲突。

保护测试资产

测试资产本身就构成攻击面。 保护其机密性、完整性和可用性，以便测试不会公开敏感信息或打开新的攻击途径。

• 使用不包含个人身份信息（PII）或生产数据的清理或合成数据。
• 仅根据需要保留测试数据并安全地将其删除。
• 确认跨区域的测试环境中强制实施跨界数据驻留规则。
• 生成专用测试凭据、API 密钥和证书。 使用自己的访问策略将它们存储在单独的密钥保管库实例中。
• 设置隔离的测试环境，以镜像生产安全控制，例如网络安全组（NSG）、基于角色的访问控制（RBAC）策略、防火墙和数据丢失防护（DLP）规则。 采用与生产环境相同的分段指导原则。 有关详细信息，请参阅 分段策略的建议。

对测试资产执行定期漏洞扫描

按照与生产资产相同的频率对测试资产进行漏洞扫描，包括测试代码、基础设施即代码（IaC）、容器和 VM 镜像、代码库以及流水线。 使用与开发和部署工作流集成的工具自动执行这些检查。

为工作负载建立持续测试机制

将安全测试视为一项持续活动，使工作负荷的安全状况保持最新状态，因为威胁、代码和配置不断演变。 按计划运行测试，使更改不会带来安全风险或回归。 随时准备好组织安全验证，以及安全事件触发的测试。 以下各节介绍需要规划的节奏。

例程测试

例程测试为工作负荷的安全状况设置基线。 定期执行这些操作，作为标准操作过程的一部分，并满足合规性要求。 你可以以不同的节奏运行各种测试，但关键是定期和按计划执行这些测试。

使测试套件多样化，以验证标识、数据存储和传输和通信通道的保证。 如果在生命周期的相同阶段发现了新问题，就添加新的测试用例。

不要只依赖于自动测试。 使用手动测试来查找只有人类专业知识才能捕获的漏洞，以及针对未知风险的探索性工作。

即兴测试

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

即兴测试的好处是为真实事件做好准备。 这些测试可以作为推动用户验收测试（UAT）的手段。

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

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

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

风险： 未知的风险。 在没有既定流程或工具的情况下，即兴测试可能是一次性的。 但主要风险是业务节奏的潜在中断。 评估这些风险相对于好处。

安全事件测试

使用能够从源头检测安全事件原因的测试。 解决这些安全漏洞，防止事件定期发生。

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

跨攻击面验证安全控制

使用各种测试方法获取完整的覆盖范围，并发现安全控制、配置错误以及可观测性和检测方面的弱点。 本部分中介绍的大多数测试都可以作为例程测试运行。 但是，可重复性可能会产生成本并导致中断。 仔细考虑这些权衡。

测试加密控件。 加密失败时不会有任何提示。 数据看起来受到保护，直到一次数据泄露暴露出并非如此。

• 验证是否强制实施加密，而不仅仅是配置加密。
• 在每个密钥轮换、证书续订和基础结构更改后重新测试。

测试网络控制。 网络边界是实施网络分段策略的地方。

• 在发生任何网络拓扑更改后对其进行测试。
• 验证拒绝默认规则是否保留，以及允许的流量路径是否与体系结构意向匹配。

测试应用程序代码。 应用程序层防御是攻击者到达数据之前的最后一个边界。

• 验证部署的应用程序是否抵制常见的攻击模式，而不是仅在生成时扫描源代码。
• 在源代码上运行应用程序安全测试（AST）技术，以确认安全编码做法，并捕获运行时错误，例如内存损坏和特权问题。 有关详细信息，请参阅 社区链接。

模拟基于身份的攻击并验证检测能力

基于标识的攻击是最常见的初始攻击途径。 模拟这些攻击，以验证你的身份控制措施是否有效，以及你的监控是否能够捕获这些事件。

访问控制是第一道防线。 在每次角色或策略变更后，以及按照自动计划，都要对它们进行测试。 模拟常见的攻击模式，并确认控件强制实施最低特权并抵制绕过尝试。

设计测试时，请考虑以下攻击模式：

• 绕过授权
• 令牌被盗和重播
• 跨账户或服务的横向移动
• 特权提升

检查每个控件的两个方面：

• 积极案例：授权用户成功。
• 负面情况：阻止和记录未经授权的尝试。

测试威胁检测和警报

不触发警报的检测几乎没有价值。 在每个安全控制验证过程中测试监视和警报，并验证用于检测攻击的机制是否按预期工作。

运行攻击的端到端模拟，然后确认检测管道的每个阶段：

• 验证登录尝试、权限更改和令牌操作等安全事件是否记录了足够的详细信息。
• 验证安全信息和事件管理（SIEM）平台或安全操作仪表板是否关联相关事件。
• 建立警报服务级别协议（SLA），并测试警报在该时间范围内可操作和浮出水面。
• 验证日志不能被非管理帐户篡改或删除。
• 确认每个模拟攻击的检测机制都会触发。 例如，如果模拟具有有效流量模式的分布式拒绝服务 （DDoS） 攻击，请确认速率限制检测并缓解它。

对于成熟的工作负载，应将治理护栏验证作为例行测试。 有意引入不安全的配置，并验证管道是否检测和响应。 确认 Azure Policy 或着陆区约束实施了预期的保护措施。 平台或安全团队通常执行此测试，而不是工作负荷团队。

使用基于对手的测试加强防御

使用通过模拟真实世界攻击来支持威胁狩猎的测试。 这些测试可以识别潜在的威胁参与者、其技术和对工作负荷构成威胁的利用。 使攻击尽可能现实化。 使用在威胁建模过程中识别的所有潜在威胁向量。

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

• 将这些攻击作为常规测试的一部分时，可以使用外部透视来检查工作负荷，并确保防御能够承受攻击。
• 根据他们学到的教训，团队将提升他们的知识和技能水平。 该团队提高了情况意识，并可以自我评估其应对事件的准备情况。

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

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

黑盒和白盒测试

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

风险：这两种类型之间的差异是前期成本。 白盒测试在了解系统所需的时间和精力方面可能耗费很大。 在某些情况下，白盒测试要求你购买专用工具。 黑盒测试不需要准备时间，但它可能效果不佳。 可能需要付出额外的努力来发现问题。 这是一种时间投资的权衡。

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

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

权衡：渗透测试是即兴进行的，可能由于中断和资金投入而付出高昂代价，因为渗透测试通常是第三方从业者提供的收费服务。

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

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

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

在此模拟攻击方法中，两个团队参与：

• 红队充当对手，试图模拟现实世界的攻击。 如果他们成功入侵，就是在你的安全设计中找到了漏洞，并评估他们入侵所产生的影响范围。

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

如果你定期开展这些测试，攻防演练就能让你持续了解防御状况，并确信你的防御措施能够按预期发挥作用。 战争模拟演习可能会测试您的工作负载的不同层级。

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

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

有关 red-team 和 blue-team 设置的信息，请参阅 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 和 GitHub 启用 DevSecOps - Azure DevOps。

相关链接

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

• 渗透测试参与规则

• 渗透测试

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

社区链接

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

渗透测试执行标准（PTES） 提供有关建立基线所需的常见方案和活动的指南。

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

安全清单

请参阅完整的建议集。