×

【每日一记7】+第3天+云安全面临的常见威胁
  

简单思考 8871人觉得有帮助

{{ttag.title}}
如今,企业上云的数量已经稳步增加,中小企业青睐于其物理基础设施的经济性选择,而大企业则喜欢充分利用云服务的灵活性。然而,现在他们也都面临了一个挑战,尤其是那些刚刚上云的企业,他们还并不熟悉云上业务的运作方式、与纯本地系统的的差异。云设置经常不仅仅只涉及一个设施,经常要和物理数据中心想结合。
因此,这个挑战会延伸到安全层面,当云安全部署不充分或者对于配置参数不熟悉时,会存在许多风险。许多因素会导致工作负载和应用程序暴露在网络上招致攻击,包括错误的配置、技术的合理使用、运营经验和云系统防护,甚至是对于部分研发人员和云工程师的风险忽视。云系统的组成因素在很多方面是相互交织的,这会导致潜在攻击媒介难以追踪。对于刚开始使用云平台和服务的IT安全人员来说,安全这个任务十分艰巨。
不管是云平台还是云服务,结果发现配置错误一直是云安全主要的陷阱之一,而且还会对订阅云服务的企业和托管在云上的软件用户有所影响。
全域可写的亚马逊S3存储桶
AWS凭借其多种产品,现在已经成为云行业的主要参与者。在AWS稳定版的产品中,Amazon  S3或许是最受欢迎的,像Netflix、Reddit和Pinterest这些企业都在用它的基础设施。
我们在研究Amazon  S3存储桶时看到的一贯趋势是,许多组织将它们放置在全域可写中,这是一种错误配置,允许未经授权的用户写入存储桶。比较知名的例子比如《洛杉矶时报》,该杂志之前有一个网络控制列表(ACL),该列表配置允许公众将访问路径写入存储桶中,该存储桶托管在其一个凶杀报告的网站上。攻击者可以在JavaScript代码中注入加密挖矿程序。
遥测数据还表明,对一些全域可写的存储桶网站攻击大部分发生在2019年间,同时还涉及一些恶意代码注入攻击,最终以网站表单形式提取数据。我们遇到的另一个问题是存储在Amazon  S3存储桶中的恶意文件归类。大部分恶意文件使用旧的路径寻址方案。这意味着存储桶使用通用的Amazon  S3主机名,而不是虚拟存储方案,在虚拟托管方案中,存储桶的名称包含在主机名中。这会给安全筛选器带来问题,因为阻止使用路径方案的恶意网站的主机名也同样会阻止其他非恶意站点。
云上可用的第二项主要服务是计算,目前这些服务主要集中于容器技术。在过去几年中,像一般的云细分市场一样,容器的采用率也很高。Docker、Kubernetes和AWS  Lambda之类的软件推动了容器技术的发展,为希望简化其开发操作的企业提供了轻便高效的云部署。但是,配置失误或错误很常见,这些错误配置的系统有受到攻击的风险。

1. Docker
交付加密货币挖矿不断增加,一直困扰着Docker用户,这也是因为暴露在网络上的Docker容器所致。挖矿会严重影响用户的计算机,并且因自动扩展的云部署的CPU利用率过高而造成金钱损失。
攻击者有多种技术将挖矿代码注入未加密的Docker服务器。最简单的方法是直接在包含代码的映像中安装加密挖矿程序。另一种方法就是在启动过程中使用类似Ubuntu的常用基础映像来安装挖矿软件。

2. AWS Lambda
AWS  Lambdas是无服务器事件驱动平台,可为应用程序提供轻量级且经济高效的解决方案,无需设置使用模式。一个常见的误解是Lambda受白帽保护,不能直接检索函数名。这种误解通常会导致未经适当身份验证的情况下执行功能。
但是,攻击者可以使用多种方法找到Lambda,例如,使用嗅探器侦听网络流量,或者通过检查Lambda使用并运行API网关站点的源代码。如果没有安全的Lambda身份验证,敏感信息有暴露的危险。
另外,由于开发人员的编码方式不同,在给定不正确的参数时,许多基于Python的Lambda函数会打印堆栈跟踪,这可能导致攻击者了解Lambda配置的基础信息。

