在监管趋紧的形式下，即时通讯场景会遇到很多安全合规领域的挑战，如何满足这些安全合规的要求，如何保护用户的隐私安全，是一件非常有挑战的事情。
为给大家提供相关的经验及参考，声网联合环信推出了“声网开发者创业讲堂 • 第四期丨创业团队如何保障产品业务的安全合规?”活动，本期特别邀请环信 IM SDK 研发负责人赵亮，以“即时通讯场景下安全合规的实践和经验”为题进行分享。
赵亮具有十余年电信和互联网从业经验，曾主持研发多个明星项目，目前在环信主持即时通讯云 SDK 研发工作。本文基于其在分享中内容二次整理。
安全合规的趋势
1、隐私监管趋紧
最近四五年来，安全合规的趋势变得越来越严格，各个国家都有比较重磅的安全合规的相关法规出台，比如美国加州的《消费者隐私法案》《儿童在线隐私保护法》、保险医疗领域的 HIPPA，以及欧盟推出的比较有代表性的《通用数据保护条例》。国内去年也出台了《个人信息保护法》《数据安全法》，加上之前发布的《网络安全法》，对于安全合规领域的覆盖也比较完善。
2、APP/SDK 趋严
图 1
图 1 所示为国内主要的有关法规和内容，大家如果留意行业新闻的话，也会看到很多这方面的趋势，比如工信部发布的各种应用下架的新闻或者公告，都涉及了个人数据隐私相关的内容。
3、安全合规的基本框架
安全合规的基本框架可以总结成两个方向，一个是用户知情同意，另一个就是安全保障义务。我们以《通用数据保护条例》(GDPR)为例，它是一个法规条文，内容包括各种监管措施、惩罚措施，还规定了应保障的用户权利，后面的介绍中会有一些具体的用户权利说明。
国内外的监管重点
接下来我们分别看一下国内外监管的重点，从国内这几年的角度来看，主要包括以下几个方面。
1、国内 App 上架 —— 信息采集
图 2
如图 2 所示，我们看到用户信息的采集方面受到越来越多的重视，国家部委出台了《常见类型移动互联网应用程序必要个人信息的范围规定》，指出了二三十个场景下能够采集的必要的个人信息。
比如地图导航类，它的基本功服是定位和导航，必要的个人信息为位置信息、出发地和到达地。就是特别简单的几项，其他都是非必要的，所以大家在开发应用的时候一定要确认一下这个信息，否则 App 就无法上架了。
再如网络社区类的，它的基本功能是博客、论坛等，这些个人信息跟即时通讯类的必要信息比较接近，就是用户的移动电话号码和账号联系人信息。网约车类型中也规定了电话号码，包括出发地、到达地、支付时间、支付信息等。大家可能已经留意到了，即时通讯类为什么需要移动电话号码呢?按说不是只需要账号就可以了吗?接下来我们要介绍的内容就解释了这个问题。
2、国内 App 上架 —— 符合安全规定
除了可以采集的必要信息的约束之外，我国还有很多特定的相关不同行业或领域的约束。
在应用的上架流程中，应用商店都有详细的审查规定，如果涉及即时通讯、直播或者用户舆论领域，就需要一个安全评估报告，这个安全评估报告中增加了额外的要求，比如说用户真实身份的核验，就是要核验服务中用户的身份是真实可靠的，这里就回答了前面即时通讯领域的问题，想真正地服务客户，就要能够做到实名制，而实名制其实一般就是通过校验手机和短信的方式。
另外，其实这还涉及用户舆论的问题，需要针对这个问题建立投诉举报的机制，公布投诉举报的联系方式和处理情况，对于这些用户的昵称、信息发布、转发评论等，要有相关的记录保存措施，通过一定的保存机制来支持追查这些信息。这样一方面约束了必要的个人信息的采集;另一方面在不同的领域也补充了额外的要求，比如金融或者医疗领域的要求肯定是更高的。
根据一则新闻通报所示，近期违规下架应用累计为 3000 款左右，涉及的问题大部分是违规收集个人信息，少量是强制或者索取权限相关的问题，国内的应用、网站可能涉及的问题主要就是这些方面。
3、海外的关注 —— ?户权利
如果目标客户是在海外，那么会发现海外的侧重点稍有不同。除了常见的这些安全约束之外，其更关注用户的权利。
我们可以举几个例子，比如用户的知情权、信息获取权、修改权和被遗忘权。知情权就是明确地告知用户要收集哪些信息、信息用来做什么以及保存多久;信息获取权就是用户必须能够导出自己的数据;修改权就是用户可以对个人信息进行修改;被遗忘权就是用户有权利注销和删除自己的数据。Facebook 等海外的大型平台都支持注销账号、导出个人数据等功能，这是海外比较重视的。
图 3
图 3 的案例比较有意思，是说英国的数据保护监管机构向加拿大的一家数据分析公司发出通知，要求其删除所有跟英国公民相关的个人数据，如果不履行义务，将面临着 2000 万欧元或者上一年全球总营业额 4% 的罚款。这里的 2000 万欧元和 4% 的罚款就是《通用数据保护条例》中所做的规定，这个措施是很严格的。
4、共同关注点 —— 数据跨境
国内和国外还有一个共同的关注点，就是热点数据跨境，简单来说就是个人信息和重要的数据应当在境内，这里的在境内应该就是说，比如中国公民的信息和重要的数据不能被随意地存储到境外的服务器上，欧盟地区的数据也不能被随意地存在欧盟以外。其他的地区比如东南亚或者印度，也有当地的法规来约束这些事情，当然这些话题我们就不展开了，这里只是举个例子。
如果确实需要向境外提供，我国的要求是要通过评估办法进行慎重的评估。欧盟则是要求他们认为已经采取足够的安全保护措施的地区可以跨境转移数据，但至少现在为止中国还不在这个名单上，所以欧盟的数据也不能随意存储在中国境内的服务器上。
如何评估和满足安全合规要求经验和建议
了解了安全合规的趋势和相应的重点之后，我们如何评估和满足安全合规的要求呢?首先回溯前面介绍的安全合规的框架。
用户知情同意包括充分告知和权利保障。充分告知就是提供用户隐私协议，权利保障就是用户可以拒绝、可以删除，而且收集的数据要符合最小化原则(最小必要)。
安全保障义务比较复杂，首先，从风险评估、公司内部的制度建设到安全开发流程中都会涉及这个问题，比如产品从需求阶段就要有安全方面的专家确认是否涉及用户数据、用户数据怎么传输、用户数据怎么来保存、是否是必要的，因此从产品需求阶段到方案设计阶段，到最后上线阶段都要有必要的安全评估。
其次是技术保障，这里的技术保障指的是采集过程当中的传输、存储都应当采取足够的技术保障，换算成技术角度就是说，传输过程中要进行传输的加密，存储过程中要进行存储的加密。法律法规不会规定具体的某个安全措施，只是要求采取必要的技术措施保障用户数据的安全。
所以从技术角度侧理解，要采取业内比较标准的或者比较高标准的安全措施，比如 https 默认是使用其他的传输协议，比如 TCP、UDP 等也应当符合业内的安全标准。
当然，安全保障还少不了审计和监管，就是说要有一定的安全开发流程或者安全制度，满足监管机构的监管要求。
1、如何评估安全合规的要求
那么，如何评估安全合规的要求呢。这要看我们具体的涉及的业务，不同领域的要求是不一样的，我们前面提到，金融、医疗领域的要求更加严格。在某些医疗领域，对于医疗用户(患者)的数据或者处理要记录至少 5 年以上，这是该领域的一个特殊要求。另外，针对不同区域用户的要求也不一样，比如刚才提到的东南亚，至少我知道新加坡有自己的特殊规定，其他区域也可能有自己的要求。
客户的行业之间也有不同的安全要求，重要的企业或者事业单位，对于数据库有时会有一些特殊的要求，比如要求必须是国内的数据库，这就是不同的行业或者不同的客户可能面临的特殊要求。还有一个重要的因素就是要评估依赖的第三方。
我们现在开发产品或者服务，免不了要依赖一家甚至多家第三方，这些第三方是否能够满足特定的要求也是特别重要的，因为大多数的应用都会依赖多家第三方，在上架或者遭遇审查的时候，由于第三方因素引起应用下架是很正常的。
最后一个是成本因素，就是说要采取技术措施来保证安全合规的要求，肯定会带来成本的增加，所以从方案角度或者预算角度来说，要考虑这方面的问题。从我们自己的经验来说，比如开启了传输加密和存储加密之后，服务器成本的大概是百分之四五十这个量级的增长，具体数字跟不同的行业和采用的不同技术关联性特别大。
2、产品架构维度
图 4
图 4 展示了产品架构的维度，这里我稍微解释一下，比如一个客户的应用使用了我们的 SDK，一般来说应用也会有自己的 App server，这个 App server 和用户的应用都会跟我们的服务进行交互。我们的 SDK 跟我们的服务器会有两个通道，一个是 TCP 加 TLS，另外一个就是 https。同时用户的应用服务器可能会通过 RESTful 的 API 做一些管理级别的控制，比如创建聊天室或者创建群组甚至封禁用户。
我们的服务还提供了 webhook，就是将消息回调给用户的应用服务器，然后把消息抄送给用户的服务器，甚至是发送前的一个回调。就是说有一些消息内容或者配置的特定消息内容，提前经过用户的服务器进行审查，确认这些消息是否投递。最后管理者用户可以在 console 开发者后台对这些功能进行不同的配置，也可以做一些管理的功能，比如管理某些群组、解散某些聊天室或者封禁用户。同时用户的应用也会跟自己的服务器进行交互，不管是 https 还是其他的协议。
从完整的视角会看到有哪些通道涉及传输，比如用户的应用和他的应用服务器，我们的 SDK 跟我们的服务，服务器跟服务器之间又是一个。此外，我们必须保证这些传输通道的传输安全，不管是用 TLS 或者是其他方式。
用户应用上会存储数据，比如用户名、密码甚至是 token，有的应用可能也会做缓存。还有一些容易忽略的点，比如应用开发的过程当中经常会打印一些 log，在这些 log 当中也要避免用户信息或者敏感信息被泄露，不能使用户的 token 或者密码输出在 log 中。同时，用户应用服务器和我们的服务可能会存储一些用户的消息历史，这些节点和通道都是安全合规角度下必须要确认或者审查的。以开发者后台来看，管理权限级别的账号的保管、账号丢失之后的处理都要有相关的考虑。
3、数据处理流程的维度
从用户数据处理流程的维度来看，一个数据的处理流程主要涉及数据的采集、传输、存储、处理、擦除与销毁、对第三方提供以及用户隐私权利的保障，如图 5 所示。
图 5
采集过程当中首先要进行充分的告知，一般在网站或者应用中都会有一个收集到的隐私协议的说明，包括收集的目的、收集到的个人用户数据的范围、采集的期限等，其中采集期限是很容易被忽略的。传输过程和存储过程是典型的数据处理流程，涉及传输加密和存储加密技术。数据处理过程则要符合收集的目的，遵循准确、必要等原则，不能任意对用户来数据进行操作，要有特定的目的才能做数据处理。擦除与销毁过程要求及时和彻底。
对第三方提供过程也是比较关键的，我们经常会借用第三方的内容审核或类似于 APM 的工具，对于这些第三方工具需要仔细进行检查，确保提供相同的保障条件。最后，用户隐私权利保障过程除了要明确用户是自愿选择之外，还要保证用户可以注销或删除账号，并对这些操作进行及时的响应。
经验和建议
前面给出了满足和评估安全合规的维度，接下来分享一下我们的经验和建议。当然，这些经验和建议是基于即时通讯领域的。
1、安全合规能?建设需要做什么
在过去一段时间内我们同外部的咨询机构进行了合作，对我们流程的进行了审查，然后声网的安全合规团队也帮助我们梳理了相关的安全内容，这个团队包括技术、架构、合规、运营、隐私、开发等多个方向的专家。
当然，初创企业可能还不需要做这么多的安全合规的能力建设，如果是发展到一定规模或者中等规模的公司，可能就要做一些安全能力的建设，比如 GDPR 中提到员工超过 250 人，需要对数据处理加以记录。
我们进行了安全开发流程的建设，对于安全开发流程前面也简单提过，公司内部的开发流程中在产品需求阶段、设计阶段、验收阶段都要有安全方面的介入，以确认是否涉及用户数据、是否是必要的、是否遵循最小原则等。在这些过程当中还会进行每年度甚至半年度的审查，确认整个流程过程当中有没有安全问题以及在合规方面有没有漏洞，这是我们过去两年做所做的安全合规能力建设。
2、目前安全合规的能力
经过这些建设之后，我们有了足够的安全基础，可以进行全流程的传输加密和存储加密;还具备了资源隔离的能力，支持多数据中心、支持国内国际不同区域的合规要求。针对隐私合规，根据最小化和公开透明的处理原则，满足了不同区域的网络安全和数据安全的要求，能够对必要的用户数据进行脱敏处理;用户权益的 API 方面支持用户数据的导出和删除。
3、开发建议 —— 即时通讯领域
不管是借助第三方的能力还是自研的能力，如果在即时通讯或者教育领域有了一定的用户量之后，肯定会遇到一些问题。我给出了一些建议，首先如果使用第三方，一般会注册一些信息，这时最好是由你的服务器来下发，不要内置在应用中，否则信息容易泄露。
第二个是比较关键的信息，就是保护好用户列表。比如在已经具备一定的用户量之后，如果此时被拖库或者网站被攻击，用户可能会收到广告或者一些灰产信息，所以用户列表就比较关键了，不管用户是不是通过手机号注册，用户 ID 要散列，而且不要对用户可见。
另外，我们的服务端有类似于全员通知的功能，针对全员通知这个功能，我们添加了相应的白名单功能，在配置好之后，只有某个特定的服务器才能给全员发通知。如果你的业务能够开启好友之间发消息的限制，最好就开启，这样即使用户 ID 被泄露，他们也不能随意地相互之间发消息。
服务器校验用户的合法性也是一个非常重要的功能，如果是直接在第三方平台上注册的用户，那么他有可能会直接绕过你的服务器来给其他的用户来收发消息。这种情况建议还是由你的服务器来签发 token，然后保证这个 token 一定的时效性，时间不要太长，这样即便某个用户有问题，你的服务器也可以及时发现并且封禁这个用户。
如果有更进一步的安全要求，甚至可以在消息级别进行校验，比如这个消息有特定的 Key 签发密钥，则消息的收发双方都要做相应的校验，甚至端到端的消息加密。
当然现在我们也支持了内容审核的功能，可以在我们的后台配置相应的审核规则。除了前面的保护措施之外，还要做一些内部防范，对类似于开发者证书或者内部的用户列表等关键数据一定要进行相应的保护，比如备份这些数据库的信息，不要被开发者不经意间放到 GitHub 或某个技术博客上。
问答环节
1、很多开发者会有这样一种想法，比如说我接入了某个第三方安全审核功能后，是不是就可以高枕无忧了?
这个显然不是，就是现在的鉴黄，也没有 100% 的能力完全做到这一点。我们肯定还是要做一些措施，比如能做到监督，这样事后有记录就能对他进行管理甚至封禁，而不只是说扔给第三方。
2、您在演讲中提到加密会使服务器的成本开销较大，那么有哪些加密方式是您建议一定要启用的，MD 5 和 AES 256 方式您建议使用哪一种呢?
如果是对称加密的话，建议是 AES 256 以上。成本方面没有明确的答案，这与数据块有关系，如果我们的消息都是比较小的，那么数据增加可能会比较明显。而对于大一些的消息，比如文件级别的甚至更大，数据增加可能少一些。所以这没有一个很明确的规律，但是肯定会对你的成本有所增加。
3、如果个人要求删除个人数据，主要是与 App 运营厂商处理，还是像这种提供 PaaS 服务的平台来进行联动处理呢?
我们的 PaaS平台一般是要提供能力，但我们还有观察到一些 PaaS 的主要提供商都不是直接给用户的，而是给应用的开发者。我们有用户级别的 token 和管理员级别的 token，我们现在的用户隐私相关 API 设计都是管理员级别的，就是说用户要求注销账号或者删除数据的时候，一般是经过应用的 owner 和应用的服务器使用这些第三方平台来完成的，否则可能数据删除的处理不完整。第三方平台一般是提供这部分能力。
4、初创公司应该如何做产品或者技术合规的审查?
这个问题我在介绍的过程当中其实也提到了，对于不同的行业和领域，要求都不太一样。一般来说，比如在华为或者苹果的应用商店上架应用，都会选择不同的应用分类，选择特定的分类之后，就会有一些特定的要求，有的会要求你的资质，有的会要求安全评估报告。
也就是说，要根据应用的所属行业或者你的业务属性来确定，只要满足这些要求一般不会有太大的问题。而且你对于自己的应用所属的领域行业都有基本的了解，可以在上架之前把这些要求大致了解清楚，提前做好准备，否则被打回再重新修改上架，也会影响产品的上线计划。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
