數據訪問控制的未來 - 網安 - 專業的網絡安全產業、社區、知識平臺

數據訪問控制是零信任的最后環節和終極目標。基于零信任的數據訪問控制，已經成為數據安全保護和治理的新方法。

但是，對于數據訪問控制的實施問題，企業客戶卻不得不面對幾種選擇：

1）基于數據存儲原生控制的方法：是指利用數據存儲的原生控制能力，來構建自己需要的數據訪問控制。企業客戶可以自己動手構建DIY(自己動手)解決方案，也可以花錢購買數據訪問編排解決方案。但都無法擺脫數據存儲原生控制存在可觀察性不足的問題。

2）基于數據訪問代理的方法：通過在數據消費者(用戶/應用程序)和數據存儲之間建立獨立的數據訪問層，將訪問控制與數據存儲基礎設施分離。這是目前主流的商用數據訪問平臺采用的方式，也是當前最被看好的數據訪問控制方法。但傳統的數據庫代理技術主要用于南北向的流量控制，且難以適應于云原生微服務環境。

3）基于數據層邊車的方法：將服務網格(Service Mesh)中的邊車(Sidecar)技術理念，應用到數據網格(Data Mesh)，專門解決云原生微服務環境中的東西向數據訪問控制難題。數據層邊車本質上充當應用程序和數據之間的斷路器。盡管數據層邊車還是發揮代理的作用，但它是為云原生架構和數據網格架構而設計的未來型代理。

雖然新一代技術常常代表了未來的方向，但是企業客戶還是應該結合自身的實際情況，選擇最適合的數據訪問控制實施方案。

目錄

1.數據存儲原生控制方法

1）DIY(自己動手)解決方案

2）數據訪問編排解決方案

3）數據存儲庫的可觀察性不足

2.數據訪問代理方法

1）代理和數據庫代理

2）SQL無感知數據庫代理

3）SQL感知數據庫代理

3.數據層邊車方法

1）傳統代理無法適應云原生環境

2）云原生世界需要數據層邊車

3）數據層邊車 vs. 數據庫代理

數據存儲原生控制方法

數據存儲原生控制方法可以細分為兩種方案：DIY(自己動手)解決方案+數據訪問編排方案。

1）DIY（自己動手）解決方案

方法說明。DIY（自己動手）解決方案是指客戶利用數據存儲原生能力，自己動手構建客戶需要的數據訪問控制。

原生功能包括數據存儲中可用的安全視圖、函數、策略。
如果客戶的數據團隊有能力利用數據存儲中的原生功能，他們通常會這樣做。

方法不足。使用原生能力構建DIY（自己動手）解決方案的問題在于：

它不是核心業務。在大多數情況下，利用原生功能構建DIY數據訪問控制方案，并不是客戶的高優先級事項。客戶的工程資源最好用于支持和發展客戶業務的核心活動，從而為企業創造更大的業務價值。
維護成本高。數據訪問控制不是那種“設置好后就可以拋之腦后”的東西，它需要持續、悉心的照料，這會帶來隱性成本和風險。
學習曲線陡峭。很多時候，如果您缺乏創建或管理數據訪問解決方案的經驗，此類項目可能會帶來未知的工程挑戰。
遷移數據平臺的煩惱。如果客戶想從一個數據平臺遷移到另一個數據平臺，可能需要重新編寫DIY解決方案的大部分內容。
原生功能受限。DIY解決方案受限于可用的數據存儲原生能力。參見下文。

2）數據訪問編排解決方案

方法說明。數據訪問編排解決方案是對原生數據存儲能力進行編排的產品，只需要付費購買即可，無需客戶自己的數據團隊親自動手實現它們。

數據編排通常由軟件平臺支持，該平臺連接各種存儲系統，并在需要時啟用與其他應用程序的連接。它將來自多個存儲位置的數據進行整合，以便企業可以在其分析和管理平臺中使用這些數據。
在數據訪問編排中，被編排的是對數據的訪問，而非數據本身。不是在數據存儲本身（例如數據庫、數據倉庫和數據湖）中手動配置數據訪問，而是使用單個工具定義訪問策略，然后在各種數據存儲中執行安全策略。
編排解決方案可能會節省客戶利用原生能力構建方案的時間。

方法不足。與后文介紹的數據訪問代理方案相比，編排解決方案在許多方面受到限制：

