Amazon Nimble Studio 的身分和存取管理 - Amazon Nimble Studio
目標對象使用身分驗證使用政策管理存取權

支援終止通知：在 2024 年 10 月 22 日， AWS 將停止對 Amazon Nimble Studio 的支援。2024 年 10 月 22 日之後，您將無法再存取 Nimble Studio 主控台或 Nimble Studio 資源。

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

Amazon Nimble Studio 的身分和存取管理

AWS Identity and Access Management (IAM) 是一種 AWS 服務 ，可協助管理員安全地控制對 AWS 資源的存取。管理員可控制誰可以進行身分驗證 （登入） 和授權 （具有許可） 來使用 Amazon Nimble Studio 資源。IAM 是 AWS 服務 您可以免費使用的 。

主題

目標對象

使用方式 AWS Identity and Access Management (IAM) 會有所不同，取決於您在 Nimble Studio 中執行的工作。

服務使用者 – 如果您使用 Nimble Studio 服務來執行任務，則您是服務使用者。在這種情況下，您的管理員將為您提供存取指派資源所需的登入資料和許可。當您使用更多 Nimble Studio 功能來執行工作時，您可能需要額外的許可。了解存取許可的管理方式可協助您向管理員請求正確的許可。如果您無法存取 Nimble Studio 中的功能，請參閱 對 Amazon Nimble Studio 身分和存取進行故障診斷。

服務管理員 – 如果您在公司負責 Nimble Studio 資源，您可能可以完整存取 Nimble Studio。您的任務是判斷員工應存取哪些 Nimble Studio 功能和資源。然後，向您的管理員提交請求，以變更服務使用者的許可。檢閱此頁面上的資訊，了解 IAM 的基本概念。若要進一步了解貴公司如何搭配 Nimble Studio 使用 IAM，請參閱Amazon Nimble Studio 如何與 IAM 搭配使用。

使用身分驗證

身分驗證是您 AWS 使用身分憑證登入 的方式。如需使用 登入的詳細資訊 AWS 管理主控台，請參閱《IAM 使用者指南》中的以 IAM 使用者或根使用者 AWS 管理主控台 身分登入 。

您需要以 AWS 帳戶 根使用者、使用者或擔任 IAM 角色身分進行身分驗證 （登入 AWS)。您也可以使用公司的單一登入身分驗證，甚至使用 Google 或 Facebook 登入。在上述案例中，您的管理員會使用 IAM 角色預先設定聯合身分。當您 AWS 使用其他公司的登入資料存取 時，您會間接擔任 角色。

若要直接登入 AWS 管理主控台，請使用您的密碼搭配您的根使用者電子郵件地址或使用者名稱。您可以使用根使用者或使用者存取 AWS 金鑰，以程式設計方式存取 。

AWS 提供 SDK 和命令列工具，以密碼編譯方式使用您的登入資料簽署請求。如果您不使用 AWS 工具，請自行簽署請求。請使用 Signature 第 4 版來執行此作業，它是針對傳入 API 請求進行身分驗證的通訊協定。如需驗證請求的詳細資訊，請參閱 中的簽章第 4 版簽署程序 AWS 一般參考 。

無論您使用何種身分驗證方法，您可能還需要提供額外的安全性資訊。例如， AWS 建議您使用多重要素驗證 (MFA) 來提高帳戶的安全性。若要進一步了解，請參閱《IAM 使用者指南》中的使用多重要素驗證 (MFA) AWS。

AWS 帳戶 根使用者

當您第一次建立 時 AWS 帳戶，您會從單一登入身分開始，該身分可完整存取 帳戶中的所有 AWS 服務 和資源。此身分稱為 AWS 帳戶 Theroot 使用者，可透過使用您用來建立帳戶的電子郵件地址和密碼登入來存取。強烈建議您不要將根使用者用於日常任務，即使是管理任務。反之，請遵循僅以根使用者建立您第一個 IAM 使用者的最佳實務。接著請妥善鎖定根使用者登入資料，只用來執行少數的帳戶與服務管理作業。

使用者和群組

使用者是 中具有單一人員或應用程式特定許可 AWS 帳戶 的身分。使用者可以擁有長期憑證或一組存取金鑰。若要了解如何產生存取金鑰，請參閱《IAM 使用者指南》中的管理 IAM 使用者的存取金鑰。當您為使用者產生存取金鑰時，請檢視並安全地儲存金鑰對。您未來無法復原秘密存取金鑰。反之， 會產生新的存取金鑰對。

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

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

IAM 角色

IAM 角色是 中具有特定許可 AWS 帳戶 的身分。它類似於使用者，但與特定人員沒有關聯。您可以 AWS 管理主控台 切換角色，暫時在 中擔任 IAM 角色。您可以透過呼叫 AWS CLI 或 AWS API 操作或使用自訂 URL 來擔任角色。如需使用角色方法的詳細資訊，請參閱《IAM 使用者指南》中的使用 IAM 角色。

