數字化新業態下資料安全創新-token化

// 文丨王志剛 

美團安全架構師。密碼學、雲原生和DevOPS安全，資料安全和隱私合規專家。近幾年推動用大資料演算法解決網路安全和資料安全能力。曾先後在亞馬遜、華為、阿里雲、百度擔任過重要安全技術崗位。曾獲得CISSP 和 DevOPS Professional認證。

引言  

伴隨科技創新引領數字化浪潮席捲全球，資料成為企業發展的核心生產要素。像Google、Facebook等高科技公司，透過提供免費、優秀的軟體和服務，接入大量的使用者，並基於資料資源驅動，獲得了巨大的商業上的成功。然而，在高速發展的同時，公司對資料卻疏於治理，引起了大量的資料洩漏、演算法濫用以及隱私相關的問題。這種危機伴隨著Facebook的“劍橋分析”醜聞，2020年美國大選等標誌性事件，推向了高潮。基於對資料安全和隱私的擔憂，歐盟的GDPR領銜的現代隱私合規出臺，隨後風靡全球，成為又一不可逆轉的潮流。

擺在企業面前是兩條路，既要透過資料科技創新保證生存發展，又要保證使用者資料的安全。在這兩條路的選擇與平衡上，有些企業倒下了，有些企業存活下來，迸發出新的勃勃生機。

由此可見，唯有轉變思路，勇於創新，才能化危為機，長遠發展。我們要認清轉折趨勢：數字化時代從上半場粗放、低效，大水漫灌式碳增長，向基於高效資料管理、治理能力的高質量、高效率的資料碳中和轉變。企業要在這個轉變中生存並脫穎而出，科技創新是重要的抓手。重點把握兩大核心思想：1.需要認清強大資料應用生產力特徵，積極進行技術改造，充分利用先進的資料管理技術手段，提高資料使用效率和治理水平；2.深入學習、理解隱私合規的目的和本質，遵循“可用、不可見”的核心思想，實現效率與治理的統一。

一、資料科技對安全的挑戰

數字化應用環境下，資料具有如下特徵：

1.資料的流動性與開放性：按數字經濟學理論，資料要想創造出商業價值，就必須做到低成本、大規模供應，高效流動。如果利用傳統網路安全最小化、層層審批、層層設防，將嚴重限制資料生產活力。此外在資料流經的每一個節點都達到高階的防護基準，成本也是組織無法承受的。

2.資料的可複製性和失控性：資料作為流動資產，一旦被訪問後其控制權將被轉移，供應者將失去對它的管控。傳統的信任邊界在資料應用中也越來越模糊，這些都讓集中安全策略在新型資料架構下落實起來成本巨大，收效甚微。

3.資料形態多變、應用複雜：資料將在幾乎所有IT系統中傳遞、儲存和處理，其複雜程度超乎想象。加之AI、機器學習以及各類創新型資料應用，讓資料使用邏輯更難以琢磨，要想了解資料的全貌幾乎是不可能的任務。

4.資料威脅複雜多變：資料的巨大商業價值讓包括黑、灰產業鏈，內、外部人員乃至商業、國際間諜都趨之若鶩。攻擊技術、動機層出不窮，防不勝防。

圖1: 常規系統為中心防護模式下資料暴露性

傳統模式下，資料以明文形式在系統中流通，資料暴露性巨大。攻擊者透過應用程式、儲存、主機系統入口，以及攻擊系統的授權賬戶等多種渠道獲取大量資料。

圖2: 常規模式橫向資料暴露性

數字化場景，資料將在數以萬計的應用、任務中傳遞。每個應用都有自身邏輯，讓所有應用合規成本巨大。在如此廣泛、複雜的環境下要保護資料安全，如果採用傳統以系統為中心的防禦模式，必將造成防禦戰線過長，攻強守弱的格局，讓資料安全治理長期處於不利地位。必須轉變思路，創造出一種資料內生的安全機制，在資料業務高速擴張環境下，安全防護能力也隨之增長，這就是以資料為中心的安全防禦創新機制。

