【GDPR施行後的法遵議題】深度剖析隱私工程

在今年5月25日施行的歐盟GDPR（歐盟通用資料保護規則），有許多國家也調整該國法律以配合GDPR的實施，更有甚者，有越來越多企業，開始慢慢的意識到，企業必須調整該公司對於個資的使用方式。

GDPR正式實施後，其實跟許多行業都息息相關，不只是在歐盟設點的企業必須面臨GDPR的法遵要求，只要提供歐盟民眾服務、跟歐盟有生意往來的企業，也都受到GDPR的規範；而企業對於GDPR的討論，也從單純法條內容的討論和應該如何遵循的作法等，進一步深入，開始真正從IT技術上，去克服企業進行法遵時所面臨的困難。

勤業眾信集團董事萬幼筠：使用一些數學或者是計量方式，甚至是一些加、解密的方式，把資料做到「不足茲識別」，是隱私工程最初步的解釋。

不過，GDPR的本質其實是「隱私保護」，GDPR最重要的意義在於，賦予個資當事人7種權利，讓所有的個資使用，都必須尊重當事人的意願，加上，GDPR也要求企業提供各種產品和服務的同時，都必須要做到預設Privacy By Design（預設隱私）或者是Security By Default（預設安全），然而，這當中到底包含多少的技術含量，以及管理精神呢？相關的各種概念，其實也深刻影響到許多企業系統的設計與調整。

若要真正將GDPR法規要求的Privacy By Design，或者是Security By Default，落實到企業系統中，我們要仰賴「隱私工程框架」（Privacy Engineering Framework）才有辦法做到，此時，就得從「隱私工程」技術面著手。

隱私工程和所謂的安全工程，甚至是經常聽見的SSDLC（安全的軟體生命開發周期），又有什麼差異呢？那麼，何謂隱私工程框架呢？這是一種新興的概念嗎？有什麼必備條件嗎？對於所有的企業來說，都有辦法達成這樣的目標嗎？

而在實際的技術面上，我們又該如何執行呢？

面對這種種對於隱私工程的疑問，勤業眾信集團董事萬幼筠表示，簡單來說，隱私工程就是使用一些數學或者是計量方式，甚至是一些加、解密的方式，把資料做到「不足茲識別」，這就是對於隱私工程最初步的解釋。

保護資料，更要促進資料合理使用

萬幼筠指出，歐盟實施GDPR後，各國對於這個號稱最嚴格個資法的因應，都已經產生相關的漣漪，除了保護範圍複雜，也會擔心技術演進是否足以保護個資。因此，國外把GDPR當成一門生意在做，反觀臺灣，卻視為不得不做的法遵要求，相較之下，兩者的主動性和積極度就有很大的差別。

以歐盟境內為例，只要符合GDPR的保護要件，個人資料就可以在歐盟境內自由流通，讓企業享有做好個資保護帶來的優勢。

例如，以歐盟之前剛通過的金融規範「歐盟新的支付命令：PSD2」為例，裡面隱含GDPR的「資料可攜」的概念，屆時，只要符合GDPR的規範，金融開戶不必在多點、多地進行，只要在一地設立帳戶，就可以做到多點多地共用。

而且，歐盟所保持的態度是：資料保護之餘，是否可以促進資料的合理使用，將更為重要，關鍵在於：怎麼讓監理機關安心，信任個人資料不會遭到企業濫用，讓資料的使用處於合理保護範圍內，促使企業不會侵害、濫用個資。

他認為，畢竟，資料使用的終極目標，是為了帶來數位時代新興國家的應用，所有資料的使用，就是要扶植這個產業，產生一些符合數位國家的新興應用。例如，如果醫療上的資料如果用得好，就可以帶來健保不浪費、醫療效率提升的好處。但若只是為了符合個資法規範，而把所有資料應用的可行性全部鎖死，一旦這樣的法律實施後，是不會帶來任何符合公益性的活動。

但臺灣個資法沿襲歐盟對於個資的保護，重點不只在於「保護」，萬幼筠指出，臺灣個資法第一條、第二條，就明定「促進資料合理使用，符合特定目的」，希望可以做到保障當事人個資權利，包含資訊自主權、人格權等，「如果資料保護很好，但其實不好進一步的使用，其實，並未合於法律提到的合理使用及符合特定目的規定。」他說。

目前，國發會正在改進相關的要求，針對個資法修法的呼聲也越來越高，畢竟，歐盟是臺灣第五大貿易國，我們有許多企業和機構都在歐盟設點，雙方也有很多的資料進出和人員自然流動，因應GDPR，對於臺灣這種外貿型國家而言，早已經是不可避免的趨勢。

