Machine-to-machine身分管理 - AWS 方案指引
EC2 執行個體描述檔Amazon Cognito 用戶端憑證授予mTLS 連線IAM Roles Anywhere

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

Machine-to-machine身分管理

Machine-to-machine(M2M) 身分驗證可讓在 AWS 上執行的服務和應用程式安全地彼此通訊，以存取資源和資料。機器身分驗證系統不會使用長期靜態登入資料，而是發出臨時登入資料或字符來識別信任的機器。它們允許精確控制哪些機器可以存取環境的特定部分，而無需人工介入。設計良好的機器身分驗證可透過限制廣泛的憑證公開、動態撤銷許可，以及簡化憑證輪換，來協助改善您的安全狀態。機器身分驗證的典型方法包括 EC2 執行個體描述檔、Amazon Cognito 用戶端憑證授予、相互驗證的 TLS (mTLS) 連線，以及 IAM Roles Anywhere。本節提供有關在 AWS 上實作安全且可擴展的 M2M 身分驗證流程的指引。

EC2 執行個體描述檔

對於您在 Amazon Elastic Compute Cloud (Amazon EC2) 上執行的應用程式或服務需要呼叫 AWS APIs的情況，請考慮使用 EC2 執行個體描述檔。執行個體描述檔可讓在 EC2 執行個體上執行的應用程式安全地存取其他 AWS 服務，而不需要靜態、長期的 IAM 存取金鑰。反之，您應該將 IAM 角色指派給執行個體，以透過執行個體描述檔提供所需的許可。然後，EC2 執行個體可以自動從執行個體描述檔取得臨時安全登入資料，以存取其他 AWS 服務。 

下圖說明此案例。

使用 EC2 執行個體描述檔進行machine-to-machine的身分管理

  1. EC2 執行個體上需要呼叫 AWS API 的應用程式會從執行個體中繼資料項目擷取角色提供的安全登入資料iam/security-credentials/<role-name>。 

  2. 應用程式會收到 AccessKeyId、 SecretAccessKey和秘密字符，可用於簽署 AWS API 請求。

  3. 應用程式會呼叫 AWS API。如果角色允許 API 動作，請求會成功。

若要進一步了解如何搭配 AWS 資源使用臨時憑證，請參閱 IAM 文件中的搭配 AWS 資源使用臨時憑證。

優勢

  • 改善安全性。此方法可避免將長期憑證分發至 EC2 執行個體。登入資料會透過執行個體描述檔暫時提供。 

  • 輕鬆整合。在執行個體上執行的應用程式可以自動取得登入資料，無需任何其他編碼或組態。AWS SDKs會自動使用執行個體描述檔登入資料。

  • 動態許可。您可以更新指派給執行個體描述檔的 IAM 角色，以變更執行個體可用的許可。會自動取得反映更新許可的新登入資料。 

  • 輪換。AWS 會自動輪換臨時憑證，以降低憑證遭到入侵的風險。 

  • 撤銷。您可以從執行個體描述檔中移除角色指派，以立即撤銷登入資料。

設計考量

  • EC2 執行個體只能有一個連接的執行個體描述檔。

  • 使用最低權限 IAM 角色。僅將應用程式所需的許可指派給執行個體描述檔的 IAM 角色。從最低許可開始，並視需要稍後新增更多許可。 

  • 在角色政策中使用 IAM 條件，根據標籤、IP 地址範圍、當日時間等來限制許可。這會限制應用程式可存取的服務和資源。

  • 考慮您需要多少執行個體描述檔。在 EC2 執行個體上執行的所有應用程式都會共用相同的設定檔，並具有相同的 AWS 許可。您可以將相同的執行個體描述檔套用至多個 EC2 執行個體，因此您可以在適當情況下重複使用執行個體描述檔，以減少管理開銷。

  • 監控活動。使用 AWS CloudTrail 等工具來監控使用執行個體設定檔憑證的 API 呼叫。留意可能表示登入資料洩露的異常活動。 

  • 刪除不需要的登入資料。從未使用的執行個體描述檔中移除角色指派，以防止使用登入資料。您可以使用 IAM 存取顧問來識別未使用的角色。 

  • 使用PassRolepermission 來限制使用者在啟動執行個體時可以傳遞給 EC2 執行個體的角色。這可防止使用者執行比已授予使用者更多許可的應用程式。

  • 如果您的架構跨越多個 AWS 帳戶，請考慮一個帳戶中的 EC2 執行個體如何存取另一個帳戶中的資源。適當使用跨帳戶角色，以確保安全存取，而無需嵌入長期 AWS 安全登入資料。

  • 若要大規模管理執行個體描述檔，您可以使用下列其中一個選項：

    • 使用 AWS Systems Manager Automation Runbook 自動化執行個體描述檔與 EC2 執行個體的關聯。這可以在啟動時間或執行個體執行之後完成。

    • 使用 AWS CloudFormation 在建立時以程式設計方式將執行個體描述檔套用至 EC2 執行個體，而不是透過 AWS 主控台進行設定。

  • 使用 VPC 端點從在 EC2 執行個體上執行的應用程式私下連線至支援的 AWS 服務，例如 Amazon S3 和 Amazon DynamoDB 是很好的做法。 