缺乏數據感知能力。通常來說，編排解決方案依賴于定期批處理，來識別和標記敏感數據。而數據訪問代理平臺則能夠在訪問數據的同時對其進行分析，可以即時發現敏感信息并立即采取行動。
侵入性。編排解決方案經常會使用抽象數據訪問所需的對象，污染數據基礎設施。此外，在許多情況下，它們會迫使您更改現有邏輯（例如訪問新的抽象對象而非現有對象）。而使用數據訪問代理，則無需添加任何數據庫對象，也無需改變查詢中的任何內容。
超級管理員憑據使用。編排解決方案需要使用高訪問權限賬戶。這意味著您可能需要設置一個賬戶，能在SaaS或設備上執行很多操作（即創建對象和讀取數據）。而使用數據訪問代理，您無需添加任何額外的憑據，從而消除了意外更改的風險。
原生功能受限。編排解決方案受限于可用的數據存儲原生能力。參見下文。

3）數據存儲庫的“可觀察性不足”

數據存儲庫存在“可觀察性不足”的問題。

3.1）數據存儲庫日志通常被禁用

在傳統的本地數據庫和DBaaS（數據庫即服務）中，日志的唯一來源通常是由數據存儲庫本身將活動記錄到文件系統中。但是，日志記錄通常會因為性能下降和PII泄密風險等原因而關閉：

性能下降。在MySQL和PostgreSQL數據庫中，當打開查詢日志記錄時，由于關鍵查詢執行路徑中產生的額外I/O，QPS(每秒查詢數)通常會下降25-30%；
PII泄密的風險。被記錄的查詢/請求日志，并沒有經過對PII信息的隱私處理。這必然導致安全問題。

3.2）DBaaS(數據庫即服務)的可見性不足

DBaaS中的指標主要有兩個來源，但都存在不足：

一是粗粒度的DBaaS指標。這些是由DBaaS引擎自身發布的聚合指標，比如說每秒連接次數、每秒SELECT/UPDATE/INSERT次數、每秒慢速查詢次數。但它們都是粗粒度的，無法對應到與DBaaS交互的特定用戶或服務；
二是匯總的云提供商指標。但這些指標也無法被有效映射和歸因。例如，AWS Cloudwatch發布了與DBaaS引擎的網絡I/O活動相對應的字節數和吞吐量。然而，它無法識別出某個表中的多少行或者某個集合中的多少文檔，對應于網絡層觀察到的字節數量。也不可能將這些指標的觀察值，歸因于特定用戶或服務。

3.3）傳統數據庫部署的可見性不足

傳統的數據庫部署的確增加了一些可見性，如下所示。但由于性能影響或存儲成本，這些日志通常會被禁用。

服務帳戶：用戶通常使用BI(商業智能)工具或應用程序登錄數據庫，而BI工具和應用程序將使用共享型服務帳戶來查詢數據庫。也就是說，真實用戶的身份無法記錄在數據庫日志中。
用戶活動：身份認證日志可以突出顯示身份認證失敗時間，包括事件的日期和時間。但是，這類日志不包括上下文數據，包括執行的查詢或調用者的源IP。
查詢活動：這類日志通常用于數據庫調優，包含性能細節，包括查詢計劃和執行時間。
系統健康狀況：關于數據庫健康狀況的聚合指標，包括使用的內存和存儲、上次運行性能調優的時間，以及硬件或損壞問題。

3.4）增強型數據庫原生控制方法的不足

增強數據訪問控制的一種常見方法，是將數據存儲與IAM產品進行集成，從而為數據訪問增強用戶身份識別能力。
但是，這種集成在安全和監管方面留下了空白，因為它們沒有將數據庫原生訪問控制的全部功能擴展到經過SSO身份認證的用戶，也沒有提供可以擴展的訪問策略工具。

總而言之，數據存儲原生控制在很多時候都靠不住。所以，數據訪問代理方法才被廣泛采用。

數據訪問代理方法

1）代理和數據庫代理

代理是位于客戶端和服務器之間的攔截服務。當代理靠近客戶端部署時，稱為正向代理。當代理部署在離服務器更近的地方，使得客戶端不知道服務器的來源時，它被稱為反向代理。

數據庫代理（ProxySQL、MaxScale等）基本上是一種反向代理，旨在為數據庫、鍵值存儲、消息隊列提供安全性、可伸縮性、高可用性等優勢。

圖1-數據庫代理

2）SQL無感知數據庫代理

在高度分布式的數據存儲庫（如MongoDB和Cassandra）流行之前，數據庫代理通過為后端數據存儲庫提供連接池，來實現擴展性和高性能。通過將請求路由到健康的數據后端，來確保高可用性，并減少故障轉移時間。

此類數據庫代理通常被稱為L4層代理或SQL無感知代理，包括HAProxy、Nginx和類似工具。

3）SQL感知數據庫代理

隨著應用程序遷移到云端，數據量猛增，現代數據存儲庫開始提供可擴展性和高可用性功能，使用分布式Coordinator-Worker（協調器-工作節點）架構的數據分片和復制。

