3
3

More than 1 year has passed since last update.

AWS Identity Centerの備忘録

Last updated at Posted at 2023-03-28

AWS Identity Center(旧Single Sign On、SSO)の基本概念

公式サイト:
AWS Identity Center (successor to AWS Single Sign-On)

IAMに代わり、Identity Centerを利用することでAWS管理コンソールへのSSOを実現可能となるが、そのサービス仕様(仕組み)について備忘録的に記録しておく。
(アプリケーションへの割り当ては除外)

  1. Identity Centerのコンポーネント
    • アイデンティティソース
    • ユーザー/グループ
    • 許可セット
  2. SSOログインが可能になるまでの流れ
  3. 仕様と注意(一部推測)
  4. 権限の課題

Identity Centerのコンポーネント

  • アイデンティティソース
    3つのIDソースから選択することができる。Identity Centerディレクトリ以外を選択した場合でも実質的にはIdentity Center上にユーザー/グループが作成されることになる。(詳細はユーザー/グループの項を参照)
No IDソース サインインページ
1 Identity Centerディレクトリ AWS アクセスポータル
2 Active Directory AWS アクセスポータル
3 外部IDプロバイダー 利用者側で用意が必要

注意事項として、AWS アクセスポータルはhttps://xxxxx.awsapps.com/start というURLで固定(xxxxxの部分は任意に設定可能)となり、ページレイアウトや内容のカスタマイズは一切できない。

  • ユーザー/グループ
    アイデンティティソースにActive Directoryや外部IDプロバイダーを選択した場合、「特定のユーザー/グループを同期する」設定を行い、同期されたユーザー/グループがIdentity Center上に作成されることになる。
    なお、同期の際は全ユーザー/グループではなく、Identity Center上で「同期したいユーザー/グループ」として指定したものだけが同期される。

  • 許可セット
    特定のAWSアカウントに特定のユーザー/グループでSSOログインした際に付与したい権限を定義する。複数のアカウントへ同じ権限を付与したい場合、作成した許可セットを再利用すればよい(但し注意点あり)

許可セットには以下の3つのパターンのIAMポリシー、および1つの許可の境界(Permission Boundary)を付与することができる。

No ポリシー種別 許可セットへの割り当て
1 AWSマネージドポリシー アタッチ/デタッチ(一覧から選択)
2 カスタマーマネージドポリシー アタッチ/デタッチ(ポリシー名入力)
3 インラインポリシー ポリシーを直接記述
4 許可の境界 アタッチ/デタッチ(ポリシー名入力)

上記ポリシーの権限の集合がSSOでログインしたユーザーに与えられることになる。

SSOログインが可能になるまでの流れ

以下の流れで作業をすることで、SSOログインを実現できる。

  1. アイデンティティソース上にユーザー/グループを用意する
    アイデンティティソースがIdentity Centerディレクトリ以外の場合はユーザー/グループの同期設定を行う。

    1. Identity Centerの管理コンソールの左メニューの設定をクリック
    2. アイデンティティソースのページタブ上でアクションタブから同期を管理をクリック
    3. ユーザーまたはグループのページタブ上のユーザーとグループを追加ボタンをクリック
    4. アイデンティティソース上の同期したいユーザー/グループの名前を入力して追加ボタンを押した後、送信ボタンを押して同期を開始
      ユーザーやグループが存在しない場合はエラーとなり、存在した場合は同期が開始してIdentity Center上にユーザー/グループ名が認識される
  2. 許可セットを作成する

    1. Identity Centerの管理コンソールの左メニューの許可セットをクリック
    2. カスタム許可セットを選択
    3. 「ポリシーと許可の境界を指定」で適切なポリシーおよび境界の設定をアタッチ、もしくはインラインポリシーを作成して次へボタンをクリック
    4. 「許可セットの詳細を指定」で許可セットの名前を指定(その他の項目はそのままで問題なし)して次へボタンをクリック
    5. 最終的に入力内容を確認後、作成ボタンを押して作成
  3. AWSアカウントにユーザー/グループを割り当てる
    実際にはユーザー/グループと一緒に許可セットを割り当てる

    1. Identity Centerの管理コンソールの左メニューのAWSアカウントをクリック
    2. SSOログインさせたいAWSアカウントをOrganizationsのツリーから選択(複数可)し、ユーザーまたはグループを割り当てボタンをクリック
    3. 「ユーザーとグループを「xxxxx(AWS Organizations上のAWSアカウントのエイリアス名)」に割り当て」でユーザーまたはグループを選択し、次へボタンをクリック
    4. 「許可セットを「xxxxx」に割り当て」で許可セットを選択(複数可)して次へボタンをクリック
    5. 最終的に入力内容を確認後、送信ボタンを押して完了

