近年來,由于云計算與云存儲具有一定的廉價性和可擴展性,云數據倉庫(Cloud data warehouses,CDW)得到了廣泛的應用并飛速發展。同時,CDW不但能夠存儲比本地數據庫更多的數據,而且可以通過現代化數據管道,簡化了ETL的各種流程,因此許多企業都開始用它來開展大規模的數據分析業務。
其實,早在十多年前,公有云服務提供商便開始以平臺即服務(PaaS)的模式發布云端數據倉庫了。其中,Google的BigQuery和Amazon的Redshift都能夠讓組織在幾分鐘內,完成對CDW的部署,而無需額外安裝數據庫,或配置服務器。通過將數據從本地遷移到CDW(已被認為是現代數據棧的一部分),數據消費者和生產者在數據的訪問過程中,獲得了極大的便利性。在某些CDW平臺中,企業甚至不需要DBA去維護數據的索引。其整個數據庫的管理工作會變得異常簡單。
當然,此類技術也面臨著包括敏感數據的泄漏、隱私的暴露、數據結構的治理,以及滿足合規等方面的挑戰。在本文中,我們將和您討論在將數據遷移到CDW過程中的各種安全注意事項。
遷移到云數據倉庫后的安全性問題
我們之所以要將數據遷移到云端數據倉庫中,就是為了允許更多的用戶去訪問我們的數據,并能夠從數據中創造更大的價值。這就是業界常說的 “數據民主化(data democratization)”。與此同時,由于CDW是在所謂的“共享責任模型”上實現的,因此云服務提供商需要承擔諸如:物理安全、操作系統安全和補丁、甚至是維護基本數據庫軟件等責任。而這些并非租戶企業所需要參與的。因此,他們應當將注意力放在云端的數據安全上。這些往往不只是企業中安全專業團隊的責任,而需要數據工程師,乃至業務團隊的參與,需要大家共同制定和踐行相關的安全策略。
加密
租戶企業必須確保存儲的靜態數據、以及連接的傳輸中數據,都得到必要的加密。從安全的角度來說,這些不但對于降低中間人(MITM)的攻擊、肆意訪問到存儲數據的風險是必需的;而且對于滿足合規性,也是非常必要的。在一些主流的CDW平臺中,它們會在默認情況下,對靜態和傳輸中的數據進行加密。而其他的平臺,則需要您手動配置對存儲數據的加密,并在訪問數據的過程中,強制采用加密協議。
網絡訪問控制
在大多數情況下,設置網絡訪問策略是降低CDW風險級別的一種簡單而有效的方法。有些平臺在默認情況下,根本沒有公共互聯網的訪問權限;而在某些平臺中,您需要額外配置網絡訪問規則。而一些特定的應用場景中,您還需要為特定的用戶或用戶組,設置更加具體的網絡訪問策略。下面是以Snowflake為例,制定的網絡訪問策略,并需要將其應用到特定的用戶上:
CREATE OR REPLACE NETWORK POLICY us_employees
ALLOWED_IP_LIST =( '1.1.1.0/24', '2.2.2.0/24', '3.3.4.5' )
BLOCKED_IP_LIST =( '1.1.1.128', '2.2.2.128' )
COMMENT = 'US employees offices, excluding guest WiFi gateways';
/* Assigning the policy to a user */
ALTER user us_marketing_analysts SET NETWORK_POLICY=US_EMPLOYEES;
驗證
CDW對于用戶的身份驗證,會因平臺而異。例如,并非所有平臺都支持在BI(業務智能化)工具中,將OAuth用于個人用戶的身份驗證。此外,有些平臺會趨向采取“避重就輕”的途徑,繞開那些最適合達到安全效果的身份驗證方式。例如,在許多公司中,明明應用程序可以使用更強的、基于密鑰(PKI)的身份驗證方式,它們卻僅使用“用戶名+密碼”去連接數據倉庫。對此,數據和安全團隊(有時還應包括IT團隊)需要通過協作,來解決并確保有明確的安全指導策略,來具體規定應該使用哪種身份驗證的類型。例如:應盡可能地使用與身份提供商(Identity Provider)相集成的方式,讓用戶遵守組織已有的雙因素身份驗證策略。
授權
在數據倉庫安全性中,最難管控的部分莫過于授權了。此處的授權是指:一旦用戶通過了數據倉庫的身份驗證,就應該準確授予他們可以訪問哪些數據、以及在什么級別上進行訪問。不同的CDW有著不同的授權機制。例如,Snowflake具有嚴格的、基于角色的訪問控制模型(RBAC),而Amazon的Redshift最近也推出了自己的RBAC模型。
總的說來,CDW在授權過程中往往面臨著如下安全挑戰:
- 由于用戶量和數據種類比較龐大,因此許多用戶往往需要頻繁地更改其數據訪問的相關權限,這就會給數據工程團隊造成工作量上的壓力。
- 企業通常會忽略執行“撤銷對用戶不再需要的數據訪問權限”的流程。
- 難以出于合規性和安全性的通用需求,及時、準確地跟蹤用戶對于敏感數據的訪問。
- 用戶經常被授予過多的訪問權限。
在CDW運行一段時間后,如果我們無法恪守明確的訪問規則,他們的訪問權限就會很快變得復雜、且難以管理。對此,企業需要啟用自動化的數據訪問授權、創建和執行明確的安全策略,以及應用到不同數據倉庫環境的安全訪問規則。
細粒度的訪問控制
在云數據倉庫的語境中,我們認為針對諸如:表、視圖、模式、以及數據庫的訪問控制,屬于“粗粒度”對象管理。除此之外,我們還會碰到居多“細粒度”管理的安全需求。也就是說,我們需要對于某些用戶是否能夠僅訪問表中的特定行(即,行級別安全性),以及根據用戶或其角色,對數據的操作能力予以動態屏蔽。同樣,在此方面,不同的CDW也具有不同的能力。在某些平臺中,您可以通過使用現成的函數和視圖,來設計并實現此類策略;而在其他的平臺上,您可能需要自行創建策略,并將其應用于數據對象上。當然,如果數據量和類型過大的話,則需要通過自動化控制機制,來實現大規模數據訪問的全覆蓋。
審計和監控
審計和監控既是數據訪問平臺內部安全的重要組成部分,也是合規性的基本要求。同樣,不同的CDW提供不同級別的審計日志,以及啟用它們的不同步驟。例如,在Snowflake中,數據訪問日志是開箱即用的snowflake.account_usage架構(可使用SQL的選擇查詢),而對于Amazon的Redshift,您需要通過配置查詢日志,以導出到S3存儲桶。
優先級和保護敏感數據
和過去保存在本地的數據類似,在確保CDW的數據安全性時,我們離不開與業務、運維團隊的協作,以了解企業的敏感數據到底被存放在哪里,并且根據實際情況排定資源的安全優先級。
下面,我總結了當前四大主流的CDW平臺,在上面提到的各項安全控制要點上的顯著特點:
AMAZON REDSHIFT | SNOWFLAKE | AZURE SYNAPSE | GOOGLE BIGQUERY? | |
網絡訪問控制 | 已作為AWS賬戶網絡策略的一部分 | 使用SQL予以定義 | 已作為Azure中Synapse工作區配置的一部分 | 已在G-Suite管理面板中定義 |
訪問控制 | 已使用SQL配置,對用戶、組或角色進行授權 | 已使用SQL配置,僅使用角色授權(嚴格的RBAC) | 使用Azure(用于添加用戶)和SQL(用于授予對特定對象的訪問權限)對用戶或角色進行配置 | 使用GCP的UI/API來配置,以授予用戶或組的訪問權限 |
細粒度的安全性 | 作為平臺一部分,實現列級訪問 | 作為平臺一部分,實現動態屏蔽和行級策略 | 作為平臺一部分,實現動態屏蔽、列級和行級策略 | 作為平臺一部分,實現列級和行級策略 |
審計和監控 | 提供將審計日志導出到S3所需的配置 | 虛擬數據庫模式(snowflake.account_usage)中的自動訪問和查詢日志 | 提供啟用對Azure存儲的審核所需的配置 | 作為GCP一部分的自動訪問和查詢日志(可以使用REST API實現拉取) |
小結
云數據倉庫能夠使數據團隊更加專注于增加本企業數據的驅動價值。而隨著更多的用戶能夠訪問更多、且不斷變化的海量數據,我們對數據訪問的安全性保護也需要越來越重視。因此,在將數據遷移至CDW之前,我們需要對平臺的安全性做好評估。而在完成遷移并開始使用CDW平臺時,安全團隊既要能夠使用由平臺提供的安全管控措施,又要善于使用其他安全元素(如,BI工具或數據訪問處理方法),來補齊CDW的本身不足。
當然,無論您選擇了上面提到的何種CDW(可能不僅會考慮平臺的安全能力,也會綜合考量各種其他因素),請通過明確的安全策略、數據和安全團隊之間的緊密協作、以及持續降低數據風險的方案,實現對企業數據的妥善管理。
譯者介紹
陳峻 (Julian Chen),51CTO社區編輯,具有十多年的IT項目實施經驗,善于對內外部資源與風險實施管控,專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式,分享前沿技術與新知;經常以線上、線下等方式,開展信息安全類培訓與授課。
原文標題:??Data Security Considerations in Cloud Data Warehouses??,作者:Ben Herzberg