圖2-Coordinator-Worker架構

為了保護應用程序邏輯免受底層拓撲變化的影響，ProxySQL和MaxScale等 SQL感知數據庫代理開始受到關注。

SQL感知代理可以執行這類任務：通過將讀查詢定向到Worker并將寫查詢定向到Coordinator中的master，來執行SQL讀查詢/寫查詢的路由。

SQL感知代理也用于這些場景：需要在SQL層操作以緩存SQL查詢的響應，以提高性能；或者重寫和阻斷某些SQL查詢，以增加安全性。

事實上，目前主流的數據訪問平臺都采用了感知型數據庫代理的方式。這也是當前最被看好的數據訪問控制方法。

圖3-基于數據庫代理模式的數據訪問平臺

數據層邊車方法

1）傳統代理無法適應云原生環境

隨著容器技術尤其是Docker的成熟，以微服務為可組合單元的面向服務架構（SOA）開始受到廣泛歡迎。云原生應用程序開始使用微服務作為它們的構建模塊，從而將自身用于持續集成和持續部署的DevOps方法。

雖然基于微服務的新架構帶來了許多好處，但它們也暴露了挑戰，特別是在安全和流量管理方面：

這些分散的微服務之間的通信，導致東西向流量激增；
卻沒有可以強制執行安全規則的明確邊界；
也沒有可以執行流量管理的單一入口/出口點。

因此，在應用程序和數據存儲庫（數據庫或數據倉庫）之間部署代理的傳統模型，在云原生的新世界中不再適用。

2）云原生世界需要數據層邊車

在云原生世界中部署代理的思路是數據層邊車（Sidecar），即采用邊車模式部署的無狀態攔截服務。

在云原生應用程序部署架構中，數據層邊車本質上充當應用程序和數據之間的斷路器，以保護數據存儲庫。

數據層邊車誕生于云中，可以快速部署到客戶環境中，并實時攔截對任何類型數據存儲庫（數據庫、數據管道、數據倉庫等）的所有請求，而不會影響性能和可擴展性。所有的集成和配置，都可以從統一控制平面進行集中管理。

由于數據層邊車便于使用Kubernetes等服務編排工具進行部署，因此企業可以確保其所有存儲庫的數據保護始終處于開啟狀態。

雖然數據層邊車仍然發揮代理的作用，但它的架構是為云原生架構而設計的：

圖4-攔截方式對比：傳統代理 vs. 數據層邊車

如上圖所示，數據層邊車可以采取無狀態方式運行，從而支持橫向擴展和高可用性。

傳統的應用程序代理，需要管理查詢客戶端的會話狀態，以幫助舊數據庫架構應付繁重的工作壓力。
而如今，數據存儲庫能夠自己管理數據層連接，因此數據層邊車可以無狀態運行。于是，可以部署多個邊車，來保護單個數據存儲庫。

3）數據層邊車 vs. 數據庫代理

數據層邊車與數據庫代理相比，具有很多明顯的優勢：

數據架構的先進性：數據層邊車支持現代數據網格架構；而數據庫代理采用中心輻射架構，來自微服務的流量被迫先到達代理，然后才被發送到目標。
云編排平臺的可用性：數據層邊車使用云編排平臺（如Kubernetes）部署；而數據庫代理通常使用未集成到云編排平臺。
流量控制能力：數據層邊車支持全方向流量控制，即包括南北向和東西向；而數據庫代理僅支持南北向。
可觀測能力：數據層邊車與可觀測性技術棧（如ELK、Prometheus等）高度集成，具有豐富的遙測數據；而數據庫代理只有基本的日志數據。
微服務環境的適應性：數據層邊車與基礎設施模板工具（如Terraform、Cloudformation等）一起使用；而數據庫代理不適合高度分布式的微服務環境。
DevOps集成：數據層邊車采取API優先原則，與DevOps工具（如Prometheus、Grafana等）集成，用于日志記錄、監測、可視化、CI/CD；而數據庫代理缺少與DevOps工具的集成。
持續部署：數據層邊車通過與CI/CD工具（如Jenkins X、Spinnaker等）的集成，實現持續部署；而數據庫代理不支持CI/CD。
網絡延遲：數據層邊車采用無狀態的斷路器設計，使得去往數據存儲庫的流量延遲可以忽略不計；而數據庫代理在服務和數據存儲庫之間引入額外控制點，導致不可忽略的網絡延遲。
身份保護：數據層邊車內置了使用mTLS的身份保護，提供了原生的身份認證和授權能力；而數據庫代理缺少對連接服務進行身份認證和授權的原生支持。