通过

资产管理

通过持续库存发现、服务审批强制执行和安全生命周期控制，组织能够保持对云基础结构的全面可见性和治理。 与传统的定期资产审核不同，新式云环境需要实时资产跟踪、跨混合基础结构的自动发现以及策略驱动的治理来解决快速资源预配、影子 IT 激增和动态多云部署，攻击者通过不受监视的资源和未经授权的服务利用这些部署。 实施可靠的资产管理功能的组织保持准确的安全可见性并强制实施批准的配置，而忽视这些控制的组织将面临未知的攻击面暴露、影子 IT 扩散和无效的事件响应。

下面是资产管理安全域的三大核心支柱。

资产清单和可见性： 使用自动化发现工具维护跨混合和多云环境的所有云资源的全面、持续更新的清单。 部署系统标记策略并跟踪资产风险、安全状况和配置合规性，确保安全组织能够了解云、本地和边缘基础结构的潜在风险。

相关控件：

服务审批和应用程序控制： 通过基于策略的控制、自适应应用程序控件和更改跟踪来强制实施批准的服务和应用程序。 防止未经授权的服务预配和软件执行，同时保持已批准的业务需求的作灵活性。

相关控件：

资产生命周期和访问管理： 使用基于角色的访问控制、条件访问策略和资源保护机制（限制资产管理功能并防止未经授权的修改）通过适当的访问控制和治理来实现安全资产生命周期管理。

相关控件：

AM-1：跟踪资产库存及其风险

安全原则

使用自动发现和分类功能维护所有资产的全面、持续更新的清单。 确保安全组织能够实时了解所有环境中的资产配置、风险状况和业务关键性，以支持有效的威胁检测、事件响应和合规性验证。

待缓解风险

在没有综合资产清单和持续风险监视的情况下运行的组织将面临严重的安全盲点，这些盲点可防止有效的威胁检测、事件响应和安全状况管理。 没有系统的资产跟踪：

  • 未知攻击面暴露： 安全团队无法保护他们不知道的资产，允许攻击者利用不受监视的资源并通过影子 IT 基础结构建立持久访问。
  • 不完整的安全覆盖范围： 安全控制、监视和合规性策略不能应用于未发现的资产，从而在保护和检测功能方面造成差距。
  • 无效的事件响应优先级： 缺少资产关键性分类和业务影响评估可以防止适当的事件优先级，导致资源分配不当，并延迟了对关键威胁的响应。
  • 合规性和审核失败： 监管框架要求对资产进行全面的清单盘点，以便于安全控制、变更管理和数据保护的验证。如果缺乏准确的资产清单，将会导致合规性违规和审核失败。
  • 过时的安全风险评估： 安全组织在未持续更新的资产清单（包括配置详细信息、软件版本和漏洞状态）的情况下无法评估出现的威胁。
  • 资源浪费和孤立资产： 组织为放弃的资源、开发环境和测试系统付费，这些系统不提供业务价值，同时增加攻击面和运营成本。

资产可见性不足会通过防止准确了解必须保护的内容来破坏每个安全控制。

MITRE ATT&CK

  • 初始访问（TA0001）：利用面向公众的应用程序（T1190），以针对在资产清单过程中安全团队未能发现的未知或不受监视的面向互联网的资源。
  • 持久性（TA0003）：创建帐户（T1136），在集中式安全可见性和管理之外在影子 IT 资源和不受监视的订阅中建立持久访问。
  • 防御逃避（TA0005）：未使用/不支持的云区域（T1535）在资产清单和安全监视覆盖范围不包括的云区域中部署恶意基础结构。

AM-1.1：实现全面的资产清单和发现

准确而全面的资产清单构成了有效安全作的基础，可实现跨云环境的威胁检测、事件响应、合规性报告和风险管理。 如果没有完全的可见性，安全团队无法保护他们不知道的资产，从而为对手留下利用的盲点。 自动发现和分类功能可确保随着基础结构缩放和演变，库存保持最新状态，从而消除了在几天内过时的手动跟踪。

部署 Azure Resource Graph 和 Microsoft Defender for Cloud 资产清单 ，以保持具有自动化发现和分类功能的所有 Azure 资源的全面、持续更新的清单。

Azure Resource Graph 查询功能：

  • 跨订阅资产发现： 使用 Kusto 查询语言（KQL）跨多个订阅和管理组查询所有资源，以聚合完整的资产清单以执行安全作和事件响应。
  • 资产关键性查询： 通过业务关键性标记查询资源，标识需要增强的安全监视和更快的事件响应优先级的关键资产。
  • 影子 IT 检测查询： 识别缺少必要的所有权、成本中心或符合性范围标签的资源，这些标签表明资源未经批准的预配绕过了安全审查和治理流程。
  • 孤立资源识别： 查询未附加的磁盘、未使用的公共 IP 地址、空闲虚拟机和被遗弃的存储帐户，这些资源在没有业务价值时消耗预算，应考虑停用。
  • 更改历史记录和审核跟踪： 跟踪资源创建、修改和删除事件，以维护历史资产清单，识别未经授权的更改和配置偏移，以便进行合规性报告。
  • 合规性和策略状态查询： 跨订阅查询策略符合性状态，确定需要按法规框架或安全基线分组的修正的非合规资源。

Microsoft Defender for Cloud 资产清单：

  • 安全状况可见性： 综合资产清单，其中包含集成到集中式仪表板中的安全建议、漏洞评估和合规性状态。
  • 资源运行状况监视： 使用自动刷新和更新实时监视资源运行状况、安全警报和配置偏移检测。
  • Defender 计划覆盖范围： 跟踪受特定 Defender 计划保护的资源，包括 Defender for Servers、存储、容器和数据库。
  • 法规符合性映射： 资产清单自动映射到法规合规性框架，包括 PCI-DSS、HIPAA 和 ISO 27001，其中显示了覆盖范围和差距。
  • 与安全工作流集成： 将资产清单数据导出到 Microsoft Sentinel、逻辑应用和外部 SIEM 平台，实现安全自动化和关联。

AM-1.2：将清单扩展到混合和多云环境

混合和多云环境分散跨管理控制台和安全工具的资产可见性，创建非托管资源存在漏洞和策略冲突的盲点。 将分布式基础结构投影到统一的控制平面时，无论托管位置如何，都可以实现一致的治理、安全监视和合规性报告。 这种统一的方法消除了管理每个环境的单独清单所固有的操作复杂性和安全漏洞。

通过这些功能统一混合和多云资产清单：

将 Azure Arc 部署到 Azure 资源管理器中，以投影本地、边缘和多云资源，从而跨混合环境实现统一的资产清单、治理和安全管理。

已启用 Azure Arc 的资产发现：

  • 启用 Azure Arc 的服务器： 将托管于 Azure 之外的 Windows 和 Linux 物理服务器和虚拟机（本地、VMware、Hyper-V、AWS EC2、Google 计算引擎）作为本地 Azure 资源投射到 Azure 中（启用 Azure Arc 的服务器）。
  • 已启用 Azure Arc 的 Kubernetes： 连接和管理运行在任何位置的 Kubernetes 群集，包括本地、AWS EKS、Google GKE 和其他云提供商，并使用统一治理和 GitOps 部署（已启用 Azure Arc 的 Kubernetes）。
  • 已启用 Azure Arc 的 SQL 托管实例： 使用统一清单、生命周期管理和安全治理（已启用 Azure Arc 的 SQL 托管实例）管理在本地或其他云中运行的已启用 Azure Arc 的 SQL 托管实例部署。
  • 已启用 Azure Arc 的 PostgreSQL： 使用统一清单、生命周期管理和安全治理（已启用 Azure Arc 的 PostgreSQL）管理在本地或其他云中运行的已启用 Azure Arc 的 PostgreSQL 部署。
  • 已启用 Azure Arc 的 VMware vSphere： 通过 Azure 发现和管理 VMware 虚拟机，启用自助服务虚拟机操作，并结合 Azure 治理和策略（已启用 Azure Arc 的 VMware vSphere）。
  • 多云连接器： 将 AWS 和 Google Cloud 帐户连接到 Azure Arc，发现用于统一多云清单（多云连接器）的 EC2 实例、S3 存储桶和其他云资源。

