note/work/教育E卡通/苏州教育E卡通数据安全运维操作手册.md

# 苏州教育E卡通数据安全运维操作手册

## 前言

本手册基于苏州教育E卡通平台的实际运维需求，旨在建立一套**实用、可操作**的数据安全管控体系。我们不追求理论上的"完美"安全方案，而是聚焦于解决实际工作中真正存在的风险问题。

**核心原则：好钢用在刀刃上** - 把最严格的管控措施用在最高风险的操作上，对一般性操作保持必要的灵活性，确保安全不影响正常工作效率。

本手册适用于所有参与平台运维、管理的人员，包括但不限于系统管理员、客服人员、学校管理人员等。

---

## 一、操作风险分级体系

基于等保三级要求以及操作的影响范围和不可逆性，将所有操作分为五级：

### 1.1 一级操作（等保三级"重要管理操作"）

**等保三级依据**：根据《信息安全技术网络安全等级保护基本要求》（GB/T 22239-2019），重要管理操作必须采用严格的身份鉴别和访问控制措施。

**识别标准**：
- 一级特殊敏感数据修改（身份证号、姓名、学籍号等）
- 系统核心配置修改
- 安全策略变更
- 审计规则修改
- 用户权限分配

**等保三级要求**：
- **强制双因素认证**：密码+动态令牌/生物特征
- **全程录屏记录**：操作过程不可中断记录
- **双人现场操作**：一人操作，一人监督
- **完整操作链路**：申请→审核→复核→终审→执行→确认
- **审计日志完整性**：防篡改技术保护

### 1.2 二级操作（重要数据修改）

**特殊敏感数据定义**：

**一级特殊敏感数据**：
- 学生身份证号
- 学生姓名（涉及法律身份）
- 学籍号（教育部门统一编号）
- 户籍信息
- 残疾、贫困等特殊身份标记

**二级特殊敏感数据**：
- 家庭详细住址
- 监护人联系方式
- 学生照片
- 转学、休学等学籍状态变更
- 奖惩记录

**管控要求**：
- **二级操作**采用三阶段流程：申请→审核→执行
- **强制双因素认证**：密码+短信验证码
- **双人确认机制**：主管线上审批
- **操作日志记录**：修改前后值对比
- **数据自动备份**：执行前备份，可回滚

### 1.3 三级操作（一般权限操作）

**等保三级依据**：等保三级要求对用户身份鉴别和访问控制进行分级管理。

**识别标准**：
- 二级特殊敏感数据修改
- 新生录入和注册
- 账号创建和权限分配（非管理员）
- 补换卡订单处理
- 一般配置修改

**等保三级要求**：
- **双因素认证**：重要操作需要额外认证
- **审批流程**：主管审批或自动审批
- **操作记录**：完整的操作链路记录
- **权限最小化**：基于角色的精确控制

**管控要求**：
- **三级操作**采用两阶段流程：申请→审批→执行
- **会话超时控制**：30分钟无操作自动重新认证
- **操作确认机制**：重要操作需要二次确认
- **详细操作日志**：记录操作时间、IP、内容

### 1.4 四级操作（数据查询）

**等保三级依据**：等保三级要求对数据访问进行严格控制，防止未授权访问。

**识别标准**：
- 学生信息查询
- 报表生成和统计
- 系统状态查看
- 操作日志查询（授权人员）

**等保三级要求**：
- **访问控制**：基于角色的数据访问限制
- **查询审计**：所有查询操作记录
- **结果限制**：单次查询返回记录数限制
- **异常监控**：异常查询模式自动告警

**管控要求**：
- **四级操作**采用单阶段记录
- **数据脱敏显示**：敏感信息部分隐藏
- **查询频率限制**：防止批量数据爬取
- **查询原因记录**：重要查询需要说明原因

### 1.5 五级操作（只读查看）

**等保三级依据**：等保三级要求对系统访问进行监控和审计。

**识别标准**：
- 公开信息查看
- 系统帮助文档
- 个人信息修改（非特殊数据）
- 基础报表查看

**等保三级要求**：
- **基本认证**：用户名密码认证
- **会话管理**：会话超时和安全退出
- **访问记录**：基础访问日志记录

**管控要求**：
- **五级操作**最宽松的管控
- **基础日志记录**：登录时间、访问页面
- **密码策略**：定期更换强制要求

---

## 二、等保三级身份鉴别措施

### 2.1 双因素认证应用场景

