AWS Systems Manager を使用したジャストインタイムノードアクセスの紹介

本記事は 2025 年 4 月 29 日に公開された Introducing Just-in-time node access using AWS Systems Manager を翻訳したものです。

2025 年 4 月 29 日に AWS Systems Manager の新機能であるジャストインタイムノードアクセスの一般提供を開始しました。ジャストインタイムノードアクセスは、AWS Systems Manager で管理されている Amazon Elastic Compute Cloud (Amazon EC2)、オンプレミス、およびマルチクラウドノードへの動的かつ時間制限付きのアクセスを可能にします。ポリシーベースの承認プロセスを導入することで、長期的なアクセス権を適切に管理しつつ、運用効率とセキュリティの両方を向上させることができます。

何千ものノードに運用を拡大する組織では、監査とコンプライアンスの目標をサポートするために、ID ベースの詳細な権限が必要で、長期的な認証情報を完全に排除したいと考えています。ノードアクセスに長期的な認証情報を使用する慣行は、セキュリティの脆弱性を生み出し、不正アクセスや潜在的な侵害のリスクを高めます。

これまで、お客様はセキュリティと運用効率の間で難しいトレードオフに直面していました。特定のリソースに誰がアクセスする必要があるかを慎重に決定するのではなく、IT チームは大規模なユーザーグループに過剰な権限を付与していました。この慣行は、運用上の利便性の必要性によるものですが、オペレーターの誤操作のリスクを高め、悪意のある行為者に機会を与えていました。長期的な認証情報を維持してセキュリティが侵害されるリスクを高めるか、インシデント対応を遅らせる制限的なアクセス制御を実装するかのどちらかでした。さらに、独自に構築したソリューションは保守や拡張が複雑になりがちでした。一方、エージェントを使用する AWS 以外のツールでは、ノードへのアクセスに別途 ID と権限が必要となっていました。

概要

ジャストインタイムノードアクセスは、運用チームが問題に迅速に対応できるようにしながら、最小権限アクセスを実装するのに役立ちます。これは AWS Organizations 全体でシームレスに機能し、単一のアカウントでも複数のアカウントでも一貫したアクセス制御を設定できます。この新機能により、管理者は承認ポリシーを通じて正確なアクセス制御を定義でき、誰がどのノードにどのような条件でアクセスできるかを指定できます。組織は、複数の承認者による手動承認プロセスと条件ベースの自動承認ポリシーのどちらかを選択でき、セキュリティ要件に合わせた柔軟性を提供します。

例えば、管理者はインシデント対応中のオンコールエンジニアに迅速にアクセスを提供するための自動承認ポリシーを確立し、オンコール AWS IAM Identity Center グループのオペレーターにのみアクセスを許可することができます。ジャストインタイムノードアクセスを通じて、オペレーターは必要なときにノードへのアクセスをリクエストできます。事前設定された承認ポリシーに基づいて、定義された時間経過後に自動的に期限切れになる一時的なアクセスを受け取ります。承認されると、インバウンドポートを開いたり SSH キーを管理したりする必要なく、ワンクリックのブラウザベースのシェル、AWS Command Line Interface (AWS CLI) または Systems Manager でサポートされているリモートデスクトッププロトコル (RDP) を介して、これらのノードに直接アクセスできます。

承認プロセスを簡素化するために、ジャストインタイムノードアクセスは Amazon Q Developer を通じて Slack や Microsoft Teams などのツールと統合し、保留中のリクエストについて承認者に通知するためのメールも送信します。Systems Manager はまた、ジャストインタイムノードセッションアクセスリクエストのステータス更新のために Amazon EventBridge にイベントを発行します。これらのイベントは通知のために Amazon Simple Notification Service (Amazon SNS) にルーティングしたり、内部システムと統合したりすることができ、チームが既存のワークフローを通じてアクセスリクエストを追跡し対応することを可能にします。これにより、組織全体でアクセスリクエストを監視し、監査証跡を維持することができます。さらに、ジャストインタイムノードアクセスは、セッション中に実行されたコマンドをログに記録したり、RDP セッション中の操作を録画することで、オペレーターの作業の見える化を提供します。