统一混合资产管理：

  • Azure Resource Graph 集成： 使用 Azure Resource Graph 查询已启用 Azure Arc 的资源以及本机 Azure 资源，在所有环境中提供单窗格清单。
  • 跨云进行一致的标记： 无论托管位置如何，将 Azure 资源标记应用于启用 Arc 的服务器和资源，实现一致的分类和组织分类法。
  • 混合资产分组： 使用管理组、资源组和订阅组织混合资源，将治理层次结构应用于非 Azure 基础结构。
  • 跨云依赖项映射： 可视化 Azure、本地、AWS 和 Google Cloud 资源之间的依赖关系，确定连接要求和迁移候选项。
  • 集中式资产报告： 在单个仪表板中生成统一资产清单报告，聚合 Azure 原生、已启用 Arc 的服务器、Kubernetes 群集和多云资源。

Azure Arc 安全性和治理：

  • Microsoft Defender for Cloud 集成： 将 Defender for Cloud 安全状况评估、漏洞扫描和威胁防护扩展到已启用 Arc 的服务器和 Kubernetes 群集。
  • Azure Policy 强制实施： 将 Azure Policy 应用于混合和多云资源，确保所有环境的安全基线、符合性要求和配置标准一致。
  • Azure Monitor 集成： 将已启用 Arc 的资源中的日志、指标和性能数据收集到 Azure Monitor 和 Log Analytics 中，以便进行统一的监视和警报。
  • Azure 更新管理器： 使用 Azure 更新管理器 集中管理已启用 Arc 的 Windows 和 Linux 服务器，确保跨混合基础结构进行一致的安全修补。
  • Microsoft Sentinel 关联： 将启用 Arc 的服务器发送的安全事件流式传输到 Microsoft Sentinel，并将混合基础设施的安全信号与云原生 Azure 安全遥测关联起来。

终结点和迁移发现集成：

Microsoft Intune 设备清单集成：

  • 终结点资产发现： 使用 Microsoft Intune 将资产清单扩展到企业管理的终结点，包括 Windows、macOS、iOS 和 Android 设备，从而提供跨云基础结构和终结点设备的统一可见性。
  • 设备符合性状态： 跟踪设备的符合性状态，同时通过云资源清单识别需要修正的非合规终结点，在授予对敏感资源的访问权限之前进行修正。
  • 条件访问集成： 将 Intune 设备符合性与 Azure 资源访问策略相关联，确保只有合规的托管设备才能访问资产管理接口和敏感数据。
  • 硬件和软件清单： 从托管终结点收集硬件规范、已安装的应用程序和安全配置，以补充云资源清单，以便获得全面的资产可见性。

Azure Migrate 发现集成：

  • 预云评估： 使用 Azure Migrate 进行无代理探测，发现并识别本地 VMware、Hyper-V、物理服务器以及 AWS/GCP 虚拟机的迁移候选项和依赖项，为 Azure 载入做好准备。
  • 依赖项映射： 可视化跨本地基础结构的应用程序依赖项和网络连接模式，告知迁移规划和 Azure 资源预配策略。
  • 性能和大小调整数据： 从本地工作负荷收集性能指标和利用率数据，从而为 Azure 迁移提供适当的大小建议和成本优化。
  • 迁移就绪情况评估： 评估迁移准备情况，包括兼容性检查、成本估算和安全注意事项，在云采用之前建立基线清单。

标记策略：

使用 Azure 资源标记 实施系统资源标记策略，按业务上下文、关键性、所有权和合规性要求以逻辑方式组织资产。

战略标记框架：

  • 业务关键性标记： 按业务影响级别（关键、高、中、低）对资源进行分类，可实现基于风险的安全优先级和事件响应。
  • 数据分类标记： 基于数据敏感度级别（公共、内部、机密、高度机密）标记资源，以支持数据保护策略和合规性要求。
  • 环境标记： 明确分离生产、过渡、开发和测试环境，防止在安全作期间意外影响生产系统。
  • 成本中心和所有权标记： 业务单位、成本中心和技术所有者分配可在安全事件期间实现责任制、成本分摊和快速通知利益相关者。
  • 符合性范围标记： 根据特定的法规要求（PCI-DSS、HIPAA、SOX、GDPR）标记资源，从而触发适当的安全控制和审核过程。

标签管理和治理：

  • Azure Policy 标记强制实施： 自动标记要求策略可防止在没有强制性标记的情况下创建资源，并确保整个组织之间的一致分类。
  • 标记继承： 资源组和订阅级标记由子资源自动继承，确保一致的分类，而无需手动标记负担。
  • 标记值验证： Azure Policy 针对已批准的列表验证标记值，防止拼写错误并确保整个组织的标准化分类。
  • 标记审核和修正： 定期审核标记符合性，并基于资源特征和安全评估添加缺失标记的自动修正工作流。

AM-1.3：授予安全组织清单访问权限

安全团队需要全面了解所有资产，以检测威胁、调查事件和衡量风险状况，而无需依赖于基础结构团队进行访问或手动数据收集。 适当的只读权限可以开启安全操作，同时防止特权升级或操作中断。 集中式访问管理可确保安全组织保持可见性，即使云环境的发展和组织结构也不断演变。

通过以下权限配置安全团队资产可见性：

  • 确保安全组织具有使用 安全读取者角色、Azure RBAC 和管理组范围来查看和监视资产库存的适当权限，以确保全面可见性，而不会导致权限过剩。

安全组织权限策略：

  • 安全读取者角色分配： 在管理组或订阅范围内授予安全读取者角色，使安全团队无需修改功能即可查看资源、安全警报和建议。
  • 管理组范围： 在根管理组级别应用权限，以便根据组织结构将企业范围的安全可见性或范围应用于特定业务部门。
  • Defender for Cloud 访问： 确保安全团队有权访问 Defender for Cloud 资产清单、安全建议和合规性仪表板，以便集中风险可见性。
  • Azure Resource Graph 查询访问： 为自定义资产发现查询和安全研究提供 对 Azure Resource Graph 资源管理器 的安全分析师访问权限，而无需资源级权限。
  • Log Analytics 读取者访问权限： 向安全团队授予 Log Analytics 读取者权限，以便安全日志分析和威胁搜寻，而无需访问修改工作区配置。

操作安全集成：

  • 自动库存共享： 将资产清单导出到安全信息和事件管理（SIEM）平台和安全业务流程工具，以便关联和自动化。
  • 持续监视集成： 将资产清单与 Microsoft Sentinel 集成，以便实时安全监视、威胁检测和自动响应与资产相关的风险。
  • 安全指标和报告： 为安全领导提供仪表板和报表，其中显示了资产增长、安全态势趋势以及跨云环境的风险暴露。

AM-1.4：监视资产风险和安全状况

当威胁和配置在动态云环境中持续更改时，静态资产清单提供不足的安全可见性。 持续风险监视将清单数据转换为可作的安全智能，在攻击者利用这些漏洞之前识别新兴的漏洞、配置偏差和合规性违规。 自动评估使安全团队能够根据实际风险确定修正优先级，而不是在利用后对事件做出反应。

