1. 医疗App隐私与安全工程导论

医疗App与普通消费类App最根本的差别，不在于界面或功能，而在于它处理的数据对象。一次挂号、一次血压记录、一张检验报告、一段用药提醒，背后都是可识别到具体个人的健康信息。这类数据一旦泄露或被篡改，后果往往不是"换个账号"就能挽回的：它可能影响就业、保险、婚恋，甚至造成歧视与人身风险。因此，医疗App的隐私与安全工程，本质上是一门"以数据为中心、以风险为尺度、以合规为底线"的工程学科。

一、课程定位：从"能跑"到"可信"

本课程面向医疗App的研发、测试、运维与合规人员，目标不是培养密码学专家，而是让工程团队具备三方面能力：第一，能识别医疗数据在采集、传输、存储、使用、共享、销毁各环节的风险点；第二，能选择并落地恰当的技术控制措施，如传输加密、字段级脱敏、访问控制、审计日志；第三，能把法规要求翻译成可验证的工程指标，而不是停留在"我们很重视隐私"的口号上。

换句话说，课程关注的是"可信"这一非功能属性如何被工程化：它既要有技术实现，也要有流程约束，还要有可被检查的证据。

二、医疗数据的特殊性

医疗数据与一般个人信息的差异，可以归纳为四点：

• 高度敏感且不可撤销：诊断、用药、基因、影像等信息一旦泄露，无法像密码那样"重置"。
• 强关联性：单条数据看似无害，但多条组合后可重新识别个人。例如"某小区+某罕见病+某年龄段"往往唯一指向一个人。
• 多方流转：数据常在患者、医院、第三方检验、云服务、科研机构之间流动，责任边界复杂。
• 合规约束密集：涉及《个人信息保护法》《数据安全法》《网络安全法》，以及医疗行业特有的病历管理、人类遗传资源等规定。

这四点决定了医疗App不能照搬电商或社交App的安全方案。电商可以接受"低价值数据+高便利"，医疗则必须坚持"高敏感数据+最小必要"。

三、隐私与安全工程的目标

安全与隐私常被混用，但目标并不相同。安全工程关注机密性、完整性、可用性：数据不被未授权读取、不被篡改、在需要时可用。隐私工程关注可识别性、目的限制、最小必要、用户控制：数据是否必须收集、是否只用于声明目的、用户能否知情并撤回同意。

两者在医疗场景中必须协同。例如，加密能保护机密性，但如果App把用户手机号明文写进日志，加密就形同虚设；再如，访问控制能限制内部人员，但如果采集时超范围收集，后续再严的控制也无法弥补"本不该收"的问题。因此，工程上通常把隐私要求前置到需求与设计阶段，安全措施贯穿开发、上线与运营。

四、法规与伦理约束

法规给出的是底线，伦理给出的是更高标准。以《个人信息保护法》为例，处理敏感个人信息需取得单独同意，并告知必要性与影响；医疗健康信息属于敏感个人信息，这意味着App不能用一个笼统的"用户协议"打包所有授权。工程上对应的做法是：把同意拆分为可勾选、可撤回、可追溯的条目，并记录同意时间、版本与范围。

伦理层面则要求"不伤害、行善、尊重自主、公平"。落到工程上，就是不做诱导性授权、不默认勾选、不因拒绝非必要权限而拒绝提供核心医疗服务。这些不是抽象口号，而是可以直接转化为界面与接口设计的约束。

五、整体知识地图

本课程后续内容围绕一条主线展开：数据从产生到销毁的全生命周期，并在每个环节叠加"风险—控制—验证"三层视角。下图给出整体知识地图，帮助建立全局认知。

这张地图的读法是：横向是数据生命周期，纵向是"风险—控制—验证"三层。任何一个具体问题，都可以定位到"某个环节的某一层"。例如"第三方SDK把设备号上传到广告服务器"，属于采集/共享环节的风险层，对应控制层是SDK清单管理与最小化采集，验证层则是抓包核查与隐私政策一致性检查。

六、一个可操作的最小示例

为了让抽象目标落地，这里给出一个教学示例（参数为合理假设，非实测结果）。假设某血压记录App需要上传一条记录，字段包括：用户ID、收缩压、舒张压、测量时间、设备型号。工程上可按如下方式处理：

原始字段：userId=U10086, sbp=138, dbp=88, time=2025-03-01T08:12, model=BP-200

处理策略：
1. 传输：HTTPS + 证书固定（Certificate Pinning）
2. 存储：userId 单独加密存储，血压数值与时间以明文列存储但整库加密
3. 日志：仅记录 requestId 与状态码，禁止打印 userId 与血压值
4. 共享：默认不上传设备型号；若用于兼容性统计，需先做去标识化并单独告知

验证要点：
- 抓包确认无明文 userId
- 查看日志文件确认无血压数值
- 关闭"兼容性统计"开关后，确认请求体中 model 字段消失

这个示例说明：隐私与安全不是一次性动作，而是"设计时就决定字段怎么流、在哪一层被保护、用什么证据证明它被保护"。