介绍
一个发货集成会读取待处理订单并发布发货更新。当前仓库示例看起来没有问题，但被删除的 API 密钥可能仍能访问服务。你负责控制泄露并恢复待执行的发货任务。
运用引导实验中练习过的 Git 调查、定向吊销、权限选择、私有配置和业务验证方法，在保持无关监控可用的同时完成发货结果。挑战从独立的预配置环境开始。
恢复发货集成
当前情况
发货团队使用预置 worker 读取待处理订单并发布发货更新。例如，处理批次后，订单 O-201 应获得状态 ready。密钥已从当前仓库示例删除，但告警表明仍可从历史中恢复。dispatch 批次尚未处理。无关的可用性监控必须保持正常；控制泄露期间允许发货任务暂时暂停。
环境使用与引导实验相同的本地教学服务、Git 方法、管理界面、INI 格式和两个终端角色。所有内容均为模拟，无需外部账号。
请使用当前 VM 的凭据，不要沿用之前实验的值。与引导实验相同，本服务用 401 表示凭据无效或已吊销，403 表示有效凭据缺少所需权限，200 表示读取被接受。worker 每次调用都会读取私有文件，无需重启。
范围
- Workstation 打开后位于
/home/labex/project/repository。其中的三个提交及shipping-example.ini包含历史证据。当前示例并非运行配置。 - Integration 以
keyworker在/home/labex/project中运行。私有配置是runtime/job.ini；不得修改的 worker 是/opt/keylab/worker.py，接收批次名作为参数。 - API 位于
http://127.0.0.1:8000。Key Manager 使用/home/labex/.config/keylab/operator-token中的操作员令牌管理凭据。 - 独立监控使用
lab_key_monitor_only访问GET /v1/health。
| 操作 | 所需权限范围 | 业务用途 |
|---|---|---|
GET /v1/orders |
orders:read |
读取待处理订单 |
POST /v1/shipment-updates |
shipment-updates:write |
发布发货状态 |
GET /v1/results |
orders:read |
查看已接收的批次结果 |
GET /v1/customers |
customers:read |
无关的客户目录 |
GET /v1/health |
health:read |
独立监控 |
目标
历史中泄露的凭据不再获得 API 访问。未修改的发货 worker 使用保存在私有运行配置中的独立专用替代密钥，接收服务保存该替代密钥提交的完整 dispatch 发货结果。替代密钥仍无法读取客户目录，无关监控保持正常。
验收标准
- 历史泄露密钥已吊销，读取订单得到
401，同时 API 保持可达。 - 已配置的替代密钥有效，且恰好拥有两项发货业务权限，与泄露密钥不同。
/home/labex/project/runtime/job.ini属于keyworker，模式为600，可由该服务账号读取。新秘密值既不出现在仓库文件中，也不出现在其提交中。- 未修改的 worker 使用已配置的替代密钥读取指定
dispatch批次，接收端 API 以同一替代密钥 ID 接受订单O-201与O-202的结果，两者状态均为ready。 - 替代密钥读取客户目录得到
403。未更改的监控凭据读取健康检查端点仍得到200。
提示
删除的秘密值可能留在哪里？
比较当前示例与早期提交。将历史密钥 ID 对应到管理界面记录；仅靠显示名称无法识别凭据。
有效的替代密钥为何仍然失败？
worker 既发送输入请求，也发送输出请求。用端点表区分权限范围不足与秘密值错误或已吊销。shell 变量不会更新私有运行文件。
什么证据能证明业务已恢复？
仅演示运行或终端消息并不足够。查看接收端 API 中的指定批次，并将其密钥 ID 与已配置替代密钥比较。保持预置 worker 不变。
总结
你将事件响应方法从支持摘要任务迁移到了发货集成。完整响应需要让历史秘密值失效，用专用受限凭据恢复实际业务，把秘密值留在版本控制之外，并保持无关服务的访问。
