銀聯分散式資料庫安全設計

隨著個人資訊和隱私資料對於保密要求越來越高，各行各業對安全的要求也越來越高。而支撐各行各業的資訊系統在設計和開發時，面臨著安全方面的新挑戰。資料庫作為資訊系統中資料儲存和資料管理一個重要模組，其安全和設計顯得尤為重要。近年來，分散式資料庫在金融業加速落地，金融機構對分散式資料庫安全有哪些需求?金融機構分散式資料庫要如何進行安全設計?

本文整理自DTCC 2021中國資料庫技術大會上嘉賓演講，分享嘉賓是中國銀聯雲端計算中心高階工程師李永峰，他介紹了分散式資料庫安全體系，以及銀聯分散式資料庫UPDRDB在安全設計方面的探索實踐。本文主要包括以下部分：

1. 分散式資料庫的安全訴求

2. 使用者安全

3. SQL安全

4. 資料安全

5. 未來工作

1.分散式資料庫安全訴求

首先看一下分散式資料庫安全體系的定義，根據金融行業標準對分散式資料庫安全體系的定義。分散式資料庫安全體系包括基礎支撐保障、使用者管理、訪問控制、資料安全、監控預警、密匙管理、安全管理、安全審計等。

最底層是基礎支撐安全保障，包括作業系統、網路以及物理裝置的一些安全要求。上面才是真正的分散式資料庫核心的一些安全保障，包括使用者管理，如身份識別和鑑別，使用者授權和角色管理等。還有訪問控制，如物件訪問控制、一些許可權節點訪問控制，讀寫安全控制等。此外，比較重要的一部分是資料安全，資料安全包括資料儲存加密、資料備份恢復加密，作為分散式資料庫所強調的資料副本一致性的安全保障等。此外，還包括安全審計，如SQL 審計，資料庫對SQL審計有很多要求，為了防止惡意的 SQL 攻擊，使用者對資料庫操作 SQL 都要進行一些安全的審計來提供安全保障。

銀聯作為一個金融機構，嚴格按照金融標準要求去做分散式設計和改造。銀聯內自研的分散式資料庫是一個演變的過程，從上一代的分散式資料庫中介軟體UPSQL PROXY逐漸演變到新一代的 UPDRDB。

UPDRDB在原有架構上主要有以下兩點創新升級：

一是在部署架構上，採用新型的中介軟體與分散式儲存引擎(Lamost)混合部署架構。其中最新引入的分散式儲存引擎(Lamost)主要負責資料的儲存以及其他一些複雜語句的處理。

二是引入了獨特的 SQL 分類路由和分散式事務管理機制。在新引入的布式儲存引擎(Lamost)上，接入層對使用者的請求進行了特殊分類，分為簡單的連線交易和複雜的管理類查詢交易。其中簡單的連線交易，直接路由到儲存層(InnoDB)處理，對於複雜的管理類查詢，如多表Join以及子查詢等複雜查詢操作，路由到分散式儲存引擎(Lamost)來處理。

UPDRDB創新架構較第一代分散式中介軟體有不少優勢，一是支援單點 DDL，可以直接建表，對複雜語句的支援更完備，同時也支援了在純中介軟體下不太容易實現的擴縮容，新一代架構實現了線上的水平擴縮容。而且較上一代產品，對簡單的聯機交易，在效能上也有提升。

同時新一代UPDRDB產品考慮到更多安全，在安全方面也做了加固。

在銀聯新一代分散式資料庫設計時，銀聯內部的安全訴求主要體現在使用者安全、SQL安全、資料安全三個方面。使用者安全，主要是對用基於分散式中介軟體架構資料庫的使用者管理、鑑權以及訪問控制。SQL安全主要是引入了 SQL 黑白名單以及 SQL 審計。資料安全主要是資料儲存安全和資料傳輸安全。資料儲存安全對於使用者密碼以及使用者資料的儲存引入了國密的演算法，作為金融機構，銀聯需要滿足國密的要求。

2.使用者安全

UPDRDB底層儲存是基於MySQL構建，整個使用者體系也是在 MySQL原生使用者體系上擴充套件新的訪問控制策略。一方面在代理層增加更細緻的IP黑白名單，另一方面使用者密碼支援國密儲存和傳輸。

