避免CI成为一个安全隐患|洞见

背景

最近临时交接了一个客户测试环境和产品环境的维护工作。交接的客户资产包含:代码库、生产环境主机、测试环境主机、搭建在测试环境主机上的持续集成服务器以及对应的账号密码。这个持续集成服务器采用Jenkins搭建,并且可以用来部署测试环境和生产环境的应用。

不久,接到了客户的一个维护请求:把最新的生产环境数据同步到测试环境里。

这个维护任务需要通过SSH登录到测试环境主机上进行操作。测试主机是通过authorized_keys进行SSH认证的,只要你自己的ssh-key被添加到了主机上,就可以实现无密码登录。

这样有两个好处:一方面维护人员无需使用密码,避免了生产环境密码的泄露。另一方面可以按需吊销不再使用的客户端,及时回收权限。所以我需要把自己的sshpublickey交给管理员,让他把我的key加到可访问列表里。

悲剧的是,前管理员告诉我,他的key因为更换电脑的关系没有及时更新。所以,他也无法登录主机。而且之前参与维护的其它管理员的key也都失效了,这意味着我们失去了对主机的控制。此时,我手上只有登录Jenkins的的用户名和密码,于是一个邪恶的想法就诞生了:

既然Jenkins可以执行脚本,那么我是否可以通过Jenkins把我的key注入进去?

于是我把ExecuteShell的Job变成了我的命令行,通过运行日志得知了宿主用户的文件目录信息。然后把自己的sshpublickey加到了登录列表里(此处省略敏感信息):

sudo sh -c“cp~/.ssh/authorized_keys~/.ssh/authorized_keys.bak”

sudo sh -c"echo‘{我的sshpublickey}’>>~/.ssh/authorized_keys"

It works !

我成功的登录了机器,但这却暴露了一个问题:持续集成服务器成为了一个安全隐患。

首先,持续集成服务器可以执行代码。这就意味着它有可能执行有害代码。

其次,持续集成服务器缺乏足够的用户鉴权,这很有可能导致未授权用户访问。

无权限控制的服务器+可以执行代码=裸奔的肉鸡

那么,如何构建一个更安全的持续集成服务器服务器?


rootless原则

“神操纵着万物,你感觉得到他,但永远看不见他。”——《圣经·希伯来书11:27》

在服务器的世界里,root用户就是神,拥有至高的权力和力量。如果有人获得了“神之力”,后果可能不堪设想。

无论是Web服务器、数据库服务器还是持续集成服务器。都是这个世界里的二等公民,权限和力量都应该受到约束。执行的时候应该受到控制。

此外,应该极力避免sudo的滥用,尤其是对那些从外部访问的用户。很多情况下,为了操作方便,很多用户都有sudo的权限。但这恰恰造成了低权限用户通过提升自己的访问权限进行有害操作。

在上述的故事里,因为没有对Jenkins的主机用户做有效隔离,导致了我可以用sudo注入自己的key获得机器的访问权限。

沙盒隔离原则

因为持续集成服务器会执行脚本或运行程序,而这些程序和脚本有可能是存在恶意代码的。所以,对应的任务应该在隔离的安全沙盒中执行,例如:受限的用户,受限的权限,受限的空间。

在上述的故事里,我就通过CI执行了一段不安全的脚本成功获得了登录主机的权限。

如果这些任务在隔离并受控的Docker容器里执行,那么会安全得多。

当然,也可以考虑采用TravisCI这样的第三方持续集成服务来保证安全性。

备份和备份核查原则

在上述故事里,因为缺乏有效的备份机制,导致了所有人都无法访问主机。此外,我在修改authorized_keys的时候先进行了备份。这样,如果我注入失败,还可以还原。

这里的备份,不光是对配置、数据的备份,还有岗位的备份。

如果管理员有备份,完全不会出现无法登陆的事情。

如果有备份QA服务器,完全可以不需要当前的QA服务器。

在做任何变更前,都应该做好备份以及还原的准备。因为任何变更都会带来“蝴蝶效应”。

但是,光备份是不够的。如果备份不能有效还原,那和没有备份没有什么区别。所以,要定时的进行备份恢复测试。确保备份在各种情况下可用。

多重要素身份验证原则

上述的持续集成服务器是暴露在互联网中的,任何一个人访问到这个站点,通过一定程度的密码破解,就可以获得这个持续集成服务器的访问控制权限。从而可以做出上述的操作。

