「シングルサインオンはいいぞ」　AWS Single Sign-Onのいいところ・イマイチなところ

ZOZOTOWNのエンジニア

光野達朗氏（以下、光野）：これから「AWS Single Sign-Onを用いた、セキュアでよりよいログイン体験への取り組み」について紹介したいと思いますので、よろしくお願いいたします。

まず、自己紹介をさせてください。ZOZOテクノロジーズSRE部でテックリードを務めている光野達朗です。もともとサーバサイドのエンジニアとしてキャリアを始めていましたが、途中でAWSの魅力に取り憑かれて転職しました。現在はSREで、AWSを専門とするエンジニアとして、日々アーキテクチャの選定・構築などを行っています。

まず、弊社が扱うプロダクトの紹介を簡単にさせてください。もしかすると利用していただいている方もいるかと思いますが、「ZOZOTOWN」という日本でも最大級のファッション通販サイトを扱っています。

また、EC以外にも「WEAR」というファッションコーディネートアプリの提供も行っています。ファッションが好きな方おられましたら、ぜひ利用してもらえればうれしいです。

本発表で扱う範囲ですが、先ほどご紹介した個々のプロダクトではなくて、組織全体のAWS運用に関するお話をしたいと思います。

本発表を通してお伝えしたいことは「Single Sign-Onはいいぞ」。この一言です。AWSをマルチアカウントで用いる場合には必ず設定したほうがいいと思っています。また、もしお使いのAWSアカウントが1つだけだったとしても、設定する価値はあるでしょう。

AWSアカウント体系とは

まず前提として、弊社ZOZOテクノロジーズのAWSアカウント体系について紹介させてください。

弊社のAWSは、AWS Organizationsを用いて、複数のアカウントを1つの組織（Organization）で管理。マスターアカウントと呼ばれる請求を管理したり統制系の機能を管理したりするところを親としまして、メンバーアカウントを作っています。

このメンバーアカウントを、各プロダクト、先ほどの「ZOZOTOWN」や「WEAR」のプロダクトチームが複数所有して、主体的に運用。本番環境用や事前環境用など、少なくとも2つ以上を運用している状況です。

マルチアカウント体系のメリット・デメリットは複数あります。メリットとしてはセキュリティの分離や課金の管理や影響範囲の縮小など。さまざまなメリットもある一方で、当然1つだけ見ればいいわけではなく、運用のオーバーヘッドが多数発生いたします。本日お話しする内容もこの運用のオーバーヘッドに関する部分です。

本日取り上げる運用のオーバーヘッド、なによりもまずログインが手間で、MFAを必須にするとさらに大変になります。

ログインの模式図なのですが、各アカウントにIAMユーザーやIAMロールを作成が必要になります。今度はログインのたびにワンタイムのパスのトークンをMFAで入力する。本番アカウントに入ってみたり事前環境用のアカウントに入ってみたりと切り替えるたびにMFAのトークンを入力することが必要です。ともかく面倒くさい作業になります。

この手間が必要かどうか考えますと、まず仕組みとしては必要です。

アカウントの分離もMFAも大事なサービスを守るためには非常に必要ですが、手間はかけなくてよい作業だと思います。一番身近にあるとすれば、入退社に伴うIAMユーザーの作成や削除でしょうか。こういった手間がかかることはついつい後回しにされがちで、結果的に安全でなくなる可能性があります。

必要なことは簡単にしたいと考え、さまざまな取り組みを検討をいたしました。「何かすてきな仕組みを使って複数のアカウントを簡単に切り替えられはしないかな」「IAMリソースの作成もなんとか減らしたいな」と感じて、いろいろ取り組みを行いました。

それがSingle Sign-Onです。以下、「SSO」と略してお話しいたします。

AWSログインの流れ

SSOは、一度のユーザー認証処理で複数のサービスのユーザー認証を済ませる仕組です。おそらく利用されている方も多数いると思います。「どこかに一度ログインしたらAWSアカウントのログインもそれで済ませる」ことがしたいと考えました。

また、SSOと言っても実現方法はさまざまです。満たしたい要素として、まず「組織のID体系と紐付けたい」。弊社ZOZOテクノロジーズの場合は、Azure ADによるActive Directory管理を行っています。

次に「AWSアカウントごとに設定したくない」と思いました。現在は60アカウント程度のAWSアカウントが存在して、どんどん増えています。

最後に、当然のことかもしれませんが、「ユーザーやアカウント、権限の紐付けを柔軟にしたい」と考えました。ここで言うユーザーは利用者一人ひとり、アカウントはAWSアカウントのことです。

