本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# IAM 中的安全最佳實務
為了協助保護您的 AWS 資源，請遵循 (IAM) 的 AWS Identity and Access Management 這些最佳實務。
**Topics**
+ [要求人類使用者使用聯合身分提供者，以 AWS 使用臨時憑證存取](#bp-users-federation-idp)
+ [要求工作負載使用具有 IAM 角色的臨時憑證來存取 AWS](#bp-workloads-use-roles)
+ [需要多重要素驗證 (MFA)](#enable-mfa-for-privileged-users)
+ [對於需要長期憑證的使用案例，請視需要更新存取金鑰](#update-access-keys)
+ [遵循最佳實務以保護您的根使用者憑證](#lock-away-credentials)
+ [套用最低權限許可](#grant-least-privilege)
+ [開始使用 AWS 受管政策並邁向最低權限許可](#bp-use-aws-defined-policies)
+ [使用 IAM Access Analyzer 根據存取活動產生最低權限政策](#bp-gen-least-privilege-policies)
+ [定期檢閱並移除未使用的使用者、角色、許可、政策和憑證](#remove-credentials)
+ [使用 IAM 政策中的條件進一步限制存取權](#use-policy-conditions)
+ [使用 IAM Access Analyzer 驗證對資源的公開與跨帳戶存取權](#bp-preview-access)
+ [使用 IAM Access Analyzer 驗證 IAM 政策，確保許可安全且可正常運作](#best-practice-policy-validation)
+ [建立跨多個帳戶的許可防護機制](#bp-permissions-guardrails)
+ [使用許可界限委派帳戶內的許可管理](#bp-permissions-boundaries)
## 要求人類使用者使用聯合身分提供者，以 AWS 使用臨時憑證存取
人類使用者具有*人類身分*，是應用程式的相關人員、管理員、開發人員、操作員和消費者。它們必須具有身分才能存取您的 AWS 環境和應用程式。擁有您組織成員身分的人類使用者，也具有*人力身分*。人類使用者也可以是與您合作的外部使用者，以及與您的 AWS 資源互動的使用者。他們也可以透過 Web 瀏覽器、用戶端應用程式、行動應用程式或互動式命令列工具進行此項工作。
要求您的人類使用者在存取時使用臨時登入資料 AWS。您可以透過 AWS 帳戶 擔任提供臨時登入資料的角色，為您的人類使用者使用身分提供者來提供 的聯合存取。如果是集中式存取管理，我們建議您使用 [AWS IAM Identity Center (IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) 管理您帳戶的存取權和這些帳戶內的許可。您可以使用 IAM Identity Center 管理使用者身分，或從外部身分提供者管理 中使用者身分的存取許可。如需詳細資訊，請參閱 *AWS IAM Identity Center 使用者指南*中的[什麼是 AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。
如需角色的詳細資訊，請參閱[角色術語和概念](id_roles.md#id_roles_terms-and-concepts)。
## 要求工作負載使用具有 IAM 角色的臨時憑證來存取 AWS
*工作負載*是可提供商業價值的資源和程式碼的集合，例如應用程式或後端程序。您的工作負載可能有需要憑證才能向 AWS 服務發出請求 (例如讀取 Amazon S3 中資料的請求) 的應用程式、操作工具和元件。
當您在 Amazon EC2 或 Lambda 等 AWS 運算服務上建置 時， 會將 IAM 角色的臨時登入資料 AWS 交付至該運算資源。使用 AWS SDK 撰寫的應用程式將探索和使用這些臨時登入資料來存取 AWS 資源，而且不需要將 IAM 使用者的長時間存留登入資料分發到執行 的工作負載 AWS。
在 外部執行的工作負載 AWS，例如您的內部部署伺服器、來自其他雲端供應商的伺服器，或受管持續整合和持續交付 (CI/CD) 平台，仍然可以使用臨時登入資料。不過，您需要將這些臨時憑證提供給工作負載。以下是將臨時憑證提供給工作負載時可採用的方式：
+ 您可以使用 IAM Roles Anywhere，從公有金鑰基礎設施 (PKI) 使用 X.509 憑證請求工作負載的臨時 AWS 憑證。
+ 您可以使用外部身分提供者 AWS AWS STS`AssumeRoleWithSAML`(IdP) 的 SAML 聲明，呼叫 API 來請求工作負載的臨時 AWS 憑證 AWS 帳戶。
+ 您可以使用 IdP AWS AWS STS `AssumeRoleWithWebIdentity`中的 JSON Web 權杖 (JWT)，呼叫 API 來請求工作負載的臨時 AWS 登入資料 AWS 帳戶。 IdP
+ 您可以使用 的 Mutual Transport Layer Security (MTLS) 身分驗證，從您的 IoT 裝置請求臨時 AWS 憑證 AWS IoT Core。
有些 AWS 服務 也支援整合，將臨時登入資料交付至在下列位置之外執行的工作負載 AWS：
+ [Amazon Elastic Container Service (Amazon ECS) Anywhere](https://aws.amazon.com/ecs/anywhere/) 可讓您在自己的運算資源上執行 Amazon ECS 任務，並將臨時 AWS 憑證提供給在這些運算資源上執行的 Amazon ECS 任務。
+ [Amazon Elastic Kubernetes Service Hybrid Nodes](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-overview.html) 可讓您將在 外部作為 AWS 節點執行的運算資源加入 Amazon EKS 叢集。Amazon EKS 可以將臨時憑證提供給在運算資源上執行的 Amazon EKS Pod。
+ [AWS Systems ManagerHybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html) 可讓您 AWS 使用 SSM 管理在 之外執行的運算資源，並將臨時 AWS 登入資料交付給在運算資源上執行的 SSM 代理程式。
## 需要多重要素驗證 (MFA)
我們建議將 IAM 角色用於會存取您 AWS 資源的人類使用者和工作負載，以便他們使用暫時性憑證。但是，對於帳戶中需要 IAM 使用者或根使用者的情況，則需要 MFA 提供額外的安全性。使用 MFA，使用者便可擁有一個裝置，針對身分驗證查問產生回應。擁有每位使用者的憑證及裝置產生的回應，才能完成登入程序。如需詳細資訊，請參閱[AWS IAM 中的多重要素驗證](id_credentials_mfa.md)。我們建議您盡可能使用網路釣魚防護 MFA，例如通行金鑰和安全金鑰。如需詳細資訊，請參閱[在 中指派通行金鑰或安全金鑰 AWS 管理主控台](id_credentials_mfa_enable_fido.md)。
如果將 AM Identity Center 用於人類使用者的集中式存取管理，則可在使用 IAM Identity Center 身分存放區、 AWS Managed Microsoft AD 或 AD Connector 設定身分來源時使用 IAM Identity Center MFA 功能。如需有關 IAM Identity Center 中的 MFA 的詳細資訊，請參閱 *AWS IAM Identity Center 使用者指南*中的[多重要素驗證](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)。
## 對於需要長期憑證的使用案例，請視需要更新存取金鑰
我們建議您盡可能依賴暫時性憑證，而不要建立長期憑證，例如存取金鑰。但是，對於需要具有程式化存取和長期憑證的 IAM 使用者的情況，我們建議您視需要更新存取金鑰，如在員工離職時。我們建議您使用 *IAM 存取上次使用的資訊*，以便安全地更新和移除存取金鑰。如需詳細資訊，請參閱[更新存取金鑰](id-credentials-access-keys-update.md)。
有特定的使用案例需要具有 IAM 使用者的長期登入資料 AWS。以下是部分使用案例：
+ **無法使用 IAM 角色的工作負載** - 您可以從需要存取 AWS的位置執行工作負載。在某些情況下，您無法使用 IAM 角色提供暫時性憑證，例如針對 WordPress 外掛程式。在這些情況下，請將 IAM 使用者長期存取金鑰用於該工作負載，對 AWS進行身分驗證。
+ **第三方 AWS 用戶端** – 如果您使用不支援透過 IAM Identity Center 存取的工具，例如未託管的第三方 AWS 用戶端或廠商 AWS，請使用 IAM 使用者長期存取金鑰。
+ **AWS CodeCommit 存取** – 如果您使用 CodeCommit 存放程式碼，您可以使用 IAM 使用者搭配 SSH 金鑰或服務特定的登入資料，讓 CodeCommit 驗證您的儲存庫。除了將 IAM Identity Center 中的使用者用於一般身分驗證之外，我們也建議您這樣做。IAM Identity Center 中的使用者是您人力中需要存取您的 AWS 帳戶 或雲端應用程式的人員。若要將您 CodeCommit 儲存庫的存取權授予使用者，而不設定 IAM 使用者，您可以設定 **git-remote-codecommit** 公用程式。如需 IAM 和 CodeCommit 的詳細資訊，請參閱 [CodeCommit 的 IAM 登入資料：Git 登入資料、SSH 金鑰和 AWS 存取金鑰](id_credentials_ssh-keys.md)。如需設定**git-remote-codecommit**公用程式的詳細資訊，請參閱*AWS CodeCommit 《 使用者指南*》中的[使用輪換憑證連線至 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials)。
+ **Amazon Keyspaces (適用於 Apache Cassandra) 存取** – 在無法使用 IAM Identity Center 中的使用者的情況下，例如為了測試 Cassandra 相容性，您可以將 IAM 使用者搭配服務特定憑證使用，以便使用 Amazon Keyspaces 進行身分驗證。IAM Identity Center 中的使用者是您人力中需要存取您的 AWS 帳戶 或雲端應用程式的人員。您也可以使用暫時性憑證連線到 Amazon Keyspaces。如需詳細資訊，請參閱 *Amazon Keyspaces (for Apache Cassandra) Developer Guide* 中的 [Using temporary credentials to connect to Amazon Keyspaces using an IAM role and the SigV4 plugin](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM)。
## 遵循最佳實務以保護您的根使用者憑證
建立 時 AWS 帳戶，您可以建立根使用者登入資料以登入 AWS 管理主控台。如同保護其他敏感的個人資訊那樣，保護您的根使用者憑證。若要更好地了解如何保護和擴展根使用者程序，請參閱 [您 的根使用者最佳實務 AWS 帳戶](root-user-best-practices.md)。
## 套用最低權限許可
設定 IAM 政策的許可時，請僅授予執行任務所需的許可。為實現此目的，您可以定義在特定條件下可以對特定資源採取的動作，這也稱為*最低權限許可*。探索工作負載或使用案例所需的許可時，您可能會從廣泛許可開始。隨著使用案例的成熟，您可以設法減少授予的許可，以便朝向最低權限的目標邁進。如需使用 IAM 套用許可的詳細資訊，請參閱 [中的政策和許可 AWS Identity and Access Management](access_policies.md)。
## 開始使用 AWS 受管政策並邁向最低權限許可
若要開始授予許可給使用者和工作負載，請使用 *AWS 受管政策*，為許多常見使用案例授予許可。它們可在您的 中使用 AWS 帳戶。請記住， AWS 受管政策可能不會授予特定使用案例的最低權限許可，因為它們可供所有 AWS 客戶使用。因此，我們建議您定義使用案例的[客戶管理政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)，以便進一步減少許可。如需詳細資訊，請參閱[AWS 受管政策](access_policies_managed-vs-inline.md#aws-managed-policies)。如需專為特定任務函數設計的 AWS 受管政策的詳細資訊，請參閱 [AWS 任務函數的 受管政策](access_policies_job-functions.md)。
## 使用 IAM Access Analyzer 根據存取活動產生最低權限政策
若只授予執行任務所需的許可，您可以根據在 AWS CloudTrail中記錄的存取活動產生政策。[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 會分析您 IAM 角色使用的服務和動作，然後產生您可以使用的精細政策。測試產生的每個政策後，您可以將政策部署到生產環境。這可確保您僅授予所需的許可給工作負載。如需政策產生的詳細資訊，請參閱 [IAM Access Analyzer 政策產生](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)。
## 定期檢閱並移除未使用的使用者、角色、許可、政策和憑證
您的 AWS 帳戶中可能存在不再需要的 IAM 使用者、角色、許可、政策或憑證。IAM 會提供*上次存取的資訊*，協助您識別不再需要的使用者、角色、許可、政策和憑證，以便您移除這些資料。這可協助您減少必須監控的使用者、角色、許可、政策和憑證數量。您也可以使用此資訊來精簡 IAM 政策，以便更完善地遵循最低權限許可。如需詳細資訊，請參閱[AWS 使用上次存取的資訊在 中精簡許可](access_policies_last-accessed.md)。
## 使用 IAM 政策中的條件進一步限制存取權
您可以根據生效的政策陳述式指定條件。如此，您便可以授予對動作和資源的存取權，前提是存取請求符合特定條件。例如，您可以撰寫政策條件，指定必須使用 TLS 傳送所有請求。您也可以使用條件來授予對服務動作的存取權，但僅限透過特定 使用時 AWS 服務，例如 CloudFormation。如需詳細資訊，請參閱[IAM JSON 政策元素：Condition](reference_policies_elements_condition.md)。
## 使用 IAM Access Analyzer 驗證對資源的公開與跨帳戶存取權
在授予公有或跨帳戶存取的許可之前 AWS，建議您驗證是否需要此類存取。您可以使用 IAM Access Analyzer，協助自己預覽和分析所支援資源類型的公開和跨帳戶存取權。為此，您可以檢閱 IAM Access Analyzer 產生的[問題清單](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html)。這些問題清單有助於您驗證資源存取控制是否授予您預期的存取權。此外，隨著您更新公開和跨帳戶許可，您可以在將新的存取控制部署到資源前驗證變更的影響。IAM Access Analyzer 也會持續監控支援的資源類型，並為允許公開或跨帳戶存取權的資源產生問題清單。如需詳細資訊，請參閱[使用 IAM Access Analyzer API 預覽存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-preview-access-apis.html)。
## 使用 IAM Access Analyzer 驗證 IAM 政策，確保許可安全且可正常運作
驗證您建立的政策，確保它們遵守[IAM 政策語言](access_policies.md#access_policies-json) (JSON) 和 IAM 最佳實務。您可以使用 IAM Access Analyzer 政策驗證來驗證自己的政策。IAM Access Analyzer 提供 100 多項政策檢查及切實可行的建議，可協助您編寫安全且實用的政策。您在主控台中編寫新政策或編輯現有政策時，IAM Access Analyzer 會提供建議，協助您在儲存政策前完善和驗證政策。此外，我們建議您檢閱並驗證所有現有政策。如需詳細資訊，請參閱 [IAM Access Analyzer 政策驗證](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。如需 IAM Access Analyzer 所提供政策檢查的詳細資訊，請參閱《[IAM Access Analyzer 政策檢查參考](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html)》。
## 建立跨多個帳戶的許可防護機制
當您擴展工作負載時，請使用 管理的多個帳戶來分隔工作負載 AWS Organizations。我們建議您使用 AWS Organizations [服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) 來建立許可防護機制，以控制您帳戶間所有主體 (IAM 角色和使用者） 的存取。建議使用 AWS Organizations [資源控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) (RCP) 來建立許可防護機制，以控制整個組織中的 AWS 資源存取。SCPs和 RCPs 是組織政策的類型，可用於在 AWS 組織、組織單位 (OU) 或帳戶層級管理組織中的許可。
不過，僅有 SCP 和 RCP 並不足以授予許可給您組織中的主體和資源。SCP 和 RCP 沒有授予任何許可。要授予許可，您必須將[身分型或資源型政策](access_policies_identity-vs-resource.md)連接到 IAM 使用者、IAM 角色或您帳戶中的資源。如需詳細資訊，請參閱 [SRA 建置區塊 AWS Organizations-、帳戶和護欄](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/organizations.html)。
## 使用許可界限委派帳戶內的許可管理
在某些情況下，您可能想要將帳戶內的許可管理委派給其他人。例如，您可以允許開發人員為其工作負載建立和管理角色。委派許可給其他人時，請使用*許可界限*來設定您委派許可的上限。許可界限是一種進階功能，可供您使用受管政策來設定身分型政策可以授予 IAM 角色的許可上限。許可界限不會自行授予許可。如需詳細資訊，請參閱[IAM 實體的許可界限](access_policies_boundaries.md)。