云平臺為客戶提供技術(shù)和工具來保護他們的資產(chǎn)，包括最重要的資產(chǎn)——數(shù)據(jù)。在撰寫本文時，關(guān)于誰負責保護數(shù)據(jù)存在很多爭論，但一般來說，作為數(shù)據(jù)合法所有者的公司必須確保它符合（國際）法律和標準。在英國，公司必須遵守數(shù)據(jù)保護法，而在歐盟，所有公司都必須遵守通用數(shù)據(jù)保護條例( GDPR )。

數(shù)據(jù)保護法和 GDPR 都涉及隱私。國際標準 ISO/IEC 27001:2013 和 ISO/IEC 27002:2013 是涵蓋數(shù)據(jù)保護的安全框架。這些標準規(guī)定所有數(shù)據(jù)都必須有一個所有者，以便明確誰負責保護數(shù)據(jù)。簡而言之，在云平臺上存儲數(shù)據(jù)的公司仍然擁有該數(shù)據(jù)，因此有責任保護數(shù)據(jù)。

為了保護云平臺上的數(shù)據(jù)，企業(yè)必須關(guān)注兩個方面：

• 加密
• 訪問，使用身份驗證和授權(quán)

這些只是安全問題。企業(yè)還需要能夠確保可靠性。他們需要確保，例如，密鑰保存在數(shù)據(jù)本身以外的另一個地方，即使由于技術(shù)原因無法訪問密鑰保管庫，仍然有辦法以安全的方式訪問數(shù)據(jù)。工程師不能簡單地帶著磁盤或 USB 設(shè)備開車到數(shù)據(jù)中心來檢索數(shù)據(jù)。Azure、AWS 和 GCP 如何解決這個問題？我們將在下一節(jié)中對此進行探討。

在 Azure 中使用加密和密鑰

在 Azure 中，用戶將數(shù)據(jù)寫入 blob 存儲。存儲由自動生成的存儲密鑰保護。存儲密鑰保存在存儲本身所在的子網(wǎng)之外的密鑰保管庫中。但密鑰保管庫不僅僅存儲密鑰。它還通過輪換定期重新生成密鑰，提供共享訪問簽名( SAS ) 令牌來訪問存儲帳戶。概念如下圖所示：

圖 1：Azure Key Vault 的概念

Microsoft Azure 強烈推薦使用 Key Vault 來管理加密密鑰。加密是 Azure 中的一個復(fù)雜域，因為 Microsoft 在 Azure 中提供了多種加密服務(wù)?？梢允褂?BitLocker 或適用于 Linux 系統(tǒng)的 DM-Crypt 對 Azure 中的磁盤進行加密。使用 Azure，存儲服務(wù)加密( SSE ) 數(shù)據(jù)可以在存儲到 blob 之前自動加密。SSE 使用 AES-256。對于 Azure SQL 數(shù)據(jù)庫，Azure 使用透明數(shù)據(jù)加密( TDE )為靜態(tài)數(shù)據(jù)提供加密，它還使用 AES-256 和三重數(shù)據(jù)加密標準( 3DES )。

在 AWS 中使用加密和密鑰

與 Azure 一樣，AWS 也有一個稱為密鑰管理服務(wù)( KMS ) 的密鑰保管庫解決方案。原理也很相似，主要是使用服務(wù)端加密。服務(wù)器端意味著要求云提供商在數(shù)據(jù)存儲在該云平臺內(nèi)的解決方案之前對數(shù)據(jù)進行加密。當用戶檢索數(shù)據(jù)時，數(shù)據(jù)被解密。另一種選擇是客戶端，客戶在存儲數(shù)據(jù)之前負責加密過程。

AWS 中的存儲解決方案是 S3。如果客戶在 S3 中使用服務(wù)器端加密，AWS 會提供 S3 托管密鑰 (SSE-S3)。這些是使用主密鑰加密的唯一數(shù)據(jù)加密密鑰( DEK )，即密鑰加密密鑰( KEK )。主密鑰不斷地重新生成。對于加密，AWS 使用 AES-256。

AWS 通過客戶主密鑰( CMK )提供一些附加服務(wù)。這些密鑰也在 KMS 中進行管理，提供審計跟蹤以查看誰在何時使用了密鑰。最后，可以選擇使用客戶提供的密鑰( SSE-C )，客戶自己管理密鑰。AWS中使用CMK的KMS概念如下圖所示：