通过这些功能建立持续资产风险监视：

  • 使用 Microsoft Defender for Cloud Secure Score、 Azure 安全基线和 漏洞评估 来跟踪资产安全状况和新兴风险，实现持续风险监视。

持续风险评估：

  • 安全分数监控：跟踪 Microsoft Defender for Cloud Secure Score 在跨订阅和管理组中的表现，以衡量整体安全状况和控制有效性。
  • 安全建议跟踪： 根据资产严重性、潜在影响和威胁智能按优先级监视安全建议。
  • 漏洞评估集成： 使用 Qualys 或 Microsoft Defender 漏洞管理（具有基于风险的修正优先级）对虚拟机进行自动漏洞扫描。
  • 合规性仪表板监视： 通过差距分析和修正跟踪受 PCI-DSS、HIPAA、ISO 27001 和其他框架约束的资产的法规合规性状态。
  • 配置偏移检测： 自动检测安全配置更改和策略冲突，以及针对未经授权的修改或不符合配置的警报。

威胁情报和风险关联：

  • Microsoft 威胁情报集成： 自动将资产清单与 Microsoft 威胁情报关联，以识别可能被已知威胁行为者或活动攻击的资源。
  • 安全警报聚合： 集中聚合来自 Defender for Cloud、Microsoft Sentinel 和 Microsoft Defender XDR 的安全警报，并将其映射到特定资产，以便全面掌握风险状况。
  • 攻击面分析： 基于漏洞状态和威胁环境持续分析面向 Internet 的资产、开放端口和网络暴露，风险评分。

实现示例

一个跨 Azure、本地数据中心和 AWS 运营混合云基础结构的组织发现，他们无法全面了解其完整的资产清单，从而带来合规性风险和未知的安全风险。

挑战： 组织在多个环境中难以实现分散的资产可见性。 部署在 Azure 中的云资源、区域数据中心内的本地服务器和 AWS 工作负载存在于单独的管理孤岛中，没有统一的清单。 安全团队对资产关键性、漏洞状态和合规性状况缺乏全面可见性。 监管审核确定了 PCI-DSS 和 HIPAA 合规性所需的资产跟踪差距。 影子 IT 激增创造了不受监视的资源消耗预算，同时使组织面临安全风险。

解决方案方法：

  • 统一库存平台： 已部署 Azure Resource Graph 查询，以发现多个订阅中的所有 Azure 资源，并实现每日自动库存更新。 实现了已启用 Azure Arc 的服务器载入 500 多个本地 Windows 和 Linux 服务器以及 200 多个 AWS EC2 实例，可实现统一清单管理。 为 AWS 集成配置了多云连接器，用于发现 EC2 实例、S3 存储桶和 RDS 数据库，并将其投影到 Azure Resource Graph 中，以便获得合并的资产可见性。
  • 资产分类和管理： 使用 Azure Policy 实施强制标记策略，在所有资源（包括已启用 Arc 的服务器）进行预配前，需标记业务关键性、数据分类、成本中心和符合性范围。 制定了业务关键性分类标准，其中，“业务关键型”用于业务关键系统，“高级”用于敏感数据存储，“中级”用于内部应用程序，“低级”用于开发环境。
  • 安全可见性和监控： 在根管理组级别为安全运营中心（SOC）团队授予安全阅读者角色，配置了 Microsoft Defender for Cloud 资产清单，以实现跨 Azure 和启用 Arc 的资源的企业级可见性。 在所有 Azure 虚拟机和 Arc 启用的虚拟机上，使用 Microsoft Defender 漏洞管理部署漏洞评估，并实现自动修复工作流。 将 Azure Policy 强制实施扩展到已启用 Arc 的服务器，这些服务器应用安全基线、加密要求和诊断日志记录策略。
  • 执行报告： 为安全领导创建了 Azure 工作簿仪表板，其中显示了 Azure、本地和 AWS 环境中的资产清单、安全功能分数、漏洞状态和合规性状况，以及自动化的日常更新和趋势分析。

结果： 通过对以前未受监视的系统进行全面的漏洞扫描，实现了跨 Azure、本地和 AWS 实现的资产可见性。 合规性审核准备时间大幅减少，同时识别和停用孤立资源，从而节省大量云支出。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： CM-8、CM-8（1）、CM-8（2）、CM-8（3）、PM-5、RA-2
  • PCI-DSS v4： 2.4.1、2.4.2、12.5.2
  • CIS 控件 v8.1： 1.1、1.2、1.3、1.4、2.1
  • NIST CSF v2.0： ID.AM-1、ID.AM-2、ID.AM-4
  • ISO 27001：2022： A.5.9、A.8.1、A.8.2
  • SOC 2： CC6.1、CC7.2

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

Azure Policy： 请参阅 Azure 内置策略定义：AM-2。

安全原则

强制实施服务审批流程，通过基于策略的控制和监控来限制用户可以预配哪些云服务。 确保在生产使用之前，所有已部署的服务都经过安全审查、合规性验证和适当的配置强化，防止影子 IT 和未经授权的服务蔓延。

待缓解风险

不受控制的云服务预配通过影子 IT、配置漏洞和合规性违规造成重大安全风险。 未经服务批准的情况下强制执行：

  • 影子 IT 安全漏洞： 未经批准的服务绕过安全评审过程，在没有安全监视的情况下运行，并且缺少适当的配置强化，从而创建可利用的漏洞。
  • 合规性框架冲突： 未经审查的服务可能无法满足数据保护、审核日志记录或加密的法规要求，从而导致合规性失败和潜在的监管制裁。
  • 攻击面增加： 每个新服务类型使用独特的安全配置、API 和集成点扩展攻击面，安全团队缺乏适当的安全专业知识。
  • 成本溢出和预算浪费： 不受控制的服务预配会导致重复的功能、未使用的资源和意外费用破坏财务治理和预算可预测性。
  • 作复杂性： 服务类型的激增增加了作复杂性、培训要求和支持负担，同时分散了安全监视和事件响应功能。
  • 数据管理失败： 未经批准的存储服务和数据库绕过数据分类策略、保留要求和加密标准，从而造成数据保护差距。

缺乏强制执行服务审批导致不受控制的技术扩散，破坏了安全性、合规性和运营效率。

MITRE ATT&CK

  • 初始访问（TA0001）：使用合法用户凭据的有效帐户（T1078）使用安全配置来预配未经批准的服务，攻击者利用这些配置进行初始访问。
  • 资源开发（TA0042）：获取基础结构（T1583）预配未经批准的云服务，以建立攻击基础结构、命令和控制功能或绕过安全评审过程的恶意工作负荷。
  • 防御逃避（TA0005）：未使用/不支持的云区域（T1535）在安全监视范围之外的未经批准的云区域中部署恶意基础结构。

AM-2.1：实施 Azure Policy 服务限制

不受限制的服务预配使用户能够部署不受支持的、不安全或不合规的云服务，这些云服务绕过安全审查并将漏洞引入生产环境。 未经批准的服务会扩展攻击面，可能导致安全设置配置不当、软件未更新或出现攻击者可利用的未监控接入点。 强制实施批准的服务目录可确保只有经过安全验证、运营支持的服务才能生产，同时在开发环境中保持受控创新。

通过以下强制机制控制服务预配：

  • 部署包含拒绝策略和审核策略的 Azure Policy，以将服务预配限制为已批准的 Azure 服务类型，但已批准的创新项目和开发环境除外。

