Amazon Q 開發人員的身分識別和存取管理

AWS Identity and Access Management (IAM) 可協助系統管理員安全地控制 AWS 資源存取權。 AWS 服務 IAM 管理員控制誰可以驗證 (登入) 和授權 (具有權限) 使用 Amazon Q 開發人員資源。 IAM 是您 AWS 服務 可以免費使用的。

主題

• 物件
• 使用身分驗證
• 使用政策管理存取權
• Amazon Q 開發人員如何使用 IAM
• 使用政策管理 Amazon Q 開發人員的存取權
• Amazon Q 開發人員許可參考
• AWS Amazon Q 開發人員的受管政策
• 針對 Amazon Q 開發人員和使用者訂閱使用服務連結角色

物件

您的使用方式會有所 IAM 不同，具體取決於您在 Amazon Q 中所做的工作。

服務使用者 ‒ 如果您使用 Amazon Q 執行任務，您的管理員會為您提供您需要的憑證和許可。隨著您為了執行作業而使用的 Amazon Q 功能數量變多，您可能會需要額外的許可。瞭解存取許可的管理方式可協助您向管理員請求正確的許可。

服務管理員 − 如果您在公司負責管理 Amazon Q 資源，建議您掌握 Amazon Q 的完整存取權。您的任務是決定服務使用者應該存取哪些 Amazon Q 功能和資源。然後，您必須向 IAM 管理員提交請求，才能變更服務使用者的權限。檢閱此頁面上的資訊，以瞭解的基本概念 IAM。若要進一步了解貴公司如何 IAM 搭配 Amazon Q 使用，請參閱 Amazon Q 如何搭配使用 IAM。

IAM 管理員 — 如果您是管理 IAM 員，可能想要了解如何撰寫政策來管理 Amazon 問的存取權限的詳細資訊。如果您是管理IAM員，請考慮瞭解如何撰寫政策以管理IAM使用者對服務的存取權限的詳細資訊。如需 Amazon Q 的特定資訊，請參閱 Amazon Q 的AWS 區域 受管政策。

使用身分驗證

驗證是您 AWS 使用身分認證登入的方式。您必須以 AWS 帳戶 root 使用者、或假設 IAM 角色來驗證 (登入 AWS)。 IAM 使用者

您可以使用透過 AWS 身分識別來源提供的認證，以聯合身分識別身分登入。 AWS IAM Identity Center (IAM Identity Center) 使用者、貴公司的單一登入驗證，以及您的Google或Facebook認證都是同盟身分的範例。當您以聯合身分登入時，您的管理員先前已設定使用 IAM 角色的聯合身分。當您使 AWS 用同盟存取時，您會間接擔任角色。

根據您的使用者類型，您可以登入 AWS Management Console 或 AWS 存取入口網站。如需有關登入的詳細資訊 AWS，請參閱《AWS 登入 使用指南》 AWS 帳戶中的如何登入您的。

無論您使用何種身分驗證方法，您可能還需要提供額外的安全性資訊。例如， AWS 建議您使用多重要素驗證 (MFA) 來增加帳戶的安全性。若要深入瞭解，請參閱使用AWS IAM Identity Center 者指南中的多重要素驗證和使用多重要素驗證 (MFA) AWS的使用IAM者指南。

AWS 帳戶根使用者

當您第一次建立時 AWS 帳戶，您會從單一登入身分開始，該身分可以完整存取帳戶中的所有資源 AWS 服務 和資源。此身份稱為 AWS 帳戶根使用者 ，可透過使用您用來建立帳戶的電子郵件地址和密碼登入來存取。強烈建議您不要以根使用者處理日常作業。保護您的根使用者憑證，並將其用來執行只能由根使用者執行的任務。如需需要您以 root 使用者身分登入的完整工作清單，請參閱《使用指南》中的〈需要 root 使用者認證的IAM工作〉。

聯合身分

最佳作法是要求人類使用者 (包括需要系統管理員存取權的使用者) 使用與身分識別提供者的同盟，才能使用臨時認證 AWS 服務 來存取。

聯合身分識別是來自企業使用者目錄的使用者、Web 身分識別提供者、Identity Center 目錄，或使用透過身分識別來源提供的認證進行存取 AWS 服務 的任何使用者。 AWS Directory Service同盟身分存取時 AWS 帳戶，他們會假設角色，而角色則提供臨時認證。

對於集中式存取權管理，我們建議您使用 AWS IAM Identity Center。您可以在 IAM Identity Center 中建立使用者和群組，也可以連線並同步至您自己身分識別來源中的一組使用者和群組，以便在所有應用程式 AWS 帳戶 和應用程式中使用。如需IAM身分識別中心的相關資訊，請參閱IAM識別中心是什麼？ 在《AWS IAM Identity Center 使用者指南》中。

IAM 使用者 和群組

