ABAC 認可で属性に基づいてアクセス許可を定義する

属性ベースのアクセスコントロール (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 リソースにアクセスするためのアクセス許可を定義する」を参照してください。ABACをサポートするサービスについては、IAM と連携する AWS のサービス を参照してください。

ABAC と従来の RBAC モデルの比較

IAM で使用される従来の認可モデルは、ロールベースのアクセスコントロール (RBAC) です。RBAC は、IAM ロールとは異なる、ユーザーの職務機能またはロールに基づいて許可を定義します。IAMには、RBACモデルのジョブ機能にアクセス許可を調整するジョブ機能の管理ポリシーが含まれています。

IAM では、職務機能ごとに異なるポリシーを作成して RBAC を実装します。次に、ポリシーを ID (IAM ユーザー、IAM グループ、または IAM ロール) にアタッチします。ベストプラクティスとして、職務機能に必要な最小限のアクセス許可を付与します。これにより、最小特権アクセスを実現できます。各職務機能ポリシーには、そのポリシーに割り当てられた ID がアクセスできる特定のリソースがリストされます。従来の RBAC モデルを使用することの欠点は、管理者またはユーザーが環境に新しいリソースを追加する際に、それらのリソースへのアクセスを許可するためにポリシーを更新する必要があるということです。

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

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 を使用すると、きめ細かなアクセス許可が可能です。ポリシーを作成するときは、 最小限のアクセス許可を付与することがベストプラクティスです。従来の RBAC では、特定のリソースへのアクセスを許可するポリシーを記述します。ただし、ABAC を使用する場合、リソースのタグがプリンシパルのタグと一致する場合、すべてのリソースでアクションを許可できます。

• ABAC を使用して、社内ディレクトリの従業員属性を使用します。セッションタグを IAM に渡すよう SAML または OIDC プロバイダーを設定できます。従業員が AWS にフェデレーションすると、IAM は、結果として得られるプリンシパルに従業員の属性を適用します。その後、ABAC を使用して、これらの属性に基づいてアクセス許可を許可または拒否できます。

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