服务限制策略框架：

  • 允许的资源类型策略： 定义已批准的 Azure 服务（包括虚拟机、存储帐户、数据库和平台服务）的综合允许资源类型策略。
  • 拒绝的资源类型策略： 出于安全问题、合规性限制或操作限制而禁止的服务的显式拒绝策略，并有明确的理由记录。
  • 区域限制策略： 根据数据驻留要求、合规性授权和作支持功能，将资源预配限制为已批准的 Azure 区域。
  • SKU 和层限制： 将资源 SKU 和服务层限制为已批准的配置，确保成本控制和安全功能可用性。
  • 预览服务控件： 在生产环境中限制或禁止预览版和 beta 版服务，同时允许在开发订阅中控制使用情况进行评估。

策略范围和强制执行：

  • 管理组策略分配： 在管理组级别应用服务限制策略，并在企业范围内强制执行，同时继承到所有子订阅。
  • 基于环境的豁免： 为开发和沙盒订阅授予策略豁免，从而在维护生产环境控制的同时实现创新。
  • 策略强制模式： 配置生产环境拒绝操作以防止不合规的资源预配，或者配置审核模式以便可见性和符合性报告。
  • 异常请求工作流： 通过安全审查、限时审批和补偿控制，建立合法业务需求的正式例外请求流程。

Azure Arc 混合策略强制实施：

  • 已启用 Arc 的服务器的策略扩展： 将 Azure Policy 来宾配置应用于已启用 Arc 的服务器，以强制实施混合基础结构的安全基线、软件限制和符合性要求。
  • Kubernetes 策略强制实施： 在已启用 Arc 的 Kubernetes 群集上部署用于 Kubernetes 的 Azure Policy，控制跨多云环境的 Pod 安全性、映像注册表和资源配置。
  • 跨云服务审批： 使用 Azure Arc 和 Azure Policy 在多云资源上强制实施批准的服务模式，防止未批准的 AWS 服务或 Google Cloud 配置。
  • 混合合规性报告： 统一策略合规性仪表板，展示了本地 Azure 和 Arc 启用的服务器，以及具有已批准服务目录的多云资源的合规性状态。

AM-2.2：监视和警报未批准的服务使用情况

策略执行可防止未经批准的资源预配，但检测现有不合规资源并监控策略违规，使安全团队能够识别异常、响应违规，并维护持续监控合规性。 实时检测将反应性合规性审核转换为主动安全作，从而快速响应通过未经批准的服务引入的潜在安全风险。 自动警报可确保安全团队在攻击者发现和利用配置不当的资源之前解决违规问题。

通过以下监视功能检测和响应未经批准的服务：

  • 实施 Azure Monitor 警报规则和 Microsoft Defender for Cloud 建议，以检测未经批准的服务预配尝试和现有的不合规资源。

未授权服务检测：

  • Azure 活动日志监视： 监视 Azure 活动日志，以便将资源创建事件与已批准的服务目录进行比较，并实时针对策略冲突发出警报。
  • Azure Policy 合规性仪表板： 跨订阅跟踪策略符合性状态，标识需要修正或解除授权的不符合状态的资源。
  • Defender for Cloud 建议： 利用 Defender for Cloud 安全建议，确定需要配置更改的资源或服务在安全基线之外运行。
  • 自定义警报规则： 为需要安全团队通知和调查的特定服务类型或配置模式创建自定义 Azure Monitor 警报规则。

警报和响应工作流：

  • Microsoft Teams 和电子邮件通知： 在预配未批准服务或检测到策略违规时，自动通知安全运营和资源所有者。
  • Azure 逻辑应用集成： 触发安全评审票证、利益干系人通知和上报流程的自动化工作流，用于策略违规修正。
  • Microsoft Sentinel 集成： 将 Azure Policy 合规性数据和服务预配事件流式传输到 Microsoft Sentinel，以便进行安全关联和威胁检测。

实现示例

在 HIPAA 合规性要求下运行的医疗保健组织面临在没有适当安全验证的情况下部署的未经授权的云服务的挑战，从而产生合规性风险和审核结果。

挑战： 开发人员在没有正式安全评估的情况下部署了 Azure 服务，导致 HIPAA 审核发现识别出未经批准的服务在处理受保护的健康信息（PHI）。 组织缺乏集中式服务审批流程和技术实施机制，防止未经授权的部署。 合规性团队发现 Azure 认知服务和 Azure OpenAI 服务处理 PHI，而无需完成所需的风险评估。 影子 IT 的激增导致了合规性差距，部署的 40 多种服务类型中缺乏记录的安全控制或加密验证。

解决方案方法：

  • 治理框架： 已建立的服务验证委员会由安全、合规性和工程领导组成，通过强制安全评估、合规性验证和数据分类分析来评审新的服务请求。 已创建服务目录，其中记录了具有安全基线、加密要求、合规性控制以及已批准的用例的服务。
  • 技术强制： 在管理组级别部署允许的资源类型策略，将预配限制为已批准的计算（虚拟机、Azure Kubernetes 服务、容器实例）、存储（Blob 存储、Azure 文件存储、Azure 文件、队列存储）、数据库（Azure SQL 数据库、Cosmos DB、Azure Database for PostgreSQL）和网络（虚拟网络、网络安全组、应用程序网关、Azure 防火墙）服务。 实施区域限制策略，将部署限制为符合 HIPAA 数据驻留要求的已批准的 Azure 区域。 配置的 SKU 限制策略阻止在开发和测试订阅中使用高级层和超高性能 SKU。
  • 持续监视： 使用 Azure 逻辑应用工作流创建用于策略冲突尝试的 Azure Monitor 警报规则，创建 ServiceNow 事件并通知资源所有者和安全运营团队。 为创新沙盒订阅授予策略豁免，允许评估不受生产限制的新服务。
  • 开发人员赋能： 已发布的基础架构即代码模板，包括 Terraform 模块和 Bicep 模板，这些模板带有预先应用的安全配置，可用于加速合规资源的部署。

结果： 完整服务审批符合性通过 Azure Policy 实现，防止未经授权的部署，从而保护 PHI 不被泄露。 HIPAA 审核结果消除，同时通过可预测的审批流程保持开发人员工作效率。

严重性级别

应该有。

控件映射

  • NIST SP 800-53 Rev.5： CM-7、CM-7（1）、CM-7（2）、SA-3、SA-8
  • PCI-DSS v4： 1.2.6、2.2.7、6.3.2
  • CIS 控件 v8.1： 2.3、2.7、4.1
  • NIST CSF v2.0： ID.AM-3、PR。IP-1、PR。PT-3
  • ISO 27001：2022： A.5.23、A.8.9、A.8.19
  • SOC 2： CC6.1、CC6.6、CC7.2

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

Azure Policy： 请参阅 Azure 内置策略定义：AM-3。

安全原则

实现从配置到报废的安全资产生命周期管理，使用安全默认配置、变更控制流程和系统化处置程序。 确保所有生命周期阶段包括安全验证、审核日志记录和审批工作流，以便进行高影响修改，以防止安全降级和维护合规性。

待缓解风险

资产生命周期管理不足会在整个资源预配、修改和解除授权过程中造成安全漏洞。 没有适当的生命周期控制：

  • 不安全的资源预配： 在没有安全强化、加密、监视或网络控制的情况下部署的资源从一开始就处于易受攻击状态，从而创建即时攻击面。
  • 配置偏移和未经授权的更改： 不受控制的资源修改会绕过安全评审过程，导致配置不当、合规性冲突和安全控制降级。
  • 无人管理的资源积累：资源在项目结束或团队解散后依然存在，消耗预算，同时由于缺乏监控，使用过时的凭证和未更新的安全补丁，创建了潜在的攻击风险。
  • 未完成停用： 资源删除不当会导致数据残留、存储帐户、网络配置和标识分配造成数据泄露风险和合规性冲突。
  • 通过生命周期差距提升特权： 攻击者利用生命周期管理弱点来预配恶意资源、修改安全配置或在检测尝试后保持持久性。
  • 审核线索差距： 生命周期文档不足可防止法医调查、合规性演示以及涉及资源更改的安全事件的根本原因分析。

