卡密安全管理：从加密存储到防刷防泄露

卡密是发卡系统的核心资产——一旦泄露或丢失，直接就是经济损失。本文从四个维度分享卡密安全管理的实战经验。

# 一、加密存储

卡密不能明文存储，这是底线。

# 加密方案对比

HmwCard 使用 AES-256-GCM 加密卡密：

• 加密密钥（ENCRYPTION_KEY）独立于数据库存储
• 每个卡密加密时使用随机 IV（初始化向量）
• 数据库泄露没有密钥也无法解密

# 密钥管理

# 生成 32 字节（256 位）随机密钥
openssl rand -hex 32

将生成的密钥写入 backend/.env：

ENCRYPTION_KEY=生成的32字节hex字符串

关键：密钥一旦生成，不要更换。更换密钥会导致所有已加密卡密无法解密。

# 二、访问控制

# 数据库层面

-- 只有应用账号能读写卡密表
GRANT SELECT, INSERT, UPDATE ON hmwcard.card_secrets TO 'hmwcard'@'%';
REVOKE DELETE ON hmwcard.card_secrets FROM 'hmwcard'@'%';

应用层通过 Prisma ORM 访问，不直接暴露 SQL 接口。

# API 层面

• 卡密列表 API 需要管理员认证（HttpOnly Cookie）
• 卡密内容在 API 返回时部分脱敏
• 单次查询有数量限制，防止批量导出

# 日志层面

// 日志中卡密自动脱敏
function sanitizeLogInput(input: string): string {
  // 卡密字段替换为 ****
  return input.replace(/secret['":\s]+['"]?([A-Za-z0-9-]{4})[^'"]*/gi, 'secret": "****$1..."');
}

# 三、防刷机制

# 1. 接口限流

HmwCard 内置多层限流：

# 2. 订单创建防护

• 同一商品短时间大量下单 → 触发风控
• 同 IP 多账号下单 → 标记审核
• 新注册账号大额购买 → 强制审核

# 3. 卡密发放防护

-- 使用 SELECT FOR UPDATE 行级锁
BEGIN;
SELECT * FROM card_secrets 
WHERE product_id = ? AND is_used = FALSE 
ORDER BY id ASC LIMIT 1 FOR UPDATE;

UPDATE card_secrets SET is_used = TRUE, used_at = NOW(), order_id = ? WHERE id = ?;
COMMIT;

数据库事务 + 行级锁确保同一张卡密不会被发放两次。

# 4. 登录防护

• 连续失败 5 次 → 锁定 15 分钟
• 连续失败 10 次 → 锁定 1 小时
• 锁定状态存储在 Redis，重启不丢失

# 四、泄露应急响应

# 发现卡密泄露怎么办

1. 确认泄露范围：哪些卡密、通过什么渠道泄露
2. 立即止损：暂停相关商品的销售
3. 更换密钥：如果是加密密钥泄露，立即更换（需重新加密所有卡密）
4. 通知用户：如果卡密已被使用，联系受影响用户
5. 加固防护：分析泄露原因，修复漏洞

# 更换加密密钥

# 1. 生成新密钥
openssl rand -hex 32

# 2. 使用旧密钥解密所有卡密
# 3. 使用新密钥重新加密
# 4. 更新 ENCRYPTION_KEY
# 5. 重启后端

这是一个危险操作，建议在维护窗口进行，操作前务必备份。

# 五、最佳实践

# 日常运维

• [ ] 每周检查异常登录记录
• [ ] 每月审查管理员操作日志
• [ ] 每季度轮换 API 密钥
• [ ] 每半年进行安全审计

# 开发规范

• 不要在日志中打印明文卡密
• 不要在 URL 参数中传递卡密
• API 返回的卡密要部分脱敏
• 数据库备份文件要加密存储

# 服务器安全

• 数据库端口不对外开放
• 定期更新系统和依赖
• 使用防火墙限制来源 IP
• 启用 fail2ban 防止暴力破解

# 写在最后

卡密安全不是一次性的工作，是持续的过程。加密存储是基础，访问控制是核心，防刷机制是保障，应急响应是底线。

没有绝对的安全，但做好这四层防护，被攻破的概率已经极低。

相关文章：卖虚拟商品被退款薅羊毛怎么办