域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過

前言

隨著移動(dòng)互聯(lián)網(wǎng)和 5G 通信新技術(shù)的浪潮席卷全球，傳統(tǒng)的通信方式已經(jīng)發(fā)生了翻天覆地的變化。人們已經(jīng)習(xí)慣了通過即時(shí)通訊軟件和網(wǎng)絡(luò)交流平臺(tái)分享自己生活的方方面面，隨著人們?cè)絹碓焦_自己的生活，人們也開始關(guān)注隱私和安全等問題。

隱私作為人們不愿為他人知曉的私密空間、私密活動(dòng)和私密信息，歷來被互聯(lián)網(wǎng)用戶所關(guān)注。尤其是在即時(shí)通訊服務(wù)的使用過程中，用戶可以輕易將自己的隱私傳輸至互聯(lián)網(wǎng)上，這使得用戶在享受便捷服務(wù)的同時(shí)，更容易因隱私泄露而影響生活安寧。近些年來各類隱私泄露事件更是讓人們?cè)谙硎鼙憬莸幕ヂ?lián)網(wǎng)服務(wù)時(shí)，對(duì)網(wǎng)絡(luò)服務(wù)提供者的隱私保護(hù)能力持懷疑態(tài)度。甚至在某種程度上，隱私保護(hù)逐漸成為用戶選擇網(wǎng)絡(luò)服務(wù)時(shí)考慮的重要因素。為了保護(hù)用戶的隱私， 世界各地都相繼出臺(tái)了隱私保護(hù)相關(guān)的法律法規(guī)，使得企業(yè)的隱私保護(hù)合規(guī)工作更加具有挑戰(zhàn)性。

作為全球互聯(lián)網(wǎng)消息云的開創(chuàng)者和引領(lǐng)者，數(shù)據(jù)和用戶隱私安全是環(huán)信最關(guān)切的問題。環(huán)信始終將數(shù)據(jù)和用戶隱私安全作為首要安全原則，并將其作為理念融入安全能力建設(shè)當(dāng)中，2021 年環(huán)信行業(yè)首家通過了史上最嚴(yán)格的數(shù)據(jù)保護(hù)法案“GDPR”的相關(guān)安全合規(guī)標(biāo)準(zhǔn)。

為幫助開發(fā)者及用戶感知和理解環(huán)信在即時(shí)通訊服務(wù)上的努力，了解環(huán)信服務(wù)的安全屬性，CSDN聯(lián)合環(huán)信特發(fā)布即時(shí)通訊行業(yè)首個(gè)《安全合規(guī)白皮書》。該白皮書全面分析了安全合規(guī)的趨勢(shì)及國內(nèi)外監(jiān)管重點(diǎn)，同時(shí)給出環(huán)信在即時(shí)通信領(lǐng)域安全合規(guī)開發(fā)的經(jīng)驗(yàn)及建議，還列舉了環(huán)信云服務(wù)的相關(guān)安全和合規(guī)工作，希望能夠?yàn)闃I(yè)界提供了全面、詳實(shí)的安全能力建設(shè)參考。

目錄

1.安全合規(guī)的趨勢(shì)

1.1隱私監(jiān)管趨緊

1.2APP/SDK 趨嚴(yán)

1.3安全合規(guī)的基本框架

2.國內(nèi)外的監(jiān)管重點(diǎn)

2.1國內(nèi) App 上架-信息采集

2.2國內(nèi) App 上架-符合安全規(guī)定

2.3海外的關(guān)注-?戶權(quán)利

2.4共同關(guān)注點(diǎn)-數(shù)據(jù)跨境

3.如何評(píng)估和滿?安全合規(guī)要求

3.1如何評(píng)估安全合規(guī)的要求

3.2產(chǎn)品架構(gòu)維度

3.3數(shù)據(jù)處理流程的維度

4.安全合規(guī)開發(fā)經(jīng)驗(yàn)及建議

4.1安全合規(guī)能?建設(shè)需要做什么

4.2?前安全合規(guī)的能?

4.3開發(fā)建議-即時(shí)通訊領(lǐng)域

5.環(huán)信安全合規(guī)、隱私保護(hù)及相關(guān)認(rèn)證

5.1環(huán)信安全合規(guī)和隱私保護(hù)

5.2安全標(biāo)準(zhǔn)和認(rèn)證(GDPR)

6.環(huán)信即時(shí)通訊 PaaS 服務(wù)的安全

6.1數(shù)據(jù)中心計(jì)算資源安全

6.2SDK 安全

6.3RESTful API 安全

7.數(shù)據(jù)安全

7.1數(shù)據(jù)安全政策

7.2數(shù)據(jù)采集

7.3數(shù)據(jù)脫敏

7.4數(shù)據(jù)保護(hù)和加密傳輸

7.5數(shù)據(jù)使用和存儲(chǔ)

7.6用戶的數(shù)據(jù)權(quán)利

8.安全運(yùn)營

8.1安全開發(fā)生命周期管理 SDL

8.2反入侵和安全監(jiān)控

8.3安全應(yīng)急響應(yīng)機(jī)制

8.4安全合作

9.APP 開發(fā)者接入環(huán)信 SDK 的合規(guī)要求

9.1隱私政策內(nèi)容合規(guī)

9.2隱私政策展示形式合規(guī)

10.結(jié)語

引言

在監(jiān)管趨緊的形式下，即時(shí)通訊場(chǎng)景會(huì)遇到很多安全合規(guī)領(lǐng)域的挑戰(zhàn)，如何滿足這些安全合規(guī)的要求，如何保護(hù)用戶的隱私安全，是一件非常有挑戰(zhàn)的事情。

一、安全合規(guī)的趨勢(shì)

1.1 、隱私監(jiān)管趨緊

最近四五年來，安全合規(guī)的趨勢(shì)變得越來越嚴(yán)格，各個(gè)國家都有比較重磅的安全合規(guī)的相關(guān)法規(guī)出臺(tái)，比如美國加州的《消費(fèi)者隱私法案》《兒童在線隱私保護(hù)法》、保險(xiǎn)醫(yī)療領(lǐng)域的 HIPPA，以及歐盟推出的比較有代表性的《通用數(shù)據(jù)保護(hù)條例》。國內(nèi)去年也出臺(tái)了《個(gè)人信息保護(hù)法》

《數(shù)據(jù)安全法》，加上之前發(fā)布的《網(wǎng)絡(luò)安全法》，對(duì)于安全合規(guī)領(lǐng)域的覆蓋逐漸比較完善。

1.2 、App/SDK 趨嚴(yán)

圖 1 所示為國內(nèi)主要的有關(guān)法規(guī)和內(nèi)容，而且這個(gè)趨勢(shì)也是越來越嚴(yán)格，比如工信部發(fā)布的各種應(yīng)用下架的新聞或者公告，都涉及了個(gè)人數(shù)據(jù)隱私相關(guān)的內(nèi)容。

1.3 、安全合規(guī)的基本框架

安全合規(guī)的基本框架可以總結(jié)成兩個(gè)方向，一個(gè)是用戶知情同意，另一個(gè)就是安全保障義務(wù)。我們以《通用數(shù)據(jù)保護(hù)條例》( GDPR )為例，它是一個(gè)法規(guī)條文，內(nèi)容包括各種監(jiān)管措施、懲罰措施，還規(guī)定了應(yīng)保障的用戶權(quán)利，后續(xù)章節(jié)將介紹一些具體的用戶權(quán)利說明。

