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