糟糕的生命周期管理允许安全漏洞在整个作生命周期内从资源创建中持续存在。

MITRE ATT&CK

  • 持久性（TA0003）：创建或修改系统进程（T1543），利用弱生命周期控制在资源预配期间部署持久后门，而无需进行安全审查。
  • 特权提升（TA0004）：滥用提升控制机制（T1548）在生命周期更改期间修改资源权限和访问控制，以获得未经授权的提升权限。
  • 防御逃避（TA0005）：通过在资源修改过程中禁用安全监控和日志记录来削弱防御（T1562），绕过检测功能。

AM-3.1：实现安全资源预配

自一开始未经过安全强化部署的资源，会立即创建持久存在的漏洞，因为在部署后再改造安全控制不仅在技术上非常复杂，而且在操作上会造成破坏性影响。 默认情况下，通过基础结构即代码进行安全预配可确保自动应用一致的保护配置，从而防止攻击者利用的配置差距。 自动安全验证在部署前阻止不安全配置进入生产环境，将安全措施从被动修复转变为主动预防。

通过以下机制建立安全默认预配：

  • 使用安全强化的配置部署 Azure 部署堆栈、 Azure 资源管理器模板和 Terraform ，确保从一开始就使用适当的安全控制部署资源。

默认情况下，安全预配：

  • 用于治理的 Azure 部署堆栈： 使用 Azure 部署堆栈 将 Azure Policy 分配、RBAC 角色分配和资源模板合并到受管理捆绑包中。 部署堆栈创建拒绝分配（DenyDelete 或 DenyWriteAndDelete），保护托管资源和治理项目免受未经授权的修改或删除，同时通过基础结构即代码启用受控更新。
  • 基础设施即代码安全性： 已默认启用加密的 ARM 模板和 Terraform 模块经过加固，配置了诊断日志记录，应用了网络安全组，专用终端已默认部署。
  • 策略驱动的预配： Azure Policy 在资源创建期间自动应用安全配置，包括加密要求、诊断设置和标记授权。
  • 专用网络默认值： 默认情况下，使用专用终结点和服务终结点部署的资源会禁用公共 Internet 访问，除非明确要求和批准。
  • 安全扫描集成： 在部署之前，使用 Checkov、Terrascan 或 Microsoft Defender for Cloud DevOps Security 等工具自动扫描基础结构即代码模板。

预配审批工作流：

  • Azure DevOps 审批入口： 要求安全团队批准涉及敏感数据、面向 Internet 的资源或高特权配置的生产部署。
  • 更改顾问委员会评审： 影响重大的资源预配将接受变更顾问委员会审查，包括安全性、合规性和运营利益干系人评估。
  • 成本和安全阈值触发器： 适用于超出成本阈值的资源或具有安全敏感度且需要领导授权的情况下的自动审批要求触发器。

AM-3.2：实现资产生命周期更改控制

不受控制的资源修改会绕过安全评审过程，使对手能够通过逃避检测的配置更改禁用保护控制、提升特权或保持持久性。 更改控制通过安全验证、审核线索和自动强制实施将临时修改转换为受管理工作流，从而防止未经授权的更改。 持续配置监视检测到偏离已批准的基线，确保资源在其运营生命周期内保持安全态势，而不是随时间推移而下降。

通过这些更改控制机制控制资源修改：

  • 使用 Azure Policy、 Azure 资源锁和 Azure 活动日志监视 建立更改控制过程，以控制资源修改并防止未经授权的安全配置更改。

更改控制和治理：

  • Azure 资源锁： 在生产资源上部署 CanNotDelete 或 ReadOnly 锁，防止意外删除或修改，而无需显式锁定删除审批，需要记录的更改请求和安全评审。
  • Azure Policy 拒绝效果： 这些策略旨在阻止安全配置的退化，包括禁用加密、删除诊断设置、将资源暴露给公共互联网，或未经批准修改网络安全组规则。
  • 更改跟踪和审核： Azure 活动日志与 Microsoft Sentinel 集成，通过安全关联、异常检测和针对高风险配置更改自动警报跟踪所有资源修改。
  • 配置偏移检测： Azure Policy 来宾配置检测未经授权的配置更改，并触发生产系统的自动修正工作流或安全团队通知。
  • 身份生命周期管理： 使用 Microsoft Entra ID Governance 实现自动化身份生命周期工作流，管理服务主体和托管身份的预配、访问审查和取消预配，并与资产生命周期阶段相一致。

AM-3.3：实现系统资源退役

资源注销不当会导致数据残留、孤立配置和过时凭据，即使在项目结束后，也会造成长期安全隐患和合规性问题。 正式停用程序确保使用合适的数据处理、访问撤销以及审核跟踪保留来彻底移除资源，防止对废弃资产的未经授权访问。 自动检测遗弃资源可以消除被遗忘基础设施的积累，这些基础设施在耗费预算的同时，还创造了未受监控的攻击面。

通过以下过程执行安全资源解除授权：

  • 使用 Azure 资源管理器、 Azure Policy 和数据 保留策略 建立正式解除授权过程，确保通过适当的数据处理和审核线索保留来保护资源删除。

安全退役程序：

  • 数据备份和保留： 在资源删除之前验证备份完成和保留策略符合性，确保业务连续性和法规合规性要求。
  • 访问吊销： 在删除之前，删除与资源关联的所有角色分配、托管标识、服务主体和密钥保管库访问策略。
  • 网络依赖项验证： 验证没有活动网络依赖项、对等关系或 DNS 记录，防止安全资源删除。
  • 合规性和法律保留检查： 在删除之前，验证是否存在法律保留、法规保留要求或正在进行的调查需要保留资源。
  • 软删除启用： 利用密钥保管库、存储帐户和数据库软删除功能，为意外删除提供恢复窗口。

孤立的资源检测：

  • Azure 顾问成本建议： 利用 Azure 顾问识别未附加的磁盘、空闲虚拟机和未使用的公共 IP 地址等未使用的资源。
  • Azure Resource Graph 查询： 基于活动模式、上次访问时间和资源利用率指标发现孤立资源的自定义查询。
  • 自动化退役工作流： Azure Automation runbooks 识别这些孤立的开发资源，并在经过可配置的空闲期后执行退役，同时通知资源所有者。

实现示例

在 Azure 和本地基础架构中拥有 3,000 多个云资源的组织面临生命周期管理方面的挑战，包括由配置不当的资源引发的安全事件，以及因孤立无援的基础架构导致的过高成本。

挑战： 开发团队部署的资源没有标准化的安全配置，导致 25% 新部署缺少加密或日志记录要求。 生产资源缺少删除保护，并发生三起重大事件，其中严重资源被意外删除，导致业务中断。 组织维护了 400 多个孤立资源，包括未附加的磁盘、未使用的公共 IP 地址和每年耗资 120,000 美元的空闲虚拟机。 更改管理流程依赖于手动评审无法检测安全配置偏移。 资源退役缺少正式过程，导致数据删除不完整和残留的访问权限。

解决方案方法：

  • 预配标准化： 部署了具有安全强化资源模板的 Azure 部署堆栈，确保为所有配置了 DenyDelete 拒绝分配的生产资源激活了加密、配置专用终结点和诊断日志记录。 已发布的基础结构即代码模板和模块，其中预应用了安全基线，防止预配时配置错误。
  • 更改保护： 在所有生产资源组上实现 Azure 资源锁，防止意外删除和未经授权的对关键基础结构的修改。 已建立的变更控制板审查高影响修改，包括标识提供者更改、网络安全组修改和管理特权分配。 部署的 Azure Policy 拒绝影响可防止安全配置回归，包括阻止公共 Internet 访问启用、加密禁用和诊断日志记录删除的策略。
  • 退役治理： 在 Azure DevOps 中部署的退役清单，要求在删除生产资源之前进行数据备份验证、访问撤销确认和合规团队审批。 为提供 90 天恢复时段的密钥保管库、存储帐户和数据库实现了软删除策略。
  • 孤立资源管理： 设计 Azure 自动化 Runbook，每周扫描孤立资源，识别并淘汰未附加的磁盘、未使用的公共 IP 和空闲虚拟机。在这些资源空闲30天后，会通知所有者。

