之前由Nitzan Niv在Alcide博客上发表
在安全领域,识别系统被破坏、滥用或错误配置的最成熟方法之一,是收集系统用户和自动化服务执行的所有活动的日志,并分析这些日志。
作为安全最佳实践的审计日志
一般来说,审计日志有两种用途:
Kubernetes审计日志
让我们研究一下如何在Kubernetes世界中配置和使用审计日志,它们包含哪些有价值的信息,以及如何利用它们来增强基于Kubernetes的数据中心的安全性。
Kubernetes审计日志的目的,是使集群管理员能够以取证的方式恢复服务器的状态和导致Kubernetes API中数据的当前状态的一系列客户机交互。
在技术术语中,Kubernetes审计日志是对Kubernetes API-Server的每个调用的详细描述。Kubernetes组件向外界暴露Kubernetes API。它是Kubernetes集群中所有用户、自动化和组件访问的中心接触点。API服务器通过HTTP实现RESTful API并执行所有API操作。
当接收到一个请求时,API服务器通过以下几个步骤来处理它:
请求及其处理步骤可以存储在Kubernetes审计日志中。可以将API服务器配置为存储所有或部分请求,并提供不同程度的详细信息。此审计策略配置还可以指定审计日志存储在何处。分析工具可以通过这个钩子请求接收这些日志。
审计Kubernetes集群的挑战
虽然审计日志收集和分析的原则自然适用于云,特别是构建在Kubernetes上的数据中心,但在实践中,这种环境的规模、动态特性和隐含的上下文使得分析审计日志变得困难、耗时和昂贵。
集群中活动的规模意味着,任何仅依赖手工检查成千上万个每日日志条目的分析都是不切实际的。“安静”集群没有人类触发行动,没有重大变化应用活动,仍然是每小时处理成千上万的API调用,由内部Kubernetes机制生成,确保集群是活的,根据指定的部署,利用其资源和失败会自动识别并恢复。即使使用日志过滤工具,审核员也需要大量的经验、直觉和时间来放大一些有趣的条目。
Kubernetes集群这样的系统的动态特性,意味着工作负载正在快速地添加、删除或修改。这不是审核员专注于访问包含数据库的几个特定工作负载的问题,而是确定在审核时间段的每个特定时刻哪些工作负载包含敏感数据库的问题,以及哪些用户和角色有合理的理由访问每个数据库 这些数据库工作负载在什么时间等等。
此外,虽然找到一些有趣的结果只是在日志中查找预先已知的与不良活动相关的特定条目,但是在日志中查找可疑但先前未知的活动需要一套不同的工具和技能,尤其是在这种可疑行为只能在很长一段时间内从更广泛的上下文中理解,而不仅仅是一个或两个相关的日志条目。例如,检测用户未能向系统进行身份验证非常简单,因为每次登录尝试都显示为单个日志条目。然而,识别潜在的盗窃用户凭证只能检测到,如果审计员连接看似不同的条目到一个整体的模式,例如访问系统使用特定用户的凭证从一个组织以外的未知的互联网地址,而使用了相同的用户的凭证并发从内部组织的网络访问系统。
使日志审计再次成为可行的实践
为了使大型、复杂的Kubernetes集群的审计成为一种可行的实践,我们需要使审计员的工具适应这种环境。这些工具将自动和主动地识别异常和有问题的行为,特别是在Kubernetes控制安全的情况下,以便:
当然,为了实现这些目标,这样的工具必须能够:
让我们描述一些更复杂的威胁场景,我们希望预想的审计日志分析仪自动检测:
显然,这种场景的检测远远不止使用预先确定的规则对审计日志进行简单的过滤。必须使用复杂的机器学习算法来自动地、大规模地和在实际威胁活动之后的合理时间内实现这一点。
分析工具应该收集日志中显示的集群的操作和安全活动的特征,并将它们提供给机器学习算法进行测量、加权和链接。在这个过程的最后,可疑行为的可能模式可以提交给审核员进行验证和进一步的调查。
总结
对系统日志的审计是一种成熟的实践,用于识别对系统的安全威胁,无论这些威胁在实现之后是否会产生有害影响。事实上,某些形式的定期审计是法律和规章规定的。
然而,在复杂、大规模、动态系统(如现代的Kubernetes集群)的审计日志中识别可疑模式是一项艰巨的任务。虽然使用某种类型的自动化对于这样的分析是强制性的,但是大多数现有的审计工具只是一些不需要动脑筋的过滤器,很难帮助审计员应对其任务的更深层的挑战。
在本文中,我们提出了一个自动化Kubernetes审计日志分析工具的设想,它远远超出了这个范围。使用机器学习,这样的工具可以自动检测审计员可以关注的日志中的潜在威胁模式,甚至是实时的。此外,以用户可理解的方式汇总审计日志中的信息可以让审计员快速验证已识别的模式,并帮助她调查其他隐藏的可疑活动。