🫂

TEAM for AWS IAM Identity Center 導入ガイド ──(1/6) 概要

に公開
AWS
study
idea

本ガイドは、全6部構成となっています。

☘️ はじめに

本ページは、AWS に関する個人の勉強および勉強会で使用することを目的に、AWS ドキュメントなどを参照し作成しておりますが、記載の誤り等が含まれる場合がございます。

最新の情報については、AWS 公式ドキュメントをご参照ください。
手順画像などの一部は公式ドキュメントの画像を流用しております。

TEAM

本ページでは、TEAMの概要について説明します。

📌 対象読者

  • TEAMアプリケーションの導入を検討している人、TEAMアプリケーションでできることを知りたい人

👀 Contents

1. TEAM for AWS IAM Identity Center とは

Temporary elevated access management (TEAM) for AWS IAM Identity Center とは、AWS が提供するオープンソースソリューションで、ユーザーに一時的な管理者権限を付与するための仕組みです。

TEAM architecture

※ 画像は TEAM の GitHub より引用

1.1. 公式ドキュメント

TEAMを理解する公式ドキュメントは次のとおりです。

Temporary elevated access management (TEAM)

GitHub

AWS Security Blog on 08 JUN 2023

builders.flash on 2025-05-01 | AWS Community Hero: 山口 正徳氏)

1.2. 導入のメリット

TEAMを導入する主なメリットは以下の5つです。

  1. 常時管理者権限の排除
  • 常設の管理者権限を削減し、必要な時だけ一時的に権限を付与することで、セキュリティリスクを最小化できます
  1. 承認ワークフローの実装
  • 申請・承認プロセスを通じて、権限付与の透明性と説明責任を確保できます
  1. 監査証跡の自動記録
  • すべての権限申請、承認、アクセスログが自動的に記録され、コンプライアンス要件に対応できます
  1. 柔軟なポリシー設定
  • グループ、アカウント、OU単位で細かく権限申請のルールを設定でき、組織の要件に合わせた運用が可能です
  1. 運用コストの削減
  • IAM Identity Centerと統合されているため、既存のユーザー管理基盤をそのまま活用でき、追加の認証基盤が不要です

1.3. 主なユースケース

  • 本番環境へのアクセス管理
    • 開発者やオペレーターが本番環境で作業する際に、一時的な管理者権限を申請・承認フローを通じて付与
  • 緊急対応時の権限付与
    • インシデント対応やトラブルシューティング時に、迅速かつ記録可能な形で必要な権限を付与
  • コンプライアンス対応
    • コンプライアンス規格または監査規格に対応するため、すべての特権アクセスの記録と承認証跡を保持
  • 職務分離の実現
    • 申請者と承認者を分離し、自己承認を防止することで、内部統制を強化
  • マルチアカウント環境での権限管理
    • AWS Organizationsと連携し、複数のAWSアカウントに対する一時権限を一元管理

2. 基本機能

TEAMは以下の主要な機能を提供します。

2.1. 権限申請機能

利用者（申請者）は、Webベースのアプリケーションから一時的な管理者権限を申請できます。

image09

申請時に指定可能な項目は次のようなものがあります。

  • 対象のAWSアカウント
  • 付与する権限（IAM Identity Centerの許可セット）
  • アクセス開始時刻
  • アクセス期間（時間単位）
  • 作業理由（Justification）
  • チケット番号（任意、または必須に設定可能）

申請後、設定された承認ポリシーに従って承認者に通知が送信されます。

2.2. 承認ワークフロー

承認者は申請内容を確認し、承認または拒否を判断します。

承認ワークフローの特徴は次のとおりです。

  • 承認者は申請内容の詳細（誰が、どのアカウントに、何の権限を、いつまで、なぜ必要か）を確認可能
  • 自己承認の防止: 承認者権限を持っていても、自分自身の申請は承認できない仕組み
  • 承認ポリシーは、アカウントまたはOU単位で設定可能
  • 承認が不要な設定も可能（開発環境など、リスクの低い環境向け）

2.3. 一時権限の自動付与・削除

承認された申請は、指定された開始時刻に自動的にIAM Identity Centerで権限が付与されます。

