Azure Blob 存储：如何为多个容器创建共享访问签名？

Question

我正在创建一个将托管在Azure上的应用程序。在这个应用程序中，用户可以上传自己的内容。他们还可以配置其他受信任的应用程序用户列表，这些用户将能够读取他们的文件。我正在尝试解决如何设计存储的问题。

我认为我会创建一个以每个用户的应用程序ID命名的存储容器，并且他们将能够在那里上传文件。我的问题与如何授予用户对其应该访问的所有文件的读取权限有关。我一直在阅读有关共享访问签名的信息，它们似乎非常适合我想要实现的功能。但是，我正在评估授予用户访问权限的最有效方法。我认为存储的访问策略可能很有用。但具体来说：

我可以使用一个共享访问签名（或存储的访问策略）来授予用户对多个容器的访问权限吗？我找到了一条我认为非常相关的信息：

http://msdn.microsoft.com/en-us/library/windowsazure/ee393341.aspx

“一个容器、队列或表可以包含最多5个存储的访问策略。每个策略可以被任意数量的共享访问签名使用。”

但我不确定自己是否理解正确。如果一个用户与其他20个人连接，我能否授予他或她访问20个特定容器的权限？当然，我可以生成20个单独的存储的访问策略，但这似乎不是很有效率，而且当他们首次登录时，我计划显示所有其他受信任的应用程序用户的内容摘要，这将相当于一次性要求20个签名（如果我理解正确的话）。

感谢任何建议... -Ben”

- BenjiFB

---

参见：https://dev59.com/uF8e5IYBdhLWcg3wAWYL - dreftymac

Answer 1

由于每个用户都将拥有一个容器（现在我将用户等同于您所称的用户应用程序ID），这意味着您将拥有一个存储帐户，其中包含许多不同的容器，供许多用户使用。如果您想使应用程序能够上传到仅一个特定容器而从多个容器中读取，则有两种选择。

第一种：创建一个存在某处的API来处理所有请求。在API后面，您的代码将完全访问整个存储帐户，因此您的业务逻辑将确定他们可以访问和无法访问的内容。其优点是您根本不需要创建共享访问签名（SAS）。您的应用程序只知道如何与API交互。您甚至可以通过对单个应用程序调用并行调用来获取来自各个容器的内容的摘要来合并它们可以查看的数据。其缺点是您现在正在托管此API服务，该服务必须处理所有这些调用。如果您走这条路线，仍然需要API服务生成SAS，但只需要生成SAS，客户端应用程序将直接与Windows Azure存储服务进行通信，分担负载，从而减少实际需要的资源。

第二种：采用SAS路线，并根据需要生成SAS，但这会变得有点棘手。

您只能在每个容器上创建最多五个存储访问策略（Stored Access Policies）。其中之一是为容器的“所有者”创建一个策略，为其提供读写权限。现在，由于您允许其他人给出读取权限，因此除非您重用相同的读取策略，否则您将达到策略计数限制，但然后如果用户将读者列表中的某些人删除，则无法撤消该策略。例如，如果我向Bob和James都授予容器的权限，并且他们都获得了读取SAS的副本，如果我需要删除Bob，我必须取消他们共享的Read策略并向James重新发放新的读取SAS。不过，这不是什么大问题，因为应用程序可以检测到它没有许可证，并请求更新的SAS。

无论如何，您仍然希望策略的寿命很短。如果我从我的可信读者列表中移除了Bob，我几乎希望他立即被切断。这意味着您将经常返回获取更新的SAS并重新创建已签名的访问签名，从而降低了已签名的访问策略的实用性。这实际上取决于您打算允许该策略存活多长时间以及如果有人“不受信任”，您希望多快将其切断。

现在，更好的选择可能是创建特定的签名。

实际上，您可以拥有任意多个特定的签名，但是它们不能被撤销，并且最多只能持续一小时。由于您会使它们的寿命很短，所以长度或缺乏撤销不应成为问题。选择此路线意味着您需要根据需要使应用程序返回获取它们，但考虑到上述情况，当某人被删除且您希望SAS失效时，这可能不是一个大问题。

正如您指出的那样，这确实增加了事情的复杂性，因为您正在生成大量SAS；但是，由于这些是特定的，因此您不需要跟踪它们。

如果您要走SAS路线，我建议您的API根据需要生成特定的SAS。它们不应持续超过几分钟，因为人们可以被删除对容器的权限，而您要做的就是减少托管服务实际执行上传和下载时的负载。同样，处理某人可以看到哪些容器的所有逻辑仍在您的API服务中，而应用程序只获取可以使用一小段时间的签名。

- MikeWo

---

感谢您详细、深思熟虑的回答。我明天肯定会再读几遍！ - BenjiFB