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

资产保护

资产包括物理资产和虚拟资产，例如笔记本电脑、数据库、文件和虚拟存储帐户。 对业务关键资产的保护通常依赖于基础系统（如存储、数据、终结点设备和应用程序组件）的安全性。 最有价值的技术资产通常是数据和应用程序可用性，如企业网站、生产线和通信。

资产保护可实现控制措施，为安全体系结构、标准和策略提供支持。 每种资产类型和安全要求都是唯一的。 任何资产类型的安全标准都应一致地应用于所有实例。

资产保护重点在于实现所有控制类型的一致执行。 预防性、检测性等措施协调一致，以符合策略、标准和体系结构的要求。

资产保护充当资产技术行业专家。 它与其他专业领域合作，例如治理、体系结构、安全运营和工作负载团队。 资产保护可确保策略和标准可行，并使控制措施得以实现，从而为策略和标准提供支持。 资产保护可提供反馈，便于持续改进。

注意

资产保护通常由维护资产的 IT 运营团队实现，并由安全团队专家提供补充。 有关详细信息，请参阅作为团队设计控制措施。

威胁者不会罢休，他们会极力寻找因标准和策略在应用上的差距而导致的漏洞。 攻击者可以直接攻击业务关键数据或应用程序。 他们还可以攻击授权他们访问业务关键数据和应用程序的基础结构。 访问控制侧重于管理对资源的授权访问。 资产保护消除了所有其他以带外方式获取资源访问权限或控制的可能性。 这两个规则相互补充，应一起设计以满足体系结构、策略和标准的要求。 有关详细信息，请参阅访问控制。

观看以下视频，了解资产保护的历史以及如何确保旧资产和新资产的安全。

获得安全性

获得安全性侧重于使资源满足组织当前安全标准、策略和体系结构的要求。 有两种类型的活动：

• 棕色地带：对现有资产的当前安全标准和控制措施进行改进。 组织可能在设计和运营 IT 环境时将安全性作为低优先级事项。 这种方法会带来“技术债务”：薄弱的安全配置、没有升级的软件、未加密的通信或存储、遗留的软件和协议等等。 将安全控制引入当前方法。 此改进对于缓解风险至关重要，因为攻击者会持续提高恶意利用这些漏洞的能力。
• 绿色地带：确保将新资产和新资产类型配置为标准资产和标准资产类型。 此过程至关重要，可避免持续创建即时旧项或棕色地带项，或不符合当前标准的系统。 技术债务将不得不在以后以更大代价来解决，在解决之前，风险度将持续增加。

在财务上，“获得安全性”通常与一次性投资中的动态资本性支出 (CAPEX) 对应。 绿色地带安全预算应尽可能匹配资产创建，应为每个新软件项目、主要软件升级或整体云采用计划预留一定百分比的安全预算。 许多组织预留大约 10% 的安全预算。 棕色地带预算通常是为使安全控制措施符合当前标准和合规性而资助的特殊项目。

保持安全性

任何物品都会随着时间的推移而降级。 物理物品会磨损，软件、安全控制及安全性等虚拟物品所处的环境会发生变化。 它们可能不再满足不断变化的要求。 现在，这些转变发生得太快，皆是因为以下因素在迅速变化：

• 由数字化转型驱动的业务要求。
• 由云平台快速发展和功能发布驱动的技术要求。
• 由攻击者新型攻击及原生云安全功能快速发展驱动的安全要求。

这种动态变化会影响安全性的所有部分，包括安全运营、访问控制，尤其是创新安全性中的 DevSecOps。

保持安全性包含许多元素。 重点关注资产保护的以下两个特定领域：

• 持续云改进：拥抱云带来的安全功能的持续改进。 例如，Azure 存储和 Azure SQL 数据库等 Azure 中的许多服务都增加了安全功能，以抵御攻击者的持续攻击。
• 软件生命周期结束：如果不再提供安全更新，任何软件（包括操作系统）的生命周期都势必会结束。 在这种情况下，低成本的攻击就能轻松破坏业务关键数据和应用程序。 虽然服务型软件 (SaaS) 以及云基础结构和平台由云提供商维护，但企业通常拥有大量自行安装、创作且必须维护的软件。

计划升级或停用生命周期结束的软件。 对安全态势进行投资可以降低发生重大安全事件的风险。 保持安全性是定期持续投资中的动态运营性支出 (OPEX) 的一部分。

关于应用补丁的困境

业务领导务必要为其 IT 和安全领导和团队提供支持。 在恶意环境中运行复杂软件存在固有风险。 在应对运营风险和安全风险方面，安全和 IT 领导不断做着艰难抉择。

• 运营风险：对系统运行所在的软件进行更改可能会中断业务流程。 此类变更会影响为组织自定义系统时所做的假设。 这一事实给避免更改系统带来压力。
• 安全风险：攻击会带来业务停机风险。 攻击者会在每个重大安全更新发布时对其进行分析。 他们可以在 24-48 小时内开发出一个有效漏洞，攻击尚未应用安全更新的组织。

由于技术的不断变化和攻击技术的不断发展，你的组织会经常遭遇这种困境。 业务领导必须意识到使用复杂软件运行业务的风险。 支持更新业务流程，如以下示例：

