お久しぶりです。
クラウドインテグレーション部 柿﨑です。
IAMには属性ベースのアクセスコントロール(以下、ABAC)というものがございます。
ドキュメントを読んだだけではちゃんと理解できているか怪しいため、今回は触りながらABACの挙動を確認してみようと思います。
たまたまAWS SSOを触る機会があったため、せっかくなのでAWS SSO + ABACの組み合わせを試してみましょう。
情報量はなるべく絞ってシンプルにいきます。
構成情報
今回の構成はざっくりこのようなかたちです。
マスターアカウントのAD Connectorと認証アカウントのAD on EC2はすでに設定済みで、AWS SSOを有効化したところからスタートとします。
手順
AWS SSOの設定
AWS SSOを有効化した直後はIDソースがAWS SSOになっており、アクセスコントロールの属性が無効となっています。
IDソースをAD Connectorに変更することで、属性マッピングの項目が出現します。
中身を確認してみます。
ここではADから受け取る属性をAWS SSOのユーザー属性にマッピングしています。
公式ドキュメントを参照すると2021/04月時点で利用可能なAWS SSOのユーザー属性はキャプチャと一致していることが確認できます。
今回はユーザーを一意に特定可能なemailを利用することとします。
次にアクセスコントロールの属性を有効化します。
アクセスコントロールの属性を有効化したあとに詳細を開きます。
値を選択すると設定可能なAWS SSOのユーザー属性が表示されます。
今回はキーにemail、値にAWS SSOのユーザー属性であるemailを設定します。
先ほど設定したアクセスコントロールの属性を利用したアクセスポリシーを作っていきます。
独自のポリシーを作成するため、カスタムアクセス権限セットを選択します。
以下でも同様にカスタムアクセス権限ポリシーを選択し、ポリシー(詳細は後述)を入力します。
上記で設定するポリシーは、スイッチロールしたユーザーすべてにEC2のDescribe権限を付与し、EC2のemailタグの値とアクセスコントロールの属性が一致したときのみ、EC2の起動と停止権限が付与されます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/email": "${aws:PrincipalTag/email}"
}
}
}
]
}
参考情報: 新機能 — AWS Single Sign-On による属性ベースのアクセスコントロール
タグと確認はそのまま進み、作成を押下します。
ここまででアクセス権限の作成が完了したため、今度はAWSアカウント、ユーザー、アクセス権限を紐付けていきます。
今回は2つのユーザーを利用します。
ユーザー名: kakizaki1、メールアドレス: kakizaki1@kakizaki.local
ユーザー名: kakizaki2、メールアドレス: kakizaki2@kakizaki.local
付与する権限は先ほど作成したアクセス権限セットとなります。
以上でAWS SSO側の設定は完了となります。
メンバーアカウントの準備～ABACの挙動確認
ここからはメンバーアカウントの準備～ABACの挙動確認まで実施します。
まずはメンバーアカウント上にて、emailタグにkakizaki2@kakizaki.localと設定したEC2を作成します。
このEC2は起動、停止、削除の操作しかしないため、タグ以外の設定はデフォルトで構いません。
EC2の作成が完了したところで、AWS SSOにサインインします。
まずはユーザー: kakizaki1です。
サインイン後、AWSアカウントを選択してスイッチロールします。
そこで先ほど作成したEC2を選択し、停止の操作を行います。
※このEC2にemailタグが付与され、値にkakizaki2@kakizaki.localと入力されていることを事前に確認します。
するとEC2の停止権限がないよとエラーが発生しました。
これはEC2のemailタグの値がkakizaki2@kakizaki.localに対し、アクセスコントロールの属性がkakizaki1@kakizaki.localのため、ポリシーの条件分岐によってEC2の操作権限がDenyされているからですね(厳密には暗黙のDeny)。
ということで、本命のユーザー: kakizaki2で同様の操作を行います。
今度はEC2を停止させることができました。
こちらではEC2のemailタグの値がkakizaki2@kakizaki.localに対し、アクセスコントロールの属性もkakizaki2@kakizaki.localのため、EC2の操作権限が付与されています。
そのため、EC2の停止のみならず起動操作も実行可能です。
以上でABACの挙動確認は終わりです。
まとめ
今回のABACの使い方であれば,、EC2ごとにemaiタグの値を変更するだけで、個々人にEC2の操作権限を割り当てることが可能と分かりました。
ポリシーの条件分岐に利用する属性を個人単位、事業部単位、会社単位などと使い分けすることで、単一のポリシーのみで柔軟な制御ができそうです。
ただし、2021/04月時点でAWS SSOにてサポートされているユーザー属性に限りがあるため、より多くの属性を利用して制御したい場合はIDソースに外部IDプロバイダーを検討すると良いでしょう。