二、Token化-數字世界銀行體系  

Token化方案參考現實世界的銀行系統。銀行體系出現前，市面上經濟活動主要以現金交易為主。現金的過度暴露，產生了大量的盜竊、搶劫案件，雖然鏢局生意盛行，但只有少數富豪才僱傭得起，因此社會資產大量流失。銀行體系應運而生：使用者獲得現金後，第一時間去銀行將現金兌換成存款（等價代替物），隨後在整個社會中流通的都是這個代替物-電子現金，只有在極個別場景兌換成現金。隨著銀行系統的滲透，加上各類線上支付應用的普及，這種現金使用場景越來越少。要想搶錢，只能到銀行去，而銀行是經過重點防護。

同樣，資料作為核心資產，可以透過方案在個人敏感資料資料（PII）剛進入組織業務系統時，就將明文資料（P）替換成與其一一對應的假名-token。在隨後的整個組織應用環境中以token高效流通。因為token與明文是一一對應的，可以在生命週期絕大多數場景代替明文傳輸、交換、儲存和使用，而Token只有透過安全可靠的token化服務，才能兌換成明文。駭客和內外部惡意攻擊者即便拿到了也毫無用處（不可見）。由於token的自帶安全屬性，只要在組織內控制住主要資料來源和資料樞紐只使用token流通。新的明文資料需主動換成token，實現資料預設安全，從根本上解決了個人敏感資料的治理難題。

圖3: token化的資料暴露性

如圖，透過推廣Token化，可將實際可訪問明文的服務壓縮到2位數，資料服務暴露性降低到1%以內。

圖4: token化後資料縱向暴露性

如圖，Token化改造後，敏感資料做到0儲存、0快取，0介面，0數倉；只有在少量具有解密許可權主機記憶體，以及UI才可能獲取明文資料訪問權。UI透過後續細粒度訪問控制和審計風控等措施，實現風險可控。對於少量的記憶體資料，因其數量有限，可透過特定的加固和風控措施，進行強化。如果實現全面token化，敏感資料整體風險控制能力可大大增強。

三、Token化方案介紹

3.1什麼是Token化

Token化（Tokenization）是透過不敏感的資料等價替代物token（token）替換個人敏感資料，在業務系統中流通來降低資料風險和滿足隱私合規的方案。Token化屬於去標識化技術的一種。最早出現在支付卡行業（PCI）場景替換銀行卡（PANs），目前有趨勢替換通用數字化場景中的個人敏感資訊（PII）。

1.個人唯一標識資訊（PII）：任何可以直接、間接關聯到具體的自然人的唯一標識資訊如身份證件、手機號、銀行卡、電子郵件、微訊號或者地址。單獨依賴PII資訊，結合其他公開資訊，就可以找到自然人。PII資訊一旦洩漏，可能對個人造成如身份冒用、欺詐等生命財產傷害。因此在包括國內外各類法規中明確要求企業對PII全生命週期保護。

2.去標識化（De-identification）：透過一定技術手段，對敏感資料進行替換、轉換，臨時或永久消除個人敏感資料與自然人的關聯。具體的手段包括假名化、匿名化、資料加密等。

3.假名化（pseudonymization）：透過將敏感資料替換成人工ID或假名，未經授權，任何人無法利用假名建立起與原自然人之間的關聯。Token化就是一種假名化實現機制，廣義上二者可以概念互換。假名化是包括GDPR在內認可的去標識化方案。注意，假名化與PII是一一對應，在特定場景是可以還原原始資料。

4.匿名化（Anonymization）：對敏感資料部分，或全部進行遮蓋、替換，讓其完全失去與原資料或自然人的關聯。匿名化是不可逆的，常用的匿名化技術包括資料遮蓋（data masking）。

5.資料加密：採用資料加密演算法，如國密對稱演算法SM4，普密演算法AES，對敏感資料進行加密，生成密文（Cipher），除非獲取如金鑰管理系統（KMS）加密金鑰授權，無法進行解密，獲得明文。注意與假名化Token不同的是，密文只能解密出明文後才能使用，沒有任何直接使用屬性。因此密文只能用來儲存和資訊傳遞，大大限制了使用範圍，例如搜尋、關聯、查詢、匹配等資料分析場景。

