Amazon Verified Permissions 中的資料保護

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

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

• 建議您以下列方式保護您的資料：

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

  • 使用 SSL/TLS 與 AWS 資源通訊。我們需要 TLS 1.2。

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

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

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

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

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

• 您的動作名稱不應包含任何敏感資訊。

• 我們也強烈建議您一律為實體 （資源和主體） 使用唯一、不可變和不可重複使用的識別符。在測試環境中，您可以選擇使用簡單的實體識別符，例如 jane或 bob 做為類型 之實體的名稱User。不過，在生產系統中，基於安全考量，您使用無法重複使用的唯一值至關重要。我們建議您使用通用唯一識別碼 (UUIDs等值。例如，請考慮離開公司的jane使用者。稍後，您會讓其他人使用名稱 jane。該新使用者會自動存取仍參考 的政策授予的所有內容User::"jane"。已驗證的許可和 Cedar 無法區分新使用者和先前的使用者。

  本指南同時適用於主體和資源識別符。一律使用保證唯一且永遠不會重複使用的識別符，以確保您不會因為政策中存在舊識別符而意外授予存取權。

• 請確定您提供用來定義 Long和 Decimal值的字串，在每種類型的有效範圍內。此外，請確保您使用任何算術運算子不會導致值超出有效範圍。如果超過範圍，操作會導致溢位例外狀況。導致錯誤的政策會被忽略，這表示許可政策可能會意外地無法允許存取，或禁止政策可能會意外地無法封鎖存取。

資料加密

Amazon Verified Permissions 會使用 自動加密所有客戶資料，例如政策 AWS 受管金鑰，因此不需要也不支援使用客戶受管金鑰。