

# SEC 2. 如何管理人員和機器的身分驗證？
<a name="sec-02"></a>

處理安全的 AWS 工作負載時，您需要管理兩種身分類型。
+  **真人身分：**需要存取您的 AWS 環境和應用程式的真人身分可分為三個群組：人力資源、第三方和使用者。

   *人力資源*群組包括管理員、開發人員，以及身為您組織成員的操作人員。他們需要存取權來管理、建置和操作您的 AWS 資源。

   *第三方*是外部協作者，例如承包商、廠商或合作夥伴。他們與您組織互動的過程中，會需要與 AWS 資源互動。

   *使用者*是您應用程式的取用者。他們透過 Web 瀏覽器、用戶端應用程式、行動應用程式或互動式命令列工具存取您的 AWS 資源。
+  **機器身分︰**您的工作負載應用程式、操作工具和元件需要身分才能向 AWS 服務發出請求，例如讀取資料。這些身分也包括您 AWS 環境 (如 Amazon EC2 執行個體或 AWS Lambda 函數) 內執行的機器。您也可以管理需要存取您 AWS 環境之外部對象的機器身分，或 AWS 外部的機器。

**Topics**
+ [

# SEC02-BP01 使用強式登入機制
](sec_identities_enforce_mechanisms.md)
+ [

# SEC02-BP02 使用暫時憑證
](sec_identities_unique.md)
+ [

# SEC02-BP03 安全地儲存和使用機密
](sec_identities_secrets.md)
+ [

# SEC02-BP04 仰賴集中式身分提供者
](sec_identities_identity_provider.md)
+ [

# SEC02-BP05 定期稽核和輪換憑證
](sec_identities_audit.md)
+ [

# SEC02-BP06 採用使用者群組和屬性
](sec_identities_groups_attributes.md)

