1.1 定义与重要性

1.1 定义与重要性

本节摘要：移动应用安全保护代码逻辑、本地敏感数据、与后端通信、设备权限交互及越狱/Root 运行环境。SOURCE 强调一旦漏洞被利用，可触发身份盗窃、PCI 罚款与品牌声誉连锁崩塌——本节用后果链图把「技术漏洞」翻译成业务语言。

学习目标

1. 用五层对象定义移动应用安全范围
2. 解释 GDPR、PCI DSS、HIPAA 对移动数据的约束
3. 绘制应用—TLS—API—数据库链路上的安全控制点

一、从现场案例理解「移动安全」

某社交 App 把 refresh token 存在未加密 SQLite，取证人员用 sqlite3 直接读出——攻击面不在服务器，而在用户口袋里的设备。移动应用安全（Mobile Application Security）是一套技术、流程与实践，目标是：

1. 保护应用代码与逻辑 — 防逆向、篡改、恶意注入
2. 保护应用数据 — PII、支付信息、位置、生物特征在存储与传输中的 CIA
3. 保护通信 — TLS 正确配置、证书校验、防 MITM
4. 保护设备资源交互 — 相机、通讯录等权限不被滥用
5. 应对运行环境风险 — 恶意软件、越狱/Root、OS 漏洞

交互链路安全控制点

交互链路安全控制点

二、为何「重要」而非「可选」

SOURCE 1.1.2 从六个维度论证：

三、工程验收：你的 App 算「做了移动安全」吗

⚠️ 常见坑：把「上架应用商店」等同于「安全审计通过」——商店审核不替代 SAST/DAST。

💡 关键直觉：移动安全贯穿需求、设计、开发、测试、部署、运行全生命周期，不是发版前一周补洞。

要点速记

• 移动安全覆盖代码、数据、通信、权限、环境五层
• 泄露后果链：技术漏洞 → 业务/合规/声誉损失
• GDPR、PCI DSS 等把移动数据保护变成法定义务
• 验收靠可检查清单，不靠主观「感觉安全」

下一节讨论移动相对 Web 难在哪里——碎片化与物理可访问性。

深化：从五层对象到数据资产清单

五层保护对象再往下走一步，是「给数据分类」。没有分类就无法确定每类数据的保护强度：公开信息、业务半敏感、账号敏感、支付与生物特征，应分等级并各自制定存储、传输、生命周期策略。先做数据清单，再决定保护手段，比反过来从工具入手靠谱。

# 数据资产分类清单（示例）
数据项: 设备号    | 分类: 半敏感 | 存储: 明文本地     | 生命周期: 卸载即清
数据项: 会话Token | 分类: 高敏感 | 存储: Keystore加密 | 生命周期: 注销即删
数据项: 银行卡PAN | 分类: 极高   | 存储: 不落客户端   | 生命周期: 仅内存短用
​

合规压力来自 GDPR、个保法、PCI DSS 等，但本质要求一致：能少收集就少收集，收集了要加密、要能删除。把「数据清单 + 保护强度」写进需求文档，是安全从文档走向落地的最小动作。

安全目标与合规节奏

安全目标可以拆成三层：防泄露（机密性）、防篡改（完整性）、防不可用（可用性），落到业务上分别对应数据资产、业务逻辑、服务可用。评审时每一类数据都要标注它的 C/I/A 优先级，再决定保护投入。合规节奏建议按三个节点推进：上架前完成数据清单与隐私政策核对，发版时跑一次安全扫描门禁，运营期按季度复查第三方 SDK 与漏洞。把安全从「一次突击」改成「三个节点」的节奏，成本更低且可预期。