码迷,mamicode.com
首页 > 其他好文 > 详细

云环境下的安全服务架构

时间:2017-05-14 12:12:17      阅读:182      评论:0      收藏:0      [点我收藏+]

标签:数据   突发事件   代理   ati   nal   延伸   复杂度   box   169.254   

这几天被利用smb等漏洞入侵并使用加密勒索软件的新闻刷屏了,至少各大公有云厂商、云安全服务厂商的响应都还挺及时,更新了防护规则、漏洞检测规则、补丁升级程序,并对开启了相应服务端口的客户进行了提示告警。国内优秀的安全团队更是早在4月份NSA文件刚被公开解密后就开始了对这些问题的密切关注,并对各自有合作的云业务进行了工作开展。不难发现,利用云的力量统一推送安全规则,统一监测告警对这些突发事件应急响应一定是安全的趋势。

因为这次大范围勒索软件对这波NSA公开漏洞感兴趣的可以研究下:

x0rz/EQGRP

这次利用的漏洞是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也有没踩完的坑。而云安全服务以安全为出发点,自然更需要考虑服务架构本身所体现、承载的安全能力。

云环境下的安全服务架构

标签:数据   突发事件   代理   ati   nal   延伸   复杂度   box   169.254   

原文地址:http://www.cnblogs.com/opsec/p/6851876.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!