📚 课程目录第3章静态脱敏技术

3、静态脱敏技术：数据遮蔽、数据替换、数据混淆、在嵌入式数据库中的应用

静态脱敏，说白了就是数据在“静止”状态下做清洗。数据躺在数据库里、躺在文件系统里，还没开始流动，这时候我们动手把它改掉。我做过不少物联网项目，发现很多团队只盯着传输加密，却忘了源头数据本身就是裸奔的。你想想看，攻击者一旦拿到设备固件或者直接物理接触了存储芯片，加密传输再强也没用。

这一章我们聊四种最常用的静态脱敏手法：数据遮蔽、数据替换、数据混淆，以及它们怎么在嵌入式数据库里落地。嗯，这里要注意，嵌入式环境资源有限，不能把云端那套大数据脱敏框架直接搬过来。

3.1 数据遮蔽（Masking）

数据遮蔽是最直观的手法。把敏感字符用固定符号替换掉，只保留格式和部分可识别信息。我在智能门锁项目里处理设备序列号时就用过这招——日志里输出完整序列号太危险，但全抹掉又没法排查问题。

常见的遮蔽规则：

保留头尾：比如手机号 138****1234
保留格式：比如身份证号 110101****1234****
动态遮蔽：根据用户角色决定遮蔽长度

嵌入式场景下，我建议直接在数据写入日志或导出时做遮蔽，而不是存两份数据。举个例子：

// C语言示例：设备ID遮蔽，保留前4位和后4位
void mask_device_id(char *id) {
    int len = strlen(id);
    if (len <= 8) return; // 太短就不遮蔽了
    for (int i = 4; i < len - 4; i++) {
        id[i] = '*';
    }
}

我的习惯：遮蔽函数一定要做边界检查。我曾经遇到过设备ID长度只有6位的情况，遮蔽后全变成星号，日志完全没法用。后来我加了个最小长度判断，低于8位就不遮蔽，只截断。

3.2 数据替换（Substitution）

数据替换不是简单地把字符盖住，而是用合法但虚假的数据替换真实数据。这样做的最大好处是：替换后的数据仍然能通过格式校验，测试环境可以直接用。

我在智能电表项目里做过一个替换规则表：

原始字段	替换规则	示例
设备MAC地址	保留厂商OUI，后6位随机	AC:23:3F:XX:XX:XX
用户手机号	从预置号码池随机取	13800010001
地理位置坐标	偏移100-500米	39.9042, 116.4074 → 39.9067, 116.4102
设备序列号	按规则生成伪序列号	SN2024A00001

替换的关键是保持关联性。同一个设备ID在不同表里出现，替换后必须一致。否则测试环境里数据对不上，联查全崩。我习惯用哈希映射来保证一致性：

// 伪代码：确定性替换，同一输入永远得到同一输出
char* substitute_serial(const char* real_serial) {
    uint32_t hash = simple_hash(real_serial);
    static char fake[32];
    snprintf(fake, sizeof(fake), "FAKE-%08X", hash);
    return fake;
}

注意：替换算法不能太简单。我曾经见过有人直接用CRC32当伪序列号，结果被攻击者反向推算出原始序列号的取值范围。建议至少用HMAC加盐。

3.3 数据混淆（Obfuscation）

数据混淆比遮蔽和替换更“狠”一点。它通过编码变换、加密、乱序等手段，让数据变得难以理解。但注意，混淆不是加密——加密有密钥管理，混淆通常没有密钥，或者密钥是固定的。

嵌入式设备上常用的混淆手法：

Base64变种：自定义字符表，不是标准Base64
XOR混淆：用一个固定密钥做异或
字节重排：按固定模式打乱字节顺序
分段反转：把数据分成几段，每段反转

我个人比较推荐XOR混淆，开销极小，在MCU上跑毫无压力。但一定要配合加盐，否则固定密钥容易被破解。

// XOR混淆示例，密钥来自设备唯一ID
void obfuscate_buffer(uint8_t *buf, size_t len, uint32_t device_key) {
    uint32_t key = device_key ^ 0xA5A5A5A5;
    for (size_t i = 0; i < len; i++) {
        buf[i] ^= (uint8_t)(key >> (8 * (i % 4)));
    }
}

核心区别总结：

遮蔽：保留部分原始信息，适合日志和显示
替换：完全替换为假数据，适合测试环境
混淆：变换数据形式，适合存储和传输

3.4 在嵌入式数据库中的应用

嵌入式数据库（SQLite、LevelDB、RocksDB等）资源受限，不能跑复杂的脱敏引擎。我的做法是：在数据写入层做脱敏，而不是在数据库层面做。

具体来说，分三种场景：

场景一：写入时脱敏

数据进入数据库之前，应用层先调用脱敏函数。这样数据库里存的已经是脱敏后的数据，即使存储芯片被物理读取，攻击者也拿不到原始信息。

// SQLite写入前脱敏示例
void insert_sensor_data(sqlite3 *db, const char *raw_device_id, float value) {
    char masked_id[32];
    strncpy(masked_id, raw_device_id, sizeof(masked_id));
    mask_device_id(masked_id); // 遮蔽处理
    
    sqlite3_stmt *stmt;
    sqlite3_prepare_v2(db, "INSERT INTO sensor VALUES(?, ?)", -1, &stmt, NULL);
    sqlite3_bind_text(stmt, 1, masked_id, -1, SQLITE_STATIC);
    sqlite3_bind_double(stmt, 2, value);
    sqlite3_step(stmt);
    sqlite3_finalize(stmt);
}

场景二：读取时脱敏

有些场景需要保留原始数据（比如用于固件升级校验），但查询结果不能暴露敏感信息。这时候可以在查询结果返回前做脱敏。

场景三：导出时脱敏

设备日志导出、数据备份时做批量脱敏。我建议用流式处理，边读边脱敏边写，避免内存暴涨。

避坑指南：我曾经在SQLite上直接挂载脱敏虚拟表，结果查询性能掉了40%。后来改成应用层脱敏，性能影响控制在5%以内。嵌入式设备上，不要在数据库引擎内部做复杂变换。

3.5 知识体系总览

下面这张图把三种静态脱敏技术以及它们在嵌入式数据库中的位置串起来了。你可以看到，数据从采集到存储，经过脱敏层后，敏感信息被遮蔽、替换或混淆，最终写入数据库的都是安全数据。

从图上你可以看到，整个流程的核心是脱敏策略选择。不同场景选不同手法：日志输出用遮蔽，测试数据用替换，存储用混淆。而且所有操作都在应用层完成，数据库本身不感知脱敏逻辑。这样做的好处是——换数据库也不影响脱敏策略。

我的建议：在嵌入式设备上，优先选择写入时脱敏。原因很简单：写入时脱敏只做一次，读取时不需要额外计算。对于电池供电的物联网设备，省电就是省命。

好了，静态脱敏的三种手法和嵌入式数据库的集成方式就聊到这里。记住一个原则：脱敏越早做，风险越小。数据还没落地就处理掉，后面所有环节都安全。