在探索 Azure 存储时，我注意到对存储容器的访问是通过共享密钥完成的。我在工作的地方担心，如果开发人员将这个密钥用于他们正在构建的应用程序，然后离开公司，他们仍然可以登录到存储帐户并删除他们想要的任何内容。解决方法是为帐户重新生成辅助密钥，但随后我们必须更改每个使用这些密钥的应用程序中的所有密钥。
最佳做法是为每个环境（开发、测试、暂存、生产）的每个应用程序拥有一个完整的存储帐户吗？ 是否可以保护虚拟网络后面的存储帐户？ 我们应该在每个应用程序的基础上在容器上使用签名吗？
有没有人有类似的经历并找到了处理这个问题的好方法？
【问题讨论】：
标签： azure azure-storage azure-blob-storage
我有一点不同的场景——外部应用程序，但问题是一样的——数据访问安全
我使用共享访问签名 (SAS) 来授予对容器的访问权限。
在您的场景中，您可以在容器上为每个应用程序创建共享访问策略，并使用此存储访问策略生成具有较长过期时间的 SAS，您可以随时通过从容器中删除共享访问策略来撤销它。因此，在您的场景中，您可以撤销当前的 SAS 并在开发人员离开时生成新的 SAS。您不能为多个容器生成单个 SAS，因此如果您的应用程序使用多个容器，则必须生成多个 SAS。
从开发人员的角度来看，用法保持不变： 您可以使用 SAS 令牌创建 CloudStorageAccount 或 CloudBlobClient，因此它几乎就像一个常规访问密钥。
从长远来看，我可能会考虑创建一个负责生成 SAS 并更新它们的内部服务（内部 API）。通过这种方式，您可以拥有完全自动化的系统，并且只向该主要服务公开访问密钥。然后，您可以使用虚拟网络、证书、身份验证等限制对该服务的访问。如果出现问题（编写该服务的开发人员离开 :-)），您可以重新生成访问密钥并更改它们，但这次只能在一个地方。
几件事：
【讨论】：
我不会主观/意见答案，而是从客观的角度来看：如果开发人员拥有存储帐户密钥，那么他们就可以完全访问存储帐户。如果他们离开公司并保留了钥匙的副本？阻止它们的唯一方法是重新生成密钥。
您可能会认为使用不同存储帐户分隔应用程序会有所帮助。但是，请记住这一点：如果开发人员有权访问订阅，则他们可以访问该订阅中每个存储帐户的密钥。
在考虑密钥再生时，请考虑了解密钥本身的应用程序的总表面积。如果存储操作仅是服务器端操作，则更改密钥的影响很小（每次部署中的小应用程序更改，以及更新您使用的任何存储浏览工具）。如果您将密钥嵌入桌面/移动应用程序以直接访问存储，则必须推出更新的客户端会遇到更大的问题，但无论如何您已经遇到了安全问题。
【讨论】：