从云消费者的角度谈云安全架构

• 运行在云上的服务应该遵循最小权限原则。
• 多个安全区之间的隔离应该通过使用分层防火墙得以保证——云防火墙、虚拟层管理程序（hypervisor）防火墙、客居系统（guest）防火墙以及应用程序容器。云上的防火墙策略应该遵守基于数据敏感性的可信任区隔离标准。
• 应用程序应该使用端到端的传输层的加密（SSL、TLS、IPSEC）以确保数据在部署于云上的应用程序之间以及到部署于企业内部的应用程序之间的传输是安全的。
• 应用程序应该将认证与授权扩展到可信任的安全服务。基于SAML 2.0，应该支持单点登陆。
• 数据遮掩和加密应该基于数据的敏感性而采用，并且与企业数据净化标准相一致。
• 位于可信任区的应用程序应该被部署于经过授权的企业标准虚拟机镜像上。
• 在部署虚拟私有云（virtual private cloud, VPC）时，应该使用行业标准的VPN协议，诸如SSH、SSL和IPSEC。
• 云上的安全监控应该与既有的企业安全监控工具通过API集成在一起。

云安全架构模式

在架构时加入适当的保护云上信息CIA的安全控制可以防御云安全威胁。安全控制可以被作为与提供商、企业或者第三方提供商提供的服务交付（安全即服务，Security-as-a-Service）。安全架构模式通常从安全控制的角度（安全护卫）——技术与流程——进行阐述。这些安全控制和服务来源（企业、云提供商、第三方）应该在安全模式中突出强调。

安全架构模式宛如北极星，可以加速应用往云上的迁移，而又管理了安全风险。此外，云安全架构模式应该强调不同的服务与部署于云服务之上的组件的可信任边界。这些模式也应该指出标准接口、安全协议（SSL、TLS、IPSEC、LDAPS、SFTP、SSH、SCP、SAML、OAuth、 Tacacs、OCSP等）以及认证、令牌管理、授权、加密方法（哈希、对称式、非对称式）、加密算法（三重DES、128位AES、448位加密（Blowfish）、RSA等）、安全事件日志、对于策略与用户属性的真相来源（source-of-truth）及耦合模型（紧耦合或是松耦合）等机制。最终，模式应该可以被用以创建安全检查列表，需要用配置管理工具（如puppet）自动化起来。

通常，对于被云应用消费的每项安全服务，其模式都应该强调下面的属性（但是不局限于此）：

• 逻辑位置——本地到云服务、内部云、第三方云。位置可能会受到性能、可用性、防火墙策略以及服务监理的限制。
• 协议——调用服务的协议是什么？例如基于X.509证书的REST风格的服务请求。
• 服务功能——服务的功能是什么？例如加密制物、日志、认证以及机器指纹。
• 输入／输出——输入（包含控制的方法）、从安全服务得到的输出是什么？例如，输入＝XML文件，输出＝包括加密属性的XML文件。
• 控制描述——安全服务提供了什么安全控制？例如，防卫信息保密性、用户认证和应用认证。
• 执行者——谁是服务的用户？例如，终端（End Point）、终端用户、企业管理员、IT审计员和架构师。

下图是由开放安全架构组（open security architecture group，opensecurityarchitecturegroup.org）发布的云安全架构模式的子集。

该模式展示了执行者（架构师、终端用户、业务经理、IT经理）与系统（终端、云、托管于云上的应用程序、安全服务）的交付，以及为了防护执行者与系统（访问管理、DoS防御、边界防护、钥加密与管理等）而采用的控制。让我们仔细看看本模式描述的细节。

云服务提供商方的基础设施安全服务（控制）

正如本模式所展示，云服务提供商应该提供对DoS防护以及针对由手机与PC发起的会话的保密性与完整性防护的安全控制。通常，这些会话由浏览器或者客户端应用程序发起，并使用SSL／TLS进行传输，直到由云服务提供商管理的负载均衡为止。云服务提供商通常并不共用DoS防护机制，因为黑客们可以很容易地滥用它。

（内部或云服务提供商）的应用程序安全服务

安全服务，诸如用户身份识别、认证、访问管理、设备识别、加密服务以及钥管理，既可以位于云服务提供商、企业数据中心，这两者也可以结合起来。

下图的第二种模式展示了源自CSA身份域的身份与访问模式。

本模式展示了一组常见的云访问控制用例，诸如用户注册、认证、帐户权限设置、策略管理（policy enforcement）、日志、审计与计量。它强调了执行者（终端用户、企业业务用户、第三方身技人员、云服务所有者）与托管在云、企业内部或者第三方的服务的交付。

本模式阐述了下述方面：

云服务提供商方的身份安全服务（控制）

云上面运行着下述的服务：

• 认证服务支持由企业门户（本地AuthN界面）发起的、常常使用SAML协议传输的用户认证。经认证的会话在云上的会话存储之中维护。
• 帐户与用户资料设置服务支持创建新帐户和用户资料——常常是通过调用SPML（Service Provisioning Markup Language）或者云服务提供商的特定API。用户资料存储与用户资料存储。
• 云策略管理服务被用以管理策略，比如指示云上的哪个资源可以被终端用户访问。使用这项服务，云服务所有者（企业）就可以执行管理功能，而终端用户可以请求对云资源的访问。云策略都存储于云策略存储。
• 认证服务日志与审计服务支持双重功能，首先是云上事件（包括安全事件）的日志，其次是审计之用。访问这项服务时可以采用云审计协议和API。
• 计量服务跟踪了云资源的使用。财务部门可以将这项服务用于收费，也可以用于费用对账。

企业的身份安全服务

在本模式中，应用程序的子集被托管于企业内部：

• 云注册界面提供了用户注册、管理和设置新的云资源的界面服务。认证和授权是通过云服务管理的。
• 云使用报表界面可以由终端用户用来声称使用报表。
• 云配置（provisioning）服务被用来配置云资源（计算、存储、网络、应用程序服务）。访问控制（AuthN、AuthZ）和会话管理在云服务端管理了。

位于第三方的身份安全服务

在本模式下,云应用程序依赖于第三方提供并托管于第三方的身符识别服务。这些服务支持第三方用户访问云资源，代表企业执行业务功能。例如备份和应用监控服务。在该模型中,用户设置、认证和访问管理功能被委托给了第三方服务。

结论

通过了解可以利用哪些来自于云平台或服务提供商的服务，你可以将安全构建进入你的程序，而不用在你应用程序的边界之内再去重新创造这些能力——因此避免了昂贵的“附加”保障。一个良好的实践是创造可以运用在设计阶段的安全原则和架构模式。架构模式可以帮助在设计阶段就弄清楚了在哪里（云，抑或第三方，抑或企业）实施了控制，这样，适当的安全控制就被融入进了应用程序的设计中去。在创造云安全模式的时候，记住相关的威胁与“风险适当”原则。最终，云安全架构应该支持开发的需要，以保护处理和储存在云端的数据的保密性、完整性和可用性。