精品国产亚洲一区二区三区|亚洲国产精彩中文乱码AV|久久久久亚洲AV综合波多野结衣|漂亮少妇各种调教玩弄在线

<blockquote id="ixlwe"><option id="ixlwe"></option></blockquote>
  • <span id="ixlwe"></span>

  • <abbr id="ixlwe"></abbr>

    環(huán)信:即時通訊場景下安全合規(guī)的實踐和經(jīng)驗

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

    為給大家提供相關(guān)的經(jīng)驗及參考,聲網(wǎng)聯(lián)合環(huán)信推出了“聲網(wǎng)開發(fā)者創(chuàng)業(yè)講堂 • 第四期丨創(chuàng)業(yè)團隊如何保障產(chǎn)品業(yè)務的安全合規(guī)?”活動,本期特別邀請環(huán)信 IM SDK 研發(fā)負責人趙亮,以“即時通訊場景下安全合規(guī)的實踐和經(jīng)驗”為題進行分享。

    趙亮具有十余年電信和互聯(lián)網(wǎng)從業(yè)經(jīng)驗,曾主持研發(fā)多個明星項目,目前在環(huán)信主持即時通訊云 SDK 研發(fā)工作。本文基于其在分享中內(nèi)容二次整理。

    安全合規(guī)的趨勢

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

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

    2、APP/SDK 趨嚴

    圖 1

    圖 1 所示為國內(nèi)主要的有關(guān)法規(guī)和內(nèi)容,大家如果留意行業(yè)新聞的話,也會看到很多這方面的趨勢,比如工信部發(fā)布的各種應用下架的新聞或者公告,都涉及了個人數(shù)據(jù)隱私相關(guān)的內(nèi)容。

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

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

    國內(nèi)外的監(jiān)管重點

    接下來我們分別看一下國內(nèi)外監(jiān)管的重點,從國內(nèi)這幾年的角度來看,主要包括以下幾個方面。

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

    圖 2

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

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

    再如網(wǎng)絡社區(qū)類的,它的基本功能是博客、論壇等,這些個人信息跟即時通訊類的必要信息比較接近,就是用戶的移動電話號碼和賬號聯(lián)系人信息。網(wǎng)約車類型中也規(guī)定了電話號碼,包括出發(fā)地、到達地、支付時間、支付信息等。大家可能已經(jīng)留意到了,即時通訊類為什么需要移動電話號碼呢?按說不是只需要賬號就可以了嗎?接下來我們要介紹的內(nèi)容就解釋了這個問題。

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

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

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

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

    根據(jù)一則新聞通報所示,近期違規(guī)下架應用累計為 3000 款左右,涉及的問題大部分是違規(guī)收集個人信息,少量是強制或者索取權(quán)限相關(guān)的問題,國內(nèi)的應用、網(wǎng)站可能涉及的問題主要就是這些方面。

    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 等海外的大型平臺都支持注銷賬號、導出個人數(shù)據(jù)等功能,這是海外比較重視的。

    圖 3

    圖 3 的案例比較有意思,是說英國的數(shù)據(jù)保護監(jiān)管機構(gòu)向加拿大的一家數(shù)據(jù)分析公司發(fā)出通知,要求其刪除所有跟英國公民相關(guān)的個人數(shù)據(jù),如果不履行義務,將面臨著 2000 萬歐元或者上一年全球總營業(yè)額 4% 的罰款。這里的 2000 萬歐元和 4% 的罰款就是《通用數(shù)據(jù)保護條例》中所做的規(guī)定,這個措施是很嚴格的。

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

    國內(nèi)和國外還有一個共同的關(guān)注點,就是熱點數(shù)據(jù)跨境,簡單來說就是個人信息和重要的數(shù)據(jù)應當在境內(nèi),這里的在境內(nèi)應該就是說,比如中國公民的信息和重要的數(shù)據(jù)不能被隨意地存儲到境外的服務器上,歐盟地區(qū)的數(shù)據(jù)也不能被隨意地存在歐盟以外。其他的地區(qū)比如東南亞或者印度,也有當?shù)氐姆ㄒ?guī)來約束這些事情,當然這些話題我們就不展開了,這里只是舉個例子。

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

    如何評估和滿足安全合規(guī)要求經(jīng)驗和建議

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

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

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

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

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

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

    1、如何評估安全合規(guī)的要求

    那么,如何評估安全合規(guī)的要求呢。這要看我們具體的涉及的業(yè)務,不同領(lǐng)域的要求是不一樣的,我們前面提到,金融、醫(yī)療領(lǐng)域的要求更加嚴格。在某些醫(yī)療領(lǐng)域,對于醫(yī)療用戶(患者)的數(shù)據(jù)或者處理要記錄至少 5 年以上,這是該領(lǐng)域的一個特殊要求。另外,針對不同區(qū)域用戶的要求也不一樣,比如剛才提到的東南亞,至少我知道新加坡有自己的特殊規(guī)定,其他區(qū)域也可能有自己的要求。

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

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

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

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

    圖 4

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

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

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

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

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

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

    圖 5

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

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

    經(jīng)驗和建議

    前面給出了滿足和評估安全合規(guī)的維度,接下來分享一下我們的經(jīng)驗和建議。當然,這些經(jīng)驗和建議是基于即時通訊領(lǐng)域的。

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

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

    當然,初創(chuàng)企業(yè)可能還不需要做這么多的安全合規(guī)的能力建設(shè),如果是發(fā)展到一定規(guī)模或者中等規(guī)模的公司,可能就要做一些安全能力的建設(shè),比如 GDPR 中提到員工超過 250 人,需要對數(shù)據(jù)處理加以記錄。

    我們進行了安全開發(fā)流程的建設(shè),對于安全開發(fā)流程前面也簡單提過,公司內(nèi)部的開發(fā)流程中在產(chǎn)品需求階段、設(shè)計階段、驗收階段都要有安全方面的介入,以確認是否涉及用戶數(shù)據(jù)、是否是必要的、是否遵循最小原則等。在這些過程當中還會進行每年度甚至半年度的審查,確認整個流程過程當中有沒有安全問題以及在合規(guī)方面有沒有漏洞,這是我們過去兩年做所做的安全合規(guī)能力建設(shè)。

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

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

    3、開發(fā)建議 —— 即時通訊領(lǐng)域

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

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

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

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

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

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

    問答環(huán)節(jié)

    1、很多開發(fā)者會有這樣一種想法,比如說我接入了某個第三方安全審核功能后,是不是就可以高枕無憂了?

    這個顯然不是,就是現(xiàn)在的鑒黃,也沒有 100% 的能力完全做到這一點。我們肯定還是要做一些措施,比如能做到監(jiān)督,這樣事后有記錄就能對他進行管理甚至封禁,而不只是說扔給第三方。

    2、您在演講中提到加密會使服務器的成本開銷較大,那么有哪些加密方式是您建議一定要啟用的,MD 5 和 AES 256 方式您建議使用哪一種呢?

    如果是對稱加密的話,建議是 AES 256 以上。成本方面沒有明確的答案,這與數(shù)據(jù)塊有關(guān)系,如果我們的消息都是比較小的,那么數(shù)據(jù)增加可能會比較明顯。而對于大一些的消息,比如文件級別的甚至更大,數(shù)據(jù)增加可能少一些。所以這沒有一個很明確的規(guī)律,但是肯定會對你的成本有所增加。

    3、如果個人要求刪除個人數(shù)據(jù),主要是與 App 運營廠商處理,還是像這種提供 PaaS 服務的平臺來進行聯(lián)動處理呢?

    我們的 PaaS平臺一般是要提供能力,但我們還有觀察到一些 PaaS 的主要提供商都不是直接給用戶的,而是給應用的開發(fā)者。我們有用戶級別的 token 和管理員級別的 token,我們現(xiàn)在的用戶隱私相關(guān) API 設(shè)計都是管理員級別的,就是說用戶要求注銷賬號或者刪除數(shù)據(jù)的時候,一般是經(jīng)過應用的 owner 和應用的服務器使用這些第三方平臺來完成的,否則可能數(shù)據(jù)刪除的處理不完整。第三方平臺一般是提供這部分能力。

    4、初創(chuàng)公司應該如何做產(chǎn)品或者技術(shù)合規(guī)的審查?

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

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

    (免責聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性,但不保證有關(guān)資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏,概不負任何法律責任。
    任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時,應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明,并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后,將會依法盡快聯(lián)系相關(guān)文章源頭核實,溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 )