RightScale安全总监Phil Cox分析IaaS安全监控的三大问题

RightScale安全与合规总监Phil Cox在RightScale的官方博客上发表文章,介绍RightScale如何监控公共云IaaS中的安全。

文章开头,Phil Cox指出:

关于如何真正在云中实施安全,特别是在IaaS中,我看到很多人都有困惑。云厂商在反复洗脑,销售也在灌输令人恐惧、困惑、怀疑(FUD,Fear、Uncertainty、Doubt)的观念,而且这些观念一直存在,这就让云安全的问题更难有直接的答案。

接下来,Phil首先定义了“安全监控”:

针对系统和应用中与安全相关的事件,能够收集、分析、警告的能力。这些事件等同于存在问题的系统或应用中的日志。 …… 安全监控的重要性在于:它是整体信息安全规划的关键部分,没有它,安全规划就是不完整的。如果系统中存在漏洞,或者有人借漏洞攻击,如果没有安全监控,你 恐怕永远不知道在发生什么,直到你在新闻里面看到。

Phil指出两点:

  • 云中的安全,在根本上,与其他环境中的安全类似。
  • 在IaaS中监控,是传统企业监控工作的一个子集。主要原因在于:无法深入到一般的网络层(比如:没有调试端口可以查看通过这个设备的所 有流量)。虽然可以搭建出这样的一个架构,找到某个点通过所有流量,以此获得失去的透明度。但要是这么做,就等于削足适履,而且会引入新的问题,比如:单 点失败、带宽限制、延迟问题等等。不如拥抱变化,找出新形势下应该如何做,而且不要试着强制推行过去的方案。

Phil建议:在实施安全监控之前,先问“为什么”、再问“怎么做”,然后才是“用哪些”。

RightScale对于“为什么”的答案是:合规、防窃报警、事后分析。满足合规要求,当发生不正常的事情时,就能系统通知他们,而且他们希望在事后能够分析过去的事件。

Phil认为下面这些措施,是安全监控具体做法的重要内容:

  1. 警告延迟:当某件事情发生之后,需要多久得到通知?这就必须考虑事件处理时间和真正收到警告的时间。这个问题的答案直接影响存储I/O、网络带宽、CPU和内存的需求。
  2. 带宽:在集中系统中,处理系统上是否有足够带宽处理所有的网络负载?对于主机要传输下来的数据量,其成本是多少?
  3. 可靠性:正在处理的实际数据和警告要达到什么级别的可靠性?很多人会说“完全的可靠性”,但最通用的日志传输方法是通过UDP传输Syslog。这个决策取决于对于“为什么”问题的回答。
  4. 部署模型:有很多种部署模型,但下面三种是IaaS云中的最佳方案:

    A:本地代理、本地报警、集中关联、集中存档

    B:本地代理、集中报警、集中关联、集中存档

    C:没有代理、集中收集、集中报警、集中关联、集中存档

具体到RightScale:

  1. 警告延迟:“防窃报警”事件发生后,我们会在3分钟内触发警报。
  2. 带宽:我们会限制数据传输的成本(每天,我们有上百G日志产生,而且增长迅速),使用同一个区域或地区内部的系统是免费的,或者对于大带 宽使用,要花费最少成本。我们的平台在设计时,有一个主要的想法,当时RightScale已经有需求要将日志集中,以解决问题,因此利用很希望继续这个 机制。
  3. 可靠性:我们会使用可靠的机制,确保日志集中存储,并且可以访问。
  4. 部署模型:上述三种全部采用。

解决了“为什么”和“怎么做”,接下来要考虑“用什么”。此时就要着手研究具体的技术解决方案了,看看如何配合“怎么做”,满足“为什么”。可以了 解厂商产品、开源方案、内部开发,或是三者结合。此时,另一个重要问题是:找出可用技术的局限,并将其结合之前的问题,做进一步分析。

RightScale对“用什么”的回答是:

我们认为:同时使用三种部署模型,这是满足我们对“为什么”问题的三个答案的最佳方式。

  1. 关键服务器(比如数据库服务器):我们使用OSSEC开源多平台入侵检测系统的独立模式,rsyslog和RELP(可靠事件日志协 议),以实现模型A。这让我们可以实现本地防窃报警,如果有问题,马上就有报警。实现本地代理和本地报警,增加了这些系统的管理压力,但是因为它们是关键 系统,这些压力还是值得的。
  2. PCI环境:我们选择了CloudPasssage商用产品Halo,实现部署模型B。Halo同时提供更多安全方面的好处,满足我们的PCI合规需求。
  3. 其他系统:我们使用RELP发送到集中日志收集系统,OSSEC的服务器模式来做报警和相关性分析(模型C)。我们部署集中日志收集系统 的地点,满足“降低带宽成本”要求。选择模型C,因为这从系统管理角度看,是最简单的方式,没有本地代理需要管理。这让我们可以完成通用相关分析和环境报 警,同时提供事后分析需要的日志。

Phil指出:

所谓“监控”,我指的就是“日志分析”。

那么如何确定哪些日志是有问题的呢?Phil认为要具体情况具体分析。

安全监控最困难的部分,就是确定哪些值得报警——特别是日志。

Phil还列出了几种RightScale使用的报警:

  • 针对数据库服务器的交互式登录:在我们的环境里,这是很难得发生的事情,因此我需要知道。同时,我也会注意类似事件在统计上的增加现象,这可能意味着某些东西出了问题。
  • 来自未知系统的数据库访问:这种情况不应该发生,可能说明防火墙存在问题,或是说明有另外一个需要马上处理的问题。
  • 前雇员账号试图访问:这种警告能够有效识别出在雇员离职流程中漏掉的职员账号。

文章最后,Phil做出如下总结:

一定要从“为什么”这个问题开始。而且你也会发现:RightScale的决策最后都会直接与我们的“为什么”相关。如果不知道这些答案,你就会为了技术而直接部署技术,到最后还是会继续郁闷,无法得到期望的结果。

在RightScale,我们认为:让系统管理变得简单,特别是在高度灵活的IaaS环境中,十分重要。而且,从我过去部署全球安全事件监控工具的经验中,我知道定制相关性和报警是最佳起点,更容易成功和成长。

尽管我们在安全监控上投入了很多工作,这是个不断发展的长期过程。如前所述,在公共云IaaS领域的安全监控是做事情的全新方式,所有人都在不断学习。我们也会根据需求和解决方案的变化调整和变更。

Phil在一个网络视频课程中介绍了更多关于部署模型的细节,如果希望了解,可以访问《云中的安全监控:RightScale如何实现》。

郑柯 郑柯,实用的理想主义者,相信:每天改变一点点,这个世界会更好。

This entry was posted in Best Practices, Cloud Computing, Security. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s