结果： 资源配置合规性通过部署堆栈的帮助自动安全配置大幅提升，同时资源锁避免了意外删除。 通过清理孤立资源，显著地节省了基础设施成本；同时，配置偏移事件由于 Azure Policy 的拒绝效应而减少。

严重性级别

应该有。

控件映射

  • NIST SP 800-53 Rev.5： CM-3、CM-3（1）、CM-4、SA-3、SA-4（10）
  • PCI-DSS v4： 6.3.1、6.4.1、6.4.2、12.3.3
  • CIS 控件 v8.1： 4.1、4.2、15.1、15.2
  • NIST CSF v2.0： PR.IP-1、PR.IP-3、PR.MA-1
  • ISO 27001：2022： A.5.31、A.8.1、A.8.32
  • SOC 2： CC6.1、CC6.6、CC8.1

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

安全原则

通过基于角色的访问控制、条件访问策略和资源保护机制强制实施对资产管理功能的最低特权访问。 根据业务理由限制用户创建、修改或删除资产的能力，要求进行强身份验证、使用安全的工作站，以及对影响生产基础设施的管理操作时提供限时提升的访问权限，以防止未经授权的操作。

待缓解风险

过度访问资产管理功能会导致意外资源删除、恶意基础结构修改和特权升级攻击的风险。 没有适当的访问控制：

  • 意外的生产影响： 过度特权的用户意外删除生产资源、修改关键网络配置或禁用安全监视，从而导致业务中断。
  • 内部威胁放大： 具有过度资产管理权限的恶意内部成员可以删除审核日志、泄露数据、部署恶意基础结构或破坏系统。
  • 特权提升路径： 攻击者通过获取具有资产管理权限的帐户，然后通过修改 RBAC 分配、创建服务主体或部署具有提升访问权限的资源来升级特权。
  • 合规性和审核失败： 缺少最低特权访问控制违反了分离职责的法规要求，并在 SOX、PCI-DSS 和 HIPAA 评估中创建审核结果。
  • 凭据盗窃影响： 具有广泛资产管理访问权限的泄露凭据使攻击者能够在检测之前在云环境中造成最大损害。
  • 更改控制绕过： 过度的权限允许用户绕过更改控制流程、审批工作流和安全评审过程进行基础结构修改。

过度特权访问基础结构管理可放大意外错误和恶意活动的影响。

MITRE ATT&CK

  • 特权提升（TA0004）：使用具有资产管理权限的受入侵帐户（T1078）通过修改角色分配或创建高特权标识来提升特权的有效帐户。
  • 影响 （TA0040）：资源劫持（T1496）利用资产管理权限部署加密挖掘基础结构或其他资源密集型恶意工作负荷。
  • 防御逃避（TA0005）：使用基础结构权限禁用安全监视、删除诊断日志或删除阻止检测的安全代理，损害防御（T1562）。

AM-4.1：为资产管理实现基于角色的访问控制

广泛的基础结构权限使意外配置错误和故意滥用在众多资源中产生的影响放大，使得特权管理对于限制安全事件爆炸半径至关重要。 通过基于角色的控制，最低特权访问可确保人员仅访问合法工作职能所需的资源，从而减少泄露凭据或恶意内部人员的风险。 实时激活将长期管理访问权限转换为临时的已审核提升事件，从而大大减少了凭据盗窃利用的机会窗口。

通过以下访问控制实现最低特权资产管理：

  • 通过最小特权角色分配、自定义角色和资源级别的范围界定部署Azure RBAC，将资产管理能力限制在有业务理由的授权人员范围内。

最小特权角色策略：

  • 读取者角色为默认值： 向常规用户授予读取者角色，使用户能够查看资源，而无需修改权限，从而支持运营洞察。
  • 特定于资源的参与者角色： 使用特定于服务的参与者角色（虚拟机参与者、存储帐户参与者），而不是限制权限范围的广泛参与者角色。
  • 自定义角色定义： 为特定作业函数创建自定义 RBAC 角色，其所需权限最少，以避免过度权限的内置角色。
  • 资源组和资源范围： 将角色分配范围限定为特定的资源组或单个资源，而不是订阅范围的分配，从而减少爆炸半径。
  • 限时分配： 为需要定期重新验证的项目访问实施具有到期日期的临时角色分配。

特权访问管理：

  • Microsoft Entra Privileged Identity Management （PIM）： 需要对所有者和参与者角色进行具有审批工作流、理由要求和最大持续时间限制的及时激活（Microsoft Entra Privileged Identity Management）。
  • Microsoft Entra ID Governance： 实现 Microsoft Entra ID Governance ，定期评审资产管理权限，确保通过自动访问认证和权利管理获得最低特权访问。
  • 紧急访问帐户： 维护具有所有者权限、受脱机凭据保护的应急帐户，监控访问并定期执行验证程序。
  • 职责分离： 用于资源预配、安全配置和网络管理的单独权限，防止单人高风险更改。

AM-4.2：实现 Azure 管理的条件访问

如果攻击者从受攻击的设备、不受信任的网络或指示凭据被盗的异常位置进行作，则仅验证用户标识就不足以保护基础结构管理。 条件访问策略强制实施设备符合性、网络限制和基于风险的控制，确保基础结构管理仅发生在符合安全标准的受信任上下文中。 多重身份验证与设备和位置验证相结合，可进一步防止基础结构泄露，即使在凭据被盗时也是如此。

通过以下策略强制实施上下文感知基础结构访问：

  • 使用多重身份验证要求部署 Microsoft Entra 条件访问 策略，以限制对 Azure 资源管理器 的访问，具体取决于设备符合性、网络位置和风险级别。

条件访问策略要求：

  • 多重身份验证强制： 要求 MFA 对 Azure 管理应用（Azure 资源管理器 API）进行所有访问，以防止对基础结构管理进行基于凭据的攻击。
  • 符合设备要求： 限制对 Intune 托管的合规设备的 Azure 管理访问，防止从非托管个人设备进行资产管理。
  • 特权访问工作站 （PAW）： 需要从具有增强安全性配置的专用特权访问工作站访问所有者和参与者角色。
  • 网络位置限制： 限制通过公司网络或批准的 VPN 连接对 Azure 管理的访问，阻止来自不受信任网络的访问。
  • 基于风险的访问控制： 阻止或要求对来自不熟悉的位置、有风险的登录或匿名 IP 地址进行 Azure 管理访问的其他身份验证。

条件访问阻止方案：

  • 阻止访问策略： 为不应访问 Azure 基础结构管理的用户实现Microsoft Azure 管理应用的“阻止访问”策略。
  • 会话持续时间限制： 为需要对持续基础结构管理活动进行频繁重新身份验证的特权访问配置短会话生存期。
  • 使用条款要求： 要求在 Azure 管理访问之前接受使用条款，并概述可接受的使用策略和安全责任。

AM-4.3：实现资源锁和不可变性

