AWS Systems Managerでの監査ログ取得 – セキュリティ編

こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。

前回・前々回の記事では、AWS Systems Manager Session Managerのセッションログ記録とRDP録画の設定方法を解説しました。SSM-SessionManagerRunShellドキュメントでCloudWatch Logsへのログ記録を有効化し、Just-in-timeノードアクセスでRDP接続の画面録画を設定することで、EC2インスタンスへのすべての操作を証跡として残す仕組みを構築しました。
 
しかし、ここでひとつ疑問が浮かびます。Session Managerには対話型シェル以外にも、ポートフォワーディングやSSH over SSMなど、複数の接続方法があります。これらの接続方法を使われた場合でも、ログや録画はきちんと記録されるのでしょうか。もし記録されない接続方法が存在するなら、それを使われてしまうとせっかくの設定が無意味になってしまいます。
 
本記事では、Session ManagerとFleet Managerの接続バリエーションを網羅的に洗い出し、それぞれでセッションログやRDP録画が記録されるか調査結果をまとめています。その上で、記録が回避されるシナリオを特定し、ネットワーク面と設定面の両方から対策を整理します。
 

Session Managerの通信メカニズム

接続バリエーションごとのログ記録状況を理解するために、まずSession Managerの通信の仕組みを押さえておきましょう。

通信の全体像

Session Managerでは、EC2インスタンス上で動作するSSM Agentが、AWSのサービスエンドポイントに対してアウトバウンドのHTTPS（ポート443）接続を確立します。クライアントPC側も同様に、AWSのエンドポイントに対してHTTPS接続を行います。つまり、クライアントPCとEC2インスタンスが直接通信するのではなく、AWSのサービスを介してデータをやり取りする構成です。

この仕組みにより、EC2インスタンス側でインバウンドポート（SSH 22番やRDP 3389番）を開放する必要がありません。SSM Agentが自らAWSサービスに接続しに行くため、ファイアウォールでインバウンドトラフィックを許可する必要がないのです。

Session Managerが使用する主なエンドポイントは以下の3つです。

  • ssm.region.amazonaws.com: コントロールプレーン。セッション開始時の認証・認可や、SSM Agentの定期的なハートビート（5分間隔）に使用されます
  • ssmmessages.region.amazonaws.com: データプレーン。セッションの実データ（シェル入出力やポートフォワーディングのストリーム）を中継します。WebSocket over HTTPS/443で双方向通信を行います
  • ec2messages.region.amazonaws.com: メッセージ配信。SSM Agent 3.3.40.0以降ではssmmessagesが優先されます

インターネットゲートウェイやNATゲートウェイを持たない閉じたVPC環境では、これらのエンドポイント用にInterface型のVPCエンドポイント（AWS PrivateLink）を作成することで、インターネットを経由せずにAWSサービスと通信できます。

セッションタイプによる通信の違い

Session Managerの通信は、いずれのセッションタイプ(次項「セッションドキュメントの4つのタイプ」参照)でもクライアントPCおよびEC2インスタンスからssmmessagesエンドポイントへのWebSocket over HTTPS/443接続で行われます。この接続はTLS 1.2以上で暗号化されています。ただし、この接続の中を流れるデータの扱いがセッションタイプによって異なり、それがログ記録の可否に直結します。

対話型シェルセッション（Standard_Stream。後述）の場合、SSM Agentがインスタンス上のシェルの入出力を読み取り、WebSocket接続を通じてクライアントPCに中継します。シェルの入出力はプレーンテキストとしてSSM Agentが扱えるため、CloudWatch LogsやS3にセッションログを記録できます。

一方、SSH over SSMやポートフォワーディング（Port。後述）の場合、Session ManagerはSSH/RDPの通信を中継するトンネルとして機能します。SSM Agentはトンネルの終端として、受け取ったデータをインスタンス内部のlocalhost上で動作するSSH/RDPサービス（Linuxではsshd、WindowsではRemote Desktop Services）に転送します。ネットワーク経由のインバウンド通信ではないため、セキュリティグループでSSH（22番）やRDP（3389番）を開放する必要はありませんが、インスタンス上でこれらのサービスが起動している必要があります。

Portタイプの通信図解