TEAMはサーバーレスアーキテクチャで構築されており、以下のAWSサービスが連携して一時権限のライフサイクルを自動管理します。
基本的に、AWS Step Functionsが権限のライフサイクル全体を管理しています。

workflow

ライフサイクルの各フェーズは次のとおりです。

  1. 承認フェーズ（Approval State Machine）

    • 承認者への通知
    • 承認期限までの待機
    • 承認/否認の処理

  2. スケジュールフェーズ（Schedule State Machine）

    • 権限開始日時までの待機
    • 申請者への通知

  3. 権限付与フェーズ（Grant State Machine）

    • CreateAccountAssignment API実行
    • 権限終了時刻までの待機

  4. 権限削除フェーズ（Revoke State Machine）

    • DeleteAccountAssignment API実行
    • 申請者への通知

  5. キャンセル/棄却フェーズ（Reject State Machine）

    • 申請のキャンセル処理
    • 関係者への通知

この自動化で手動による権限管理が不要になり、人的ミス（権限の付けっぱなしなど）を防止できます。

2.4. 通知機能

申請や承認のステータス変化を、複数のチャネルで通知できます。

サポートされる通知方法は次のとおりです。

  • Eメール通知: Amazon SESを利用した電子メール通知
  • SNS通知: Amazon SNSトピックへの発行（Emailサブスクリプションやその他の統合が可能）
  • Slack通知: Slackチャンネルへのリアルタイム通知

通知は申請者、承認者の両方に送信され、承認待ちや承認完了などのステータスをタイムリーに把握できます。

2.5. 監査とコンプライアンス

すべてのアクセス履歴と操作ログが記録され、監査に対応できます。

監査機能は次のとおりです。

  • 承認履歴の閲覧: すべての申請と承認/拒否の履歴を確認可能
  • セッションアクティビティログ: CloudTrail Lakeと統合し、一時権限でアクセスしたユーザーがどのAWSサービスにアクセスしたかを追跡
  • CSVエクスポート: 監査レポート作成のため、履歴データをCSV形式でダウンロード可能
  • 読み取り専用の監査者ロール: 監査者は履歴を閲覧できるが、設定変更や承認操作はできない

2.6. ポリシー管理

管理者は柔軟にポリシーを設定し、組織のセキュリティ要件に合わせた運用が可能です。

  • 申請者ポリシー（Eligibility Policy）

    • 誰が（ユーザーまたはグループ）
    • どのアカウント/OUに対して
    • どの許可セットを
    • 何時間まで申請可能か
    • 承認が必要かどうか

  • 承認者ポリシー（Approver Policy）

    • どのアカウント/OUに対する申請を
    • どの承認者グループが承認できるか

これらのポリシーにより、例えば「開発環境は承認不要で最大8時間」「本番環境は承認必須で最大4時間」といった柔軟な設定が可能です。

3. 運用のポイント

TEAMを効果的に運用するためのベストプラクティスと注意点を解説します。

3.1. コスト管理

TEAMアプリケーションの運用にかかる主なコストは以下のとおりです。

  • AWS Amplify: Webアプリケーションのホスティング費用（ビルド時間とデータ転送量に応じた従量課金）
  • Amazon Cognito: ユーザー認証の月間アクティブユーザー数に応じた課金
  • Amazon DynamoDB: 申請・承認データの保存（オンデマンドモードの読み書き料金）
  • AWS Step Functions: 申請処理、承認処理、権限付与・削除処理の実行時間に応じた課金
  • AWS Lambda: Webアプリケーションから呼び出されるAPIの実行回数、時間に応じた課金
  • CloudTrail Lake: セッションアクティビティログの保存（データ取り込みと保存期間に応じた課金）
    • 詳細は、「CloudTrail Lakeのコスト管理」を参照してください
    • 利用者が増加し、アクティビティの記録が増えるとこの部分のコストがネックになりそうです
  • Amazon SES: メール通知を利用する場合の送信料金
  • AWS Secret Manager: GitHub Personal Access Tokenの参照

