AWS の ABAC とは - AWS Identity and Access Management
ABAC と従来の RBAC モデルの比較

AWS の ABAC とは

属性ベースのアクセスコントロール (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。これらの属性は、AWS でタグと呼ばれています。タグは、IAM エンティティ (ユーザーまたはロール) を含めた IAM リソース、および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または少数のポリシーのセットを作成できます。これらの ABAC ポリシーは、プリンシパルのタグがリソースタグと一致するときに操作を許可するように設計することができます。ATBAC は、急成長する環境や、ポリシー管理が煩雑になる状況で役に立ちます。

例えば、access-project タグキーを使用して 3 つのロールを作成できます。最初のロールのタグ値を Heart、2 番目を Sun、3 番目を Lightning に設定します。そうすることで、access-project に関してロールとリソースが同じ値でタグ付けされているときにアクセスを許可する単一のポリシーを使用できます。AWS の ABAC の使用方法を説明する詳細なチュートリアルについては、「IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する」を参照してください。ABACをサポートするサービスについては、IAM と連携する AWS のサービス を参照してください。

ABAC モデル

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

IAM で使用される従来の認証モデルは、ロールベースのアクセスコントロール (RBAC) と呼ばれます。RBAC は、AWS の外部でロールとして知られる、ユーザーの職務機能に基づいてアクセス許可を定義します。AWS 内では、ロールは通常 IAM ロールを指します。IAM ロールは、引き受けることができる IAM の ID です。IAMには、RBACモデルのジョブ機能にアクセス許可を調整するジョブ機能の管理ポリシーが含まれています。

IAM では、職務機能ごとに異なるポリシーを作成して RBAC を実装します。次に、ポリシーを ID（IAM ユーザー、ユーザーのグループ、または IAM ロール）にアタッチします。ベストプラクティスとして、職務機能に必要な最小限のアクセス許可を付与します。これは、最小アクセス許可の付与と呼ばれます。これを行うには、職務機能がアクセスできる特定のリソースを一覧表示します。従来の RBAC モデルを使用することの欠点は、従業員が新しいリソースを追加するときに、それらのリソースへのアクセスを許可するようにポリシーを更新する必要があることです。

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

RBAC モデル
ABAC には、従来の RBAC モデルと比べて以下の利点があります。

  • ABAC のアクセス許可は、イノベーションに合わせてスケールされます。新しいリソースへのアクセスを許可するために、管理者が既存のポリシーを更新する必要はありません。たとえば、access-project タグを使用して ABAC 戦略を設計したとします。開発者は、access-project = Heart タグでロールを使用します。Heart プロジェクトのユーザーが追加の Amazon EC2 リソースを必要とする場合、開発者は access-project = Heart タグを使用して新しい Amazon EC2 instances インスタンスを作成できます。その後は、タグ値が一致するため、 Heart プロジェクトのすべてのユーザーがこれらのインスタンスを起動および停止できます。

  • ABAC では必要なポリシーが少なくなります。職務機能ごとに異なるポリシーを作成する必要がないため、作成するポリシーは少なくなります。これらのポリシーは管理しやすくなります。

  • ABAC を使用することで、チームは迅速に変化し、成長することができます。これは、新しいリソースの許可が属性に基づいて自動的に付与されるためです。たとえば、会社が ABAC を使用して Heart プロジェクトと Sun プロジェクトをすでにサポートしている場合、新しい Lightning プロジェクトは簡単に追加できます。IAM 管理者は、access-project = Lightning タグを使用して新しいロールを作成します。新しいプロジェクトをサポートするためにポリシーを変更する必要はありません。ロールを引き受けるアクセス許可を持っているユーザーは、 access-project = Lightning でタグ付けされたインスタンスを作成および表示できます。また、チームメンバーが Heart プロジェクトから Lightning プロジェクトに移動する場合があります。 管理者は、ユーザーを別の IAM ロールに割り当てます。アクセス許可ポリシーを変更する必要はありません。

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

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

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