Amazon Cognito 用戶端憑證授予

Amazon Cognitois 是受管客戶身分和存取管理服務。Amazon Cognito 提供符合 OAuth 的身分驗證流程，包括能夠透過用戶端憑證授予類型來驗證機器或應用程式，而非使用者。此授予可讓應用程式直接擷取臨時 AWS 登入資料，以存取 AWS 服務。Amazon Cognito 用戶端登入資料是提供應用程式 AWS 許可的安全方式，無需人工使用者互動。應用程式會將其用戶端 ID 和用戶端秘密呈現給 Amazon Cognito 字符端點。反之，他們會收到存取字符，可用來驗證對各種資源和服務後續的請求。此存取的範圍取決於與用戶端 ID 相關聯的許可。接收請求的應用程式必須透過檢查其簽章、過期時間戳記和對象來驗證字符。進行這些檢查後，應用程式會透過驗證字符中的宣告，來驗證是否允許請求的動作。

下圖說明此方法。

使用 Amazon Cognito 用戶端憑證進行machine-to-machine身分管理

  1. 想要從伺服器請求資源的應用程式 （應用程式用戶端） （資源伺服器） 會從 Amazon Cognito 請求權杖。

  2. Amazon Cognito 使用者集區會傳回存取權杖。

  3. App Client 會將請求傳送至 Resource Server，並包含存取權杖。

  4. Resource Server 會使用 Amazon Cognito 驗證權杖。

  5. 如果驗證成功且允許請求的動作，Resource Server 會以請求的資源回應。

優勢

  • 機器身分驗證。此方法不需要使用者內容或登入。應用程式會直接使用字符進行身分驗證。

  • 短期登入資料。應用程式可以先從 Amazon Cognito 取得存取字符，然後使用有時間限制的存取字符從資源伺服器存取資料。

  • OAuth2 支援。此方法可減少不一致，並有助於應用程式開發，因為它遵循已建立的 OAuth2 標準。

  • 增強安全性。使用用戶端憑證授予可提供增強的安全性，因為用戶端 ID 和用戶端秘密不會傳輸到資源伺服器，不同於 API 金鑰授權機制。只有在呼叫 Amazon Cognito 以取得有時間限制的存取權杖時，才會共用和使用用戶端 ID 和秘密。

  • 透過範圍進行精細存取控制。應用程式可以定義和請求範圍和其他宣告，以限制對特定資源的存取。

  • 稽核線索。您可以使用 CloudTrail 收集的資訊來判斷對 Amazon Cognito 提出的請求、提出請求的 IP 地址、提出請求的人員、提出請求的時間，以及其他詳細資訊。 

設計考量

  • 仔細定義每個用戶端 ID 的存取範圍，並將其限制在所需的最低範圍內。嚴格範圍有助於減少潛在漏洞，並確保服務只能存取必要的資源。 

  • 使用 AWS Secrets Manager 等安全儲存服務來儲存登入資料，以保護用戶端 IDs 和秘密。請勿將登入資料檢查為原始程式碼。

  • 使用 CloudTrail 和 CloudWatch 等工具來監控和稽核字符請求和用量。注意可能表示問題的非預期活動模式。 

  • 定期自動輪換用戶端秘密。每次輪換時，建立新的應用程式用戶端、刪除舊用戶端，以及更新用戶端 ID 和秘密。促進這些輪換，而不會中斷服務通訊。 

  • 對字符端點請求強制執行速率限制，以協助防止濫用和拒絕服務 (DoS) 攻擊。 

  • 在發生安全漏洞時，準備好策略來撤銷權杖。雖然字符是短期的，但遭到入侵的字符應該立即失效。

  • 使用 AWS CloudFormation 以程式設計方式建立 Amazon Cognito 使用者集區和應用程式用戶端，這些用戶端代表需要向其他服務進行身分驗證的機器。

  • 在適當的情況下，快取權杖以提供效能效率和成本最佳化。

  • 確保存取權杖過期符合您組織的安全狀態。

  • 如果您使用自訂資源伺服器，請一律驗證存取權杖，以確保簽章有效、權杖尚未過期，且存在正確的範圍。視需要驗證任何其他宣告。

  • 若要大規模管理用戶端憑證，您可以使用下列其中一個選項：

    • 在單一集中式 Amazon Cognito 執行個體中集中管理所有用戶端登入資料。這可以降低多個 Amazon Cognito 執行個體的管理開銷，並使組態和稽核變得更簡單。不過，請務必規劃擴展並考慮 Amazon Cognito 服務配額。

    • 將用戶端憑證的責任聯合到工作負載帳戶，並允許多個 Amazon Cognito 執行個體。此選項可提升彈性，但相較於集中式選項，可能會增加額外負荷和整體複雜性。

