在今天的博文中我们将讨论Azure Storage的安全性以及如何使用共享访问签名（SAS）和存储的访问策略来控制对容器和Blob的访问。SAS基本上是带有查询参数的URI，该查询参数指定诸如到期时间，权限和签名等选项。我将在本文后面详细介绍这些内容。请注意，共享访问签名也可以与表和队列一起使用，但是我将仅在Blob存储方面进行讨论
什么是共享访问签名（SAS）
共享访问签名（SAS）是URI，它允许使用者在指定时间范围具有访问存储资源（例如blob或容器）所允许的权限。时间跨度和权限可以从存储的访问策略中得出，也可以在URI中指定。
可能有得朋友看到这里会提出我使用存储账户密钥就可以了，为什么要使用此功能？因为这允许客户端在不知道我们存储账户密钥的情况下访问存储帐户中的容器和Blob。从安全的角度考虑，如果将存储帐户密钥放在客户端应用程序中，则它可能会遭到******，并且可能会被他人窃取和使用，甚至会用感染了病毒的文件替换正常的文件。使用存储帐户密钥，对存储帐户的访问没有限制。在企业中的实际环境中，无限访问可能不是我们想看到的权限控制场景。
默认的容器权限
在控制对Blob存储的访问时，首先要使用容器权限。可以将blob存储中每个容器的权限设置为如下权限之一：
- Private：禁止公众访问Blob或容器
- Blob：Blob的公共读取权限
- Container：Blob容器和Blob的公共读取访问
如果将权限设置为Private，则只有具有存储帐户名和密钥，或者使用共享访问签名，才能访问Blob和容器。
如果将权限设置为Blob，则在容器中具有URL的任何人都可以读取blob以及blob属性和元数据。除非他们使用具有适当权限的共享访问签名，否则他们将无法编写Blob或获取有关Blob所在容器的任何信息，也无法在容器中获取Blob列表。
如果将权限设置为Container，则容器和Blob是公共可读的。可以列出容器中的Blob，也可以下载Blob。可以读取容器属性和元数据；还可以读取blob属性和元数据。请注意，即使拥有此权限，也仍然无法修改，上传或删除Blob，如果希望进行修改，上传或删除则需要帐户密钥或适当的SAS。
这表明我们可以结合使用容器权限和共享访问签名来控制对Blob和容器的访问粒度。
存储访问策略
下面是创建SAS URI的两种方法。首先，可以创建一个临时的SAS来访问文件或容器，并指定使用的过期日期和权限。如果这样做，应该考虑将时间跨度设置为15分钟之类的小时间跨度，以最小化其他人使用相同URL访问相同文件的机会。例如，如果我们正在检索SAS URI以显示一组图片，则有人可能在Fiddler中看到uri并使用它们，直到它们过期。当使用SAS URI时，取消访问权限的惟一其他方法是更改存储帐户密钥，这可能会产生严重影响，具体取决于有多少应用程序正在使用该存储帐户。
创建SAS URI的第二种方法是为容器设置存储的访问策略，并指定名称、启动时间、过期时间、权限等。然后，当我们需要一个SAS URI时，我们可以创建它并指定存储的访问策略的名称，而不是URI的特定版本所需的所有参数。在进行授权时，将从存储的访问策略检索信息。另外，与临时SAS URI不同，如果您想撤销访问权限，您可以简单地更改存储的访问策略，从存储的访问策略继承的所有SAS URI将立即被修改，这比更改存储帐户密钥更可取!
需要注意的是一个容器最多可以有5个存储的访问策略。每个策略可以由任意数量的共享访问签名使用。例如，可以为读/写和只读访问设置不同的访问策略，使用不同的过期时间。您可以使用的特定uri的数量没有限制。
在创建存储访问策略时，可以指定启动时间、过期时间和权限的任何组合。如果在策略上指定它们，则必须从实际的SAS URI中省略参数。或者，可以在存储的访问策略中指定其中一些参数，而在SAS URI中指定其他参数。实际上，可以在创建存储访问策略时指定SAS URI上的所有参数，但是如果这样做，则只能使用存储的访问策略来撤销签名，而不能修改签名的行为。
共享访问签名和存储的访问策略必须包含验证签名所需的所有字段，并且不能有重复的字段。例如，您不能将存储的访问策略设置为具有权限R/W，不能创建SAS URI并指定只读权限。
通过编写要使用的策略的完整列表，在容器上设置存储的访问策略。如果希望取消对其中一个策略的访问，可以通过编写策略列表并排除该策略来删除它。如果希望更改其中一个策略的权限，则必须使用包含修改后的策略的新列表覆盖存储的策略列表。
到目前为止，相信各位已经了解了存储访问策略，接下来让我们来看看共享访问签名。
共享访问签名
前面也和大家提到，SAS是一个URI，它在其查询参数中包括所有信息，以验证对Blob或容器的访问所需的身份。查询参数可以包括以下内容（实际查询参数在参数名称后的括号中）：
- Blob URI：这是Blob的地址。我们应该始终使用HTTPS构造共享访问签名。示例：https://sql12bak.blob.core.chinacloudapi.cn
- 存储服务版本（sv）：指示要使用的存储服务版本。示例：sv = 2019-02-02这是可选的，如果未指定，它将设置为可用的最新版本。
- 开始时间（st）：这是SAS生效的时间。如果省略，则SAS立即生效。由于计算机之间的时差（时钟偏斜），因此请务必小心。如果您将开始时间设置为现在，则可能是将来在另一资源上使用5分钟，并且可能不允许再访问5分钟。除非时间不长，否则建议不要设置此设置，或者将开始时间设置为当前时间之前的15分钟。此文件必须为ISO 8061格式。示例：st=2020-01-19T03:27:10Z
- 到期时间（秒）：这是SAS不再有效的时间。我们应该始终使用它，或者将其与具有此设置的存储访问策略相关联。此文件必须为ISO 8061格式。示例：se=2020-01-19T11:27:10Z
- 存储资源（sr）：告诉资源是否是blob，队列等。示例：sr = b，它表示资源是blob，或sr = c，说资源是容器。
- 权限（sp）：这定义了可以对存储资源执行的操作。示例：sp = rw，它授予读取（r）和写入（w）访问权限。
- 签名（sig）：用于验证对Blob的访问。这是使用SHA256算法在字符串到符号和密钥上计算的HMAC，然后使用Base64编码进行编码。
示例：sig = Z％2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk％3D
将这些内容放在一起会产生以下URI，它允许对存储帐户sql12bak中container进行读/写访问，时间为2020年1月19日11:27:10 AM至2020年1月19日7:27:10 PM
https://sql12bak.blob.core.chinacloudapi.cn/?sv=2019-02-02&ss=bfqt&srt=sco&sp=rw&se=2020-01-19T11:27:10Z&st=2020-01-19T03:27:10Z&spr=https&sig=pOyu%2FIVLKBVeQWydo3vxIJKEi46NXxwk%2FH%2BtXyas5c8%3D
这是一个临时SAS。通过指定所有必需的查询参数和Blob的原始URI来访问Blob时，可以创建此文件。
撤销权限
临时SAS URI与使用存储的访问策略之间的重要区别与撤销所允许的权限有关。有了SAS，无论创建了哪个进程，任何获取URI的人都可以使用它。因此，在前面提到的方案中，如果客户使用Fiddler捕获了一个SAS URI，则他可以将其发送给其他人，然后其他人可以访问存储帐户中的文件并上载或下载。
SAS URI与用于创建签名的帐户密钥和关联的存储访问策略（如果有）相关联。如果未指定任何存储访问策略，则撤消共享访问签名的唯一方法是更改存储帐户密钥。
通常，SAS可以一直工作到：
已达到SAS的到期时间。
如果使用了存储的访问策略，则在达到存储的访问策略的到期时间时，SAS将停止工作。发生这种情况的原因是时间实际上已到期，或者因为存储的访问策略的到期时间已修改为过去。
如果您使用存储的访问策略，并且SAS引用的策略被删除，则SAS将不再起作用。
将重新创建用于创建SAS的帐户密钥。
最佳实践
创建或分发SAS时，需要始终使用HTTPS。如果通过HTTP传递SAS，则可以由执行中间人***的人读取和使用。
尽可能使用存储的访问策略，因为使用它们可以撤消权限而不必重新生成存储帐户密钥。如果需要永久访问权限，请将过期时间设置为较长时间，并确保定期更新以将其移至更远的将来。
使用临时SAS URI时，请使用尽可能小的日期范围来限制曝光。
如有必要，请客户端应用程序更新SAS。因此，如果有权访问映像，并且SAS过期，则应用程序应该能够对其进行更新，以使客户端没有障碍。
如前所述，在设置SAS起始时间时，请务必通过排除起始时间参数或从当前时间中减去15分钟来解决时钟偏移问题。
请具体说明需要访问的资源。如果客户只需要访问一个Blob，则不要让他们访问整个容器。
在将SAS写入存储之后但使用它之前，请验证使用SAS写入的数据，以确保它没有损坏或恶意。
不要总是使用SAS。如果您想对输入数据的验证进行更多控制，或者想在身份验证方面增加额外的安全性，则可能需要创建一个中间层服务来对blob存储进行读写。另外，如果有一种更简单的方法来提供访问权限，请使用它。例如，如果您希望容器中的所有Blob对公众都是可读的，请使容器公开，而不是为需要访问的每个客户端创建SAS。
使用存储分析来监视我们的应用程序。这将帮助我们发现由于SAS提供程序服务问题或意外删除存储的访问策略而导致的身份验证失败。
原文地址：https://blog.51cto.com/wuyvzhang/2468009