云安全基线

网络安全

网络安全包含用于保护 Azure 网络的控制措施，包括保护虚拟网络、建立专用连接、阻止和减少外部攻击以及保护 DNS。

NS-1：建立网络分段边界

安全原则：确保虚拟网络部署符合 GS-2 安全控制中定义的企业分段策略。 任何可能给组织带来较高风险的工作负载都应位于独立的虚拟网络中。 高风险工作负载的示例包括：

•     存储或处理高度敏感数据的应用程序。
  

•     公众或组织外部用户可访问的面向外部网络的应用程序。
  

•     使用不安全的体系结构或包含无法轻松修正的漏洞的应用程序。
  

若要增强企业的分段策略，请通过网络控制限制或监视内部资源之间的流量。 对于明确定义的特定应用程序（例如 3 层应用），可采用高度安全的“默认拒绝，允许例外”方法，包括限制网络流量的端口、协议、源和目标 IP。 如果有多个应用程序和终结点彼此交互，那么阻止流量的扩展性可能并不好，你可能只能监视流量。

NS-2：使用网络控制保护云服务

安全原则：通过为资源建立专用访问点保护云服务。 如果可能，还应禁用或限制来自公共网络的访问。

NS-3：在企业网络边缘部署防火墙

安全原则：部署防火墙，对与外部网络之间的网络流量执行高级筛选。 还可以在内部段之间使用防火墙来支持分段策略。 如果需要，在需要强制网络流量通过网络设备以进行安全控制时，请使用子网的自定义路由来替代系统路由。
至少要阻止已知的不良 IP 地址和高风险协议，例如远程管理（例如 RDP 和 SSH）和 Intranet 协议（例如 SMB 和 Kerberos）。

NS-4：部署入侵检测/入侵防护系统 (IDS/IPS)

安全原则：使用网络入侵检测和入侵防护系统 (IDS/IPS) 检查进出工作负载的网络和有效负载流量。 请确保始终优化 IDS/IPS，为 SIEM 解决方案提供高质量的警报。
有关更深入的主机级别检测和防护功能，请将基于主机的 IDS/IPS 或基于主机的终结点检测和响应 (EDR) 解决方案与网络 ID/IPS 结合使用。

NS-5：部署 DDOS 防护

安全原则：部署分布式拒绝服务 (DDoS) 防护，以保护网络和应用程序免受攻击。

NS-6：部署 Web 应用程序防火墙

安全原则：部署 Web 应用程序防火墙 (WAF) 并配置适当的规则，以保护 Web 应用程序和 API 免受特定于应用程序的攻击。

NS-7：简化网络安全配置

安全原则：管理复杂的网络环境时，请使用工具来简化、集中和增强网络安全管理。

NS-8：检测并禁用不安全的服务和协议

安全原则：在操作系统、应用程序或软件包层检测并禁用不安全的服务和协议。 如果无法禁用不安全的服务和协议，请部署补偿控制。

NS-9：以私密方式连接本地或云网络

安全原则：使用专用连接在不同网络之间进行安全通信，例如在归置环境中的云服务提供商数据中心和本地基础结构之间。

NS-10：确保域名系统 (DNS) 安全性

安全原则：确保域名系统 (DNS) 安全配置能够防范已知风险：

•     在云环境中使用受信任的权威和递归 DNS 服务，以确保客户端（例如操作系统和应用程序）收到正确的解析结果。
  

•     将公共和专用 DNS 解析分开，以便可以将专用网络的 DNS 解析过程与公共网络的 DNS 解析过程隔离开来。
  

•     确保 DNS 安全策略还包括针对常见攻击的缓解措施，例如无关联 DNS、DNS 放大攻击、DNS 中毒和欺骗等。
  

身份管理

标识管理包括用于使用 Azure Active Directory 建立安全标识和访问控制的控制措施，其中包括使用单一登录、强身份验证、用于应用程序的托管标识（和服务主体）、条件访问和帐户异常监视。

IM-1：使用集中式标识和身份验证系统

安全原则：使用集中式标识和身份验证系统来管理组织的标识以及云和非云资源的身份验证。

IM-2：保护标识和身份验证系统

