是的，在 SAS 令牌过期之前，安全问题一直存在。尽可能使用用户委派 SAS。用户委派 SAS 为服务 SAS 或帐户 SAS 提供了更高的安全性。用户委派 SAS 使用 Azure AD 凭据进行保护，因此您无需将帐户密钥与代码一起存储。

为每个用户生成个人 SAS 很好，但不建议无限地持续使用它。即使这样做，也需要define a stored access policy for a service SAS。存储访问策略为您提供了撤消服务 SAS 权限的选项，而无需重新生成存储帐户密钥。在将来（或无限）为这些设置过期，并确保定期更新以将其移动到更远的将来。

根据best practices when using SAS，在 ad hoc SAS 服务 SAS 或帐户 SAS 上使用短期过期时间。这样，即使 SAS 受到损害，它也仅在短时间内有效。如果您不能引用存储的访问策略，这种做法尤其重要。短期过期时间还通过限制可用于上载到 Blob 的时间来限制可写入 Blob 的数据量。

是的，在网页前端显示 SAS 令牌可能会导致安全问题，并可能导致您的敏感数据暴露。如果 SAS 泄露，则获取它的任何人都可以使用它，这可能会危及您的存储帐户。

You can generate the SAS token by following below path:
Settings => Shared access signature => Select the options required and click on generate SAS and connection string and copy the SAS token.

何时使用共享访问签名？

使用 SAS 将对存储帐户中的资源的安全访问权限授予对这些资源没有其他权限的任何客户端。

SAS 很有用的一个常见方案是用户将自己的数据读写到您的存储帐户的服务。在存储帐户存储用户数据的方案中，有两种典型的设计模式：

s upload and download data via a front-end proxy service, which performs authentication. This front-end proxy service allows the validation of business rules. But for large amounts of data, or high-volume transactions, creating a service that can scale to match demand may be expensive or difficult.

A lightweight service authenticates the client as needed and then generates a SAS. Once the client application receives the SAS, it can access storage account resources directly. Access permissions are defined by the SAS and for the interval allowed by the SAS. The SAS mitigates the need for routing all data through the front-end proxy service.