必要なときだけ、安全に管理者アクセスを
AWS の Temporary Elevated Access Management (TEAM) とは ？
Author : 山口 正徳 (AWS Community Hero)
AWS Community Hero の山口です。みなさん、AWS アカウントへのアクセスをどのように管理していますか ?
AWS 環境を運用していると、「一時的に管理者権限が必要」な場面は意外と多くあります。障害対応、本番環境の緊急メンテナンス、運用タスクの実施など・・・。しかし、そのたびに恒久的な権限を付与してしまっては、セキュリティリスクが高まり、監査対応も難しくなります。そんな課題を解決するのが、AWS が提供するオープンソースソリューション「Temporary Elevated Access Management (TEAM)」です。
Temporary Elevated Access Management (TEAM) サイト
TEAM は、2023 年 6 月 8 日に AWS 公式ブログで初めて紹介されました。筆者はその直後、2023 年 6 月 13 日・14 日に米国カリフォルニア州アナハイムで開催された AWS re:Inforce 2023 にて TEAM の存在を知り、その後の参加報告会などのイベントで、セキュリティ強化に役立つソリューションとして各所で紹介してきました。
最近では、JAWS-UG 各支部の勉強会やイベントでも TEAM に関する発表を目にする機会が増えてきました。そこで今回、改めてこの場で皆さんに TEAM をご紹介したいと思います。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
このクラウドレシピ (ハンズオン記事) を無料でお試しいただけます »
毎月提供されるクラウドレシピのアップデート情報とともに、クレジットコードを受け取ることができます。
TEAM リリースの背景
「管理者権限を恒久的に付与するのは避けたい。でも、柔軟に昇格できる仕組みがない」というニーズに対し、最小権限の原則(PoLP) を実現するベストプラクティスの 1 つとして提供されたものです。
TEAM のリリースは、単なる便利ツールの提供ではなく、「クラウドセキュリティの標準を引き上げる」という明確なメッセージでもあります。
- セキュリティリスクへの対応強化
- 求められる透明性と説明責任
- そして DevSecOps の浸透による「開発者主導のセキュリティ」
これらの時代的な潮流に対応するために、TEAM のようなアプローチが必要不可欠になりつつあります。
TEAM が活躍するシーン
では、どのようなシチュエーションで TEAM は特に力を発揮するのでしょうか？実際の現場でありがちな状況にフォーカスして解説します。
| シチュエーション | TEAM の活用 | |
| 1. 本番環境でのトラブルシューティング | 本番環境で問題が発生。開発者が Amazon S3 バケットや Amazon RDS のデータを確認・修正する必要があるが、常時管理者権限は持っていない。 | 開発者が TEAM 経由で「一時的な管理者アクセス」をリクエストし、承認者が承認すれば、時間制限付きで必要なアクセスのみが付与される。アクセス終了後は自動でロールから削除され、監査ログにも記録が残る。 リスクを抑えてスピーディな対応が可能となり、アクセスログで説明責任を果たせる。 |
| 2. 定期メンテナンス作業 | 月 1 回の AWS Lambda 関数の更新作業、Amazon ECS タスク定義の更新など、限定的な操作が必要な運用業務。 | あらかじめ定義された「メンテナンス作業用グループ」への一時参加をリクエスト。特定の時間枠でのみ昇格アクセスを得て作業し、その後は自動的に権限が解除される。 スケジュールベースで計画的な権限付与を行うことができ、作業者に恒久的な Admin 権限を与える必要がなくなる。 |
| 3. 外部ベンダーや一時的な委託作業員へのアクセス提供 | 社外のセキュリティベンダーや SIer が特定の AWS アカウントに一時的な作業アクセスを必要としている。 | 一時的に必要な IAM Identity Center グループにアクセスを許可し、アクセス期間や対象範囲を厳密に制限可能。作業完了後に自動でアクセスを無効化。 「いつの間にか残っている外部アクセス」を防止し、内部統制・監査にも強い対応が可能となる。 |
TEAM は、単なるアクセス制御ツールではなく、「日常業務とセキュリティ強化の架け橋」となります。さまざまなシチュエーションにおいて “必要なアクセスを、必要なときだけ、正しく記録して与える” という運用を、無理なく組織に定着させる仕組みそのものです。
TEAM の全体構成をざっくり理解する
TEAM は、AWS が提供するマネージドサービスとサーバーレスアーキテクチャをベースに構築されています。AWS Lambda、Amazon API Gateway、Amazon DynamoDB などを組み合わせることで、インフラの運用コストや保守負荷を最小限に抑えた構成となっています。
主な構成コンポーネント
コンポーネント |
役割 |
IAM Identity Center |
AWS アカウントへの実際の権限付与 |
Amazon Cognito |
TEAM Web アプリケーションのユーザー認証 |
Amazon DynamoDB |
リクエストやセッションのメタデータ保存 |
Amazon API Gateway + AWS Lambda |
バックエンド API 処理 (リクエスト管理、承認処理など) |
Amazon EventBridge + AWS Lambda |
スケジュール管理 (期限切れアクセスの自動削除など) |
Amazon S3 + Amazon CloudFront |
TEAM アプリケーション静的Webページ (申請画面・管理画面) の配信 |
AWS Step Functions |
リクエストの通知、承認など一連の処理ワークフロー |
TEAM のデプロイ方法
TEAM はオープンソースソリューションのため、機能の追加や修正に伴いデプロイ手順も更新されます。最新の詳細な手順は TEAM公 式のデプロイガイドをご参照ください。本項では、TEAM を利用するための前提条件などの情報を記載します。
TEAM をデプロイするための前提条件：
AWS Organization
セットアップ済みの IAM Identity Center
TEAM アプリケーション専用 AWS アカウント
AWS Cloudtrail Lake イベント データストア
Organization 管理アカウントへの管理権限をもつ IAM ユーザー
- AWS CLI を実行するための名前付きプロファイルが必要
TEAM アプリケーション専用アカウントへの管理権限をもつ IAM ユーザー
- AWS CLI を実行するための名前付きプロファイルが必要
AWS CLI、git-remote-codecommit、jq を実行できる環境
- AWS CloudShell を利用可能
補足：TEAM をデプロイガイドの注意点
TEAM 公式のデプロイガイドではデプロイ用のスクリプトを実行は、どの AWS アカウントで行うべきかについては言及されていません。Organization 管理アカウントへの管理権限をもつ IAM ユーザー、TEAM アプリケーション専用アカウントへの管理権限をもつ IAM ユーザーそれぞれの名前付きプロファイルがセットアップされた環境であればどの AWS アカウントでも実行可能です。
TEAM 利用の流れ (ワークフロー)
TEAM を利用して必要な人に対して必要な AWS アカウントへ一時的な権限を付与する流れと、実際の操作に沿ってステップごとに解説していきます。
まず、各ステップで登場する TEAM のユーザーの役割を記載します。
役割名 |
主な役割・目的 |
申請者 (Requester) |
一時的なアクセス権限をリクエストするユーザー(開発者やオペレーターなど) |
承認者 (Approver) |
リクエストをレビュー・承認 / 拒否する権限を持つユーザー |
管理者 (Admin) |
TEAM アプリケーションの設定管理・ユーザー管理・グループ設定などを行う |
監査者 (Auditor) |
リクエスト履歴やアクセスログの確認・レビューを行うユーザー (読み取り専用) |
TEAM を利用するユーザーと役割は、IAM Identity Center のグループを使って制御します。グループ名は任意の名前を利用可能です。
グループ名（例） |
対応する役割 |
補足 |
TEAM-Users |
Requester |
User とその他の役割は重複して設定可能。ただし、自身のリクエストは自身では承認できない。 |
TEAM-Approvers |
Approver |
Approvers グループは複数作成し、アカウントごとに承認者を分ける運用を推奨。 |
TEAM-Admin |
Admin |
|
TEAM-Auditors |
Auditor |
|
ステップ １ : IAM Identity Center のポータルにログインする (申請者)
一時的にアクセス権限を取得したいユーザー (申請者) は、IAM Identity Center のポータルにログインします。
クリックすると拡大します
ステップ 2 : TEAM アプリケーションへアクセスする (申請者)
TEAM アプリケーションをデプロイすると、IAM Identity Center のカスタムアプリケーションとして登録されますので IAM Identity Center のポータルから TEAM アプリケーションへアクセスします。
クリックすると拡大します
ステップ ３ :アクセスリクエストの作成 (申請者)
ユーザーは、一時的にアクセス権限を取得したい AWS アカウントへのアクセスリクエストを作成します。
クリックすると拡大します
ステップ 4 : リクエストされたアクセスを承認する (承認者)
ユーザーがリクエストを送信すると、承認者グループにメールなどで通知が送信されます。承認者は TEAM アプリケーションにログインして、昇格されたアクセス要求を承認または拒否します。
クリックすると拡大します
ステップ ５ : アクセスの有効化 (TEAM の内部処理)
承認が通ると、TEAM アプリケーションはリクエストがアクティブであることをリクエスト者に通知し、申請者は IAM Identity Center 経由で一時的なアクセス権限を得ることができます。
ステップ 6 :アクセスの使用 (利用者)
TEAM アプリケーションは、申請者の IAM Identity Center ユーザー ID とリクエスト内の権限セットおよびアカウントをリンクするため、IAM Identity Center ポータルより申請した AWS アカウントがリストに表示されます。
申請者はリクエストした権限で対処の AWS アカウントに接続することができます。
クリックすると拡大します
ステップ ７ : アクセスの自動終了 (または手動終了)
承認されたアクセスは、リクエストされた期間が経過するか、申請者または承認者が TEAM アプリケーションで明示的に取り消した時点で終了します。
承認されたアクセスが終了すると TEAM アプリケーションは、申請者の IAM Identity Center ユーザー ID とリクエスト内の権限セットおよびアカウントの紐付けを解除します。(承認されたアクセスが利用可能な期間中に呼び出されたセッションは IAM Identity Center の権限セットに設定されたセッション期間が終了するまで有効になる可能性があります)
ステップ ８ : セッションアクティビティの記録と確認 (監査者、申請者)
セッションの操作内容 (CloudTrail ログなど) や、TEAM 上のセッション情報はすべて記録され、TEAM アプリケーションから確認できます。
クリックすると拡大します
まとめ
権限昇格の運用を仕組み化したい方にとって、TEAM は実用性の高い選択肢です。承認フローや自動失効など、現場で求められる機能が揃っており、セキュリティとスピードを両立できます。検証環境から気軽に導入できます。
IAM ロールの恒久付与に不安を感じている方は、TEAM の導入を検討してみてください。必要なときだけ、安全に昇格できる仕組みがあることで、開発・運用チーム双方の安心感と監査対応力が高まります。まずは動かして学ぶのがおすすめです。
本記事の内容が、アクセス管理や権限運用に潜むリスクを見直すきっかけとなり、セキュリティ強化に向けた一歩につながれば幸いです。
筆者プロフィール
山口 正徳
フォージビジョン株式会社 / AWS Community Hero
大手 SIer 、フリーランスを経て、クラウドインテグレーションを手掛けるフォージビジョン株式会社にインフラエンジニアとして入社。現在、同社で AWS 事業部長を務める。
JAWS DAYS 2014 への参加をきっかけに AWS に興味を持ち、2016 年から本格的に AWS を使いはじめる。2018 年から JAWS-UG 千葉支部の運営に携わるように。現在「APN Ambassador / 2020 APN AWS Top Engineers」であり、全世界共通の認定プログラムである AWS 公式の「APN Ambassador」のひとりでもある。
AWS を無料でお試しいただけます