Article / 文章中心

云原生安全的攻防实践

发布时间:2021-11-15 点击数:329

应用是云原生体系中最贴近用户和业务价值的部分,笔者在之前应用层安全风险篇一文中分析了云原生应用面临的风险,相信各位读者已经有所了解,本文为《云原生安全:攻防实践与体系构建》书籍解读第二篇,主要针对传统应用安全、API安全、微服务架构下的应用安全、Serverless安全这四方面风险提出作者的一些防护见解及思考。

传统应用安全防护

传统应用风险为云原生应用风险奠定了基石,因而传统应用的安全也同样适用于云原生应用安全,笔者认为传统应用的安全防护方法主要包含以下四方面。

应用程序代码漏洞缓解

应用程序的已知漏洞几乎是造成所有风险的主要原因,因而针对应用程序的漏洞缓解措施是必要的。应用程序代码漏洞缓解应当从两方面考虑,一方面是安全编码,另一方面是使用自动化检测工具。

应用程序依赖库漏洞防护

应用程序的漏洞缓解措施只能一定程度上规避开发者不规范编码造成的风险,而应用程序本身除了开发者编写的代码,还可能需要引入第三方依赖库,那么依赖库是否含有已知漏洞将会直接导致该应用程序是否相对安全,因而针对应用程序依赖库漏洞的防护也是必要的。针对应用程序依赖库漏洞造成的风险,我们可以使用受信任的源或软件组成分析技术进行防护。

应用程序访问控制

《云原生安全:攻防实践与体系构建》书籍中多次提到“访问权限的错误配置”,“脆弱的函数运行时”等会导致未授权访问风险的因素,可以看出做好应用程序的访问控制非常重要。在业务逻辑相对简单的应用中,我们可通过为每个用户赋予不同的权限从而实现访问控制,但随着业务量逐渐复杂,用户数量不断增多,准确识别每个用户需要哪些权限、不需要哪些权限是一件具有挑战性的工作,且为每个用户赋予单一权限的方法易造成权限泛滥的风险,因而我们应遵循最小特权原则,即给予每个用户必不可少的特权,从而可以保证所有的用户都能在所赋予的特权之下完成应有的操作,同时也可以限制每个用户所能进行的操作。使用基于角色的访问控制是实现最小特权原则的经典解决方案,基于角色的访问控制就是将主体(用户、应用)划分为不同的角色,然后为每个角色赋予权限,例如上述提到的业务量大,用户数多的应用程序中,使用基于角色的访问控制就显得很有效,因为我们可以定义每类角色所具备的访问权限,这样即便有成千上万个用户,我们只需按照用户的类型去划分角色,从而可能只需要有限个数的用户角色即可完成访问控制。

应用程序数据安全防护

我们知道,应用程序最终为业务服务,而数据为业务产生了价值,数据泄露风险是目前应用程序面临的巨大风险,如何防止数据泄露是我们需要关心的一大问题。笔者认为应用程序的数据安全防护应当覆盖安全编码、密钥管理、安全协议三方面。安全编码涉及敏感信息编码,密钥管理涉及密钥的存储与更换,安全协议涉及函数间数据的安全传输。

API安全

我们知道,虽然云原生应用架构的变化导致了API数量的不断增多,但在造成的API风险上并无太大区别,因而在相应的API防护上我们可以参考传统的API防护方法。此外,我们还可采用API脆弱性检测的方式防止更多由于不安全的配置或API漏洞造成的种种风险。最后,在云原生应用架构下,我们可使用云原生API网关,其与传统的API网关有何不同,能为云原生应用风险带来哪些新的防护是我们关心的问题。《云原生安全:攻防实践与体系构建》书籍中将API安全分为传统API防护、API脆弱性检测、云原生API网关三个部分进行介绍,欢迎各位读者深入阅读。

微服务架构下的应用安全

从应用层安全风险篇中我们可以看出应用的微服务化带来的新风险主要包含数据泄露、未授权访问、被拒绝服务,那么如何进行相应的防护也应从以上三方面去考虑,笔者通过调研和一些实践发现使用传统的防护方法是可行的,但当服务随业务的增多而逐渐增多时,传统的防护方法由于需要开发人员进行大量配置而变得非常复杂,例如用户的应用部署在Kubernetes上,该应用包含上百个服务,当我们做访问控制时可以依托Kubernetes的RBAC机制对目的服务进行授权,进而我们就需要依赖Kubernetes的API以完成配置,每次配置是会耗费一定时间的,因此需要大量服务授权时往往会让开发者感到力不从心,为解决诸如以上服务治理带来的难题,我们可以使用微服务治理框架进行相应防护,笔者在2018年发表的《Service Mesh实践之Istio初体验》[1]文章中对什么是Service Mesh及Istio的基本概念进行了相应介绍,从中可以看出Istio目前已作为第二代微服务治理框架的代表,因而笔者认为Istio的安全防护能力也是基本能够覆盖微服务应用安全范畴的。事实上,笔者在2019年发表的《Istio系列一:Istio的认证授权机制分析》[2]一文中也对Istio的安全机制进行了介绍,不过当时Istio处于较早期版本,虽然与目前最新版本的Istio在功能实现稍有不同,但底层原理几乎未变,可供各位读者参考。综上,笔者认为面向微服务架构下的应用安全,可以采用传统的防护方式或微服务治理框架进行防护,具体的防护方法可以包含以下几方面。

