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

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

#SSO

#AWS Single Sign-On

#AWS IAM

#AWS

川原征大

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ストア依存)