重新设计公共云的全套网络安全控件

一旦企业确认了安全原型（或一系列原型，每个原型与具有类似安全要求的一系列工作负载相匹配），它们就可以设计和实施网络安全控件。公司正在尝试各种控件设计，鉴于进展速度，网络安全管理人员预计，在未来三年，这些控件会发生相当大的变化，这是可以理解的。网络安全控件可以分为八个领域，组织必须将这些领域结合起来考虑。以下是八个控件领域，以及来自我们的研究的观察结果。

身份和访问管理：基于云的应用程序和数据的身份和访问管理解决方案正逐渐转移到云端。60％的受访者表示，他们现在使用本地的身份和访问管理解决方案，但只有一半的人希望在三年内使用本地的身份和访问管理解决方案。那时有60％的受访者预计，他们的企业将依赖第三方身份和访问管理服务，这些服务支持多个公共云环境，并将内部和公共云资源的身份和访问管理控件统一起来。

数据：在活动和静止的情况下对云数据加密的做法很快就会成为标准。立志使用云端的公司中有84％的公司有望在三年内对存储在云中的数据进行加密。最终，首席信息安全官（CISO）也希望有更多实用的机制来加密内存中的数据。然而，受访者有不同的方法来管理云工作负载的加密密钥：33％的人更倾向于让云服务提供商来管理密钥，28％的人更倾向于将其保留在内部，11％的人更倾向于让第三方管理密钥。

外围：企业正朝着“虚拟外围”模式发展。目前，大约40％的企业通过本地部署的数据中心对流量进行路由，使用某种形式的虚拟专用网络（VPN）或使用本地部署的工作负载和公共云负载之间的连结性，以此来作为访问公共云平台上的应用程序或数据的唯一方式。但49％的受访者表示，他们希望公司在未来三年内使用第三方的外围控件。向这些周边控件模型的过渡往往涉及到这样的做法——凭借一系列服务来开发清理设计，例如安全性Web网关、Web应用程序防火墙以第三方提供的网络监视机制，这些机制支持多重云。

应用程序：大多数受访者（84％）为基于云的应用程序定义了安全配置标准，并依赖云服务提供商来实现这些标准。但85％的受访者表示，由于工作负载迁移到云端，他们的公司可能会促进更多的开发治理。这种治理很可能是软治理，只有20％的企业使用应用程序的安全性工具或模板。

运营监控。56％的企业依靠当前的安全信息和事件管理（SIEM）工具来监控云应用。这使它们可以统览内部部署的工作负载和云工作负载。另有30％的企业使用云服务提供商提供的其它本地监控工具或从云服务提供商那里获取日志，以使用专门的数据分析解决方案生成洞察。由于云服务提供商可以提供丰富的监控数据，因此组织必须与它们协作，选择能够提供统览内部部署的工作负载和公共云工作负载的解决方案。

服务器端端点：受访者对云服务提供商提供的服务器端的安全性充满信心：51％的受访者表示，他们对服务器端的端点的云服务提供商提供的安全性高度适应。很多公司（特别是那些安全程序不太复杂的公司）认为，云服务提供商能够洞悉并控制它们的服务器群，这比公司内部做效果更好。

用户端点：将工作负载迁移到云往往需要更改用户设备的控件，这主要是为了防止数据丢失以及防御病毒和恶意软件。70％的受访者表示，如果使用公共云基础架构，他们的企业就必须更换用户的端点控件。

监管治理：大多数网络安全计划受数据保护法规（如欧盟通用数据保护法规），数据的位置、主权以及个人身份信息的管辖。金融机构和医疗组织也受制于行业特定的法规。与我们交谈的高管中有50％的人表示，他们希望云服务提供商共同负责法规的合规。

在选择控件时，组织应结合这八大领域并构建全面的网络安全架构，而不是采用零散的方法。公司可以根据威胁情景和所需的安全级别设计控件，然后应用合适的安全性模型原型（例如回传或清理）来确定最佳的安全控件及其范围。公司还可以与云服务提供商合作，以确定要使用哪些控件以及从第三方采购哪些控件。最后，公司必须对可以标准化和自动化的控件进行筛选并确定其优先级，并在敏捷迭代中实现这些控件。

