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

简介

云应用开发者以及DevOps人员已经针对IaaS（Amazon AWS、Rackspace等）和PaaS（Azure、Google App Engine、Cloud Foundry等）平台成功开发了数以万计的应用。这些平台提供了基本的安全机制，诸如认证、DoS攻击防御、防火墙策略管理、日志、基本用户与帐户管理等，但是安全顾虑依然是企业级云实施的首要障碍。对云的安全顾虑，从安全配置部署于IaaS平台之上的虚拟机到在PaaS云上管理用户权限，不可谓不广泛。

鉴于云服务能够以多种方式进行提供，例如服务交付模型（SaaS、PaaS以及IaaS（SPI））与运维模型（公有、私有以及混合）的任意混合形式，云安全顾虑与解决方案都是依赖于上下文（模式）。因此，解决方案架构应该基于云应用架构去适配这些顾虑、并构建安全护卫（控件）。

如此，在云应用架构师与DevOps人员在针对IaaS和PaaS平台开发应用之时，他们有哪些架构框架和工具可以使用？在本文中，我将讨论如何将“足够的”安全性植入到部署于IaaS和PaaS云上的应用。

云安全－共同的职责

首先，让我们讨论云安全的运维模型。由定义来看，公有云的云安全是在云消费者（你的企业）和云服务提供商共同的职责，然而在私有云里面，消费者自身需要管理云平台的各个方面。云服务提供商负责确保公用的基础设施，其中包括路由器、交换机、负载均衡、防火墙、虚拟层管理程序（hypervisor）、存储网络、管理平台、DNS、目录服务以及云API。

下图描绘了云服务中各个层次的安全职责由提供商与消费者共同承担。

在与某提供商签下合约之前，对云的服务能力做一次峰值分析非常重要。这一练习能给云平台的成熟度、透明度以及与企业安全标准（如ISO 27001）和通用标准（如PCI DSS、HIPAA与SOX等）的遵从度提供指标。云安全成熟度模型可以帮助加快应用向云移植的战略。下面是你在评测云服务提供商的安全成熟度之时可以使用的一组原则：

• 公开安全策略、遵从性与实践：云服务提供商应该展示其与行业标准框架（诸如ISO 27001、SS 16以及CSA云控件矩阵等）的遵从度。由提供商授证的控件应该满足你的企业数据保护标准所要求的控件标准。当云服务满足ISO 27001或者SSAE 16的要求时，控件的范围应该被公示。托管受管数据的云必须遵守诸如PCI DSS、Sarbanes-Oxley和HIPAA的规定。
• 在被要求时公开：云服务提供商在由于法律或管理需要必须公开之时应该公开相关的数据。
• 安全架构：云服务提供商应该公开安全架构细节——它们可能帮助或者会阻碍企业标准要求的安全管理。例如，保证租用者之间互相隔离的虚拟化架构应该被公开。
• 安全自动化： 云服务提供商应该通过发布支持下述操作的API（HTTP／SOAP）支持安全自动化：
  • • 以XML或者企业日志标准格式导出和导入安全事件日志、修改管理日志、用户授权（权限）、用户帐户、防火墙策略、访问日志。
    • 持续安全监控，包括对如云审计（Cloud Audit）等演化中标准的支持。
• 监理与安全职责：云消费者与提供商的监理与安全管理职责应该被表述清晰。

云安全威胁与防御

云计算是否给你的应用加重了安全威胁？哪些相关的新威胁？哪些传统的威胁增强了或者减弱了？这些问题的答案都依赖于实际所使用的云服务部署与运维模型的结合方式。下图展示了在对部署到云的应用架构设计时，对安全控件应该考量的依赖：

除了上述对信息保密性和完整性的威胁，对服务可用性的威胁也需要被作为设计时应该考量的因素。请记住安全架构的基本宗旨就是设计控件保护信息与服务的保密性、完整性和可用性（Confidentiality、Integrity、Availability，以下缩写为CIA）。

针对云服务可用性的威胁——云服务（SaaS、PaaS、IaaS）可以通过DDoS攻击或者由云服务操作人员或者消费者错误的配置破坏。这些错误可能会蔓延到整个云，破坏托管云应用的整个网络、系统和存储。为了达到持续可用性，云应用的架构应该可以能够承受处于单个数据中心或者某个地理地区（Geographic Region）的破坏。最近的亚马逊服务不可用事件——某个弹性块存储（Elastic Block Storage，EBS）导致了部署于US东部地区（east region）整个可用区（Availability Zone）的客户应用不可用——就极好地解释了这一弱点。然而，架构可以容忍整个地区（Region）出错的应用则极大地避免了这次服务不可用的影响，并且继续向用户提供服务。作为设计原则，假设云中的所有事物都会失败，并且针对失败去设计。应用应该能够承受地理地区的底层物理硬件的失败以及服务崩溃。应用与组件的松耦合在后一种情形下可以起到作用。