二、國內(nèi)外的監(jiān)管重點(diǎn)

關(guān)于國內(nèi)外監(jiān)管的重點(diǎn)，從國內(nèi)這幾年的角度來看，主要包括以下幾個(gè)方面：

2.1 、國內(nèi) App 上架 —— 信息采集

如圖 2 所示，用戶信息的采集方面正受到越來越多的重視，國家部委出臺(tái)了《常見類型移動(dòng)互聯(lián)網(wǎng)應(yīng)用程序必要個(gè)人信息的范圍規(guī)定》，指出了二三十個(gè)場(chǎng)景下能夠采集的必要的個(gè)人信息。

比如地圖導(dǎo)航類，它的基本功能是定位和導(dǎo)航，必要的個(gè)人信息為位置信息、出發(fā)地和到達(dá)地。開發(fā)者在開發(fā)應(yīng)用的時(shí)候首要確認(rèn)相關(guān)信息，如果收集了其余非必要數(shù)據(jù)App 就無法上架。

再比如網(wǎng)絡(luò)社區(qū)類應(yīng)用，它的基本功能是博客、論壇等，這些個(gè)人信息跟即時(shí)通訊類的必要信息比較接近，諸如用戶的移動(dòng)電話號(hào)碼和賬號(hào)聯(lián)系人等信息。網(wǎng)約車類型中也規(guī)定了電話號(hào)碼， 包括出發(fā)地、到達(dá)地、支付時(shí)間、支付信息等。為什么即時(shí)通訊類需要移動(dòng)電話號(hào)碼呢?一般認(rèn)為是只需要賬號(hào)就可以了?接下來的篇幅就解釋了這個(gè)問題。

2.2 、國內(nèi) App 上架 —— 符合安全規(guī)定

除了可以采集的必要信息的約束之外，我國還有很多特定的相關(guān)不同行業(yè)或領(lǐng)域的約束。

在應(yīng)用的上架流程中，應(yīng)用商店都有詳細(xì)的審查規(guī)定，如果涉及即時(shí)通訊、直播或者用戶輿論領(lǐng)域，就需要一個(gè)安全評(píng)估報(bào)告，這個(gè)安全評(píng)估報(bào)告中增加了額外的要求，比如說用戶真實(shí)身份的核驗(yàn)，就是要核驗(yàn)服務(wù)中用戶的身份是真實(shí)可靠的，這里就回答了前面即時(shí)通訊領(lǐng)域的問題，想真正地服務(wù)客戶，就要能夠做到實(shí)名制，而實(shí)名制其實(shí)一般就是通過校驗(yàn)手機(jī)號(hào)和短信等方式。

另外，其實(shí)這還涉及用戶輿論的問題，需要針對(duì)這個(gè)問題建立投訴舉報(bào)的機(jī)制，公布投訴舉報(bào)的聯(lián)系方式和處理情況，對(duì)于這些用戶的昵稱、信息發(fā)布、轉(zhuǎn)發(fā)評(píng)論等，要有相關(guān)的記錄保存措施，通過一定的保存機(jī)制來支持追查這些信息。這樣一方面約束了必要的個(gè)人信息的采集; 另一方面在不同的領(lǐng)域也補(bǔ)充了額外的要求，比如金融或者醫(yī)療領(lǐng)域就有更高級(jí)別的相關(guān)要求。

根據(jù)工信部數(shù)據(jù)顯示，近期違規(guī)下架應(yīng)用累計(jì)為 3000 款左右，涉及的問題大部分是違規(guī)收集個(gè)人信息，少量是強(qiáng)制或者索取權(quán)限相關(guān)的問題，國內(nèi)的應(yīng)用、網(wǎng)站可能涉及的問題主要集中在這幾個(gè)方面。

2.3 、海外的關(guān)注 —— 用戶權(quán)利

如果目標(biāo)客戶是在海外，那么會(huì)發(fā)現(xiàn)海外的側(cè)重點(diǎn)稍有不同。除了常見的這些安全約束之外， 其更關(guān)注用戶的權(quán)利。

舉幾個(gè)例子，比如用戶的知情權(quán)、信息獲取權(quán)、修改權(quán)和被遺忘權(quán)。知情權(quán)就是明確地告知用戶要收集哪些信息、信息用來做什么以及保存多久;信息獲取權(quán)就是用戶必須能夠?qū)С鲎约旱臄?shù)據(jù);修改權(quán)就是用戶可以對(duì)個(gè)人信息進(jìn)行修改;被遺忘權(quán)就是用戶有權(quán)利注銷和刪除自己的數(shù)據(jù)。Facebook 等海外的大型平臺(tái)都支持注銷賬號(hào)、導(dǎo)出個(gè)人數(shù)據(jù)等功能，這些是海外比較重視的方面。

圖 3 案例所示，英國的數(shù)據(jù)保護(hù)監(jiān)管機(jī)構(gòu)向加拿大的一家數(shù)據(jù)分析公司發(fā)出通知，要求其刪除

所有跟英國公民相關(guān)的個(gè)人數(shù)據(jù)，如果不履行義務(wù)，將面臨著 2000 萬歐元或者上一年全球總

營業(yè)額 4% 的罰款。這里的 2000 萬歐元和 4% 的罰款就是《通用數(shù)據(jù)保護(hù)條例》中所做的規(guī)定，從中不難看出這個(gè)措施是非常嚴(yán)格的。

2.4 、共同關(guān)注點(diǎn) —— 數(shù)據(jù)跨境

國內(nèi)和國外還有一個(gè)共同的關(guān)注點(diǎn)，就是熱點(diǎn)數(shù)據(jù)跨境，簡單來說就是個(gè)人信息和重要的數(shù)據(jù)應(yīng)當(dāng)在境內(nèi)，這里的在境內(nèi)應(yīng)該就是說，比如中國公民的信息和重要的數(shù)據(jù)不能被隨意地存儲(chǔ)到境外的服務(wù)器上，歐盟地區(qū)的數(shù)據(jù)也不能被隨意地存儲(chǔ)在歐盟以外。其他的地區(qū)比如東南亞或者印度，也有當(dāng)?shù)氐南嚓P(guān)法律法規(guī)來約束。

如果確實(shí)需要向境外提供數(shù)據(jù)，我國的要求是要通過評(píng)估辦法進(jìn)行慎重的評(píng)估。歐盟則是要求他們認(rèn)為已經(jīng)采取足夠的安全保護(hù)措施的地區(qū)可以跨境轉(zhuǎn)移數(shù)據(jù)，但至少現(xiàn)在為止中國還不在這個(gè)名單上，所以歐盟的數(shù)據(jù)也不能隨意存儲(chǔ)在中國境內(nèi)的服務(wù)器上。

三、如何評(píng)估和滿足安全合規(guī)要求

了解了安全合規(guī)的趨勢(shì)和相應(yīng)的重點(diǎn)之后，我們?nèi)绾卧u(píng)估和滿足安全合規(guī)的要求呢?首先回溯前面介紹的安全合規(guī)的框架。

用戶知情同意包括充分告知和權(quán)利保障。充分告知就是提供用戶隱私協(xié)議，權(quán)利保障就是用戶可以拒絕、可以刪除，而且收集的數(shù)據(jù)要符合最小化原則(最小必要)。

