临时发布为什么要回收
调试、活动、临时对接开通的目的映射，申请时通常写着「先开通，用完删除」，但到期没有提醒机制，映射就长期留在边界设备上，变成无人维护的暴露点：服务可能早已下线、维护人已经换岗，端口却仍然可达。回收要做的不只是删映射本身，配套策略、例外白名单与台账都要同步清理，否则暴露面只是换了形态。
基本信息
| 回收触发 | 到期日、活动结束、项目下线、责任人变更 |
|---|---|
| 执行内容 | 删除目的映射、配套策略与例外、更新台账 |
| 验证方式 | 从公网复测端口不可达，内网服务同步收回 |
| 通知环节 | 提前通知业务方，避免突然中断引起投诉 |
| 观察期 | 保留一周观察记录，确认无系统仍在调用 |
| 台账要求 | 临时开通必须登记有效期与责任人 |
典型使用场景
- 活动期间临时开放的对外服务，活动结束后回收
- 项目调试期的临时映射，上线后统一收口
- 厂商远程支持用的临时通道，支持结束后按期关闭
- 业务下线后对应映射与策略的清理
- 季度策略评审时集中处理已过期的临时发布
回收清单
回收清单
1. 确认已到期或业务已结束，通知相关业务方 # 前置
2. 边界设备删除目的映射与关联地址池引用 # 主体
3. 删除配套安全策略与例外规则 # 最易漏
4. 内网服务确认已下线或收回为仅内部访问 # 一致性
5. 从公网复测端口不可达 # 验证
6. 台账标记失效并记录回收人与时间 # 留痕漏回收的形态与后果
| 漏掉的部分 | 后果 |
|---|---|
| 只删映射不删策略 | 留下空放行，策略仍在但服务已不存在 |
| 例外规则未删 | 为临时需求开的白名单长期有效，成为绕过点 |
| 台账未更新 | 资产清单失真，下次评审无法判断映射是否还有效 |
| 未验证关闭 | 以为已删除实际仍可达，暴露面长期存在 |
回收后保留一周观察记录：若有系统仍在调用会及时暴露，而不是等到业务投诉才发现。
临时发布不登记有效期与责任人，等于把回收责任交给「以后再说」，这类暴露点最容易在安全检查中被抓出来。