安全原则：在组织的云安全实践中，将标识和身份验证系统的保护视为具有高优先级的实践。 常见的安全控制措施包括：

•     限制特权角色和帐户
  

•     要求对所有特权访问进行强身份验证
  

•     监视和审核高风险活动
  

IM-3：安全且自动地管理应用程序标识

安全原则：使用托管应用程序标识，而不是为应用程序创建用于访问资源和执行代码的人工帐户。 托管应用程序标识提供了一些好处，例如减少凭据的暴露。 自动轮换凭据以确保标识的安全性。

IM-4：对服务器和服务进行身份验证

安全原则：从客户端对远程服务器和服务进行身份验证，以确保连接到受信任的服务器和服务。 最常见的服务器身份验证协议是传输层安全性 (TLS)，其中客户端（通常是浏览器或客户端设备）通过验证服务器的证书是否由受信任的证书颁发机构颁发来验证服务器。
注意：当服务器和客户端相互进行身份验证时，可以使用相互身份验证。

IM-5：使用单一登录(SSO)进行应用程序访问

安全原则：使用单一登录 (SSO) 简化跨云服务和本地环境对资源（包括应用程序和数据）进行身份验证的用户体验。

IM-6：使用强身份验证控制

安全原则：对所有资源访问使用集中式标识和身份验证管理系统强制实施强身份验证控制（强的无密码身份验证或多重身份验证）。 仅基于密码凭据的身份验证被视为旧版身份验证，因为它不安全且无法抵御常见的攻击方法。
部署强身份验证时，请先配置管理员和特权用户，以确保使用最高级别的强身份验证方法，紧接着向所有用户推出适当的强身份验证策略。
注意：如果旧版应用程序和方案需要基于旧版密码的身份验证，请确保遵循密码安全最佳做法，例如复杂性要求。

IM-7：根据条件限制资源访问

安全原则：在零信任访问模型中，显式验证受信任的信号以允许或拒绝用户访问资源。 要验证的信号应包括用户帐户的强身份验证、用户帐户的行为分析、设备可信度、用户或组成员身份、位置等。

IM-8：限制凭据和机密的泄露

安全原则：确保应用程序开发人员安全地处理凭据和机密：

•     避免将凭据和机密嵌入到代码和配置文件中
  

•     使用密钥保管库或安全密钥存储服务来存储凭据和机密
  

•     扫描源代码中的凭据。
  

注意：这通常通过安全的软件开发生命周期 (SDLC) 和 DevOps 安全流程进行管理和实施。

IM-9：保护用户对现有应用程序的访问

安全原则：在混合环境中，如果其中有使用旧式身份验证的本地应用程序或非本机云应用程序，请考虑云访问安全代理 (CASB)、应用程序代理、单一登录 (SSO) 等解决方案来管理对这些应用程序的访问，以获得以下好处：

•     强制执行集中式强身份验证
  

•     监视和控制风险最终用户活动
  

•     监视和修正有风险的旧版应用程序活动
  

•     检测和防止敏感数据传输
  

特权访问

特权访问包括用于保护对你的 Azure 租户和资源的特权访问的控制措施，包括一系列用于避免管理模型、管理帐户和特权访问工作站面临有意和无意的风险的控制措施。

PA-1：隔离和限制高度特权/管理用户

安全原则：确保你将标识所有严重影响业务的帐户。 限制云的控制平面、管理平面和数据/工作负载平面中的特权/管理帐户的数量。

PA-2：避免对用户帐户和权限的长期访问

安全原则：使用实时 (JIT) 机制将特权访问分配到不同的资源层，而不是创建已有的权限。

PA-3：管理标识和权利的生命周期

安全原则：使用自动化流程或技术控制来管理标识和访问生命周期，包括请求、审查、批准、预配和取消预配。

PA-4：定期审查和协调用户访问权限

安全原则：定期审查特权帐户权利。 确保授予帐户的访问权限对控制平面、管理平面和工作负载的管理有效。

PA-5：设置紧急访问

安全原则：设置紧急访问，确保不会在紧急情况下意外锁定关键云基础结构（例如标识和访问管理系统）。
紧急访问帐户应很少使用，如果泄露，会对组织造成巨大损害，但在极少数需要紧急访问帐户的情况下，紧急访问帐户对于组织的可用性又是至关重要的。

