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

  • 郑柯

2013 年 2 月 20 日

话题:安全DevOps架构

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 如何实现》。

安全DevOps架构