從五個面向剖析隱私工程的內涵

KPMG數位科技安全部門協理邱述琛：隱私工程目前仍是很年輕的學門，而根據美國NIST針對隱私工程的內涵來定義，可以從五個面向來看，包括：法令要求、風險模型、隱私工程與安全目標、風險管理框架，以及隱私衝擊評鑑。

KPMG安侯建業數位科技安全部門協理邱述琛表示，隱私工程目前仍是很年輕的學門，而根據美國NIST針對隱私工程的內涵來定義，可以從五個面向來看，包括：法令要求、風險模型、隱私工程與安全目標、風險管理框架，以及隱私衝擊評鑑。

基本上，隱私工程組成的元件，很大一部分來自於各種法令的要求，尤其是企業針對使用者提供各種產品和服務，需要滿足隱私需求時，都會跟法令有關。再者，依照各種使用情境不同，進行風險評鑑後，便會導引出不同的風險模型，也經常會出現需要重新再識別的風險；當依照不同風險模型做風險評估後，所設定提供的服務，必須要有對應系統能力與需求，同時，也要確保系統可以滿足需求並對應風險。

不過，因為風險情境會改變，不同情境也會產生新的風險，不管採用哪一種風險管理框架，例如ISO 27001等，都需要定期評估，就平常而言，至少一年執行一次是合理的。但是，如果有重大事件發生的時候，就必須要做隱私衝擊評鑑，像是國內外同業發生的資安事件，不管是之前的SWIFT國際轉帳系統的盜轉案例，或是臺灣ATM盜領事件等，對於金融業，都是必須重新評估風險評估的時候，在當下不僅要識別風險，也要部署管控機制和措施，並且確認系統如何滿足隱私需求等，「重點是，企業在做隱私衝擊評鑑時，千萬不可比爛。」邱述琛說。

像是因為數位相機解析度越來越高，就有人擔心拍照比讚的時候，個人指紋會被冒用偽造，而因為生物特徵無法改變，一旦遺失就終生無法使用時，對於企業而言，在設計相關的門禁系統或服務時，就必須要回歸到系統面，審視該如何滿足隱私需求，並且要知道哪些地方會使用哪些隱私資訊，以及對於個人和企業將造成的影響。

以日前爆發Google+的API隱私漏洞為例，邱述琛認為，當初這套社交網站設計之時，只保留兩週的Log（登錄檔）記錄，就是沒有從隱私工程角度思考的作法，並未考量到企業所提供的產品或服務，是否已經包含預設隱私（Privacy By Design）的概念。從這裡，我們也可以發現，Google+最後決定停用個人版的理由──隱私保護是需要投入成本的，當保護隱私的成本太高時，企業就可能會終止服務。

而基於這樣的考量之下，資安和隱私之間的關係，又會是什麼？

邱述琛也引述美國NIST的定義，當中提到：隱私工程是專注於解決系統處理個人識別資訊（PII），可能帶來無法接受隱私遭到侵害後果的系統工程指導，涵蓋到兩種狀況下帶來的個資隱私要求交集點：來自未授權系統行為的安全需求，以及未經授權存取個資產品流程的隱私需求。

歐盟的8種隱私工程設計策略

萬幼筠指出，歐盟網路和資訊保安局（ENISA）在2014年，就提出8種隱私工程設計策略，達到保護資料隱私權的目標。這8種設計策略，包括：個資數量應限制在可能最少數量的「最小化」（Minimize）策略、個資及其彼此間關連性應該被隱藏的「隱藏」（Hide）策略、個資盡可能以分散形式在單獨空間處理的「分置」（Separate）策略，以及個資在最高級別的聚合中進行處理，並盡可能減少使用細部個資的「聚合」（Aggregate）策略。

接著，還有應充分告知個資當事人個資被使用情況的「告知」（Inform）策略、為當事人提供處理個資的聯絡或代理窗口的「控制」（Control）策略、制定符合法律要求的隱私政策並予以「執行（Enforce）的策略，以及資料控制者必須能夠提供符合現行隱私政策與相關法律要求證明的「宣告」（Demonstrate）政策。

他表示，這8種隱私工程的設計策略，可以從資料蒐集、資料分析、資料儲存和資料使用等四個面向，檢視可能的實施方式；更重要的是，在資訊流的每一個階段，都要檢視是否符合相關法規，且能提供相關佐證的證明。

去識別化常見的技術，包括假名化和匿名化