セッションドキュメントの4つのタイプ

Session Managerでは、セッションの種類を「セッションドキュメント」で定義します。ドキュメントには以下の4つのタイプ（sessionType）があります。

タイプ 用途 ログ記録可否
Standard_Stream 対話型シェルセッション 可能
Port ポートフォワーディング、SSH over SSM 不可
InteractiveCommands 対話型コマンド実行 可能
NonInteractiveCommands 非対話型コマンド実行 可能
参考:
  • Session document schema – セッションドキュメントの4つのタイプ（sessionType）の定義
  • Start a session – 対話型シェル、SSH、ポートフォワーディング等の接続方法
なお、InteractiveCommandsとNonInteractiveCommandsは、カスタムドキュメントであらかじめ定義した特定のコマンドだけを実行させるためのタイプです。InteractiveCommandsはセッションが維持される用途（例: tail -f でログをリアルタイム閲覧）、NonInteractiveCommandsはコマンドを実行して結果を返したら終了する用途（例: ディスク使用率の取得）で使われます。いずれも自由なシェル操作はできないため、一般的なOSログインの手段ではありません。本記事では詳細な説明は割愛します。
 
ここでのポイントは、Portタイプのセッションではログ記録ができないという点です。AWS公式ドキュメントにも以下のように明記されています。

Logging isn’t available for Session Manager sessions that connect through port forwarding or SSH. This is because SSH encrypts all session data within the secure TLS connection established between the AWS CLI and Session Manager endpoints, and Session Manager only serves as a tunnel for SSH connections.

出典: Enabling and disabling session logging – AWS Systems Manager

つまり、Portタイプのセッションでは、トンネル内部がSSH/RDPプロトコルで暗号化されているため、Session Managerはトンネルとしてのみ機能し、中身を記録することができません。

接続バリエーション別のログ・録画記録設定

それでは、Session ManagerとFleet Managerで利用可能な接続方法を洗い出し、それぞれのログ・録画記録設定を確認しましょう。

接続方法の一覧

以下の表は、各接続方法とそのログ・録画記録状況をまとめたものです。

接続方法 ドキュメントタイプ セッションログ(CloudWatch Logs/S3) RDP録画(S3) 使用ドキュメント
対話型シェル（コンソール/CLI） Standard_Stream 記録される – SSM-SessionManagerRunShell
SSH over SSM（ProxyCommand） Port 記録されない – AWS-StartSSHSession
ポートフォワーディング Port 記録されない – AWS-StartPortForwardingSession
リモートホストへのポートフォワーディング Port 記録されない – AWS-StartPortForwardingSessionToRemoteHost
Fleet Manager Remote Desktop Port（内部使用） 記録されない 記録される（JIT有効時） AWS-StartPortForwardingSession（内部使用）

各接続方法の詳細

対話型シェルセッション（Standard_Stream）

マネジメントコンソールやAWS CLIからドキュメントを指定せずにSession Manager接続を開始すると、SSM-SessionManagerRunShellドキュメントが使用されます。このドキュメントのタイプはStandard_Streamで、シェルの入出力がプレーンテキストとしてSSM Agentに渡されるため、CloudWatch LogsやS3にセッションログを記録できます。

前々回の記事で設定したデフォルトログ記録は、このStandard_Streamタイプのセッションに対して有効です。

SSH over SSM（Port）

SSH over SSMは、クライアントPCのSSH設定ファイル（~/.ssh/config）にProxyCommandを記述し、SSHの通信経路としてSession Managerを利用する方法です。SSHクライアントが生成したSSHパケットをSession Manager Pluginがトンネル内にカプセル化して送信します。

この接続ではAWS-StartSSHSessionドキュメント（Portタイプ）が使用されます。トンネル内部がSSHプロトコルで暗号化されているため、Session Managerはトンネルとしてのみ機能し、セッションログは記録されません。ただし、CloudTrailにはssm:StartSession APIの呼び出しが記録されるため、「誰が、いつ、どのインスタンスに接続したか」は追跡可能です。

ポートフォワーディング（Port）

