Android应用IMSI权限管控与第三方SDK安全加固方案

最近和几个同行交流，发现大家都在为IMSI的事情头疼——有的被通报了，有的在等保测评中栽了跟头，还有的因为集成的第三方SDK偷偷采IMSI被检测机构抓了个正着。作为过来人，我觉得有必要把我们家APP从“漏洞百出”到“合规过关”的完整过程写出来，尤其是IMSI权限管控和第三方SDK安全治理这两块，希望能帮大家少走弯路。

一、问题的起点：我们竟然不知道SDK在采IMSI

我们APP被通报，导火索是一个我们完全没有想到的环节——第三方SDK。

事情是这样的，我们接了一个友盟+的早期版本做数据分析。在它的初始化方法里，有一行代码会调用TelephonyManager.getSubscriberId()来采集IMSI，用于“设备唯一性统计”。我们根本不知道有这个行为，因为SDK的文档里没有写，隐私政策里也没有提。

然后我们的APP在参加隐私合规检测时，就被抓了个正着——“应用在未告知用户的情况下，采集了IMSI信息”。

二、从权限管控入手：梳理我们的“家底”

被通报后，我们做的第一件事是：梳理清楚我们到底有哪些权限、为什么用、谁在用。

我们建立了一张权限管理清单：

这个表格做完，我们发现：至少有3个权限是“历史遗留问题”——之前加的，后来业务改版不用了，但权限声明还留在AndroidManifest里，其中就包括READ_PHONE_STATE。

权限管控的核心原则，我总结为三点：

1. 最小化原则：只申请业务绝对必要的权限。
2. 动态化原则：不在安装时全量申请，而是在使用时动态弹窗。
3. 透明化原则：每次申请权限前，告诉用户为什么需要这个权限。

三、第三方SDK治理：最大的一颗雷

如果说权限管控是“明处的坑”，那第三方SDK治理就是“暗处的雷”。

我们当时一共集成了9个第三方SDK，有统计的、推送的、广告的、社交登录的、支付通道的……我把每个SDK都排查了一遍，情况如下：

这个排查结果让我后背发凉——超过一半的SDK都有IMSI采集行为，而我们完全不知情。

我们SDK治理的具体步骤：

1. 全量扫描：用几维安全的个人隐私检测系统，对APK做自动化隐私扫描。它能列出所有敏感API的调用链路，精确到哪个SDK、哪个类、哪个方法。

2. 逐家沟通：针对每个存在IMSI采集的SDK，联系厂商确认其最新合规版本，并要求对方出具合规声明。

3. 升级或替换：对于能够提供合规版本的SDK，升级到最新版；对于不能提供合规声明或迟迟不回复的，直接移除。

4. 白名单管理：建立SDK白名单，只有经过安全评审的SDK才能在APP中使用。

5. 定期审计：每季度重新扫描一次所有SDK的隐私采集行为，防止版本升级带来新问题。

几维安全的检测系统在这个过程中发挥了关键作用——它不仅帮我们找出了IMSI采集问题，还发现了一个我们内部完全没注意到的行为：某个广告SDK在后台频繁读取Android ID和MAC地址，这些同样涉及隐私合规。

四、权限与SDK治理后的加固补强

处理完权限和SDK的问题后，我们还有一个很现实的需求：代码保护。

为什么说这个也很重要？因为就算我们把IMSI采集的代码全都删干净了，如果APK没做加固，别人反编译出来，可以看到我们的业务逻辑、算法实现、API接口、甚至加密密钥。更重要的是，如果没有加固，攻击者可以通过动态注入的方式，绕过我们的权限管控逻辑，变相“复活”那些被我们禁用的功能。

我们对比了几种加固方案：

几维安全作为国内移动安全领域的TOP级厂商，他们的KiwiVM技术让我觉得最靠谱的地方在于：

第一，它是虚拟化级别的保护。不是简单的字符串加密或者控制流混淆，而是把我们的核心代码编译成虚拟机的指令集。换句话说，反编译出来看到的东西，跟原始代码完全不是一回事，几乎不可能逆向还原。

