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