![]()
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令牌在用,轮换密钥前需要多久完成全量替换?微软官方文档的建议是"预留足够时间",但"足够"二字的具体数字,取决于你上次梳理令牌清单是什么时候。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.