當企業不再保護客戶的資料隱私，客戶也不願意提供更有價值的資料，甚至可能提供假資料，此時，反而會因為彼此缺乏互信，客戶就不可能提供真實有價值的資料，當然，企業也無法提供更好的服務。

因此，國際上也開始在個資隱私保護框架上，建構所謂「去識別化」的方法。舉例而言，英國在2012年提出「匿名化應用準則」，接著，歐盟在2014年公布「匿名化技巧意見書」，日本也在2018年9月修訂「個人情報保護法」，正式將「去識別化」納入法律規範。

從上述各國採行的做法，我們也可以看出，所謂隱私工程中的「去識別化」（De-identification），就是一個重要的發展方向，希望針對個資中各種可以識別的資訊，予以移除或模糊化，降低個人不想揭露資訊的風險。

至於如何確認是否已經完成去識別化呢？萬幼筠表示，去識別化後，可以從三個方向，判斷是否已經做到真正的去識別化，包括：是否還有可能識別當事人？是否可能和其他個資連結？是否可能推論出與特定人？

而去識別化其實是一種通稱，意味著個資不再具有直接或間接識別性，包括假名化（Pseudonymization）和匿名化（Anonymuzation），皆是去識別化最常見的兩種技術。

「假名化」可以單獨保存資訊，實際採行的作法是，以一致的值來替換任何可識別為數據的各種方式，而且，在日後有需要的時候，可以檢索那些能識別出來的訊息，也可以將數據鏈連結回個人──重點是，假名化之後的資料是「可以逆轉」的。

但只要所有的資料採用了「匿名化」技術，就會是一種對於可識別數據的破壞，也就永遠不可能再透過各種方式連結回當事人。因為，資料一旦匿名化之後，就是永久匿名化，而且，匿名化的資料都是「不可以逆轉」的。

萬幼筠強調，當資料透過去識別化的方式，來降低侵害他人隱私，或者是減少不想被揭露的資訊外洩的風險時，反而會讓資訊的運用產生更多的可能性、更大的價值，像是：新型態商業模式、大數據的運用、政府推動的開放資料，而且，資料分析精準行銷，或者是智慧生活科技發展等，都可以透過這些已經去識別化的資料後，發揮更大的價值。

比較嚴格一點的區分方式，就是歐盟法規所提到的定義，例如什麼是假名化？什麼是匿名化？像是匿名化的資料，就不在GDPR的管轄範圍內，因為已經是「不足茲識別」了，但這樣的資料，被利用率也相對低。

所以多數人都在研究，什麼樣的資料保存可以匿名化？什麼樣的資料用假名化？假名化的資料使用場景又是為何？例如，某些涉及公眾存取得資料，假名化的強度就要很高；如果是企業內使用的資料，如果可以確保不會被外界任意存取，這些資料的假名化就可以有程度上的差別。

從是否能夠更改原始資料的狀況，來考量適合的去識別化技術

萬幼筠指出，若要進一步理解去識別化的實作技術，可從是否需要更改原始資料，來區別不同實作面的技術。

若需更改原始資料內容，降低資料洩漏可能的風險和隱私侵犯，此時，我們可交叉使用下列四種技術實作方式，包括：重排（Permuntation）、概括化（Generalization）、遮蔽（Masking Out），以及亂數（Random）。

若是不需要更改原始資料內容，就可以透過：資料欄位移除（Removing）、資料加密（Encoding），以及資料筆數變異（Add false information）的方式，去降低資料洩漏的風險。

但不管使用哪一種去識別化的技術，相關的資料都必須經過可靠性驗證，包括：經過K匿名、L多樣性、T相似性檢定後確認。

整體而言，去識別化是一個過程，當機敏資料加上去識別化的方法和技術，可以降低隱私個資遭到濫用的風險。而決定資料是否要去識別化之前，企業要先經過「盤點」、「分類或分級」、「去識別化」以及「管理」等四個步驟，持續予以檢視。

詳細來看這個過程，第一步，就是盤點資料內容欄位，確認包含哪些機敏資料，以及是否要進行去識別化或者是完全不開放；第二步，則是透過分類或分級方式，確認欄位屬性，針對不同特定領域的資料，依據機敏程度和風險水準進行資料分類或分級；第三步，就是依據資料等級，選擇不同安全性的去識別化技術和演算法；到了最後，是依據分類後資料欄位屬性，來選定驗證方法。

延伸閱讀

萬幼筠：從隱私工程來看GDPR的法遵落實

邱述琛：隱私工程實戰解析與未來挑戰