こんにちは、DevPFチームの菅原です。
この記事では、私たちが AWS IAM Identity Center（以下、IIC）を導入した際の技術的な構成選択について、事例をご紹介します。なお、この記事は Timee Advent Calendar 2025 シリーズ1の4日目の記事です。
私たちが採用したのは、認証と認可の管理を分離する構成です。具体的には、全社的な IdP（ID プロバイダー）である Okta で「認証」を担い、AWS の権限割り当て（許可セット）に関わる「認可」管理は IIC 側で Terraform を使って行う、というハイブリッドなパターンです。 なぜこの構成を選んだのか、その背景と技術的なポイントを共有します。
私たちの前提環境
タイミーでは AWS Well-Architected フレームワークを参考にアカウントの分離を進めており、2025 年現在では 20 を超える AWS アカウントを保有しています。 各アカウントへは、Google Workspace を用いた Federated SSO（参考: How to set up federated single sign-on to AWS using Google Workspace）を経由して踏み台用の AWS アカウントにログインし、そこからスイッチロールする運用を行っていました。
この構成では、開発者ごとに踏み台アカウントへの SSO 用 IAM Role を制御し、その Role からスイッチロールできる先を絞ることで、最小権限を実現していました。 しかし、Google Workspace のユーザープロパティの設定はコーポレート IT の管轄であるため、AWS アカウントの管理部署である DevPF からは変更できません。 そのため、AWS 管理者である DevPF の承認を必ず経由させるような権限付与フローの徹底が難しいことや、ロール再設計の際のコミュニケーションコストがネックとなっていました。
また、利用者にはブラウザで Switch Role 操作を補助する Chrome Extension や、SSO 用の OSS を社内の公式手順として提供していました。しかし、以前から SSO 用 OSS が Dev Container 内で期待どおりに動作しない問題があり、オンボーディングがスムーズに進まず、改善の要望が上がっていました。
こうした前提があり、開発者体験とセキュリティ向上の両立を目的に IIC 導入に踏み切りました。
導入計画当時抱えていた課題
IIC と Okta を連携させる、おそらく最も標準的な方法は、Okta 側のユーザーと組織情報等に基づいたグループを管理し、SCIM 連携で IIC に同期させ、同期されたグループに許可セットを割り当てるような構成です。
しかし、私たちの環境ではこの標準的な構成がフィットしませんでした。理由は大きく 3 つあります。
IdP（Okta）の過渡期
全社的な ID 管理を Okta に統合する戦略がありましたが、当時はまだ整備の途中段階でした。そのため、AWS の権限管理の基準として利用できるほどの「高精度な所属組織情報」が Okta 側にはまだ揃っていませんでした。
「仮想組織」の存在
タイミーの開発組織は、人事上の組織図とは異なる「仮想組織」で活動しています。従来よりも適切な権限割り当てを実現するには、仮想組織単位での権限付与が必要です。 しかし、「仮想組織」は開発組織内だけの概念であり、かつ流動的であるため、Okta で一元管理することが困難でした。
管理主体の違いによるスピード感の懸念
Okta の管理主体はコーポレート IT 部門です。 もし Okta のグループを使って AWS 権限を管理する場合、日々の細かい権限変更のたびに他部署への申請・調整コストが発生し、開発基盤として求められるスピード感が損なわれる懸念がありました。
選択した構成：認証と認可の分離
これらの前提と課題から、私たちは IdP をソースとしたグループを利用せず、許可セットを割り当てるグループは別情報ソースを基にして管理する構成を選択しました。
- 認証（IdP） → Okta が管理
- Okta を IIC の外部 IdP として接続します。
- SCIM 連携は有効にしますが、同期されるグループ情報は利用しません。
- 入社・退職・異動に伴うユーザーのライフサイクル管理（Oktaアカウントの有効化・無効化）は、Okta 側で自動化（コーポレート IT 側の運用にオフロード）できます。
- 認可（グループ管理） → DevPF が Terraform で管理
- IIC 側で直接グループ（IdentityStore group）を作成します。「どのユーザーがどのグループに所属するか」というメンバーシップ情報も合わせて、DevPF が Terraform でコード管理します。
- その際の元情報として、開発組織内で管理している実組織・仮想組織の Google Workspace グループを参照します。
- この Google Workspace のグループを Terraform Provider から参照し、所属情報に基づいて IIC グループを作成し、許可セットを紐付けています。
この構成により、新たな全社的 ID 管理基盤である Okta を活用しつつ、開発組織の実態（仮想組織）に合わせた柔軟な認可管理を、AWS 管理者である DevPF が主体となって迅速に行えるようになりました。
まとめ
AWS IAM Identity Center の導入において、必ずしも IdP 側で「ユーザー」と「グループ」のすべてを完結させる必要はありません。組織の成熟度や、既存の認証・認可の仕組み、開発チームの働き方によっては、 IdPの責務を段階的に分担していく方が、現実的かつ運用しやすいケースもあります。
私たちの事例のように、IIC 側でグループを Terraform などで別途管理するパターンは、IdP 側の情報整備が途上であったり、開発組織特有の柔軟な権限管理が求められたりする場合に、有効な選択肢となります。特に「開発チームごとに細かくロールを分けたいが、IdP のグループ設計にすぐには反映しづらい」 といった状況では、IAC によるコードベースな管理が、スピードと可視性の両面で大きなメリットをもたらします。
一方で、IdP と IIC の両方でグループを扱う構成は、権限の責務境界が曖昧になると運用負荷やヒューマンエラーの温床にもなり得ます。そのため、「どの粒度のグループを IdP 側の標準として扱い、どこから先を IIC＋Terraform 側で柔軟に管理するのか」 をあらかじめチーム内で合意し、命名規則や運用フローをドキュメント化しておくことが重要です。
今回は最終的には、IdP による一元管理を目指しつつも、現時点の制約や開発スピードとのバランスを取りながら、現実解として IIC 側グループ管理を組み合わせるというアプローチを選択しました。本記事で紹介した考え方や設計パターンが、同様に IAM Identity Center の導入・移行で悩まれている方の判断材料や議論のたたき台になれば幸いです。
みんなでワイワイ発信活動をやってく環境いいな〜と思う方、ご興味があればぜひお話ししましょう！
