Azure Blob存储和安全最佳实践

Question

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

最佳实践是每个应用程序在每个环境（开发，测试，登台，生产）中拥有一个完整的存储帐户吗？ 是否可以在虚拟网络后面保护存储帐户？ 是否应该在每个应用程序的基础上对容器使用签名？

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

Answer 1

我的情况有些不同-外部应用程序，但问题是相同的-数据访问安全性

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

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

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

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

一些事情：

• 每个应用程序（和/或环境）的存储帐户是一个不错的策略，但是您必须了解限制–每个订阅最多100个存储帐户。
• 没有选择来限制对具有虚拟网络的存储帐户的访问
• 一个容器最多可以有5个共享访问策略

Answer 2

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

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

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