即時通訊場景下安全合規的實踐和經驗

前言

在監管趨緊的形式下，即時通訊場景會遇到很多安全合規領域的挑戰，如何滿足這些安全合規的要求，如何保護使用者的隱私安全，是一件非常有挑戰的事情。

為給大家提供相關的經驗及參考，「 聲網開發者創業講堂 • 第四期丨創業團隊如何保障產品業務的安全合規？ 」活動特別邀請環信 IM SDK 研發負責人趙亮，以「即時通訊場景下安全合規的實踐和經驗」為題進行分享。

趙亮具有十餘年電信和網際網路從業經驗，曾主持研發多個明星專案，目前在環信主持即時通訊雲 SDK 研發工作。本文基於其在分享中內容二次整理。

01 安全合規的趨勢

1、隱私監管趨緊

最近四五年來，安全合規的趨勢變得越來越嚴格，各個國家都有比較重磅的安全合規的相關法規出臺，比如美國加州的《消費者隱私法案》《兒童線上隱私保護法》、保險醫療領域的 HIPPA，以及歐盟推出的比較有代表性的《通用資料保護條例》。國內去年也出臺了《個人資訊保護法》《資料安全法》，加上之前釋出的《網路安全法》，對於安全合規領域的覆蓋也比較完善。

2、APP/SDK 趨嚴

■圖 1

圖 1 所示為國內主要的有關法規和內容，大家如果留意行業新聞的話，也會看到很多這方面的趨勢，比如工信部發布的各種應用下架的新聞或者公告，都涉及了個人資料隱私相關的內容。

3、安全合規的基本框架

安全合規的基本框架可以總結成兩個方向，一個是使用者知情同意，另一個就是安全保障義務。我們以《通用資料保護條例》（ GDPR ）為例，它是一個法規條文，內容包括各種監管措施、懲罰措施，還規定了應保障的使用者權利，後面的介紹中會有一些具體的使用者權利說明。

02 國內外的監管重點

接下來我們分別看一下國內外監管的重點，從國內這幾年的角度來看，主要包括以下幾個方面。

1、國內 App 上架 —— 資訊採集

■圖 2

如圖 2 所示，我們看到使用者資訊的採集方面受到越來越多的重視，國家部委出臺了《常見型別移動網際網路應用程式必要個人資訊的範圍規定》，指出了二三十個場景下能夠採集的必要的個人資訊。

比如地圖導航類，它的基本功服是定位和導航，必要的個人資訊為位置資訊、出發地和到達地。就是特別簡單的幾項，其他都是非必要的，所以大家在開發應用的時候一定要確認一下這個資訊，否則 App 就無法上架了。

再如網路社群類的，它的基本功能是部落格、論壇等，這些個人資訊跟即時通訊類的必要資訊比較接近，就是使用者的行動電話號碼和賬號聯絡人資訊。網約車型別中也規定了電話號碼，包括出發地、到達地、支付時間、支付資訊等。大家可能已經留意到了，即時通訊類為什麼需要行動電話號碼呢？按說不是隻需要賬號就可以了嗎？接下來我們要介紹的內容就解釋了這個問題。

2、國內 App 上架 —— 符合安全規定

除了可以採集的必要資訊的約束之外，我國還有很多特定的相關不同行業或領域的約束。

在應用的上架流程中，應用商店都有詳細的審查規定，如果涉及即時通訊、直播或者使用者輿論領域，就需要一個安全評估報告，這個安全評估報告中增加了額外的要求，比如說使用者真實身份的核驗，就是要核驗服務中使用者的身份是真實可靠的，這裡就回答了前面即時通訊領域的問題，想真正地服務客戶，就要能夠做到實名制，而實名制其實一般就是通過校驗手機和簡訊的方式。

另外，其實這還涉及使用者輿論的問題，需要針對這個問題建立投訴舉報的機制，公佈投訴舉報的聯絡方式和處理情況，對於這些使用者的暱稱、資訊釋出、轉發評論等，要有相關的記錄儲存措施，通過一定的儲存機制來支援追查這些資訊。這樣一方面約束了必要的個人資訊的採集；另一方面在不同的領域也補充了額外的要求，比如金融或者醫療領域的要求肯定是更高的。

根據一則新聞通報所示，近期違規下架應用累計為 3000 款左右，涉及的問題大部分是違規收集個人資訊，少量是強制或者索取許可權相關的問題，國內的應用、網站可能涉及的問題主要就是這些方面。

