为特定用户组保护Windows Azure存储中的blob的最佳方法是什么。例如，我在本地有一个ASP.NET网站（内部网），其中包含用于大文件的后端Windows Azure blob存储。我喜欢为每个blob提供安全签名URL的想法，但这确实适用于将在那里存在很长时间的blob。 （无限？）
我只需要特定用户对blob进行细粒度的安全性处理（如何使用Blob存储轻松实现这一点）。 *注意我相信我不应该需要ACS。我希望尽可能使用策略和签名URL来实现它。
第二个问题，我假设我也可以用同样的方式在CDN中保护这些数据，有人可以确认吗？
由于
共享访问策略，具有无限时间工作和blob权限，例如读书工作？
答案 0 :(得分：18)
如果您需要blob可供个别用户使用超过一小时，则必须使用附加到容器的SAS策略。但是，由于每个容器最多可以容纳5个容器，因此对于许多用户来说，它不会很好地扩展。 SAS政策可以按年度计算到期日。
此处更典型的解决方案是让用户点击您的网站或服务，并以您选择的任何方式对其进行身份验证。当他们真的希望下载文件时，您应该生成一个具有较短过期（而非策略）的一次性SAS签名。这样可以很好地扩展并防止未经授权的用户在以后重复使用。您还可以从存储而非网络角色中获益。
使用CDN时，事情变得更加复杂。因此，虽然您可以在CDN资源上使用SAS签名，但它们并不真正受到尊重。也就是说，唯一URL是底层资源的关键。因此，当您请求SAS安全blob时，它只会将其拉入CDN并使用该URI作为密钥提供服务。然后，它将使用CDN缓存策略（而非SAS过期）来继续服务。这可能会导致blob URI设置为在10分钟后过期，但CDN将使用相同的SAS签名缓存该blob数天，具体取决于过期策略。 CDN永远不会再次联系存储进行验证。因此，使用它可能不是一个好主意。此外，由于每个CDN资源都键入URI，这也意味着每次SAS签名更改时都会缓存同一文件的许多副本（运行事务和带宽费用）。长话短说，CDN和SAS不能很好地融合。
答案 1 :(得分：3)
我无法帮助您使用CDN，因为我没有使用它的经验，虽然我希望它能以类似的方式工作。
在这种情况下，我要做的是在用户尝试访问文件时生成共享访问签名。您可以在应用程序内部维护用于确定用户是否可以访问任何给定文件的访问规则。
当请求该文件时，您可以动态生成共享访问签名（有关详细信息，请参阅here）并将其交给用户。
这样做的好处是，文件下载不会通过您的Web角色进行，而是直接从blob存储下载到用户。