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

定义安全策略

安全组织的最终目标并不随云服务的采用而变化，但如何实现这些目标会发生变化。 安全团队仍必须注重降低遭受攻击的业务风险，并努力在所有信息系统和数据内构建机密性、完整性和可用性保证。

现代化你的安全策略

随着组织采用云并运营云，安全团队需要现代化战略、体系结构和技术。 尽管变化的大小和数量最初看起来很令人生畏，但安全计划的现代化使安全性摆脱了一些与旧方法关联的痛苦负担。 组织可以暂时使用旧策略和工具运营，但此方法难以在云的变化步调和威胁环境下维持：

• 如果安全团队采用回答总是以“不”开头的“保持距离”安全性的传统心态（而不是与 IT 和业务团队合作，以在启用业务的同时降低风险），那么他们很可能会被排除在云采用决策之外。
• 如果安全团队只使用旧的本地工具，并针对所有防御和监视只坚持仅限网络外围的原则，则会很难检测和防御云攻击。

云规模的监视和保护

云规模的防御是一项重大的转换工作，要求使用云原生检测和自动化功能，并引入了标识外围来帮助监视和保护云和移动资产。

• Microsoft 标识平台可以帮助你将新式身份验证和授权机制并入应用程序中。
• Microsoft Sentinel 在整个组织范围内提供云原生安全分析和威胁情报，从而利用大型的威胁情报存储库以及云的几乎无限制的处理和存储功能提高了威胁检测的能力。

我们建议安全团队采用一种敏捷的方法来现代化安全性——迅速现代化策略的最关键方面，不断地增量改进，向前发展。

云的安全性和来自云的安全性

当组织采用云服务时，安全团队将致力于两个主要目标：

• 云的安全性（保护云资源）：应将安全性集成到云服务的规划和运营中，以确保在所有资源中一致地应用这些核心安全保证。
• 来自云的安全性（使用云来转换安全性）：安全性应立即开始规划并考虑如何使用云技术来现代化安全工具和过程，特别是本机集成的安全工具。 安全工具被越来越多地托管在云中——这提供了在本地环境中难以或不可能执行的功能。

保护软件定义的数据中心

许多组织开始时都将云资源视为另一个“虚拟数据中心”，这是云安全性的有效起点。 随着组织使用来自云的安全性进行现代化，大多数组织会发现他们很快就会超越这种思维模式。 保护软件定义的数据中心能够实现超出本地模型所能提供的功能。 云托管的安全工具提供：

• 快速启用和缩放安全功能。
• 高效的资产清单和安全配置卫生发现。

部署 Microsoft Defender For Cloud可实现“组织的安全态势和控制的持续评估”。 它增强了云资源的安全态势，并且借助其集成的 Microsoft Defender 计划，Defender for Cloud 可保护在 Azure、混合和其他云平台中运行的工作负载。 详细了解 Microsoft Defender for Cloud。

注意

Azure 安全中心和 Azure Defender 现在称为 Microsoft Defender For Cloud。 我们还将 Azure Defender 计划重命名为了 Microsoft Defender 计划。 例如，Azure Defender for Storage 现在名为 Microsoft Defender for Storage。

详细了解 Microsoft 安全服务最近的重命名。

正确的安全摩擦级别

安全性自然会产生减缓过程的摩擦，因此识别 DevOps 和 IT 过程中哪些元素是正常的而哪些不是很重要：

• 正常摩擦：就像是运动中的阻力使肌肉更强壮，集成正确等级的安全摩擦可以通过在正确的时间强制进行批判性思考来加强系统或应用程序。 通常采取的形式是：在设计过程中考虑攻击者可能尝试如何破坏应用程序或系统及其动机，（称为威胁建模），并查看、识别和理想地修复攻击者在软件代码、配置或操作实践中可以利用的潜在漏洞。
• 不正常摩擦：所妨碍的价值大于其保护的价值。 这种情况通常发生在工具生成的安全 bug 具有较高的假正率（如误报），或者发现或修复安全问题的工作量远远超过攻击潜在影响的时候。

独立和集成的职责

提供机密性、完整性和可用性方面的保证要求安全专家运营专用安全功能，并与组织中的其他团队密切合作：