基于角色的访问控制限制谁可以修改基础结构，但防止意外或恶意破坏关键资源需要通过不可变控制强制超出权限。 资源锁将治理从权限管理转变为技术实施，阻止即便是拥有所有者权限的帐户删除或修改资源，从而防止因人为错误或凭据泄露导致的不可逆数据丢失。 部署堆栈将保护扩展到治理工件本身，确保安全策略和角色分配不会被它们所控的特权移除。

通过以下保护机制强制实施资源不可变性：

  • 部署 Azure 资源锁 和 Azure 部署堆栈的拒绝设置，防止即使具有所有者权限的用户也无法删除或修改资源，除非通过受管理的流程进行明确的策略变更。

资源锁策略：

  • CanNotDelete 锁： 将 CanNotDelete 锁应用于生产资源，防止意外删除，同时允许配置修改以实现作灵活性。
  • ReadOnly 锁： 在敏感基础结构（包括网络安全组、虚拟网络和标识资源）上部署 ReadOnly 锁，防止任何修改而不删除锁。
  • 继承的锁： 在资源组或订阅层级应用锁，并将其继承到子资源，这样可以简化治理，并防止通过创建新资源来绕过锁定。
  • 锁定移除审批工作流： 需要安全团队批准，执行变更管理过程，并记录审核日志和提供理由文档来完成锁定移除。

Azure 部署堆栈拒绝设置：

  • 部署堆栈拒绝分配： 部署堆栈通过拒绝设置，阻止修改或删除托管资源，甚至订阅所有者也无法执行这些操作，从而确保基础设施的不可变性。
  • DenyDelete 模式： 使用 DenyDelete 配置的部署堆栈可以保护策略分配、角色分配和部署的资源，同时允许配置更新。
  • DenyWriteAndDelete 模式： 具有 DenyWriteAndDelete 的部署堆栈阻止对需要通过受控基础结构即代码过程进行堆栈更新的治理配置所做的任何修改。

实现示例

一家每天处理超过20亿美元交易的金融服务组织面临资产管理访问权限控制带来的SOX合规风险和因未经授权的基础设施变更引发的安全事件挑战。

挑战： 应用程序团队拥有过多的权限，在订阅级别分配的参与者角色允许跨多个资源组对财务事务处理系统进行未经授权的访问。 发生三起安全事件，开发人员意外修改了生产网络安全组，导致付款处理中断。 SOX 审核发现，访问控制不足，40 多名用户拥有永久所有者权限，没有业务理由。 外部攻击者入侵开发人员凭据，并从非公司位置访问 Azure 管理门户，而无需进行额外的安全验证。 关键基础结构缺少删除保护，并有可能意外删除付款处理资源。

解决方案方法：

  • 最低特权访问： 实现了 Azure RBAC 自定义角色，授予应用程序团队其资源组范围内的资源特定贡献者权限，而无需具有订阅范围的访问权限。 删除了影响 40 多个用户的订阅级贡献者分配，减少了过多权限的 85%。
  • 按需访问： 部署的 Privileged Identity Management 需按需激活参与者与所有者角色，并采用经理审批工作流以及8小时限时访问持续时间。 取消了常规操作的现有特权访问。
  • 访问保护： 配置了Microsoft Entra 条件访问策略，这些策略要求对所有 Azure 管理访问进行 MFA、合规设备和公司网络位置，以防止外部访问尝试。 已建立特权访问工作站计划，专用强化的 VM 用于独立于标准企业网络的基础结构管理活动。
  • 资源保护： 向所有生产资源组应用了 CanNotDelete 锁，以保护财务事务处理系统免受意外删除。 在网络安全组、虚拟网络和 ExpressRoute 线路上部署的 ReadOnly 锁可防止未经授权的网络配置更改。 为治理资源配置了 DenyWriteAndDelete 的部署堆栈，包括策略分配、RBAC 角色和安全基线配置。

结果： 通过采用最小特权 RBAC 和资源锁定强制措施，修正了所有审核发现，从而实现了全面的 SOX 合规性。 通过条件访问策略消除未经授权的基础结构更改和外部访问尝试，同时通过实时特权访问激活保持运营效率。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AC-2、AC-2（1）、AC-5、AC-6、AC-6（1）、AC-6（5）
  • PCI-DSS v4： 7.2.2、7.2.4、7.2.5、8.2.2
  • CIS 控件 v8.1： 5.4、6.1、6.7、6.8
  • NIST CSF v2.0： PR.AC-4、PR.AC-7、PR.PT-3
  • ISO 27001：2022： A.5.15、A.5.16、A.5.18、A.8.2
  • SOC 2： CC6.1、CC6.2、CC6.3

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

安全原则

通过允许列表策略和行为监控强制实施应用程序控制，确保只有授权的软件能够在计算资产上执行。 防止未经授权的软件执行，包括恶意软件、未经批准的工具和过时的应用程序，同时保持已批准的业务应用程序和管理任务的运营灵活性。

待缓解风险

虚拟机上不受控制的软件执行通过恶意软件、未经授权的工具和过时的软件创建安全漏洞。 没有应用程序控制：

  • 恶意软件和勒索软件执行： 缺少应用程序允许列表允许恶意软件、勒索软件和其他恶意软件在攻击者获得系统访问权限后自由执行。
  • 未经授权的管理工具： 攻击者安装远程访问工具、网络扫描程序、凭据转储实用工具和其他支持攻击进度的利用后工具。
  • 未经批准的商业软件： 用户安装未经许可的软件、个人工具和未经批准的应用程序，从而产生法律责任、安全漏洞和支持挑战。
  • 过时的易受攻击的软件： 旧版应用程序和过时的软件版本保留在包含攻击者可利用的已知漏洞的系统上。
  • 内部威胁工具使用： 恶意内部人员不被发现地安装数据泄露工具、加密实用工具和系统破坏应用程序。
  • 加密货币挖掘和滥用： 泄露的系统执行加密矿工、僵尸网络客户端和其他资源密集型恶意应用程序，从而降低性能。

不受控制的应用程序执行使攻击者能够在实现初始访问后部署完整的开发后工具包。

MITRE ATT&CK

  • 执行（TA0002）：用户执行（T1204）欺骗用户执行恶意软件，从而绕过应用程序控制机制或利用策略差距。
  • 防御逃避（TA0005）：伪装（T1036）通过将恶意可执行文件伪装为合法应用程序，企图绕过应用程序许可列表控制。
  • 凭据访问（TA0006）：通过执行凭据窃取工具（如 Mimikatz），实现 OS 凭据转储（T1003），从内存中获取凭据以提升特权。

AM-5.1：实现自适应应用程序控制

不受限制的应用程序执行使攻击者能够在获得初始访问权限后立即部署开发后工具包，在检测之前将轻微入侵转换为完整的系统控制。 应用控制白名单通过定义已批准的软件并阻止其他所有内容，从而颠覆传统的防病毒防御，防止未知恶意软件和利用现有系统资源的技术，逃避基于签名的检测。 机器学习驱动的自适应控制通过在合法应用程序发展的同时自动调整允许列表，而保持对未经授权软件的防护，从而消除了手动维护策略的操作负担。

通过以下应用程序控件建立可执行限制：

  • 部署 Microsoft Defender for Cloud 自适应应用程序控制，它基于观察到的行为自动生成应用程序允许列表，并具备持续学习和执行的能力。

自适应应用程序控制实现：

  • 自动允许列表生成： 机器学习驱动的应用程序执行模式分析，为虚拟机组生成建议的允许列表。
  • 审核模式学习期： 审核模式下的初始部署观察应用程序执行模式，而无需强制构建全面的应用程序基线。
  • 强制模式激活： 转换到强制模式，在基线建立后阻止未经授权的应用程序执行，并持续学习和自动规则更新。
  • 文件完整性监视： 与文件完整性监视集成，检测未经授权的应用程序安装尝试和配置文件修改。
  • 基于发布服务器的规则： 应用程序允许基于发布者证书、文件哈希和路径规范的列表规则，以平衡安全性与作灵活性。