安全保障義務(wù)比較復(fù)雜。首先，從風(fēng)險(xiǎn)評(píng)估、公司內(nèi)部的制度建設(shè)到安全開發(fā)流程中都會(huì)涉及這個(gè)問題，比如產(chǎn)品從需求階段就要有安全方面的專家確認(rèn)是否涉及用戶數(shù)據(jù)、用戶數(shù)據(jù)怎么傳輸、用戶數(shù)據(jù)怎么來保存、是否是必要的等等，因此從產(chǎn)品需求階段到方案設(shè)計(jì)階段，到最后上線階段都要有必要的安全評(píng)估。

其次是技術(shù)保障，這里的技術(shù)保障指的是采集過程當(dāng)中的傳輸、存儲(chǔ)都應(yīng)當(dāng)采取足夠的技術(shù)保障，換算成技術(shù)角度就是說，傳輸過程中要進(jìn)行傳輸?shù)募用?，存?chǔ)過程中要進(jìn)行存儲(chǔ)的加密。法律法規(guī)不會(huì)規(guī)定具體的某個(gè)安全措施，只是要求采取必要的技術(shù)措施保障用戶數(shù)據(jù)的安全。

所以從技術(shù)角度側(cè)理解，要采取業(yè)內(nèi)比較標(biāo)準(zhǔn)的或者比較高標(biāo)準(zhǔn)的安全措施，比如 https 默認(rèn)是使用其他的傳輸協(xié)議，比如 TCP、UDP 等也應(yīng)當(dāng)符合業(yè)內(nèi)的安全標(biāo)準(zhǔn)。

當(dāng)然，安全保障還少不了審計(jì)和監(jiān)管，就是說要有一定的安全開發(fā)流程或者安全制度，滿足監(jiān)管機(jī)構(gòu)的監(jiān)管要求。

3.1 、如何評(píng)估安全合規(guī)的要求

那么，如何評(píng)估安全合規(guī)的要求呢?這要看我們具體的涉及的業(yè)務(wù)，不同領(lǐng)域的要求是不一樣的。諸如金融、醫(yī)療等領(lǐng)域的要求會(huì)更加嚴(yán)格。在某些醫(yī)療領(lǐng)域，對(duì)于醫(yī)療用戶(患者)的數(shù)據(jù)或者處理要記錄至少 5 年以上，這是該領(lǐng)域的一個(gè)特殊要求。另外，針對(duì)不同區(qū)域用戶的要求也不一樣，比如剛才提到的東南亞，新加坡就有自己的特殊規(guī)定，其他地區(qū)也有相關(guān)的特殊要求。

客戶的行業(yè)之間也有不同的安全要求，重要的企業(yè)或者事業(yè)單位，對(duì)于數(shù)據(jù)庫有時(shí)會(huì)有一些特殊的要求，比如要求必須是國內(nèi)的數(shù)據(jù)庫，這就是不同的行業(yè)或者不同的客戶可能面臨的特殊要求。還有一個(gè)重要的因素就是要評(píng)估依賴的第三方。

例如，我們現(xiàn)在開發(fā)產(chǎn)品或者服務(wù)，免不了要依賴一家甚至多家第三方，這些第三方是否能夠滿足特定的要求也是特別重要的，因?yàn)榇蠖鄶?shù)的應(yīng)用都會(huì)依賴多家第三方，在上架或者遭遇審查的時(shí)候，由于第三方因素引起應(yīng)用下架也是很正常的。

最后一個(gè)是成本因素，就是說要采取技術(shù)措施來保證安全合規(guī)的要求，肯定會(huì)帶來成本的增加， 所以從方案角度或者預(yù)算角度來說，要考慮這方面的問題。從相關(guān)經(jīng)驗(yàn)來說，比如開啟了傳輸加密和存儲(chǔ)加密之后，服務(wù)器成本的大概是百分之四五十這個(gè)量級(jí)的增長，具體數(shù)字跟不同的行業(yè)和采用的不同技術(shù)關(guān)聯(lián)性特別大。

3.2 、產(chǎn)品架構(gòu)維度

圖 4 展示了產(chǎn)品架構(gòu)的維度，比如一個(gè)客戶的應(yīng)用使用了環(huán)信的 SDK，一般來說應(yīng)用也會(huì)有自己的 App server，這個(gè) App server 和用戶的應(yīng)用都會(huì)跟環(huán)信的服務(wù)進(jìn)行交互。SDK 跟服務(wù)器會(huì)有兩個(gè)通道，一個(gè)是 TCP 加 TLS，另外一個(gè)就是 https。同時(shí)用戶的應(yīng)用服務(wù)器可能會(huì)通過RESTful 的 API 做一些管理級(jí)別的控制，比如創(chuàng)建聊天室或者創(chuàng)建群組甚至封禁用戶。

環(huán)信的服務(wù)還提供了 webhook，就是將消息回調(diào)給用戶的應(yīng)用服務(wù)器，然后把消息抄送給用戶的服務(wù)器，甚至是發(fā)送前的一個(gè)回調(diào)。有一些消息內(nèi)容或者配置的特定消息內(nèi)容，提前經(jīng)過用戶的服務(wù)器進(jìn)行審查，確認(rèn)這些消息是否投遞。最后管理者用戶可以在 console 開發(fā)者后臺(tái)對(duì)這些功能進(jìn)行不同的配置，也可以做一些管理的功能，比如管理某些群組、解散某些聊天室或者封禁用戶。同時(shí)用戶的應(yīng)用也會(huì)跟自己的服務(wù)器進(jìn)行交互，不管是 https 還是其他的協(xié)議。

從完整的視角會(huì)看到有哪些通道涉及傳輸，比如用戶的應(yīng)用和他的應(yīng)用服務(wù)器，我們的 SDK 跟我們的服務(wù)，服務(wù)器跟服務(wù)器之間又是一個(gè)。此外，我們必須保證這些傳輸通道的傳輸安全， 不管是用 TLS 或者是其他方式。

用戶應(yīng)用上會(huì)存儲(chǔ)數(shù)據(jù)，比如用戶名、密碼甚至是token，有的應(yīng)用可能也會(huì)做緩存。還有一些 容易忽略的點(diǎn)，比如應(yīng)用開發(fā)的過程當(dāng)中經(jīng)常會(huì)打印一些 log，在這些 log 當(dāng)中也要避免用戶信息或者敏感信息被泄露，不能使用戶的 token 或者密碼輸在 log 中。同時(shí)，用戶應(yīng)用服務(wù)器和我們的服務(wù)可能會(huì)存儲(chǔ)一些用戶的消息歷史，這些節(jié)點(diǎn)和通道都是安全合規(guī)角度下必須要確認(rèn)或者審查的。以開發(fā)者后臺(tái)來看，管理權(quán)限級(jí)別的賬號(hào)的保管、賬號(hào)丟失之后的處理都要有相關(guān)的考慮。

3.3 、數(shù)據(jù)處理流程的維度

從用戶數(shù)據(jù)處理流程的維度來看，一個(gè)數(shù)據(jù)的處理流程主要涉及數(shù)據(jù)的采集、傳輸、存儲(chǔ)、處理、擦除與銷毀、對(duì)第三方提供以及用戶隱私權(quán)利的保障，如圖 5 所示。