# SEC02-BP01 使用強式登入機制
<a name="sec_identities_enforce_mechanisms"></a>

 登入 (使用登入憑證進行驗證) 可預防當沒有使用多重要素驗證 (MFA) 等機制時的風險，尤其是在登入憑證遭到意外暴露或輕易被猜出的情況下。使用強式登入機制透過要求 MFA 和強式密碼政策來降低這些風險。

 **預期成果：**透過對 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 使用者、[AWS 帳戶 根使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)、[AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 和協力廠商身分提供者使用強式登入機制，來降低 AWS 中意外存取憑證的風險。這意味著要求使用 MFA，強制強式密碼政策，以及偵測異常的登入行為。

 **常見的反模式：**
+  沒有為您的身分強制強式密碼政策，包括複雜密碼和 MFA。
+  在不同使用者之間共用相同的憑證。
+  沒有針對可疑的登入使用偵測控制。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 真人身分可採用數種方法來登入 AWS。AWS 最佳實務是依賴使用聯合 (在 AWS IAM 與集中式 IdP 之間的直接 SAML 2.0 聯合或使用 AWS IAM Identity Center) 的集中式身分提供者，向 AWS 進行身分驗證。在這種情況下，以您的身分提供者或 Microsoft Active Directory 建立安全的登入程序。

 當您第一次開啟 AWS 帳戶 時，是從 AWS 帳戶 根使用者開始。您應僅使用帳戶根使用者來設定使用者的存取權 (以及[需要根使用者的任務](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html))。務必在開啟 AWS 帳戶 之後，立即為帳戶根使用者開啟多重要素驗證 (MFA)，並使用 [AWS 最佳實務指南](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html)來保護根使用者。

 AWS IAM Identity Center 是專為員工使用者所設計，您可以在服務內建立和管理使用者身分，並使用 MFA 保護登入程序。AWS另一方面，Cognito 是專為客戶身分和存取管理 (CIAM) 所設計，它為應用程式中的外部使用者身分提供使用者集區和身分提供者。

 如果您在 AWS IAM Identity Center 中建立使用者，請保護該服務中的登入程序，並[開啟 MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)。對於您應用程式中的外部使用者身分，您可以使用 [Amazon Cognito 使用者集區](https://docs.aws.amazon.com/cognito/index.html)並保護該服務中的登入程序，或透過 Amazon Cognito 使用者集區支援的其中一個身分提供者。

 此外，對於 AWS IAM Identity Center 中的使用者，您可以在將存取權授予 AWS 資源之前，使用 [AWS Verified Access](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html) 來確認使用者的身分和裝置狀態，藉此提供一層額外的保護。

 如果您使用 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 使用者，請使用 IAM 保護登入程序。

 您可以同時使用 AWS IAM Identity Center 和直接 IAM 聯合來管理 AWS 的存取權。您可以使用 IAM 聯合來管理 AWS 管理主控台 和服務的存取權，以及使用 IAM Identity Center 來管理 Quick 或 Amazon Q Business 等業務應用程式的存取權。

 無論登入方法為何，強制執行強式登入政策至關重要。

### 實作步驟
<a name="implementation-steps"></a>

 以下是一般的強式登入建議。您設定的實際設定應由貴公司政策來規定，或使用如 [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html) 的標準。
+  Require MFA (需要 MFA)。[IAM 最佳實務是對真人身分和工作負載要求 MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users)。開啟 MFA 可提供多一層安全防護，要求使用者提供登入憑證和一次性密碼 (OTP)，或是從硬體裝置以密碼編譯方式驗證和產生的字串。
+  強制密碼長度下限，此為密碼強度的要素。
+  強制密碼複雜性，使密碼更難猜測。
+  允許使用者變更自己的密碼。
+  建立個別身分，而不是共用憑證。透過建立個別身分，您可以為每個使用者提供一組獨一無二的安全憑證。個別使用者可讓您稽核每個使用者的活動。

 IAM Identity Center 建議：
+  當使用預設目錄來建立密碼長度、複雜性和重複使用需求時，IAM Identity Center 提供預先定義的[密碼政策](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)。
+  當身分來源為預設目錄、AWS Managed Microsoft AD 或 AD Connector 時，[開啟 MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) 並為 MFA 設定內容感知或永遠開啟設定。
+  允許使用者[註冊自己的 MFA 裝置](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html)。

 Amazon Cognito 使用者集區目錄建議：
+  設定[密碼強度](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)設定。
+  使用者[需要 MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html)。
+  針對[適應性身分驗證](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html) (這可封鎖可疑登入) 等功能使用 Amazon Cognito 使用者集區[進階安全設定](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html)。

 IAM 使用者建議：
+  在理想情況下，您使用 IAM Identity Center 或直接聯合。然而，您可能需要 IAM 使用者。在這種情況下，為 IAM 使用者[設定密碼政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)。您可以使用密碼政策來定義需求，例如最短長度或是密碼是否需要非字母字元等。
+  建立 IAM 政策以[強制 MFA 登入](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1)，以便允許使用者管理自己的密碼和 MFA 裝置。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC02-BP03 安全地儲存和使用機密](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html) 
+  [SEC02-BP04 仰賴集中式身分提供者](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) 
+  [SEC03-BP08 在組織內安全地共用資源](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html) 

 **相關文件：**
+  [AWS IAM Identity Center 密碼政策](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) 
+  [IAM 使用者密碼政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [設定 AWS 帳戶 根使用者密碼](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 
+  [Amazon Cognito 密碼政策](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html) 
+  [AWS 憑證](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) 
+  [ IAM 安全最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 

 **相關影片：**
+  [使用 AWS IAM Identity Center 大規模管理使用者許可](https://youtu.be/aEIqeFCcK7E) 
+  [在每一層都能掌握身分](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP02 使用暫時憑證
<a name="sec_identities_unique"></a>

 當進行任何類型的驗證時，最好是使用臨時憑證，而不是長期憑證，以降低或消除風險，例如憑證遭到意外洩露、共用或遭竊。

 **預期成果：**為了降低長期憑證的風險，對於人員和機器身分，請盡可能使用臨時憑證。長期憑證會產生許多風險，例如，經由上傳到公有儲存庫而暴露。透過使用臨時憑證，您可大幅降低憑證遭到入侵的可能性。

 **常見的反模式：**
+  開發人員使用取自 IAM 使用者的長期存取金鑰，而不是使用聯合從 CLI 取得暫時憑證。
+  開發人員將長期存取金鑰內嵌在程式碼中，並將該程式碼上傳到公有 Git 儲存庫。
+  開發人員將長期存取金鑰內嵌在行動應用程式中，之後在應用程式商店中提供該行動應用程式。
+  使用者與其他使用者共用長期存取金鑰，或是擁有長期存取金鑰的離職員工仍持有金鑰。
+  對機器身分可以使用暫時憑證時，卻使用長期存取金鑰。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 對所有 AWS API 和 CLI 請求使用暫時安全憑證，而不是長期憑證。幾乎在任何情況下，對 AWS 服務的 API 和 CLI 請求都必須使用 [AWS 存取金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)簽署。您可以使用暫時或長期憑證簽署這些請求。您唯一應使用長期憑證 (又稱為長期存取金鑰) 的時候是在使用 [IAM 使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)或 [AWS 帳戶 根使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)時。當您聯合至 AWS 或透過其他方法擔任 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)時，系統會產生暫時憑證。每當您使用登入憑證存取 AWS 管理主控台 時，系統會為您產生暫時憑證以呼叫 AWS 服務。在幾種情況下，您將需要長期憑證，並能夠使用暫時憑證完成幾乎所有任務。

 避免使用長期憑證而改用暫時憑證，同時實行減少使用 IAM 使用者並支持聯合和 IAM 角色的策略。雖然對人類和機器身分過去以來都是使用 IAM 使用者，我們現在建議不要使用它們以避免使用長期存取金鑰的風險。

### 實作步驟
<a name="implementation-steps"></a>

#### 真人身分
<a name="human-identities"></a>

 對於人力資源身分，例如員工、管理員、開發人員、操作員和客戶：
+  您應[仰賴集中式身分提供者](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)並[要求人類使用者以聯合搭配身分提供者，使用臨時憑證存取 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)。您可以[直接聯合至各個 AWS 帳戶](https://aws.amazon.com/identity/federation/) 或使用 [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 和您選擇的身分提供者，為您的使用者進行聯合。與使用 IAM 使用者相比，聯合除了可消除長期憑證外，還提供一些優勢。您的使用者也可以從命令列進行[直接聯合](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/)，或使用 [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) 請求暫時憑證。這表示有少數使用案例會需要 IAM 使用者，或使用者需要長期憑證。

 對於第三方身分：
+  當授權讓第三方 (例如軟體即服務 (SaaS) 提供者) 存取 AWS 帳戶 中的資源時，您可以使用[跨帳戶角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)和[以資源為基礎的政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)。此外，您可以針對 B2B SaaS 客戶或合作夥伴，使用 [Amazon Cognito OAuth 2.0 授權](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints-oauth-grants.html)用戶端憑證流程。

 透過 Web 瀏覽器、用戶端應用程式、行動應用程式或互動式命令列工具存取您的 AWS 資源的使用者身分。
+  如果需要授權應用程式供消費者或客戶存取您的 AWS 資源，您可以使用 [Amazon Cognito 身分集區](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html)或 [Amazon Cognito 使用者集區](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)來提供臨時憑證。憑證的許可是透過 IAM 角色來設定。您也可以為未驗證的訪客使用者，另外定義有限許可的 IAM 角色。

#### 機器身分
<a name="machine-identities"></a>

 對於機器身分，您可能需要使用長期憑證。在這些情況下，您應[要求工作負載使用暫時憑證，並以 IAM 角色存取 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles)。
+  對於 [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2)，您可以使用[適用於 Amazon EC2 的角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)。
+  [AWS Lambda](https://aws.amazon.com/lambda/) 可讓您設定 [Lambda 執行角色，授予服務許可](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)以使用暫時憑證執行 AWS 動作。有許多其他類似的模型可供 AWS 服務使用 IAM 角色授予暫時憑證。
+  對於 IoT 裝置，您可以使用 [AWS IoT Core 憑證提供者](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)來請求暫時憑證。
+  對於內部部署系統或是在 AWS 之外執行並需要存取 AWS 資源的系統，您可以使用 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)。

 在某些情況下不支援臨時憑證，因此需要使用長期憑證。在這些情況下，[定期稽核和輪換這些憑證](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)並[定期輪換存取金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)。對於有嚴格限制的 IAM 使用者存取金鑰，請考慮下列其他安全措施：
+  授予有嚴格限制的許可：
  +  遵守最低權限原則 (具體指定動作、資源和條件)。
  +  考慮僅授予 IAM 使用者一個特定角色的 AssumeRole 操作。根據內部部署架構而定，此方法有助於隔離和保護長期 IAM 憑證。
+  在 IAM 角色信任政策中，限制允許的網路來源和 IP 位址。
+  監控用量並設定未使用許可或濫用的警示 (使用 AWS CloudWatch Logs 指標篩選器和警報)。
+  強制執行[許可界限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) (服務控制政策 (SCP) 和許可界限來彼此互補 - SCP 較為粗略，而許可界限較為精細。
+  實作程序來佈建並安全地儲存 (在內部部署保存庫中) 憑證。

 其他適用於需要長期憑證的案例的選項包括：
+  建置自己的權杖供應 API (使用 Amazon API Gateway)。
+  在您必須使用長期憑證，或是使用 AWS 存取金鑰以外的憑證 (例如資料庫登入) 的情況下，您可以使用專為管理機密而設計的服務，例如 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)。Secrets Manager 可簡化加密、輪換及安全儲存加密機密的工作。許多 AWS 服務都可使用 Secrets Manager 支援[直接整合](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html)。
+  對於多重雲端整合，您可以根據來源憑證服務提供者 (CSP) 憑證使用聯合身分 (請參閱 [AWS STS AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html))。

 如需有關輪換長期憑證的詳細資訊，請參閱[輪換存取金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC02-BP03 安全地儲存和使用機密](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html) 
+  [SEC02-BP04 仰賴集中式身分提供者](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) 
+  [SEC03-BP08 在組織內安全地共用資源](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html) 

 **相關文件：**
+  [暫時安全憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) 
+  [AWS 憑證](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) 
+  [IAM 安全最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 
+  [IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 
+  [身分提供者與聯合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [輪換存取金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) 
+  [安全合作夥伴解決方案：存取與存取控制](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [AWS 帳戶根使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 
+  [使用 Google Cloud Platform 原生工作負載身分存取 AWS](https://aws.amazon.com/blogs/security/access-aws-using-a-google-cloud-platform-native-workload-identity/) 
+  [如何使用 AWS Security Token Service 存取 Microsoft Entra ID 租用戶中的 AWS 資源](https://aws.amazon.com/blogs/security/how-to-access-aws-resources-from-microsoft-entra-id-tenants-using-aws-security-token-service/) 

 **相關影片：**
+  [使用 AWS IAM Identity Center 大規模管理使用者許可](https://youtu.be/aEIqeFCcK7E) 
+  [在每一層都能掌握身分](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP03 安全地儲存和使用機密
<a name="sec_identities_secrets"></a>

 工作負載需要能夠自動向資料庫、資源和第三方資源證明其身分。這需使用私密存取憑證來完成，例如 API 存取金鑰、密碼和 OAuth 字符。使用專用服務來儲存、管理和輪換這些憑證有助於降低這些憑證遭到入侵的可能性。

 **預期成果：**實作安全管理應用程式憑證的機制，以達成下列目標：
+  識別工作負載需要何種機密。
+  盡可能以短期憑證取代長期憑證，來減少所需的長期憑證數目。
+  建立安全的存放區並自動輪換其餘的長期憑證。
+  稽核對存在於工作負載中的機密的存取。
+  持續監控以確認原始程式碼在開發過程中沒有內嵌機密。
+  降低憑證遭意外洩露的可能性。

 **常見的反模式：**
+  沒有輪換憑證。
+  將長期憑證存放在原始程式碼或設定檔中。
+  未加密儲存靜態憑證。

 **建立此最佳實務的優勢：**
+  已加密儲存靜態和傳輸中的機密。
+  透過 API 限制憑證的存取 (將其視為*憑證自動販賣機*)。
+  稽核並記錄對憑證的存取 (包括讀寫)。
+  區隔顧慮：由不同的元件執行憑證輪換，而該元件可與其餘的架構分離。
+  自動將機密隨需散發到軟體元件並集中進行輪換。
+  可以精細的方式控制對憑證的存取。

 **未建立此最佳實務時的風險暴露等級**：高 

## 實作指引
<a name="implementation-guidance"></a>

 以往，憑證用於向資料庫進行驗證，而第三方 API、字符和其他機密可能內嵌在原始程式碼或環境檔案中。AWS 提供數種機制以安全儲存這些憑證，自動輪換並稽核它們的使用情況。

 著手機密管理的最佳方法是遵循移除、取代和輪換的指引。最安全的憑證是您不用儲存、管理或處理的憑證。有些憑證對於工作負載的運作不再是必要的，故能夠安全移除。

 對於工作負載適當運作仍舊是必要的憑證，可能有機會以暫時或短期憑證取代長期憑證。例如，與其對 AWS 私密存取金鑰進行硬式編碼，考慮使用 IAM 角色以臨時憑證取代長期憑證。

 部分長期存留的機密可能無法移除或取代。您可以將這些機密儲存在 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 之類的服務中，進行集中儲存、管理和定期輪換。

 對工作負載的原始程式碼和設定檔的稽核，可能顯現多種類型的憑證。下表概述處理常見憑證類型的策略：


|  憑證類型  |  描述  |  建議策略  | 
| --- | --- | --- | 
|  IAM 存取金鑰  |  用於在工作負載內擔任 IAM 角色的 AWS IAM 存取和私有金鑰  |  取代：改用指派給運算執行個體的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html) (例如 [Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) 或 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html))。為了與需要存取您的 AWS 帳戶 中的資源的第三方進行互通，請詢問他們是否支援 [AWS 跨帳戶存取權](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)。對於行動應用程式，請考慮透過 [Amazon Cognito 身分集區 (聯合身分)](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html) 使用臨時憑證。對於 AWS 外部執行的工作負載，請考慮 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 或 [AWS Systems Manager 混合啟用](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)。關於容器，請參閱 [Amazon ECS 任務 IAM 角色](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)或 [Amazon EKS 節點 IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html)。 | 
|  SSH 金鑰  |  用於手動或做為自動化程序的一部分登入 Linux EC2 執行個體的 Secure Shell 私有金鑰  |  取代：使用 [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) 或 [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) 透過 IAM 角色提供對 EC2 執行個體的程式設計和手動存取。 | 
|  應用程式和資料庫憑證  |  密碼 – 純文字字串  |  輪換：將憑證儲存在 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 中並建立自動輪換 (如果可能)。 | 
|  Amazon RDS 和 Aurora Admin 資料庫憑證  |  密碼 – 純文字字串  |  取代：使用 [Secrets Manager 與 Amazon RDS 的整合](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html)或 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html)。此外，某些 RDS 資料庫類型可以在某些使用案例中使用 IAM 角色而非密碼 (如需詳細資訊，請參閱 [IAM 資料庫身分驗證](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html))。 | 
|  OAuth 字符  |  私密字符 – 純文字字串  |  輪換：將字符儲存在 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 中並設定自動輪換。 | 
|  API 字符和金鑰  |  私密字符 – 純文字字串  |  輪換：儲存 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 中，並在可能的情況下建立自動輪換。 | 

 常見的反模式是將 IAM 存取金鑰內嵌在原始程式碼、組態檔案或行動應用程式內。當需要 IAM 存取金鑰與 AWS 服務通訊時，請使用[暫時 (短期) 安全憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)。您可以透過[適用於 EC2 的 IAM 角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)執行個體、[執行角色](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) (用於 Lambda 函數)、[Cognito IAM 角色](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) (用於行動使用者存取)，以及 [IoT Core 政策](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) (用於 IoT 裝置) 提供這些短期憑證。與第三方互動時，偏好[委派 IAM 角色的存取權](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) (包含對帳戶資源的必要存取權)，而不是設定 IAM 使用者並將該使用者的私密存取金鑰傳送給第三方。

 在很多情況下，工作負載需要儲存機密才能與其他服務和資源相互操作。[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 是專為安全管理這些憑證所打造的，可儲存、使用和輪換 API 字符、密碼和其他憑證。

 AWS Secrets Manager 提供五項重要功能以確保敏感憑證的安全儲存和處理：[靜態加密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)、[傳輸中加密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html)、[全面性稽核](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html)、[精細存取控制](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html)，以及[可擴充的憑證輪換](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)。來自 AWS 合作夥伴的其他機密管理服務，或本機開發並提供類似功能和保證的解決方案也可接受。

 擷取機密時，您可以使用 Secrets Manager 用戶端快取元件進行快取以供未來使用。擷取快取的秘密比從 Secrets Manager 中擷取要快。此外，由於呼叫 Secrets Manager API 會產生費用，因此使用快取可以降低成本。如需您可以擷取機密的所有方法，請參閱[取得機密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)。

**注意**  
 某些語言可能會要求您針對用戶端快取實作自己的記憶體內加密。

### 實作步驟
<a name="implementation-steps"></a>

1.  使用 [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/) 等自動工具識別包含硬式編碼憑證的程式碼路徑。

   1.  使用 Amazon CodeGuru 掃描您的程式碼儲存庫。檢閱完成後，在 CodeGuru 中篩選 Type=Secrets 以尋找有問題的程式碼行。

1.  識別可移除或取代的憑證。

   1.  識別不再需要的憑證並標示以進行移除。

   1.  對於內嵌在原始程式碼中的 AWS 機密金鑰，請將其取代為與必要資源關聯的 IAM 角色。如果您部分的工作負載位於 AWS 之外，但需要 IAM 憑證來存取 AWS 資源，請考慮 [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) 或 [AWS Systems Manager 混合啟用](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)。

1.  對於其他第三方長期存留且需要使用輪換策略的機密，將 Secrets Manager 整合至程式碼中以在執行時期擷取第三方機密。

   1.  CodeGuru 主控台可以使用已探索的憑證自動[在 Secrets Manager 中建立機密](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)。

   1.  將 Secrets Manager 的機密擷取整合至您的應用程式程式碼中。

      1.  無伺服器 Lambda 函數可以使用與語言無關的 [Lambda 延伸](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html)。

      1.  對於 EC2 執行個體或容器，AWS 提供範例[用戶端程式碼，可以數種熱門的程式設計語言從 Secrets Manager 擷取機密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)。

1.  定期審查您的程式碼庫並重新掃描，以確認程式碼中未加入新的機密。

   1.  考慮使用 [git-secrets](https://github.com/awslabs/git-secrets) 之類的工具以防將新機密認可到您的原始程式碼儲存庫。

1.  [監控 Secrets Manager 活動](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html)以尋找非預期使用、不當私密存取或嘗試刪除機密的跡象。

1.  減少對憑證的人員接觸。將讀寫和修改憑證的存取權限於專門用於此用途的 IAM 角色，並且只將擔任該角色的存取權提供給一小組可操作的使用者子集。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC02-BP02 使用臨時憑證](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html) 
+  [SEC02-BP05 定期稽核和輪換憑證](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) 

 **相關文件：**
+  [開始使用 AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [身分提供者與聯合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [Amazon CodeGuru 推出機密偵測器](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) 
+  [AWS Secrets Manager 使用 AWS Key Management Service 的方式](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html) 
+  [Secrets Manager 中的機密加密和解密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html) 
+  [Secrets Manager 部落格文章](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/) 
+  [Amazon RDS 宣佈與 AWS Secrets Manager 整合](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/) 

 **相關影片：**
+  [大規模管理、擷取和輪換機密的最佳實務](https://youtu.be/qoxxRlwJKZ4) 
+  [使用 Amazon CodeGuru 機密偵測器尋找硬式編碼的機密](https://www.youtube.com/watch?v=ryK3PN--oJs) 
+  [使用 AWS Secrets Manager 保護混合式工作負載的機密](https://www.youtube.com/watch?v=k1YWhogGVF8) 

 **相關研討會：**
+  [在 AWS Secrets Manager 中儲存、擷取和管理敏感憑證](https://catalog.us-east-1.prod.workshops.aws/workshops/92e466fd-bd95-4805-9f16-2df07450db42/en-US) 
+  [AWS Systems Manager 混合啟用](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html) 

# SEC02-BP04 仰賴集中式身分提供者
<a name="sec_identities_identity_provider"></a>

 人力身分 (員工和承包商) 可仰賴身分供應商來集中管理身分。由於您是從單一位置建立、指派、管理、撤銷和稽核存取權，因此這樣一來可以更好管理多個應用程式和系統中的存取權。

 **預期成果：**擁有集中式身分提供者，可集中管理員工使用者、身分驗證政策 (例如，要求多重要素驗證 (MFA))，以及對系統和應用程式進行授權 (例如，根據使用者的群組成員資格或屬性指派存取權)。您的員工使用者登入集中身分提供者並聯合 (單一登入) 至內部和外部應用程式，如此一來，使用者就不需記住多個憑證。您的身分提供者與您的人力資源 (HR) 系統整合，因此人事變更會自動同步至您的身分提供者。例如，若有人離開您的組織，您可以自動撤銷聯合應用程式和系統 (包括 AWS) 的存取權。您已在身分提供者中啟用詳細稽核日誌記錄，並監控這些日誌以找出不尋常的使用者行為。

 **常見的反模式：**
+  您未使用聯合和單一登入。您的員工使用者在多個應用程式和系統中建立了不同的使用者帳戶和憑證。
+  您尚未將員工使用者的身分生命週期自動化，例如透過整合身分提供者與您的 HR 系統。使用者離開您的組織或變更職務時，您採取手動程序在多個應用程式和系統中刪除或更新記錄。

 **建立此最佳實務的優勢：**透過使用集中式身分提供者，您就可以從單一位置管理員工使用者身分和政策，而且能夠將應用程式存取權指派給使用者和群組，並監控使用者登入活動。透過與您的人力資源 (HR) 系統整合，使用者變更職務時，這些變更就會同步至身分提供者，並自動更新指派的應用程式和許可。使用者離開您的組織時，系統會自動停用他們在身分提供者中的身分，並撤銷他們對聯合應用程式和系統的存取權。

 **未建立此最佳實務時的風險暴露等級**：高 

## 實作指引
<a name="implementation-guidance"></a>

 **員工使用者存取 AWS 的指引**：員工使用者 (例如組織中的員工和承包商) 可能需要使用 AWS 管理主控台 或 AWS Command Line Interface (AWS CLI) 存取 AWS 來執行其工作職能。您可以透過從集中式身分提供者，在兩個層級聯合至 AWS 的方式，將 AWS 存取權授予員工使用者：直接聯合至各個 AWS 帳戶，或聯合至您的 [AWS 組織](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)中的多個帳戶。

 若要將您的員工使用者直接與各個 AWS 帳戶 聯合，您可以使用集中式身分提供者來聯合至該帳戶中的 [AWS Identity and Access Management](https://aws.amazon.com/iam/)。IAM 的彈性可讓您啟用單獨的 [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) 或 [Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) 身分提供者用於各個 AWS 帳戶，並使用聯合身分使用者屬性進行存取控制。您的員工使用者將透過提供憑證 (例如密碼和 MFA 字符代碼) 的方式，使用自己的 Web 瀏覽器登入身分提供者。身分提供者會向其瀏覽器發出 SAML 聲明，並提交至 AWS 管理主控台 登入 URL，以允許使用者透過[擔任 IAM 角色對 AWS 管理主控台](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html) 進行單一登入。您的使用者也可以取得暫時 AWS API 憑證，以便在 [AWS CLI](https://aws.amazon.com/cli/) 或 [AWS SDK](https://aws.amazon.com/developer/tools/) (從 [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)) 中使用，方法是[使用來自身分提供者的 SAML 聲明擔任 IAM 角色](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)。

 若要將您的員工使用者與 AWS 組織中的多個帳戶聯合，您可以使用 [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) 集中管理員工使用者對 AWS 帳戶 和應用程式的存取權。您可以為組織啟用 Identity Center，並設定您的身分來源。IAM Identity Center 提供了預設身分來源目錄，您可以使用此目錄來管理您的使用者和群組。或者，您可以選擇外部身分來源，方法是使用 SAML 2.0 [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)，並使用 SCIM [自動佈建](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html)使用者和群組，或是使用 [Directory Service](https://aws.amazon.com/directoryservice/) [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html)。身分來源設定後，您可以透過在您的[許可集](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)中定義最低許可政策的方式，指派使用者和群組對 AWS 帳戶 的存取權。您的員工使用者可以進行身分驗證的方式包括：透過您的集中身分提供者登入 [AWS 存取入口網站](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html)以及對 AWS 帳戶 和指派給他們的雲端應用程式進行單一登入。您的使用者可以設定 [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) 以透過 Identity Center 進行身分驗證，並取得憑證來執行 AWS CLI 命令。Identity Center 也允許透過單一登入方式存取 AWS 應用程式，例如 [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) 和 [AWS IoT IoT Sitewise Monitor 入口網站](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html)。

 依照上述指引進行後，您的員工使用者在 AWS 上管理工作負載時，將不再需要使用 IAM 使用者 和群組，可直接正常操作。反之，您的使用者和群組將在 AWS 外部進行管理，而且使用者能夠以*聯合身分*存取 AWS 資源。聯合身分會使用您的集中式身分提供者所定義的群組。您應該識別並移除您的 AWS 帳戶 中不再需要的 IAM 群組、IAM 使用者和長期存在的使用者憑證 (密碼和存取金鑰)。您可以使用 [IAM 憑證報告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)[找到未使用的憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html)，[刪除相應的 IAM 使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html)和[刪除 IAM 群組](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html)。您可以對組織套用[服務控制政策 (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 以協助防止建立新的 IAM 使用者和群組，並強制透過聯合身分存取 AWS。

**注意**  
 您負責處理 SCIM 存取權杖的輪換，如[自動佈建](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html)文件中所述。此外，您也負責輪換支援您的聯合身分的憑證。

 **應用程式使用者的指引**：您可以使用 [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) 做為您的集中式身分提供者，來管理應用程式 (例如行動應用程式) 使用者的身分。Amazon Cognito 可為您的 Web 和行動應用程式啟用身分驗證、授權和使用者管理功能。Amazon Cognito 提供了可擴展至數百萬使用者的身分存放區、可支援社交與企業聯合身分，並且提供進階安全功能來協助保護您的使用者和業務。您可以將自訂 Web 或行動應用程式與 Amazon Cognito 整合，在幾分鐘內就能在應用程式中新增使用者身分驗證和存取控制。Amazon Cognito 是以 SAML 和 Open ID Connect (OIDC) 等開放身分標準為基礎所建置，可支援各種不同的合規法規，並與前端和後端開發資源整合。

### 實作步驟
<a name="implementation-steps"></a>

 **員工使用者存取 AWS 的步驟** 
+  使用下列其中一種方法，透過集中式身分提供者將您的員工使用者聯合至 AWS：
  +  使用 IAM Identity Center 透過與您的身分提供者聯合，對您的 AWS 組織中的多個 AWS 帳戶 啟用單一登入。
  +  使用 IAM 將您的身分提供者直接連接到各個 AWS 帳戶，以實現聯合的精細存取。
+  識別並移除已由聯合身分取代的 IAM 使用者和群組。

 **應用程式使用者的步驟** 
+  使用 Amazon Cognito 作為應用程式的集中式身分提供者。
+  使用 OpenID Connect 和 OAuth 將您的自訂應用程式與 Amazon Cognito 整合。您可以使用 Amplify 程式庫來開發自訂應用程式，這些程式庫提供了簡單的介面，可與各種不同的 AWS 服務進行整合，例如用於身分驗證的 Amazon Cognito。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC02-BP06 採用使用者群組和屬性](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_groups_attributes.html) 
+  [SEC03-BP02 授予最低權限存取權](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html) 
+  [SEC03-BP06 根據生命週期管理存取](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html) 

 **相關文件：**
+  [AWS 中的聯合身分](https://aws.amazon.com/identity/federation/) 
+  [IAM 中的安全最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [AWS Identity and Access Management 最佳實務](https://aws.amazon.com/iam/resources/best-practices/) 
+  [IAM Identity Center 委派管理入門](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/) 
+  [如何在 IAM Identity Center 中針對進階使用案例使用客戶受管政策](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/) 
+  [AWS CLI v2：IAM Identity Center 憑證提供者](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html) 

 **相關影片：**
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) 深入剖析](https://youtu.be/YMj33ToS8cI) 
+  [AWS re:Invent 2022 - 使用 IAM Identity Center 簡化現有的員工存取權](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Invent 2018：在每一層都能掌握身分](https://youtu.be/vbjFjMNVEpc) 

 **相關範例：**
+  [研討會：使用 AWS IAM Identity Center 實現強大的身分管理](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US) 

 **相關工具：**
+  [AWS 安全能力合作夥伴：身分和存取管理](https://aws.amazon.com/security/partner-solutions/) 
+  [saml2aws](https://github.com/Versent/saml2aws) 

# SEC02-BP05 定期稽核和輪換憑證
<a name="sec_identities_audit"></a>

 定期稽核和輪換憑證以限制憑證可用來存取資源的時限。長期憑證會產生許多風險，而透過定期輪換長期憑證可以降低這些風險。

 **預期成果：**實作憑證輪換以協助降低與使用長期憑證關聯的風險。定期稽核和修復不符合憑證輪換政策的情況。

 **常見的反模式：**
+  沒有稽核憑證的使用。
+  不必要地使用長期憑證。
+  使用長期憑證並且未定期輪換。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 當您無法倚賴臨時憑證且需要長期憑證時，請稽核憑證以確保強制執行既定的控制 (例如[多重要素驗證](https://aws.amazon.com/iam/features/mfa/) (MFA))、定期輪換，並且具備適當的存取層級。

 定期驗證 (最好是透過自動化工具) 是確認強制執行正確的控制項的必要項目。對於人類身分，您應要求使用者定期變更密碼，並淘汰存取金鑰而改用暫時憑證。隨著您從 AWS Identity and Access Management (IAM) 使用者移向集中式身分，您可以[產生憑證報告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)以稽核您的使用者。

 我們也建議您在身分提供者中強制和監控 MFA。您可以設定[AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 或使用 [AWS Security Hub CSPM 安全標準](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3)來監控使用者是否已啟用 MFA。請考慮使用 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 為機器身分提供臨時憑證。在無法使用 IAM 角色和暫時憑證的情況下，必須經常稽核和輪換存取金鑰。

### 實作步驟
<a name="implementation-steps"></a>
+  **定期稽核憑證：**稽核身分提供者和 IAM 中設定的身分有助於確認只有已授權的身分才能存取您的工作負載。此類身分可能包括但不限於 IAM 使用者、AWS IAM Identity Center 使用者、Active Directory 使用者，或不同上游身分提供者中的使用者。例如，移除離職的人員和移除不再需要的跨帳戶角色。對於 IAM 實體存取的服務，備妥程序來定期稽核許可。這有助您識別需要修改的政策，以移除任何不使用的許可。使用憑證報告和 [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 來稽核 IAM 憑證和許可。您可以使用 [Amazon CloudWatch 來設定對特定 API 呼叫 (在 AWS 環境中呼叫) 的警示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html)。[Amazon GuardDuty 也可以向您提醒未預期的活動](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html)，這可指出對 IAM 憑證過於寬鬆的存取或意外存取。
+  **定期輪換憑證：**當您無法使用暫時憑證時，定期輪換長期 IAM 存取金鑰 (最長每 90 天)。如果在您不知情的情況下意外洩漏了存取金鑰，這可限制憑證可用來存取資源的時限。如需有關輪換 IAM 使用者的存取金鑰的詳細資訊，請參閱[輪換存取金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)。
+  **審查 IAM 許可：**為提升 AWS 帳戶 的安全，請定期審查和監控每個 IAM 政策。確認政策遵守最低權限的原則。
+  **考慮自動化 IAM 資源建立和更新：**[IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 會自動執行許多 IAM 任務，例如角色和政策管理。或者，可以使用 AWS CloudFormation 自動化 IAM 資源 (包括角色和政策) 的部署，以減少人為錯誤，因為可針對範本進行驗證和版本控制。
+  **對於機器身分，使用 IAM Roles Anywhere 取代 IAM 使用者：**[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 可讓您在傳統上無法使用的區域 (例如內部部署伺服器) 使用角色。IAM Roles Anywhere 使用可信的 [X.509 憑證](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/trust-model.html#signature-verification)向 AWS 進行身分驗證及接收臨時憑證。使用 IAM Roles Anywhere 讓您無需輪換這些憑證，因為長期憑證不再儲存於內部部署環境中。請注意，您將需要監視 X.509 憑證，並在快到期時輪換。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC02-BP02 使用臨時憑證](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html) 
+  [SEC02-BP03 安全地儲存和使用機密](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html) 

 **相關文件：**
+  [開始使用 AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [IAM 最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [身分提供者與聯合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [安全合作夥伴解決方案：存取與存取控制](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [暫時安全憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) 
+  [取得 AWS 帳戶 的憑證報告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) 

 **相關影片：**
+  [大規模管理、擷取和輪換機密的最佳實務](https://youtu.be/qoxxRlwJKZ4) 
+  [使用 AWS IAM Identity Center 大規模管理使用者許可](https://youtu.be/aEIqeFCcK7E) 
+  [在每一層都能掌握身分](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP06 採用使用者群組和屬性
<a name="sec_identities_groups_attributes"></a>

 根據使用者群組和屬性定義許可，有助於減少政策的數量並降低複雜性，因而更容易實現最低權限原則。您可以利用使用者群組，根據人員在組織中的職務，從單一位置管理多人的許可。部門、專案或位置這類屬性可在人員職務相似的情況下，針對不同的資源子集提供另一層許可範圍。

 **預期成果：**您可以根據職務，針對執行該職務的所有使用者套用許可變更。群組成員資格和屬性會控管使用者許可，進而減少管理個別使用者層級許可的需求。您在身分提供者 (IdP) 中定義的群組和屬性會自動傳播到您的 AWS 環境。

 **常見的反模式：**
+  管理個別使用者的許可，並且針對許多使用者重複此操作。
+  為群組定義的層級過高，授予的許可範圍過廣。
+  為群組定義的層級過於精細，致使成員資格發生重複和混淆的情形。
+  在可以使用屬性替代的情況下，仍使用在資源子集中具有重複許可的群組。
+  未透過整合在您 AWS 環境中的標準化身分提供者管理群組、屬性和成員資格。
+  使用 AWS IAM Identity Center 工作階段時使用角色鏈結 

 **未建立此最佳實務時的曝險等級：**中 

## 實作指引
<a name="implementation-guidance"></a>

 AWS 許可是在與主體 (例如使用者、群組、角色或資源) 相關聯且稱為*政策*的文件中定義。您可以根據工作職能、工作負載及 SDLC 環境來組織許可指派 (群組、許可、帳戶)，藉此調整許可管理的規模。針對您的員工，這可讓您根據使用者為組織執行的職務，而不是所存取的資源來定義群組。例如，WebAppDeveloper 群組可能已附加政策，用於設定開發帳戶內的 Amazon CloudFront 等服務。`AutomationDeveloper` 群組可能有部分許可與 `WebAppDeveloper` 群組重疊。您可在個別政策中擷取這些常用的許可，並讓這些許可同時與這兩個群組相關聯，而不要讓這兩種職務的使用者屬於 `CloudFrontAccess` 群組。

 除了群組之外，您還可以使用*屬性*來進一步設定存取範圍。例如，您的 `WebAppDeveloper` 群組中的使用者可能有「專案」屬性，可用來將其專案特定的資源設定至存取範圍內。如果使用此技術，則不需要在所擁有許可相同的情況下，針對處理不同專案的應用程式開發人員建立不同的群組。您在許可政策中參照屬性的方式是根據其來源，無論其定義為聯合通訊協定的一部分 (例如 SAML、OIDC 或 SCIM)、為自訂 SAML 聲明，還是在 IAM Identity Center 內設定。

### 實作步驟
<a name="implementation-steps"></a>

1.  確定您將定義群組和屬性的位置：

   1.  依照 [SEC02-BP04 仰賴集中式身分提供者](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)中的指引，您可以確定是否需要在身分提供者內、IAM Identity Center 內或在特定帳戶中使用 IAM 使用者群組定義群組和屬性。

1.  定義群組：

   1.  根據職務和所需的存取範圍確定您的群組。考慮使用階層式結構或命名慣例來有效組織群組。

   1.  如果在 IAM Identity Center 內定義，請建立群組，並使用許可集關聯所需的存取層級。

   1.  如果在外部身分提供者內定義，請確定提供者是否支援 SCIM 通訊協定，並考慮在 IAM Identity Center 內啟用自動佈建。此功能可在您的提供者與 IAM Identity Center 之間同步群組的建立、成員資格和刪除。

1.  定義屬性：

   1.  如果您使用外部身分提供者，SCIM 和 SAML 2.0 通訊協定預設都會提供特定屬性。您可以使用 SAML 聲明與 `https://aws.amazon.com/SAML/Attributes/PrincipalTag` 屬性名稱來定義和傳遞其他屬性。如需定義和設定自訂屬性的指引，請參閱身分提供者的文件。

   1.  如果您在 IAM Identity Center 內定義角色，請啟用屬性型存取控制 (ABAC) 功能並視需要定義屬性。考慮符合組織結構或資源標記策略的屬性。

 如果您需要透過 IAM Identity Center 擔任的 IAM 角色進行 IAM 角色鏈結，則 `source-identity` 和 `principal-tags` 這類值就不會傳播。如需詳細資訊，請參閱[啟用和設定存取控制的屬性](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)。

1.  根據群組和屬性設定許可的範圍：

   1.  考慮在許可政策中加入條件，用來比較您主體的屬性與所存取資源的屬性。例如，您可以定義一項條件，規定僅在 `PrincipalTag` 條件索引鍵的值與相同名稱的 `ResourceTag` 索引鍵的值相符時，才允許對相關資源的存取。

   1.  定義 ABAC 政策時，請遵循 [ABAC 授權](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)最佳實務和範例中的指引。

   1.  隨著組織的需求發展，定期審查並更新群組和屬性結構，以確保最佳的許可管理。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC02-BP04 仰賴集中式身分提供者](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) 
+  [SEC03-BP02 授予最低權限存取權](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html) 
+  [COST02-BP04 實作群組和角色](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html) 

 **相關文件：**
+  [IAM 最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [在 IAM Identity Center 中管理身分](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) 
+  [AWS 的 ABAC 是什麼？](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [IAM Identity Center 中的 ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) 
+  [ABAC 政策範例](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html) 

 **相關影片：**
+  [使用 AWS IAM Identity Center 大規模管理使用者許可](https://youtu.be/aEIqeFCcK7E) 
+  [在每一層都能掌握身分](https://www.youtube.com/watch?v=vbjFjMNVEpc) 