はじめに
こんにちは！ Ｓｋｙの社内システムを開発・運用する、Ｓｋｙスタイル部でSREエンジニアをしています。
社内システムの運用にはAmazon Web Services（以下、AWS）を利用しているのですが、AWSアカウントへのアクセスをどのように管理するかは重要なテーマとなっています。
今日は、Temporary Elevated Access Management (以下TEAM) というAWSのソリューションを導入してみた、という話をしたいと思います。
背景・目的
これまで社内システムは内製開発が主体でしたが、開発規模の拡大に伴い外部委託の取り組みも進めています。
外部業者様にＳｋｙ社外ネットワークから社内ネットワークの開発環境にアクセスいただくにあたり、AWS Systems Manager Fleet Manager経由で踏み台環境（EC2）を利用いただく形式をとりました。
その際、AWSマネージメントコンソールへのアクセス権付与の方法を思案していたところ、AWSのソリューションアーキテクトの方から「TEAM」をご紹介いただき、今回導入に至りました。
TEAMとは
AWSが提供するアクセス管理のソリューションです。AWS IAM Identity Center（以下、IdC）と統合し、複数のAWSアカウントにまたがってアクセス権を管理できます。
TEAMの大きな特徴として、「AWSアカウントの権限を常時付与するのではなく、必要な時に一時的に昇格させることができる」という点が挙げられます。
よくある権限付与の例として、IdCで事前に作成した許可セットを割り当てたり、管理者グループに加えたりなどが考えられると思いますが、どちらにおいても一度付与した権限は残り続けてしまい、作業後に不要な権限が付与されたままとなってしまうリスクがあります。
TEAMでは付与する権限の有効期限を設定することができ、有効期限を迎えると自動で剥奪されます。緊急対応やメンテナンス対応の開始時に有効にした後、作業が完了した際に権限を外し忘れるリスクを減らすことができます。
TEAMの有無によるアクセス権付与の流れのイメージ図
TEAMの構成要素
ここからはTEAMの構築についての話です。
公式のドキュメントに構築の手順が用意されていますが、実環境に応じて調整する部分もあるので、実際に構築した記録を残そうと思います。
まず、登場人物を整理しましょう。今回登場するAWSアカウントは3種類あります。
- AWS Organization管理アカウント
- TEAM構築先アカウント
- アクセス許可先アカウント
このとき、Organization管理アカウントからTEAM構築先アカウントへ、IdCの管理を委任しておく必要があります。
アクセス許可先アカウントは実際にユーザーが操作するアカウントで、アカウントの運用パターンによってはTEAM構築先アカウントと同一になることもあると思います。
ざっくりした位置関係のイメージは以下のようになります。
TEAM構築時のAWSアカウント構成のイメージ図
また、TEAMはAWSのサーバーレスサービスを使って構築され、デプロイが完了すると以下公式ドキュメントに記載の画像のような構成ができあがります。
画像には記載がないですが、AWS Amplify（以下、Amplify）やCloudFormation、S3といったリソースも作成されるのであらかじめ認識しておきましょう。
TEAMの構築手順・ポイント
実際の手順は公式ドキュメントに従って進めていくことになるので、構築の詳細については下記を参照してください。
ここでは構築時に詰まったポイントをいくつか紹介します。
CodeCommitについて
Amplifyをデプロイする際にソースコードを参照できる必要があります。
公式のデフォルト設定ではCodeCommitを使用する手順が記載されていますが、2024年7月25日をもってCodeCommitは新規顧客の受け入れを停止しています。
CodeCommitが使えない場合は、GitHubなどの外部のソースプロバイダーを使うことになります。しかし、当初はGitHubを使用する方法で検討していたのですが、私たちのGitHub EnterpriseではIP制限を設けており、Amplifyから通信を通す手段がなかったため、今回はCodeCommitで構築しました。
（2025年9月時点でAmplifyは固定のIPアドレス範囲を公開しておらず、IPアドレスの許可リストに設定できませんでした）
TEAMのカスタムドメイン
デフォルトではAmplifyによって自動生成されるドメインが割り当てられますが、独自のカスタムドメインを設定することも可能です。
デプロイする前に、以下の手順に従ってドメイン名をパラメータに設定しておく必要があります。
（すでにデプロイ済みの場合は、再デプロイが必要です）
デプロイ完了後に、Amplifyの設定画面からドメイン検証の設定やSSL証明書の登録を行なってください。
Amplifyのスクリーンショット画像
なおドメインの設定自体はAmplifyの設定画面からでも可能ですが、同時にAmazon Cognitoの設定変更も行う必要になるため、 コンソールからではなくデプロイスクリプトで設定することをお勧めします。
TEAMのアクセス制御
TEAMで作成されるAmplifyはデフォルトで外部からアクセス可能な状態になっています。 （とはいえIdCと連携した認証が組み込まれているため、誰でもTEAMにログインできるわけではありません）
アクセス制御としてBasic認証や、ファイアウォール（WAF）を利用することができ、今回はWAFによるIP制限を設定しました。
Amplifyの設定画面から「ファイアウォール」メニューを選択し、既存のWAFを紐づける、もしくはAmplifyの画面上でルールを入力することで設定できます。
Amplifyのスクリーンショット画像
TEAMの運用準備
実際にTEAMを構築した後に、実運用を始めるにあたって必要な準備作業になります。
承認者ポリシーの設定
TEAMでは「Approval policy」という名前で、承認操作を行うユーザーを設定することができます。
TEAMのスクリーンショット画像
承認者はアカウント単位で設定する形で、ユーザーとグループのどちらかを指定できるので、開発環境と本番環境で承認者（グループ）を分けて定義することも可能です。
なおあくまで承認者（グループ）を設定できるのはアカウント単位になります。
私たちの運用パターンだと作業内容によって承認先を分けたいシーンがあったのですが、現状の機能ではそこまで細かな制御はできないようです。
1つのアカウントに対して承認ユーザー（グループ）は複数設定できるので、後述する通知の仕組みをカスタマイズして、申請ユーザーに応じてLambda等で通知先を振り分けるなどひと工夫を設けています。
申請ポリシーの設定
TEAMでは「Eligibility policy」という名前で、権限付与のリクエストを行うことのできるユーザーや、対象となるアカウント・許可セットを設定することができます。
申請するユーザーは事前に設定されたポリシー内でしか申請できないので、意図しない範囲への申請が飛んでくることはありません。
例えば以下の例だと、
TEAMのスクリーンショット画像
- 特定のグループに対し
- 3つのアカウントにおいて
- 2種類の権限
が申請可能になります。
例えばここに本番環境のアカウントが含まれていない場合、そもそも申請ができないので安心して運用することができますね。
このとき設定できる権限（許可セット）は事前に作成しておく必要があります。事前定義済みの許可セットを利用することもできますし、カスタムポリシーを用いて独自の許可セットを作成することもできます。
通知の設定
実際にアクセス権がリクエストされると、作成したポリシーに対応する承認者へ通知を飛ばすことができます。
TEAMが提供する通知の方法は以下の3つです。
- Amazon SES
- Amazon SNS
- Slack
メールは飛んできても気づきにくい、Slackは導入していない、ということで、今回はSNSを利用して業務で使用するチャットツールへ連携する仕組みを作成しました。
TEAMの設定画面でSNSを有効にすると自動でSNSトピックが作成されるので、Lambda関数へ連携してチャットメッセージをカスタマイズしています。
TEAMのスクリーンショット画像
TEAMの運用デモ
実際にTEAMでアクセス権を申請し、マネジメントコンソールにアクセスする部分を紹介したいと思います。
1. アクセス権の申請
まず、申請者がアクセス権をリクエストする画面です。
IdCのアクセスポータルから「アプリケーション」タブを開き、「TEAM」をクリックします。
AWS アクセスポータルのスクリーンショット画像
TEAMのホーム画面に表示されているボタンから申請をリクエストします。
フォームからアクセスしたいアカウント・許可セットを選択し、利用したい時間と申請理由も入力します。
TEAMのスクリーンショット画像
2. アクセス権の承認
リクエストが送信されると、承認者側の画面にリクエスト内容が表示されます。
内容に問題なければ「Approve」で承認します。
TEAMのスクリーンショット画像
3. 承認された権限を使ってアクセスする
承認されると、IdCのアクセスポータルに申請したアカウント・許可セットが表示されます。
これを選択することで、承認された権限を使ってアクセスすることができます。
TAWS アクセスポータルのスクリーンショット画像
実際に運用してみての感想
現在は以下のように、事前にプロジェクトマネージャーに承認権限を与え、利用申請時はプロジェクトマネージャーが承認できるような仕組みにしています。
TEAMによるアクセス権付与の運用イメージ図
管理者の視点としては、一時的に権限をつけ外しする操作が自動化されており、とても快適に運用を行うことができていると感じています。事前に定義したアクセス範囲を超えた申請を行うことはできないため安心感も大きいです。
また今回、実際に日々承認作業を行なっている方からも感想を伺いました。
-
SREチームへの依頼なしで、チーム内でアクセスの承認依頼もらって、承認できるのはかなり楽です！承認もすぐできるので、特に時間がかからず助かってます！
-
セキュリティを担保するために承認は必須となりますが、この承認方式によって、最低限の作業でスピード感をもって対応することができるので大変助かっております。 TEAMがなければ、作業のたびに手動で権限を管理する手間がかかり、委託作業者、プロジェクトマネージャー、SREチームの三者の効率が悪くなっていたと予想されます。 この承認方式で踏み台を使う仕組みが導入されて、本当に良かったと感じております。
-
チャットツールに通知がくるのですぐに気づくことができます。申請から作業開始までのラグがほぼないので『申請したけど権限付与まで時間がかかり作業時間があまり取れなかった』みたいなことが起こらなくて良いです。
このようにとても好評をいただいており、改めてTEAMを導入して良かったと感じました。
今後のTEAM活用について
今回外部業者様のアクセスに関わる部分で導入しましたが、今後は、メンテナンス作業や本番運用作業などのシーンでも活用できないか検討したいと考えています。
まとめ
TEAMがどのようなソリューションか、どのようにTEAMを運用しているかをご紹介しました。 最小権限の原則（Principle of Least Privilege: PoLP）を実現するためのソリューションとして、今後もTEAMを活用していきたいと考えています。
