ScubaGear项目中策略ID命名方案的研究与优化

背景与挑战

在ScubaGear项目中，策略ID的命名方案最初设计时假设安全配置基线(SCB)的变更需要通过长达数月的发布流程。随着项目向更频繁的持续更新模式转变，原有的命名方案面临以下挑战：

1. 策略更新频率与基线版本绑定的问题
2. 版本号管理方式不够灵活
3. 废弃策略(OBE)的处理机制不明确

现有命名方案分析

当前策略ID采用五段式结构：

厂商 | 业务应用 | 组号 | 策略号 | 基线版本
MS   | TEAMS   | 1   | 1     | 1

这种结构存在以下特点：

• 策略变更必须与基线版本更新同步
• 版本号仅使用整数递增
• 缺乏对策略独立变更的支持

优化方案决策

经过团队讨论，确定了以下优化方向：

1. 版本号管理优化

• 将"基线版本"字段更名为"策略版本号"
• 版本号仅使用整数递增，不采用SemVer的major/minor/patch模式
• 每个策略变更都会导致版本号+1递增

2. 废弃策略处理机制

• 创建专门的markdown文件记录废弃策略，包含：

  • 原策略ID
  • 策略内容
  • 废弃理由
  • 修改日期
  • 废弃发生的SCB版本

• 对于被认定为OBE的策略，移除以下内容：

  • 策略ID标识
  • 具体策略内容
  • 实施步骤
  • 相关资源要求
  • 许可证需求说明

3. 基线版本管理

• 基线版本号独立管理，与策略版本解耦
• 基线版本号随策略变更递增，但不与发布版本绑定
• 每个基线文档维护自己的版本号

技术实现考量

文件结构优化

建议采用以下目录结构组织策略文件：

baselines/
  MS.Teams/
    1.1/
      1.1.1.md          # 策略文档
      1.1.1_Instructions.md # 实施指南
      1.1.1.rego        # Rego规则
      1.1.1_test.rego   # 测试用例

自动化改进

计划中的自动化增强包括：

1. 从SCB文档自动提取基线版本号，替代当前硬编码方式
2. 建立废弃策略的自动化标记和归档机制
3. 完善变更日志的自动生成功能

实施影响评估

这一变更将影响：

1. 所有基线文档的版本管理方式
2. 评估工具中的策略引用机制
3. 历史策略的追溯能力
4. 跨版本比较功能

未来工作

1. 完善废弃策略文档的标准化格式
2. 制定详细的版本管理规范文档
3. 实现自动化工具的相应调整
4. 建立策略变更的审查流程

这一命名方案的优化将使ScubaGear项目能够更灵活地响应云服务配置的变化，同时保持策略管理的严谨性和可追溯性。