【ユースケース別】TEAM for IAM Identity Centerデプロイ後の管理者向けガイド集

記事タイトルとURLをコピーする

垣見です。
IAM Identity Center運用を効率化するTEAMについて、要望パターン別に手順をご案内いたします。

はじめに

以前、AWSの公式ソリューションTemporary Elevated Access Management (TEAM)とは何か、そのメリットとできることについて解説するブログを投稿しました。

過去記事はこちら: blog.serverworks.co.jp

TEAMをデプロイしたは良いもののどのように使えばよいかわからない方へ向けて、よくあるユースケース別に操作手順をまとめました。

注意事項

基本的に以下の公式ドキュメントに準拠しています。
TEAMは現在もgithub上で改善が続いているので、バージョンが変わると挙動も変わる可能性があるのはご注意ください。

About | TEAM

また、本ブログに出てくる「ペルソナ」とは、公式で定義されたAdministrator、Requestor、Approver、Auditor(それぞれ管理ペルソナ、申請ペルソナ、承認ペルソナ、監査ペルソナとしています)を示しています。

なお、IAM Identity Centerの基本的な使い方は分かっている方を対象としたブログです。ご注意ください。

TEAMにログインしたい

IAM Identity center アクセスポータル > アプリケーション からTEAMのホームにアクセスできます。

TEAMのデプロイが済んでいるのにTEAMが出てこない場合、後述の「TEAMを使えるユーザー・グループを確認したい/増やしたい/減らしたい」をご覧ください。

TEAMで申請・承認の流れを試したい・方法が知りたい

過去記事の実際の画面を参考にお試しください。

こちらの公式シナリオも参考になるかと思います。 End-to-end Scenario | TEAM

注意事項

  • 管理ペルソナによるアプリ上での設定が済んでいないと申請・承認ペルソナは申請を行えません。後述の「承認ペルソナを設定したい」「申請ペルソナを設定したい」をご確認いただき、はじめに設定を行ってください。

申請ペルソナの設定ができていないのでAccountがひとつも出てこない

  • 自分で自分の承認を行うことはできないため、申請ペルソナ・承認ペルソナを持つ2ユーザーが必要です。(後述の自動承認設定の場合を除く。「権限の自動付与設定をしたい」参照)

承認ペルソナを設定したい

管理ペルソナでTEAMにログインします。

Approver policy > Add approvers を選択します。

Entity type (OUs/Accounts): OU単位または個別アカウント単位で権限を持たせる対象アカウントを選びます。
Ticket No: 管理に使う場合はチケットナンバーとして適当な値を入れます。(管理者設定より省略可能)
Approver Groups: 承認ペルソナとして設定したいグループを選択します。

Add approversを選択します。

OU単位の場合
個別アカウント単位の場合

設定した承認ペルソナは Approver policy 画面に一覧化されていきます。

申請ペルソナを設定したい

管理ペルソナでTEAMにログインします。

Eligibility policy > Add policy を選択します。

Entity Type (Group/User): IAM Identity Centerユーザーまたはグループ単位で申請権限を持たせる対象ユーザーを選びます。
Ticket No: 管理に使う場合はチケットナンバーとして適当な値を入れます。(管理者設定より省略可能)
Accounts/OUs: AccountsとOU単位それぞれで申請可能な対象アカウントを選びます。(以下写真は選択のわかりやすさのためrootにチェックを入れていますが、実際は必要なアカウントのみ選択してください)
Permission: 申請できる権限として、現存のIAM Identity Center許可セットを選択します。「選んだアカウントに対し、この権限を使ってログインしてよいか申請する」ことを許可することが出来ます。
Max duration: どの程度まで連続権限時間を申請できるかの最大時間を設定します。最小1時間、最大8000時間設定できるようです。
Approval required: オフにするとその申請ペルソナは承認ペルソナの承認なしで権限を得られます。いわゆる自動付与設定です。

設定を終えたらAdd eligibility policyを選択します。

グループ単位の場合
ユーザー単位の場合

設定した申請ペルソナは Eligibility policy 画面に一覧化されていきます。

