利用云应用程序安全策略自动化提高云安全性

将安全策略手动转换为技术实现是一个艰难、昂贵且易出错的过程，特别是在应用程序层实现该转换时。云安全性工具需要变得更加自动化，才能实现更多时间和成本节省。而且只有实现了这些工具的自动化，才能使云安全性管理成为一项更加简单的任务，让云管理员专注于更加重要的安全问题。

本文详述了有效应用程序安全策略自动化的挑战，阐述了模型驱动安全方法给安全策略自动化带来的好处，然后展示了如何实现云应用程序安全策略自动化。

安全性是采用云技术所必需的一个要素，缺乏安全性通常会阻碍云技术的采用。然而，随着安全策略和合规复杂性、IT 复杂性和 IT 敏捷性的增加，将安全策略转化为安全实现的任务变得更加耗时、重复、昂贵且容易出错，并且很容易增加最终用户组织的安全工作量。自动化可帮助最终用户组织（和云提供商）减少该工作量，并提高策略实施准确度。本文将重点介绍一个特别有趣的、富有挑战且经常被遗忘的话题：应用程序层的安全策略自动化。

云应用程序安全性自动化

应用程序安全策略自动化主要是一个自动化流程，将人类可理解的安全需求（比如企业安全策略、遵从性法规和最佳实践）转化为在应用程序层实现的对应的技术安全策略规则和配置。在整个循环最后，它还包含审计自动化；例如，收集应用程序层警报并将它们映射为人类可理解的安全性和合规需求，以便持续评估安全态势。

云应用程序安全策略剖析

应用程序安全策略通常对于互联、动态变化的应用程序格局来说尤其复杂，比如面向服务架构 (SOA)、云应用程序 mashup、其他 “即插即用” 的应用程序环境。出于各种业务原因，以及以最少的总体维护工作量支持这些原因的安全要求，客户采用了这样的应用程序环境。因此自动化非常关键。

安全自动化对于云计算尤其重要，因为云用户要求云提供商支持法规遵从策略管理，同时按照与云计算大致相同的度量方式（根据它削减其前期资本支出和其内部手工维护工作的程度）衡量优势。

总体而言，“应用程序层安全性” 远比本文介绍的策略自动化方面宽泛，还包括漏洞扫描、应用程序层防火墙、配置管理、警报监控和分析以及源代码分析等任务。与应用程序层安全策略密切相关的一个任务是身份识别和访问管理。尽管身份识别和访问管理常常被视为与用户身份管理（而非应用程序安全性）有更大的关系，但它们实际上与应用程序层安全性高度相关。这是因为，当用户访问应用程序并进行身份验证时，需要实施一个授权策略，这在很大程度上往往依赖于受访问的特定应用程序。

此时，难题出现了：这个授权策略来自何处？谁编写和维护该策略？如何实施该策略？如何审计该策略？这些问题在以下情况下也适用：使用应用程序安全策略自动化以及身份识别和访问管理，让策略管理更省时、不重复、不再昂贵且不易出错。

如今的云应用程序安全策略自动化部署

总体而言，安全策略自动化，特别是对于云技术来说，仍然处于相对较早的阶段。它主要侧重于将身份识别/身份验证作为一种服务（例如，Facebook 连接）提供。还有一些基于云的安全服务（反病毒、电子邮件扫描、入侵检测系统 (IDS)，日志管理），其中一些服务与应用程序间接相关。

本文专注于将应用程序安全策略自动化作为一种服务提供。目前只有几个适用于早期采用者的部署：首先，ObjectSecurity 将其 OpenPMF 模型驱动的安全策略自动化产品与一个私有平台即服务 (PaaS) 云（带 Intalio BPMS 的 Intalio 云）相集成，为云 mashup 提供无缝的策略自动化。涉及 OpenPMF 的另一个早期部署适用于美国海军，在介于私有云和 SOA 之间的灰色区域中。它涉及到策略即服务，面向高保障环境中的虚拟化 IT 服务。两个案例都将在后面的 案例研究 一节加以讨论。

还有大量其他模型驱动的安全策略自动化部署，但不是针对云，且大部分没有涉及到策略即服务。

应用程序安全策略自动化的挑战

遗憾的是，在大多数情况下，安全策略自动化说起来容易，做起来难。本节概述应用程序安全策略自动化实现起来较难的原因。

策略变得更难以实现和自动化，因为它们对人们和组织来说更加有意义

