Android 本地数据与日志安全实践

移动应用会接触账户标识、业务记录、缓存文件和调试日志。安全问题往往不是某个算法选择错误，而是数据在整个生命周期中被复制到过多位置：请求参数被完整记录、敏感字段进入普通偏好存储、临时文件长期不清理，或 WebView 暴露了超出需要的能力。

一、先做数据分类

安全设计应从数据含义开始。可以按风险分为：

• 公开数据：公开资讯、通用配置等。
• 内部数据：业务开关、非公开运行信息等。
• 个人数据：账户资料、设备标识、使用记录等。
• 高敏感数据：身份凭据、支付验证信息、私密文件等。

分类决定是否允许落盘、保存多久、能否进入日志，以及退出登录时是否必须清除。没有必要为所有公开缓存使用高成本保护，也不能因为开发方便而降低高敏感数据的要求。

二、坚持最小化存储

最安全的数据是无需保存的数据。接口响应中即使包含多个字段，也只应落盘业务真正需要的部分。短期页面状态保存在内存即可，不必写入持久化存储。

存储前应明确：

1. 为什么需要保存。
2. 保存到哪个作用域。
3. 何时过期或清除。
4. 哪些模块可以读取。
5. 用户退出或切换账户时如何处理。

这些规则应落实在仓库或安全存储组件中，而不是依赖每个页面自行记忆。

三、避免把凭据放进普通配置

普通偏好存储适合主题、引导状态等低敏感配置，不适合直接保存长期身份凭据。敏感值应通过项目既有的安全存储组件处理，由它统一完成密钥管理、加解密和版本兼容。

不要在业务模块自行拼装一套加密逻辑。算法、密钥保存和设备迁移之间存在完整约束，局部实现很容易只保护了文件表面，却把密钥放在同样容易读取的位置。

四、日志默认不记录敏感内容

日志可能被本地文件、远程采集、测试平台和多人调试环境同时接触。请求体、响应体、身份头、手机号和证件信息都不应默认完整输出。

可以在统一日志层基于字段语义脱敏：

data class SafeAccountLog(
    val userIdSuffix: String,
    val requestId: String,
    val resultCode: String
)

fun AccountResult.toSafeLog(): SafeAccountLog {
    return SafeAccountLog(
        userIdSuffix = userId.takeLast(4),
        requestId = requestId,
        resultCode = resultCode
    )
}

脱敏后的内容仍要评估组合识别风险。正式构建还应按项目策略关闭调试级输出，避免仅依赖人工约束。

五、管理数据库和缓存文件

数据库、图片缓存和导出文件需要不同策略：

• 数据库只保存业务必需字段，并按账户隔离。
• 普通图片缓存可以按容量和时间清理。
• 含敏感信息的导出文件应存放在受控目录，并设置明确生命周期。
• 临时文件使用完成后及时删除，不等待系统不确定的回收时机。
• 退出登录时清理当前账户专属数据，不能误删其他账户数据。

删除范围必须通过稳定目录和业务标识确定，避免使用宽泛路径或未经验证的拼接结果。

六、控制组件暴露

Activity、Service、Receiver 和 Provider 是否允许外部应用访问，应根据真实需求明确配置。只在应用内部使用的组件不应暴露。

需要外部调用时，应验证调用来源、参数和权限，并把入口逻辑保持精简。导出组件接收到的数据都应视为不可信输入，不能因为调用发生在移动设备上就省略校验。

七、谨慎配置 WebView

WebView 只开启业务必需能力。页面不需要脚本时，不应默认开启；需要文件访问、媒体播放或原生桥接时，也应限制具体范围。

原生桥接方法要保持最小集合，校验调用页面和参数，并避免把高权限对象整体暴露给脚本。页面跳转应经过项目统一规则判断，不接受未经确认的外部目标。

WebView 调试能力只用于受控的开发构建，正式环境按项目安全策略关闭。

八、防止界面信息被意外暴露

支付结果、身份资料等高敏感页面可能需要限制系统截图或最近任务预览。是否限制必须依据产品和合规要求，因为它会影响用户正常使用及辅助功能。

通知内容同样要谨慎。锁屏上不应直接展示高敏感详情，可以只显示通用提示，用户进入应用并完成必要校验后再查看完整内容。

九、依赖与兼容性管理

依赖升级不仅带来功能，也可能修复安全问题。但升级前要确认与项目最低系统版本、构建工具和现有行为兼容，并完成回归测试。

安全能力不应直接调用超出最低版本的系统 API。项目已有兼容封装时优先复用，避免不同业务模块形成多套行为不一致的实现。

十、建立验证清单

发布前可以检查：

• 正式日志中是否出现身份字段和完整请求内容。
• 退出登录后账户数据是否按范围清除。
• 临时文件是否有确定的删除时机。
• 内部组件是否意外暴露。
• WebView 能力和桥接方法是否遵循最小原则。
• 高敏感页面的后台预览是否符合要求。
• 调试开关是否在正式构建中关闭。

总结

Android 数据安全应覆盖采集、传输之外的本地全生命周期。先做数据分类，坚持最小化保存，再统一管理安全存储、日志脱敏、文件清理和组件暴露。安全策略越集中、边界越明确，越不容易在业务快速迭代中被绕过。