• 独特安全功能：安全团队执行组织中其他地方没有的独立功能，如安全运营、漏洞管理（例如针对虚拟机、容器）和其他功能。
• 将安全性集成到其他函数中：安全团队还充当组织中其他团队和职能的主题专家，这些团队和职能负责推动业务计划、评估风险、设计或开发应用程序和运营 IT 系统。 安全团队为这些团队提供有关攻击者、攻击方法和趋势、可能允许未经授权访问的漏洞、以及缓解步骤或解决方法选项及其潜在的优势或缺陷的专业知识和背景信息。 这种安全性函数与质量函数类似，因为它将被编织入大大小小的许多地方，以支持单一结果。

在执行这些职责的同时跟上云变化和业务转型的快速步伐，需要安全团队现代化其工具、技术和过程。

转型、心态和预期

许多组织正在管理组织中多个同时进行的转型链。 这些内部转型通常开始的原因是几乎所有外部市场都在进行转型以满足客户对移动和云技术的新偏好。 组织经常面临初创企业的竞争威胁和传统竞争对手的数字化转型，这些竞争对手会扰乱市场。

内部转型过程通常包括：

• 业务的“数字化转型”，抓住新机会并保持与数字原生初创企业的竞争力。
• IT 组织的“技术转型”，支持云服务、现代化开发实践和相关变化的计划。
• “安全转型”，适应云，同时应对日益复杂的威胁环境。

内部冲突的成本可能很高

变化会造成压力和冲突，这会使决策陷入停滞。 在安全性方面尤其如此，因为安全风险的问责通常错误地落在主题专家（安全团队）身上，而不是对业务结果和所有其他风险类型负责的资产所有者（业务所有者）。 这种错误的问责经常发生的原因是所有利益干系人都错误地将安全性视为要解决的技术问题或绝对问题，而不是像公司间谍和其他传统犯罪活动这样的动态持续风险。

此次转型期间，所有团队的领导都必须积极地致力于减少会破坏关键项目以及诱使团队绕开安全风险缓解操作的冲突。 团队间的内讧可能导致：

• 安全风险增加，如可避免的安全事件或攻击所导致的业务损害增加（尤其是当团队因安全性受挫而绕过正常过程时，或者当攻击者轻易绕过过时的安全方法时）。
• 对业务或任务造成负面影响，如当业务过程不能足够快速地启用或更新以满足市场需求时（通常是当安全过程阻碍了关键业务计划时）。

对团队内和团队间关系的健康状况保持了解非常关键，这有助于他们驾驭可能使宝贵的团队成员感到不安全和不稳定的不断变化的局面。 对这些心态的耐心、同理心和教育，以及未来的积极潜力，有助于您的团队更好地驾驭这一时期，为组织带来良好的安全结果。

领导者可通过如下的具体主动步骤来帮助推动区域性变革：

• 公开建模其团队的预期行为。
• 对变化所带来的挑战保持透明，包括突出其自身为适应变化所经历的挣扎。
• 定期提醒团队现代化和集成安全性的紧迫性和重要性。

网络安全复原

许多经典安全策略一直以来只专注于阻止攻击，这种方法不足以应对新式威胁。 安全团队必须确保他们的策略超越这一点，并且还能实现快速攻击检测、响应和恢复，以提高复原能力。 组织必须假定攻击者会破坏某些资源（有时称为“假想数据泄露”）并努力确保资源和技术设计在攻击预防和攻击管理之间取得平衡（而不是只试图防止攻击的典型默认方法）。

很多组织已经走在这条路上，他们近年来一直在管控着攻击量和复杂性的稳步上升。 这一旅程通常会从第一次重大事件开始，这可能是一个情绪事件，人们在此事件中失去了从前的无敌感和安全感。 虽然没有失去生命那么严重，但此事件会触发类似的情绪，从否认开始，最终以接受结束。 这种“失败”的假设可能一开始让某些人很难接受，但它与已确立的“防故障”工程原则有很强的相似之处，并且该假设允许你的团队专注于更好的成功定义：复原能力。

NIST 网络安全 framework 的功能可作为一项有用的指南，指导如何在复原策略中的识别、保护、检测、响应和恢复的互补活动之间实现投资平衡。

有关网络安全复原和网络安全控制的最终目标的详细信息，请参阅如何为组织维持低风险。

