こんにちは、AWS サポート課（旧テクニカルサポート課）の坂本（@t_sakam）です。今回も、前回に続いて AWS Systems Manager (SSM) の新しいエクスペリエンス（= 統合コンソール）についてのブログです。
はじめに
前回のブログのあと、2025/4/29 に新しいエクスペリエンスを有効化した環境で利用が可能な「ジャストインタイムノードアクセス (Just-in-Time Node Access / JITNA)」という要注目の機能が発表されました。そのため、AWS Systems Manager の新しいエクスペリエンスシリーズ第 2 回の今回は、予定を変更し「ジャストインタイムノードアクセス」機能を前回の Organizations 環境を利用して試してみたいと思います！
- ジャストインタイムノードアクセス (JITNA) とは？
- 今回の環境について
- RAM の信頼されたアクセスを有効化する
- ジャストインタイムノードアクセス (JITNA) を有効化する
- 承認 / 拒否ポリシーについて
- 登場人物
- セッションマネージャーで接続する
- まとめ
ジャストインタイムノードアクセス (JITNA) とは？
ジャストインタイムノードアクセス（JITNA）は、運用者が EC2 などのノードにアクセスする際に、承認フローを通じて一時的なアクセス権を得る仕組みです。接続には SSM のセッションマネージャーを使用します。
これにより、ノードに対する長期にわたる権限を削除し、運用効率を維持することができます。お客様は、AWS、ハイブリッド、マルチクラウドの環境で稼働している AWS Systems Manager 管理下のノードに対して、オペレーターが Session Manager を使用してリモート接続する前にアクセスをリクエストするように設定することで、ノードに対するゼロスタンディング権限を作成できます。
引用元: AWS Systems Manager でジャストインタイムのノードアクセスをリリース
ゼロスタンディング権限 (Zero Standing Privileges)とは？
上記の AWS の発表でも触れられている「ゼロスタンディング権限」とは、ユーザーに常時のアクセス権限（Standing Privileges）を与えず、必要なときにだけ一時的なアクセスを許可するセキュリティモデル（または、その権限自体）のことです。
JITNA の機能を利用することで、上記や以下の AWS のドキュメントにも記載の通り、StartSession 権限がないユーザーへの、一時的なアクセス権限（ゼロスタンディング権限）を作成することができます。
ユーザーがノードに接続しようとするときにジャストインタイムノードアクセスのみが使用されるようにするには、IAM ポリシーから StartSession などの Session Manager アクションの権限を削除する必要があります。
引用（翻訳）元: Setting up just-in-time access with Systems Manager
今回の環境について
それでは、実際に設定をおこなっていきます。今回の内容は、前回の環境を利用します。そのため、前回までの設定は全て終わっているという状況からの設定になります。また、今回は Dev アカウントに EC2 を起動済みで Systems Manager のマネージドノードとしても登録済みである環境を想定しています。
今回の設定作業により、その EC2 接続時に手動承認プロセスが追加されるイメージです。
詳しい Organizations 環境全体の構成は、適宜前回の第 1 回のブログをご確認いただけると幸いです。
RAM の信頼されたアクセスを有効化する
まず、JITNA を有効化する前に、組織で AWS Resource Access Manager (RAM) の信頼されたアクセスを有効にする必要があります。
Org アカウントで、Organizations のマネジメントコンソールの「サービス」画面を確認します。一覧の中から [RAM] リンクをクリックすると、Organizations 側ではなく、RAM のマネジメントコンソール側で信頼されたアクセスを有効にするよう促されるので、それに従い [RAM コンソールへ移動] ボタンを押します。
[次との共有を有効にする] チェックボックスにチェックを入れ、[設定の保存] ボタンを押して設定を保存します。
ジャストインタイムノードアクセス (JITNA) を有効化する
Org アカウントで RAM の信頼されたアクセスの有効化が完了したら、今度は、Ops アカウントで JITNA を有効化していきます。
Systems Manager のマネジメントコンソールの左メニューの[ジャストインタイムノードアクセス] リンクをクリックします。
画面右上の [ジャストインタイムノードアクセスを有効にする] ボタンを押します。
次の画面の「組織単位」項目では「すべての OU」と「カスタム」が選択できます。今回は、前回の環境の Prod アカウントと Dev アカウントの上位 OU にあたる 「Application」OU を選択しました。
「リージョン」項目は、「デフォルト」と「カスタム」が選択できます。今回は「デフォルト」のままにしています。デフォルトのリージョンは、前回 Systems Manager の新しいエクスペリエンスを有効化した際に設定した us-west-2 と ap-northeast-1 リージョンになります。最後に画面右下の [ジャストインタイムノードアクセスを有効にする] ボタンを押します。
承認 / 拒否ポリシーについて
JITNA では、以下の 3 種類のポリシーが存在します。自動承認ポリシーと手動承認ポリシーは、ポリシーを作成した AWS アカウントとリージョンにのみ適用されます。
アクセス拒否ポリシーは、以下の AWS のドキュメントで、組織内のすべてのアカウントに適用されると記載されています。今回を例にすると、適用範囲は先ほど指定した「Application」OU 配下のアカウントになり、対象リージョンも、us-west-2 と ap-northeast-1 になります。
- 自動承認ポリシー
- 特定の条件を満たすアクセスリクエストを自動的に承認します。
- 手動承認ポリシー
- アクセスリクエストに対して、指定された承認者による手動の承認を必要とします。
- アクセス拒否ポリシー
- 特定のノードへのアクセスリクエストの自動承認を明示的に拒否します。
アクセス拒否ポリシーは、指定したノードへのアクセス要求の自動承認を明示的に防止します。アクセス拒否ポリシーは、AWS 組織内のすべてのアカウントに適用されます。自動承認と手動承認のポリシーは、作成された AWS アカウントと AWS リージョンにのみ適用されます。
引用（翻訳）元: Just-in-time node access using Systems Manager
アクセス拒否ポリシーの設定
アクセス拒否ポリシーは、自動承認が有効な場合に、特定の条件に一致するアクセスリクエストを自動的に拒否するための設定です。今回の検証では手動承認を使用するため、この設定は動作に影響しないはずですが、今後の検証に備えてあらかじめ設定しておきます。この設定は、引き続き Ops アカウントで設定をおこないます。
まず、[ジャストインタイムノードアクセス] - [承認ポリシー] - [組織ポリシー] の画面中央の [アクセス拒否ポリシーを作成] ボタンを押します。
（上の画面の「アクセス拒否ポリシーの仕組み」に「AWS RAM を使用して、アクセス拒否ポリシーを組織と共有します。」との記載があり、この仕様のために RAM の信頼されたアクセスを有効化する必要があったようです。）
手動承認へ進む際の指定（EC2 に付与された Environment タグの値が Shared-Development）の場合は、自動承認させない、という設定をしておきました。画面左にいくつか記載方法のサンプルがあり、今回は「ノードのタグ」というサンプルを利用しています。
手動承認ポリシーの作成
今度は、Dev アカウントで「手動承認ポリシー」を作成していきます。
「アクセス期間」項目は、今回は 1 時間にしておきます。この項目では、承認リクエスト後にセッションを開始できる期間を指定できます。セッション維持期間ではないことに注意が必要です。
セッション維持期間は、別の設定場所の「アイドルセッションタイムアウト」と「最大セッション時間」項目で設定します。
今回は、接続後すぐにセッションを終了させるため、設定を飛ばしますが、以下の AWS のドキュメントに記載の通り、ジャストインタイムノードアクセスは、セッションを自動的に終了しないため、実際の運用時は、セキュリティの観点からセッションを維持させ続けないために、設定をする必要があります。
必要なすべての承認を受け取ると、ユーザーは、承認ポリシーで指定されたアクセスウィンドウの期間中、必要なだけノードへのセッションを開始できます。Systems Manager は、ジャストインタイムのノードアクセスセッションを自動的に終了しません。ベストプラクティスとして、最大セッション時間とアイドルセッションタイムアウトのセッション環境設定の値を指定します。
引用（翻訳）元: Just-in-time node access using Systems Manager
「ターゲット」項目では、手動承認をおこないたいノードを設定します。「すべてのノード」と「特定のノードのみ」が選択できます。今回は「特定のノードのみ」を選びました。先ほども少し触れていたタグで絞ります。「Environment タグの値が Shared-Development のターゲットの場合は、手動承認が必要」という設定にしておきます。複数人で共有している開発環境の場合は、手動承認を挟むイメージです。
「アクセスリクエストの承認」項目では、何段階の承認が必要か、と承認者の設定ができます。
今回は、1 段階のみの承認です。承認者を事前に設定しておいた IAM Identity Center のグループ「SSM-JITNA-Approver-Group」を指定しています。最後に左下の [手動承認ポリシーを公開] ボタンを押して設定を完了します。
登場人物
承認者 (Red さん)
このあと、実際にセッションマネージャーでの EC2 接続時の流れを確認していきますが、その際、先ほど承認者として指定した SSM-JITNA-Approver-Group に所属している Red というユーザーの権限でマネジメントコンソールにログインし、承認をおこないます。
許可セットで、こちらの AWS のドキュメントの「IAM policy for access request approvers」の箇所に記載のポリシーを設定しています。
運用者 (Green さん)
SSM-JITNA-Operator-Group に所属しているの Green というユーザーは、実際にセッションマネージャーで EC2 に接続する際に、接続リクエストを送信し、接続できるかを確認するユーザーです。
許可セットで、こちらの AWS のドキュメントの「IAM policy for just-in-time node access users」の箇所に記載のポリシーを設定しています。このポリシーを確認していただくとわかりますが、StartSession 権限は付与されていません。
セッションマネージャーで接続する
ここからは、実際に Dev アカウントのマネジメントコンソールに上記の運用者と承認者としてログインし、接続までの流れを確認していきます。
接続リクエスト（運用者）
まずは、ユーザー Green として、マネジメントコンソールにログインし、Systems Manager の画面を表示します。左メニューの [ノードを詳しく見る] リンクをクリックします。接続したい EC2 を選択し、画面右の [ノードのアクション] - [接続] - [ターミナルセッションを開始する] をクリックします。
ポップアップが表示されるので [Create access request] ボタンを押して、アクセスリクエストを送信します。
承認（承認者）
今度は、ユーザー Red として、マネジメントコンソールにログインし、Systems Manager の画面を表示します。左メニューの [ジャストインタイムノードアクセス] リンクをクリックします。[アクセスリクエスト] タブ - [私へのリクエスト] から 該当のリクエストを選択し、画面右の [承認] ボタンを押して、承認します。
セッションを開始する（運用者）
再度ユーザー Green として、マネジメントコンソールにログインし、Systems Manager の画面を表示します。左メニューの [ジャストインタイムノードアクセス] リンクをクリックします。[アクセスリクエスト] タブ - [私からのリクエスト] から、該当のリクエスト ID を選択し、リクエストの詳細画面を表示します。
画面右上の [セッションを開始する] ボタンを押して接続します。
接続できました。画面右上の [終了] ボタンを押します。
ポップアップが表示されるので [終了] ボタンを押してセッションを終了します。
まとめ
今回は、Systems Manager の新しいエクスペリエンス（= 統合コンソール）を有効化した環境で利用できる「ジャストインタイムノードアクセス（JITNA）」を、前回と同じ Organizations を利用した環境で試してみました。
StartSession 権限を持たないユーザーが、JITNA の機能を利用することで、一時的なゼロスタンディング権限でアクセスできることを確認できました。
今回は、共有している開発環境へのアクセスを想定して、手動承認プロセスを試してみましたが、実際の運用時は、例えば、個人の開発環境であれば自動承認にしたり、本番環境であれば 2 人以上の承認者を求めたりと、要件に応じて柔軟に設定できそうです。
他にも通知やログの設定など、まだ試せていない機能が残っていますので、次回はそれらも含めて、JITNA をさらに深掘りしていきたいと思います！