Systems Manager は、アカウントごと、リージョンごとにジャストインタイムノードアクセスの無料トライアルを提供しており、この機能を評価することができます。この無料トライアル期間は、機能を有効化した月の残り期間と、その翌月の 1 か月間が含まれます。このトライアル期間中、追加料金なしで設定やアクセスポリシーをテストできるよう、すべての機能にアクセスできます。トライアルが終了すると、ジャストインタイムノードアクセスは有料サービスとなり、使用パターンに基づいて課金されます。詳細な価格情報とコスト内訳については、AWS Systems Manager の料金を参照してください。

ジャストインタイムノードアクセスの使用

ジャストインタイムのノードアクセスでは、管理者、オペレーター、承認者という3つの役割があります。管理者は承認ポリシーの設定と管理を、オペレーターは必要なノードへのアクセス要求を、承認者はそれらの要求の確認と承認を担当します。
この機能の設定と使い方について、具体例を用いて説明します。ここでは、オンコールエンジニアが本番環境の「r2d2-app-01」というインスタンスにアクセスする必要がある場合を想定します。図 1 には、アクセス対象となる可能性のあるインスタンス群が示されています。

図 1: Amazon EC2 コンソールに表示される EC2 インスタンスのリスト

オンコールエンジニア（オペレーター）が本番システムへのアクセスをリクエストし、DevOps リード（承認者）が管理者が定義した承認ポリシー内でそれを管理する方法を紹介します。

管理者としてのジャストインタイムノードアクセスの設定

ステップ1 – ジャストインタイムノードアクセスの有効化

このウォークスルーでは、AWS Organizations のジャストインタイムノードアクセスを有効にします。まず、Systems Manager 統合コンソールをセットアップする必要があります。統合コンソールがセットアップされたら、Systems Manager でジャストインタイムノードアクセスを有効にできます。

次に、展開のターゲットとする組織単位（OU）と AWS リージョンを選択できます。これにより、図2に示すように、組織全体または特定の領域でソリューションを実装する場所を正確に制御できます。

図 2: ジャストインタイムノードアクセスの有効化

ステップ2 – 承認ポリシーの作成

機能を有効にした後、次の重要なステップは承認ポリシーの作成です。承認ポリシーは、ユーザーがノードにアクセスする方法を決定します。これらのポリシーには、自動承認、手動承認、アクセス拒否ポリシーの3種類があります。自動承認ポリシーは、ユーザーが自動的に接続できるノードを定義します。手動承認ポリシーは、指定したノードにアクセスするために提供する必要がある手動承認の数とレベルを定義します。アクセス拒否ポリシーは、指定したノードへのアクセスリクエストの自動承認を明示的に防止します。

この例では、「r2d2-app-01」ノードを含む Workload:Application01 でタグ付けされたノードに対する手動承認ポリシーの作成方法を説明します。

ポリシーを作成するには、AWS Systems Manager コンソールに移動し、ナビゲーションペインでジャストインタイムノードアクセスを選択し、承認ポリシータブおよびローカルポリシーを選択して、手動ポリシーを作成を選択します。ポリシー設定にはいくつかの重要なコンポーネントが必要です。

まず、承認ポリシーの詳細セクションで、図 3 に示すように、承認ポリシーの名前と説明を入力し、最大アクセス期間を設定します。この期間は、承認されたアクセスが自動的に期限切れになるまでの有効期間を決定します。

図 3: 手動承認ポリシーページ

ターゲットセクションでは、タグのキーと値のペアを使用して、ポリシーが適用されるノードを定義します。この例では、「r2d2-app-01」ノードを含む Workload:Application01 でタグ付けされたノードをターゲットにします。図 4 に示すように、この方法によって Application01 に関連するすべてのノードにポリシーが確実に適用されます。

図 4: 手動承認ポリシーのターゲット