云正在如何改变安全性

安全性转向云不仅仅是一种简单的技术变革，它是技术的换代，类似于从大型机到桌面设备再到企业服务器的转变。 成功驾驭这一变革要求安全团队在预期和心态上发生根本性的转变。 采取正确的心态和预期会减少组织内的冲突，并提高安全团队的效率。

虽然这可能是任何安全现代化计划的一部分，但云的快节奏变革使采取正确的心态和预期成为当务之急。

• 与共享目标的合作关系。 在这种决策快节奏和过程不断演进的时代，安全性不能再采用“保持距离”的方法来批准或拒绝对环境的更改。 安全团队必须与业务和 IT 团队密切合作，围绕生产力、可靠性和安全性建立共享目标，并与这些合作伙伴共同努力实现这些目标。

  这种合作关系是“左移”的最终形式——该原则是指在过程的早期集成安全性，以使修复安全问题更简单、更有效。 这要求所有涉及组（安全、业务和 IT）进行区域性变革，即要求每个组都要了解其他组的区域性和规范，同时向其他组传授它们自己的文化和规范。

  安全团队必须：

  • “了解”业务和 IT 目标以及每个目标的重要性，以及它们在转型时考虑如何实现这些目标。
  • “共享”为什么安全性在这些业务目标和风险的上下文中非常重要，其他团队可以采取哪些措施来实现安全性目标以及他们应该如何做。

  虽然这不是一件简单的任务，但它对可持续性保护组织及其资产是必要的。 这种合作关系很可能会导致正常的妥协，即最初可能仅满足最低的安全性、业务和可靠性目标，但随着时间的推移会稳步提高。

• 安全性是一种持续的风险，而不是一个问题。 你不能“解决”犯罪。 就其核心而言，安全性只是一种风险管理规则，它恰好专注于人类的恶意操作，而不是自然事件。 与所有风险一样，安全性并不是可以通过解决方案解决的问题，它是负面事件（攻击）造成损害的可能性和影响的组合。 它与传统的公司间谍和犯罪活动最相似，在这些活动中，组织面临的有动机的人类攻击者成功攻击组织可以获得财务激励。

• 生产力或安全性的成功需要两者兼具。 在当今“创新或失去竞争力”的环境中，组织必须同时专注于安全性和生产力。 如果组织没有生产力，并在推动新的创新，它可能会失去市场竞争力，从而导致财务上的削弱或最终失败。 如果组织不安全，并失去对资产的控制给攻击者，它可能会失去市场竞争力，从而导致财务上的削弱或最终失败。

• 没有人是完美的。 没有任何组织是完全适合采用云的，Microsoft 也不例外。 Microsoft 的 IT 和安全团队也在努力克服我们的客户所面临的许多相同挑战，例如，确定如何很好地构建程序、平衡支持旧版软件与支持尖端创新，甚至云服务中的技术差距。 随着这些团队了解如何更好地运营并保护云，他们正积极地通过此类文档以及 IT 展示网站上的其他内容分享他们的经验教训，同时持续向我们的工程团队和第三方供应商提供反馈，以改进其产品/服务。

  根据我们的经验，我们建议团队秉持一种持续学习和改进的标准，而不是完美标准。

• 转型中的机会。 将数字化转型视为安全性的一个积极机会非常重要。 虽然很容易看到此变革的潜在不利因素和风险，但也很容易错过重新创造安全角色并赢得决策席位的巨大机会。 与企业合作可以增加安全资金，减少安全性方面浪费的重复性工作，使安全性工作更愉快，因为他们将与组织的使命更紧密地联系在一起。

采用共担责任模型

在云中托管 IT 服务在云提供商和客户租户之间拆分工作负载的运营和安全责任，从而建立事实上的共担责任合作关系。 所有安全团队都必须研究并了解此共担责任模型，以调整其过程、工具和技能集来适应新的世界。 这将有助于避免在安全状况中无意地造成缺口或重叠，从而导致安全风险或资源浪费。

此图说明了在事实合作关系中如何在云供应商与云客户组织之间分配安全责任：

由于云服务有不同的模型，每个工作负载的责任将有所不同，具体取决于它是托管在软件即服务 (SaaS) 上、平台即服务 (PaaS) 上、基础结构即服务 (IaaS) 上还是本地数据中心。

