📚 课程目录第3章数据分类分级

数据分类分级：从混乱到有序

数据分类分级这件事，说白了就是回答两个问题：我们有什么数据？这些数据到底有多敏感？

我在不少项目里见过这样的场景——团队把所有数据一股脑儿加密存储，结果性能扛不住；或者反过来，把客户身份证号当普通日志随便存，出了事才追悔莫及。嗯，这两种极端我都踩过坑。

今天我们就来聊聊，怎么在设备端把数据分门别类，定好级别。这套方法我用了好几年，至少没出过大乱子。

数据分类：先搞清楚家里有什么

分类是第一步。我个人习惯把设备上的数据分成三大类：

类别	定义	典型例子
个人身份信息 (PII)	能直接或间接识别出具体个人的数据	姓名、身份证号、手机号、生物特征（指纹、人脸）
敏感数据	泄露后可能造成人身、财产或名誉损害的数据	医疗记录、支付密码、位置轨迹、通讯录
商业数据	与业务运营、商业决策相关的数据	产品代码、客户名单、定价策略、内部文档

一个小技巧：分类时别太纠结边界。比如「手机号」既是PII，也是敏感数据。我的做法是——取交集，按最高级别保护。宁可多保护，不可漏保护。

你可能会问：「那用户生成的普通内容呢？比如一张风景照。」

这类数据通常归为一般数据，不在上述三类里。但要注意——如果照片里拍到了别人的脸，那就又回到PII的范畴了。所以分类不是一劳永逸的，得结合上下文。

数据分级：给每类数据贴上标签

分类是分堆，分级是定优先级。我建议用四级制，简单明了：

级别	名称	影响描述	示例
L4	极敏感	泄露后造成严重法律/财务/人身风险	支付密钥、生物特征、医疗诊断
L3	敏感	泄露后造成中等风险，需内部严格管控	身份证号、通讯录、位置轨迹
L2	内部	泄露后影响有限，但不宜公开	产品代码、内部文档、客户名单
L1	公开	泄露后无实质影响	设备型号、系统版本、公开帮助文档

注意：分级不是拍脑袋定的。我曾经见过一个团队把所有数据都标成L4，结果合规审计时反而被质疑「分级不合理」。分级要有依据，最好跟法务、安全、业务三方对齐。

分级标准制定：把规则写下来

光有级别还不够，你得有判定标准。不然每个人理解不一样，分级就乱了。

我常用的判定维度有三个：

可识别性——这条数据能不能直接或间接定位到具体个人？
敏感性——泄露后会造成什么后果？经济损失？名誉损害？人身安全？
合规要求——法律法规（如GDPR、个人信息保护法）有没有特殊要求？

举个例子，判断一条数据该不该归为L3：

如果它能直接识别个人（比如身份证号），且泄露后可能被用于诈骗 → L3或L4
如果它只是内部使用，泄露后最多被竞争对手看到（比如产品路线图）→ L2
如果它本来就是公开信息（比如设备序列号的前几位）→ L1

我的经验：制定标准时，最好画一张决策树。把判定条件写清楚，让开发同学照着走一遍就能定级。别搞得太复杂，否则没人愿意用。

数据分类分级流程图

下面这张图是我在项目中实际用过的分类分级流程，你可以直接参考：

避坑指南：我踩过的几个坑

讲完了理论，说说实战中容易翻车的地方。

坑一：分类分级只做一次

我曾经在一个IoT项目里，上线前把数据分类分级做得漂漂亮亮。结果半年后业务加了新功能，采集了新的数据类型，但没人更新分类表。直到合规检查才发现，新数据全都没定级。所以——分类分级要跟数据生命周期绑定，每次新增数据源都要重新过一遍流程。

坑二：分级标准太模糊

「敏感数据」这个词太宽泛了。我见过一个团队把「用户头像」也标成敏感数据，理由是「头像可能泄露用户长相」。嗯，理论上没错，但实际执行时你会发现，所有数据都成了敏感数据，等于没分级。我的建议是：分级标准要具体到「什么场景下、泄露后会造成什么后果」。

一个小建议：在设备端实现分类分级时，别想着一步到位。先挑最核心的几类数据（比如PII和支付相关）做好分级，其他的慢慢补。迭代比完美更重要。

代码示例：设备端分类分级实现

最后给一段伪代码，展示怎么在设备端做分类分级。这是我从一个嵌入式Linux项目里提炼出来的：

// 数据分类枚举
typedef enum {
    DATA_CATEGORY_PII,       // 个人身份信息
    DATA_CATEGORY_SENSITIVE, // 敏感数据
    DATA_CATEGORY_BUSINESS,  // 商业数据
    DATA_CATEGORY_GENERAL    // 一般数据
} data_category_t;

// 数据分级枚举
typedef enum {
    DATA_LEVEL_L1 = 1,  // 公开
    DATA_LEVEL_L2 = 2,  // 内部
    DATA_LEVEL_L3 = 3,  // 敏感
    DATA_LEVEL_L4 = 4   // 极敏感
} data_level_t;

// 分类分级结构体
typedef struct {
    data_category_t category;
    data_level_t    level;
    const char*     data_tag;  // 数据标签，用于审计
} data_classification_t;

// 分类分级判定函数
data_classification_t classify_data(const char* data_type) {
    data_classification_t result = {0};

    // 规则引擎：根据数据类型判定分类和级别
    if (strcmp(data_type, "fingerprint") == 0) {
        result.category = DATA_CATEGORY_PII;
        result.level    = DATA_LEVEL_L4;  // 生物特征，最高级别
        result.data_tag = "biometric_pii";
    } else if (strcmp(data_type, "location") == 0) {
        result.category = DATA_CATEGORY_SENSITIVE;
        result.level    = DATA_LEVEL_L3;
        result.data_tag = "location_trace";
    } else if (strcmp(data_type, "app_config") == 0) {
        result.category = DATA_CATEGORY_BUSINESS;
        result.level    = DATA_LEVEL_L2;
        result.data_tag = "internal_config";
    } else {
        result.category = DATA_CATEGORY_GENERAL;
        result.level    = DATA_LEVEL_L1;
        result.data_tag = "general_data";
    }

    return result;
}

// 使用示例
void on_data_collect(const char* data_type, void* data_buffer) {
    data_classification_t cls = classify_data(data_type);

    // 根据级别决定保护策略
    if (cls.level >= DATA_LEVEL_L3) {
        encrypt_data(data_buffer, cls.data_tag);
        enable_access_control(cls.data_tag);
    } else if (cls.level == DATA_LEVEL_L2) {
        encrypt_data(data_buffer, cls.data_tag);
        // 内部数据不需要严格访问控制
    }
    // L1数据直接存储，不做额外保护

    // 记录审计日志
    audit_log("data_collected", cls.data_tag, cls.level);
}

这段代码的核心思路是：把分类分级逻辑集中到一个函数里，所有数据采集点都调用它。这样规则变了，只改一个地方就行。

嗯，数据分类分级这件事，说难不难，说简单也不简单。关键是形成习惯，把它嵌入到开发流程里，而不是事后补作业。希望今天的内容对你有帮助。