使用暫時憑證的 IAM 角色在下列情況中非常有用：

  • 暫時使用者許可 - 使用者可以擔任 IAM 角色來暫時針對特定任務採用不同的許可。

  • 聯合身分使用者存取 – 您可以使用來自 Directory Service企業使用者目錄或 Web 身分提供者的現有身分，而不是建立使用者。這些稱為聯合身分使用者。透過身分提供者身分提供者來請求存取時， AWS 會指派角色給聯合身分使用者。如需聯合身分使用者的詳細資訊，請參閱《IAM 使用者指南》中的聯合身分使用者和角色。

    • 成員資格 – Nimble Studio 使用名為 'membership' 的概念，為使用者提供特定啟動設定檔的存取權。成員資格可讓 Studio 管理員將資源存取權委派給使用者，而不必撰寫或了解 IAM 政策。當 Nimble Studio 管理員在啟動設定檔中為使用者建立成員資格時，該使用者有權執行使用啟動設定檔所需的 IAM 動作，例如檢視其屬性，以及使用該啟動設定檔啟動串流工作階段。

    • 服務角色 – 服務角色是服務擔任的 IAM 角色，可代表您執行動作。服務角色只會在您的 帳戶中提供存取權，無法用來授予其他帳戶中服務的存取權。管理員可以從 IAM 內建立、修改和刪除服務角色。如需詳細資訊，請參閱《IAM 使用者指南》中的建立角色以將許可委派給 AWS 服務 。

    • 服務連結角色 – 服務連結角色是連結至 的服務角色類型 AWS 服務。服務可以擔任代表您執行動作的角色。Nimble Studio 不支援服務連結角色。

  • 在 Amazon EC2 上執行的應用程式 – 您可以使用 IAM 角色來管理在 EC2 執行個體上執行之應用程式的臨時登入資料，以及提出 AWS CLI 或 AWS API 請求。這是在 EC2 執行個體內儲存存取金鑰的較好方式。若要將 AWS 角色指派給 EC2 執行個體，並將其提供給其所有應用程式，您可以建立連接至執行個體的執行個體描述檔。執行個體設定檔包含該角色，並且可讓 EC2 執行個體上執行的程式取得暫時憑證。如需詳細資訊，請參閱《IAM 使用者指南》中的使用 IAM 角色將許可授予在 Amazon EC2 執行個體上執行的應用程式。

若要了解如何使用 IAM 角色或使用者，請參閱《IAM 使用者指南》中的何時建立 IAM 角色 （而非使用者）。

使用政策管理存取權

您可以透過建立政策並將其連接至 IAM 身分或 AWS 資源 AWS 來控制 中的存取。政策是 中的物件， AWS 當與身分或資源建立關聯時， 會定義其許可。您可以以根使用者身分登入，也可以擔任 IAM 角色。然後，當您提出請求時， 會 AWS 評估相關的身分型或資源型政策。政策中的許可決定是否允許或拒絕請求。大多數政策會以 JSON 文件 AWS 的形式存放在 中。如需 JSON 政策文件結構和內容的詳細資訊，請參閱《IAM 使用者指南》中的 JSON 政策概觀。

管理員可以使用 AWS JSON 政策來指定誰可以存取內容。也就是說，哪個委託人可以對哪些資源以及哪些條件執行動作。

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

IAM 政策定義該動作的許可，無論您使用何種方法來執行操作。例如，假設您有一個允許 iam:GetRole 動作的政策。具有該政策的使用者可以從 AWS 管理主控台 AWS CLI、 或 AWS API 取得角色資訊。

身分型政策

以身分為基礎的政策是 JSON 許可政策文件，您可以連接到身分，例如使用者、使用者群組或角色。這些政策控制使用者和角色可以執行的動作、資源以及條件。若要了解如何建立身分型政策，請參閱《IAM 使用者指南》中的建立 IAM 政策。

身分型政策可進一步分類成內嵌政策或受管政策。內嵌政策會直接內嵌到單一使用者、群組或角色。受管政策是獨立的政策，您可以連接到 中的多個使用者、群組和角色 AWS 帳戶。受管政策包括 AWS 受管政策和客戶受管政策。若要了解如何在受管政策或內嵌政策之間進行選擇，請參閱《IAM 使用者指南》中的在受管政策和內嵌政策之間進行選擇。

資源型政策

資源型政策是連接到資源的 JSON 政策文件。資源型政策的最常見範例是 IAM 角色信任政策和 Amazon S3 儲存貯體政策。在支援資源型政策的服務中，服務管理員可以使用它們來控制對特定資源的存取權限。對於附加政策的資源，政策會定義指定主體可以對該資源執行的動作，以及針對哪些條件執行的動作。在資源型政策中指定委託人。委託人可以包括帳戶、使用者、角色、聯合身分使用者或 AWS 服務。

資源型政策是位於該服務中的內嵌政策。您無法在資源型政策中使用來自 IAM 的 AWS 受管政策。

Nimble Studio 中的存取控制清單 (ACLs)

存取控制清單 (ACL) 可控制哪些主體 (帳戶成員、使用者或角色) 擁有存取某資源的許可。ACLs 類似於以資源為基礎的政策，雖然它們不使用 JSON 政策文件格式。

Amazon S3 AWS WAF和 Amazon VPC 是支援 ACLs的服務範例。如需進一步了解 ACL，請參閱 Amazon Simple Storage Service 開發人員指南中的存取控制清單 (ACL) 概觀。

其他政策類型

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

  • 許可界限 – 許可界限是一種進階功能，您可以在其中設定身分型政策可授予 IAM 實體 （使用者或角色） 的最大許可。您可以為實體設定許可界限。產生的許可是實體身分型政策及其許可界限的交集。在 Principal 欄位中指定使用者或角色的資源型政策不受許可界限限制。所有這類政策中的明確拒絕都會覆寫該允許。如需許可界限的詳細資訊，請參閱《IAM 使用者指南》中的 IAM 實體的許可界限。

  • 服務控制政策 SCPs) – SCPs是 JSON 政策，可在 Organizations 中指定組織或組織單位 (OU) 的最大許可。Organizations 是一項服務，用於分組和集中管理企業擁有 AWS 帳戶 的多個 。若您啟用組織中的所有功能，您可以將服務控制政策 (SCP) 套用到任何或所有帳戶。SCP 會限制成員帳戶中實體的許可，包括每個 AWS 帳戶 根使用者。如需 Organizations 和 SCPs的詳細資訊，請參閱 AWS Organizations 使用者指南中的 SCPs運作方式。

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

多種政策類型

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