29、联系人安全与隐私：加密存储敏感数据、应用锁、数据脱敏展示、GDPR合规建议

做联系人系统开发，最绕不开的就是安全与隐私。说实话，我早年刚入行时，觉得联系人嘛，不就是存个名字和电话，能有多大事？直到有一次，我在一个企业级项目里，客户要求所有联系人数据必须加密存储，否则不给验收。那会儿我才真正意识到——联系人信息，其实是用户最核心的隐私资产之一。

今天这一章，咱们就聊聊怎么把联系人系统的安全防护做到位。我会从四个维度展开：加密存储、应用锁、数据脱敏展示，以及GDPR合规建议。嗯，都是我在真实项目中踩过的坑和总结的经验。

29.1 加密存储：别让数据裸奔

先问一个问题：你的联系人数据库，是不是直接明文存到SQLite里的？如果是，那其实跟把通讯录贴在手机背面没啥区别。

我个人习惯，所有敏感字段必须加密。什么叫敏感字段？姓名、电话号码、邮箱、地址、生日、备注——这些都属于。你想想看，一旦手机丢了，或者数据库被恶意读取，这些信息就全暴露了。

Android上做加密，我推荐用 Android Keystore + AES-GCM 的组合。Keystore负责安全地存储密钥，AES-GCM负责加密数据。为什么选GCM？因为它自带认证标签，能防篡改。

下面是我常用的一个加密工具类核心代码：

// 使用 Android Keystore 生成 AES 密钥
KeyGenParameterSpec spec = new KeyGenParameterSpec.Builder(
        "contact_key",
        KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
        .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
        .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
        .setKeySize(256)
        .build();

KeyGenerator keyGenerator = KeyGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
keyGenerator.init(spec);
SecretKey key = keyGenerator.generateKey();

// 加密
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
cipher.init(Cipher.ENCRYPT_MODE, key);
byte[] iv = cipher.getIV();
byte[] encrypted = cipher.doFinal(plaintext.getBytes(StandardCharsets.UTF_8));

// 存储时：iv + encrypted 一起存，解密时需要iv

我在项目中遇到过一个问题：如果用户卸载App再重装，Keystore里的密钥就没了，之前加密的数据全部作废。所以，如果你需要跨安装周期保留数据，可以考虑用基于用户密码派生的密钥，或者使用备份机制。但说实话，大多数联系人App不需要这么复杂，随安装周期销毁反而更安全。

29.2 应用锁：给App加把门

加密存储解决的是数据被静态读取的问题。但还有一个场景：手机借给别人用，别人直接打开你的联系人App，所有数据一览无余。怎么办？加应用锁。

Android上实现应用锁，主流方案有两种：

• 系统级方案：利用Android 12+的 DevicePolicyManager 或 BiometricPrompt 做生物识别锁。
• 自定义方案：在App启动时弹出一个锁屏界面，验证通过后才进入主界面。

我个人更推荐第二种，因为兼容性好，而且可以自定义锁屏样式。下面是一个简单的实现思路：

// 在 Application 或 BaseActivity 中判断是否需要锁屏
public class ContactApp extends Application {
    private boolean isLocked = true;

    public boolean isLocked() {
        return isLocked;
    }

    public void unlock() {
        isLocked = false;
    }

    public void lock() {
        isLocked = true;
    }
}

// 在 BaseActivity 的 onResume 中检查
@Override
protected void onResume() {
    super.onResume();
    ContactApp app = (ContactApp) getApplication();
    if (app.isLocked()) {
        startActivity(new Intent(this, LockScreenActivity.class));
    }
}

另外，应用锁的验证方式，我建议优先支持指纹/面部识别，同时保留PIN码作为备用。毕竟不是所有设备都有生物识别模块。

29.3 数据脱敏展示：该藏的藏，该露的露

什么叫数据脱敏？说白了，就是在界面上展示时，把敏感信息部分隐藏掉。比如联系人列表里，电话号码显示成 138****1234，而不是完整的 13800138000。

为什么要做脱敏？两个场景：

• 用户把手机给别人看联系人列表时，不希望对方直接看到完整号码。
• App在后台做数据统计或日志输出时，不能把明文敏感信息写进日志。

我常用的脱敏工具方法：

public static String maskPhone(String phone) {
    if (phone == null || phone.length() < 7) {
        return phone;
    }
    // 保留前3位和后4位，中间用****代替
    return phone.substring(0, 3) + "****" + phone.substring(phone.length() - 4);
}

public static String maskEmail(String email) {
    if (email == null || !email.contains("@")) {
        return email;
    }
    int atIndex = email.indexOf("@");
    String prefix = email.substring(0, atIndex);
    String suffix = email.substring(atIndex);
    // 前缀只保留第一个字符，其余用***代替
    return prefix.charAt(0) + "***" + suffix;
}

另外，脱敏的粒度要灵活。比如在联系人详情页，用户自己查看时，应该展示完整信息；但在列表页或者分享给第三方时，才做脱敏。我建议在ViewModel层做一个脱敏开关，根据当前场景决定是否脱敏。

29.4 GDPR合规建议：别惹欧洲的麻烦

GDPR（通用数据保护条例）是欧盟的数据保护法规。如果你的App面向欧洲用户，或者你的服务器部署在欧洲，那就必须遵守。不遵守的后果？罚款最高可达全球年营收的4%或2000万欧元——嗯，这可不是闹着玩的。

对于联系人系统，GDPR的核心要求有几点：

要求	说明	实现建议
明确同意	收集联系人数据前，必须获得用户明确、自愿的同意	在首次启动时弹出隐私协议，用户勾选同意后才能导入联系人
数据最小化	只收集必要的字段，不要过度采集	默认只存姓名和电话，邮箱、地址等设为可选
删除权（被遗忘权）	用户有权要求删除其所有数据	提供“删除账户”功能，一键清除所有联系人数据
数据可移植性	用户有权导出自己的数据	提供vCard或CSV导出功能
数据泄露通知	发生数据泄露时，72小时内通知用户	建立安全监控和告警机制

我在做GDPR合规时，踩过一个坑：用户要求删除数据，我删了本地数据库，但忘了清理云端备份和日志文件。结果审计时被查出来，差点被罚。所以，删除操作一定要做到“全链路删除”——本地、云端、缓存、日志，一个都不能漏。

29.5 知识体系总览

下面这张图，我把本章的核心知识点串了起来。你可以把它当作一个安全检查清单：

这张图把四个维度串在了一起。你可以把它当作一个安全检查清单：加密存储做了吗？应用锁加了吗？脱敏展示实现了吗？GDPR合规检查过了吗？嗯，全部打勾，才算合格。

29.6 写在最后

安全与隐私，不是功能，而是态度。我见过太多App，功能做得花里胡哨，但数据安全一塌糊涂。用户把通讯录交给你，是对你的信任。别辜负这份信任。

如果你正在开发联系人系统，我建议你从今天开始，至少把加密存储和脱敏展示加上。这两步成本最低，但效果最明显。至于应用锁和GDPR合规，可以根据你的目标用户群体来决定优先级。

好了，这一章就聊到这儿。记住：安全无小事，隐私是底线。

---