采集過程當(dāng)中首先要進(jìn)行充分的告知，一般在網(wǎng)站或者應(yīng)用中都會(huì)有一個(gè)收集到的隱私協(xié)議的說明，包括收集的目的、收集到的個(gè)人用戶數(shù)據(jù)的范圍、采集的期限等，其中采集期限是很容易被忽略的。傳輸過程和存儲(chǔ)過程是典型的數(shù)據(jù)處理流程，涉及傳輸加密和存儲(chǔ)加密技術(shù)。數(shù)據(jù)處理過程則要符合收集的目的，遵循準(zhǔn)確、必要等原則，不能任意對(duì)用戶數(shù)據(jù)進(jìn)行操作，要有特定的目的才能做數(shù)據(jù)處理。擦除與銷毀過程要求及時(shí)和徹底。

對(duì)第三方提供過程也是比較關(guān)鍵的，我們經(jīng)常會(huì)借用第三方的內(nèi)容審核或類似于 APM 的工具， 對(duì)于這些第三方工具需要仔細(xì)進(jìn)行檢查，確保提供相同的保障條件。最后，用戶隱私權(quán)利保障過程除了要明確用戶是自愿選擇之外，還要保證用戶可以注銷或刪除賬號(hào)，并對(duì)這些操作進(jìn)行及時(shí)的響應(yīng)。

四、安全合規(guī)開發(fā)經(jīng)驗(yàn)及建議

前面給出了滿足和評(píng)估安全合規(guī)的維度，接下來將介紹環(huán)信基于即時(shí)通訊領(lǐng)域的經(jīng)驗(yàn)和建議。

4.1 、安全合規(guī)能力建設(shè)需要做什么

在過去一年時(shí)間內(nèi)環(huán)信同外部的咨詢機(jī)構(gòu)進(jìn)行了合作，對(duì)我們的流程進(jìn)行了審查，然后環(huán)信母公司聲網(wǎng)集團(tuán)的安全合規(guī)團(tuán)隊(duì)也幫助我們梳理了相關(guān)的安全內(nèi)容，這個(gè)團(tuán)隊(duì)包括技術(shù)、架構(gòu)、合規(guī)、運(yùn)營、隱私、開發(fā)等多個(gè)方向的專家。

初創(chuàng)企業(yè)前期不需要做這么多的安全合規(guī)的能力建設(shè)，如果是發(fā)展到一定規(guī)?；蛘咧械纫?guī)模的公司，就需要做相關(guān)安全能力的建設(shè)，比如 GDPR 中提到員工超過 250 人，需要對(duì)數(shù)據(jù)處理加以記錄等。

為此，環(huán)信進(jìn)行了安全開發(fā)流程的建設(shè)，公司內(nèi)部的開發(fā)流程中在產(chǎn)品需求階段、設(shè)計(jì)階段、驗(yàn)收階段都要有安全方面的介入，以確認(rèn)是否涉及用戶數(shù)據(jù)、是否是必要的、是否遵循最小原則等。在這些過程當(dāng)中還會(huì)進(jìn)行每年度甚至半年度的審查，確認(rèn)整個(gè)流程過程當(dāng)中有沒有安全問題以及在合規(guī)方面有沒有漏洞等。

4.2 、目前安全合規(guī)的能力

經(jīng)過這些建設(shè)之后，環(huán)信有了足夠的安全基礎(chǔ)，可以進(jìn)行全流程的傳輸加密和存儲(chǔ)加密;還具備了資源隔離的能力，支持多數(shù)據(jù)中心、支持國內(nèi)國際不同區(qū)域的合規(guī)要求。針對(duì)隱私合規(guī)， 根據(jù)最小化和公開透明的處理原則，滿足了不同區(qū)域的網(wǎng)絡(luò)安全和數(shù)據(jù)安全的要求，能夠?qū)Ρ匾挠脩魯?shù)據(jù)進(jìn)行脫敏處理;用戶權(quán)益的 API 方面支持用戶數(shù)據(jù)的導(dǎo)出和刪除。

4.3 、開發(fā)建議(即時(shí)通訊領(lǐng)域)

不管是借助第三方的能力還是自研的能力，如果在即時(shí)通訊或者教育領(lǐng)域有了一定的用戶量之后，肯定會(huì)遇到一些問題。環(huán)信給出一些建議，首先如果使用第三方，一般會(huì)注冊(cè)一些信息， 這時(shí)最好是由自己的服務(wù)器來下發(fā)，不要內(nèi)置在應(yīng)用中，否則信息容易泄露。

第二個(gè)是比較關(guān)鍵的信息，就是保護(hù)好用戶列表。比如在已經(jīng)具備一定的用戶量之后，如果此時(shí)被拖庫或者網(wǎng)站被攻擊，用戶可能會(huì)收到廣告或者一些灰產(chǎn)信息，所以用戶列表就比較關(guān)鍵了，不管用戶是不是通過手機(jī)號(hào)注冊(cè)，用戶 ID 要散列，而且不要對(duì)用戶可見。

另外，環(huán)信的服務(wù)端有類似于全員通知的功能，針對(duì)全員通知這個(gè)功能，我們添加了相應(yīng)的白名單功能，在配置好之后，只有某個(gè)特定的服務(wù)器才能給全員發(fā)通知。如果你的業(yè)務(wù)能夠開啟好友之間發(fā)消息的限制，最好就開啟，這樣即使用戶 ID 被泄露，用戶也不能隨意地相互之間發(fā)消息。

服務(wù)器校驗(yàn)用戶的合法性也是一個(gè)非常重要的功能，如果是直接在第三方平臺(tái)上注冊(cè)的用戶， 那么他有可能會(huì)直接繞過你的服務(wù)器來給其他的用戶來收發(fā)消息。這種情況建議還是由你的服務(wù)器來簽發(fā) token，然后保證這個(gè) token 一定的時(shí)效性，時(shí)間不要太長，這樣即便某個(gè)用戶有問題，你的服務(wù)器也可以及時(shí)發(fā)現(xiàn)并且封禁這個(gè)用戶。

如果有更進(jìn)一步的安全要求，甚至可以在消息級(jí)別進(jìn)行校驗(yàn)，比如這個(gè)消息有特定的 Key 簽發(fā)密鑰，則消息的收發(fā)雙方都要做相應(yīng)的校驗(yàn)，甚至端到端的消息加密。

當(dāng)然現(xiàn)在環(huán)信也支持了內(nèi)容審核的功能，可以在我們的后臺(tái)配置相應(yīng)的審核規(guī)則。除了前面的保護(hù)措施之外，還要做一些內(nèi)部防范，對(duì)類似于開發(fā)者證書或者內(nèi)部的用戶列表等關(guān)鍵數(shù)據(jù)一定要進(jìn)行相應(yīng)的保護(hù)，比如備份這些數(shù)據(jù)庫的信息，不要被開發(fā)者不經(jīng)意間放到 GitHub 或其他技術(shù)博客上。

五、環(huán)信安全合規(guī)、隱私保護(hù)及相關(guān)認(rèn)證

秉持即時(shí)通訊服務(wù)的易用、高質(zhì)量、安全、合規(guī)理念，環(huán)信在持續(xù)提升自身的安全能力水位的同時(shí)，也依賴開發(fā)者及用戶的密切合作。一般用戶應(yīng)用的集成，如下圖所示：

