在参与深圳大学教育数据管理项目时，发现部分学生个人信息（如身份证号、家庭住址）未加密存储，违反《个人信息保护法》。请描述处理过程：1）如何识别数据泄露风险；2）如何制定数据加密方案（如字段级加密、传输加密）；3）如何与教务处、信息中心沟通，推动合规整改；4）如何验证整改效果（如数据脱敏测试、安全审计）。
答案
1) 【一句话结论】在项目中，通过技术扫描+流程审计识别数据泄露风险，制定字段级（如身份证AES-256加密）与传输级（TLS）加密方案，跨部门沟通推动整改，通过脱敏测试与安全审计验证效果，确保数据合规存储。
2) 【原理/概念讲解】
数据泄露风险识别类似“找漏”过程：用静态数据扫描工具（如数据库审计工具）检查未加密字段（如“学生信息”表的“身份证号”字段），或通过流程审计（查看数据存储逻辑文档）发现未加密环节。
字段级加密：针对敏感字段单独加密（如身份证号用AES-256算法），密钥由密钥管理系统管理，解密仅授权用户访问（类比：给每个敏感字段“上锁”，钥匙仅授权人持有）。
传输加密：用TLS协议保障数据传输安全（类比：给数据“穿防护服”，防止传输中被窃取）。
《个人信息保护法》依据：依据第二十八条“处理敏感个人信息需采取加密等安全措施”，未加密属于违规。
3) 【对比与适用场景】
| 方式 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 字段级加密 | 对数据库敏感字段单独加密 | 数据静态存储安全 | 教育数据中身份证、住址等敏感字段 | 密钥管理复杂，需密钥管理系统 |
| 传输加密 | 数据传输过程加密 | 防止传输中窃取 | 数据传输（如学生信息上传至服务器） | 需配置TLS证书，确保传输安全 |
4) 【示例】
假设数据库表“学生信息”包含“身份证号”“家庭住址”字段。通过SQL扫描工具检查，发现“身份证号”字段未加密。配置字段级加密：使用AES-256算法，密钥由KMS管理，修改表结构添加加密列（如“身份证号加密”），并更新业务逻辑（仅授权用户解密）。传输时，通过Spring Boot配置TLS，确保数据传输安全。
5) 【面试口播版答案】
在参与深圳大学教育数据管理项目时，我首先通过静态数据扫描工具（如数据库审计工具）和流程审计，识别出“学生信息”表中身份证号、家庭住址等敏感字段未加密存储，属于违反《个人信息保护法》的风险点。接着制定加密方案：对身份证号等敏感字段采用字段级AES-256加密，密钥由密钥管理系统统一管理；数据传输时启用TLS协议保障传输安全。然后与教务处、信息中心沟通：向教务处说明风险及合规要求，提出加密方案；与信息中心协作，由其负责技术实施，我提供业务需求与合规指导。最后验证整改效果：组织数据脱敏测试（模拟解密过程，确保仅授权用户能访问），并配合安全审计（检查数据库访问日志、加密配置），确认整改符合要求。
6) 【追问清单】
- 问：你识别风险时具体用了什么工具？答：用了数据库审计工具（如SQL Server Audit或自定义脚本）扫描未加密字段，同时结合流程审计（查看数据存储逻辑文档）。
- 问：加密方案中密钥管理怎么做？答：密钥由密钥管理系统（如AWS KMS或自建KMS）管理，定期轮换，仅授权用户访问。
- 问：与教务处沟通时遇到什么困难？答：教务处担心加密影响业务效率，我解释了加密对合规的重要性，并承诺优化解密流程，最终达成共识。
- 问：验证整改效果时，脱敏测试具体怎么做？答：模拟正常业务场景，授权用户尝试访问加密字段，验证解密逻辑正确，且未授权用户无法访问。
7) 【常见坑/雷区】
- 坑1：只说加密而不提密钥管理，被问密钥如何保护时答不上来。
- 坑2：沟通时只提问题不提解决方案，显得被动。
- 坑3：验证时只说测试而不提审计，显得验证不全面。
- 坑4：忽略《个人信息保护法》的具体条款，比如未提及第二十八条关于存储安全的要求。
- 坑5：加密方案过于复杂，未结合实际业务场景，显得不实用。