AWS の ABAC とは - AWS Identity and Access Management

AWS の ABAC とは

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

たとえば、access-project タグキーを使用して 3 つのロールを作成できます。最初のロールのタグ値を Heart に設定し、2 番目を Sun に、3 番目を Lightning に設定します。その後、ロールとリソースが access-project の同じ値でタグ付けされたときに、アクセスを許可する 1 つのポリシーを使用できます。AWS の ABAC の使用方法を説明する詳細なチュートリアルについては、「チュートリアル: AWS で属性ベースのアクセスコントロールにタグを使用する」を参照してください。


         ABAC モデル

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

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

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

たとえば、従業員が取り組んでいる LightningHeartSun、という名前の 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 インスタンスを作成できます。その後は、タグ値が一致するため、 Heart プロジェクトのすべてのユーザーがこれらのインスタンスを起動および停止できます。

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

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

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

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

AWS の ABAC の使用方法を説明する詳細なチュートリアルについては、「チュートリアル: AWS で属性ベースのアクセスコントロールにタグを使用する」を参照してください。