個人隱私保護之三:數據安全防護實踐

2019-12-31 49390人圍觀 ,發現 3 個不明物體 數據安全

一、前言

自GDPR法規在歐盟發布以來,隱私保護在國內也逐漸完善了立法和相關標準的制定,今年四部委成立APP專項治理組后,許多公司也開始對APP進行的自查和整改。我們在此項工作中,發現許多細節內容并沒有多少具體實施和落地的資料可以查閱,只能逐步在摸索中進行。

APP隱私政策保護主要在以國標GB/T 35273-2017《個人信息安全規范》,APP專項治理工作組編制了《App違法違規收集使用個人信息自評估指南》作為主要標準依據,尤其是《指南》是目前官方可能唯一發布的相對比較具體的重要參考。

上一篇《APP隱私保護之二——用戶端隱私保護實踐》中探討了APP前端的一些法規要求和實踐措施,本文著重探討服務端及企業內部數據安全策略方面的數據安全保護機制,包括數據存儲,使用,共享,轉讓,公開等數據生命周期中的核心環節。

以往文章:

《APP隱私保護之二——用戶端隱私保護實踐(上)》

《APP隱私保護之二——用戶端隱私保護實踐(下)》

二、個人信息保存

個人信息保存包括數據傳輸和數據存儲的相關要求,APP運營方應該對數據傳輸和存儲過程,方式,以及有效時間做相關的控制,并使用如加密,匿名化等技術措施作為數據保障的基礎能力。

2.1. 數據加密和匿名化技術

2.1.1. 數據加密

(1)數據傳輸加密:通常會使用HTTPS等安全協議進行傳輸

SSL/TLS系列中有五種協議:SSL v2,SSL v3,TLS v1.0,TLS v1.1和TLSv1.2;

SSLv2 是不安全的,不能使用;

TLSv1.1 和 v1.2 都沒有已知的安全問題,只有 v1.2 提供了現代的加密算法;

當然也可以用其他協議傳輸,將傳輸的敏感數據內容加密。

(2)數據存儲加密:線上數據加密一般會對結構化數據的某幾個敏感字段家加密,比如含有個人隱私信息的字段

數據庫存儲加密的三種方式:

開源的加密組件,如Key Management Service(KMS),通過開發SDK或集成至數據庫中間層實現自動加解密。

數據庫自身功能,如Mysql加密解密函數AES_ENCRYPT(),AES_DECRYPT();SQL Server加解密函數dbo.EncryptByPassPhrasePwd,dbo.DecryptByPassPhrasePwd。

商業數據加解密產品,有需要的可以自行了解一下

2.1.2. 匿名化處理

匿名化處理是使用場景

用戶注銷賬戶,刪除數據時

大數據平臺使用數據加工

收集個人信息后,建議將數據匿名化或去標識化,并將該信息與可用于恢復識別個人的信息分開存儲(一般存儲至大數據平臺)。數據加工時,優先使用匿名化的數據,并加強對個人信息的訪問控制,這樣可以很好的控制個人隱私泄露的場景。

2.2. 人信息控制者停止運營后的處置機制

公司一般不會涉及到這種情況,但是做隱私合規時,需要這部分完善的管理制度。

a) 及時停止繼續收集個人信息的活動;

b) 將停止運營的通知以逐一送達或公告的形式通知個人信息主體;

c) 對其所持有的個人信息進行刪除或匿名化處理。

一般來說需要建立一套管理制度,或某個管理制度建立相關條款。并對上述要求具體實施細則建立一個操作流程。

三、個人信息使用

3.1. 個人信息使用的訪問控制

個人信息的訪問控制,我的理解主要是針對企業內部的數據訪問機制,需要遵循最小權限原則,即用最少的人訪問最少的數據。

常見的場景:

后臺系統訪問和獲取數據的權限控制措施,系統統一認證鑒權

應用系統之間數據接口的權限管控,尤其是跨業務線,跨項目的情況

