maxwell/note

Fork 0

imac-maxwell b655fbadb3 init

2025-11-19 10:16:05 +08:00

32 KiB

Raw Permalink Blame History

苏州教育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小时内响应）
制定操作回滚方案
通知相关人员操作时间窗口

操作过程中：

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

操作完成后：

验证操作结果
监督员确认操作成功
填写《高危操作完成记录》
相关人员确认系统正常


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

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

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

**管控要求**：

操作前：

系统内提交操作申请，说明操作原因
主管线上审批（4小时内响应）
系统生成操作确认码

操作中：

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

操作后：

发送操作完成通知
相关数据自动备份


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

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

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

**管控要求**：

操作中：

记录查询条件和结果
敏感查询自动标记
异常查询行为告警

操作后：

日志保存180天
支持事后审计分析


---

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

### 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

需要二次确认的命令：

# 需要输入确认码
delete from [table_name]
update [table_name] set
drop table
alter table

3.2 等保三级访问控制粒度

字段级权限控制：

-- 身份证号字段访问控制
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))
);

记录级访问控制：

-- 本校数据访问控制
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())
);

时间窗口访问控制：

-- 非工作时间访问限制
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()
);

接口访问控制：

{
  "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"
}

动态权限分配：

-- 基于任务的临时权限
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/表名等）
操作结果（成功/失败）
对于查询：查询条件和结果数量
对于修改：修改前后的值

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

数字签名技术：

-- 日志表结构
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();

日志完整性验证：

-- 完整性检查函数
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;

日志存储保护：

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

日志保存要求：

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

5.2 异常行为监控

告警规则：

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

处理流程：

系统自动告警
安全管理员15分钟内响应
评估风险，必要时阻断操作
24小时内完成调查和记录

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

6.1 数据完整性保护要求

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

数据完整性校验机制：

传输完整性保护：

-- 数据传输完整性校验
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;

存储完整性保护：

-- 重要表的完整性约束
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;

定期完整性检查：

-- 每日自动完整性检查
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 数据完整性应急处理流程

完整性破坏应急响应：

立即响应（15分钟内）：
- 暂停相关数据访问
- 保护原始数据不被进一步破坏
- 通知应急响应小组
损害评估（2小时内）：
- 确定破坏范围和影响
- 分析破坏原因和方式
- 评估对业务的影响程度
数据恢复（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：特殊数据修改证明材料要求

身份证号修改所需材料：

公安部门出具的户籍变更证明原件
学生户口本复印件（含变更页）
学生本人或监护人身份证复印件
学校出具的变更申请说明（加盖公章）

姓名修改所需材料：

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

学籍号修改所需材料：

教育局出具的学籍号变更文件原件
学校学籍管理部门的变更申请
相关政策依据文件
变更原因的详细说明

户籍信息修改所需材料：

公安部门出具的户籍变更证明
户口本复印件（含变更页）
家庭关系证明材料
学校审核确认文件

特殊身份标记修改所需材料：

相关政府部门出具的认定文件
医疗证明（如残疾认定）
民政部门证明（如贫困认定）
学校相关部门审核意见

证明材料要求：

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

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

32 KiB Raw Permalink Blame History Unescape Escape

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

前言

一、操作风险分级体系

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

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

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

1.4 四级操作（数据查询）

1.5 五级操作（只读查看）

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

2.1 双因素认证应用场景

2.2 会话管理要求

2.3 密码策略

3.2 等保三级访问控制粒度

3.3 接口权限控制

四、操作流程和检查表

4.1 高危操作检查表

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

4.3 双人确认流程

五、审计和监控

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

5.2 异常行为监控

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

6.1 数据完整性保护要求

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

6.3 安全事件分级

6.2 应急联系人

七、培训和考核

7.1 必须培训内容

7.2 考核要求

附录

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

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

附录C：权限申请审批表

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

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

32 KiB

Raw Permalink Blame History