如今的许多安全工具提供了一定程度的自动化（无需维护），但无法实现相关性、正确性和自动化之间的折衷：在某些情况下，自动化工具的构建以供应商知道最终用户组织想实现什么默认安全策略为前提。在其他情况下，构建产品的宗旨在于随时间启发式地学习策略。两种方法的缺点在于，它们可能会实施非计划中的、不相关或不完整的策略，即使安全机制自身能够发挥其作用。

这样的传统安全自动化往往更适用于更加通用的安全工具，这些工具不需要特定于组织的策略，且面向技术体系的底层级（例如，网络或操作系统层），比如反病毒、反恶意软件、预配置的网络入侵检测系统，以及通用的应用程序漏洞扫描。

当必须将组织、用户和应用程序行为考虑在内来实施和审计安全策略时，安全自动化变得更难以实现。例如，处理信用卡支付的一家组织会希望实施这样的策略，比如 “未解密的信用卡信息不得带离组织之外”，“必须删除不再使用的信用卡信息”。另一个示例是，一家医疗组织希望实施的策略包括，“医生和护士仅在有法用途需要时，才能访问其当前 患者的健康档案，而不创建报警审计日志”。这样复杂的、与上下文相关的策略取决于特定组织的安全策略、业务流程、应用程序和应用程序交互。通常实施这种复杂的、与上下文相关的策略的原因在于，最终用户组织必须满足行业特定规范（PCI 数据安全标准或 PCI DSS 和健康保险便携性与责任法案或 HIPAA）。

策略变得更难以实现和自动化，因为它们变得更多、更复杂、功能多样、粒度更细且与上下文相关

传统的 “授权管理” 如今被归类为身份识别和访问管理一部分，它说明了这些挑战：当系统和参与者越来越多，当互联应用程序动态演化（“敏捷性”），当策略变得丰富多样、细粒度和与上下文相关时，策略变得不可管理。有太多、太复杂的技术安全规则需要管理，因此授权策略可能变得不明确或不可管理，并且对所实施策略的信心可能被削弱。如前所述，需要回答的问题是：这个授权策略来自何处？谁编写和维护该策略？如何实施该策略？如何审计该策略？

策略自动化变得更难以实现，因为 IT 格局变得越来越敏捷和互联（特别对于云 mashup）

要支持敏捷应用程序环境（比如云和 SOA）背后的采用原理，授权管理本身至少需要是同等敏捷的，而且是自动化的、可管理的、细粒度的、与上下文相关的。遗憾的是，面对频繁而动态的系统变更，创建和维护一致且正确的技术安全策略是一大挑战。这是因为，动态变更（例如，云 mashup 的动态变更）会使实施的技术策略无效，而且安全策略对于互联、动态变化的应用程序格局来说尤为复杂，比如 SOA、云应用程序 mashup，以及其他 “即插即用” 应用程序环境。如果不考虑这些缺点，授权管理形成一个关键的技术构建块，可为所有受保护资源实施和审计应用程序授权策略。它是云应用程序安全性的一个重要部分，对于云 mashup 来说更是如此，因为不同的角色（用户或云应用程序）应当在特定情况下获得授权后，才能够根据安全策略调用彼此的服务。一个重要的授权管理标准是 OASIS 可扩展访问控制标记语言 (XACML)。

法规遵从性是与策略相关的一个要求，因此也需要得到尽可能多的自动化支持

企业云用户不可避免地会要求为其云托管应用程序和服务提供简单、低维护量（自动化）的合规支持。这是因为，许多云应用程序要处理监管信息（隐私、健康信息、支付信息），这些信息通常是跨组织边界且需要审计的。合规审计不能成为云用户的独有责任，因为用户对云体系的可见性有限（特别对于 PaaS 和软件即服务，以及基础架构即服务）。因此需要将法规遵从性（就像安全策略管理和事故监控）部分地内置于云平台上。

用户需要采用基于白名单的策略，因为黑名单不再够好

在此提醒，黑名单是指您向任何不在黑名单上的人提供访问。白名单是指您仅向白名单中的人提供访问。

模型驱动的安全组件

要实现自动化，一些 “算法” 需要能够理解安全策略要求和与策略相关的一切（用户、应用程序、应用程序互联和应用程序工作流），并自动生成匹配的技术安全策略实现。模型驱动安全方法将模型驱动的软件开发方法背后的推理应用于安全和合规性策略管理，从而推进了这一需要的安全策略自动化级别。

模型驱动安全方法

