前言
随着移动互联网和 5G 通信新技术的浪潮席卷全球，传统的通信方式已经发生了翻天覆地的变化。人们已经习惯了通过即时通讯软件和网络交流平台分享自己生活的方方面面，随着人们越来越公开自己的生活，人们也开始关注隐私和安全等问题。
隐私作为人们不愿为他人知晓的私密空间、私密活动和私密信息，历来被互联网用户所关注。尤其是在即时通讯服务的使用过程中，用户可以轻易将自己的隐私传输至互联网上，这使得用户在享受便捷服务的同时，更容易因隐私泄露而影响生活安宁。近些年来各类隐私泄露事件更是让人们在享受便捷的互联网服务时，对网络服务提供者的隐私保护能力持怀疑态度。甚至在某种程度上，隐私保护逐渐成为用户选择网络服务时考虑的重要因素。为了保护用户的隐私， 世界各地都相继出台了隐私保护相关的法律法规，使得企业的隐私保护合规工作更加具有挑战性。
作为全球互联网消息云的开创者和引领者，数据和用户隐私安全是环信最关切的问题。环信始终将数据和用户隐私安全作为首要安全原则，并将其作为理念融入安全能力建设当中，2021 年环信行业首家通过了史上最严格的数据保护法案“GDPR”的相关安全合规标准。
为帮助开发者及用户感知和理解环信在即时通讯服务上的努力，了解环信服务的安全属性，CSDN联合环信特发布即时通讯行业首个《安全合规白皮书》。该白皮书全面分析了安全合规的趋势及国内外监管重点，同时给出环信在即时通信领域安全合规开发的经验及建议，还列举了环信云服务的相关安全和合规工作，希望能够为业界提供了全面、详实的安全能力建设参考。
下载地址：https://www.easemob.com/product/im
目录
1.安全合规的趋势
1.1隐私监管趋紧
1.2APP/SDK 趋严
1.3安全合规的基本框架
2.国内外的监管重点
2.1国内 App 上架-信息采集
2.2国内 App 上架-符合安全规定
2.3海外的关注-⽤户权利
2.4共同关注点-数据跨境
3.如何评估和满⾜安全合规要求
3.1如何评估安全合规的要求
3.2产品架构维度
3.3数据处理流程的维度
4.安全合规开发经验及建议
4.1安全合规能⼒建设需要做什么
4.2⽬前安全合规的能⼒
4.3开发建议-即时通讯领域
5.环信安全合规、隐私保护及相关认证
5.1环信安全合规和隐私保护
5.2安全标准和认证（GDPR）
6.环信即时通讯 PaaS 服务的安全
6.1数据中心计算资源安全
6.2SDK 安全
6.3RESTful API 安全
7.数据安全
7.1数据安全政策
7.2数据采集
7.3数据脱敏
7.4数据保护和加密传输
7.5数据使用和存储
7.6用户的数据权利
8.安全运营
8.1安全开发生命周期管理 SDL
8.2反入侵和安全监控
8.3安全应急响应机制
8.4安全合作
9.APP 开发者接入环信 SDK 的合规要求
9.1隐私政策内容合规
9.2隐私政策展示形式合规
10.结语
引言
在监管趋紧的形式下，即时通讯场景会遇到很多安全合规领域的挑战，如何满足这些安全合规的要求，如何保护用户的隐私安全，是一件非常有挑战的事情。
一、安全合规的趋势
1.1 、隐私监管趋紧
最近四五年来，安全合规的趋势变得越来越严格，各个国家都有比较重磅的安全合规的相关法规出台，比如美国加州的《消费者隐私法案》《儿童在线隐私保护法》、保险医疗领域的 HIPPA，以及欧盟推出的比较有代表性的《通用数据保护条例》。国内去年也出台了《个人信息保护法》
《数据安全法》，加上之前发布的《网络安全法》，对于安全合规领域的覆盖逐渐比较完善。
1.2 、App/SDK 趋严
图 1 所示为国内主要的有关法规和内容，而且这个趋势也是越来越严格，比如工信部发布的各种应用下架的新闻或者公告，都涉及了个人数据隐私相关的内容。
1.3 、安全合规的基本框架
安全合规的基本框架可以总结成两个方向，一个是用户知情同意，另一个就是安全保障义务。我们以《通用数据保护条例》（ GDPR ）为例，它是一个法规条文，内容包括各种监管措施、惩罚措施，还规定了应保障的用户权利，后续章节将介绍一些具体的用户权利说明。
二、国内外的监管重点
关于国内外监管的重点，从国内这几年的角度来看，主要包括以下几个方面：
2.1 、国内 App 上架 —— 信息采集
如图 2 所示，用户信息的采集方面正受到越来越多的重视，国家部委出台了《常见类型移动互联网应用程序必要个人信息的范围规定》，指出了二三十个场景下能够采集的必要的个人信息。
比如地图导航类，它的基本功能是定位和导航，必要的个人信息为位置信息、出发地和到达地。开发者在开发应用的时候首要确认相关信息，如果收集了其余非必要数据App 就无法上架。
再比如网络社区类应用，它的基本功能是博客、论坛等，这些个人信息跟即时通讯类的必要信息比较接近，诸如用户的移动电话号码和账号联系人等信息。网约车类型中也规定了电话号码， 包括出发地、到达地、支付时间、支付信息等。为什么即时通讯类需要移动电话号码呢？一般认为是只需要账号就可以了？接下来的篇幅就解释了这个问题。
2.2 、国内 App 上架 —— 符合安全规定
除了可以采集的必要信息的约束之外，我国还有很多特定的相关不同行业或领域的约束。
在应用的上架流程中，应用商店都有详细的审查规定，如果涉及即时通讯、直播或者用户舆论领域，就需要一个安全评估报告，这个安全评估报告中增加了额外的要求，比如说用户真实身份的核验，就是要核验服务中用户的身份是真实可靠的，这里就回答了前面即时通讯领域的问题，想真正地服务客户，就要能够做到实名制，而实名制其实一般就是通过校验手机号和短信等方式。
另外，其实这还涉及用户舆论的问题，需要针对这个问题建立投诉举报的机制，公布投诉举报的联系方式和处理情况，对于这些用户的昵称、信息发布、转发评论等，要有相关的记录保存措施，通过一定的保存机制来支持追查这些信息。这样一方面约束了必要的个人信息的采集； 另一方面在不同的领域也补充了额外的要求，比如金融或者医疗领域就有更高级别的相关要求。
根据工信部数据显示，近期违规下架应用累计为 3000 款左右，涉及的问题大部分是违规收集个人信息，少量是强制或者索取权限相关的问题，国内的应用、网站可能涉及的问题主要集中在这几个方面。
2.3 、海外的关注 —— 用户权利
如果目标客户是在海外，那么会发现海外的侧重点稍有不同。除了常见的这些安全约束之外， 其更关注用户的权利。
举几个例子，比如用户的知情权、信息获取权、修改权和被遗忘权。知情权就是明确地告知用户要收集哪些信息、信息用来做什么以及保存多久；信息获取权就是用户必须能够导出自己的数据；修改权就是用户可以对个人信息进行修改；被遗忘权就是用户有权利注销和删除自己的数据。Facebook 等海外的大型平台都支持注销账号、导出个人数据等功能，这些是海外比较重视的方面。
图 3 案例所示，英国的数据保护监管机构向加拿大的一家数据分析公司发出通知，要求其删除
所有跟英国公民相关的个人数据，如果不履行义务，将面临着 2000 万欧元或者上一年全球总
营业额 4% 的罚款。这里的 2000 万欧元和 4% 的罚款就是《通用数据保护条例》中所做的规定，从中不难看出这个措施是非常严格的。
2.4 、共同关注点 —— 数据跨境
国内和国外还有一个共同的关注点，就是热点数据跨境，简单来说就是个人信息和重要的数据应当在境内，这里的在境内应该就是说，比如中国公民的信息和重要的数据不能被随意地存储到境外的服务器上，欧盟地区的数据也不能被随意地存储在欧盟以外。其他的地区比如东南亚或者印度，也有当地的相关法律法规来约束。
如果确实需要向境外提供数据，我国的要求是要通过评估办法进行慎重的评估。欧盟则是要求他们认为已经采取足够的安全保护措施的地区可以跨境转移数据，但至少现在为止中国还不在这个名单上，所以欧盟的数据也不能随意存储在中国境内的服务器上。
三、如何评估和满足安全合规要求
了解了安全合规的趋势和相应的重点之后，我们如何评估和满足安全合规的要求呢？首先回溯前面介绍的安全合规的框架。
用户知情同意包括充分告知和权利保障。充分告知就是提供用户隐私协议，权利保障就是用户可以拒绝、可以删除，而且收集的数据要符合最小化原则（最小必要）。
安全保障义务比较复杂。首先，从风险评估、公司内部的制度建设到安全开发流程中都会涉及这个问题，比如产品从需求阶段就要有安全方面的专家确认是否涉及用户数据、用户数据怎么传输、用户数据怎么来保存、是否是必要的等等，因此从产品需求阶段到方案设计阶段，到最后上线阶段都要有必要的安全评估。
其次是技术保障，这里的技术保障指的是采集过程当中的传输、存储都应当采取足够的技术保障，换算成技术角度就是说，传输过程中要进行传输的加密，存储过程中要进行存储的加密。法律法规不会规定具体的某个安全措施，只是要求采取必要的技术措施保障用户数据的安全。
所以从技术角度侧理解，要采取业内比较标准的或者比较高标准的安全措施，比如 https 默认是使用其他的传输协议，比如 TCP、UDP 等也应当符合业内的安全标准。
当然，安全保障还少不了审计和监管，就是说要有一定的安全开发流程或者安全制度，满足监管机构的监管要求。
3.1 、如何评估安全合规的要求
那么，如何评估安全合规的要求呢？这要看我们具体的涉及的业务，不同领域的要求是不一样的。诸如金融、医疗等领域的要求会更加严格。在某些医疗领域，对于医疗用户（患者）的数据或者处理要记录至少 5 年以上，这是该领域的一个特殊要求。另外，针对不同区域用户的要求也不一样，比如刚才提到的东南亚，新加坡就有自己的特殊规定，其他地区也有相关的特殊要求。
客户的行业之间也有不同的安全要求，重要的企业或者事业单位，对于数据库有时会有一些特殊的要求，比如要求必须是国内的数据库，这就是不同的行业或者不同的客户可能面临的特殊要求。还有一个重要的因素就是要评估依赖的第三方。
例如，我们现在开发产品或者服务，免不了要依赖一家甚至多家第三方，这些第三方是否能够满足特定的要求也是特别重要的，因为大多数的应用都会依赖多家第三方，在上架或者遭遇审查的时候，由于第三方因素引起应用下架也是很正常的。
最后一个是成本因素，就是说要采取技术措施来保证安全合规的要求，肯定会带来成本的增加， 所以从方案角度或者预算角度来说，要考虑这方面的问题。从相关经验来说，比如开启了传输加密和存储加密之后，服务器成本的大概是百分之四五十这个量级的增长，具体数字跟不同的行业和采用的不同技术关联性特别大。
3.2 、产品架构维度
图 4 展示了产品架构的维度，比如一个客户的应用使用了环信的 SDK，一般来说应用也会有自己的 App server，这个 App server 和用户的应用都会跟环信的服务进行交互。SDK 跟服务器会有两个通道，一个是 TCP 加 TLS，另外一个就是 https。同时用户的应用服务器可能会通过RESTful 的 API 做一些管理级别的控制，比如创建聊天室或者创建群组甚至封禁用户。
环信的服务还提供了 webhook，就是将消息回调给用户的应用服务器，然后把消息抄送给用户的服务器，甚至是发送前的一个回调。有一些消息内容或者配置的特定消息内容，提前经过用户的服务器进行审查，确认这些消息是否投递。最后管理者用户可以在 console 开发者后台对这些功能进行不同的配置，也可以做一些管理的功能，比如管理某些群组、解散某些聊天室或者封禁用户。同时用户的应用也会跟自己的服务器进行交互，不管是 https 还是其他的协议。
从完整的视角会看到有哪些通道涉及传输，比如用户的应用和他的应用服务器，我们的 SDK 跟我们的服务，服务器跟服务器之间又是一个。此外，我们必须保证这些传输通道的传输安全， 不管是用 TLS 或者是其他方式。
用户应用上会存储数据，比如用户名、密码甚至是token，有的应用可能也会做缓存。还有一些 容易忽略的点，比如应用开发的过程当中经常会打印一些 log，在这些 log 当中也要避免用户信息或者敏感信息被泄露，不能使用户的 token 或者密码输在 log 中。同时，用户应用服务器和我们的服务可能会存储一些用户的消息历史，这些节点和通道都是安全合规角度下必须要确认或者审查的。以开发者后台来看，管理权限级别的账号的保管、账号丢失之后的处理都要有相关的考虑。
3.3 、数据处理流程的维度
从用户数据处理流程的维度来看，一个数据的处理流程主要涉及数据的采集、传输、存储、处理、擦除与销毁、对第三方提供以及用户隐私权利的保障，如图 5 所示。
采集过程当中首先要进行充分的告知，一般在网站或者应用中都会有一个收集到的隐私协议的说明，包括收集的目的、收集到的个人用户数据的范围、采集的期限等，其中采集期限是很容易被忽略的。传输过程和存储过程是典型的数据处理流程，涉及传输加密和存储加密技术。数据处理过程则要符合收集的目的，遵循准确、必要等原则，不能任意对用户数据进行操作，要有特定的目的才能做数据处理。擦除与销毁过程要求及时和彻底。
对第三方提供过程也是比较关键的，我们经常会借用第三方的内容审核或类似于 APM 的工具， 对于这些第三方工具需要仔细进行检查，确保提供相同的保障条件。最后，用户隐私权利保障过程除了要明确用户是自愿选择之外，还要保证用户可以注销或删除账号，并对这些操作进行及时的响应。
四、安全合规开发经验及建议
前面给出了满足和评估安全合规的维度，接下来将介绍环信基于即时通讯领域的经验和建议。
4.1 、安全合规能力建设需要做什么
在过去一年时间内环信同外部的咨询机构进行了合作，对我们的流程进行了审查，然后环信母公司声网集团的安全合规团队也帮助我们梳理了相关的安全内容，这个团队包括技术、架构、合规、运营、隐私、开发等多个方向的专家。
初创企业前期不需要做这么多的安全合规的能力建设，如果是发展到一定规模或者中等规模的公司，就需要做相关安全能力的建设，比如 GDPR 中提到员工超过 250 人，需要对数据处理加以记录等。
为此，环信进行了安全开发流程的建设，公司内部的开发流程中在产品需求阶段、设计阶段、验收阶段都要有安全方面的介入，以确认是否涉及用户数据、是否是必要的、是否遵循最小原则等。在这些过程当中还会进行每年度甚至半年度的审查，确认整个流程过程当中有没有安全问题以及在合规方面有没有漏洞等。
4.2 、目前安全合规的能力
经过这些建设之后，环信有了足够的安全基础，可以进行全流程的传输加密和存储加密；还具备了资源隔离的能力，支持多数据中心、支持国内国际不同区域的合规要求。针对隐私合规， 根据最小化和公开透明的处理原则，满足了不同区域的网络安全和数据安全的要求，能够对必要的用户数据进行脱敏处理；用户权益的 API 方面支持用户数据的导出和删除。
4.3 、开发建议（即时通讯领域）
不管是借助第三方的能力还是自研的能力，如果在即时通讯或者教育领域有了一定的用户量之后，肯定会遇到一些问题。环信给出一些建议，首先如果使用第三方，一般会注册一些信息， 这时最好是由自己的服务器来下发，不要内置在应用中，否则信息容易泄露。
第二个是比较关键的信息，就是保护好用户列表。比如在已经具备一定的用户量之后，如果此时被拖库或者网站被攻击，用户可能会收到广告或者一些灰产信息，所以用户列表就比较关键了，不管用户是不是通过手机号注册，用户 ID 要散列，而且不要对用户可见。
另外，环信的服务端有类似于全员通知的功能，针对全员通知这个功能，我们添加了相应的白名单功能，在配置好之后，只有某个特定的服务器才能给全员发通知。如果你的业务能够开启好友之间发消息的限制，最好就开启，这样即使用户 ID 被泄露，用户也不能随意地相互之间发消息。
服务器校验用户的合法性也是一个非常重要的功能，如果是直接在第三方平台上注册的用户， 那么他有可能会直接绕过你的服务器来给其他的用户来收发消息。这种情况建议还是由你的服务器来签发 token，然后保证这个 token 一定的时效性，时间不要太长，这样即便某个用户有问题，你的服务器也可以及时发现并且封禁这个用户。
如果有更进一步的安全要求，甚至可以在消息级别进行校验，比如这个消息有特定的 Key 签发密钥，则消息的收发双方都要做相应的校验，甚至端到端的消息加密。
当然现在环信也支持了内容审核的功能，可以在我们的后台配置相应的审核规则。除了前面的保护措施之外，还要做一些内部防范，对类似于开发者证书或者内部的用户列表等关键数据一定要进行相应的保护，比如备份这些数据库的信息，不要被开发者不经意间放到 GitHub 或其他技术博客上。
五、环信安全合规、隐私保护及相关认证
秉持即时通讯服务的易用、高质量、安全、合规理念，环信在持续提升自身的安全能力水位的同时，也依赖开发者及用户的密切合作。一般用户应用的集成，如下图所示：
简要来说，环信作为即时通讯云提供商，会对自身PaaS 平台和 SDK 的安全进行管控；开发者作为服务的接入方，需要对自身应用，应用服务器和系统环境的安全进行管控，并根据自身需求，对环信SDK 及服务的安全选项进行合理的配置，以保障自身信息、平台、程序、系统和网络的安全。
5.1. 安全合规与隐私保护
环信致力于使平台产品遵从国内外隐私法律法规要求，包括中国《个人信息保护法（草案）》；欧盟《通用数据保护条例》（GDPR））等法律要求。
为此，我们组建了专⻔的隐私合规和安全团队，建立了有效的隐私保护和安全管理体系，以保护开发者及用户的个人信息。并对产品进行隐私保护设计评估和安全评估，以确保产品中嵌入了隐私和安全方面的考虑；我们根据开发者及用户所在的国家区域范围和适用的隐私保护法律，在适用情况下向其提供个人数据主体权利；我们遵守隐私保护法律，使用标准合同条款来转移个人信息或将开发者及用户的个人信息转移到具有充分数据保护的国家。
同时，我们实施了适当的物理、管理和技术措施以保护开发者及用户的个人信息，避免对个人信息未授权访问、更改、披露和滥用。我们的即时通讯 SDK 提供了内置加密算法；与开发者及用户的网络通信支持加密传输协议保护；我们服务端存储的用户数据同样支持加密保护。
此外，环信遵循国际认可的信息安全和隐私保护标准以及行业要求，致力于采用国际最佳实践来建设隐私和安全管理体系，在保障产品安全合规的同时，也为开发者及用户提供合规支持，帮助开发者及用户遵守适用法律法规和监管要求。
5.2 安全标准和认证（GDPR）
目前，环信已经通过了多个国际认可的信息安全和隐私管理体系认证，包括 ISO/IEC 27001、公安部等级 2.0 保护三级、GDPR 等，以此证明自身的隐私合规、安全管理以及国际化能力。
ISO/IEC 27001: 2013 信息安全管理标准
ISO/IEC 27001: 2013 是最基础的、获得国际最广泛认可的信息安全管理体系标准。
公安部信息安全等级保护三级认证
《GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求》简称安全等级保护，是中国国家标准化管理委员会发布的信息安全标准，是中华人民共和国信息安全保障的一项基本制度。等级根据信息系统的重要程度，从低到高分为 1 至 5 个等级，不同安全等级实施不同的保护
策略和要求。环信采用的是 3 级信息系统的保护策略，并顺利通过了国家网络与信息系统安全产品质量监督检验中心（公安部第三研究所）的测评。
欧盟《通用数据保护条例》（GDPR）
欧盟议会于 2016 年 4 月 14 日通过的《通用数据保护条例（General Data Protection Regulations）》（“GDPR”）于 2018 年 5 月 25 日在欧盟成员国内正式生效实施。GDPR 堪称史上最严格的数据保护法案，它的实施代表着欧盟对个人信息保护及其监管达到了前所未有的高度。该条例的适用范围极为广泛，任何收集、传输、保留或处理涉及到欧盟所有成员国内的个人信息的机构组织均受该条例的约束。
作为行业首家遵从GDPR 安全法规要求的企业，在GDPR(General Data Protection Regulation)方面，环信做到了极致的隐私数据保护，用户拒绝营销和被遗忘权，严格的角色权限区分和访问控制管理，日志审计和脱敏，SDK、Server 端代码全量扫描，严苛的运维操作流程管理等。
六、环信即时通讯 PaaS 服务的安全
从逻辑划分，环信即时通讯 PaaS 服务，主要包含数据中心服务以及提供给开发者的 IM SDK。在该章节，我们将系统性地介绍各层中的技术及运营环节的安全风险控制措施。
6.1 数据中心计算资源安全
环信即时通讯服务由国内外多个数据中心（IDC）以及头部公有云供应商的云服务组成，以构建一个统一、高可用、高扩展、高效率、高安全的基础资源环境。
6.1.1 网络隔离
对网络进行合理的划分，定义清晰用途，制定适配的访问控制策略，是网络安全的前提之一。环信基于 IM PaaS 承载功能和安全级别的不同，将网络划分出了核心、边缘、IT 等几大安全区域。在不同的安全域之间，根据不同的业务访问需求和安全级别，环信制定了不同的路由策略以及严格的安全访问策略。
6.1.2 防 DDoS 攻击
分布式拒绝服务攻击（Distributed Denial of Service，DDoS）会对 IM 服务的系统和业务可用性产生重大影响，严重时可导致服务中断或质量下降。为此，环信基于自身服务的特性，结合公有云能力，在核心服务上部署了 DDoS 防御方案。该方案能够实时检测并防御来自网络层、传输的 DDoS 攻击。防 DDoS 攻击方案，能够自动检测、自动调度并触发清洗功能，数秒内就可以完成攻击、流量清洗动作，保证核心服务的可用性。
此外所有 DDoS 攻击事件，都会通过邮件、短信、电话等方式，第一时间知会安全团队，以便安全团队持续关注和响应决策。
6.1.3 主机、数据库、中间件等计算资源安全
各类服务运行所依赖的资源，由操作系统或容器化为关联的后台程序、缓存、数据库等中间件， 合理地调度分配 CPU、内存、磁盘等资源来满足。环信结合自身基础服务场景，在实际安全运营中，通过制定适配的安全基线、漏洞管理规范，并落地纵深威胁检测机制，确保基础运算负载资源的安全性。
6.1.3.1 安全基线
环信制定了 IDC 和公有云的安全基线，涵盖主机操作系统、容器、数据库、存储、Web 服务等中间件，内容包括账户安全、身份认证、最小服务、最小授权、日志审计、时钟同步等。并根据不同的用途，对操作系统或中间件进行不同程度的安全配置加固，确保新交付的运算负载资源满足相关安全基线要求。对于运行中的负载资源，安全团队会进行定期的配置巡检，对比与安全基线的差异，输出不符合项，通知到关联的运维和业务技术团队，并落实整改。
6.1.3.2 漏洞管理
所有交付上线的运算负载资源，均来自统一管理的操作系统镜像或中间件软件包。对于交付使用中的资源，安全团队会采集操作系统和中间件版本信息，然后发送到安全运营系统中分析， 从而识别是否存在受漏洞影响的版本。对于公有云上的主机资源，环信会部署公有云的安全客户端，实现对操作系统和中间件等软件产品的实时漏洞检测。另外，安全团队通过部署业界知名商业漏洞扫描产品，定期对运算负载资源发起扫描巡检，输出漏洞扫描报告，并将信息采集到安全运营系统。
一旦发现存在漏洞版本匹配的组件，安全团队会对漏洞的风险做综合评估，提供应急处置措施和修复建议，并联合运维及相关业务技术团队落实漏洞修复、配置加固、镜像更新，从而实现漏洞管理的闭环。
6.1.3.3 计算资源中的安全运维
运维账号安全
在日常运维中，环信制定并启用了 IAM（Identity and Access Management，身份和访问控制管理）机制，所有涉及运维内容的人员必须具有有效的身份和授权才可进行操作，运维账号与员工身份一一对应，其默认启用 MFA（Multi-factor authentication, 多重要素验证）。
操作系统账号安全
对于系统账号，环信制定了一系列安全制度和操作规范，例如，避免使用弱口令作为密码，并要求定期更换，信息安全团队也会通过定期的安全检查。
运维操作审计
环信在日常运维过程中，会实时记录归档各类操作，制定实时监控告警策略，并对风险操作及时处置。
6.2 SDK 安全
环信提供 iOS、Android、Flutter、React Native、Windows、小程序、Web 等平台的 SDK 支持，以满足开发者及用户的各类实时音视频互动接入需求。IM SDK 不仅仅为开发者及用户提供简单、易用、统一、可信、安全的即时通讯开发套件，也竭尽全力为开发者及用户提供合规、安全的配置选项，以提升开发者及用户在实时音视频互动场景和应用中合规监管和应对信源数据安全威胁的能力。
根据国家法律法规规定及监管机构执法要求，APP 在使用第三方SDK 时，必须在APP《隐私政策》中告知用户，并在调用时序上做好延迟初始化配置，确保用户同意 APP《隐私政策》后 SDK 才可以被启动，进行数据采集和服务。为了帮助开发者避免合规风险，环信推出隐私政策合规要求，包括隐私政策展示内容和展示形式合规。关于环信所收集的信息种类、用途、个人信息保护的规则及退出机制等，详见环信官网（https://www.easemob.com/） 上的隐私政策 （https://www.easemob.com/protocol） 条款。
6.2.1 SDK 的合规与安全保证
环信在为开发者提供 SDK 时，SDK 的可信和安全是首要保证的内容之一。在评审 SDK 新增或迭代的功能时，会充分评估功能需求在合规隐私以及安全上的风险点，确保与环信合规和隐私政策的一致性。功能实现时，会在进行充分的质量保证（QA）测试时对代码进行安全审计， 在涉及引用或集成第三方 SDK、库文件时进行安全检测，尤其是合规性确认，例如，是否存在恶意代码或后门，是否遵守版权或使用协议。如果检测出存在风险，SDK 只有在修复并确认无风险后，才允许进入下一阶段。在分发环节，会在官方渠道更新。
6.2.2 对开发者及用户的安全与合规支持
在 SDK 上，环信提供了设备端存储内容加密，日志安全等安全配置选项，以协助开发者及用户完善即时通讯数据安全及隐私合规。有需要的开发者及用户，可以参考开发者文档进行配置启用。
6.2.2.1 本地存储内容
环信 SDK 使用行业标准的加密技术对在设备本地的消息等内容记录进行加密存储。
6.2.2.2 日志脱敏
环信SDK 提供不同的日志级别，方便开发者在开发调试和发布时使用，同时对设备上的日志进行脱敏，防止用户数据被识别和窃取。
6.3 RESTful API 安全
为方便开发者高效地管理自己的应用和服务，诸多业务功能和管理功能以 RESTful API 的方式供开发者调用。在安全保障上，除了将站点接入 WAF 外，还有如下的安全控制措施。
身份鉴权
开发者在使用 RESTful API 前，需先登录控制台，创建开发者专属的 key&secret。后续 API 调用，需使用对应的 key&secret 对，以区分不同项目或应用。
传输安全
RESTful API 支持 HTTPS 协议，以确保使用 SSL / TLS 对所有 API 通信进行加密，可以保护 API凭据和传输的数据，以及防止一些如中间人攻击（MITM, man in the middle）等。
API 限速
服务端对 API 请求的速率有限制，在保证正常用户请求可以得到响应的同时，限制恶意用户的 API 请求。
输入验证
开发者请求的参数会经过服务器后台过滤，以避免一些常见的易受攻击缺陷（SQL-注入，远程代码执行等）。
七、环信数据安全
数据作为信息活动的载体，经过合法合规且安全的处理尤为重要。数据安全是环信最为关切的问题之一，本节将介绍环信在数据安全上采取的政策及落实的管理和技术控制措施。
7.1 数据安全政策
针对日益严峻的网络安全态势，以及逐渐趋紧的监管要求，环信坚持以数据保密、完整和高可用作为业务服务的数据安全发展战略，并将数据安全理念融入安全体系建设过程中，即
保密性：防止未经授权的访问和窃听
完整性：防止恶意篡改和伪造数据
可用性：通过不同数据中心和边缘节点保障数据高可用
因此环信对所有员工均开展信息保护、隐私合规及保密意识安全培训，并签订保密协议；对违反数据安全制度和保密要求的人员，我们会视情形严重程度以采取相应的违规处理措施，包括但不限于谈话、加强培训考核、解除劳动协议及追究其他法律责任等措施。
7.2 数据采集
采用最小化的数据采集原则，只采集经用户授权同意的，且业务所必须的数据字段。
7.3 数据脱敏
为保护数据隐私，环信针对官网控制台的企业和个人信息均进行脱敏后的展示，此策略同样也适用于不同的服务和SDK。
7.4 数据保护和加密传输
在 IM PaaS 服务中，对于不同的传输通道例如SDK 与服务器，服务器与用户的应用服务器之间等，都支持安全传输协议(HTTPS/TLS/WSS 等)
7.5 数据使用和存储
对于开发者及用户的机密信息，如密码，我们会以哈希加盐值（salt）的方式进行存储。对已存 储的信息，将根据相关监管要求和制定的数据备份和存储策略，严格制定数据保存期限，并按要求在需要时对其进行销毁；对来自开发者及用户的数据处理申请，我们将根据开发者及用户的授权及相应监管要求配合实施数据清理或转移。
7.6 用户的数据权利
提供了不同维度的用户权益的 API 方面支持用户数据的导出和删除。
八、环信安全运营
安全是一个持续的过程，在实际安全运营中，环信基于自身业务特性，通过如下维度来开展。
8.1 安全开发生命周期管理 SDL
在软件开发生命周期中，嵌入了安全和隐私的相关要求，结合当前流行的 DevSecOps，让 SDL 流程更自动化，从而在原有的安全开发生命周期的基础上，更高效的进行安全和隐私的检查。
8.1.1 威胁建模
在设计和架构阶段，为了能够更早的发现风险，通过威胁建模来识别潜在的安全问题并实施响应环节措施。为了有效发现并解决设计阶段的潜在风险，参考 STRIDE 的威胁建模方法，主要聚焦攻击面最小化，基本隐私，权限最小化，默认安全，数据加密等。
8.1.2 CI/CD 黑白盒检测
在安全测试层面更注重 DevSecOps 崇尚的内置安全防护，且已在 CI/CD 层面进行了黑白盒工具的集成，包含开源代码扫描工具 SonarQube，组件及合规扫描商业工具 BlackDuck，App/Sdk 扫描工具 MobSF 等，从而完善在集成发布过程中的风险监测。
8.2 反入侵和安全监控
环信的各类运算系统、业务应用服务每天都会产生海量的日志数据。在落实纵深防御以应对威胁的基础之上，安全团队也会在最小权限范围内采集用于安全分析的日志。基于这些日志，通过安全监控分析平台实时运算。对识别的安全异常事件，会及时告警，安全运营人员会进一步展开关联以及溯源分析复核；对确认的风险，会根据应急响应机制进行处置和追踪，以保障业务系统的安全性和可用性。
8.3 安全应急响应机制
基于自身即时通讯业务特性，对服务类型进行分类分级，系统性地安全评估和威胁识别，制定不同的安全事件分类标准，以及响应时效和处置流程，以确保及时有效地处理安全异常。
8.4 安全合作
在自身内部安全建设的基础上，环信已与 Trustwave 等多家第三方安全厂商合作，定期进行渗透测试，代码审查，逆向工程等来帮助环信发现线上应用、系统、服务以及 SDK 等层面的安全漏洞和各类潜在风险，从而提升整体服务安全性和系统健壮性。
九、APP 开发者接入环信 SDK 的合规要求
根据国家法律法规规定及监管机构执法要求，APP 在使用第三方SDK 时，必须在APP《隐私政策》中告知用户，并在调用时序上做好延迟初始化配置，确保用户同意 APP《隐私政策》后 SDK 才可以被启动，进行数据采集和服务。为了帮助环信开发者避免合规风险，环信推出了隐私政策合规要求，包括隐私政策展示内容和展示形式合规。
9.1.隐私政策内容合规
注意：本信息收集范围说明适用于SDK3.8.4 版本及以上
当APP 开发者接入环信 SDK 服务时，请务必按照我国法律法规、规范性文件之要求，在APP 自身的隐私政策或个人信息保护政策等相关公示文件中“第三方服务”/“第三方合作伙伴”部分明确列出本APP 所集成的环信 SDK 收集、使用个人信息的目的、方式和范围，环信提供如下两种参考表达话术，以方便APP 开发者更高效、更合规地调整自身的隐私政策，共同保护个人信息。
参考表达一、以文字方式向用户呈现
如：我们使用了第三方（北京亿思摩博网络科技有限公司，以下称“环信”） 环信 SDK 服务为您提供【 】功能。为了顺利实现该功能，您需要授权环信 SDK 提供对应的服务;在您授权后， 环信将收集您相关的个人信息。关于环信所收集的信息种类、用途、个人信息保护的规则及退
出机制等，详见环信官网（https://www.easemob.com/） 上的隐私政策 （https://www.easemob.com/protocol） 条款
参考表达二、以表格方式向用户呈现
如：【您的 APP 名称】(iOS 版/Android 版)内嵌第三方SDK 详情
9.2 隐私政策展示形式合规
需要增加明确弹窗，有明显同意和拒绝按钮，让用户自主选择是否接受隐私政策。App 隐私政策包含的环信隐私权政策链接可允许用户点击查看。
十、结语
为开发者提供合规、安全、可信的即时通讯云平台，是环信所有架构和产品服务首要考虑的要素之一。环信从人员、技术、管理、流程等多个方面系统性推进信息安全政策的落地，履行监管合规义务，与行业客户以及第三方社区或团体个人紧密合作，同时积极探索新的技术，推进安全自动化、智能化，实现安全防护能力高效输出。
在日趋复杂的互联网环境下，技术迭代周期越来越短，新型攻击手段层出不穷，我们无时不刻都在面临各类安全威胁。筚路蓝缕启山林、栉风沐雨砥砺行，在此背景下，希望本白皮书能够为企业或机构的安全建设提供参考和借鉴，也欢迎业界同仁共同参与完善，助力行业高质量稳健发展！
访问环信官网，免费下载白皮书PDF全文。
