fukunee/Hugo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update: add Prolog translation, 4A system design, Mermaid, Hextra partials & blog articles

Browse Source
This commit is contained in:
claw
2026-05-18 14:09:14 +08:00
parent 826a74ed4e
commit 829313765e
101 changed files with 8087 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files
4a-system-design/ai-cicd.md
+388
View File
@@ -0,0 +1,388 @@
# AI全流程兜底闭环
## 1. 核心理念
两个月自研一套对标泰岳的4A系统，**不可能靠纯人工完成**。AI不是锦上添花，而是项目成功的前提条件。
核心策略：**AI最大化替代重复性工作，人工聚焦架构设计、安全审查和关键决策。**
---
## 2. AI在各个阶段的介入点
### 2.1 开发阶段
```
┌─────────────────────────────────────────────────────────────────────┐
│ 开发阶段 AI 介入 │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ AI代码生成 │ │ AI代码审查 │ │
│ │ │ │ │ │
│ │ • API层CRUD代码 │ │ • 安全漏洞扫描 │ │
│ │ • 数据模型→SQL │ │ (SQL注入/XSS/越权) │ │
│ │ • Service层业务逻辑 │ │ • 接口规范一致性检查 │ │
│ │ • 前端列表/表单页面 │ │ • 日志埋点完整性检查 │ │
│ │ • 单元测试代码 │ │ • 异常处理覆盖率检查 │ │
│ │ • 接口文档生成 │ │ • 代码风格统一 │ │
│ └────────────────────┘ └────────────────────┘ │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ AI数据模型辅助 │ │ AI对接适配器生成 │ │
│ │ │ │ │ │
│ │ • 从泰岳界面反推 │ │ • 金科人脸API适配器 │ │
│ │ 数据模型 │ │ • 消息中心API适配器 │ │
│ │ • 字段映射脚本生成 │ │ • 现网账号同步适配器 │ │
│ │ • 数据迁移/同步 │ │ • 亚信接口规范适配器 │ │
│ │ 代码生成 │ │ • 泰岳接口模拟器 │ │
│ └────────────────────┘ └────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
```
**AI代码生成策略**：
1. **模型选型**：使用 DeepSeek/Claude 等具有编程能力的模型
2. **Prompt模板化**：为每种代码类型（API CRUD、数据模型、单元测试、接口适配层）建立标准 Prompt
3. **微调/知识注入**：将本项目的表结构定义、接口规范作为 System Prompt 上下文
4. **人机协作**：AI生成初稿 → 人工审查 → AI根据Review意见修正 → 循环至满意
5. **生成量目标**：争取 60-70% 的业务代码由AI完成初稿
### 2.2 测试阶段
```
┌──────────────────────────────────────────────────────────────────────┐
│ 测试阶段 AI 介入 │
│ │
│ 1. 测试用例自动生成 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 输入: API接口定义/数据模型/业务规则描述 → AI生成: │ │
│ │ - 正常流程测试用例集 │ │
│ │ - 异常路径测试用例集（参数错误/越权/并发/超时） │ │
│ │ - 边界条件测试用例集（空值/超长/特殊字符/数据溢出） │ │
│ │ - 安全性测试用例（SQL注入/XSS/CSRF/越权枚举） │ │
│ │ - 压力测试基准脚本 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ 2. 与泰岳版行为比对测试 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ AI Agent 框架： │ │
│ │ │ │
│ │ ① AI录制泰岳版操作 → 生成操作序列 │ │
│ │ ② AI将操作序列转为自动化测试脚本 │ │
│ │ ③ AI同时在泰岳版和自研版执行测试脚本 │ │
│ │ ④ AI比对两系统的： │ │
│ │ - 接口请求/响应差异 │ │
│ │ - 界面元素/流程差异 │ │
│ │ - 数据持久化结果差异 │ │
│ │ ⑤ AI输出差异报告，标注关键程度 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ 3. 回归测试自愈 │
│ - 当代码变更导致测试失败时，AI自动分析失败原因 │
│ - 测试预期结果过时？AI自动更新测试用例 │
│ - 产品逻辑改变？AI识别并标记为"预期变化" │
│ - 测试环境问题？AI标记为"环境异常"而非"功能失败" │
└──────────────────────────────────────────────────────────────────────┘
```
### 2.3 部署阶段
```
┌──────────────────────────────────────────────────────────────────────┐
│ 部署阶段 AI 介入 │
│ │
│ 1. 基础设施编排 │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ AI生成 Ansible Playbook / Terraform 配置: │ │
│ │ - 服务器初始化（OS调优、安全基线配置） │ │
│ │ - 中间件部署（Nginx/Redis/MySQL/ES/MinIO） │ │
│ │ - 应用部署（认证中心/资源中心/审计中心各模块） │ │
│ │ - 网络策略配置（防火墙规则、反向代理、TLS证书） │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ 2. 配置差异自适应 │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 当部署失败时，AI分析错误日志： │ │
│ │ - 配置参数与环境不匹配？AI推荐正确值 │ │
│ │ - 依赖组件版本冲突？AI推荐兼容版本组合 │ │
│ │ - 权限问题？AI生成正确的权限设置命令 │ │
│ │ - 网络不可达？AI诊断网络路径 + 推荐修复方案 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ 3. CI/CD Pipeline │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 流水线步骤（AI辅助维护）： │ │
│ │ │ │
│ │ [代码提交] → [AI代码审查] → [AI生成测试] → [自动编译] │ │
│ │ → [单元测试] → [集成测试] → [AI比对测试] → [安全扫描] │ │
│ │ → [构建镜像] → [部署到测试环境] → [冒烟测试] → [通知] │ │
│ └───────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
```
### 2.4 运维阶段
```
┌──────────────────────────────────────────────────────────────────────┐
│ 运维阶段 AI 介入 │
│ │
│ 1. 智能告警与根因分析 │
│ ┌───────────────────────────────────────────────────────────┐ │
│ 场景1：用户反馈"登录不上了" │ │
│ AI排查链路：API超时？→ Redis连接失败？→ Redis进程挂了？ │ │
│ → OOM被Killed？→ 内存泄漏？ │ │
│ 根因定位后AI自动在5分钟内输出根因报告 + 修复方案 │ │
│ │
│ 场景2：SSO跳转后白屏 │ │
│ AI排查链路：前端报错→ API返回500 → 后端日志ClassNotFound │ │
│ → 发版时删了jar包 → 回滚建议 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ 2. 数据一致性巡检 │
│ ┌───────────────────────────────────────────────────────────┐ │
│ AI Agent定时任务（每天凌晨执行）： │ │
│ ✓ 自研系统账号数与现网账号平台对比 → 偏差 > 0.1% 告警 │ │
│ ✓ 昨日新增的日志量与API调用量匹配度 → 缺漏事件告警 │ │
│ ✓ 授权数据完整性和无循环引用 → 数据损坏告警 │ │
│ ✓ 密钥轮换成功率检测 → 失败操作通知管理员 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ 3. 性能基线追踪 │
│ ┌───────────────────────────────────────────────────────────┐ │
│ 持续采集： │ │
│ - API响应时间 P50/P95/P99（按接口维度） │ │
│ - 认证成功率/耗时趋势 │ │
│ - ES查询响应时间趋势 │ │
│ - 堡垒机并发数/响应延迟趋势 │ │
│ │
│ 当性能偏离基线 > 20%时，AI自动生成性能分析报告 │ │
│ 与上一发版/配置变更/流量突增做关联分析 │ │
│ └───────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
```
---
## 3. 与泰岳版的比对验证方案
### 3.1 验证框架
```
┌────────────────────────────────────────────────────────────────────────┐
│ 比对验证框架 │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ 功能覆盖度验证 │ │ 行为一致性验证 │ │
│ ├────────────────────┤ ├────────────────────┤ │
│ │ 工具: AI扫描 + │ │ 工具: AI Agent │ │
│ │ 功能矩阵表 │ │ 录制→回放→比对 │ │
│ │ 方法: │ │ 方法: │ │
│ │ ① 列出泰岳版所有 │ │ ① 录制泰岳版操作 │ │
│ │ 功能点 │ │ ② 生成测试脚本 │ │
│ │ ② 逐项标记自研版 │ │ ③ 在两系统执行 │ │
│ │ 覆盖状态 │ │ ④ AI比对行为差异 │ │
│ │ ③ AI辅助识别遗漏 │ │ ⑤ 输出差异报告 │ │
│ └────────────────────┘ └────────────────────┘ │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ 性能基准验证 │ │ 安全基准验证 │ │
│ ├────────────────────┤ ├────────────────────┤ │
│ │ 工具: JMeter/k6 │ │ 工具: 安全扫描器+AI │ │
│ │ 方法: │ │ 方法: │ │
│ │ ① 相同硬件上运行 │ │ ① OWASP Top10扫描 │ │
│ │ ② 定义核心场景 │ │ ② 认证机制审查 │ │
│ │ (登录/SSO/授权/ │ │ ③ 敏感数据加密审计 │ │
│ │ 日志查询) │ │ ④ 越权测试 │ │
│ │ ③ 逐步增加并发 │ │ ⑤ AI对比差异 + │ │
│ │ ④ AI输出对比曲线 │ │ 给出安全建议 │ │
│ └────────────────────┘ └────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘
```
### 3.2 功能覆盖度矩阵（示例片段）
| 功能模块 | 功能点 | 泰岳版 | 自研版 | 完成度 | 备注 |
|---------|--------|--------|--------|--------|------|
| 认证 | 密码认证 | ✓ | ✓ | 100% | |
| 认证 | 短信验证码 | ✓ | ✓ | 100% | |
| 认证 | 人脸识别认证 | ✓ | ✓ | 100% | 金科接口 |
| 认证 | SIM卡无感认证 | — | ✓ | 100% | 自研特有 |
| 认证 | LDAP集成 | ✓ | ☐ | 0% | 二期 |
| 认证 | MFA策略配置 | ✓ | ✓ | 100% | |
| 账号 | 账号新建 | ✓ | ✓ | 100% | |
| 账号 | 账号批量导入 | ✓ | ✓ | 100% | |
| 账号 | 账号同步(多源) | ✓ | ✓ | 100% | |
| 账号 | 密码策略配置 | ✓ | ✓ | 100% | |
| 应用SSO | OIDC协议 | ✓ | ✓ | 100% | |
| 应用SSO | SAML协议 | ✓ | ✓ | 80% | 部分场景验证中 |
| 应用权限 | RBAC模型 | ✓ | ✓ | 100% | |
| 应用权限 | ABAC策略 | — | ✓ | 100% | 自研特有 |
| 应用权限 | 临时授权 | ✓ | ✓ | 100% | |
| 系统资源 | 资产纳管 | ✓ | ✓ | 100% | |
| 系统资源 | 批量导入资产 | ✓ | ✓ | 100% | |
| 系统资源 | 命令白名单 | ✓ | ✓ | 100% | |
| 系统资源 | 命令拦截 | ✓ | ✓ | 100% | |
| 系统资源 | 密码轮换 | ✓ | ✓ | 50% | 实现中 |
| 堡垒机 | SSH单点登录 | ✓ | ✓ | 100% | |
| 堡垒机 | RDP单点登录 | ✓ | ☐ | 0% | 二期 |
| 堡垒机 | 会话录制 | ✓ | ✓ | 100% | |
| 堡垒机 | 会话回放 | ✓ | ✓ | 80% | 播放器优化中 |
| 审计 | 操作日志 | ✓ | ✓ | 100% | |
| 审计 | 合规规则引擎 | — | ✓ | 100% | 自研特有 |
| 审计 | 定时报表 | ✓ | ✓ | 100% | |
| 审计 | 自定义报表 | ✓ | ✓ | 80% | 查询条件还在完善 |
### 3.3 比对验证AI Agent（核心设计）
```yaml
验证Agent设计:
输入:
- 泰岳版API/界面操作录制
- 自研版API/界面操作
- 期望行为描述
处理流程:
1. 理解场景: 从录制内容中提取操作步骤和预期结果
2. 脚本生成: 将操作步骤转换为可执行的测试脚本
3. 双系统执行: 并行在泰岳版和自研版中执行
4. 结果采集: 捕获接口请求/响应、页面状态、数据变更
5. 差异分析:
- 返回JSON字段差异
- 流程状态机步骤差异
- 数据持久化差异
- 错误处理差异
6. 差异分级:
Critical: 功能缺失/数据丢失
Major: 行为不符合预期
Minor: 界面/错误提示文本差异
Info: 实现方式不同但结果一致
7. 报告生成: 输出结构化差异报告
输出:
- 功能覆盖度百分比
- 行为一致度评分
- 差异清单（含分级和截图/调用链）
- 建议排期（哪些差异需要立即修复）
```
---
## 4. 用户发现问题 → 闭环解决的AI全链路支持
### 4.1 问题闭环流程
```
┌──────────────────────────────────────────────────────────────────────┐
│ 用户反馈 → AI初步诊断 → 自动修复/路由 → 人工确认 → 知识沉淀 │
│ │
│ 阶段1: 用户反馈 │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 用户: "我通过4A跳转到报销系统，显示'无权限'，但我昨天还能用" │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段2: AI初步诊断 │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ AI Agent 自动排查： │ │
│ │ ① 查询该用户的权限分配记录（最近变更） │ │
│ │ ② 查询报销系统的应用注册配置是否变更 │ │
│ │ ③ 查询用户所属组织的角色继承链路 │ │
│ │ ④ 检查授权有效期是否已过期 │ │
│ │ ⑤ 模拟该用户的权限验证请求 │ │
│ │ │ │
│ │ 初步结论：用户角色有效期已过期（昨日到期） │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段3: 自动修复 / 路由 │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 自动处理： │ │
│ │ ① 生成角色续期申请单（自动填充用户信息+原有角色） │ │
│ │ ② 推送给用户的直接上级审批 │ │
│ │ ③ 回复用户："经排查，您对报销系统的访问权限已于昨日到期。 │ │
│ │ 已为您生成续期申请，请等待审批人确认，预计5分钟内恢复。" │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段4: 人工确认 │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 审批人确认 → 权限生效 │ │
│ │ AI自动通知用户："权限已恢复，请重新登录报销系统" │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 阶段5: 知识沉淀 │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ AI将本次问题 + 排查链路 + 修复方案 存入"问题知识库" │ │
│ │ 同类问题下次出现时，AI可更快定位 + 自动修复 │ │
│ │ 定期输出"常见问题处理SOP" 给运维团队 │ │
│ └──────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
```
### 4.2 问题知识库设计
```sql
CREATE TABLE T_ISSUE_KNOWLEDGE (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
issue_type VARCHAR(64) NOT NULL COMMENT '问题类型',
symptom TEXT NOT NULL COMMENT '用户描述的症状',
diagnosis_steps JSON NOT NULL COMMENT '排查步骤(结构化)',
root_cause TEXT COMMENT '根因分析',
solution TEXT COMMENT '解决方案',
auto_fixable TINYINT NOT NULL DEFAULT 0 COMMENT '是否可自动修复',
auto_fix_script TEXT COMMENT '自动修复脚本/指令',
severity VARCHAR(16) COMMENT 'high/medium/low',
occurrence_count INT NOT NULL DEFAULT 1,
last_occurrence DATETIME,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
INDEX idx_issue_type (issue_type),
INDEX idx_symptom (symptom(100))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='问题知识库';
```
### 4.3 AI闭环成熟度模型
| 阶段 | 能力 | 目标月份 |
|------|------|---------|
| L1: 人工全流程 | 用户反馈 → 人工排查 → 人工修复 | 第1个月 |
| L2: AI辅助诊断 | AI根据知识库推荐排查路径 + 建议修复方案 | 第1-2个月 |
| L3: AI半自动修复 | AI可处理 >50% 的常见问题（权限过期、配置错误等） | 第2个月+ |
| L4: AI全自动闭环 | AI自动发现、自动诊断、自动修复、自动通知 | 后续迭代 |
---
## 5. 技术实现要点
### 5.1 AI工具链选型
| 用途 | 工具/平台 | 备注 |
|------|----------|------|
| 代码生成 | Claude / DeepSeek Coder | 用于核心逻辑编写 |
| 代码审查 | DeepSeek + 自定义规则 | 自动化Review |
| 测试生成 | AI Agent（自定义实现） | 基于接口定义生成 |
| 比对验证 | AI Agent | 录制→回放→比对 |
| 部署编排 | Ansible + AI生成Playbook | 配置即代码 |
| 运维Agent | 自建Agent框架 | 使用LLM API |
| 知识库 | 向量数据库（Milvus/Chroma） | 问题案例语义搜索 |
### 5.2 Prompt策略
| 场景 | Prompt策略 |
|------|-----------|
| 代码生成 | 给出完整的表结构、接口规范、业务规则描述，要求严格遵循 |
| 测试生成 | 给出API定义，要求覆盖正常/异常/边界/安全场景 |
| 问题诊断 | 给出系统日志、用户描述、相关配置，要求结构化输出排查链路 |
| 比对验证 | 给出双系统的操作结果，要求逐字段比对并分级差异 |
### 5.3 重要提醒
> **AI不是银弹**。关键约束：
> 1. AI生成的代码必须经过人工安全审查——尤其涉及认证和授权的逻辑
> 2. AI不擅长系统架构决策——架构师责任不可外包
> 3. AI生成的测试用例依赖人类确认预期结果是否正确
> 4. 数据一致性场景AI不能100%信任——关键路径需人工复核
> 5. 泰岳版接口反推中，AI只能辅助分析，最终结论需人工验证
4a-system-design/audit-center.md
+477
View File
@@ -0,0 +1,477 @@
# 审计中心设计
## 1. 总体定位
审计中心是4A系统的**可观测性和合规性基座**，负责收集、存储、分析全平台的操作行为数据。核心职责：
- 从认证身份中心、应用资源管理中心、系统资源管理中心采集全量操作事件
- 基于现有审计报表逆推审计数据模型
- 提供合规规则引擎，实时/准实时检测异常行为
- 生成分级审计报表，支撑部门级和公司级审计需求
- 利用招标空窗期（几个月）充分梳理数据模型
---
## 2. 设计原则
### 2.1 从报表反推模型——逆推方法论
泰岳版现网已有成熟审计报表。我们的策略：**不猜测泰岳的存储结构，而是从"报表要什么"反推"数据该存什么"**。
```
┌──────────────────────────────────────────────┐
│ 逆推路径：报表需求 → 数据模型 │
│ │
│ Step 1: 收集所有现网审计报表 │
│ - 固定报表（日/周/月报） │
│ - 自定义报表（管理员手动查询） │
│ - 触发式报表（异常告警详情） │
│ │
│ Step 2: 提取报表中的字段 │
│ - 每个报表的列、筛选条件、汇总维度 │
│ - 示例：登录报表需要{用户、时间、IP、结果、 │
│ 认证方式、地理位置、设备指纹} │
│ │
│ Step 3: 构建事件模型 │
│ - 将字段归类到事件模型中 │
│ - 识别共性字段（audit_id, timestamp, user, │
│ action, resource, result, client_info） │
│ │
│ Step 4: 设计存储结构 │
│ - 根据查询模式选择存储引擎 │
│ - 高频查询字段建索引 │
│ - 根据报表筛选条件确定分区策略 │
└──────────────────────────────────────────────┘
```
### 2.2 逆推示例
**现网报表-A：账号登录统计日报**
```
字段: 日期 | 登录名 | 姓名 | 部门 | 登录次数 | 成功次数 | 失败次数 |
最后登录时间 | 最后登录IP | 最后认证方式
```
**逆推结论 → 登录事件字段集**：
- 基础：`event_id, event_type, timestamp`
- 主体：`account_id, login_name, display_name, org_path`
- 行为：`action=login, auth_method, result, fail_reason`
- 环境：`source_ip, user_agent, device_id, geo_location`
- 关联：`session_id, mfa_level`
**现网报表-B：权限变更审计报表**
```
字段: 变更时间 | 操作人 | 被授权人 | 应用/资产 |
授权角色 | 操作类型(授予/回收) | 审批人 | 生效时间
```
**逆推结论 → 授权事件字段集**：
- `event_id, event_type=auth_change, timestamp`
- `operator_id, target_user_id`
- `resource_type(app/asset), resource_id`
- `old_role, new_role, change_type(grant/revoke/expire)`
- `approver_id, approval_comment`
- `effective_period`
---
## 3. 三中心数据来源定义
### 3.1 事件分类与来源
| 事件类型 | 来源中心 | 采集方式 | 实时性 |
|---------|---------|---------|--------|
| 登录事件 | 认证身份中心 | API回调 / MQ | 实时 |
| 登出事件 | 认证身份中心 | API回调 | 实时 |
| 令牌刷新 | 认证身份中心 | 中间件Hook | 实时 |
| 认证失败 | 认证身份中心 | 业务日志 | 实时 |
| 密码修改 | 认证身份中心 | 业务日志 | 近实时 |
| 账号创建/修改/删除 | 认证身份中心 | CQRS事件 | 近实时 |
| SSO跳转 | 应用资源管理中心 | 网关日志 | 实时 |
| 权限分配/回收 | 应用资源管理中心 | 业务日志 | 实时 |
| 权限校验结果 | 应用资源管理中心 | 授权引擎日志 | 准实时 |
| 应用注册/配置变动 | 应用资源管理中心 | 业务日志 | 近实时 |
| 资产访问（SSH/RDP） | 系统资源管理中心 | 堡垒节点代理 | 实时 |
| 命令执行记录 | 系统资源管理中心 | 堡垒节点代理 | 实时 |
| 文件传输记录 | 系统资源管理中心 | 堡垒节点代理 | 实时 |
| 密码轮换操作 | 系统资源管理中心 | 业务日志 | 近实时 |
| 资产授权变动 | 系统资源管理中心 | 业务日志 | 近实时 |
### 3.2 数据采集架构
```
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 认证身份中心 │ │ 应用资源中心 │ │ 系统资源中心 │
│ (业务事件) │ │ (业务事件) │ │ (业务事件) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
│ 异步MQ │ 异步MQ │ 异步MQ
│ (RocketMQ) │ (RocketMQ) │ (RocketMQ)
├────────────────┼────────────────┘
│ │
▼ ▼
┌────────────────────────────────────────────────┐
│ 审计事件消费处理器 │
│ │
│ 1. 事件解析器（JSON → 统一事件格式） │
│ 2. 事件增强器（补充IP地理信息、资产元数据等） │
│ 3. 事件路由器（分类型写入不同索引） │
│ 4. 合规规则引擎（实时检测异常规则） │
└──────┬─────────────────────────────────┬────────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────────┐
│ Elasticsearch │ │ 告警通道 │
│ (事件存储) │ │ (企业微信/短信等) │
│ 按时间分索引 │ │ │
│ 按月建索引别名 │ │ 合规告警 → 通知 │
└──────────────┘ └──────────────────┘
│
▼
┌──────────────┐
│ 报表引擎 │
│ (定时+按需) │
└──────────────┘
```
---
## 4. 统一审计事件模型
### 4.1 事件基础结构
```json
{
"audit_id": "aud-20260517-abc123def456",
"event_type": "login", // 事件类型
"event_version": "1.0", // 事件格式版本
"timestamp": 1700000000000, // 事件发生时间(毫秒级)
"received_at": 1700000001000, // 审计中心接收时间
"actor": { // 行为主体
"uid": "uid_00123",
"login_name": "zhangsan",
"display_name": "张三",
"org_code": "BJ_SALES",
"org_path": "省公司/北京分公司/销售部",
"identity_type": "internal"
},
"action": { // 行为描述
"category": "auth", // 大类: auth/access/perm/admin/system
"operation": "login", // 具体操作
"detail": "密码认证登录", // 人工可读描述
"result": "success", // success/failure/blocked
"reason": "" // 失败/阻断原因
},
"resource": { // 操作对象
"type": "system", // system/app/asset/data
"id": "auth-service", // 资源标识
"name": "认证服务" // 资源名称
},
"context": { // 操作上下文
"source_ip": "10.0.1.100",
"source_ip_country": "中国",
"source_ip_city": "北京",
"user_agent": "Mozilla/5.0 ...",
"device_id": "dev_fingerprint_xxx",
"session_id": "sess_xyz789",
"mfa_level": 2,
"auth_methods": ["password", "sms"]
},
"metadata": { // 元数据
"source_center": "auth-identity",
"source_service": "auth-api",
"trace_id": "trace-uuid-xxx"
}
}
```
### 4.2 ES索引模型
```json
// 索引模板：audit-events-{year}-{month}
{
"mappings": {
"dynamic": "strict",
"properties": {
"audit_id": { "type": "keyword" },
"event_type": { "type": "keyword" },
"event_version":{ "type": "keyword", "index": false },
"timestamp": { "type": "date", "format": "epoch_millis" },
"received_at": { "type": "date", "format": "epoch_millis" },
// actor字段
"actor.uid": { "type": "keyword" },
"actor.login_name": { "type": "keyword" },
"actor.display_name": { "type": "text", "fields": { "keyword": { "type": "keyword" } } },
"actor.org_code": { "type": "keyword" },
"actor.org_path": { "type": "keyword" },
"actor.identity_type": { "type": "keyword" },
// action字段
"action.category": { "type": "keyword" },
"action.operation": { "type": "keyword" },
"action.detail": { "type": "text" },
"action.result": { "type": "keyword" },
"action.reason": { "type": "text" },
// resource字段
"resource.type": { "type": "keyword" },
"resource.id": { "type": "keyword" },
"resource.name": { "type": "text" },
// context字段
"context.source_ip": { "type": "ip" },
"context.source_ip_country": { "type": "keyword" },
"context.source_ip_city": { "type": "keyword" },
"context.user_agent": { "type": "text", "index": false },
"context.device_id": { "type": "keyword" },
"context.session_id": { "type": "keyword" },
"context.mfa_level": { "type": "integer" },
"context.auth_methods": { "type": "keyword" }
}
},
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1,
"refresh_interval": "5s"
}
}
```
### 4.3 索引与生命周期管理
```
索引命名: audit-events-2026-05 (按月)
别名策略:
write: audit-events-active (当前写入索引)
read: audit-events-all (查询所有)
生命周期（ILM）:
热阶段(7天): SSD存储, 副本数2, 刷新间隔1s
温阶段(30天): HDD存储, 副本数1, 刷新间隔30s
冷阶段(180天): HDD存储, 副本数1, forcemerge 1段
删除: 180天后删除索引
容量估算:
假设日均50万事件 × 1KB/事件 ≈ 500MB/天
30天 ≈ 15GB, 180天 ≈ 90GB (含副本)
上硬件资源绰绰有余
```
---
## 5. 合规规则引擎
### 5.1 规则示例
```yaml
rules:
- id: "RULE-001"
name: "非工作时间登录告警"
severity: "medium"
condition:
event_type: "login"
time_range:
- "22:00-08:00" # 非工作时间
- "周六,周日"
action: "notify_manager"
- id: "RULE-002"
name: "连续登陆失败锁定"
severity: "high"
condition:
event_type: "login"
action.result: "failure"
count: 5
window: "5m" # 5分钟内
per: "actor.uid"
action: "lock_account"
- id: "RULE-003"
name: "异地登录检测"
severity: "high"
condition:
event_type: "login"
action.result: "success"
geo_change: true # 与前一次登录IP不同城市
window: "1h" # 1小时内跨越城市
action: "notify_user_sms"
- id: "RULE-004"
name: "高危命令执行"
severity: "critical"
condition:
event_type: "command"
command_match: "(rm -rf|shutdown|reboot|mkfs|dd if=)"
action: "block_and_notify"
- id: "RULE-005"
name: "权限批量回收异常"
severity: "medium"
condition:
event_type: "perm_change"
change_type: "revoke"
count: 10
window: "10m"
per: "actor.uid"
action: "notify_security_admin"
- id: "RULE-006"
name: "非授权资产访问尝试"
severity: "high"
condition:
event_type: "access"
action.result: "denied"
count: 3
window: "5m"
action: "notify_security_admin"
```
### 5.2 规则执行架构
```
┌─────────────┐
│ 审计事件流 │
│ (MQ消费) │
└──────┬──────┘
│
▼
┌──────────────────────┐
│ 规则引擎核心 │
│ │
│ ┌──────────────────┐ │
│ │ 规则编译模块 │ │
│ │ (YAML → 执行计划) │ │
│ └──────────────────┘ │
│ ┌──────────────────┐ │
│ │ 规则执行器 │ │
│ │ (有状态: 使用 │ │
│ │ Redis计数窗口) │ │
│ └──────────────────┘ │
│ ┌──────────────────┐ │
│ │ 告警聚合器 │ │
│ │ (去重+降噪) │ │
│ └──────────────────┘ │
└──────┬──────┬───────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ 告警存储 │ │ 通知通道 │
│ (ES告警索引)│ │ 企业微信 │
│ │ │ 短信/电话 │
│ │ │ 4A管理台 │
└──────────┘ └──────────┘
```
### 5.3 规则治理
- **规则热加载**：规则从DB/配置中心动态读取，变更无需重启
- **规则测试沙箱**：支持在沙箱中测试规则效果再发布
- **规则级联**：支持规则之间的依赖和触发关系
- **误报反馈**：告警可标注"误报"，自动调整规则阈值
---
## 6. 审计报表输出模型
### 6.1 报表分类
| 报表类型 | 周期 | 受众 | 内容 |
|---------|------|------|------|
| **部门操作日报** | 日 | 部门安全员 | 本部门人员登录、权限变更、资产访问汇总 |
| **公司安全周报** | 周 | 安全管理员 | 全公司异常行为统计、高危操作汇总 |
| **合规月报** | 月 | 合规部门/领导 | 合规指标完成情况、不合规事件明细 |
| **账号健康检查报告** | 月 | 系统管理员 | 僵尸账号、过期权限、密码过期情况 |
| **资产访问趋势分析** | 月 | 运维负责人 | 各资产访问频次、高峰时段、异常访问 |
| **权限审计专报** | 季 | 审计部门 | 权限合规性专项检查、最小权限原则遵从度 |
| **自定义报表** | 按需 | 指定人员 | 按事件类型/时间/用户/资产组合查询 |
### 6.2 报表模板示例
**报表：部门操作日报**
```
┌────────────────────────────────────────────────────────────────┐
│ 4A操作日报 - 日期：2026-05-17 │
│ 部门：北京分公司/销售部 │
├────────────────────────────────────────────────────────────────┤
│ 一、登录统计 │
│ ┌─────────────────────┬────────┬────────┬────────┐ │
│ │ 项目 │ 总量 │ 成功 │ 失败 │ │
│ ├─────────────────────┼────────┼────────┼────────┤ │
│ │ 密码登录 │ 156 │ 148 │ 8 │ │
│ │ 人脸登录 │ 23 │ 22 │ 1 │ │
│ │ SIM卡登录 │ 12 │ 12 │ 0 │ │
│ │ 短信验证码登录 │ 45 │ 44 │ 1 │ │
│ └─────────────────────┴────────┴────────┴────────┘ │
│ │
│ 二、权限变更 │
│ ┌─────────────────────┬────────┬────────┬────────┐ │
│ │ 操作类型 │ 次数 │ 涉及用户 │ 涉及应用 │ │
│ ├─────────────────────┼────────┼────────┼────────┤ │
│ │ 角色授予 │ 3 │ 3 │ 2 │ │
│ │ 角色回收 │ 1 │ 1 │ 1 │ │
│ │ 临时授权 │ 2 │ 2 │ 1 │ │
│ └─────────────────────┴────────┴────────┴────────┘ │
│ │
│ 三、资产访问 │
│ ┌─────────────────────┬────────┬────────┐ │
│ │ 资产 │ 访问次数 │ 操作人员数 │ │
│ ├─────────────────────┼────────┼────────┤ │
│ │ 10.0.1.10 (DB-MAST)│ 12 │ 3 │ │
│ │ 10.0.2.20 (APP-01) │ 8 │ 2 │ │
│ └─────────────────────┴────────┴────────┘ │
│ │
│ 四、异常告警 │
│ ┌────────────────────────────┬────────┬──────────┐ │
│ │ 告警内容 │ 等级 │ 处理状态 │ │
│ ├────────────────────────────┼────────┼──────────┤ │
│ │ 用户张三 22:35 登录(异地) │ 中 │ 待处理 │ │
│ └────────────────────────────┴────────┴──────────┘ │
└────────────────────────────────────────────────────────────────┘
```
### 6.3 报表引擎设计
```yaml
报表引擎:
调度器:
- 定时任务 (cron表达式)
- 按需触发 (API)
- 事件触发 (达到某告警阈值时自动生成详细报告)
数据源:
ES查询: 按事件类型/时间范围/用户/资产等组合查询
聚合: 使用ES的聚合API (terms/date_histogram/filters/cardinality)
补充: 需要时从MySQL读取用户/资产元数据
输出格式:
- HTML (内联样式, 可邮件发送)
- PDF (wkhtmltopdf / puppeteer)
- Excel (报表导出)
分发通道:
- 企业微信/钉钉机器人
- 邮件 (IMAP-SMTP技能)
- 4A管理台消息中心
- 短信通知（仅紧急告警）
报表存储:
- 生成的报表文件 → MinIO对象存储
- 元数据 → MySQL
- 保留周期: 日报30天, 周报6个月, 月报2年
```
---
## 7. 与泰岳版比对关注点
| 项 | 自研方案 | 泰岳方案（推测） | 验证方法 |
|----|---------|-----------------|---------|
| 事件模型 | 统一JSON事件模型，ES存储 | 可能关系型数据库分表存储 | 事件查询效率对比（涉及跨类型查询场景） |
| 合规规则 | 可编程规则引擎，热加载 | 可能硬编码或有限规则 | 新增规则的上线周期对比 |
| 审计报表 | 模板引擎+ES聚合 | 可能定时SQL查询生成 | 复杂报表生成时间对比 |
| 存储方案 | ES按时间分区+ILM | 可能MySQL分表+归档 | 180天数据查询性能对比 |
| 实时告警 | 流式规则引擎 | 可能定时任务扫描 | 告警延迟对比 |
| 会话回放 | asciinema播放器 | 自有格式播放器 | 回放流畅度+存储效率对比 |
4a-system-design/auth-identity-center.md
+382
View File
@@ -0,0 +1,382 @@
# 认证身份中心设计
## 1. 总体定位
认证身份中心是4A系统的**统一认证入口和账号数据基座**，合并了传统4A中"认证"和"身份"两个模块。核心职责：
- 维护全平台统一的账号数据模型
- 提供多因素认证能力（密码 + 人脸 + SIM卡识别 + 短信验证码）
- 管理用户会话和令牌（JWT签发/验证/刷新）
- 与现网账号平台保持账号数据实时/准实时一致
---
## 2. 数据模型
### 2.1 核心账号表（T_ACCOUNT）
```sql
-- 账号主表
CREATE TABLE T_ACCOUNT (
account_id BIGINT PRIMARY KEY AUTO_INCREMENT,
-- 统一账号标识（与现网账号平台对齐）
uid VARCHAR(64) NOT NULL UNIQUE COMMENT '统一用户ID，与现网平台一致',
login_name VARCHAR(128) NOT NULL UNIQUE COMMENT '登录名',
display_name VARCHAR(256) COMMENT '显示姓名',
-- 身份信息
id_type TINYINT NOT NULL DEFAULT 1 COMMENT '身份类型:1-内部员工 2-外包 3-第三方 4-临时',
employee_id VARCHAR(64) COMMENT '工号',
org_code VARCHAR(64) COMMENT '所属组织编码',
org_path VARCHAR(512) COMMENT '组织全路径, 如:省公司/市公司/部门',
-- 联系方式
mobile VARCHAR(32) COMMENT '手机号',
email VARCHAR(256) COMMENT '邮箱',
-- 认证凭据
password_hash VARCHAR(256) COMMENT '密码哈希(BCrypt)',
password_salt VARCHAR(64) COMMENT '密码盐值',
password_version INT NOT NULL DEFAULT 1 COMMENT '密码策略版本号',
need_reset_password TINYINT NOT NULL DEFAULT 0 COMMENT '需要重置密码:0-否 1-是',
-- 人脸信息
face_template_id VARCHAR(128) COMMENT '人脸模板ID(金科侧)',
face_registered TINYINT NOT NULL DEFAULT 0 COMMENT '是否已注册人脸',
-- SIM卡信息
sim_imsi VARCHAR(64) COMMENT 'SIM卡IMSI(互联网SIM卡识别用)',
sim_phone VARCHAR(32) COMMENT 'SIM卡关联手机号',
sim_verified TINYINT NOT NULL DEFAULT 0 COMMENT 'SIM卡是否已验证',
-- 状态管理
status TINYINT NOT NULL DEFAULT 1 COMMENT '状态:0-禁用 1-正常 2-锁定 3-过期',
lock_reason VARCHAR(256) COMMENT '锁定原因',
last_login_ip VARCHAR(64) COMMENT '最后登录IP',
last_login_time DATETIME COMMENT '最后登录时间',
login_fail_count INT NOT NULL DEFAULT 0 COMMENT '连续登录失败次数',
unlock_time DATETIME COMMENT '自动解锁时间',
-- 有效期
effective_date DATE COMMENT '生效日期',
expire_date DATE COMMENT '失效日期',
-- 审计字段
created_by VARCHAR(64) NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_by VARCHAR(64) NOT NULL,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
deleted TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除:0-未删除 1-已删除',
INDEX idx_uid (uid),
INDEX idx_login_name (login_name),
INDEX idx_org_code (org_code),
INDEX idx_mobile (mobile),
INDEX idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账号主表';
```
### 2.2 账号扩展属性表（T_ACCOUNT_ATTR）
支持与现网平台扩展属性的灵活映射，避免频繁改表。
```sql
CREATE TABLE T_ACCOUNT_ATTR (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
account_id BIGINT NOT NULL COMMENT '关联账号ID',
attr_key VARCHAR(128) NOT NULL COMMENT '属性键',
attr_value VARCHAR(1024) COMMENT '属性值',
attr_type VARCHAR(32) COMMENT '值类型:string/number/date/json',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
UNIQUE KEY uk_account_attr (account_id, attr_key),
INDEX idx_attr_key (attr_key, attr_value(128))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账号扩展属性表';
```
### 2.3 与现网账号平台拉齐方案
现网账号平台通常是多系统异构的（HR系统、OA、运维平台等各有账号体系）。拉齐策略：
```
┌─────────────────────────────────────────────────────────────────┐
│ 现网账号平台（多源） │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ HR系统 │ │ OA系统 │ │ 运维平台 │ │ 第三方接入 │ │
│ │ (工号为主)│ │(邮箱为主) │ │ (SSH用户) │ │ (API对接) │ │
│ └─────┬────┘ └────┬─────┘ └─────┬────┘ └──────┬───────┘ │
│ │ │ │ │ │
│ └──────┬─────┴──────┬──────┴──────────────┘ │
│ │ │ │
│ ┌──────▼────────────▼──────┐ │
│ │ 账号同步适配器层 │ │
│ │ (定时拉取 + 变更推送) │ │
│ │ 策略：现网→自研单向同步 │ │
│ │ 冲突：以现网最新时间为准 │ │
│ └───────────┬──────────────┘ │
│ │ │
│ ┌───────────▼──────────────┐ │
│ │ 自研T_ACCOUNT主表 │ │
│ │ (以uid为统一标识) │ │
│ │ 额外字段：sync_source │ │
│ │ sync_version │ │
│ └──────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
```
**同步策略关键点**：
1. **单向同步**：现网平台 → 自研系统（防止自研的修改反向污染现网）
2. **标识统一**：`uid` 字段作为跨系统唯一标识，映射现网各系统 ID
3. **定时+事件驱动**：
- 定时全量同步（每天凌晨）
- 变更事件订阅（MQ消息，实时增量同步）
- 手动触发全量同步（管理员操作）
4. **冲突处理**：
- 自研系统只读现网字段，不做覆盖
- 现网字段为主版本，自研扩展字段（如人脸模板ID）为从版本
- 时间戳精度到毫秒级，解决并发冲突
5. **挂载表记录同步日志**：T_ACCOUNT_SYNC_LOG 记录每次同步的变更明细
---
## 3. 认证能力接入
### 3.1 认证流程总图
```
┌──────────────────────┐
│ 统一认证入口 │
│ POST /api/v1/auth │
└──────────┬───────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
┌─────▼─────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ 密码认证 │ │ 人脸认证 │ │ SIM认证 │
│ provider │ │ provider │ │ provider │
└─────┬─────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
└────────┬────────┴────────┬────────┘
│ │
┌──────▼──────┐ ┌──────▼──────┐
│ 认证成功 │ │ 认证失败 │
│ → 生成令牌 │ │ → 记录失败 │
│ → 返回JWT │ │ → 触发告警 │
└─────────────┘ └─────────────┘
```
### 3.2 密码认证
- **技术选型**：BCrypt（自适应哈希，cost factor=10-12）
- **策略**：
- 支持密码复杂度策略（长度/大小写/特殊字符组合）
- 支持密码历史管理（禁止使用最近N次密码）
- 连续失败N次后锁定账号 T 分钟
- 支持首次登录强制改密
- **接口**：标准 OAuth2 Password Grant + 自定义扩展
### 3.3 金科人脸识别接入
**集成方案**：
```yaml
# 金科人脸识别对接配置
face_recognition:
provider: "jinke"
api_base: "https://face-api.chinamobile.com/v2"
auth_mode: "aksk" # API Key + Secret Key 认证
timeout_ms: 5000
retry:
max_attempts: 2
backoff_ms: 200
endpoints:
verify: "/face/verify" # 1:1 人脸验证
detect: "/face/detect" # 人脸检测
register: "/face/register" # 人脸模板注册
delete: "/face/template/delete" # 删除人脸模板
liveness:
enabled: true # 活体检测开关
mode: "action" # action: 动作指令式, flash: 闪光
```
**认证流程**：
1. 客户端采集人脸图片 → 上传至自研后台
2. 自研后台调用金科 `/face/detect` 检测有效性（活体检测）
3. 通过后调用 `/face/verify` 传入用户 `uid` + 人脸图片
4. 金科返回置信度和匹配结果（阈值 >= 0.85 视为通过）
5. 自研后台记录认证日志，签发JWT
### 3.4 互联网SIM卡识别
**能力说明**：
- 利用运营商网关能力，识别用户手机号与SIM卡IMSI的绑定关系
- 用户通过蜂窝网络访问时，网关可携带SIM卡信息
- 实现"无感认证"——用户只需打开页面即可自动识别身份
**接入方案**：
```
用户手机(蜂窝网络) ──→ 运营商网关 ──→ 自研4A网关
↑ ↑
HTTP Header携带 解析Header提取
IMSI/MSISDN SIM信息，与账号
T_ACCOUNT.sim_imsi
做匹配验证
```
**技术要点**：
1. 依赖运营商网关配置（需与网络部协调开通）
2. 作为辅助认证因子，不可单独作为强认证手段
3. 需配合设备指纹、IP地理位置等信息做风险判断
4. 当SIM信息与预注册信息不一致时，触发二次认证（短信验证码）
### 3.5 消息中心短信接入
**集成方案**：
```yaml
sms:
provider: "message_center" # 中国移动消息中心
api_base: "https://msg-center.chinamobile.com/api"
app_id: "${SMS_APP_ID}"
app_secret: "${SMS_APP_SECRET}"
endpoints:
send: "/sms/send"
batch_send: "/sms/batch_send"
query_status: "/sms/status/{msg_id}"
features:
template: true # 使用短信模板（防篡改）
signature: "【中国移动】"
expiry_minutes: 5 # 验证码有效期5分钟
```
**流程**：
1. 发送验证码：生成6位数字验证码 → 写入 Redis（key=sms:code:{mobile}, TTL=300s）→ 调用消息中心API下发
2. 验证：用户提交验证码 → 查 Redis 比对 → 正确则完成认证
3. 限制策略：60秒内不可重复发送，每日上限10次
### 3.6 多因素认证组合策略
```
┌──────────────────────────────────────────────────────────────────┐
│ MFA策略配置（可动态调整） │
│ │
│ 场景类型 │ 认证因子组合 │
│ ──────────────────┼─────────────────────────────────────────── │
│ 内部网络登录 │ 密码 (单因素) │
│ 远程VPN登录 │ 密码 + 短信验证码 (双因素) │
│ 堡垒机登录 │ 密码 + 人脸/SIM (双因素) │
│ 敏感操作确认 │ 已登录令牌 + 短信验证码 (双因素) │
│ 管理员操作 │ 密码 + 人脸 + 短信验证码 (三因素) │
│ SIM卡网关识别 │ SIM识别 (零操作) │
└──────────────────────────────────────────────────────────────────┘
```
---
## 4. 令牌与会话管理
### 4.1 JWT令牌设计
```json
{
"access_token": {
"header": {"alg": "RS256", "typ": "JWT", "kid": "2026-01"},
"payload": {
"sub": "uid_00123",
"iss": "4a-self",
"aud": "4a-resource-centers",
"exp": 3600,
"iat": 1700000000,
"jti": "unique-token-id-abc123",
"auth_context": {
"mfa_level": 2,
"auth_methods": ["password", "sms"],
"session_id": "sess_xyz789"
},
"roles": ["operator", "auditor"]
},
"sign": "RS256_signature..."
},
"refresh_token": {
"expiry": 86400 * 7,
"rotation": true
}
}
```
- **签名算法**：RS256（非对称），access_token 和 refresh_token 使用不同密钥对
- **有效期**：access_token 1小时，refresh_token 7天（支持滑动刷新）
- **吊销机制**：Redis 维护黑名单（`jti:revoked`），注销/改密后立即使所有token失效
### 4.2 会话状态存储
```
Redis Key 设计:
4a:session:{session_id} → Session对象（用户信息、MFA等级、设备指纹）
4a:token:jti:{jti} → 令牌元数据（issuer_ip、issued_at、status）
4a:token:user:{uid} → 用户当前有效令牌列表
4a:token:blacklist:{jti} → 吊销令牌集合（TTL = token有效期）
4a:sms:code:{mobile} → 短信验证码（TTL = 300s）
4a:login:fail:{uid} → 登录失败计数（TTL = 锁定周期）
```
---
## 5. 接口规范
### 5.1 认证接口
| 接口 | 方法 | 说明 |
|------|------|------|
| `/api/v1/auth/login` | POST | 统一登录入口，请求体指定认证方式 |
| `/api/v1/auth/refresh` | POST | 刷新access_token |
| `/api/v1/auth/logout` | POST | 登出，吊销令牌 |
| `/api/v1/auth/check` | GET | 校验令牌有效性 |
| `/api/v1/auth/sms/send` | POST | 发送短信验证码 |
| `/api/v1/auth/face/register` | POST | 注册人脸模板 |
| `/api/v1/auth/sim/verify` | POST | SIM卡验证 |
### 5.2 账号管理接口
| 接口 | 方法 | 说明 |
|------|------|------|
| `/api/v1/accounts` | GET | 分页查询账号列表 |
| `/api/v1/accounts/{uid}` | GET | 查询单个账号详情 |
| `/api/v1/accounts` | POST | 创建账号（同步到现网需审批） |
| `/api/v1/accounts/{uid}` | PUT | 更新账号信息 |
| `/api/v1/accounts/{uid}` | DELETE | 禁用/删除账号 |
| `/api/v1/accounts/{uid}/password` | PUT | 修改密码 |
| `/api/v1/accounts/{uid}/status` | PATCH | 修改账号状态 |
| `/api/v1/accounts/sync/trigger` | POST | 手动触发全量同步 |
| `/api/v1/accounts/sync/log` | GET | 查询同步日志 |
### 5.3 响应格式
```json
// 成功响应
{
"code": 0,
"message": "success",
"data": {},
"request_id": "req-uuid-xxx"
}
// 错误响应
{
"code": 40101,
"message": "invalid_credentials",
"detail": "密码错误，还剩3次尝试机会",
"request_id": "req-uuid-xxx"
}
```
---
## 6. 与泰岳版比对关注点
| 项 | 自研方案 | 泰岳方案（推测） | 验证方法 |
|----|---------|-----------------|---------|
| 密码存储 | BCrypt + 多代盐值 | 厂商自研加密模块 | 黑盒：记录认证耗时 |
| 会话管理 | Redis + JWT | 可能为DB + Session | 比较并发下Session创建吞吐 |
| 认证流程扩展 | Provider模式，可插拔 | 模块化程度未知 | 接入新因子时的改动量对比 |
| 多因素组合 | 策略引擎（DSL配置） | 可能硬编码 | 配置灵活度对比 |
| 账号同步 | 适配器模式对接多源 | 可能单源集中 | 同步延迟和完整性对比 |
4a-system-design/overview.md
+160
View File
@@ -0,0 +1,160 @@
# 自研4A对标系统 - 总体架构说明
## 1. 系统定位
### 1.1 为什么做
现网4A系统为神州泰岳采购版，存在以下核心痛点：
- **黑盒依赖**：核心数据模型、流程引擎、认证逻辑不可控，定制需求依赖厂商排期（通常3-6个月）
- **报价不透明**：二期扩容、功能增补的报价缺乏比价基准
- **技术演进受限**：无法灵活接入新认证方式（人脸、SIM卡识别等），扩展成本高
- **运维锁死**：故障排查依赖厂商支撑，MTTR难以压缩
本项目利用**1级4A 8期工程已申请的硬件资源**，划拨部分服务器，自研一套与泰岳版功能对标的4A系统，周期**两个月**。
### 1.2 核心目标
| 维度 | 目标 |
|------|------|
| **功能对标** | 覆盖泰岳版90%以上的核心功能（SSO、账号管理、权限管理、审计） |
| **流程对标** | 实现对标的24个账号管理流程、资源接入流程 |
| **架构验证** | 验证自研方案在性能、稳定性、安全性上是否可替代采购版 |
| **成本基线** | 建立"自研 vs 采购"的成本-能力对比基线，支撑后续采购决策 |
| **技术自主** | 形成完全可控的4A技术栈，后续功能迭代不受厂商约束 |
### 1.3 约束条件
- **周期**：2个月（包含开发、测试、部署、基线对比）
- **硬件**：8期工程剩余资源（具体规格视项目申请而定，按通用X86服务器 + KVM虚拟化部署）
- **团队**：非专职团队，需兼顾现网运维，强调AI辅助开发提效
- **范围**：不做全量替代，做"可验证对标"版本，功能深度聚焦核心链路
---
## 2. 四中心架构总览
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ 自研4A对标系统 │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ 认证身份中心 │ │ 应用资源管理中心 │ │ 系统资源管理中心 │ │
│ │ │ │ │ │ (含堡垒集群) │ │
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
│ │ │ 账号数据模型 │ │ │ │ SSO网关 │ │ │ │ 系统资源 │ │ │
│ │ │ (LDAP/DB) │ │ │ │ (OIDC/SAML) │ │ │ │ 授权模型 │ │ │
│ │ ├───────────────┤ │ │ ├───────────────┤ │ │ ├───────────────┤ │ │
│ │ │ 多因素认证 │ │ │ │ 应用注册 │ │ │ │ 堡垒机集群 │ │ │
│ │ │ 人脸/SIM/密码 │ │ │ │ +元数据管理 │ │ │ │ SSO/录屏 │ │ │
│ │ ├───────────────┤ │ │ ├───────────────┤ │ │ ├───────────────┤ │ │
│ │ │ 令牌/会话管理 │ │ │ │ 权限配置 │ │ │ │ 权限 │ │ │
│ │ │ (JWT/Redis) │ │ │ │ +授权规则引擎 │ │ │ │ 回收/审批流 │ │ │
│ │ └───────────────┘ │ │ └───────────────┘ │ │ └───────────────┘ │ │
│ └─────────┬───────────┘ └─────────┬───────────┘ └─────────┬───────────┘ │
│ │ │ │ │
│ └──────────┬─────────────┴─────────────┬───────────┘ │
│ │ │ │
│ ┌────────▼──────────────────────────▼────────┐ │
│ │ 审计中心 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌───────────────────┐ │ │
│ │ │ 审计数据湖 │ │ 报表引擎 │ │ │
│ │ │ (ES引擎存储) │ │ (定时/按需生成) │ │ │
│ │ ├──────────────┤ ├───────────────────┤ │ │
│ │ │ 合规规则引擎 │ │ 分级下发通道 │ │ │
│ │ │ (策略驱动) │ │ (部门级/公司级) │ │ │
│ │ └──────────────┘ └───────────────────┘ │ │
│ └────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ AI全流程兜底闭环层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │代码生成 │ │自动测试 │ │部署编排 │ │智能运维 │ │数据一致性│ │ │
│ │ │Copilot │ │Agent │ │CI/CD │ │AIOps │ │校验Agent │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
```
### 2.1 中心间交互关系
```
┌─────────────────┐
│ 前端网关 │
│ (统一入口) │
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌───────▼──────┐ ┌────▼─────┐ ┌─────▼──────┐
│ 认证身份中心 │ │ 应用资源 │ │ 系统资源 │
│ (认证鉴权) │ │ 管理中心 │ │ 管理中心 │
└───────┬──────┘ └────┬─────┘ └─────┬──────┘
│ │ │
└──────┬───────┴──────┬──────┘
│ │
┌──────▼──────────────▼──────┐
│ 审计中心 │
│ (接收全量操作事件) │
└────────────────────────────┘
```
**核心数据流**：
1. 用户请求 → 前端网关 → 认证身份中心（登录认证）→ 颁发令牌
2. 用户携带令牌 → 应用资源管理中心（SSO接入应用）/ 系统资源管理中心（SSO接入堡垒机）
3. 全量操作事件 → 异步写入 → 审计中心（ES存储）
4. 审计中心 → 合规规则引擎 → 异常告警/报表生成
---
## 3. 两个月研发计划
```
Week 1-2: 基础设施搭建 + 认证身份中心核心 (账号模型 + 密码认证 + JWT)
Week 3-4: 多因素认证接入 (人脸/SIM/短信) + 令牌管理
Week 5-6: 应用资源管理中心 (SSO网关 + 应用注册 + 基本授权)
Week 7: 系统资源管理中心 + 堡垒机SSO原型
Week 8: 审计中心MVP + AI测试 + 与泰岳版比对验证
```
### 交付原则
- **每两周一个可演示版本**：第一周结束出认证登录页，第二周结束出SSO跳转
- **AI优先**：能用AI生成的代码、测试用例、部署脚本绝不手写
- **模块化**：每个中心独立可部署，降低集成风险
- **记录一致**：所有反推结论/接口规范写入文档，作为与泰岳谈判的技术基线
---
## 4. AI全流程兜底闭环策略
详见 `ai-cicd.md`，核心思路：
1. **开发阶段**：AI辅助生成全部业务代码（CRUD + API + 前端），人工聚焦架构和安全性审查
2. **测试阶段**：AI Agent自动生成测试用例、执行回归测试、比对与泰岳版的行为差异
3. **部署阶段**：AI编排部署流水线（Ansible/Terraform），自动处理配置差异
4. **运维阶段**：AI监控日志异常、自动排查一致性偏差、推送修复建议
5. **验收阶段**：AI驱动功能覆盖度扫描，自动生成"自研vs泰岳"比对报告
---
## 5. 与泰岳版比对策略
| 比对维度 | 方法 | 产出物 |
|---------|------|-------|
| 功能覆盖 | 逐功能点人工标记 + AI辅助扫描 | 功能覆盖矩阵表 |
| 性能基准 | 相同硬件上运行压测脚本 | 响应时间/并发量对比曲线 |
| 认证流程 | 录制泰岳版操作流程 → 生成测试脚本 → 在自研版本执行 | 流程一致度报告 |
| 数据模型 | 反推泰岳库结构 → 与自研模型逐字段比对 | 数据模型差异表 |
| 安全等级 | 相同安全基线扫描工具 | 安全差距分析 |
---
## 6. 风险与对策
| 风险 | 概率 | 影响 | 对策 |
|------|------|------|------|
| 两个月内功能覆盖不足 | 高 | 中 | 聚焦核心链路（SSO+账户管理），非核心功能标记为"二期" |
| 泰岳接口反向推导不完整 | 中 | 高 | 重点攻克登录/授权关键接口，优先保证自研体系内部闭环 |
| 团队人力分散 | 高 | 中 | AI最大化替代重复劳动，每个中心配1-2人即可启动 |
| 与现网系统对接兼容问题 | 中 | 高 | 提前识别对接点，使用适配器模式隔离变更 |
4a-system-design/resource-centers.md
+532
View File
@@ -0,0 +1,532 @@
# 应用资源管理中心 + 系统资源管理中心（含堡垒集群）
> 本文件涵盖2个中心的设计，考虑到它们共享权限模型和SSO机制，合并在同一份文档中。
---
## 第一部分：应用资源管理中心
## 1. 总体定位
应用资源管理中心负责企业内**业务应用的单点登录接入和权限管理**。核心职责：
- 提供统一SSO网关，对接各类业务系统（B/S架构为主）
- 管理应用注册、元数据、接入配置
- 提供权限模型和授权规则引擎
- 参考亚信安全接口规范（IAM/SSO相关）
---
## 2. SSO网关设计
### 2.1 支持的协议
| 协议 | 成熟度 | 适用场景 | 优先级 |
|------|--------|---------|--------|
| OAuth2.0 + OIDC | 高 | 现代应用（RESTful API） | P0 |
| SAML 2.0 | 高 | 传统企业应用、ERP系统 | P0 |
| CAS | 中 | 部分遗留Java应用 | P1 |
| 自定义Token透传 | 低 | 老系统改造过渡 | P2 |
### 2.2 SSO流程（OIDC Authorization Code）
```
┌──────┐ ┌──────────┐ ┌──────────────┐ ┌──────────┐
│ 用户 │ │ 业务应用 │ │ 认证身份中心 │ │SSO网关 │
│ │ │ (Client) │ │ (Auth Server) │ │ │
└──┬───┘ └─────┬────┘ └──────┬───────┘ └─────┬────┘
│ │ │ │
│ 访问应用 │ │ │
│───────────────>│ │ │
│ │ 未登录，跳转SSO │ │
│<───────────────│ │ │
│ 302重定向 │ │ │
│──────────────────────────────────>│ │
│ │ │ SSO网关代收 │
│ │ │ 认证请求，返回 │
│ 登录页 │ │ 授权码 │
│<──────────────────────────────────│ │
│ │ │ │
│ 提交凭证 │ │ │
│──────────────────────────────────>│ │
│ │ │ 验证通过 │
│ │ │ 返回授权码 │
│<──────────────────────────────────│ │
│ │ │ │
│ 携带授权码回调 │ │ │
│──────────────────────────────────────────────> │
│ │ │ SSO网关 │
│ │ │ 校验+与身份中心 │
│ │ │ 交换AccessToken │
│ │ <───────────────────────────────────│
│ │ │ │
│ 登录成功 │ │ │
│<───────────────│ │ │
```
### 2.3 应用注册模型
```sql
CREATE TABLE T_APP (
app_id BIGINT PRIMARY KEY AUTO_INCREMENT,
app_name VARCHAR(128) NOT NULL COMMENT '应用名称',
app_key VARCHAR(64) NOT NULL UNIQUE COMMENT '应用唯一标识',
app_secret VARCHAR(256) NOT NULL COMMENT '应用密钥(加密存储)',
app_type TINYINT NOT NULL DEFAULT 1 COMMENT '应用类型:1-B/S 2-C/S 3-API 4-移动端',
-- SSO配置
sso_protocol VARCHAR(16) NOT NULL DEFAULT 'oidc' COMMENT 'SSO协议:oidc/saml/cas',
callback_urls JSON NOT NULL COMMENT '允许的回调URL列表',
logout_url VARCHAR(512) COMMENT '登出回调URL',
token_endpoint_auth_method VARCHAR(32) DEFAULT 'client_secret_basic',
-- 应用访问控制
access_level TINYINT NOT NULL DEFAULT 1 COMMENT '访问等级:1-普通 2-敏感 3-高敏感',
require_mfa TINYINT NOT NULL DEFAULT 0 COMMENT '是否需要MFA',
allowed_ips JSON COMMENT 'IP白名单',
allowed_domains JSON COMMENT '域名白名单',
-- 权限模型
permission_mode VARCHAR(16) DEFAULT 'rbac' COMMENT '权限模式:rbac/abac/hybrid',
-- 状态
status TINYINT NOT NULL DEFAULT 1 COMMENT '状态:0-停用 1-启用',
-- 审计
created_by VARCHAR(64) NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
deleted TINYINT NOT NULL DEFAULT 0,
INDEX idx_app_key (app_key),
INDEX idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='应用注册表';
```
---
## 3. 权限模型（参考亚信接口规范）
### 3.1 RBAC + ABAC 混合模型
```
┌──────────┐
│ 用户 │
│ (User) │
└────┬─────┘
│
┌─────────┼─────────┐
│ │ │
┌─────▼──┐ ┌────▼───┐ ┌────▼───┐
│ 组织(Org)│ │ 角色 │ │ 属性 │
│ (ABAC) │ │ (Role) │ │(Attr) │
└────┬───┘ └────┬───┘ └────┬───┘
│ │ │
│ ┌─────▼──────┐ │
│ │ 权限集 │ │
└────┤ (Permission)├──┘
│ +策略规则 │
└─────┬──────┘
│
┌─────▼──────┐
│ 资源实例 │
│ (Resource) │
└────────────┘
```
**权限判定引擎流程**：
```
输入: 用户U, 应用A, 操作OP, 资源R, 上下文C
1. 检查U是否在A的应用白名单中（组织级） → 否→拒绝
2. 获取U在A中的角色列表 → 获取角色对应的权限集
3. 检查权限集是否包含 (OP, R) → 是→允许
4. ABAC规则评估：检查上下文C（时间/IP/设备/MFA等级）
→ ABAC规则不满足 → 降级/拒绝
5. 返回判定结果
```
### 3.2 核心权限表结构
```sql
-- 角色表
CREATE TABLE T_ROLE (
role_id BIGINT PRIMARY KEY AUTO_INCREMENT,
app_id BIGINT NOT NULL COMMENT '所属应用',
role_name VARCHAR(64) NOT NULL COMMENT '角色名',
role_code VARCHAR(64) NOT NULL COMMENT '角色编码(应用内唯一)',
description VARCHAR(256),
is_system TINYINT NOT NULL DEFAULT 0 COMMENT '系统预置角色',
status TINYINT NOT NULL DEFAULT 1,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_app_role (app_id, role_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='角色表';
-- 权限资源表
CREATE TABLE T_PERMISSION (
perm_id BIGINT PRIMARY KEY AUTO_INCREMENT,
app_id BIGINT NOT NULL COMMENT '所属应用',
resource VARCHAR(128) NOT NULL COMMENT '资源标识: menu:/user/list',
action VARCHAR(32) NOT NULL COMMENT '操作: read/write/delete/admin',
description VARCHAR(256),
status TINYINT NOT NULL DEFAULT 1,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_app_resource_action (app_id, resource, action)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='权限资源表';
-- 角色-权限关联
CREATE TABLE T_ROLE_PERMISSION (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
role_id BIGINT NOT NULL,
perm_id BIGINT NOT NULL,
effect TINYINT NOT NULL DEFAULT 1 COMMENT '1-允许 0-拒绝',
UNIQUE KEY uk_role_perm (role_id, perm_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='角色权限关联表';
-- 用户-应用角色分配
CREATE TABLE T_USER_APP_ROLE (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
account_id BIGINT NOT NULL COMMENT '用户账号ID',
app_id BIGINT NOT NULL COMMENT '应用ID',
role_id BIGINT NOT NULL COMMENT '角色ID',
grant_type VARCHAR(16) DEFAULT 'direct' COMMENT 'direct-直接分配 org-继承',
start_date DATETIME,
end_date DATETIME COMMENT '有效期',
granted_by VARCHAR(64),
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_account_app_role (account_id, app_id, role_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户应用角色分配表';
-- ABAC策略规则表
CREATE TABLE T_ABAC_POLICY (
policy_id BIGINT PRIMARY KEY AUTO_INCREMENT,
app_id BIGINT NOT NULL,
policy_name VARCHAR(128) NOT NULL,
policy_type VARCHAR(16) NOT NULL COMMENT 'allow/deny',
subject_attr JSON COMMENT '主体属性条件',
resource_attr JSON COMMENT '资源属性条件',
action_cond JSON COMMENT '操作条件',
context_cond JSON COMMENT '上下文条件(时间/IP/设备等)',
priority INT NOT NULL DEFAULT 0 COMMENT '优先级(数字越大越优先)',
status TINYINT NOT NULL DEFAULT 1,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='ABAC策略规则表';
```
### 3.3 与应用系统的权限接口规范
参考亚信安全接口规范，提供以下核心接口供业务系统对接：
```yaml
授权查询接口:
GET /api/v1/authorization/check
参数:
- app_key: 应用标识
- uid: 用户ID
- resource: 资源路径
- action: 操作
- context: 上下文（可选JSON）
返回: { allowed: true/false, reason: "xxx" }
用户角色列表:
GET /api/v1/apps/{app_key}/users/{uid}/roles
返回: [{role_id, role_code, role_name, grant_type, valid_until}]
用户权限列表:
GET /api/v1/apps/{app_key}/users/{uid}/permissions
返回: [{resource, action, effect}]
权限批量校验:
POST /api/v1/authorization/batch-check
请求体: [{app_key, uid, resource, action, context}, ...]
返回: [{allowed, reason}, ...]
权限同步通知（服务端推送）:
POST /webhook/app/{app_key}/permission-sync
请求体: {event_type: "role_assign"|"role_revoke"|"perm_change",
uid, changed_roles, timestamp}
```
---
## 4. 授权流程
```
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ 资源申请者 │ │ 审批人 │ │ 权限中心 │ │ 业务应用 │
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘
│ │ │ │
│ 提交权限申请 │ │ │
│────────────────>│ │ │
│ │ │ │
│ 审批通过/拒绝 │ │
│ │────────────────>│ │
│ │ │ 分配角色 │
│ │ │────────────────>│
│ │ │ (授权生效通知) │
│ 申请结果通知 │ │ │
│<───────────────────────────────────────────────────│
│ │ │ │
│ 使用授权 │ │ │
│───────────────────────────────────────────────────>│
│ │ │ 鉴权校验 │
│<───────────────────────────────────────────────────│
```
**授权模式**支持：
1. **手动分配**：管理员为指定用户分配角色
2. **申请审批**：用户提交申请 → 上级/安全管理员审批 → 自动生效
3. **组织继承**：自动继承所属组织的默认角色集
4. **临时授权**：设定生效时间窗口，到期自动回收
---
## 第二部分：系统资源管理中心（含堡垒集群）
## 5. 总体定位
系统资源管理中心负责**服务器、网络设备、数据库等基础设施资源的权限管理**，包含堡垒机集群集成。核心职责：
- 管理系统资源的访问权限（SSH/RDP/数据库连接）
- 提供堡垒机单点登录和会话录制
- 参考泰岳管理模型（反推库结构和接口）
- 管理登录凭证、密钥、授权策略
---
## 6. 参考泰岳管理模型 - 反推策略
### 6.1 泰岳系统资源管理模型推断
基于现网泰岳版4A的运维经验和操作界面观察，反推其数据模型：
```sql
-- 推断的泰岳资产表结构
-- T_ASSET
-- asset_id BIGINT PK
-- asset_name VARCHAR(128) 资产名称
-- asset_ip VARCHAR(64) 管理IP
-- asset_type TINYINT 资产类型:1-Linux 2-Windows 3-网络设备 4-数据库
-- asset_group VARCHAR(128) 所属资产组
-- protocol VARCHAR(16) 管理协议:ssh/rdp/telnet
-- port INT 端口
-- account_auto TINYINT 1-纳管账号 0-手动密码
-- auth_mode TINYINT 1-密码 2-密钥 3-双因子
-- status TINYINT
-- 推断的泰岳授权表
-- T_ASSET_AUTH
-- auth_id BIGINT PK
-- asset_id BIGINT FK -> T_ASSET
-- account_id BIGINT FK (泰岳内部账号)
-- system_account VARCHAR(64) 目标系统账号(root/oracle/...)
-- access_level TINYINT 权限等级:1-普通 2-运维 3-管理员
-- start_time DATETIME 授权开始
-- end_time DATETIME 授权结束
-- approver VARCHAR(64)
```
**反推方法论**：
```
┌──────────────────────────────────────────────────────────────────┐
│ 反推方法 │
│ │
│ 1. 界面观察法 │
│ - 录屏泰岳操作界面，记录所有字段名和排列顺序 │
│ - 观察搜索/筛选条件字段（通常映射到DB索引字段） │
│ - 导出功能里的列名（CSV/xls导出列名常等于DB列名） │
│ │
│ 2. API嗅探法 │
│ - 浏览器开发者工具抓取泰岳管理的API请求/响应JSON │
│ - 关注字段名映射（下划线命名 vs 驼峰命名规律） │
│ - 分页参数（limit/offset习惯暗示底层DB） │
│ │
│ 3. 日志分析法 │
│ - 查看泰岳版的操作日志/审计日志字段定义 │
│ - 从报错信息中提取表名和字段名（典型：Constraint violation） │
│ │
│ 4. 行为验证法 │
│ - 设置特定值 → 观察界面呈现 → 推断字段类型/约束 │
│ - 创建/修改/删除操作 → 推断关联关系和约束条件 │
└──────────────────────────────────────────────────────────────────┘
```
### 6.2 自研系统资源模型
```sql
-- 资产主表
CREATE TABLE T_SYSTEM_ASSET (
asset_id BIGINT PRIMARY KEY AUTO_INCREMENT,
asset_name VARCHAR(128) NOT NULL COMMENT '资产名称',
asset_ip VARCHAR(64) NOT NULL COMMENT '管理IP',
asset_type TINYINT NOT NULL COMMENT '1-Linux 2-Windows 3-网络设备 4-数据库 5-中间件',
asset_group_id BIGINT COMMENT '所属资产组',
-- 连接信息
protocol VARCHAR(16) NOT NULL DEFAULT 'ssh' COMMENT '管理协议:ssh/rdp/telnet/mysql/oracle',
port INT NOT NULL DEFAULT 22,
-- 凭据管理
credential_mode TINYINT NOT NULL DEFAULT 1 COMMENT '1-纳管密码 2-纳管密钥 3-手动输入 4-动态令牌',
-- 纳管账号（系统层面的账号，非4A用户账号）
managed_account VARCHAR(64) COMMENT '纳管系统账号(root/oracle等)',
managed_password_enc VARCHAR(512) COMMENT '纳管密码(AES-256加密)',
managed_key_enc TEXT COMMENT '纳管私钥(AES-256加密)',
-- 访问控制
access_level TINYINT NOT NULL DEFAULT 2 COMMENT '访问等级:1-低 2-中 3-高',
allowed_users JSON COMMENT '允许操作的白名单用户列表',
-- 堡垒机集成
bastion_enabled TINYINT NOT NULL DEFAULT 1 COMMENT '是否通过堡垒机接入',
-- 状态
status TINYINT NOT NULL DEFAULT 1 COMMENT '0-停用 1-启用 2-维护',
-- 元数据
department VARCHAR(128) COMMENT '所属部门',
location VARCHAR(128) COMMENT '物理位置',
vendor VARCHAR(64) COMMENT '厂商',
model VARCHAR(64) COMMENT '型号',
os_version VARCHAR(64) COMMENT '操作系统版本',
remark TEXT,
-- 审计
created_by VARCHAR(64),
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
deleted TINYINT NOT NULL DEFAULT 0,
INDEX idx_asset_ip (asset_ip),
INDEX idx_asset_type (asset_type),
INDEX idx_group (asset_group_id),
INDEX idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统资产表';
-- 资产授权表
CREATE TABLE T_ASSET_AUTHORIZATION (
auth_id BIGINT PRIMARY KEY AUTO_INCREMENT,
asset_id BIGINT NOT NULL,
account_id BIGINT NOT NULL COMMENT '4A用户ID',
-- 目标系统身份
target_username VARCHAR(64) NOT NULL COMMENT '目标系统账号(root/appuser)',
-- 授权信息
access_level TINYINT NOT NULL DEFAULT 1 COMMENT '1-只读查看 2-普通操作 3-管理员操作',
-- 时间窗口
grant_type VARCHAR(16) NOT NULL DEFAULT 'permanent' COMMENT 'permanent-永久 temporary-临时',
valid_from DATETIME NOT NULL,
valid_until DATETIME,
-- 审批信息
approval_status TINYINT NOT NULL DEFAULT 0 COMMENT '0-待审批 1-已批准 2-已拒绝 3-已回收',
approver_id BIGINT,
approved_at DATETIME,
-- 行为约束
command_filter TEXT COMMENT '允许执行的命令白名单(正则)',
file_transfer TINYINT NOT NULL DEFAULT 0 COMMENT '0-禁止 1-允许上传 2-允许下载 3-双向',
-- 审计
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
revoked_at DATETIME,
revoked_by BIGINT,
INDEX idx_asset (asset_id),
INDEX idx_account (account_id),
INDEX idx_valid (valid_from, valid_until),
INDEX idx_status (approval_status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='资产授权表';
-- 资产组表
CREATE TABLE T_ASSET_GROUP (
group_id BIGINT PRIMARY KEY AUTO_INCREMENT,
group_name VARCHAR(128) NOT NULL,
parent_id BIGINT,
org_code VARCHAR(64) COMMENT '所属组织',
description VARCHAR(256),
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='资产组表';
-- 账号密码自动轮换配置
CREATE TABLE T_CREDENTIAL_ROTATION (
rotation_id BIGINT PRIMARY KEY AUTO_INCREMENT,
asset_id BIGINT NOT NULL,
target_account VARCHAR(64) NOT NULL COMMENT '目标系统账号',
rotation_schedule VARCHAR(32) NOT NULL DEFAULT '30d' COMMENT '轮换周期:7d/14d/30d/90d',
password_rule JSON COMMENT '密码生成规则',
last_rotation DATETIME,
next_rotation DATETIME,
auto_execute TINYINT NOT NULL DEFAULT 1 COMMENT '是否自动执行',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_asset_account (asset_id, target_account)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='密码轮换配置表';
```
---
## 7. 堡垒集群集成方案
### 7.1 架构选择
采用**代理模式**（非网关代理，而是独立部署堡垒机节点转发流量）：
```
┌──────────────┐
│ 4A管控平台 │
│ (认证+授权) │
└──────┬───────┘
│ API
┌──────────────┼──────────────┐
│ │ │
┌────────▼───┐ ┌──────▼──────┐ ┌────▼────────┐
│ 堡垒节点1 │ │ 堡垒节点2 │ │ 堡垒节点3 │
│ (区域A) │ │ (区域B) │ │ (区域C) │
│ ┌────────┐ │ │ ┌────────┐ │ │ ┌────────┐ │
│ │SSH/RDP │ │ │ │SSH/RDP │ │ │ │SSH/RDP │ │
│ │代理 │ │ │ │代理 │ │ │ │代理 │ │
│ └────────┘ │ │ └────────┘ │ │ └────────┘ │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
│ (网络隔离，策略控制) │
│ │ │
┌──────▼──────┐ ┌─────▼───────┐ ┌────▼──────┐
│ 目标服务器1 │ │ 目标服务器2 │ │ 目标服务器3 │
│ 10.0.1.10 │ │ 10.0.2.20 │ │ 10.0.3.30 │
└─────────────┘ └─────────────┘ └───────────┘
```
### 7.2 堡垒机核心功能
| 功能 | 说明 | 实现方案 |
|------|------|---------|
| **SSO登录** | 用户从4A平台认证后直接跳转堡垒机，无需再次认证 | JWT令牌 → 堡垒节点验证 → 建立会话 |
| **会话录制** | 记录所有操作步骤（键盘输入 + 屏幕输出） | ttyrec/cast 格式录制，定期归档至对象存储 |
| **命令审计** | 记录执行命令，匹配高危命令规则 | 实时监控bash/windows shell日志 |
| **文件传输审计** | 追踪SCP/SFTP传输的文件名、大小、路径 | 代理层拦截审计 |
| **命令拦截** | 高危命令（rm -rf /, shutdown等）实时阻断 | 自定义shell profile + 命令过滤器 |
| **会话同步** | 多人同时监控同一会话 | WebSocket实时同步 |
| **事后回放** | 回放录制的会话 | 基于录制文件+时间轴播放器 |
### 7.3 堡垒节点技术选型
| 组件 | 推荐 | 备选 |
|------|------|------|
| 代理核心 | Apache Guacamole（已支持SSH/RDP/VNC） | teleport/ssh-proxy 自研 |
| 会话录制 | asciinema (ttyrec格式) | script + scriptreplay |
| 命令拦截 | 自定义shell profile (bash_prompt wrapper) | pam_exec模块钩子 |
| 文件传输审计 | SFTP proxy (在openssh中集成ForceCommand) | rssh/scponly |
| 会话存储 | 本地文件 → 定时上传至MinIO | Ceph RGW |
| 会话回放 | asciinema player 前端组件 | 自研播放器组件 |
### 7.4 堡垒机SSO流程
```
1. 用户从4A平台认证 → 获取JWT (payload含allowed_assets)
2. 用户选择目标资产 → 4A平台验证授权
3. 4A平台生成一次性堡垒令牌（有效期60秒，含用户+资产+目标账号）
4. 用户浏览器跳转至堡垒节点URL（带令牌）
5. 堡垒节点验证令牌 → 获取目标账号的真实密码/密钥（加密传输）
6. 堡垒节点建立SSH/RDP连接目标资产
7. 代理层开始录制和审计
8. 会话结束后录制上传至对象存储
```
---
## 8. 与泰岳版比对关注点
| 项 | 自研方案 | 泰岳方案（推测） | 验证方法 |
|----|---------|-----------------|---------|
| 资产模型 | 通用资产表+扩展属性 | 可能按类型分多表 | 创建各类型资产对比信息完整度 |
| 授权粒度 | 命令级黑白名单+时间窗口+文件传输控制 | 类似 | 设置复杂授权策略对比生效情况 |
| 堡垒节点 | 基于开源组件（Guacamole） | 自研代理 | 并发连接数对比 |
| 密码轮换 | 定时间隔+自动执行 | 类似 | 轮换成功率+时间对比 |
| 会话录制 | asciinema格式 | 未知格式 | 存储空间占用+回放体验对比 |
| 命令拦截 | shell profile级 | 代理级更底层 | 高危命令漏报率对比 |