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

有关建立安全基线的建议

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

SE:01 建立符合性要求、行业标准和平台建议的安全基线。 根据基线定期衡量工作负载体系结构和操作,以随着时间的推移维持或改善安全状况。

本指南介绍有关建立安全基线的建议。 安全基线是一个文档,用于指定组织在一系列领域的最低安全要求和期望。 良好的安全基线可帮助你:

  • 保护数据和系统的安全。
  • 符合法规要求。
  • 最大程度地降低监督风险。
  • 降低违规和后续业务影响的可能性。

应在整个组织中广泛发布安全基线,以便所有利益干系人都了解预期。

本指南提供有关基于内部和外部因素设置安全基线的建议。 内部因素包括业务需求、风险和资产评估。 外部因素包括行业基准和法规标准。

定义

术语 定义
基线 工作负荷必须具有的最低安全级别才能避免被利用。
基准 表示组织希望采用的安全状况的标准。 随着时间的推移,它会进行评估、测量和改进。
控件 对工作负载的技术或操作控制,有助于防止攻击并增加攻击者成本。
法规要求 由行业标准推动的一组业务要求,由法律和当局实施。

关键设计策略

安全基线是一个结构化文档,它定义了工作负载为了提高安全性而必须满足的一组安全标准和功能。 在更成熟的形式中,可以扩展基线,以包括一组用于设置防护措施的策略。

基线应被视为衡量安全状况的标准。 目标应始终是充分实现,同时保持广泛的范围。

安全基线绝不应是临时工作。 行业标准、合规性 (内部或外部) 或法规要求、区域要求和云平台基准是基线main驱动因素。 示例包括 Internet 安全中心 (CIS) 控制、国家标准与技术研究院 (NIST) ,以及平台驱动的标准,例如 Microsoft 云安全基准 (MCSB) 。 所有这些标准都被视为基线的起点。 通过结合业务需求中的安全要求来构建基础。

有关上述资产的链接,请参阅 相关链接

通过获得业务和技术领导者之间的共识来创建基线。 基线不应仅限于技术控制。 它还应包括管理和维护安全状况的操作方面。 因此,基线文档还充当组织对工作负载安全性的投资承诺。 安全基线文档应在组织内广泛分发,以确保了解工作负载的安全状况。

随着工作负载的增长和生态系统的发展,必须使基线与更改保持同步,以确保基本控制仍然有效。

创建基线是一个有条不紊的过程。 下面是有关该过程的一些建议:

  • 资产清单。 确定工作负载资产的利益干系人和这些资产的安全目标。 在资产清单中,按安全要求和关键性进行分类。 有关数据资产的信息,请参阅 有关数据分类的建议

  • 风险评估。 标识与每个资产关联的潜在风险,并确定其优先级。

  • 合规性要求。 对这些资产的任何法规或合规性进行基线,并应用行业最佳做法。

  • 配置标准。 定义并记录每个资产的特定安全配置和设置。 如果可能,请模板化或找到一种可重复的自动化方法,以在整个环境中一致地应用设置。

  • 访问控制和身份验证。 指定基于角色的访问控制 (RBAC) 和多重身份验证 (MFA) 要求。 记录资产级别 刚好足够访问权限 的含义。 始终从最低特权原则开始。

  • 修补程序管理。 对所有资源类型应用最新版本,以增强抵御攻击。

  • 文档和通信。 记录所有配置、策略和过程。 将详细信息传达给相关利益干系人。

  • 强制实施和问责。 建立明确的执行机制和不符合安全基线的后果。 追究个人和团队维护安全标准的责任。

  • 持续监视。 通过可观测性评估安全基线的有效性,并加班改进。

基线的构成

下面是一些应属于基线的常见类别。 以下列表并不详尽。 它旨在概述文档的范围。

法规符合性

工作负荷可能受特定行业细分市场的法规遵从性约束,可能存在一些地理限制,等等。 了解法规规范中给出的要求至关重要,因为这些要求会影响设计选择,在某些情况下必须包含在体系结构中。

基线应包括根据法规要求定期评估工作负载。 利用平台提供的工具,例如 Microsoft Defender for Cloud,这些工具可以识别不符合要求的区域。 请与组织的合规性团队协作,确保满足和维护所有要求。

体系结构组件

基线需要针对工作负荷的main组件提供规范性建议。 这些通常包括网络、标识、计算和数据的技术控制。 引用平台提供的安全基线,并将缺少的控件添加到体系结构。

请参阅 示例

开发过程

基线必须具有有关以下内容的建议:

  • 系统分类。
  • 批准的资源类型集。
  • 跟踪资源。
  • 强制实施使用或配置资源的策略。

