第二章 合规法规与标准框架：GDPR、CCPA、个保法、ISO 27001、SOX
说实话，做第三方SDK安全审计，最头疼的往往不是技术细节，而是搞不清该听谁的。
欧洲说GDPR，加州说CCPA，国内有个人信息保护法，还有ISO 27001、SOX这些老牌框架。我曾经在一个跨国项目中，SDK同时服务欧盟、美国和中国用户，合规条款堆了三十多页纸——后来才明白，每套法规都有它的脾气，你要摸清楚它的核心诉求。
核心观点：没有一家SDK能绕开所有法规。你至少要搞清楚目标市场的“硬门槛”，再做减法。
2.1 GDPR：欧盟的“数据铁幕”
GDPR（通用数据保护条例）是2018年生效的。为什么说它影响大？因为它有“长臂管辖”——只要你的SDK处理了欧盟用户的数据，不管公司注册在哪，都得遵守。
我个人习惯把它拆成三个关键词：
- 同意：用户必须主动、明确地同意数据收集。我见过很多SDK在初始化时偷偷调用了定位权限，这在GDPR下直接违法。
- 数据最小化：只收集业务必要的数据。举个例子，一个天气SDK非要拿通讯录，就明显超标。
- 被遗忘权：用户有权要求删除数据。SDK必须提供接口，让宿主App能一键清除用户数据。
避坑指南：我曾经审计过一家广告SDK，它在后台持续上传设备ID和GPS坐标，且没有任何开关让用户关闭。这要是被欧盟监管查到，罚款是年营收的4%或2000万欧元——选高的那个。后来我们给SDK加了“隐私开关”和静默期策略，才算过关。
2.2 CCPA：加州版的“知情权”
CCPA（加州消费者隐私法案）2020年生效。虽然只针对加州居民，但加州经济体量全球第五，所以影响力不小。
CCPA和GDPR最大的区别是什么？说白了，GDPR偏向“禁止”，而CCPA偏向“知情+选择退出”。
- 知情权：用户有权知道SDK收集了哪些数据、卖给谁了。SDK接入文档里必须写清楚。
- 选择退出权：用户可以要求“不要卖我的数据”。很多SDK在设置页面加了一个“Do Not Sell My Personal Information”链接，就是这个原因。
- 非歧视：不能因为用户拒绝了数据收集，就提供更差的服务。
我记得有次给电商App做审计，后台发现广告SDK把用户的购买记录和第三方共享了，但隐私协议里只字未提。这违反了CCPA的“知情权”和“选择退出权”。
2.3 个人信息保护法：中国版数据治理
2021年生效的《个人信息保护法》（PIPL）和我们做SDK的关系最为直接。它的核心逻辑和GDPR类似，但更严苛的地方也不少。
比如：
- 单独同意：收集敏感个人信息（位置、人脸、健康等）必须单独取得用户同意，不能混在通用协议里。
- 影响评估：SDK上线前要做个人信息安全影响评估（PIA）。我参与的项目里，这一步往往是开发最忽略的环节。
- 数据本地化：某些重要数据原则上要存储在中国境内。如果SDK的数据服务器在国外，可能违法。
小技巧：审计时，我通常会检查SDK的“隐私协议”里是否列出了所有三方数据接收方，以及有没有提供撤回同意的入口。很多SDK开发小哥把协议写成“我们可能收集您的信息”这种模糊表述，这在PIPL下是无效的。
2.4 ISO 27001：信息安全的“通用语言”
ISO 27001并不是法律，而是一个国际标准。但它经常被政府或大企业写进采购合同里。如果你的SDK要接入一个大型银行的App，对方很可能要求你通过ISO 27001认证。
它的核心是ISMS（信息安全管理体系）。说白了，就是一套“你如何安全地做事情”的制度。包括：
- 风险评估：知道自己的SDK有哪些风险（比如代码漏洞、数据泄露）。
- 控制措施：比如加密传输、访问控制、日志审计。
- 持续改进：每年要做内审和管理评审。
我个人建议，哪怕不认证，至少参考ISO 27001的框架来搭建安全流程。这样可以少走很多弯路。
2.5 SOX：财务合规的老祖宗
SOX（萨班斯-奥克斯利法案）是2002年美国出的，主要是针对上市公司的财务报告内控。但为什么SDK审计要关注它？
因为如果你的客户是上市公司，而SDK中有支付、订单、用户数据相关功能，这些可能会影响财务报告的准确性（比如收入确认）。SOX要求公司必须对关键数据流有“控制测试”和“审计线索”。
举个例子：如果SDK中的支付模块修改了订单金额而没有日志记录，SOX审计就可能出大问题。
| 法规/标准 | 适用区域 | 核心要求 | 对SDK的典型影响 |
|---|---|---|---|
| GDPR | 欧盟 | 同意、数据最小化、被遗忘权 | 需提供用户数据删除接口 |
| CCPA | 加州 | 知情权、选择退出权 | 需增加“Do Not Sell”按钮 |
| PIPL | 中国 | 单独同意、安全影响评估、数据本地化 | 敏感数据收集需单独弹窗 |
| ISO 27001 | 国际 | ISMS、风险评估、安全控制 | 需建立完整的安全管理文档 |
| SOX | 美国 | 财务内部控制、审计追踪 | 支付等模块必须留痕 |
2.6 框架之间的关系：一张图看懂
你想想看，这么多法规标准，它们之间到底怎么互相影响？我画了一张图，展示核心合规框架的层级和覆盖范围。
嗯，这里要注意。法律层（GDPR、CCPA、PIPL）是底线，不能碰。标准层（ISO 27001等）是靶心，尽量打中。特定领域（SOX、PCI DSS）是附加题，看你的SDK场景是否涉及。
2.7 实际审计中的优先级判断
我遇到过好几个团队，上来就问“我们要不要全部合规？”说实话，资源和时间都不允许。
我建议采用以下优先级：
- 先确定SDK的主要市场：如果主推欧盟，GDPR是必须过的；主推美国，CCPA也得关注；主推国内，PIPL优先。
- 再看客户的行业：如果客户是金融、医疗，ISO 27001可能被写进合同，SOX也可能涉及。
- 最后做差异分析：把目标法规的要求列个清单，和SDK现状一一对比，找到最严重的Gap。
实操建议：我有一个自己的“合规三问”清单，每次审计前都会问自己：
- 这个SDK收集了哪些数据？每个数据是否都有合法理由？
- 用户能否方便地查询、删除或撤回同意？
- 数据存储和传输是否加密？访问控制是否到位？
把这三点答清楚，80%的合规问题就解决了。
好了，这一章我们梳理了五大法规/标准的精髓。它们就像不同国家的交通规则——有的靠左，有的靠右，但核心都是要保障安全。做SDK审计，你不用背下所有条款，但脑子里要有这张框架图。