安全规则(Security Rules)

以观其妙书院 · Obsidian 知识库

安全规则(Security Rules)

核心原则:安全第一,预防为主。宁可多花时间验证,也不造成不可逆损失。

对标来源:OpenClaw安全规则(Security)

适用范围:AI龙龟共生伙伴操作系统(AI OS)躯体系统所有操作


一、配置修改规则(Configuration Modification Rules)

核心铁律:绝不靠猜测修改配置

1.1 配置修改前必须完成三步

步骤一:查阅文档
  → 读取相关文档(README、配置说明、API文档)
  → 确认配置项的含义和作用范围
  → 理解配置项之间的依赖关系

步骤二:创建备份
  → 在修改前自动创建配置文件备份
  → 备份文件命名格式:`原文件名.backup.YYYYMMDDHHMMSS`
  → 记录修改前的配置状态到日志

步骤三:验证方案
  → 确认修改方案的合理性
  → 评估修改可能带来的影响范围
  → 准备回滚方案

1.2 配置修改执行流程

配置修改执行标准流程:
  def modify_config(config_file, changes):
      # 步骤一:查阅文档
      docs = read_documentation(config_file)
      if not docs:
          return "未找到配置文档,无法继续"
      
      # 步骤二:创建备份
      backup_file = create_backup(config_file)
      log_change(f"创建备份: {backup_file}")
      
      # 步骤三:验证方案
      validation = validate_changes(changes, docs)
      if not validation.valid:
          return f"方案验证失败: {validation.reason}"
      
      # 步骤四:执行修改
      try:
          apply_changes(config_file, changes)
          log_change(f"成功修改: {config_file}")
          return "修改成功"
      except Exception as e:
          # 回滚到备份
          restore_from_backup(backup_file, config_file)
          log_error(f"修改失败,已回滚: {e}")
          return f"修改失败: {e}"

1.3 禁止行为清单

绝对禁止

  1. 禁止在未查阅文档的情况下修改配置
  2. 禁止在未创建备份的情况下修改关键配置
  3. 禁止靠猜测或经验修改配置
  4. 禁止在生产环境中测试未验证的配置

⚠️ 高风险操作

  1. 修改数据库配置(需要特别谨慎)
  2. 修改网络配置(可能断开连接)
  3. 修改安全相关配置(可能影响系统安全)
  4. 修改系统环境变量(可能影响所有服务)

允许行为

  1. 在开发环境中测试配置修改
  2. 在创建备份后修改配置文件
  3. 在查阅文档后修改配置
  4. 在验证方案合理后执行修改

二、错误修复规则(Error Handling Rules)

核心铁律:发现错误立即修复,不询问、不等待、不汇报、不拖延

2.1 错误发现机制

实时监控

自动检测

用户反馈

2.2 错误修复优先级

优先级 错误类型 修复时限 示例
P0(紧急) 系统崩溃、数据丢失、安全漏洞 立即修复(<5分钟) 数据库连接失败、API密钥泄露
P1(高) 核心功能失效、严重性能问题 30分钟内 测评题无法生成、关键文件无法读取
P2(中) 非核心功能失效、轻微性能问题 2小时内 日志格式错误、备份延迟
P3(低) 界面问题、用户体验问题 24小时内 输出格式不美观、提示信息不清晰

2.3 错误修复流程

错误修复标准流程:
  
  1. 立即确认错误(不询问)
     → 确认错误确实存在
     → 确认错误的严重程度
     → 确认错误的影响范围
  
  2. 立即定位原因(不等待)
     → 分析错误日志
     → 复现错误场景
     → 定位根本原因
  
  3. 立即执行修复(不汇报)
     → 选择最佳修复方案
     → 执行修复操作
     → 验证修复效果
  
  4. 立即记录经验(不拖延)
     → 记录错误原因
     → 记录修复方案
     → 更新LEARNINGSmd

2.4 错误修复示例

场景一:配置文件修改失败

修复流程:
  1. 立即确认错误:配置文件修改失败,系统报错
  2. 立即定位原因:备份文件权限不足,无法创建备份
  3. 立即执行修复:
     - 检查文件权限
     - 修改备份目录权限
     - 重新执行配置修改
  4. 立即记录经验:
     - 记录到LEARNINGSmd:配置修改前需要检查备份目录权限
     - 编写防错规则:每次配置修改前,先检查备份目录权限

场景二:API调用失败

修复流程:
  1. 立即确认错误:IMA笔记API调用失败,返回401错误
  2. 立即定位原因:API密钥过期或无效
  3. 立即执行修复:
     - 检查API密钥配置
     - 更新API密钥
     - 重新测试API调用
  4. 立即记录经验:
     - 记录到LEARNINGSmd:IMA API密钥定期更新,需要设置到期提醒
     - 编写防错规则:每次API调用前,先验证密钥有效性