PA-6：使用特权访问工作站

安全原则：受保护的独立工作站对于机密角色（如管理员、开发人员和关键服务操作员）的安全性至关重要。

PA-7：遵循 Just Enough Administration（最小特权）原则

安全原则：遵循 Just Enough Administration（最小特权）原则以在精细的级别管理权限。 使用基于角色的访问控制 (RBAC) 等功能，通过角色分配管理资源访问。

PA-8 确定云提供商支持的访问流程

安全原则：建立用于请求和批准供应商支持请求的审批流程和访问路径，并通过安全通道临时访问数据。

数据保护

数据保护涵盖控制静态数据保护、传输中的数据保护以及通过授权访问机制实现的数据保护，包括使用 Azure 中的访问控制、加密、密钥和证书管理发现、分类、保护和监视敏感数据资产。

DP-1：对敏感数据进行发现、分类和标记

安全原则：根据定义的敏感数据范围，建立和维护敏感数据的清单。 使用工具发现、分类和标记范围内的敏感数据。

DP-2：监视针对敏感数据的异常情况和威胁

安全原则：监控敏感数据周围的异常情况，例如未经授权将数据传输到企业可见性和控制范围之外的位置。 这通常涉及监视那些可能意味着未经授权的数据外泄的异常活动（大型或异常传输）。

DP-3：加密传输中的敏感数据

安全原则：使用加密保护传输中的数据免受“带外”攻击（例如流量捕获），确保攻击者无法轻松读取或修改数据。
设置网络边界和服务范围，并在网络内部和外部强制实施传输中数据加密。 虽然这对于专用网络上的流量来说是可选的，但对于外部和公共网络上的流量来说，这是至关重要的。

DP-4：默认启用静态数据加密

安全原则：为了对访问控制进行补充，应使用加密保护静态数据，以免遭受“带外”攻击（例如访问底层存储）。 这有助于确保攻击者无法轻松读取或修改数据。

DP-5：需要时在静态数据加密中使用客户管理的密钥选项

安全原则：根据法规合规性要求，如果需要，请定义需要客户管理的密钥选项的用例和服务范围。 在服务中使用客户管理的密钥启用和实施静态数据加密。

DP-6：使用安全密钥管理流程

安全原则：记录并实现企业加密密钥管理标准、流程和过程，以控制密钥生命周期。 如果需要在服务中使用客户管理的密钥，请使用安全的 Key Vault 服务进行密钥生成、分发和存储。 根据定义的计划以及在密钥停用或泄露时轮换和撤销密钥。

DP-7：使用安全证书管理流程

安全原则：记录并实现企业证书管理标准、流程和过程，其中包括证书生命周期控制和证书策略（如果需要公钥基础结构）。
使用自动化机制确保及时清查、跟踪、监视和续订组织中的关键服务使用的证书，以避免服务中断。

DP-8：确保密钥和证书存储库的安全性

安全原则：确保用于加密密钥和证书生命周期管理的密钥保管库服务的安全性。 通过访问控制、网络安全、日志记录和监视以及备份强化 Key Vault 服务，以确保始终使用最大安全性保护密钥和证书。

资产管理

资产管理包括用于确保 Azure 资源安全可见性和治理的控制措施，包括以下几方面的建议：安全人员的权限、对资产清单的安全访问，以及管理对服务和资源的审批（盘点、跟踪和更正）。

AM-1：跟踪资产清单及其风险

安全原则：通过查询跟踪资产清单并发现所有云资源。 根据资产的服务性质、位置或其他特征，对资产进行标记和分组，以便从逻辑上组织资产。 确保安全组织能够访问不断更新的资产清单。
通过始终集中汇总安全见解和风险，确保安全组织能够监视云资产的风险

AM-2：仅使用已获批准的服务

安全原则：通过审核和限制用户可在环境中预配的服务，确保仅可使用已获批准的云服务。

AM-3：确保资产生命周期管理的安全

安全原则：确保资产的安全属性或配置在资产生命周期内将会一直更新。

AM-4：限制对资产管理的访问

安全原则：限制用户对资产管理功能的访问，避免意外或恶意修改云中的资产。

