一、背景介紹
随着資料時代的到來，越來越多的國家、企業都遭受到資訊洩露的困擾，例如2022年發生的某某汽車資料洩露事件，标志着外部攻擊者正常的攻擊手段逐漸從傳統的服務破壞轉變為資訊竊取，為應對攻擊方的手段進化，甲方安全體系架構設計也逐漸從以網絡、終端為核心的保護理念過渡到以資料為核心的保護方式，近年來伴随着國際上例如歐盟 GDPR 等資料安全嚴令的頒布，大陸也相繼在2021年頒布了《中華人民共和國資料安全法》、《中華人民共和國個人資訊保護法》（後續簡稱資料安全法及個人資訊保護法），标志着國内資訊安全保護新紀元的到來。
二、資料安全保護措施介紹
針對資料安全的保護實踐，并不是單一保護措施就能夠解決的安全問題，而是需要從資料收集生成、資料使用、資料傳輸、資料存儲、資料分享與披露、資料銷毀整個生命周期去考慮，将需要的控制方法和理念融入到産品的開發過程、技術體系搭建及流程設計體系之中。本次文章的内容受限于篇幅，主要針對資料存儲加密及資料展示脫敏兩部分的實踐探索進行重點介紹，其中資料存儲加密隻說明結構化資料加密的部分，非結構化資料的加密及鑒權并不進行涉及。
圖1：資料洩露的走向呈現多元性
為保證文章内容的通讀适用性，故在第二部分優先先介紹各自的基礎概念及其解決的核心問題，便于不同領域的讀者進行了解和回顧。
2.1 資料展示脫敏
問題一、什麼是資料脫敏？
資料脫敏是按照一定規則對資料進行變形、隐藏或者部分隐藏的資料處理方式，讓處理後的資料不會直接洩露原有資料的敏感屬性，進而實作對于敏感及機密資料的保護。
以手機号舉例，完整的手機号為11位存在一定規律性的數字字段，那麼脫敏後的手機号可能就是 138*****413（用*替代了中間的數字）
問題二、脫敏解決什麼問題？
針對現有的産品形态，展示敏感資料的媒體可能是網頁、APP、小程式等，在展示敏感資訊，特别是機密或者個人資訊的時候，可通過肩窺、任意複制等形式出現洩露。
我們舉一個比較常見的案例，企業任何形式的通訊錄中均包含了公司全體的手機号及個人資訊，如果預設展示不存在任何脫敏措施可以進行任意查詢，是否可能存在有人通過批量腳本進行查詢導出的方式，進而導緻員工手機号大量洩露。
2.2 資料存儲加密
問題一、什麼是資料加密?
在早些年提起所謂“資料安全”的概念時，大部分人們會聯想到的都是所謂的“存儲安全”概念，在一個時期内，資料安全和存儲安全是劃上了狹義的等号的，這個階段内資料視為一種靜态的資源進行保護。随着理念的提升，資料被人們認知為一種動态的資源，這種情況下，資料存儲作為原始資料的基礎儲存形式，需要被作為源頭保護起來。
圖2：加密和解密樣例
問題二、加密解決什麼問題?
資料加密主要的目的就是為了防止原始資料被竊取之後導緻的敏感資料洩露，例如資料庫檔案被拖走，經過加密的資料字段，在外部攻擊者拿到檔案後，也無法進行解密，敏感資料不至于洩露。
三、安全方案調研及選型
方案調研及選型是資料安全實踐中極為重要的階段，因為這其中涉及到确定方案後調整難度較大的問題，故該過程中需要技術架構、安全、DBA、CI/CD等多方的共同讨論和确定，充分識别方案中的風險及實際可行性。
3.1 敏感資料的定義
3.1.1 可參考的國内法律法規
前文提到2021年度國家頒布了适用于國内情況的個人資訊保護法及資料安全法，在個人資訊保護法中存在針對個人資訊的描述，指的是以電子或其他形式記錄的能夠單獨或者與其他資訊結合識别自然人個人身份的資訊，包括但不限于自然人的姓名、生日、身份證号碼、個人生物識别資訊、住址、電話号碼等。
因目前針對于網際網路私營企業尚未有規範化明确定義的敏感資料分類分級标準，故在實際實踐過程中，調研方案可結合目前已經公布的較為成熟适用于金融領域的《金融資料安全資料安全分級指南》（JR/T 0197—2020），以及适用于電信領域的《基礎電信企業資料分類分級方法》（YD/T 3813-2020）中針對敏感資料的定義及分類分級标準。
3.1.2 綜合考慮意見
結合上述國内相關的合規要求，以及考慮到後續針對加密及脫敏的業務場景接入适配情況，可以從以下幾個方面整體界定何為敏感資料；
- 業務資料：敏感個人資訊以及涉及個人隐私的資料、UGC生成資料、企業内定義機密資料；
- 基礎支援資料：密碼、加解密密鑰等；
最終結合整體考慮及業務實際存儲資料情況，可确定适用于實際情況的敏感資料定義分類分級标準，以下為部分重點可考慮字段。
圖3：敏感資料定義部分樣例
3.1.3 敏感資料分類分級打标
在完成敏感資料定義的階段後，下一步較為重要的工作是針對敏感資料分布的調研工作，是針對資料資産識别的重要步驟，根據企業内部确定的資料分類分級标準内容，對原始資料的儲存情況進行識别确定，針對識别得到的個人敏感資料及重要資料标簽分布，和對應業務線研發進行下一步精細确認，確定敏感資料資産分布識别的準确性。為全面推進資料加密的落地及資料的集中統一，打好相應基礎工作。
在确認敏感資料分類分級分布的過程中，工具的選擇主要分為掃描部分與打标部分。
敏感資料掃描抽取方案
針對掃描部分需根據實際公司情況進行選擇和使用，例如公司存在大資料HIVE平台的，如對接了全局資料庫資料，可以考慮從HIVE中抽取資料内容進行資料字段結構确認和示例資料标注。
如果公司隻存在資料庫執行個體可進行分布确認工作，那麼針對線上資料庫的掃描需同步考慮穩定性需求，在抽取資料的SQL查詢方法選擇上存在多種方案可選，其各自也會存在優缺點，以下做相應介紹：
方案一：順序抽取一定數量的資料進行樣本比對
優點：實作較為簡單。
缺點：如資料庫執行個體中前期存在部分測試資料，順序抽取的資料樣本關聯性會存在影響。
方案二：随機抽取一定數量的資料進行樣本比對
優點：從統計學角度來說，該種方式比對的樣本資料準确度最高。
缺點：随機抽取的樣本如果SQL編寫不當，且資料庫資料量較大，會直接導緻較多的慢查詢出現。
方案三：倒序抽取一定數量的資料進行樣本比對
優點：抽取樣本資料為最新産生資料，比對準确率能夠提升。
缺點：如資料庫資料處于新增狀态，其比對的資料結果可能存在不一緻的情況，如主鍵或唯一值是自增的情況，可考慮使用唯一值進行範圍标定。
敏感資料識别打标方案
針對打辨別别部分，目前市面上較為常見的還是通過複合規則的方案進行标定，例如對樣例資料進行正則比對，針對标準化字段名進行比對等。但在面對龐大的資料庫字段情況下，必然會出現部分誤報和漏報的情況，亦如上文提到的一樣，這個過程依然需要一定程度的人工介入，降低錯誤打标的問題。
在該部分的實踐中，如考慮排查人力成本問題，建議針對識别規則選擇設定的更為寬松，漏報的排查難度會高于誤報的排查難度，故識别規則的寬松适當使得誤報出現提升，可以有效降低對于人力的投入。
3.2 資料脫敏方案調研
3.2.1 脫敏接入方式的選擇
針對資料脫敏方式的選擇，目前主流的脫敏方案主要存在以下幾種：
- API接口脫敏
- 資料庫view方案
- JS前端脫敏
- 匿名去辨別化脫敏
API接口脫敏
優點：提供的方式較為标準化，且能夠支援不同的脫敏需求；
缺點：依賴于針對整體接口的統計及配置接入，防止出現遺漏進而達到整體脫敏效果；
資料庫view方案
優點：可實作動态脫敏方案，适用于web應用場景，邏輯可封裝在視圖中，便于維護開發；
缺點：碰到較為複雜的脫敏邏輯時，其占用的空間成本及較大的性能開銷都會較為凸顯；
示例：
圖4：建立使用者資訊表
針對上表建立脫敏視圖
create view user_info_view asselect id,name,concat(left(phone,3),'****',right(phone,3)) as phone,concat(left(id_card,4),'**************') as id_card from user_info; 圖5：建立脫敏視圖表
JS前端脫敏方案
優點：實作成本最低，能夠快速實作脫敏需求；
缺點：實際為僞脫敏，容易被外部攻擊者進行還原，并未起到真正脫敏的效果；
匿名化方案
優點：實作相對簡單，不需要複雜的算法和技術支援；
缺點：使用場景主要集中于資料集釋出或共享，因泛化及抑制的限制，匿名化資料的效用會被降低，特定查詢無法進行造成資訊損失。
方案最優解
考慮到脫敏應當盡量從源頭進行脫敏的原則，以及實際業務場景仍然可能需要檢視明文資料的情況，選擇通過API接口脫敏的方案進行具體實踐是目前的最優解。
3.2.2 脫敏标準的确定
前文明确了需要保護資料的範圍和範疇，針對資料展示脫敏的實踐，我們即需要考慮到針對已定義敏感資料根據其資料特征的安全保護，又需要兼顧實際使用人在檢視脫敏資訊過程中，對于内容的一定可識别性，我們以身份證号和手機号來進行舉例。
圖6：大陸公民身份證号編碼結構
圖7：大陸手機号編碼結構
從上述大陸身份證及手機号的編碼結構組成來看，每個人的這兩組資訊都是由幾個分段組合而成，特别是後四位是相當重要的一個識别标簽。
在這裡我們引用加拿大學者ElEmam等人定義了三類常見的隐私攻擊場景，并結合其評估名額計算方式，針對脫敏标準的方案進行計算，盡量降低風險暴露風險，可得到以下幾項結論。
圖8：三種重識别攻擊場景
圖9：評估名額計算風險示例
評估名額結論：
- 脫敏強度位數越多，重識别及洩露風險越低，但實際情況中需考慮預期适用範圍，保持資料可用性；
- 僅對手機号中間4位機身份證出生年月日進行脫敏處理，被重識别的風險機率較高，風險較高；
- 針對身份證後4位及手機号後8位進行脫敏處置，可以将平均重識别風險較低到一個較低的标準；
- 結合第三點的結論，如果保留僅保留手機号的前3位及身份證的前兩位，可以将風險進一步降低；
結合以上名額考慮結論，目前國内較多企業的最佳實踐，以及使用者最小夠用原則，以下脫敏使用實踐提供參考：
圖10：敏感資料定義部分樣例
一個企業内部，在實踐過程中最好大家需約定使用一套脫敏标準，避免出現因脫敏标準不一緻，而出現被惡意利用拼湊出完整敏感資訊的情況，例如一個企業内的兩個AB業務，A業務針對手機号碼的脫敏方式為隐藏中間4位，展示為138****6123，而B業務選擇隐藏後4位，展示為1386454****，那麼在這個業務場景中，攻擊者就有辦法通過查詢AB兩業務的資料進行比對，獲得完整的手機号，這點需要特别注意。
3.3 資料加密的調研
3.3.1 加密算法選擇
針對加密算法的選擇工作，主要會出現以下幾種選項和考慮内容：
- 采用國際通用加密算法還是采用目前國内規定的國密算法；
- 采用非對稱加密算法還是采用對稱加密算法；
- 采用加密強度最高的算法，還是選擇相對适中強度的算法；
針對以上三個問題，是在加密算法選型過程中考慮最多的内容，我們逐一對三個選擇進行各自的解讀，便于讀者知曉在實際業務場景中如何進行更好的選擇。
問題一：國際還是國内加密算法？
針對該問題，主要的業務背景在于随着國内密碼法的落地，國内針對于關鍵基礎設施的密碼保護要求出現了一定的變化，是以是否必須使用國密算法，主要核心的點在于該企業或者機關機關是否為認定的關鍵基礎設施，如果一經認定，那麼使用國密算法是較為穩妥的選擇。
問題二：非對稱還是對稱加密算法？
非對稱和對稱在實際業務場景中，存在各自的優缺點，例如對稱加密算法相較于非對稱加密算法來說其加解密速度更快，更适用于大規模資料的加解密操作，而非對稱算法則相反，其更适用于小規模資料的加解密操作或進行資料簽名操作，在實際的加解密方案選擇中，兩者會結合使用，使用對稱加密大規模業務資料，使用非對稱保護密鑰及校驗加密資料内容。
問題三：強度最高還是适中的加密算法？
并不是強度越高的算法，在實際業務運用中就安全性越高，還需要出于業務性能、可用性、以及高強度算法本身缺陷等多方面的考慮，故實際的業務使用，需以實際業務資料進行加解密性能測試後進行選擇。
3.3.2.加密密鑰的管理機制
密鑰管理是整個資料安全加密過程中最為重要的一個環節，一個安全的加密系統，至少需要二級及二級以上的加密機制，特别是密鑰系統在應用自身管理下的場景，故針對加密密鑰的管理在評估階段重點針對以下幾項内容進行了讨論和考慮。
- 密鑰生成是否需考慮随機數的添加；
- 密鑰是否需要具備輪轉機制；
- 密鑰存儲在何種可信KMS中進行存儲；
- 加密是否采用分層密鑰結構（根密鑰、密鑰加密密鑰、工作密鑰）；
- 密鑰是否需考慮動态轉換和過期失效丢失等場景；
針對密鑰管理KMS系統的最終實作，可以具體檢視下述引用連結内容的介紹進行了解（WKMS微盟密鑰管理系統）。
3.3.3.加密方式的選擇
從整體資料流動的全生命周期來看，根據部署方式及部署環節的不同，會存在多種加密技術方案可供選擇，各技術方案有其優勢和劣勢，在評估階段需結合實際業務場景進行考慮，以下列舉在實際業務場景中較為實際可用于評估的方案内容進行介紹。
圖11：加密方式整體圖示
技術一：CASB代理網關
原了解析
部署位置：終端-應用伺服器之間
圖12：CASB代理網關原理
原理：CASB代理網關（Cloud Access Security Broker）是一種委托式安全代理技術，無需改造目标應用，隻需通過适配目标應用，對用戶端請求進行解析，并分析出其包含的敏感資料。
優勢：與業務結合的資料安全保護，可以基于使用者、資源、操作和業務屬性，靈活利用通路者所對應屬性集合決定是否有權通路目标資料。
劣勢：實施成本較高。
技術二：應用内加密（內建SDK）
原了解析
部署位置：應用伺服器
圖13：應用内加密（內建密碼SDK）技術原理
原理：應用内加密（內建密碼SDK）是指應用系統通過開發改造的方式，與封裝了加密業務邏輯的密碼SDK進行內建，并調用其加解密接口，使目标應用系統具備資料加密防護能力。
優勢：
1.适用範圍廣，應用系統的開發商可以自行解決資料加解密的絕大多數問題，對資料庫系統本身或第三方的資料安全廠商沒有依賴；
2.靈活性高，應用服務端加密，主要是針對于應用伺服器的加密方式，因為應用服務端加密可與業務邏輯緊密結合。
劣勢：
需要對應用系統開發改造。應用系統加密的實作需要應用系統開發投入較大的研發成本，時間周期較長，後期實施和維護成本較高，也面臨大量代碼改造帶來的潛在業務風險；
技術三：資料庫加密網關
原了解析
部署位置：應用伺服器-資料庫之間
圖14：資料庫加密網關技術原理
原理：資料庫加密網關是部署在應用伺服器和資料庫伺服器之間的代理網關裝置，通過解析資料庫協定，對傳入資料庫的資料進行加密，進而獲得保護資料安全的效果。
優勢：
應用系統與加解密功能分離。相比較于傳統的應用内加密（內建密碼SDK）技術，資料庫加密網關技術具有獨立性，能夠使使用者從高度複雜且繁重的加密解密處理邏輯的開發工作解放出來。
劣勢：
高性能和高可用實作難度大。資料庫加密網關增加了額外的處理節點，在大資料量和高并發通路場景下，要實作高性能、高可用，面臨工程化實作難點。
技術四：資料庫外挂加密
原了解析
部署位置：資料庫
圖15：資料庫外挂加密技術原理
原理：資料庫外挂加密通過針對資料庫定制開發外挂程序，使進入資料庫的明文先進入到外挂程式中進行加密，形成密文後再插入資料庫表中。這種技術使用“觸發器”+“多層視圖”+“擴充索引”+“外部調用”的方式實作資料加密，可保證應用完全透明。通過擴充的接口和機制，資料庫系統使用者可以通過外部接口調用的方式實作對資料的加解密處理。
優勢：
獨立權控體系。使用資料庫外挂加密技術，可以在外置的安全服務中提供獨立于資料庫自有權控體系之外的權限控制體系，适用于對“獨立權控體系”有相關需求的場景，可以有效防止特權使用者（如DBA）對敏感資料的越權通路。
劣勢：
1.僅支援Oracle等少量資料庫類型。資料庫外挂加密，目前大多數的技術實作形式，存在功能性依賴，僅支援開放進階接口的Oracle等少量資料庫；
2.資料庫性能損耗較高。資料庫外挂加密是通過觸發器、多級視圖，進行外部接口調用來實作加解密，觸發器或視圖的運作機制要求對加密表中的每一條資料中的每個加密列的讀寫都會進行外部接口調用，是以，當遇到比如“查詢中涉及的加密列較多”等情況時，會對資料庫的讀寫性能存在明顯影響；
3.可擴充性差。在業務變化引起資料庫表結構發生變化時，需要對外挂程式業務邏輯進行調整，甚至需重新定制開發，存在後期維護成本。
技術五：TDE透明資料加密
原了解析
部署位置：資料庫
圖16：透明資料加密技術原理
原理：透明資料加密（Transparent Data Encryption，簡稱為TDE）是在資料庫内部透明實作資料存儲加密、通路解密的技術，資料在落盤時加密，在資料庫記憶體中是密文，當攻擊者“拔盤”竊取資料，由于資料庫檔案無法獲得密鑰而隻能擷取密文，進而起到保護資料庫中資料的效果。
優勢：
1.獨立權控體系。與資料庫外挂加密類似，使用插件形式的透明資料加密技術，同樣可以在外置的安全服務中提供獨立于資料庫自有權控體系之外的權限控制體系；
2.性能損耗較低。透明資料加密技術隻對資料庫引擎的存儲管理層進行了性能增強，不影響資料庫引擎的語句解析和優化等處理過程，資料庫自身性能得以更好保留，透明資料加密技術在資料庫加密技術中，性能損耗較低。
劣勢：
1.防護顆粒度較粗。TDE本身是一種落盤加密技術，資料在記憶體中處于明文狀态，需要結合其他通路控制技術使用。在實戰場景中難以防範DBA等風險；
2.資料庫類型适用性上有限制。透明資料加密因使用插件技術，對資料庫的版本有較強依賴性，且僅能對有限幾種類型的資料庫實作透明資料加密插件，在資料庫類型适用性上有一定限制。
圖17：加密技術優劣勢比較
在整體技術方案的選型中，最終方向選取了應用層加密的方式來實作業務實踐落地方案，但在該過程中，也出現了兩個擴充方向進行讨論。
方向一：統一敏感資料收斂到中台，減少資料落地，實作敏感資訊出入口最小化
優點：資料彙總統一，使敏感資料加密接入方減少，且可統一未來敏感資料出入口
缺點：對敏感資訊服務的可用性要求高，且存在資料收斂改造成本
方向二：各業務及應用接入加密，根據實際業務情況接入開發
優點：各業務可根據自身情況靈活接入SDK實作加密方案
缺點：實際各業務系統的改造，工程量大，時間周期長，研發成本高
3.3.4 加密帶來的影響
從上述描述加密方案選型的内容來看，加密并不是一件隻有好處沒有壞處的事情，其可能帶來的問題也需要在方案評估階段盡可能的考慮，如确實存在未考慮到或實際場景存在變化的情況，也需要在項目進行過程中，結合多方意見進行調整，以下總結并列出了以下幾項可預見性的影響。
- 問題一：加密後帶來的資料檢索、資料運算、資料排序等業務需求問題如何滿足；
- 問題二：加密後帶來的上下遊資料同步及使用問題；
問題一：
如果要對加密後的資料進行檢索等操作，目前是存在較多的困難的，雖然理論學術上目前存在同态加密技術來解決相關問題，但在我們實際的工程實踐中其應用場景還是較為有限，故要考慮到通用性的檢索場景，目前存在兩種折中的方法：
- 添加加密關鍵字段用于檢索輔助，根據分段關鍵字減少搜尋範圍，實作檢索；
- 增加輔助字段，用于檢索内容的範圍縮小（例如位址資訊，增加省、市、區等不加密字段，通過收縮檢索範圍到具體街道，進而實作檢索）；
問題二：
對于任何一個企業的資料來說，其都是一個動态流動的過程，且對于資料加密改造來說，必然會存在曆史明文資料字段，以往的資料上下遊互動一定同步使用的是明文字段，那麼在加密後一定會帶來原始資料同步下遊的相關問題，該點會在最終明文資料完全去除的過程中爆發。
故針對該點，可考慮方案采用明文，密文字段并存雙寫，并在後期做服務切換的過程中，監控相應資料庫 SQL 審計内容，來确定明文字段的相應流量，保證上下遊改造的一緻性。
四、改造實踐方案探讨
推動企業内部進行資料存儲加密改造以及資料展示脫敏改造，如果不是一個全新從零起步的系統服務，都會面臨着對于曆史服務的改造，以及保證新上線業務能夠遵循已确定的資料安全改造需求。
推動曆史存量的改造，會涉及到相應應用服務的改造、曆史資料的清洗、接口或流量切換等工作，但也不能忽視針對增量的管控措施，從風險的角度來說，越早發現越早解決，相應風險産生的可能性及影響都會更低，是以在解決曆史存量的問題過程中，從事前、事中、事後的角度考慮管控措施，有助于整體資料安全風險的降低。
4.1 資料脫敏改造步驟
4.1.1 脫敏存量改造
考慮到業務子產品的複雜性及多樣性，在存量改造過程中，需要廣泛地獲得研發及産品的相應支援，針對對應的業務子產品進行統計彙總，确認改造範圍，并根據各自業務子產品的排期、接口子產品的使用熱度、業務重要性等多方面次元進行考量，分别管理其項目推進接入計劃内容。在多期接入方案完成後，配合産品及研發對其子產品進行複盤，确定相應脫敏遺漏情況。
4.1.2 脫敏增量管控
事前階段：
方案評審過程嵌入資料安全評審項目，明确項目是否存在敏感資料展示；
事中階段：
針對全局接口的上線過程進行準入控制，在過程中明确相應接口的出參内容是否包含敏感資料字段并進行字段敏感類型定義；
圖18：字段敏感定義示意圖
事後階段：
定期通過 API 流量審計系統監控系統服務中敏感資料使用及傳輸接口的敏感資料脫敏實際情況，并與事中階段登記的敏感接口清單進行比對，如發現敏感資料接口未進行敏感字段登記、登記有誤或者未進行脫敏，則通過内部通知的方式告知應用負責人進行整改工作。
圖19：流量系統中的敏感字段展示
4.2 資料加密改造步驟
資料加密改造是一項風險高，周期長的改造工作，需分多階段多步驟逐漸推進相應工作，且需要做到各階段取得階段性工作目标後進行相應的核對檢查無誤後，進入下一階段，在該過程中，研發、DBA、CI/CD、大資料、安全等多部門需要配合恰當，共同确認和推進相關過程。
4.2.1 加密存量改造
圖20：改造工作步驟圖
各改造階段需注意檢查項
- 新增加密字段階段：表結構字段長度和密文長度比對，防止出現長度不足，同時加密字段需保留原明文字段索引，減少性能影響。
- 資料雙寫階段：自增ID需要建立檢查機制，如果是原表新增密文字段可不考慮，建立表雙寫需進行校驗。
- 應用服務切換階段：資料讀取邏輯兩步進行比對，灰階切換過程中需要進行雙邊比對，完善打點記錄，保證報錯後進行排查，制定完善且逐漸的灰階切換計劃。
- 存量資料加密刷數階段：存量資料需保證100%刷寫密文，防止遺漏。
- 資料庫流量監控階段階段：作為明文下線前的最後階段，要在這個階段核心實是否存在通路流量。
- 明文下線階段：明文字段應進行灰階置空操作，避免一次性操作，預留灰階觀察時間。
4.2.2 加密增量管控
事前階段：
方案評審過程嵌入資料安全評審項目，明确項目是否存在敏感資料需要進行存儲；
事中階段：
在應用上線環節中，研發在建表過程中定義其新應用服務涉及的敏感資料字段，并通過針對“CREATE TABLE”、“ALTER TABLE table_name ADD COLUM”等語句增加sql審計檢測，檢測技術标準中敏感參數定義的方式，明确事中環境的敏感資料辨別打标準入，并且關聯CI/CD過程中的告警觸達進行規範的傳達；
事後階段：
定期針對資料庫進行增量掃描，對增量資料庫字段抽取其樣例資料及字段特征，判斷其是否存儲敏感資料，比對前期登記情況，如因為項目排期問題或者因為事中階段通知觸達遺漏等情況導緻未進行存儲加密，對未加密的敏感字段，通知業務方進行整改。
圖21：定期增量字段掃描
五、總結
資料安全實踐是一個長期且艱難的過程，其涉及業務線廣泛、實施難度大、流程內建性要求高、改造周期長等多方面的難題，故資料安全改造實踐也處于一個長期改進探索調整的過程當中，本文介紹的加密和脫敏隻是資料安全實踐的其中兩個環節，隻有不斷根據資料安全生命周期添加不同環節對應的安全措施，才能夠提升企業整體的資料防護能力，保障使用者的資料及隐私安全。
随着資料安全落地實踐的進一步深入，資料屬于動态資産的概念越發明顯，我們加密了資料庫，保護了資料展示的過程，是否就能高枕無憂？資料安全的推進工作沒有終點，還有很多的實踐工作等着我們進一步探索。
六、參考資料
[1].[綠盟科技]，大資料下的隐私攻防02：身份證号+手機号如何脫敏才有效 (https://cloud.tencent.com/developer/article/1636078)
[2].[煉石網絡CG]，一文讀懂十種資料存儲加密技術 (https://www.zhihu.com/people/lian-shi-wang-luo-cg)
[3].JR/T 0197—2020，金融資料安全資料安全分級指南
[4].YD/T 3813-2020，基礎電信企業資料分類分級方法
[2].[Eleven_Liu]，利用資料庫視圖實作WEB查詢敏感資訊接口動态脫敏 (https://www.cnblogs.com/Eleven-Liu/p/11234324.html)
作者:朱瀛海
來源:微信公衆号:微盟技術中心
出處:https://mp.weixin.qq.com/s/7RDGtYHwFexB7P0-hewcOg