3.2 Token化基本設計

3.2.1 可用、不可見

1.可用性實現：

a）大資料分析場景利用Token的唯一性，實現資料探勘、加工、分析等場景的去重、統計、關聯等功能；

b）資訊傳遞，在其他所有場景，Token利用其唯一性，可以完全替代明文資料在整個體系中流通，解決交換、關聯、查詢、匹配等環節的資料使用；

c）敏感功能使用：在必須使用明文資料場景，可以透過Token化服務換回明文，實現可用性兜底。

2.不可見性實現： Token化本身的安全性是整個方案的安全基礎。因此Token化從設計、到實現必須保證其安全，來防止非法者利用Token獲得對應的原始明文，導致資料洩漏。詳細請參考“四、Token化安全性實現”。

3.2.2 基本架構需求

為滿足複雜場景下資料保護能力，要求Token化方案滿足幾個主要架構要求。

1.業務適配性： Token化需要滿足所有資料應用場景的資料交換要求，包括線上交易、實時和離線資料應用，以及AI和機器學習演算法等所有場景。

2.安全性：保證Token的脫敏屬性是透過保證其與明文的關聯關係的保護。這裡需要透過演算法和Token化服務的安全以及下游應用的多重安全來保障。

3.可用性和效率：Token化的引入，不應增加對業務系統的效率和穩定性的下降。

3.3 Token生成邏輯

Token化的邏輯是，在企業範圍內，為敏感資料生成全域性唯一的ID-Token。通常有3種方案實現ID生成。

圖5: token化邏輯示意圖

圖6：token化生成方法1

1.隨機化：Token完全隨機生成，並透過儲存一一對映關係表（這種是狹義的Token化生成方式）。因為token與明文沒有演算法關係，只能透過Token化服務才能進行正、反向關聯，因此是最安全的方案。但這個方案的缺點是，為保證Token的高度一致性，新token生成邏輯不能併發，否則會出現一對多的一致性問題。為保證資料一致性，將犧牲一定的分散式能力、效能。無形增加了可用性風險，尤其是遠端異地場景。

圖7：token化生成方法2

2.MAC方式 ：透過統一的加鹽雜湊HMAC演算法，任何程式、任何位置都能生成相同的token，保證一致性。生成後的token與明文的對映關係落表，實現反token化能力。該方式優點是可以跨地域實現分散式，缺點是犧牲了一定的安全性。攻擊者一旦獲得了鹽，就可以用演算法批次計算token。我們可以透過對鹽採取適當的保護機制（採用與加密金鑰相同保護策略），可以獲得安全與可用性的平衡。

圖8：token化生成方法3

3.確定性加解密： 透過確定性加密演算法，如（AES-SIV），或者格式保留加密（FPE），將明文加密，生成可逆Token。該演算法破壞了加密的安全技術-隨機性，目前的演算法普遍存在漏洞，不建議使用。此外，該演算法還存在一個天然的漏洞，就是金鑰無法輪換。

3.4 Token化方案邏輯架構

圖9: Token化邏輯架構圖

Token化服務需要滿足全業務場景相容性、安全性和可用性，主要透過多種接入整合方案。並整合必要的安全措施。token化服務按邏輯分為接入層、服務層和儲存層。

1.接入層：主要用來對接業務應用和人員訪問，完成Token與明文之間的轉換即Token化和反Token化請求需求。分別提供人機介面（Portal）、服務介面（API）呼叫和大資料任務請求。由於Token化安全要求，接入層需要保證可靠的安全措施，如細粒度訪問控制、IAM、服務鑑權和大資料作業鑑權能力。

2.服務層：實際執行Token化和反Token化的行為。主要是完成token的生成、儲存以及查詢。