实际上，通过分析应用程序及其所有交互并应用通用安全要求，模型驱动安全方法可以自动生成技术授权（和其他）规则。模型驱动安全方法是一个工具支持的流程，涉及到较高抽象级别上的建模安全要求，以及使用系统可用的其他信息源，特别是应用程序的功能模型（由其他利益相关者建立），自动生成细粒度、上下文相关的技术授权（和其他）规则。模型驱动安全流程中输入的信息用领域特定语言 (DSL) 表达，使用通用建模语言（比如统一建模语言或 UML）或企业架构框架（EA 框架）（例如，美国国防部架构框架或 DODAF，英国国防部架构框架或 MODAF，以及 NATO 架构框架或 NAF）。

捕获安全要求在不使用图形编辑器的情况下完成；也可以使用文本模型编辑器完成此任务（例如，在 Eclipse 这样的建模工具中）。然后通过分析有关这些应用程序及其所有交互的信息，这些要求会被自动转换为可实施的安全规则（访问控制和监控规则）。

模型驱动安全运行时支持跨所有受保护 IT 应用程序的安全策略运行时实施，自动策略更新，以及策略违规的综合监控。在模型驱动安全方法的第一步中，需要在一个模型驱动安全工具中将法规和治理标准建模（或从预先构建的模板中选择）为一个高级安全策略。然后将这一安全策略模型应用于各组成系统的功能模型，也就是说，将安全策略模型角色映射到系统角色，并根据安全策略模型限制这些系统角色的行为。

从技术角度来看，这些（安全性和功能）模型被自动转换为低级、细粒度、上下文相关的安全策略，并在整个云业务流程、云 mashup 或 SOA 环境中得到实施（例如，通过集成到中间件或域边界的本地实施点）。本地实施点也可以处理安全合规性相关事件的监控。每当 SOA 应用程序（或其交互配置）发生变化时，模型驱动安全方法可以自动更新安全性实施和监控。

总而言之，模型驱动安全流程可以分为以下几个步骤：策略建模，自动策略生成，策略实施，策略审计，和自动更新。下面我们看看这些步骤在云应用程序上下文中是如何执行的。

模型驱动安全架构

图 1 中的图表展示了基本架构：左上角显示基于云的开发和 mashup 环境（业务流程管理系统 (BPMS)，编排的 Web 服务）。其中还显示，需要（由云提供商）将模型驱动的安全组件安装到开发/mashup 工具链中，以自动化策略的生成。

右上角显示云安全服务，该服务提供 PaaS，开发工具的模型驱动的安全附加组件，以及定期的通用形式的策略更新；另外，还显示了云安全服务提供的运行时管理（监控/分析/报告）功能。

底部显示了部署到应用程序服务器（和云运行时堆栈的其他部分）的一些云服务，以及需要在运行时堆栈上（由云提供商）安装的策略实施 (PEP) 和监控点。

在开发并集成一个应用程序之后，模型驱动安全方法会自动分析应用程序和策略模型，并生成被自动推送到相关 PEP/监控点的技术规则。每当一条消息经过任何受保护资源之间时，模型驱动安全方法就会自动评估和实施技术策略，并且如有需要，将事故警报推送到云安全服务的运行时安全策略管理特性。

图 1. 架构概览：使用 PaaS 的模型驱动的云安全策略自动化

优势

如得到有效利用（参见 案例研究），模型驱动安全方法具有众多优势：

它可以通过自动化（策略生成，实施，监控，更新）降低人工管理开销，节省成本/时间，对于敏捷软件应用程序来说尤其如此。

它还可以通过最大限度减少人工错误降低安全风险，通过确保安全策略始终符合业务需求和系统的功能行为来增加保障，从而增强系统的安全性。

此外，它可以跨安全孤岛（例如，不同的应用程序运行时平台）统一策略。

最后，它形成一个更加自动化的模型驱动敏捷认证方法的一部分。

缺陷

模型驱动安全方法的采用出于几个原因仍然受到挑战：

依赖于应用程序规范和一个适当定义的软件开发生命周期 (SDLC)；然而，建模互联系统（特别是云 mashup 交互）的各个方面是先进的云 PaaS 的一个重要部分，也是健全的系统设计的一部分。

