🦙

ABACでEntra IDの属性に従ってAWSアクセスを制御する

2024/12/31に公開

AWS

 1.はじめに前回記事でEntra IDのグループやユーザーをSCIMでAWS IAM Identity Centerに自動連携しました。

今回はEntra IDに登録されている属性情報に従ってIAM Identity Centerで権限を細かくコントロールするABAC（Attribute－Based Access Control）を試してみたいと思います。

 2.RBACとABACとはまずABACとはなにか、RBACと比較しながら説明してみます。

RBAC (Role-Based Access Control) は役割ベースのアクセス制御で、ユーザーに割り当てられた役割（ロール）に基づいてアクセス権限を管理する方式です。例えば、「管理者」「一般ユーザー」「閲覧者」といった役割を定義し、各役割に対して適切な権限を設定します。
ABAC (Attribute-Based Access Control) は属性ベースのアクセス制御で、より柔軟なアクセス制御を実現します。ユーザーの属性（部署、役職、場所など）、リソースの属性（機密レベル、所有者など）、環境属性（時間、IPアドレスなど）、アクションの属性など、複数の要素を組み合わせてアクセス制御を行います。
以下に、ABACとRBACの主な特徴を比較した表を示します：

観点
RBAC
ABAC

制御基準
役割（ロール）
複数の属性の組み合わせ

柔軟性
比較的低い（役割定義の範囲内）
高い（属性の組み合わせで細かい制御が可能）

設定の複雑さ
シンプル
複雑（多くの属性と条件の組み合わせ）

メンテナンス性
容易（役割の追加・変更が主）
やや困難（属性や条件の組み合わせの管理が必要）

スケーラビリティ
中程度（役割数が増えると管理が複雑化）
高い（属性ベースで柔軟に対応可能）

適用例
組織構造が明確で、権限が役割と紐づく場合
きめ細かい制御が必要で、状況に応じた柔軟な制御が求められる場合

実装の容易さ
比較的容易
やや困難（多くの属性と条件の評価が必要）

パフォーマンス
高い（単純な役割チェック）
やや低い（複数の属性評価が必要）

私はABACを自分で使ったり運用したことはないのですが、実際のシステムや運用ではRBACを基本的に使用しつつ、より細かい制御が必要な部分でABACを適用するなど、両者を組み合わせて使用することが多いと思われます。

 3.IAM Identity CenterでABAC設定
 3-1.ABAC有効化まずはIAM Identity CenterでABACを有効化する必要があります。
AWSマネージメントコンソールのIAM Identity Centerの左側のメニューから「Settings」を選択

「アクセスコントロールの属性」をEnableにします

有効化すると下記のような表示がされ、「アクセスコントロールの属性」タブが表示されます

今回はデフォルトの属性を使用するので属性は設定しません

 3-2.カスタム許可セットの作成IAM Identity Centerコンソールの左側のメニューから「Permission sets」を選択

「許可セットを作成」をクリック

「カスタム許可セット」を選択し、「次へ」をクリック

ポリシーを設定

下記のような動きを想定した設定をしたいと思います。
EC2インスタンス表示を許可
属性：部署developのメンバーはEC2のStartInstanceを許可
属性：役職managerのメンバーはEC2のStopInstanceを許可

ポリシーは今回はインラインポリシーで記載します。

インラインポリシーの▽をクリックして設定を展開し、下記のようにポリシーを設定して「次へ」をクリック

インラインポリシー
{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"ec2:DescribeInstances"
			],
			"Resource": "*"
		},
		{
			"Effect": "Allow",
			"Action": [
				"ec2:StartInstances"
			],
			"Resource": [
				"*"
			],
			"Condition": {
				"StringEquals": {
					"aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
				}
			}
		},
		{
			"Effect": "Allow",
			"Action": [
				"ec2:StopInstances"
			],
			"Resource": [
				"*"
			],
			"Condition": {
				"StringEquals": {
					"aws:ResourceTag/Title": "${aws:PrincipalTag/Title}"
				}
			}
		}
	]
}
許可セット名（dev-department）を入力して「次へ」をクリック

確認画面が出るので、問題なければ「作成」をクリック

許可セットdev-departmentが作成されました。まだプロビジョニングはされていません。

 4.Entra属性設定
Azureポータルにログイン
「Microsoft Entra ID」->「エンタープライズアプリケーション」->「AWS IAM Identity Center」を開く

左メニューから「シングル サインオン」を選択し、「属性とクレーム」の編集をクリック

「新しいクレームの追加」を選択

クレームの設定をします

名前：権限設定に使用する属性名を入力します。