コスト最適化のポイントは以下のとおりです。

  • CloudTrail Lake EventDataStoreの保持期間を適切に設定（365日が推奨ですが、要件に応じて調整可能）
  • 開発環境など頻繁にアクセスする環境は、承認不要で直接付与する設定を検討する（申請・承認のオーバーヘッドを削減）

3.2. モニタリング

TEAMアプリケーションの健全性と利用状況を継続的に監視することが重要です。

  1. アプリケーションの可用性
  • AWS Amplifyのビルド状態とデプロイ状況を確認
  • AWS LambdaやAWS Step Functionsのエラー率と実行時間をCloudWatch メトリクスで監視
  • DynamoDBのスロットリングエラーが発生していないか確認
  1. 利用状況の把握
  • 月間の申請件数と承認率の推移
  • 承認待ち時間の平均値（承認プロセスのボトルネック検出）
  • アカウント別、ユーザー別の申請頻度
  1. セキュリティイベントの監視
  • 拒否された申請の傾向（不正な申請の兆候）
  • 期限切れになった申請の数（承認プロセスの遅延検出）
  • キャンセルされた申請の理由

推奨する監視方法

  • CloudWatch ダッシュボードを作成し、Step Functionsのエラー、DynamoDBのメトリクス、Amplifyのビルド状況を可視化
  • TEAMの監査者機能を活用し、定期的に承認履歴とセッションアクティビティをレビュー
    image08
  • SNS通知を有効化し、管理者がリアルタイムで申請状況を把握できるようにする

3.3. セキュリティ

TEAMを安全に運用するためのセキュリティベストプラクティスです。

1. 最小権限の原則

  • 申請者ポリシーでは、必要最小限のアカウントと許可セットのみを申請可能にする
  • 本番環境へのアクセスは必ず承認必須とし、非本番環境でも適切なポリシーを設定する
  • 「AdministratorAccess」のような強力な権限は、本当に必要な場合のみ申請可能にする

2. 承認プロセスの設計

  • 本番環境の承認者は、技術とビジネスの両面から判断できる経験豊富なメンバーを選定する
  • 承認者グループは複数名で構成し、単一障害点を避ける（一人が不在でも承認できる体制）
  • 緊急時の対応手順を事前に定義し、承認者に周知しておく

3. 監査とレビュー

  • 定期的（月次または四半期ごと）に承認履歴とセッションアクティビティを監査者がレビューする
  • 異常なパターン（深夜の申請、長時間のアクセス、頻繁な申請）を検出し、必要に応じて調査する
  • CloudTrail Lakeのクエリを活用し、一時権限で実行された操作を詳細に追跡する

4. 設定の定期的な見直し

  • 申請者ポリシーと承認者ポリシーを定期的に見直し、組織の変更に合わせて更新する
  • 退職者や異動者を迅速に削除する
  • 最大申請期間の設定が適切か（長すぎないか）を定期的に確認する

5. バックアップと災害対策

  • TEAM管理アカウントのCloudFormationテンプレートとパラメータファイルをバージョン管理システムで管理する
  • DynamoDBのバックアップを有効化し、データ損失に備える
  • GitHub Personal Access Tokenは定期的にローテーションし、AWS Secrets Managerで安全に管理する

6. 通信のセキュリティ

  • TEAMアプリケーションはHTTPSで保護されており、IAM Identity Centerのフェデレーション認証を使用
  • Cognitoユーザープールは外部からの直接アクセスを防ぎ、IAM Identity CenterのSAML統合のみを許可する
  • 必要に応じて、AWS WAFをAmplifyアプリケーションに適用し、不正アクセスから保護する

💡 セキュリティインシデントが発生した場合は、TEAMアプリケーションの監査ログとCloudTrail Lakeを活用し、影響範囲を迅速に特定できます。

4. TEAM用IAM Identity Centerグループ定義例

本導入ガイドでは、以下のグループを定義した前提で説明を行います。実際の環境では用途に応じて、適切なグループを定義してください。

