IAM Identity Center(AWS SSO)に移行して1年たったので使い方などまとめる

AWSアカウントが複数ある時、みなさんは認証・認可の管理をどうしていますか? PLAN-Bでは2019年に全面的にAWS SSOを使い始め、1年以上が経ちました。以下の点で特にメリットを感じており、利用を継続しています。

• アカウントごとにIAMを管理する必要がなくなる
• クレデンシャルが長期に渡ってローカルマシンに保持されることがない
• 基本的には無料

いずれも運用次第なので例外がありますが、マルチアカウントの管理に辟易していてゆるく始めるのであれば上記の認識で良いかと思います。きっちりかっちり管理が必要な場合もそれはそれで対応できるので、AWS SSOを導入した上で組織のポリシーと相談して合わせれば良いです。

本記事では社内でのAWSアカウントの状況、認証・認可方式の変遷を、経験を踏まえてまとめます。もし興味をお持ちいただけたのであれば、具体的な導入方法や細かいことはAWS公式のドキュメントや、AWS Black Belt Online SeminarのAWS SSOの回をご覧ください。

AWS SSO導入時点でのマルチアカウント状況

PLAN-BではAWS、GCP、Azureのいずれもそれぞれの得意領域に合わせて利用しています。AWSにおいては複数のプロダクトや社内向けのサービスが動いており、更にそれぞれ開発環境と本番環境とでアカウントを切り離しています。マイクロサービス化の一環で決済や単独利用可能な機能なども、独立したアカウントとして切り離しています。 時期により増減がありますが、おおむね15〜20個のアカウントが存在します。開発者1人あたりだと、2〜6個ほどのアカウントをまたがって操作をすることが日常的にあります。

プロダクト×環境ごとにアカウントがある

2018年頃まではマルチアカウントとしての管理をしておらず、それぞれのアカウントにIAMユーザーが存在していました。そこから少しずつスイッチロール運用、AWS Organizationsによる組織化と進めて、現在はAWS Organizations + AWS SSOの運用に落ち着いています。 それぞれの段階で解決していったこと、問題になっていたことを時系列で紹介します。

過去編: アカウントごとに個別のIAMユーザー

AWSアカウント1つにつき1つのIAMユーザーを用意する方式です。何らかの認証・認可や組織化の仕組みを入れない場合は自然とこの形になります。

例えば1人の開発者が4つのアカウントで何らかの作業をする場合、それぞれのアカウントにIAMユーザーが作られるので、合計4つのIAMユーザーを管理することになります。 ローカル環境からAWSに接続し開発や運用を行う場合、IAMユーザーごとにクレデンシャルを生成し保持することになります。 それぞれのアカウントにIAMユーザーとそれに付随してIAMロールも存在するため、例えば入退社などで人の移動があった場合に、アクセス権の整理が非常に煩雑かつ抜け漏れが発生しやすくなります。

アクセスできるアカウントが多いほど、IAMユーザーとクレデンシャルが大量に

当時の問題をまとめます。

• 1人が複数のIAMユーザーを持つことになり、管理が面倒になる(パスワードを同じにするなどのリスクもあがる)
• セキュリティを強化するために多要素認証を入れた場合、これもIAMユーザーの数だけ必要なので管理が煩雑(二要素認証アプリ内にAWSアカウントが何個も並んでつらい)
• IAMユーザーの数だけクレデンシャルが生成され、ローカルマシンに保持することがあるので、マシン紛失時などのリスクが高まる
• 管理側としても「誰がどのアカウントを使っていて、どの権限を持っているか」を把握するのに相当な手間がかかる

ここから特に解決したかったのは「1人の開発者が複数のIAMユーザーを持つ」ことでした。 そこで「1人の開発者につきログインするIAMユーザーは1つ」に変えるために、スイッチロール運用を始めました。

過去編: スイッチロールによるIAMユーザーの統一

AWSにはスイッチロールという仕組みがあり、ざっくり言うと「IAMユーザーが1つあれば、信頼関係にある他のAWSアカウントのIAMロールを使える」ようにできます。 IAMユーザーを管理するAWSアカウントを1つにできるので、管理側からすると人の移動に伴うIAMユーザーの追加/削除の管理が楽になり、開発者からしても1つのIAMユーザーだけ管理すればいいので手間が大きく減ります。