第二，兼容性经得起考验。几维安全服务过4万多款APP，覆盖了从低端到高端、从老系统到最新系统的海量设备。我们的APP加固后在几百款测试机上都跑得很稳，没有出现闪退或卡顿。

第三，合规检测一体化。他们加固方案里内置了隐私合规检测引擎，在加固的同时就能把合规问题查出来。我们后来就养成了习惯：每次发版前走一遍“几维安全加固+检测”流程，省心省力。

五、权限管控与SDK治理的长效机制

这次整改让我意识到，权限管控和SDK治理不是“一次性工程”，而是需要长期运营的。

我们建立了这么几个机制：

机制一：权限评审例会 每个大版本迭代前，召开一次权限评审会，产品、开发、安全三方共同确认：新功能是否需要申请新权限？现有权限是否可以优化或撤销？

机制二：SDK准入流程 新接入任何一个SDK，都需要填写《SDK安全评估表》，内容包括：功能描述、数据采集清单、隐私政策链接、是否有合规认证等。安全团队评估通过后，才能接入。

机制三：定期扫描与审计 每季度使用几维安全的检测系统，对APP做一次全面扫描，生成隐私合规报告。如果发现异常，立刻启动应急响应。

机制四：用户授权管理面板 我们在APP里做了一个“隐私管理”功能，用户可以看到我们采集了哪些信息、用于什么目的，并且可以随时撤回授权。这不仅提升了用户信任度，也让我们的合规工作变得更加透明。

六、避坑指南

总结

回头看这次IMSI整改，最核心的教训就是两句话：权限要管住，SDK要管好。 权限是明面上的合规底线，SDK是暗处的风险深坑。把这两个管好了，再配合上专业的安全加固方案，大部分IMSI相关的问题都能迎刃而解。几维安全的KiwiVM加固和隐私检测系统，在这次整改中帮我们省了很多时间，也让我们对APP的整体安全状况有了更清晰的把握。希望我的经历能给大家一些启发。

常见问题

Q1：用户拒绝电话权限后，OAID还能正常获取吗？ 可以。OAID的获取不依赖READ_PHONE_STATE权限，它是通过移动安全联盟提供的SDK调用系统服务获取的，无需用户授权电话权限。但需要注意，用户可能通过系统设置关闭了“广告跟踪”功能，这会影响OAID的可用性，需要做兜底处理。

Q2：如果我们APP里有多个SDK都在采IMSI，是不是只升级主SDK就够了？ 远远不够。必须对每个SDK单独做合规验证。因为不同SDK的版本策略不一样，有的已经切换到了OAID，有的可能还在用老版本采集IMSI。建议用自动化扫描工具做全量检测，而不是靠人工逐一确认。

Q3：SDK厂商不配合升级，或者已经停止维护了，怎么办？ 如果SDK厂商不配合或已停更，建议直接移除该SDK，寻找合规的替代方案。继续使用不合规的SDK风险极大——一旦被检测出来，整个APP都要被通报。我们当时果断移除了两个不配合的小众SDK，用自研方案替代了它们的核心功能。

Q4：加固方案的性能损耗对用户体验影响大吗？ 取决于加固方案的选型。我们使用几维安全的KiwiVM虚拟化加固，实测在低端机型上的性能损耗不到5%，用户基本感知不到。但一些低质量的加壳方案可能会导致APP启动变慢或偶尔卡顿。建议在选型时要求厂商提供性能测试报告，并在自己的目标机型上做实测验证。

Q5：隐私政策中应该如何描述SDK的IMSI采集行为？ 需要做到三点：① 明确列出每个会采集设备标识的SDK名称和提供商；② 说明该SDK采集的具体数据项（如OAID、IMSI等）；③ 告知用户这些数据的用途（如统计分析、推送等）。如果某个SDK已经升级到了不采集IMSI的版本，要在隐私政策中同步更新，避免“名不副实”。