Amazon 安全湖中的資料保護 - Amazon Security Lake
靜態加密傳輸中加密

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon 安全湖中的資料保護

AWS 共同責任模型適用於 Amazon Security Lake 中的資料保護。如此模型中所述， AWS 負責保護執行所有 AWS 雲端. 您負責維護在此基礎設施上託管內容的控制權。您也同時負責所使用 AWS 服務 的安全組態和管理任務。如需資料隱私權的詳細資訊，請參閱資料隱私權常見問答集。如需有關歐洲資料保護的相關資訊，請參閱 AWS 安全性部落格上的 AWS 共同的責任模型和 GDPR 部落格文章。

基於資料保護目的，我們建議您使用 AWS IAM Identity Center 或 AWS Identity and Access Management (IAM) 保護 AWS 帳戶 登入資料並設定個別使用者。如此一來，每個使用者都只會獲得授與完成其任務所必須的許可。我們也建議您採用下列方式保護資料：

  • 每個帳戶均要使用多重要素驗證 (MFA)。

  • 使用 SSL/TLS 與 AWS 資源進行通訊。我們需要 TLS 1.2 並建議使用 TLS 1.3。

  • 使用設定 API 和使用者活動記錄 AWS CloudTrail。

  • 使用 AWS 加密解決方案以及其中的所有默認安全控制 AWS 服務。

  • 使用進階的受管安全服務 (例如 Amazon Macie)，協助探索和保護儲存在 Amazon S3 的敏感資料。

  • 如果您在透過命令列介面或 API 存取時需要經 AWS 過 FIPS 140-2 驗證的加密模組，請使用 FIPS 端點。如需有關 FIPS 和 FIPS 端點的更多相關資訊，請參閱聯邦資訊處理標準 (FIPS) 140-2 概觀。

我們強烈建議您絕對不要將客戶的電子郵件地址等機密或敏感資訊，放在標籤或自由格式的文字欄位中，例如名稱欄位。這包括當您使用主控台、API 或 AWS SDK AWS 服務 使用安全湖或其他工作時。 AWS CLI您在標籤或自由格式文字欄位中輸入的任何資料都可能用於計費或診斷日誌。如果您提供外部伺服器的 URL，我們強烈建議請勿在驗證您對該伺服器請求的 URL 中包含憑證資訊。

靜態加密

Amazon 安全湖使用 AWS 加密解決方案安全地存放您的靜態資料。原始安全日誌和事件資料存放在 Security Lake 管理的帳戶中的多租戶 Amazon 簡單儲存服務 (Amazon S3) 儲存貯體中。安全湖使用AWS 擁有的密鑰 AWS Key Management Service （AWS KMS）對此原始數據進行加密。 AWS 擁有的金鑰是一組 AWS KMS 金鑰， AWS 服務 (在本例中為 Security Lake) 擁有並管理，以供多個帳戶使用。 AWS

安全湖對原始日誌和事件資料執行擷取、轉換和載入 (ETL) 工作。處理過的資料會在安全湖服務帳戶中保持加密狀態。

ETL 任務完成後，Security Lake 會在您的帳戶中建立單一租用戶 S3 儲存貯體 (每個已在其中啟用 Security Lake AWS 區域 的儲存貯體各一個儲存貯體)。資料只會暫時存放在多租戶 S3 儲存貯體中，直到 Security Lake 能夠可靠地將資料傳遞到單租戶 S3 儲存貯體。單租用戶值區包含以資源為基礎的政策，可授予 Security Lake 將記錄檔和事件資料寫入值區的權限。若要加密 S3 儲存貯體中的資料，您可以選擇 S3 受管加密金鑰或客戶管理金鑰 (來源 AWS KMS)。這兩個選項都使用對稱加密。

使用 KMS 金鑰加密您的資料

根據預設，安全湖交付到 S3 儲存貯體的資料會使用 Amazon 伺服器端加密使用 Amazon S3 受管加密金鑰 (SSE-S3) 進行加密。若要提供您直接管理的安全層，您可以改為針對安全湖資料使用金AWS KMS 鑰 (SSE-KMS) 的伺服器端加密。