今回は部署名で権限を分けるためにAccessControl:Departmentと設定

名前空間：https://aws.amazon.com/SAML/Attributesと入力

ソース：「属性」を選択

ソース属性：user.departmentを選択

入力したら「保存」をクリックします。

部署名以外に役職でも権限を分けるために、もう1つクレーム（title）を追加しておきます。

 5.Entraにグループ、ユーザーを追加ABACを試すためにEntraにグループとユーザーを追加し、エンタープライズアプリケーションを割り当てします。

 5-1.グループ、ユーザー追加「Microsoft Entra ID」->「グループ」の左メニューから「すべてのグループ」を開き、「新しいグループ」をクリックします

AWS-Developというグループを作成するため、以下情報を入力します。
グループの種類：セキュリティ
グループ名：AWS-Develop
グループの説明：AWS開発用アクセスグループ
所有者：（自分のアカウントを選択）
メンバー：（後でユーザーを追加するため、ここでは空のまま）

入力後に「作成」をクリックして、グループを作成します。
「Microsoft Entra ID」->「ユーザー」の左メニューから「すべてのユーザー」を開きます。

「新しいユーザー」をクリックし、「新しいユーザーの作成」をクリックします

基本情報の設定
ユーザープリンシパル名：awsdeveloper
表示名：AWS developer
パスワード：パスワード自動生成（チェックを入れる）
有効なアカウント（チェックを入れる）

「プロパティ」をクリック
プロパティの設定
名：Develop
姓：Member
ユーザーの種類：メンバー
役職：developer
部署：develop

「割り当て」をクリック
割り当ての設定
「グループの追加」をクリック

「AWS-Develop」（先ほど作成したグループ）にチェックを入れて「選択」をクリック

「ロールの追加」は不要

「次：確認と作成」をクリック
確認と作成
ユーザープリンシパル名をメモしておきます
初期パスワードをメモしておきます

※この画面を閉じると二度と初期パスワードは表示されません

「作成」をクリック
同じように3～7手順に従って別ユーザーを作成します

基本情報
ユーザープリンシパル名：awsdevmanager
表示名：AWS dev manager

プロパティ
名：Develop
姓：Manager
ユーザーの種類：メンバー
役職：manager
部署：develop

グループは「AWS-Develop」に追加

ユーザープリンシパル名と初期パスワードをメモして作成します。
グループのメンバーシップ確認
「Microsoft Entra ID」->「グループ」の左メニューから「すべてのグループ」を開き、「AWS-Develop」を選択
「ユーザー」をクリック
作成したユーザー（AWS developerとAWS dev manager）が表示されていることを確認

 5-2.エンタープライズアプリケーションへのグループ割り当て
Azureポータルにログイン
「Microsoft Entra ID」->「エンタープライズアプリケーション」->「AWS IAM Identity Center」を開く

3.左メニューで「ユーザーとグループ」を選択し、「ユーザーまたはグループの追加」を選択

ユーザーとグループの「選択されていません」の箇所をクリックし、「AWS-Develop」グループを選択して「選択」をクリック

「割り当て」をクリック

これでAWSのシングルサインオンにAWS-Developグループも割り当てられました。

 6.テスト用AWSリソース作成テスト用EC2を作成します。
AWSマネージメントコンソールでEC2画面を開き、「インスタンス」->「インスタンスを起動」でEC2を作成していきます。

一旦起動・停止ができればよいので適当に作成します。

名前：test-abac

AMI：Amazon Linux 2023 AMI

インスタンスタイプ：t2.micro

キーペア：キーペアなしで続行

VPC：適当なVPC

サブネット：できればPrivateサブネットのほうがよい

セキュリティグループ：適当なセキュリティグループ

あとはデフォルトで可。「インスタンスを起動」でインスタンスを作成します。タグはあとで設定します。

インスタンスが起動したらタグを設定します。

作成したインスタンスを選択して、「アクション」->「インスタンスの設定」->「タグを管理」

「新規タグを追加」をクリックしてタグ2個を追加します。
タグ1

タグキー：Department

値：develop
タグ2

タグキー：Title

値：manager

タグを設定したら、「保存」をクリックします。
EC2を停止しておきます

インスタンスを選択して、「インスタンスの状態」->「インスタンスを停止」

確認画面が表示されるので「停止」をクリック

 7.許可セット割り当てグループに許可セットを割り当てます。
IAM Identity Centerコンソールの左側のメニューから「AWS accounts」を選択

AWSアカウントツリーが表示されるので、許可セットを割り当てたいアカウントにチェックを入れて、「ユーザーまたはグループを割り当て」をクリックします。