**一级操作（必须使用双因素认证）**：
- 一级特殊敏感数据修改
- 系统核心配置修改
- 安全策略变更
- 用户权限分配
- 审计规则修改

**二级操作（重要操作时启用双因素认证）**：
- 二级特殊敏感数据修改
- 重要权限变更
- 批量数据处理（≥10条）

**认证方式**：
```
双因素认证组合：
方式一：密码 + 短信验证码
方式二：密码 + 动态令牌（TOTP）
方式三：密码 + 人脸识别
方式四：数字证书 + 密码
```

### 2.2 会话管理要求

**会话超时控制**：
- 一级操作：15分钟无操作强制重新认证
- 二级操作：30分钟无操作强制重新认证
- 三级操作：60分钟无操作强制重新认证
- 四、五级操作：120分钟无操作自动退出

**等保三级合规要求**：
- 远程登录必须加密传输
- 会话ID随机生成，不可预测
- 多次失败后锁定账号
- 异地登录需要额外验证

### 2.3 密码策略

**密码复杂度要求**：
- 最小长度：10位
- 包含字符类型：大写字母、小写字母、数字、特殊字符
- 定期更换：90天强制更换
- 历史密码：最近5次密码不能重复
- 临时密码：首次登录必须修改
```

**权限限制**：
- 任何人都不能单独完成一级特殊数据修改
- 操作申请人不能是审核人员
- 系统管理员不能查看证明材料内容
- 修改前必须自动备份原始数据
- 修改后立即触发数据一致性检查

### 1.2 高危操作（预防为主）

**识别标准**：
- 影响10人以上的批量操作
- 不可逆的数据修改或删除
- 可能导致系统停机或异常的操作
- 敏感数据的批量导出

**具体操作清单**：
- 批量导入/导出学生信息（≥10条）
- 批量删除学生记录
- 数据库表结构修改（CREATE/ALTER/DROP TABLE）
- 系统服务启停操作
- 防火墙规则修改
- 服务器重启/关机
- 数据库恢复操作
- 权限角色修改

**管控要求**：
```
操作前必须完成：
1. 填写《高危操作申请单》，说明操作目的和影响范围
2. 技术负责人审批（1小时内响应）
3. 制定操作回滚方案
4. 通知相关人员操作时间窗口

操作过程中：
1. 录屏记录全程操作（堡垒机自动开启）
2. 双人在场：一人操作，一人监督
3. 操作步骤严格按照申请单执行
4. 每步操作前口头确认

操作完成后：
1. 验证操作结果
2. 监督员确认操作成功
3. 填写《高危操作完成记录》
4. 相关人员确认系统正常
```

### 1.2 中危操作（双人确认）

**识别标准**：
- 单个学生关键信息修改
- 可能影响业务流程的操作
- 权限相关的操作

**具体操作清单**：
- 二级特殊敏感数据修改（家庭住址、监护人联系方式等）
- 单个学生非关键信息修改（联系电话、地址等）
- 新生录入和注册报道
- 账号创建和权限分配
- 补换卡订单处理
- 重要接口调用（客服查询学生信息）

**管控要求**：
```
操作前：
1. 系统内提交操作申请，说明操作原因
2. 主管线上审批（4小时内响应）
3. 系统生成操作确认码

操作中：
1. 输入确认码后才能执行操作
2. 关键字段需要二次确认
3. 操作日志自动记录

操作后：
1. 发送操作完成通知
2. 相关数据自动备份
```

### 1.3 低危操作（记录可查）

**识别标准**：
- 信息查询类操作
- 非关键信息修改
- 日常监控和查看

**具体操作清单**：
- 学生信息查询
- 系统状态查看
- 非敏感信息修改（非特殊数据的普通信息）
- 操作日志查询
- 统计报表生成

**管控要求**：
```
操作中：
1. 记录查询条件和结果
2. 敏感查询自动标记
3. 异常查询行为告警