AWS CLIで –document-name AWS-StartPortForwardingSession を指定すると、クライアントPCのローカルポートとEC2インスタンスの指定ポートをSession Managerトンネル経由で接続できます。例えば、ローカルの56789番ポートをインスタンスの3389番ポート（RDP）に転送するように指定して、ローカルのRDPクライアントから localhost:56789 に接続するといった使い方です。

このPortタイプのセッションでも、トンネル内部がRDPプロトコルで暗号化されるため、セッションログは記録されません。

リモートホストへのポートフォワーディング（Port）

AWS-StartPortForwardingSessionToRemoteHostドキュメントを使用すると、SSM Agentが動作しているEC2インスタンスを踏み台として、そこからネットワーク的に到達可能な別のホスト（例: RDSデータベース）のポートをフォワードできます。こちらもPortタイプのため、セッションログは記録されません。

Fleet Manager Remote Desktop（Port + RDP録画）

Fleet Manager Remote Desktopは、マネジメントコンソールからWindows ServerインスタンスにRDP接続できる機能です。内部的にはAWS-StartPortForwardingSessionドキュメントを使用しており、セッションのタイプはPortです。そのため、Session Managerのセッションログ（CloudWatch Logs/S3）は記録されません。

ただし、Fleet Manager Remote Desktopには独自のRDP録画メカニズムがあります。Just-in-timeノードアクセスを有効化し、RDP接続記録を設定すると、 ssm-guiconnect サービスがRDP接続の画面録画をS3バケットに保存します。この録画機能はSession Managerのログ記録とは別のメカニズムで動作するため、Portタイプのセッションであっても画面録画が可能です。

ログ記録の死角

上記の調査結果から、以下のことがわかります。

  • Standard_Streamタイプ（対話型シェル）のセッションは、SSM-SessionManagerRunShellドキュメントのログ設定が適用され、セッションログが記録される
  • Portタイプ（SSH over SSM、ポートフォワーディング）のセッションは、セッションログが記録されない
  • Fleet Manager Remote Desktopは、セッションログは記録されないが、RDP録画は別メカニズムで記録可能

つまり、ユーザーがAWS CLIでPortタイプのドキュメントを指定してセッションを開始すれば、セッションログの記録を回避できてしまいます。また、当然ですがSession Managerを経由せずにネットワーク経由で直接SSH/RDP接続できてしまう環境では、そもそもSession Managerのログ記録の仕組み自体が機能しません。

回避シナリオと対策

ログ記録の死角を踏まえ、具体的な回避シナリオとその対策を整理します。対策は「ネットワーク面」と「設定面（IAMポリシー）」の2つの観点から考えます。

回避シナリオ

シナリオ1: Portタイプのドキュメントを指定してセッションを開始

ユーザーがAWS CLIで以下のようなコマンドを実行すると、ポートフォワーディングセッションが開始され、セッションログは記録されません。

aws ssm start-session \
--target i-1234567890abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["3389"],"localPortNumber":["56789"]}'

この場合、ローカルのRDPクライアントから localhost:56789 に接続すれば、Session Managerトンネル経由でインスタンスにRDP接続できますが、セッションログには何も記録されません。

シナリオ2: ネットワーク経由でSSH/RDPに直接接続

EC2インスタンスのセキュリティグループでSSH（22番）やRDP（3389番）のインバウンドが許可されている場合、Session Managerを経由せずに直接接続できてしまいます。この場合、Session Managerのログ記録の仕組み自体が関与しないため、操作記録は一切残りません。

ネットワーク面の対策

ネットワーク面の対策は、シナリオ2（Session Managerを経由しない直接接続）を防ぐことが目的です。

プライベートVPC環境の構築

インターネットゲートウェイやNATゲートウェイを持たないプライベートVPC環境を構築することで、インターネット経由での直接接続を遮断できます。EC2インスタンスがAWSサービスと通信するためには、VPCエンドポイント（AWS PrivateLink）を使用します。

セキュリティグループの設計

EC2インスタンスのセキュリティグループでは、インバウンドルールにSSH（22番）やRDP（3389番）を追加しないことが重要です。Session Managerの通信はすべてHTTPS（443番）のアウトバウンドで行われるため、インバウンドポートの開放は不要です。