數據提取和拷貝機制

大數據平臺,在線數據分析

辦公網數據管控(桌管,零信任,線上文檔編輯工具)

兜底方案:DLP,水印,染色,審計系統

3.2. 系統后臺展示方式

涉及通過界面展示個人信息的(如顯示屏幕、紙面),對需展示的個人信息采取去標識化處理等措施,降低個人信息在展示環節的泄露風險。例如,在個人信息展示時,防止內部非授權人員及個人信息主體之外的其他人員未經授權獲取個人信息。

這里簡單的解釋就是系統展示也做脫敏,當然許多場景可能不能脫敏。

3.3. 用戶請求的處理機制

(1)投訴處理機制

個人信息控制者應建立申訴管理機制和申訴跟蹤流程,并在合理的時間內對申訴進行響應。具體做法分為四個步驟

建立申訴管理制度;

提供了有效的申訴渠道;

承諾了反饋時限;

承諾的反饋時限內進行響應。

申訴管理制度可以是一個獨立文件,也可以是和客服建立的流程機制,甚至是知識庫文件,建立制度的目的是規范申訴事件的處理方法,避免出現,無人響應,應答錯誤等情況

有效的申訴渠道一般在隱私政策中會有說明,最好還是建立多個申訴渠道,保證申訴渠道的通暢,比如電話,在線等,在APP中建立相應入口最佳。

承諾了反饋時限原則上不能超過15日。

承諾的反饋時限內進行響應是上述所有措施有效的保障:

第一,建立詳細的申訴受理流程,客服,安全,法務,公關等崗位進行聯動。客服直接面向客戶進行簡單的判斷和爭取收集,安全部跟進確認申訴事件判斷最終結果,法務和公關進行最中事件解決的方案。

第二,保障上述流程進行,需要建立知識庫,常見問題,需要收集哪些信息告知一線客服,并進行相應培訓。

第三,安全部的數據溯源措施,工具,以及內部承接事件的應急處置方案建立。由于有時間限制,一般從客服接單后,只有不到10天的“破案”事件,所以溯源工具和標準化作業流程很重要。

第四,定期演練和培訓,演練和培訓是保障機制流暢運行的好辦法。

第五,對自己的隊友多鼓勵,不要埋怨。尤其是制度建立之初,可能會有一些不靠譜的單子發過來,這時如果一味的埋怨一線客服可能會讓整個流程變得阻塞。多分析原因,逐步積累知識庫和培訓素材,才是讓一切變好的好方法

(2)個人信息獲取副本和查詢信息

獲取渠道確認:可以是電話申請,線上申請等

獲取途徑:郵寄,在線提供等

身份認證:驗證身份信息,可以通過輸入密碼,核對**等

信息提取流程:用戶需要信息的類型,建立信息提取流程

證據保存:包括用戶請求證據,***據,提取過程日志或記錄。

四、個人信息的共享,轉讓,公開

4.1. 第三方共享轉讓

(1) 事先開展個人信息安全影響評估,并依評估結果采取有效的保護個人信息主體的措施。

參照《信息安全技術 個人信息安全影響評估意見稿》方法,這里不詳細介紹了。

(2) 向個人信息主體告知共享、轉讓個人信息的目的、數據接收方的類型,并事先征得個人信息主體的授權同意。

一般通過隱私政策,隱私政策彈窗

(3) 共享、轉讓經去標識化處理的個人信息,且確保數據接收方無法重新識別個人信息主體。

只能盡量傳輸去標識化信息或脫敏信息,影響正常業務的還是可以共享個人信息的,主要看業務開展的模式。要建立相關制度,比如對第三方的安全要求,共享機制,安全協議,監控措施等。

(4) 準確記錄和保存個人信息的共享、轉讓的情況,包括共享、轉讓的日期、規模、目的,以及數據接收方基本情況等