簡要來說，環(huán)信作為即時(shí)通訊云提供商，會(huì)對(duì)自身PaaS 平臺(tái)和 SDK 的安全進(jìn)行管控;開發(fā)者作為服務(wù)的接入方，需要對(duì)自身應(yīng)用，應(yīng)用服務(wù)器和系統(tǒng)環(huán)境的安全進(jìn)行管控，并根據(jù)自身需求，對(duì)環(huán)信SDK 及服務(wù)的安全選項(xiàng)進(jìn)行合理的配置，以保障自身信息、平臺(tái)、程序、系統(tǒng)和網(wǎng)絡(luò)的安全。

5.1. 安全合規(guī)與隱私保護(hù)

環(huán)信致力于使平臺(tái)產(chǎn)品遵從國內(nèi)外隱私法律法規(guī)要求，包括中國《個(gè)人信息保護(hù)法(草案)》;歐盟《通用數(shù)據(jù)保護(hù)條例》(GDPR))等法律要求。

為此，我們組建了專?的隱私合規(guī)和安全團(tuán)隊(duì)，建立了有效的隱私保護(hù)和安全管理體系，以保護(hù)開發(fā)者及用戶的個(gè)人信息。并對(duì)產(chǎn)品進(jìn)行隱私保護(hù)設(shè)計(jì)評(píng)估和安全評(píng)估，以確保產(chǎn)品中嵌入了隱私和安全方面的考慮;我們根據(jù)開發(fā)者及用戶所在的國家區(qū)域范圍和適用的隱私保護(hù)法律，在適用情況下向其提供個(gè)人數(shù)據(jù)主體權(quán)利;我們遵守隱私保護(hù)法律，使用標(biāo)準(zhǔn)合同條款來轉(zhuǎn)移個(gè)人信息或?qū)㈤_發(fā)者及用戶的個(gè)人信息轉(zhuǎn)移到具有充分?jǐn)?shù)據(jù)保護(hù)的國家。

同時(shí)，我們實(shí)施了適當(dāng)?shù)奈锢怼⒐芾砗图夹g(shù)措施以保護(hù)開發(fā)者及用戶的個(gè)人信息，避免對(duì)個(gè)人信息未授權(quán)訪問、更改、披露和濫用。我們的即時(shí)通訊 SDK 提供了內(nèi)置加密算法;與開發(fā)者及用戶的網(wǎng)絡(luò)通信支持加密傳輸協(xié)議保護(hù);我們服務(wù)端存儲(chǔ)的用戶數(shù)據(jù)同樣支持加密保護(hù)。

此外，環(huán)信遵循國際認(rèn)可的信息安全和隱私保護(hù)標(biāo)準(zhǔn)以及行業(yè)要求，致力于采用國際最佳實(shí)踐來建設(shè)隱私和安全管理體系，在保障產(chǎn)品安全合規(guī)的同時(shí)，也為開發(fā)者及用戶提供合規(guī)支持，幫助開發(fā)者及用戶遵守適用法律法規(guī)和監(jiān)管要求。

5.2 安全標(biāo)準(zhǔn)和認(rèn)證(GDPR)

目前，環(huán)信已經(jīng)通過了多個(gè)國際認(rèn)可的信息安全和隱私管理體系認(rèn)證，包括 ISO/IEC 27001、公安部等級(jí) 2.0 保護(hù)三級(jí)、GDPR 等，以此證明自身的隱私合規(guī)、安全管理以及國際化能力。

ISO/IEC 27001: 2013 信息安全管理標(biāo)準(zhǔn)

ISO/IEC 27001: 2013 是最基礎(chǔ)的、獲得國際最廣泛認(rèn)可的信息安全管理體系標(biāo)準(zhǔn)。

公安部信息安全等級(jí)保護(hù)三級(jí)認(rèn)證

《GB/T 22239-2019 信息安全技術(shù) 網(wǎng)絡(luò)安全等級(jí)保護(hù)基本要求》簡稱安全等級(jí)保護(hù)，是中國國家標(biāo)準(zhǔn)化管理委員會(huì)發(fā)布的信息安全標(biāo)準(zhǔn)，是中華人民共和國信息安全保障的一項(xiàng)基本制度。等級(jí)根據(jù)信息系統(tǒng)的重要程度，從低到高分為 1 至 5 個(gè)等級(jí)，不同安全等級(jí)實(shí)施不同的保護(hù)

策略和要求。環(huán)信采用的是 3 級(jí)信息系統(tǒng)的保護(hù)策略，并順利通過了國家網(wǎng)絡(luò)與信息系統(tǒng)安全產(chǎn)品質(zhì)量監(jiān)督檢驗(yàn)中心(公安部第三研究所)的測(cè)評(píng)。

歐盟《通用數(shù)據(jù)保護(hù)條例》(GDPR)

歐盟議會(huì)于 2016 年 4 月 14 日通過的《通用數(shù)據(jù)保護(hù)條例(General Data Protection Regulations)》(“GDPR”)于 2018 年 5 月 25 日在歐盟成員國內(nèi)正式生效實(shí)施。GDPR 堪稱史上最嚴(yán)格的數(shù)據(jù)保護(hù)法案，它的實(shí)施代表著歐盟對(duì)個(gè)人信息保護(hù)及其監(jiān)管達(dá)到了前所未有的高度。該條例的適用范圍極為廣泛，任何收集、傳輸、保留或處理涉及到歐盟所有成員國內(nèi)的個(gè)人信息的機(jī)構(gòu)組織均受該條例的約束。

作為行業(yè)首家遵從GDPR 安全法規(guī)要求的企業(yè)，在GDPR(General Data Protection Regulation)方面，環(huán)信做到了極致的隱私數(shù)據(jù)保護(hù)，用戶拒絕營銷和被遺忘權(quán)，嚴(yán)格的角色權(quán)限區(qū)分和訪問控制管理，日志審計(jì)和脫敏，SDK、Server 端代碼全量掃描，嚴(yán)苛的運(yùn)維操作流程管理等。

六、環(huán)信即時(shí)通訊 PaaS 服務(wù)的安全

從邏輯劃分，環(huán)信即時(shí)通訊 PaaS 服務(wù)，主要包含數(shù)據(jù)中心服務(wù)以及提供給開發(fā)者的 IM SDK。在該章節(jié)，我們將系統(tǒng)性地介紹各層中的技術(shù)及運(yùn)營環(huán)節(jié)的安全風(fēng)險(xiǎn)控制措施。

6.1 數(shù)據(jù)中心計(jì)算資源安全

環(huán)信即時(shí)通訊服務(wù)由國內(nèi)外多個(gè)數(shù)據(jù)中心(IDC)以及頭部公有云供應(yīng)商的云服務(wù)組成，以構(gòu)建一個(gè)統(tǒng)一、高可用、高擴(kuò)展、高效率、高安全的基礎(chǔ)資源環(huán)境。

6.1.1 網(wǎng)絡(luò)隔離

對(duì)網(wǎng)絡(luò)進(jìn)行合理的劃分，定義清晰用途，制定適配的訪問控制策略，是網(wǎng)絡(luò)安全的前提之一。環(huán)信基于 IM PaaS 承載功能和安全級(jí)別的不同，將網(wǎng)絡(luò)劃分出了核心、邊緣、IT 等幾大安全區(qū)域。在不同的安全域之間，根據(jù)不同的業(yè)務(wù)訪問需求和安全級(jí)別，環(huán)信制定了不同的路由策略以及嚴(yán)格的安全訪問策略。

6.1.2 防 DDoS 攻擊

