合规安全大考核：移动应用安全策略全盘点

谁借莪１个温暖的怀抱￠ 2022-09-10 12:22 212阅读 0赞

**简介：** 移动应用涵盖用户大量个人数据，一旦发生泄漏可能对个人、社会造成重大影响，同时对移动应用产业长远的发展来说也是毁灭性打击。移动应用开发者，也应注意开发过程中的规范性、安全性，敬畏安全问题，防范合规风险。

![科学防疫教室消毒防疫手绘首图.jpg][.jpg]

据统计，每年至少新增 150 万种移动恶意软件，至少造成超过 1600 万件的移动恶意软件攻击事件。

而 Android 因其开放性的生态环境，安全问题更是相当严峻。在应用市场上，很多 Android App 都存在潜在的安全风险，一旦被利用，会给用户和开发者带来很大影响。

同时，伴随《网络安全法》以及《个人信息保护法》等相关法律法规的出台和落地，移动应用开发者们也需要协同政府部门，共同营造安全的移动应用环境，促进网络安全的规范化、安全化、健康化发展。

为帮助移动开发者有效应对应安全要求，mPaaS 内很多模块都采用了安全策略：

*  移动应用安全加固
 *  隐私合规检测
 *  RPC 的加签加密
 *  离线包的签名校验
 *  移动同步的tcp+ssl机制
 *  热修复的加密配置

……

本文将为大家介绍上述常见 mPaaS 关于安全设计的几种模块，便于后续更好的使用。

# 隐私合规检测 #

随着政策法规及监管标准不断细化深化，监管查处力度的不断加大，App 开发方需要面临的政策风险也在逐步增加。

mPaaS 隐私合规检测服务，依据国家相关法律法规及行业规范，对移动 App 隐私安全、个人数据收集和使用进行合规分析。

从个人信息收集、权限使用场景、隐私政策等多个维度帮助企业及 App 开发者识别安全风险，提供对应的专家整改建议，助力客户规避监管处罚及通过审核上架。

![4C3AB18F-79FD-41d2-B784-B751D3E36147.png][]

# 移动安全加固 #

结合着阿里内部移动应用安全加固能力的升级，我们现已在 mPaaS 中对外输出移动应用安全加固能力。

针对市面上移动应用普遍存在的破解、篡改、盗版、钓鱼欺诈、内存调试、数据窃取等各类安全风险，mPaaS 移动安全加固为 App 提供稳定、简单、有效的安全防护，提升 App 整体安全水平，力保 App 不被破解和攻击。

在应对 Android 常见的攻击手段，比如 反编译、二次打包、动态调试等的同时，我们也注重性能和兼容性。

*  加固能力经历了淘宝、菜鸟等上亿业务的实践，在安全性上有保障；
 *  在兼容性上，我们支持 4.2 到 Android Q 的 版本；
 *  能够支持 arm、x86、x64 的系统架构，在复杂的环境下稳定运行，奔溃率低；
 *  另外，通过对于类的混淆保护，增加攻击者逆向 App 的难度，让攻击无从下手。

![b6c4eb7e176a49c588a0d381452cb470.png][]

# RPC #

作为 mPaaS 最重要的组件之一，RPC 提供了客户端和服务端的安全通信通道，其中涉及安全的主要包括加签和加密。其中加签解决的是防止客户端被伪造，加密解决的是防止请求数据被泄漏。

### 1 加签 ###

![1.png][]

整体流程：

1.  在 mPaaS 后台初始化应用的时候，会为每一个 App 创建一个唯一的appSecret；
2.  客户端通过appid、WorkspaceID、appSecret等信息，生成无线保镖图片。通过无线保镖模块的加密，保证了存放在客户端的 appSecret 的安全性；
3.  客户端请求的时候，从无线保镖获取 appSecret，同时添加 OperationType、time、requestData 等因子做 MD5 计算，添加到 header 发到 MGS 网关；
4.  MGS 收到后按照同样的方法再计算一次 MD5，如果一致，则通过校验。

优势：通过无线保镖机制，保证了内置在客户端内的 appSecret 的安全性。

### 2 加密 ###

![2.png][]

整体流程：

