微软把存储权限玩成定时炸弹：7天后自动失效的访问密钥

Azure存储账户的权限管理，本质上是一场与时间的博弈。一个测试文件上传后默认进入Hot tier，每天烧掉的钱够买两杯咖啡——而大多数管理员甚至不知道可以手动降级。

这不是技术门槛问题，是产品设计把关键功能藏得太深。

从上传文件到发现"烧钱陷阱"

打开名为marchsa的存储账户，这是上一步"Prepare"练习留下的资源。在Data storage区域找到Containers，新建一个容器，上传测试文件。系统弹出的第一个细节往往被忽略：文件自动分配到了Hot访问层级。

Hot tier的定价逻辑很简单——频繁访问的数据付高价买速度。但测试文件显然不配这个待遇。右键点击文件，Change tier选项藏在操作菜单里，Cool tier能砍掉60%以上的存储成本，Archive tier更狠，直接打到骨折价。

微软的界面设计在这里耍了个心眼：默认选最贵的，省钱功能需要主动挖掘。这种"惰性定价"策略在云服务领域司空见惯，但每次都让人想起健身房自动续费的套路。

容器搞定后，切到File shares标签页。文件共享（File Share）和容器的区别，可以类比成公司网盘和个人U盘——前者支持SMB协议挂载，能被多台虚拟机同时读写，后者更适合程序化的对象存储。

创建共享时需要指定配额，这个数字是硬上限，不是软性建议。配额设10GB，第10.001GB的文件会直接报错，没有缓冲地带。

SAS令牌：给权限装上倒计时器

文件传上去之后，真正的戏码才开始。管理员的需求很明确：不能让外部人员拿着永久有效的钥匙，但也不想暴露主账户密钥。

Azure的解法是共享访问签名（SAS, Shared Access Signature）。生成界面有一排时间控件，Start时间自动填充当前时刻，End时间需要手动设定。这里埋着一个设计细节——令牌有效期最短可以设1分钟，最长不能超过账户密钥本身的轮换周期。

权限粒度拆得很细：Read、Write、Delete、List可以任意组合。给外部合作方只开Read+List，相当于图书馆借书证；给内部CI/CD流水线开Write，相当于快递柜的投件码。

令牌生成瞬间，系统吐出两段字符串：SAS token和完整的URL。URL可以直接粘贴到浏览器，token则需要拼接到API请求里。两者的关系像房卡和房间地址——光有地址进不去，光有房卡不知道去哪。

但这里有个反直觉的设定：SAS令牌一旦发出，Azure侧没有任何"吊销列表"可以勾选。它不像企业VPN账号那样能在后台一键禁用，而是像射出去的箭，只能等它自己落地。

密钥轮换：唯一的后悔药

如果令牌发错了人，或者怀疑已经泄露，怎么办？

Azure的权限体系在这里露出刚性的一面。SAS令牌是用存储账户的访问密钥（Access Key）签名的，密钥有两个，Key1和Key2，互为备份。要作废一批令牌，必须轮换（Rotate）生成它们的那把密钥。

操作流程在Access keys页面：点击Rotate key，系统生成新密钥，旧密钥签名的所有SAS瞬间失效。这个动作没有二次确认弹窗，没有"影响评估报告"，执行后依赖旧令牌的自动化脚本会立即报错。

密钥轮换的残酷性在于它的无差别打击。你无法单独作废某一个SAS，只能一锅端。如果Key1签发了10个给不同团队的令牌，轮换Key1意味着10个团队同时收到故障通知。

这也是Azure保留Key2的原因——可以先用Key2重新签发一批新令牌，通知各方切换，再轮换Key1。这种"双轨并行"策略是大型运维的标准动作，但小团队往往图省事直接硬切，然后凌晨两点被报警短信炸醒。

整个练习串起来看，微软在存储安全上的设计哲学很清晰：默认开放，但给足工具让你自己收紧。Hot tier的默认选择、SAS的不可吊销、密钥轮换的批量效应，都在把决策成本转嫁给管理员。

这种设计不算坏，只是需要使用者清醒认识到——云厂商提供的"便利"，往往贴着隐性的价格标签。

最后留个实操问题：如果你的生产环境有200个SAS令牌在用，轮换密钥前需要多久完成全量替换？微软官方文档的建议是"预留足够时间"，但"足够"二字的具体数字，取决于你上次梳理令牌清单是什么时候。