A IAM 使用者是您的身分，具 AWS 帳戶 有單一人員或應用程式的特定權限。在可能的情況下，我們建議您仰賴臨時登入資料，而不 IAM 使用者 要建立具有密碼和存取金鑰等長期認證的使用者。不過，如果您有需要長期認證的特定使用案例 IAM 使用者，建議您輪換存取金鑰。如需詳細資訊，請參閱《使用指南》中的「IAM定期輪換存取金鑰」以瞭解需要長期認證的使用案例。

IAM 群組是指定集合的識別 IAM 使用者。您無法以群組身分登入。您可以使用群組來一次為多名使用者指定許可。群組可讓管理大量使用者許可的程序變得更為容易。例如，您可以擁有一個名為的群組，IAMAdmins並授與該群組管理 IAM 資源的權限。

使用者與角色不同。使用者只會與單一人員或應用程式建立關聯，但角色的目的是在由任何需要它的人員取得。使用者擁有永久的長期憑證，但角色僅提供暫時憑證。有關詳情，請參閱《IAM用戶指南》中的何時建立 IAM 使用者 （而非角色）。

IAM 角色

IAM 角色是您 AWS 帳戶 中具有特定權限的身份。IAM角色與特定人員相似， IAM 使用者 但與特定人員無關。您可以切換角色來暫時擔任中 AWS Management Console 的角色。 IAM 您可以通過調用 AWS Command Line Interface （AWS CLI）或 AWS API操作或使用自定義來承擔角色URL。如需有關使用角色方法的詳細資訊，請參閱《使用指南》中的IAM〈使用 IAM 角色〉。

IAM 具有臨時認證的角色在下列情況下很有用：

• 聯合身分使用者存取 — 如需向聯合身分指派許可，請建立角色，並為角色定義許可。當聯合身分進行身分驗證時，該身分會與角色建立關聯，並獲授予由角色定義的許可。如需聯合角色的相關資訊，請參閱《使用指南》中的〈建立第三方身分識別提供IAM者的角色〉。如果您使用IAM身分識別中心，則需要設定權限集。為了控制身分驗證後可以存取的內 IAM容，IAMIdentity Center 會將權限集與中的角色相關聯。如需有關許可集的資訊，請參閱 AWS IAM Identity Center 使用者指南中的許可集。

• 臨時 IAM 使用者 權限 — IAM 使用者 可以假定某個 IAM 角色暫時對特定任務具有不同的權限。

• 跨帳戶存取 — 您可以使用 IAM 角色允許不同帳戶中的某個人 (受信任的主體) 存取您帳戶中的資源。角色是授予跨帳戶存取權的主要方式。但是，對於某些策略 AWS 服務，您可以將策略直接附加到資源（而不是使用角色作為代理）。如需有關跨帳戶存取角色與以資源為基礎的政策之間差異的詳細資訊，請參閱《IAM使用指南》中的IAM 角色與以資源為基礎的政策有何不同。

• 跨服務訪問 — 有些 AWS 服務 使用其他 AWS 服務功能。服務可能會使用呼叫主體的許可、使用服務角色或使用服務連結角色來執行此作業。

  • 主參與者權限 — 當您使用 IAM 使用者 或角色執行中的動作時 AWS，您會被視為主參與者。政策能將許可授予主體。當您使用某些服務時，您可能會執行一個動作，然後在不同的服務中觸發另一個動作。在此情況下，您必須具有執行這兩個動作的許可。

  • 服務角色 − 服務角色是服務擔任的 IAM 角色，可代表您執行動作。 IAM 管理員可以從中建立、修改和刪除服務角色 IAM。如需詳細資訊，請參閱《IAM使用指南》 AWS 服務中的建立角色以將權限委派給

  • 服務連結角色 — 服務連結角色是連結至. AWS 服務服務可以擔任代表您執行動作的角色。服務連結角色會顯示在您的中， AWS 帳戶 且屬於服務所有。 IAM 管理員可以檢視但無法編輯服務連結角色的權限。

• 執行中的應用程式 Amazon EC2 — 您可以使用 IAM 角色來管理在執行個體上 Amazon EC2 執行的應用程式以及發出 AWS CLI 或 AWS API要求的應用程式的臨時認證。這比在 Amazon EC2 實例中存儲訪問密鑰更好。若要將 IAM 角色指派給 Amazon EC2 執行個體並讓其所有應用程式都能使用，請建立附加至執行個體的執行個體設定檔。執行個體設定檔包含角色，可讓執行個體上 Amazon EC2 執行的程式取得臨時登入資料。如需詳細資訊，請參閱《使用指南》中的使用 IAM 角色將權限授與在 Amazon EC2 執行個體上執行的應IAM用程式。

有關是否使用 IAM 角色的更多信息，請參閱《用戶指南》中的何時創建 IAM 角色（而不是用IAM戶）。

使用政策管理存取權