建模系统和安全策略的工作。然而，在适当的粒度级别（例如，云 mashup 模型）建模系统实际上不会增加策略管理的总体成本。这是因为，如果安全管理员因其工具不支持模型驱动安全方法而必须手动指定详细的技术安全规则，他们可以在其策略管理工具内有效地指定应用程序规范的安全相关方面。在实践中，对于大型系统来说，这是不可能的，尤其是在整个系统生命周期中。模型驱动安全方法只是重用专家（和/或工具）指定的模型上的信息（通常占安全策略规则的很大一部分），不管怎样，这些专家更了解应用程序和工作流（应用程序开发人员/集成人员和流程建模人员）。

从实践经验来看，与传统的人工策略定义和管理相比，即使应用很小一段时间，模型驱动安全方法也可以大大降低保护系统的成本，并提高安全性。

实现云应用程序安全策略自动化

随着云 PaaS 的兴起，将所述模型驱动安全架构的全部或部分迁移到云中，以最高的自动化水平保护和审计云应用程序和 mashup 是合乎逻辑的。特别是，安全策略模型被作为一个云服务提供给应用程序开发和部署工具（策略即服务），而且策略自动化被嵌入到云应用程序部署和运行时平台（自动化策略生成/更新、实施和监控）。

不同的云部署场景是可行的；例如，开发工具和应用程序平台中的安全特性都作为 Paas 配置的一部分托管在同一云服务中，或一些安全特性是另行托管的（特别是策略配置和监控）。这不同于本地非云部署，其中模型驱动安全方法通常安装在本地安装的开发工具（比如 Eclipse）内，或与其并行安装，以保护大量本地运行时应用程序平台（例如，Web 应用程序服务器）上的应用程序，并支持本地监控和报告。

如前所述，一般的模型驱动安全流程分为以下步骤：策略建模、自动策略生成、策略实施、策略审计和自动更新。下面我们看看这些步骤在云应用程序上下文中是如何执行的。在云上下文中，模型驱动安全方法的 5 个步骤如下所述。

云中的策略配置（策略即服务）

在模型驱动安全方法的云版本中，可以将策略配置作为基于订阅的云服务提供给应用程序开发工具。将策略模型的规范、维护和更新提供给应用程序开发人员和安全专家具有显著的效益：最重要的是，应用程序开发人员和安全专家现在无需持续指定（或购买并安装）和维护用于模型驱动安全方法的策略模型，而是可以订阅他们需要的策略源，而无需知道模型的细节。

策略即服务提供商（通常与云提供商不同）负责策略建模、维护和更新。其他优势包括，用户组织无需是安全和合规性专家，因为最新策略模型将被作为源持续提供给他们，前期成本障碍因订阅模型而得以最小化。而且最终用户组织无需持续监控变革法规和最佳实践。

对于更加复杂的策略，一些简单的设置和安全相关信息的一些潜在标记可能是有必要的：例如，对于一个 PCI DSS 策略模型订阅，支付信息相关的界面可能需要连同应用程序 mashup 模型一同加以标记。整合到云中的预包装云模块越多，最终用户组织需要做的标记就越少，因为云模块可能已经提前被云提供商所标记（例如，支付处理模块的 PCI 相关标记）。

总而言之，所描述的外包模型并非新事物。它已经在其他安全方面成功应用了多年，比如反病毒和反间谍软件。用户从反病毒提供商那里订阅策略源，并让反病毒软件客户端自动实施该策略（但与反病毒相比之下，本文阐述应用于云应用程序安全的外包模型）。

尽管质疑一个基于云的授权策略管理服务的真实性和可靠性是很自然的事（特别对于任务关键型环境），但需要将这样一个部署场景的含义看作与受保护云应用程序的内在真实性和可靠性水平相关。如果受保护云服务本身可通过 Internet 进行访问，那么对策略管理服务的许多攻击（例如，拒绝服务）也可以被转移至受保护服务本身。在这种情况下，基于云的策略管理器不会增加风险。如果需要更高的真实性和可靠性，比方说对于一个启用了优质服务 (QoS) 的私有云，那么策略管理器和受保护云都需要加固的基础架构。总之，基于云的安全策略管理将是为许多组织配置的许多服务的正确选择，但并不面向所有服务。

云中的自动技术策略生成

模型驱动安全方法的自动策略生成特性被集成到了开发、部署和 mashup 工具中（以获取对功能应用信息的访问）。它使用上一节描述的策略源。PaaS 有时包含云托管的开发和 mashup 工具，以及一个云托管的运行时应用程序平台。在这种情况下，使用模型驱动安全方法的自动技术策略生成也可被迁移到云中，这样一来在云托管的开发、部署和/或 mashup 流程中就可以为应用程序自动生成技术安全策略。对于 mashup 工具来说尤其如此，因为这些工具更有可能是云托管的，通常是图形和/或模型驱动的工具，且关注云服务之间的交互和信息流。如果开发工具不托管在 PaaS 云上，那么就需要将模型驱动的安全技术策略自动生成特性集成到本地开发工具中。