AM-5：仅在虚拟机中使用已获批准的应用程序

安全原则：通过创建允许列表并阻止未经授权的软件在环境中执行，确保仅已授权的软件才能执行。

日志记录和威胁检测

日志记录和威胁检测涵盖了用于检测 Azure 上的威胁以及启用、收集和存储 Azure 服务的审核日志的控件，包括使用控件启用检测、调查和修正过程，以利用 Azure 服务中的本机威胁检测生成高质量的警报；它还包括使用 Azure Monitor 收集日志，使用 Azure Sentinel 集中进行安全分析、时间同步和日志保留。

LT-1：启用威胁检测功能

安全原则：若要支持威胁检测方案，请监视所有已知资源类型的已知和预期的威胁和异常。 配置警报筛选和分析规则以从日志数据、代理或其他数据源中提取高质量警报，从而减少误报。

LT-2：为标识和访问管理启用威胁检测

安全原则：通过监视用户和应用程序登录和访问异常来检测标识和访问管理威胁。 应针对失败的登录尝试次数过多和使用了订阅中的已弃用帐户等行为模式发出警报。

LT-3：启用日志记录以进行安全调查

安全原则：为云资源启用日志记录，以满足安全事件调查以及安全响应与合规性的要求。

LT-4：启用网络日志记录以进行安全调查

安全原则：为网络服务启用日志记录，以支持与网络相关的事件调查、威胁搜寻和安全警报生成。 网络日志可能包括来自网络服务的日志，例如 IP 筛选、网络和应用程序防火墙、DNS、流量监视等。

LT-5：集中管理和分析安全日志

安全原则：集中记录存储和分析，以实现跨日志数据的关联。 对于每个日志源，请确保已分配数据所有者、访问指南、存储位置、用于处理和访问数据的工具以及数据保留要求。

LT-6：配置日志存储保留期

安全原则：根据合规性、法规和业务要求规划日志保留策略。 在各个日志记录服务中配置日志保留策略，以确保对日志进行正确存档。

LT-7：使用批准的时间同步源

安全原则：为日志记录时间戳使用已获批准的时间同步源，其中包括日期、时间和时区信息。

事件响应

事件响应包括对事件响应生命周期（准备、检测、分析、包含和事后活动）的控制措施，包括使用 Microsoft Defender for Cloud 和 Sentinel 等 Azure 服务自动执行事件响应过程。

IR-1：准备 - 更新事件响应计划和处理过程

安全原则：确保组织遵循行业最佳做法来制定流程和计划，以响应云平台上的安全事件。 请注意共担责任模型以及 IaaS、PaaS 和 SaaS 服务之间的差异。 这将直接影响你与云提供商在事件响应和处理活动方面的协作方式，例如事件通知和会审、证据收集、调查、清除和恢复。

IR-2：准备 - 设置事件通知

安全原则：确保事件响应组织中的正确联系人可以接收来自云服务提供商平台和你的环境的安全警报和事件通知。

IR-3：检测和分析 - 基于高质量警报创建事件

安全原则：确保你有创建高质量警报和衡量警报质量的流程。 这样，你就可以从过去的事件中吸取经验，并为分析人员确定警报的优先级，确保他们不会浪费时间来处理误报。
可以基于过去的事件经验、经验证的社区源以及旨在通过融合和关联各种信号源来生成和清理警报的工具构建高质量警报。

IR-4：检测和分析 - 调查事件

安全原则：确保安全运营团队在调查潜在事件时可以查询和使用不同的数据源，以便全面了解发生的情况。 应收集各种各样的日志，以跟踪整个终止链中潜在攻击者的活动，避免出现盲点。 还应确保收集见解和经验，以供其他分析人员使用和用作将来的历史参考资料。

IR-5：检测和分析 - 确定事件的优先级

安全原则：为安全运营团队提供上下文，帮助他们根据组织的事件响应计划中定义的警报严重性和资产敏感度确定应首先关注哪些事件。

IR-6：遏制、根除和恢复 - 自动执行事件处理

安全原则：自动执行重复性手动任务，以加快响应速度并减轻分析人员的负担。 执行手动任务需要更长的时间，这会导致减慢每个事件的速度，并减少分析人员可以处理的事件数量。 手动任务还会使分析人员更加疲劳，这会增加可导致延迟的人为错误的风险，并降低分析人员专注于复杂任务的工作效率。

