云环境下的安全服务架构
这几天被利用smb等漏洞入侵并使用加密勒索软件的新闻刷屏了，至少各大公有云厂商、云安全服务厂商的响应都还挺及时，更新了防护规则、漏洞检测规则、补丁升级程序，并对开启了相应服务端口的客户进行了提示告警。国内优秀的安全团队更是早在4月份NSA文件刚被公开解密后就开始了对这些问题的密切关注，并对各自有合作的云业务进行了工作开展。不难发现，利用云的力量统一推送安全规则，统一监测告警对这些突发事件应急响应一定是安全的趋势。
因为这次大范围勒索软件对这波NSA公开漏洞感兴趣的可以研究下：
这次利用的漏洞是4月第二批放出来的，在这里：
x0rz/EQGRP_Lost_in_Translation
顺便可以follow一下这位安全专家 x0rz
言归正传，无论是私有云还是公有云环境，云安全服务都是必不可少的。传统安全设备/服务对云环境的支撑已经显露疲态了，主要原因在于：
- .熟悉当前云网络或看过本专栏VPC相关文章的读者一定能够理解，传统安全服务与VPC内网无法形成良好连接；
- 随着越来越多的厂商选择了软硬解耦，纯软实现SDN的模式下，过去的盒子类产品如果作为网关式服务，反倒成为了网络中的不稳定点。
相对的，云安全服务应运而生，早年的云安全服务注重于云WAF、云流量清洗（抗D），只需用户改一改域名解析即可，本质上还是一种在VPC外的安全服务。而现在，越来越多的云厂商、安全厂商将安全服务能力延伸到了VPC内，对用户的所有资产提供多维度的安全体验。
VPC内云安全服务的工作模式，常见的有两类：
- 安全服务的镜像化
- 用户资产内置agent
第一类即是类似于OpenStack的 Octavia 、 Manila 那样，将服务集成于一个具体的镜像里，开启服务即是开启一台云主机，该云主机开在用户VPC内即可，保证网络的互访可达或是转发。在公有云的镜像市场上可以见到非常多的这种服务，而类似F5、VMware NSX等，更是把这一套很早就玩通了。纯安全厂商也喜欢以这一种形式与云厂商展开合作，集成代价小，如同现在越来越多的人喜欢aio http service一样。
第二类需要更多的开发维护成本，适配各种各样的操作系统环境，考虑服务端架构，以及受客户实际环境的制约，当然这种方式能拿到更多的即时数据，对漏扫深度、检测范围、周期任务的支持能力也更突出，往往由云服务商自行提供或者以云服务商为主导，纯安全厂商作支持。
不过，正因为云租户拥有对其所拥有的云资产的完全权限，和云计算平台管理角色兼有安全责任权限，但此时云管理员/程序只能以辅助身份参与到租户的云资产安全运维周期中来，租户有充分的对安全服务内容、范围和形式的选择与决策权。因而提供给云租户的入侵检测功能接口和数据接口是必要的，粗粒度的检测规则是基于对租户资产最小化嵌入性的考量。特别是当云安全服务的设计考量有许多租户定制化选项时，租户完全可以选择针对具体功能的开启、关闭甚至是完全清理。
为某客户做的基础云安全服务架构：
Agent类安全服务，与云管理平台服务端做数据交互时是一大关键点，常见的方案有：
- 带外网络方式
对于有足够灵活双向互访需求的agent服务来说，用户的云主机有额外的一张网卡，与服务端连接至同一专属网络，实现互访，同时在此网络中做好除了 “any → 服务端IP” 及 “服务端IP → any” 之外皆DROP的安全策略。就好像一个“带外管理”网络一样。 - 代理方式
通过在VPC内新建一台代理机，同样可以实现互访，而代理机与服务端的连接是不止通过“带外”网络一种方式的。乍一看，和 Zabbix 的 proxy部署方式是不是同样的工作原理。
- 南北方式
和前两者主要是东西向流量不同，这一种方式，无论是VPC网络还是基础网络，统一通过访问在上层网络的服务端来实现，当然，在没有实现长连接的情况下，只能由agent端主动发起连接。
对OpenStack环境而言，参考元数据metadata的实现方式可以给agent类服务提供更多的思路。
Neutron-ns-metadata-proxy 利用在 unix domain socket 之上的 HTTP 技术，实现了不同网络命名空间之间的 HTTP 请求转发。并在请求头中添加’X-Neutron-Router-ID’和’X-Neutron-Network-ID’信息，以便 Neutron-metadata-agent 来辨别发送请求的虚拟机，获取虚拟机的 ID。
.Metadata 请求发送流程
虚拟机获取 metadata 的大致流程为：首先请求被发送至 neutron-ns-metadata-proxy，此时会在请求中添加 router-id 和 network-id，然后请求通过 unix domian socket 被转发给 neutron-metadata-agent，根据请求中的 router-id、network-id 和 IP，获取 port 信息，从而拿到 instance-id 和 tenant-id 加入请求中，最后请求被转发给 nova-api-metadata，其利用 instance-id 和 tenant-id 获取虚拟机的 metadata，返回相应。
当云主机向169.254.169.254发送元数据http请求时，会被转发至qrouter(如有)地址的9697或qdhcp地址的80
不难发现，这条连接之所以成立就是那一条REDIRECT规则，所以agent与server间的通信只需在网络节点上部署一个小控制程序，实现对netns内规则的修改即可。灵活的规则可以适应各种各样的架构，也能保护服务端的真实IP不被暴露。
在寻常架构的实际部署中，往往需要：
或是
架构稳定还好说，server信息（IP）一旦变动，agent则会失连失控，解决方法通常是在最近的一次通信中，由server主动告知agent，接下来的连接信息将变化；或是 agent 轮询请求一个稳定地址（也可是元数据服务），将server地址写在里面。如此 agent知晓连接信息的变化并改变本地配置。
所以，何不把这个工作交给网络节点的控制程序来做，agent只和169.254.169.254的连接就好了，当然也没有了更多的、变动的安全策略顾虑。
至于云安全服务的细节执行，核心部分在传统安全产品的实践中已经足够丰富了，各家无非拼的是“快与准”，规则更新快、告警快、修复快，漏洞检测准、威胁定位准、风险分析准。云场景中额外需要考量的对资源的使用限额，对用户资产的侵入性和服务端存在的交互风险。某agent被抓取数据传输内容后伪造数据污染服务端数据库的惨剧…… 当然就算数据传输加了密，也还得防agent被本地逆向的风险，这又得安利一下元数据模式的好，数据规整与身份信息等可以在网络节点上做，用户接触不到这一块的逻辑自然无从下手。
—————————————————————————————————————————
其实综合以上各种，在确定云服务架构的时候，既要考虑资源消耗和管理成本，也要考量服务实现的逻辑复杂度、健壮性。虽然大家都看齐AWS，也不一定是最适合自家的，何况AWS也有没踩完的坑。而云安全服务以安全为出发点，自然更需要考虑服务架构本身所体现、承载的安全能力。
