无服务模型导致云原生产生哪些风险


发现错别字 2个月前 提问
回答
1
浏览
87
请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!
回答数量: 1
CISO 高级信息系统项目管理师 PMP

无服务模型导致云原生产生以下这些风险:

  • 服务商风险:云服务商对无服务器的防护还很薄弱,虽然无服务器已经很普遍,但是无服务器功能,会让整个基础设施变得更抽象,让问题更严重。网络攻击者会寻找容器和无服务器代码中的隐患,以及云基础设施中的错误配置,以接入包含敏感信息的实体,再用它们提升权限,攻击其他实体。

  • Key的泄露:云原生应用对资源和设施的管理和使用基本都是基于Key,因此针对云原生的攻击首先的变化就是对key的攻击。根据统计,用户的apikey无意泄露在github等网站其实是很常见的,因此有黑客专门去这些网站扫描无意提交的key信息。云服务商为了应对这种新攻击,基本都与GitHub这些主流的网站进行合作,主动扫描发现这些泄露的key并及时通知其客户消除风险。

  • 云原生配置风险:无服务器使用的资产是品类多、动态的、用完即走的,各种安全配置分散在各个产品中,缺乏统一管理和运维平台,难以做到管理和检查,从而导致配置安全和隐患,配置安全这个是容易被忽略的。多产品联动已经足够困难,更棘手的是,不少项目会跨厂商联动,比如组合了阿里云、腾讯云、高德开放平台、百度云等的产品,造成难度系数陡增。

  • 资产多:采用云原生的时候,资产比较隐蔽变化也快,这个需要云服务商多多工作,同时跨厂商的使用让复杂度也更提升

  • API风险:无服务器是细粒度的服务,他的安全重点也就是API安全,如API异常调用、越权操作、违规调用。

  • 内部审计风险:云服务商的无服务器无法保障细粒度的操作的记录和安全性,如更新代码人员、部署新服务人员、删除函数人员等,或要想实现付出的成本很高昂。

  • 功能天然风险:当前包括腾讯云的云函数在内的主流无服务器云服务商,都提供了镜像部署和代码部署两种方式。在安全方面,镜像部署面临更多的安全风险(如镜像安全风险、镜像仓库安全风险)。

  • 安全变量风险:若将配置或敏感信息保存在环境变量,一旦被突破这些信息直接泄露、被修改甚至被利用。建议:少用或不用环境变量,因此复杂的环境配置而导致必须用镜像部署的,应该考虑将各种环境变量配置使用配置文件

  • 攻击面广:无服务器中微服务模式部署有着其先天的优势而一定成为主流,但微服务随之带来了新的风险,可供攻击的面也更广泛;建议:采用“零信任”的理念来处理每次的访问的安全防御。

  • 环境变量风险:使用环境变量替代配置文件虽然存储更简单,但是使用环境变量本就是不安全行为,攻击者进入运行环境,可以轻易获取、修改环境变量信息,引发信息泄露。腾讯云的文档做的就不好,竟然有把数据库的账号密码配置在环境变量

  • 资源权限管控风险:传统的基础设施是静态的,无服务器中基础设施的出现和使用是函数级动态的,因此每个函数与资源的权限映射会非常多,如何高效进行角色和权限的管控是个复杂问题,很多开发者暴力为所有函数配置单一角色和权限,这一行为极大增加函数使用风险。

  • 跨函数调用数据清理不及时引入数据泄露风险:在运行过程中,调用结束后没有及时清除暂存的配置参数、账号信息或其他业务敏感信息,后续调用的函数访问时,可能存在越权和获取机密数据的情况。在“单实例多并发”或“请求多并发”功能的加持下,这个风险又会额外增加。建议:函数执行时,不要偷懒直接复用当前已经存在的文件、内存变量、配置信息等,而是每次都应该视为全新使用,有临时存储的需求时,必须检测操作的成功与否,以免误用历史信息。

  • 缺乏无服务器专有安全解决方案:现在的安全工具和安全体系是基于云场景中的虚拟机或容器底座,基于web应用或传统框架进行设计开发和应用的。在servless上这些无法直接匹配或使用。

  • 钱包攻击:传统攻击以阻塞业务为目标,无服务器的安全性让攻击者无法阻塞其业务,只能转而进行钱包攻击。

回答所涉及的环境:联想天逸510S、Windows 10。

2个月前 / 评论