2026-03-23 Ops-JAWS Meetup39 Session Managerを使った セキュアなサーバーアクセス

Ops-JAWS Meetup39 あなたの推しのSSMは？SSM運用特集
https://opsjaws.connpass.com/event/383000/

Session Managerを使った セキュアなサーバーアクセスに関してのスライド。

Transcript

1. Session Managerを使った セキュアなサーバーアクセス OpsJAWS Meetup#39 2026-03-23
2. おまえだれよ 名前: すずきまさし/x:@masasuz/masasuzu 所属: 株式会社スリーシェイク シニアアーキテクト クラウドインフラ何でも屋さん すきなもの: AWS, Google Cloud, Terraform 2024-2025 AWS Community Builder Cloud Operations 2025 Japan All AWS Certifications Engineers Google Cloud Partner Top Engineer 2026 2
3. 目次 1. SSHによるEC2アクセスの課題 2. Session Managerの概要 3. Session Managerの機能 4. セキュリティ・統制上の注意点 5. さらなる統制へ: JITNA 6. まとめ 3
4. SSHによるEC2アクセスの課題 4
5. SSHによるEC2アクセスの課題 SSHキーの管理 — 漏洩リスク、共有問題、ローテーションの手間 踏み台ホストの運用 — 可用性確保、パッチ適用、コスト インバウンドポート22の開放 — 攻撃対象面の拡大 「誰がいつ何をしたか」の把握が難しい — 監査対応の負荷 → これらの課題を解決するのが Session Manager 5
6. Session Managerの概要 6
7. Session Managerとは AWS Systems Managerの一機能。EC2上のSSM AgentがSystems Managerに接続し、シェルア クセスを提供する ユーザー Systems Manager (AWS マネージドサービス) EC2インスタンス (SSM Agent) HTTPS/443 HTTPS/443 EC2からのアウトバウンド通信 ※ EC2へのインバウンドは不要 7
8. Session Managerの特徴 インバウンドポート不要（ポート22を閉じたまま運用） SSHキー・踏み台ホスト不要 IAMポリシーによるアクセス制御 TLS 1.3 による通信暗号化（KMS暗号化のオプションあり） 8
9. Session Managerの前提条件 SSM Agentのインストール・起動 Amazon Linux 2/2023、Ubuntu等の主要AMIにはプリインストール済み IAM Policy（ AmazonSSMManagedInstanceCore 等）の付与 DHMCでも可 アウトバウンド通信の許可（HTTPS/443） VPCエンドポイント経由でインターネット接続なしでも利用可能 9
10. Session Managerでできること ブラウザベースのシェル Systems Managerコンソール / EC2コンソールから起動 AWS CLIからのセッション開始 aws ssm start-session --target i-xxxxx ポートフォワーディング ローカルポート → RDS等プライベートリソースへの接続 SSH over SSM SSMをトランスポート層として利用（ProxyCommand） ※ SSHキーは引き続き必要 10
11. SSHとの比較 観点 SSH Session Manager 認証・鍵管理 SSHキー（要管理） IAMポリシー（鍵不要） ネットワーク ポート22のインバウンド必 要 不要（アウトバウンドのみ） 踏み台 必要 不要 セッションログ OS側で個別設定 S3/CloudWatch Logsに一元記録（通常セッションの み） 監査 独自に構築 CloudTrail + EventBridge連携 ポートフォワー ド ssh -L aws ssm start-session 料金 踏み台のコスト EC2接続は追加料金なし 11
12. CloudShellという選択肢 CloudShellをVPCに接続すると、VPC内のリソースに直接アクセスできる → VPC内リソースへの接続という目的ではSession Managerの代替になりうる 踏み台EC2が不要 — 統制上の理由がなければ構成がシンプルになる EC2の管理コスト（パッチ適用、SSM Agent管理等）を削減できる コンソールにログインしているプリンシパルの権限でコマンドを実行 Session Managerの場合はEC2のインスタンスプロファイルの権限を利用 Session Manager ローカルPC EC2（踏み台） SSM Agent RDS SSM CloudShell + VPC接続 ブラウザ CloudShell VPC接続（ENI） RDS HTTPS 12
13. CloudShellの制約 ただし制約もある: セッションログが取れない（Session Managerの通常セッションのようなログ記録機能が ない） セッションのタイムアウト（30分で切断） → ログや統制が求められる環境ではSession Managerが適切 13
14. Session Manager vs CloudShell + VPC接続（比較表） 観点 Session Manager CloudShell + VPC接続 目的 サーバーにログイン（シェルアクセス） AWS CLIを使う場所を得る 管理対象EC2 必要 不要 VPC内リソース ポートフォワーディングで接続 VPC接続（ENI作成）で直接接続 セッションログ 通常セッションは記録可能 記録不可 IAM統制 ドキュメント単位で制御可能 VPCアクセス可否のみ タイムアウト アイドルタイムアウト: 最大60分 30分で切断 実行権限 EC2のインスタンスプロファイル コンソールログイン中のプリンシパル 運用コスト EC2管理が必要 マネージド（管理不要） 14
15. Session Managerの機能 15
16. セッションログ Session Managerの通常セッションでは、コマンドの入出力をログとして記録できる Amazon S3 — セッション終了後にログファイルを保存（KMS暗号化オプションあり） Amazon CloudWatch Logs — セッション中のログをストリーミング送信 AWS CloudTrail — セッションの開始/終了等のAPI呼び出しを記録 Amazon EventBridge + SNS — セッション開始/終了をトリガーに通知 → 「誰がいつ何をしたか」をSSHより容易に把握できる ※ Session Manager設定で有効化が必要（デフォルトでは無効） 16
17. Run As（OSユーザー指定） デフォルトではSession Manager接続時のOSユーザーは ssm-user Run Asを有効にすると、接続先のOSユーザーを制御できる（Linux / macOSのみ） Session Managerの設定で「Enable Run As support for Linux instances」を有効化 OSユーザーの指定方法は2つ: Session Manager設定でデフォルトOSユーザー名を指定（全員共通） IAMユーザーまたはフェデレーテッドロールにタグ SSMSessionRunAs を付与し、値 にOSユーザー名を指定（個別制御） タグもデフォルト設定もない場合、セッション接続が失敗する（ssm-userへのフォール バックなし） → 共有アカウントの回避、操作の個人特定が可能になる 17
18. ポートフォワーディング SSMのセキュアチャネルを利用して、ローカルポートへの接続をリモートに転送する ローカルPC EC2インスタンス (SSM Agent) RDS等 (リモートホスト) SSMセキュアチャネル ローカルPFはここまで TCP接続 リモートホストPFはここまで到達 （EC2→RDS間のSG許可が必要） リモートホストポートフォワーディングでは、EC2を経由してRDS等のプライベートリソース に接続可能 リモートホスト自体がSystems Managerで管理されている必要はない 18
19. コマンド例: ローカルポートフォワーディング ローカルPC localhost:8080 EC2（Webサーバー） :80 SSMセキュアチャネル curl http://127.0.0.1:8080 → EC2のポート80に到達 EC2自身のポート80に接続する場合: aws ssm start-session \ --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters '{"portNumber":["80"],"localPortNumber":["8080"]}' 19
20. コマンド例: リモートホストポートフォワーディング ローカルPC localhost:13306 EC2 (SSM Agent) RDS (MySQL) :3306 SSMセキュアチャネル TCP/3306 ※ EC2→RDSのSGでTCP/3306の許可が必要 mysql -h 127.0.0.1 -P 13306 → EC2経由でRDSに到達 EC2経由でRDS（MySQL）に接続する場合: aws ssm start-session \ --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSessionToRemoteHost \ --parameters '{"host":["mydb.xxx.rds.amazonaws.com"], "portNumber":["3306"],"localPortNumber":["13306"]}' 20
21. SSH over SSM SSMのセキュアチャネルをSSHのトランスポート層として利用する ~/.ssh/config に ProxyCommand を設定することで、通常のSSHコマンドでSSM経由の接 続が可能になる Host i-* mi-* ProxyCommand sh -c "aws ssm start-session \ --target %h --document-name AWS-StartSSHSession \ --parameters 'portNumber=%p'" インバウンドポート22の開放が不要になる SSHキーは引き続き必要（SSM上にSSHを重ねるため、SSH認証はそのまま） SCPやSFTPも利用可能 セッションログは記録されない（SSHが暗号化するためSSMはトンネルとして機能する だけ） 21
22. セキュリティ・統制上の注意点 22
23. ただし、Session Managerにも注意点がある SSHの課題は解決するが、デフォルトのまま使うと統制に穴が残る セッションログが記録されないケースがある デフォルトのOSユーザーが実質root権限 ネットワーク制限をトンネルで迂回できてしまう → ここからは注意点と対策を見ていきます 23
24. 注意点1: セッションログが記録されない SSH over SSM / ポートフォワーディング経由のセッション 通常セッション ユーザー Systems Manager EC2 セッションログ ✔ 記録される SSH over SSM ユーザー SSH暗号化 Systems Manager (トンネルのみ) EC2 セッションログ ✘ 記録されない SSHが通信を暗号化するため、Systems Managerはデータの中⾝を参照できずトンネルとして機能するだけ 24
25. 注意点1: セッションログ（補足） SSH over SSM: SSHがデータを暗号化するため、SSMはトンネルとして機能するだけで コマンドの入出力を取得できない ポートフォワーディング: Session Managerはデータストリームのトンネルとして機能する だけで、転送データの内容を記録できない CloudTrailには接続の開始/終了のみ記録 操作内容・転送データの中身は記録されない 監査要件がある場合は通常セッションを優先すべき 通常セッションのログ出力先: S3バケット / CloudWatch Logs（Session Manager設定で有 効化） 25
26. 注意点2: ssm-userのデフォルト権限 Session Manager接続時のデフォルトOSユーザー ssm-user Linux: /etc/sudoers.d/ssm-agent-users に設定 ssm-user ALL=(ALL) NOPASSWD:ALL パスワードなしでsudo可能 = 実質root 対策 sudo権限の削除（ /etc/sudoers.d/ssm-agent-users を削除または編集） Session Manager設定の runAsEnabled でIAMユーザーごとにOSユーザーを指定 26
27. 注意点3: ポートフォワーディングによる迂回 プライベートサブネットのRDSはSGでEC2からのアクセスのみ許可し、 ユーザーのローカルPCからは直接到達できない構成が一般的 しかしSession Managerのポートフォワーディングを使うと EC2経由のトンネルでローカルPCからRDSに接続できてしまう （EC2→RDS間はSGで許可済みのため、トンネルを通った通信も許可される） ユーザー SSM PF EC2 プライベートサブネット（SG/NACLで制限） RDS 内部API 管理画⾯ 27
28. IAMポリシーによる制御 不要な機能はIAMポリシーで 明示的にDeny する ssm:StartSession アクションに対して、以下のドキュメントをリソースとして指定する 制限対象 ドキュメント名 SSH over SSM AWS-StartSSHSession ローカルPF AWS-StartPortForwardingSession リモートホストPF AWS-StartPortForwardingSessionToRemoteHost SSH over SSMのDenyは注意点1（ログが記録されない問題）の対策にもなる 通常のSession Managerセッションは引き続き利用可能 SCP（Service Control Policy） で組織全体に適用も可能 28
29. IAMポリシー例 Denyは既存のAllowより優先されるため、追加するだけでOK { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ssm:StartSession", "Resource": [ "arn:aws:ssm:*:*:document/AWS-StartSSHSession", "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession", "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost" ] } ] } 29
30. さらなる統制へ: JITNA 30
31. さらなる統制へ: Just-In-Time Node Access (JITNA) IAM Denyで機能は制限できるが、許可されたユーザーは常時アクセス可能という課題が残る → JITNAは ゼロ常設権限（Zero Standing Privileges） を実現する 従来 IAM権限あり いつでも接続可能 ← 常時アクセス可能 JITNA リクエスト 承認 通知: メール / Slack / Teams （Slack/TeamsはAmazon Q Developer経由） ⼀時トークン 接続 31
32. JITNA の主な特徴 承認ポリシー（ノード単位で設定） ポリシー 動作 Deny-access アクセスを拒否（最優先） Auto-approval 自動承認（リクエスト即時許可） Manual 承認者が手動で承認/拒否 手動承認の場合、メール / Slack / Microsoft Teams で承認者に通知される （Slack/TeamsはAmazon Q Developer経由） 32
33. JITNA の主な特徴 監査 アクセスリクエストには理由の記録が必須 リクエスト履歴は 1年間保持 導入 既存Session Managerと並行運用しながら段階的に移行可能（既存リソースに変更なし） 移行時に ssm:StartSession 権限を ssm:StartAccessRequest / ssm:GetAccessToken に置き換える 前提条件: 統合コンソール、AWS Organizations 料金: 30日間無料トライアルあり、以降有料 33
34. まとめ 34
35. まとめ SSHの課題（鍵管理・踏み台・ポート開放・監査）を Session Managerで解決 できる ただし デフォルトのままでは統制に穴がある — 注意点を把握して使おう 不要な機能は IAMポリシーで明示的にDeny して統制を効かせる さらに統制を強めるなら JITNA で承認ワークフローを導入 35
36. ありがとうございました 36
37. 参考リンク Session Manager Session Managerのログ記録 ssm-userのアクセス許可 SSH接続の有効化と制御 ポートフォワーディングセッションの開始 Just-In-Time Node Access AWS CloudShell 37