云原生安全实践

举报
火线安全 发表于 2022/03/21 12:00:33 2022/03/21
【摘要】 Clare是安全架构师,专注于信息安全攻防研究和深度测试,今天分享的主题是“云原生安全实践”。我讲的议题是,云原生安全实践,主要从两个方面来介绍云原生安全。第一个是云原生安全面临的风险第二个是云原生安全实践云原生的定义:它是一种构建和运行应用程序的现代方法,它主要代表的是容器,微服务,持续集成交付和devops为代表的一个技术体系。它给开发迭代带来了新的革命,提高了研发交付的效率和提高了高可...

Clare是安全架构师,专注于信息安全攻防研究和深度测试,今天分享的主题是“云原生安全实践”。



我讲的议题是,云原生安全实践,主要从两个方面来介绍云原生安全。


  • 第一个是云原生安全面临的风险
  • 第二个是云原生安全实践



云原生的定义:它是一种构建和运行应用程序的现代方法,它主要代表的是容器,微服务,持续集成交付和devops为代表的一个技术体系。



它给开发迭代带来了新的革命,提高了研发交付的效率和提高了高可用性。但是,云原生继承了传统网络安全几乎所有的风险,传统的安全模型主要关注基于边界的安全(perimeter-based security),不足以保护云原生架构的安全。所以相对于传统安全,云原生安全仍然是真正的挑战。


云原生安全,它是一种保护云原生平台及基础设施和整个应用程序安全实践,包括自动化数据分析,威胁检测,确保应用整个安全性及纵深防御。



刚才提到了云原生安全面临的风险,像Kubernetes一些漏洞,还有一些常见的像k8s上用的组件漏洞,包括其他的内部组件的高危漏洞等都威胁整个云原生平台的安全性。


在图上看到很多漏洞,风险是比较高的,出现的频率也比较多。包括之前讲到一些容器逃逸等等这些在容器里面都遇到的非常多。



云原生安全面临的风险,主要是缺乏对威胁攻击的这种感知能力。在很多的企业里面,他们对这种异常流量的监测,缺乏实时的感知能力。还有一些应用安全本身存在的漏洞,也会导致云原生面临的漏洞。


一些中间件、操作系统、外部的漏洞,还有比如人文因素,错误配置导致或者权限设置失效导致的被黑客入侵等等。再比如API缺乏有效的鉴权,缺少有效的应用安全防护,微服务等会影响到整个云平台的一些安全。


其实给我们带来便利的同时,也带来了很多的安全需求和挑战。



云安全风险的来源包括应用多样化、网络攻击环境等等,都在对应用服务、集群容器、代码层面的安全造成很大的风险。



另外,我们从攻击者的角度来看待云原生安全。一些容器相关的组件历史漏洞,还有内部没有受到严格保护的一些API,都会导致像比如说Kubernetes的平台等等被入侵,或者是利用他这些服务,入侵到容器内部或是控制整个集群等。


再比如不安全的容器镜像,不可信的镜像,它本身会导致被入侵。有些容器本身带有恶意脚本,黑客利用容器进行“挖矿”,而且云原生过程中API没有受到严格的保护,也是一个很大的安全问题。平台的安全管控,和其他相关联的安全隐患,都会对云平台导致很大的风险。



接下来第二个,就是云原生安全实践,主要讲述在云原生整个过程中,如何应对遇到的风险。


云原生的生命周期,它包括运行时的安全,分发构件部署等整个安全防护。



整个云原生平台,整个依赖于基础平台的安全,计算平台的安全,容器,应用微服务方面的安全,任何一个环节的问题,都会导致N起事故的发生,所以都要从多个方面对威胁进行评估和提前主动防御。



Kubernetes的服务安全加固,罗列了一些简单的方法。Kubernetes版本很多漏洞就不用详细介绍了,从未知来源下载镜像,在平台上运行,还有Kubernetes基于角色的访问控制,都会提升安全性。


API管理端口访问控制,就不需要分配或足够的鉴权,访问控制资源,还是有一些软件配置自定义参数上来提升整个安全,容器不应该以root用户运行,但是很多企业的安全实践中,还是有很多用户以root权限运行的,包括API Server认证授权,完全以身份认证授权来控制。


很多时候在排查故障,发现有些日志根本没有记录,对排查故障也存在一个很大的问题。所以就需要记录所有有价值的日志,最好在一个独立的日志中心存储、查看或分析。


