

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

# 什麼是 IAM？
<a name="introduction"></a>

AWS Identity and Access Management (IAM) 是一種 Web 服務，可協助您安全地控制對 資源的 AWS 存取。透過 IAM，您可以管理許可，以控制使用者可以存取哪些 AWS 資源。您可以使用 IAM 來控制能通過身分驗證 (登入) 和授權使用資源的 (具有許可) 的人員。IAM 提供控制 AWS 帳戶身分驗證和授權所需的基礎設施。

**身分**

 當您建立 時 AWS 帳戶，您會從一個名為 AWS 帳戶 *theroot 使用者的*登入身分開始，該身分具有對所有 AWS 服務 和 資源的完整存取權。強烈建議不要使用根使用者來執行日常任務。有關需要根使用者憑證的任務，請參閱《IAM 使用者指南》**中的[需要根使用者憑證的任務](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。

使用 IAM 來設定根使用者以外的其他身分，例如管理員、分析師和開發人員，並授予他們在任務中取得成功所需的資源存取權。

**存取管理**

在 IAM 中設定使用者後，他們會使用其登入憑證對 AWS進行驗證。身分驗證是透過將登入憑證比對至 信任的委託人 (IAM 使用者、 AWS STS 聯合委託人、IAM 角色或應用程式） 來提供 AWS 帳戶。接下來，系統會提出請求來向主體授與資源的存取權。如果使用者已獲得資源許可，則會授予存取權以回應授權請求。舉例來說，當您第一次登入主控台且位於主控台首頁頁面時，您並未存取特定服務。選取某項服務時，系統會將授權請求傳送至該服務，該項服務會檢查您的身分是否在授權使用者清單上、強制執行了哪些政策來控制授與的存取層級，以及任何可能生效中的其他政策。授權請求可由您內部的委託人 AWS 帳戶 或您信任 AWS 帳戶 的委託人提出。

獲得授權後，主體即可對您 AWS 帳戶中的資源採取動作或執行操作。例如，委託人可以啟動新的 Amazon Elastic Compute Cloud 執行個體、修改 IAM 群組成員資格或刪除儲存 Amazon Simple Storage Service 貯體。

**提示**  
AWS 訓練和認證提供 IAM 的 10 分鐘影片簡介：  
[AWS Identity and Access Management簡介](https://www.aws.training/learningobject/video?id=16448)。

**服務可用性**

IAM 與許多 AWS 其他服務一樣，[最終是一致的](https://wikipedia.org/wiki/Eventual_consistency)。IAM 可跨 Amazon 全球資料中心內多部伺服器複寫資料，來達到高可用性。如果變更一些資料的請求成功完成，則該變更經認可並安全儲存。然而，該變更必須跨 IAM 複寫，這可能需要一些時間。此類變更包括建立或更新使用者、群組、角色或政策。在應用程式的關鍵、高可用性代碼路徑中，我們不建議進行此類 IAM 變更。而應在不常運作的、單獨的初始化或設定常式中進行 IAM 變更。另外，在生產工作流程套用這些變更之前，請務必確認變更已完成傳播。如需詳細資訊，請參閱[我所做的變更不一定都會立刻生效](troubleshoot.md#troubleshoot_general_eventual-consistency)。

**服務成本資訊**

AWS Identity and Access Management (IAM)、 AWS IAM Identity Center 和 AWS Security Token Service (AWS STS) 是您 AWS 帳戶的功能，無需額外付費。只有在您使用 IAM 使用者或 AWS STS 臨時安全登入資料存取其他服務時 AWS ，才會向您收取費用。

會提供 IAM Access Analyzer 外部存取分析，無需額外付費。不過，您需支付未使用的存取分析和客戶政策檢查的費用。如需 IAM Access Analyzer 的完整費用與定價清單，請參閱 [IAM Access Analyzer 定價](https://aws.amazon.com/iam/access-analyzer/pricing)。

如需其他 AWS 產品定價的資訊，請參閱 [Amazon Web Services 定價頁面](https://aws.amazon.com/pricing/)。

**與其他 AWS 服務的整合**

IAM 與許多 AWS 服務整合。如需使用 AWS IAM 的服務清單，以及服務支援的 IAM 功能，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)。

# 為什麼要使用 IAM？
<a name="intro-iam-features"></a>

AWS Identity and Access Management 是一種強大的工具，可安全地管理對 AWS 資源的存取。使用 IAM 的主要優點之一是能夠授予 AWS 您帳戶的共用存取權。此外，IAM 可讓您指派精細的許可，讓您精確控制不同使用者可以對特定資源執行的動作。此層級的存取控制對於維護 AWS 環境的安全性至關重要。IAM 也提供數個其他安全功能。可以新增多重要素驗證 (MFA) 以獲得額外的保護，並利用聯合身分無縫整合來自公司網路或其他身分提供程式的使用者。IAM 也與 整合 AWS CloudTrail，提供詳細的記錄和身分資訊，以支援稽核和合規要求。透過利用這些功能，您可以協助確保對關鍵 AWS 資源的存取受到嚴格控制且安全。

## 共用存取您的 AWS 帳戶
<a name="intro-shared-access"></a>

您可以授與其他人管理和使用 AWS 帳戶資源的許可，而無需共用您的密碼或存取金鑰。

## 精密許可
<a name="intro-granular-permissions"></a>

您可以對不同的人員授與不同資源的不同許可。例如，您可以允許某些使用者完整存取 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、Amazon Redshift 和其他 AWS 服務。對於其他使用者，您可以只允許對一些 Amazon S3 儲存貯體進行唯讀存取，或僅具有管理一些 Amazon EC2 執行個體的許可，或存取您的帳單資訊，但不能進行任何其他動作。

## 安全存取在 Amazon EC2 上執行的應用程式 AWS 的資源
<a name="intro-secure-access"></a>

您可以使用 IAM 功能為在 EC2 執行個體上執行的應用程式安全地提供憑證。這些登入資料為您的應用程式提供存取其他 AWS 資源的許可。範例包括 S3 儲存貯體和 DynamoDB 表格。

## 多重要素驗證 (MFA)
<a name="intro-mfa-iam"></a>

您可以為帳戶和個別使用者新增雙重要素身分驗證，以提高安全性。使用 MFA，您或您的使用者不僅必須提供密碼或存取金鑰才能使用您的帳戶，還必須提供來自特殊設定裝置的代碼。如果您已將 FIDO 安全金鑰與其他 服務搭配使用，且具有 AWS 支援的組態，則可以使用 WebAuthn 確保 MFA 安全。如需詳細資訊，請參閱[使用通行密鑰和安全金鑰的支援組態](id_credentials_mfa_fido_supported_configurations) 

## 聯合身分
<a name="intro-identity-federation-iam"></a>

您可以允許已經在其他地方擁有密碼的使用者 (例如，在您的公司網路中或使用網際網路身分提供程式) 存取您的 AWS 帳戶。這些使用者會獲得符合 IAM 最佳實務建議的臨時憑證。使用聯合身分可增強 AWS 帳戶的安全性。

## 身分資訊保證
<a name="intro-identity-assurance"></a>

如果您使用 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)，則會收到日誌記錄，其中包含有關在您的帳戶中請求資源的資訊。該資訊是根據 IAM 身分。

## PCI DSS 合規
<a name="intro-pci-dss-compliance"></a>

IAM 支援處理、儲存、傳輸商家或服務供應商的信用卡資料，並且已驗證合規於支付卡產業 (PCI) 資料安全標準 (DSS)。如需 PCI DSS 的詳細資訊，包括如何請求 AWS PCI 合規套件的副本，請參閱 [PCI DSS 第 1 級](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)。

# IAM 的使用時機為何？
<a name="when-to-use-iam"></a>

AWS Identity and Access Management 是一種核心基礎設施服務，可提供根據內部身分進行存取控制的基礎 AWS。您每次存取 AWS 帳戶時都會使用 IAM。使用 IAM 的方式將取決於組織中的具體責任和工作職責。 AWS 服務的使用者使用 IAM 存取day-to-day工作所需的 AWS 資源，管理員會授予適當的許可。另一方面，IAM 管理員負責管理 IAM 身分並撰寫政策，以控制對 資源的存取。無論您的角色為何，每當您驗證和授權存取 AWS 資源時，都會與 IAM 互動。這可能包括以 IAM 使用者身分登入、充當 IAM 角色，或利用聯合身分進行無縫存取。了解各種 IAM 功能和使用案例對於有效管理 AWS 環境的安全存取至關重要。在建立政策和許可時，IAM 可提供靈活且精細的方法。除了指定使用者或角色可存取的動作和資源的身分型政策之外，還可以定義信任政策來控制哪些主體可以擔任某個角色。透過設定這些 IAM 政策，可以協助確保使用者和應用程式具有適當的許可層級來執行其所需任務。

## 執行不同工作職能時
<a name="security_iam_audience"></a>

AWS Identity and Access Management 是一種核心基礎設施服務，可提供根據內部身分進行存取控制的基礎 AWS。每次存取 AWS 帳戶時都會使用 IAM。

 使用 IAM 的方式會有所不同，具體取決於您在 AWS中所執行的工作。
+ 服務使用者 – 如果您使用 AWS 服務來執行任務，您的管理員會為您提供所需的登入資料和許可。隨著您為了執行作業而使用更多的進階功能，您可能會需要額外的許可。了解存取許可的管理方式可協助您向管理員請求正確的許可。
+ 服務管理員 – 如果您負責公司 AWS 的資源，您可能擁有 IAM 的完整存取權。您的任務是判斷服務使用者應存取的 IAM 功能及資源。接著，您必須將請求提交給您的 IAM 管理員，來變更您服務使用者的許可。檢閱此頁面上的資訊，了解 IAM 的基本概念。
+ IAM 管理員：如果您是 IAM 管理員，您可以透過管理 IAM 身分和寫入政策來管理 IAM 存取權。

 

## 當您獲得存取 AWS 資源的授權時
<a name="security_iam_authentication-intro"></a>

身分驗證是您 AWS 使用身分憑證登入 的方式。您必須以 AWS 帳戶根使用者、IAM 使用者或擔任 IAM 角色身分進行身分驗證。

您可以使用身分來源的登入資料，例如 AWS IAM Identity Center (IAM Identity Center)、單一登入身分驗證或 Google/Facebook 登入資料，以聯合身分的形式登入。如需有關登入的詳細資訊，請參閱《AWS 登入 使用者指南》**中的[如何登入您的 AWS 帳戶](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。

對於程式設計存取， AWS 提供 SDK 和 CLI 以密碼編譯方式簽署請求。如需詳細資訊，請參閱《IAM 使用者指南》**中的 [API 請求的AWS 第 4 版簽署程序](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)。

## 以 IAM 使用者身分登入時
<a name="security_iam_authentication-iamuser"></a>

*IAM 使用者*[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)是一種身分具備單人或應用程式的特定許可權。建議以臨時憑證取代具備長期憑證的 IAM 使用者。如需詳細資訊，請參閱《*IAM 使用者指南*》中的[要求人類使用者使用聯合身分提供者來 AWS 使用臨時憑證存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) 。

[IAM 群組](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)**會指定 IAM 使用者集合，使管理大量使用者的許可權更加輕鬆。如需詳細資訊，請參閱《IAM 使用者指南》**中的 [IAM 使用者的使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)。

## 擔任 IAM 角色時
<a name="security_iam_authentication-iamrole"></a>

*IAM 角色*[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)的身分具有特定許可權，其可以提供臨時憑證。您可以透過[從使用者切換到 IAM 角色 （主控台） ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)或呼叫 AWS CLI 或 AWS API 操作來擔任角色。如需詳細資訊，請參閱《IAM 使用者指南》**中的[擔任角色的方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)。

IAM 角色適用於聯合身分使用者存取、臨時 IAM 使用者許可、跨帳戶存取權與跨服務存取，以及在 Amazon EC2 執行的應用程式。如需詳細資訊，請參閱《*IAM 使用者指南*》中的 [IAM 中的快帳戶資源存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。

## 建立政策和許可時
<a name="getting-started_trust-policies"></a>

您能夠建立政策，進而將許可授與給使用者。該政策文件中會列出使用者可執行的動作，以及會受到這些動作影響的資源。根據預設，未明確允許的任何動作或資源將被拒絕。可建立政策並連接至主體 (使用者、使用者群組、使用者擔任的角色以及資源)。

可搭配使用這些政策與 IAM 角色：
+ **信任政策**：定義哪些[主體](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal)可以在哪些條件下擔任該角色。信任政策是一項專屬於 IAM 角色的資源型政策。一個角色只能由一項信任政策。
+ **身分型政策 (內嵌和受管)**：這些政策會定義角色使用者能夠執行 (或無法執行) 的許可，以及在哪些資源上執行。

使用 [以身分為基礎的 IAM 政策範例](access_policies_examples.md) 可協助您定義 IAM 身分的許可。在您找到所需的政策後，選擇「查看政策」以查看政策的 JSON。您可以將 JSON 政策文件用作自己政策的範本。

**注意**  
如果使用 IAM Identity Center 來管理使用者，您可以在 IAM Identity Center 指派許可集，而不是將許可政策連接至主體。當您將許可集指派給群組或 時 AWS IAM Identity Center 的使用者，IAM Identity Center 會在每個帳戶中建立對應的 IAM 角色，並將許可集中指定的政策連接到這些角色。IAM Identity Center 會負責管理角色，並允許您定義的授權使用者擔任該角色。修改許可集後，IAM Identity Center 會確保有據此更新對應的 IAM 政策和角色。  
如需有關 IAM Identity Center 的詳細資訊，請參閱 *AWS IAM Identity Center 使用者指南*中的[什麼是 IAM Identity Center？](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。

# 如何管理 IAM？
<a name="intro-managing-iam"></a>

 AWS Identity and Access Management 在 AWS 環境中進行管理涉及利用各種工具和界面。最常見的方法是透過 Web 型界面 AWS 管理主控台，可讓您執行各種 IAM 管理任務，從建立使用者和角色到設定許可。

對於更熟悉命令列界面的使用者， AWS 提供兩組命令列工具： AWS Command Line Interface 和 AWS Tools for Windows PowerShell。它們可讓您直接從終端發出 IAM 相關命令，通常比導覽主控台更有效率。此外， AWS CloudShell 可讓您使用與主控台登入相關聯的許可，直接從 Web 瀏覽器執行 CLI 或 SDK 命令。

除了主控台和命令列之外， AWS 還提供各種程式設計語言的軟體開發套件 (SDKs)，可讓您將 IAM 管理功能直接整合到您的應用程式。或者，您可以使用 IAM 查詢 API (允許您直接向服務發出 HTTPS 請求)，以程式設計方式存取 IAM。利用這些不同的管理方法，可靈活地將 IAM 整合到現有的工作流程和程序中。

## 使用 AWS 管理主控台
<a name="intro-managing-iam-section-1"></a>

 AWS 管理主控台是一種 Web 應用程式，包含並參考各種用於管理 AWS 資源的服務主控台。若是首次登入，這時主控台頁面將會顯示。首頁提供每個服務主控台的存取權，並提供單一位置來存取執行 AWS 相關任務的資訊。登入 主控台後，您可以使用哪些服務和應用程式，取決於您有權存取 AWS 的資源。您可以透過擔任某個角色、加入已取得許可的群組或明確取得相關許可，從而獲得對資源的許可。對於獨立的 AWS 帳戶，根使用者或 IAM 管理員會設定資源的存取權。對於 AWS Organizations，管理帳戶或委派的管理員會設定資源的存取權。

如果您計劃讓人員使用 AWS 管理主控台來管理 AWS 資源，我們建議您使用暫時登入資料來設定使用者，做為安全[最佳實務](best-practices.md)。已擔任角色的 IAM 使用者、聯合身分主體和 IAM Identity Center 中的使用者擁有臨時憑證，而 IAM 使用者和根使用者擁有長期憑證。根使用者登入資料提供 的完整存取權 AWS 帳戶，而其他使用者則擁有登入資料，可存取 IAM 政策授予他們的資源。

登入體驗因不同類型的 AWS 管理主控台 使用者而異。
+ IAM 使用者和根使用者從主要登入 URL (https://signin.aws.amazon.com：//) AWS 登入。一旦登入，他們便可存取已取得許可的帳戶中的資源。

  若要以根使用者身分登入，您必須有根使用者電子郵件地址和密碼。

  若要以 IAM 使用者身分登入，您必須擁有 AWS 帳戶 號碼或別名、IAM 使用者名稱和 IAM 使用者密碼。

  我們建議您將帳戶中的 IAM 使用者限定於需要長期憑證的特定情形，例如緊急存取，而且您只會在[需要根使用者憑證的任務](id_root-user.md#root-user-tasks)中使用根使用者。

  為了方便起見， AWS 登入頁面會使用瀏覽器 Cookie 來記住 IAM 使用者名稱和帳戶資訊。下次使用者前往 中的任何頁面時 AWS 管理主控台，主控台會使用 Cookie 將使用者重新導向至帳戶登入頁面。

  完成您的工作階段後，請登出主控台以防止重複使用您先前的登入。
+ IAM Identity Center 使用者使用其組織獨有的特定 AWS 存取入口網站登入。登入後，他們可以選擇要存取的帳戶或應用程式。如果選擇存取某個帳戶，他們會選擇想要在管理工作階段中使用哪個許可集。
+ 外部身分提供者管理的 OIDC 和 SAML 聯合身分主體會連結至使用自訂企業存取入口網站的 AWS 帳戶 登入。使用者可以使用的 AWS 資源取決於其組織所選取的政策。

**注意**  
為了提供額外層級的安全性，根使用者、IAM 使用者和 IAM Identity Center 中的使用者可以在授予 AWS 資源存取權 AWS 之前，由 驗證多重要素驗證 (MFA)。當啟用 MFA 時，您還必須能夠存取要登入的 MFA 裝置。

若要進一步了解不同使用者如何登入 管理主控台，請參閱 [登入使用者指南中的登入 AWS 管理主控台](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)。 *AWS *

## AWS 命令列工具
<a name="management-method-cli"></a>

您可以使用 AWS 命令列工具，在系統的命令列發出命令，以執行 IAM 和 AWS 任務。使用命令列可以比主控台更快，也更便利。如果您想要建置執行 AWS 任務的指令碼，命令列工具也很有用。

AWS 提供兩組命令列工具： [AWS Command Line Interface](https://aws.amazon.com/cli/)(AWS CLI) 和 [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/)。如需安裝和使用 的詳細資訊 AWS CLI，請參閱[AWS Command Line Interface 《 使用者指南》](https://docs.aws.amazon.com/cli/latest/userguide/)。如需安裝和使用 Tools for Windows PowerShell 的詳細資訊，請參閱 [AWS Tools for PowerShell 使用者指南](https://docs.aws.amazon.com/powershell/latest/userguide/)。

登入 主控台後，您可以從 AWS CloudShell 瀏覽器使用 來執行 CLI 或 SDK 命令。存取 AWS 資源的許可取決於您用來登入 主控台的登入資料。根據您的經驗，您可能會發現 CLI 是管理 AWS 帳戶的更有效率的方法。如需詳細資訊，請參閱[使用 AWS CloudShell 搭配 AWS Identity and Access Management](using-aws-with-cloudshell.md)

### AWS 命令列界面 (CLI) 和軟體開發套件 (SDKs)
<a name="management-method-cli-sdk"></a>

當 IAM Identity Center 和 IAM 使用者透過相關 SDK 中的 CLI 或應用程式介面 (API) 驗證身分時，他們會使用不同方法來驗證其憑證。

登入資料和組態設定位於多個位置，例如系統或使用者環境變數、本機 AWS 組態檔案，或在命令列上明確宣告為參數。某些位置的優先順序高於其他位置。

IAM Identity Center 和 IAM 均提供可與 CLI 或 SDK 搭配使用的存取金鑰。IAM Identity Center 存取金鑰是可自動整理的臨時憑證，並且優於與 IAM 使用者相關聯的長期存取金鑰。

若要 AWS 帳戶 使用 CLI 或 SDK 管理 ，您可以從 AWS CloudShell 瀏覽器使用 。如果您使用 CloudShell 執行 CLI 或 SDK 命令，必須先登入主控台。存取 AWS 資源的許可取決於您用來登入 主控台的登入資料。根據您的經驗，您可能會發現 CLI 是管理 AWS 帳戶的更有效率的方法。

對於應用程式開發，您可以將 CLI 或 SDK 下載到您的電腦，然後從命令提示或 Docker 視窗進行登入。在這種情況下，您要將身分驗證和存取憑證設定為 CLI 指令碼或 SDK 應用程式的一部分。您可以採用不同的方式設定對資源的程式設計存取，具體取決於適用於您的環境和存取權。
+ 使用 AWS 服務驗證本機程式碼的建議選項是 IAM Identity Center 和 IAM Roles Anywhere
+ 要驗證在 AWS 環境中執行的程式碼，建議的選項是使用 IAM 角色或使用 IAM Identity Center 憑證。

使用 AWS 存取入口網站登入時，您可以從選擇許可集的開始頁面取得短期憑證。這些憑證具有定義的持續時間，不會自動重新整理。如果您想要使用這些登入資料，請在登入 AWS 入口網站後，選擇 ， AWS 帳戶 然後選擇許可集。選取**命令列或程式設計存取**，以檢視可用於以程式設計方式或從 CLI 存取 AWS 資源的選項。如需有關這些方法的詳細資訊，請參閱《IAM Identity Center 使用者指南》**中的[取得與重新整理臨時憑證](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html#how-to-get-temp-credentials)。這些憑證經常在應用程式開發期間使用，以便快速測試程式碼。

我們建議您使用 IAM Identity Center 登入資料，在自動化對 AWS 資源的存取時自動重新整理。如果您已在 IAM Identity Center 中設定使用者和許可集，您可以使用 `aws configure sso` 命令以便利用命令列精靈來協助您識別可用的憑證，並且將它們存放在設定檔中。如需有關設定您的設定檔的更多資訊，請參閱《AWS 命令列介面使用者指南 (適用於版本 2)》**中的[使用 `aws configure sso` 精靈設定您的設定檔](https://docs.aws.amazon.com/cli/latest/userguide/sso-configure-profile-token.html#sso-configure-profile-token-auto-sso)。

**注意**  
許多範例應用程式使用與 IAM 使用者或根使用者相關聯的長期存取金鑰。您應該只在沙盒環境中使用長期憑證，這是您學習練習的一部分。檢閱[長期存取金鑰的替代方案](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys)並制定轉換程式碼計畫，使其儘快使用替代憑證，例如 IAM Identity Center 憑證或 IAM 角色。在轉換程式碼後，請刪除存取金鑰。

若要進一步了解如何設定 CLI，請參閱《 第 2 [AWS 版的命令列界面使用者指南》中的安裝或更新最新版本的 CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)，以及《 *AWS 命令列界面使用者指南*》中的身分[驗證和存取登入](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html)資料。 *AWS *

若要詳細了解如何設定軟體開發套件，請參閱《AWS SDK 和工具參考指南》**中的 [IAM Identity Center 身分驗證](https://docs.aws.amazon.com/sdkref/latest/guide/access-sso.html)和《AWS 軟體開發套件和工具參考指南》**中的 [IAM Roles Anywhere](https://docs.aws.amazon.com/sdkref/latest/guide/access-rolesanywhere.html)。

## 使用 AWS SDKs
<a name="intro-managing-iam-section-2"></a>

AWS 提供 SDKs（軟體開發套件），其中包含適用於各種程式設計語言和平台 (Java、Python、Ruby、.NET、iOS、Android 等） 的程式庫和範本程式碼。SDKs提供便捷的方式來建立對 IAM 和 的程式設計存取 AWS。例如，開發套件會負責的工作諸如以密碼演算法簽署請求、管理錯誤以及自動重試請求。如需 AWS SDKs 的相關資訊，包括如何下載和安裝，請參閱[適用於 Amazon Web Services 的工具](https://aws.amazon.com/tools/)頁面。

## 使用 IAM 查詢 API
<a name="intro-managing-iam-section-3"></a>

您可以使用 IAM 查詢 API 以 AWS 程式設計方式存取 IAM 和 ，這可讓您直接向 服務發出 HTTPS 請求。使用查詢 API 時，您必須加入程式碼，才能夠使用您的登入資料以數位方式簽署請求。如需詳細資訊，請參閱 [使用 HTTP 查詢請求呼叫 IAM API](programming.md) 和 [IAM API 參考](https://docs.aws.amazon.com/IAM/latest/APIReference/)。

# IAM 的運作方式
<a name="intro-structure"></a>

AWS Identity and Access Management 提供必要的基礎設施，以控制 的身分驗證和授權 AWS 帳戶。

首先，人類使用者或應用程式會使用其登入憑證來向 AWS進行身分驗證。IAM 會將登入憑證比對至 信任的委託人 (IAM 使用者、 AWS STS 聯合身分使用者委託人、IAM 角色或應用程式）， AWS 帳戶 並驗證存取 的許可 AWS。

接下來，IAM 會提出請求，向主體授予資源的存取權。IAM 根據授權請求來授予或拒絕存取權。舉例來說，當您第一次登入主控台且位於主控台首頁頁面時，您並未存取特定服務。當您選取服務時，會針對該服務將授權請求傳送至 IAM。IAM 會驗證您的身分是否在授權使用者清單中，確定哪些政策控制授予的存取層級，並評估可能有效的任何其他政策。您內部 AWS 帳戶 或您 AWS 帳戶 信任之其他 的委託人可以提出授權請求。

獲得授權後，主體即可對 AWS 帳戶中的資源執行動作或操作。例如，委託人可以啟動新的 Amazon Elastic Compute Cloud 執行個體、修改 IAM 群組成員資格或刪除儲存 Amazon Simple Storage Service 貯體。下圖透過 IAM 基礎設施說明此流程：

![\[此圖表顯示委託人如何經過 IAM 服務驗證和授權，以在其他 AWS 服務或資源上執行動作或操作。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/intro-diagram _policies_800.png)


## 請求的元件
<a name="intro-structure-request"></a>

當委託人嘗試使用 AWS 管理主控台、 AWS API 或 時 AWS CLI，該委託人會傳送*請求*至 AWS。請求包含下列資訊：
+ **動作或操作** – 委託人想要執行的動作或操作。例如 中的 動作 AWS 管理主控台，或 AWS CLI 或 AWS API 中的 操作。
+ **資源** – 委託人請求執行動作或操作 AWS 的資源物件。
+ **主體** – 使用實體 (使用者或角色) 來傳送請求的人員或應用程式。主體的相關資訊包括許可政策。
+ **環境資料**：IP 地址、使用者代理程式、啟用 SSL 的狀態以及時間戳記的相關資訊。
+ **資源資料**：與所請求資源相關的資料，例如 DynamoDB 資料表名稱或 Amazon EC2 執行個體上的標籤。

AWS 會將請求資訊收集到*請求內容*中，IAM 會評估這些內容來授權請求。

## 如何對主體進行身分驗證
<a name="intro-structure-authentication"></a>

委託人 AWS 使用 IAM 驗證的登入資料登入 ，以允許委託人傳送請求 AWS。有些服務，例如 Amazon S3 和 AWS STS，允許匿名使用者提出特定請求。不過，這些服務是此規則的例外。每種類型的使用者都會經過身分驗證。
+ **根使用者** – 用於身分驗證的登入憑證是您用來建立 AWS 帳戶 和您當時指定的密碼的電子郵件地址。
+ **聯合委託人** – 您的身分提供者會驗證您的身分，並將您的登入資料傳遞給 AWS，您不需要直接登入 AWS。IAM Identity Center 和 IAM 都支援聯合身分。
+ **中的使用者 AWS IAM Identity Center 目錄** *（非聯合）* – 直接在 IAM Identity Center 預設目錄中建立的使用者使用 AWS 存取入口網站登入，並提供您的使用者名稱和密碼。
+ **IAM 使用者**：您可以透過提供您的帳戶 ID 或別名、使用者名稱以及密碼來登入。若要從 API 或 驗證工作負載 AWS CLI，您可以透過擔任角色來使用暫時登入資料，也可以透過提供存取金鑰和私密金鑰來使用長期登入資料。

  若要進一步了解 IAM 實體，請參閱 [IAM 使用者](id_users.md) 和 [IAM 角色](id_roles.md)。

AWS 建議您對所有使用者使用多重驗證 (MFA)，以提高帳戶的安全性。若要進一步了解 MFA，請參閱 [AWS IAM 中的多重要素驗證](id_credentials_mfa.md)。

## 授權和許可政策基本概念
<a name="intro-structure-authorization"></a>

授權是指擁有完成其請求所需許可的主體。在授權期間，IAM 使用請求內容中的值來識別適用於請求的政策。接著使用政策以決定是否允許或拒絕請求。IAM 會將大多數許可政策儲存為 [JSON 文件](access_policies.md#access_policies-json)，它們可指定主體實體的許可。

有[數種類型的政策](access_policies.md)會影響授權請求。若要提供使用者存取帳戶中 AWS 資源的許可，您可以使用身分型政策。資源型政策可授予[跨帳戶存取權](access_permissions-required.md#UserPermissionsAcrossAccounts)。若要在不同的帳戶中發出請求，在其他帳戶中的政策必須可讓您存取資源，*而且*您用來發出請求的 IAM 實體必須具備允許該請求的身分型政策。

IAM 會檢查適用於請求內容的每個政策。IAM 政策評估使用*明確拒絕*，這表示如果單一許可政策包含拒絕的動作，則 IAM 會拒絕整個請求並停止評估。由於*預設拒絕*請求，因此適用的許可政策必須允許 IAM 請求的每個部分，以授權您的請求。用於單一帳戶中請求的評估邏輯遵循以下基本規則：
+ 根據預設，所有的請求一律拒絕。(一般而言，一律允許使用帳戶中的資源的 AWS 帳戶根使用者 登入資料提出請求)。
+ 任何許可政策中的明確允許 (以身分為基礎或以資源為基礎的政策) 都會覆寫此預設值。
+  AWS Organizations 服務控制政策 (SCP) 或資源控制政策 (RCP)、IAM 許可界限或工作階段政策的存在會覆寫允許。如果這些政策類型中有一或多個存在，則它們必須全部允許該請求。否則，它會被隱含拒絕。如需 SCP 和 RCP 的詳細資訊，請參閱 *AWS Organizations User Guide* 中 [Authorization policies in AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html)。
+ 任何政策中的明確拒絕會覆寫任何政策中的任何允許。

如需詳細資訊，請參閱 [政策評估邏輯](reference_policies_evaluation-logic.md)。<a name="intro-structure-actions"></a>

在 IAM 驗證並授權主體之後，IAM 會透過評估適用於主體的許可政策來核准其請求中的動作或操作。每個 AWS 服務都會定義其支援的動作 （操作），並包含您可以對資源執行的動作，例如檢視、建立、編輯和刪除該資源。適用於主體的許可政策必須包含執行操作所需的動作。若要要進一步了解 IAM 如何評估許可政策，請參閱 [政策評估邏輯](reference_policies_evaluation-logic.md)。

該服務定義了主體可對每個資源執行的一組動作。建立許可政策時，務必包含您希望使用者執行的動作。例如，IAM 支援超過 40 個使用者資源動作，包括下列基本動作：
+ `CreateUser`
+ `DeleteUser`
+ `GetUser`
+ `UpdateUser`

此外，可以在許可政策中指定條件，以便在請求符合指定條件時提供對資源的存取。例如，您可能想要政策陳述式在特定日期之後生效，或者在 API 請求中出現特定值時控制存取。若要指定條件，請使用政策陳述式的 [`Condition`](reference_policies_elements_condition_operators.md) 元素。

在 IAM 核准請求中的操作之後，主體可以使用帳戶中的相關資源。資源是存在於服務內的物件。範例包括 Amazon EC2 執行個體、IAM 使用者和 Amazon S3 儲存貯體。如果主體建立請求，以對未包含在許可政策中的資源執行動作，則服務會拒絕該請求。例如，如果您擁有刪除 IAM 角色的許可，但您請求刪除 IAM 群組，則如果您沒有刪除 IAM 群組的許可，則請求會失敗。若要進一步了解不同 AWS 服務支援的動作、資源和條件索引鍵，請參閱 [AWS 服務的動作、資源和條件索引鍵](reference_policies_actions-resources-contextkeys.html)。

# 比較 IAM 身分和憑證
<a name="introduction_identity-management"></a>

在 中管理的身分 AWS Identity and Access Management 是 IAM 使用者、IAM 角色和 IAM 群組。這些身分是與您的 一起 AWS 建立的根使用者以外的身分 AWS 帳戶。

強烈建議您不要以根使用者處理日常作業，即使是管理作業。反之，應佈建其他使用者，並授予他們執行必要任務所需的許可。您可以將人員新增至 IAM Identity Center 目錄、將外部身分提供者與 IAM Identity Center 或 IAM 聯合，或建立最低權限的 IAM 使用者，以新增使用者。

為了提高安全性，我們建議您集中根存取，以協助您集中保護 AWS 帳戶 受管 的根使用者憑證 AWS Organizations。 [集中管理成員帳戶的根存取權](id_root-user.md#id_root-user-access-management)可讓您集中移除和防止長期根使用者憑證復原，防止大規模的意外根存取。啟用集中式根存取權後，您可以擔任特權工作階段，對成員帳戶執行動作。

設定使用者之後，您可以將 的存取權授予 AWS 帳戶 特定人員，並提供他們存取 資源的許可。

[作為最佳實務](best-practices.md)， AWS 建議您要求人類使用者擔任 IAM 角色來存取 ， AWS 以便他們使用臨時登入資料。如果您要管理 IAM Identity Center 目錄中的身分，或與身分提供者聯合使用身分，請遵循以下最佳實務。

## 條款
<a name="intro-structure-terms"></a>

使用 IAM 身分時通常會使用這些術語：

**IAM 資源**  
IAM 服務會存放這些資源。您可以從主控台中新增、編輯和移除這些資源。  
+ IAM 使用者
+ IAM 群組
+ IAM 角色
+ 許可政策
+ 身分提供者物件

**IAM 實體**  
 AWS 用於身分驗證的 IAM 資源。在資源型政策中將實體指定為主體。  
+ IAM 使用者
+ IAM 角色

**IAM 身分**  
在政策中授權以執行動作和存取資源的 IAM 資源。身分包括 IAM 使用者、IAM 群組及 IAM 角色。  
  

![\[此圖表顯示 IAM 使用者和 IAM 角色是即是實體也是身分的主體，但根使用者是既不是實體也不是身分的主體。圖表也會通知您 IAM 群組是身分。IAM 身分驗證會使用政策來控制身分的存取，但根使用者擁有完整的 AWS 資源存取，且不會受到身分或資源型 IAM 政策的限制。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/iam-terms-2.png)


**主體**  
可對 AWS 資源提出動作或操作請求的 AWS 帳戶根使用者、IAM 使用者或 IAM 角色。主體包括人類使用者、工作負載、聯合身分主體及擔任的角色。身分驗證之後，IAM 會根據委託人類型 AWS，授予委託人永久或暫時的登入資料來提出請求。  
*人類使用者*也稱為*人類身分*，例如相關人員、管理員、開發人員、操作員和應用程式消費者。  
*工作負載*是提供商業價值的資源和程式碼集合，例如應用程式、流程、操作工具和其他元件。  
*聯合身分主體*是指身分和憑證由其他身分提供者管理的使用者，例如 Active Directory、Okta 或 Microsoft Entra。  
*IAM 角色*是您可以在帳戶中建立的 IAM 身分，具有特定許可，可決定身分可以和不可以執行的動作。但是，角色的目的是讓需要它的任何人可代入，而不是單獨地與某個人員關聯。  
IAM 授予 IAM 使用者和根使用者長期憑證和 IAM 角色臨時憑證。 AWS IAM Identity Center 的使用者、OIDC 和 SAML 聯合身分主體在登入時擔任 IAM 角色 AWS，這會授予他們臨時憑證。[最佳實務](best-practices.md)是，建議您要求人類使用者和工作負載使用臨時登入資料存取 AWS 資源。

## IAM 使用者和 IAM Identity Center 之間的不同之處
<a name="intro-identity-users"></a>

 **IAM 使用者**不是單獨的帳戶；他們是您帳戶內的個別使用者。每個使用者都有自己的密碼來存取 AWS 管理主控台。您也可以為每個使用者建立個別的存取金鑰，讓使用者能利用程式設計方式提出請求，進而能使用您帳戶中的資源。

IAM 使用者及其存取金鑰具有 AWS 資源的長期登入資料。IAM 使用者的主要用途是讓無法使用 IAM 角色的工作負載能夠使用 API 或 CLI 向 AWS 服務提出程式設計請求。

**注意**  
對於需要具有程式化存取和長期憑證的 IAM 使用者的情況，我們建議您視需要更新存取金鑰。如需詳細資訊，請參閱[更新存取金鑰](id-credentials-access-keys-update.md)。

人力身分 （人員） 具有不同的許可需求**AWS IAM Identity Center 的使用者**，取決於他們正在執行的角色，並且可以 AWS 帳戶 在整個組織中在各種 中工作。如果您有需要存取金鑰的使用案例，您可以使用 支援這些使用案例 AWS IAM Identity Center 的使用者。透過 AWS 存取入口網站登入的人員可以取得具有 AWS 資源短期憑證的存取金鑰。如果是集中式存取管理，我們建議您使用 [AWS IAM Identity Center (IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) 管理他人對您帳戶的存取權和這些帳戶內的許可。IAM Identity Center 會自動設定 Identity Center 目錄做為您的預設身分來源，您可以在其中新增人員和群組，並將他們的存取層級指派給您的 AWS 資源。如需詳細資訊，請參閱 *AWS IAM Identity Center 使用者指南*中的[什麼是 AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。

這兩種使用者類型的主要區別在於，IAM Identity Center 中的使用者在存取管理主控台或 AWS 資源 AWS 之前，會在登入 時自動擔任 IAM 角色。每次使用者登入時，IAM 角色都會授予臨時登入資料 AWS。若要讓 IAM 使用者使用 IAM 角色登入，他們必須具有擔任和切換角色的許可，而且必須在存取 AWS 帳戶後明確選擇切換到想要擔任的角色。

## 來自現有身分來源的聯合身分使用者
<a name="intro-identity-federation"></a>

如果組織中的使用者已在登入公司網路時進行身分驗證，則您不需要為他們建立個別 IAM 使用者，或建立 IAM Identity Center 使用者。反 AWS 之，您可以使用 IAM 或 *將這些使用者身分聯合*到 AWS IAM Identity Center。OIDC 和 SAML 聯合身分主體擔任 IAM 角色，該角色可為其提供存取特定資源的許可。如需角色的詳細資訊，請參閱[角色術語和概念](id_roles.md#id_roles_terms-and-concepts)。

![\[此圖表顯示聯合身分主體如何取得臨時 AWS 安全登入資料，以存取 中的資源 AWS 帳戶。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/iam-intro-federation.diagram.png)


在下列情況下，聯合很有用：
+ **您的使用者已存在於公司目錄。**

  如果您的公司目錄與安全性聲明標記語言 2.0 (SAML 2.0) 相容，您可以設定公司目錄， AWS 管理主控台 為您的使用者提供 的單一登入 (SSO) 存取權。如需詳細資訊，請參閱[暫時性憑證的常見案例](id_credentials_temp.md#sts-introduction)。

  如果您的公司目錄與 SAML 2.0 不相容，您可以建立身分代理程式應用程式， AWS 管理主控台 為您的使用者提供 的單一登入 (SSO) 存取權。如需詳細資訊，請參閱[啟用 AWS 主控台的自訂身分代理程式存取](id_roles_providers_enable-console-custom-url.md)。

  如果您的公司目錄是 Microsoft Active Directory，您可以使用 AWS IAM Identity Center 連接 Active Directory 中的自我管理目錄或 中的目錄[AWS Directory Service](https://aws.amazon.com/directoryservice/)，以在公司目錄與 之間建立信任 AWS 帳戶。

  如果您使用 Okta 或 Microsoft Entra 等外部身分提供者 (IdP) 來管理使用者，您可以使用 AWS IAM Identity Center 來建立 IdP 與 之間的信任 AWS 帳戶。如需詳細資訊，請參閱《AWS IAM Identity Center 使用者指南》** 中的 [連結至外部身分供應商](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)。
+ **您的使用者已經有網際網路身分。**

  如果您正在建立行動應用程式或 Web 為基礎的應用程式，讓使用者透過網際網路身分提供者 (例如，Login with Amazon、Facebook、Google 或任何與 OpenID Connect (OIDC) 相容的身分提供者) 識別自己的身分，則該應用程式可以使用聯合功能存取 AWS。如需詳細資訊，請參閱[OIDC 聯合身分](id_roles_providers_oidc.md)。
**提示**  
若要搭配網際網路身分提供者使用聯合身分，建議您使用 [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)。

## 提供使用者存取權的不同方法
<a name="AccessControlMethods"></a>

以下是您可以提供 AWS 資源存取權的方法。


****  

| 使用者存取類型 | 何時使用？ | 在哪裡可以獲得更多資訊？ | 
| --- | --- | --- | 
|  針對相關人員 (例如您的人力使用者)，使用 IAM Identity Center 的單一登入存取來存取 AWS 資源  |  IAM Identity Center 提供集中位置，可集中管理使用者及其對 AWS 帳戶 和雲端應用程式的存取。 您可以在 IAM Identity Center 中設定身分存放區，或者您也可以使用現有的身分提供者 (IdP) 設定聯合。安全最佳實務建議將有限登入資料授予您的人類使用者 AWS 。 相關人員擁有更簡單的登入體驗，而您也能從單個系統持續控制他們的資源存取權。IAM Identity Center 支援多重要素驗證 (MFA)，以提高對帳戶安全的保護。  |  如需有關設定 IAM Identity Center 的詳細資訊，請參閱《AWS IAM Identity Center 使用者指南》**中的[入門](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)。 如需有關使用 IAM Identity Center 中的 MFA 的詳細資訊，請參閱《AWS IAM Identity Center 使用者指南》**中的[多重要素驗證](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)。  | 
| 針對人類使用者 (例如您的人力使用者)，使用 IAM 身分提供者 (IdP) 的聯合存取來存取 AWS 服務 | IAM 支援 IdP，其與 OpenID Connect (OIDC) 或 SAML 2.0 (安全性聲明標記語言 2.0) 相容。建立 IAM 身分提供者後，可建立一個或多個 IAM 角色，這些角色可以動態指派給聯合身分主體。 | 如需有關 IAM 身分提供者與聯合的詳細資訊，請參閱 [身分提供者和聯合身分 AWS](id_roles_providers.md)。 | 
|  之間的跨帳戶存取 AWS 帳戶  |  您想要與其他 中的使用者共用特定 AWS 資源的存取權 AWS 帳戶。 角色是授予跨帳戶存取權的主要方式。不過，一些 AWS 服務支援資源型政策，允許您直接將政策連接到資源 (而不是使用角色做為代理)。  | 如需關於 IAM 角色的詳細資訊，請參閱 [IAM 角色](id_roles.md)。 如需服務連結角色的詳細資訊，請參閱[建立服務連結角色](id_roles_create-service-linked-role.md)。 如需有關哪些服務支援使用服務連結角色的資訊，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)。尋找**服務連結角色**欄中顯示為**是**的服務。若要檢視該服務的服務連結角色文件，請選擇該欄中與 **Yes (是)** 相關聯的連結。  | 
|  您 中指定 IAM 使用者的長期登入資料 AWS 帳戶  |  您可能有特定的使用案例，需要具有 IAM 使用者的長期登入資料 AWS。您可以使用 IAM 在 中建立這些 IAM 使用者 AWS 帳戶，並使用 IAM 管理其許可。以下是部分使用案例： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/introduction_identity-management.html) 對於需要具有[程式化存取和長期憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)的 IAM 使用者的情況，我們建議的[最佳實務](best-practices.md)是視需要更新存取金鑰。如需詳細資訊，請參閱[更新存取金鑰](id-credentials-access-keys-update.md)。  | 如需有關設定 IAM 使用者的詳細資訊，請參閱 [在 中建立 IAM 使用者 AWS 帳戶](id_users_create.md)。 如需有關 IAM 使用者存取金鑰的詳細資訊，請參閱 [管理 IAM 使用者的存取金鑰](id_credentials_access-keys.md)。 如需 AWS CodeCommit 或 Amazon Keyspaces 的服務特定登入資料的詳細資訊，請參閱 [CodeCommit 的 IAM 登入資料：Git 登入資料、SSH 金鑰和 AWS 存取金鑰](id_credentials_ssh-keys.md)和 [將 IAM 與 Amazon Keyspaces (適用於 Apache Cassandra) 搭配使用](id_credentials_keyspaces.md)。  | 

## 支援程式設計使用者存取
<a name="gs-get-keys"></a>

如果使用者想要與 AWS 外部互動，則需要程式設計存取 AWS 管理主控台。授予程式設計存取權的方式取決於正在存取的使用者類型 AWS：
+ 如果您在 IAM Identity Center 中管理身分， AWS APIs需要設定檔，而 AWS Command Line Interface 需要設定檔或環境變數。
+ 如果您有 IAM 使用者， AWS APIs和 AWS Command Line Interface 需要存取金鑰。如有可能，請建立臨時憑證，其中包含存取金鑰 ID、私密存取金鑰，以及指出憑證何時到期的安全記號。

若要授予使用者程式設計存取權，請選擇下列其中一個選項。


| 哪個使用者需要程式設計存取權？ | 選項 | 其他資訊 | 
| --- | --- | --- | 
|  人力資源身分  (IAM Identity Center 中管理的人員和使用者)  | 使用短期登入資料簽署對 AWS CLI 或 AWS APIs程式設計請求 （直接使用或使用 AWS SDKs)。 |  對於 AWS CLI，請遵循[《 使用者指南》中的取得 CLI 存取的 IAM 角色登入](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtogetcredentials.html)資料中的指示。 *AWS IAM Identity Center * 對於 AWS APIs，請遵循 *AWS SDKs 和工具參考指南*中 [SSO 登入](https://docs.aws.amazon.com//sdkref/latest/guide/feature-sso-credentials.html)資料的指示。  | 
| IAM 使用者 | 使用短期登入資料簽署對 AWS CLI 或 AWS APIs程式設計請求 （直接使用或使用 AWS SDKs)。 | 請遵循[將臨時登入資料與 AWS 資源](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_use-resources.html)搭配使用中的指示。 | 
| IAM 使用者 | 使用長期登入資料簽署對 AWS CLI 或 AWS APIs程式設計請求 （直接使用或使用 AWS SDKs)。(不建議使用) | 請遵循[管理 IAM 使用者的存取金鑰](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html)中的指示。 | 
| 聯合身分主體 | 使用 AWS STS API 操作建立具有暫時性安全登入資料的新工作階段，其中包含存取金鑰對和工作階段字符。 | 如需 API 操作的說明，請參閱 [請求臨時安全憑證](id_credentials_temp_request.md) | 

# 許可和政策如何提供存取管理
<a name="introduction_access-management"></a>

 AWS Identity and Access Management (IAM) 的存取管理部分可協助您定義委託人實體在帳戶中可執行的操作。主體實體是指使用 IAM 實體 (IAM 使用者或角色) 執行身分驗證的人員或應用程式。存取管理通常稱為*授權*。您可以透過 AWS 建立政策並將其連接至 IAM 身分 (IAM 使用者、IAM 群組或 IAM 角色） 或 AWS 資源來管理 中的存取。政策是 中的物件， AWS 當與身分或資源相關聯時， 會定義其許可。當委託人使用 IAM 實體 (IAM 使用者或 IAM 角色） 提出請求時， 會 AWS 評估這些政策。政策中的許可決定是否允許或拒絕請求。大多數政策會以 JSON 文件 AWS 的形式存放在 中。如需有關政策類型及其使用的詳細資訊，請參閱 [中的政策和許可 AWS Identity and Access Management](access_policies.md)。

## 政策和帳戶
<a name="intro-access-accounts"></a>

如果您在 中管理單一帳戶 AWS，則會使用 政策定義該帳戶中的許可。如果您跨多個帳戶管理許可，您的 IAM 使用者會更難管理許可。對於跨帳戶許可，您可以使用 IAM 角色、以資源為基礎的政策或存取控制清單 (ACL)。不過，如果您擁有多個帳戶，我們建議您改用 AWS Organizations 服務來協助您管理這些許可。如需詳細資訊，請參閱*AWS Organizations 《 使用者指南*》中的[什麼是 AWS Organizations？](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)。

## 政策與使用者
<a name="intro-access-users"></a>

IAM 使用者是 AWS 帳戶中的身分。當您建立 IAM 使用者，在您提供許可前他們無法存取您帳戶中的任何項目。可透過建立連接到 IAM 使用者或該 IAM 使用者所屬 IAM 群組的身分型政策，為 IAM 使用者提供許可。下列範例顯示 JSON 政策，其允許 IAM 使用者執行 `us-east-2` 區域內 `123456789012` 帳戶之 `Books` 資料表上的所有 Amazon DynamoDB 動作 (`dynamodb:*`)。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books"
  }
}
```

------

 將此政策連接至 IAM 使用者後，使用者有權執行 DynamoDB 執行個體的 `Books` 資料表中的所有動作。大多數 IAM 使用者都有多個政策，這些政策可合併以代表其授予的總許可。

根據預設，政策未明確允許的動作或資源會被拒絕。例如，如果上述政策是連接到使用者的單一政策，則該使用者可以對 `Books` 資料表執行 DynamoDB 動作，但無法對其他資料表執行動作。同樣地，不允許使用者在 Amazon EC2、Amazon S3 或任何其他 AWS 服務中執行任何動作，因為使用這些服務的許可不包含在政策中。

## 政策和 IAM 群組
<a name="intro-access-groups"></a>

您可以將 IAM 使用者組織到 *IAM 群組*並將政策連接到 IAM 群組。在這種情況下，各個 IAM 使用者仍有自己的憑證，但是 IAM 群組中的所有 IAM 使用者都擁有連接到 IAM 群組的許可。使用 IAM 群組可更輕鬆地進行許可管理。

![\[此圖顯示 IAM 使用者如何被組織到 IAM 群組中，讓許可管理更加輕鬆，因為每個 IAM 使用者擁有指派給 IAM 群組的許可。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/iam-intro-users-and-groups.diagram.png)


IAM 使用者或 IAM 群組可以有多個政策與之連接，分別授予不同的許可。在這種情況下，政策組合會決定主體的有效許可。如果主體沒有動作和資源的明確 `Allow` 許可，則主體沒有這些許可。

## 聯合身分使用者工作階段和角色
<a name="intro-access-roles"></a>

聯合主體不會像 IAM 使用者 AWS 帳戶 那樣擁有永久身分。若要向聯合身分主體指派許可，可以建立稱為*角色*的實體，並為角色定義許可。當 SAMl 或 OIDC 聯合委託人登入 時 AWS，使用者會與該角色建立關聯，並獲授予角色中定義的許可。如需詳細資訊，請參閱[為第三方身分提供者建立角色](id_roles_create_for-idp.md)。

## 以身分為基礎和以資源為基礎的政策
<a name="intro-access-resource-based-policies"></a>

以身分為基礎的政策是指您連接到 IAM 身分的許可政策，這些身分包括像是 IAM 使用者、群組或角色。以資源為基礎的政策是您連接到資源的許可政策，這些資源包括像是 Amazon S3 儲存貯體或 IAM 角色信任政策。

***以身分為基礎政策***可控制身分在何種條件下對哪些資源執行哪些動作。身分型政策可進一步分類：
+ **受管政策**：您可以連接到 中多個使用者、群組和角色的獨立身分型政策 AWS 帳戶。您可以使用兩種類型受管政策：
  + **AWS 受管政策** – 由 建立和管理的受管政策 AWS。如果您是初次使用 政策，建議您先使用 AWS 受管政策。
  + **客戶管理政策**：您在 AWS 帳戶中建立和管理的受管政策。客戶受管政策提供比 AWS 受管政策更精確的政策控制。您可以在視覺化編輯器建立和編輯和驗證 IAM 政策，或直接建立 JSON 政策文件。如需更多詳細資訊，請參閱 [使用客戶管理政策定義自訂 IAM 許可](access_policies_create.md) 及 [編輯 IAM 政策](access_policies_manage-edit.md)。
+ **內嵌政策**：由您建立和管理並直接嵌入到單一使用者、群組或角色的政策。在大多數情況下，我們建議您不要使用內嵌政策。

***以資源為基礎的政策***可控制指定的主體在何種條件下對該資源執行哪些動作。資源為基礎的政策是內嵌政策，而且沒有受管的以資源為基礎的政策。如需啟用跨帳戶存取權，您可以在其他帳戶內指定所有帳戶或 IAM 實體作為資源型政策的主體。****

IAM 服務支援一種稱為角色*信任政策*的資源型政策，它可連接到 IAM 角色。由於 IAM 角色是支援資源型政策的身分也是資源，所以您必須將信任政策和身分型政策同時連接到 IAM 角色。信任政策會定義哪些委託人實體 （帳戶、使用者、角色和聯合身分使用者委託人） AWS STS 可以擔任該角色。若要了解 IAM 角色與其他以資源為基礎之政策之間的差別，請參閱 [IAM 中的跨帳戶資源存取](access_policies-cross-account-resource-access.md)。

若要查看哪些服務支援以資源為基礎的政策，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)。若要進一步了解以資源為基礎的政策的詳細資訊，請參閱 [以身分為基礎和以資源為基礎的政策](access_policies_identity-vs-resource.md)。

# 使用 ABAC 授權根據屬性定義許可
<a name="introduction_attribute-based-access-control"></a>

屬性型存取控制 (ABAC) 是一種授權策略，可根據屬性定義許可。 會 AWS 呼叫這些屬性*標籤*。您可以將標籤連接至 IAM 資源，包括 IAM 實體 (IAM 使用者或 IAM 角色） 和 AWS 資源。您可以為您的 IAM 主體建立單一 ABAC 政策或是一組政策。您可以設計 ABAC 政策，當主體的標籤與資源標籤相符時允許操作。ABAC 的屬性系統可提供較高的使用者內容和精細的存取控制。由於 ABAC 是以屬性為基礎，因此可以對實時授予或撤銷存取權的資料或應用程式執行動態授權。ABAC 在擴展環境中以及身分或資源政策管理變得複雜的情況下很有用。

例如，您可以使用 `access-project` 標籤鍵建立三個 IAM 角色。將第一個 IAM 角色的標籤值設為 `Heart`，第二個設為 `Star`，並將第三個設為 `Lightning`。然後，您可以使用單一政策，在 IAM 角色和資源 AWS 具有標籤值 時允許存取`access-project`。如需示範如何在 AWS中使用 ABAC 的詳細教學，請參閱 [IAM 教學課程：定義根據標籤存取 AWS 資源的許可](tutorial_attribute-based-access-control.md)。若要瞭解支援 ABAC 的服務，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)。

![\[此圖表說明套用至主體的標籤必須符合套用至資源的標籤，才能為使用者授予資源許可。標籤可套用至 IAM 群組、資源群組、個別使用者和個別資源。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/tutorial-abac-concept-23.png)


## ABAC 與傳統 RBAC 模型的比較
<a name="introduction_attribute-based-access-control_compare-rbac"></a>

IAM 中使用的傳統授權模型為角色型存取控制 (RBAC)。RBAC 會根據人員的任務函數或*角色*來定義許可，這與 IAM 角色不同。IAM 確實包括在 RBAC 模型中將許可對齊到任務功能的[用於任務角色的受管政策](access_policies_job-functions.md)。

在 IAM 中，您可以為不同的任務角色建立不同的政策，來實作 RBAC。然後，您可以將政策連接到身分 (IAM 使用者、IAM 群組或 IAM 角色)。根據[最佳實務](best-practices.md)，您應授與任務角色所需要的最低許可。這會導致[最低權限](best-practices.md#grant-least-privilege)存取。每個工作職能政策都會列出該身分指派該政策可存取的特定資源。使用傳統 RBAC 模型的缺點是當您或您的使用者新增新的資源至環境時，您必須更新政策以允許存取這些新資源。

例如，假設您有三個員工正在進行的專案，分別名為 `Heart`、`Star` 和 `Lightning`。您為每個專案建立 IAM 角色。接著將政策連接到各 IAM 角色，定義允許擔任 IAM 角色的人員所能存取的資源。若一名員工在您的公司內變更了職位，您便會將他們指派至不同的 IAM 角色。可將人員或程式指派給多個 IAM 角色。但是，`Star` 專案可能需要其他資源，例如，新的 Amazon EC2 容器。在這種情況下，您必須更新連接到 `Star` IAM 角色的政策，指定新的容器資源。否則，`Star` 專案的成員便無法存取新的容器。

![\[此圖表說明角色型存取控制要求為每個身分指派一個以特定工作職能為基礎的政策，以存取不同的資源。\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/tutorial-abac-rbac-concept-23.png)


**與傳統 RBAC 模型相較，ABAC 提供了下列優點：**
+ **ABAC 許可隨創新擴展。**管理員不再需要更新現有政策來允許存取新的資源。例如，假設您使用 `access-project` 標籤設計您的 ABAC 策略。開發人員可將 IAM 角色與 `access-project` = `Heart` 標籤搭配使用。當 `Heart` 專案的人員需要額外 Amazon EC2 資源時，開發人員便可以使用 `access-project` = `Heart` 標籤建立新的 Amazon EC2 執行個體。接著，`Heart` 專案的任何人員便可以開始和停止這些執行個體，因為他們的標籤值相符。
+ **ABAC 需要的政策較少。**由於您不需要為不同的任務功能建立不同政策，您建立的政策也會較少。這些政策較易於管理。
+ **使用 ABAC 時，團隊可以動態回應變化和增長。**由於新資源的許可會根據屬性自動授予，因此不需要手動將政策指派給身分。例如，若您的公司已使用 ABAC 支援 `Heart` 和 `Star`，新增新的 `Lightning` 專案也相當容易。IAM 管理員可以使用 `access-project` = `Lightning` 標籤建立新的 IAM 角色。不需要變更政策來支援新的專案。有權承擔 IAM 角色的任何人員都可建立和檢視標記有 `access-project` = `Lightning` 的執行個體。另一個情況是團隊成員從 `Heart` 專案移至 `Lightning` 專案時。若要提供團隊成員對 `Lightning` 專案的存取權，IAM 管理員可將他們指派給不同的 IAM 角色。而不需要變更許可政策。
+ **使用 ABAC 可實現精密許可。**在您建立政策時，最佳實務是[授與最低權限](best-practices.md#grant-least-privilege)。使用傳統 RBAC 時，需要撰寫允許存取特定資源的政策。但是，當您使用 ABAC 時，如果資源標籤與主體標籤相符，可以允許對所有資源執行動作。
+ **搭配 ABAC 使用您企業目錄的員工屬性。**您可以設定 SAML 或 OIDC 提供者，將工作階段標籤傳遞至 IAM。當您的員工聯合到 時 AWS，IAM 會將其屬性套用至其產生的委託人。您接著可以使用 ABAC 來根據這些屬性允許或拒絕許可。

如需示範如何在 中使用 ABAC 的詳細教學課程 AWS，請參閱 [IAM 教學課程：定義根據標籤存取 AWS 資源的許可](tutorial_attribute-based-access-control.md)。