| 导读 | 随着多云及混合云趋势的发展，过去传统的云安全策略显然已不适应新的云环境。尽管，很多企业一直非常重视云安全问题，但其中很多风险点并没有得到实际解决。大多数企业依然在采用过去本地环境下的云安全措施，导致企业出现云安全策略不一致，应用风险和漏洞增加的状况!最严重的问题是，很多私有云部署环境下的安全问题，并不需要黑客高手侵入，而是缺乏安全常识! |
很多安全问题都是防不胜防!即使在理想的环境下，还容易出现重大安全事故，更何况你系统本身就有问题，那等于是在给攻击者开了一扇门。所以，为了确保云环境下的万无一失，我们除了在云安全措施上下功夫，还要在安全常识问题上，提高警惕!
首先，不要忽略“僵尸负载”。
很多企业往往会忽略在系统架构上运行着的僵尸负载。尤其是在企业应用峰值期，一旦遇到严重的安全问题，会首先把“僵尸负载”排除在外，不予理会。
实际上，很多别有用心的人就是利用僵尸资源来窃取密码。尽管僵尸工作负载并不重要，但是它构建于企业整体基础设施之上，一旦疏于管理，会更容易遭遇入侵。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进行监控，或则采用其他网络评估工具，进行定期审计，非常必要。
本文转自：https://www.linuxprobe.com/cloud-security-knowledge.html
原文地址：https://www.cnblogs.com/it-artical/p/11794738.html