図解の垣見です。
「IAM Identity Centerの権限をいちいち付けたり戻したり…もう面倒！」
そんなあなたに「TEAM」ソリューションの良さをご紹介します。
認可に関する【セキュリティ強化＆運用効率化】のお話です。
想定読者
このブログでは、「TEAM」というソリューションとは何か、何ができてどこがすごいのか、を解説します。
- TEAMで何ができるのかまったく～そこまで知らない人
- TEAMについて短時間でわかりやすい使用イメージを持ちたい人
- TEAMの訴求ポイントが知りたい人
IAM Identity Centerを使っている人に刺さるソリューションのはずです。
- IAM Identity Centerを使っており、権限のつけ外し運用を行っていて、それを自動化・効率化したい人
- IAM Identity Centerを使っており、強力な権限をつけっぱなしにしていることでセキュリティ的に不安がある人
TEAMとは
「TEAM」(Temporary elevated access management)とは、IAM Identity Center（以下IdC）アクセスポータルからアカウントへの一時的なアクセス許可を与えるAWS提供のパッケージソリューションです。
About | TEAM
TEAMをデプロイ（方法は後述）後、IdCの”アプリケーション”に連携し、IdC上のユーザーかグループに対して承認・申請権限を割り振ることで、そのメンバーがTEAMを使えるようになります。
TEAMの基本動作
基本的には、「申請者が承認者にアカウント使用を申請し、承認or否認することで制限時間ありの権限が与えられる」という流れになります。
概要
基本の動きの4ステップです。
①初期状態→②申請→③承認→④最終状態→⑤時間経過 or 途中権限取り消し→①初期状態…と続きます。
①初期状態
②申請
③承認
④最終状態
実際の画面
上記の流れを実際の画面で見るとこんな感じです。
クリックで展開・折り畳みします
①初期状態
IAM Identity centerにログインします。
この時点では申請者はどのアカウントへもアクセスできません。
②申請
IAM Identity centerホーム > アプリケーション からTEAMのホームにアクセスできます。
左ペインにRequests, Approvals, Elevated accessとあるので、Create requestを選択します。
申請内容を入力していきます。
申請できたか確認しましょう。
出来ていそうですね！
③承認
承認者としてIdCにログインします。
Approve requestsを見ると、
先ほどのリクエストが届いているようです。承認しましょう。
ActionsからApproveを選びます。承認/否認時コメントも残せます。
承認したことで、My ApprovalsとActive Accessに1件増えました。
④最終状態
改めて申請者側の画面に戻ってみると、先ほどpendingだったMy requestsが「approved」になっています。
※rejectされると「rejected」になります。画像ではもう一つの申請（AdministratorAccess権限の申請）はrejectされていますね。
アクセスできるか確認してみましょう。IAM Identity centerホームに戻ります。
先ほどは何もなかったAccountsにAcceptされたアカウントが増え、ReadOnlyAccessの許可セットが選べるようになっています。
IdCホームの対象アカウントのReadOnlyAccess をクリックすると、アカウントにログインできます
こんな感じで、一時的なアクセスを付与できるわけです。
さらにこの後、権限をはく奪することもできます。
さらにクリックで展開・折り畳みします
⑤権限のはく奪
承認者がActive accessからRevokeすると、ログはActive accessから消えてEnded accessへ移ります。
まだ申請した1時間を過ぎていませんでしたが、IAM Identity center画面から選択肢が消えます。もうアクセスできません。
申請者がTEAMの画面を見ると、Elevated access > Ended accessから、自分のアクセスがrevokedされたことがわかります
このようにすることで、不明なセッションの緊急停止をさせられます。
TEAMのポイント
それで、このTEAMは結局何が良いんでしょうか？以下の4点にわけて、お客様に喜ばれる機能をご紹介します。
- 権限の自動削除
- 承認者と管理者が別
- セッションごとのアプリ上での監査
- 「承認者の承認必要なし」での自動権限付与
①権限の自動削除
言うまでもないですが、一番のポイントは、申請で通った期間を過ぎたら権限が自動削除される点です。
強力な作業権限はつけっぱなしにすることはリスクがあります。
しかし、都度手動で削除するのは工数がかかるうえ、作業ミスが発生しやすいです。
そこを自動化してくれるのが一番のポイントです。
しかも、申請時にスタートを「未来の日付」に設定することもできるので、数日前から予定されている作業は事前に申請しておけば当日は何もしなくてよいことになります。これはすごい。
②承認者と管理者が別
2つめのポイントは承認者と管理者が別である点です。
管理者と承認者って違うの？という声が聞こえました。はい、TEAMでは違います。
前提として、TEAMでは4つのペルソナ（利用にあたっての想定役割）が存在します。
申請者と承認者は先ほども出てきましたね。数が多い一般利用者と考えてください。
監査人と管理者はデプロイ時に対象のIdCグループ名を設定して作成します。
管理者とは、「誰がどのアカウントに承認・申請できるのか」のペルソナ自体を管理するメンバーです。（監査人は後述）
さて、ポイントの承認者と管理者が別である点に戻って注目しましょう。
承認者は、アカウントごと分けて複数設定することが出来ます。
1つの管理者/管理チームがすべてのアカウントのリアルタイム状況を把握すると、いちいち責任者に確認をとったり削除時の連絡をしたりと負担も工数も余分に発生します。
一度管理者が「この人/グループがこのアカウントの承認担当」と決めたら後はそちらに任せることで、オペミスの減少・負担の軽減につながります。
また「ピア承認」といって、承認者と申請者が同じチームに所属することもできます。
こうすることで、作業状況をよく知るチーム内の誰かが承認すればよいので、さらに負担が軽減します。
※自分で自分のリクエストを承認することはできません
③セッションごとのアプリ上での監査
先ほどのペルソナに出てきた監査人を割り当てられたグループメンバーは、TEAMアプリ上からCloudtrailログを確認し、セッション(申請)ごとに何があったか確認できます。
監査のために個別/管理アカウントログインがいらない点、セッションごと、そのチームメンバーがその割り当て期間にやったことがわかるというのはかなり管理的メリットを感じる方が多いのではないでしょうか？（CloudTrailのログをぽちぽち絞り込んで見るのって地味に大変ですよね…）
④「承認者の承認必要なし」での自動権限付与
さらに自動化の話です。
管理者の設定次第で、なんと「承認者の承認は必要なし」で一次的なアクセス権限付与を行うこともできてしまうのです。すなわち承認側の自動化。
申請の精査をするほどでもないと判断した権限の場合、こちらの設定をお勧めします。
「その場合、わざわざTEAMで申請しなくても従来のIdCでつけっぱなしにしておけばいいんじゃ？」
そう思った貴方、鋭い。
こちら、「承認者必要なし」ではなく「承認者の承認必要なし」です。つまり、承認者権限を持つ人は「何の申請がされたか」「今アクティブなセッションは何か」が確認できます。
また、先述の監査人によるセッション単位のログ確認も適用されるというメリットもあります。
※ある人に対し複数の申請権限があった場合、承認が必要な申請が優先されます。
料金
さてさて、ここまで読んでいる方はもうTEAMを試したくてしょうがなくなってきているのではないでしょうか？
そこで気になるのは料金ですよね。
結論から言うと、「使用量によって変わる」となってしまいます。（すみません…）（AWSそうなりがち問題）
無料とはいかないのできちんと実環境での検討やテストが必要ですが、「今まで行っていた運用作業分の工数をTEAMに任せられる」というのはやはり強みです。
導入検討時は、普段どれだけIdC部分に工数を割いていたかを可視化して根拠にしてみるのもいいかもしれません。
公式に書いてある構成図は以下の通りです。
サーバーレスでアプリケーションが構築されているのがわかります。これらはCodeCommitとAmplify上で作られるようです。
これらのサービス自体 "は" そこまでお金はかかりません。お試しで使うだけなら無料利用枠に収まってほとんど気にならない程度かと思います。
ただ、ここに書かれていないリソースとして「CloudTrail Lake」があり、こちらはその他リソースと比べて利用料が上がりやすいです。TEAMを使うためにはこれを有効化して連携する必要があります。
アクセス期間中にユーザーが実行した API アクティビティとアクションのクエリ、監査、ログ記録のために使われているそうですが、例によって「使えば使うほど課金」なので予測しにくいです。
（参考までに、昇格された1人のユーザーでインスタンスの立ち上げ～終了を10回程度実施したところ、4ドル程度の利用料が発生しました。）
メンバーの操作量（＝データ使用量）で料金が変動しますので、初めは人のいないテスト環境で確認したり、こまめに料金を監視したりすることをお勧めします。
ちなみに公式のCloudTrail Lakeの料金（1 年間の延長可能な保持料金）としてはこのように書かれています。
- CloudTrail の管理およびデータイベント: 0.75 USD/GB
- その他の AWS および AWS 以外の監査可能なデータソース**: 0.50 USD/GB
参考：
TEAMの構築方法
試したい！IdC自動化を進めたい！という方向けに、構築方法の説明です。
以下の公式ガイドに従うことでデプロイできます。 aws-samples.github.io
- githubに公開されており、CLI経由でデプロイする形となります
- IAM Identity CenterとCloudTrailLakeが既に存在する前提での手順ですので、事前に確認と必要があれば構築をお願いします（※CloudTrail Lakeはもともと手順内で構築が可能でしたが、最近発生したバグの修正のために暫定「既存のデータイベントを選ぶ」という手順に変更となりました。インターネット上にある解説系ブログとは手順が異なる恐れがありますので、公式に準拠してください）
- 手順内でIAM Identity Centerの委任手続きなどがあります。TEAMをデプロイするアカウントにIAM Identity Centerが委任されて良いことを確認してください（IAM Identity Centerアカウントにデプロイするのが楽かと思います）
その他のおまけ情報
ここまででTEAMの紹介は終わりです。
この章ではおまけとして、ぜんぜん上の流れには盛込めなかったけど地味に気になる？かもしれない情報を載せています。
具体的には通知と最大連続セッション時間です。
通知
Email、TEAMデプロイアカウントのSNS、Slack連携が可能です。
（管理者がTEAMアプリ上で一括設定する必要があります）
Slack通知では、Slackアプリとして、承認者ユーザーのメールアドレスに対しリクエストが通知されるようにすることができます。
SNS通知では、Amazon SNS上で設定したメールアドレスに対し、通知内容と「誰が承認権限を持っているか」が通知されます。
それがSlackに通知されているか？と言った細かい事項も通知されます。
スクショ右のように、メール以外に連携することもできます。
最大連続セッション時間
「このアカウントにReadOnlyで1時間ちょうだい！」の「1時間」と選べる部分の上限のことです。作業者の方は特にセッション切れ問題が気になりますよね。
管理者は権限付与期間を、事前に1～8000時間（約333日）の範囲でグループごとに設定可能です。思ったより長かった。
とはいえ、そんなに長く設定させてしまうとTEAMの本来の目的から逸れてしまうので、基本的には最大12時間など必要最小限にしておいて都度承認することを推奨します。
終わりに
TEAM、有効活用できればかなり便利かと思います。
ブログが皆様のお役に立てれば幸いです。