客戶端與UPDRDB資料庫建立連線的時候，主要是接入層做連線處理。在接入層會依次執行Host校驗和User校驗。

校驗的過程分為兩個階段。第一個階段是在 TCP 建鏈階段，根據客戶端Src執行Host校驗，在初始階段進行防護。

第二階段是在使用者認證階段，會根據的使用者名稱和訪問源端地址進行使用者匹配和校驗，這與MySQL 原生使用者匹配同樣的策略，在使用者認證完之後，還會再根據客戶端Src進行 IP 黑白名單校驗。

分散式中介軟體這種架構，代理層會有一個訪問地址，存在不透明的問題。如建立一個使用者U1，僅限於10.0.1.%網段訪問，代理層的整個使用者的控制僅10.0.1.%網段網段ID的客戶端可以訪問。由於代理層的存在，在資料庫層的使用者訪問只能限於代理層的伺服器訪問地址，可能變成了 172 這樣一個網段地址，導致代理層的訪問控制策略和儲存層的訪問控制策略不一致。

如何將整個代理層和儲存層的節點訪問控制策略保持一致?銀聯的實現方式是 IP 透傳(IP Transparency)。

IP 透傳的實現是在代理層擴充套件了 MySQL通訊協議，在代理層與儲存層建立連線的時候，將客戶端原始IP 地址作為連線屬性透傳給儲存層，儲存層在接到代理層連線時，實際上並沒有用代理層的連線去做 IP 校驗，而是識別擴充套件欄位，用擴充套件的欄位來表示原始的 IP 進行最終的使用者Host校驗。這樣可以做到整個代理層和儲存層的訪問策略是一樣的，都是10.0.1.%網段。

3.SQL安全

(1)SQL相似性

銀聯新一代UPDRDB中在SQL 安全方面，對接入層SQL 解析做了很大改進。在SQL解析階段，根據詞法分析(lex)和語法分析(yacc)生成SQL摘要，並基於單詞序列來判斷和查詢相似SQL語法樹，並獲得了美國專利授權。 SQL相似性檢測有以下幾個好處：

在效能方面，相似SQL規避語法解析和CASE分析等階段，複用語法樹和執行計劃，使得SQL解析與分散式執行計劃構建的整體效能提升1倍左右;在資料安全方面，SQL 摘要可以達到資料脫敏效果，脫敏的資訊可以用於 SQL 審計等方面;在訪問控制方面，可以基於SQL 摘要實現SQL 黑白名單控制;在態勢監控方面，對SQL執行狀態進行實施監控和告警，也便於使用者及時調優。

(2) SQL黑白名單

關於SQL 安全的SQL黑白名單，顧名思義就是透過設定SQL黑白名單來實現SQL訪問控制和告警。整個 SQL 黑白名單是在SQL 相似性的基礎上，基於SQL摘要來做。

銀聯SQL黑白名單包括三個階段，第一階段是 learning 階段，即學習階段，使用者可以線上下或設定環境對業務上所有的 SQL 進行執行，做一個全量回歸，學習到所有的使用者SQL列表，將整個列表裡面新的SQL請求標記為灰名單。第二階段是識別階段，在識別階段，使用者可以根據學習到的列表將所有的 SQL 劃分到白名單和黑名單。到第三階段生產執行的時候，使用者應用執行的任何請求，在接入層都會根據 SQL 黑白名單進行校驗。如果是白名單，則允許SQL執行，如果是黑名單，則拒絕執行。如果是灰名單，有不同的控制策略，可以控制它拒絕執行，也可以控制它允許執行。同時也可以對灰名單設定更高階的告警，讓使用者感知到有新的 SQL 執行。

實際上這三個階段是一個不斷迴圈的過程，在執行階段進行時，學習階段也在進行。當執行階段使用者變更業務，有新的 SQL 執行，則進入 learning 階段，重新進行學習得到灰名單列表，識別階段使用者會根據自己的需求將新SQL劃分成白名單或黑名單。透過SQL 黑白名單，可以有效防止使用者未授權的 SQL 在資料庫中執行，避免一些高危 SQL 執行帶來的風險。

