全球隱私法規日趨嚴謹　IT提前因應有道可循

在隱私權逐步受到重視的時代，近年來世界各國均頒布或強化該國之隱私安全法規。在製造業回流的時代，我們的產品與服務更須放眼世界，考量全球各地之隱私法規，及早於資訊端建立因應措施，方能身處台灣，心無罣礙地行銷全球。

隱私工程（Privacy Engineering）的導入

所有資訊安全行業的夥伴都知道，安全最重要的是建立組織氛圍。而組織氛圍的建立，除高階主管的支持，最重要的就是建立相關單位均認同的流程，而後結構化、系統化地將其要求嵌入組織既有流程中，方能可長可久，尤其在大型企業更是如此。而建立可信服的流程，就需要參照的國際標準與最佳實務的經驗，目前較可參考的是ISO27550:2019以及美國國家標準暨技術研究院（NIST）對於聯邦系統的相關要求。

系統風險建模（Thread Modeling）

在一般具規模的組織中，通常已建立需求管理以及上線簽核之相關控制，這裡想強調的是隱私安全需求整合於組織既有流程的實務建議： ‧系統需求階段：這個部分恐怕是所有安全管理人員的痛。需求永遠可以一改再改，開發端時程可以一拖再拖，但安全端永遠是最後才知道，並只有極短的時間檢視、確認與簽核。在法規要求相對薄弱的製造業或是零售、傳產更容易發生這些情況。但這裡想分享的是，安全管理人員其實不需要氣餒，安全是可及早嵌入於系統中的，只要平常天線拉長，對於法規趨勢、安全情資有一定程度的掌握，然後在需求階段仔細了解業務單位的Business Initiative，安全需求其實在很先期就可羅列出來並加入系統需求。另外，在需求階段就掌握資料來源與運用的合法性並與法務單位共同檢視，亦是極為重要的。

‧資料流定義：這一點亦是難中之難，試問多少組織每個系統都能有系統流程？都有詳細的資料流？若非深徹大悟的組織應該很難落實。因此，要能從業務需求、系統架構裡面抓重點才是王道，資料在何時須跨系統傳送、何時須跨組織交換、何時出了整個系統生態圈（Ecosystem），都必須能掌握，那麼對於有經驗的資安工作者安全的重點要求就不言可喻了。

‧風險識別、應對與認可：風險的識別，須考量法規層面（各國法規異同、法規修訂與合法性依據等）、技術層面（MITM、DDOS、資料加解密等）與維運層面（人員精實度、資料存取控制），重點是安全團隊需協助業務單位識別風險，負責單位須提出應對方案，還有最終的CISO或DPO的核可一定得嵌入組織之作業流程中。

建置結合隱私與安全需求的管理系統

實務上，因流程作業時間長，佐證資料多元，牽涉的組織又龐雜，建議相關功能可建置於安全需求管理系統方能實現。而其系統功能重點在於安全需求的確認、資料流（涵蓋個人資訊）的提供，以及可能的安全風險、風險減輕方案的實施、剩餘風險的高階主管核可等。其使用者應橫跨使用者單位、研發單位、資訊安全單位、法務、品管、系統負責單位等等，整體隱私安全管理流程最好還能與企業採購與驗收流程介接方能竟全功。

使用者UI介面的新思維

一個重視使用者隱私安全的企業，勢必要能讓使用者親身感受（Look & Feel），那麼在使用者介面的設計思維，就必須注意以下重點：

Everything is optional

由於大數據的特質是廣泛蒐集資料用以進一步分析，因此資料來源龐雜，多少會有重複、謬誤的資料，若要實際運用，某種程度的去蕪存菁是絕對必要的，甚至很多時候在資料彙整的時候，一定會發現某幾個資料欄位可能會有缺少的情況，其原因除當初因蒐集目的不同外，也很可能是因為使用者選擇不提供，或在過程中執行「被遺忘權」而依法刪除了資料。在以往關聯式資料庫的架構下，以上種種原因很容易導致資料庫異常的情形。近年在非關聯式資料庫（NoSQL）資料庫的興起後，這個問題稍稍舒緩了一些。然而，仍須注意前端使用者介面如Web端的程式邏輯，避免因不必要的欄位合理性檢查（例如性別檢查）而造成程式損毀。

Getting explicit consent

使用者「明確同意」這個部分，在GDPR之後已引起廣泛的注意，須面向全球用戶的跨國企業目前多已大致落實。「明確同意」這件事，談的是重要資料（例如即時的位址資訊）的取得必須使用者明確針對這個項目依其自由心證選擇性加入（OPT-IN），而非以往將其涵蓋於廣泛性的隱私權聲明中一次請使用者同意所有權限。這個部分的程式改動大多僅牽涉前端介面，但困難的是許多App已上線多時，為取得使用者授權補正，可能又須派發一次程式改版，帶來大量的CDN流量費用，許多企業甚至為了這個額外費用將過時的App下架，也算是另類的網路潔淨（Clean Network）計畫！

