2. 医疗App数据生命周期与威胁建模

医疗App的数据安全不是“加个HTTPS、做个登录”就能解决的问题。同一条血压记录，在采集时可能来自蓝牙设备、在传输时经过公网、在存储时落到本地SQLite或云端对象存储、在使用时被推送给医生、在共享时流向第三方健康平台、在销毁时又可能残留在备份与日志中。每个阶段的资产形态、信任边界和攻击者能力都不同，因此需要按生命周期逐段分析，再用威胁建模方法把“可能出什么事”结构化。

一、六阶段数据生命周期与典型风险

采集阶段的风险集中在来源可信与授权边界。例如App读取用户手动输入的用药记录、通过蓝牙血糖仪获取读数、调用系统健康数据接口读取步数。若未校验设备身份，攻击者可用伪造的BLE外设注入错误血糖值；若权限申请过宽，可能顺带读取与业务无关的通讯录。采集还应明确“最小必要”：一个记录经期的小程序不应索取精确定位。

传输阶段的核心是机密性与完整性。移动端到服务端应使用TLS 1.2以上，并启用证书校验；若客户端关闭证书校验或信任用户安装的根证书，中间人即可解密。对于蓝牙传输，应使用配对加密并校验设备绑定关系。此外，传输元数据（如请求时间、IP、设备型号）本身也可能泄露就诊行为。

存储阶段要区分本地与服务端。本地常见风险包括：数据库明文、日志打印敏感字段、截图缓存、备份到iCloud/Google Drive未加密。服务端则涉及数据库访问控制、字段级加密、密钥管理。例如身份证号、基因数据等敏感字段应使用信封加密，密钥与数据分离存放。

使用阶段的风险来自内部越权与二次利用。医生、客服、运维人员可能超出职责范围查询患者数据；数据分析任务可能把可识别信息带入测试环境。应实施基于角色的访问控制与字段脱敏，并对批量导出、异常时段访问进行审计。

共享阶段涉及第三方SDK、科研合作、保险或广告平台。风险包括未获单独同意、共享范围超出约定、接收方二次转售。共享前应做去标识化，并签订数据处理协议，明确用途、留存期限与删除义务。

销毁阶段最容易被忽视。删除App不等于删除服务端数据；数据库逻辑删除后备份仍可能存在；日志、CDN缓存、消息队列中的副本也可能长期留存。应建立数据保留策略，到期后对主库、备份、日志执行可验证的物理或加密擦除。

二、STRIDE与LINDDUN：两种互补的威胁建模视角

STRIDE由微软提出，关注系统安全属性，适合分析“系统会不会被攻破”。它把威胁分为六类：仿冒、篡改、抵赖、信息泄露、拒绝服务、权限提升。在医疗App中，仿冒可能表现为伪造医生账号登录；篡改可能是修改检验报告数值；抵赖可能发生在医生否认开过某张处方；信息泄露对应患者数据外泄；拒绝服务可能让挂号或急救通道不可用；权限提升则可能是普通用户通过接口漏洞读取他人病历。

LINDDUN则专门面向隐私，关注“个人数据会不会被不当关联或披露”。它包含关联、识别、不可否认、可检测、披露、无感知、不合规七类。例如，同一设备ID在多个健康App间被关联，可能推断出用户患有某种慢性病；用户不知道自己的数据被用于训练模型，属于“无感知”；未按法规取得单独同意，属于“不合规”。

实践中，两者应结合使用：先用STRIDE梳理系统组件与信任边界，再用LINDDUN检查每个数据流是否满足隐私原则。例如，对“上传血糖记录到云端”这一数据流，STRIDE会问“传输是否可被篡改”，LINDDUN会问“云端是否会将记录与用户身份长期绑定”。

三、典型攻击面识别与建模落地

攻击面是攻击者可以尝试交互的入口集合。医疗App常见攻击面包括：移动端本地存储、网络接口、蓝牙/WiFi外设、第三方SDK、推送通道、后台管理端、云存储桶、日志与监控系统。识别时可按“入口—资产—信任边界”三步走：先列出所有入口，再标注每个入口能触达的数据资产，最后画出信任边界，明确哪些区域之间需要认证与加密。

下面给出一份可直接用于评审的威胁建模工作表示例，以“血糖记录上传”数据流为例：

最后需要强调：威胁建模的产出不是一张漂亮的图，而是一组可验证的安全需求。例如“传输必须启用证书固定”应转化为测试用例：使用代理工具尝试中间人，若App拒绝连接则通过；“日志不得出现手机号”应转化为代码扫描规则。只有把威胁落到可测试、可审计的控制点，生命周期安全才真正闭环。