前言
隨著移動互聯(lián)網(wǎng)和 5G 通信新技術(shù)的浪潮席卷全球，傳統(tǒng)的通信方式已經(jīng)發(fā)生了翻天覆地的變化。人們已經(jīng)習慣了通過即時通訊軟件和網(wǎng)絡(luò)交流平臺分享自己生活的方方面面，隨著人們越來越公開自己的生活，人們也開始關(guān)注隱私和安全等問題。
隱私作為人們不愿為他人知曉的私密空間、私密活動和私密信息，歷來被互聯(lián)網(wǎng)用戶所關(guān)注。尤其是在即時通訊服務(wù)的使用過程中，用戶可以輕易將自己的隱私傳輸至互聯(lián)網(wǎng)上，這使得用戶在享受便捷服務(wù)的同時，更容易因隱私泄露而影響生活安寧。近些年來各類隱私泄露事件更是讓人們在享受便捷的互聯(lián)網(wǎng)服務(wù)時，對網(wǎng)絡(luò)服務(wù)提供者的隱私保護能力持懷疑態(tài)度。甚至在某種程度上，隱私保護逐漸成為用戶選擇網(wǎng)絡(luò)服務(wù)時考慮的重要因素。為了保護用戶的隱私， 世界各地都相繼出臺了隱私保護相關(guān)的法律法規(guī)，使得企業(yè)的隱私保護合規(guī)工作更加具有挑戰(zhàn)性。
作為全球互聯(lián)網(wǎng)消息云的開創(chuàng)者和引領(lǐng)者，數(shù)據(jù)和用戶隱私安全是環(huán)信最關(guān)切的問題。環(huán)信始終將數(shù)據(jù)和用戶隱私安全作為首要安全原則，并將其作為理念融入安全能力建設(shè)當中，2021 年環(huán)信行業(yè)首家通過了史上最嚴格的數(shù)據(jù)保護法案“GDPR”的相關(guān)安全合規(guī)標準。
為幫助開發(fā)者及用戶感知和理解環(huán)信在即時通訊服務(wù)上的努力，了解環(huán)信服務(wù)的安全屬性，CSDN聯(lián)合環(huán)信特發(fā)布即時通訊行業(yè)首個《安全合規(guī)白皮書》。該白皮書全面分析了安全合規(guī)的趨勢及國內(nèi)外監(jiān)管重點，同時給出環(huán)信在即時通信領(lǐng)域安全合規(guī)開發(fā)的經(jīng)驗及建議，還列舉了環(huán)信云服務(wù)的相關(guān)安全和合規(guī)工作，希望能夠為業(yè)界提供了全面、詳實的安全能力建設(shè)參考。
目錄
1.安全合規(guī)的趨勢
1.1隱私監(jiān)管趨緊
1.2APP/SDK 趨嚴
1.3安全合規(guī)的基本框架
2.國內(nèi)外的監(jiān)管重點
2.1國內(nèi) App 上架-信息采集
2.2國內(nèi) App 上架-符合安全規(guī)定
2.3海外的關(guān)注-?戶權(quán)利
2.4共同關(guān)注點-數(shù)據(jù)跨境
3.如何評估和滿?安全合規(guī)要求
3.1如何評估安全合規(guī)的要求
3.2產(chǎn)品架構(gòu)維度
3.3數(shù)據(jù)處理流程的維度
4.安全合規(guī)開發(fā)經(jīng)驗及建議
4.1安全合規(guī)能?建設(shè)需要做什么
4.2?前安全合規(guī)的能?
4.3開發(fā)建議-即時通訊領(lǐng)域
5.環(huán)信安全合規(guī)、隱私保護及相關(guān)認證
5.1環(huán)信安全合規(guī)和隱私保護
5.2安全標準和認證(GDPR)
6.環(huán)信即時通訊 PaaS 服務(wù)的安全
6.1數(shù)據(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ù)保護和加密傳輸
7.5數(shù)據(jù)使用和存儲
7.6用戶的數(shù)據(jù)權(quán)利
8.安全運營
8.1安全開發(fā)生命周期管理 SDL
8.2反入侵和安全監(jiān)控
8.3安全應(yīng)急響應(yīng)機制
8.4安全合作
9.APP 開發(fā)者接入環(huán)信 SDK 的合規(guī)要求
9.1隱私政策內(nèi)容合規(guī)
9.2隱私政策展示形式合規(guī)
10.結(jié)語
引言
在監(jiān)管趨緊的形式下，即時通訊場景會遇到很多安全合規(guī)領(lǐng)域的挑戰(zhàn)，如何滿足這些安全合規(guī)的要求，如何保護用戶的隱私安全，是一件非常有挑戰(zhàn)的事情。
一、安全合規(guī)的趨勢
1.1 、隱私監(jiān)管趨緊
最近四五年來，安全合規(guī)的趨勢變得越來越嚴格，各個國家都有比較重磅的安全合規(guī)的相關(guān)法規(guī)出臺，比如美國加州的《消費者隱私法案》《兒童在線隱私保護法》、保險醫(yī)療領(lǐng)域的 HIPPA，以及歐盟推出的比較有代表性的《通用數(shù)據(jù)保護條例》。國內(nèi)去年也出臺了《個人信息保護法》
《數(shù)據(jù)安全法》，加上之前發(fā)布的《網(wǎng)絡(luò)安全法》，對于安全合規(guī)領(lǐng)域的覆蓋逐漸比較完善。
1.2 、App/SDK 趨嚴
圖 1 所示為國內(nèi)主要的有關(guān)法規(guī)和內(nèi)容，而且這個趨勢也是越來越嚴格，比如工信部發(fā)布的各種應(yīng)用下架的新聞或者公告，都涉及了個人數(shù)據(jù)隱私相關(guān)的內(nèi)容。
1.3 、安全合規(guī)的基本框架
安全合規(guī)的基本框架可以總結(jié)成兩個方向，一個是用戶知情同意，另一個就是安全保障義務(wù)。我們以《通用數(shù)據(jù)保護條例》( GDPR )為例，它是一個法規(guī)條文，內(nèi)容包括各種監(jiān)管措施、懲罰措施，還規(guī)定了應(yīng)保障的用戶權(quán)利，后續(xù)章節(jié)將介紹一些具體的用戶權(quán)利說明。
二、國內(nèi)外的監(jiān)管重點
關(guān)于國內(nèi)外監(jiān)管的重點，從國內(nèi)這幾年的角度來看，主要包括以下幾個方面：
2.1 、國內(nèi) App 上架 —— 信息采集
如圖 2 所示，用戶信息的采集方面正受到越來越多的重視，國家部委出臺了《常見類型移動互聯(lián)網(wǎng)應(yīng)用程序必要個人信息的范圍規(guī)定》，指出了二三十個場景下能夠采集的必要的個人信息。
比如地圖導(dǎo)航類，它的基本功能是定位和導(dǎo)航，必要的個人信息為位置信息、出發(fā)地和到達地。開發(fā)者在開發(fā)應(yīng)用的時候首要確認相關(guān)信息，如果收集了其余非必要數(shù)據(jù)App 就無法上架。
再比如網(wǎng)絡(luò)社區(qū)類應(yīng)用，它的基本功能是博客、論壇等，這些個人信息跟即時通訊類的必要信息比較接近，諸如用戶的移動電話號碼和賬號聯(lián)系人等信息。網(wǎng)約車類型中也規(guī)定了電話號碼， 包括出發(fā)地、到達地、支付時間、支付信息等。為什么即時通訊類需要移動電話號碼呢?一般認為是只需要賬號就可以了?接下來的篇幅就解釋了這個問題。
2.2 、國內(nèi) App 上架 —— 符合安全規(guī)定
除了可以采集的必要信息的約束之外，我國還有很多特定的相關(guān)不同行業(yè)或領(lǐng)域的約束。
在應(yīng)用的上架流程中，應(yīng)用商店都有詳細的審查規(guī)定，如果涉及即時通訊、直播或者用戶輿論領(lǐng)域，就需要一個安全評估報告，這個安全評估報告中增加了額外的要求，比如說用戶真實身份的核驗，就是要核驗服務(wù)中用戶的身份是真實可靠的，這里就回答了前面即時通訊領(lǐng)域的問題，想真正地服務(wù)客戶，就要能夠做到實名制，而實名制其實一般就是通過校驗手機號和短信等方式。
另外，其實這還涉及用戶輿論的問題，需要針對這個問題建立投訴舉報的機制，公布投訴舉報的聯(lián)系方式和處理情況，對于這些用戶的昵稱、信息發(fā)布、轉(zhuǎn)發(fā)評論等，要有相關(guān)的記錄保存措施，通過一定的保存機制來支持追查這些信息。這樣一方面約束了必要的個人信息的采集; 另一方面在不同的領(lǐng)域也補充了額外的要求，比如金融或者醫(yī)療領(lǐng)域就有更高級別的相關(guān)要求。
根據(jù)工信部數(shù)據(jù)顯示，近期違規(guī)下架應(yīng)用累計為 3000 款左右，涉及的問題大部分是違規(guī)收集個人信息，少量是強制或者索取權(quán)限相關(guān)的問題，國內(nèi)的應(yīng)用、網(wǎng)站可能涉及的問題主要集中在這幾個方面。
2.3 、海外的關(guān)注 —— 用戶權(quán)利
如果目標客戶是在海外，那么會發(fā)現(xiàn)海外的側(cè)重點稍有不同。除了常見的這些安全約束之外， 其更關(guān)注用戶的權(quán)利。
舉幾個例子，比如用戶的知情權(quán)、信息獲取權(quán)、修改權(quán)和被遺忘權(quán)。知情權(quán)就是明確地告知用戶要收集哪些信息、信息用來做什么以及保存多久;信息獲取權(quán)就是用戶必須能夠?qū)С鲎约旱臄?shù)據(jù);修改權(quán)就是用戶可以對個人信息進行修改;被遺忘權(quán)就是用戶有權(quán)利注銷和刪除自己的數(shù)據(jù)。Facebook 等海外的大型平臺都支持注銷賬號、導(dǎo)出個人數(shù)據(jù)等功能，這些是海外比較重視的方面。
圖 3 案例所示，英國的數(shù)據(jù)保護監(jiān)管機構(gòu)向加拿大的一家數(shù)據(jù)分析公司發(fā)出通知，要求其刪除
所有跟英國公民相關(guān)的個人數(shù)據(jù)，如果不履行義務(wù)，將面臨著 2000 萬歐元或者上一年全球總
營業(yè)額 4% 的罰款。這里的 2000 萬歐元和 4% 的罰款就是《通用數(shù)據(jù)保護條例》中所做的規(guī)定，從中不難看出這個措施是非常嚴格的。
2.4 、共同關(guān)注點 —— 數(shù)據(jù)跨境
國內(nèi)和國外還有一個共同的關(guān)注點，就是熱點數(shù)據(jù)跨境，簡單來說就是個人信息和重要的數(shù)據(jù)應(yīng)當在境內(nèi)，這里的在境內(nèi)應(yīng)該就是說，比如中國公民的信息和重要的數(shù)據(jù)不能被隨意地存儲到境外的服務(wù)器上，歐盟地區(qū)的數(shù)據(jù)也不能被隨意地存儲在歐盟以外。其他的地區(qū)比如東南亞或者印度，也有當?shù)氐南嚓P(guān)法律法規(guī)來約束。
如果確實需要向境外提供數(shù)據(jù)，我國的要求是要通過評估辦法進行慎重的評估。歐盟則是要求他們認為已經(jīng)采取足夠的安全保護措施的地區(qū)可以跨境轉(zhuǎn)移數(shù)據(jù)，但至少現(xiàn)在為止中國還不在這個名單上，所以歐盟的數(shù)據(jù)也不能隨意存儲在中國境內(nèi)的服務(wù)器上。
三、如何評估和滿足安全合規(guī)要求
了解了安全合規(guī)的趨勢和相應(yīng)的重點之后，我們?nèi)绾卧u估和滿足安全合規(guī)的要求呢?首先回溯前面介紹的安全合規(guī)的框架。
用戶知情同意包括充分告知和權(quán)利保障。充分告知就是提供用戶隱私協(xié)議，權(quán)利保障就是用戶可以拒絕、可以刪除，而且收集的數(shù)據(jù)要符合最小化原則(最小必要)。
安全保障義務(wù)比較復(fù)雜。首先，從風險評估、公司內(nèi)部的制度建設(shè)到安全開發(fā)流程中都會涉及這個問題，比如產(chǎn)品從需求階段就要有安全方面的專家確認是否涉及用戶數(shù)據(jù)、用戶數(shù)據(jù)怎么傳輸、用戶數(shù)據(jù)怎么來保存、是否是必要的等等，因此從產(chǎn)品需求階段到方案設(shè)計階段，到最后上線階段都要有必要的安全評估。
其次是技術(shù)保障，這里的技術(shù)保障指的是采集過程當中的傳輸、存儲都應(yīng)當采取足夠的技術(shù)保障，換算成技術(shù)角度就是說，傳輸過程中要進行傳輸?shù)募用?，存儲過程中要進行存儲的加密。法律法規(guī)不會規(guī)定具體的某個安全措施，只是要求采取必要的技術(shù)措施保障用戶數(shù)據(jù)的安全。
所以從技術(shù)角度側(cè)理解，要采取業(yè)內(nèi)比較標準的或者比較高標準的安全措施，比如 https 默認是使用其他的傳輸協(xié)議，比如 TCP、UDP 等也應(yīng)當符合業(yè)內(nèi)的安全標準。
當然，安全保障還少不了審計和監(jiān)管，就是說要有一定的安全開發(fā)流程或者安全制度，滿足監(jiān)管機構(gòu)的監(jiān)管要求。
3.1 、如何評估安全合規(guī)的要求
那么，如何評估安全合規(guī)的要求呢?這要看我們具體的涉及的業(yè)務(wù)，不同領(lǐng)域的要求是不一樣的。諸如金融、醫(yī)療等領(lǐng)域的要求會更加嚴格。在某些醫(yī)療領(lǐng)域，對于醫(yī)療用戶(患者)的數(shù)據(jù)或者處理要記錄至少 5 年以上，這是該領(lǐng)域的一個特殊要求。另外，針對不同區(qū)域用戶的要求也不一樣，比如剛才提到的東南亞，新加坡就有自己的特殊規(guī)定，其他地區(qū)也有相關(guān)的特殊要求。
客戶的行業(yè)之間也有不同的安全要求，重要的企業(yè)或者事業(yè)單位，對于數(shù)據(jù)庫有時會有一些特殊的要求，比如要求必須是國內(nèi)的數(shù)據(jù)庫，這就是不同的行業(yè)或者不同的客戶可能面臨的特殊要求。還有一個重要的因素就是要評估依賴的第三方。
例如，我們現(xiàn)在開發(fā)產(chǎn)品或者服務(wù)，免不了要依賴一家甚至多家第三方，這些第三方是否能夠滿足特定的要求也是特別重要的，因為大多數(shù)的應(yīng)用都會依賴多家第三方，在上架或者遭遇審查的時候，由于第三方因素引起應(yīng)用下架也是很正常的。
最后一個是成本因素，就是說要采取技術(shù)措施來保證安全合規(guī)的要求，肯定會帶來成本的增加， 所以從方案角度或者預(yù)算角度來說，要考慮這方面的問題。從相關(guān)經(jīng)驗來說，比如開啟了傳輸加密和存儲加密之后，服務(wù)器成本的大概是百分之四五十這個量級的增長，具體數(shù)字跟不同的行業(yè)和采用的不同技術(shù)關(guān)聯(lián)性特別大。
3.2 、產(chǎn)品架構(gòu)維度
圖 4 展示了產(chǎn)品架構(gòu)的維度，比如一個客戶的應(yīng)用使用了環(huán)信的 SDK，一般來說應(yīng)用也會有自己的 App server，這個 App server 和用戶的應(yīng)用都會跟環(huán)信的服務(wù)進行交互。SDK 跟服務(wù)器會有兩個通道，一個是 TCP 加 TLS，另外一個就是 https。同時用戶的應(yīng)用服務(wù)器可能會通過RESTful 的 API 做一些管理級別的控制，比如創(chuàng)建聊天室或者創(chuàng)建群組甚至封禁用戶。
環(huán)信的服務(wù)還提供了 webhook，就是將消息回調(diào)給用戶的應(yīng)用服務(wù)器，然后把消息抄送給用戶的服務(wù)器，甚至是發(fā)送前的一個回調(diào)。有一些消息內(nèi)容或者配置的特定消息內(nèi)容，提前經(jīng)過用戶的服務(wù)器進行審查，確認這些消息是否投遞。最后管理者用戶可以在 console 開發(fā)者后臺對這些功能進行不同的配置，也可以做一些管理的功能，比如管理某些群組、解散某些聊天室或者封禁用戶。同時用戶的應(yīng)用也會跟自己的服務(wù)器進行交互，不管是 https 還是其他的協(xié)議。
從完整的視角會看到有哪些通道涉及傳輸，比如用戶的應(yīng)用和他的應(yīng)用服務(wù)器，我們的 SDK 跟我們的服務(wù)，服務(wù)器跟服務(wù)器之間又是一個。此外，我們必須保證這些傳輸通道的傳輸安全， 不管是用 TLS 或者是其他方式。
用戶應(yīng)用上會存儲數(shù)據(jù)，比如用戶名、密碼甚至是token，有的應(yīng)用可能也會做緩存。還有一些 容易忽略的點，比如應(yīng)用開發(fā)的過程當中經(jīng)常會打印一些 log，在這些 log 當中也要避免用戶信息或者敏感信息被泄露，不能使用戶的 token 或者密碼輸在 log 中。同時，用戶應(yīng)用服務(wù)器和我們的服務(wù)可能會存儲一些用戶的消息歷史，這些節(jié)點和通道都是安全合規(guī)角度下必須要確認或者審查的。以開發(fā)者后臺來看，管理權(quán)限級別的賬號的保管、賬號丟失之后的處理都要有相關(guān)的考慮。
3.3 、數(shù)據(jù)處理流程的維度
從用戶數(shù)據(jù)處理流程的維度來看，一個數(shù)據(jù)的處理流程主要涉及數(shù)據(jù)的采集、傳輸、存儲、處理、擦除與銷毀、對第三方提供以及用戶隱私權(quán)利的保障，如圖 5 所示。
采集過程當中首先要進行充分的告知，一般在網(wǎng)站或者應(yīng)用中都會有一個收集到的隱私協(xié)議的說明，包括收集的目的、收集到的個人用戶數(shù)據(jù)的范圍、采集的期限等，其中采集期限是很容易被忽略的。傳輸過程和存儲過程是典型的數(shù)據(jù)處理流程，涉及傳輸加密和存儲加密技術(shù)。數(shù)據(jù)處理過程則要符合收集的目的，遵循準確、必要等原則，不能任意對用戶數(shù)據(jù)進行操作，要有特定的目的才能做數(shù)據(jù)處理。擦除與銷毀過程要求及時和徹底。
對第三方提供過程也是比較關(guān)鍵的，我們經(jīng)常會借用第三方的內(nèi)容審核或類似于 APM 的工具， 對于這些第三方工具需要仔細進行檢查，確保提供相同的保障條件。最后，用戶隱私權(quán)利保障過程除了要明確用戶是自愿選擇之外，還要保證用戶可以注銷或刪除賬號，并對這些操作進行及時的響應(yīng)。
四、安全合規(guī)開發(fā)經(jīng)驗及建議
前面給出了滿足和評估安全合規(guī)的維度，接下來將介紹環(huán)信基于即時通訊領(lǐng)域的經(jīng)驗和建議。
4.1 、安全合規(guī)能力建設(shè)需要做什么
在過去一年時間內(nèi)環(huán)信同外部的咨詢機構(gòu)進行了合作，對我們的流程進行了審查，然后環(huán)信母公司聲網(wǎng)集團的安全合規(guī)團隊也幫助我們梳理了相關(guān)的安全內(nèi)容，這個團隊包括技術(shù)、架構(gòu)、合規(guī)、運營、隱私、開發(fā)等多個方向的專家。
初創(chuàng)企業(yè)前期不需要做這么多的安全合規(guī)的能力建設(shè)，如果是發(fā)展到一定規(guī)?；蛘咧械纫?guī)模的公司，就需要做相關(guān)安全能力的建設(shè)，比如 GDPR 中提到員工超過 250 人，需要對數(shù)據(jù)處理加以記錄等。
為此，環(huán)信進行了安全開發(fā)流程的建設(shè)，公司內(nèi)部的開發(fā)流程中在產(chǎn)品需求階段、設(shè)計階段、驗收階段都要有安全方面的介入，以確認是否涉及用戶數(shù)據(jù)、是否是必要的、是否遵循最小原則等。在這些過程當中還會進行每年度甚至半年度的審查，確認整個流程過程當中有沒有安全問題以及在合規(guī)方面有沒有漏洞等。
4.2 、目前安全合規(guī)的能力
經(jīng)過這些建設(shè)之后，環(huán)信有了足夠的安全基礎(chǔ)，可以進行全流程的傳輸加密和存儲加密;還具備了資源隔離的能力，支持多數(shù)據(jù)中心、支持國內(nèi)國際不同區(qū)域的合規(guī)要求。針對隱私合規(guī)， 根據(jù)最小化和公開透明的處理原則，滿足了不同區(qū)域的網(wǎng)絡(luò)安全和數(shù)據(jù)安全的要求，能夠?qū)Ρ匾挠脩魯?shù)據(jù)進行脫敏處理;用戶權(quán)益的 API 方面支持用戶數(shù)據(jù)的導(dǎo)出和刪除。
4.3 、開發(fā)建議(即時通訊領(lǐng)域)
不管是借助第三方的能力還是自研的能力，如果在即時通訊或者教育領(lǐng)域有了一定的用戶量之后，肯定會遇到一些問題。環(huán)信給出一些建議，首先如果使用第三方，一般會注冊一些信息， 這時最好是由自己的服務(wù)器來下發(fā)，不要內(nèi)置在應(yīng)用中，否則信息容易泄露。
第二個是比較關(guān)鍵的信息，就是保護好用戶列表。比如在已經(jīng)具備一定的用戶量之后，如果此時被拖庫或者網(wǎng)站被攻擊，用戶可能會收到廣告或者一些灰產(chǎn)信息，所以用戶列表就比較關(guān)鍵了，不管用戶是不是通過手機號注冊，用戶 ID 要散列，而且不要對用戶可見。
另外，環(huán)信的服務(wù)端有類似于全員通知的功能，針對全員通知這個功能，我們添加了相應(yīng)的白名單功能，在配置好之后，只有某個特定的服務(wù)器才能給全員發(fā)通知。如果你的業(yè)務(wù)能夠開啟好友之間發(fā)消息的限制，最好就開啟，這樣即使用戶 ID 被泄露，用戶也不能隨意地相互之間發(fā)消息。
服務(wù)器校驗用戶的合法性也是一個非常重要的功能，如果是直接在第三方平臺上注冊的用戶， 那么他有可能會直接繞過你的服務(wù)器來給其他的用戶來收發(fā)消息。這種情況建議還是由你的服務(wù)器來簽發(fā) token，然后保證這個 token 一定的時效性，時間不要太長，這樣即便某個用戶有問題，你的服務(wù)器也可以及時發(fā)現(xiàn)并且封禁這個用戶。
如果有更進一步的安全要求，甚至可以在消息級別進行校驗，比如這個消息有特定的 Key 簽發(fā)密鑰，則消息的收發(fā)雙方都要做相應(yīng)的校驗，甚至端到端的消息加密。
當然現(xiàn)在環(huán)信也支持了內(nèi)容審核的功能，可以在我們的后臺配置相應(yīng)的審核規(guī)則。除了前面的保護措施之外，還要做一些內(nèi)部防范，對類似于開發(fā)者證書或者內(nèi)部的用戶列表等關(guān)鍵數(shù)據(jù)一定要進行相應(yīng)的保護，比如備份這些數(shù)據(jù)庫的信息，不要被開發(fā)者不經(jīng)意間放到 GitHub 或其他技術(shù)博客上。
五、環(huán)信安全合規(guī)、隱私保護及相關(guān)認證
秉持即時通訊服務(wù)的易用、高質(zhì)量、安全、合規(guī)理念，環(huán)信在持續(xù)提升自身的安全能力水位的同時，也依賴開發(fā)者及用戶的密切合作。一般用戶應(yīng)用的集成，如下圖所示：
簡要來說，環(huán)信作為即時通訊云提供商，會對自身PaaS 平臺和 SDK 的安全進行管控;開發(fā)者作為服務(wù)的接入方，需要對自身應(yīng)用，應(yīng)用服務(wù)器和系統(tǒng)環(huán)境的安全進行管控，并根據(jù)自身需求，對環(huán)信SDK 及服務(wù)的安全選項進行合理的配置，以保障自身信息、平臺、程序、系統(tǒng)和網(wǎng)絡(luò)的安全。
5.1. 安全合規(guī)與隱私保護
環(huán)信致力于使平臺產(chǎn)品遵從國內(nèi)外隱私法律法規(guī)要求，包括中國《個人信息保護法(草案)》;歐盟《通用數(shù)據(jù)保護條例》(GDPR))等法律要求。
為此，我們組建了專?的隱私合規(guī)和安全團隊，建立了有效的隱私保護和安全管理體系，以保護開發(fā)者及用戶的個人信息。并對產(chǎn)品進行隱私保護設(shè)計評估和安全評估，以確保產(chǎn)品中嵌入了隱私和安全方面的考慮;我們根據(jù)開發(fā)者及用戶所在的國家區(qū)域范圍和適用的隱私保護法律，在適用情況下向其提供個人數(shù)據(jù)主體權(quán)利;我們遵守隱私保護法律，使用標準合同條款來轉(zhuǎn)移個人信息或?qū)㈤_發(fā)者及用戶的個人信息轉(zhuǎn)移到具有充分數(shù)據(jù)保護的國家。
同時，我們實施了適當?shù)奈锢?、管理和技術(shù)措施以保護開發(fā)者及用戶的個人信息，避免對個人信息未授權(quán)訪問、更改、披露和濫用。我們的即時通訊 SDK 提供了內(nèi)置加密算法;與開發(fā)者及用戶的網(wǎng)絡(luò)通信支持加密傳輸協(xié)議保護;我們服務(wù)端存儲的用戶數(shù)據(jù)同樣支持加密保護。
此外，環(huán)信遵循國際認可的信息安全和隱私保護標準以及行業(yè)要求，致力于采用國際最佳實踐來建設(shè)隱私和安全管理體系，在保障產(chǎn)品安全合規(guī)的同時，也為開發(fā)者及用戶提供合規(guī)支持，幫助開發(fā)者及用戶遵守適用法律法規(guī)和監(jiān)管要求。
5.2 安全標準和認證(GDPR)
目前，環(huán)信已經(jīng)通過了多個國際認可的信息安全和隱私管理體系認證，包括 ISO/IEC 27001、公安部等級 2.0 保護三級、GDPR 等，以此證明自身的隱私合規(guī)、安全管理以及國際化能力。
ISO/IEC 27001: 2013 信息安全管理標準
ISO/IEC 27001: 2013 是最基礎(chǔ)的、獲得國際最廣泛認可的信息安全管理體系標準。
公安部信息安全等級保護三級認證
《GB/T 22239-2019 信息安全技術(shù) 網(wǎng)絡(luò)安全等級保護基本要求》簡稱安全等級保護，是中國國家標準化管理委員會發(fā)布的信息安全標準，是中華人民共和國信息安全保障的一項基本制度。等級根據(jù)信息系統(tǒng)的重要程度，從低到高分為 1 至 5 個等級，不同安全等級實施不同的保護
策略和要求。環(huán)信采用的是 3 級信息系統(tǒng)的保護策略，并順利通過了國家網(wǎng)絡(luò)與信息系統(tǒng)安全產(chǎn)品質(zhì)量監(jiān)督檢驗中心(公安部第三研究所)的測評。
歐盟《通用數(shù)據(jù)保護條例》(GDPR)
歐盟議會于 2016 年 4 月 14 日通過的《通用數(shù)據(jù)保護條例(General Data Protection Regulations)》(“GDPR”)于 2018 年 5 月 25 日在歐盟成員國內(nèi)正式生效實施。GDPR 堪稱史上最嚴格的數(shù)據(jù)保護法案，它的實施代表著歐盟對個人信息保護及其監(jiān)管達到了前所未有的高度。該條例的適用范圍極為廣泛，任何收集、傳輸、保留或處理涉及到歐盟所有成員國內(nèi)的個人信息的機構(gòu)組織均受該條例的約束。
作為行業(yè)首家遵從GDPR 安全法規(guī)要求的企業(yè)，在GDPR(General Data Protection Regulation)方面，環(huán)信做到了極致的隱私數(shù)據(jù)保護，用戶拒絕營銷和被遺忘權(quán)，嚴格的角色權(quán)限區(qū)分和訪問控制管理，日志審計和脫敏，SDK、Server 端代碼全量掃描，嚴苛的運維操作流程管理等。
六、環(huán)信即時通訊 PaaS 服務(wù)的安全
從邏輯劃分，環(huán)信即時通訊 PaaS 服務(wù)，主要包含數(shù)據(jù)中心服務(wù)以及提供給開發(fā)者的 IM SDK。在該章節(jié)，我們將系統(tǒng)性地介紹各層中的技術(shù)及運營環(huán)節(jié)的安全風險控制措施。
6.1 數(shù)據(jù)中心計算資源安全
環(huán)信即時通訊服務(wù)由國內(nèi)外多個數(shù)據(jù)中心(IDC)以及頭部公有云供應(yīng)商的云服務(wù)組成，以構(gòu)建一個統(tǒng)一、高可用、高擴展、高效率、高安全的基礎(chǔ)資源環(huán)境。
6.1.1 網(wǎng)絡(luò)隔離
對網(wǎng)絡(luò)進行合理的劃分，定義清晰用途，制定適配的訪問控制策略，是網(wǎng)絡(luò)安全的前提之一。環(huán)信基于 IM PaaS 承載功能和安全級別的不同，將網(wǎng)絡(luò)劃分出了核心、邊緣、IT 等幾大安全區(qū)域。在不同的安全域之間，根據(jù)不同的業(yè)務(wù)訪問需求和安全級別，環(huán)信制定了不同的路由策略以及嚴格的安全訪問策略。
6.1.2 防 DDoS 攻擊
分布式拒絕服務(wù)攻擊(Distributed Denial of Service，DDoS)會對 IM 服務(wù)的系統(tǒng)和業(yè)務(wù)可用性產(chǎn)生重大影響，嚴重時可導(dǎo)致服務(wù)中斷或質(zhì)量下降。為此，環(huán)信基于自身服務(wù)的特性，結(jié)合公有云能力，在核心服務(wù)上部署了 DDoS 防御方案。該方案能夠?qū)崟r檢測并防御來自網(wǎng)絡(luò)層、傳輸?shù)?DDoS 攻擊。防 DDoS 攻擊方案，能夠自動檢測、自動調(diào)度并觸發(fā)清洗功能，數(shù)秒內(nèi)就可以完成攻擊、流量清洗動作，保證核心服務(wù)的可用性。
此外所有 DDoS 攻擊事件，都會通過郵件、短信、電話等方式，第一時間知會安全團隊，以便安全團隊持續(xù)關(guān)注和響應(yīng)決策。
6.1.3 主機、數(shù)據(jù)庫、中間件等計算資源安全
各類服務(wù)運行所依賴的資源，由操作系統(tǒng)或容器化為關(guān)聯(lián)的后臺程序、緩存、數(shù)據(jù)庫等中間件， 合理地調(diào)度分配 CPU、內(nèi)存、磁盤等資源來滿足。環(huán)信結(jié)合自身基礎(chǔ)服務(wù)場景，在實際安全運營中，通過制定適配的安全基線、漏洞管理規(guī)范，并落地縱深威脅檢測機制，確保基礎(chǔ)運算負載資源的安全性。
6.1.3.1 安全基線
環(huán)信制定了 IDC 和公有云的安全基線，涵蓋主機操作系統(tǒng)、容器、數(shù)據(jù)庫、存儲、Web 服務(wù)等中間件，內(nèi)容包括賬戶安全、身份認證、最小服務(wù)、最小授權(quán)、日志審計、時鐘同步等。并根據(jù)不同的用途，對操作系統(tǒng)或中間件進行不同程度的安全配置加固，確保新交付的運算負載資源滿足相關(guān)安全基線要求。對于運行中的負載資源，安全團隊會進行定期的配置巡檢，對比與安全基線的差異，輸出不符合項，通知到關(guān)聯(lián)的運維和業(yè)務(wù)技術(shù)團隊，并落實整改。
6.1.3.2 漏洞管理
所有交付上線的運算負載資源，均來自統(tǒng)一管理的操作系統(tǒng)鏡像或中間件軟件包。對于交付使用中的資源，安全團隊會采集操作系統(tǒng)和中間件版本信息，然后發(fā)送到安全運營系統(tǒng)中分析， 從而識別是否存在受漏洞影響的版本。對于公有云上的主機資源，環(huán)信會部署公有云的安全客戶端，實現(xiàn)對操作系統(tǒng)和中間件等軟件產(chǎn)品的實時漏洞檢測。另外，安全團隊通過部署業(yè)界知名商業(yè)漏洞掃描產(chǎn)品，定期對運算負載資源發(fā)起掃描巡檢，輸出漏洞掃描報告，并將信息采集到安全運營系統(tǒng)。
一旦發(fā)現(xiàn)存在漏洞版本匹配的組件，安全團隊會對漏洞的風險做綜合評估，提供應(yīng)急處置措施和修復(fù)建議，并聯(lián)合運維及相關(guān)業(yè)務(wù)技術(shù)團隊落實漏洞修復(fù)、配置加固、鏡像更新，從而實現(xiàn)漏洞管理的閉環(huán)。
6.1.3.3 計算資源中的安全運維
運維賬號安全
在日常運維中，環(huán)信制定并啟用了 IAM(Identity and Access Management，身份和訪問控制管理)機制，所有涉及運維內(nèi)容的人員必須具有有效的身份和授權(quán)才可進行操作，運維賬號與員工身份一一對應(yīng)，其默認啟用 MFA(Multi-factor authentication, 多重要素驗證)。
操作系統(tǒng)賬號安全
對于系統(tǒng)賬號，環(huán)信制定了一系列安全制度和操作規(guī)范，例如，避免使用弱口令作為密碼，并要求定期更換，信息安全團隊也會通過定期的安全檢查。
運維操作審計
環(huán)信在日常運維過程中，會實時記錄歸檔各類操作，制定實時監(jiān)控告警策略，并對風險操作及時處置。
6.2 SDK 安全
環(huán)信提供 iOS、Android、Flutter、React Native、Windows、小程序、Web 等平臺的 SDK 支持，以滿足開發(fā)者及用戶的各類實時音視頻互動接入需求。IM SDK 不僅僅為開發(fā)者及用戶提供簡單、易用、統(tǒng)一、可信、安全的即時通訊開發(fā)套件，也竭盡全力為開發(fā)者及用戶提供合規(guī)、安全的配置選項，以提升開發(fā)者及用戶在實時音視頻互動場景和應(yīng)用中合規(guī)監(jiān)管和應(yīng)對信源數(shù)據(jù)安全威脅的能力。
根據(jù)國家法律法規(guī)規(guī)定及監(jiān)管機構(gòu)執(zhí)法要求，APP 在使用第三方SDK 時，必須在APP《隱私政策》中告知用戶，并在調(diào)用時序上做好延遲初始化配置，確保用戶同意 APP《隱私政策》后 SDK 才可以被啟動，進行數(shù)據(jù)采集和服務(wù)。為了幫助開發(fā)者避免合規(guī)風險，環(huán)信推出隱私政策合規(guī)要求，包括隱私政策展示內(nèi)容和展示形式合規(guī)。
6.2.1 SDK 的合規(guī)與安全保證
環(huán)信在為開發(fā)者提供 SDK 時，SDK 的可信和安全是首要保證的內(nèi)容之一。在評審 SDK 新增或迭代的功能時，會充分評估功能需求在合規(guī)隱私以及安全上的風險點，確保與環(huán)信合規(guī)和隱私政策的一致性。功能實現(xiàn)時，會在進行充分的質(zhì)量保證(QA)測試時對代碼進行安全審計， 在涉及引用或集成第三方 SDK、庫文件時進行安全檢測，尤其是合規(guī)性確認，例如，是否存在惡意代碼或后門，是否遵守版權(quán)或使用協(xié)議。如果檢測出存在風險，SDK 只有在修復(fù)并確認無風險后，才允許進入下一階段。在分發(fā)環(huán)節(jié)，會在官方渠道更新。
6.2.2 對開發(fā)者及用戶的安全與合規(guī)支持
在 SDK 上，環(huán)信提供了設(shè)備端存儲內(nèi)容加密，日志安全等安全配置選項，以協(xié)助開發(fā)者及用戶完善即時通訊數(shù)據(jù)安全及隱私合規(guī)。有需要的開發(fā)者及用戶，可以參考開發(fā)者文檔進行配置啟用。
6.2.2.1 本地存儲內(nèi)容
環(huán)信 SDK 使用行業(yè)標準的加密技術(shù)對在設(shè)備本地的消息等內(nèi)容記錄進行加密存儲。
6.2.2.2 日志脫敏
環(huán)信SDK 提供不同的日志級別，方便開發(fā)者在開發(fā)調(diào)試和發(fā)布時使用，同時對設(shè)備上的日志進行脫敏，防止用戶數(shù)據(jù)被識別和竊取。
6.3 RESTful API 安全
為方便開發(fā)者高效地管理自己的應(yīng)用和服務(wù)，諸多業(yè)務(wù)功能和管理功能以 RESTful API 的方式供開發(fā)者調(diào)用。在安全保障上，除了將站點接入 WAF 外，還有如下的安全控制措施。
身份鑒權(quán)
開發(fā)者在使用 RESTful API 前，需先登錄控制臺，創(chuàng)建開發(fā)者專屬的 key&secret。后續(xù) API 調(diào)用，需使用對應(yīng)的 key&secret 對，以區(qū)分不同項目或應(yīng)用。
傳輸安全
RESTful API 支持 HTTPS 協(xié)議，以確保使用 SSL / TLS 對所有 API 通信進行加密，可以保護 API憑據(jù)和傳輸?shù)臄?shù)據(jù)，以及防止一些如中間人攻擊(MITM, man in the middle)等。
API 限速
服務(wù)端對 API 請求的速率有限制，在保證正常用戶請求可以得到響應(yīng)的同時，限制惡意用戶的 API 請求。
輸入驗證
開發(fā)者請求的參數(shù)會經(jīng)過服務(wù)器后臺過濾，以避免一些常見的易受攻擊缺陷(SQL-注入，遠程代碼執(zhí)行等)。
七、環(huán)信數(shù)據(jù)安全
數(shù)據(jù)作為信息活動的載體，經(jīng)過合法合規(guī)且安全的處理尤為重要。數(shù)據(jù)安全是環(huán)信最為關(guān)切的問題之一，本節(jié)將介紹環(huán)信在數(shù)據(jù)安全上采取的政策及落實的管理和技術(shù)控制措施。
7.1 數(shù)據(jù)安全政策
針對日益嚴峻的網(wǎng)絡(luò)安全態(tài)勢，以及逐漸趨緊的監(jiān)管要求，環(huán)信堅持以數(shù)據(jù)保密、完整和高可用作為業(yè)務(wù)服務(wù)的數(shù)據(jù)安全發(fā)展戰(zhàn)略，并將數(shù)據(jù)安全理念融入安全體系建設(shè)過程中，即
保密性：防止未經(jīng)授權(quán)的訪問和竊聽
完整性：防止惡意篡改和偽造數(shù)據(jù)
可用性：通過不同數(shù)據(jù)中心和邊緣節(jié)點保障數(shù)據(jù)高可用
因此環(huán)信對所有員工均開展信息保護、隱私合規(guī)及保密意識安全培訓(xùn)，并簽訂保密協(xié)議;對違反數(shù)據(jù)安全制度和保密要求的人員，我們會視情形嚴重程度以采取相應(yīng)的違規(guī)處理措施，包括但不限于談話、加強培訓(xùn)考核、解除勞動協(xié)議及追究其他法律責任等措施。
7.2 數(shù)據(jù)采集
采用最小化的數(shù)據(jù)采集原則，只采集經(jīng)用戶授權(quán)同意的，且業(yè)務(wù)所必須的數(shù)據(jù)字段。
7.3 數(shù)據(jù)脫敏
為保護數(shù)據(jù)隱私，環(huán)信針對官網(wǎng)控制臺的企業(yè)和個人信息均進行脫敏后的展示，此策略同樣也適用于不同的服務(wù)和SDK。
7.4 數(shù)據(jù)保護和加密傳輸
在 IM PaaS 服務(wù)中，對于不同的傳輸通道例如SDK 與服務(wù)器，服務(wù)器與用戶的應(yīng)用服務(wù)器之間等，都支持安全傳輸協(xié)議(HTTPS/TLS/WSS 等)
7.5 數(shù)據(jù)使用和存儲
對于開發(fā)者及用戶的機密信息，如密碼，我們會以哈希加鹽值(salt)的方式進行存儲。對已存 儲的信息，將根據(jù)相關(guān)監(jiān)管要求和制定的數(shù)據(jù)備份和存儲策略，嚴格制定數(shù)據(jù)保存期限，并按要求在需要時對其進行銷毀;對來自開發(fā)者及用戶的數(shù)據(jù)處理申請，我們將根據(jù)開發(fā)者及用戶的授權(quán)及相應(yīng)監(jiān)管要求配合實施數(shù)據(jù)清理或轉(zhuǎn)移。
7.6 用戶的數(shù)據(jù)權(quán)利
提供了不同維度的用戶權(quán)益的 API 方面支持用戶數(shù)據(jù)的導(dǎo)出和刪除。
八、環(huán)信安全運營
安全是一個持續(xù)的過程，在實際安全運營中，環(huán)信基于自身業(yè)務(wù)特性，通過如下維度來開展。
8.1 安全開發(fā)生命周期管理 SDL
在軟件開發(fā)生命周期中，嵌入了安全和隱私的相關(guān)要求，結(jié)合當前流行的 DevSecOps，讓 SDL 流程更自動化，從而在原有的安全開發(fā)生命周期的基礎(chǔ)上，更高效的進行安全和隱私的檢查。
8.1.1 威脅建模
在設(shè)計和架構(gòu)階段，為了能夠更早的發(fā)現(xiàn)風險，通過威脅建模來識別潛在的安全問題并實施響應(yīng)環(huán)節(jié)措施。為了有效發(fā)現(xiàn)并解決設(shè)計階段的潛在風險，參考 STRIDE 的威脅建模方法，主要聚焦攻擊面最小化，基本隱私，權(quán)限最小化，默認安全，數(shù)據(jù)加密等。
8.1.2 CI/CD 黑白盒檢測
在安全測試層面更注重 DevSecOps 崇尚的內(nèi)置安全防護，且已在 CI/CD 層面進行了黑白盒工具的集成，包含開源代碼掃描工具 SonarQube，組件及合規(guī)掃描商業(yè)工具 BlackDuck，App/Sdk 掃描工具 MobSF 等，從而完善在集成發(fā)布過程中的風險監(jiān)測。
8.2 反入侵和安全監(jiān)控
環(huán)信的各類運算系統(tǒng)、業(yè)務(wù)應(yīng)用服務(wù)每天都會產(chǎn)生海量的日志數(shù)據(jù)。在落實縱深防御以應(yīng)對威脅的基礎(chǔ)之上，安全團隊也會在最小權(quán)限范圍內(nèi)采集用于安全分析的日志?；谶@些日志，通過安全監(jiān)控分析平臺實時運算。對識別的安全異常事件，會及時告警，安全運營人員會進一步展開關(guān)聯(lián)以及溯源分析復(fù)核;對確認的風險，會根據(jù)應(yīng)急響應(yīng)機制進行處置和追蹤，以保障業(yè)務(wù)系統(tǒng)的安全性和可用性。
8.3 安全應(yīng)急響應(yīng)機制
基于自身即時通訊業(yè)務(wù)特性，對服務(wù)類型進行分類分級，系統(tǒng)性地安全評估和威脅識別，制定不同的安全事件分類標準，以及響應(yīng)時效和處置流程，以確保及時有效地處理安全異常。
8.4 安全合作
在自身內(nèi)部安全建設(shè)的基礎(chǔ)上，環(huán)信已與 Trustwave 等多家第三方安全廠商合作，定期進行滲透測試，代碼審查，逆向工程等來幫助環(huán)信發(fā)現(xiàn)線上應(yīng)用、系統(tǒng)、服務(wù)以及 SDK 等層面的安全漏洞和各類潛在風險，從而提升整體服務(wù)安全性和系統(tǒng)健壯性。
九、APP 開發(fā)者接入環(huán)信 SDK 的合規(guī)要求
根據(jù)國家法律法規(guī)規(guī)定及監(jiān)管機構(gòu)執(zhí)法要求，APP 在使用第三方SDK 時，必須在APP《隱私政策》中告知用戶，并在調(diào)用時序上做好延遲初始化配置，確保用戶同意 APP《隱私政策》后 SDK 才可以被啟動，進行數(shù)據(jù)采集和服務(wù)。為了幫助環(huán)信開發(fā)者避免合規(guī)風險，環(huán)信推出了隱私政策合規(guī)要求，包括隱私政策展示內(nèi)容和展示形式合規(guī)。
9.1.隱私政策內(nèi)容合規(guī)
注意：本信息收集范圍說明適用于SDK3.8.4 版本及以上
當APP 開發(fā)者接入環(huán)信 SDK 服務(wù)時，請務(wù)必按照我國法律法規(guī)、規(guī)范性文件之要求，在APP 自身的隱私政策或個人信息保護政策等相關(guān)公示文件中“第三方服務(wù)”/“第三方合作伙伴”部分明確列出本APP 所集成的環(huán)信 SDK 收集、使用個人信息的目的、方式和范圍，環(huán)信提供如下兩種參考表達話術(shù)，以方便APP 開發(fā)者更高效、更合規(guī)地調(diào)整自身的隱私政策，共同保護個人信息。
參考表達一、以文字方式向用戶呈現(xiàn)
如：我們使用了第三方(北京億思摩博網(wǎng)絡(luò)科技有限公司，以下稱“環(huán)信”) 環(huán)信 SDK 服務(wù)為您提供【 】功能。為了順利實現(xiàn)該功能，您需要授權(quán)環(huán)信 SDK 提供對應(yīng)的服務(wù);在您授權(quán)后， 環(huán)信將收集您相關(guān)的個人信息。
參考表達二、以表格方式向用戶呈現(xiàn)
如：【您的 APP 名稱】(iOS 版/Android 版)內(nèi)嵌第三方SDK 詳情
9.2 隱私政策展示形式合規(guī)
需要增加明確彈窗，有明顯同意和拒絕按鈕，讓用戶自主選擇是否接受隱私政策。App 隱私政策包含的環(huán)信隱私權(quán)政策鏈接可允許用戶點擊查看。
十、結(jié)語
為開發(fā)者提供合規(guī)、安全、可信的即時通訊云平臺，是環(huán)信所有架構(gòu)和產(chǎn)品服務(wù)首要考慮的要素之一。環(huán)信從人員、技術(shù)、管理、流程等多個方面系統(tǒng)性推進信息安全政策的落地，履行監(jiān)管合規(guī)義務(wù)，與行業(yè)客戶以及第三方社區(qū)或團體個人緊密合作，同時積極探索新的技術(shù)，推進安全自動化、智能化，實現(xiàn)安全防護能力高效輸出。
在日趨復(fù)雜的互聯(lián)網(wǎng)環(huán)境下，技術(shù)迭代周期越來越短，新型攻擊手段層出不窮，我們無時不刻都在面臨各類安全威脅。篳路藍縷啟山林、櫛風沐雨砥礪行，在此背景下，希望本白皮書能夠為企業(yè)或機構(gòu)的安全建設(shè)提供參考和借鑒，也歡迎業(yè)界同仁共同參與完善，助力行業(yè)高質(zhì)量穩(wěn)健發(fā)展!
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
