Open Harmony 安全隐私：从备份恢复扩展看应用数据保护方案 🔐

前言 🌟

安全隐私并不只等于“权限申请弹窗”。在移动应用中，数据的备份、恢复、迁移和暴露边界，同样属于安全隐私的一部分。

当前项目中已经存在一个备份恢复扩展 Ability：

entry/src/main/ets/entrybackupability/EntryBackupAbility.ets

并且在 module.json5 中进行了注册。这篇文章就基于项目里的真实代码，分析 OpenHarmony / HarmonyOS 项目中如何声明备份恢复能力，以及为什么这类扩展需要谨慎处理。

需要说明的是：当前项目只实现了备份恢复扩展的基础回调和日志，没有真正读写用户数据。因此本文不会虚构“已经完成数据加密备份”之类的内容，而是围绕现有工程讲清楚它能做什么、现在做到了哪一步、后续应该怎样扩展。

项目中的备份扩展配置 📦

先看 module.json5 中的配置：

"extensionAbilities": [
  {
    "name": "EntryBackupAbility",
    "srcEntry": "./ets/entrybackupability/EntryBackupAbility.ets",
    "type": "backup",
    "exported": false,
    "metadata": [
      {
        "name": "ohos.extension.backup",
        "resource": "$profile:backup_config"
      }
    ]
  }
]

这段配置说明当前项目注册了一个扩展 Ability，名称是 EntryBackupAbility，类型是 backup。

几个重点：

1. type: "backup" 表示这是备份恢复相关扩展。
2. srcEntry 指向扩展 Ability 的 ArkTS 文件。
3. exported: false 表示该扩展不对外暴露。
4. metadata 绑定了备份配置资源。

在安全隐私角度，exported: false 是一个值得强调的点。备份恢复通常涉及应用内部数据，不应该随意对外开放能力入口。

backup_config.json 配置 🧾

项目中还有一个备份配置文件：

{
  "allowToBackupRestore": true
}

该文件路径是：

entry/src/main/resources/base/profile/backup_config.json

当前配置表示允许应用参与备份恢复流程。注意，这只代表“允许”，并不代表项目已经完成了复杂的数据备份逻辑。

如果后续应用中存在用户笔记、草稿、浏览记录、收藏状态等数据，就需要在备份恢复过程中仔细判断哪些数据可以备份、哪些数据不应该备份。

例如：

1. 可以考虑备份本地偏好设置。
2. 可以考虑备份非敏感草稿。
3. 不应随意备份访问令牌、敏感身份凭据。
4. 涉及用户隐私的数据应结合业务要求进行过滤、脱敏或加密处理。

这些是后续扩展方向，不是当前项目已经完成的能力。

EntryBackupAbility 的真实实现 ⚙️

当前项目中的实现如下：

import { hilog } from '@kit.PerformanceAnalysisKit';
import { BackupExtensionAbility, BundleVersion } from '@kit.CoreFileKit';

const DOMAIN = 0x0000;

export default class EntryBackupAbility extends BackupExtensionAbility {
  async onBackup() {
    hilog.info(DOMAIN, 'testTag', 'onBackup ok');
    await Promise.resolve();
  }

  async onRestore(bundleVersion: BundleVersion) {
    hilog.info(DOMAIN, 'testTag', 'onRestore ok %{public}s', JSON.stringify(bundleVersion));
    await Promise.resolve();
  }
}

代码结构非常清楚：

1. 继承 BackupExtensionAbility。
2. 实现 onBackup 回调。
3. 实现 onRestore 回调。
4. 通过 hilog 输出备份与恢复日志。

目前 onBackup 和 onRestore 中没有真实数据处理，只是异步返回。这在模板阶段是合理的，因为它先搭好了能力入口。后续如果需要接入真实数据，再在这两个回调里处理文件、数据库或配置项。

为什么这属于安全隐私主题？🛡️

很多人写安全隐私文章时，会优先想到权限申请、相册访问、定位权限等内容。但从工程角度看，备份恢复同样重要，因为它涉及数据离开当前运行环境后的处理方式。

如果一个应用允许备份恢复，就应该思考这些问题：

1. 哪些数据可以被备份？
2. 哪些数据恢复后仍然有效？
3. 敏感数据是否需要重新登录后才能使用？
4. 备份过程中是否会记录过多日志？
5. 恢复时是否需要兼容旧版本数据结构？

当前项目已经接入备份扩展入口，这给后续安全隐私设计提供了基础。

日志也要注意隐私 📌

当前代码中有一行：

hilog.info(DOMAIN, 'testTag', 'onRestore ok %{public}s', JSON.stringify(bundleVersion));

这里记录的是 bundleVersion，用于观察恢复时的版本信息。实际项目中，日志输出一定要克制。

建议遵守几个原则：

1. 不在日志里输出用户手机号、账号、Token。
2. 不在日志里输出完整隐私数据。
3. 出错时记录错误类型和流程节点，而不是敏感内容本身。
4. 能用状态码和业务场景定位问题时，就不要输出完整对象。

日志是排查问题的工具，不应该变成隐私泄露的入口。

后续真实项目可以怎样扩展 🚀

基于当前项目，后续可以继续扩展：

1. 在 onBackup 中整理允许备份的数据。
2. 在 onRestore 中根据 BundleVersion 做版本兼容。
3. 对敏感数据进行过滤。
4. 将备份恢复逻辑拆到单独 service，避免扩展 Ability 过重。
5. 为备份恢复流程增加测试用例。

这些方向都是真实可落地的，但当前项目还没有实现，所以文章中应该写成“后续可扩展”，而不是“已经完成”。

总结 ✅

这篇文章对应“四大主题”中的 安全隐私。

当前项目已经具备备份恢复扩展的基础结构，包括：

1. EntryBackupAbility。
2. backup_config.json。
3. module.json5 中的 extensionAbilities 注册。
4. exported: false 的安全边界配置。

它还不是完整的数据保护方案，但已经具备安全隐私文章中非常值得讲的工程基础。真实项目中，数据备份恢复不是简单地“能备份就行”，而是要明确数据范围、恢复策略、日志边界和版本兼容。

参考资料：

• HarmonyOS 官方文档：ExtensionAbility 与备份恢复相关能力
• HarmonyOS 官方文档：模块配置文件说明
• 当前项目文件：EntryBackupAbility.ets、backup_config.json、module.json5