一般通過數據接口傳輸數據需要記錄數據傳輸的日志,日志含有日期,訪問規模,額外等級該接口的使用目的和數據接收方信息。

(5) 承擔因共享、轉讓個人信息對個人信息主體合法權益造成損害的相應責任

處理個別案件和免責聲明時要注意,可能需要讓法務部了解一下。

(6) 幫助個人信息主體了解數據接收方對個人信息的保存、使用等情況,以及個人信息主體的權利,例如,訪問、更正、刪除、注銷賬戶等。

客服的流程,客服能夠幫助客戶了解第三方信息。在與第三方簽訂合作時,需要將次義務特別說明。

4.2. 個人信息公開披露處理

(1) 事先開展個人信息安全影響評估,并依評估結果采取有效的保護個人信息主體的措施

同上,不介紹了

(2) 向個人信息主體告知公開披露個人信息的目的、類型,并事先征得個人信息主體明示同意

在公開披露個人信息前,需要通知并獲得同意

(3) 準確記錄和保存個人信息的公開披露的情況,包括公開披露的日期、規模、目的、公開范圍等

公開披露場景很多,所以沒有確定的方式。比如通過系統公開獲獎名單,一般會脫敏個人信息,并且上傳系統的日志中記錄此次獲獎名單即可。

(4) 承擔因公開披露個人信息對個人信息主體合法權益造成損害的相應責任

(5) 不得公開披露個人生物識別、基因信息

4.3. 個人信息委托處理

(1) 個人信息控制者應對委托行為進行個人信息安全影響評估

同上,不介紹了

(2) 受委托者應:

嚴格按照個人信息控制者的要求處理個人信息。受委托者因特殊原因未按照個人信息控制者的要求處理個人信息,應及時向個人信息控制者反饋;

受委托者確需再次委托時,應事先征得個人信息控制者的授權;

協助個人信息控制者響應個人信息主體提出的請求;

受委托者在處理個人信息過程中無法提供足夠的安全保護水平或發生了安全事件,應及時向個人信息控制者反饋;

在委托關系解除時不再保存個人信息。

應用場景很少,沒有合適的場景和案例。基本遵循兩點原則:第一,最小的保存時間原則,第二,委托的授權和個人信息處理方式對信息主體有知情權和同意撤銷權

(3) 通過合同等方式規定受委托者的責任和義務;對受委托者進行審計

主要是審計工作的安排,如果很重大的項目建議采用定期審計,建議聘請外部審公司可以有效轉移風險。一般項目可以考慮自動化審計工具,日志分析等方式。

4.4. 跨境

跨境目前比較復雜,要遵循我國跨境傳輸法律并遵循當地的法律要求。我國的跨境傳輸指南是現在比較常用的參考。歐盟的GDPR現在要求比較嚴格,所以傳輸至歐洲需要特別注意

五、結束語

上一篇主要是針對APP應用端,即用戶側的隱私保護內容,內容比較顯性,大多是前端的修改,涉及很多文案工作。本篇針對的是服務端和公司內部的流程和機制,不僅僅是合規的需要,還是保護公司自身利益的需要。尤其是第三方數據共享時,數據流出公司防護邊界,其泄露極可能影響到公司利益,并且很難排查。

本文主要從隱私要求,管理和法律方式對第三方的數據保護進行約束,公司內容防護建設也應注意對第三方的數據權限控制,并具備一定審計和溯源能力,比如使用脫敏,染色等技術。

*本文原創作者:Alkaid13,本文屬于FreeBuf原創獎勵計劃,未經許可禁止轉載

相關推薦
發表評論

已有 3 條評論

取消
Loading...
Alkaid13

專注于數據安全,企業安全建設,安全合規方向 個人微信:Alkaid13,歡迎新老朋友一起討論

4 文章數 3 評論數 6 關注者

特別推薦

活動預告

填寫個人信息

姓名
電話
郵箱
公司
行業
職位
css.php 微信上那些说赚钱是真的吗