mTLS 連線

相互 TLS (mTLS) 身分驗證是一種機制，允許用戶端和伺服器在透過 TLS 使用憑證進行通訊之前互相驗證。mTLS 的常見使用案例包括具有高法規、物聯網 (IoT) 應用程式和business-to-business(B2B) 應用程式的產業。除了現有的授權選項之外，Amazon API Gateway 目前還支援 mTLS。您可以在自訂網域上啟用 mTLS，以針對區域 REST 和 HTTP APIs進行身分驗證。您可以使用 Bearer、JSON Web Token (JWTs) 或簽署具有 IAM 型授權的請求來授權請求。 

下圖顯示在 EC2 執行個體上執行之應用程式的 mTLS 身分驗證流程，以及在 Amazon API Gateway 上設定的 API。

EC2 執行個體上執行之應用程式的 mTLS 身分驗證

  1. API Gateway 直接向 AWS Certificate Manager (ACM) 請求公開信任的憑證。

  2. ACM 會從其憑證授權單位 (CA) 產生憑證。

  3. 呼叫 API 的用戶端會隨 API 請求提供憑證。

  4. API Gateway 會檢查您已建立的 Amazon S3 信任存放區儲存貯體。此儲存貯體包含您信任用來存取 API 的 X.509 憑證。若要讓 API Gateway 繼續進行請求，憑證的發行者和根 CA 憑證的完整信任鏈必須位於您的信任存放區中。

  5. 如果用戶端的憑證受信任，API Gateway 會核准請求並呼叫 方法。

  6. 相關聯的 API 動作 （在此案例中為 AWS Lambda 函數） 會處理請求並傳回傳送給請求者的回應。

優勢

  • M2M 身分驗證。服務會直接互相驗證，而不是使用共用秘密或字符。這樣就不需要存放和管理靜態登入資料。

  • 竄改保護。TLS 加密可保護服務之間傳輸中的資料。第三方無法讀取或修改通訊。 

  • 輕鬆整合。 mTLS 支援內建在主要程式設計語言和架構中。服務可以在最少的程式碼變更下啟用 mTLS。 

  • 精細許可。服務僅信任特定憑證，允許對允許的發起人進行精細控制。 

  • 撤銷。遭入侵的憑證可以立即撤銷，使其不再受信任，防止進一步存取。 

設計考量

  • 當您使用 API Gateway 時：

    • 根據預設，用戶端可以使用 API Gateway 為 API 產生的execute-api端點來呼叫您的 API。若要確保用戶端只能透過搭配 mTLS 使用自訂網域名稱來存取您的 API，請停用此預設端點。若要進一步了解，請參閱 API Gateway 文件中的停用 REST API 的預設端點。

    • API Gateway 不會驗證憑證是否已撤銷。

    • 若要設定 REST API 的 mTLS，您必須使用 API 的區域性自訂網域名稱，最低 TLS 版本為 1.2。私有 APIs 不支援 mTLS。

  • 您可以從自己的 CA 發行 API Gateway 憑證，或從 AWS Private Certificate Authority 匯入憑證。

  • 建立程序以安全地發行、分發、續約和撤銷服務憑證。盡可能自動化發行和續約。如果 M2M 通訊的一側是 API 閘道，您可以與 AWS Private CA 整合。

  • 保護私有 CA 的存取。入侵 CA 會危及其發行的所有憑證的信任。

  • 安全地存放私有金鑰，並與憑證分開存放。定期輪換金鑰，在遭到入侵時限制影響。

  • 當不再需要憑證或憑證遭到入侵時，立即撤銷憑證。將憑證撤銷清單分發至 服務。 

  • 可能的話，發行僅供特定用途或資源使用的憑證，以便在其公用程式遭到入侵時加以限制。

  • 針對 CA 或憑證撤銷清單 (CRL) 基礎設施的憑證過期和中斷制定應變計畫。 

  • 監控您的系統是否有憑證故障和中斷。請留意可能表示問題的失敗峰值。

  • 如果您使用 AWS Certificate Manager (ACM) 搭配 AWS Private CA，您可以使用 AWS CloudFormation 以程式設計方式請求公有和私有憑證。

  • 如果您使用的是 ACM，請使用 AWS Resource Access Manager (AWS RAM) 將憑證從安全帳戶共用到工作負載帳戶。

