近年來，由于云計算與云存儲具有一定的廉價性和可擴展性，云數據倉庫（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