生成安全计划

此图说明了大多数安全计划为调整其云安全策略和安全计划目标而应遵循的三个主要安全计划：

在云中生成可复原的安全状况需要几种并行互补方法：

• 信任但验证：对于云提供商执行的责任，组织应采取“信任但验证”方法。 组织应评估其云提供商的安全做法及其提供的安全控制，以确保云提供商满足组织的安全需求。

• 现代化基础结构和应用程序安全性：对于组织控制下的技术元素，优先现代化安全工具和关联技能集，以最小化保护云中资源的覆盖缺口。 这由两个不同的互补工作组成：

  • 基础结构安全性：组织应该使用云来现代化其方法，以保护和监视许多应用程序（如操作系统、网络和容器基础结构）使用的常见组件。 这些云功能通常包括跨 IaaS 和本地环境管理基础结构组件。 优化此策略非常重要，因为此基础结构依赖于在其上运行的应用程序和数据，它们通常启用关键业务过程并存储关键业务数据。

  • 应用程序安全性：组织还应以保护由组织开发或为组织开发的独特应用程序和技术的方式进行现代化。 随着敏捷 DevOps 过程的采用、越来越多开源组件的使用以及云 API 和云服务的引入来取代应用程序组件或互连应用程序，此规则正在迅速变化。

    正确实现这一点至关重要，因为这些应用程序通常会启用关键业务过程并存储关键业务数据。

  • 新式外围：组织应具有一种全面的方法来跨所有工作负载保护数据，组织应建立一致的集中托管的标识控件的新式外围，以保护其数据、设备和帐户。 这受到一种零信任策略的严重影响，详细信息请参阅 CISO 研讨会的模块 3。

安全和信任

在安全性方面使用“信任”一词可能容易造成混淆。 本文档以两种方式引用它，以说明此概念的有用应用程序：

• 零信任是安全策略的常见行业术语，假设企业或 Intranet 网络是恶意的（值得“零信任”）并相应地设计安全性。
• 信任但验证是一种本质上的表达，即两个不同的组织尽管存在其他一些潜在的利益分歧，但为了一个共同的目标而协同工作。 这简明地捕捉了与组织的商业云提供商合作的早期阶段的许多细微差别。

云提供商及其做法和过程可以对满足合同和法规要求负责，并可能赢得或失去信任。 网络是一种没有生命的连接，如果被攻击者使用，不会面临后果（就像不能让道路或汽车对使用它们的罪犯负责一样）。

云正在如何改变安全关系和职责

与以前转换到新一代技术（如桌面计算和企业服务器计算）一样，向云计算的转移正在破坏长期建立的关系、角色、职责和技能集。 我们在过去几十年中已经习惯的作业说明并未清晰映射到现在包含云功能的企业。 随着行业共同致力于规范化新模式，组织必须专注于提供尽可能明确的信息，以帮助管理在这一变化期间模棱两可的不确定性。

安全团队受他们支持的业务和技术的这些变革及其自身内部现代化工作的影响，得以更好地应对威胁参与者。 攻击者正在积极发展，不断寻找组织的人员、过程和技术中最容易利用的弱点，而安全团队必须开发功能和技能来解决这些角度。

本部分介绍在向云转型的过程中频繁变化的关键关系，包括在最小化风险和拥抱改进机会方面的经验教训：

• 安全性与业务利益干系人之间：安全领导需要越来越多地与业务负责人合作，使组织能够降低风险。 安全负责人应作为安全主题专家 (SME) 支持业务决策，并应努力成长为这些业务负责人所信任的顾问。 此关系有助于确保业务负责人在做出业务决策时考虑安全风险，告知安全团队业务的优先级，并帮助确保安全投资与其他投资一起确定适当的优先级。

• 安全领导与团队成员之间：安全领导应该将业务领导的这些见解带回其团队，以指导其投资优先级。

  通过设置与业务负责人及其团队协作的基调，而不是传统的“保持距离”关系，安全负责人可以避免妨碍安全和生产力目标的对抗性动态。

  安全负责人应努力向其团队阐明如何管理其有关生产力与安全性权衡的日常决策，因为这对其团队中许多人来说是新的内容。