PLAN-Bではこの時点でIAMユーザーを管理するAWSアカウントを新規作成しました。(以後rootアカウントとします) AWSへのログインはrootアカウント一本に絞り、各プロダクトがのっている他のAWSアカウントにはスイッチロールをする運用に変更しました。

「認証」するIAMユーザーを1つにし、認可と分ける

「認証」の手間を大きく減らすことはできましたが、この方式では「認可」の手間はほとんど変わりません。 IAMユーザーは1つになりますが、そこからスイッチロールする先のIAMロールをアカウント側に用意する必要があり、更にスイッチ元(rootアカウント)とスイッチ先(各プロダクトのアカウント)の信頼関係を設定する必要もあります。 アクセス権の管理をする際には、結局IAMユーザー×各アカウントのIAMロールの数だけの確認をすることになります。 そこで当時の情報セキュリティポリシーも鑑みつつ、AWSで開発者に割り当てるIAMロールについて大幅な割り切りを行いました。

1. プロダクトのアカウントでスイッチするIAMロールに関しては、AWS標準のポリシーのみを利用する
2. AWSの習得度が一定以上(経験や資格で判断)の社員は、参画しているプロダクトのアカウントにおいて全てのIAMロールにスイッチできる
3. 例外として、開発者以外や社外のユーザーに関してはアクセス権改廃の稟議を行う

1のAWSの標準のポリシーで使うのは主に以下の4つで、現在のAWS SSO運用でも基本的に同様のポリシーに基づいています。

これらの権限を、AWS未経験者やAWS研修が終わっていない新卒らを除いて、開発に関わる社員全員に割り当てました。 アクセス権の改廃自体は行っているので、ざっくりまとめると「AWSわかっているなら、申請してくれれば関わるAWSアカウントの全権限あげる」かたちです。 これはプロダクトのアカウントに限った話なので、rootアカウント自体やアカウントの管理ユーザーについてはごく一部の許可された人のみが触れます。 また開発に関わらない社員や他社の方には、上記に限らない細かい権限を割り当てる場合もあります。(ごく少数なので例外として対応)

この割り切りを行った結果、IAMロール設定を一定のルールに基づいて行えるので、AWS CloudFormationによるスイッチ先IAMロールの自動作成ができるようになりました。 管理作業自体シンプルになり、自動化による作業時間の短縮もできました。

スイッチロールによって解決したことと、残っている課題をまとめます。 解決したこと:

• 開発者1人につき複数アカウントのIAMユーザーを管理している状態から、1人につき1IAMユーザーの管理になった
• どのアカウントにどの開発者のIAMユーザーがあるか管理側が把握しにくい状況を解決
• 副次的に、各プロダクトのアカウントで独自管理されていたIAMロールを、標準ポリシーに寄せる整理ができた

残っている課題:

• スイッチできるIAMユーザーのクレデンシャルがローカルマシンに存在するので、マシン紛失時などのリスクは依然高い
• スイッチ先のアカウントやロールの組み合わせを把握しておく必要があり、開発者からすると一部煩雑
• スイッチロールをする際に、開発時やAWS CLIでひと手間かかる(本記事では詳細には扱いません)
• 自動化はしたものの、IAMロールをアカウントごとに作成・管理するのは煩雑
• 請求管理が各アカウントをスイッチしてまわることになるので煩雑

これらを解決するために、AWS Organizationsによる複数アカウントの組織化と、AWS SSOの導入検討を始めました。

過去編: AWS Organizationsによる複数アカウントの組織化

AWS Organizationsは認証・認可の仕組みではなく、複数のアカウントを組織化し、一元管理するためのサービスです。 AWS Organizationsによってアカウント間をツリー状に紐付けることで、認証・認可であるAWS SSOの利用や、セキュリティのAmazon Guard Dutyを統合利用するなどができます。 また、認証・認可とは別軸ですがものすごく大事なこととして、請求の一括管理ができるようになります。 請求支払いをまとめるのはもちろんのこと、コストエクスプローラーで複数のアカウントをまたがって請求確認ができるので、コストの監視や取りまとめが非常に楽になります。 AWSアカウントの作成もここからできますが、PLAN-BではAWS Control TowerからAWS Organizationsにアカウントを作成しています。(本記事では詳細は扱いません)

スイッチロール時代に作ったrootアカウントを組織上のRootにし、そこから統制用のアカウントやプロダクトのアカウントをツリー状に紐づけていきました。

