はじめに
お久しぶりです。服部です。
出遅れてしまいましたが、2025年4月29日にAWS Systems Manager でジャストインタイムのノードアクセスのリリースが発表されましたね。 なんと、セッションマネージャーに一時権限付与する仕組みやフリートマネージャのログも取得できるようになったのだとか。
踏み台インスタンスをAWSのマネージドサービスに移行したいけど、作業証跡が取れないのは厳しいなどAWS Systems Manager Session Manager（以下Session Manager）の機能不足に悩んでいた方へ朗報です。
本記事では、何ができるようになったのか、基本的な設定方法についてご紹介いたします！
結論
まずは、手っ取り早くAWS Systems Manager Session Managerでできるようになったことをご紹介します。
できること
必要な時だけアクセスを許可:
- ノードへの接続要求が発生した際に、その都度、申請→承認を行うことができます。これにより、不要な常時接続のリスクを低減できます。
自動承認と手動承認:
- アクセス要求に対して、事前に定義したポリシーに基づいて自動的に承認するか、複数の承認者による手動承認フローを設定できます。手動承認の場合、再承認が不要な期間を設定することも可能です。
マルチアカウント対応:
- AWS IAM Identity Center と連携することで、AWS Organizations環境におけるユーザーの承認も可能です。
統合されたエクスペリエンス:
- AWS Session Managerの画面から直接にジャストインタイムノードアクセスの申請画面に遷移することが可能です。
通知機能:
- アクセスリクエストのイベント（承認依頼、承認、承認キャンセル）発生時に、メールやSlack、Teamsへの通知を設定できます。
セキュリティの強化:
- 不要なポート開放が不要になるため、インターネットに公開するサーバを削減し、セキュリティリスクを低減できます。
踏み台ホストが不要:
- 踏み台ホストを立てて管理する必要がなくなり、運用のオーバーヘッドを削減し、セキュリティ上の懸念も減らすことができます。
OSにログインするためのユーザ管理が不要:
- AWS Identity and Access ManagementのロールまたはAWS Identity and Access Management (IAM) Identity Center のユーザで管理が可能であるため、OSログイン用のユーザーを個別で管理しなくて済みます。
監査ログ:
- 誰がいつノードにアクセスしたかの記録をCloudTrailで監査できます。
- また、セッション中の操作（CUI・GUIともに）についてもS3に保管・確認することができます。
AWS CLIでの利用:
- AWS CLIからもジャストインタイムノードアクセスを利用できます。
できないこと
確実なコストの削減:
- AWSアカウントの使用状況にもよりますが、大体マネージドインスタンス1台当たり月10USDほどかかります。
- 料金 - AWS Systems Manager | AWS
- マネージドインスタンスを100台ほど利用しているような環境であれば、AWSの利用料がかなり増加してしまう可能性があります。
- ただし、セキュリティ対策への投資という考え方もできるので、ご検討の余地はあるかと考えています。
ファイルのコピペ不可:
- Session ManagerのコンソールやAWS CLIの基本的な機能では、直接的なドラッグ＆ドロップのようなGUI操作でのファイル転送機能は提供されていない。
- ただし、Fleet Managerでは、GUIベースでファイルシステムの操作（コピー、切り取り、貼り付けなど）が可能。
基本設定ガイド
※今回は、AWS IAM Identity Centerで設定してみます！
大筋
- 下準備：OSログイン用の許可セットを作成する
- 下準備：マネージドインスタンスおよびネットワーク環境の整備
- AWS Systems Manager Session Manager 新機能_ジャストインタイムノードアクセスの有効化
- ユーザIDの変更
- 承認ポリシーの作成
- 試してみる
下準備：OSログイン用の許可セットを作成する
Administratorアクセス権限やPowerUser権限の場合、最初からセッションを開始するための権限が付与されてしまっているので、個別の許可セット・ポリシーを作成する必要があります。 逆にReadOnlyだけだとそもそもアクセスを申請する権限がないため、「Access Deny」となります。 ちょっとややこしいですね…
ではまず、AWS IAM Identity Centerの操作画面に移動します。 左側の「許可セット」をクリックします。
「許可セットを作成」をクリックします。
「カスタム許可セット」を選択し、「次へ」クリックします。
インラインポリシーを選択し、Systems Manager によるジャストインタイム アクセスの設定の「ジャストインタイムノードアクセスユーザー向けのIAMポリシー」をコピペします。その後、次へをクリックします。 ※152行目の【Accout ID】は【*】に変更します。
許可セット名などについては任意の値（今回はSSMJustInTimeAccess）を入れ、「次へ」をクリックします。
以下のような画面が出たら「使用を開始」をクリックして、対象のユーザ・グループを選択します。
追加されたことを確認します。
許可セットを作成した後は任意のグループユーザにアタッチすることをお忘れなく！！！
下準備：マネージドインスタンスおよびネットワーク環境の整備
細かく説明すると今回の目的からずれてしまうので、下記リンクから環境設定をお願いします。 docs.aws.amazon.com
AWS Systems Manager Session Manager ジャストインタイムノードアクセスの有効化
ログインしたいインスタンスのあるアカウントのAWS Systems Managerの画面に移動し、「ジャストインタイムノードアクセス」を有効化する。
※なお、SSMについて組織の委任された管理者で管理している場合は、そのアカウントで実行
※対象のアカウントが、CloudFormationのStackSetsの委任された管理者であることも確認
「ジャストインタイムノードアクセスを有効にする」をクリックする
有効化にするための項目が出てくるので、テスト用のOUだけ選択しましょう。リージョンも同様に必要最低限で。
※一気に本番環境まで許可すると上記で記載の通り、インスタンスの台数X10USDなので、コストが大変なことになります。
設定できたら「ジャストインタイムノードアクセスを有効にする」をクリックする ※クリックしたら、下記のような文言が表示されるので待ちましょう。
完了すると下記のように変化します
ユーザIDの変更
今回はAWS IAM Identity CenterでテストするのでユーザIDを変更していきます
ジャストインタイムノードアクセスを有効化したアカウントで設定します。
画像の通り、「設定」→「ジャストインタイムノードアクセス」→「組織設定」→「編集」をクリックします。
AWS IAM アイデンティティセンター (SSO)を選択します。
下記のような画面が表示されますが、「続行」をクリックします。戻ったら「送信」をクリックします。
承認ポリシーの作成
ジャストインタイムノードアクセスで承認フローを適用したいアカウントでジャストインタイムノードアクセスを開くと、手動承認ポリシーの作成表示になるので、「名前」「説明」「アクセス期間」を指定します。
ターゲットを任意で選択します。なお、特定のノードのみ対象にする場合は、タグの設定で対象を絞るようです。
その後「承認者を追加」をクリックします。※なお、申請者と承認者は別のユーザである必要がありますので、ご注意ください。
任意のユーザまたはグループを選択したら、「手動承認ポリシーを公開」クリックします。
※承認ポリシーの設定ミスで作り直しています。
作成できたことを確認します！
試してみる
では、設定した内容をテストしてみます！！ 上記で作成したポリシーを利用して、アクセス先のノードがあるアカウントにログインしてみます。
AWS Systems Managerから「ノードを詳しく見る」からアクセス先のノードを選択します。
「ノードアクション」から「接続」＞「ターミナルセッションを開始する」をクリックします。
リクエストを作成する画面が表示されました！
任意のコメント（日本語もOK）を記載して、「Create access request」をクリックします。
では、承認者のユーザに切り替えます。
ジャストインタイムノードアクセスからリクエストがありました！！
対象のリクエストを選択後、「承認」をクリックします。
承認のコメント（日本語もOK）を記載して、「Approve」をクリックします。
申請者側のユーザに戻るとセッションが許可されているので「セッションを開始する」をクリックします。
無事ログインできました！
補足：アクセス拒否ポリシーについて
ユーザーがノードに接続しようとすると、ジャストインタイムノードアクセスは、まずアクセス拒否ポリシー（明示的な拒否）を評価します。
その後ID によるノードへの接続が明示的に拒否されない場合、残りの承認ポリシーが評価されるような流れになる。
従って、ジャストインタイムノードアクセスからどうしてもアクセスさせたくないインスタンスを管理することも可能です。
ただし、別でリソースを共有する必要があり、AWS Organizations のリソース共有は、組織の管理アカウントから有効が必要です。
コスト
ジャストインタイムノードアクセス機能は無料ではないので、注意が必要です！ 大体1マネージドノード当たり10USD /月ほどかかるので、EC2インスタンスが大量にあるアカウントで有効化すると一気にコストがかかる可能性があるため注意が必要です。
一応、中央管理しているAWS Systems Managerで有効化しても、各アカウントでの有効化・無効化は選択できるようなので、よかったです… 中央管理のアカウントで有効化して、全アカウント・全インスタンスで費用が発生したらインシデントモノです… 皆様、本機能は便利ですが、有効化の際は、コストも考慮した上で有効化しましょう。
最後に
いかがでしたでしょうか？どなたかの役に立てたら幸いです。
今回はAWS IAM Identity Centerからジャストインタイムノードアクセスを利用方法だけになってしまいましたが、近々設計・運用方法のお勧めについてもかけたらと考えています。 特にRDPのログ保管できるようになったのはとても良き…
この記事を読んでくださり、ありがとうございました！