• 应用程序与基础结构团队（与云提供商）之间：由于 IT 和安全行业出现多种趋势，旨在提高创新速度和开发人员生产力，因此此关系正经历重大变化。

  旧的规范和组织功能已被打破，但新的规范与功能仍在出现，因此我们建议接受这种模糊性，跟上当前的思维，并试验适合于组织的规范与功能直到成功。 我们不建议在此领域采取观望的态度，因为这可能会使你的组织处于重大竞争劣势。

  这些趋势正在挑战应用程序和基础结构的角色和关系的传统规范：

  • DevOps 融合规则：在其理想状态下，这有效地创建了一个单一高功能团队，它将这两组主题专业知识合并在一起，以快速创新、发布更新并解决问题（安全性及其他方面）。 尽管实现这种理想状态需要一些时间，而其间的责任仍然不明确，但由于这种协作方法组织已经而收获了快速发布的一些好处。 Microsoft 建议将安全性集成到此周期中，以帮助了解这些区域性、共享安全学习，并努力实现快速发布安全可靠的应用程序这一共同目标。

  

  • 容器化成为常见的基础结构组件：应用程序正逐渐由 Docker、Kubernetes 等技术和类似技术托管和协调。 这些技术通过抽象基础操作系统的安装和配置的许多元素来简化开发和发布。

  

  虽然容器一开始是由开发团队管理的应用程序开发技术，但它正逐渐成为一个常见的基础结构组件，并越来越多地向基础结构团队转移。 这种转换在许多组织里仍在进行中，但这是一个自然且积极的方向，有关传统基础结构技能集（如网络、存储和容量管理）的许多当前挑战都将得到最好的解决。

  应为支持他们的基础结构团队和安全团队成员提供培训、过程和工具，以帮助管理、监视和保护此技术。

  • 无服务器和云应用程序服务：行业目前的主要趋势之一是减少生成或更新应用程序所需的时间和开发工作。

    

    开发人员也在越来越多地使用云服务：

    • 运行代码，而不是在虚拟机 (VM) 和服务器上托管应用程序。
    • 提供应用程序功能，而不是开发自己的组件。 这导致了一个“无服务器”模型，该模型使用现有云服务实现常见功能。 云服务的数量和种类（及其创新速度）也已超出了安全团队评估和批准这些服务的使用的能力，他们只能选择允许开发人员使用任何服务，尝试阻止开发团队使用未经批准的服务，或者尝试寻找更好的方法。
    • 无代码应用程序和 Power Apps：另一个新兴趋势是使用无代码技术，如 Microsoft Power Apps。 此技术使没有编码技能的人能够创建可实现业务结果的应用程序。 由于这种低摩擦和高价值的潜力，此趋势有可能迅速流行起来，安全专业人员最好迅速了解其可能的影响。 安全工作应侧重于人员在应用程序中可能出错的领域，即通过对应用程序组件、交互/关系和角色权限进行威胁建模来设计应用程序和资产权限。

• 开发人员与开源组件作者之间：开发人员还在通过使用开源组件和库而不是开发自己的组件来提高效率。 这通过效率带来价值，但也通过创建外部依赖项和正确维护和修补这些组件的要求而引入了安全风险。 开发人员在使用这些组件时在有效假设安全和其他 bug 的风险，并且必须确保有计划可以按其开发代码的同一标准来缓解这些风险。

• 应用程序与数据之间：数据与应用程序的安全性之间的界限在某些地方正变得模糊，新的法规正在要求数据/隐私团队和安全团队之间更密切地合作：

  • 机器学习算法：机器学习算法类似于应用程序，因为它们旨在处理数据以创建结果。 主要区别包括：

    • 高价值机器学习：机器学习通常赋予显著的竞争优势，并通常被视为敏感的知识产权和商业秘密。

    • 敏感度印记：受监督的机器学习使用数据集优化，其在算法上印记数据集的特征。 因此，由于用于训练优化算法的数据集，优化算法可能被视为敏感算法。 例如，使用秘密军事基地数据集训练机器学习算法以在地图上找到秘密军事基地将使其成为敏感资产。

    注意

    并非所有示例都很明显，因此，从数据科学团队、业务利益干系人、安全团队、隐私团队及其他团队中选取合适的利益干系人来组成一个团队至关重要。 这些团队应该有责任实现共同的创新和责任目标。 它们应解决常见问题，例如如何以及在何处存储不安全配置中的数据副本，如何对算法进行分类，以及组织关心的任何问题。

    Microsoft 已发布了负责任的 AI 原则，指导我们自己的团队和客户。

    • 数据所有权和隐私：GDPR 等法规提高了数据问题和应用程序的可见性。 应用程序团队现在有能力在与银行和金融机构跟踪财务数据相当的级别控制、保护和跟踪敏感数据。 数据所有者和应用程序团队需要对应用程序存储哪些数据以及需要哪些控件建立充分的了解。