3. Kubernetes
Kubernetes是一个用于管理容器工作负载的开源容器编排平台。我们使用Shodan发现2019年1月有32000台Kubernetes服务器暴露在网络上。与其他配置错误的例子一样,恶意分子可以利用网络公开访问Kubernetes服务或其任何组件。
(1) Kubeletes
Kubernetes使用其Kubeletes子组件的API来管理每个节点中的容器。在旧版本1.10之前的Kubernetes中,Kubelet公开了数据端口10255和控制端口10250,这两个端口均可被利用。滥用控制端口更为明显,比如可用于安装加密货币挖矿软件,且端口10255可能包含潜在的敏感信息。
(2) etcd
Etcd是一个分布式和复制的键值存储,充当Kubernetes的主要数据存储。它负责存储Kubernetes安装配置,并提供服务发现的存储后端。除了Kubernetes,其他应用程序(例如CoreDNS和Rook)都使用etcd。如果将其用作数据存储,则公开暴露的etcd可能会泄漏敏感数据,包括用于服务器和应用程序的凭据。我们使用Shodan发现了2400多个暴露的etcd服务器,包含Kubernetes和其他软件的混合。
凭证管理不当
尽管凭据使用经常被忽略,但却是云计算最重要的方面之一。由于企业无法像数据中心一样在物理上保护云系统,因此对凭证安全性的需求就变得更大。在保护凭据方面面临的一个挑战是许多流程通常需要访问身份验证数据和其他资源,这意味着用户需要保护数据和凭据免受泄露。
程序员经常犯的一个错误是,他们会无意间在GitHub等公共存储库上泄露凭证信息。有时会在网上发布的代码段中找到诸如API密钥之类的敏感数据,然后攻击者就可以使用这些代码片段来接管凭据使用的帐户,随后再进行犯罪活动,例如盗窃客户数据,在暗网出售这些数据。
我们发现的另一个问题是,许多经验不足的程序员经常遵循错误的云教程,其中许多教程鼓励在代码本身内部对凭证进行硬编码。如果代码发布到任何人都可以访问的存储库中,这将成为一个问题。
随着云服务采用率的增长,企业需要充分了解其面临的威胁,并做好适当的准备,保护其云系统。如果没有可靠的安全实施措施,云技术的好处就无法实现。本文研究分析的威胁并未涵盖云中所有潜在的威胁和风险,包括一些最重要的威胁。对于需要了解云的结构以及保护云的策略的IT和安全人员而言,这尤其重要。

打赏鼓励作者,期待更多好文!

打赏
暂无人打赏

sangfor_闪电回_小六 发表于 2020-5-19 18:52
  
您好,感谢楼主分享,如文章为转载的内容需附上原文链接哦!

关于笔记内容社区建议如下↓
创作笔记指南:
内容图文结合,文章不用太长,条理清晰,有实质性的参考价值,能解决实际问题;
建议笔记采用的结构:
QA(问题-答案)式结构,先说问题,再给建议或者解决方案(可以多条并列)以故障排错为例:问题现象--原因分析---排查思路和解决方法--排查结果--注意事项” 可以参考这样的组织结构写作;
杜绝复制粘贴式、抄袭、滥竽充数、灌水、过于简单的内容(否则将取消激励,造成个人时间浪费!小编会审核每一条笔记的哦)
参考案例:https://bbs.sangfor.com.cn/forum ... read&tid=100181
卢冰 发表于 2020-6-12 13:19
  
感谢分享
发表新帖
热门标签
全部标签>
西北区每日一问
技术盲盒
安全效果
【 社区to talk】
技术笔记
干货满满
每日一问
信服课堂视频
GIF动图学习
新版本体验
技术咨询
2023技术争霸赛专题
功能体验
产品连连看
安装部署配置
通用技术
秒懂零信任
技术晨报
自助服务平台操作指引
原创分享
标准化排查
排障笔记本
玩转零信任
排障那些事
SDP百科
深信服技术支持平台
POC测试案例
畅聊IT
答题自测
专家问答
技术圆桌
在线直播
MVP
网络基础知识
升级
安全攻防
上网策略
测试报告
日志审计
问题分析处理
流量管理
每日一记
运维工具
云计算知识
用户认证
解决方案
sangfor周刊
VPN 对接
项目案例
SANGFOR资讯
专家分享
技术顾问
信服故事
功能咨询
终端接入
授权
设备维护
资源访问
地址转换
虚拟机
存储
迁移
加速技术
产品预警公告
信服圈儿
S豆商城资讯
技术争霸赛
「智能机器人」
追光者计划
社区帮助指南
答题榜单公布
纪元平台
卧龙计划
华北区拉练
天逸直播
以战代练
山东区技术晨报
文档捉虫活动
齐鲁TV
华北区交付直播
每周精选
2024年技术争霸赛
北京区每日一练
场景专题
故障笔记
高手请过招
升级&主动服务
高频问题集锦
社区新周刊
全能先锋系列
云化安全能力

本版达人

新手68983...

本周分享达人

零和一网络

本周提问达人