分布式拒絕服務(wù)攻擊(Distributed Denial of Service，DDoS)會(huì)對(duì) IM 服務(wù)的系統(tǒng)和業(yè)務(wù)可用性產(chǎn)生重大影響，嚴(yán)重時(shí)可導(dǎo)致服務(wù)中斷或質(zhì)量下降。為此，環(huán)信基于自身服務(wù)的特性，結(jié)合公有云能力，在核心服務(wù)上部署了 DDoS 防御方案。該方案能夠?qū)崟r(shí)檢測(cè)并防御來自網(wǎng)絡(luò)層、傳輸?shù)?DDoS 攻擊。防 DDoS 攻擊方案，能夠自動(dòng)檢測(cè)、自動(dòng)調(diào)度并觸發(fā)清洗功能，數(shù)秒內(nèi)就可以完成攻擊、流量清洗動(dòng)作，保證核心服務(wù)的可用性。

此外所有 DDoS 攻擊事件，都會(huì)通過郵件、短信、電話等方式，第一時(shí)間知會(huì)安全團(tuán)隊(duì)，以便安全團(tuán)隊(duì)持續(xù)關(guān)注和響應(yīng)決策。

6.1.3 主機(jī)、數(shù)據(jù)庫、中間件等計(jì)算資源安全

各類服務(wù)運(yùn)行所依賴的資源，由操作系統(tǒng)或容器化為關(guān)聯(lián)的后臺(tái)程序、緩存、數(shù)據(jù)庫等中間件， 合理地調(diào)度分配 CPU、內(nèi)存、磁盤等資源來滿足。環(huán)信結(jié)合自身基礎(chǔ)服務(wù)場(chǎng)景，在實(shí)際安全運(yùn)營中，通過制定適配的安全基線、漏洞管理規(guī)范，并落地縱深威脅檢測(cè)機(jī)制，確?；A(chǔ)運(yùn)算負(fù)載資源的安全性。

6.1.3.1 安全基線

環(huán)信制定了 IDC 和公有云的安全基線，涵蓋主機(jī)操作系統(tǒng)、容器、數(shù)據(jù)庫、存儲(chǔ)、Web 服務(wù)等中間件，內(nèi)容包括賬戶安全、身份認(rèn)證、最小服務(wù)、最小授權(quán)、日志審計(jì)、時(shí)鐘同步等。并根據(jù)不同的用途，對(duì)操作系統(tǒng)或中間件進(jìn)行不同程度的安全配置加固，確保新交付的運(yùn)算負(fù)載資源滿足相關(guān)安全基線要求。對(duì)于運(yùn)行中的負(fù)載資源，安全團(tuán)隊(duì)會(huì)進(jìn)行定期的配置巡檢，對(duì)比與安全基線的差異，輸出不符合項(xiàng)，通知到關(guān)聯(lián)的運(yùn)維和業(yè)務(wù)技術(shù)團(tuán)隊(duì)，并落實(shí)整改。

6.1.3.2 漏洞管理

所有交付上線的運(yùn)算負(fù)載資源，均來自統(tǒng)一管理的操作系統(tǒng)鏡像或中間件軟件包。對(duì)于交付使用中的資源，安全團(tuán)隊(duì)會(huì)采集操作系統(tǒng)和中間件版本信息，然后發(fā)送到安全運(yùn)營系統(tǒng)中分析， 從而識(shí)別是否存在受漏洞影響的版本。對(duì)于公有云上的主機(jī)資源，環(huán)信會(huì)部署公有云的安全客戶端，實(shí)現(xiàn)對(duì)操作系統(tǒng)和中間件等軟件產(chǎn)品的實(shí)時(shí)漏洞檢測(cè)。另外，安全團(tuán)隊(duì)通過部署業(yè)界知名商業(yè)漏洞掃描產(chǎn)品，定期對(duì)運(yùn)算負(fù)載資源發(fā)起掃描巡檢，輸出漏洞掃描報(bào)告，并將信息采集到安全運(yùn)營系統(tǒng)。

一旦發(fā)現(xiàn)存在漏洞版本匹配的組件，安全團(tuán)隊(duì)會(huì)對(duì)漏洞的風(fēng)險(xiǎn)做綜合評(píng)估，提供應(yīng)急處置措施和修復(fù)建議，并聯(lián)合運(yùn)維及相關(guān)業(yè)務(wù)技術(shù)團(tuán)隊(duì)落實(shí)漏洞修復(fù)、配置加固、鏡像更新，從而實(shí)現(xiàn)漏洞管理的閉環(huán)。

6.1.3.3 計(jì)算資源中的安全運(yùn)維

運(yùn)維賬號(hào)安全

在日常運(yùn)維中，環(huán)信制定并啟用了 IAM(Identity and Access Management，身份和訪問控制管理)機(jī)制，所有涉及運(yùn)維內(nèi)容的人員必須具有有效的身份和授權(quán)才可進(jìn)行操作，運(yùn)維賬號(hào)與員工身份一一對(duì)應(yīng)，其默認(rèn)啟用 MFA(Multi-factor authentication, 多重要素驗(yàn)證)。

操作系統(tǒng)賬號(hào)安全

對(duì)于系統(tǒng)賬號(hào)，環(huán)信制定了一系列安全制度和操作規(guī)范，例如，避免使用弱口令作為密碼，并要求定期更換，信息安全團(tuán)隊(duì)也會(huì)通過定期的安全檢查。

運(yùn)維操作審計(jì)

環(huán)信在日常運(yùn)維過程中，會(huì)實(shí)時(shí)記錄歸檔各類操作，制定實(shí)時(shí)監(jiān)控告警策略，并對(duì)風(fēng)險(xiǎn)操作及時(shí)處置。

6.2 SDK 安全

環(huán)信提供 iOS、Android、Flutter、React Native、Windows、小程序、Web 等平臺(tái)的 SDK 支持，以滿足開發(fā)者及用戶的各類實(shí)時(shí)音視頻互動(dòng)接入需求。IM SDK 不僅僅為開發(fā)者及用戶提供簡單、易用、統(tǒng)一、可信、安全的即時(shí)通訊開發(fā)套件，也竭盡全力為開發(fā)者及用戶提供合規(guī)、安全的配置選項(xiàng)，以提升開發(fā)者及用戶在實(shí)時(shí)音視頻互動(dòng)場(chǎng)景和應(yīng)用中合規(guī)監(jiān)管和應(yīng)對(duì)信源數(shù)據(jù)安全威脅的能力。

根據(jù)國家法律法規(guī)規(guī)定及監(jiān)管機(jī)構(gòu)執(zhí)法要求，APP 在使用第三方SDK 時(shí)，必須在APP《隱私政策》中告知用戶，并在調(diào)用時(shí)序上做好延遲初始化配置，確保用戶同意 APP《隱私政策》后 SDK 才可以被啟動(dòng)，進(jìn)行數(shù)據(jù)采集和服務(wù)。為了幫助開發(fā)者避免合規(guī)風(fēng)險(xiǎn)，環(huán)信推出隱私政策合規(guī)要求，包括隱私政策展示內(nèi)容和展示形式合規(guī)。

6.2.1 SDK 的合規(guī)與安全保證

