经过长时间的实验，龙头企业正在认真考虑大规模采用公共云。在过去几年中，很多公司已经改变了IT战略，将越来越多的应用程序和数据转移到公共云基础设施和平台上。然而，公共云的使用颠覆了很多公司多年来积累的传统网络安全模型。因此，随着公司渐渐利用公共云，它们需要大力发展网络安全方面的实践，从而以这样的方式使用公共云——既能保护关键数据又能充分利用这些服务所带来的速度和敏捷性。
虽然迄今为止公共云的采用仍然受到限制，但未来的前景却大不同。在我们研究的公司中，只有40%的公司在公共云平台上的工作负载超过10%;相比之下，80%的公司计划在三年内在公共云平台上的工作负载将达到10%，或计划将云渗透率提高一倍。我们将这些公司称为“立志使用云端的公司”。这些公司得出的结论是，公共云为很多工作负载和实施方案带来了更多的技术灵活性和更简单的扩展。在某些情况下，使用公共云还可以降低IT运营成本。因此，公司正在云中构建新的应用程序和分析功能，并逐渐将现有的工作负载和技术栈迁移到公共云平台上。
尽管公共云平台有诸多好处，但人们对公共云的网络安全性一直心存担忧，这阻碍了公司向云端迁移的步伐。在我们对2016年的云采用的研究中，高管们将安全性视为云迁移的主要障碍之一，其它障碍包括对变革进行管理的复杂性，为云的采用制定引人注目的业务案例的难度。
有趣的是，我们对首席信息安全官(CISO)进行的研究表明，他们的目光变得更长远了，不再局限于“云安全吗?”这样的问题。在很多情况下，他们承认，云服务提供商(CSP)的安全资源远胜一筹，他们如今的疑问是如何安全地使用云服务，因为他们很多现有的安全实践和架构在云端不见得会更高效。如果某些本地控件(例如安全日志记录)没有重新配置，这些控件就不太可能适用于公共云平台。采用公共云还有可能放大某些类型的风险。云服务为开发人员提供的速度和灵活性也可以(在没有适当的配置治理的情况下)用来创建不受保护的环境，很多公司都发现了这样的事实，这让它们十分尴尬。
简而言之，公司需要采取主动、系统的方法，使网络安全功能可以适应公共云。多年来我们一直在云计算网络安全计划上与大型组织展开合作，并与网络安全领导者进行交流，我们相信，以下四种做法有助于公司制定一致、高效的公共云网络安全性方面的方法：
• 开发以云为中心的网络安全模型：如何在云中管理边界;在多大程度上为应用程序重新设计架构，使风险承受能力和现有的应用程序架构、可用资源和整体云战略保持一致，公司必须为此做出选择。
• 为公共云重新设计一整套网络安全控件：对每个单独的控件而言，公司都要确定应该由谁来提供控件，要达到怎样的严格程度。
• 与提供商的做法相比较，明确网络安全的内部责任：公共云需要一个共享的安全模型，提供商及其客户各自负责特定的功能。公司必须了解这种责任分配的做法(这与传统的外包安排有很大的不同)并相应地对内部流程进行重新设计。
• 将开发运维应用于网络安全：如果开发人员可以在短短几秒内启动服务器，但必须等待两周的时间才能让安全团队认同配置，这会削弱公共的云灵活性所带来的价值。公司必须通过API为开发人员提供高度自动化的安全服务，就像他们为基础架构服务所做的那样。
开发以云为中心的网络安全模型
对一家初涉公共云的公司来说，使用内部部署的系统已有的控件来构建公共云网络安全模型，这种做法是很诱人。但这可能会引发问题，因为内部部署的控件在没有进行重新配置的情况下不太可能适用于公共云平台。即使在重新配置之后，这些控件也无法在所有工作负载和云平台上提供可见性和保护。由于认识到这些局限性，这些立志使用云端的公司正在对一系列安全策略和架构进行试验，有一些原型已经问世了。
最有效的方法是根据两个因素对公司的网络安全模型进行重新评估：如何定义网络边界以及是否需要针对公共云来更改应用程序架构。边界的定义决定了云网络安全模型的拓扑和边界。与应用程序架构有关的选择可以对应用程序中的安全控件的结合起指导作用。这两个关键选择也会相互影响。例如，公司可以做出这样的选择——通过添加安全功能来使应用程序具有更高的安全性，这些功能可以在处理数据时最大限度地减少敏感数据的泄露，并且不会对应用于已知环境的安全控件做出任何臆断。
为周边的安全性选择一个模型
在这些立志使用云端的公司中，以下三种周边设计模型脱颖而出：
• 回传：通过内部部署的网络对流量进行回传或路由，半数立志使用云端的公司就是这么管理周边安全性的。该模型吸引了需要在内部使用大部分云工作负载的公司，并希望就工作负载的迁移做出特定的选择，使其符合它们所拥有的架构。在云安全方面经验不足的公司也可以从回传中受益，因为这使它们可以继续使用已然熟悉的本地安全工具。但回传也许不会长盛不衰：立志使用云端的公司中只有11%的公司表示，它们可能会在三年后使用这种模式。
• 默认采用云服务提供商提供的控件。我们研究的立志使用云端的公司中有36%的公司做出了这样的选择。使用云服务提供商的安全控件的成本可能比使用其它任何一个周边模型的成本都要低，但这却使保护多云环境变得更加复杂。对规模更大、更复杂的组织来说，使用云服务提供商提供的控件似乎是一种临时措施：立志使用云端的公司中有27%的公司表示，它们将在三年内使用此模型(比如今的比率下降了36%)。
• 清理：清理涉及到对“虚拟边界”的设计并从各种外部提供商提供的解决方案开发云特有的控件。立志使用云端的公司中大约有15%的公司使用这种方法，这种方法使公司能够应用它们能找到的最佳外围安全解决方案，并根据需要进行切换。由于不断变化的解决方案会产生技术需求，因此公司通常会在拥有足够的内部网络安全专业方面的知识来选择供应商并整合其解决方案时进行清理。尽管这些工作可以减缓工作负载迁移到云中的速度，但是清理工作似乎正在增加，立志使用云端的公司中大约有47%的公司表示，它们将在三年内使用云特有的控件。尽管清理的成本和复杂性很高，但组织还是选择了这种方法，以便它们可以支持多云环境，并在需求发展时能更轻松地替换点解决方案(point solution)。
我们研究了众多立志使用云端的公司，发现回传是最受这些公司青睐的周边安全模型。然而，企业正在转向虚拟周边模型，这些模型通过清理来开发周边模型。清理是目前管理周边安全性最不受欢迎的做法，但越来越多的高管表示，他们将在未来三年内使用清理，而不是其它模型。
决定是否为应用程序重新设计应用程序的架构
另一个选择是定义公司的云网络安全方面的立场：通过重写代码或改变应用程序的架构(或两者都做)来重新构建公共云中的应用程序。我们采访的高管中只有27%的人表示他们的公司会这样做。这样做的好处是可以兼容所有的云服务提供商(例如容器架构)、有更强的安全性(使用散列检测篡改检测，内存释放以及调用之间的数据流加密)，优越的性能(例如，通过允许水平扩展)公共云，更低的运营成本(因为应用级别的安全保护减少了公司选择最佳安全解决方案的需求)。但是，重新设计云应用程序的架构可能会降低公司的迁移率。因此，在我们的调查中，绝大多数企业(78%)都在迁移应用程序而不是对公共云的架构进行重新设计。
周边安全设计的选择(以及是否使应用程序适配公共云的选择)为云网络安全创建了六个原型。我们的经验表明，只要有五个主要标准，企业就能知道其对整体云网络安全模型所做的决策：公共云安全性方面的有效性、希望达到的云迁移率、支付额外安全成本的意愿、实施新安全计划的所要具备的专业知识、以及企业希望从安全架构中获得的灵活性。
为公共云应用程序重新设计架构可提高安全性，但这可能会降低迁移速度。回传则可以将公司已经熟悉的现有控件扩展到公共云。使用默认的云服务提供商的控件是最简单且最具成本效益的方法。清理控件需要大量安全性方面的专业知识，但它能为多个云提供灵活性和支持。组织可以使用这些标准来选择最佳方法。也就是说，公司不需要将相同的原型应用到整个公共云配置文件。对具有不同要求的应用程序来说，使用不同的原型是可能的，甚至是有利的：为了核心事务系统来能够实现更快的迁移和熟悉的控制，同时使用云服务提供商提供的安全控件来降低成本，加快部署面向新客户的应用程序。
重新设计公共云的全套网络安全控件
一旦企业确认了安全原型(或一系列原型，每个原型与具有类似安全要求的一系列工作负载相匹配)，它们就可以设计和实施网络安全控件。公司正在尝试各种控件设计，鉴于进展速度，网络安全管理人员预计，在未来三年，这些控件会发生相当大的变化，这是可以理解的。网络安全控件可以分为八个领域，组织必须将这些领域结合起来考虑。以下是八个控件领域，以及来自我们的研究的观察结果。
• 身份和访问管理：基于云的应用程序和数据的身份和访问管理解决方案正逐渐转移到云端。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运营模式，因此安全实施成为云开发和部署过程的一部分。在这样的运营模式中，经过适当培训的开发团队就是安全团队;无需外部参与即可获得合适的安全性方面的专业知识。在开发团队中注入安全性方面的专业知识可以消除云部署过程中的延迟，同时使开发团队以快于传统安全模型所允许的速度进行迭代。
公司如何着手加强云中的网络安全
我们描述的构建公共云网络安全计划的四种做法应该能使公司更好地利用公共云平台。然而，设置程序可能是一项复杂的任务，因为公司有多个云工作负载，云服务提供商、内部部署的功能和私有云功能、位置、法规要求和安全要求。这个由十个步骤构成的工作计划将帮助公司在设计、开发和实施公共云网络安全计划时协调一致。
11. 确定要迁移到公共云的工作负载。例如，很多组织一开始就选择将面向客户的应用程序或分析工作负载迁移到公共云，同时将核心事务系统保留在本地。然后，它们就可以确定所迁移的工作负载的安全要求。
12. 至少要找到一家能够满足工作负载安全要求的云服务提供商。公司可以为不同的工作负载选择多个提供商，但这些选择应该与公司整体的云战略的目标一致。
13. 根据迁移的简易性、安全状况、成本因素和内部的专业知识为每个工作负载分配安全原型。例如，公司可以重新设计应用程序的架构并使用默认的云服务提供商控件来实现面向客户的工作负载，并在不重新设计架构的情况下提升和转移内部核心事务的应用程序，同时对数据访问进行回传。
14. 对于每个工作负载，请确认安全性级别，从而实施八个控件中的每一个控件。例如，公司应确定身份和访问管理是否仅需要单因素身份验证(single-factor authentication)，需要多因素身份验证(multifactor authentication)，还是需要更高级的方法(如行为身份验证)。
15. 确定每个工作负载的八个控件分别要使用哪些解决方案。鉴于针对每个工作负载所确定的云服务提供商(或云服务提供商)的功能，公司可以确定是使用现有的本地安全解决方案、云服务提供商提供的解决方案还是第三方解决方案。
16. 实施必要的控件并将其集成到现有的解决方案。这要求公司充分了解云服务提供商的安全功能和安全执行流程。云服务提供商需要对产品的这些方面保持透明。
17. 就每个控件是否可以标准化和自动化形成一个看法。这包括分析整套控件并做出决策——哪些控件在整个组织中实现标准化，哪些控件实现自动化。
18. 人们可以根据公司迁移的应用程序以及公司指定的安全模型来确定控件的优先级。
19. 实现控制和治理模型。对于可以标准化但不能自动化的控件，公司可以开发查验清单(checklist)，就如何遵循这些清单对开发人员进行培训。对于可以标准化和自动化的控件，公司可以使用安全的开发运维方法来创建自动化例程，以实现控件并实施标准化。
20. 利用在第一波实施过程中获得的经验来选择要实施的下一组控制。借鉴这一经验也将有助于改进一系列后续控件的实施过程。
公司正在将更多应用程序从内部部署的数据中心和私有云平台稳步转移到公共云平台，这些平台在很多情况下都能带来卓越的成本效益、灵活性和速度。但只有在公司维护应用程序和数据的安全性时，公共云的迁移才能顺利进行——有些公司正在努力做到这一点。
我们的经验和研究表明，只要用对方法，公共云网络安全是可以实现的。公司只要开发以云为中心的网络安全模型，在八个安全领域设计强大的控件，明确云服务提供商的职责，以及使用安全的开发运维，这样它们就有更大的把握将工作负载转移到公共云中，从而保护最关键的信息资产。
京公网安备 11010502049343号