临时策略为什么会长期存在
测试、临时接入、短期对接这类需求，申请时通常写着「先开通，用完删除」。但没有人负责到期回收，也没有系统提醒，几周后申请人与运维的关注点都转移了，这条策略就默默留在设备上。临时策略是长期风险最常见的来源：它当初按最小需求开通，却缺少依据、缺少责任人，也缺少后续复核。
基本信息
| 登记内容 | 申请人、用途、有效期、预期删除时间、责任人 |
|---|---|
| 提醒机制 | 到期前提醒申请人与运维，而非临期临时沟通 |
| 到期处理 | 确认是否仍需：需要则走变更延期，不需要则删除 |
| 删除要求 | 按变更流程执行，同步清理配套例外与映射 |
| 闭环记录 | 删除后更新台账与评审记录 |
| 检查频率 | 纳入季度策略评审，集中处理过期项 |
典型使用场景
- 测试环境所需的临时访问开通
- 短期供应商或合作方接入
- 活动期间临时放开特定端口或来源
- 故障处置时的临时放行，事后需要回收
- 季度评审时集中清理已过期的临时开通
管理动作
管理动作
开通：登记台账并设置到期提醒 # 一开始就管起来
到期：与申请人确认是否仍需使用 # 到期复核
延期：重新提交依据与期限，走变更流程 # 不接受口头延期
删除：按变更流程执行，清理配套例外与映射 # 彻底回收
复盘：更新台账与评审记录，统计延期次数 # 评估依据质量风险与对应措施
| 风险 | 对应措施 |
|---|---|
| 策略被遗忘长期保留 | 登记有效期并设置到期提醒 |
| 到期后反复延期 | 延期需重新提交依据，统计延期次数 |
| 责任人不明确 | 台账登记申请人与运维双方责任人 |
| 清理不彻底 | 删除策略同时清理例外白名单与映射 |
| 无从发现过期项 | 纳入季度策略评审集中核查 |
临时策略是长期风险的常见来源：用台账加提醒，把「临时」真正管成临时，而不是靠人的记忆。
同一地址或同一需求反复延期时，说明它其实已经是长期需求：应重新按正式流程评审依据与范围，而不是继续挂着临时标签。