ユーザーも利用状況も一括把握　認証情報レポートでAWSのIAMユーザー棚卸し

組織全体のAWS運用がトークテーマ

光野達朗氏（以下、光野）：「マルチアカウントでのIAMユーザー把握と可視化 IAMユーザー棚卸しへの取り組み」と題して、ZOZOテクノロジーズの光野が事例を共有します。よろしくお願いします。

まず始めに私の自己紹介をします。ZOZOテクノロジーズCTO室ならびに技術本部 SRE部 テックリードを務める光野です。ふだんは弊社AWS Organizationsの管理者を務めています。

弊社が手掛けるプロダクトについても簡単に触れます。1つ目はZOZOTOWNです。日本最大級のファッション通販サイトで、1,300以上のショップ、7,400以上のブランドを取り扱っています。必ず好みのアイテムが見つかると思うので、ぜひ一度覗いてもらえればと思います。

2つ目がWEAR、日本最大級のファッションコーディネートアプリです。画面左にあるように、自分が来ている服にタグ付けを行い、どのようなコーディネートしているかをお互いにシェアできる、SNS要素のあるアプリケーションです。こちらもぜひ一度ご覧ください。

このZOZOTOWNやWEARのどちらも、一部がAWSの上で動いていますが、本日話すのは個々のプロダクトではなく、組織全体のAWS運用に関するお話です。本発表を通して伝えたいことは、“マルチアカウントでもIAMユーザーの棚卸しはできる”ことです。

ZOZOテクノロジーズでは、継続的なIAMユーザーの棚卸しに取り組んでいます。そのために、組織のIAMユーザーの把握、可視化、Slackに共有する仕組みを作りました。今見てもらっているものがまさにそれで、IAMユーザーの日時の変化や、アカウントごとに所属するIAMユーザー数などが可視化できます。

ZOZOテクノロジーズのログインユーザー管理

本題に入る前の前提して、弊社のログインユーザー管理の様子です。Azure ADをメインのIdPとしており、それをAWS Single Sign-Onを通じてマネージメントアカウントからメンバーアカウントに対して権限やユーザーの配布をしています。メンバーアカウントのほうには、ログインのリソースを作る必要はありません。

このかたちを踏まえて、実現したいことが1つあります。IAMユーザーの利用を最小限にすることです。IAMユーザーの問題点は、部署異動、退職時のユーザー管理が煩雑ということです。煩雑とはいえ、残しておくとログインできてしまうので、削除が必要です。またアクセストークンに有効期限がないのも問題かと思っています。SSOの場合は、セッションタイムアウトに準ずるので、だいたい12時間で有効期限が来て使えなくなります。

AWS SSOがある今、WebコンソールへのログインにIAMユーザーを使う必要はなく、これの多くは削除が可能なはず、と考えました。そのためには、まず把握が必要です。

どうやってマルチアカウントのなかでIAMユーザーを把握するか？

課題です。どのようにしてマルチアカウントの世界でIAMユーザーを把握するかが最初の問題でした。IAMユーザーの中には、Webコンソールにログインできないユーザーもいます。コンソールへのパスワードを持たない、いわゆるアプリケーションのためのアクセスキー発行などの目的で作られるユーザーです。まずはこれを除外した一覧を作るところから始まりました。

（スライドの）下に列挙しているとおり目視やConfig、APIといった何らかの手段は思い浮かぶものの、あまりにも非効率であったり、要件を満たさないことが課題でした。また、実際のところ削除に臨むのであれば、アクセスキーの状況も確認したいです。

IAMユーザーや利用状況を手軽に把握できる、そんな便利なものはないのだろうかと思い、サポートケースなども含めて調査をしたところ、ありました。IAMが提供している認証情報レポートです。認証情報レポートとは、AWSアカウント内に存在するIAMユーザーと、各種認証情報のステータスが一覧にまとまったものです。Webコンソール、もしくはAPIにてcsvファイルで取得が可能です。

下の表がそのcsvの中の列を抜粋したものですが、例えばユーザー名、パスワードの有効・無効化状況、最終利用時刻。アクセス権に関しても、有効・無効と最終利用日時などが一覧で取得できます。AWSアカウント1つですが、欲しい情報はすべてありました。これをマルチアカウントで利用する、それが私たちのアプローチです。

IAMユーザーの現状把握で重視した3つのこと