1.  通过 openssl 生成非对称秘钥，客户端保存公钥，服务端报错私钥；
2.  客户端每次请求 RPC 都会生成一个新的对称秘钥，通过第一步生成的非对称秘钥进行加密，生成 SecKey；
3.  客户端使用对称密钥同时对原始数据进行加密，得到加密的数据 SecData；
4.  移动网关通过保存的私钥对 SecKey 进行解密得到对称密钥；
5.  通过上一步得到的对称秘钥，对加密数据SecData进行解密，得到原始数据。

优势：RPC 的加密采用了混合加密的模式，使用了非对称加密和对称加密的组合。如果单纯使用对称秘钥，虽然性能较好，但是保证不了足够的安全性。如果单独使用非对称加密，虽然保证了安全性，但是会导致性能变差，不适合RPC这种大量通信的场景。

所以RPC采取的这种混合加密模式，很好的结合了两者的优点。

### 3 防抓包 ###

在客户端端为了防止数据被抓包软件抓到，客户端进行了防止抓包的设置，通过设置网络库禁止代理的方式，解决了被抓包的风险。代码如下：

![carbon.png][]

# 离线包 #

作为业务使用很多的离线模块，为了保证下发到本地的离线包模块没有被篡改，离线包提供了签名校验机制。

整体流程：

1.  提前通过 openssl 生成公钥和私钥，公钥内置在客户端内，私钥存储到服务端；
2.  离线包打包的时候，服务端对当前离线包的文件做 MD5 计算，然后将计算后的值通过非对称秘钥进行加密生成加密后的签名数据，随离线包下发到客户端；
3.  客户端每次打开离线包的时候，通过客户端内的公钥获取下发的 MD5 和本地的离线包文件做 MD5 对比，如果一致，则校验通过，如果不一致，则删除离线包，直接访问 fallback 资源。

![3.png][]

优势：

*  由于是每次打开离线包都做校验，保证了离线包的来源正确和不被篡改;
 *  校验失败后直接降级到fallback地址，减少对客户使用的影响

# MDS 实时发布 #

MDS 实时发布服务提供了 apk 的发布功能，同时为了保证下载的 apk 文件不被篡改，提供了基于 MD5 的完整性校验。

在上传 apk 的时候，会基于当前的 apk 生成 MD5 下发，本地安装的时候本地下载文件的 MD5 和会和服务端下发的 MD5 做匹配，如果匹配成功才会继续安装。

服务端下发的 MD5 字段如下图所示:

![4.png][]

# MSS 移动同步 #

移动同步服务 Sync 是基于 TCP 进行通信的，为了保证安全，Sync 可以配置为 TCP+SSL 模式进行通信。

当指定 Sync 的端口号为 433 端口后，客户端就会开始基于 TCP+SSL 实现长连接，长连接请求到服务端后，需要通过 F5 或者其他类似负载装置完成 SSL 卸载，最后到 MSS 实现长连接。

整体流程如下图所示：

![5.png][]

# 结语 #

随着移动应用的迅猛发展，用户对于移动应用涉及到的隐私问题、安全问题日益关注。

移动应用涵盖用户大量个人数据，一旦发生泄漏可能对个人、社会造成重大影响，同时对移动应用产业长远的发展来说也是毁灭性打击。

移动应用开发者，也应注意开发过程中的规范性、安全性，敬畏安全问题，防范合规风险。

本文作者：阿里云 mPaaS TAM 团队（荣阳）

[原文链接][Link 1]  
本文为阿里云原创内容，未经允许不得转载。

[.jpg]: /images/20220829/1b3539c7d00b49dd8cd6dfcd46a97062.png
[4C3AB18F-79FD-41d2-B784-B751D3E36147.png]: /images/20220829/0448a4f8d63e423abc2a514be6dbc10c.png
[b6c4eb7e176a49c588a0d381452cb470.png]: /images/20220829/9b0149679e2f423eb96925bf89245cf2.png
[1.png]: /images/20220829/6ed6619380ea4c80b079e41958f145a9.png
[2.png]: /images/20220829/2376e47143414f57be1e94c82861ab53.png
[carbon.png]: /images/20220829/ac9c361762f6434a92208abb7ede7bf6.png
[3.png]: /images/20220829/cd4aa0c861894f278f141e22ca5fe724.png
[4.png]: /images/20220829/970c043c61544474bcc4a60ca8089a91.png
[5.png]: /images/20220829/2fcede44196543a6be8c803aaae24d11.png
[Link 1]: http://click.aliyun.com/m/1000294131/