安全湖泊主控台不支援 SSE-KMS。若要搭配安全性湖 API 或 CLI 使用 SSE-KMS，請先建立 KMS 金鑰或使用現有金鑰。您可以將原則附加至金鑰，以決定哪些使用者可以使用金鑰來加密和解密 Security Lake 資料。

如果您使用客戶受管金鑰來加密寫入 S3 儲存貯體的資料，則無法選擇多區域金鑰。對於客戶管理的金鑰，Security Lake 會將CreateGrant要求傳送至，以代表您建立授權 AWS KMS。中的授權 AWS KMS 用於授予安全湖存取客戶帳戶中 KMS 金鑰的權限。

Security Lake 需要授權，才能在下列內部作業中使用您的客戶管理金鑰：

  • 傳送GenerateDataKey要求 AWS KMS 以產生由客戶管理金鑰加密的資料金鑰。

  • 將請RetireGrant求發送到 AWS KMS。當您更新資料湖時，此作業可讓新增至 AWS KMS 金鑰以進行 ETL 處理的授權淘汰。

安全湖不需要Decrypt權限。當授權的金鑰使用者讀取 Security Lake 資料時，S3 會管理解密，授權的使用者能夠以未加密的形式讀取資料。不過，訂閱者需要使用來源資料的Decrypt權限。如需有關訂閱者權限的詳細資訊，請參閱管理安全湖訂戶的資料存取。

如果您想要使用現有的 KMS 金鑰來加密安全湖資料，則必須修改 KMS 金鑰的金鑰原則。金鑰政策必須允許與 Lake Formation 資料湖位置關聯的 IAM 角色使用 KMS 金鑰來解密資料。如需如何變更 KMS 金鑰金鑰金鑰原則的指示，請參閱 AWS Key Management Service 開發人員指南中的變更金鑰政策。

當您建立金鑰原則或使用具有適當權限的現有金鑰原則時，您的 KMS 金鑰可以接受授與要求，讓 Security Lake 存取金鑰。如需建立金鑰原則的指示，請參閱AWS Key Management Service 開發人員指南中的建立金鑰政策。

將下列金鑰原則附加至您的 KMS 金鑰：


{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/ExampleRole"}
  "Action": [
    "kms:CreateGrant",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

使用客戶受管金鑰時所需的 IAM 許可

如需使用 Security Lake 所需建立的 IAM 角色概觀，請參閱入門：先決條件一節。

當您新增自訂來源或訂閱者時，Security Lake 會在您的帳戶中建立 IAM 角色。這些角色旨在與其他 IAM 身分共用。它們允許自訂來源將資料寫入資料湖，而訂閱者則可使用資料湖中的資料。名為的 AWS 受管理策略會AmazonSecurityLakePermissionsBoundary設定這些角色的權限界限。

加密 Amazon SQS 佇列

建立資料湖時，Security Lake 會在委派的安全湖管理員帳戶中建立兩個未加密的 Amazon 簡單佇列服務 (Amazon SQS) 佇列。您應該加密這些佇列以保護您的資料。Amazon 簡單佇列服務提供的預設伺服器端加密 (SSE) 不足。您必須在 AWS Key Management Service (AWS KMS) 中建立客戶受管金鑰來加密佇列，並授予 Amazon S3 服務主體許可以處理加密佇列。如需授與這些許可的指示，請參閱為什麼 Amazon S3 事件通知沒有傳送到使用伺服器端加密的 Amazon SQS 佇列？ 在 AWS 知識中心。

由於安全湖用 AWS Lambda 於支援資料上的擷取、傳輸和載入 (ETL) 任務，因此您還必須授與 Lambda 許可，以管理 Amazon SQS 佇列中的訊息。如需詳細資訊，請參閱AWS Lambda 開發人員指南中的執行角色權限。

傳輸中加密

安全湖會加密 AWS 服務之間傳輸中的所有資料。Security Lake 會使用傳輸層安全性 (TLS) 1.2 加密通訊協定，自動加密所有網路間資料，藉此保護傳輸中的資料 (往返服務)。傳送至安全湖 API 的直接 HTTPS 要求是使用簽AWS 章版本 4 演算法來簽署，以建立安全連線。