云平臺為客戶提供技術(shù)和工具來保護他們的資產(chǎn)，包括最重要的資產(chǎn)——數(shù)據(jù)。在撰寫本文時，關(guān)于誰負(fù)責(zé)保護數(shù)據(jù)存在很多爭論，但一般來說，作為數(shù)據(jù)合法所有者的公司必須確保它符合（國際）法律和標(biāo)準(zhǔn)。在英國，公司必須遵守數(shù)據(jù)保護法，而在歐盟，所有公司都必須遵守通用數(shù)據(jù)保護條例(GDPR)。
數(shù)據(jù)保護法和 GDPR 都涉及隱私。國際標(biāo)準(zhǔn) ISO/IEC 27001:2013 和 ISO/IEC 27002:2013 是涵蓋數(shù)據(jù)保護的安全框架。這些標(biāo)準(zhǔn)規(guī)定所有數(shù)據(jù)都必須有一個所有者，以便明確誰負(fù)責(zé)保護數(shù)據(jù)。簡而言之，在云平臺上存儲數(shù)據(jù)的公司仍然擁有該數(shù)據(jù)，因此有責(zé)任保護數(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ù)加密標(biāo)準(zhǔn)(3DES)。
在 AWS 中使用加密和密鑰與 Azure 一樣，AWS 也有一個稱為密鑰管理服務(wù)(KMS) 的密鑰保管庫解決方案。原理也很相似，主要是使用服務(wù)端加密。服務(wù)器端意味著要求云提供商在數(shù)據(jù)存儲在該云平臺內(nèi)的解決方案之前對數(shù)據(jù)進行加密。當(dāng)用戶檢索數(shù)據(jù)時，數(shù)據(jù)被解密。另一種選擇是客戶端，客戶在存儲數(shù)據(jù)之前負(fù)責(zé)加密過程。
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ù)默認(rèn)情況下都是加密的。就像 Azure 和 AWS 一樣，GCP 提供了管理密鑰的選項。這些可以由 Google 或客戶提供和管理。密鑰存儲在Cloud Key Management Service中。如果客戶選擇自己提供和/或管理密鑰，這些將作為 GCP 提供的標(biāo)準(zhǔn)加密之上的附加層。這在客戶端加密的情況下也是有效的——數(shù)據(jù)以加密格式發(fā)送到 GCP，但 GCP 仍然會執(zhí)行自己的加密過程，就像服務(wù)器端加密一樣。GCP Cloud Storage 使用 AES-256 加密數(shù)據(jù)。
加密過程本身類似于 AWS 和 Azure，并使用 DEK 和 KEK。當(dāng)客戶將數(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ù)的影響。認(rèn)為數(shù)據(jù)因為經(jīng)過加密和安全存儲而受到充分保護會給人一種錯誤的安全感。安全真正始于身份驗證和授權(quán)。
標(biāo)簽：
