云安全错误认知以及应对方法！

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

实际上，很多别有用心的人就是利用僵尸资源来窃取密码。尽管僵尸工作负载并不重要，但是它构建于企业整体基础设施之上，一旦疏于管理，会更容易遭遇入侵。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中，这样就可以通过第三方流程访问。

没有对公网访问设限，安全团队要想识别和隔离恶意行为，要花很长

（编辑：南通站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!