(3)SQL態勢監控

SQL 態勢監控，在接入層定期將相似的 SQL 執行狀態按照不同的維度彙總到監控平臺上，進行監控和展示。

具體的維度分為 SQL 型別和 SQL 摘要。銀聯將 SQL型別 分為幾大類，如DML 裡面有update 和 delete 這樣的操作，此外還有 DDL 的一些操作，都按照型別進行劃分並監控。而SQL 摘要，可以看到某一個型別裡面更詳細的一些 SQL 執行狀態。可以看到每一個SQL型別執行平均延時、最大延時以及執行次數等指標。同時也支援針對每一個指標設定告警策略，超過限值會對使用者告警通知。

(4)SQL審計

SQL 審計是現在資料庫常見的功能，從客戶端連線到接入層、傳送請求到請求處理結束，最後客戶端斷開連線，對整個生命週期中請求的行為進行審計。這裡分成了前端審計事件和後端審計事件兩類事件。前端審計事件主要審計客戶端與接入層直接接入的一些資訊，包括前端應用跟接入層的連線建立和退出，後端審計事件會審計整個 SQL 執行的一些計劃，後端接入層和資料層的連線的建立退出，以及整個過程中請求執行時間、結果、耗時、錯誤碼，包括分散式資料庫的整個執行計劃到了哪個分片等都會有記錄。

4.資料安全

資料安全包括儲存加密和傳輸加密兩方面。

(1)儲存加密

儲存加密方面。首先是使用者密碼加密儲存和傳輸，MySQL 本身支援密碼加密，有一個加密外掛 mysql_native_password，是基於sha1的加密，密碼屬於密文傳輸。銀聯的UPDRDB引入了upsql_sm3_password外掛，引入了新的加密演算法 sm3(國密)。在傳輸的過程中，UPDRDB支援用國密的演算法對密碼加密進行傳輸和校驗。

資料儲存UPDRDB做了一個 InnoDB 表空間加密，MySQL 本身是基於keyring_file.so外掛呼叫加密演算法對錶空間進行加密，InnoDB原生預設AES加密，為了滿足金融機構對國密的需求，UPDRDB對整個外掛進行了擴充套件，引入了新的SM4(國密)加密演算法。在設定儲存引數時，可以指定使用哪種加密演算法。

(2)傳輸加密

傳輸加密方面，MySQL 本身支援 SSL/TLS加密資料傳輸。在UPDRDB架構下，由於前面有接入層、儲存層，所以做了兩部分的加密。

一種是隻在前端加密傳輸，就是客戶端和接入層做加密，如傳統的SSL/TLS解除安裝那樣，在這種方式下，接入層和儲存層之間並沒有做資料加密傳輸。第二種是做全鏈路加密傳輸，相當於客戶端到接入層，以及接入層到資料儲存層的整個傳輸過程中都採用加密傳輸。

客戶端採用上述兩種加密傳輸的任何一種，需要在各個層面做證書配置。考慮到效能，銀聯自己內部實踐一般都是推薦選用前端加密傳輸，但是因為有一些要求全鏈路加密傳輸，所以UPDRDB也支援全鏈路加密傳輸。

5.未來工作

在易用性方面，將進一步提升SQL相容性，如觸發器、臨時表等，以及擴充套件分散式索引等;在安全方面，增強資料加密傳輸，如雙向認證、國密認證;運維方面，深度挖掘SQL審計，進一步加強SQL防禦功能，加強對分散式鎖等待、慢查詢SQL等分析;效能方面，最佳化複雜SQL執行效率，如條件下推，儘可能把各種條件都下推到儲存層做資料查詢，複雜計算儘量用少量的資料做計算，同時最佳化接入層連線池模型，以及鎖的最佳化等。

李永峰在演講的最後介紹，銀聯雲是中國銀聯的一個雲服務品牌，於 2020 年 9 月 16日正式上線。銀聯雲源於開源安全可控，立足金融為核心理念和服務宗旨，致力於為客戶提供雲資源服務、雲平臺服務、雲共享服務等多方面的服務，同時結合銀聯在金融領域長期的研究實踐和技術積累，為客戶提供一站式金融解決方案。