SafeInCloud 数据在本地与云端的流转路径
理解数据流转的意义
知道数据怎么走，才能知道安全在哪一层就不够了。很多用户以为"数据在云上就等于安全"，其实"安全"取决于每个环节的保护。SafeInCloud 的数据流转路径比较清晰，因为它不经过厂商服务器，只有两端：用户设备本地 + 用户自己的云盘。
一条密码条目的完整生命周期
以"在手机上添加一个新的信用卡密码条目"为例：
第一步：本地创建用户打开 Safe → 主密码解锁保险库 → 本地内存中解密保险库文件 → 添加卡片条目（包含卡号、持卡人姓名、CVC、有效期、附加备注） → 条目进入内存中的加密数据结构。
第二步：本地落盘条目写入内存后，整个保险库（包含之前所有条目 + 新条目）会重新用 AES-256 加密，然后覆盖写入本地 SafeInCloud.db 文件。这一步仍然完全在用户设备上完成，没有任何网络通信。
第三步：云端同步本地文件写入完成后，Safe 的云同步模块检测到本地文件的最后修改时间戳比云端版本更新 → 调用云服务商的 API（Google Drive API / Dropbox API / OneDrive API / WebDAV PUT）将本地加密文件上传覆盖云端文件。
第四步：另一台设备拉取电脑端 Safe 打开云同步模块 → 检测到云端文件的最后修改时间戳比本地版本更新 → 下载云端加密文件覆盖本地 → 下次解锁时解密看到新添加的信用卡条目。
各环节的安全保护
| 环节 | 加密保护 | 风险点 |
|---|---|---|
| 内存中 | 解锁期间明文 | 设备被越狱/Root 后理论上可从内存 dump |
| 本地文件 | AES-256 | 设备丢失且未锁屏时，攻击者可以拿到加密文件并离线暴力破解 |
| 传输通道 | 云服务商 HTTPS | 几乎无风险，除非设备存在网络劫持 |
| 云端存储 | 云服务商自身保护 + Safe 的 AES-256 | 云服务商账户被盗可导致文件被删除 |
没有哪个环节是绝对安全的
SafeInCloud 的安全模型建立在"多层防线"上。AES-256 是核心防线，但如果用户把主密码写在便签贴在显示器上、手机锁屏设置为"滑动直接解锁"、Google 账户没有开启 2FA，这些行为会绕过所有技术层防线。