第二章:账户安全与认证——多因素认证、API密钥管理与权限模型

账户安全,说白了就是交易系统的第一道门。我见过太多团队把精力花在业务逻辑上,结果被一个弱口令直接打穿。今天咱们聊聊怎么把这扇门焊死。

2.1 多因素认证(MFA)实现方案

MFA不是新鲜概念,但落地时坑特别多。我个人习惯把认证因素分成三类:你知道的(密码)、你拥有的(手机/硬件Key)、你是什么(指纹/人脸)。交易系统至少要用两种。

核心原则:任何单一因素被攻破,系统依然安全。

2.1.1 TOTP(基于时间的一次性密码)

这是最常用的方案。我建议用Google Authenticator或Authy。实现时注意三点:

  • 时钟同步:服务器和客户端时间差不能超过30秒
  • 密钥存储:服务端存Base32编码的密钥,客户端存二维码
  • 防重放:每个TOTP只能使用一次,用后立即失效
// TOTP生成示例(Java)
public String generateTOTP(String secretKey) {
    long timeSlice = System.currentTimeMillis() / 30000;
    byte[] key = Base32.decode(secretKey);
    byte[] data = ByteBuffer.allocate(8).putLong(timeSlice).array();
    byte[] hash = HmacSHA1(key, data);
    int offset = hash[hash.length - 1] & 0x0F;
    int binary = ((hash[offset] & 0x7F) << 24) |
                 ((hash[offset + 1] & 0xFF) << 16) |
                 ((hash[offset + 2] & 0xFF) << 8) |
                 (hash[offset + 3] & 0xFF);
    int otp = binary % 1000000;
    return String.format("%06d", otp);
}

避坑指南:我曾经遇到一个项目,TOTP验证总是失败。查了半天发现是服务器时间漂移了。后来加了NTP自动同步,再也没出过问题。

2.1.2 短信/邮件验证码

虽然方便,但安全性不如TOTP。短信可能被拦截,邮件可能被钓鱼。我建议只作为备用方案,或者用于低风险操作。

2.2 API密钥管理与轮换策略

API密钥是系统间通信的凭证。你想想看,如果密钥泄露了,攻击者就能冒充你的系统做任何操作。所以管理必须严格。

2.2.1 密钥生成与存储

  • 使用加密安全的随机数生成器(如SecureRandom)
  • 密钥长度至少256位
  • 存储时加密,数据库字段加密存储
  • 永远不要硬编码在代码里

2.2.2 轮换策略

我个人习惯每90天强制轮换一次。但要注意平滑过渡:

  1. 生成新密钥,标记为“待激活”
  2. 旧密钥和新密钥同时生效24小时
  3. 客户端切换到新密钥后,旧密钥标记为“过期”
  4. 再过7天,彻底删除旧密钥

注意:轮换期间一定要有监控。我曾经见过一个系统,轮换时没通知下游,结果所有API调用都失败了。嗯,那次事故让我学会了“先通知,再操作”。

2.3 会话管理与单点登录(SSO)集成

交易系统通常有多个子系统:交易终端、风控后台、清算系统。每个系统都登录一遍?太麻烦了。SSO就是解决这个问题的。

2.3.1 会话管理要点

  • 会话ID必须随机且不可预测
  • 设置合理的超时时间:交易系统建议15分钟无操作自动退出
  • 支持会话撤销:用户主动退出或管理员强制下线
  • 防止会话固定攻击:登录成功后重新生成会话ID

2.3.2 SSO集成方案

我推荐用OAuth 2.0 + OpenID Connect。流程是这样的:

  1. 用户访问子系统A,未登录
  2. 子系统A重定向到SSO服务器
  3. 用户输入凭证,SSO服务器验证
  4. SSO服务器返回授权码
  5. 子系统A用授权码换取令牌
  6. 子系统A用令牌访问用户信息

关键点:令牌一定要用JWT格式,包含用户ID、角色、过期时间。签名用RS256,私钥妥善保管。

2.4 权限分级模型(RBAC/ABAC)

权限模型决定了谁能做什么。交易系统里,权限搞错了就是真金白银的损失。

2.4.1 RBAC(基于角色的访问控制)

这是最经典的模型。我习惯这样设计:

角色 权限 适用场景
交易员 下单、撤单、查看持仓 日常交易操作
风控员 查看风控规则、调整限额 风险监控与干预
管理员 用户管理、系统配置 系统运维
审计员 查看日志、导出报表 合规审计

2.4.2 ABAC(基于属性的访问控制)

RBAC不够灵活时,用ABAC。比如:交易员只能操作自己名下的账户,金额超过100万需要风控员审批。这些用RBAC很难表达,但ABAC可以:

// ABAC策略示例
{
  "effect": "deny",
  "condition": {
    "user.role": "trader",
    "transaction.amount": { "gt": 1000000 },
    "approval.status": { "ne": "approved" }
  }
}

我的经验:大部分系统用RBAC就够了。ABAC虽然灵活,但策略多了容易混乱。我建议先上RBAC,等确实需要细粒度控制时再引入ABAC。

知识体系总览

下面这张图展示了账户安全与认证的核心逻辑。你可以看到,从用户登录到权限校验,每一步都有对应的防护措施。

账户安全与认证体系 第一层:认证(你是谁?) 密码 TOTP 短信验证码 生物特征 多因素认证(MFA)至少使用两种 第二层:会话管理(你持续在线吗?) 会话ID 超时策略 SSO集成 会话撤销 OAuth 2.0 + OpenID Connect 第三层:授权(你能做什么?) RBAC(基于角色) ABAC(基于属性) 权限分级 最小权限原则 API密钥管理:生成 → 存储 → 轮换 → 销毁

这套体系环环相扣。认证解决“你是谁”,会话解决“你还在吗”,授权解决“你能做什么”,密钥管理解决“系统间怎么信任”。少一个环节,整个安全体系就有漏洞。

最后提醒:安全不是一次性工作。定期审计权限、检查密钥轮换情况、测试MFA有效性。我每个季度都会做一次安全自查,雷打不动。

公众号:蓝海资料掘金营,微信deep3321