【AWS SSO】【Switch Role】複数のAWSアカウントでログインを簡単に!

AWS

こんにちはますのです。
AWSアカウントを部署毎に作ったり、本番/ステージング/テストなどで環境ごとに変える管理をするなどあるのではないでしょうか。

複数環境を作ることで発生する悩ましい問題が「共通する人間のアカウント管理」かと思います。
AWSアカウントが増えれば増えるほど、異動発生時に管理するIAMが増えていって時間がもってかれますよね。

ということで、複数のAWSアカウントでログインユーザを管理するにはどうするのが良いのか?をサポートに聞いてみましたので備忘録です。

ベストプラクティスでは「スイッチロール」での管理となる

AWSのベストプラクティスに沿った管理手法としては「スイッチロール」でのアカウント切替を推奨しているようです。

ロールを使用したアクセス許可の委任
アカウント間でセキュリティ認証情報を共有しないでください。
これは、別の AWS アカウントのユーザーがお客様の AWS アカウントのリソースにアクセスできないようにするためです。
その代わりに、IAM ロールを使用します。他のアカウントの IAM ユーザーに許可されている権限を指定するロールを定義できます。また、そのロールを引き受けることが許可されている IAM ユーザーを持つ AWS アカウントを指定することもできます。
信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を参照してください。引用:IAM でのセキュリティのベストプラクティス – AWS Identity and Access Management

筆者の結論:請求方法とアカウント管理方法の要件で変わる

実装時の要件にどちらがいかにマッチするか??という点で変わってくる印象です。
あくまでも筆者の考えとして、おおよそ以下2点が大きな分岐になるかな?と感じました。

  • AWSアカウント毎に請求を分割したい場合:Switch Roleを利用
  • 異動が頻繁に発生しADで管理している場合:AWS SSOを利用
調べた情報が古く、以前は「Switch Role」しかなかったからだと思い問い合わせに至りました。
しかし「AWS SSO」が出てきた以降もベストプラクティスは「Switch Role」に据え置きとなっているようです。筆者は後述する「AWS SSOの仕様」でネックになる部分もあり、今回はIAMロールでの管理:Switch Roleによるログインを実装しました。

AWS SSOを利用する場合の要件

AWS SSOを利用するにはいくつか縛りが発生します。

  • AWS Organizationを利用する
  • 料金請求はアカウント毎ではなく、すべてのアカウント分を一括請求する
  • バージニアリージョンでのみ利用可能

わたしは「アカウント毎の請求」が出来ない点がネックとなり、AWS SSOは検討の土台に乗らなかったです。

AWS SSOを利用するメリット

AWSドキュメントから画像を拝借。主に以下の3つのようですね。

  • 社内のオンプレActiveDirectoryを利用してAWSコンソールにアクセスが可能。
  • Office365、Gsuite、GitHub、Salesforce、Slack等の業務アプリケーションのSSOとして利用可能。
  • SAML実装アプリケーションへSSOを提供可能。

ADとの連携やSAML認証が出来るのは嬉しいですね。
AzureADなどのクラウド認証基盤を持っていない場合はわりと重宝しそうな機能のように見えます。
今後のゼロトラストの考え方にIdPを持つことは必要なことですからね。しかも無料機能なのです。機会があればぜひこれも実装したいものだと感じます。

Switch Roleを利用する場合の要件

スイッチロールに関してはADとの連携ではなく、IAMの管理となります。
そのためスイッチ元となるAWSアカウントのIAMユーザ管理は必要になります。

  • スイッチ先のIAMロールの作成。
  • スイッチ元のIAMポリシーの作成。
  • IAMグループでの細かな管理は不可、個別設定する場合はIAMユーザ毎のJSONを記載する必要がある。
  • スイッチ先のアクセス権限は「IAMロール」に記載されている内容になる。スイッチ元の権限は継承されない。

スイッチロールのイメージ図


引用:Swith Roleで複数のAWSアカウント間を切替える

Switch Roleを利用する際のメリット

  • スイッチ元の全IAMユーザ、もしくはIAMグループ単位に展開する場合、設定以降は管理が不要

もうこれにつきます。はい。
以下のJSONを、スイッチ元(上図での「開発アカウント」)のIAMポリシーに仕込めば手入れ不要になります。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::<スイッチ先のAWSアカウントID>:role/<スイッチ先に作成したIAMロール名>"
    }
}

なお、細かい設定手順はクラスメソッドさんの記事をご覧あれです。

IAMグループ単位にスイッチロールの権限を付与する

あとは作成した「sts:AssumeRole」の許可されたIAMポリシーを、特定のIAMグループにアタッチすればIAMグループ単位での許可が可能となります。

手順:【Switch Role】特定のIAMグループのみに権限を付与する

IAMユーザ単位にスイッチロールの権限を付与する

特定のIAMユーザに限定してSwitchRoleを設定する方法

「全IAMユーザに対してスイッチロール権限を付与したい」という要件であれば、スイッチロールが一番簡単ではないかと思います。

特定のIAMユーザだけに付与したい!という場合はJSONの記述を変更する必要があります。
異動等でユーザ更新が頻繁にある場合はAD連携されている「AWS SSO」の方が運用負荷は少なく済むのではないかと所感でした。

最新情報をチェックしよう!