SQL 数据加密存储与访问控制

mysql中aes_encrypt返回varbinary导致查询乱码，需用aes_decrypt配对解密；密钥长度须严格匹配（如aes-256需32字节），生产环境必须显式指定加密模式（如’aes-256-gcm’），避免使用不安全的默认ecb模式。

MySQL 用 AES_ENCRYPT 存敏感字段，但查出来是乱码？

不是加密失败，是解密时没配对使用 AES_DECRYPT，而且默认返回 VARBINARY，直接 select 会显示十六进制或乱码。

• 必须用 AES_DECRYPT + 同一把密钥 + 同样的模式（如 AEAD_AES_256_GCM）才能还原；AES_ENCRYPT 返回的是二进制，别用 CAST(... AS char) 硬转，可能截断或乱码
• 密钥长度要严格匹配：AES-128 要 16 字节，AES-192 是 24，AES-256 是 32 —— 用 UNHEX(SHA2('mykey', 256)) 这类方式生成更稳，别手拼字符串
• MySQL 5.7+ 默认用 ECB 模式（不安全），生产务必显式指定 MODE 参数，比如 AES_ENCRYPT(data, key, 'aes-256-gcm')，否则审计过不了

postgresql 的 pgcrypto 加密后，应用层解不开？

常见原因是加解密使用的盐值、IV 或填充方式不一致。PostgreSQL 默认的 crypt() 是单向哈希，不能“解密”——真要可逆，得用 pgp_sym_encrypt() 配合 pgp_sym_decrypt()。

• pgp_sym_encrypt() 默认用 AES-128-CFB + 自动管理 IV 和 salt，解密时只要密钥对就行；但若手动传入 iv 参数，两边必须完全一致，否则返回 NULL
• 密钥建议用 gen_random_bytes(32) 生成，别用明文密码直接当密钥；如果用 passphrase，记得加 pgp_sym_encrypt(data, passphrase, 'cipher-algo=aes256') 显式指定算法
• 字段类型必须是 BYTEA，别建为 TEXT —— 插入时 PostgreSQL 会自动 hex-encode，取出来再解密前要先 DECODE(..., 'hex')，否则报错 invalid byte sequence

应用连接数据库时被拒绝访问加密字段，权限配置漏了哪步？

加密本身不改变权限模型，但实际中常因绕过视图/函数封装，或误用 DEFINER 权限导致执行失败。

• 如果把解密逻辑写在存储函数里（比如 decrypt_ssn(v BYTEA)），函数要用 SECURITY DEFINER，且定义者账号必须有 EXECUTE 权限，调用者账号则只需 EXECUTE，不用给底层表 SELECT
• 别让应用直连加密列；更稳妥的是建只读视图，字段用 AES_DECRYPT 包一层，并限制该视图只对特定角色 GRANT SELECT
• 注意 MySQL 的 SQL_MODE=STRICT_TRANS_TABLES 下，AES_DECRYPT 解密失败会返回 NULL 而非报错，容易掩盖密钥不匹配问题；加个 IS NULL 判断日志才看得见

Java 应用读取加密字段时抛 SQLDataException: Data type mismatch

这是 JDBC 驱动尝试把 VARBINARY 当字符串映射到 String 类型，底层字节流和字符编码对不上。

• Java 侧读取时，用 ResultSet.getBytes("ssn_encrypted") 拿 byte[]，别用 getString()；解密后再转 new String(decryptedBytes, StandardCharsets.UTF_8)
• mybatis 中如果用了 resultType="map"，它会自动调 getString，此时要么改用 resultMap 指定 jdbcType=BINARY，要么在 @Select SQL 里套一层 HEX(ssn_encrypted) 返回字符串再 hex-decode
• spring Data JPA 更麻烦：自定义 @Converter 时，convertToDatabaseColumn 必须返回 byte[]，且实体字段类型也得是 byte[]，别用 String 或 ByteBuffer，否则 hibernate 会默默转码

加密字段的边界很窄：它只保存储时的静态安全，不防注入、不防 dba、不防内存泄露。真正难的不是怎么加解密，而是密钥生命周期怎么管、谁有权看明文、审计日志有没有覆盖到解密操作——这些地方一松，前面全白干。