4. 密码策略版本仓库设计

密码策略版本治理的核心，是把“策略文本”当作可审计、可回滚、可追溯的工程制品来管理。版本仓库不是简单地把策略文件丢进 Git，而是要在仓库结构、分支模型、标签策略、存储选型和访问控制五个维度上做出明确设计，使策略从草稿到生效、从生效到退役的每一步都有据可查。本节围绕这五个维度展开，并给出可直接参考的仓库骨架与配置示例。

一、仓库结构：按“策略域—环境—制品”分层

推荐采用单仓多目录（monorepo）结构，把同一套密码策略的所有版本集中在一个仓库中，避免多仓同步带来的版本漂移。目录按策略域划分，每个域下再按环境与制品类型分层：

crypto-policy-repo/
├── policies/                     # 策略源文件（唯一事实来源）
│   ├── password/                 # 口令策略域
│   │   ├── base.yaml             # 基线参数（长度、复杂度、历史）
│   │   ├── rotation.yaml         # 轮换与过期规则
│   │   └── lockout.yaml          # 锁定与重试策略
│   ├── key/                      # 密钥策略域
│   │   ├── algorithm.yaml        # 算法与密钥长度
│   │   └── lifecycle.yaml        # 生成、轮换、销毁
│   └── tls/                      # 传输策略域
│       └── cipher-suite.yaml
├── environments/                 # 环境差异化覆盖
│   ├── dev/overrides.yaml
│   ├── staging/overrides.yaml
│   └── prod/overrides.yaml
├── schemas/                      # 策略参数校验 schema
│   └── policy.schema.json
├── tests/                        # 策略合规性测试
│   └── test_policy_rules.py
├── CHANGELOG.md                  # 人工可读的变更记录
└── CODEOWNERS                    # 目录级审批责任人

关键原则是：policies/ 目录只存放策略源文件，不存放任何环境相关的密钥、证书或口令。环境差异通过 environments/ 下的覆盖文件表达，合并顺序为“基线 → 环境覆盖”，由发布流水线在渲染阶段完成合并。这样同一份基线在 dev 与 prod 之间只差一个覆盖文件，审计时能快速定位差异来源。

二、分支模型：主干保护 + 短生命周期变更分支

密码策略的变更频率不高，但每次变更影响面大，因此分支模型应偏向保守。推荐使用“主干保护 + 短生命周期变更分支”模型：

• main：唯一受保护主干，对应“已批准、可发布”的策略状态。禁止直接推送，必须通过合并请求（MR）进入。
• feature/policy-<域>-<简述>：如 feature/password-min-length-14，用于单次策略调整，生命周期不超过 5 个工作日。
• hotfix/<事件号>：用于紧急回滚或安全事件响应，允许在审批人少于常规数量时合并，但必须在 24 小时内补全记录。
• release/<日期>：可选，用于冻结一批策略变更，等待窗口期统一发布。

合并请求必须满足三项门禁：策略 schema 校验通过、合规测试用例全部通过、CODEOWNERS 中对应目录的审批人至少一人批准。这三项门禁由 CI 自动执行，人工无法绕过。

三、标签策略：用语义化标签锚定“生效版本”

分支表达“正在改什么”，标签表达“曾经生效过什么”。密码策略仓库的标签建议采用 policy-<域>-v<主>.<次>.<修订> 格式，例如 policy-password-v2.3.1。主版本号在策略语义发生不兼容变化时递增（如口令哈希算法从 PBKDF2 切换为 Argon2id），次版本号在参数调整时递增（如最小长度 12→14），修订号仅用于文档修正或注释补充。

每个标签必须附带一条轻量注解，记录生效环境、生效时间与审批单号。发布流水线只允许从带标签的提交渲染生产环境配置，禁止从分支头直接发布。回滚时，运维只需将生产环境指向旧标签对应的渲染产物，无需重新走一遍策略评审。

四、存储选型：源文件与渲染产物分离

存储选型的关键判断是：策略源文件与渲染产物必须分开存放。源文件放在 Git 仓库中，享受版本历史、差异对比和代码评审能力；渲染产物（合并环境覆盖后的最终配置）放在制品库中，按标签归档，供发布系统按需拉取。这样做的直接好处是：生产环境永远只消费“已打标签的渲染产物”，不会因为某人误推一个分支而改变线上策略。

对于策略中不可避免要引用的敏感值（如 HSM 连接串、KMS 密钥别名），仓库中只保留占位符，例如 ${KMS_KEY_ALIAS}，真实值由发布流水线在渲染阶段从密钥管理系统注入。这样即使仓库被完整克隆，也不会泄露任何可直接利用的凭据。

五、访问控制：最小权限与职责分离

访问控制围绕三个角色设计：策略作者只能向 feature 分支推送，不能合并到 main；审批人由 CODEOWNERS 指定，按策略域划分，例如 password 域由身份安全团队审批，key 域由密码学团队审批；发布机器人是唯一有权在 main 上打标签并触发渲染的实体，其凭据由 CI 系统托管，不分配给任何个人。

以下是一份可直接参考的 CODEOWNERS 示例：

# 策略域审批责任人
/policies/password/   @identity-security-team
/policies/key/        @crypto-team
/policies/tls/        @network-security-team
/environments/prod/   @security-arch-board
/schemas/             @policy-platform-team

配合分支保护规则，main 分支应开启“要求合并请求”“要求 CODEOWNERS 审批”“要求状态检查通过”“禁止强制推送”四项设置。对于 hotfix 分支，可临时将审批人数降为 1 人，但必须在合并后 24 小时内由安全架构委员会补签确认，补签记录写入 CHANGELOG.md。

综合来看，仓库结构解决“东西放在哪”，分支模型解决“怎么改”，标签策略解决“哪个版本生效”，存储选型解决“源与产物如何隔离”，访问控制解决“谁有权做什么”。五者共同构成密码策略版本仓库的完整设计，使策略版本的集中管理从口号落到可执行的工程实践上。