• 将软件维护集成到业务运营假设、计划、预测和其他业务流程中。
• 对体系结构进行投资，使维护变得更简单，减少对业务运营的影响。 此方法可能涉及更新现有体系结构，或者通过迁移到云服务或面向服务的体系结构完全转向新的体系结构。

如果没有业务领导的支持，安全和 IT 领导无法全力支持重要业务目标的实现。 他们不得不陷入这种没有胜算的局面。

网络隔离

网络隔离可能是一个有效的选择，可以保护那些不再安全，但又不能立即停用的旧资产。 此方案通常适用于生命周期结束的操作系统和应用程序。 常用于运营技术 (OT) 环境和旧系统中。

尽管不安全的资产应获得资产保护，但是隔离本身是一种访问控制措施。 有关详细信息，请参阅避开防火墙并删除。

某些系统在生命周期结束时很难完全断开连接并隔离。 建议不要让这些不安全的系统完全连接到生产网络。 利用此配置，攻击者能够入侵系统并获取对组织资产的访问权限。

对于正常运转十年或更久的计算机技术，升级或替换它势必需要高昂的成本或花费巨大的精力。 记录其功能的文档可能非常有限。 失去对多个业务关键资产的控制对业务带来的潜在影响往往超过升级或替换它的成本。 对于无法隔离的资产，组织常常会发现，使用云技术和分析实现工作负载现代化可以创造出新的业务价值，它们可以抵消升级或替换所需成本或证明这些成本的使用是合理的。

在瞬息万变的世界里，保持安全性是一项挑战。 务必要时时刻刻确定，哪些资产要实现现代化，哪些资产要尽可能地保护。 利用业务风险和业务优先级进行评估。

入门

若要开始使用资产保护，建议组织采用以下步骤。

• 首先关注已知资源：考虑团队已熟知的云中虚拟机、网络和标识。 通过此方法，你可以立即取得进展，使用 Microsoft Defender for Cloud 等原生云工具通常能够更轻松地进行管理和保护。

• 从供应商/行业基线开始：使用已知且经过验证的解决方案开始进行安全配置，例如：

  • Azure 安全基准中的安全基线。 Microsoft 为每项 Azure 服务提供了有针对性的安全配置指南。 这些基线将 Azure 安全基准应用于每项服务的唯一属性。 此方法使安全团队能够保护每项服务，并根据需要优化配置。 有关详细信息，请参阅 Azure 安全基线。
  • Microsoft 安全基线。 Microsoft 为常用技术（包括 Windows、Microsoft Office 和 Microsoft Edge）提供安全配置指南。 有关详细信息，请参阅 Microsoft 安全基线。
  • CIS 基准。 Internet 安全中心 (CIS) 为许多产品和供应商提供特定配置指南。 有关详细信息，请参阅 CIS 基准。

重要信息

以下关键要素有助于指导资产保护流程：

责任团队和负责团队

安全责任应始终由业务中承担所有其他风险并享有相应利益的最终资源所有者承担。 安全团队和行业专家共同负责就风险、任何缓解措施以及实际实现向责任人提供建议。

资产保护责任可能由管理企业范围内资产的 IT 运营团队、负责其工作负载资产的 DevOps 和 DevSecOps 团队、或与 IT 或 DevOps 和 DevSecOps 团队合作的安全团队履行。

随着组织迁移到云，其中的许多责任可以转移给云提供商，例如更新固件和虚拟化解决方案，或者可以更轻松地履行，例如执行安全配置扫描和修正。

有关共担责任模型的详细信息，请访问云中共担责任。

云灵活性

与本地资源不同，云资源可以只存在一小段时间。 根据需要，工作负载可以创建更多服务器、Azure Functions 和其他资源的实例来执行作业。 Azure 会在之后删除资源。 此方案可以在几个月内进行，但有时也可以在几分钟或几小时内进行。 请在资产保护流程和措施中考虑使用这种方案的可能性。

云灵活性要求调整许多流程。 它提供按需清单而非静态报告，从而改善了可见度。 云灵活性还提高了更正问题的能力。 例如，能够出于安全原因迅速生成新的虚拟机。

异常管理

确定某个资产的最佳做法后，将其一致地应用于该资产的所有实例。 可能会有临时的例外情况，但需要使用特定到期日期来管理这些例外。 请确保临时例外不会演变为长期业务风险。

难于衡量价值

资产保护的商业价值可能很难衡量。 一个问题在导致真正故障之前，我们很难发现它的影响。 不更新安全漏洞的风险无声无息，也看不见。

首选自动化策略

首选自动化强制修正机制，例如用于资产保护的 Azure Policy。 此方法有助于避免重复执行手动任务带来的高成本和士气低落问题。 还可以降低人为错误导致的风险。

借助 Azure Policy，中心团队可以指定用于跨云资产的配置。

作为团队设计控制措施

应与关键利益干系人合作共同设计所有控制措施：

• 资产保护提供有关资产、可用的控制措施以及控制措施实现可行性的行业专业知识。
• 治理团队提供控制措施如何适应安全体系结构、策略和标准以及监管合规性要求的背景。
• 安全运营团队就检测控制措施提供建议。 他们将警报和日志整合到安全运营工具、流程和培训中。
• 供应商和云提供商可以就系统和组件提供深层的行业专业知识，以避免出现客户已知问题。

后续步骤

请查看下一个规则：安全治理