开发团队需要清楚地了解安全检查的范围。 例如,威胁建模是确保代码和部署管道中识别潜在威胁的要求。 具体说明管道中的静态检查和漏洞扫描,以及团队需要如何定期执行这些扫描。

有关详细信息,请参阅 有关威胁分析的建议

开发过程还应为各种测试方法及其节奏制定标准。 有关详细信息,请参阅 有关安全测试的建议

Operations

基线必须设置有关使用威胁检测功能的标准,并针对指示实际事件的异常活动发出警报。 威胁检测需要包括工作负载的所有层,包括可从恶意网络访问的所有终结点。

基线应包括有关设置事件响应过程(包括通信和恢复计划)的建议,以及其中哪些流程可以自动执行以加快检测和分析。 有关示例,请参阅 Azure 安全基线概述

事件响应还应包括恢复计划和该计划的要求,例如用于定期执行和保护备份的资源。

使用平台提供的行业标准和建议制定数据泄露计划。 然后,当发现违规时,团队会制定一个全面的计划。 此外,请与组织检查,以查看是否有通过网络保险的保险。

培训

开发和维护安全培训计划,以确保工作负载团队具备相应的技能来支持安全目标和要求。 团队需要基本的安全培训,但应使用组织提供的功能来支持专业角色。 基于角色的安全培训合规性和参与演练是安全基线的一部分。

使用基线

使用基线来推动计划,例如:

  • 为设计决策做好准备。 在开始体系结构设计过程之前,创建并发布安全基线。 确保团队成员尽早充分了解组织的期望,从而避免因缺乏明确性而导致成本高昂的返工。 可以使用基线条件作为组织已承诺的工作负载要求,并针对这些约束设计和验证控制措施。

  • 衡量设计。 根据当前基线对当前决策进行评分。 基线为条件设置实际阈值。 记录延迟或被视为长期可接受的任何偏差。

  • 驱动器改进。 虽然基线设定了可实现的目标,但始终存在差距。 确定积压工作中的差距的优先级,并根据优先级进行修正。

  • 根据基线跟踪进度。 必须根据设定的基线持续监视安全措施。 趋势分析是查看一段时间内安全进度的好方法,可以揭示与基线的一致偏差。 尽可能使用自动化,从各种内部和外部源拉取数据,以解决当前问题并为未来的威胁做好准备。

  • 设置护栏。 在可能的情况下,基线条件必须具有防护措施。 Guardrail 基于内部因素和外部因素强制实施所需的安全配置、技术和操作。 内部因素包括业务需求、风险和资产评估。 外部因素包括基准、法规标准和威胁环境。 护栏有助于最大程度地降低因不合规而无意的监督和惩罚性罚款的风险。

了解自定义选项的Azure Policy,或使用内置计划(如 CIS 基准或 Azure 安全基准)来强制实施安全配置和合规性要求。 请考虑在基线外创建 Azure 策略和计划。

定期评估基线

不断向理想状态逐步提高安全标准,以确保持续降低风险。 定期进行评审,以确保系统是最新的且符合外部影响。 对基线的任何更改都必须是正式的、商定的,并通过适当的更改管理流程发送。

根据新基线衡量系统,并根据修正的相关性和对工作负载的影响来确定修正的优先级。

通过实施审核和监视符合组织标准,确保安全状况不会随着时间的推移而降级。

Azure 简化

Microsoft 云安全基准 (MCSB) 是一个全面的安全最佳做法框架,你可以将其用作安全基线的起点。 将其与其他资源一起使用,为基线提供输入。

有关详细信息,请参阅 Microsoft 云安全基准简介

使用 Microsoft Defender for Cloud (MDC) 法规合规性仪表板跟踪这些基线,并在检测到基线之外的模式时发出警报。 有关详细信息,请参阅自定义法规符合性中的标准集仪表板

有助于建立和改进基线的其他功能:

示例

此逻辑关系图显示了体系结构组件(包括网络、基础结构、终结点、应用程序、数据和标识)的示例安全基线,以演示如何安全地保护常见的 IT 环境。 其他建议指南基于此示例。

显示具有体系结构组件的组织安全基线 IT 环境示例的关系图。

基础结构

常见的 IT 环境,具有具有基本资源的本地层。

Azure 安全服务

Azure 安全服务和功能(按它们保护的资源类型)。

Azure 安全监视服务

Azure 上提供的监视服务超越了简单的监视服务,包括安全信息事件管理 (SIEM) 和安全业务流程自动响应 (SOAR) 解决方案和云Microsoft Defender。

威胁

此层提供了一个建议和提醒,无论使用何种方法或矩阵式 Mitre 攻击矩阵或网络杀伤链,都可以根据组织对威胁的担忧来映射威胁。

组织遵循情况

云采用框架为中心团队提供有关使用建议模板建立基线的指导:

安全清单

请参阅完整的建议集。