IAM Roles Anywhere

當機器或系統需要連線到 AWS 服務，但不支援 IAM 角色時，我們建議您使用 IAM Roles Anywhere for M2M 身分管理。IAM Roles Anywhere 是 IAM 的延伸，它使用公有金鑰基礎設施 (PKI)，透過使用臨時安全登入資料授予對工作負載的存取權。您可以使用可透過 CA 或 AWS Private CA 發行的 X.509 憑證，在 CA 和 IAM Roles Anywhere 之間建立信任錨點。如同 IAM 角色，工作負載可以根據連接到角色的許可政策來存取 AWS 服務。 

下圖顯示如何使用 IAM Roles Anywhere 將 AWS 與外部資源連線。

使用 IAM Roles Anywhere machine-to-machine身分管理

  1. 您可以建立信任錨點，在 AWS 帳戶與向內部部署工作負載發行憑證的 CA 之間建立信任。憑證是由您註冊為 IAM Roles Anywhere 中信任錨點 （信任根） 的 CA 發行。CA 可以是現有公有金鑰基礎設施 (PKI) 系統的一部分，也可以是您使用 AWS Private Certificate Authority 建立並使用 ACM 管理的 CA。在此範例中，我們使用 ACM。

  2. 您的應用程式會向 IAM Roles Anywhere 提出身分驗證請求，並傳送其公有金鑰 （在憑證中編碼） 和由對應私有金鑰簽署的簽章。您的應用程式也會指定要在請求中擔任的角色。

  3. 當 IAM Roles Anywhere 收到請求時，會先使用公有金鑰驗證簽章，然後驗證憑證是否由信任錨點發出。在這兩種驗證都成功後，您的應用程式會經過身分驗證，而 IAM Roles Anywhere 會透過呼叫 AWS Security Token Service (AWS STS)，為請求中指定的角色建立新的角色工作階段。

  4. 您可以使用 IAM Roles Anywhere 提供的憑證協助程式工具，來管理使用憑證建立簽章的程序，並呼叫端點以取得工作階段憑證。工具會以標準 JSON 格式將登入資料傳回給呼叫程序。

  5. 透過在 IAM 和 PKI 之間使用此橋接信任模型，內部部署工作負載會使用這些臨時登入資料 （存取金鑰、私密金鑰和工作階段字符），擔任 IAM 角色來與 AWS 資源互動，而不需要長期登入資料。您也可以使用 AWS CLI 或 AWS SDKs來設定這些登入資料。

優勢

  • 無永久登入資料。應用程式不需要具有廣泛許可的長期 AWS 存取金鑰。 

  • 精細存取。政策會決定特定實體可擔任的 IAM 角色。 

  • 了解內容的角色。您可以根據已驗證實體的詳細資訊自訂角色。

  • 撤銷。撤銷信任許可會立即封鎖實體擔任角色。

設計考量

  • 伺服器必須能夠支援憑證型身分驗證。 

  • 最佳實務是鎖定要使用的信任政策aws:SourceArn，或aws:SourceAccount鎖定已設定信任錨點的帳戶。 

  • 主體標籤會從憑證詳細資訊轉送。這些包括通用名稱 (CN)、主體替代名稱 (SAN)、主體和發行者。

  • 如果您使用的是 ACM，請使用 AWS RAM 將憑證從安全帳戶共用到工作負載帳戶。

  • 使用作業系統 (OS) 檔案系統許可來限制擁有使用者的讀取存取權。

  • 切勿將金鑰檢查為來源控制。將它們與原始程式碼分開存放，以降低意外將它們包含在變更集中的風險。如果可能，請考慮使用安全的儲存機制。

  • 請確定您有輪換和撤銷憑證的程序。