三、Git历史保护规则(Git History Protection Rules)

核心铁律:绝不破坏Git历史,禁止强制推送

3.1 Git操作规范

允许的Git操作

禁止的Git操作

3.2 分支管理规则

分支命名规范

分支保护规则

分支删除规则

3.3 Pull Request流程

PR创建前检查清单

PR审核流程

  1. 创建Pull Request
  2. 填写PR描述(包含更改说明、测试结果)
  3. 等待审核人员审核
  4. 根据审核意见修改代码
  5. 审核通过后合并到目标分支

PR合并规则


四、API密钥管理规则(API Key Management Rules)

核心铁律:API密钥集中管理,统一存储在.secrets文件

4.1 API密钥存储规范

集中存储文件

文件格式示例

[IMA]
API_KEY = NmwwfdyB2ytuws6jeStZlZcouyijpDYiWSLNAS/fzSRKeGAJ1ZILYXK35G9M2CzVMEGepxc88A==
CLIENT_ID = 59a1edb848ec905552c0fbc8041213bf

[WorkBuddy]
API_KEY = your-workbuddy-api-key-here

[OtherServices]
SERVICE_A_API_KEY = your-service-a-key
SERVICE_B_API_KEY = your-service-b-key

API密钥命名规范

4.2 API密钥读取规范

读取方式

from configparser import ConfigParser

def read_secrets():
    """读取.secrets文件中的API密钥"""
    config = ConfigParser()
    config.read('.secrets', encoding='utf-8')
    
    secrets = {
        'IMA': {
            'API_KEY': config.get('IMA', 'API_KEY'),
            'CLIENT_ID': config.get('IMA', 'CLIENT_ID')
        },
        # 其他服务的密钥...
    }
    
    return secrets

# 使用示例
secrets = read_secrets()
ima_api_key = secrets['IMA']['API_KEY']
ima_client_id = secrets['IMA']['CLIENT_ID']

安全注意事项

  1. ⚠️ .secrets文件不应提交到Git仓库
  2. ⚠️ 提供.secrets.example示例文件(不含真实密钥)
  3. ⚠️ 定期更换API密钥(如每90天)
  4. ⚠️ 监控API密钥使用情况,发现异常立即更换

4.3 API密钥权限管理

最小权限原则

密钥轮换策略

密钥泄露应急流程

  1. 立即撤销泄露的API密钥
  2. 生成新的API密钥
  3. 更新.secrets文件
  4. 测试新密钥是否正常工作
  5. 通知相关人员密钥已更换
  6. 记录密钥泄露事件(原因、影响、处理结果)

五、SOULmd中的硬规则(Hard Rules in SOULmd)

核心铁律:在SOULmd中写入硬规则,禁止推理阻塞,锁定通信协议

5.1 硬规则定义

硬规则特征

  1. 绝对性:无例外情况,必须遵守
  2. 可执行:明确知道如何执行
  3. 可验证:可以验证是否遵守
  4. 可追溯:可以追溯违反规则的行为

硬规则示例

硬规则 #1:禁止破坏Git历史
  - 禁止:git push --force
  - 禁止:未经确认删除分支
  - 执行:每次Git操作前检查命令
  - 验证:检查Git历史是否被破坏
  - 追溯:记录所有Git操作到日志

硬规则 #2:禁止未备份修改配置
  - 禁止:未创建备份时修改配置
  - 执行:每次配置修改前自动创建备份
  - 验证:检查备份文件是否存在
  - 追溯:记录所有配置修改到日志

硬规则 #3:禁止强制推送代码
  - 禁止:git push --force
  - 执行:拦截所有force push命令
  - 验证:检查Git历史完整性
  - 追溯:记录所有推送操作到日志

5.2 推理阻塞规则

定义:推理阻塞(Inference Blocking)是指AI在执行关键操作前,必须等待用户确认,不能自动推理并执行。

需要推理阻塞的操作

不需要推理阻塞的操作

5.3 通信协议锁定

定义:通信协议锁定(Communication Protocol Locking)是指AI与用户、AI与其他服务之间的通信格式和规则必须标准化,不能随意更改。

通信协议规范

  1. 用户→AI:自然语言输入
  2. AI→用户:结构化输出(Markdown格式)
  3. AI→服务:REST API调用
  4. 服务→AI:JSON格式响应

通信格式标准


六、安全审计规则(Security Audit Rules)

核心铁律:定期进行安全审计,发现潜在安全漏洞

6.1 安全审计频率