IAMユーザーの現状把握にあたり、重視したことが3つあります。1つは運用に手間をかけないこと。これは私の取り組みすべてのポリシーにもありますが、一度作ったあとにメンテナンスし続けないといけないものは非常に手間がかかり、運用コストがかかると継続が難しくなります。ともかく、最初に作ったらあとはうまく動いてくれることを重視しています。

2つ目が、認証情報レポートの取得と分析を分離することです。rawデータをそのまま保存し、必要なタイミングで分析するかたちにしたいと考えていました。プログラムを使って加工することは容易ですが、そうすると分析要件が変わった際に追随できなくなるので、やはりrawデータをそのまま保存して、適宜分析にこだわりをもって設計しました。

3つ目。これは必ずしも把握に必要なわけではありませんが、対応状況を時系列で可視化、自動で共有されることにもこだわりました。やはりIAMユーザーの把握と削除は継続的な活動です。自動で可視化されたものが共有されることで、モチベーションの維持にもなるし、他部署とのコミュニケーションも捗るだろうという判断で重視しています。

現状把握に活躍した3つのサービスと詳細

実現のために、「AWS CloudFormation Service Managed StackSets」「Amazon Athena」「Amazon QuickSight」、この3つのサービスが活躍しました。

このService Managed StackSetsを用いることで、AWSアカウントができたタイミングで新しいリソースの準備が可能になります。AthenaとQuickSightに関しては、S3のデータを標準SQLを使用して分析をしたり、さまざまなデータソースから集めたデータを基にして分析、可視化するBIツールです。

先ほど列挙した3つのサービスを用いて、Webコンソールにログイン可能なIAMユーザーに限定して可視化できるようになりました。

少し構成についても紹介したいと思います。マルチアカウントでIAMユーザーを把握する流れですが、かたちとしてはシンプルで、マネージメントアカウントからCloudFormation StackSetsで必要なリソースを、メンバーアカウントに準備します。

メンバーアカウントは特定のアカウントにレポートを集約します。その集約されたアカウントでAthenaを使って分析したり、QuickSightで可視化をしたり、またSlackに対して共有をしたりしています。

こだわった部分

詳細も少し触れたいと思います。全体の細かい部分の詳細は説明しませんが、こだわった部分をこれから掘り下げていきたいと思います。

まず1つ目。S3へのレポート保存の部分です。分析には認証情報レポートだけで十分ですが、少し利便性を向上するために工夫をしています。分析、可視化するにあたっては、やはりAWSのアカウントIDの12桁の数字ではなく、アカウントの名前を使えたほうが便利なので、AWS Organizations APIをLambdaから叩いてアカウント名を取得しています。

レポートの中にアカウントIDが含まれますが、名前は含まれないので、その補完をLambdaがしています。また、S3に保存する際にAthenaのPartition Projectionが利用できるかたち、パーティション作成という行為を自動化する仕組みで保存しました。詳細についてはこの次のスライドで説明しますが、保存に関しては、YYYY/MM/DD/を含んだパスに先ほど取得したアカウントネームを付けたcsvで保存します。

次にAthenaでのテーブル定義に関してです。先ほど話したPartition Projectionを利用しています。こちらは何をしているかと言うと、1日ごとで自動的にパーティションを作成するようになっています。Athenaを使ったことがある方は知っているかと思うんですが、パーティションを参照することでクエリが速く、コストも低く使うことができるものの、その運用はなかなか癖があるものでした。

Partition Projectionはそれを自動化するものです。実はここまでの取り組みで、当初の目的だったIAMユーザーの把握に関しては実現できています。

こちらは分析の様子です。肝は$pathという変数を用いているところです。Athenaは$pathという組み込み変数名で、データを読み取ったオブジェクト名を参照できます。先ほど、認証情報レポートをアカウント名.csvで保存しましたが、これにより、csvを加工せずともその内容とアカウント名を紐づけてSELECTできるようになります。

実際に下に写っているものがその結果です。IAMユーザー名、12桁の数字、それに紐づく何らかの名前、〇〇-prdとか〇〇-stgというもの。そしてパスワードやアクセスキーの情報をいつ使ったのかの状況を一覧で取得できるようになりました。

最後に構成上の工夫。QuickSightでの可視化と共有に関してです。QuickSightではAthenaにクエリを発行してデータセットを作成するようにしました。QuickSightで可視化を行う際に、その7日前、14日前といった日付を用いる場合は、列の1つに日付型を含む必要があります。