仕様と注意(一部推測)

  • 特定のAWSアカウントにユーザー/グループと許可セットを割り当てる
    実際にはSSOログインさせたいAWSアカウント上にSSOログイン用(と思われる)AWSReservedSSO_zzzzzz_xxxxxxというIAMロールが自動的に作成され、(zzzzzzは許可セット名、xxxxxxはランダムな十六進数の数値となる)
    Identity Centerでログインした直後はこのIAMロールになって操作することになる

  • AWSReservedSSO_zzzzzz_xxxxxxの作成権限
    このIAMロール作成はIdentity CenterのサービスリンクロールAWSServiceRoleForSSOにて行われているため、Identity Centerで許可セットを作成したりAWSアカウントへユーザー/グループと許可セットを割り当てする作業者にはIAMロール作成系の権限は不要となる

  • 当該AWSアカウントへSSOログインの設定を行うのが初めてのとき
    上記にあるように、当該AWSアカウント上にサービスリンクロールを作成する必要があるため、初めての際はAWSSSOMasterAccountAdministratorの権限が必要となる
    2回目以降はAWSSSOMemberAccountAdministratorの権限で問題ない

  • 同期の際の権限不足
    アイデンティティソースをIdentity Centerディレクトリ以外にした場合は同期が必要であるが、その場合そのままでは作業者に対してidentity-syncの権限不足のエラーが出る
    この権限はAWSSSOMasterAccountAdministratorにもAWSSSOMemberAccountAdministratorにも付与されていないため、別途IAMポリシーを作成してアタッチする必要がある

同期に必要な権限
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "identity-sync:*",
            "Resource": "*"
        }
    ]
}
  • 許可セットを複数のAWSアカウントに割り当てする場合
    カスタマーマネージドポリシーや境界の設定については、ポリシーの一覧から選択するのではなく名称を入力させることから察せられるとおり、許可セットを割り当てようとするAWSアカウント上に、指定された名称のポリシーが存在することが前提となっている
    許可セットをAWSアカウントに割り当てする前に事前に作成しておく必要があること、およびポリシーの内容が同一かどうかはチェックされないため、作業者が予め認識しておく必要がある

  • Identity CenterでのMFA認証とスイッチロールでのMFA認証のチェック
    Identity CenterでのMFA認証とIAMでのMFA認証は別扱いされている(MFAデバイスが別扱いなのが根拠)ため、例えば以下のようにスイッチロール先のIAMロールにて信頼関係のポリシーに対しMFA認証されていることを必須にした場合、Identity CenterでMFA認証を有効化し、MFA認証したとしてもIAMではMFA認証していないことになるため、このスイッチロールは失敗する

IAMロールの信頼関係
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::xxxxxxxxxxxx:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}

権限の課題

上記の仕様と注意から推測されるように、Identity Centerの許可セットには以下の課題が出てくる
どちらも、許可セットへのマネージドポリシーのアタッチはssoの権限であり、iamの権限ではないため、許可の境界やIAMの条件キーは効かないためである

  • AWSマネージドポリシーやカスタマーマネージドポリシーに対し、AdministratorAccessのような強い管理権限を持ったポリシーのアタッチを作業者が行ってしまうことに対し(故意/事故問わず)防止できない

  • インラインポリシーに以下のような権限を記述されても防止できない
    インラインポリシーの内容チェックは文法チェックのみであり、許可の境界での禁止は行われないため、IAMの権限が一切なくともIdentity Centerの許可セットの作成権限があれば、作業者は権限の拡大を行うことが出来てしまう

インラインポリシー
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

履歴

  • 2023/3/29 初稿
3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
3