# ABAC 認可で属性に基づいてアクセス許可を定義する
<a name="introduction_attribute-based-access-control"></a>

属性ベースのアクセスコントロール (ABAC) は、属性に基づいて許可を定義する認可戦略です。AWS はこれらの属性をタグと呼んでいます。タグは、IAM エンティティ (IAM ユーザーまたは IAM ロール) を含めた IAM リソース、および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または少数のポリシーのセットを作成できます。プリンシパルのタグがリソースタグと一致したら操作を許可する ABAC ポリシーを設計できます。詳細なユーザーコンテキストときめ細かなアクセスコントロールの両方を提供する ABAC の属性システム。ABAC は属性ベースであるため、アクセスをリアルタイムで付与または取り消すデータまたはアプリケーションについて動的認可を実行できます。ABAC は、スケールしている環境や、ID またはリソースポリシーの管理が複雑になった状況で役立ちます。

例えば、`access-project` タグキーを使用して 3 つの IAM ロールを作成できます。最初の IAM ロールのタグ値を `Heart`、2 番目を `Star`、3 番目を `Lightning` に設定します。その後、IAM ロールと AWS リソースにタグ値 `access-project` がある場合にアクセスを許可する単一のポリシーを使用できます。AWS の ABAC の使用方法を説明する詳細なチュートリアルについては、「[IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する](tutorial_attribute-based-access-control.md)」を参照してください。ABACをサポートするサービスについては、[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md) を参照してください。

![\[この図は、リソースに対する許可をユーザーに付与するために、プリンシパルに適用されるタグが、リソースに適用されるタグと一致する必要があることを示しています。タグは、IAM グループ、リソースグループ、個々のユーザー、個々のリソースに適用されます。\]](http://docs.aws.amazon.com/ja_jp/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 を実装します。次に、ポリシーを ID (IAM ユーザー、IAM グループ、または IAM ロール) にアタッチします。[ベストプラクティス](best-practices.md)として、職務機能に必要な最小限のアクセス許可を付与します。これにより、[最小特権](best-practices.md#grant-least-privilege)アクセスを実現できます。各職務機能ポリシーには、そのポリシーに割り当てられた ID がアクセスできる特定のリソースがリストされます。従来の RBAC モデルを使用することの欠点は、管理者またはユーザーが環境に新しいリソースを追加する際に、それらのリソースへのアクセスを許可するためにポリシーを更新する必要があるということです。

たとえば、従業員が取り組んでいる `Lightning`、`Heart`、`Star`、という名前の 3 つのプロジェクトがあるとします。各プロジェクトの IAM ロールを作成します。次に、ポリシーを各 IAM ロールにアタッチして、IAM ロールを引き受けることができるすべてのユーザーがアクセスできるリソースを定義します。従業員が社内でジョブを変更した場合は、別の IAM ロールに割り当てます。複数の IAM ロールに人々またはプログラムを割り当てることができます。ただし、`Star` プロジェクトでは、新しい Amazon EC2 コンテナなどの追加のリソースが必要になる場合があります。その場合は、`Star` IAM ロールにアタッチされたポリシーを更新して、新しいコンテナリソースを指定する必要があります。そうしないと、`Star` プロジェクトメンバーは新しいコンテナにアクセスできません。

![\[この図は、ロールベースのアクセスコントロールでは、異なるリソースにアクセスするために、各 ID に特定の職務機能ベースのポリシーを割り当てる必要があることを示しています。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/tutorial-abac-rbac-concept-23.png)


**ABAC には、従来の RBAC モデルと比べて以下の利点があります。**
+ **ABAC のアクセス許可は、イノベーションに合わせてスケールされます。**新しいリソースへのアクセスを許可するために、管理者が既存のポリシーを更新する必要はありません。たとえば、`access-project` タグを使用して ABAC 戦略を設計したとします。開発者は、`access-project` = `Heart` タグで IAM ロールを使用します。`Heart` プロジェクトのユーザーが追加の Amazon EC2 リソースを必要とする場合、開発者は `access-project` = `Heart` タグを使用して新しい Amazon EC2 instances インスタンスを作成できます。その後は、タグ値が一致するため、 `Heart` プロジェクトのすべてのユーザーがこれらのインスタンスを起動および停止できます。
+ **ABAC では必要なポリシーが少なくなります。**職務機能ごとに異なるポリシーを作成する必要がないため、作成するポリシーは少なくなります。これらのポリシーは管理しやすくなります。
+ **ABAC を使用すると、チームは変化や成長に動的に対応できます。**新しいリソースについての許可は属性に基づいて自動的に付与されるため、ID にポリシーを手動で割り当てる必要はありません。たとえば、会社が ABAC を使用して `Heart` プロジェクトと `Star` プロジェクトをすでにサポートしている場合、新しい `Lightning` プロジェクトは簡単に追加できます。IAM 管理者は、`access-project` = `Lightning` タグを使用して新しい IAM ロールを作成します。新しいプロジェクトをサポートするためにポリシーを変更する必要はありません。IAM ロールを引き受けるアクセス許可を持っているユーザーは、 `access-project` = `Lightning` でタグ付けされたインスタンスを作成および表示できます。もう 1 つのシナリオは、チームメンバーが `Heart` プロジェクトから `Lightning` プロジェクトに移動する場合です。`Lightning` プロジェクトへのアクセスをチームメンバーに提供するために、IAM 管理者は、それらを別の IAM ロールに割り当てます。アクセス許可ポリシーを変更する必要はありません。
+ **ABAC を使用すると、きめ細かなアクセス許可が可能です。**ポリシーを作成するときは、 [最小限のアクセス許可を付与](best-practices.md#grant-least-privilege)することがベストプラクティスです。従来の RBAC では、特定のリソースへのアクセスを許可するポリシーを記述します。ただし、ABAC を使用する場合、リソースのタグがプリンシパルのタグと一致する場合、すべてのリソースでアクションを許可できます。
+ **ABAC を使用して、社内ディレクトリの従業員属性を使用します。**セッションタグを IAM に渡すよう SAML または OIDC プロバイダーを設定できます。従業員が AWS にフェデレーションすると、IAM は、結果として得られるプリンシパルに従業員の属性を適用します。その後、ABAC を使用して、これらの属性に基づいてアクセス許可を許可または拒否できます。

AWS の ABAC の使用方法を説明する詳細なチュートリアルについては、「[IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する](tutorial_attribute-based-access-control.md)」を参照してください。