所以,有了用户名和密码,并不一定是可信用户。还需要通过更多的手段,诸如手机短信验证码或者第三方认证集成来验证用户的身份。

关键操作手动验证原则

试想一下,如果在上述的例子中我并没有服务器的访问权限。而是通过提交未经审查的代码自动运行测试脚本。实际上也会造成同样的效果。

有时候我们会为了方便,让持续集成服务器自动触发测试。但是,恰恰是这种“方便”带来了额外的安全隐患。而这样的方便,不光方便了自己,也方便了恶意入侵者。

所以,不能为了方便而留下安全隐患。在关键操作上设置为手动操作,并通过一定机制保证关键操作的可靠性才是最佳实践。


构建安全CI的几个实践:

采用Sibling的方式在Docker里运行任务。

账户密码管理统一采用LDAP认证,如果过期则从外部修改。

CI的登录权限和其它的认证方式(比如GitHub、Okta等)集成起来。并用组限制登录。

对于生产环境的CI,通过更加细粒度的权限限制来隔离一些危险操作。

官方的安全指南

不少持续集成工具的官方都提供了最佳实践以及安全指南帮助我们构建持续集成服务器。请务必在构建持续集成服务器前阅读并理解这些安全实践和措施,并遵照安全最佳实践构建持续集成服务器:

  • Jenkins最佳实践
  • Jenkins官方安全指南

如果没有这些如果

上面提到了太多的如果。如果这些“如果”能发生在事前,这些问题就不会产生。持续集成本身是开发的最佳实践,但如果缺乏安全的意识,一味的追求方便和高效,则会带来很大的安全隐患。通过一些简单而基础的措施和手段,我们就能大大的降低风险。


原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2017-07-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

左手用R右手Python系列——多进程/线程数据抓取与网页请求

这一篇涉及到如何在网页请求环节使用多进程任务处理功能,因为网页请求涉及到两个重要问题:一是多进程的并发操作会面临更大的反爬风险,所以面临更严峻的反爬风险,二是抓...

25860
来自专栏服务端技术杂谈

海量日志数据存储用 elasticsearch 和 hbase 哪个?

首先看两者的简单介绍: ElasticSearch:是一个基于Lucene的搜索引擎; HBase:是一个开源的,非关系的,分布式的数据模型存储引擎; 两个框...

53050
来自专栏服务端技术杂谈

20分钟了解微服务

image.png 简介 所有的功能打包在一个war包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,...

28030
来自专栏alexqdjay

SpringCloud(一)Eureka2.0

36750
来自专栏服务端技术杂谈

系统的高可用(纯理论)

专注服务端首先要专注的是关于高可用。 有的时候高可用系统并不是简单的技术方案,会包含很多其他的东西。 什么是高可用? 基本来讲是为了让我们的计算机(硬件/软件...

33960
来自专栏EAWorld

API管理的正确姿势--API Gateway

数字化生态,以创新客户体验为核心,所有我们身边能感知到的变化都来自于渐近的创新。这些创新需要试错,需要不断的升级,并且创新往往与我们熟知的功能分离开来分别呈现。...

47720
来自专栏互联网杂技

什么是微服务

在介绍微服务时,首先得先理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是"微"、什么是"服务", 微 狭义来讲就是体积小、著名的"2 p...

19910
来自专栏程序员互动联盟

【专业技术】Android如何实现推送?

存在问题: 现在各种实时推送消息不时的在我们手机通知里闪烁,而windowphone搞了那么久在加上,实时消息要求的是实时性。在我们开发中如何掌握这种实时模式呢...

62650
来自专栏EAWorld

微服务架构实践:服务注册与发现中负载方案选型

微服务架构不是银弹,在微服务架构中,我们将面临很多新的问题,这时候势必会引入一个服务注册发现问题。本文作者向大家介绍了随着负载均衡位置的不同,三种主要的服务注册...

393110
来自专栏IT大咖说

微软:云原生的MySQL托管服务架构及读写分离的优化

内容来源:2017 年 08 月 24 日,微软中国首席产品经理宋青见在“ODF 2017开源数据库论坛(北京)”进行《云原生的MySQL托管服务架构及读写分离...

13930

扫码关注云+社区

领取腾讯云代金券