IR-7：事后活动 - 吸取教训并保留证据

安全原则：定期和/或在发生重大事件后在组织中吸取教训，以提高未来的事件响应和处理能力。
根据事件的性质，在事件处理标准中定义的期限内保留与事件相关的证据，以供进一步分析或采取法律措施。

态势和漏洞管理

态势和漏洞管理侧重于评估和改进 Azure 安全状况的控制措施，包括漏洞扫描、渗透测试和修正，以及 Azure 资源中的安全配置跟踪、报告和更正。

PV-1：定义并建立安全配置

安全原则：为云中的不同资源类型定义安全配置基线。 或者，使用配置管理工具在资源部署之前或期间自动建立配置基线，以便在部署后默认情况下环境符合要求。

PV-2：审核并强制执行安全配置

安全原则：如果定义的配置基线存在偏差，则持续监视和发出警报。 通过拒绝不合规的配置或部署配置，根据基线配置强制实施所需的配置。

PV-3：定义并建立计算资源的安全配置

安全原则：为计算资源（如 VM 和容器）定义安全配置基线。 使用配置管理工具在计算资源部署之前或期间自动建立配置基线，以便在部署后默认情况下环境符合要求。 或者，使用预配置的映像将所需的配置基线构建到计算资源映像模板中。

PV-4：审核并强制执行计算资源的安全配置

安全原则：如果计算资源中定义的配置基线存在偏差，则持续监视和发出警报。 通过拒绝不合规的配置或在计算资源中部署配置，根据基线配置强制实施所需的配置。

PV-5：执行漏洞评估

安全原则：按固定计划或按需对所有层的云资源执行漏洞评估。 跟踪和比较扫描结果，以验证是否已修正漏洞。 评估应包括所有类型的漏洞，例如 Azure 服务、网络、Web、操作系统、配置错误等中的漏洞。
请注意与漏洞扫描程序使用的特权访问相关的潜在风险。 遵循特权访问安全最佳做法，以保护用于扫描的任何管理帐户。

PV-6：快速自动地修正漏洞

安全原则：快速自动部署补丁和更新，修复云资源中的漏洞。 使用适当的基于风险的方法确定漏洞修复的优先级。 例如，应将较高价值资产中更严重的漏洞作为更高的优先级进行处理。

PV-7：定期执行红队操作

安全原则：模拟真实世界的攻击，以提供组织漏洞的更完整视图。 红队操作和渗透测试补充了传统的漏洞扫描方法，以发现风险。
遵循行业最佳做法来设计、准备和进行此类测试，确保它不会对环境造成损害或破坏。 这应始终包括与相关利益干系人和资源所有者讨论测试范围和约束。

端点安全性

终结点安全保护对终结点检测和响应的控制措施，包括在 Azure 环境中对终结点使用终结点检测和响应 (EDR) 和反恶意软件服务。

ES-1：使用终结点检测和响应 (EDR)

安全原则：为 VM 启用终结点检测和响应 (EDR) 功能，并与 SIEM 和安全操作流程集成。

ES-2：使用新式反恶意软件

安全原则：使用能够实时保护和定期扫描的反恶意软件解决方案。

ES-3：确保反恶意软件和签名已更新

安全原则：确保针对反恶意软件解决方案快速一致地更新反恶意软件签名。

备份和恢复

备份和恢复包括用于确保在不同服务层执行、验证和保护数据和配置备份的控制措施。

BR-1：确保定期执行自动备份

安全原则：确保在资源创建期间或通过现有资源的策略对关键业务资源强制执行备份。

BR-2：保护备份和恢复数据

安全原则：确保备份数据和操作免受数据外泄、数据泄露、勒索软件/恶意软件和恶意内部人员的影响。 应该应用的安全控制包括用户和网络访问控制、数据加密（静态和传输中）。

BR-3：监视器备份

安全原则：确保所有业务关键型可保护资源符合定义的备份策略和标准。

BR-4：定期测试备份

安全原则：定期对备份执行数据恢复测试，以验证备份配置和备份数据的可用性是否满足 RTO（恢复时间目标）和 RPO（恢复点目标）中定义的恢复需求。