• 组织与云提供商之间：当组织在云中托管工作负载时，他们正在与其中每个云提供商建立业务关系。 使用云服务通常会带来业务价值，例如：

  • 加速数字化转型计划，通过缩短新功能的上市时间。

  • 提高 IT 和安全活动的价值，通过解放团队，让团队专注于更高价值（业务一致）的活动，而不是可以由云服务代表他们更高效地提供的较低级别的商品任务。

  • 提高了可靠性和响应能力：与传统的本地数据中心相比，大多数新式云还有较高的运行时间，并已显示它们可以快速缩放（例如，在新冠疫情期间）以及在雷击等自然事件之后的复原能力（许多本地等效设备停机的时间要长得多）。

    虽然这很有利，但转移到云并非没有风险。 组织采用云服务时，应考虑潜在的风险领域，包括：

  • 业务连续性和灾难恢复：云提供商的财务状况是否健康，业务模型是否有可能在组织使用服务期间生存和发展？ 如果提供商遇到财务或其他失败，云提供商是否做出了规定以允许客户连续性（例如为客户提供源代码或开放源代码）？

    有关 Microsoft 财务状况的详细信息和文档，请参阅 Microsoft 投资者关系。

  • 安全性：云提供商是否遵循行业安全最佳做法？ 这一点是否经独立监管机构验证？

    • Microsoft Defender for Cloud Apps 允许你发现超过 16，000 个云应用程序的使用情况，这些云应用程序基于 70 多个风险因素进行排名和评分，可让你持续了解云使用、影子 IT 和影子 IT 给你的组织带来的风险。
    • Microsoft 服务信任门户向客户提供法规合规性认证、审核报告、渗透测试等等。 这些文档包含许多内部安全做法的详细信息（值得注意的有，SOC 2 类型 2 报告和 FedRAMP Moderate 系统安全计划）。 Microsoft Defender for Cloud 允许安全策略管理，并且可以指示符合预定义行业和法规标准的级别。

  • 业务竞争对手：云提供商在你的行业中是一个重要的业务竞争对手吗？ 云服务协定或其他方式是否提供了充分的保护来防止业务受到潜在恶意操作？

    有关 Microsoft 如何避免与云客户竞争的注释，请查看此文章。

  • 多云：许多组织都有事实上的或有意的多云策略。 这可能是为了减少对单个供应商的依赖或访问独特的同类最佳功能而有意设定的目标，但也可能是因为开发人员选择了首选或熟悉的云服务，或者你的组织获得了另一项业务。 无论什么原因，此策略都可能会引入必须管理的潜在风险和成本，包括：

    • 多个依赖项的故障时间：架构依赖于多个云的系统会暴露于更多故障时间风险来源，因为云提供商的中断（或者你的团队对它们的使用）可能会导致业务停止/中断。 这种增加的系统复杂性也会增加中断事件的可能性，因为团队成员不太可能对更复杂的系统有充分的了解。
    • 谈判能力：大型组织还应考虑单云（相互承诺/合作关系）或多云策略（转移业务的能力）是否会对其云提供商实现更大的影响，以使其组织的功能请求获得优先权。
    • 增加的维护开销：IT 和安全资源已经因为现有的工作负载和为了跟上单云平台的变化而负担过重。 每一个额外的平台都进一步增加了这一开销，使团队成员无法执行更高价值的活动，例如简化技术过程以加快业务创新，咨询业务组如何更有效地使用技术，等等。
    • 人员配备和培训：组织通常不考虑支持多个平台所需的人员配备要求，也不考虑维护快节奏发布的新功能的知识和现时性所需的培训。