如何让开发者只读访问Azure存储生产数据且禁止匿名？

我来分享几个经过实践验证的方案，完美匹配你的需求——让开发者能通过Azure Storage Explorer查看生产数据，但没法意外编辑，还不用走匿名只读的路子：

方案一：利用Azure RBAC分配只读角色 #

这是最推荐的方案，基于Azure AD身份管理，权限管控精细且安全：

• 针对Blob存储：给开发者的Azure AD账户（或组）分配Storage Blob Data Reader角色，这个角色仅允许读取Blob容器和数据，没有写入、删除权限。
• 针对Table存储：分配Storage Table Data Reader角色，同样只开放读取表数据的权限。
• 操作步骤：
  1. 登录Azure门户，找到目标存储账户。
  2. 进入「访问控制（IAM）」页面，点击「添加角色分配」。
  3. 搜索并选择对应的只读角色，接着添加需要授权的开发者用户或用户组。
  4. 确认后，开发者打开Azure Storage Explorer，用自己的Azure AD账户登录，就能看到对应的存储资源，但所有编辑/删除操作都会被拒绝。

方案二：生成带只读权限的共享访问签名（SAS） #

如果不想让开发者用Azure AD账户登录，可以用SAS来提供受限的只读访问：

• 生成SAS时，严格限制权限：只勾选「读（r）」权限，取消所有写入、删除、添加等权限。
• 额外安全措施：
  • 设置合理的过期时间（比如一周或一个月），避免长期有效。
  • 绑定开发者的固定IP地址，只有指定IP能使用这个SAS。
  • 选择最小的资源范围：比如只给特定容器/表生成SAS，而不是整个存储账户。
• 开发者使用方式：在Storage Explorer中选择「通过SAS连接」，输入SAS URI或共享访问令牌，就能只读访问目标资源。记得定期轮换SAS，进一步降低风险。

方案三：创建专用只读服务主体 #

如果团队开发者较多，用AD组管理还是麻烦，可以创建一个专门的只读服务主体：

• 在Azure AD中注册一个新的应用程序（即服务主体），给它分配Blob和Table的只读RBAC角色。
• 生成服务主体的凭据（客户端密钥或证书），分发给需要访问的开发者。
• 开发者在Storage Explorer中选择「使用服务主体登录」，输入客户端ID、租户ID和凭据，就能以只读权限访问存储资源。
• 优势：可以统一管理这个服务主体的权限，比如随时撤销或更新权限，不用逐个调整开发者的账户权限。

额外注意事项 #

• 定期审计权限：通过Azure门户的「访问控制（IAM）」页面，检查有没有多余的权限分配，确保权限最小化。
• 测试验证：给开发者授权后，一定要测试下编辑/删除操作是否会被拒绝，确保权限配置正确。
• 对于Table存储，注意「Storage Table Data Reader」角色不会允许修改表结构或数据，完全符合只读需求。

内容的提问来源于stack exchange，提问作者Sjors Miltenburg