AWS Organizationsあり、外部認証基盤なしでSingle Sign-On(SSO)を使うべきか

それともSSO使わずJumpアカウントを作るほうが良い?
2020.10.29

現在参画中のプロジェクトでAWS Single Sign-On(以下SSO)を利用するべきかどうか検討しました。

要件

  • Organizationsを使って、複数アカウントを管理する
  • AD等の外部認証基盤は無い
  • コードで構成管理したい (Infrastructure as Code)
  • MasterAccountはできる限りいじりたくない
  • できるだけ簡単に設定・管理したい
  • できるだけ簡単に各アカウントにアクセスしたい
  • ユーザーあるいはグループごとに細かな権限設定をしたい
  • MFA(多要素認証)必須 (にするかも)
  • AWSアカウントへのアクセスのみが目的。SAML 対応のクラウドアプリケーション (Salesforce、Office 365、Box など)や他アプリケーションで認証基盤を共用することは考えていない ※ SSOで実現できる機能です

選択肢

  • SSOを使う(以後SSO案と呼ぶ)
  • SSO使わない。いわゆるJumpアカウントを用意する(以後Jumpアカウント案と呼ぶ)

SSO案概要

外部認証基盤が無いので、SSOのIDストアも利用します。SSOを有効化して、以降ざっくりとは以下を実施します。

  • ユーザー、グループを作成する
  • PermissionSet(日本語訳では「アクセス権限セット」「アクセス許可セット」などと訳されています)を作成する
  • PermissionSetにIAM Policyをアタッチする
  • PermissionSetとアカウントを紐付ける
  • ユーザーやグループにPermissionSetを割り当てる

SSO有効化時にユーザーポータルが作成されURLが発行されます。ユーザーはそのユーザーポータルにログインし、そこから自身に紐付けられたアカウント x 権限を選んでスイッチロールします。

Jumpアカウント案概要

JumpアカウントにのみIAMユーザーを作成し、他アカウントにはIAMロールを作成します。他アカウントで作業する際には、Jumpアカウントに作成したIAMユーザーからIAMロールにスイッチロールします。

参考情報

比較

Jumpアカウント案は先の要件をすべて満たします。SSO案で満たせない要件は無いか、またJumpアカウント案と比較してのメリット・デメリットは何か調査しました。

コードで構成管理できる?

SSO案は一部可能です。

CloudFormation

2020/09/10にSSOのCloudFormationサポートが追加されました。

ですが、CloudFormationでできることは限定的です。以下2点の定義のみです。

  • PermissionSet (IAMポリシーと適用AWSアカウントの組み合わせ)
  • Assignment (上記PermissionSetをユーザーやグループに割り当てる)

他の設定、例えば最初にSSOを有効化する部分とか、ユーザーやグループを作成する(SSOのIDストアを利用する、つまり外部認証基盤を使わない場合のみの話ですが)設定などはSSOのコンソールから実施する必要があります。

また、CloudFormationテンプレートで使用する各種リソースのIDはコンソールでは確認できず、AWS CLI等を使って取得する必要があるものが結構あります。

Terraform

Terraformは2020/10/29現在、まだ対応していない模様です。

できる限り簡単に設定・管理したい

この点ではSSO案に軍配が上がるかと思います。SSOコンソールから一元設定できます。

ただし現状は、管理の部分はやや面倒だなと感じました。各ユーザーに現在与えられている権限をSSOコンソールから一覧することができません。代わりにAWS CLIなどを駆使して確認する必要があります。(CloudFormationでプロビジョニングしてテンプレートを確認するほうが良いと思いました。)

できるだけ簡単に各アカウントにアクセスしたい

この点もSSO案の方が優れています。 ユーザーポータルからログインしたいアカウント x 権限を選択できます。

以下は、3アカウントに対してログイン権限を持つユーザーでユーザーポータルにログインした場合の画面です。3アカウント全てでAdministratorAccess権限、一番上のアカウントについては加えてReadOnlyAccess権限も持っています。

アカウント x 権限単位でログイン先を一覧できるのはとても便利かと思います。

一方Jumpアカウント案については、こういった一覧画面はありません。
初回スイッチロール時はスイッチ先のアカウントIDとロール名を指定する必要があります。つまりこの情報を控えておく必要があります。

2回目以降は以下画像のようなコンソール右上ロール履歴から簡単にスイッチできます。が、最大直近5件までしか保存してくれません。 6件以上保存したい場合はAWS Extend Switch Rolesを使われている方が多いようです。

MasterAccountはできる限りいじりたくない

この点はJumpAccountの方が良いです。

SSOの設定はMasterAccountで行なう必要があります。一方、Jumpアカウント案は、どのアカウントをJumpアカウントにするかに制約はありません。

ユーザーあるいはグループごとに細かな権限設定できる?

SSOでも細かな権限設定ができます。前述のPermissionSetには、AWS 管理ポリシーもしくはインラインポリシーをアタッチできます。このPermissionSetをユーザーやグループに割り当てることで権限設定ができます。

カスタマー管理ポリシーは使えませんが、それほど困らないのではないかと思います。複数のPermissionSetに同じポリシーを当てるケースはあまりないのではないでしょうか。

MFA使える?強制できる?

SSO案でもMFA使えます。また強制もできます。

以下はSSOコンソールのMFA設定フォームです。こんな設定項目があります。

ただし、ユーザーにMFAデバイスを登録させる場合、初回は未登録なので代替としてメールアドレスに送信されるワンタイムVerificationCodeを利用することになります。その後もMFA登録しなければ、ずっとこのVerificationCode方式が採用されます。つまりこの場合MFAを完全強制することはできません。

Jumpアカウント案の場合、以下のようにaws:MultiFactorAuthPresent条件を使うことでMFAを強制できます。

可用性

要件欄に書いてませんでしたが非機能要件として。これはJumpアカウント案の方が高そうです。

Jumpアカウント案=IAM vs SSO案=IAM+SSO

Jumpアカウント案はIAMのみで実現できます。一方SSO案も、裏ではIAMを利用しています。各アカウントに設定したポリシーをアタッチしたIAMロールを作成し、その信頼するエンティティがSSOで作成したIDプロパイダーになります。というわけでSSO案の場合、IAMとSSO、2つの単一障害点があることになります。IAMのみのJumpアカウント案よりは可用性が低くなります。

SSOはリージョナルサービス

さらに、SSOはリージョナルサービスです。グローバルサービスであるIAMよりは可用性が低いのではないかと予測します。かつ、SSOは複数リージョンを利用することはできません。SSOを有効化する際、どのリージョンで有効化するかを選択することになります。選んだリージョンにSSOで作成する各種データが保存されます。一度あるリージョンで有効化すると、他のリージョンでは有効化できません。他のリージョンで使いたかったらまず今お使いのリージョンで設定を解除する必要があります。

有効化したリージョンのSSOがダウンしたら、全アカウントにログインできなくなることになります。これはなかなか厳しいと思いますので、緊急用にSSOを介さない方法で各アカウントにログインできる経路を予め設計、実装しておいた方が良いかと思います。

まとめ

Organizations利用、かつ外部認証基盤を利用しない場合に、SSOを利用する案とJumpアカウント案を比較しました。個人的には、MasterAccountをできるだけ使いたくない、もしくは完全にIaC(Infrastracture as Code)化したいという場合を除いてはSSOを利用するほうが便利なのではと思います。