原文通过结合h1报告详细阐述7大安全问题，为了方便读者理解还添加了本人推荐的优秀技术文章，欢迎各位批评指正。原文来自hackerone：https://www.hackerone.com/application-security/7-common-security-pitfalls-avoid-when-migrating-cloud
在一项调查中，96% 的决策者正在实施云计划。将工作负载迁移到云端有很多好处：
成本是云部署的主要优势之一。总部位于新西兰的云会计公司 Xero使用 AWS 服务将毛利率提高了81% 。另一个驱动因素是获得强大的机器学习技术，这有助于 NSA 决定迁移。
但是，迁移到云端存在挑战，安全性是一个大问题。
七个常见安全陷阱
没有人迁移到云端会变得比迁移之前更不安全。阅读下文以了解如何在迁移到云时防止此类安全性倒退。
暴露敏感信息
OWASP Top 10将敏感信息泄露列为第三大安全风险是有原因的。一段时间以来，敏感数据泄露一直是个问题。但是，迁移到云时会出现新的风险。
Amazon Web Services (AWS) 提供了一项名为S3的服务。S3 为用户提供了一个简单的存储服务（因此得名）。您可以将数据放入 S3“存储桶”以用于其他服务或用于备份目的。例如，您可以将您的数据库备份放入 S3 以廉价地存储它们。批处理所需的文件也可以放在 S3 中。
不幸的是，有许多 S3 存储桶是公开的，这意味着任何有 Internet 连接的人都可以访问其中的数据。当坏人发现这些暴露的存储桶时，它们会导致严重的数据泄露(点击查看10个最严重的 Amazon S3 漏洞)。
在此，为各位整理了相关存储桶漏洞挖掘方式：
您不必成为下一个 S3 数据泄露事件。您可以采取一些具体步骤来确保您的 S3 存储桶是安全的:
创建构建管道。
开发人员不应直接接触 S3 存储桶配置。S3 具更加规范的默认设置，可让您的存储桶私有化。任何更改都应通过构建管道进行，而不是由用户直接进行。
考虑使用深度防御策略。
Amazon 推荐的策略是我们将 Amazon CloudFront 和存储桶策略放在 S3 存储桶前面，从而防止使用 S3 URL 暴露它们。查看文档了解详细信息。
使用良好的 IAM 策略。
AWS 拥有丰富的身份和访问管理 (IAM) 服务以及可帮助您的最佳实践。使用应用程序角色和存储桶策略来控制来自各种其他服务（例如 EC2 或 Lambda）的存储桶访问。您的 S3 存储桶应被视为旧数据中心中的“后端”系统。只有您的应用程序才能访问它们，因此请相应地设置您的 IAM 策略和角色。
更多的防御方式，可以查看此处。
泄露凭证
任何应用程序正常运行都需要高度特权的凭据。这就是我们必须面对的现实。当公司没有妥善保管这些凭证时，就会出现问题。注：凭证可以是 AWS 等服务的用户名、密码或秘密访问密钥，如h1历史报告中出现：私钥泄露以及通过SSRF漏洞访问EC2 和 OpenStack 上的元数据服务器，在/latest/meta-data/ 和/latest/user-data可以发现大量用户信息。
您可以查看黑客常用的搜集凭证的方式，以及后续如何利用。
当凭证被硬编码或存储在源代码控制中时，基础设施和应用程序代码可能会向 AWS 服务公开用于身份验证的密钥。
这里简单介绍几种防御方式：
使用 Git 检测敏感数据。
Git 是一个强大的源代码管理工具，也是 GitHub 的基础。Git 的技术细节超出了本次讨论的范围。但是，一个安全的库应该是：开发人员和安全团队成员扫描 Git 存储库和提交代码都查找不到敏感信息。
使用您的云提供商的工具来减少在源代码或文件中存储凭据的需要。
亚马逊发布了两个工具，Secrets Manager和Macie，它们可以帮助防止和检测凭证泄漏。Microsoft 的 Azure 现在有一个密钥库来保护您的机密。使用这些工具允许应用程序进行所需的访问，而无需以明文形式存储机密。
缺乏明确的政策（并执行）
云环境的一大优点是其灵活性和可扩展性。但这些特性也给安全团队带来了意想不到的挑战。有些公司根本没有政策，即使有也不会强制执行。这便导致每个开发人员都是管理员，或者所有管理员都可以访问每项服务。
那么公司可以做些什么来定义和执行政策呢？
瑞典安全公司 Detectify 的开发人员Christoffer Fjellström说：“主要问题是公司确实没有相关政策，或者他们没有跟进并确保遵守这些政策。”
对供应商审查不严
Verizon 的数据泄露事件导致了 600 万条客户记录的泄露，原因是 Verizon 的合作伙伴 Nice Systems 将日志信息放入可公开访问的 S3 存储桶中。
目前国内常用的云厂商几乎都爆出过CVE漏洞，，例如：CVE-2022-25165：AWS VPN 客户端中的 SYSTEM 权限提升
对此，提供几点建议：
- 在选择供应商之前，请彻底审查他们的安全实践。确保可以强制执行您的安全策略。
- 让安全成为您合同的一部分。谷歌询问他们的所有供应商是否有办法让外部各方向他们提交漏洞。Dropbox最近举办了一场现场黑客活动，其中一些供应商的资产在范围内。确保您的任何安全要求都在合同中详细说明。让供应商对您的数据安全负责。
帐户失控
如果员工可以代表公司创建 AWS 账户，则可能会暴露敏感数据。使用最小权限安全原则来防止员工无限制访问也是必不可少的，给大家推荐一个篇技术文章：通过错误配置的 AWS Cognito 接管 AWS 帐户
值得庆幸的是，AWS为账户管理创建了一组最佳实践：
- 明确定义 AWS 账户创建流程。这可以集中创建，但只要您保留帐户清单就不必如此。
- 定义公司范围的 AWS 使用策略。
- 创建用于管理多个帐户的安全帐户结构。如果您在账户之间创建安全关系，您可以更轻松地评估您的 AWS 账户安全性。
- 利用 AWS API 和脚本。使用脚本和 AWS API 将允许您在所有账户中设置基线安全配置。
如果您觉得这太难了，而且您不知道从哪里开始，请不要担心。AWS 有一个实施指南来帮助您开始使用这个框架。无论您是按照亚马逊的方式还是另一种方式，您都需要 AWS 中的账户管理框架。
网络错误配置使网络暴露在外
如果您是云新手，您可能会遇到一个技术陷阱，即网络配置不正确。
密切关注虚拟私有云 (VPC)和网络访问控制列表 (ACL)设置。
VPC 允许您在云中构建自定义子网。如果互联网就是世界，你的 VPC 就是你的房子。这是一个你可以去并拥有隐私的地方。除非您允许，否则任何人都不应访问您的 VPC。如果您的 VPC 允许访问 Internet 上的任何 IP 地址，这就像敞开大门一样。
网络 ACL 就像云中的防火墙一样，控制网络之间的通信方式。想想像边境巡逻这样的 ACL。它检查进入 VPC 的数据包并决定是否允许它们进入。与 VPC 类似，ACL 可以接受来自任何和所有 IP 地址的流量。
VPC 和 ACL 需要记住一个最佳实践。不允许所有 IP 地址访问您的 AWS 网络。仅允许来自您受信任端点的 IP 地址。
未使用正确的加密
使用云服务时，绝对需要适当的加密。Accenture的数据泄露非常严重，因为 S3 中存储了 40,000 个明文密码。您若不希望数据泄露，可以采用加密的方式为您提供额外的保护（只要您的密钥也未找到）。
许多 AWS 服务都有可用的加密选项。S3 具有默认加密选项，以及针对不同要求的许多加密选项。使用密钥管理服务可让您安全地加密 Amazon 服务中的数据。Amazon 的Elastic Block Store (EBS)和关系数据库服务 (RDS)都可以选择加密您的静态数据。
传输中的加密可以通过使用与 AWS 的 VPN 连接来完成。默认情况下，所有 Amazon 端点都通过 HTTPS 提供服务。AWS Certificate Manager是一种在云基础设施中管理 TLS 证书的方法。