AthenaではString型で保存されているので、その列の型を変換するなどの処理をQuickSight上で行い、最終的に可視化、そして結果をメールで共有しています。

IAMユーザーの把握と削除の運用状況

現在の運用状況を紹介します。IAMユーザーの把握と削除は、Webコンソールにログイン可能なIAMユーザーを90パーセント削減することを直近の目標として掲げ、今取り組んでいるところです。削除作業の進捗共有に関してはQuickSightによる可視化を社内で展開して、IAMユーザー数の多いAWSアカウントはそれをフォローする取り組みを行っています。

今後解決する必要があるものも、まだ残っています。まずホワイトリストの管理です。必要性が認められるIAMユーザーも中にはあるだろうということで、それをホワイトリストで管理する予定があります。問題はそれをどこで管理するかで、できればAWS的なアプローチで管理したいと考えています。

2つ目は、IAMユーザーをそもそも作ることが減ってきたので、それを作成したタイミングでイベントとしてキャッチして、必要であればヒアリングすることにつなげていけたらと考えています。

認証情報レポートでIAMユーザー情報を取得できる

まとめです。組織全体のAWSでIAMユーザーを最小限にしたい課題がありました。IAMユーザーは部署異動や退職などのタイミングで適宜管理するべきですが、それは非常に煩雑です。弊社はAWS SSOを利用しているので、Webコンソールにログイン可能なIAMユーザーが必要なケースは非常に稀という状況もあります。

そこで、認証情報レポートを用いて、アカウント単位のIAMユーザー情報を取得できることを学べました。さらにいくつかのサービスを組み合わせてマルチアカウントに拡充し、IAMユーザーの把握、可視化、共有が実現しました。マルチアカウントのIAMユーザーの棚卸しに、鋭意取り組んでいる最中です。本日紹介したアーキテクチャが、みなさんの課題解決につながれば何よりです。

最後に採用についても触れたいと思います。弊社は積極的に採用活動しています。AWSを使ってWebサービスを作りたい人はもちろん、本日紹介した何らかの仕組みを作りたい方も大歓迎です。ぜひ一度弊社のサイトを見てもらい、そこから連絡をもらえれば幸いです。以上で私の発表を終了します。本日はありがとうございました。

質疑応答：IAMユーザーを作らざるケースとコントロール方法

それでは質疑応答に移りたいと思います。ではさっそく「IAMを作らざるを得ないケースもあるかと思いますが、どのようにコントロールされていますか？」

IAMを作らざるを得ないケースの1つは、そもそもログインのためというよりアクセストークンが必要で、パスワードを持っていないIAMユーザーを作るケースです。もちろん、パスワードを持ってどうしてもWebコンソールにログインしたいケースもあると思っています。ただ、いずれも数としてはだいぶ少ないのではないか、というのが整理している現在の所感です。

登壇の中にも少しありましたが、AWS Configを使って発生のイベントそのものを検知して、そのタイミングでヒアリングできるような世界にできないかと、今計画しているところです。厳しく取り締まるという意味合いではありませんが、適切に、必要なものを必要なときに、という運用体制構築を目指しています。

「だいたいどれくらいのIAMユーザーがいましたか？」という質問に回答します。シングルサインオンを導入する前までは、三百何十かのIAMユーザーがありました。シングルサインオンを導入後、徐々に切り替えを促進して、現在だとだいたい100を切るぐらいまで減っています。当時多かったときの1割、30以下、ゆくゆくは0が現状の目標になっています。

質疑応答：IAMユーザーの削除方針

「IAMの最終利用日時だけではIAMの必要性判断には情報不足すると思いますが、IAMの利用状況の把握は結局1つ1つ確認する以外に何かあるのでしょうか？　まずは使っていないIAMを削除する方針でしょうか？」

そのとおりだと思います。最終日時だけでは判断がちょっと難しいので、弊社が加える情報としてはアクセストークンの有無と、それを最後にいつ使ったかを情報の目安として取り組んでいます。実はもうSSOに移行していたので、いらなかったユーザーも棚卸しするとけっこうあるもので。まずは明らかにすぐ消せるところを一気に消す対応を取っています。

その上で「アクセストークンが直近に使われているな」とか。すぐに確認できない範囲に関しては、ログインのパスワードを無効化し、Webコンソールにログインできない状態を作った上で調査するかたちで数を減らしている最中です。

