云安全服务架构长怎么样的？快来一探究竟

早年的云安全服务注重于云WAF、云流量清洗（抗D），只需用户改一改域名解析即可，本质上还是一种在VPC外的安全服务。而现在，越来越多的云厂商、安全厂商将安全服务能力延伸到了VPC内，对用户的所有资产提供多维度的安全体验。

传统安全服务与VPC内网无法形成良好连接。

VPC内云安全服务的工作模式，常见的有两类：安全服务的镜像化；用户资产内置agent。

云租户拥有对其所拥有的云资产的完全权限，和云计算平台管理角色兼有安全责任权限，但此时云管理员/程序只能以辅助身份参与到租户的云资产安全运维周期中来，租户有充分的对安全服务内容、范围和形式的选择与决策权。

因而提供给云租户的入侵检测功能接口和数据接口是必要的，粗粒度的检测规则是基于对租户资产最小化嵌入性的考量。特别是当云安全服务的设计考量有许多租户定制化选项时，租户完全可以选择针对具体功能的开启、关闭甚至是完全清理。

Agent类安全服务，与云管理平台服务端做数据交互时是一大关键点，常见的方案有：

带外网络方式：对于有足够灵活双向互访需求的agent服务来说，用户的云主机有额外的一张网卡，与服务端连接至同一专属网络，实现互访，同时在此网络中做好除了 “any → 服务端IP” 及 “服务端IP → any” 之外皆DROP的安全策略。就好像一个“带外管理”网络一样。

代理方式：通过在VPC内新建一台代理机，同样可以实现互访，而代理机与服务端的连接是不止通过“带外”网络一种方式的。乍一看，和 Zabbix 的 proxy部署方式是不是同样的工作原理。

南北方式：和前两者主要是东西向流量不同，这一种方式，无论是VPC网络还是基础网络，统一通过访问在上层网络的服务端来实现，当然，在没有实现长连接的情况下，只能由agent端主动发起连接。

对OpenStack环境而言，参考元数据metadata的实现方式可以给agent类服务提供更多的思路。

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，返回相应。

条连接之所以成立就是那一条REDIRECT规则，所以agent与server间的通信只需在网络节点上部署一个小控制程序，实现对netns内规则的修改即可。灵活的规则可以适应各种各样的架构，也能保护服务端的真实IP不被暴露。

在寻常架构的实际部署中，往往需要：

server信息（IP）一旦变动，agent则会失连失控，解决方法通常是在最近的一次通信中，由server主动告知agent，接下来的连接信息将变化；或是 agent 轮询请求一个稳定地址（也可是元数据服务），将server地址写在里面。如此 agent知晓连接信息的变化并改变本地配置。

在确定云服务架构的时候，既要考虑资源消耗和管理成本，也要考量服务实现的逻辑复杂度、健壮性。