应用程序控制策略配置：

  • 基于组的策略： 根据每个服务器角色应用定制的应用程序控制策略的应用程序要求，将虚拟机组织成组。
  • 建议的规则接受： 在强制激活之前，查看并接受具有安全团队验证的自适应应用程序控制建议。
  • 自定义规则添加： 为特定于业务的应用程序、脚本和管理工具添加自定义允许列表规则，这些规则不会在学习阶段自动发现。
  • 警报和违规监控： 在 Defender for Cloud 中使用自动警报监控应用程序控制违规，对于需要调查的未经授权执行尝试进行监视。

AM-5.2：实现软件清单和更改跟踪

应用程序控制可防止未经授权的软件执行，但检测软件安装、配置更改和系统修改可提供识别控制绕过、策略冲突和新兴威胁所需的可见性。 全面的软件清单通过识别需要修补的过时应用程序来实现漏洞管理，而变更追踪则揭示出未经授权的修改，这些修改可能指示泄露或内部活动。 持续监控将瞬时库存快照转化为安全情报，在更改升高为事件之前检测异常变化。

通过这些功能监视软件和配置更改：

更改跟踪功能：

  • 软件清单收集： 使用 Azure Monitor 代理自动收集已安装的软件，包括应用程序名称、版本、发布者和安装日期。
  • 文件更改监视： 使用可配置的文件路径监视跟踪对关键文件和目录的更改，检测未经授权的软件安装、配置修改和恶意软件部署。
  • Windows 服务监视： 监视 Windows 服务更改，检测未经授权的服务安装和配置修改，指示具有可配置收集频率的恶意软件或持久性机制。
  • 注册表更改跟踪： Windows注册表持续监控，检测持久性机制、配置修改以及与恶意软件相关的注册表变动，支持HKEY_LOCAL_MACHINE注册表配置单元。
  • Linux 守护程序监视： 跟踪 Linux 守护程序和系统服务更改，识别受支持 Linux 分发版中未经授权的后台进程和持久性机制。

清单分析和警报：

  • 软件审批比较： 将发现的软件与已批准的应用程序目录进行比较，确定需要通过 Log Analytics 查询进行调查或删除的未经批准的应用程序。
  • 漏洞关联： 将软件清单与标识需要修补或更换与 Microsoft Defender 漏洞管理集成的过时软件的漏洞数据库相关联。
  • 更改警报规则： 配置 Azure Monitor 警报规则，当关键文件发生更改、未经授权的软件安装或注册表修改时触发通知，并具有可自定义的阈值。
  • Log Analytics 集成： 更改跟踪数据自动存储在 Log Analytics 工作区中，从而启用高级 KQL 查询、Azure 工作簿仪表板和Microsoft Sentinel 关联。

AM-5.3：控制脚本执行和管理工具

PowerShell、Python 和其他脚本语言为攻击者提供了强大的执行环境，这些环境绕过传统的可执行控件，同时提供广泛的系统访问和模糊处理功能。 为合法系统管理设计的管理工具在攻击者手中成为利用后工具，从而实现凭证窃取、横向移动和持久性建立。 将脚本执行限制为已签名的授权代码，并限制对已批准的人员的管理工具访问权限，可防止攻击者利用内置功能进行恶意目的，同时通过受限的执行环境保持作灵活性。

通过以下限制控制脚本和管理访问权限：

  • 实现 PowerShell 脚本执行策略、 AppLocker 和 Windows Defender 应用程序控制 ，将脚本和管理工具的执行限制为授权人员和方案。

脚本执行控件：

  • PowerShell 执行策略： 配置 PowerShell 执行策略，要求对远程脚本进行脚本签名，同时保持已签名管理脚本的灵活性。
  • PowerShell 约束语言模式： 部署 PowerShell 约束语言模式，限制 PowerShell 功能，防止恶意脚本执行，同时允许批准的管理任务。
  • 脚本块日志记录： 启用 PowerShell 脚本块日志记录 ，捕获所有执行的 PowerShell 代码，以便进行安全监视和取证调查。
  • Just Enough Administration (JEA)（适度管理）： 实现 Just Enough Administration 端点，将管理 PowerShell 的功能限制为特定的已批准 cmdlet 和参数。

管理工具限制：

  • Windows Defender 应用程序控制（WDAC）： 部署 Windows Defender 应用程序控制 策略，仅允许批准的管理工具、系统实用工具和业务应用程序执行。
  • AppLocker 规则配置： 配置 AppLocker 发布者规则、路径规则和控制管理工具和实用工具执行的哈希规则。
  • 生活在陆地二进制文件 （LOLBin） 控制： 限制攻击者通常滥用的系统二进制文件的执行，包括 regsvr32、rundll32 和 mshta。

实现示例

在处理 500 多个 Windows 服务器上的受保护的健康信息时，某医疗保健组织面临由于应用程序控制导致的勒索软件漏洞和《健康保险便利与责任法案》（HIPAA）合规性差距的挑战。

挑战： 组织遇到了两起勒索软件事件，攻击者在文件服务器上执行未经授权的加密工具，导致业务中断并触发 HIPAA 泄露通知要求。 安全团队无法了解 500 多个服务器中已安装的应用程序，这些服务器存在未知软件激增，从而造成了合规性风险。 开发人员在生产服务器上安装了未经批准的管理工具，包括远程访问实用工具和调试软件，向未经授权的访问公开 PHI。 PowerShell 脚本在没有日志记录或限制的情况下执行，使攻击者能够执行未检测到的侦察和横向移动。 HIPAA 审核发现对应用程序执行和缺少软件清单管理的控制不够。

解决方案方法：

  • 应用程序控制部署： 在强制激活之前，在所有 Windows 服务器上部署了 Microsoft Defender for Cloud 自适应应用程序控制，其审核模式学习期为 30 天。 配置的应用程序控制策略，由服务器角色组织，包括 Web 服务器、数据库服务器、文件服务器和域控制器，每个工作负荷类型定制的允许列表阻止未经授权的执行尝试，包括勒索软件和黑客工具。
  • 更改监视： 通过 Azure Monitor 代理实施更改跟踪和库存，监视虚拟机上的软件安装、文件修改和注册表更改，并与 Microsoft Sentinel 集成以实现安全性关联。 为应用程序控制冲突创建了 Azure Monitor 警报规则，用于识别尝试执行的恶意软件执行和需要安全团队调查的未经授权的工具使用情况。
  • 脚本执行控件： 在所有虚拟机上启用了 PowerShell 脚本块日志记录和约束语言模式，以捕获 PowerShell 命令，用于安全分析并阻止恶意脚本执行尝试。 在域控制器和证书颁发机构服务器上部署了 Windows Defender 应用程序控制策略，防止未经授权的管理工具执行保护 Active Directory 基础结构。

结果： 通过应用程序控制强制阻止未经授权的执行尝试消除勒索软件事件。 HIPAA 审核发现已解决，而 PowerShell 监视支持检测横向移动和侦察活动，从而提高事件调查速度。

严重性级别

应该有。

控件映射

  • NIST SP 800-53 Rev.5： CM-7（2）、CM-7（5）、SC-18、SI-3、SI-4
  • PCI-DSS v4： 5.2.1、5.2.2、5.3.3、11.5.1
  • CIS 控件 v8.1： 2.3、2.5、2.6、10.5
  • NIST CSF v2.0： PR.DS-6、PR.PT-2、DE.CM-4
  • ISO 27001：2022： A.8.7、A.8.12、A.8.19
  • SOC 2： CC6.1、CC6.6、CC7.2
  • Last updated on