AWS Identity Centerを活用して荒ぶるIAM Userの棚卸し

こんにちは、KAZYです。

この度 AWS Identity Center を導入して荒ぶるIAM Userの棚卸しを行いました。

導入

これまで当社では AWS アカウントをプロダクトごと・環境ごと（開発/本番）に IAM User で管理していました。
特に歴史の長い開発環境では IAM User の権限やライフサイクルが十分に管理されておらず、とっちらかっていました。

具体的には以下のような問題を抱えていました：

• 誰がどのアカウントにアクセスできるのか把握しづらい
• 退職者のアカウント削除が適切に行われているか不安
• 複数アカウントを行き来する際の認証が面倒
• ユーザの発行フローが不明瞭
• 個人に発行したユーザのシステム利用

これは可愛がっているAIエージェントの教育上も良くない。保護者としてもう少しマシな環境を作ってあげたいと常々思っていました。

Oh messy!

移行を決めた背景

2024年に介護施設向けの新プロダクト『KaigoDX』をリリースし、プロダクト専用のAWS環境を新たに構築しました。その結果、管理対象のAWSアカウントがさらに増え、従来の手動によるIAM User管理を根本的に見直す必要が生じました。

https://kaigodx.com/

また、不要なユーザーの棚卸しや整理もこの機会に実施したいと考えていました。多くのプロジェクトを経験してきた中で、開発者の入れ替わりもあり、「誰のアカウントかわからない」「このユーザーにはどんな権限があるの？」といった状況が散見されていたためです。

春は出会いと別れの季節です。これまで頑張ってくれたIAM User達に別れを告げる決心をしました。

AWS Identity Centerを選んだ理由

AWS Identity Center（旧 AWS Single Sign-On）を選択した主な理由は以下の通りです：

1. 複数のAWSアカウントを一元管理できる

   • 一箇所でユーザー・グループを管理し、複数のAWSアカウントへのアクセス権を集中管理できる
   • Organizations との統合により、組織全体のアクセス管理が容易になる

2. グループベースでシンプルに権限を設定できる

   • ロールベースのアクセス管理（RBAC）が直感的に実装できる
   • Permission Set によって標準化された権限セットを複数アカウントに適用可能

3. セキュリティの向上

   • 短期間のセッションベースの認証
   • SAML や OIDC を使った外部 ID プロバイダとの連携可能性

移行で行ったこと

AWS Identity Center の設定をコード化

AWS Identity Centerの導入にあたり、すべての設定をTerraformコードとして管理しました。

ユーザーリストに数行追加するだけ新規メンバーの追加ができるようにしました。

locals.tf

users = [
    {
        given_name  = "Taro",
        family_name = "Yamada",
        email       = "[e-mail]"
        group       = "admin"
    },
    {
        given_name  = "Saburo",
        family_name = "Kato",
        email       = "[e-mail]"
        group       = "developer"
    },
    ...
]

ユーザー整理と権限設定の明確化

1. 既存 IAM ユーザーの棚卸し

   • 全ての IAM ユーザーをリストアップし、現在も必要かどうかを精査
   • 不要なユーザー・不明なユーザーを削除

2. 権限設定（Permission Set）の体系化

   • 必要な権限グループの洗い出し（開発者、インフラ管理者、読み取り専用など）
   • AWS マネージドポリシーの活用と、必要に応じたカスタムポリシーの作成

3. ユーザーグループの整理

   • 職能や役割に基づいたグループ設計
   • プロジェクトやプロダクト横断の権限管理の統一

はまったこと

ユーザーへの招待メール問題

AWS Identity Center 導入時に想定外だった問題がありました。Terraform でユーザーを作成した場合、招待メールが送信されないことです。

この問題は HashiCorp の AWS Provider の GitHub リポジトリでも Issue として報告されています。

https://github.com/hashicorp/terraform-provider-aws/issues/28102

解決策: API 経由で作成されたユーザー向け OTP の有効化

この問題に対する回避策として、AWS Identity Center の設定で「Send email OTP for users created from API」オプションを有効にすることで解決できました。
このオプションを有効にすると、初回ログイン時にユーザーのメールアドレスに OTP（ワンタイムパスワード）が送信されるようになります。

「Send email OTP for users created from API」オプション

ユーザーは次のような流れでログインすることになります:

ユーザー名を入力する画面

メールで受け取った検証コードを入力する画面

Terraform の制約

残念ながら、2025年5月現在、hashicorp/aws プロバイダーでは「Send email OTP for users created from API」設定を管理するための Terraform リソースが提供されていないようです。
この設定は AWS マネジメントコンソールから手動で行いました。

移行中の出来事

慎重に進めたつもりでしたが、確実に「個人用だ」と判断して削除したIAMユーザーが、実はシステムから使用されていたことに気づき、システムが停止しかけて冷や汗をかきました。

uh-oh...

このような状況を避けるため、良い子皆さんは削除する前にCloudTrailを活用して各IAMユーザーの使用状況を確認しましょう。

移行後の成果

Before（課題）	After（成果）
IAM ユーザーが乱立して管理が困難	AWS Identity Center でユーザー管理を統一。ユーザー数を削減。
ユーザー追加や権限設定が手作業で煩雑	Terraform でコード管理され、新規追加や変更作業が迅速化・明確化。
アクセスキーによる漏洩リスク	aws sso コマンドによる有効期限付きトークンで安全性向上。
マルチアカウント環境での認証切り替えが面倒	ブラウザベースの統一されたアクセスポイントから各アカウントにシームレスにアクセス。
権限管理のドキュメントが不足し属人化	Infrastructure as Codeによる共有知識化。

まとめと今後の展望

AWS Identity Center と Terraform によるコード化により、ユーザー管理の簡潔になりました。
運用コストやセキュリティ面も大幅に改善されました。

規則の整備やIaC化はAIと相性が良く、Terraformのコード生成やユーザーの権限設定をAIに任せることで、さらに効率化が図れると期待しています。

また、弊社はGoogle Workspaceを利用しているため、GoogleアカウントでのSSOにするのもいいですね。