4、请求验证与身份核验：身份验证的合规要求、多因素验证方案、防止冒用与欺诈

好，咱们进入第四讲。这一章非常关键，说白了就是「你怎么确认来要数据的人，真的是他本人？」。我见过太多公司，合规制度写得漂漂亮亮，结果在身份核验这一步漏了风，最后被罚得底裤都不剩。

你想想看，GDPR、个保法都明确要求：数据控制者有义务验证请求者的身份。这不是走形式，是真刀真枪的合规防线。如果随便一个人发封邮件说「我要删除张三的数据」，你就真删了，那麻烦就大了。

4.1 身份验证的合规要求

合规要求其实就三条线，我给大家拆开讲：

合规维度	具体要求	我踩过的坑
必要性原则	只收集验证身份所必需的信息，别趁机多要	有次客户要求上传身份证正反面+手持视频，被监管点名了
比例原则	验证强度与数据风险匹配。查个联系方式，别搞人脸识别	我习惯按数据分级来定验证等级，省事又合规
最小留存原则	验证完成后，立即删除验证材料	曾经有公司把身份证扫描件存了三年，直接触发处罚

嗯，这里要注意：你不能因为验证身份，反而制造了新的数据安全风险。比如你让用户上传身份证，结果你的服务器被拖库了，那责任还是你的。

4.2 多因素验证方案

我个人习惯把验证方案分成三个等级，对应不同的数据敏感度：

4.2.1 基础验证（L1）

适用于查询、更正等低风险操作。说白了就是「能对上号就行」。

• 注册手机号验证：发送验证码
• 注册邮箱验证：发送确认链接
• 历史订单信息核对：比如「您最近一笔订单的金额是多少？」

我在项目中遇到过，有些用户手机号早换了，这时候你得准备备用验证通道。别一根筋只认手机号。

4.2.2 中级验证（L2）

适用于删除、导出等中等风险操作。需要两个以上独立因素。

• 因素1：你知道的（密码、PIN码）
• 因素2：你拥有的（手机、硬件令牌）
• 因素3：你本身的（指纹、面部识别）

举个例子：用户要导出全部数据。我建议的做法是——先发验证码到绑定手机，再要求用户回答一个只有他知道的问题（比如「您注册时填写的备用邮箱是什么？」）。

4.2.3 高级验证（L3）

适用于涉及敏感数据（生物识别、金融信息、医疗数据）的操作。

• 视频核身：人工或AI比对
• 线下核验：要求本人到场，出示身份证原件
• 第三方认证：通过国家政务服务平台等权威渠道

为什么会用到这么重的方案？因为敏感数据一旦泄露，后果是灾难性的。我曾经处理过一个医疗数据泄露事件，就是因为身份验证只用了邮箱验证，结果黑客盗了邮箱就拿到了全部病历。

4.3 防止冒用与欺诈

这一块是实战中的硬骨头。冒用身份的手段层出不穷，我给大家总结几个高频场景和应对方案：

4.3.1 常见的冒用手段

冒用方式	典型特征	我的应对建议
撞库攻击	用其他平台泄露的密码尝试登录	强制启用多因素认证，别只靠密码
社会工程学	冒充客服套取验证信息	建立内部验证机制，客服不能直接修改用户信息
伪造证件	PS身份证、伪造授权书	引入活体检测，静态图片一律不认
内部人员作案	员工利用权限冒用用户身份	操作日志审计，敏感操作双人复核

4.3.2 防冒用的技术手段

嗯，这里我直接给代码级的建议。虽然不要求大家手写，但理解原理很重要：

// 伪代码：风险评分引擎示例
function riskAssessment(request) {
  let score = 0;
  
  // 设备指纹异常
  if (request.deviceFingerprint !== user.knownDevices) {
    score += 30;
  }
  
  // 地理位置突变
  if (geoDistance(request.ipLocation, user.lastLoginLocation) > 500) {
    score += 20;
  }
  
  // 操作行为异常
  if (request.action === 'delete_all' && user.accountAge < 7) {
    score += 40;  // 新账号要求删除全部数据，高度可疑
  }
  
  // 时间异常
  if (request.time between '02:00' and '05:00') {
    score += 10;
  }
  
  return score;
}

// 风险等级判定
if (score > 70) {
  blockRequest();  // 直接拦截
} else if (score > 40) {
  requireAdditionalVerification();  // 要求额外验证
} else {
  proceedWithStandardVerification();  // 标准流程
}

这个评分模型是我在项目中反复调优过的。核心思路是：不要等出了问题再补救，要在请求阶段就识别风险。

4.3.3 避坑指南

我曾经犯过一个低级错误，分享出来大家引以为戒：

• 别把验证结果缓存太久。 有次我为了性能优化，把用户验证结果缓存了24小时。结果用户手机丢了，黑客拿着缓存的token为所欲为。
• 别忽略「静默验证」。 用户可能没意识到，但后台要默默做设备指纹比对、行为分析。我习惯把这些信息记录在审计日志里，万一出事有迹可循。
• 别一刀切拒绝所有异常请求。 有些用户就是出差了、换手机了。我建议设置「人工复核通道」，让客服介入处理。

好，这一章就到这里。下一章我们聊聊「响应时限与流程管理」，说白了就是怎么在规定时间内把事儿办完，还不出错。到时候见。