タイミーでのIAM Identity Center活用

ツール導入前の課題

タイミーでは数十の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 のユーザープロパティの設定はAWS全体の管理者とは異なる社内情報管理部門の管轄であるため、AWS 管理者であるプラットフォームエンジニアリングチームの承認を必ず経由するフローの徹底が困難であり、ロール再設計の際のコミュニケーションコストがネックとなっていました。 また、利用者にはブラウザで Switch Role 操作を補助する Chrome Extension や、SSO 用の OSS を社内の公式手順として提供していました。しかし、以前から SSO 用 OSS が Dev Container 内で期待どおりに動作しない問題がありオンボーディングがスムーズに進まず改善の要望が上がっていました。

どのような状態を目指していたか

次の状態を目指しました。

• Dev Container等でもスムーズに利用できる仕組みを提供し、開発者体験を向上させること。
• 組織間の依存を最小限にして、権限設計の改善サイクルを高速化すること。
• 適切な承認フローの徹底により、セキュリティレベルを向上させること。

改善したかった課題はどれくらい解決されたか

導入検討のきっかけとなった開発者体験については、課題が解消され、大きく向上しました。 また目標の通り認可フローが適正化され、AWS管理者チームの承認を必要とするフローが構築できました。 一方で、複数の情報ソースに依存する構成となったため、権限付与に若干のリードタイムが発生するようにもなりました。

どのような成果が得られたか

柔軟な認可管理をAWS管理者が主体となって迅速に行えるようになり、セキュリティ上望ましい状態に近づきました。 従来より簡単に手元の環境セットアップが行え、Dev Container等の環境でもスムーズに動作するようになり、開発者からの評判も上々です。

また最近は組織利用の際にIICが前提になるKiro CLIなどのサービスも出てきており、それが検討できるようになりました。

導入タイミングが全社的なIdP刷新の過渡期と重なったため、IdP（Okta）側のユーザーグループ情報をそのままAWS権限管理の正（ソース）として利用することができませんでした。そのため、IdPとは別の情報ソースを活用してグループ管理を行う仕組みを独自に構築する必要がありました。 また、 IICの「許可セット」は、従来のSwitch Roleを前提としたIAMロール設計とは概念が大きく異なります。既存のIAMロールとポリシーを単純に移行するだけでは管理が煩雑になるため、IICの仕様に合わせた権限の再設計に苦労しました。

• AWS Backupで活用できるマルチパーティー承認機能や、AWS Bedrock などIAM Identity Centerと連携するサービスも増えてきているため、あらかじめ導入しておくことでそのようなサービスを素早く試せることも増えると考えます。
• IICの許可セットは中央集権的で従来のIAM設計と異なり、既存IAMロールをそのまま許可セット化しようとすると許可セットが膨大になり管理が破綻しかねません。この設計の差を十分に理解し、権限まわりの再設計も含めた余裕を持った移行を計画するのがオススメです。

より強固なセキュリティが求められるユースケースに対応するため、Okta Identity Governanceを活用した複数人の承認を必要とする一時的なAWSアカウントアクセス許可を進めています。