DevOps安全性

DevOps 安全性涵盖 DevOps 过程中与安全工程和运营相关的控制，包括在部署阶段之前部署关键安全检查（如静态应用安全测试、漏洞管理），以确保整个 DevOps 流程的安全；它还包括常见主题，例如威胁建模和软件供应安全。

DS-1：执行威胁建模

安全原则：执行威胁建模，以识别潜在威胁并枚举缓解威胁的控制。 确保威胁建模具有以下用途：

•     在生产运行时阶段保护应用程序和服务。
  

•     保护生成工件、基础 CI/CD 管道和其他用于生成、测试和部署的工具环境。 威胁建模至少应包括以下几方面：
  

•     定义应用程序的安全要求。 确保在威胁建模中充分满足这些要求。
  

•     分析应用程序组件、数据连接及其关系。 确保此分析还包括应用程序范围之外的上游和下游连接。
  

•     列出应用程序组件、数据连接以及上游和下游服务可能面临的潜在威胁和攻击途径。
  

•     确定可用于缓解枚举威胁的适用安全控制，并识别可能需要制定额外处理计划的任何控制漏洞（例如安全漏洞）。
  

•     枚举和设计可以缓解所识别漏洞风险的控制。
  

DS-2：确保软件供应链安全性

安全原则：确保企业的 SDLC（软件开发生命周期）或流程包括一组安全控制，用于管理应用程序依赖的内部和第三方软件组件（包括专有软件和开源软件）。 定义限制条件，防止将易受攻击组件或恶意组件集成和部署到环境中。
软件供应链安全控制至少应包括以下几方面：

•     确定开发、生成、集成和部署阶段所需的上游依赖项。
  

•     当上游有可用的修补程序时，对内部和第三方软件组件进行盘存和跟踪来发现已知的漏洞。
  

•     使用静态和动态应用程序测试评估软件组件中的漏洞和恶意软件，以发现未知的漏洞。
  

•     确保使用适当的方法缓解漏洞和恶意软件的威胁。 这可能包括源代码本地修复或上游修复、功能排除和/或应用补偿控制（如果直接缓解不可用）。
  

如果在生产环境中使用第三方闭源组件，则可能无法看见其安全状况。 应考虑其他控制，例如访问控制、网络隔离和终结点安全性，以便在出现与组件相关的恶意活动或漏洞时将影响降至最低。

DS-3：安全 DevOps 基础结构

安全原则：确保 DevOps 基础结构和管道遵循各环境（包括生成、测试和生产阶段）中的最佳安全做法。 这通常包括以下范围的安全控制：

•     用于存储源代码、生成的包和映像、项目生成工件和业务数据的生成工件存储库。
  

•     托管 CI/CD 管道的服务器、服务和工具。
  

•     CI/CD 管道配置。
  

DS-4：将静态应用程序安全测试集成到 DevOps 管道

安全原则：确保静态应用程序安全测试 (SAST) 是 CI/CD 工作流程中限制控制的一部分。 可根据测试结果设置限制，防止易受攻击的包提交到存储库、生成到包中或部署到生产中。

DS-5：将动态应用程序安全测试集成到 DevOps 管道

安全原则：确保动态应用程序安全测试 (DAST) 是 CI/CD 工作流程中限制控制的一部分。 可根据测试结果设置限制，防止漏洞生成到包中或部署到生产中。

DS-6：在整个 DevOps 生命周期内加强工作负载的安全性

安全原则：确保在开发、测试和部署阶段的整个生命周期内保护工作负载。 使用 Azure 安全基准评估可以在默认情况下设置为护栏或在部署阶段之前左移的控制（例如网络安全、标识管理、特权访问等）。 具体而言，请确保在 DevOps 过程中实现以下控制：

•     在 CI/CD 工作流、基础结构管理（基础结构即代码）和测试中使用 Azure 或第三方工具实现自动部署，以减少人为错误和攻击面。
  

•     确保 VM、容器映像和其他生成工件免受恶意操纵。
  

•     在 CI/CD 工作流中进行部署之前，扫描工作负载生成工件（也就是容器映像、依赖项、SAST 和 DAST 扫描）
  