云中的自动安全策略实施

策略实施自然而然应当集成到 PaaS 应用程序平台中，这样一来，每当云服务得到访问时就会自动实施生成的技术策略。如上一节所述，策略要么使用托管模型驱动安全和 PaaS 开发工具在云内生成，要么通过本地模型驱动安全和开发工具上传进来。

在 PaaS 应用程序平台内置策略实施点的方式取决于 PaaS 应用程序平台是否允许安装策略实施点（例如，各种开源 PaaS 平台；参见 案例研究）；支持一个基于标准的策略实施点（例如 OASIS XACML）；或者支持一个专有策略实施点。

云中的自动策略监控

策略实施点通常引起安全相关的运行时警报，特别是与阻截的调用相关的事故。对这些警报的收集、分析和直观表示也可被迁移到云中。这有诸多优势：可以集中分析多个云服务的事故以及其他信息（比如网络入侵检测）；而且可以跨多个云服务提供安全态势的综合直观表示；可以存储整合的事故信息供审计之用；而且可以将合规相关决策支持工具作为云服务加以提供。

自动更新

所述模型驱动方法支持在应用程序、特别是其交互变更时，自动更新技术安全策略实施和审计。当安全策略需求变化时可以实现同样的自动化。

最终用户组织和云提供商如何使用安全策略自动化

所述策略即服务方法消除了最终用户以及云提供商的诸多负担：

最终用户组织中的安全专家只需订阅其云订阅中的策略即服务安全选项，可能会采用一些简单的安全标记特性（或培训期开发人员），并定期检查合规报告。不过在此之前，安全专家的一个重要任务是要求其云提供商实现策略自动化（特别是针对私有云）。

最终用户组织中的应用程序开发人员/集成人员只需使用云提供商提供的、策略即服务增强的 mashup/开发工具，并且可能会采用一些简单的安全标记特性。

PaaS 云提供商将为最终用户组织实现所有这些简单性，通过执行以下步骤来实现策略自动化：首先，他们将与策略即服务提供商建立一个订阅和服务级别协议。接下来，他们将需要从策略即服务提供商那里获取模型驱动的安全自动化软件和实施/监控软件，并将它们分别安装到其 PaaS mashup/开发工具和运行时平台中。他们还将需要为最终用户组织提供相关的安全订阅选项、手册和对策略即服务提供商创建的合规报告的访问权限。在短期内，与公有云提供商相比，私有云提供商将更有可能提供这种服务（参见下面的案例研究），因为私有云用于更多任务关键型用户。

新概念还是使用过的已有概念？

一些安全工具作为云服务（安全即服务）提供，例如，用于执行 Web 应用程序测试。然而，针对授权管理的模型驱动安全方法之前没有作为云服务（策略即服务）实现（据本文作者所知），主要是由于标准，特别是 PEP，采用起来比较缓慢。通过直接与云提供商协作，作者为 OpenPMF 参考实现避免了这一问题（参见 案例研究）。这样一来，就可以将合适的集成点开发到其基础架构中。

案例研究

下面我们来探讨一些案例。

面向私有云的应用程序安全策略自动化

ObjectSecurity 的 OpenPMF 针对大量不同的技术实现了应用程序安全策略自动化。在传统安装中，OpenPMF 被用作一个本地开发、编排和合规监控/报告工具插件，位于一个本地安装的开发工具（例如 Eclipse，Intalio BPMS）内或与之并排放置，以保护大量平台（各种 Web 应用程序服务器、Java EE、数据分发服务或 DDS、CORBA/CORBA 组件模型或 CCM）上的应用程序。随着 PaaS 的兴起，将 OpenPMF 也作为云服务提供才合情合理。

例如，对于针对私有云的应用程序安全策略自动化，从本地策略自动化到基于云的策略自动化的所述转变被集成到了 Intalio 云中。Intalio 云是一个全栈式开源云产品，包含实现策略自动化的必要先决条件，包括使用业务流程建模的应用程序开发和集成（参见下图），以及一个基于 Web 服务的运行时平台。已经为 OpenPMF 完成了开发 (Intalio BPMS/Eclipse)、运行时 (Apache Axis2) 和身份验证/加密（安全套接字层或 SSL/传输层安全或 TLS）的当前技术集成。图 3 显示嵌入到 BPM Web 服务编排工具中的策略自动化特性（菜单 OpenPMF > Generate Security Policy）。只需单击一下，就可以自动生成特定应用程序的详细技术安全规则（参见图 4）。

