对OpSource——我们不提亚马逊Web服务(AWS)、Rackspace、Terremark和其他企业——来说，这个答案就是2层VLAN。在OpSource案例中，用户使用VPN客户端或站到站VPN隧道连接到云中。这种做法让公有云成为私有云的延伸，从而使其成为一种安全的混合云。
美国国家公路交通安全管理局(NHTSA)在2009年时花费了30天时间建设并测试了为总统奥巴马的《协助消费者回收暨节约法案》所构建的基础设施，NHTSA的答案是来自Layer 7科技公司的CloudSpan CloudConnect网关。这种服务允许NHTSA将其服务器放置在公有云中，并加以适当的安全控制。结果是，这个被消费者称为“旧车换现金”的法案让超过69万的美国人领到了货币补贴，可以用旧车换辆更新、更清洁、更安全的新车。
具有VPN功能的公有云和附加的安全层，如CloudSpan，还只是众多解决公有云安全问题的其中两例而已。每个个案都有自己的长处和短处，缺陷中有成本、复杂性、性能和延迟开销等。
组织可以优化这些解决公有云安全的方法，这要依据某个应用到底是不是关键任务，以及如何保证该应用所需的数据安全而定。下面是十个强化公有云安全以支持企业级应用的方法。
1、为公有云选择合适的应用
有些企业，包括大多数新创企业，一开始都会为其所有应用采用公有云服务，包括关键任务应用及其相关数据。例如快速成长的社交媒体网站Pinterest就使用了150个AWS实例，所存储的数据目前已超过了400TB，这样一个新创企业就把自己的所有应用都放在了公有云上。
然而，公有云并不适合于所有组织，也并不适合于一个组织内的所有应用。一般来说，适合于公有云的企业应用都没有很严格的安全要求。在网站、应用开发、测试、在线产品目录和产品文档等案例中，大多数云服务提供商(CSP)所提供的默认安全足以应付此类应用的安全需求。
2、如有必要，评估并强化安全
CSP所提供的公有云安全可以说千差万别。因此在评估CSP时务必注意这一点。ISO/IEC 27000标准系列提供了系统研究信息安全风险、重视各类威胁、漏洞及其影响的各种准则，用于设计和实施一套全面的信息安全控制系统，采用可确保准则遵照执行的管理流程。
正考虑将敏感应用及其数据迁移到公有云的组织需要根据这些标准来评估和比较不同CSP的安全措施。如有必要，在组织内部私有云所使用的安全措施也可扩展到其公有云实例中。如上所述，诸如CloudSpan等公司的产品允许组织在私有和公有云实例上强制执行相同标准的信息和应用安全策略。
3、确认并使用适当的第三方审计服务
在考虑安全合规性时，组织不能简单地相信CSP的宣传。第三方审计服务可以审计CSP的流程及相关程序，看他们是否符合安全标准，是否一致等，并可将它们与CSP对客户的承诺进行对照。SAS 70 Type II标准规定了此类审计至少需要延续6个月甚至更长时间。将一些应用迁移到公有云中，并在一定延长期内对其加以审计，可以为组织提供一定的适应期，以便企业能更自信地将更多敏感应用及相关数据迁移到公有云中。
4、增加身份验证层
大多数CSP都会为公有云实例提供良好的身份验证服务，但是像SaaS安全厂商CloudPassage的产品Halo NetSec还额外增加了一个身份验证层。这里你需要权衡，是需要更好的公有云安全还是需要降低可能增加的网络延迟成本、可能带来的性能退化以及额外增加的故障点。
5、考虑附加安全对集成的影响
大多数领先CSP提供的默认安全已经相当强大。在其上再增加公有云安全措施可能会影响到整体的应用性能，同时还会让认证和接入管理工作变得更复杂。如果企业的关键任务应用需要与其他业务应用集成的话，那么这些考虑因素就更加重要了，因为最终用户不喜欢应用在他们需要的时候急忙打不开。
6、把安全条款放在SLA的最前面
在运行私有云时，你会有一些工具让你知道何时以及何地可能发生安全泄露。但是一个CSP的客户如何才能不断获知此类安全泄露事件呢?
CSP所提供的公有云安全保障不是最好的，除非在签约时写成书面的SLA条款，除非透明监控和报表功能对云客户来说是可用的。CSP自拟的合同在这方面可能毫无用处。
7、坚持透明的安全流程
在SLA中对透明和可检验的安全流程、程序以及实践的要求远远超出了对潜在的数据泄露风险的要求。在企业租借托管服务器时，至少还有一个物理的场所在，你还可以看见放置物理服务器的机柜。而在公有云中，你却无法准确地知道企业云实例的物理行踪，你所有可依赖的只有CSP为你提供的信息。这也是为什么透明是如此重要的原因。
8、简化日志和监控
仔细考量CSP云实例的监控和日志是确保公有云安全的另一个关键。在签署SLA之前，比较一下各家CSP的日志和监控实践，或许能揭示出各家CSP所提供的安全措施之间的细微差别。
9、加密
你可以使用自己的加密方法，而不使用CSP所提供的方法。虽然CSP会对信息加密之后再发送到公共互联网上，存储在公有云中，但CSP还要发送加密密钥。这可能会让组织感觉不放心，因为密钥有可能会在发送途中落入恶意分子手中。
有不少可安装产品或SaaS厂商都可以联机进行这类加密。这样做时，只有客户和第三方厂商指导密钥，CSP则无法获知。
10、采用多家、冗余的CSP分散风险
从多家厂商购买连接数据中心的高带宽，是一种常见的做法，这是因为企业希望将风险在多家提供商之间分散。如果一家CSP宕机，其他厂商依然可以正常运行。目前，有不少云配置工具都已集成在了领先CSP的服务中。
企业可以按需自动启动多个CSP的附加的服务器实例，有些网站如Pinterest(下午和傍晚)和Netflix(周末)可以在峰值期间提供此类实例。在此处，如果CPU使用率达到某个阀值，附加的实例便会启动，而当使用率下降时，实例便会关闭。
在启动附加实例时，采用循环方式使用不同CSP的实例是很合理的。例如，第一个实例使用AWS的，第二个使用Rackspace的，第三个使用OpSource……等等。如果采用这种方式，那么6月29日发生的AWS服务中断事件就不会对组织的应用造成不利影响了。
权衡公有云的安全与性能
虽然安全是很多组织在使用公有云作为IaaS时的首要关注问题，但是也有不少方法可以有效地解决这一问题。最简单的方法就是只将最不敏感的应用和数据迁移到公有云中。
如果组织决定把关键任务应用迁移到云中，则需要在CSP所提供的安全措施之外再增加一些安全措施。不过在增加公有云安全层时总是需要进行一番权衡的，因为这样做有可能增加故障点或导致应用运行得更慢。在安全和性能之间寻找恰当的平衡点可能是困难的，但努力实现这种平衡则会让组织感到安心。