具体的には、以下のような設計が推奨されます。

  • EC2インスタンスのセキュリティグループ
    インバウンド: ルールなし。システムの通信要件上ポート開放が必要な場合でも、SSH（22番）やRDP（3389番）は許可しない。
  • VPCエンドポイントのセキュリティグループ
    インバウンド: VPC CIDRからのTCP 443のみ

この設計により、EC2インスタンスへの直接SSH/RDP接続は物理的に不可能になります。

ネットワーク制御の限界

ただし、ネットワーク制御だけではシナリオ1（Portタイプのドキュメント指定）を防ぐことはできません。ポートフォワーディングやSSH over SSMは、Session Managerのトンネル（HTTPS/443）を経由して動作するため、セキュリティグループやVPCエンドポイントの設定では区別できないのです。

IAMポリシー設定面の対策

IAMポリシー設定面の対策は、シナリオ1（Portタイプのドキュメント指定）を防ぐことが目的です。

IAMポリシーでドキュメントを制限

Portタイプのセッションドキュメントに対するssm:StartSessionを明示的に拒否（Deny）することで、ユーザーがCLIからポートフォワーディングやSSH over SSMのセッションを開始できないようにします。

ただし、Fleet Manager Remote Desktopは内部的にAWS-StartPortForwardingSessionドキュメントを使用するため、単純にDenyするとFleet Manager Remote Desktopも使えなくなってしまいます。aws:CalledVia 条件を使い、ssm-guiconnect（Fleet Manager）経由の呼び出しは例外とすることで、Fleet Manager Remote DesktopによるRDP接続（RDP録画付き）は許可しつつ、CLIからの直接的なポートフォワーディングは拒否できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPortSessionsExceptFleetManager",
      "Effect": "Deny",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession",
        "arn:aws:ssm:*:*:document/AWS-StartSSHSession",
        "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost"
      ],
      "Condition": {
        "ForAllValues:StringNotEquals": {
          "aws:CalledVia": ["ssm-guiconnect.amazonaws.com"]
        }
      }
    }
  ]
}

このポリシーにより、ユーザーがCLIからAWS-StartPortForwardingSessionやAWS-StartSSHSessionを指定しようとするとAccessDeniedエラーが発生します。一方、Fleet Manager Remote Desktop（ssm-guiconnect経由）からの接続は aws:CalledVia 条件により拒否されないため、RDP録画付きのRDP接続は引き続き利用可能です。

参考: Configuring IAM permissions for Remote Desktop – Fleet Manager Remote DesktopのIAMポリシー例（aws:CalledVia 条件の使用例）

ドキュメントの作成・変更権限の制限

さらに、ユーザーにssm:CreateDocumentやssm:UpdateDocumentの権限を付与しないことで、ログ記録設定のないカスタムドキュメントの作成を防止できます。(設定例は省略します)

まとめ

本記事では、Session ManagerとFleet Managerの接続バリエーションを洗い出し、それぞれのログ・録画記録状況を検証しました。

Session Managerの通信メカニズムを調査した結果、セッションドキュメントのタイプによってログ記録の可否が決まることがわかりました。Standard_Streamタイプ（対話型シェル）ではセッションログが記録されますが、Portタイプ（ポートフォワーディング、SSH over SSM）ではトンネル内部がSSH/RDPプロトコルで暗号化されるため、セッションログは記録されません。Fleet Manager Remote Desktopは内部的にPortタイプですが、RDP録画は別メカニズム（ssm-guiconnect）で記録可能です。

この「ログ記録の死角」に対処するには、ネットワーク設定面とIAM設定面の両方から対策を講じる必要があります。

  • ネットワーク設定面: プライベートVPC環境でインバウンドポートを開放せず、Session Managerを経由しない直接接続を遮断する
  • IAM設定面: IAMポリシーでPortタイプのセッションドキュメントを拒否し、CLIからのポートフォワーディングやSSH over SSMを防止する。Fleet Manager Remote Desktopは aws:CalledVia 条件で例外とし、RDP録画付きの接続は許可する

前回、前々回の記事で設定したセッションログ記録とRDP録画に加え、本記事で整理したネットワークとIAMの対策を組み合わせることで、すべての操作記録を取る環境を実現できます。

タイトルとURLをコピーしました