非Organizations環境のAWSアカウントにAzure ADのユーザーからSSOしてスイッチロールしてみた

hayashi.masaya

2021.03.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは。大阪オフィスの林です。

前回のエントリで、非Organizations環境のAWSアカウントにAzure ADのユーザーからSSOするところまでを試しました。

前回検証した内容を図で表すと下記の通りで、Azure ADのユーザーからAWSアカウントに対してSSOするところまでで終わっています。

作業する対象が、1つのAWSアカウントのみであれば前回のエントリの内容のみで事足りることもあるかと思いますが、複数のAWSアカウントがあって、その複数のAWSアカウントそれぞれにログインしてAWSの環境を触るケースもあるかと思います。前回のエントリのセットアップをすべてのAWSアカウントで実装すれば対応は出来るものの手間もかかってしまい、全環境で同じ内容のセットアップを行うのは非効率であまり現実的ではありません。

今回やること

そこで、今回の検証ではAzureと連携するAWSアカウントを「Jumpアカウント」として別のAWSアカウントにスイッチロールする踏み台として扱います。他のAWSアカウントに作成するスイッチ先のロールには、フェデレーションしてきたAzure ADのユーザーを識別するポリシーを記述することで、悪意を持った利用者からの想定外のスイッチロールを防止します。※設定方法は後述します。

やってみた

Jumpアカウント側の作業

まずはJumpアカウント側の設定です。前回のエントリでも記載しましたが、AWSにフェデレーションしてきたユーザーはIDプロバイダに割り当てられているロールによって認可されます。通常はJumpアカウントでの操作は不要なケースが多いのでベースとなる権限としては「ReadOnly権限」など弱い権限を割り当てておきます。今回は「ReadOnly権限」に加えてJumpアカウントとして別のAWSアカウントにスイッチするために「AssumeRole」を許可するポリシーも付加しておきます。

それでは、JumpアカウントでAssumeRoleの許可ポリシー割り当てをやっていきたいと思います。

AssumeRoleの許可ポリシー割り当て

IAMのダッシュボード左メニューから「ポリシー」-「ポリシーの作成」を選択します。

「JSON」タブから下記のJOSNをコピペして次のステップに進みます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

必要に応じてタグを設定し次のステップに進みます。

任意のポリシー名を入力後、「ポリシーの作成」を選択します。

AssumeRole用のIAMポリシーが作成されました。

次に、IDプロバイダに紐付いているIAMロールに、今作ったAssumeRole用のIAMポリシーを割り当てます。左メニューから「ロール」を選択し、IDプロバイダに紐付けているIAMロールを検索し選択します。

「ポリシーをアタッチします」を選択します。

今作ったAssumeRole用のIAMポリシーを検索し、選択し「ポリシーのアタッチ」を選択します。

AssumeRole用のIAMポリシーがIDプロバイダに紐付いているIAMロールにアタッチされました。

スイッチ先のAWSアカウント側の作業

スイッチ先のAWSアカウントでは、スイッチ先となるIAMロールを作成するのですが、不特定多数のユーザーからスイッチされては困るので、作成するIAMロールに割り当てるポリシーでフェデレーションしてきたユーザーを識別して、意図したユーザーからのスイッチしか出来ないようなコントロールを行います。

IAMのダッシュボード左メニューから「ロール」-「ロールの作成」を選択します。

最終的には変更するのですが、ここでは一旦JumpアカウントのAWSIDを入力し、次のステップに進みます。

割り当てる権限は用途に合わせて適宜選択してください。今回は検証なのでAdministratorAccessを選択して進めます。

必要に応じてタグを設定し次のステップに進みます。

任意のロール名を入力後、「ロールの作成」を選択します。

IAMロールが作成されました。

作成されたIAMロールのリンクを選択します。

「信頼関係」タブから「信頼関係の編集」を選択します。ここの設定で、フェデレーションしてきたユーザーを識別して意図したスイッチしか出来ないようなコントロールを行います。

下記のJOSNをコピペして「信頼ポリシーの更新」を選択します。今回の設定では、JumpアカウントのIDプロバイダに紐付いているAzureAD-IdP-RoleというIAMロールによって認可されたユーザー且つsso-test-user-1@hogehoge.onmicrosoft.comというAzure ADのユーザーIDからのみロールへのスイッチを許可する設定としています。Azure ADのユーザーID先頭の*はスイッチロール時に付与される変動するIDのため設定時に特定できません。そのため*としています。Azure ADのユーザーIDの先頭に:があるので*としておいても、意図しない他のユーザーIDに許可を与えてしまうことも無いでしょう。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012(JumpアカウントのAWSID 12桁):role/JumpアカウントのIDプロバイダに割り当てたIAMロール(AzureAD-IdP-Role)"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "aws:userid": "*:sso-test-user-1@hogehoge.onmicrosoft.com"
        }
      }
    }
  ]
}

信頼関係の設定が更新できました。

動作確認

それでは動作を見ていきたいと思います。動作確認ではsso-test-user-1@hogehoge.onmicrosoft.comとsso-test-user-2@hogehoge.onmicrosoft.comの2つのAzure ADのユーザーからスイッチロールを試して動作を見ていきたいと思います。まずはsso-test-user-1@hogehoge.onmicrosoft.comからです。

SSO後のAWSマネージメントコンソールの画面から「ロールの切り替え」を選択します。

「アカウント」にスイッチ先のAWSアカウント（12桁）を入力し、「ロール」にスイッチするロールの名前を入力後、「ロールの切り替え」を選択します。

スイッチロールが許可されたユーザー（意図したユーザー）であるため、スイッチロールが成功します。

次にスイッチロールが許可されていないユーザー（意図されていないユーザー）で試してみます。sso-test-user-2@hogehoge.onmicrosoft.comでSSOしました。

同様の情報でロールの切り替えをしてみますが、許可されていないためスイッチロールが成功しません。

まとめ

AWSだけで完結している環境の場合、JumpアカウントにIAMユーザーを作成しておいて、そのIAMユーザーから別のAWSアカウントにスイッチして操作するというケースはよく聞きますが、Azure ADとSSO連携した場合のスイッチロールについては試したことが無かったので、今回の検証で非常に勉強になりました！Azure ADユーザーを使ったAWSマネージメントコンソールへのSSOをご検討されている方の参考になれば幸いです！

以上、大阪オフィスの林がお送りしました！