742
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
dingybin 2016-09-29
- 打赏
- 举报
OpenStack项目本质复杂，常由许多独立的子项目组成。当下，OpenStack逐渐成熟、被愈发广泛采用，这让如何加强OpenStack在生产环境中的安全性随之成为备受关注的话题。
同时，OpenStack每半年发布一次的新功能也是安全隐患的一大来源。近期在glibc和OpenSSL发现的安全隐患显示，一个组件可以影响整个系统的安全性和可靠性。其实安全威胁是IT产业中所不能避免的 – 无论怎样的架构、技术，都会涉及到。鉴于此，如何化解安全隐患，确保云的安全可靠，是值得探讨的话题。
针对OpenStack云，一些高效、高可用的工具和实践将可有效的防御安全攻击，确保其行业合规性。本文将分两部分，首先探讨OpenStack云最常见的安全威胁，再通过安全领域的最佳实践与建议，介绍应对安全威胁的一些工具和方法，
OpenStack云可能面临的安全威胁
针对软件，根据攻击媒介，安全威胁可分为以下几类：
欺诈 – 伪装成自身真实身份以外的体积。
篡改 – 修改磁盘内容、网络或内存里的内容
否认（Repudiation） – 否定某个行为或声称无责
信息泄露 – 向无授权人员泄露敏感信息
拒绝服务（DoS）– 吸收、占用正常提供服务所需的资源
权限升级 – 允许访问人完成无权限完成的行为，
安全威胁可来自外部、云提供商，亦可来自某个租户，同时攻击云租户与云提供商的基础架构。以下是一些较常见的威胁：
外部威胁 – 攻击者利用用户虚拟机中的安全隐患将之控制，之后横移至云中的其他虚拟机，直到攻击者得其所望。
来自云提供商 – 攻击者可利用云中的错误配置实现权限升级或信息泄露。举例:攻击者可发布新的虚拟机，附带被已在运行中的用户VM使用的存储卷以获取敏感用户数据。
来自其他租户 – 攻击者可以运行权限升级，脱离其自身VM，控制主机或其他租户。这里，攻击者将可接入共享的资源，例如存储或网络资源等。
化解OpenStack云安全威胁 – 一些建议
防御欺诈攻击：
使用公钥基础架构（PKI，Public Key Infrastructure）实现身份验证；
使用认证完善的SSL/TLS 作为HTTP会话保护；
在结点部署时修改厂商的初始密码；对于云用户亦是如此
使用OpenStack Keystone与LDAP/Active Directory的整合，确保验证系统、密码政策及账户的安全性。
防御恶意篡改：
使用数字化签名确保数据安全。OpenStack Algorithm。Mitaka版本将对此做出改善；
使用强制访问控制（Mandatory Access Control, MAC）以及基于角色的访问控制（Role Based Access Control, RBAC）保护OpenStack服务；
防御恶意否定：
起用登录及安全审计；
使用集中化日志管理机制；将日志内容尽可能实时发送至安全的远程高可用SIEM系统；
监控租户网络，及时发现异常状况 – 最好的方式是针对已知漏洞使用基于网络的入侵检测及防御系统（IDS/IPS）; 针对zero-day漏洞使用沙盒系统。
防御信息泄露：
使用存储加密（OpenStack Cinder与libvirt都可支持存储卷加密）；
为用户的工作负载使用OpenStack许可、域、租户及组实施MAC/RBAC；
防御DoS攻击:
为域、项目及用户设定配额，实施OpenStack HA最佳实践。HA架构以冗余为基础，所以运维人员可以安全的隔离、关闭受影响的实例，而剩下的实例依旧可正常运转。
使用OpenStack availability zones实现物理隔离或冗余；
HTTP可反转REST API端点的代理服务以及在DMZ中可用来从直接访问中隔离OpenStack服务的HTTP应用。每个代理服务由一台Linux服务器+尽量小的程序包组成，可被轻易维护，亦可用作HTTP负载均衡器、已加密的连接的HTTP加速器及安全网关来高效防御DoS/DDoS攻击。
防御恶意权限升级
用SELinux/AppArmor为管理程序及OpenStack 服务实施MAC/RBAC；
将OpenStack服务放于DMZ内，只允许对API端点的访问。
防御来自云租户的威胁
为租户采用单独的云
采用 per VM 或 per 租户存储加密
OpenStack Nova为Filter Scheduler设有Trusted Filter功能，用来将工作负载只分配给可信的计算资源。对执行资源没有特殊要求的工作负载可根据使用率被分配到任意结点，而对此有特定要求的工作负载将只会被安排到可信的结点。
防御来自云提供商的威胁
监控东西向（服务器间）的流量异常
云加密
OpenStack支持多种加密算法，可用于身份识别和授权、确保数据传输的安全性、保护数据。一些常用加密算法包括：
针对密码的加盐加密：具有唯一性，随机产生；
用椭圆曲线密码（Elliptic Curve Cryptography，ECC）代替RSA/DSA – ECC可以使用相对更小的密钥提供同等加密，所以基于ECC的算法速度更快。
使用Diffie-Hellman密钥交换协议/算法作为在公共渠道交换密钥的方式
主机安全性
以下清单可用来确保OpenStack主机的物理安全：
及时完成固件的安全更新 – 近期发现的AMD安全隐患(http://www.theregister.co.uk/2016/03/06/amd_microcode_6000836_fix/)显示，CPU中的微代码亦可存在隐患；
及时安装来自操作系统厂商的安全更新（完成测试后）;
管理员功能需根据具体网络及工作站受限 – 管理员应该只能从特定网络或工作站接入；
为更改服务器配置建立严格的管理流程，保存全部配置信息，在上线前全面测试；定期根据最后应用的配置核实系统文件；
使用按服务器分配的iptable过滤进入及输出连接及协议，通过流量限速（例如SSH协议）完成简单的进入链接节流至服务；
在设置中限制SSH协议：只使用推荐的密码，禁用第一版本的SSH协议；仅允许特定用户使用SSH、禁用root登录及密码验证，使用chroot将用户锁定在其原始目录，等；
使用SELinux/AppArmor作为为GNU/Linux加强安全性的机制以实施强制访问控制（mandatory Access Control, MAC）；
下期内容中，我们将对针对不同OpenStack组件探讨如何防御安全威胁。
上期内容对安全攻击的不同种类和各自定义做出了明确阐述。本期内容将针对不同的OpenStack组件，探讨可以怎样加固其安全性。
OpenStack CLI
用户名和密码对于OpenStack CLI 工具的使用必不可少。很多OpenStack使用手册建议使用在OpenStack RC文件中定义的OS_USERNAME 和 OS_PASSWORD环境定量，但将身份证书信息保存为未加密的文件必然不是最好的安全实践。
更为安全的做法是使用OpenStack CLI工具为每个请求申请不同的户名和密码，或使用预定的 authentication token。位于DMZ中的指定节点或VM亦可成为OpenStack CLI 工具的专属节点，确保只有来自可靠网络的SSH接入被允许，不必要的服务和Bash历史记录可被禁止；网络日志被全部存放于远程、安全、高可用的存储池。
Nova
Nova是OpenStack服务中最为复杂的一个，需要与诸多其他服务保持联系且配置选择繁复。也正因此，Nova是确保OpenStack服务安全性的首要重点。
Nova配置文件的所有者该是root，配置文件群组该是nova；权限该是640 (所有者：读/写权；群组：只读权)。
禁用管理程序的PCI passthrough 功能，以限制VM到主机硬件，例如DMA，的直接访问。
使用sVirt或SELinux/AppArmor 将管理程序放进单独的安全体系。
一些管理程序可能带有内存优化技术，为主机上的VM完成内存页面去重。举例: Xen有Transparent Page Sharing (TSP) 功能；KVM有Kernel Samepage Merging (KSM)。用户可采用严格的租户分离应对云租户威胁，进而为需要的计算节点禁用管理程序的内存优化技术。
将管理程序日志存放于安全的远程存储位置。
严格监控管理程序的可执行文件的完整性；基于Debian的操作系统可使用debsums；基于红帽的可选择rpm –V。
为可执行的管理程序使ASLR (Address Space Layout Randomization)和PIE (Position Independent Executables)；qemu-kvm可将之支持。
为VNC或SPICE会话使用TLS；
确保Nova与其他OpenStack服务，例如Keystone 或Glance的通讯（通过TLS）是安全可靠的。对于其他OpenStack服务亦是如此。
Glance
OpenStack Glance可为发布新VM提供镜像存储服务。其安全性对于确保镜像安全十分重要。
不要使用来源不明的提前建好的镜像或Docker 容器。
启用Glance image signing (已被Mitaka 支持)。
Neutron
Neutron的角色是在云中为VMs提供网络连接与IP地址。Neutron 的架构是基于插件的，所以了解哪些插件为必需、哪些为第三方解决方案，之后再按需完成禁用是非常必要的。
为OpenStack服务使用独立的管理网络；
使用VLAN或基于GRE隧道的L2隔离；
在Neutron中启用安全组，并且禁用Nova安全组(所有Nova 安全组都该转发至Neutron)；
用TLS确保Neutron API端点的安全性；
使用iptables 和ebtables规则防止MAC和ARP欺骗攻击；
使用网络配额机制预防DoS攻击；
信息队列 (RabbitMQ)
消息队列的角色在于促进OpenStack服务间的通信，而RabbitMQ是OpenStack云最常见的解决方案。鉴于OpenStack无法支持message signing，消息队列需确保OpenStack服务信息传输的安全性。
删除RabbitMQ的来宾账户；
为不同的OpenStack 服务提供独立的RabbitMQ实例，使用唯一校验体，并设置独立的权限。
用TLS确保RabbitMQ API的安全性；
将RabbitMQ 日志存放于安全的远程存储位置；
Keystone
Keystone为其他OpenStack服务提供身份服务，需妥善保护以避免欺诈及其他攻击。
利用外部认证系统，例如Apache HTTP服务器，启用多维度认证；
默认情况下，token的失效时间为1小时，而我们的建议是在允许OpenStack服务完成请求的情况下尽量缩短此时长。需注意，一些请求需要较长时间完成， 例如需Nova的镜像迁移操作。
使用专为REST API设计、比常规token更安全、占用资源更少的Fernet tokens；
使用Keystone域实现对于租户更细粒化的管理；域的管理人可以创建用户、群组和角色。
Cinder
Cinder的角色是为管理块存储设备提供高级API，主要被Nova使用。Cinder可能受到的攻击模式包括DoS、信息泄露及篡改等。
配置文件的拥有者该为root；配置文件组该为Cinder；权限该为640（拥有者权限：读/写；组权限：只读）。
为请求数量设定上限 – 默认配置对请求数量没有限制，因此可能受到DoS攻击。
启用volume wiping 确保Cinder卷删除的安全性；
Swift
Swift 可为OpenStack提供持久化的对象存储，主要保存Glance镜像。因此其安全性亦较重要。
配置文件的拥有者该为root；配置文件组该为swift；权限该为640（拥有者权限：读/写；组权限：只读）。
为存储节点启用独立的网络；
启用防火墙来保护代理节点上的公共界面。
以下是一些OpenStack 安全性相关的项目：
Barbican
OpenStack Barbican是一套为OpenStack云而建的PKI与密码服务，已与Havana发行版一起发布。Barbican可支持TLS认证必需的可信CA、透明加密、Cinder LVM卷的密钥分发、KDS信息签注服务及Swift对象加密。
Anchor
Anchor是为启动密码信任而设的任轻量级PKI服务。Anchor通常采用时长在12-24小时的短期认证。
服务质量即服务(Quality of Service as a Service, QoSaaS)
服务质量即服务（Quality of Service as a Service, QoSaaS）目前正在开发中，将提供流量成型、按端口、网络、租户的流量限速以及流分析。
防火墙即服务（Firewall as a Service, FWaaS)
防火墙即服务(Firewall as a Service, FWaaS)目前正在开发中，其目标是为传统的L2/L3防火墙提供统一API；为 OpenStack云提供下一代防火墙
负载均衡器即服务（Load Balancer as a service，LBaaS）
现有的LBaaS 实施大多基于HAProxy，但此项目的目标是利用企业级硬件和开源的负载均衡技术完成实际的业务负载均衡请求。
结论
对于OpenStack云安全，除上述建议之外，实时跟踪OpenStack安全隐患、 更新OpenStack环境同样重要。加固OpenStack云的安全性需涉及多个层面，从物理(数据中心设备和基础设施)层开始，到应用层(用户工作负载)和组织层（与云用户签订的，涉及隐私、安全和可靠性的正式协议）。与OpenStack安全相关的话题有很多，希望这两期内容对如何加固您的OpenStack云有所启发。
