# 身分與存取管理
**Topics**
+ [SEC 2. 如何管理人員和機器的身分驗證？](sec-02.md)
+ [SEC 3. 如何管理人員和機器的許可？](sec-03.md)
# SEC 2. 如何管理人員和機器的身分驗證？
處理安全的 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 使用強式登入機制
登入 (使用登入憑證進行驗證) 可預防當沒有使用多重要素驗證 (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。
+ 在不同使用者之間共用相同的憑證。
+ 沒有針對可疑的登入使用偵測控制。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
真人身分可採用數種方法來登入 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 等業務應用程式的存取權。
無論登入方法為何，強制執行強式登入政策至關重要。
### 實作步驟
以下是一般的強式登入建議。您設定的實際設定應由貴公司政策來規定，或使用如 [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 裝置。
## 資源
**相關的最佳實務：**
+ [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 使用暫時憑證
當進行任何類型的驗證時，最好是使用臨時憑證，而不是長期憑證，以降低或消除風險，例如憑證遭到意外洩露、共用或遭竊。
**預期成果：**為了降低長期憑證的風險，對於人員和機器身分，請盡可能使用臨時憑證。長期憑證會產生許多風險，例如，經由上傳到公有儲存庫而暴露。透過使用臨時憑證，您可大幅降低憑證遭到入侵的可能性。
**常見的反模式：**
+ 開發人員使用取自 IAM 使用者的長期存取金鑰，而不是使用聯合從 CLI 取得暫時憑證。
+ 開發人員將長期存取金鑰內嵌在程式碼中，並將該程式碼上傳到公有 Git 儲存庫。
+ 開發人員將長期存取金鑰內嵌在行動應用程式中，之後在應用程式商店中提供該行動應用程式。
+ 使用者與其他使用者共用長期存取金鑰，或是擁有長期存取金鑰的離職員工仍持有金鑰。
+ 對機器身分可以使用暫時憑證時，卻使用長期存取金鑰。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
對所有 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 使用者，我們現在建議不要使用它們以避免使用長期存取金鑰的風險。
### 實作步驟
#### 真人身分
對於人力資源身分，例如員工、管理員、開發人員、操作員和客戶：
+ 您應[仰賴集中式身分提供者](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 角色。
#### 機器身分
對於機器身分，您可能需要使用長期憑證。在這些情況下，您應[要求工作負載使用暫時憑證，並以 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)。
## 資源
**相關的最佳實務：**
+ [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 安全地儲存和使用機密
工作負載需要能夠自動向資料庫、資源和第三方資源證明其身分。這需使用私密存取憑證來完成，例如 API 存取金鑰、密碼和 OAuth 字符。使用專用服務來儲存、管理和輪換這些憑證有助於降低這些憑證遭到入侵的可能性。
**預期成果：**實作安全管理應用程式憑證的機制，以達成下列目標：
+ 識別工作負載需要何種機密。
+ 盡可能以短期憑證取代長期憑證，來減少所需的長期憑證數目。
+ 建立安全的存放區並自動輪換其餘的長期憑證。
+ 稽核對存在於工作負載中的機密的存取。
+ 持續監控以確認原始程式碼在開發過程中沒有內嵌機密。
+ 降低憑證遭意外洩露的可能性。
**常見的反模式：**
+ 沒有輪換憑證。
+ 將長期憑證存放在原始程式碼或設定檔中。
+ 未加密儲存靜態憑證。
**建立此最佳實務的優勢：**
+ 已加密儲存靜態和傳輸中的機密。
+ 透過 API 限制憑證的存取 (將其視為*憑證自動販賣機*)。
+ 稽核並記錄對憑證的存取 (包括讀寫)。
+ 區隔顧慮：由不同的元件執行憑證輪換，而該元件可與其餘的架構分離。
+ 自動將機密隨需散發到軟體元件並集中進行輪換。
+ 可以精細的方式控制對憑證的存取。
**未建立此最佳實務時的風險暴露等級**：高
## 實作指引
以往，憑證用於向資料庫進行驗證，而第三方 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)。
**注意**
某些語言可能會要求您針對用戶端快取實作自己的記憶體內加密。
### 實作步驟
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 角色，並且只將擔任該角色的存取權提供給一小組可操作的使用者子集。
## 資源
**相關的最佳實務：**
+ [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 仰賴集中式身分提供者
人力身分 (員工和承包商) 可仰賴身分供應商來集中管理身分。由於您是從單一位置建立、指派、管理、撤銷和稽核存取權，因此這樣一來可以更好管理多個應用程式和系統中的存取權。
**預期成果：**擁有集中式身分提供者，可集中管理員工使用者、身分驗證政策 (例如，要求多重要素驗證 (MFA))，以及對系統和應用程式進行授權 (例如，根據使用者的群組成員資格或屬性指派存取權)。您的員工使用者登入集中身分提供者並聯合 (單一登入) 至內部和外部應用程式，如此一來，使用者就不需記住多個憑證。您的身分提供者與您的人力資源 (HR) 系統整合，因此人事變更會自動同步至您的身分提供者。例如，若有人離開您的組織，您可以自動撤銷聯合應用程式和系統 (包括 AWS) 的存取權。您已在身分提供者中啟用詳細稽核日誌記錄，並監控這些日誌以找出不尋常的使用者行為。
**常見的反模式：**
+ 您未使用聯合和單一登入。您的員工使用者在多個應用程式和系統中建立了不同的使用者帳戶和憑證。
+ 您尚未將員工使用者的身分生命週期自動化，例如透過整合身分提供者與您的 HR 系統。使用者離開您的組織或變更職務時，您採取手動程序在多個應用程式和系統中刪除或更新記錄。
**建立此最佳實務的優勢：**透過使用集中式身分提供者，您就可以從單一位置管理員工使用者身分和政策，而且能夠將應用程式存取權指派給使用者和群組，並監控使用者登入活動。透過與您的人力資源 (HR) 系統整合，使用者變更職務時，這些變更就會同步至身分提供者，並自動更新指派的應用程式和許可。使用者離開您的組織時，系統會自動停用他們在身分提供者中的身分，並撤銷他們對聯合應用程式和系統的存取權。
**未建立此最佳實務時的風險暴露等級**：高
## 實作指引
**員工使用者存取 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) 等開放身分標準為基礎所建置，可支援各種不同的合規法規，並與前端和後端開發資源整合。
### 實作步驟
**員工使用者存取 AWS 的步驟**
+ 使用下列其中一種方法，透過集中式身分提供者將您的員工使用者聯合至 AWS：
+ 使用 IAM Identity Center 透過與您的身分提供者聯合，對您的 AWS 組織中的多個 AWS 帳戶 啟用單一登入。
+ 使用 IAM 將您的身分提供者直接連接到各個 AWS 帳戶，以實現聯合的精細存取。
+ 識別並移除已由聯合身分取代的 IAM 使用者和群組。
**應用程式使用者的步驟**
+ 使用 Amazon Cognito 作為應用程式的集中式身分提供者。
+ 使用 OpenID Connect 和 OAuth 將您的自訂應用程式與 Amazon Cognito 整合。您可以使用 Amplify 程式庫來開發自訂應用程式，這些程式庫提供了簡單的介面，可與各種不同的 AWS 服務進行整合，例如用於身分驗證的 Amazon Cognito。
## 資源
**相關的最佳實務：**
+ [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 定期稽核和輪換憑證
定期稽核和輪換憑證以限制憑證可用來存取資源的時限。長期憑證會產生許多風險，而透過定期輪換長期憑證可以降低這些風險。
**預期成果：**實作憑證輪換以協助降低與使用長期憑證關聯的風險。定期稽核和修復不符合憑證輪換政策的情況。
**常見的反模式：**
+ 沒有稽核憑證的使用。
+ 不必要地使用長期憑證。
+ 使用長期憑證並且未定期輪換。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
當您無法倚賴臨時憑證且需要長期憑證時，請稽核憑證以確保強制執行既定的控制 (例如[多重要素驗證](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 角色和暫時憑證的情況下，必須經常稽核和輪換存取金鑰。
### 實作步驟
+ **定期稽核憑證：**稽核身分提供者和 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 憑證，並在快到期時輪換。
## 資源
**相關的最佳實務：**
+ [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 採用使用者群組和屬性
根據使用者群組和屬性定義許可，有助於減少政策的數量並降低複雜性，因而更容易實現最低權限原則。您可以利用使用者群組，根據人員在組織中的職務，從單一位置管理多人的許可。部門、專案或位置這類屬性可在人員職務相似的情況下，針對不同的資源子集提供另一層許可範圍。
**預期成果：**您可以根據職務，針對執行該職務的所有使用者套用許可變更。群組成員資格和屬性會控管使用者許可，進而減少管理個別使用者層級許可的需求。您在身分提供者 (IdP) 中定義的群組和屬性會自動傳播到您的 AWS 環境。
**常見的反模式：**
+ 管理個別使用者的許可，並且針對許多使用者重複此操作。
+ 為群組定義的層級過高，授予的許可範圍過廣。
+ 為群組定義的層級過於精細，致使成員資格發生重複和混淆的情形。
+ 在可以使用屬性替代的情況下，仍使用在資源子集中具有重複許可的群組。
+ 未透過整合在您 AWS 環境中的標準化身分提供者管理群組、屬性和成員資格。
+ 使用 AWS IAM Identity Center 工作階段時使用角色鏈結
**未建立此最佳實務時的曝險等級：**中
## 實作指引
AWS 許可是在與主體 (例如使用者、群組、角色或資源) 相關聯且稱為*政策*的文件中定義。您可以根據工作職能、工作負載及 SDLC 環境來組織許可指派 (群組、許可、帳戶)，藉此調整許可管理的規模。針對您的員工，這可讓您根據使用者為組織執行的職務，而不是所存取的資源來定義群組。例如，WebAppDeveloper 群組可能已附加政策，用於設定開發帳戶內的 Amazon CloudFront 等服務。`AutomationDeveloper` 群組可能有部分許可與 `WebAppDeveloper` 群組重疊。您可在個別政策中擷取這些常用的許可，並讓這些許可同時與這兩個群組相關聯，而不要讓這兩種職務的使用者屬於 `CloudFrontAccess` 群組。
除了群組之外，您還可以使用*屬性*來進一步設定存取範圍。例如，您的 `WebAppDeveloper` 群組中的使用者可能有「專案」屬性，可用來將其專案特定的資源設定至存取範圍內。如果使用此技術，則不需要在所擁有許可相同的情況下，針對處理不同專案的應用程式開發人員建立不同的群組。您在許可政策中參照屬性的方式是根據其來源，無論其定義為聯合通訊協定的一部分 (例如 SAML、OIDC 或 SCIM)、為自訂 SAML 聲明，還是在 IAM Identity Center 內設定。
### 實作步驟
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. 隨著組織的需求發展，定期審查並更新群組和屬性結構，以確保最佳的許可管理。
## 資源
**相關的最佳實務：**
+ [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)
# SEC 3. 如何管理人員和機器的許可？
管理許可，以控制對需要存取 AWS 和工作負載的人員和機器身分的存取。您可利用許可來控制誰可以在何種條件下存取哪些內容。將許可設定為特定的真人和機器身分，即可授予對特定資源上特定服務動作的存取權。此外，您可以指定必須為 true 才能授予存取的條件。
**Topics**
+ [SEC03-BP01 定義存取需求](sec_permissions_define.md)
+ [SEC03-BP02 授予最低權限存取權](sec_permissions_least_privileges.md)
+ [SEC03-BP03 建立緊急存取程序](sec_permissions_emergency_process.md)
+ [SEC03-BP04 持續減少許可](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 為您的組織定義許可防護機制](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 根據生命週期管理存取](sec_permissions_lifecycle.md)
+ [SEC03-BP07 分析公有和跨帳戶存取權](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 在組織內安全地共用資源](sec_permissions_share_securely.md)
+ [SEC03-BP09 安全地與第三方共用資源](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 定義存取需求
管理員、終端使用者或其他元件都需要存取工作負載的每個元件或資源。請明確定義應該有權存取每個元件的人員和機器，選擇適當的身分類型及驗證和授權方法。
**常見的反模式：**
+ 將機密硬式編碼或儲存在應用程式中。
+ 為每名使用者授予自訂許可。
+ 使用長期憑證。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
管理員、終端使用者或其他元件都需要存取工作負載的每個元件或資源。請明確定義應該有權存取每個元件的人員和機器，選擇適當的身分類型及驗證和授權方法。
應提供組織內對 AWS 帳戶 的定期存取 (使用[聯合存取](https://aws.amazon.com/identity/federation/)或集中式身分提供者)。您應集中進行身分管理，並確保有既定的實務，可將 AWS 存取整合至員工的存取生命週期。例如，當員工改為擔任具有不同存取層級的任務角色時，其群組成員資格也應變更，以反映新的存取需求。
為非人類身分定義存取需求時，請判斷哪些應用程式和組成部分需要存取權，以及如何授予許可。使用透過最低權限存取模型建置的 IAM 角色是建議的方法。[AWS受管政策](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)提供預先定義的 IAM 政策，其中涵蓋最常見的使用案例。
AWS 服務 (例如 [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) 和 [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)) 可協助將機密從應用程式或工作負載中安全地分離。在 Secrets Manager 中，您可以為憑證建立自動輪換。您可以使用 Systems Manager 來參考指令碼、命令、SSM 文件、組態和自動化工作流程中的參數，方法是使用您在建立參數時指定的唯一名稱。
您可以使用 [AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 取得 [IAM 中的臨時安全憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)，以用於在 AWS 外部執行的工作負載。工作負載可以使用您在 AWS 應用程式中使用的相同 [IAM 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)和 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)來存取 AWS 資源。
可能的話，請選擇短期暫時憑證，而不是長期靜態憑證。對於您希望使用者具備程式設計存取權和長期憑證的情況，請使用[存取金鑰上次使用的資訊](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)來輪換和移除存取金鑰。
若使用者想要與 AWS 管理主控台 之外的 AWS 互動，則需要程式化存取權。授與程式化存取權的方式取決於存取 AWS 的使用者類型。
若要授予使用者程式設計存取權，請選擇下列其中一個選項。
****
| 哪個使用者需要程式設計存取權？ | 到 | 根據 |
| --- | --- | --- |
| IAM | (建議事項) 將主控台憑證用作臨時憑證來簽署對 AWS CLI、AWS SDK 或 AWS API 的程式設計請求。 | 請依照您要使用的介面所提供的指示操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/sec_permissions_define.html) |
| 人力資源身分 (IAM Identity Center 中管理的使用者) | 使用臨時憑證簽署對 AWS CLI、AWS SDK 或 AWS API 的程式設計請求。 | 請依照您要使用的介面所提供的指示操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/sec_permissions_define.html) |
| IAM | 使用臨時憑證簽署對 AWS CLI、AWS SDK 或 AWS API 的程式設計請求。 | 請遵循《IAM 使用者指南》中[使用臨時憑證搭配 AWS 資源](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)中的指示。 |
| IAM | (不建議使用)使用長期憑證簽署 AWS CLI、AWS SDK 或 AWS API 的程式設計要求。 | 請依照您要使用的介面所提供的指示操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/sec_permissions_define.html) |
## 資源
**相關文件：**
+ [屬性型存取控制 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [ IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [IAM Identity Center 的 AWS 受管政策](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS IAM 政策條件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [IAM 使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [移除不必要的憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [使用 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [如何根據 AWS 帳戶、OU 或組織控制對 AWS 資源的存取權](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [使用 AWS Secrets Manager 中增強的搜尋功能來輕鬆識別、安排和管理機密](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**相關影片：**
+ [在 60 分鐘內精通 IAM 政策](https://youtu.be/YQsK4MtsELU)
+ [責任區隔、最低權限、委派和 CI/CD](https://youtu.be/3H0i7VyTu70)
+ [簡化身分和存取管理，以促進創新](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 授予最低權限存取權
僅授予使用者在特定情況下對特定資源執行特定動作所需的存取權。使用群組和身分屬性大規模動態設定許可，而不是定義個別使用者的許可。例如，您可以允許一組開發人員的存取權，以只管理其專案的資源。如此一來，當開發人員退出專案時，其存取權將自動被撤銷，而無需變更基礎存取政策。
**預期成果：**使用者只擁有其特定工作職能所需的最低許可。您可以分開 AWS 帳戶 來隔離開發人員與正式作業環境。當開發人員需要存取特定任務的正式作業環境時，他們會獲得授予有限且受控的存取權，且僅限於任務期間有效。他們的正式作業存取權會在完成必要的工作後立即撤銷。您定期審查許可，並在不再需要時立即撤銷許可，例如，使用者變更角色或離開組織時。您可以將管理員權限侷限在一小群可信任的群組，以減少暴險。您僅給予機器或系統帳戶執行其預期任務所需的最低許可。
**常見的反模式：**
+ 根據預設，您會對使用者授予管理員許可。
+ 您使用根使用者帳戶從事日常活動。
+ 您建立過度寬鬆的政策，而未適當界定範圍。
+ 您不常檢閱許可，這會導致許可滲透。
+ 您完全依賴屬性型存取控制來隔離環境或管理許可。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
[最低權限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)原則指出，僅應允許身分執行完成特定任務所需的最小動作集。這平衡了可用性、效率和安全性。根據此原則運作有助於限制意外存取，也有助於追蹤誰有權存取哪些資源。IAM 使用者和角色在預設情況下沒有任何許可。根使用者預設擁有完整存取權，應受到嚴格監控，並僅用於[需要根存取權的任務](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。
IAM 政策用於明確授予許可給 IAM 角色或特定資源。例如，以身分為基礎的政策可以連接到 IAM 群組，而 S3 儲存貯體可由以資源為基礎的政策控制。
建立 IAM 政策時，您就可以指定必須為 true 的服務動作、資源和條件，以便 AWS 允許或拒絕存取。AWS 支援各種條件，以協助您縮減存取權範圍。例如，透過使用 PrincipalOrgID [條件金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)，就可以在請求者不屬於您的 AWS 組織時拒絕動作。
此外，您還可以使用 CalledVia 條件金鑰控制 AWS 服務代您發出的請求，例如建立 AWS Lambda 函數的 AWS CloudFormation。您可以將不同的政策類型分層，以便建立深度防禦並限制使用者的整體許可。您還可以限制在什麼條件下，可以授予哪些許可。例如，您可以允許工作負載團隊為他們建置的系統建立自己的 IAM 政策，但前提是須套用[許可界限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)來限制他們可授予的最大許可。
### 實作步驟
+ **實作最低權限政策**：將具有最低權限的存取政策指派給 IAM 群組和角色，以反映您已定義的使用者角色或職能。
+ **透過分隔 AWS 帳戶 來隔離開發和正式作業環境**：針對開發和正式作業環境使用不同的 AWS 帳戶，並使用[服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)、資源政策和身分政策來控制兩者之間的存取權。
+ **API 使用方式的基本政策**：確定所需許可的一種方法是審核 AWS CloudTrail 日誌。您可以利用這種檢閱根據使用者在 AWS 內實際執行的動作，建立適合的許可。[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 可根據存取活動[自動產生](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) IAM 政策。您可以在組織或帳戶層級使用 IAM Access Advisor 來[追蹤特定政策的最後存取資訊](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)。
+ **考慮使用 [AWS 受管政策來執行工作職能](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)**：當您開始制定精細的許可政策時，針對帳單、資料庫管理員和資料科學家等常見的任務角色使用 AWS 受管政策會很實用。這些政策可在您決定如何實施最低權限政策的同時，協助縮小使用者的存取權。
+ **移除不必要的許可：**偵測並移除未使用的 IAM 實體、憑證和許可，以實踐最低權限原則。您可以使用 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) 來識別外部和未使用的存取權，而 [IAM Access Analyzer 政策產生](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)功能可協助微調許可政策。
+ **確保使用者對生產環境具有有限的存取權：**使用者應只能存取具有有效使用案例的生產環境。在使用者執行完需要生產存取權的特定任務後，就應撤銷存取權。限制對生產環境的存取，有助於防止發生會影響生產的意外事件，也能降低意外存取的影響範圍。
+ **考慮使用許可界限：**[許可界限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)是一種使用受管政策功能，其主要設定以身分為基礎的政策可授予 IAM 實體的最大許可權限。實體的許可界限可讓其只執行由身分類型政策和其許可界限同時允許的動作。
+ **使用屬性型存取控制和資源標籤讓存取權更精簡**：(若支援) 使用資源標籤的[屬性型存取控制 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 可用來精簡許可。您可以使用 ABAC 模型，此模型會比較主體標籤與資源標籤，以根據您定義的自訂維度來精簡存取權。這種方法可以簡化並減少組織中的許可政策數量。
+ 建議僅在主體和資源皆為您的 AWS Organization 所擁有時，才使用 ABAC 進行存取控制。外部對象可以將與您的組織相同的標籤名稱和值，用於其自有主體和資源。如果您完全依賴這些名稱-值對來對外部對象的主體或資源授予存取權，則可能會提供意外的許可。
+ **使用 AWS Organizations 的服務控制政策：**[服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)可集中控制組織中成員帳戶的最大可用許可數。重要的是，您可以使用服務控制政策來限制成員帳戶中的根使用者許可。此外，還可以考慮使用 AWS Control Tower，它提供規範性受管控制，可以豐富 AWS Organizations。您也可以在 Control Tower 中定義自己的控制。
+ **為您的組織制定使用者生命週期政策：**使用者生命週期政策定義了當使用者上線至 AWS、變更職務或範圍或不再需要存取 AWS 時要執行的任務。在使用者生命週期的每個步驟進行許可審查，以確定許可受到適當限制並避免許可滲透的問題。
+ **建立定期審查許可的排程，並移除任何不需要的許可：**您應該定期審查使用者存取權，確認使用者沒有過度寬鬆的存取權。[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 和 IAM Access Analyzer 可在使用者許可稽核過程中提供協助。
+ **建立職務矩陣：**職務矩陣會以視覺化的方式顯示您 AWS 足跡內所需的各種角色和存取層級。利用職務對照表，即可根據組織內的使用者職責定義和區分許可。使用群組，而不是將許可直接套用至個別使用者或角色。
## 資源
**相關文件：**
+ [授予最低權限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [IAM 實體的許可界限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [用於寫入最低權限 IAM 政策的技巧](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer 會根據存取活動產生 IAM 政策，因此更容易實作最低權限許可](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [使用 IAM 許可界限將許可管理委派給開發人員](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [使用上次存取的資訊精簡許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [IAM 政策類型以及何時使用這些政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [使用 IAM 政策模擬器測試 IAM 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [AWS Control Tower 中的防護機制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [零信任架構：AWS 觀點](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [如何使用 CloudFormation StackSets 實作最低權限原則](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [屬性型存取控制 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [檢視使用者活動以縮小政策範圍](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [檢視角色存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)
+ [使用標記來組織您的環境並推動問責制](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [AWS 標記策略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [標記 AWS 資源](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**相關影片：**
+ [下一代許可管理](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [零信任：AWS 觀點](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 建立緊急存取程序
建立一項程序，在集中式身分提供者發生問題時，緊急存取您的工作負載。
您必須針對可能導致緊急事件發生的不同故障模式設計不同的程序。例如，正常情況下，您的員工使用者會使用集中式身分提供者 ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) 聯合至雲端，以管理其工作負載。不過，如果您的集中式身分提供者發生錯誤，或是雲端中聯合的組態經過修改，則您的員工使用者可能無法連至雲端。緊急存取程序可讓授權的管理員透過替代方式 (例如聯合或直接使用者存取的替代形式) 存取您的雲端資源，以修正聯合組態或工作負載的問題。緊急存取程序會持續使用，直到恢復正常聯合機制為止。
**預期成果：**
+ 您已定義並記載可視為緊急情況的故障模式：請考慮正常情況以及使用者用來管理工作負載的系統。考慮這些相依性如何發生錯誤並導致緊急情況。您可以在[可靠性支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html)中找到問題與最佳實務，有助於識別故障模式並架構更具彈性的系統，以盡量降低故障的可能性。
+ 您已記載確認故障為緊急情況須遵循的步驟。例如，您可以要求身分管理員檢查主要和待命身分提供者的狀態，如果兩者都無法使用，則發佈身分提供者發生錯誤緊急事件。
+ 您已針對每一種緊急或故障模式類型定義了緊急存取程序。明確定義可減少部分使用者過度使用一般程序，來處理所有類型的緊急情況。您的緊急存取程序描述了各個程序應在何種情況下使用，以及不應在哪些情況下使用，並指出可能適用的替代程序。
+ 您的程序完整記載了詳細指示和程序手冊，可快速有效地遵循。請記住，緊急事件對使用者來說可能會非常緊張，他們可能面對極大的時間壓力，因此程序的設計應盡可能簡單。
**常見的反模式：**
+ 您沒有詳細記載且經過充分測試的緊急存取程序。您的使用者未準備好面對緊急情況，而在緊急事件發生時只能隨機應變。
+ 您的緊急存取程序與正常存取機制依賴相同的系統 (例如集中式身分提供者)。這表示，一旦這類系統發生故障，就可能同時影響您的正常和緊急存取機制，並損及您從故障復原的能力。
+ 您的緊急存取程序用在非緊急情況。例如，您的使用者經常濫用緊急存取程序，因為他們發現直接進行變更透過管道提交變更容易。
+ 您的緊急存取程序未產生足夠的日誌來稽核程序，或是日誌未受監控，無法在發生可能濫用程序的情況時發出提醒。
**建立此最佳實務的優勢：**
+ 只要有詳細記載且經充分測試的緊急存取程序，就能縮短使用者回應和解決緊急事件所花的時間。這樣就能進一步減少停機時間，並為客戶帶來更高的服務可用性。
+ 您可以追蹤每一項緊急存取請求，以及偵測未經授權的人士試圖濫用程序來處理非緊急事件的情況，並發出提醒。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
本節提供建立緊急存取程序的指引，用於處理與 AWS 上部署的工作負載相關的數種故障模式，一開始先介紹適用於所有故障模式的通用指引，接著再根據故障模式類型說明特定指引。
**適用所有故障模式的通用指引**
為故障模式設計緊急存取程序時，請考慮下列事項：
+ 記載程序的前提和假設：應該和不應該使用程序的時機。這樣做有助於詳細說明故障模式並記載假設，例如其他相關系統的狀態。舉例來說，故障模式 2 的程序假設身分提供者可以使用，但 AWS 上的組態已經過修改或已過期。
+ 預先建立緊急存取程序所需的資源 ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html))。例如，在所有工作負載帳戶中預先建立具有 IAM 使用者和角色的緊急存取 AWS 帳戶，以及跨帳戶 IAM 使用者角色。這樣就可確定這些資源在緊急事件發生時立即可用。透過預先建立資源，您就不必依賴 AWS [控制平面](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) API (用來建立和修改 AWS 資源)，因為它們在緊急情況下可能無法使用。此外，預先建立 IAM 資源就不需考慮[因最終一致性而可能發生的延遲](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)。
+ 請將緊急存取程序納入您的事件管理計畫中 ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html))。記載緊急事件的追蹤方式，並傳達給組織中的其他人，例如同儕團隊、您的領導階層，以及適時向外傳達給您的客戶和業務合作夥伴。
+ 在您現有的服務請求工作流程系統 (若有的話) 中定義緊急存取請求程序。一般來說，這類工作流程系統可讓您建立接收表單來收集有關請求的資訊、在工作流程的每個階段追蹤請求，以及新增自動和手動核准步驟。將每一個請求與事件管理系統中追蹤的對應緊急事件建立關聯。採用統一的緊急存取系統，可讓您在單一系統中追蹤這些請求、分析使用趨勢並改善程序。
+ 確認您的緊急存取程序只能由經授權的使用者啟動，並且視情況要求使用者同儕或管理層的核准。核准程序在營業時間內外都要能夠有效運作。定義在主要核准者沒有空的情況下，如何由次要核准者核准請求，以及如何在您的管理鏈中向上呈報，直到請求獲得核准。
+ 實作可靠的記錄、監控和警示機制，以因應緊急存取程序和機制。同時針對成功和失敗的嘗試產生詳細的稽核日誌，以便取得緊急存取權。在事件管理系統中將活動與正在發生的事件相互關聯，並在動作發生於預期時段之外，或在正常操作期間使用緊急存取帳戶時發出警示。緊急存取帳戶只能在緊急情況下存取，因為破窗程序也可視為後門。與您的安全資訊和事件管理 (SIEM) 工具或 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 整合，以在緊急存取期間回報和稽核所有活動。恢復正常操作時，自動輪換緊急存取憑證，並通知相關團隊。
+ 定期測試緊急存取程序，以確認步驟是否清楚，並且快速有效地授予正確的存取層級。您的緊急存取程序應在事件回應模擬的過程中 ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) 和災難復原測試中 ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)) 進行測試。
**故障模式 1：用於聯合至 AWS 的身分提供者無法使用**
如 [SEC02-BP04 仰賴集中化的身分提供者](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)中所述，我們建議您仰賴集中式身分提供者來聯合您的員工使用者，以授予 AWS 帳戶 的存取權。您可以使用 IAM Identity Center 聯合至您 AWS 組織中的多個 AWS 帳戶，或是使用 IAM 聯合至個別 AWS 帳戶。在這兩種情況下，員工使用者都會先透過集中式身分提供者進行身分驗證，然後才重新導向至 AWS 登入端點進行單一登入。
萬一您的集中式身分提供者無法使用，您的員工使用者就無法聯合至 AWS 帳戶 或管理其工作負載。在此緊急事件中，您可以提供緊急存取程序讓一小群管理員存取 AWS 帳戶，以便執行無法等到集中式身分提供者恢復連線後才處理的重要工作。例如，您的身分提供者停擺了 4 小時，而在此期間，您需要修改生產帳戶中 Amazon EC2 Auto Scaling 群組的上限，以處理客戶流量意外暴增的情況。您的緊急管理員應遵循緊急存取程序，才能獲得特定生產 AWS 帳戶 的存取權並進行必要的變更。
緊急存取程序依賴預先建立的緊急存取 AWS 帳戶，該帳戶單純用於緊急存取，並擁有 AWS 資源 (例如 IAM 角色和 IAM 使用者) 可支援緊急存取程序。在正常操作期間，任何人都不應該存取緊急存取帳戶，而且您必須監控濫用此帳戶的情況並發出提醒 (如需詳細資訊，請參閱前一節「通用指引」)。
緊急存取帳戶具有緊急存取 IAM 角色，有權在需要緊急存取的 AWS 帳戶 中擔任跨帳戶角色。這些 IAM 角色會預先建立並設定信任政策，以便信任緊急帳戶的 IAM 角色。
緊急存取程序可以使用下列其中一種方法：
+ 您可以預先建立一組 [IAM 使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)並包含關聯的強式密碼和 MFA 字符，以供緊急存取帳戶中的緊急管理員使用。這些 IAM 使用者有權擔任 IAM 角色，且後續可在需要緊急存取時跨帳戶存取 AWS 帳戶。我們建議這類使用者的數量越少越好，並且將每一位使用者指派給單一緊急管理員。在緊急情況下，緊急管理員使用者會使用其密碼和 MFA 字符代碼登入緊急存取帳戶，切換到緊急帳戶中的緊急存取 IAM 角色，最後再切換到工作負載帳戶中的緊急存取 IAM 角色，以執行緊急變更動作。這種方法的優點是，每個 IAM 使用者都會指派給一名緊急管理員，而且您可以透過審核 CloudTrail 事件得知登入的使用者。缺點是，您必須維護多個 IAM 使用者及其關聯的長期存在密碼和 MFA 字符。
+ 您可以使用緊急存取 [AWS 帳戶 根使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)來登入緊急存取帳戶、擔任緊急存取的 IAM 角色，並且在工作負載帳戶中擔任跨帳戶角色。我們建議您為根使用者設定強式密碼和多個 MFA 字符。同時也建議您，將密碼和 MFA 字符儲存在強制執行強式身分驗證和授權的安全企業憑證保存庫中。您應確保密碼和 MFA 字符重設要素的安全性：將帳戶的電子郵件地址設定為受到您的雲端安全管理員監控的電子郵件分發清單，並將帳戶的電話號碼設定為同樣受到安全管理員監控的共用電話號碼。這種方法的優點是，只需管理一組根使用者憑證。缺點是，由於這是共用使用者，因此有多個管理員能夠以根使用者的身分登入。您必須稽核企業保存庫日誌事件，以確定哪個管理員簽出了根使用者密碼。
**故障模式 2：AWS 上的身分提供者組態已經過修改或已過期**
若要讓您的員工使用者聯合至 AWS 帳戶，您可以使用外部身分提供者設定 IAM Identity Center，或建立 IAM 身分提供者 ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html))。一般來說，您可以匯入身分提供者提供的 SAML 中繼資料 XML 文件來進行這些設定。中繼資料 XML 文件包含一個 X.509 憑證，對應於身分提供者用來簽署其 SAML 聲明的私有金鑰。
AWS 端的這些組態可能遭到管理員誤改或誤刪。另一種情況是，匯入 AWS 中的 X.509 憑證可能過期，而具有新憑證的新中繼資料 XML 尚未匯入 AWS 中。這兩種情況都可能使員工使用者的 AWS 聯合中斷，導致緊急情況發生。
在這類緊急事件中，您可以提供 AWS 的存取權給身分管理員，以修正聯合問題。例如，您的身分管理員使用緊急存取程序登入緊急存取 AWS 帳戶、切換為 Identity Center 管理員帳戶中的角色，並透過從您的身分提供者匯入最新的 SAML 中繼資料 XML 文件來更新外部身分提供者組態，以重新啟用聯合。聯合修復後，您的員工使用者繼續使用正常操作程序來聯合至其工作負載帳戶。
您可以依照先前「故障模式 1」中詳述的方法來建立緊急存取程序。您可以將最低權限許可授予身分管理員，以限制他們只能存取 Identity Center 管理員帳戶以及在該帳戶中對 Identity Center 執行動作。
**故障模式 3：Identity Center 中斷**
萬一發生 IAM Identity Center 或 AWS 區域 中斷的情況，建議您設定一個可用來暫時存取 AWS 管理主控台 的組態。
緊急存取程序會在緊急帳戶中，使用您的身分提供者對 IAM 的直接聯合。如需有關程序和設計考量的詳細資訊，請參閱[設定 AWS 管理主控台 的緊急存取](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)。
### 實作步驟
**適用所有故障模式的通用步驟**
+ 建立緊急存取程序專用的 AWS 帳戶。在帳戶中預先建立所需的 IAM 資源，例如 IAM 角色或 IAM 使用者，也可以選擇建立 IAM 身分提供者。此外，在工作負載 AWS 帳戶 中預先建立跨帳戶 IAM 角色，並與緊急存取帳戶中對應的 IAM 角色建立信任關係。您可以使用 [CloudFormation StackSets 搭配 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) 在組織的成員帳戶中建立此類資源。
+ 建立 AWS Organizations [服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) 以拒絕刪除和修改成員 AWS 帳戶 中的跨帳戶 IAM 角色。
+ 為緊急存取 AWS 帳戶 啟用 CloudTrail，並將追蹤事件傳送到日誌收集 AWS 帳戶 中的中央 S3 儲存貯體。如果您使用 AWS Control Tower 來設定和管控您的 AWS 多帳戶環境，則您使用 AWS Control Tower 建立或在 AWS Control Tower 中註冊的每個帳戶都會預設啟用 CloudTrail，並傳送至專用日誌封存 AWS 帳戶 中的 S3 儲存貯體。
+ 透過建立在主控台登入時比對的 EventBridge 規則來監控活動的緊急存取帳戶，以及透過緊急 IAM 角色監控 API 活動。當活動於事件管理系統中追蹤的持續緊急事件之外發生時，傳送通知給您的安全營運中心。
**適用「故障模式 1：用於聯合至 AWS 的身分提供者無法使用」及「故障模式 2：AWS 上的身分提供者組態已經過修改或已過期」的其他步驟**
+ 根據您選擇的緊急存取機制預先建立資源：
+ **使用 IAM 使用者：**預先建立 IAM 使用者並設定強式密碼和關聯的 MFA 裝置。
+ **使用緊急帳戶根使用者：**設定根使用者使用強式密碼，並將密碼儲存在您的企業憑證保存庫中。將多個實體 MFA 裝置與根使用者建立關聯，並將裝置儲存在您的緊急管理員小組成員可快速存取的位置。
**適用「故障模式 3：Identity Center 中斷」的其他步驟**
+ 如[設定 AWS 管理主控台 的緊急存取](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)中所述，在緊急存取 AWS 帳戶 中，建立 IAM Identity Provider 身分提供者，以從您的身分提供者啟用直接 SAML 聯合。
+ 在 IdP 中建立緊急操作群組，但不新增任何成員。
+ 在緊急存取帳戶中建立對應於緊急操作群組的 IAM 角色。
## 資源
**相關 Well-Architected 的最佳實務：**
+ [SEC02-BP04 仰賴集中式身分提供者](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 授予最低權限存取權](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 制定事件管理計畫](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 執行演練日](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**相關文件：**
+ [設定 AWS 管理主控台 的緊急存取](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [使 SAML 2.0 聯合身分使用者能夠存取 AWS 管理主控台](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [緊急存取](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**相關影片：**
+ [AWS re:Invent 2022 - 使用 IAM Identity Center 簡化現有的員工存取權](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) 深入剖析](https://youtu.be/YMj33ToS8cI)
**相關範例：**
+ [AWS 緊急存取角色](https://github.com/awslabs/aws-break-glass-role)
+ [AWS 客戶程序手冊架構](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS 事件回應程序手冊範例](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 持續減少許可
在團隊確定所需的存取權時，請移除不需要的許可，並建立審查程序以達到最低權限的許可。持續監視人類和機器存取權，並移除不使用的身分和許可。
**預期成果：**許可政策應遵循最低權限原則。隨著工作職責和角色的定義變得更具體，您需要審查許可政策以移除不必要的許可。若憑證遭到意外洩露或以其他方式在未經授權下遭存取，此方法可縮小影響範圍。
**常見的反模式：**
+ 預設授予使用者管理員許可。
+ 建立過於寬鬆的政策，但不具完整的管理員權限。
+ 保留不再需要的許可政策。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
在團隊和專案剛開始時，可使用寬鬆的許可政策來激發創新和敏捷性。例如，在開發或測試環境中，可以讓開發人員存取廣泛的 AWS 服務。我們建議您持續評估存取權，並將存取權限於完成目前工作所需的這些服務和服務動作。我們建議對人類和機器身分進行此項評估。機器身分有時候稱為系統或服務帳戶，是提供 AWS 存取權給應用程式或伺服器的身分。此存取權在生產環境中尤為重要，因為過於寬鬆的許可可能影響廣大而且可能暴露客戶資料。
AWS 提供多種方法可協助識別未使用的使用者、角色、許可和憑證。AWS 也有助於分析 IAM 使用者和角色的存取活動，包括關聯的存取金鑰，以及對 AWS 資源的存取，例如 Amazon S3 儲存貯體中的物件。AWS Identity and Access Management Access Analyzer 政策產生可協助您根據某主體進行互動的實際服務和動作來建立限制性許可。[屬性型存取控制 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 可以協助簡化許可管理，因為您可以使用使用者的屬性提供許可給使用者，而不是將許可政策直接連接至每個使用者。
### 實作步驟
+ **使用 [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)：**IAM Access Analyzer 可協助您識別組織和帳戶中[與外部實體共用](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html)的資源，例如 Amazon Simple Storage Service (Amazon S3) 儲存貯體或 IAM 角色。
+ **使用 [IAM Access Analyzer 政策產生](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)：**IAM Access Analyzer 政策產生可協助您[根據 IAM 使用者或角色的存取活動建立精細的許可政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks)。
+ **在正式作業前測試較低環境的許可：**一開始先使用[較不重要的沙盒和開發環境](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html)，利用 IAM Access Analyzer 來測試各種不同工作職能所需的許可。然後在測試、品質保證和預備環境逐步加強並驗證這些許可，再將許可套用至正式作業環境。較低的環境一開始可以擁有較寬鬆的許可，因為服務控制政策 (SCP) 會透過限制授予的許可數上限來強制執行防護機制。
+ **為 IAM 使用者和角色確定可接受的時間範圍和使用政策：**使用[上次存取的時間戳記](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html)以[識別未使用的使用者和角色](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/)並將其移除。審核服務和動作上次存取的資訊，以識別和[設定特定使用者和角色的許可範圍](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)。例如，您可以使用上次存取的資訊來識別您的應用程式角色所需的特定 Amazon S3 動作，並將該角色的存取權僅限於這些動作。AWS 管理主控台 中有提供「上次存取的資訊」功能，並且可讓您透過程式設計的方式將這些功能併入基礎設施工作流程和自動化工具中。
+ **考慮[在 AWS CloudTrail 中日誌記錄資料事件](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html)：**在預設情況下，CloudTrail 不會記錄資料事件，例如 Amazon S3 物件層級活動 (如 `GetObject` 和 `DeleteObject`) 或 Amazon DynamoDB 資料表活動 (如 `PutItem` 和 `DeleteItem`)。考慮對這些事件使用日誌記錄功能，以確定哪些使用者和角色需要存取特定 Amazon S3 物件或 DynamoDB 資料表項目。
## 資源
**相關文件：**
+ [授予最低權限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [移除不必要的憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [ 什麼是 AWS CloudTrail？](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [使用 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [ DynamoDB 中的日誌記錄和監控](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ 對您的 Amazon S3 儲存貯體和物件使用 CloudTrail 事件日誌記錄](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ 取得 AWS 帳戶 的憑證報告](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**相關影片：**
+ [在 60 分鐘內精通 IAM 政策](https://youtu.be/YQsK4MtsELU)
+ [責任區隔、最低權限、委派和 CI/CD](https://youtu.be/3H0i7VyTu70)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) 深入剖析](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 為您的組織定義許可防護機制
使用許可防護機制縮小可授予主體的可用許可範圍。許可政策評估鏈包括您的防護機制，可在進行授權決策時確定主體的*有效許可*。 您可以採用分層方式定義防護機制。對整個組織廣泛套用一些防護機制，另外對暫時存取工作階段套用一些精細的防護機制。
**預期成果：**您可以使用個別 AWS 帳戶 對環境進行明確的隔離。 服務控制政策 (SCP) 用於定義整個組織的許可防護機制。較寬鬆的防護機制設定於最靠近組織根目錄的階層層級，較嚴謹的防護機制則設定於較靠近個別帳戶的層級。
在受支援的情況下，資源政策會定義主體必須滿足才能取得資源存取權的條件。資源政策也會適時縮小允許的動作範圍。許可界限會設置在管理工作負載許可的主體上，以將許可管理委派給個別工作負載擁有者。
**常見的反模式：**
+ 在 [AWS 組織](https://aws.amazon.com/organizations/)內建立成員 AWS 帳戶，但未使用 SCP 來限制其根憑證適用的用途和許可。
+ 根據最低權限指派許可，但未對可授予的許可集上限設置防護機制。
+ 仰賴 AWS IAM 的*隱含拒絕*基礎來限制許可，相信政策不會授予不需要的*明確允許*許可。
+ 在相同 AWS 帳戶 中執行多個工作負載環境，然後仰賴 VPC、標籤或資源政策等機制來強制執行許可界限。
**建立此最佳實務的優勢：**許可防護機制有助於建立信心，確保不會有不需要的許可授予情況，即使許可政策嘗試這樣做也不必擔心。 此最佳實務可透過縮小需考量的許可範圍上限來簡化定義和管理許可。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
建議您採用分層方式為您的組織定義許可防護機制。此方法能夠隨著套用額外的分層，有系統地減少可能的許可集上限。這可協助您根據最低權限原則授予存取權，降低了因政策組態錯誤導致意外存取的風險。
建立許可防護機制的第一步，是將您的工作負載和環境隔離到個別 AWS 帳戶 中。在沒有明確許可的情況下，某一帳戶中的主體無法存取另一帳戶中的資源，即使兩個帳戶在相同 AWS 組織中或在相同[組織單位 (OU)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) 下亦是如此。您可以使用 OU 將您要管理的帳戶分組為一個單位。
下一步是減少您可授予組織的成員帳戶內主體的許可集上限。您可以使用[服務控制政策 (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 達到此目的，這些政策可套用至 OU 或帳戶。SCP 可強制執行通用的存取控制，例如限制對特定 AWS 區域 的存取、協助防止資源遭到刪除，或停用有潛在風險的服務動作。您套用至組織根目錄的 SCP 只會影響其成員帳戶，而不會影響管理帳戶。 SCP 只會控管組織內的主體。您的 SCP 不會控管組織外部存取您資源的主體。
如果您使用 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)，則可以利用其[控制項](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work)和[登陸區域](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)做為許可防護機制和多帳戶環境的基礎。登陸區域提供預先設定的安全基準環境，當中採用不同的帳戶來處理不同的工作負載和應用程式。防護機制透過服務控制政策 (SCP)、AWS Config 規則及其他組態的組合，強制執行有關安全、操作和合規的強制性控制。不過，同時使用 Control Tower 防護機制和登陸區域與自訂 Organization SCP 時，務必遵循 AWS 文件中所述的最佳實務，以避免衝突並確保適當的控管。如需在 Control Tower 環境中管理 SCP、帳戶和組織單位 (OU) 的詳細建議，請參閱 [AWS Organizations 的 AWS Control Tower 指引](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html)。
只要遵循這些指引，您就能有效利用 Control Tower 的防護機制、登陸區域和自訂 SCP，同時減少前在衝突，並確保適當控管與控制多帳戶 AWS 環境。
再下一步是使用 [IAM 資源政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)來設定您可對其控管的資源執行的可用動作範圍，以及設定執行動作的主體必須符合的任何條件。這個範圍可以很廣泛，例如只要主體屬於組織的一部分就允許所有動作 (使用 PrincipalOrgId [條件金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html))，也可以很精細，例如只允許特定 IAM 角色執行特定動作。您可以在 IAM 角色信任政策中採取類似方法，並附帶條件。 如果資源或角色信任政策明確指名相同帳戶中的某個主體作為其控管的角色或資源，則該主體不需要有授予相同許可的連接 IAM 政策。 如果主體位於與資源不同的帳戶中，則該主體確實需要有授予這些許可的連接 IAM 政策。
通常，工作負載團隊會希望管理其工作負載需要的許可。 這樣一來，他們便需要建立新的 IAM 角色和許可政策。 您可以擷取允許團隊在 [IAM 許可界限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)中授予的許可範圍上限，並將此文件與 IAM 角色關聯，之後團隊就可使用該角色來管理其 IAM 角色和許可。 這種方法可讓他們彈性地完成其工作，同時降低擁有 IAM 管理存取權的風險。
更詳細的步驟是實作*特殊權限存取管理* (PAM) 和*暫時提升存取管理* (TEAM) 技術。 PAM 的範例是，要求主體在採取特殊權限動作之前執行多重要素驗證。 如需詳細資訊，請參閱[設定受 MFA 保護的 API 存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。TEAM 需要使用解決方案來管理允許主體擁有已提升存取權的核准和時間範圍。 其中一種方法是暫時將主體新增至具有已提升存取權之 IAM 角色的角色信任政策中。 另一種方法是在正常操作情況下，使用[工作階段政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)縮小 IAM 角色授予主體的許可範圍，然後在核准時段暫時解除此限制。若要進一步了解已經過 AWS 和精選合作夥伴驗證的解決方案，請參閱[暫時提升的存取權](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html)。
### 實作步驟
1. 將您的工作負載和環境隔離到個別 AWS 帳戶 中。
1. 使用 SCP 減少可授予組織的成員帳戶內主體的許可集上限。
1. 定義 SCP 以減少可授予組織成員帳戶中主體的許可集上限時，您可以選擇*允許清單*或*拒絕清單*方法。允許清單策略會明確指定允許的存取權，並隱含地封鎖所有其他存取權。拒絕清單策略會明確指定不允許的存取權，並預設允許所有其他存取權。這兩種策略各有其優點和權衡，而適當的選擇取決於組織的特定要求和風險模型。如需詳細資訊，請參閱[使用 SCP 的策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html)。
1. 此外，請查看[服務控制政策範例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)，了解如何有效地建構 SCP。
1. 使用 IAM 資源政策可縮小資源上許可動作的範圍並指定條件。 在 IAM 角色信任政策中使用條件來建立擔任角色的限制。
1. 將 IAM 許可界限指派至 IAM 角色，之後工作負載團隊可以使用這些角色來管理自己的工作負載 IAM 角色和許可。
1. 根據您的需求評估 PAM 和 TEAM 解決方案。
## 資源
**相關文件：**
+ [ 上的資料周邊AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [使用資料周邊建立許可防護機制](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [政策評估邏輯](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**相關範例：**
+ [服務控制政策範例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**相關工具：**
+ [AWS 解決方案：暫時提升存取管理](https://aws-samples.github.io/iam-identity-center-team/)
+ [適用 TEAM 的已驗證安全合作夥伴解決方案](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 根據生命週期管理存取
監控並調整授予您的主體 (使用者、角色和群組) 在組織內其整個生命週期的許可。隨著使用者變更角色調整群組成員資格，並在使用者離開組織時移除存取權。
**預期成果**您可在組織內監控並調整主體整個生命週期的許可，進而降低不必要權限帶來的風險。您可在建立使用者時授予適當的存取權。您可以隨著使用者的職責變更修改存取權，並且在使用者不再為作用中狀態或離開組織時移除存取權。您可以集中管理使用者、角色和群組的變更。您使用自動化的方式將變更傳播到您的 AWS 環境。
**常見的反模式：**
+ 事先授予身分過多或過廣的存取權限，超過最初所需的範圍。
+ 當身分的角色和職責隨時間發生變更後，未能審查並調整存取權限。
+ 未移除非作用中或已終止身分的作用中存取權限。此舉會增加未經授權存取的風險。
+ 未利用自動化來管理身分的生命週期。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
在身分的整個生命週期中，仔細管理和調整您授予身分 (例如使用者、角色、群組) 的存取權限。此生命週期涵蓋初始入職階段、後續角色和職責變更，以及最終離職或終止。根據生命週期階段主動管理存取權，以維護適當的存取層級。遵守最低權限原則，以降低過度或不必要存取權限帶來的風險。
您可以直接在 AWS 帳戶 內管理 IAM 使用者的生命週期，或透過從人力資源身分提供者至 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 的聯合來進行管理。針對 IAM 使用者，您可以在 AWS 帳戶 內建立、修改和刪除使用者及其關聯的許可。針對聯合身分使用者，您可以使用 IAM Identity Center 管理生命週期，方法是透過[跨網域身分管理系統](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) (SCIM) 協定，同步源自您組織身分提供者的使用者和群組資訊。
SCIM 是開放標準協定，可在不同系統中自動佈建和解除佈建使用者身分。透過將身分提供者與使用 SCIM 的 IAM Identity Center 整合，您就可以自動同步使用者和群組資訊，協助驗證組織是否根據其授權身分來源的變更授予、修改或撤銷存取權限。
隨著組織內員工的角色和職責改變，調整他們的存取權限。您可以使用 IAM Identity Center 的許可集來定義不同的工作角色或職責，並將其與適當的 IAM 政策和許可關聯。當員工的角色變更時，您可以更新其指派的許可集，以反映他們的新職責。確認他們具有必要的存取權，同時遵守最低權限原則。
### 實作步驟
1. 定義並記錄存取管理生命週期流程，包括授予初始存取權、定期審查和離職的程序。
1. 實作 [IAM 角色、群組和許可界限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)，以共同管理存取權，並強制執行受允許的最高存取層級。
1. 使用 IAM Identity Center 與[聯合身分提供者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) (例如 Microsoft Active Directory、Okta、Ping Identity) 整合，使其做為使用者和群組資訊的授權來源。
1. 使用 [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) 協定可將來自身分提供者的使用者和群組資訊同步到 IAM Identity Center 的身分存放區中。
1. 在 IAM Identity Center 中建立[許可集](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)，以代表組織內不同的工作角色或職責。為每個許可集定義適當的 IAM 政策和許可。
1. 實作定期存取權審查、提示撤銷存取權，以及持續改進存取權管理生命週期流程。
1. 為員工提供有關存取權管理最佳實務的培訓和認知。
## 資源
**相關的最佳實務：**
+ [SEC02-BP04 仰賴集中式身分提供者](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**相關文件：**
+ [管理您的身分來源](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [管理 IAM Identity Center 中的身分](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [使用 AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [IAM Access Analyzer 政策產生](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**相關影片：**
+ [AWS re:Inforce 2023 - 使用 AWS IAM Identity Center 管理暫時提升的存取權](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:Invent 2022 - 使用 IAM Identity Center 簡化現有的員工存取權](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:Invent 2022 - 使用 Access Analyzer 掌握 IAM 政策之力並駕馭許可](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 分析公有和跨帳戶存取權
持續監控強調公有和跨帳戶存取權的調查結果。減少僅對需要此存取之特定資源的公有存取權和跨帳戶存取權。
**預期成果：**知道您共用了哪些 AWS 資源以及共用的對象。持續監控和稽核您共用的資源以確認這些資源僅與已授權主體共用。
**常見的反模式：**
+ 沒有維持共用資源的詳細目錄。
+ 未遵循程序來核准跨帳戶或資源的公有存取權。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
如果您的帳戶位於 AWS Organizations 中，您可以將資源的存取權授予整個組織、特定組織單位或個別帳戶。如果您的帳戶不是組織的成員，您可以與個別帳戶共用資源。您可以使用以資源為基礎的政策 (例如 [Amazon Simple Storage Service (Amazon S3) 儲存貯體政策](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)) 來授予直接跨帳戶存取權，或允許另一個帳戶中的主體擔任您帳戶中的 IAM 角色。當使用資源政策時，確認僅將該存取權授予已授權的主體。定義程序，來核准所有需要公開提供的資源。
[AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) 採用[可證明的安全性](https://aws.amazon.com/security/provable-security/)來識別從其帳戶外部存取資源的所有路徑。它會持續審查資源政策，並報告公有和跨帳戶存取權的調查結果，讓您輕鬆分析潛在的各種存取。考慮使用 AWS Organizations 設定 IAM Access Analyzer，以確認您對所有帳戶具有可見性。IAM Access Analyzer 也允許您在部署資源許可之前[預覽調查結果](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)。這可讓您驗證政策變更是否僅授予對您資源的預期公有和跨帳戶存取權。設計多帳戶存取權時，您可以使用[信任政策](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)來控制可以擔任角色的情況。例如，您可以使用 [`PrincipalOrgId` 條件金鑰來拒絕嘗試從 AWS Organizations](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) 外部擔任角色的動作。
[AWS Config 可以報告設定不當的資源](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html)，並可透過 AWS Config 政策檢查來偵測已設定公開存取的資源。諸如 [AWS Control Tower](https://aws.amazon.com/controltower/) 和 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 的服務可簡化在 AWS Organizations 間部署控制和防護機制的作業，以識別和修正公開暴露的資源。例如，AWS Control Tower 具備受管的防護機制，可偵測是否有任何[可由 AWS 帳戶 還原的 Amazon EBS 快照](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)。
### 實作步驟
+ **考慮[對 AWS Organizations 使用 AWS Config](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)：** AWS Config 可讓您將 AWS Organizations 內來自多個帳戶的調查結果彙總到一個委派的管理員帳戶。這提供了全面性檢視，並讓您[在帳戶間部署 AWS Config 規則 以偵測公開可存取的資源](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)。
+ **設定 AWS Identity and Access Management Access Analyzer：**IAM Access Analyzer 可協助您識別組織及帳戶中[與外部實體共用](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html)的資源，例如 Amazon S3 儲存貯體或 IAM 角色。
+ **使用 AWS Config 中的自動修復以回應 Amazon S3 儲存貯體的公開存取設定中的變更：**[您可以自動開啟 Amazon S3 儲存貯體的封鎖公開存取設定](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)。
+ **實作監控和提醒以識別 Amazon S3 儲存貯體是否已變為公有：**您必須設立[監控和提醒](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/)以識別何時關閉 Amazon S3 封鎖公開存取，以及 Amazon S3 儲存貯體是否變為公有。此外，如果您正在使用 AWS Organizations，可以建立[服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)來防止對 Amazon S3 公開存取政策進行變更。[AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) 會檢查具有公開存取許可的 Amazon S3 儲存貯體。將上傳或刪除存取權授予每個人的儲存貯體許可，可讓任何人在儲存貯體中新增、修改或移除項目，進而產生潛在的安全問題。Trusted Advisor 檢查會分析明確的儲存貯體許可，以及可能覆寫儲存貯體許可的關聯儲存貯體政策。您也可以使用 AWS Config 來監控 Amazon S3 儲存貯體的公開存取。如需詳細資訊，請參閱[如何使用 AWS Config 來監控及回應允許公開存取的 Amazon S3 儲存貯體](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)。
檢閱 Amazon S3 儲存貯體的存取控制時，請務必考量儲存於其中的資料性質。[Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) 是一項服務，其設計在於協助您探索和保護敏感資料，例如個人身分識別資訊 (PII)、受保護健康資訊 (PHI)，以及私有金鑰或 AWS 存取金鑰等憑證。
## 資源
**相關文件：**
+ [使用 AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [AWS Control Tower 控制程式庫](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [AWS 基礎安全最佳實務標準](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [AWS Config 受管規則](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [AWS Trusted Advisor 檢查參考](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [ 使用 Amazon EventBridge 監控 AWS Trusted Advisor 檢查結果](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [ 管理組織內所有帳戶間的 AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config 和 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [在 Amazon EC2 中公開提供您的 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**相關影片：**
+ [保護多帳戶環境的最佳實務](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [深入了解 IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 在組織內安全地共用資源
隨著工作負載數量增加，您可能需要在這些工作負載內共用對資源的存取，或在多個帳戶間多次佈建資源。您可能具備劃分環境 (例如擁有開發、測試和生產環境) 的建構模組。然而，擁有分隔建構模組並不會限制您安全共用的能力。透過共用重疊的元件，您可以降低營運負擔並允許一致的體驗，而不用猜測在多次建立相同的資源時可能錯過了什麼。
**預期成果：**使用安全方法在組織內共用資源，藉此充分減少意外存取，並協助您的資料外洩防護計畫。減輕與管理個別元件相較下的營運負擔，減少多次手動建立相同元件的錯誤，以及增加工作負載的可擴展性。您可以從多點失敗案例中更短的解決時間獲益，並更有信心確定何時不再需要某元件。如需有關分析外部共用的資源的方案指引，請參閱 [SEC03-BP07 分析公有和跨帳戶存取權](sec_permissions_analyze_cross_account.md)。
**常見的反模式：**
+ 缺乏可持續監控和自動發出意外外部共用通知的程序。
+ 對於應該和不應該共用的內容缺乏基準。
+ 預設採用廣泛的開放政策而不是在必要時明確共用。
+ 必要時手動建立重疊的基礎資源。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
建構您的存取控制和模式來管控安全地取用共用資源並只與信任的實體共用。監控共用資源並持續審查共用資源存取，在不當或意外共用時獲得提醒。審核[分析公開和跨帳戶存取權](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)協助您確立管控能力以減少外部存取，而僅限於需要存取的資源，以及建立程序持續監控並自動提供提醒。
在 AWS Organizations 內跨帳戶共用受到[數個 AWS 服務](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)的支援，例如 [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html)、[Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) 和 [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html)。這些服務允許將資料共用到中央帳戶，從中央帳戶存取，或從中央帳戶管理資源和資料。例如，AWS Security Hub CSPM 可以將調查結果從個別帳戶轉移到中央帳戶，讓您能夠檢視所有調查結果。AWS Backup 可以對資源進行備份並在帳戶之間共用。您可以使用 [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) 來共用其他常見的資源，例如 [VPC 子網路和 Transit Gateway 附件](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc)、[AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) 或 [Amazon SageMaker AI 管道](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)。
若要將您的帳戶限制為僅共用組織內的資源，請使用[服務控制政策 (SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) 防止存取外部主體。當共用資源時，結合身分型控制和網路控制[為您的組織建立資料周邊](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)，以協助預防意外存取。資料周邊是一組預防性防護機制，可協助確認只有可信的身分從預期網路存取可信的資源。這些控制應適當限制可以共用哪些資源，並防止共用或公開不應該允許的資源。例如，作為資料周邊的一部分，您可以使用 VPC 端點政策和 `AWS:PrincipalOrgId` 條件來確保存取 Amazon S3 儲存貯體的身分屬於您的組織。請務必注意，[SCP 不適用於連結服務的角色或 AWS 服務主體](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions)。
當使用 Amazon S3 時，請[關閉 Amazon S3 儲存貯體的 ACL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) 並使用 IAM 政策來定義存取控制。若要[限制從](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 對 Amazon S3 原點的存取，請從原始存取身分 (OAI) 遷移至原始存取控制 (OAC)，後者支援額外的功能，包括使用 [AWS Key Management Service](https://aws.amazon.com/kms/) 的伺服器端加密。
在某些情況下，您可能會想要允許在組織外部共用資源或將資源的存取權授予第三方。如需有關管理許可以在外部共用資源的方案指引，請參閱[許可管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)。
### 實作步驟
1. **使用 AWS Organizations：**AWS Organizations 是一項帳戶管理服務，可讓您將多個 AWS 帳戶 整合到您所建立和集中管理的組織中。您可以將帳戶編組成組織單位 (OU) 並將不同的政策連接至各個 OU，以協助滿足您的預算、安全和合規需求。您也可以控制 AWS 人工智慧 (AI) 和機器學習 (ML) 服務收集和儲存資料的方式，並使用與 Organizations 整合的 AWS 服務的多帳戶管理功能。
1. **將 AWS Organizations 與 AWS 服務整合：**當您啟用 AWS 服務代表您在組織的成員帳戶中執行任務時，AWS Organizations 會在每個成員帳戶中為該服務建立 IAM 服務連結角色 (SLR)。您應該使用 AWS 管理主控台、AWS API 或 AWS CLI 來管理可信存取。如需有關開啟可信存取的方案指引，請參閱[使用 AWS Organizations 與其他 AWS 服務](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html)以及[您可以搭配 Organizations 使用的 AWS 服務](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)。
1. **建立資料周邊：**資料周邊提供明確的信任和所有權界限。在 AWS 上，它通常表示為 AWS Organizations 所管理的組織 AWS，以及存取您的 AWS 資源的任何內部部署網路或系統。資料周邊的目標是要確認若身分可信、資源可信且是預期的網路，則允許存取。不過，建立資料周邊並非一體適用的方法。請根據您的特定安全風險模型和須求，評估和採用[在 AWS 上建立周邊白皮書](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html)中所述的控制目標。您應仔細考慮您獨特的風險狀態，並實作符合您安全需求的周邊控制。
1. **使用 AWS 服務中的資源共用並適當限制：**許多 AWS 服務都可讓您與另一個帳戶共用資源，或鎖定另一個帳戶中的資源，例如 [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 和 [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html)。限制 `ModifyImageAttribute` API 以指定可信帳戶來共用 AMI。當使用 AWS RAM 來限制僅共用至您的組織時，指定 `ram:RequestedAllowsExternalPrincipals` 條件來協助防止不受信任的身分的存取。如需方案指引和考量，請參閱[資源共用和外部目標](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html)。
1. **使用 AWS RAM 在帳戶中或與其他 AWS 帳戶 安全地共用：**[AWS RAM](https://aws.amazon.com/ram/) 可協助您安全地將您使用帳戶中的角色和使用者所建立的資源與其他 AWS 帳戶 共用。在多帳戶環境中，AWS RAM 可讓您建立資源一次並與其他帳戶共用。這個方法有助於降低營運負擔，同時透過與 Amazon CloudWatch 和 AWS CloudTrail 的整合提供一致性、可見性和可稽核性，這是在使用跨帳戶存取權時所沒有的。
如果您擁有之前使用以資源為基礎的政策共用的資源，可以使用 [`PromoteResourceShareCreatedFromPolicy` API](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) 或同等項目將資源共用升級到完整 AWS RAM 資源共用。
在某些情況下，您可能需要採取額外步驟來共用資源。例如，若要共用加密快照，您需要[共用 AWS KMS 金鑰](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key)。
## 資源
**相關的最佳實務：**
+ [SEC03-BP07 分析公有和跨帳戶存取權](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 安全地與第三方共用資源](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 建立網路層](sec_network_protection_create_layers.md)
**相關文件：**
+ [儲存貯體擁有者將跨帳戶許可授予非其擁有的物件](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [如何使用信任政策搭配 IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [在 AWS 上建置資料周邊](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [向第三方授予對 AWS 資源的存取權限時如何使用外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [可與 AWS Organizations 搭配使用的 AWS 服務](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ 在 AWS 上建立資料周邊：僅允許可信身分存取公司資料](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**相關影片：**
+ [使用 AWS Resource Access Manager 進行精密的存取](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [使用 VPC 端點確保資料周邊的安全](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ 在 AWS 上建立資料周邊](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**相關工具：**
+ [ 資料周邊政策範例](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 安全地與第三方共用資源
您雲端環境的安全並不止於您的組織。您的組織可能仰賴第三方來管理您的部分資料。針對第三方管理的系統的許可管理應該遵循即時存取的做法，採用最低權限的原則搭配暫時憑證。透過與第三方密切合作，您可以同時減少影響範圍以及意外存取的風險。
**預期成果：**您會避免使用長期 AWS Identity and Access Management (IAM) 憑證，例如存取金鑰和私密金鑰，因為這些金鑰遭到濫用的情況下，會帶來安全風險。您改用 IAM 角色和臨時憑證來改善您的安全狀態，並將管理長期憑證的營運負擔降至最低。授予第三方存取權時，您使用通用唯一識別碼 (UUID) 做為 IAM 信任政策中的外部 ID，並持續掌控與角色連接的 IAM 政策，以確保最低權限存取。如需有關分析外部共用資源的方案指引，請參閱 [SEC03-BP07 分析公開和跨帳戶存取權](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)。
**常見的反模式：**
+ 無條件地使用預設 IAM 信任政策。
+ 使用長期 IAM 憑證和存取金鑰。
+ 重複使用外部 ID。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
您可能會想要允許在 AWS Organizations 之外共用資源或將帳戶存取權授予第三方。例如，第三方可能提供監控解決方案，而該解決方案需要存取您帳戶中的資源。在這些情況下，僅以第三方需要的權限來建立 IAM 跨帳戶角色。此外，請使用[外部 ID 條件](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)定義信任政策。當使用外部 ID 時，您或第三方可以為每個客戶、第三方或租用戶產生唯一 ID。在建立唯一 ID 後，其不應該受除了您之外的任何人控制。第三方必須實作程序，以安全、可稽核且可重新產生的方式將外部 ID 與客戶關聯。
您還可以使用 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 為 AWS 之外使用 AWS API 的應用程式管理 IAM 角色。
如果第三方不再需要存取您的環境，請移除該角色。避免為第三方提供長期憑證。持續關注其他支援共用的 AWS 服務，例如，允許與其他 AWS 帳戶 [共用工作負載](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html)的 AWS Well-Architected Tool，以及可協助您與其他帳戶安全共用您所擁有 AWS 資源的 [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)。
### 實作步驟
1. **使用跨帳戶角色提供存取權給外部帳戶。**[跨帳戶角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)可減少外部帳戶和第三方為了服務客戶所儲存的敏感資訊量。跨帳戶角色允許您在帳戶中將 AWS 資源的存取權安全地授予第三方，例如 AWS 合作夥伴或組織內的其他帳戶，同時維持管理和稽核該存取權的能力。第三方可能從混合式基礎設施為您提供服務，或將資料提取至異地。[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 可協助您讓第三方工作負載安全地與您的 AWS 工作負載進行互動，並進一步減少使用長期憑證的需要。
您不應該使用與使用者關聯的長期憑證或存取金鑰來提供外部帳戶存取權。反而應該使用跨帳戶角色來提供跨帳戶存取權。
1. **執行盡職調查並確保第三方 SaaS 提供者的安全存取。**與第三方 SaaS 提供者共用資源時，請執行徹底的盡職調查，以確保他們採取安全且負責任的方法來存取您的 AWS 資源。評估他們的共同責任模型，以了解他們提供哪些安全措施，以及您的責任範圍。確保 SaaS 提供者採取安全且可稽核的程序來存取您的資源，包括使用[外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) 和最低權限存取原則。使用外部 ID 有助於解決[權利義務混淆問題](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/)。
實作安全控制，以確保在授予存取權給第三方 SaaS 提供者時，能夠安全存取並遵守最低權限原則。這可能包括使用外部 ID、通用唯一識別碼 (UUID) 和 IAM 信任政策，這些會將存取權限於絕對必要的身分。與 SaaS 提供者密切合作，以建立安全存取機制、定期審查他們對您 AWS 資源的存取，並進行稽核以確保遵循您的安全需求。
1. **棄用客戶提供的長期憑證。**棄用長期憑證並使用跨帳戶角色或 IAM Roles Anywhere。如果您必須使用長期憑證，請制定計畫以遷移至角色型存取。如需有關管理金鑰的詳細資訊，請參閱[身分管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html)。另外也與您的 AWS 帳戶 團隊和第三方合作建立風險緩解執行手冊。如需有關回應和緩解潛在安全事件的衝擊的方案指引，請參閱[事件回應](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)。
1. **確認設定具有方案指引且已自動化。**外部 ID 不會被視為機密，但外部 ID 不能是容易猜測的值，例如電話號碼、名稱或帳戶 ID。將外部 ID 設為唯讀欄位，而使外部 ID 不能為了冒充設定的目的而遭到變更。
您或第三方可以產生外部 ID。定義程序以決定由誰負責產生 ID。無論建立外部 ID 的實體為何，第三方都要在客戶間一致地強制唯一性和格式。
您的帳戶中為跨帳戶存取權建立的政策必須遵循[最低權限原則](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)。第三方必須提供角色政策文件，或使用 AWS CloudFormation 範本或對您來說同等的自動設定機制。這可減少發生與手動政策建立相關聯之錯誤的機率，並提供可稽核的記錄。如需有關使用 AWS CloudFormation 範本來建立跨帳戶角色的詳細資訊，請參閱[跨帳戶角色](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/)。
第三方應該提供自動化、可稽核的設定機制。然而，透過使用概述所需存取權的角色政策文件，您應該可自動設定角色。使用 AWS CloudFormation 範本或同等項目，您應該透過偏移偵測來監控變更，以做為稽核實務的一部份。
1. **將變更列入考量。**您的帳戶結構、對第三方的需求或他們提供的服務方案可能發生變更。您應該預期變更和失敗，並透過合適的人員、程序和技術相應進行規劃。定期稽核您提供的存取層級，並實作偵測方法以在發生意外變更時通知您。監控和稽核角色和外部 ID 資料儲存的使用。您應該準備好在發生意外變更或存取模式時撤銷第三方存取權，無論是暫時或永久撤銷。另外，衡量撤銷作業的衝擊，包括執行所花的時間、牽涉的人員、成本，以及對其他資源的衝擊。
如需有關偵測方法的方案指引，請參閱[偵測最佳實務](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)。
## 資源
**相關的最佳實務：**
+ [SEC02-BP02 使用臨時憑證](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 為您的組織定義許可防護機制](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 根據生命週期管理存取](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 分析公有和跨帳戶存取權](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 偵測](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**相關文件：**
+ [儲存貯體擁有者將跨帳戶許可授予非其擁有的物件](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [如何搭配 IAM 角色使用信任政策](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [使用 IAM 角色在 AWS 帳戶 間委派存取權](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [如何使用 IAM 存取另一個 AWS 帳戶 中的資源？](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [IAM 中的安全最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [跨帳戶政策評估邏輯](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [將 AWS 資源的存取權授予第三方時如何使用外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [從在外部帳戶中使用自訂資源建立的 AWS CloudFormation 資源收集資訊](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [安全地使用外部 ID 存取其他人擁有的 AWS 帳戶](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [使用 IAM Roles Anywhere 將 IAM 角色擴展到 IAM 之外的工作負載](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**相關影片：**
+ [如何允許不同 AWS 帳戶 中的使用者或角色存取我的 AWS 帳戶？](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018：在 60 分鐘內精通 IAM 政策](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWS 知識中心直播：IAM 最佳實務和設計決策](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**相關範例：**
+ [設定對 Amazon DynamoDB 的跨帳戶存取權](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [AWS STS 網路查詢工具](https://github.com/aws-samples/aws-sts-network-query-tool)