Azure blob存储和安全性最佳实践

Question

在探索Azure存储时，我注意到存储容器的访问是通过共享密钥完成的。我担心如果开发人员将这个密钥用于他们正在构建的应用程序，然后离开公司，他们仍然可以登录到存储帐户并删除他们想要的任何内容。解决方法是重新生成帐户的辅助密钥，但之后我们必须更改使用这些密钥的每个应用程序中的所有密钥。

最佳做法是为每个环境（开发，测试，升级，生产）每个应用程序创建一个完整的存储帐户吗？ 是否可以将存储帐户保护在虚拟网络后面？ 我们是否应该根据应用在容器上使用签名？

任何人都有类似的经历，并找到了解决这个问题的良好模式吗？

Answer 1

我有一个不同的场景 - 外部应用程序，但问题是相同的 - 数据访问安全性

我使用共享访问签名（SAS）授予对容器的访问权限。

在您的方案中，您可以在容器上为每个应用程序创建共享访问策略，并使用此存储访问策略生成具有较长过期时间的SAS，您可以通过从容器中删除共享访问策略随时撤消它。因此，在您的方案中，您可以撤消当前的SAS并在开发人员离开时生成新的SAS。您无法为多个容器生成单个SAS，因此如果您的应用程序使用多个容器，则必须生成多个SAS。

从开发人员的角度来看，用法保持不变： 您可以使用SAS令牌创建CloudStorageAccount或CloudBlobClient，因此它几乎就像常规访问密钥。

从长远来看，我可能会考虑创建一个负责生成SAS并更新它们的内部服务（内部API）。通过这种方式，您可以拥有完全自动化的系统，并且只能向此主服务公开访问密钥。然后，您可以使用虚拟网络，证书，身份验证等限制对此服务的访问。如果出现问题（编写该服务的开发人员离开:-)），您可以重新生成访问密钥并更改它们，但这次只能在一个地方。

少数事情：

• 每个应用程序（和/或环境）的存储帐户是一个很好的策略，但您必须了解限制 - 每个订阅最多100个存储帐户。
• 没有选项限制使用虚拟网络访问存储帐户
• 您可以在一个容器上拥有最多5个共享访问策略

Answer 2

我不会进入主观/意见回答，但从客观的角度来看：如果开发人员拥有存储帐户密钥，那么他们就可以完全访问存储帐户。如果他们离开公司并保留了密钥的副本？阻止它们的唯一方法是重新生成密钥。

您可能认为将应用程序与不同的存储帐户分开有帮助。但是，请记住这一点：如果开发人员有权访问订阅，他们就可以访问该订阅中每个存储帐户的密钥。

在考虑密钥更新时，请考虑具有密钥本身知识的应用程序的总表面积。如果存储操作仅仅是服务器端操作，则更改密钥的影响很小（每个部署中的应用程序更改很小，同时更新您使用的任何存储浏览工具）。如果您将密钥嵌入桌面/移动应用程序以进行直接存储访问，那么您必须推出更新的客户端会遇到更大的问题，但无论如何您已经遇到了安全问题。