与提供商的工作相比，明确了网络安全的内部责任

当企业将应用程序和数据迁移到公共云时，它们必须依靠云服务提供商和第三方提供商进行某些安全控制——但它们不应该指望这些提供商提供所有必要的控件。除非公司和云服务提供商明确划分了公共云环境中网络安全性方面的所有责任，否则有些责任可能会落空。这使公司不得不做出这样的举动——让云服务提供商提供统览安全运营模型以及随着这些模型发生变化的及时更新，从而开发并清楚地理解云服务提供商所提供的控件。（云服务提供商以不同的方式组织网络安全责任模型，并采取各种方法来共享这些模型，因此每种情况都要小心处理。）这样，公司就可以设计和配置在多重云环境中运行良好并能与各种工具、处理模型和运营模型很好地集成的控件。

根据我们的经验和研究，我们发现企业可以从整个网络安全生命周期（从设计到实施和持续运营）中与云服务提供商合作中获益。然而，四个主要领域成为公司与其云服务提供商之间合作的首要任务。

控件和程序的透明度：公司应该让云服务提供商对安全控件、程序和所有的泄密事件提供最大限度的可见性。公司还需要了解每个云服务提供商进行安全审计和渗透测试的能力。

法规合规性方面的支持：公司应要求云服务提供商提供这样的详细说明——与监管合规性有关的保证，并询问他们如何及时了解每个行业的监管变化，并相应地更新合规机制。

集成的运营监测和响应：在以支持集中安全管理的方式集成安全信息和事件管理（SIEM）工具时，公司可能必须与云服务提供商合作。公司必须要求云服务提供商持续为其提供全面的报告，洞察和威胁警报。公司可以将洞察传授给云服务提供商，帮助它们为所有租户开发新功能。公司还必须确保云服务提供商以公司可以使用内部部署分析工具处理的格式使日志随时可用。

多云的云身份和访问管理（IAM）功能。公司应该坚持要求云服务提供商提供原生的多因素身份验证（native multifactor authentication）。使用身份即服务（IDaaS）或本地身份和访问管理解决方案的人必须与云服务提供商合作才能正确地将它们集成起来，以便它们可以为多个公共云环境提供足够的支持。公司还应该让他们的云服务提供商共享云身份和访问管理的路线图，以便它们可以计划利用行为认证和基于角色的访问等功能。

将开发运维应用于网络安全

开发运维是一种越来越流行的集成开发和IT运营的方法，这种方法支持持续交付新的软件功能，这在某种程度上是通过为开发人员提供访问运营服务的API来实现的。Secure DevOps（有时称为“SecDevOps”或“持续的安全性”）将安全评估、安全控件的实施以及安全技术的部署与开发运维方法集成在一起，很多团队已经采用了这样的方法迁移到云中。只要在整个开发周期内对安全服务进行自动化并通过API提供安全服务就可以实现集成。

Secure DevOps用缩短部署时间和降低风险的方式增强了云的所有类别的安全控件。例如，有些公司的政策要求对所有数据进行分类。但是，当数据只能手动分类时，必要的付出会增加部署计划的时间。通过安全的开发运维，强制数据分类变得更加实用，因为所有数据都会根据预设的规则接收默认的分类。因为有了这样的改进以及由安全的开发运维根据预设的规则提供的分类，组织可以降低公共云环境中的违规风险，同时减少或消除在存储数据之前手动对数据进行分类所造成的延迟。

采用安全的开发运维方法要求公司培养一种文化，在这种文化中，安全性是每个软件项目的关键要素，也是每个开发人员工作的特点。很多开发人员需要接受额外的安全培训，从而在公共云迁移期间和迁移之后提供有效的支持。培训还有助于开发人员了解自己所使用的工具的安全功能，以便他们可以更好地利用现有的安全性API和编排技术并创建新的技术。