认证服务

由于攻击者在进行未授权访问前首先需要通过系统的认证,因而确保认证服务的有效性非常重要,尤其在微服务应用架构下,服务的不断增多将会导致其认证过程变得更为复杂。

访问控制

访问控制是针对未授权访问风险最直接的防护手段,微服务应用架构下,由于服务的权限映射相对复杂,因而会导致访问控制变得更难。

数据安全防护

微服务应用架构下,服务间通信不仅使用HTTP协议,还会使用gRPC协议等,这是我们需要注意的地方。

其它防护

除了上述防护方法之外,微服务治理框架与API网关/WAF可以进行结合以进行深度防护,例如可以在一定程度上缓解微服务环境中被拒绝服务的风险。

Serverless安全防护

Serverless应用安全防护

我们知道,传统应用的风险几乎可以覆盖Serverless应用的风险,因而针对Serverless应用的安全防护各位读者可以参考前文提到的传统应用安全的防护方式,尤其是应用程序的代码漏洞缓解、依赖库漏洞防护、数据安全防护。针对应用程序访问控制,由于Serverless云计算模式带来的变化,除了使用基于角色的访问控制之外,还需要进行更深层次的防护,笔者认为函数隔离及底层资源隔离是较为合适的防护方法。

Serverless平台安全防护

笔者认为Serverless平台的安全防护应从以下几点出发:

使用云厂商提供的存储最佳实践

为尽量避免用户在使用云厂商提供的Serverless平台时因不安全的错误配置造成数据泄露的风险,主流云厂商均提供了相应的存储最佳实践供各位开发者参考,例如How to secure AWS S3 Resources[3]、Azure Storage Security Guide[4]、Best Practices for Google Cloud Storage[5]等。

使用云厂商的监控资源

现今各大云厂商均为Serverless配备了相应的监控资源,例如Azure Monitor、AWS CloudWatch、AWS CloudTrail等,使用云这些监控资源可以识别和报告异常行为,例如未授权访问、过度执行的函数、过长的执行时间等。使用云厂商的账单告警机制 针对拒绝钱包服务(DoW)攻击,公有云厂商可通过提供账单告警机制进行缓解[14],如AWS开发者可通过在Lambda控制台为函数调用频度和单次调用费用设定阈值进行告警;或提供资源限额的配置,目前主流的云厂商已提供相应配置。

Serverless被滥用的防护措施

针对Serverless被滥用的风险,笔者认为可以采取以下方式进行防护:1.通过IDS等安全设备监测木马在本机的出口流量,诸如“/pixel”、“/utm.gif”、“ga.js”等URL的流量应进行重点监测;2.确认自己的资产中是否有云厂商提供的Serverless函数业务,如果没有可以通过浏览器禁用相关云厂商的子域名;3.采取断网措施,从根源上直接禁止所有网络访问;

总结

针对云原生应用防护及API安全,首先我们可以看出传统应用防护同样适用于云原生应用防护,因而深刻理解传统应用防护内容非常重要。其次,云原生应用架构的变化为API带来了更多特点,也带来了新的防护方法,如原生API网关的合理使用可以有效改善用户环境下的API安全问题。针对云原生应用新风险,我们可以看出应用架构的变化是带来新风险的主要原因,鉴于此,本文笔者针对具体的风险提出了防护方法,其中,使用微服务治理框架Istio可以在一定程度上缓解应用架构带来的风险,此外,也介绍了Istio与API网关和WAF结合的业界方案,从而可实现微服务应用的全流量防护。针对Serverless风险,笔者较为系统地从Serverless应用及平台两方面对前述提到的Serverless风险进行了相应防护介绍。可以看出,与传统安全防护不同的是无服务模式带来的新型云原生下的应用安全场景,因而,我们需要适应云计算模式的不断变化,并不断总结新场景下的防护方法,才能最终将安全落实到底。《云原生安全:攻防实践与体系构建》书籍针对以上安全防护手段从解决方案、系统架构、技术细节等层面进行了较为详细的说明,欢迎各位读者阅读相关章节,若有任何问题随时联系作者。