これを満たすためにいろいろ試しました。詳しく話すと、ここだけで発表時間を使い切ってしまいそうなので、結論を図にまとめています。

右下、Azure ADにユーザー情報が格納されており、それを……AWSが公式で提供するSingle Sign-Onと呼ばれるサービスがあります。AWS Single Sign-Onにプロビジョニングをし、マスターアカウントからメンバーアカウントに対して権限やユーザーの配布を行うかたちです。メンバーアカウント側はログイン用のIAMリソースを作成する必要がありません。

まずは百聞は一見にしかずということで、デモ動画をご覧ください。

まずMicrosoftのAzure ADのログイン画面が出てきます。モザイク多めでお送りしますが、IDとパスワード、MFAのトークンも入力をして認証が完了。Azure ADが提供する各種SSO連携アプリケーション一覧が出てきまして、AWS SSOを押しますと、AWSへのログインが行われます。

これでAWSにログインが完了しました。ここで好きなアカウントの権限を選択すると、AWSの各アカウントへ遷移できます。各アカウントへはIDもパスワードもMFAの認証もしていません。Azureですべて済ませていて、別なアカウントを選ぶと、そのアカウントに遷移いたします。

これで、ログインいたしました。最初に入ったところからは自動的にログアウトされています。このように一度だけログインを済ませることで、すべてのAWSアカウントに個別のID・パスワード・MFAがなくともログインできることが実現しました。

SSOの運用について

次に初期設定などについて、簡単な紹介します。

まず、初期設定、AWS SSOのIDのソースを検討ください。SSO自体に管理させることや、Microsoft Active Directoryを使うこと、弊社のようにAzure ADを使うこともできます。調べたところ、つい先月Oktaとも連携が開始されたようです。

IDのソースさえ決まるとあとは非常にシンプルで、Organizationsの機能からSSO統合というボタンを有効にすると、SSOのリソースを作成いたします。

あとは対向となるAzure ADに「エンタープライズアプリケーション」を作成し接続をするだけです。ここで言うアプリケーションは設定であり、プログラムを書くわけではありません。

日々の運用はもっとシンプルです。Azure AD側の「エンタープライズアプリケーション」からユーザーを追加します。AWSに送りたいユーザーを選択すると、SSO側にユーザーが現れますので、アカウントと権限を紐づける。これで完了です。

AWSアカウントごとのIAMユーザーやIAMポリシーの作成は不要で、SSOが解決してくれます。このSSOの提供アカウント、組織の親アカウントのみ管理すればユーザー管理が可能な世界ができあがりました。

AWS Single Sign-Onのいいところ・イマイチなところを簡単にまとめました。

まず、AWSアカウントの増減を気にする必要がありません。Organizationsで管理されるAWSアカウントすべてが自動的に対象となります。

また、Azure ADにてユーザーが削除されると、AWS SSO側でも無効化されます。例を挙げると、退職時にアカウントをのぞいてIAMユーザーを1個ずつ消して回る作業は必要ありません。

それと、さすが公式のサービスということで、CLIとの統合が用意されています。コマンドラインで「aws sso login」と打つと、SSOベースのアクセストークンが取得できます。

イマイチなところとしては、現在（2020年7月22日時点）公開されているAPIが少ないことです。更新系のAPIは提供されていないので、Webコンソールから操作する必要があります。

また、SSOで定義する権限がまだIAMと統合されていません。書き方は一緒ですが、SSOで定義した権限とIAMで定義した権限が2つ存在してしまいます。これらの統合やAPIの提供が待ち遠しいです。

今後の課題

また、弊社としてログインの課題は解決しましたが、権限の周りを解決する問題が残っています。

まず最小限かつ十分な権限設計。現在はSSOにするタイミングで、大まかな権限設計に切り替えました。管理者・書き込み化・読み込み専用などです。これは、既存の権限がバラバラで、何かができなくなることを避けるために大まかな権限にいったん切り替えました。いずれは最小限の権限にあらためて戻したいと思っています。

このSingle Sign-Onですが、まだ100パーセント切り替えが終わったわけではありません。まだまだSSOの啓蒙が組織に必要だと思っています。

また、SSOベースになって不要になったIAMユーザーもたくさん存在するので、これの洗い出しと削除も今後行いたいです。これについては、AWS ConfigやCloudTrailといった監査系のシステムを組み合わせて実現できないかどうか取り組んでいます。

