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

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

はじめにまとめ

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

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

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

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

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

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

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

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

img

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

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

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

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

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

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

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

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

img

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

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

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

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

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

img

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

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

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

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

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

img

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

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

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

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

img

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

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

img

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

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

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

アクセス手段『AWS SSO』

Organizations 環境であれば AWS Single Sign-On(SSO) を 追加料金無しで 利用できます。

img

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

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

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

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

※ サポートされている 外部IDプロバイダーはいくつかに絞られている点に注意してください。

おわりに

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

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

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

参考