为什么命名要立规范
策略命名规范要求名称里写清业务、源区域、目的区域、用途与申请单号，让几年后接手的人也能看懂这条策略为什么存在。命名是策略治理里成本最低的一笔投入：它不改变安全性，却直接决定日后审计、排查与清理的效率。规范要在策略数量增长之前定下来，之后再改就只能大规模重命名。
基本信息
| 建议结构 | 业务_源区域_目的区域_用途（可附申请单号） |
|---|---|
| 示例 | OA_Trust_DMZ_访问发布_CHG20261012 |
| 禁例 | abc、test1、policy-new 这类无信息量的命名 |
| 维护 | 业务下线或改名时同步更新策略名 |
典型使用场景
- 新建策略：按规范命名并写入申请单号
- 策略审计：靠名称快速判断用途与归属
- 策略清理：按名称中的业务标识识别已下线业务
- 交接与排障：不熟悉环境的人靠名称理解策略意图
- 规范落地：把命名要求写进变更模板，从入口处约束
命名示例
命名示例
# 结构：业务_源区域_目的区域_用途（可选单号）
ERP_Trust_Database_数据库访问_CHG20261012
GW_Untrust_DMZ_网站发布
VPN_Remote_Trust_远程接入_2026Q4到期
OA_Trust_DMZ_附件上传_临时开放_2026-11-30到期
# 避免：abc、test1、policy-new，或按人名、纯日期命名命名要素
| 要素 | 作用 | 示例 |
|---|---|---|
| 业务标识 | 定位归属系统 | ERP、OA、GW |
| 区域 | 明确方向与信任关系 | Trust_DMZ |
| 用途 | 说明为什么存在 | 数据库访问 |
| 单号或期限 | 追溯变更依据 | CHG20261012 |
临时策略在名称里带上到期期限，季度清理时一眼就能筛出来，不必逐个回溯申请记录。
策略改名本身也是配置变更：批量重命名前先导出备份，并确认日志与监控没有依赖旧名称，避免改名后历史记录关联不上。
把命名规范写进变更模板并附示例，比事后检查有效得多；审核环节只核对名称，就能拦住大部分不规范命名。