まとめると、弊社はAWSのマルチアカウント運用で頻繁なログインが課題でした。これに対して、SSOによってAWSアカウントでのログイン体験を改善。弊社ではAzure ADをIDソースにしましたが、SSO単品でもシンプルに扱えます。

IAMユーザーを使う場面が減るため、管理上のメリットが非常に大きいです。人間用のユーザーを削除して回る手間がなくなりました。1アカウントでも設定は可能なので、もし今後アカウントが増える可能性があればぜひ検討してみてください。

結論は頭にAWSがついていますが、「Single Sign-Onはいいぞ」。この一言に集約されます。

最後にこういった仕組みを作る人間を絶賛募集中です。AWSを使ってWebサービスを作りたい人はもちろん、仕組みづくりにも興味がある方もぜひご応募いただければと思います。

以上です。ありがとうございました。

質疑応答

坂井華子氏（以下、坂井）：光野さん、ありがとうございました。それではさっそくですけれども、sli.doでいただいた質問を見ていきましょう。お時間の都合で、すべてお答えできないことをあらかじめご了承ください。

まず1つ目。「AWSアカウント以外のアプリケーションもAWS SSOに統合していますでしょうか？　もしされていたら、統合にあたり考慮したポイントがあれば教えていただけますでしょうか？」とのことですが、いかがですか？

光野：質問ありがとうございます。現在、AWSとほかのアプリケーションは統合しておりません。あくまで弊社のメインIDはAzure ADで管理していて、そこから接続をする方針で設定をしています。以上です。

坂井：ありがとうございます。次に「OneLoginやOktaもよく使われると思うのですが、それらを使わなかった理由があれば教えていただけますでしょうか？」。

光野：質問ありがとうございます。確かに非常によく使われているSingle Sign-Onのアカウントサービスです。導入時に検討はしましたが、すでにAzure ADのID基盤があります。それとSSO AWSをつなげる際にわざわざOneLoginやOktaを間に入れるメリットがあまり大きくないかなと思い、Azure ADと直接AWSをつなげました。

もしAzure ADなどのID基盤を持っていない場合は、OneLoginやOktaとつなげるのが非常にシンプルでよいアプローチかと考えています。以上です。

坂井：ありがとうございます。次に「AWS SSO以外で検討した手段はありますか？」とのことです。

光野：AWS SSO以外にもいくつか検討しました。例えばSOSではなくてIAMのIDプロバイダーの機能があります。それを使ってもAzure ADとつなげてのSingle Sign-Onは可能です。

また、使われている方も実際いるかと思いますが、クロスアカウントでのAssumeRoleを行うことで、SSOに近しいことができないかも考えたこともあります。

ただ、いずれも「新規のアカウントを作るたびに、アカウント一つひとつに新しいリソースを作って回らないといけない」という点がネックです。最終的には、何もしなくても勝手に権限などが同期されるAWS SSOを採用しました。以上です。

坂井：ありがとうございます。新しい質問もいただいているのでいくつか見てまいりましょう。「IAM権限はどれぐらいの粒度での分割を検討されていますでしょうか？」。

光野：会社全体をまとめた際にどのようなIAM権限が最適かについて、私自身は現状で答えをもっていません。

アカウント自体は、Single Sign-On以前はストレージ専用のアカウントやEC2、コンピューティングリソースだけを触るIAM権限などが用意されていました。しかしAWS全体さまざま結合していくなかで、過不足が生まれました。

「はたしてそれをうまく最大公約数的に満たす権限ってあるのだろうか？」の問いに私自身まだわかっていません。そこを分析して新しいチャレンジとして今後取り組んでいきたいと考えています。以上です。

坂井：ありがとうございます。次が最後の質問です。「この仕組みを使って良かったり何か防げたようなエピソードはありますか？」とのことですが、いかがでしょうか？

光野：良かったこととしては、リアルタイムでアクティブなアカウント……どのAWSアカウントにどんな人間がアクティブに操作しているかについて、CloudTrailのログで一元管理できるようになったこと。親アカウントの管理者の立場としては大きなメリットでした。もちろん一利用者としては「MFAのトークンを毎回入力しなくていい」これは本当に便利なポイントです。

防げたものとしては、チーム異動や会社を辞めて新しい挑戦をされる方のアカウントを削除し損ねることがなくなりました。自動的にログインできない状態になったので、非常に運用コストが減ったのがよかった点です。

坂井：光野さん、ありがとうございました。以上でこのパートは終了といたします。ありがとうございます。

光野：ありがとうございました。