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

# 使用 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)。