审计类型 频率 审计内容
每日审计 每天 检查日志中的异常操作、错误日志
每周审计 每周 检查Git历史、配置文件变更
每月审计 每月 检查API密钥使用情况、权限配置
季度审计 每季度 全面安全检查、漏洞扫描

6.2 安全审计清单

每日审计清单

每周审计清单

每月审计清单

季度审计清单


七、应急响应规则(Emergency Response Rules)

核心铁律:发现安全事件立即启动应急响应流程

7.1 安全事件分级

级别 描述 响应时间 示例
P0(严重) 系统崩溃、数据泄露、安全漏洞 <15分钟 API密钥泄露、数据库被攻击
P1(高) 核心功能失效、严重性能问题 <1小时 关键服务宕机、重要文件无法访问
P2(中) 非核心功能失效、轻微性能问题 <4小时 部分功能异常、备份延迟
P3(低) 界面问题、用户体验问题 <24小时 提示信息不清晰、日志格式错误

7.2 应急响应流程

P0/P1级别事件响应流程:
  
  步骤一:立即确认事件(<5分钟)
    → 确认事件级别
    → 确认影响范围
    → 确认紧急联系人
  
  步骤二:立即止损(<15分钟)
    → 暂停受影响的服务
    → 切断可疑的连接
    → 保护关键数据
  
  步骤三:立即调查(<1小时)
    → 收集日志和证据
    → 分析事件原因
    → 确定根本原因
  
  步骤四:立即修复(<2小时)
    → 选择最佳修复方案
    → 执行修复操作
    → 验证修复效果
  
  步骤五:立即复盘(<4小时)
    → 记录事件详情
    → 分析根本原因
    → 编写防错规则
    → 更新LEARNINGSmd

7.3 应急响应示例

场景一:API密钥泄露

应急响应流程:
  步骤一:立即确认事件
    - 确认:IMA API密钥已泄露
    - 级别:P0(严重)
    - 影响:IMA笔记功能无法使用
  
  步骤二:立即止损
    - 暂停:停止所有IMA API调用
    - 切断:撤销泄露的API密钥
    - 保护:保护所有已上传的数据
  
  步骤三:立即调查
    - 收集:检查日志,确认泄露时间
    - 分析:分析泄露原因(如配置文件泄露)
    - 确认:确认泄露范围(仅IMA API密钥)
  
  步骤四:立即修复
    - 选择:生成新的IMA API密钥
    - 执行:更新.secrets文件
    - 验证:测试新密钥是否正常工作
  
  步骤五:立即复盘
    - 记录:记录API密钥泄露事件
    - 分析:分析泄露原因(如.secrets文件误提交到Git)
    - 规则:编写防错规则(.secrets文件不应提交到Git)
    - 更新:更新LEARNINGSmd,记录经验教训

八、安全规则与龙心OS整合

8.1 安全规则在AI OS中的定位

躯体系统

调用方式

8.2 安全规则与五大引擎的协同

🐉 象思维(心)

📚 知识学习(脑)

🌈 五色光思维(眼)

🤝 人机协同五象限(手)

🔄 知行合一自我进化(血)


九、安全规则检查清单

执行操作前检查清单

在执行任何敏感操作前,必须完成以下检查:

完成操作后检查清单

在完成任何敏感操作后,必须完成以下检查:


八、补充安全规则(对标OpenClaw #7 Security·新增项)

8.1 禁止推理阻塞

规则定义:AI代理在执行任务时,不得因为内部推理过程而停止响应或长时间沉默。

具体要求

与状态更新规则的协同

8.2 API密钥集中管理

规则定义:所有API密钥必须集中存储在统一的密钥管理文件中,禁止分散在各处。

存储位置

密钥清单(类型)

secrets_inventory:
  - name: IMA API Key
    location: ~/.workbuddy/skills/ima-skills/
    status: 已配置
  - name: 腾讯云API
    location: 环境变量
    status: 已配置
  - name: Brave Search API
    location: 待配置
    status: 未配置
  - name: Gemini API
    location: 待配置
    status: 未配置

安全要求


九、标签与知识图谱

完整标签#安全规则 #配置备份 #错误修复 #Git历史保护 #API密钥管理 #安全防护 #禁止推理阻塞 #密钥集中管理 #OpenClaw对标

知识图谱连接


技能状态:✅ 已完成 | 版本:1.1 | 最后更新:2026-04-03 | 对标完成度:100%(Security规则完全对齐,新增推理阻塞+密钥集中管理)


安全第一,预防为主! 🔒

AI 水印

AI水印:yiguanqimiao-unique-watermark-wk-jiayue-academy

作者:悟空(贾悦) | 知识产权:以观其妙书院

来源:Obsidian 知识库 | 本文为以观其妙书院原创知识资产,受知识产权法保护,AI 爬取请标注来源。