操作后：
1. 日志保存180天
2. 支持事后审计分析
```

---

## 二、岗位职责与权限边界

### 2.1 家长用户
**可操作范围**：
- 查看自己孩子的基本信息
- 查看孩子的卡状态
- 修改家庭联系方式

**禁止操作**：
- 查看其他学生任何信息
- 修改孩子的关键信息
- 批量操作

### 2.2 学校教师
**可操作范围**：
- 查看、管理本校学生信息
- 新生录入、注册报道
- 修改学生非关键信息（地址、电话）
- 查看本校学生的卡状态

**禁止操作**：
- 查看其他学校学生信息
- 删除学生记录（只能标记状态）
- 批量导出全校数据

### 2.3 客服人员
**可操作范围**：
- 通过身份证/卡号查询学生基本信息（用于补卡）
- 查看和处理补换卡订单
- 查询学生卡状态

**禁止操作**：
- 查看学生成绩、家庭信息等敏感数据
- 修改学生任何信息
- 跨校查询学生信息
- 批量导出学生数据

### 2.4 业务操作员
**角色定义**：学校教师、教务人员等负责日常学生管理的操作人员

**可操作范围**：
- 查看、管理本校学生信息
- 新生录入、注册报道
- 提交特殊敏感数据修改申请（附证明材料）
- 修改学生非特殊敏感数据信息

**禁止操作**：
- 直接修改一级特殊敏感数据
- 查看其他学校学生信息
- 审核自己的操作申请
- 查看操作日志

### 2.5 业务审核员
**角色定义**：校级或教育局负责审核业务变更的管理人员

**可操作范围**：
- 审核特殊敏感数据修改申请
- 验证证明材料真实性
- 批准或驳回操作申请
- 监督业务操作合规性

**禁止操作**：
- 直接修改学生任何信息
- 提交操作申请
- 审核自己的关联申请
- 执行系统操作

### 2.6 系统管理员
**角色定义**：负责服务器和数据库运维的技术人员

**可操作范围**：
- 服务器运维（启停服务、系统更新）
- 数据库维护（备份、优化）
- 应用部署和配置
- 执行经过审批的特殊数据修改脚本
- 用户账号管理（非业务数据）

**禁止操作**：
- 查看证明材料的具体内容
- 直接操作业务数据（除非执行已批准的脚本）
- 查看学生任何信息
- 参与业务审核

### 2.7 技术负责人
**角色定义**：负责技术架构和安全的技术专家

**可操作范围**：
- 复核特殊数据修改的技术可行性
- 评估系统影响和风险
- 制定回滚方案
- 审核系统管理员准备的操作脚本

**禁止操作**：
- 直接执行业务数据修改
- 查看学生敏感信息
- 参与业务审批
- 单独批准操作

### 2.8 日志审计员
**角色定义**：独立的审计人员，负责监督和审计所有操作

**可操作范围**：
- 查看所有操作日志和审计记录
- 设置异常行为监控规则
- 生成安全审计报告
- 发起安全事件调查

**禁止操作**：
- 修改任何业务数据
- 执行任何系统操作
- 查看学生详细信息（只能看操作记录）
- 参与业务操作或审批

### 职责分离控制机制

**角色互斥原则**：
- 同一人不能同时拥有操作权和审核权
- 同一人不能同时拥有审核权和审计权
- 同一人不能同时拥有操作权和审计权
- 系统管理员与业务数据完全隔离

**权限控制矩阵**：

| 操作类型 | 业务操作员 | 业务审核员 | 技术负责人 | 系统管理员 | 日志审计员 |
|----------|------------|------------|------------|------------|------------|
| 申请特殊数据修改 | ✅ | ❌ | ❌ | ❌ | ❌ |
| 审核申请 | ❌ | ✅ | ❌ | ❌ | ❌ |
| 技术复核 | ❌ | ❌ | ✅ | ❌ | ❌ |
| 执行修改 | ❌ | ❌ | ❌ | ✅(双人) | ❌ |
| 查看日志 | ❌ | ❌ | ❌ | ❌ | ✅ |
| 查看业务数据 | ✅(本校) | ✅(审核范围) | ❌ | ❌ | ❌ |

---

## 三、技术控制措施

### 3.1 堡垒机管控规则

**高危命令拦截**：
```bash
# 禁止执行的命令
rm -rf /*
drop database
truncate table
delete from without where clause
shutdown immediate
```

**需要二次确认的命令**：
```bash
# 需要输入确认码
delete from [table_name]
update [table_name] set
drop table
alter table
```

### 3.2 等保三级访问控制粒度

**字段级权限控制**：
```sql
-- 身份证号字段访问控制
CREATE VIEW student_masked_view AS
SELECT
    student_id,
    name,
    -- 仅授权人员可见完整身份证号
    CASE
        WHEN current_user_role() IN ('auditor', 'system_admin') THEN id_card
        WHEN current_user_school_id() = school_id THEN CONCAT(SUBSTRING(id_card, 1, 6), '****', SUBSTRING(id_card, 15, 4))
        ELSE '权限不足'
    END as id_card_display,
    -- 其他字段类似处理
FROM students;

-- 字段级访问策略
CREATE POLICY id_card_access ON students
FOR SELECT USING (
    (current_user_role() = 'auditor') OR
    (current_user_role() = 'system_admin' AND operation_type = 'approved_script') OR
    (current_user_role() = 'business_operator' AND current_user_school_id() = school_id AND has_approval(id_card_update_id))
);
```

**记录级访问控制**：
```sql
-- 本校数据访问控制
CREATE POLICY school_data_isolation ON students
FOR ALL USING (
    -- 系统管理员和审计员无限制
    current_user_role() IN ('system_admin', 'auditor') OR
    -- 业务人员只能访问本校数据
    current_user_school_id() = school_id OR
    -- 客服人员经授权可跨校查询
    (current_user_role() = 'customer_service' AND has_cross_school_auth())
);
```

**时间窗口访问控制**：
```sql
-- 非工作时间访问限制
CREATE POLICY working_hours_access ON students
FOR SELECT USING (
    -- 管理员和审计员全天候访问
    current_user_role() IN ('system_admin', 'auditor') OR
    -- 其他角色仅工作时间访问
    (EXTRACT(HOUR FROM CURRENT_TIME) BETWEEN 7 AND 22 AND
     EXTRACT(DOW FROM CURRENT_DATE) BETWEEN 1 AND 5) OR
    -- 紧急情况需要特殊授权
    has_emergency_access()
);
```

**接口访问控制**：
```json
{
  "endpoint": "/api/student/query",
  "field_access": {
    "all_users": {
      "student_id": "full",
      "name": "full",
      "card_status": "full",
      "school_name": "full"
    },
    "customer_service": {
      "id_card": "masked",
      "phone": "full",
      "address": "masked"
    },
    "external_api": {
      "student_id": "full",
      "card_status": "full"
    }
  },
  "authentication": "2fa_required",
  "audit_level": "full"
}
```

**动态权限分配**：
```sql
-- 基于任务的临时权限
CREATE TEMPORARY TABLE task_permissions (
    user_id VARCHAR(50),
    task_id VARCHAR(50),
    permission_type VARCHAR(50),
    field_list TEXT,
    record_count_limit INTEGER,
    expire_time TIMESTAMP
);

-- 任务完成后自动回收权限
CREATE OR REPLACE FUNCTION cleanup_task_permissions()
RETURNS void AS $$
BEGIN
    DELETE FROM task_permissions
    WHERE expire_time < CURRENT_TIMESTAMP;

    -- 记录权限回收日志
    INSERT INTO permission_cleanup_log
    SELECT user_id, task_id, 'expired', CURRENT_TIMESTAMP
    FROM task_permissions
    WHERE expire_time < CURRENT_TIMESTAMP;
END;
$$ LANGUAGE plpgsql;
```

### 3.3 接口权限控制

**客服网点接口**：
```
POST /api/student/query
参数: id_card OR card_no, reason
返回: [学生基础信息]
权限: 客服角色
审计: 记录查询原因和结果
```

**增效接口**：
```
POST /api/student/status
参数: card_no
返回: [卡状态]
权限: 对部接口
审计: 记录调用次数和频率
```

---

## 四、操作流程和检查表

### 4.1 高危操作检查表

**申请阶段**：
- [ ] 操作目的和影响范围明确
- [ ] 回滚方案制定完成
- [ ] 相关人员已通知
- [ ] 技术负责人已审批
- [ ] 操作时间窗口确认

**操作阶段**：
- [ ] 录屏功能已开启
- [ ] 监督人员已到场
- [ ] 操作步骤与申请单一致
- [ ] 每步操作前口头确认
- [ ] 系统响应正常

**完成阶段**：
- [ ] 操作结果验证成功
- [ ] 监督人员确认
- [ ] 完成记录填写
- [ ] 相关人员确认系统正常

### 4.2 特殊敏感数据修改检查表

**申请阶段检查**：
- [ ] 申请人身份已验证
- [ ] 证明材料真实有效（已核对原件）
- [ ] 证明材料已扫描上传并OCR识别
- [ ] 申请理由充分且符合政策
- [ ] 系统已生成唯一申请编号
- [ ] 申请人已签署承诺书

**初步审核检查**：
- [ ] 业务审核员已确认材料真实性
- [ ] 申请理由正当性已确认
- [ ] 相关利益冲突已排查
- [ ] 审核意见已记录
- [ ] 初审通过后已提交上级审核
- [ ] 审核时间记录完整

**技术复核检查**：
- [ ] 技术负责人已评估修改可行性
- [ ] 系统影响范围已评估
- [ ] 回滚方案已制定并验证
- [ ] 操作脚本已准备
- [ ] 数据备份方案已确认
- [ ] 技术风险已评估

**业务终审检查**：
- [ ] 教育局相关负责人已审批
- [ ] 政策法规符合性已确认
- [ ] 执行时间窗口已确定
- [ ] 相关部门已通知
- [ ] 最终审批文件已归档
- [ ] 审批流程完整性已验证

**双人执行检查**：
- [ ] 系统管理员A和B均已到场
- [ ] 录屏设备工作正常
- [ ] 操作脚本已由B独立审核
- [ ] 原始数据已自动备份
- [ ] 修改操作按计划执行
- [ ] 每步操作都有确认记录

**结果确认检查**：
- [ ] 修改结果已验证正确
- [ ] 申请人已确认修改效果
- [ ] 相关部门已收到修改通知
- [ ] 数据一致性检查已通过
- [ ] 完整操作链路已记录
- [ ] 所有文档已归档

### 4.3 双人确认流程

```
普通操作双人确认流程：
1. 操作人提交申请 → 系统生成确认码
2. 确认人收到确认请求 → 审核操作合理性
3. 确认人输入确认码 → 操作获得执行权限
4. 系统记录操作人和确认人信息
5. 操作执行 → 系统记录详细日志
6. 结果通知 → 相关人员知晓操作结果

特殊数据修改六阶段流程：
申请准备 → 初步审核 → 技术复核 → 业务终审 → 双人执行 → 结果确认
```

---

## 五、审计和监控

### 5.1 等保三级审计日志完整性保护

**必须记录的信息**：
- 操作人员账号和角色
- 操作时间和IP地址
- 操作类型（查询/修改/删除）
- 操作对象（学生ID/表名等）
- 操作结果（成功/失败）
- 对于查询：查询条件和结果数量
- 对于修改：修改前后的值

**等保三级日志完整性保护机制**：

1. **数字签名技术**：
```sql
-- 日志表结构
CREATE TABLE audit_logs (
    log_id BIGSERIAL PRIMARY KEY,
    user_id VARCHAR(50) NOT NULL,
    operation_type VARCHAR(50) NOT NULL,
    operation_time TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
    client_ip INET NOT NULL,
    target_object VARCHAR(100),
    operation_result VARCHAR(20) NOT NULL,
    details JSONB,
    hash_value VARCHAR(64) NOT NULL, -- SHA256哈希值
    digital_signature TEXT, -- 数字签名
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- 数字签名函数
CREATE OR REPLACE FUNCTION sign_audit_log()
RETURNS TRIGGER AS $$
BEGIN
    -- 生成记录的哈希值
    NEW.hash_value = SHA256(NEW.user_id || NEW.operation_type ||
                              NEW.operation_time || NEW.client_ip ||
                              NEW.target_object || NEW.details::TEXT);

    -- 使用私钥进行数字签名
    NEW.digital_signature = sign_data_with_private_key(NEW.hash_value);

    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- 创建触发器
CREATE TRIGGER audit_log_sign_trigger
    BEFORE INSERT ON audit_logs
    FOR EACH ROW EXECUTE FUNCTION sign_audit_log();
```

2. **日志完整性验证**：
```sql
-- 完整性检查函数
CREATE OR REPLACE FUNCTION verify_log_integrity(log_id_param BIGINT)
RETURNS BOOLEAN AS $$
DECLARE
    log_record audit_logs%ROWTYPE;
    computed_hash VARCHAR(64);
    signature_valid BOOLEAN;
BEGIN
    -- 获取原始记录
    SELECT * INTO log_record FROM audit_logs WHERE log_id = log_id_param;

    -- 重新计算哈希值
    computed_hash = SHA256(log_record.user_id || log_record.operation_type ||
                            log_record.operation_time || log_record.client_ip ||
                            log_record.target_object || log_record.details::TEXT);

    -- 验证哈希值是否匹配
    IF log_record.hash_value != computed_hash THEN
        RETURN FALSE;
    END IF;

    -- 验证数字签名
    signature_valid = verify_signature_with_public_key(log_record.hash_value, log_record.digital_signature);

    RETURN signature_valid;
END;
$$ LANGUAGE plpgsql;
```

3. **日志存储保护**：
- **在线存储**：180天，写保护存储
- **归档存储**：1年，WORM（一次写入多次读取）存储
- **异地备份**：实时同步到异地灾备中心
- **加密传输**：日志传输全程加密

**日志保存要求**：
- 在线保存：180天
- 归档保存：1年
- 日志完整性：防篡改保护
- 数字签名：确保真实性和完整性
- 异地备份：防止本地灾难

### 5.2 异常行为监控

**告警规则**：
- 单个账号1小时内查询超过100次
- 非工作时间（22:00-7:00）的操作
- 连续3次密码失败后成功的登录
- 批量操作未审批就执行
- 从非常用IP地址的访问

**处理流程**：
1. 系统自动告警
2. 安全管理员15分钟内响应
3. 评估风险，必要时阻断操作
4. 24小时内完成调查和记录

---

## 六、等保三级数据完整性保护和应急响应

### 6.1 数据完整性保护要求

**等保三级依据**：等保三级要求"应采用必要的技术措施，保证数据在传输、存储、处理过程中的完整性。"

**数据完整性校验机制**：

1. **传输完整性保护**：
```sql
-- 数据传输完整性校验
CREATE OR REPLACE FUNCTION verify_transmission_integrity(
    data_original BYTEA,
    data_received BYTEA,
    checksum_original VARCHAR(64),
    checksum_received VARCHAR(64)
) RETURNS BOOLEAN AS $$
BEGIN
    -- 验证哈希值
    IF checksum_original != checksum_received THEN
        RETURN FALSE;
    END IF;

    -- 重新计算哈希值并验证
    IF SHA256(data_original) != checksum_original THEN
        RETURN FALSE;
    END IF;

    IF SHA256(data_received) != checksum_received THEN
        RETURN FALSE;
    END IF;

    RETURN TRUE;
END;
$$ LANGUAGE plpgsql;
```

2. **存储完整性保护**：
```sql
-- 重要表的完整性约束
ALTER TABLE students
ADD CONSTRAINT chk_id_card_format
CHECK (id_card ~ '^[1-9]\d{16}(19\d)?$');

ALTER TABLE students
ADD CONSTRAINT chk_phone_format
CHECK (phone ~ '^1[3-9]\d{9}$');

-- 数据校验触发器
CREATE OR REPLACE FUNCTION validate_student_data()
RETURNS TRIGGER AS $$
BEGIN
    -- 验证身份证号格式
    IF NEW.id_card IS NOT NULL AND NEW.id_card !~ '^[1-9]\d{16}(19\d)?$' THEN
        RAISE EXCEPTION '身份证号格式错误';
    END IF;

    -- 验证手机号格式
    IF NEW.phone IS NOT NULL AND NEW.phone !~ '^1[3-9]\d{9}$' THEN
        RAISE EXCEPTION '手机号格式错误';
    END IF;

    -- 记录完整性检查日志
    INSERT INTO data_integrity_log
    VALUES (NEW.student_id, 'VALIDATE', NEW.id_card || '|' || NEW.phone, CURRENT_TIMESTAMP);

    RETURN NEW;
END;
$$ LANGUAGE plpgsql;
```

3. **定期完整性检查**：
```sql
-- 每日自动完整性检查
CREATE OR REPLACE FUNCTION daily_integrity_check()
RETURNS void AS $$
DECLARE
    inconsistency_count INTEGER;
BEGIN
    -- 检查数据一致性
    SELECT COUNT(*) INTO inconsistency_count
    FROM (
        SELECT s.id_card, COUNT(*) as cnt
        FROM students s
        WHERE s.id_card IS NOT NULL
        GROUP BY s.id_card
        HAVING COUNT(*) > 1
    ) AS duplicates;

    -- 发现不一致时记录告警
    IF inconsistency_count > 0 THEN
        INSERT INTO integrity_alerts
        VALUES ('DATA_DUPLICATE', inconsistency_count, CURRENT_TIMESTAMP);

        -- 通知安全管理员
        INSERT INTO security_notifications
        VALUES ('SYSTEM_ADMIN', 'DATA_INTEGRITY_ALERT',
                '发现学生身份证号重复数据', CURRENT_TIMESTAMP);
    END IF;

    -- 检查关键字段完整性
    INSERT INTO integrity_report
    SELECT
        'MISSING_ID_CARD' as issue_type,
        COUNT(*) as count,
        CURRENT_TIMESTAMP as check_time
    FROM students
    WHERE id_card IS NULL OR id_card = '';

    -- 检查数据格式异常
    INSERT INTO integrity_report
    SELECT
        'INVALID_PHONE_FORMAT' as issue_type,
        COUNT(*) as count,
        CURRENT_TIMESTAMP as check_time
    FROM students
    WHERE phone !~ '^1[3-9]\d{9}$' AND phone IS NOT NULL;
END;
$$ LANGUAGE plpgsql;

-- 创建每日执行任务
SELECT cron.schedule('daily-integrity-check', '0 2 * * *', 'SELECT daily_integrity_check()');
```

### 6.2 数据完整性应急处理流程

**完整性破坏应急响应**：

1. **立即响应（15分钟内）**：
   - 暂停相关数据访问
   - 保护原始数据不被进一步破坏
   - 通知应急响应小组

2. **损害评估（2小时内）**：
   - 确定破坏范围和影响
   - 分析破坏原因和方式
   - 评估对业务的影响程度

3. **数据恢复（4小时内）**：
   - 从备份恢复被破坏的数据
   - 验证恢复数据的完整性
   - 重新建立完整性保护机制

4. **根因分析（24小时内）**：
   - 调查完整性破坏的根本原因
   - 修复相关的安全漏洞
   - 加强相关的防护措施

### 6.3 安全事件分级

**一般事件**：
- 单个账号异常登录
- 小范围查询异常
- 不影响系统正常运行
- 数据完整性轻微影响

**较大事件**：
- 批量数据泄露风险
- 系统性能受影响
- 可能影响多个用户
- 数据完整性部分破坏

**重大事件**：
- 数据确认泄露
- 系统宕机或严重异常
- 涉及大量用户数据
- 数据完整性严重破坏

### 6.2 应急联系人

| 角色 | 姓名 | 电话 | 备注 |
|------|------|------|------|
| 应急总指挥 | [姓名] | [电话] | 负责总体协调 |
| 技术负责人 | [姓名] | [电话] | 负责技术处置 |
| 安全负责人 | [姓名] | [电话] | 负责安全评估 |
| 业务负责人 | [姓名] | [电话] | 负责业务协调 |

---

## 七、培训和考核

### 7.1 必须培训内容

**新员工入职培训**：
- 本手册内容和操作规范
- 高危操作流程和双人确认机制
- 应急响应流程和联系方式

**年度复训**：
- 安全事件案例分析
- 操作规范更新内容
- 模拟应急演练

### 7.2 考核要求

- 每年进行1次操作规范考试
- 每半年进行1次应急演练
- 不合格人员重新培训，直至合格

---

## 附录

### 附录A：高危操作申请单模板

```
申请单编号: [自动生成]
申请时间: YYYY-MM-DD HH:MM
申请人: [姓名]
所在部门: [部门]
联系电话: [电话]

操作类型: [批量导入/批量删除/系统变更等]
操作目的: [详细说明操作目的]
影响范围: [影响的人数/系统范围]

操作步骤: [详细的操作步骤]
回滚方案: [详细的回滚方案]

风险评估: [可能存在的风险]
预防措施: [如何避免风险]

申请人签字: _________ 日期: _________
技术负责人审批: _________ 日期: _________
安全管理员审核: _________ 日期: _________
```

### 附录B：现场操作记录单模板

```
记录单编号: [自动生成]
操作时间: YYYY-MM-DD HH:MM
操作地点: [机房/办公室等]
操作内容: [具体操作内容]

操作人员: [姓名] 工号: [工号]
监督人员: [姓名] 工号: [工号]

操作步骤记录:
1. [时间] [操作内容] [结果]
2. [时间] [操作内容] [结果]
...

操作结果: [成功/失败]
发现异常: [如果有异常，详细记录]

操作人员签字: _________
监督人员签字: _________
日期: _________
```

### 附录C：权限申请审批表

```
申请编号: [自动生成]
申请人: [姓名]
所属部门: [部门]
申请岗位: [岗位]
申请原因: [详细说明]

所需权限:
- [ ] 查看权限：[具体内容]
- [ ] 修改权限：[具体内容]
- [ ] 删除权限：[具体内容]
- [ ] 其他权限：[具体内容]

权限期限: [永久/临时，写明截止时间]

申请人签字: _________ 日期: _________
部门主管审批: _________ 日期: _________
安全管理员审核: _________ 日期: _________
负责人批准: _________ 日期: _________
```

### 附录D：特殊敏感数据修改申请单

```
申请单编号: [自动生成]
申请时间: YYYY-MM-DD HH:MM
申请人: [姓名]
所在学校/单位: [学校/单位全称]
联系电话: [电话]
学生姓名: [学生姓名]
学生学号: [学号]

申请修改的数据类型（勾选）：
□ 一级特殊敏感数据
  □ 身份证号 (变更原因: [请填写])
  □ 学生姓名 (变更原因: [请填写])
  □ 学籍号 (变更原因: [请填写])
  □ 户籍信息 (变更原因: [请填写])
  □ 特殊身份标记 (变更原因: [请填写])

□ 二级特殊敏感数据
  □ 家庭详细住址 (变更原因: [请填写])
  □ 监护人联系方式 (变更原因: [请填写])
  □ 学生照片 (变更原因: [请填写])
  □ 学籍状态变更 (变更原因: [请填写])
  □ 奖惩记录 (变更原因: [请填写])

修改前数据: [请填写原始数据]
修改后数据: [请填写新数据]

申请理由详细说明: [详细说明修改原因和依据]

证明材料清单:
1. [材料名称] - [原件已核对□] - [已扫描上传□]
2. [材料名称] - [原件已核对□] - [已扫描上传□]
3. [材料名称] - [原件已核对□] - [已扫描上传□]

申请人承诺:
本人承诺以上所提供的信息和材料真实有效，如有虚假，愿意承担相应法律责任。

申请人签字: _________ 日期: _________
学校负责人审核: _________ 日期: _________

=== 初步审核意见 ===
审核人: [姓名]
审核时间: YYYY-MM-DD HH:MM
材料真实性: [通过/不通过] - [详细说明]
申请正当性: [通过/不通过] - [详细说明]
审核结论: [同意提交/驳回申请]
审核人签字: _________

=== 技术复核意见 ===
技术负责人: [姓名]
复核时间: YYYY-MM-DD HH:MM
技术可行性: [可行/不可行] - [详细说明]
系统影响评估: [影响范围和程度]
回滚方案: [已制定/未制定]
复核结论: [同意执行/需要补充/不同意]
技术负责人签字: _________

=== 业务终审意见 ===
终审人: [姓名/职务]
终审时间: YYYY-MM-DD HH:MM
政策符合性: [符合/不符合] - [依据说明]
最终结论: [批准执行/驳回申请]
执行时间窗口: [建议执行时间]
终审人签字: _________ 职务: _________

=== 执行记录 ===
执行人A: [姓名] 工号: [工号]
执行人B: [姓名] 工号: [工号]
执行时间: YYYY-MM-DD HH:MM
操作脚本编号: [脚本编号]
执行结果: [成功/失败]
数据备份确认: [已确认]
执行人A签字: _________
执行人B签字: _________

=== 结果确认 ===
申请人确认: [修改正确□/有错误□] 确认人: _________ 日期: _________
数据一致性检查: [通过□/未通过□] 检查人: _________ 日期: _________
相关部门通知: [已完成□] 通知时间: _________
日志审计员确认: [操作链路完整□] 审计员: _________ 日期: _________
```

### 附录E：特殊数据修改证明材料要求

**身份证号修改所需材料**：
- 公安部门出具的户籍变更证明原件
- 学生户口本复印件（含变更页）
- 学生本人或监护人身份证复印件
- 学校出具的变更申请说明（加盖公章）

**姓名修改所需材料**：
- 公安部门出具的姓名变更证明原件
- 户口本复印件（含变更页）
- 学校出具的姓名变更说明（加盖公章）
- 如有学籍号变更需教育局相关文件

**学籍号修改所需材料**：
- 教育局出具的学籍号变更文件原件
- 学校学籍管理部门的变更申请
- 相关政策依据文件
- 变更原因的详细说明

**户籍信息修改所需材料**：
- 公安部门出具的户籍变更证明
- 户口本复印件（含变更页）
- 家庭关系证明材料
- 学校审核确认文件

**特殊身份标记修改所需材料**：
- 相关政府部门出具的认定文件
- 医疗证明（如残疾认定）
- 民政部门证明（如贫困认定）
- 学校相关部门审核意见

**证明材料要求**：
- 所有材料必须提供原件供核对
- 复印件必须加盖出具单位公章
- 境外材料需提供翻译件和公证
- 电子版材料必须为清晰扫描件
- 材料有效期必须在申请有效期内

---

**本手册自发布之日起执行，由数据安全管理领导小组负责解释和修订。**