ABAC 是做什麼用的 AWS？

屬性型存取控制 (ABAC) 是一種授權策略，可根據屬性來定義許可。在中 AWS，這些屬性稱為標籤。您可以將標籤附加到 IAM 資源，包括 IAM 實體 (使用者或角色) 和 AWS 資源。您可以為您的 IAM 主體建立單一 ABAC 政策或是一組政策。這些 ABAC 政策可以設計成在主體的標籤與資源標籤相符時允許操作。ABAC 在成長快速的環境中相當有幫助，並能在政策管理變得繁瑣時提供協助。

例如，您可以使用 access-project 標籤鍵建立三個角色。將第一個角色的鍵值設為 Heart，第二個角色的鍵值設為 Star，並將第三個角色的鍵值設為 Lightning。然後，您可以使用單一政策，在角色和資源針對 access-project 使用相同值標記時允許存取。如需示範如何在中使用 ABAC 的詳細教學課程 AWS，請參閱IAM 教學課程：根據標籤定義存取 AWS 資源的許可。若要瞭解支援 ABAC 的服務，請參閱 AWS 與 IAM 搭配使用的服務。

比較 ABAC 與傳統 RBAC 模型

IAM 中使用的傳統授權模型稱為角色類型存取控制 (RBAC)。RBAC 會根據人員的任務角色 (在 AWS 外稱為角色) 來定義許可。在 AWS 角色中通常是指 IAM 角色，這是您可以假設的 IAM 中的身分。IAM 確實包括在 RBAC 模型中將許可對齊到任務功能的用於任務角色的受管政策。

在 IAM 中，您可以為不同的任務角色建立不同的政策，來實作 RBAC。然後，您可以將政策連接到身分 (IAM 使用者、使用者群組或 IAM 角色)。根據最佳實務，您應授與任務角色所需要的最低許可。這稱為授與最低權限。透過列出任務功能所能存取的特定資源，即可執行此作業。使用傳統 RBAC 模型的缺點是當員工新增新的資源時，您必須更新政策以允許存取這些新資源。

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

與傳統 RBAC 模型相較，ABAC 提供了下列優點：

• ABAC 許可隨創新擴展。管理員不再需要更新現有政策來允許存取新的資源。例如，假設您使用 access-project 標籤設計您的 ABAC 策略。開發人員以 access-project = Heart 標籤使用角色。當 Heart 專案的人員需要額外 Amazon EC2 資源時，開發人員便可以使用 access-project = Heart 標籤建立新的 Amazon EC2 執行個體。接著，Heart 專案的任何人員便可以開始和停止這些執行個體，因為他們的標籤值相符。

• ABAC 需要的政策較少。由於您不需要為不同的任務功能建立不同政策，您建立的政策也會較少。這些政策較易於管理。

• 使用 ABAC，團隊便可以快速地改變和成長。這是因為新資源會自動根據屬性授與許可。例如，若您的公司已使用 ABAC 支援 Heart 和 Star，新增新的 Lightning 專案也相當容易。IAM 管理員可以使用 access-project = Lightning 標籤建立新的角色。不需要變更政策來支援新的專案。任何具備取得角色許可的人員都能建立和檢視以 access-project = Lightning 標記的執行個體。此外，團隊成員可能會從 Heart 專案移動至 Lightning 專案。IAM 管理員可以將使用者指派至不同的 IAM 角色。而不需要變更許可政策。

• 使用 ABAC 可實現精密許可。在您建立政策時，最佳實務是授與最低權限。使用傳統 RBAC，您必須撰寫政策，只允許存取特定資源。但是，當您使用 ABAC 時，您可以允許在所有資源上進行所有動作，但只有在資源標籤與主體標籤相符時才能進行。

• 搭配 ABAC 使用您企業目錄的員工屬性。您可以將 SAML 或 OIDC 提供者設定為將工作階段標記傳遞給。 AWS當您的員工聯合到時 AWS，他們的屬性會套用至其產生的主參與者。 AWS您接著可以使用 ABAC 來根據這些屬性允許或拒絕許可。

如需示範如何在中使用 ABAC 的詳細教學課程 AWS，請參閱IAM 教學課程：根據標籤定義存取 AWS 資源的許可。