役割名 主な役割 グループ名
申請者 TEAM アプリケーションで一時的なアクセス権限をリクエストするユーザーグループ(開発者やオペレーターなど) TEAM-Users
承認者 TEAM アプリケーションで本番アカウントへのリクエストをレビュー・承認 / 拒否する権限を持つユーザーグループ。ただし、自身のリクエストは自身では承認できません TEAM-Approvers-Production
承認者 TEAM アプリケーションで本番アカウント以外へのリクエストをレビュー・承認 / 拒否する権限を持つユーザーグループ。ただし、自身のリクエストは自身では承認できません TEAM-Approvers-NonProduction
管理者 TEAM アプリケーションの設定管理・ユーザー管理・グループ設定などを行うユーザーグループ TEAM-Admins
監査者 TEAMアプリケーションのリクエスト履歴やアクセスログの確認・レビューを行うユーザーグループ (読み取り専用) TEAM-Auditors

📖 まとめ

本記事では、AWS IAM Identity Center向けの一時的な権限昇格管理ソリューション「TEAM（Temporary Elevated Access Management）」について、導入から運用までを包括的に解説しました。

TEAMの主な特徴

TEAMは、AWSが提供するオープンソースソリューションとして、以下の特徴を備えています。

  • ゼロスタンディング特権の実現: 常設の管理者権限を排除し、必要な時だけ一時的に権限を付与することで、セキュリティリスクを最小化
  • 承認ワークフローの統合: 申請・承認プロセスを通じて、すべての特権アクセスに説明責任と透明性を確保
  • 完全な監査証跡: すべての申請、承認、アクセスログが自動的に記録され、コンプライアンス要件に対応
  • IAM Identity Centerとのシームレスな統合: 既存のユーザー管理基盤をそのまま活用でき、追加の認証基盤が不要

導入効果

TEAMを導入することで、以下のような効果が期待できます。

  • セキュリティの向上
    • 常時付与された強力な権限が減少し、攻撃者に悪用されるリスクが低下
    • すべての特権アクセスに承認と記録が伴うため、内部不正の抑止効果
    • 権限の有効期限が自動的に管理され、権限の付けっぱなしを防止
  • コンプライアンス対応
    • SOC2、ISO27001、PCIDSSなどの監査基準に対応した特権アクセス管理の実現
    • すべてのアクセスに対する「誰が、いつ、なぜ、何をしたか」の完全な記録
    • CloudTrail Lakeとの統合により、特権アクセス時の操作を詳細に追跡可能
  • 運用効率の向上
    • Webベースのダッシュボードにより、申請から承認までをスムーズに処理
    • IAM Identity Centerとの統合により、既存のユーザー管理プロセスをそのまま活用
    • 自動化された権限付与・削除により、手動作業のミスと負荷を削減

導入時の検討ポイント

TEAMを導入する際は、以下の点を考慮してください。

  1. 組織のポリシー設計
  • どのアカウント/環境で承認を必須とするか（本番環境は必須、開発環境は任意など）
  • 承認者をどのように配置するか（本番と非本番で承認者グループを分けるなど）
  • 最大申請期間をどの程度に設定するか（セキュリティと利便性のバランス）
  1. 運用体制の整備
  • 承認者の選定と教育（承認基準、緊急時の対応手順など）
  • 監査者の配置と定期的なレビュープロセスの確立
  • ユーザーへの利用ガイドの提供と教育
  1. 既存システムとの統合
  • 既存のチケットシステムとの連携（チケット番号の必須化など）
  • Slackなどのコラボレーションツールとの通知連携
  • 監視・アラートシステムとの統合

次のステップ

TEAMを導入した後は、以下のステップで継続的に改善していくことをお勧めします。

  1. 初期運用の観察: 導入後1〜3ヶ月は、申請・承認の頻度やパターンを観察し、ポリシーが適切か確認する
  2. ユーザーフィードバックの収集: 申請者と承認者からフィードバックを集め、運用上の課題を特定する
  3. ポリシーの最適化: 観察結果に基づいて、申請者ポリシーと承認者ポリシーを調整す
  4. 監査プロセスの確立: 定期的な監査レビューのプロセスを確立し、異常なアクセスパターンを検出する

次の記事「TEAM導入ガイド(2/6) デプロイ編」では、AWSインフラ担当者向けにTEAMのデプロイ方法について詳しく解説します。

参考リソース

TEAMに関するさらに詳しい情報は、以下の公式リソースを参照してください。

GitHubで編集を提案

Discussion