AWSの踏み台環境の考え方：監査・セッション記録・申請ベースアクセス — 何ができて何ができないか

本番サーバーへ「誰が・いつ・何をしたか」を証跡に残す。特権アクセス（踏み台）の設計は、セキュリティ監査でもっとも問われる領域のひとつです。AWSには従来型の踏み台ホストに加え、踏み台そのものを不要にするSystems Manager Session Managerという選択肢があります。本記事では4つのアクセス方式を、公式ドキュメントで確認した仕様に基づき「何ができて／何ができないか」まで正直に対比し、監査ログと申請ベース（Just-in-Time）アクセスの設計の勘所を整理します。

01踏み台の本質：閉じる境界と、残す証跡

特権アクセスの設計目的は突き詰めると2つです。ひとつは「攻撃面を閉じること」——本番インスタンスへのインバウンド（SSHの22番など）を可能な限り開かないこと。もうひとつは「証跡を残すこと」——誰が、いつ、どのサーバーに入り、何をしたかを改ざんできない形で記録することです。従来この2つを担ってきたのが踏み台ホスト（bastion / jump box）でした。しかし踏み台ホスト自体が公開エンドポイントであり、SSHキーの配布・ローテーション、OSパッチ、それ自体の監査という運用負債を抱えます。AWSでは、この負債を根本から減らせる選択肢が揃っており、まず全体像を押さえるのが出発点です。

024つのアクセス方式と、その得手不得手

AWS環境で本番ホストへ入る主な手段は4つあります。「従来型の踏み台ホスト（EC2＋SSH）」「Systems Manager Session Manager」「EC2 Instance Connect」「サードパーティPAM（特権アクセス管理）」です。それぞれ設計思想が異なり、優劣ではなく適材適所です。まずは意思決定のための一枚表で、できること・できないことを対比します。

03Session Managerが「できること」

現代のAWSでは、踏み台レスの既定手段としてSession Managerを置くのが合理的です。SSMエージェントがアウトバウンドでSystems Managerエンドポイントへ接続するため、セキュリティグループのインバウンドルールをゼロにできます。踏み台ホストもSSHキーも不要で、誰がどのノードに接続できるかはIAMポリシーで制御します。監査面では、セッション中に入力したコマンドとその出力をS3やCloudWatch Logsへ記録でき、過去30日間の接続レポートも生成できます。さらにセッションの開始・終了といったAPI操作はCloudTrailに記録され、EventBridge経由でSNS通知やLambda起動につなげられます。

# インスタンスはSSMエージェント＋IAMロール(AmazonSSMManagedInstanceCore)が前提
# インバウンド不要でシェルを開く
aws ssm start-session --target i-0123456789abcdef0

# 踏み台なしでRDP/DBへポートフォワード（内容はログに残らない点に注意）
aws ssm start-session \
  --target i-0123456789abcdef0 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3389"],"localPortNumber":["13389"]}'

04Session Managerが「できないこと」——監査の限界を正直に

ここがポジショントークになりやすい箇所です。Session Managerのセッションログは強力ですが、万能なキーロガーではありません。第一に、記録されるのは端末に出力（エコー）される入出力ストリームであり、セッション設定に依存します。パスワードのような機微情報は stty -echo で伏せられる——裏を返せば、キーストローク単位で全打鍵を確実に押さえる完全なロギングとは性質が異なります。第二に、ポートフォワードやSSHトンネルのセッションは内容が記録できません。SSHがTLSトンネル内を暗号化し、Session Managerは通り道（トンネル）に徹するためで、この場合CloudTrailに「誰がいつ開始したか」は残っても、トンネル内の通信は見えません。第三に、vimやlessのような全画面TUIはログが乱れやすく、EventBridgeもAPIを伴わないセッション内動作（exit など）は検知しません。コマンド許可リスト、画面録画、OSレベルの改ざん耐性ある監査が要件なら、auditd／sudoロギングやPAMの領域だと割り切るのが正しい設計です。

05監査ログの設計：分離と改ざん耐性

「記録できる」ことと「証跡として信頼できる」ことは別です。ログの出力先を運用アカウントと同居させると、特権を持つ運用者自身がログを消せてしまう——これはPoC・検証段階で必ず先に潰しておきたい落とし穴です。そこで、セッションログを集約するS3バケットは監査専用アカウントへ分離し、S3 Object Lock（WORM：Write Once Read Many）を有効化します。Compliance／Governanceの保持モードやリーガルホールドにより、保持期間内はオブジェクトの上書き・削除を防げます（ただし削除マーカーはWORM保護対象外である点に注意）。加えてKMSでの暗号化、CloudTrailの証跡もこの監査アカウントへ集約する構成にすると、記録主体と被監査主体を分離でき、証跡の信頼性が担保されます。

06申請ベース／Just-in-Timeアクセス

常時付与された特権は、それ自体がリスクです。理想は「必要なときだけ、承認を得て、時限で付与し、自動で失効する」——Just-in-Time（JIT）アクセスです。AWSネイティブでは複数の部品を組み合わせて実現します。承認フローはSystems Manager Change Managerが担い、変更テンプレートに必要な承認者・実行できるランブック・通知を定義し、変更リクエストの承認を経て操作を走らせます。権限の一時付与はIAMのAssumeRoleを軸に、信頼ポリシーの条件キー（MFA必須、送信元、時刻など）で絞り込みます。恒常的なガードレールはSCP（サービスコントロールポリシー）で組織全体に敷き、リソース側はタグベース（ABAC）で「このタグの環境にはこのロールだけ」と制御します。そして、承認フローが機能しない緊急時のためのブレークグラス（break-glass）用ロールを別途用意し、その使用は必ず高優先度で通知・監査する——ここまで含めて申請ベースの設計です。

07構成図：踏み台レス＋承認＋改ざん耐性ログ

ここまでの部品を1枚に落とすと次のようになります。運用者はIAM＋MFAで認証し、Change Managerの承認を経てSession Manager経由でプライベートサブネットのEC2へ接続します。EC2のセキュリティグループはインバウンドを一切開かず、セッションの入出力は監査アカウントのWORMバケットとCloudWatch Logsへ、API操作はCloudTrailへ流れます。

08設計の勘所と移行判断

結論として、現代のAWSでは踏み台レス（Session Manager）を既定に置き、SSMエージェント非対応のOS・機器やエンドポイント到達性を確保できないケースに限って従来型の踏み台ホストを残す、という切り分けが実務的です。踏み台を残す場合も、ネットワーク隔離・MFA必須・最小権限・改ざん耐性のあるログ保管という原則は共通です。EC2 Instance Connectは恒久SSHキーを排除できますが、セッション記録が標準では残らないため、監査要件が厳しい本番では単独運用を避け、記録手段とセットで検討します。深い統制（画面録画・コマンド許可リスト）が要件なら、AWSネイティブに固執せずPAMの導入を素直に評価します。

関連記事：マルチ/ハイブリッドクラウドを「ID」で束ねる考え方 ／ 踏み台の操作証跡・画面録画の仕組み