SQL注入是Web安全领域里经久不衰的攻击手段，尽管参数化查询、ORM框架已经普及，但拼接SQL的场景依然大量存在于遗留系统、报表模块和运维脚本中。一旦注入成功，攻击者构造一条UNION SELECT语句，就可能把整张用户表拖走。此时如果数据库里的手机号、身份证号、银行卡号都是以明文存储的，那么泄露就是灾难性的。反过来，如果我们提前对这些敏感列做了掩码或加密处理，攻击者拿到的只是一堆不可读或部分遮蔽的数据，损失可以被控制在极小范围内。这就是数据脱敏作为最后一道防线的价值所在。
为什么SQL注入防护需要配合数据掩码
很多团队的思路是“我把注入漏洞修好就行了”，这当然是对的，但安全建设不能只依赖单点防御。注入漏洞的发现往往滞后于攻击行为，攻击者可能在漏洞被报告之前已经潜伏数月，反复拖库而无人察觉。OWASP提出的纵深防御理念强调：即使某一层被突破，下一层依然要能提供保护。数据库层的脱敏处理正是这样的兜底机制。
具体来说，掩码处理解决的是“泄露之后的可用性”问题。假设用户表中手机号一列存储的是138****5678这样的掩码值，攻击者无论怎么注入查询，得到的都是脱敏后的数据，无法用于精准诈骗或撞库攻击。而对于确有业务需要完整手机号的场景（如短信发送、实名核验），则可以通过加密存储加受控解密的方式，把还原能力收敛到少数几个服务中。
需要注意的一点是，脱敏不是把数据改坏了就完事。脱敏方案必须在“安全性”和“业务可用性”之间做权衡：统计分析和风控模型可能需要保留手机号前缀、身份证中的出生日期等信息，因此掩码规则要按字段特性逐一定制，不能一刀切。
静态脱敏与动态脱敏：原理与选型
静态脱敏指在数据写入时就进行不可逆变换，数据库中存储的永远是脱敏后的值。比如注册时就把手机号写成138****5678。这种方式最彻底，即使数据库被拖库，原始数据也早已不存在。但它的代价是业务灵活性差：后续如果要给用户发短信，就没有完整手机号可用了。因此静态脱敏多用于测试环境数据、日志归档、大数据分析平台等不需要原始值的场景。
动态脱敏则保留原始数据（通常加密存储），在查询出口处根据访问者身份动态决定返回明文还是掩码值。数据库层面的实现如SQL Server的Dynamic Data Masking、Oracle的Redaction Policies，国产数据库和PostgreSQL生态也有相应插件或方案。动态脱敏的好处是业务系统无感知，同一个接口对不同权限返回不同精度的数据，非常适合客服系统、运营后台这类“部分人需要看完整值”的场景。
两者并非互斥，实践中常见的组合是：核心敏感列加密存储（AES-256），应用层按需解密，普通查询接口一律返回掩码值，解密操作全部走审计日志。这样即使应用存在注入点，攻击者从数据库直接捞到的也只是密文。
数据库层的掩码与加密实现
以MySQL为例，MySQL 8.0企业版自带Masking插件，可以对返回结果做脱敏。社区版用户则更常用MySQL Enterprise Encryption函数或应用层方案。下面是一个在应用层实现掩码函数的通用示例，逻辑同样适用于Go、Java等语言：
import re
def mask_phone(phone: str) -> str:
"""手机号掩码：保留前3位和后4位"""
if not phone or len(phone) != 11:
return "****"
return phone[:3] + "****" + phone[-4:]
def mask_id_card(idcard: str) -> str:
"""身份证掩码：保留前4位和后4位"""
if not idcard or len(idcard) < 10:
return "****"
return idcard[:4] + "**********" + idcard[-4:]
def mask_email(email: str) -> str:
"""邮箱掩码：保留首字符和域名"""
m = re.match(r"^(.)(.*)@(.+)$", email)
if not m:
return "****"
return m.group(1) + "****@" + m.group(3)
对于必须保留完整值的字段，推荐使用AES加密存储。MySQL中可以利用AES_ENCRYPT函数，但要注意密钥绝不能硬编码在SQL或代码里，而应交给KMS或配置中心管理：
-- 建表时使用VARBINARY存储密文
CREATE TABLE user_sensitive (
user_id BIGINT PRIMARY KEY,
phone_enc VARBINARY(256) NOT NULL,
idcard_enc VARBINARY(256) NOT NULL
);
-- 写入时加密，密钥从应用层传入
INSERT INTO user_sensitive (user_id, phone_enc)
VALUES (10001, AES_ENCRYPT('13812345678', ?, ?));
-- 校验场景：需要精确查找时对入参加密后比较
SELECT user_id FROM user_sensitive
WHERE phone_enc = AES_ENCRYPT('13812345678', ?, ?);
这种做法还有一个额外好处：加密后的字段无法使用LIKE模糊查询，倒逼开发者在设计时就把“按手机号精确查询”改为“加密值等值匹配”，减少了不必要的查询暴露面。如果业务确实需要模糊搜索，可以额外维护一个脱敏索引列，比如只存手机号前三位加后四位的哈希。
应用层与架构层的落地细节
在应用层做脱敏，推荐采用统一出口原则：所有对外返回的DTO在序列化阶段统一过一遍脱敏处理器，而不是在每个业务方法里散落着substring调用。以Java为例，可以自定义注解配合Jackson序列化器实现声明式脱敏：
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface Sensitive {
SensitiveType type();
}
public class SensitiveSerializer extends JsonSerializer<String> implements ContextualSerializer {
@Override
public void serialize(String value, JsonGenerator gen, SerializerProvider sp) throws IOException {
gen.writeString(SensitiveUtils.mask(value));
}
}
密钥管理是整个方案里最容易被忽视的环节。密钥存在代码仓库里等于没加密，正确做法是接入KMS服务或使用Vault这类工具，应用启动时拉取密钥到内存，定期轮换。同时要为解密操作建立独立的审计通道：谁在什么时间解密了哪个用户的手机号，都应有日志可查，异常高频解密行为要能触发告警。
最后是性能考量。加密存储会增加存储开销并使等值查询失去普通索引的加速能力，建议对加密列单独建表，通过主键关联，避免影响主表的热点查询。对于海量数据的报表场景，可以直接建设脱敏后的从库或数据仓库副本，让分析侧与生产侧彻底隔离。配合数据库层面的最小权限原则——应用账号只授予必要表的必要权限、禁止FILE和SUPER权限、开启慢日志审计——即便注入真的发生，攻击者能触达的数据面也被压缩到了极限。安全从来不是一个开关，而是一层层叠加的成本，让攻击变得不划算，防护的目的就达到了。