権限の自動付与設定をしたい

(ここでの自動付与とは、許可を申請すると承認なしに一時的なアクセス権が付与される状態を指します。⇔承認が必要な申請)

自動付与を行う申請と承認が必要な申請の2者が混在する場合、自動付与したい申請のApproval requiredをオンにして申請ペルソナを設定してください。(上記「申請ペルソナを設定したい」参照)

全ての申請に承認が必要ない場合の手順は以下の通りです。

管理ペルソナでTEAMにログインします。
Setting の「Group settings」から現在の設定が確認できます。変更するには、右上のEditを選択します。

Approval workflowの設定をEnabledからDisabledに変更すると、全ての申請が自動許可されます。
申請があったこと自体やそのセッションで何が起こったかのログは残ります。また、Eligibility policyのApproval required設定は無視されます。申請できる対象はEligibility policyで設定した範囲のみです。

また、設定変更前に申請してpending状態になっているリクエストは、全ての申請を自動許可してもpendingのままでした。

TEAMを使えるユーザー・グループを確認したい/増やしたい/減らしたい

IAM Identity Centerのコンソール > アプリケーションの割り当て > アプリケーション > カスタマー管理 > TEAM IDC APP を選択

「割り当てられたユーザーとグループ」にあるIAM Identity Centerのグループ/ユーザーが、TEAMを使えます。
ユーザーやグループを変更するには、右上の「ユーザーとグループを割り当てる」を選択し、

割り当てたいユーザー/グループ名を検索窓に入れて選択することで割り当てられます。

※なお、検索窓に入れないと何も出てこないので注意してください。
※また、ユーザーの場合はユーザー名やメールアドレスではなく「表示名」でしか検索に出ないようになっているようです。ご注意ください。

監査ペルソナ・管理ペルソナを確認・更新したい

管理ペルソナでTEAMにログインします。
Setting の「Group settings」から現在の設定が確認できます。変更するには、右上のEditを選択します。

TEAM admin Group ならびに TEAM auditor Groupの設定を変更することが出来ます。
選択肢は、IAM Identity Center側に登録されているグループが出るようです。TEAMと連携していなくても設定が可能でしたが、実際の利用にはアプリケーションへの追加が必要なものと思われます。(本ブログ「TEAMを使えるユーザー・グループを確認したい/増やしたい/減らしたい」参照)

これまでにあった申請/承認を確認したい

自分が申請したセッション、自分が承認権限を持つアカウントの範囲の情報はMy request、My approvals、Eleveted accessから確認することが出来ます。

情報を一元的に見たい場合、以下の手順を取ります。

監査ペルソナでTEAMにログインします。

Audit > Approvals を選択します。

これまでの申請とその許可されたかどうかがわかります。
右上Downloadボタンからダウンロードも可能です。

個別のApprovalを選択してView Detailsを選択すれば、以下のような詳細を見ることが出来ます。