Mask, Mask & Mask

現今的安全概念強調最小化資訊揭露（Need-to-Know basis），這樣的概念過去多應用在特權帳號管理，現在也應將其應用在使用者介面設計上。尤其是Fintech、Regtech服務的興起，各式業務開始透過各種不同的管道進行銷售與服務，例如透過社交軟體App查詢帳戶資訊、透過手機號碼轉帳，甚至振興方案三倍券、藝Fun券、動滋券等均須取得民眾個人資訊，這個時候就需要考量其交易目的，還有其使用者認證方法的強度，再決定其可在螢幕上顯示的個資內容。

舉例來說，查詢餘額時是否須顯示包含完整姓名的帳戶資訊？付款的QR Code畫面中是否涵蓋個資？我們的建議是非必要時應盡可能隱碼化，減少使用者個資外洩的風險。在我國的金融行動App檢測規範中，還要求含帳戶資訊的畫面不可螢幕截圖（Screen Capture），亦是可以考慮的進階做法。

考量大隱私之資訊未來戰略

針對考量大隱私之資訊未來戰略，以下分成四個面向來討論。

預先思考法規的可能變化

可以合理預期的是全球隱私法規將越來越嚴謹，作為資訊端的架構者，我們必須預期到最終的情境可能是使用者可以自由選擇任何資料欄位的提供與否（OPT-IN Everywhere）。那麼在前台資料的審核與後台資料庫的設計均應做相對應的調整。由於每筆資料的來源都必須記錄其使用者同意，那麼大數據資料庫中的資料，除商業需求外，可能還須考量其依法之可取用性，其記錄須包含其使用者同意取得時間、每個欄位依其目的可留存期間、以及使用者同意須更新的時間（一般而言為5年必須更新）。

建立整合的可視性隱私管理平台

基於大數據資料庫中每筆資料的法遵要求有其複雜度，我們期待接下來會有相關的業界標準在使用者同意的介面呈現與法律字眼，以及相關的隱私聲明，那麼這些標準就易於轉換為機器可讀（Machine Readable）的做法，用以協助大數據與人工智慧系統之法遵主管、資安主管以及用戶快速分辨其每筆資料是否符合其隱私要求，並僅存取合於法遵要求的資料集。

精煉目標行銷、深度學習之準則

一般普羅大眾至今仍不易理解企業如何運用各式技術取得其資料，並用以作為精準行銷的細部內容。近年來拜隱私法規的興起，許多網路巨擘已開始揭露其相關資訊。以臉書（Facebook）為例，大家可以在廣告貼文的右上角點擊「為什麼我會看到這則廣告」去了解廣告主如何做到相對精準之目標行銷。

在精準行銷的運用上，在之前的文章已提示過去識別化後再識別化的議題，當然，大數據希望導入更多資料進行更精確、更深入的分析，最近甚至發展出與其他企業交換資料以取得目標客戶的方法。然而，需要特別注意的是，無論任何的分析，最終都不可用類似系統人肉搜索的方式去明確指定到任一自然人，針對個人的人格剖析及標注亦不建議。另外，在資料的處理上，亦應思考隱私資訊區間化（Spectrum of Identifiability）之做法，舉例來說，年齡欄位可用年齡區間來取代實際年齡的紀錄，既不影響後續資料分析以適度平衡了隱私安全要求。

區塊鏈的應用

不曉得大家是否思考過區塊鏈去中心化、多節點的特性正好是實踐隱私管理系統的最適應用？如同智慧合約，使用者可以隨時在區塊鏈上更改給任一組織之使用者同意，只要相應組織認定其不違反相關法令要求？使用者亦可隨時查閱其隱私情形，企業亦不再為使用者之個資知情權、被遺忘權大費周章？總之，區塊鏈再隱私上的應用應是可期待的。

當然，現今群眾對於區塊鏈的認知未臻成熟，不過可以預期未來零知識證明（Zero-Knowledge Proofs）的技術獲得廣泛認知時，區塊鏈、隱私以及智慧合約的相關議題會是一門顯學。

＜本文作者顏志仲，為前高科技及金融業資訊安全主管，具有20年以上大型高科技製造業與跨國金融機構服務經驗，其專長涵蓋資訊治理、企業風險管理與企業資訊架構。作為前HTC全球資訊安全主管與亞洲最安全銀行資訊安全主管，他曾建立全球規模之資訊安全組織，其業務範疇包含安全認知∕政策∕營運∕技術與事件管理，並也曾於跨國銀行管理高度監理之零信任安全維運。在此之前，顏先生亦於資訊管理協會與電腦稽核協會大型會議擔任講師。相關發表請參閱https://medium.com/@pocket.yen.kelvin。＞