图 2. 安装（面向云平台提供商）

图 3. 自动策略生成（面向 PaaS 用户）

图 4. 技术策略部署（面向 PaaS 用户，或全部隐藏）

图 5. 运行时监控（用户和策略即服务提供商）

云和 SOA 的模型驱动安全部署

一家应用程序安全策略自动化供应商 ObjectSecurity 和主要承包商 Promia（政府和行业安全技术供应商）目前正在为美国海军在实际作战部署中实现模型驱动安全策略自动化。这一部署远比本文所述部署全面，它处理云和 SOA 体系的所有层，特别是应用程序、中间件、虚拟机、操作系统和网络。项目提供一种有效的方式，为动态变化的互联 SOA 和云应用有效管理信息安全，特别是提供一个可促进敏捷变更、快速认证和灵活策略管理的设施。

所用的技术（参见图 6）包括：ObjectSecurity OpenPMF 模型驱动安全，应用程序安全监控和策略管理；Promia Raven 入侵检测，监控，审计和 XML 信息交换功能；实施一个安全开发生命周期的安全增强的云和 SOA 开发和部署工具；可扩展的基于授权的访问控制 (ZBAC)，用于分配授权；一个加固、受信任的运行时平台，提供全堆栈保护，可托管 SOA/云应用和保护；一个提供全局全堆栈策略管理和自动化、报告、认证自动化和决策支持、配置、版本控制、扫描和测试的管理系统。

图 6. 模型驱动安全策略自动化的实现

结束语

综上所述，本文指出，敏捷分布式应用程序格局（比如云 mashup）的安全和合规策略管理需要以模型驱动且自动化的方式进行，才能具有敏捷性、可管理性、可靠性和可扩展性。这涉及到两个核心概念：首先，将策略配置作为基于订阅的云服务提供给应用程序开发工具（策略即服务）；其次，将技术策略生成、实施、审计和更新嵌入云应用程序开发和运行时平台中。通过将云应用程序和 mashup 的安全和合规策略自动化迁移到云中，云应用程序和 mashup 在云采用背后的总体理论基础内更加无缝地受到保护。这也改进和简化了云应用程序的安全软件开发生命周期。

下面是开始应用模型驱动安全自动化的后续步骤的几个具体建议：

试用

云提供商应当尝试将安全策略自动化嵌入其平台（例如，为 Eclipse 获取 ObjectSecurity 免费试用版）。对于云用户来说，如果您在支持模型驱动 mashup 和策略自动化或至少授权管理的 IaaS 或 PaaS 云中构建云应用程序，可以试用模型驱动安全策略自动化（例如，为 Intalio 云获取 ObjectSecurity 工具免费试用版）。

规划架构并推广愿景

如果您处于云采用的规划阶段，那么您应当规划您的架构来支持策略自动化，即使您没有从头开始实现它。模型驱动的 mashup 工具在支持策略自动化方面尤其有效，而且在劝说您的管理层采用策略自动化和 mashup 工具时，您可以使用 “总和大于部分” 这一论据。

如有可能，可要求您的云提供商实现策略自动化

向您的云提供商表明，有技术和方法可供使用，以及它们如何帮助您更经济高效地处理云安全性。默认情况下，云提供商似乎提供 “要么接受要么放弃” 的云产品，这些产品无法协助安全专家最好地完成其工作。遗憾的是，一些云提供商（特别是 PaaS）不对外开放其基础架构，因此集成您自己的策略自动化产品可能是一个挑战。安全专家需要提出正确的问题让云提供商朝着正确的方向发展，或选择一个更开放的云提供商。

适时集成第三方策略即服务

如果您要为大型组织部署私有云，可以考虑使用基于标准的第三方云应用程序安全策略自动化产品；这样一来，您就可以从第三方安全专家那里订阅策略即服务，同时应用程序层实施通过云提供商的基于标准的特性完成（例如，可扩展访问控制标记语言 (XACML)）。

适时集成第三方事故监控和分析服务

上述情况同样适用于监控。如果您的云提供商不提供您需要的东西，确保以标准格式（例如 syslog）导出警报，以便由第三方产品做进一步处理。