アクセスリクエストの承認セクションでは、アクセスリクエストを承認する権限を持つ個人またはグループを指定します。このシナリオでは、DevOps リードの役割を承認者として割り当てます。アクセスリクエスト承認者は、図 5 に示すように、IAM Identity Center のユーザーとグループ、またはIAM ユーザー、グループ、ロールにすることができます。

図 5: アクセスリクエスト承認

また、Cedar ポリシー言語を使用して自動アクセスルールを定義することもでき、信頼されたシナリオでは手動承認の必要性を排除できます。自動承認ポリシーは、組織の事前承認されたアクセスルールブックと考えてください。これらのポリシーは、事前定義された条件と信頼レベルに基づいて、ユーザーが自動的にアクセスできるノードを指定します。詳細については、ジャストインタイムノードアクセスの自動承認ポリシーの作成および自動承認およびアクセス拒否ポリシーのステートメント構造と組み込み演算子を参照してください。

例えば、以下の Cedar ポリシーを使用して、「DevOpsTeam」グループのメンバーが Environment: Development でタグ付けされたノードに自動的にアクセスできるようにする自動承認ポリシーを作成できます：

// Policy to permit access to Development nodes for members of the DevOpsTeam IDC group
permit (
    principal in AWS::IdentityStore::Group::"911b8590-7041-70fa-d20b-12345EXAMPLE",
    action == AWS::SSM::Action::"getTokenForInstanceAccess", 
    resource)
  when {
    resource.hasTag("Environment") && 
    resource.getTag("Environment") == "Development"
  };

オペレーターとしてのアクセスリクエスト

オペレーターとして保護されたノードにアクセスする必要がある場合、リクエストプロセスが表示されます。Session Manager を通じて接続を試みる際、即座にアクセスが許可されるのではなく、アクセスリクエストの送信を求められます。図 6 に示すように、アクセスが必要な理由の入力が必要となります。

図 6: ノードへのアクセスをリクエストするオペレーター

リクエスト送信後は、図 7 に示すように、アクセスリクエストタブでその状況を確認できます。承認プロセスの進行状況を追跡でき、アクセスが許可されるタイミングを正確に把握することができます。メール、Slack、Microsoft Teams、または他の統合プラットフォームなど、好みの通信チャネルを通じて通知を受け取ります。詳細については、ジャストインタイムアクセスリクエストの通知の設定を参照してください。

図 7: アクセスリクエストリストページ

承認の管理

承認者として、設定した通知チャネルを通じて保留中のアクセスリクエストの通知を受け取ります。AWS Command Line Interface (AWS CLI) または好みの SDK を使用してプログラムでリクエストを承認することも、図 8 に示すように、Systems Manager コンソールの私へのリクエストタブでこれらのリクエストを確認することもできます。

図 8: 承認待ちのアクセスリクエストのリスト

リクエストを確認した後、リクエストを承認または拒否し、オプションで決定に関連するコメントを追加できます。

アクセスサイクルの完了

リクエストが承認されると、オペレーターとして、アクセスが許可されたという通知を受け取ります。その後、図 9 に示すように、承認ポリシーに記載された期間、AWS マネジメントコンソールまたは AWS CLI を使用してノードに接続できます。

図 9: 管理対象ノードにアクセスするオペレーター

まとめ

このブログでは、AWS Systems Manager の新機能であるジャストインタイムノードアクセスを紹介しました。ジャストインタイムノードアクセスは、常時付与された権限を排除しながらも、Amazon EC2、オンプレミス、およびマルチクラウドノードへの迅速なアクセスを確保することで、運用効率とセキュリティ要件のバランスを取るという課題を解決します。柔軟なポリシーベースのアプローチと、手動および自動承認のサポートにより、運用能力を損なうことなくゼロスタンディング特権を実装できるようになりました。

Systems Manager はジャストインタイムノードアクセスの無料トライアルを提供しており、この機能を評価することができます。

詳細については、Systems Manager を使用したジャストインタイムノードアクセスを参照してください。

ジャストインタイムノードアクセスの体験の完全なビジュアルツアーについては、このインタラクティブデモをご覧ください。

翻訳はソリューションアーキテクトの村田が担当しました。