英雄联盟卡盟卡密数据库安全存储方案：AES-256-GCM 加密与库存防泄漏数据库设计规范

一、 卡密数据库明文存储的致命威胁与合规要求

许多开源发卡系统在设计卡密表（`cards`）时，简单粗暴地将激活码字段设置为 `VARCHAR(255)` 并明文写入。这种做法在网络安全层面存在巨大的单点崩溃风险：

1. **SQL 注入漏洞致灾**：如果前端搜索或后台筛选存在未参数化查询的注入点，攻击者通过简单的 `UNION SELECT` 即可一次性将整库卡密全部拖取；

2. **数据库备份文件外泄**：运维自动化备份脚本生成的 `.sql.gz` 文件若被放置在 Web 可访问目录，或被未授权下载，明文数据立即公开；

3. **运维与数据库管理员内鬼风险**：直接接触生产数据库的人员可随意导出资产。

现代安全标准要求：核心机密资产必须实行“入库即加密、出库即销毁、密钥与数据物理分离”。

# Python 实装基于 AES-256-GCM 的卡密安全加密与解密模块
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

class CardCryptoEngine:
    def __init__(self, master_key_bytes: bytes):
        # 必须确保 master_key 为高强度 32 字节 (256-bit) 密钥
        self.aesgcm = AESGCM(master_key_bytes)
        
    def encrypt_card(self, plain_card: str) -> str:
        # 生成 12 字节随机动态初始化向量 (IV/Nonce)
        nonce = os.urandom(12)
        encrypted_bytes = self.aesgcm.encrypt(nonce, plain_card.encode('utf-8'), None)
        # 将 IV 与密文拼接后转换为 Hex 存储
        return (nonce + encrypted_bytes).hex()
        
    def decrypt_card(self, hex_payload: str) -> str:
        raw_data = bytes.fromhex(hex_payload)
        nonce = raw_data[:12]
        ciphertext = raw_data[12:]
        decrypted_bytes = self.aesgcm.decrypt(nonce, ciphertext, None)
        return decrypted_bytes.decode('utf-8')

二、 数据库表结构优化与物理密钥分离体系

在实施 AES-256-GCM 加密时，解密密钥绝不能硬编码在代码或直接存储在 MySQL 配置表中。

生产环境必须推行密钥管理系统（KMS）架构：

- 数据库只保存经过主密钥加密后的密文字符串（`encrypted_content`）与对应密钥版本号（`key_version`）；

- 密钥由独立的宿主机环境变量或哈希环（Vault）动态载入内存；

- 当发生卡密提取请求时，业务模块动态拉取密钥解密并下发，在内存中完成渲染后立即清除明文变量。

-- 生产级高安全发卡数据表设计样例
CREATE TABLE `matrix_cards_vault` (
  `card_id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  `sku_code` VARCHAR(64) NOT NULL,
  `card_ciphertext` TEXT NOT NULL COMMENT 'AES-256-GCM 加密后的卡密数据',
  `card_status` TINYINT NOT NULL DEFAULT 0 COMMENT '0-在售 1-已提取 2-已冻结',
  `key_version` VARCHAR(16) NOT NULL DEFAULT 'v1',
  `created_at` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`card_id`),
  INDEX `idx_sku_status` (`sku_code`, `card_status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

三、 数据库访问控制与防脱裤审计策略

严格禁用数据库 Root 账号直连应用层；为发卡服务配置最小特权账号，仅授权必要表的 `SELECT` 与 `UPDATE` 权限，关闭对敏感数据字典与文件导出的全局系统级访问权限。