やはり消したいのはありますが、IAMユーザーを消したとして、それが我々の運用作業に負のダメージを与えてしまっては本末転倒なので、安全性にも配慮して数を減らしているところです。

質疑応答：SSOの権限セットについて

SSOの権限セットに関する質問を複数もらっていますね。ちょっと話題とは外れますが、こちらにも回答します。SSOの権限セットに関しては、現状シンプルに構成しています。

AdministratorとPowerUser、あとはReadOnlyでまずは大きく権限を分類して、そこに対してビリングだけが見れればいい事情があれば、そこを追加していくことを基本に、いくつか派生させて作っています。この辺りは私が2019年に登壇したSSOを導入する資料がSpeakerDeckに公開されているので、ツイートなどをたどって確認してもらえれば幸いです。

もっと細かい権限セットなどを作れればいいに越したことはないですが、まずはトラブルがないように、大きな権限で不足がないよう運用してもらった上で、必要であればログを蓄積し、もうちょっと詳細な権限セットに変えていきたいというのが長期的な計画です。

質疑応答：認証情報レポートの情報はAPIで取得できない？

1つ認証情報レポートに関する質問をもらっていますね。「認証情報レポートの情報そのものがAPIで取得できないのか」。こちらにも回答します。

認証情報レポートの情報そのものは、すべて確認したわけではありませんが、IAMのdescribe iam usersを叩けばおそらく取得はできると思います。少なくともパスワードの有無は個別にユーザーを指定して、リクエストして情報を取れたので、がんばれば認証情報レポートに入っているものもすべてWeb API経由で取れるかと思います。

ただ、やはりそれを数十のアカウントの中の、いくついるかわからないユーザーに対して全員APIを叩いてもらうのは非常に煩雑というか、スケールしないだろうなと思って。Web APIで取得することは最初から選択肢として外した上で、いろいろと調べていたところ、そもそも最初から情報がしっかりまとまったcsvがありました。しかもそのcsvがWeb APIで取得可能だということで、もう完全に途中からは認証情報レポート1本でシステムを組むように構築しています。

質疑応答：アカウント名を取得する方法

ではもう1つか2つ、質問を取り上げたいと思います。「アカウントIDからアカウント名を取得する際の『organizations:DescribeAccount』はメンバーアカウントから実行していますか？」という質問に対して回答します。

はい、メンバーアカウントから取得しています。スライドの詳細の図の真ん中にあるLambda FunctionからAWS OrganizationsのAPIを叩いて、organizations:DescribeAccountをLambdaが叩いて、権限情報の取得しています。

ここで取得するために、Organizationsのマネージメントアカウント側にメンバーアカウントがAssumeするためのIAMロールを用意しています。LambdaはAssumeRoleして権限を引き受けてAPIを叩いて、その結果を最終的にS3に保存する構成を取っています。

質疑応答：IAMユーザーを使っている理由

「IAMユーザーを使用している理由で、多かった理由を知りたいです」。これはシンプルにログインのために使っていたからです。

弊社のシングルサインオンは2020年の4月頃に本格導入をして、徐々に徐々に会社の中に広げていきました。その時点でおそらくアクティブなアカウントがすでに50以上はあったかと思います。その時点ではIAMユーザーを使ってアカウントの中に入るのが当たり前の運用だったので、さまざまなアカウントにたくさんのIAMユーザーがいる状況でした。

IAMユーザーの棚卸しに関しては、3ヶ月や半年といった組織改編のタイミングで定期的に棚卸しはしていたものの、やはりそもそもアカウント全部をリストにして削除するのは大変、というのは自分自身非常に感じていて。SSOに切り替えることをきっかけになんとかしたいと思って、この取り組みにつながっています。

質疑応答：SSOのリージョンについて

ちょっと本題からもしかしたらズレるかもしれませんが、「東京リージョンにAWS SSOが来る前は、どのような運用をしていましたか？」に回答します。

実は弊社のSSOは、東京リージョンではありません。現在ノースバージニアに作られています。というのも、SSOを導入する時点では東京リージョンにまだ来ておらず。さてどうするかと悩みましたが、他のリージョンに作ってみたところ、特に何の問題もなく動いたし、レスポンスが悪いとかそういったこともないので、引き続きノースバージニアをメインに使って運用しています。東京リージョンに持って来る話も、今のところ社内では出ていません。

それではこれで質疑応答を終わります。たくさんの質問ありがとうございました。