圖 2：在 AWS KMS 中存儲 CMK 的概念

Azure 和 AWS 都在加密方面實現(xiàn)了很多自動化。他們對關(guān)鍵服務(wù)使用不同的名稱，但主要原則非常相似。這對 GCP 也很重要，這將在下一節(jié)中討論。

在 GCP 中使用加密和密鑰

在 GCP 中，存儲在 Cloud Storage 中的所有數(shù)據(jù)默認情況下都是加密的。就像 Azure 和 AWS 一樣，GCP 提供了管理密鑰的選項。這些可以由 Google 或客戶提供和管理。密鑰存儲在Cloud Key Management Service中。如果客戶選擇自己提供和/或管理密鑰，這些將作為 GCP 提供的標準加密之上的附加層。這在客戶端加密的情況下也是有效的——數(shù)據(jù)以加密格式發(fā)送到 GCP，但 GCP 仍然會執(zhí)行自己的加密過程，就像服務(wù)器端加密一樣。GCP Cloud Storage 使用 AES-256 加密數(shù)據(jù)。

加密過程本身類似于 AWS 和 Azure，并使用 DEK 和 KEK。當客戶將數(shù)據(jù)上傳到 GCP 時，數(shù)據(jù)會被分成塊。這些塊中的每一個都使用 DEK 加密。這些 DEK 被發(fā)送到 KMS，在那里生成主密鑰。概念如下圖所示：

圖 3：GCP 中的數(shù)據(jù)加密概念

在OCI和阿里云實現(xiàn)加密

與指定的主要公共云一樣，OCI 提供使用存儲在 OCI 密鑰管理服務(wù)中的加密密鑰加密靜態(tài)數(shù)據(jù)的服務(wù)。公司也可以使用自己的密鑰，但這些密鑰必須符合密鑰管理互操作性協(xié)議( KMIP )。加密過程就像其他云一樣。首先，創(chuàng)建一個主加密密鑰，用于加密和解密所有數(shù)據(jù)加密密鑰。請記住，我們之前討論過這些 KEK 和 DEK。可以從 OCI 控制臺、命令行界面或 SDK 創(chuàng)建密鑰。

數(shù)據(jù)可以加密并存儲在塊存儲卷、對象存儲或數(shù)據(jù)庫中。顯然，OCI 也建議將密鑰輪換作為最佳實踐。

客戶自己生成的密鑰保存在 OCI Vault 中，并存儲在彈性集群中。

阿里云步驟相同。從控制臺或 CLI 創(chuàng)建密鑰，然后將加密數(shù)據(jù)存儲在阿里云提供的一種存儲服務(wù)中：OSS、Apsara File Storage 或數(shù)據(jù)庫。

到目前為止，我們一直在關(guān)注數(shù)據(jù)本身、數(shù)據(jù)存儲、數(shù)據(jù)加密以及數(shù)據(jù)訪問安全。架構(gòu)師的任務(wù)之一是將其轉(zhuǎn)化為原則。這是一項需要與 CIO 或首席信息安全官( CISO )一起執(zhí)行的任務(wù)。最低限度的原則如下：

• 加密傳輸中的所有數(shù)據(jù)（端到端）
• 對所有關(guān)鍵業(yè)務(wù)或敏感數(shù)據(jù)進行靜態(tài)加密
• 應(yīng)用 DLP 并有一個矩陣，清楚地顯示什么是關(guān)鍵和敏感數(shù)據(jù)以及需要保護到什么程度。

最后，開發(fā)用例并測試數(shù)據(jù)保護場景。創(chuàng)建數(shù)據(jù)模型、定義 DLP 矩陣并應(yīng)用數(shù)據(jù)保護控制后，組織必須測試用戶是否可以創(chuàng)建和上傳數(shù)據(jù)，以及其他授權(quán)用戶可以對該數(shù)據(jù)執(zhí)行哪些操作——讀取、修改或刪除。這不僅適用于用戶，也適用于其他系統(tǒng)和應(yīng)用程序中的數(shù)據(jù)使用。因此，數(shù)據(jù)集成測試也是必須的。

數(shù)據(jù)策略和加密很重要，但有一件事不容忽視：加密并不能保護公司免受錯誤放置的身份和訪問管理( IAM ) 憑據(jù)的影響。認為數(shù)據(jù)因為經(jīng)過加密和安全存儲而受到充分保護會給人一種錯誤的安全感。安全真正始于身份驗證和授權(quán)。