環(huán)信在為開發(fā)者提供 SDK 時(shí)，SDK 的可信和安全是首要保證的內(nèi)容之一。在評(píng)審 SDK 新增或迭代的功能時(shí)，會(huì)充分評(píng)估功能需求在合規(guī)隱私以及安全上的風(fēng)險(xiǎn)點(diǎn)，確保與環(huán)信合規(guī)和隱私政策的一致性。功能實(shí)現(xiàn)時(shí)，會(huì)在進(jìn)行充分的質(zhì)量保證(QA)測(cè)試時(shí)對(duì)代碼進(jìn)行安全審計(jì)， 在涉及引用或集成第三方 SDK、庫文件時(shí)進(jìn)行安全檢測(cè)，尤其是合規(guī)性確認(rèn)，例如，是否存在惡意代碼或后門，是否遵守版權(quán)或使用協(xié)議。如果檢測(cè)出存在風(fēng)險(xiǎn)，SDK 只有在修復(fù)并確認(rèn)無風(fēng)險(xiǎn)后，才允許進(jìn)入下一階段。在分發(fā)環(huán)節(jié)，會(huì)在官方渠道更新。

6.2.2 對(duì)開發(fā)者及用戶的安全與合規(guī)支持

在 SDK 上，環(huán)信提供了設(shè)備端存儲(chǔ)內(nèi)容加密，日志安全等安全配置選項(xiàng)，以協(xié)助開發(fā)者及用戶完善即時(shí)通訊數(shù)據(jù)安全及隱私合規(guī)。有需要的開發(fā)者及用戶，可以參考開發(fā)者文檔進(jìn)行配置啟用。

6.2.2.1 本地存儲(chǔ)內(nèi)容

環(huán)信 SDK 使用行業(yè)標(biāo)準(zhǔn)的加密技術(shù)對(duì)在設(shè)備本地的消息等內(nèi)容記錄進(jìn)行加密存儲(chǔ)。

6.2.2.2 日志脫敏

環(huán)信SDK 提供不同的日志級(jí)別，方便開發(fā)者在開發(fā)調(diào)試和發(fā)布時(shí)使用，同時(shí)對(duì)設(shè)備上的日志進(jìn)行脫敏，防止用戶數(shù)據(jù)被識(shí)別和竊取。

6.3 RESTful API 安全

為方便開發(fā)者高效地管理自己的應(yīng)用和服務(wù)，諸多業(yè)務(wù)功能和管理功能以 RESTful API 的方式供開發(fā)者調(diào)用。在安全保障上，除了將站點(diǎn)接入 WAF 外，還有如下的安全控制措施。

身份鑒權(quán)

開發(fā)者在使用 RESTful API 前，需先登錄控制臺(tái)，創(chuàng)建開發(fā)者專屬的 key&secret。后續(xù) API 調(diào)用，需使用對(duì)應(yīng)的 key&secret 對(duì)，以區(qū)分不同項(xiàng)目或應(yīng)用。

傳輸安全

RESTful API 支持 HTTPS 協(xié)議，以確保使用 SSL / TLS 對(duì)所有 API 通信進(jìn)行加密，可以保護(hù) API憑據(jù)和傳輸?shù)臄?shù)據(jù)，以及防止一些如中間人攻擊(MITM, man in the middle)等。

API 限速

服務(wù)端對(duì) API 請(qǐng)求的速率有限制，在保證正常用戶請(qǐng)求可以得到響應(yīng)的同時(shí)，限制惡意用戶的 API 請(qǐng)求。

輸入驗(yàn)證

開發(fā)者請(qǐng)求的參數(shù)會(huì)經(jīng)過服務(wù)器后臺(tái)過濾，以避免一些常見的易受攻擊缺陷(SQL-注入，遠(yuǎn)程代碼執(zhí)行等)。

七、環(huán)信數(shù)據(jù)安全

數(shù)據(jù)作為信息活動(dòng)的載體，經(jīng)過合法合規(guī)且安全的處理尤為重要。數(shù)據(jù)安全是環(huán)信最為關(guān)切的問題之一，本節(jié)將介紹環(huán)信在數(shù)據(jù)安全上采取的政策及落實(shí)的管理和技術(shù)控制措施。

7.1 數(shù)據(jù)安全政策

針對(duì)日益嚴(yán)峻的網(wǎng)絡(luò)安全態(tài)勢(shì)，以及逐漸趨緊的監(jiān)管要求，環(huán)信堅(jiān)持以數(shù)據(jù)保密、完整和高可用作為業(yè)務(wù)服務(wù)的數(shù)據(jù)安全發(fā)展戰(zhàn)略，并將數(shù)據(jù)安全理念融入安全體系建設(shè)過程中，即

保密性：防止未經(jīng)授權(quán)的訪問和竊聽

完整性：防止惡意篡改和偽造數(shù)據(jù)

可用性：通過不同數(shù)據(jù)中心和邊緣節(jié)點(diǎn)保障數(shù)據(jù)高可用

因此環(huán)信對(duì)所有員工均開展信息保護(hù)、隱私合規(guī)及保密意識(shí)安全培訓(xùn)，并簽訂保密協(xié)議;對(duì)違反數(shù)據(jù)安全制度和保密要求的人員，我們會(huì)視情形嚴(yán)重程度以采取相應(yīng)的違規(guī)處理措施，包括但不限于談話、加強(qiáng)培訓(xùn)考核、解除勞動(dòng)協(xié)議及追究其他法律責(zé)任等措施。

7.2 數(shù)據(jù)采集

采用最小化的數(shù)據(jù)采集原則，只采集經(jīng)用戶授權(quán)同意的，且業(yè)務(wù)所必須的數(shù)據(jù)字段。

7.3 數(shù)據(jù)脫敏

為保護(hù)數(shù)據(jù)隱私，環(huán)信針對(duì)官網(wǎng)控制臺(tái)的企業(yè)和個(gè)人信息均進(jìn)行脫敏后的展示，此策略同樣也適用于不同的服務(wù)和SDK。

7.4 數(shù)據(jù)保護(hù)和加密傳輸

在 IM PaaS 服務(wù)中，對(duì)于不同的傳輸通道例如SDK 與服務(wù)器，服務(wù)器與用戶的應(yīng)用服務(wù)器之間等，都支持安全傳輸協(xié)議(HTTPS/TLS/WSS 等)

7.5 數(shù)據(jù)使用和存儲(chǔ)

對(duì)于開發(fā)者及用戶的機(jī)密信息，如密碼，我們會(huì)以哈希加鹽值(salt)的方式進(jìn)行存儲(chǔ)。對(duì)已存 儲(chǔ)的信息，將根據(jù)相關(guān)監(jiān)管要求和制定的數(shù)據(jù)備份和存儲(chǔ)策略，嚴(yán)格制定數(shù)據(jù)保存期限，并按要求在需要時(shí)對(duì)其進(jìn)行銷毀;對(duì)來自開發(fā)者及用戶的數(shù)據(jù)處理申請(qǐng)，我們將根據(jù)開發(fā)者及用戶的授權(quán)及相應(yīng)監(jiān)管要求配合實(shí)施數(shù)據(jù)清理或轉(zhuǎn)移。

7.6 用戶的數(shù)據(jù)權(quán)利

提供了不同維度的用戶權(quán)益的 API 方面支持用戶數(shù)據(jù)的導(dǎo)出和刪除。

八、環(huán)信安全運(yùn)營

安全是一個(gè)持續(xù)的過程，在實(shí)際安全運(yùn)營中，環(huán)信基于自身業(yè)務(wù)特性，通過如下維度來開展。

8.1 安全開發(fā)生命周期管理 SDL

