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