云安全架构——计划

作为第一步，架构师必须理解云平台（PaaS、IaaS）提供了哪些安全能力。下图解释了云服务安全性的架构。

云提供商的安全服务与能力不断演化，而且互相不同。因此你经常会发现安全机制，如钥（key）管理和数据加密，将不可用。譬如对于加密安全制物的 AES 128位加密服务的需要，又譬如存管于钥管理服务的钥。对于这些关键服务，你需要继续依赖内部的安全服务。对于如此依赖于内部服务的应用，“混合云”部署架构模式或许是唯一可行的选择。另一常见的使用场景是单点登陆（SSO）。企业内部实现的SSO也许无法扩展到云应用，除非它基于云服务提供商支持的 SAML 1.1或者2.0使用了联邦式（federation）架构。

下面是防御云服务风险的云安全最佳实践：

• 针对安全即服务（Security-as-a-service）设计架构——云上的应用部署包括了多种服务的编排（orchestraion），其中包括DNS、负载均衡、网络QoS等服务的自动化。与安全自动化属于同一范畴的还包括云安全区之间的防火墙策略、（SSL）证书供应（provision）、虚拟机系统配置、帐户权限以及日志配置的自动化。依赖于防火墙策略创建、证书供应、钥分发和应用入侵测试（pen testing）等的部署流程应该被迁移到自服务模型。这种方式将终止人工接触，也将使安全即服务的场景变得可能。最终，这将消灭因为人类错误导致的威胁、提升运维效率，并将安全控制嵌入到云应用。
• 实现声音识别、访问管理架构与实践——可扩展的基于云的集中式与弹性的架构对基于网络的访问控制将会更少依赖，并确保很强的用户访问管理架构。云访问控制架构应该给最终用户以及授权用户解决用户与访问管理生命周期的所有方面：用户权限设置（user provisioning）与取消（deprovisioning）、认证、联盟、授权和审计。声音架构将使身份与访问服务在公有云、私有云和混合云中的所有场景下的可重用性成为可能。同时采用安全令牌服务以及合适的用户与权限设置、审计跟踪是好的实践。联邦式架构是将企业内SSO扩展到云服务的第一步。这里，你可以参阅云安全联盟第12卷获取更多信息。
• 利用API自动化防护——任何新的安全服务都应该拥有API（REST／SOAP）以支持自动化。API可以帮助自动化防火墙策略、配置强化（configuration hardening）以及应用部署时的访问控制。这可以通过使用开源工具例如puppet结合云服务提供商提供的API来实现。
• 总是加密或者遮掩敏感数据——今天的私有云应用明天都可能会部署在公有云。因此无关乎未来的运维模型，应用架构应该加密所有的敏感数据。
• 不要依赖于IP地址做认证服务——云上的IP地址本就是朝三暮四，所以为了管理网络的访问控制，你不能仅仅依赖于它们。采用证书（自签名或者来自于可信的CA）以使部署在云上的服务之间通过SSL连接成为可能。
• 日志、日志、日志——应用应该集中式记录所有安全事件的日志，它会帮助创建端到端的事务视图，而且天生无可置否。对于安全事故事件，日志和审计跟踪使唯一可靠的数据，由取证工程师用以调研和弄清楚应用是如何被滥用的。云是弹性的，日志则是瞬息万变，因此周期性将日志文件迁移到不同的云或者企业的数据中心是非常关键的。
• 持续监视云服务——鉴于防卫控制可能无法满足所有的企业标准，监视是非常重要的功能。安全性监视应该利用云服务产生的日志、API和托管的云应用以执行安全事件关联。由CSA提供的云审计（cloudaudit.org）可以被用来完成这个任务。

云安全原则

每个企业都有不同层次的风险容忍，这可以从产品开发文化、新技术采纳、IT服务交付模型、技术战略以及在安全工具与能力方面的投入上看出来。当企业的业务部门决定利用SaaS产生商业收益，技术架构应该能够支撑这个模型。此外，安全架构应该与技术架构和原则一致。下面是企业安全架构师应该考虑和定制的云安全原则示例：