一、数据生命周期管理：从生到死的合规设计

数据生命周期管理，说白了就是管好数据的「一生」。从它被创建的那一刻起，到最终被销毁，每个环节都得有规矩。我在项目中见过太多团队只关注「存」和「用」，结果审计一来，归档和销毁环节全是窟窿。

今天咱们就按六个阶段来拆解：创建、存储、使用、共享、归档、销毁。每个阶段我都会结合GDPR和《个人信息保护法》的要求，讲讲实际落地怎么做。

1.1 数据创建：源头合规最重要

数据创建是第一步，也是问题最多的一步。我个人习惯在项目启动时就问三个问题：这个数据必须收集吗？用户知情了吗？收集范围合理吗？

GDPR第5条明确说了「数据最小化原则」——你只能收集业务必需的数据。我见过一个健身App，非要收集用户的通讯录，这就明显越界了。

代码层面，我建议在数据采集层加一个「合规检查器」。举个例子：

// 数据采集前的合规检查
public class DataCollectionValidator {
    public static boolean canCollect(Context context, String dataType) {
        // 检查是否已获得用户同意
        if (!ConsentManager.hasConsent(context, dataType)) {
            Log.w("合规检查", "未获得用户同意，跳过采集");
            return false;
        }
        // 检查是否在最小必要范围内
        if (!DataMinimizationChecker.isNecessary(dataType)) {
            Log.w("合规检查", "数据不在最小必要范围内");
            return false;
        }
        return true;
    }
}

1.2 数据存储：加密是底线

数据存下来之后，安全就是头等大事。GDPR第32条要求采取「适当的技术和组织措施」，说白了就是加密要到位。

我建议至少做到这几点：

• 传输加密：所有网络请求必须走HTTPS/TLS 1.2以上
• 存储加密：敏感数据使用AES-256加密
• 密钥管理：密钥不要硬编码，用Android Keystore系统
• 数据库加密：使用SQLCipher或Room的加密扩展

来看一个实际的数据加密存储示例：

// 使用Android Keystore加密敏感数据
public class SecureStorage {
    private static final String KEY_ALIAS = "user_data_key";
    
    public static void storeSecurely(String key, String value) {
        try {
            KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
            keyStore.load(null);
            
            // 生成或获取密钥
            SecretKey secretKey = getOrCreateKey();
            
            // 加密存储
            Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
            cipher.init(Cipher.ENCRYPT_MODE, secretKey);
            byte[] encryptedData = cipher.doFinal(value.getBytes());
            
            // 存入SharedPreferences
            SharedPreferences prefs = getContext()
                .getSharedPreferences("secure_prefs", Context.MODE_PRIVATE);
            prefs.edit()
                .putString(key, Base64.encodeToString(encryptedData, Base64.DEFAULT))
                .apply();
                
        } catch (Exception e) {
            Log.e("SecureStorage", "加密存储失败", e);
        }
    }
}

1.3 数据使用：权限控制要精细

数据存好了，谁来用、怎么用，必须有严格的管控。个保法第6条要求「处理个人信息应当具有明确、合理的目的」，不能拿着用户数据随便用。

我建议在架构层面做三层权限控制：

权限层级	控制粒度	典型场景
应用层	功能模块级别	只有支付模块能访问银行卡信息
数据层	字段级别	客服只能看到用户昵称，看不到手机号
操作层	读写分离	数据分析师只能读，不能写

1.4 数据共享：第三方管控不能松

数据共享是合规的高风险区。GDPR第28条要求与数据处理者签订合同，个保法第21条也要求向第三方提供个人信息时需告知并取得同意。

我在项目中遇到过最典型的问题：App集成了十几个第三方SDK，每个SDK都在收集数据，但用户完全不知情。这绝对不行。

1.5 数据归档：保留期限要明确

数据不能无限期保留。个保法第19条要求「个人信息的保存期限应当为实现处理目的所必要的最短时间」。说白了，用完了就该归档或删除。

我建议建立数据保留策略表：

数据类型	保留期限	归档后处理
用户注册信息	账号存续期间 + 180天	脱敏后归档
交易记录	交易完成后5年（税务要求）	加密归档
日志数据	6个月	自动删除
生物识别信息	立即删除（处理完成后）	不可归档

1.6 数据销毁：彻底清除不留痕

最后一步，数据销毁。很多人觉得「删掉文件」就行了，其实远远不够。GDPR第17条「被遗忘权」要求数据被彻底清除，无法恢复。

Android端的数据销毁要注意：

• 数据库：执行DELETE后还要执行VACUUM，否则数据还在文件里
• SharedPreferences：调用clear()后，文件本身可能还有残留
• 文件存储：删除文件后，用随机数据覆盖原位置
• 缓存：清理所有应用缓存目录

// 安全删除用户数据
public class DataErasureHelper {
    public static void eraseUserData(String userId) {
        // 1. 删除数据库记录
        database.execSQL("DELETE FROM user_table WHERE user_id = ?", 
            new String[]{userId});
        // 2. 回收空间，物理清除
        database.execSQL("VACUUM");
        
        // 3. 清除SharedPreferences
        prefs.edit().clear().apply();
        
        // 4. 删除用户文件目录
        File userDir = new File(context.getFilesDir(), "user_" + userId);
        if (userDir.exists()) {
            deleteDirectory(userDir);
        }
        
        // 5. 清除缓存
        context.deleteDatabase("cache_" + userId + ".db");
        
        Log.i("DataErasure", "用户" + userId + "数据已彻底清除");
    }
}

嗯，到这里数据生命周期的六个阶段就讲完了。每个环节环环相扣，少了哪一步都不行。你想想看，如果创建时没做好最小化，后面存储、使用、共享都会出问题。如果销毁不彻底，用户要求删除数据时你就没法交代。

我个人习惯把这六个阶段做成一个检查清单，每次发版前逐项核对。合规不是一次性的事，得融入到日常开发流程里。

---

公众号:蓝海资料掘金营，微信deep3321