在軟件開發(fā)生命周期中，嵌入了安全和隱私的相關(guān)要求，結(jié)合當(dāng)前流行的 DevSecOps，讓 SDL 流程更自動(dòng)化，從而在原有的安全開發(fā)生命周期的基礎(chǔ)上，更高效的進(jìn)行安全和隱私的檢查。

8.1.1 威脅建模

在設(shè)計(jì)和架構(gòu)階段，為了能夠更早的發(fā)現(xiàn)風(fēng)險(xiǎn)，通過威脅建模來識(shí)別潛在的安全問題并實(shí)施響應(yīng)環(huán)節(jié)措施。為了有效發(fā)現(xiàn)并解決設(shè)計(jì)階段的潛在風(fēng)險(xiǎn)，參考 STRIDE 的威脅建模方法，主要聚焦攻擊面最小化，基本隱私，權(quán)限最小化，默認(rèn)安全，數(shù)據(jù)加密等。

8.1.2 CI/CD 黑白盒檢測(cè)

在安全測(cè)試層面更注重 DevSecOps 崇尚的內(nèi)置安全防護(hù)，且已在 CI/CD 層面進(jìn)行了黑白盒工具的集成，包含開源代碼掃描工具 SonarQube，組件及合規(guī)掃描商業(yè)工具 BlackDuck，App/Sdk 掃描工具 MobSF 等，從而完善在集成發(fā)布過程中的風(fēng)險(xiǎn)監(jiān)測(cè)。

8.2 反入侵和安全監(jiān)控

環(huán)信的各類運(yùn)算系統(tǒng)、業(yè)務(wù)應(yīng)用服務(wù)每天都會(huì)產(chǎn)生海量的日志數(shù)據(jù)。在落實(shí)縱深防御以應(yīng)對(duì)威脅的基礎(chǔ)之上，安全團(tuán)隊(duì)也會(huì)在最小權(quán)限范圍內(nèi)采集用于安全分析的日志?；谶@些日志，通過安全監(jiān)控分析平臺(tái)實(shí)時(shí)運(yùn)算。對(duì)識(shí)別的安全異常事件，會(huì)及時(shí)告警，安全運(yùn)營人員會(huì)進(jìn)一步展開關(guān)聯(lián)以及溯源分析復(fù)核;對(duì)確認(rèn)的風(fēng)險(xiǎn)，會(huì)根據(jù)應(yīng)急響應(yīng)機(jī)制進(jìn)行處置和追蹤，以保障業(yè)務(wù)系統(tǒng)的安全性和可用性。

8.3 安全應(yīng)急響應(yīng)機(jī)制

基于自身即時(shí)通訊業(yè)務(wù)特性，對(duì)服務(wù)類型進(jìn)行分類分級(jí)，系統(tǒng)性地安全評(píng)估和威脅識(shí)別，制定不同的安全事件分類標(biāo)準(zhǔn)，以及響應(yīng)時(shí)效和處置流程，以確保及時(shí)有效地處理安全異常。

8.4 安全合作

在自身內(nèi)部安全建設(shè)的基礎(chǔ)上，環(huán)信已與 Trustwave 等多家第三方安全廠商合作，定期進(jìn)行滲透測(cè)試，代碼審查，逆向工程等來幫助環(huán)信發(fā)現(xiàn)線上應(yīng)用、系統(tǒng)、服務(wù)以及 SDK 等層面的安全漏洞和各類潛在風(fēng)險(xiǎn)，從而提升整體服務(wù)安全性和系統(tǒng)健壯性。

九、APP 開發(fā)者接入環(huán)信 SDK 的合規(guī)要求

根據(jù)國家法律法規(guī)規(guī)定及監(jiān)管機(jī)構(gòu)執(zhí)法要求，APP 在使用第三方SDK 時(shí)，必須在APP《隱私政策》中告知用戶，并在調(diào)用時(shí)序上做好延遲初始化配置，確保用戶同意 APP《隱私政策》后 SDK 才可以被啟動(dòng)，進(jìn)行數(shù)據(jù)采集和服務(wù)。為了幫助環(huán)信開發(fā)者避免合規(guī)風(fēng)險(xiǎn)，環(huán)信推出了隱私政策合規(guī)要求，包括隱私政策展示內(nèi)容和展示形式合規(guī)。

9.1.隱私政策內(nèi)容合規(guī)

注意：本信息收集范圍說明適用于SDK3.8.4 版本及以上

當(dāng)APP 開發(fā)者接入環(huán)信 SDK 服務(wù)時(shí)，請(qǐng)務(wù)必按照我國法律法規(guī)、規(guī)范性文件之要求，在APP 自身的隱私政策或個(gè)人信息保護(hù)政策等相關(guān)公示文件中“第三方服務(wù)”/“第三方合作伙伴”部分明確列出本APP 所集成的環(huán)信 SDK 收集、使用個(gè)人信息的目的、方式和范圍，環(huán)信提供如下兩種參考表達(dá)話術(shù)，以方便APP 開發(fā)者更高效、更合規(guī)地調(diào)整自身的隱私政策，共同保護(hù)個(gè)人信息。

參考表達(dá)一、以文字方式向用戶呈現(xiàn)

如：我們使用了第三方(北京億思摩博網(wǎng)絡(luò)科技有限公司，以下稱“環(huán)信”) 環(huán)信 SDK 服務(wù)為您提供【 】功能。為了順利實(shí)現(xiàn)該功能，您需要授權(quán)環(huán)信 SDK 提供對(duì)應(yīng)的服務(wù);在您授權(quán)后， 環(huán)信將收集您相關(guān)的個(gè)人信息。

參考表達(dá)二、以表格方式向用戶呈現(xiàn)

如：【您的 APP 名稱】(iOS 版/Android 版)內(nèi)嵌第三方SDK 詳情

9.2 隱私政策展示形式合規(guī)

需要增加明確彈窗，有明顯同意和拒絕按鈕，讓用戶自主選擇是否接受隱私政策。App 隱私政策包含的環(huán)信隱私權(quán)政策鏈接可允許用戶點(diǎn)擊查看。

十、結(jié)語

為開發(fā)者提供合規(guī)、安全、可信的即時(shí)通訊云平臺(tái)，是環(huán)信所有架構(gòu)和產(chǎn)品服務(wù)首要考慮的要素之一。環(huán)信從人員、技術(shù)、管理、流程等多個(gè)方面系統(tǒng)性推進(jìn)信息安全政策的落地，履行監(jiān)管合規(guī)義務(wù)，與行業(yè)客戶以及第三方社區(qū)或團(tuán)體個(gè)人緊密合作，同時(shí)積極探索新的技術(shù)，推進(jìn)安全自動(dòng)化、智能化，實(shí)現(xiàn)安全防護(hù)能力高效輸出。

在日趨復(fù)雜的互聯(lián)網(wǎng)環(huán)境下，技術(shù)迭代周期越來越短，新型攻擊手段層出不窮，我們無時(shí)不刻都在面臨各類安全威脅。篳路藍(lán)縷啟山林、櫛風(fēng)沐雨砥礪行，在此背景下，希望本白皮書能夠?yàn)槠髽I(yè)或機(jī)構(gòu)的安全建設(shè)提供參考和借鑒，也歡迎業(yè)界同仁共同參與完善，助力行業(yè)高質(zhì)量穩(wěn)健發(fā)展!

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！