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