•     在生产环境中部署漏洞评估和威胁检测功能，并在运行时持续使用这些功能。
  

DS-7：在 DevOps 中启用日志记录和监视

安全原则：确保日志记录和监视范围包括 DevOps（和任何其他开发过程）中使用的非生产环境和 CI/CD 工作流元素。 如果未正确监视生产环境，针对这些环境的漏洞和威胁会给生产环境带来巨大的风险。 还应监视 CI/CD 生成、测试和部署工作流中的事件，以识别 CI/CD 工作流作业中的任何偏差。

治理和策略

治理和策略提供的指导可确保使用一致的安全策略和记录在案的治理方法来指导和维持安全保障，包括为不同的云安全功能、统一的技术策略以及支持策略和标准建立角色和责任。

GS-1：使组织角色、责任和职责一致

指导：确保为安全组织中的角色和职责定义并传达清晰的策略。 优先考虑提供涉及安全决策的明确责任，对每个人进行共同职责模式培训，并为技术团队传授保护云的技术。

GS-2：定义并实现企业分段/职责分离策略

指导：建立企业级的策略，将标识、网络、应用程序、订阅、管理组和其他控制措施结合使用以对资产的访问进行分段。
仔细权衡安全分离需求与为需要彼此通信并访问数据的系统启用日常操作的需求。
确保在工作负载中一致地实现分段策略，包括网络安全、标识和访问模型、应用程序权限/访问模型，以及人机过程控制。

GS-3：定义并实现数据保护策略

指导：在 Azure 中建立企业级的数据保护策略：

•     根据企业数据管理标准和法规合规性，定义并应用数据分类和保护标准，从而决定每个级别的数据分类所需的安全控制措施。
  

•     设置与企业分段策略一致的云资源管理层次结构。 企业分段策略还应根据敏感的或业务关键型的数据和系统的位置来确定。
  

•     在云环境中定义和应用适用的零信任原则，以避免基于外围网络位置来实现信任。 请改用设备和用户信任声明来限制对数据和资源的访问。
  

•     跟踪和最大程度地减少整个企业中的敏感数据占用量（存储、传输和处理），以减少攻击面和数据保护成本。 请尽可能考虑工作负载中的单向哈希处理、截断和词汇切分等方法，以避免以原始形式存储和传输敏感数据。
  

•     确保有一个完整的生命周期控制策略为数据和访问密钥提供安全保障。
  

GS-4：定义并实现网络安全策略

指导：建立 Azure 网络安全策略，作为组织访问控制的总体安全策略的一部分。 此策略应包括针对以下元素的记录在案的指南、策略和标准：

•     设计集中/分散网络管理和安全责任模型，以便部署和维护网络资源。
  

•     与企业分段策略一致的虚拟网络分段模型。
  

•     Internet 边缘及入口和出口策略。
  

•     混合云和本地互连策略。
  

•     网络监视和日志记录策略。
  

•     最新的网络安全项目（例如网络关系图、参考网络体系结构）。
  

GS-5：定义并实现安全状况管理策略

指导：建立策略、过程和标准，以确保安全配置管理和漏洞管理在云安全任务中落实就位。

GS-6：定义并实现标识和特权访问策略

指导：建立 Azure 标识和特权访问方法，将其作为组织总体安全访问控制策略的一部分。 此策略应包括针对以下方面的记录在案的指导、策略和标准：

•     集中标识和身份验证系统 (Azure AD) 及其与其他内部和外部标识系统的互连
  

•     特权标识和访问治理（如访问请求、评审和批准）
  

•     紧急（破窗式）情况下的特权帐户
  

•     在不同用例和条件中使用强身份验证（无密码身份验证和多重身份验证）方法
  

•     通过 Azure 门户、CLI 和 API 执行管理操作，保障访问安全。
  

对于未使用企业系统的例外情况，请确保具备足够的安全控制措施以用于标识、身份验证和访问管理以及治理。 企业团队应批准和定期查看这些例外。 这些例外通常出现在以下情况：

•     使用非企业指定的标识和身份验证系统，如基于云的第三方系统（可能引发未知风险）
  

•     特权用户在本地进行了身份验证和/或使用非强身份验证方法
  

