欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  网络运营

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

程序员文章站 2022-03-19 12:24:43
RightScale安全与合规总监Phil Cox在RightScale的官方博客上发表文章,介绍RightScale如何监控公共云IaaS中的安全。 文章开头,Phil Cox指出:...
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如何实现》。