マルチアカウントな AWS環境のマネジメントコンソールへのアクセス方法をまとめてみた

マルチアカウントなAWS環境のマネジメントコンソールへのアクセス手段をまとめます。利用者の所属にマッチしたアクセス手段を取りましょう。IAMユーザーを散らかすことだけは控えましょう

川原征大

2021.11.09

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

2022/08/04追記: AWS Single Sign-On(SSO) は IAM Identity Center に名称が変わっています (参考)。

はじめにまとめ

マルチアカウントなAWS環境のマネジメントコンソール(以降マネコン)へのアクセス手段、それぞれの特徴を以下の表にまとめてみました。

アクセス手段	認証情報管理	Organizations連携	AWS内で完結
全て IAMユーザー	✕	✕	◯
IAMユーザーからスイッチロール	△	✕	◯
SSO(IAM SAML)	◯	✕	✕
AWS SSO	△/◯ (IDストア依存)	◯	✕/◯ (IDストア依存)

※認証情報管理 … 管理する認証情報がどれだけ増えるか

✕ … 利用者につき複数
△ … 利用者につき1つ
◯ … 無し

以下で各アクセス手段を簡単に説明します。

アクセス手段『IAMユーザー』

各AWSアカウントへ IAMユーザーを作る方法です。各アカウント上に認証情報※ を保持する必要があります。

※認証情報はパスワード(マネコンへのログイン) やアクセスキー(CLI/API利用) です

各アカウントへIAMユーザーを展開するため

『誰がどのAWSアカウントへアクセスできるか』の把握が困難
『認証情報の複数管理』が大変 (これはセキュリティリスク増大にも繋がります)

といったデメリットがあるため、一般にはおすすめしません。

▼ セキュリティや運用のTips

最小権限に絞ることを意識しましょう
IAMユーザーグループを使った権限管理を行いましょう
認証の強化(多要素認証:MFA)を行いましょう
(そもそも、できればこの手法は取りたくないですね)

アクセス手段『IAMユーザーからスイッチロール』

IAMユーザー管理用アカウント※ で IAMユーザーを作成します。 (※よく Jumpアカウントと呼ばれます) 各作業対象のアカウントには、利用者の職務に対応した IAMロールを作成しておきます。

利用者は IAMユーザーへログイン後、各作業対象のアカウントへスイッチロール(AssumeRole)してアクセスします。

アクセス手段『IAMユーザー』 と比べて管理する認証情報が減ることがメリットです。ユーザー管理用アカウント上の IAMユーザーの認証情報のみの管理となります。

▼ セキュリティや運用のTips

最小権限に絞ることを意識しましょう
- IAMユーザー
  - 『どのアカウント』の『どのロール』へスイッチロールできるか
- IAMロール
  - 『どのアカウント』の『どのユーザーから』のスイッチロールを許可するか
  - ロールにアタッチされたポリシーの精査
IAMユーザーの認証の強化(多要素認証:MFA)を行いましょう
ロールの信頼関係で『エンティティの MFA を必須』としましょう

アクセス手段『SSO(IAM SAML)』

既存IDプロバイダー(Active DirectoryやIDaaS)の認証情報を使って各アカウントへアクセスする手法(Single Sign-On:SSO)です。

前置き (SAMLについて)

SSOの実現に Security Assertion Markup Language (SAML) を使用しています。 SAMLはざっくりいうと IDプロバイダーによるユーザー認証を使って、ほかサービス(サービスプロバイダー。今回でいうAWS)で使える認証トークンを渡すための規格です。

※SAMLについて詳しくは以下参照ください。

SAML | Okta

簡単に利用者のマネコンアクセスの流れを説明します。まず、事前に『IDプロバイダー』と『AWS(サービスプロバイダー)』との間で信頼関係を結んでおく必要があります。

利用者は通常通りログインして、IDプロバイダーから認証されます。その後 AWS(サービスプロバイダー) からアカウントへアクセスするための IAMロールの一時セキュリティ認証情報を受け取り、マネコンへアクセスできるようになります。

※詳細は以下シングルサインオンの BlackBelt が参考になります。ぜひ参照ください。

– 画像引用: 【AWS Black Belt Online Seminar】 AWSアカウントシングルサインオンの設計と運用資料及び QA 公開 | Amazon Web Services ブログ

認証情報は既存(IDプロバイダー)のものを使うので、 AWS環境内にて認証情報を管理する必要がない点がメリットです。 (アカウントへのアクセス設定が AWS内で完結しない点は、デメリットとなりうるかもしれません)

SSO(IAM SAML) 構成のパターン

マルチアカウントで SSO(IAM SAML) 構成を作るパターンは思いつく限りで 2つあります。

▼各AWSアカウントごとに『IDプロバイダーとの信頼関係』を作る

そのまま横に拡張させたパターンです。 IDプロバイダーとの信頼関係は AWSアカウントごとに結ぶ必要があります。 IDプロバイダー側で 誰がどのAWSアカウントのどのロールにアクセスできるか を集中管理できる構成です。

▼代表1アカウントのみ『IDプロバイダーとの信頼関係』を作る

IDプロバイダーと信頼関係を結ぶ代表 1アカウント( SAML連携用アカウント )を作るパターンです。 SAML連携用アカウントから アクセス手段『IAMユーザーからスイッチロール』 と同じように各アカウントへスイッチロールします。

今後増えるアカウントに対して IDプロバイダーとの信頼関係と結ぶ手間は省けます。 IDプロバイダー視点ではアクセスする(見える)アカウントは SAML連携用アカウントのみです。集中管理の面ではデメリットになるかもしれません。

上に紹介した 2パターンはどちらも一長一短あるので、要件に合わせて選択しましょう。

アクセス手段『AWS SSO』

AWS Single Sign-On(SSO)は AWSのサービスです。

Organizations 環境であれば AWS SSO を追加料金無しで利用できます。

利用者は AWS SSO 専用のポータル画面へログインしてから、各アカウントへアクセスします。

アクセスの仕組み自体は アクセス手段『SSO(IAM SAML)』 と同じですが、より AWSマネージドになっています。例えば AWSアカウントへのIAMロールの作成が自動化されています。

AWS SSOの IDストアは以下から選択します(1つのみ)。

AWS SSO管理の IDストア
外部IDプロバイダー利用
Active Directory利用

※ AWS SSOではオプションでSCIMという機能を使えます。これは「外部プロバイダーのユーザー情報を AWS SSO 側に自動プロビジョニングする」機能です。SCIM がサポートされている外部IDプロバイダーはいくつかに絞られている点に注意してください。

参考: サポートされているID プロバイダー - AWS Single Sign-On

おわりに

以上、AWSにおけるマネジメントコンソールアクセス方法をまとめてみました。表を再掲します。

アクセス手段	認証情報管理	Organizations連携	AWS内で完結
全て IAMユーザー	✕	✕	◯
IAMユーザーからスイッチロール	△	✕	◯
SSO(IAM SAML)	◯	✕	✕
AWS SSO	△/◯ (IDストア依存)	◯	✕/◯ (IDストア依存)

それぞれの利用者の所属にマッチしたアクセス手段を取ると良いと考えています。 IAMユーザーを各アカウントへ散らかすことだけは、あまり良くないと思います。

マルチアカウントな AWS環境のマネジメントコンソールへのアクセス方法をまとめてみた

はじめにまとめ

アクセス手段『IAMユーザー』

アクセス手段『IAMユーザーからスイッチロール』