Flask实现STS临时凭证获取：OSS安全直传方案详解

1. 为什么不用 AccessKey 直传而是折腾一套 STS先说结论如果你的 Flask 服务端只负责把文件上传到 OSS并且这个服务只给你自己的后台用那直接用阿里云主账号或者 RAM 用户的 AccessKey 写死在代码里确实能跑而且代码量至少少三分之一。但只要是涉及到前端直传、第三方用户上传、或者你的服务要暴露在公网环境AccessKey 直传就是一颗定时炸弹。我见过不少团队把 AccessKey 放在前端 JavaScript 代码里或者放在 Flask 的配置文件里提交到 Git 仓库结果就是某天云账号被刷了几千块流量账单。AccessKey 等同于你云资源的全部管理权限一旦泄露对方能做的事远不止上传文件——删 Bucket、开新实例、拉取你所有的数据快照全都可以。而 STSSecurity Token Service临时凭证的核心价值就在于它是临时的有效期可以设置成 15 分钟到 12 小时它是受限的可以通过 RAM 角色授权精确到某个 Bucket 的某个目录它是可回收的即使泄露过期即失效。所以这套方案的典型适用场景是前端网页或 App 需要直接上传文件到 OSS不想经过 Flask 服务端中转减少服务器带宽和内存压力你给第三方开放上传能力但不希望暴露你的长期密钥多环境隔离测试环境和生产环境使用不同的 RAM 角色互不干扰审计需求所有临时凭证的颁发和使用都可以在云盾和 RAM 操作日志中追踪这个标题里的技术组合其实就是把 STS 临时凭证的获取封装在 Flask API 里客户端请求这个接口拿到临时凭证后直接用 OSS SDK 上传。整个链路是客户端 → Flask APISTS 接口→ RAM 角色临时凭证→ OSS 文件上传。下面我把每一步拆开讲清楚并附上可直接复现的完整代码。2. 核心机制拆解STS、RAM 角色和 OSS 是怎么协作的2.1 STS 临时凭证的三个关键字段你调用 STS 接口后返回的凭证包含三个核心部分缺一不可AccessKeyId临时凭证的 ID形式上看起来和长期 AccessKey 一致但前面通常带一个前缀区分AccessKeySecret临时凭证的密钥配合上面的 ID 使用SecurityToken这是 STS 独有的令牌字段OSS SDK 在初始化客户端时必须指定否则会报 InvalidAccessKeyId 错误实际使用中SecurityToken 是最容易被忽略的。很多人用长期密钥的习惯没改过来拿着临时 AccessKeyId 和 AccessKeySecret 就往 OSS SDK 里填结果怎么调试都报权限错误。我第一次踩这个坑的时候排查了整整两个小时最后发现就是少传了 SecurityToken。这三个字段的有效期由你在调用 AssumeRole 接口时通过 DurationSeconds 参数指定范围是 900 秒15 分钟到 43200 秒12 小时。不建议设置得太长因为临时凭证的作用就是缩小风险窗口。如果某个上传任务超过 12 小时应该重新获取凭证而不是拉长有效期。2.2 RAM 角色和授权策略的作用RAM 角色是一个虚拟身份它本身没有长期凭证只能通过 AssumeRole 来换取临时凭证。你在创建角色时必须附加一个信任策略Trust Policy这个策略声明了谁有权限来 Assume 这个角色——通常就是你指定的一批 RAM 用户。角色创建好后还要给它附加一个权限策略Permission Policy这个策略决定了临时凭证能做什么操作。我们做 OSS 上传最小权限只需要类似这样的配置{ Version: 1, Statement: [ { Effect: Allow, Action: [ oss:PutObject, oss:GetObject ], Resource: [ acs:oss:*:*:your-bucket-name/uploads/* ] } ] }注意 Resource 字段里的路径限定我写了 uploads/*意味着这个角色只能操作该 Bucket 下 uploads 目录里的对象其他的读不了也写不了。这就是最小权限原则的落地临时凭证即使被拿到攻击者也最多往你指定的目录里塞文件动不了其他任何数据。2.3 客户端上传的两种路径对比STS 可以配合两种上传模式这个要提前想清楚因为它直接决定了你的 Flask API 设计第一种服务端中转上传。客户端把文件交给你的 Flask API你的 Flask 服务拿到临时凭证后自己调用 OSS SDK 上传。好处是逻辑最简单所有上传行为都经过你的服务方便做二次鉴权和审计坏处是文件流经你的服务器占用带宽和处理时间大文件上传时 Flask 服务可能成为瓶颈。第二种客户端直传。Flask API 只负责返回临时凭证客户端拿到凭证后用 OSS SDK 直连 OSS 上传不经过你的服务器。好处是 OSS 有多线接入和断点续传能力大文件上传体验更好服务器压力小坏处是上传逻辑要写在客户端而且你要信任客户端不会滥用临时凭证不过权限策略已经把可操作范围限定死了风险可控。我在项目里两种方案都用了一般建议优先考虑第二种这也是标题里Flask API 实现的核心价值——你的 Flask 服务做的事情是颁发临时凭证而不是搬运文件数据。下面我按第二种方案讲完整实现流程第一种方案在 API 设计处也会给出变体说明。3. 动手前需要准备的东西3.1 阿里云控制台侧的准备工作清单这套代码不是纯本地就能跑通的需要先在阿里云控制台完成以下操作创建 RAM 用户。登录阿里云 RAM 控制台新建一个用户访问方式选择OpenAPI 调用。创建完成后会得到这个用户的 AccessKeyId 和 AccessKeySecret妥善保存。这个用户是用来调用 AssumeRole 接口换取临时凭证的权限只需要 AssumeRole 这一个动作所以它也被称作STS 调用者。创建 RAM 角色。在 RAM 角色管理页面创建一个角色类型选择阿里云账号信任实体选择当前账号。创建时记得记录角色的 ARN阿里云资源名称格式类似acs:ram::1234567890123456:role/oss-upload-role后面代码里要用。给角色附加权限策略。参考上面的 JSON 策略把 Action 和 Resource 换成你的实际值。如果上传目录不止一个可以加多个 Resource 条目但务必精确到目录级别。给 RAM 用户授权 AssumeRole。在 RAM 用户详情页添加权限选择系统策略AliyunSTSAssumeRoleAccess或者自定义一个只包含sts:AssumeRole的策略。这样这个用户就只具备换取临时凭证的能力。3.2 Python 环境和依赖安装我的开发环境是 Python 3.10配合虚拟环境管理依赖。需要安装的库就三个pip install flask aliyun-python-sdk-sts oss2flaskWeb 框架提供 API 接口aliyun-python-sdk-sts阿里云 STS SDK负责调用 AssumeRoleoss2阿里云 OSS Python SDK客户端用它来做实际的文件上传版本方面截至本文写作时aliyun-python-sdk-sts的最新稳定版本是 3.xoss2是 2.18.x直接安装最新版即可。建议把依赖写进requirements.txt方便项目迁移部署。4. Flask API 获取 STS 临时凭证的完整实现4.1 项目目录结构我习惯把配置、STS 服务和 API 路由分开写这样后期维护起来不用在一堆代码里翻找oss-sts-flask/ ├── app.py # Flask 应用入口 ├── config.py # 配置信息OSS Bucket、角色 ARN 等 ├── services/ │ └── sts_service.py # STS 凭证获取逻辑 └── requirements.txt # 依赖清单4.2 配置文件的写法# config.py import os class Config: # 阿里云账号 AccessKeyRAM 用户的不是主账号的 ACCESS_KEY_ID os.getenv(ALIYUN_ACCESS_KEY_ID, your-ram-user-access-key-id) ACCESS_KEY_SECRET os.getenv(ALIYUN_ACCESS_KEY_SECRET, your-ram-user-access-key-secret) # RAM 角色的 ARN ROLE_ARN os.getenv(ALIYUN_ROLE_ARN, acs:ram::1234567890123456:role/oss-upload-role) # 角色会话名称用于审计建议带上业务标识 ROLE_SESSION_NAME os.getenv(ROLE_SESSION_NAME, flask-upload-session) # 临时凭证有效期单位秒默认 36001小时 DURATION_SECONDS int(os.getenv(STS_DURATION_SECONDS, 3600)) # OSS 相关配置 OSS_BUCKET your-bucket-name OSS_REGION oss-cn-hangzhou OSS_ENDPOINT fhttps://{OSS_REGION}.aliyuncs.com这里有几个细节要说明不要把 AccessKey 硬编码写在代码里通过环境变量读取是基本素养。配置文件里我写了默认值实际部署时一定要用环境变量覆盖。OSS_REGION要和你创建 Bucket 时选择的地域保持一致后缀是固定的。你在华东1杭州建的 Bucket就是oss-cn-hangzhou华北2北京就是oss-cn-beijing。写错了会报连接错误或者 Bucket 不存在。ROLE_SESSION_NAME建议带上业务标识比如订单号、用户 ID后期排查问题时能追溯到具体是哪次会话申请的凭证。4.3 STS 服务封装# services/sts_service.py import json from aliyunsdkcore.client import AcsClient from aliyunsdkcore.request import CommonRequest from aliyunsdkcore.acs_exception.exceptions import ClientException, ServerException def get_sts_token(config): 获取 STS 临时凭证 client AcsClient( config.ACCESS_KEY_ID, config.ACCESS_KEY_SECRET, cn-hangzhou # STS 服务的 region固定填 cn-hangzhou 即可 ) request CommonRequest() request.set_method(POST) request.set_domain(sts.aliyuncs.com) request.set_version(2015-04-01) request.set_action_name(AssumeRole) request.set_protocol_type(https) request.add_query_param(RoleArn, config.ROLE_ARN) request.add_query_param(RoleSessionName, config.ROLE_SESSION_NAME) request.add_query_param(DurationSeconds, config.DURATION_SECONDS) try: response client.do_action_with_exception(request) data json.loads(response) credentials data.get(Credentials, {}) return { access_key_id: credentials.get(AccessKeyId), access_key_secret: credentials.get(AccessKeySecret), security_token: credentials.get(SecurityToken), expiration: credentials.get(Expiration) } except (ClientException, ServerException) as e: # 记录日志并抛出业务异常由上层 API 统一处理 raise RuntimeError(fFailed to get STS token: {str(e)})这里我用了 CommonRequest 而不是专门的 AssumeRoleRequest。aliyun-python-sdk-sts这个包虽然提供了专门的数据类但 CommonRequest 的写法更灵活而且依赖更少代码也更直观。如果你喜欢用了类型提示的写法也可以用 SDK 自带的AssumeRoleRequest逻辑是一样的。region为什么固定填cn-hangzhou因为 STS 服务的接入点是全局统一的不区分地域你从哪个 region 的服务器请求都行但请求域名固定是sts.aliyuncs.com。4.4 Flask API 接口层面的设计# app.py from flask import Flask, jsonify, request from config import Config from services.sts_service import get_sts_token app Flask(__name__) app.route(/api/oss/token, methods[GET]) def get_upload_token(): 获取 OSS 上传所需的 STS 临时凭证 config Config() # 可选的业务参数指定上传目录前缀 upload_dir request.args.get(dir, uploads) try: token_info get_sts_token(config) # 拼接客户端上传所需的额外信息 result { access_key_id: token_info[access_key_id], access_key_secret: token_info[access_key_secret], security_token: token_info[security_token], expiration: token_info[expiration], endpoint: config.OSS_ENDPOINT, bucket: config.OSS_BUCKET, upload_dir: upload_dir, status: success } return jsonify(result), 200 except Exception as e: app.logger.error(fGet STS token failed: {e}) return jsonify({status: error, message: 获取临时凭证失败}), 500 if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)接口设计上有两个细节值得展开我用了 GET 方法因为获取凭证本身是幂等操作不改变服务端状态。但如果你有每次上传都一定要申请新凭证的需求改成 POST 也行。实际项目中我用得更多的是 POST因为通常还要带上一些业务参数做鉴权。upload_dir参数允许客户端指定上传目录前缀如果业务上有多个目录分别存储不同类型的文件这个参数就能派上用场。但注意如果你要严格限制目录需要在 STS 的权限策略里把路径固定死不能客户端传什么就允许什么。4.5 客户端使用临时凭证上传 OSS拿到 Flask API 返回的数据后客户端可以是普通 Python 脚本、浏览器或者移动端用 oss2 完成上传。核心代码如下import oss2 # 假设 data 是上面 API 返回的 JSON 数据 auth oss2.StsAuth( data[access_key_id], data[access_key_secret], data[security_token] ) bucket oss2.Bucket( auth, data[endpoint], data[bucket] ) # 构造上传对象名注意使用 API 返回的 upload_dir 作为前缀 object_name f{data[upload_dir]}/{uuid.uuid4().hex}.jpg # 从本地文件上传 bucket.put_object_from_file(object_name, /path/to/local/file.jpg)这段代码的关键点是oss2.StsAuth它和我们平时用的oss2.Auth不一样——多传了一个security_token。如果用Auth初始化OSS 服务器会因为你没有携带临时令牌而拒绝访问。注意到 object 名称前面的upload_dir一定要和 STS 权限策略里的资源路径前缀对应上。比如权限策略限定的是uploads/*那这里upload_dir就必须是uploads否则即使凭证有效OSS 也会抛出AccessDenied异常。这个坑至少有一半的初次使用者会踩。如果你做的是服务端中转上传模式可以省略上面这段客户端代码直接在 Flask 服务端用同样的方式初始化 bucket 对象然后调用put_object_from_file接收客户端传过来的文件。注意此时upload_dir的校验逻辑由你服务端自己保证不能依赖客户端传参。5. 实际上线过程中最容易踩的四个问题5.1 临时凭证过期导致的上传失败STS 临时凭证默认有效期 3600 秒如果你客户端上传的是超大文件比如几个 GB 的视频上传时间可能超过凭证有效期就会在中途报AccessDenied或RequestTimeTooSkewed错误。解决方案有两种如果上传不会超过 30 分钟把DurationSeconds调到 1800 或 3600 就够用了不用过度追求长时间如果上传时间可能超过 1 小时改用 OSS 的断点续传功能bucket.resumable_upload并且在上传过程中监控凭证的过期时间在过期前重新申请新凭证并重试5.2 策略权限配置正确但仍然报 AccessDenied这是最迷惑人的问题之一。你确认了权限策略的 Action 包含oss:PutObjectResource 路径也填对了但上传时还是被拒绝。我遇到过的真实原因有两种OSS 的 Policy 判断是基于最终的 object 名称来匹配的如果你在put_object_from_file时指定的 key 是upload/2024/01/file.jpg但策略里写的是uploads/*那就会因为前缀不匹配而被拒绝。检查一下你是不是把upload和uploads混用了。RAM 角色的信任策略没配置好。如果代码报的是没有权限调用 AssumeRole可能是 RAM 用户本身缺少sts:AssumeRole授权或者是信任策略中的 Principal 没有包含这个用户。5.3 客户端直传时 CORS 配置缺失如果你是在浏览器里直接用 JS SDK 上传OSS Bucket 必须配置 CORS 规则。否则浏览器会拦截 OSS 返回的跨域响应表现为上传请求发出去了但浏览器控制台报跨域错误上传结果一片空白。配置 CORS 的位置在 OSS Bucket 的数据安全 → 跨域设置里需要添加一条规则允许的来源写你的前端域名不加路径允许的 Method 勾选 PUT、POST、GET允许的 Header 填*暴露的 Header 填ETag。5.4 Flask 服务性能瓶颈STS 凭证获取本身是一个同步的 HTTP 请求到阿里云 STS 服务网络往返大约几十到一百毫秒。如果你的 Flask API 需要支撑高并发调用建议在 Redis 里加一层短期缓存——凭证还有效期内直接从缓存返回避免每次都打到 STS 接口。但缓存的 key 一定要包含upload_dir等业务参数不要所有接口共用一个缓存。import time # 伪代码示例 cached_token redis_client.get(fsts_token:{upload_dir}) if cached_token: return json.loads(cached_token) # 没有缓存走真实 STS 调用 token_info get_sts_token(config) redis_client.setex(fsts_token:{upload_dir}, token_info[expiration], json.dumps(token_info))注意缓存的过期时间建议比凭证的实际过期时间提前 60 秒防止凭证刚好在客户端上传前一刻失效。6. 安全加固和上线前检查清单这套方案本身的安全性建立在几个基础上RAM 用户权限最小化、角色权限最小化、临时凭证生命周期管理、和网络传输安全。结合我实际项目的经验下面这个清单值得逐项确认[ ] RAM 用户的 AccessKey 是否启用了轮换机制至少每 90 天更换一次不要把密钥写死在代码仓库里[ ] RAM 角色的权限策略是否限定到了具体 Bucket 和目录是否存在*通配符滥用[ ] Flask API 是否做了认证别人拿到你的接口地址就能直接要临时凭证的话等于免费送人上传通道必须在接口层加上你自己的 Token 鉴权或签名机制[ ] 是否启用了 HTTPSFlask 如果直接暴露公网至少要用 Nginx 做一层 HTTPS 转发不要裸奔 HTTP[ ] 是否配置了 STS 操作审计阿里云控制台的操作审计功能可以记录所有 STS AssumeRole 调用记录出了问题能追溯到客户端 IP[ ] 上传的文件类型是否做了校验OSS 本身不关心文件内容是什么你要在客户端或服务端做扩展名、MIME 类型、文件大小的校验另外一个容易被忽略的点是OSS Bucket 的读写权限建议设为私有Private即使你用的是临时凭证也不建议把 Bucket 开成公共读。客户端上传成功后如果需要展示文件通过 STS 临时凭证生成签名 URL 给前端访问而不是直接暴露一个公共可读的地址。7. 临时凭证的获取流程能否做进一步优化在基本流程跑通之后我建议你在项目里做两个小的改进会让整个系统更健壮第一个是凭证缓存。前面提到过 Redis 缓存这里说一下具体实现时的细节。缓存 key 建议带上业务标识比如sts:upload:uid:{user_id}:{dir}这样多个业务隔离缓存互不干扰。缓存的 value 直接存 STS 返回的整个 Credentials 字典读取时反序列化即可。要特别注意缓存的过期时间设置——凭证的Expiration字段是一个具体的时间点缓存有效期应该设置为expiration - now - 60s而不是简单地设置一个固定值这样才能保证不会缓存到已经过期的凭证。第二个是错误码的规范返回。目前我的 API 在获取凭证失败时统一返回 500但实际分不清是参数问题、权限问题还是 STS 服务异常。建议给异常分分类# 伪代码示例 if InvalidParameter in str(e): return jsonify({status: error, code: INVALID_PARAM, message: 参数错误}), 400 elif Forbidden in str(e): return jsonify({status: error, code: FORBIDDEN, message: 无权操作}), 403 else: return jsonify({status: error, code: STS_ERROR, message: STS服务异常}), 500这样客户端拿到不同的 code 时可以给用户呈现不同的提示信息排查问题也更高效。8. 一套可复用的 Flask 服务端参考代码前面讲了很多原理和细节这里把 Flask 服务端的完整代码整理成一个更贴近生产环境的版本包含鉴权、日志和异常处理。你可以直接复制改造成自己的项目。# app.py - 生产环境参考版 import logging import uuid from functools import wraps import oss2 from flask import Flask, jsonify, request from aliyunsdkcore.client import AcsClient from aliyunsdkcore.request import CommonRequest app Flask(__name__) logging.basicConfig(levellogging.INFO) # 配置化实际放在 config.py 或环境变量中 ACCESS_KEY_ID your-ram-access-key-id ACCESS_KEY_SECRET your-ram-access-key-secret ROLE_ARN acs:ram::1234567890123456:role/oss-upload-role ROLE_SESSION_NAME flask-production-session DURATION_SECONDS 3600 OSS_BUCKET your-bucket-name OSS_ENDPOINT https://oss-cn-hangzhou.aliyuncs.com # 简单接口鉴权生产环境建议替换为 JWT 或独立认证服务 API_TOKEN your-secret-api-token def require_token(f): wraps(f) def decorated(*args, **kwargs): token request.headers.get(X-API-Token) if token ! API_TOKEN: return jsonify({status: error, message: Unauthorized}), 401 return f(*args, **kwargs) return decorated def get_sts_token(): 调用 STS AssumeRole 获取临时凭证 client AcsClient(ACCESS_KEY_ID, ACCESS_KEY_SECRET, cn-hangzhou) request CommonRequest() request.set_method(POST) request.set_domain(sts.aliyuncs.com) request.set_version(2015-04-01) request.set_action_name(AssumeRole) request.set_protocol_type(https) request.add_query_param(RoleArn, ROLE_ARN) request.add_query_param(RoleSessionName, ROLE_SESSION_NAME) request.add_query_param(DurationSeconds, DURATION_SECONDS) response client.do_action_with_exception(request) import json data json.loads(response) return data[Credentials] app.route(/api/oss/token, methods[GET]) require_token def issue_upload_token(): 颁发临时上传凭证 upload_dir request.args.get(dir, uploads) if not upload_dir or not upload_dir.startswith(uploads): return jsonify({status: error, message: invalid dir}), 400 try: creds get_sts_token() return jsonify({ status: success, access_key_id: creds[AccessKeyId], access_key_secret: creds[AccessKeySecret], security_token: creds[SecurityToken], expiration: creds[Expiration], endpoint: OSS_ENDPOINT, bucket: OSS_BUCKET, upload_dir: upload_dir }) except Exception as e: app.logger.error(fSTS token error: {e}) return jsonify({status: error, message: internal error}), 500 app.route(/api/oss/upload, methods[POST]) require_token def server_side_upload(): 服务端中转上传备选方案 upload_dir request.form.get(dir, uploads) file request.files.get(file) if not file: return jsonify({status: error, message: no file}), 400 creds get_sts_token() auth oss2.StsAuth(creds[AccessKeyId], creds[AccessKeySecret], creds[SecurityToken]) bucket oss2.Bucket(auth, OSS_ENDPOINT, OSS_BUCKET) object_name f{upload_dir}/{uuid.uuid4().hex}_{file.filename} try: bucket.put_object(object_name, file.stream) return jsonify({status: success, url: fhttps://{OSS_BUCKET}.{OSS_ENDPOINT.replace(https://, )}/{object_name}}) except oss2.exceptions.OssError as e: app.logger.error(fOSS upload error: {e}) return jsonify({status: error, message: upload failed}), 500 if __name__ __main__: app.run(host0.0.0.0, port5000)这里有两种接口/api/oss/token是客户端直传模式/api/oss/upload是服务端中转模式。你根据实际需求选择保留其中一种即可。生产环境部署时记得去掉debugTrue用 gunicorn 或者 uWSGI 运行gunicorn -w 4 -b 0.0.0.0:5000 app:app服务端中转方案在拿到文件流之后还可以顺手做文件类型校验、大小限制甚至调用病毒扫描服务安全性上更有保障。直传模式胜在简单高效优缺点前面已经对比过。9. 常见问题速查表这个表格是我整理的实际开发中最高频的问题覆盖了从配置到运行的各个环节。如果你调试时遇到类似报错可以直接按表格排查报错信息根本原因解决方案InvalidAccessKeyId.NotFoundAccessKeyId 配置错误或已禁用检查 RAM 用户密钥是否正确是否被禁用Forbidden.RAMRAM 用户没有 AssumeRole 权限给 RAM 用户添加AliyunSTSAssumeRoleAccess策略AssumeRole access denied角色信任策略未包含该用户编辑角色信任策略在 Principal 中加入该 RAM 用户AccessDenied(上传时)临时凭证的权限策略和 object 路径不匹配检查上传的 object 前缀是否在权限策略 Resource 中RequestTimeTooSkewed客户端系统时间和 OSS 服务器时间偏差过大校准客户端系统时间尤其注意 Docker 容器内的时区问题InvalidSecurityToken.Expired临时凭证已过期重新获取凭证检查缓存过期时间设置SignatureDoesNotMatchSecurityToken 没有传给 OSS SDK确保使用oss2.StsAuth而非oss2.Auth浏览器跨域报错OSS Bucket 未配置 CORS在 OSS 控制台配置允许的来源和 Method排查这类问题有个通法先逐步排除配置问题然后看权限最后看时间。配置错了报错信息一般很直接权限问题要看策略和实际请求的资源是否匹配时间问题则比较隐蔽——我遇到过本地开发电脑和服务器时区不一致导致的诡异报错花了半天才定位到是时间偏移导致的签名校验失败。我个人在实际操作中的体会是STS 这套机制设计得其实并不复杂难的是权限模型的理解。只要你把 RAM 用户、角色、权限策略这三者之间的关系理清楚后面的开发就是按部就班的机械工作。建议你先用一个测试 Bucket 把完整链路跑通再逐步收紧权限不要一上来就追求最严格的策略否则容易在权限配置上卡住很久。最后再说一个小技巧阿里云控制台 OSS 提供了一个验证工具可以模拟上传请求调试哪一步出错会直接给出对应的 Policy 校验结果排查权限问题比看日志快得多。