Amazon SQS 的安全最佳實務 - Amazon Simple Queue Service

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

Amazon SQS 的安全最佳實務

AWS 為 Amazon SQS 提供許多安全功能,您應該在自己的安全政策中檢閱這些功能。以下是 Amazon SQS 的預防性安全最佳實務。

注意

針對常見使用案例和實作提供具體的實作指導。我們建議您在特定使用案例、架構和威脅模型的內容中檢視這些最佳實務。

確定佇列無法公開存取

除非您明確要求網際網路上的任何人都能夠讀取或寫入 Amazon SQS 佇列,否則您應確保您的佇列無法公開存取 (世界上的每個人或任何經過驗證的 AWS 使用者都可以存取)。

  • 避免建立 Principal 設定為 "" 的政策。

  • 避免使用萬用字元 (*)。請改為命名特定使用者或使用者。

實作最低權限存取

當您授與許可時,您可決定接收許可的人員、許可適用的佇列,以及您要對這些佇列允許的特定 API 動作。對於降低安全性風險及降低錯誤或惡意意圖的影響而言,實作最低權限非常重要。

遵循授與最低權限的標準安全建議。也就是說,只授與執行特定工作所需的許可。您可以使用安全政策的組合來實作此動作。

Amazon SQS 會使用生產者與消費者模型,並需要三種類型的使用者帳戶存取權:

  • 管理員 – 建立、修改和刪除佇列的存取權。管理員也會控制佇列政策。

  • 生產者 – 傳送訊息至佇列的存取權。

  • 消費者 – 從佇列接收和刪除訊息的存取權。

如需詳細資訊,請參閱下列章節:

針對需要 Amazon SQS 存取權的應用程式和 AWS 服務使用 IAM 角色

若要讓應用程式或 AWS 服務 (例如 Amazon EC2) 存取 Amazon SQS 佇列,他們必須在 AWS API 請求中使用有效的 AWS 登入資料。由於這些登入資料不會自動輪換,因此您不應將 AWS 登入資料直接儲存在應用程式或 EC2 執行個體中。

反之,您應使用 IAM 角色來為需存取 Amazon SQS 的應用程式和服務管理暫時性登入資料。使用角色時,您不必將長期登入資料 (例如使用者名稱、密碼和存取金鑰) 分發到 EC2 執行個體或 AWS 服務 (例如 AWS Lambda. 相反地,該角色會提供應用程式在呼叫其他 AWS 資源時可以使用的暫時權限。

如需詳細資訊,請參閱 IAM 角色常見的角色方案:使用者、應用程式和服務中的 IAM 使用者指南

實作伺服器端加密

若要減輕資料外洩問題,請使用靜態加密,並利用與訊息儲存在不同位置的金鑰來加密訊息。伺服器端加密 (SSE) 會提供靜態資料加密。Amazon SQS 會在儲存資料時於訊息層級進行加密,並在您存取訊息時為您進行解密。SSE 使用中管理的金鑰 AWS Key Management Service。只要您有驗證請求並具備存取許可,存取加密資料與未加密資料的方式並無不同。

如需詳細資訊,請參閱Amazon 中的靜態加密 SQSAmazon SQS 密鑰管理

強制加密傳輸中的資料

如果沒有 HTTPS (TLS),基於網絡的攻擊者可以竊聽網絡流量或操縱它,使用類似的攻擊。 man-in-the-middle使用佇列政策中的 aws:SecureTransport 條件,只允許透過 HTTPS (TLS) 加密的連線。

考慮使用 VPC 端點來存取 Amazon SQS

如果您的佇列必須能夠與之互動,但絕對不能公開於網際網路,請使用 VPC 端點,將佇列存取權限制為特定 VPC 內的主機。您可以使用佇列政策,從特定的 Amazon VPC 端點或特定的 VPC 控制對佇列的存取權。

Amazon SQS VPC 端點會提供兩種控制訊息存取的方式:

  • 您可以控制經由特定 VPC 端點允許的請求、使用者或群組。

  • 您可以使用佇列政策,控制哪些 VPC 或 VPC 端點可存取您的佇列。

如需詳細資訊,請參閱Amazon 的 Amazon Virtual Private Cloud 端端點 SQS為 Amazon 創建 Amazon VPC 端點策略 SQS