AWS SSO、AD、ABACを触ってみる

記事タイトルとURLをコピーする

お久しぶりです。
クラウドインテグレーション部 柿﨑です。

IAMには属性ベースのアクセスコントロール(以下、ABAC)というものがございます。
ドキュメントを読んだだけではちゃんと理解できているか怪しいため、今回は触りながらABACの挙動を確認してみようと思います。
たまたまAWS SSOを触る機会があったため、せっかくなのでAWS SSO + ABACの組み合わせを試してみましょう。
情報量はなるべく絞ってシンプルにいきます。

構成情報

今回の構成はざっくりこのようなかたちです。
マスターアカウントのAD Connectorと認証アカウントのAD on EC2はすでに設定済みで、AWS SSOを有効化したところからスタートとします。

f:id:swx-kakizaki:20210415232350p:plain

手順

AWS SSOの設定

AWS SSOを有効化した直後はIDソースがAWS SSOになっており、アクセスコントロールの属性が無効となっています。

f:id:swx-kakizaki:20210415232630j:plain

IDソースをAD Connectorに変更することで、属性マッピングの項目が出現します。
中身を確認してみます。

f:id:swx-kakizaki:20210415232844j:plain

ここではADから受け取る属性をAWS SSOのユーザー属性にマッピングしています。
公式ドキュメントを参照すると2021/04月時点で利用可能なAWS SSOのユーザー属性はキャプチャと一致していることが確認できます。
今回はユーザーを一意に特定可能なemailを利用することとします。

f:id:swx-kakizaki:20210415233002j:plain

次にアクセスコントロールの属性を有効化します。

f:id:swx-kakizaki:20210415233547j:plain

アクセスコントロールの属性を有効化したあとに詳細を開きます。
値を選択すると設定可能なAWS SSOのユーザー属性が表示されます。

f:id:swx-kakizaki:20210415233628j:plain f:id:swx-kakizaki:20210415233639j:plain

今回はキーにemail、値にAWS SSOのユーザー属性であるemailを設定します。

f:id:swx-kakizaki:20210415233811j:plain

先ほど設定したアクセスコントロールの属性を利用したアクセスポリシーを作っていきます。

f:id:swx-kakizaki:20210415234053j:plain

独自のポリシーを作成するため、カスタムアクセス権限セットを選択します。

f:id:swx-kakizaki:20210415234233j:plain

以下でも同様にカスタムアクセス権限ポリシーを選択し、ポリシー(詳細は後述)を入力します。

f:id:swx-kakizaki:20210415234321j:plain

上記で設定するポリシーは、スイッチロールしたユーザーすべてに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 による属性ベースのアクセスコントロール

タグと確認はそのまま進み、作成を押下します。

f:id:swx-kakizaki:20210415235549j:plain f:id:swx-kakizaki:20210415235559j:plain

ここまででアクセス権限の作成が完了したため、今度はAWSアカウント、ユーザー、アクセス権限を紐付けていきます。

f:id:swx-kakizaki:20210415235651j:plain

今回は2つのユーザーを利用します。
ユーザー名: kakizaki1、メールアドレス: kakizaki1@kakizaki.local
ユーザー名: kakizaki2、メールアドレス: kakizaki2@kakizaki.local

f:id:swx-kakizaki:20210415235927j:plain

付与する権限は先ほど作成したアクセス権限セットとなります。

f:id:swx-kakizaki:20210416000032j:plain

以上でAWS SSO側の設定は完了となります。

メンバーアカウントの準備~ABACの挙動確認

ここからはメンバーアカウントの準備~ABACの挙動確認まで実施します。

まずはメンバーアカウント上にて、emailタグにkakizaki2@kakizaki.localと設定したEC2を作成します。
このEC2は起動、停止、削除の操作しかしないため、タグ以外の設定はデフォルトで構いません。

f:id:swx-kakizaki:20210416000418j:plain

EC2の作成が完了したところで、AWS SSOにサインインします。
まずはユーザー: kakizaki1です。

f:id:swx-kakizaki:20210416000759j:plain

サインイン後、AWSアカウントを選択してスイッチロールします。
そこで先ほど作成したEC2を選択し、停止の操作を行います。
※このEC2にemailタグが付与され、値にkakizaki2@kakizaki.localと入力されていることを事前に確認します。

f:id:swx-kakizaki:20210416001003j:plain

するとEC2の停止権限がないよとエラーが発生しました。
これはEC2のemailタグの値がkakizaki2@kakizaki.localに対し、アクセスコントロールの属性がkakizaki1@kakizaki.localのため、ポリシーの条件分岐によってEC2の操作権限がDenyされているからですね(厳密には暗黙のDeny)。

f:id:swx-kakizaki:20210416001012j:plain

ということで、本命のユーザー: kakizaki2で同様の操作を行います。

f:id:swx-kakizaki:20210416001502j:plain f:id:swx-kakizaki:20210416001516j:plain

今度はEC2を停止させることができました。
こちらではEC2のemailタグの値がkakizaki2@kakizaki.localに対し、アクセスコントロールの属性もkakizaki2@kakizaki.localのため、EC2の操作権限が付与されています。

f:id:swx-kakizaki:20210416001618j:plain

そのため、EC2の停止のみならず起動操作も実行可能です。

f:id:swx-kakizaki:20210416001647j:plain f:id:swx-kakizaki:20210416001655j:plain

以上でABACの挙動確認は終わりです。

まとめ

今回のABACの使い方であれば,、EC2ごとにemaiタグの値を変更するだけで、個々人にEC2の操作権限を割り当てることが可能と分かりました。
ポリシーの条件分岐に利用する属性を個人単位、事業部単位、会社単位などと使い分けすることで、単一のポリシーのみで柔軟な制御ができそうです。
ただし、2021/04月時点でAWS SSOにてサポートされているユーザー属性に限りがあるため、より多くの属性を利用して制御したい場合はIDソースに外部IDプロバイダーを検討すると良いでしょう。

柿﨑 拓人 (記事一覧)

クラウドインテグレーション部

AWS移行案件の要件定義~構築をメインに担当。
最近ボルダリングをはじめました。