この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
現在参画中のプロジェクトでAWS Single Sign-On(以下SSO)を利用するべきかどうか検討しました。
要件
- Organizationsを使って、複数アカウントを管理する
- AD等の外部認証基盤は無い
- コードで構成管理したい (Infrastructure as Code)
- ManagementAccount(旧名MasterAccount)はできる限りいじりたくない
- できるだけ簡単に設定・管理したい
- できるだけ簡単に各アカウントにアクセスしたい
- ユーザーあるいはグループごとに細かな権限設定をしたい
- MFA(多要素認証)必須 (にするかも)
- AWSアカウントへのアクセスのみが目的。SAML 対応のクラウドアプリケーション (Salesforce、Office 365、Dropbox など)や他アプリケーションで認証基盤を共用することは考えていない ※ SSOで実現できる機能です
選択肢
- SSOを使う（以後SSO案と呼ぶ）
- SSO使わない。いわゆるJumpアカウントを用意する（以後Jumpアカウント案と呼ぶ）
SSO案概要
外部認証基盤が無いので、SSOのIDストアも利用します。SSOを有効化して、以降ざっくりとは以下を実施します。
- ユーザー、グループを作成する
- PermissionSet(日本語訳では「アクセス権限セット」「アクセス許可セット」などと訳されています)を作成する
- PermissionSetにIAM Policyをアタッチする
- アカウントごとに、ユーザーやグループとPermissionSetを紐付ける
SSO有効化時にユーザーポータルが作成されURLが発行されます。ユーザーはそのユーザーポータルにログインし、そこから自身に紐付けられたアカウント x 権限を選んでスイッチロールします。
Jumpアカウント案概要
JumpアカウントにのみIAMユーザーを作成し、他アカウントにはIAMロールを作成します。他アカウントで作業する際には、Jumpアカウントに作成したIAMユーザーからIAMロールにスイッチロールします。
参考情報
- AWS 複数アカウントの構成基準を考えてみる
- スイッチロール先の本番・開発アカウントにてIAMロール、ポリシー、パーミッションバウンダリーを作ってみた
※ この例ではPermission Boundaryを使っていますが、今回はOrganizationsを利用するのでSCPをメインに権限境界を考えます。
比較
Jumpアカウント案は先の要件をすべて満たします。SSO案で満たせない要件は無いか、またJumpアカウント案と比較してのメリット・デメリットは何か調査しました。
コードで構成管理できる？
SSO案は一部可能です。
CloudFormation
2020/09/10にSSOのCloudFormationサポートが追加されました。
ですが、CloudFormationでできることは限定的です。以下2点の定義のみです。
- PermissionSet (IAMポリシーのセット。最大でAWS管理ポリシー10個+インラインポリシー1個)
- Assignment (上記PermissionSetとAWSアカウントとユーザーorグループ、3つの概念を紐付ける)
他の設定、例えば最初にSSOを有効化する部分とか、ユーザーやグループを作成する（SSOのIDストアを利用する、つまり外部認証基盤を使わない場合のみの話ですが）設定などはSSOのコンソールから実施する必要があります。
また、CloudFormationテンプレートで使用する各種リソースのIDはコンソールでは確認できず、AWS CLI等を使って取得する必要があるものが結構あります。
Terraform
Terraformは2020/10/29現在、まだ対応していない模様です。
2021/02/15追記: 対応しました！?以下をご確認ください。
できる限り簡単に設定・管理したい
この点ではSSO案に軍配が上がるかと思います。SSOコンソールから一元設定できます。
ただし現状は、管理の部分はやや面倒だなと感じました。各ユーザーに現在与えられている権限をSSOコンソールから一覧することができません。代わりにAWS CLIなどを駆使して確認する必要があります。（CloudFormationでプロビジョニングしてテンプレートを確認するほうが良いと思いました。）
できるだけ簡単に各アカウントにアクセスしたい
この点もSSO案の方が優れています。 ユーザーポータルからログインしたいアカウント x 権限を選択できます。
以下は、3アカウントに対してログイン権限を持つユーザーでユーザーポータルにログインした場合の画面です。3アカウント全てでAdministratorAccess権限、一番上のアカウントについては加えてReadOnlyAccess権限も持っています。
アカウント x 権限単位でログイン先を一覧できるのはとても便利かと思います。
一方Jumpアカウント案については、こういった一覧画面はありません。
初回スイッチロール時はスイッチ先のアカウントIDとロール名を指定する必要があります。つまりこの情報を控えておく必要があります。
2回目以降は以下画像のようなコンソール右上ロール履歴から簡単にスイッチできます。が、最大直近5件までしか保存してくれません。
6件以上保存したい場合はAWS Extend Switch Rolesを使われている方が多いようです。
- 新しいUIのAWS管理コンソールでChrome拡張機能「AWS Extend Switch Roles」の V2 pre-release 版を試してみた
- Switch Roleの履歴が・・・消えた・・・？ って焦る前に入れておくと幸せになれるAWS Extend Switch Rolesの紹介
ManagementAccountはできる限りいじりたくない
この点はJumpAccountの方が良いです。
SSOの設定はManagementAccountで行なう必要があります。一方、Jumpアカウント案は、どのアカウントをJumpアカウントにするかに制約はありません。
ユーザーあるいはグループごとに細かな権限設定できる？
SSOでも細かな権限設定ができます。前述のPermissionSetには、AWS 管理ポリシーもしくはインラインポリシーをアタッチできます。このPermissionSetをユーザーやグループに割り当てることで権限設定ができます。
カスタマー管理ポリシーは使えませんが、それほど困らないのではないかと思います。複数のPermissionSetに同じポリシーを当てるケースはあまりないのではないでしょうか。
MFA使える？強制できる？
SSO案でもMFA使えます。また強制もできます。
以下はSSOコンソールのMFA設定フォームです。こんな設定項目があります。
ただし、ユーザーにMFAデバイスを登録させる場合、初回は未登録なので代替としてメールアドレスに送信されるワンタイムVerificationCodeを利用することになります。その後もMFA登録しなければ、ずっとこのVerificationCode方式が採用されます。つまりこの場合MFAを完全強制することはできません。
[2020-11-30追記]最近のアップデートで強制させることができるようになりました！詳しくは以下を御覧ください。
一方、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アカウント案を比較しました。個人的には、ManagementAccountをできるだけ使いたくない、もしくは完全にIaC(Infrastracture as Code)化したいという場合を除いてはSSOを利用するほうが便利なのではと思います。
61
