はじめに
この記事は、株式会社ポーラ・オルビスホールディングス Advent Calendar 2024 の13日目です！
5日目として re:Invent2024の現地参加記事を投稿しましたが、今回はAWSのユーザー管理（IAM）に関連した記事を書きたいと思います。
re:Inventからの帰りの飛行機で記事を書いています。果たして無事に期日までに執筆が出来ているのでしょうか？🤔
それでは、ここから本編となります。
マルチアカウント環境でユーザー管理をするために
AWSを活用していくとシングルアカウントではなく、システム単位でAWSアカウントを作成するケース（マルチアカウント）があり、弊社も例外なく数多くのAWSアカウントでシステムが稼働しています。
AWSアカウントが増えるたびに、各アカウントで個別にユーザー（IAM）管理を行う必要があり、管理者の作業負担や設定ミスが増えるリスクがあります。また、複数アカウントでのログイン操作が煩雑化し、利用者にとっても利便性が低下します。
| 課題 | 詳細 |
|---|---|
| 運用負荷が増大 | 異なる手法/個別管理により作業が煩雑化し運用負荷が増加 |
| セキュリティリスク | 権限管理の漏れや設定ミスが発生しやすく、リスクが高まる |
| 利便性の低下 | 複数のAWSアカウントにログインが必要となり、ユーザーの操作が煩雑化 |
セキュリティリスクの部分では、「離任者のIAMユーザー消し忘れ」などが現場あるある話ではないでしょうか？🤔
これらの課題を解決するために弊社では、各アカウントで分散していたユーザー管理を統一し、シングルサインオン（SSO）を活用して一度のログインで必要な権限を付与する仕組みを採用しました。
IAM Identity Center x Microsoft Entra ID を導入することで得られる効果
IAM Identity Center は、AWSアカウントへのアクセスを一元的に管理できるサービスです。
弊社ではMicrosoft 365を利用しており、そのユーザーは Microsoft Entra ID（旧Azure AD）で一括管理されています。
これらを連携して実際に利用したことで、以下のような効果が得られました。
ユーザー管理の一元化
- Microsoft Entra ID を利用してユーザー情報を集中管理
- IAM Identity Center と連携することで、1人のユーザーに必要なAWSアカウントの権限を一元的に管理可能
- 登録や削除の手間が大幅に軽減し、運用効率が向上
認証プロセスの簡略化
- IAM Identity Center を活用して、SSOによる1回のログインで必要なすべてのAWSアカウントにアクセス可能
- プロジェクト間でアカウントを切り替える手間が解消され、業務効率が大幅に向上
セキュリティの向上
- IAM Identity Center を通じて権限セットを統一管理し、設定ミスや漏れを防止
- 特定プロジェクトの終了後には不要な権限を速やかに削除し、不正アクセスのリスクを最小限に抑制
- ログインプロセスに多要素認証（MFA）を適用することで、セキュリティをさらに強化
例えば、新しいメンバーが入社した場合、Microsoft Entra IDに登録し、IAM Identity Centerを通じて適切なAWSアカウントの権限セットが割り当てられます。これにより、権限の付与が効率化されます。システムごとに異なるAWSアカウント上に作成されるIAMユーザーでログインする必要がありましたが、1回の認証で全てのアカウントにアクセスできるようになります。
詳細な作業手順は割愛しますが、AWS公式ドキュメント通りのステップで実装することが可能です。
MicroSoft公式ドキュメントも参考になります。
管理者観点/利用者観点の双方でメリットを得られるため、Entra IDを利用している場合、オススメしたい構成の１つです。
Entra IDにユーザーがいない場合のケースは？
上記の構成を採用していても、例えばシステム開発や管理をパートナー会社に委託していて、Microsoft Entra ID上にパートナーのユーザー情報が存在しないケースもあるかと思います。
弊社もそうでした。
管理者観点/利用者観点から IAM Identity Center x Microsoft Entra ID の仕組みは継続しつつ、セキュリティの観点から各AWSアカウントには原則IAMユーザー（人が使うIAMユーザー）は作らないという方針にしたいと考えました。
JUMPアカウントという考え方
そこで弊社では、BlackBeltを参考にIAM Identity Centerとは別で各AWS環境へアクセスするための専用の JUMPアカウントというものを用意しました。
IAMユーザーはそのJUMPアカウントに作成し、必要に応じたAWSアカウントへスイッチロールするという構成を採用しています。
【引用元：AWS Identity and Access Management (AWS IAM) ~ベストプラクティスで学ぶAWSの認証・認可~ Part2-】
これにより１つのAWSアカウントでIAM（ユーザー/ロール/ポリシーも含む）の管理をすることができ、管理の煩雑さを軽減することができました。
JUMPアカウントの課題
とはいえ、JUMPアカウントを利用する場合でも、IAMユーザーそのもの、スイッチロール先のIAMロールなどの維持管理（作成/削除/変更）という作業がゼロになるわけではありません。
IAMはマネジメントコンソールからクリックだけで簡単に作成することができますが、JUMPアカウントで一元管理を手作業で行うには限度があります。
↓は大量のIAMユーザー作成依頼が来た時の私です。
間違える自信がありました。
そこでJUMPアカウントの維持管理については、CDKで行うようにしました。
次回予告
明日、14日目の記事で 「AWS CDKでコード管理されたJUMPアカウントを構成してみた」 を投稿予定です。
興味のある方、似た悩みを抱えている方の参考になれば幸いです。
弊社では一緒に働く仲間を募集中です
現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご興味のある方は是非ご連絡ください！
募集内容等詳細は、是非採用サイトをご確認ください。
https://engineer.po-holdings.co.jp/