公司应该简化安全治理程序，以确保这些程序不会给开发人员造成延误。随着公司对安全控件进行自动化，它们可以使控件对开发人员完全可见。这样，开发人员就可以独立检查控件是否在后台正常工作，而不是延迟工作去咨询安全专家。自动化审计安全机制的过程也大有裨益。例如，为了符合策略，公司可以要求每天晚上对这个代码进行自动扫描，并将安全组件的构建时（build－time）检查集成到应用程序中。

为了实施安全的开发运维，公司还改变了IT运营模式，因此安全实施成为云开发和部署过程的一部分。在这样的运营模式中，经过适当培训的开发团队就是安全团队；无需外部参与即可获得合适的安全性方面的专业知识。在开发团队中注入安全性方面的专业知识可以消除云部署过程中的延迟，同时使开发团队以快于传统安全模型所允许的速度进行迭代。

公司如何着手加强云中的网络安全

我们描述的构建公共云网络安全计划的四种做法应该能使公司更好地利用公共云平台。然而，设置程序可能是一项复杂的任务，因为公司有多个云工作负载，云服务提供商、内部部署的功能和私有云功能、位置、法规要求和安全要求。这个由十个步骤构成的工作计划将帮助公司在设计、开发和实施公共云网络安全计划时协调一致。

确定要迁移到公共云的工作负载。例如，很多组织一开始就选择将面向客户的应用程序或分析工作负载迁移到公共云，同时将核心事务系统保留在本地。然后，它们就可以确定所迁移的工作负载的安全要求。

至少要找到一家能够满足工作负载安全要求的云服务提供商。公司可以为不同的工作负载选择多个提供商，但这些选择应该与公司整体的云战略的目标一致。

根据迁移的简易性、安全状况、成本因素和内部的专业知识为每个工作负载分配安全原型。例如，公司可以重新设计应用程序的架构并使用默认的云服务提供商控件来实现面向客户的工作负载，并在不重新设计架构的情况下提升和转移内部核心事务的应用程序，同时对数据访问进行回传。

对于每个工作负载，请确认安全性级别，从而实施八个控件中的每一个控件。例如，公司应确定身份和访问管理是否仅需要单因素身份验证（single－factor authentication），需要多因素身份验证（multifactor authentication），还是需要更高级的方法（如行为身份验证）。

确定每个工作负载的八个控件分别要使用哪些解决方案。鉴于针对每个工作负载所确定的云服务提供商（或云服务提供商）的功能，公司可以确定是使用现有的本地安全解决方案、云服务提供商提供的解决方案还是第三方解决方案。

实施必要的控件并将其集成到现有的解决方案。这要求公司充分了解云服务提供商的安全功能和安全执行流程。云服务提供商需要对产品的这些方面保持透明。

就每个控件是否可以标准化和自动化形成一个看法。这包括分析整套控件并做出决策——哪些控件在整个组织中实现标准化，哪些控件实现自动化。

人们可以根据公司迁移的应用程序以及公司指定的安全模型来确定控件的优先级。

实现控制和治理模型。对于可以标准化但不能自动化的控件，公司可以开发查验清单（checklist），就如何遵循这些清单对开发人员进行培训。对于可以标准化和自动化的控件，公司可以使用安全的开发运维方法来创建自动化例程，以实现控件并实施标准化。

利用在第一波实施过程中获得的经验来选择要实施的下一组控制。借鉴这一经验也将有助于改进一系列后续控件的实施过程。

公司正在将更多应用程序从内部部署的数据中心和私有云平台稳步转移到公共云平台，这些平台在很多情况下都能带来卓越的成本效益、灵活性和速度。但只有在公司维护应用程序和数据的安全性时，公共云的迁移才能顺利进行——有些公司正在努力做到这一点。

我们的经验和研究表明，只要用对方法，公共云网络安全是可以实现的。公司只要开发以云为中心的网络安全模型，在八个安全领域设计强大的控件，明确云服务提供商的职责，以及使用安全的开发运维，这样它们就有更大的把握将工作负载转移到公共云中，从而保护最关键的信息资产。