3.儲存層：儲存層主要包含線上儲存和數倉。由於安全性考慮，Token化對映表並不儲存明文而是儲存加密後的密文。同時，透過HMAC演算法建立HASH >token >密文的關聯關係實現明文換token（正查）和token換明文（反查）的業務邏輯。注意，應用並不能透過Token化直接獲得明文，而是獲得密文，透過KMS獲得解密許可權後本地解密獲得明文。

3.5 Token化應用全景

圖10：Token化資料流通全景

元件說明：

1.線上資料來源：敏感資料的主要資料來源，一進入公司需要對接Token化服務API兌換成token，並落庫儲存。一定場景，資料也會接入數倉。資料來源另外角色是向下遊提供分享敏感資料，可透過API，MQ，或共享儲存如S3等媒介。

2.數倉資料來源：直接倒入或來自線上，敏感資料進入數倉，需要啟用Token化任務，將明文轉換成token，並隨後向下遊其他大資料應用提供。

3.Token化服務：

a）Token化線上服務透過API為線上交易、事實任務提供明文換token服務；

b）Token化離線hive，為大資料任務提供離線資料清洗服務，將明文轉換成token。

4.KMS和加解密：

a）為Token化派發加密金鑰，並將明文加密形成密文欄位；

b）為所有具有解密許可權應用派發解密金鑰，進行解密。

5.資料應用：

a）常規中間應用：基於token就能完成業務功能的服務。從資料來源獲取token，並向下遊傳遞；

b）解密應用：按業務需求，滿足安全基線前提下，用token換取密文，並對接加解密模組進行解密，獲取明文。

四、Token化安全性實現

4.1 Token化的安全精要

Token化安全性假定就是Token和明文的無關性，如果任何一個人或系統非法儲存、構造了一份Token與明文的對照字典或者具有構造這個字典的能力，Token化的安全機制就徹底破壞了，因此Token化安全的核心就是防止這個表的生成。

4.2安全風險和安全性設計

1.Token化服務本身安全風險和控制：

a）Token生成邏輯安全：隨機token生成的唯一ID是最安全方式，需要採用可信的隨機數生成器，條件允許可採用基於硬體的密碼機生成隨機數。如透過軟體實現，需要採用基於加密的偽隨機數生成機制。如果採用HMAC方式生成，需要確保鹽的安全。

i. 只能透過KMS等可信機制進行建立、分發和儲存；

ii. 只能在Token化服務執行時內使用；

iii. 定期進行鹽的輪換，建議每日，或每週，用過的鹽進行安全刪除；

iiii.確保採用安全的hash演算法，如SHA-256或SM3。

b）Token化執行時安全：Token化服務採用專用系統，並且進行過特殊加固。

c）Token化儲存安全：考慮到大資料場景以及多種儲存需求，要求Token化儲存本身不儲存敏感資訊，只包含索引、Token 和密文。同時，token化儲存需要進行嚴格的訪問控制。

d）Token化接入安全：

i. API需要進行可靠的服務鑑權，建議MTLS + Oauth2 票據，同時啟用訪問日誌審計；

ii. Token 換明文邏輯只返回密文，由請求服務利用KMS本地進行解密，集中控制解密許可權；

iii. UI提供使用者人工進行token與明文，加解密的能力。要求必須經過IAM，並支援基於ABAC的細粒度、基於風控的訪問控制。

2.生態上下游服務、應用產生的次生安全：不論資料來源，還是下游的明文資料消費方，因具有token化介面訪問授權， 技術上是可以遠端呼叫介面，遍歷出全量的token和明文的對映關係。因此安全措施需要延伸到這些系統和使用者，保證不會因為這些錯誤行為或程式漏洞導致的資料洩漏。

a）構建資料應用安全基線，約束上下游資料使用行為；

b）嚴格禁止任何形式的非法明文，尤其是token與明文的對映關係資料轉發轉存行為；

c）禁止設定代理，必須由資料服務主體直接對接Token化服務；

d）所有生態系統必須進行完整的安全評審，包括後續的變更。確保基線合規；

e）對上下游所有的服務，納入監控體系，包括其儲存、資料介面以及應用程式碼邏輯、血緣；

f）全域性監控、掃描，確保所有不合規的處理及時發現、處理。

