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

简介 云应用开发者以及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）等演化中标准的支持。 监理与安全职责：云消费者与提供商的监理与安全管理职责应该被表述清晰。 云安全威胁与防御 云计算是否给你的应用加重了安全威胁？哪些相关的新威胁？哪些传统的威胁增强了或者减弱了？这些问题的答案都依赖于实际所使用的云服务部署与运维模型的结合方式。下图展示了在对部署到云的应用架构设计时，对安全控件应该考量的依赖： 公有／混合云——威胁 私有云——威胁 防御措施 IaaS · OWASP Top 10 · 数据泄漏（ACL不充分） · 由于管理台错误配置的权限升级 · 利用虚拟机弱点 · 通过API的DoS攻击 · 授权钥的防护过弱 · 虚拟机隔离失败 · OWASP Top 10 · （内部人员）数据盗窃 · 由于管理台错误配置的权限升级 · 针对OWASP Top 10脆弱点测试应用程序与API · 强化虚拟机镜像 · 包括加密、多因子认证、良好粒度授权、日志等的安全控制 · 安全自动化——自动配置防火墙策略、授权帐户、DNS、应用程序身份（详见下文） PaaS ［除了上述的威胁，还包括——］ · 通过API的权限升级 · 平台服务中（如消息队列、NoSQL、Blog服务）的权限弱点 · 运行时引擎中的脆弱点导致租用者的隔离失败 ［除了上述的威胁，还包括——］ · 通过API的权限升级 除了上述对信息保密性和完整性的威胁，对服务可用性的威胁也需要被作为设计时应该考量的因素。请记住安全架构的基本宗旨就是设计控件保护信息与服务 的保密性、完整性和可用性（Confidentiality、Integrity、Availability，以下缩写为CIA）。 针对云服务可用性的威胁—