アカウントの役割を明確にし、ツリーでの制御をできるようにする

AWS SSOへの移行とメリット、料金など

AWS Organizationsでアカウントを紐付けた後は、いよいよAWS SSOの導入と移行です。 AWS SSOの公式資料などではわかりづらいのですが、以下のような条件の方であればAWS SSO自体は無料で利用ができます。自前のActive DirectoryやAWS Directory Serviceは必要ありません。設定なども不要で、AWS SSOをどこかのリージョンで有効化するだけです。2020年9月に東京リージョンでも利用できるようになりました。

• AWS SSOを利用した認証・認可は、今のところAWS Organizationsで紐付けAWSアカウントだけ
• 既存のIDプロバイダを利用する予定はなく、AWS SSO内で認証・認可の管理ができれば良い

かく言う私も、「ホンマに無料か?」と相当疑いました。「Aというサービスの利用は無料です。(ただしAが使っているBというサービスでお金がかかります)」というのは結構あるあるだと思います。AWS SSOの場合は、裏側で実はDirectory Serviceが有料でかかるのでは?と疑っていましたが、上記条件のような利用であれば無料です。 実際、念の為1ヵ月の試用期間を置きましたが特に料金はかからず、1年以上経った今もAWS SSOでの料金はかかっていません。

AWS SSOで認証・認可を管理するようになると、そもそもIAMユーザーが不要になります。ユーザーの管理はAWS SSOのサービス上で行うようになるからです。IAMロールに関してはスイッチロール時に割り切った標準ポリシーがAWS SSOでも用意されているのと、必要であればカスタムポリシーも作成可能です。 AWS SSOではサービス画面上で「ユーザー(+グループ)」×「ロール」×「アカウント」の権限管理が一括でできるようになり、見通しがよくなります。

IAMユーザーを使わないので、AWS SSOに移行すると通常のマネジメントコンソールへのログイン画面ではなく、AWS SSOのログイン画面から利用することになります。 以下のように、AWS SSOにログインし、そこから自分がアクセスできるアカウントとロールが並んでいるので、「マネジメントコンソールに入る」や「一時的なクレデンシャルを発行する」ことができます。

ここで発行されるクレデンシャルにはIAMロールごとに期限をもたせることができるので、設定次第で1時間から12時間の範囲で自動的に有効期限切れにできます。最近ではAWS CLI v2がAWS SSOに対応したので、CLIからAWS SSOにログインしようとすると、ブラウザでAWS SSOのログイン画面が表示されます。そこでログインすると、自動的にAWS CLIにクレデンシャルが設定されます。8〜12時間程度に期限を設定しておけば、1日1回ログインすれば良く、クレデンシャルをローカルに保持し続けるリスクが軽減されます。

AWS SSOに移行によって解決したことをまとめます。

• AWS SSOの画面上で一括してユーザーと認可を管理できる。他のアカウントを見に行く必要はない
• IAMユーザーが不要になるのでクレデンシャルを持ち続ける必要がなく、IAMロールの有効期限付きクレデンシャルだけになる
• ログイン後にアカウントとロールの組み合わせが表示されたり、AWS CLI v2で対応していたりと、マルチアカウント間の操作ストレスがかなり低い
• 基本無料で利用できる

個別でのIAMユーザー管理はさておき、スイッチロール時から比べてもストレスフリーな部分が多く、かなりメリットが大きいと感じています。 その割にはAWS SSOをおすすめする記事をあまり見ないので、具体的な導入手順などはさておき、私が実際に感じたメリットを今回まとめてみました。 基本無料であり、AWS Organizationsにアカウントを入れるだけで試せるので、小さく始めることができます。 実際に私も少しずつ移行をしていき、最終的に全ての移行を行いました。またそれに合わせて現在では人が使うIAMユーザーを0にできています。個別アカウントでのIAMユーザー管理からスイッチロールを経て、IAMユーザーを絶滅させる作業をした時の高揚感は最高でした。

AWS SSOどちゃくそ便利で社内外でめちゃ使ってるけど、事例とか記事とか少ないのなんでなんだろう。もっとイケてる方法があるのか、1組織内でマルチアカウントしまくってるケースが少ないのか。

— Masahiro Yukawa (@yuk4w4) July 3, 2020

(東京リージョンが解禁されたことで今後増えるかも…!?)