GS-7：定义并实现日志记录、威胁检测和事件响应策略

指导：建立日志记录、威胁检测和事件响应策略，以快速检测和修正威胁并满足合规性要求。 安全操作 (SecOps / SOC) 团队应注重实施高质量警报和无缝体验，以便能够专注于威胁，而不是过多关注记录集成和手动步骤。
此策略应包括以下方面的记录在案的策略、过程和标准：

•     安全运营 (SecOps) 组织的角色和职责
  

•     一个明确定义的定期测试的事件响应计划，以及与 NIST 或其他行业框架一致的处理流程。
  

•     与客户、供应商和公开的利益相关方之间的通信和通知计划。
  

•     优先使用扩展检测和响应 (XDR) 功能（如 Azure Defender 功能）来检测各方面的威胁。
  

•     使用 Azure 原生功能（例如 Microsoft Defender for Cloud）的和第三方的平台进行事件处理，例如日志记录和威胁检测、取证以及攻击补救和清除。
  

•     定义主要方案（例如威胁检测、事件响应和合规性），并设置日志捕获和保留以满足方案要求。
  

•     使用 SIEM、原生 Azure 威胁检测功能和其他源来集中查看与威胁相关的关联信息。
  

•     事件后活动，如经验教训和证据保留。
  

GS-8：定义并实现备份和恢复策略

指导：为组织制定 Azure 备份和恢复策略。 此策略应包括以下方面的记录在案的指导、策略和标准：

•     符合你业务复原目标的恢复时间目标 (RTO) 和恢复点目标 (RPO) 定义，以及法规合规性要求。
  

•     用于云和本地的应用程序和基础结构中的冗余设计（包括备份、恢复和复制）。 请考虑在策略中使用区域、区域对、跨区域恢复和非现场存储位置。
  

•     使用数据访问控制、加密和网络安全等控制措施对备份进行保护，以防未经授权的访问和篡改。
  

•     使用备份和恢复来减小出现的威胁（如勒索软件攻击）带来的风险。 并且还可以保护备份和恢复数据本身，使其免受这些攻击。
  

•     出于审核和警报目的，监视备份和恢复数据以及操作。
  

GS-9：定义并实现终结点安全策略

指导：建立云终结点安全策略，其中包括以下方面：

•     将终结点检测和响应以及反恶意软件功能部署到终结点，并与威胁检测和 SIEM 解决方案及安全操作过程集成。
  

•     遵循 Azure 安全基准，以确保其他各方面（如网络安全性、状态漏洞管理、标识和特权访问，以及日志记录和威胁检测）与终结点相关的安全设置已到位，从而能为终结点提供深度防御保护。
  

•     为生产环境中的终结点安全性设置优先级，但要确保非生产环境（如 DevOps 过程中使用的测试和生成环境）也受到保护和监视，因为这些环境也可用于将恶意软件和漏洞引入到生产环境中。
  

GS-10：定义并实现 DevOps 安全策略

指导：将安全控制强制作为组织 DevOps 工程和操作标准的一部分。 根据组织中的企业和云安全标准，定义安全目标、控制要求和工具规范。
建议将 DevOps 用作你组织中的基本操作模型，因为这样可以在整个 CI/CD 工作流中使用不同类型的自动化操作（例如基础结构即代码预配和 SAST 和 DAST 自动扫描）来快速识别和修复漏洞。 通过这种“左移”方法，还可以更多地了解部署管道中的情况并在其中强制执行一致的安全检查，从而提前将安全护栏有效地部署到环境中，以避免在将工作负载部署到生产环境中时出现最后一分钟的安全意外。
当将安全控制向左转移到预先部署阶段时，请实现安全护栏以确保在整个 DevOps 过程中部署和执行控制。 此技术可能包含 Azure ARM 模板，可用于定义 IaC（基础结构即代码）中的护栏、资源预配和 Azure Policy，从而审核和限制可在环境中预配的服务或配置。
对于工作负载的运行时安全控制，请遵循 Azure 安全基准，设计和实现有效的控制，如标识和特权访问、网络安全、终结点安全性，以及工作负载应用程序和服务中的数据保护。

参考：Azure 安全基准 | Microsoft Docs