五、工程實踐經驗  

Token化服務從設計上並不複雜，一旦實施，將徹底改變組織資料使用習慣，從根本上解決資料使用效率與安全合規間的矛盾。然而，其強大的防護效力是基於對資料使用邏輯的改造，打破舊有的明文資料使用習慣，落地過程面臨在巨大的挑戰。包括疏於維護應用程式碼，冗餘的、混亂的歷史資料、複雜混亂的訪問邏輯，這些問題都會為系統改造帶來障礙。需要所有涉及敏感資料的業務配合改造，這種規模專案，必須從流程規劃、組織保障和技術支撐等多方面統籌，在美團推進公司的改造過程中也積累了大量經驗可以進行參考。

1.一致性策略制定與傳達：Token化作為公司級資料安全治理戰略，需要全域性統一認識。從策略要求、具體實現指南、工具方法等都需要清晰一致，並透過簡潔的文件，有效的傳遞給所有相關方，以降低溝通和錯誤成本。其中解密策略、訪問控制策略、API介面策略、大資料、AI等各種資料應用場景的安全基線，都需要完備。此外，透過有效的溝通渠道，包括培訓、產品使用手冊、介面文件等多種渠道觸達到所有的使用者、研發和業務人員。

2.化整為零，靈活推進： 敏感資料訪問鏈路長、關係複雜，加上治理水平的限制，無形增加了改造難度、心理和實際投入的壓力。將改造邏輯單元進行橫向、縱向切分，最低可細到服務級，實現碎片化灰度改造，讓改造更敏捷。

3.DevOPS化改造：因為Token化改變的是資料使用邏輯，必須由所有業務、研發投入進行。其人力成本巨大，因此將改造的邏輯封裝成簡單、易用SDK，可以降低改造難度和人為失誤導致的風險。此外包括測試、驗收，都可以透過自動化掃描、資料清洗、驗收和檢測工具由業務自助閉環完成。

4.Token化服務能力：改造後Token化將成為部分相關應用的強依賴，Token化的故障和效能問題可直接影響業務應用。因此Token化服務的效能、可用性和穩定性很重要，需要由專業團隊精心設計、並不斷測試驗證、最佳化，避免導致故障。同時，也需要在安全基礎下，提供一定的降級、容錯能力。

5.運營與治理：隨著專案的推進，token將超過明文成為主流，透過控制住要資料入口，主要資料供應方，能保障token在組織內預設使用，實現預設安全；此外，企業的冷資料、靜態資料或者相對獨立的孤島資料依然會形成遺漏和風險。因此需要針對所有資料支撐系統支援掃描，監控等多維度的感知能力。同時將異常資料對應到具體的業務，保證token的全覆蓋。

6.學習、改進與迭代：隨著數字化創新演進，會不斷有新的資料形態、資料應用加入，專案需要應對這種變化，不斷從工具、流程上改進，確保長期戰略得到保障。

六、未盡事宜  

後續，資料安全治理延伸。

資料層面，Token化沒有解決類似圖片、影片等非結構化資料。可能需要直接透過加密。

Token化沒有解決跨企業信任邊界的資料交換問題，這部分需要隱私計算、多方安全計算等新技術。

Token化主要物件是存在DB、Hive中的結構化PII資訊。對於隱藏的在JSON中的半結構化資料和日誌、檔案中的非結構化PII資料並沒有處理，需要配合強大的資料發現和資料治理工具完成。

在整個資料安全體系中，PII只是滄海一粟，Token化實際上也僅僅解決企業內部資料使用場景，但卻開了一個預設安全和設計安全的先河。由於PII資訊是個人敏感資訊的核心資料，功過Token化，上可以溯源到資料採集、下可以延伸到三方資料交換。此外，透過Token去關聯，可以實現無損資料刪除等能力。資料安全是一個巨大的課題，尤其是在數字化變革的強大發展需求下，面對紛繁複雜的資料應用，網路安全需要更多的技術創新，我們希望透過Token化拋磚引玉，激發出資料安全的創新之路。