ちなみにこれらのTEAMリクエスト、承認等に関する情報自体はDynamoDBに保管されているようです。
(参考:https://aws-samples.github.io/iam-identity-center-team/docs/overview/architecture.html#team-dynamodb-tables)

TEAM DynamoDB Tables
The following DynamoDB tables are deployed as part of the solution:

Requests Table - Stores information about TEAM requests, approval and elevated access status
Approver Table - Stores details of Approver groups for accounts and Organizational Units

各セッションでどんなCloudTrail Eventが行われたか確認したい

監査ペルソナでTEAMにログインします。

Audit > Elevated access を選択します。
確認したいセッションを選択し、View Detailsを選択します。

先ほどと比べ、誰にどんなコメントで承認されたかも分かります。(この画面は自動承認しているのでnullになっています)
同画面のSession Logsを開くと一覧が表示されます。

なお、公式ページに記載の通り、監査ペルソナのAPIアクティビティログ確認にはCloudTrail Lakeの機能を使っています。データの保持期間や取得可能なデータはCloudTrailイベントデータストアの設定に依存します。

TEAM uses AWS CloudTrail Lake for querying, auditing and logging API activities and actions performed by a user during the period of elevated access.

CloudTrail Lake イベントデータストアの設定を「組織内のすべてのアカウントを含める: いいえ」にしていたら、別アカウントのデータは取得されなかった

通知を設定したい

Amazon SES、Slack、Amazon SNSでの通知設定が可能です。

※手順は以下の公式の通知設定方法に準拠します。
Notification configuration | TEAM

管理ペルソナでTEAMにログインします。
Setting の「Group settings」から現在の設定が確認できます。

変更するには、右上のEditを選択し、Notification settingsでそれぞれのパラメータをONにします。その後、以下手順に従い実施します。

SES

以下のようにパラメータをONにします。

SES側で権限を持つ、ソースとして使うEmailのアドレスを入れてください。(事前に用意しておく必要があります) もしTEAMデプロイアカウントとは別のアカウントでSES IDを使う場合はARNを入力してください。使わない場合は空白でよいです。

なお、公式では実運用で使う場合にはデフォルトのSESの設定であるサンドボックス環境から脱出する必要があると案内があります。以下のブログが参考になれば幸いです。

blog.serverworks.co.jp

SNS

以下のようにパラメータをONにします。

TEAMをデプロイするとSNSのトピック(TeamNotifications-main)が追加されます。

このトピックに対し、サブスクリプションとして任意のプロトコル(Emailなど)を追加して設定してください。

blog.serverworks.co.jp

Slack

以下のようにパラメータをONにします。

 

OAuth & Permissions から設定を進めます。

Bot User OAuth Tokenをコピーし、最初のパラメータに張り付けてください。

Slackアプリとして、申請した/承認権を持つ ユーザーのメールアドレスに対しリクエストや申請が許可されたなどのが通知されるようにすることができます。

TEAMの設定について知りたい

管理ペルソナでTEAMにログインします。
Setting の「Group settings」から現在の設定が確認できます。

Group Settings(「監査ペルソナ・管理ペルソナを確認・更新したい」参照)

  • TEAM admin Group:管理ペルソナに設定されたグループ
  • TEAM auditor Group:監査ペルソナに設定されたグループ

Request settings

  • Approved workflow:すべての申請に対して自動承認をonにします(「権限の自動付与設定をしたい」参照)
  • Comment:コメントを必須ではなくします
  • Ticket number:チケットナンバーを必須ではなくします
  • Maximum request duration:デフォルトの最大リクエスト期間。Eligibility policy 設定の Max durationの初期値です。Eligibility policy 自体はこれを上回れます。
  • Request expiry timeout:承認されていない申請が期限切れになるまでの時間

Notification settings(「通知を設定したい」参照)

  • Email notifications:SES通知設定
  • SNS notifications:SNS通知設定
  • Slack notifications:Slack通知設定

TEAMのデプロイ時の設定を確認したい

Amplifyコンソール上に移動し、TEAM-IDC-APPを開きます。
環境変数のページに、デプロイ時のparameters.shで設定した内容を含めた環境変数が収まっています。

TEAMのデプロイ時の設定を更新したい/TEAM アプリケーションを最新バージョンに更新したい

※基本的には以下の公式の手順に従ってください。
Update | TEAM

自分の開発環境で、TEAMをデプロイしたアカウント(IAM Identity Center委任アカウント)の名前付きプロファイルに十分な権限があることを確認します。

フォルダ内のparameters.shが最新であることを確認します。(デプロイのプロセスを参考にしてください。)
今回は更新として、parameters.shの中身のCLOUDTRAIL_AUDIT_LOGS(CloudTrail Lake eventdatastore)のARNを別のものに変更してみます。

TEAMリポジトリをクローンしてある環境で、iam-identity-center-teamディレクトリ下のdeploymentディレクトリに移動し、update.shを実行します。

cd deployment
./update.sh

たった数秒で、TEAM-IDC-APP と amplify-teamidcapp-main-XXXXXがUPDATE_COMPLETEになっています。

Amplifyコンソールに移動します。TEAM-IDC-APPのアプリ概要を見ると、前回のデプロイ時間が更新されています。

Amplifyの環境変数を見ると、CLOUDTRAIL_AUDIT_LOGSの値が変わっていました。

公式手順に書かれた指示はここまでです。
ただ、この状態だとTEAM上では今回変更したイベントデータストアがうまく挙動しませんでした。(監査ペルソナのログ確認をしたところ、ログが見つからない状態となりました)

変わったのはAmplify上の環境変数だけで、実際のアプリ上ではうまく反映されていなさそうです。

そこで、Amplify上でTEAM-IDC-APPを選択し、以下赤枠エリアをクリックしてデプロイ画面に行きます。

結果、デプロイがうまくいきました。

画面が遷移しますので「このバージョンを再デプロイ」を押してみます。 最初のデプロイよりは短時間でビルドできました。(19分24秒→12秒52秒)

TEAMを削除したい

注意事項

※基本的には以下の公式の手順に従ってください。
Uninstall | TEAM

  • 公式にも注記がある通り、削除手順内では委任された管理者設定(AWS Account Management, AWS CloudTrail, AWS IAM Identity Center)、Cloudtrail eventdatastoreは削除されません。ご注意ください。
  • 公式手順に従って削除を行うと、SNS(customsns のスタック(amplify-teamidcapp-main-12345-customsns-12345ABCDE)とそのスタック内の snsNotificationTopic(TeamNotifications-main) )が残るようです。そのため自分は後からSNSトピックTeamNotifications-mainの削除を手動でおこなっていました。
Embedded stack arn:aws:cloudformation:ap-northeast-1:123456789012:stack/amplify-teamidcapp-main-12345-customsns-XXXXXXXXXXXXX was not successfully deleted: Delete canceled. Cannot delete export NotificationTopicArn as it is in use by amplify-teamidcapp-main-12345-customstepfunctions-YYYYYYYYY, amplify-teamidcapp-main-12345-functionteamNotifications-ZZZZZZZZZ and amplify-teamidcapp-main-12345-functionteamRouter-WWWWWWWWW.

こんな風にスタックが残ります

手順

自分の開発環境で、TEAMをデプロイしたアカウント(IAM Identity Center委任アカウント)の名前付きプロファイルに十分な権限があることを確認します。

TEAMリポジトリをクローンしてある環境で、iam-identity-center-teamディレクトリ下のdeploymentディレクトリに移動し、destroy.shを実行します。

cd deployment
./destroy.sh

Cloudformationスタックが消えていることを確認します。

もしamplify-teamidcapp-main-12345-customsns-12345ABCDEのスタックが残って削除が失敗していた場合

▼以下をクリックしてください Amazon Simple Notification Serviceコンソールに移行します。

トピック > TeamNotifications-mainを削除してください。

ネストされたスタックamplify-teamidcapp-main-12345-customsns-12345ABCDEを削除します。

削除に失敗したルートスタックamplify-teamidcapp-main-12809を削除します。

AWS IAM Identity Centerコンソール >アプリケーション割り当て>アプリケーション>カスタマー管理 から、TEAM IDC APPを選択します。

この時、全てのグループとユーザーの紐づけを消しておかないとCould not delete because ApplicationProfile has Assignment associated with it.のエラーが出ました。連携ユーザー・グループを選択し、「アクセス権を削除」から削除してください。

アクションドロップダウンメニューから削除を選択します。

S3コンソールに移動します。 amplify-teamidcapp-main-xxxx-deploymentの形式のS3バケットを空にして削除します。

その他何か問題が発生した場合

githubのissueを確認してみてください。
たまに、AWSやTEAM自体の更新によって問題が生まれ、ISSUE内で対策が言及されている場合があります。

github.com

おわりに

色んなペルソナやAWSサービスが関わってきてややこしいですが、このブログが少しでもお役に立てれば幸いです。

垣見(かきみ)(執筆記事の一覧)

2023年新卒入社 エンタープライズクラウド部所属

図解するのが好き。「サバワク」のアイキャッチ作成も担当しています