快速扩展的大量云服务为企业 IT 和安全团队创造了一个永无止境且异常快速的变化周期。许多团队都在争先恐后地保护公共云中的数据，而且大多数组织都在使用过时的安全策略，这些策略在应用于 AWS、Azure 和 Google Cloud 等云环境时会失败。
网络安全和基础设施安全局 (CISA) 的技术策略师 Jay Gazlay 最近告诉美国国家标准与技术研究院 (NIST) 信息安全和隐私咨询委员会：“身份现在就是一切。我们可以谈论我们的网络防御，我们可以谈论防火墙和网络分段的重要性，但实际上，身份已经成为边界，我们需要开始以这种方式重新定位我们的基础设施。”
了解身份的重要性
Gazlay 的评估表明身份是新的边界。安全团队习惯于考虑使用网络创建边界，将安全堆栈放置在这些边界相交的地方，并根据已知和锁定的数据路径对其进行配置。这根本不能作为云中的整体安全解决方案。相反，云安全团队必须考虑他们控制哪些身份、这些身份可以用于什么以及他们可以访问哪些资源。
现代攻击周期始于身份。攻击者寻求通过身份获得访问权限，然后在资源之间切换，发现凭据以及其他人和非人身份，从而使他们能够更好地访问关键数据并导致数据泄露。重要的是要了解身份将安全性扩展到企业的传统壁垒之外，这就是为什么我们看到数据泄露是将旧的网络安全策略应用于云时失败的原因。
在评估他们的云安全职位时，安全团队应该问自己以下问题：
- 我们是否将身份作为我们的边界来管理？如果您的团队仍在管理旧的网络边界，那么您的公司就会面临风险。您的组织必须管理个人和非个人身份。
- 我们是否已确定云中的安全风险？云安全风险和漂移可能很快发生。身份、资源和服务配置错误可能导致严重的数据泄露。组织可以通过首先识别未经授权的身份和过多的权限来最大限度地降低风险。数据所有者和云运营、安全和审计团队必须不断评估风险，以最大限度地提高数据的控制管理、安全和治理。
- 数据暴露指标是否不足？在风险评估策略中，仅靠透明的云数据存储是不够的。虽然数据所有者可能会信任他们的 DevOps 来管理数据对象的存储，但这并不能揭示外部方可访问性和特权的全部范围。云用户必须完全了解他们的数据真正存在的位置、哪些身份可以访问它、它是如何被访问的以及它从哪里移入和移出。
- 我们的协调问题是什么？向单个团队发送安全警报以进行分类和管理的过时范式根本不可行。在云运营模型中，不同的团队同时使用环境，包括审计、DevOps 和安全团队。在这里，过时的范式崩溃了。解决方案是将问题提交给创建它们的团队，因为他们最有能力解决这些问题。
- 我们是否解决了云安全员工的技能差距？ 许多开发人员天生就不是安全专家，应该接受最佳网络安全实践培训。不想为现有开发人员增加更多职责的组织可能需要一种新型的操作人员，将操作与安全 (DevSecOps) 相结合。未能提升员工技能意味着他们不具备保护当今组织所需的技能和知识。
是时候改进您的企业战略了
云涉及多个账户、信任关系和权限继承，使得数据所有者密切关注它变得极具挑战性。以下是您可以用来改进策略的一些领域：
作为零信任策略的一部分，组织应采取措施转移到最低权限，确定对安全影响最直接的活动，并制定实施计划。这意味着投资于满足零信任策略的解决方案，通过持续监控每个权限、访问和身份来确定其有效权限、可以做什么以及可以访问哪些数据。
在数据风险造成损害之前预防数据风险。像对待人一样对待补救和预防机器人。发现的问题应该上报给正确的团队或机器人（团队跟踪和审计）。这将为您的环境带来高性能的合规性结构。制定预防规则并确保规则得到持续满足。
不完全了解其在保护公有云中的身份和数据方面所扮演的角色的企业会采用可能导致灾难性后果的过时策略承担不必要的风险。