另外主要提到一个隔离Kubernetes节点,如果是自己单独部署的话,可能单独分配独立的网络,加强一些ACL的控制,防止被攻击者入侵。



容器安全,关于容器安全方面的比较有价值的一些工具,包括扫描容器安全性,比如说它是严重或者高危等等,都会给我们提供一些参考。



另外一个是Kubernetes集群中的安全漏洞,这个是针对于K8S集群进行一些渗透测试,然后会发现整个集群存在哪些严重的问题。对这些问题,可能需要人工进一步的确认,判断哪些可能有重大的隐患,再进行修复。这里提到的一些方法主要以开源的工具为主。



还有这个Falco,这是安全运行的安全监控,监控它的容器运行的可疑行为,执行了哪些可疑的操作。发送警报,集中分析这样一个工具,然后它会进行一系列的告警,喷制等等,这个也是经过实验,是挺好用的一个工具。


它可以部署在本地机器上、云上或者Kubernetes的集群中,它会很直观的看到当前容器的很多安全事件,安全风险的排行。



开源走进安全检测其实是洞态IAST进行针对研发测试过程中的全自动安全测试,我用了大概一段时间,后来再正式测试环境进行应用,效果感觉不错。


因为它可以从测试阶段全自动化的分析到采用了哪些安全组件,哪些组件安全是属于高危?而且它不影响研发人员测试效率,完全不用人工太过干预,全自动的,在发觉漏洞中发挥了巨大的作用。


然后我们采用一些关键字的检索,很快就知道哪些项目引用了这些不安全组件和存在这样的高危风险,然后快速去验证,去修复,节约了不少时间。大家可以深入了解一下。



其实在整个运行过程中,真的提升了漏洞检测效率,对测试流程毫无影响。当应急响应的时候,我们另一方面采用对版本库里的很多去解包、检索,还有就是当时想到我们在使用洞态IAST检索会更快,第一时间采用洞态IAST的结果,筛查使用这些可被利用的组件的项目进行修复缓解处置,然后再排查其他的一些遗留项目,极大的比以前排查组件漏洞提升了应急响应效率。


API的安全防护和web应用防护的这些系列的缺失,其实在很多的企业当中,对API的安全不是很重视,还有一些应用防护很多有waf,但是它配置的基于规则库的规则防护模式不是很智能,容易被绕过。


还有API网关,要能够感知到每个API流量请求,异常分析等等。RASP运行时保护这些,传统WAF只针对入口的应用层攻击进行防护,采用针对云原生的waf,APP安全网关,渗透测试,对于应用安全都是一个有效的补充。


在线测试中,我们要重点关注一下哪些APP和API的高危漏洞。很多云原生环境使用了针对一些虚拟化的基于容器化的这种防火墙的防护,可以防护多个集群,不同节点统一下发策略等等。最核心的是规则和风险感知,对于API进行全生命周期做到更深度的防护都是非常有必要的,它能够分析API的整个调用链路追踪等等。


另外一个就是DevSecOps,它在云原生中也是很需要加强的,包括容器安全、应用分析、静态的检测和sca等,还有软件成分分析等,像洞态iast交互式安全检测其实都是进一步提升应用安全保护的方法。DevSecOps和API安全的重要性都会随着云原生的使用进一步地提升。


包括很多安全审计在云原生平台,我们一定要加强每一个安全事件的管理。


要确保满足可审计哪些行为,执行了哪些命令,容器内部是否有偏离正常的行为等等。其实最主要做到可感知,这个在于云原生平台可感知能力,如果没有相应的手段防护,很多安全隐患是不能够及时有效的被发现。



最后总结一下,安全是一个整体


在安全防护过程中,可能会产生一些成本方面的考虑,任何环节薄弱性才决定整体的安全级别。需要慎重对风险进行研判作出决策。


我们应该从全局出发,把风险罗列出来,我们重点去针对严重问题进行主动性的防护修复,取得主动权来应对黑客的一些攻击。然后对各种攻击,做到实时感知,做到详细可视化以及主动策略防护。


对于漏洞管理,有些软件的一些漏洞,我们都要及时关注或者建立一个清单,然后重点关注这些软件的公告,安全公告漏洞、安全厂商的漏洞等等。


企业内部也要建立这种机制,加强漏洞管理,从各个渠道获取漏洞信息,POC,然后及时跟进和进行评估验证修复,结合实际需求制定安全基线,还有就是一些自动化的第三方厂商的工具来进行评估整个的安全漏洞等。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。