AWS-Developにチェックを入れて「次へ」
!グループ、ユーザーの同期には最大40分かかります。オンデマンドでプロビジョニングも可能です。

4. 作成した許可セット「dev-department」にチェックを入れて「次へ」

確認画面が表示されるので、問題なければ「送信」

成功すれば下記が表示されます。

 8.developユーザーで動作確認ブラウザのシークレットモードでウィンドウを開き、AWS access portal URLにアクセスすると、Microsoftのサインイン画面になります。

※シークレットモードを使用せずにそのままログインしても問題ありませんが、もとのセッションは切れてしまいます

awsdeveloperユーザーでサインインします。

ユーザー名とパスワードを入力してログインすると、初期パスワードを変更していないので、パスワード更新画面になりました。

パスワード更新して進めると、MFAの設定要求が出ますので、MFA設定をします。

スマートフォンのAuthenticatorアプリでQRコードをスキャンしてコード入力して設定完了です。

下記のようにアクセスポータルが表示されます。

▽マークをクリックすると使用可能な権限が表示されますので、dev-departmentをクリックします

AWSアカウントにアクセスできました。Adminとは異なり、アクセスできるリソースが制限されているのでいくつかエラーが表示されています。

EC2画面を開きます。いろいろ権限不足エラーは出ていますが、EC2一覧は表示可能です

インスタンスを選択して「インスタンスの状態」->「インスタンスを開始」を選択します。

無事起動しました。

試しに「インスタンスの状態」->「インスタンスを停止」を実行すると失敗します。

部署developはインスタンス開始権限をつけておらず、停止するためには役職属性がmanagerである必要があります。

 9.managerユーザーで動作確認先ほどのシークレットモードウィンドウを閉じ、再度ブラウザのシークレットモードでウィンドウを開いてAWS access portal URLにアクセスします。

またMicrosoftのサインイン画面になりますので、awsdevmanagerユーザーでサインインします。
ユーザー名とパスワードを入力してログイン、初期パスワード変更、MFA設定をしてAWSアカウントにログインします。
EC2画面を開きます。先ほどdeveloperで起動したEC2インスタンスがありますので、「インスタンスの状態」->「インスタンスを停止」でインスタンスを停止します。

manager属性のメンバーはインスタンス停止権限があるので成功しました。

awsdevmanagerは部署develop属性も持っているので、当然EC2起動も可能です。

 10.まとめさくっとABACを試してみるつもりでしたが、意外と手こずって時間がかかってしまいました。

実際やってみると、ABACは柔軟性がありきめ細やかな設定ができる反面、実際に適用・運用していくには整備しないといけないことが多く（運用ルール整備、勝手なタグ変更の制限など..）、ハードルが高いように感じました。

基本的には環境毎にアカウントを分ける+RBACベースで運用することを考えて、どうしても必要な箇所だけABACを組み合わせることを考えるのが良いのかなと思います。
参考にしたサイト

https://docs.aws.amazon.com/singlesignon/latest/userguide/idp-microsoft-entra.html#step5-entra-abac

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/abac-checklist.html

https://aws.amazon.com/jp/blogs/modernizing-with-aws/use-custom-attributes-for-attribute-based-access-control-abac-with-microsoft-entra-id-and-aws-iam-identity-center/

観点	RBAC	ABAC
制御基準	役割（ロール）	複数の属性の組み合わせ
柔軟性	比較的低い（役割定義の範囲内）	高い（属性の組み合わせで細かい制御が可能）
設定の複雑さ	シンプル	複雑（多くの属性と条件の組み合わせ）
メンテナンス性	容易（役割の追加・変更が主）	やや困難（属性や条件の組み合わせの管理が必要）
スケーラビリティ	中程度（役割数が増えると管理が複雑化）	高い（属性ベースで柔軟に対応可能）
適用例	組織構造が明確で、権限が役割と紐づく場合	きめ細かい制御が必要で、状況に応じた柔軟な制御が求められる場合
実装の容易さ	比較的容易	やや困難（多くの属性と条件の評価が必要）
パフォーマンス	高い（単純な役割チェック）	やや低い（複数の属性評価が必要）

1.はじめに

2.RBACとABACとは

3.IAM Identity CenterでABAC設定

3-1.ABAC有効化

3-2.カスタム許可セットの作成

4.Entra属性設定

5.Entraにグループ、ユーザーを追加

5-1.グループ、ユーザー追加

5-2.エンタープライズアプリケーションへのグループ割り当て

6.テスト用AWSリソース作成

7.許可セット割り当て

8.developユーザーで動作確認

9.managerユーザーで動作確認

10.まとめ

Discussion