SAS Token是访问Azure存储账户的一种临时授权凭证，本质上是给特定存储资源签发一张带权限和有效期的“通行证”，不需要暴露账户密钥。在服务器配置SAS（Shared Access Signature）时，创建Token是最关键的一步，它决定了外部应用如何安全、可控地访问你的存储数据，下面直接围绕“如何创建”和“关键配置”展开。
SAS Token是什么？和访问密钥有什么区别？
很多第一次接触服务器SAS配置的人会把SAS Token和存储账户的访问密钥弄混，这两者有本质区别。
- 访问密钥（Account Key）：相当于存储账户的根管理员密码，拥有了它，就等于拥有了这个存储账户的完全控制权，可以读写、删除所有数据，业内专家指出，密钥一旦泄露，攻击者可以完全接管你的存储资源，后果是灾难性的。
- SAS Token：相当于给某人一把限时限量的临时钥匙，你可以规定它只能读某个容器、只能访问某个文件、只能生效1小时，过期后自动作废，即使Token泄露，攻击者也只能在权限范围内和有效时间内搞破坏，风险被大幅缩小。
用一句话概括核心区别：密钥是“我全都要”，SAS Token是“我只要这么多，而且只给这么久”。
在实际服务器配置中,如果客户端是可信的内部服务，使用密钥更省事；如果客户端是第三方应用、前端页面或不可信网络环境，行业共识认为必须优先使用SAS Token。
| 对比维度 | 访问密钥 | SAS Token |
|---|---|---|
| 权限范围 | 整个存储账户 | 指定的容器、目录或单个文件 |
| 有效期 | 永久（除非手动轮换） | 分钟级到小时级，可精准设定 |
| 泄露风险 | 高危，需重置整个密钥 | 低危，泄露后等待过期即可 |
| 使用场景 | 内部可信服务、管理操作 | 外部应用、临时授权、数据分发 |
服务器SAS Token怎么创建
创建SAS Token的方式不止一种，取决于你是在Azure门户（Portal）界面操作，还是通过代码或命令行自动化生成，下面按路径拆解。
前置条件：先选对认证方式
在创建Token之前,有一个关键细节经常被忽略：新创建的存储账户默认只允许通过密钥（Account Key）认证，SAS认证默认是关闭的，也就是说，如果你直接尝试生成Token，系统会提示“已禁止对该存储帐户执行操作”。
操作路径如下：
- 登录Azure门户,打开目标存储账户。
- 左侧菜单找到“配置”（Configuration）或“设置”（Settings）。
- 找到“允许共享密钥访问”（Allow shared key access）选项，将其设置为“已启用”
（Enabled）。
- 点击页面底部的“保存”。
这一步不完成,后面所有的SAS创建步骤都会报错，多数情况下，这个问题是新手配置SAS时遇到的第一道坎。
通过Azure门户创建（图形界面）
这种方式适合单次创建、测试验证或对代码不熟悉的运维人员。
- 在存储账户概览页左侧菜单中,找到“共享访问签名”（Shared access signature）选项。
- “允许的资源类型”：勾选“服务”（Service）、“容器”（Container）或“对象”（Object），如果只是给某个Blob文件生成访问链接，勾选“对象”即可；如果是给容器下所有文件授权，勾选“服务”和“容器”。
- “允许的权限”：按需选择“读取”、“写入”、“删除”、“列出”等，基本原则是只勾选业务必须的权限，比如只读场景就不要勾选“写入”。
- “开始和到期时间”：设置Token的有效期，建议将开始时间设为当前时间，到期时间根据业务需求设定，最短可以只给5分钟。
- 点击“生成SAS和连接字符串”按钮，页面底部会生成一长串Token字符串。
生成的Token看起来类似：sv=2026-11-02&ss=b&srt=sco&sp=rwdlacx&se=2026-12-31T23:59:59Z&st=2026-01-01T00:00:00Z&spr=https&sig=xxxxxxxxxxxx%3D
把这串Token拼接在资源URL的末尾,用分隔，就得到了完整的可访问链接。
通过代码创建（C#示例）
自动化运维场景下,代码创建更高效，以下示例使用Azure.Storage.Blobs SDK（适用于.NET）：
using Azure.Storage;
using Azure.Storage.Sas;
using Azure.Storage.Blobs;
using Azure.Storage.Blobs.Models;
// 连接字符串中的AccountName和AccountKey
string connectionString = "DefaultEndpointsProtocol=https;AccountName=yourstorage;AccountKey=yourkey;EndpointSuffix=core.chinacloudapi.cn";
BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
// 指定要授权的容器
BlobContainerClient containerClient = blobServiceClient.GetBlobContainerClient("mycontainer");
// 创建SAS生成器
BlobSasBuilder sasBuilder = new BlobSasBuilder()
{
BlobContainerName = "mycontainer",
Resource = "c", // c代表容器级别，b代表单个Blob
ExpiresOn = DateTimeOffset.UtcNow.AddHours(2)
};
// 赋予权限：只读 + 列出
sasBuilder.SetPermissions(BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List);
// 生成Token
string sasToken = containerClient.GenerateSasUri(sasBuilder).Query;
Console.WriteLine($"SAS Token: {sasToken}");
这段代码会生成一个2小时内有效的容器只读Token,运行前需要通过NuGet安装Azure.Storage.Blobs包。
通过Azure CLI创建（命令行）
Linux服务器或自动化脚本中,CLI方式最为轻量：
az storage container generate-sas --account-name yourstorage --account-key yourkey --name mycontainer --permissions rl --expiry 2026-12-31T23:59:59Z --https-only
其中--permissions rl表示读取（r）和列出（l）权限，--expiry指定过期时间，输出结果直接就是Token字符串。
两种层级的Token怎么选
- 服务级SAS Token：针对单个服务（如Blob、File、Queue）生成，资源范围较广，配置灵活。
- 账户级SAS Token：针对整个存储账户生成，可以同时覆盖多个服务，权限粒度更粗，一般只在需要同时管理多个服务时使用。
对于绝大多数服务器文件共享、备份、日志上传场景，服务级SAS Token足够用，账户级反而扩大了风险暴露面。
SAS Token有效期怎么设置
有效期设置是SAS Token配置中最容易出问题的环节，设置过短，客户端频繁报403过期错误；设置过长，又违背了“临时凭证”的初衷。
时间策略参考
| 业务场景 | 建议有效期 | 原因 |
|---|---|---|
| 前端直传文件到Blob | 5-30分钟 | 上传动作完成后即失效，缩短暴露窗口 |
| 服务器间定时备份 | 1-8小时 | 覆盖备份脚本执行窗口即可 |
| 日志文件批量下载 | 1-24小时 | 给运维留出足够处理时间 |
| 长期数据分发（如安装包） | 1-7天 | 不建议超过7天，到期后重新生成即可 |
设置时注意三个细节
- 时区陷阱：Azure门户中默认使用UTC时间，如果你设置“2026-12-31 08:00:00”作为到期时间，而你的服务器在UTC+8时区，实际到期时间相当于北京的16:00，设置时必须换算时差，否则Token会比你预期的时间更早失效。
- 时钟偏移容忍度：Azure默认允许最多15分钟的时钟偏移，如果客户端本地时间与服务器标准时间差异过大，即使Token在有效期内，也可能被判定为无效，生产环境务必保证客户端服务器时间同步（NTP）。
- 先签名后使用：修改Token中的任何参数（如延长有效期），都需要重新用密钥签名，直接在已有Token字符串上手动改参数会导致签名验证失败，403错误。
SAS Token管理三个关键习惯
创建Token只是第一步,服务器上线后长期稳定运行，靠的是管理习惯。
尽量使用存储访问策略
存储访问策略（Stored Access Policy）相当于给SAS Token加了一层“总开关”，你可以在容器上预先定义一组权限和时间范围，然后创建Token时引用这个策略，好处是：将来想批量吊销所有Token，只需要修改或删除这个策略，所有关联的SAS立即失效，无需逐个重新生成。
- 在门户中进入某个容器 → “访问策略” → “添加策略”。
- 设置策略ID（如
read-only-policy）、权限、生效时间。 - 生成Token时,在
SignedIdentifier字段填上策略ID。
不使用策略的独立Token无法单独吊销,只能等它自然过期，这是应急响应时最尴尬的事情。
最小化权限原则
生成Token时,默认所有权限都是未勾选状态，这一点要始终坚持：只给必须具备的权限，宁可后续再加，也不要一开始就给全。
- 只读场景：勾选
读取，不勾写入和删除。 - 单文件分享：勾选
对象级别的读取，不勾选容器级别的列表列表权限会暴露容器内所有文件名，相当于把目录结构免费送给了别人。 - 内网传输：在“允许的IP地址”中填写服务器固定出口IP，限制Token只能从该IP发起请求。
定期检查并轮换
近年来,不少企业因长期未使用的SAS Token被第三方恶意调用而遭遇数据泄露，建议：
- 每月在门户的“共享访问签名”页面检查现存Token，删除过期或即将过期但不用的配置。
- 每年轮换一次存储账户密钥,轮换前先确保所有依赖旧密钥的服务都切换到新密钥，避免业务中断。
- 使用Azure Monitor中的“SAS生成事件”日志，统计Token的使用频率，对长期未使用的Token做一次清理。
SAS Token把存储访问的权限精细化到“某个文件、某段时间、某种操作”，是服务器对外提供数据能力时安全性最高的方案之一。创建过程本身只需要几分钟，真正的功夫在权限设计和生命周期管理上，记住一个原则：密钥是底线，SAS是常态；权限能少给一分，风险就少一分。
关于SAS Token创建的常见问题
创建SAS Token时提示“已禁止对该存储帐户执行操作”怎么办？
这是因为存储账户的“允许共享密钥访问”选项被禁用了，进入存储账户的“配置”页面，将“允许共享密钥访问”改为“已启用”并保存，即可正常生成SAS Token，如果这一步是在组织策略层面锁定，需要联系管理员在Azure Policy中调整。
SAS Token和存储访问策略（Stored Access Policy）是一回事吗？
不是,SAS Token是最终附加在URL上的凭据字符串，而存储访问策略是容器上定义的一组规则，可以被多个SAS Token引用，使用策略的好处在于可以集中管理和吊销Token。
生成的SAS Token有效期明明没到，为什么请求返回403？
首先检查客户端与服务器的时间差,时钟偏移超过15分钟会被拒绝，其次确认Token的签名参数中是否包含https-only限制而客户端使用了HTTP协议，最后确认Token字符串在拼接URL时是否有额外的查询参数冲突，比如URL中已经存在其他参数，需要使用&连接而非重复使用。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/585627.html