3、海外的關注 —— ⽤戶權利

如果目標客戶是在海外，那麼會發現海外的側重點稍有不同。除了常見的這些安全約束之外，其更關注使用者的權利。

我們可以舉幾個例子，比如使用者的知情權、資訊獲取權、修改權和被遺忘權。知情權就是明確地告知使用者要收集哪些資訊、資訊用來做什麼以及儲存多久；資訊獲取權就是使用者必須能夠匯出自己的資料；修改權就是使用者可以對個人資訊進行修改；被遺忘權就是使用者有權利登出和刪除自己的資料。Facebook 等海外的大型平臺都支援登出賬號、匯出個人資料等功能，這是海外比較重視的。

■圖 3

圖 3 的案例比較有意思，是說英國的資料保護監管機構向加拿大的一家資料分析公司發出通知，要求其刪除所有跟英國公民相關的個人資料，如果不履行義務，將面臨著 2000 萬歐元或者上一年全球總營業額 4% 的罰款。這裡的 2000 萬歐元和 4% 的罰款就是《通用資料保護條例》中所做的規定，這個措施是很嚴格的。

4、共同關注點 —— 資料跨境

國內和國外還有一個共同的關注點，就是熱點資料跨境，簡單來說就是個人資訊和重要的資料應當在境內，這裡的在境內應該就是說，比如中國公民的資訊和重要的資料不能被隨意地儲存到境外的伺服器上，歐盟地區的資料也不能被隨意地存在歐盟以外。其他的地區比如東南亞或者印度，也有當地的法規來約束這些事情，當然這些話題我們就不展開了，這裡只是舉個例子。

如果確實需要向境外提供，我國的要求是要通過評估辦法進行慎重的評估。歐盟則是要求他們認為已經採取足夠的安全保護措施的地區可以跨境轉移資料，但至少現在為止中國還不在這個名單上，所以歐盟的資料也不能隨意儲存在中國境內的伺服器上。

03 如何評估和滿⾜安全合規要求

瞭解了安全合規的趨勢和相應的重點之後，我們如何評估和滿足安全合規的要求呢？首先回溯前面介紹的安全合規的框架。

使用者知情同意包括充分告知和權利保障。充分告知就是提供使用者隱私協議，權利保障就是使用者可以拒絕、可以刪除，而且收集的資料要符合最小化原則（最小必要）。

安全保障義務比較複雜，首先，從風險評估、公司內部的制度建設到安全開發流程中都會涉及這個問題，比如產品從需求階段就要有安全方面的專家確認是否涉及使用者資料、使用者資料怎麼傳輸、使用者資料怎麼來儲存、是否是必要的，因此從產品需求階段到方案設計階段，到最後上線階段都要有必要的安全評估。

其次是技術保障，這裡的技術保障指的是採集過程當中的傳輸、儲存都應當採取足夠的技術保障，換算成技術角度就是說，傳輸過程中要進行傳輸的加密，儲存過程中要進行儲存的加密。法律法規不會規定具體的某個安全措施，只是要求採取必要的技術措施保障使用者資料的安全。

所以從技術角度側理解，要採取業內比較標準的或者比較高標準的安全措施，比如 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 的工具，對於這些第三方工具需要仔細進行檢查，確保提供相同的保障條件。最後，使用者隱私權利保障過程除了要明確使用者是自願選擇之外，還要保證使用者可以登出或刪除賬號，並對這些操作進行及時的響應。

04 經驗和建議

前面給出了滿足和評估安全合規的維度，接下來分享一下我們的經驗和建議。當然，這些經驗和建議是基於即時通訊領域的。

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、初創公司應該如何做產品或者技術合規的審查？

這個問題我在介紹的過程當中其實也提到了，對於不同的行業和領域，要求都不太一樣。一般來說，比如在華為或者蘋果的應用商店上架應用，都會選擇不同的應用分類，選擇特定的分類之後，就會有一些特定的要求，有的會要求你的資質，有的會要求安全評估報告。

也就是說，要根據應用的所屬行業或者你的業務屬性來確定，只要滿足這些要求一般不會有太大的問題。而且你對於自己的應用所屬的領域行業都有基本的瞭解，可以在上架之前把這些要求大致瞭解清楚，提前做好準備，否則被打回再重新修改上架，也會影響產品的上線計劃。