导读 随着多云及混合云趋势的发展,过去传统的云安全策略显然已不适应新的云环境。尽管,很多企业一直非常重视云安全问题,但其中很多风险点并没有得到实际解决。大多数企业依然在采用过去本地环境下的云安全措施,导致企业出现云安全策略不一致,应用风险和漏洞增加的状况!最严重的问题是,很多私有云部署环境下的安全问题,并不需要黑客高手侵入,而是缺乏安全常识!

很多安全问题都是防不胜防!即使在理想的环境下,还容易出现重大安全事故,更何况你系统本身就有问题,那等于是在给攻击者开了一扇门。所以,为了确保云环境下的万无一失,我们除了在云安全措施上下功夫,还要在安全常识问题上,提高警惕!

首先,不要忽略“僵尸负载”。

很多企业往往会忽略在系统架构上运行着的僵尸负载。尤其是在企业应用峰值期,一旦遇到严重的安全问题,会首先把“僵尸负载”排除在外,不予理会。

实际上,很多别有用心的人就是利用僵尸资源来窃取密码。尽管僵尸工作负载并不重要,但是它构建于企业整体基础设施之上,一旦疏于管理,会更容易遭遇入侵。SkyBoxSecurity 2018年的一份报告显示,密码劫持是主要的一种网络攻击手段。DevOps团队要像托管加密货币一样,要确保应用资源不受威胁,并采用有效的安全防范手段,来阻止一切恶意行为。

其次,对AWS S3 Buckets的泄露问题,要足够重视。

AWS云服务,尤其是 S3 Buckets是年头最长的云本地服务之一,还保持着过去的安全防护方式和规则,因此成为勒索软件攻击的主要目标。有统计数据显示,7%的 Amazon S3 bucket 都未做公开访问的限制,35%的 bucket 都未做加密,这意味着整个 Amazon S3 服务器中都普遍存在这样的问题。

恶意参与者不仅可以通过S3 bucket访问企业的敏感客户数据,而且还可以访问云凭据。很多具有灾难性的数据泄漏,都是由于访问了不受限制的S3 bucket造成的,因此要定期检查AWS平台上的公有云存储字段是非常重要的一项工作。

其三,系统更新最好不要绕过CI/CD管道。

每个DevSecOps团队都有一个惯性思维,认为系统程序更新时要通过CI/CD管道传递,这样的系统部署才更加安全,但这并不意味着每次运行都要强制执行这一策略。加快部署速度,避免出现安全问题,开放人员往往通过使用开放源码库的形式绕过CI/CD管道。

虽然这种方式为开发人员节省了系统发布和更新时间,但却给安全团队带来了更大的负担,他们必须对异常工作负载进行额外扫描。长期下去,开发团队会认为安全团队没有办法阻止未授权的工作负载,只是简单地接受和执行。最终,系统的安全状况会逐渐恶化,以至于恶意入侵者可以在不引起注意的情况下运行有害的工作负载,但是到那时才发现,一切为时已晚。

其四,网络访问要设限。

许多DevOps团队并没有花费大量的时间,用在分段和单独的访问权限上,而是依赖于一套完整的网络配置,同时这些配置远远不能满足必要的访问限制,他们通常将所有的工作负载都放在一个单独的VPC中,这样就可以通过第三方流程访问。

没有对公网访问设限,安全团队要想识别和隔离恶意行为,要花很长时间。即使在短时间内,DevSecOps团队发现了一些严重的漏洞,也无法在安全配置文件中及时处理安全漏洞!

其五,使用微服务时,规则设置要正确

当DevOps团队在容器中使用微服务时,会面临更大挑战,分得越细,意味着你就越有可能出现错误的规则设置。

即使是最熟悉的规则和集群,也会因疏忽产生大量漏洞。例如,如果允许开发人员使用特定的IP通过SSH远程连接到生产环境时,就可能会在不知情的情况下,允许敏感区域接入无限制公网访问。有时,这些错误的规则配置会被忽略长达数月之久。为了避免错误规则支持,使用Amazon Inspector的Agentless进行监控,或则采用其他网络评估工具,进行定期审计,非常必要。

原文来自:http://cloud.51cto.com/art/201910/604026.htm

本文地址:https://www.linuxprobe.com/cloud-security-knowledge.html编辑:KSJXAXOAS,审核员:张文祥

Linux命令大全:https://www.linuxcool.com/

Linux系统大全:https://www.linuxdown.com/

红帽认证RHCE考试心得:https://www.rhce.net/