您可以透 AWS 過建立原則並將其附加至 AWS 身分識別或資源來控制中的存取。原則是一個物件 AWS ，當與身分識別或資源相關聯時，會定義其權限。 AWS 當主參與者 (使用者、root 使用者或角色工作階段) 提出要求時，評估這些原則。政策中的許可決定是否允許或拒絕請求。大多數原則會 AWS 以JSON文件的形式儲存在中。如需有關JSON原則文件結構和內容的詳細資訊，請參閱《IAM使用指南》中的策略概觀。JSON

管理員可以使用 AWS JSON策略來指定誰可以存取什麼內容。也就是說，哪個主體在什麼條件下可以對什麼資源執行哪些動作。

每個 IAM 實體（用戶或角色）都沒有權限開始。根據預設，使用者無法執行任何作業，甚至也無法變更他們自己的密碼。若要授予使用者執行動作的許可，管理員必須將許可政策附加到使用者。或者，管理員可以將使用者新增到具備預定許可的群組。管理員將許可給予群組時，該群組中的所有使用者都會獲得那些許可。

IAM 原則會定義動作的權限，不論您用來執行作業的方法為何。例如，假設您有一個允許 iam:GetRole 動作的政策。具有該原則的使用者可以從 AWS Management Console AWS CLI、或取得角色資訊 AWS API。

身分型政策

以身分識別為基礎的原則是您可以附加至身分識別 (例如、角色或群組) 的JSON IAM 使用者權限原則文件。這些政策可控制身分在何種條件下能對哪些資源執行哪些動作。如需如何建立身分型原則的詳細資訊，請參閱《IAM使用指南》中的〈建立 IAM 策略〉。

身分型政策可進一步分類成內嵌政策或受管政策。內嵌政策會直接內嵌到單一使用者、群組或角色。受管理的策略是獨立策略，您可以將其附加到您的 AWS 帳戶. 受管政策包括 AWS 受管政策和客戶管理的策略。如需如何在受管理的原則或內嵌原則之間進行選擇的詳細資訊，請參閱《IAM使用指南》中的「在受管策略和內嵌政策之間進行選擇」。

資源型政策

以資源為基礎的JSON政策是您附加至資源 (例如 Amazon S3 儲存貯體) 的政策文件。服務管理員可使用這些政策來定義指定委託人 (帳戶成員、使用者或角色) 可以在什麼情況下對該資源執行什麼動作。資源型政策是內嵌政策。不存在受管的資源型政策。

存取控制清單 (ACLs)

存取控制清單 (ACLs) 是一種策略類型，可控制哪些主參與者 (帳號成員、使用者或角色) 具有存取資源的權限。ACLs類似於以資源為基礎的策略，雖然它們不使用JSON政策文件格式。 Amazon S3 AWS WAF、和 Amazon VPC 是支援的服務範例ACLs。如需有關的詳細資訊ACLs，請參閱 Amazon S3 使用者指南中的存取控制清單 (ACL) 概觀。

其他政策類型

AWS 支援其他較不常見的原則類型。這些政策類型可設定較常見政策類型授予您的最大許可。

• 權限界限 — 權限界限是一項進階功能，您可以在其中設定以身分識別為基礎的原則可授與給 IAM 實體 (IAM 使用者 或角色) 的最大權限。您可以為實體設定許可界限。產生的權限是實體以身分識別為基礎的原則及其權限界限的交集。會在 Principal 欄位中指定使用者或角色的資源型政策則不會受到許可界限限制。所有這類政策中的明確拒絕都會覆寫該允許。如需有關權限界限的詳細資訊，請參閱《IAM使用指南》中的IAM 實體的權限界限。

• 服務控制策略 (SCPs) — SCPs 是指定中組織或組織單位 (OU) 最大權限的JSON策略 AWS Organizations。 AWS Organizations 是一種用於分組和集中管理您企業擁 AWS 帳戶 有的多個服務。如果您啟用組織中的所有功能，則可以套用SCPs至任何或所有帳戶。SCP限制成員帳戶中實體的權限，包括每個 AWS 帳戶 root 使用者。若要取得有關 Organizations 的更多資訊SCPs，請參閱《AWS Organizations 使用指南》中的〈SCPs運作方式〉

• 工作階段政策 – 工作階段政策是一種進階政策，您可以在透過編寫程式的方式建立角色或聯合使用者的暫時工作階段時，作為參數傳遞。所產生工作階段的許可會是使用者或角色的身分型政策和工作階段政策的交集。許可也可以來自資源型政策。所有這類政策中的明確拒絕都會覆寫該允許。如需詳細資訊，請參閱IAM使用指南中的工作階段原則。

多種政策類型

將多種政策類型套用到請求時，其結果形成的許可會更為複雜、更加難以理解。若要瞭解如何在涉及多個原則類型時 AWS 決定是否允許要求，請參閱IAM使用指南中的原則評估邏輯。