Systems Manager活用 — Session Manager/Patch/Automation

SSHの穴を塞ぎ、踏み台を捨て、パッチと運用オペを統制下に置く。AWS Systems Managerを「監査に耐える運用基盤」として設計するための実務ポイントを、現場目線でまとめました。

AWS Systems Manager(SSM)は「便利ツールの寄せ集め」に見えて、実態は運用と統制のプラットフォームです。踏み台の廃止、パッチの標準化、手作業オペのコード化、設定値の一元管理まで、SSMを軸に据えると監査部門への説明が一気に楽になります。本記事はエンタープライズでSSMを本気で使うための設計勘所と落とし穴を、機能ごとに整理します。

01なぜいまSSM前提の運用なのか

従来のEC2運用は、パブリックサブネットに踏み台(Bastion)を置き、SSH鍵を配り、セキュリティグループで22番を絞る、という構成が定番でした。これには構造的な弱点があります。踏み台自体がパッチ対象になり、SSH鍵の配布・失効が属人化し、「誰がいつ何を実行したか」の記録が残りにくい。監査のたびに鍵管理台帳を突き合わせる作業が発生します。

SSMはこの前提を反転させます。管理対象ノードにインストールされたSSM AgentがSSMサービスへアウトバウンドで接続するため、インバウンドのSSHポートを開ける必要がありません。アクセス制御はSSH鍵ではなくIAMポリシーに寄せられ、操作記録はCloudTrailやCloudWatch Logsに残ります。つまり「ネットワーク境界での防御」から「IDと記録による統制」へ移行できるわけです。

現場のコツ：SSMを使う大前提は「Agentがオンラインで、必要なIAM権限とネットワーク到達性があること」です。プライベートサブネットのノードは、NATゲートウェイ経由か、ssm/ssmmessages/ec2messagesのVPCエンドポイント(PrivateLink)を用意します。閉域要件が強い環境では後者が定石です。

02Session Manager — SSH廃止と監査

Session Managerは、インバウンドポートを開けず、踏み台もSSH鍵も持たずにシェルアクセスを提供するSSMの中核機能です。ブラウザのワンクリックかaws ssm start-sessionで接続でき、Windows/Linux/macOSを単一ツールで扱えます。AWS公式も「インバウンドポートを開けず、踏み台やSSH鍵の管理から解放され、セキュリティ態勢を改善できる」と明言しています。

統制の観点で重要なのは次の3点です。

IAMによる集中アクセス制御：誰がどのノードにセッションを張れるかをIAMポリシーで管理します。オンコール担当に「当番の期間だけ本番へ」といった一時的付与も設計できます。
セッションログの記録：セッション内で実行したコマンドやその出力を、S3バケットやCloudWatch Logsに保存できます。KMSキーによる暗号化も可能です。API呼び出し自体はCloudTrailに残ります。
公開IP不要・PrivateLink対応：VPCエンドポイントを使えば、ノードが公開IPを持たなくても、通信をAWSネットワーク内に閉じたまま接続できます。

現場のコツ：ポートフォワーディングやSSHトンネル経由のセッションは、SSMがTLSトンネルとして振る舞うだけなのでコマンド内容がセッションログに残りません(公式のNoteに明記)。RDSへのポートフォワードなど便利ですが、「証跡が欲しい操作」は素のインタラクティブセッションで実施する、と運用ルールで切り分けるのが安全です。

監査要件が厳しい現場では、セッションログをS3に集約し、KMSで暗号化、EventBridge+SNSで「本番ノードへのセッション開始」を通知、という3点セットを標準化しておくと、監査対応が定型作業になります。IAM設計の基本はIAM最小権限の現実も併せてご覧ください。

図：踏み台+SSH構成と、SSM Session Managerによる踏み台レス構成の比較。SSMではAgentがアウトバウンドで接続し、インバウンドポートを開けない。

03Patch Manager — パッチ適用の統制

Patch Managerは、OSやアプリケーションのパッチ適用(スキャン/インストール)を自動化する機能です。中心概念はパッチベースラインで、これは「どのパッチを承認・拒否するか」のルール集合です。OS種別ごと(RHEL/Amazon Linux/Windows Serverなど)に、リリースから何日後に自動承認するか、明示的な承認・拒否リストをどうするか、を定義します。

適用方法は主に3系統です。用途で選びます。

方式	向いている場面	統制のしやすさ
パッチポリシー(Quick Setup)	Organizations全体で標準を横展開したい	高。アカウント/リージョン横断で一元管理
メンテナンスウィンドウ	「日曜2時に対象群を順次パッチ」など時間制御が要る	中〜高。スケジュールと並列度を細かく制御
Patch now(オンデマンド)	緊急CVE対応・単発検証	低。恒常運用には不向き、記録は残る

内部的にはAWS-RunPatchBaselineというSSMドキュメントが実行され、スキャンのみ(Scan)かスキャン&インストール(Scan and install)を選べます。適用前後にフックを挟めるAWS-RunPatchBaselineWithHooksもあり、アプリ停止→パッチ→起動→ヘルスチェック、といった手順を組めます。

現場のコツ：いきなり全台Scan and installは事故のもとです。まず全台Scanだけ回してコンプライアンス状況を可視化し、パッチグループ(タグPatch Group)で段階リング(dev→staging→本番の一部→本番全体)を切り、リングごとにメンテナンスウィンドウをずらすのが定石です。承認遅延日数(auto-approval delay)を本番リングだけ長めに取ると「枯れてから当てる」運用になります。数値・上限はバージョン依存のため公式で最新を確認してください。

04Run Command — 一斉オペレーションの標準化

Run Commandは、SSMドキュメントを対象ノード群へ一斉実行する機能です。「全Webサーバーで設定ファイルを更新して再起動」「特定タグのノードでログを収集」といった作業を、SSHで1台ずつ入らずに実行でき、実行結果はコンソール/CloudWatch Logs/S3に残ります。

ポイントはターゲット指定をタグベースにすることです。インスタンスIDの列挙ではなくtag:Role=webのような指定にすれば、オートスケールで入れ替わるノードにも追随します。実行の並列度(concurrency)とエラーしきい値(error threshold)を設定すれば、「50%失敗したら止める」「一度に25%ずつ」といった安全弁を効かせられます。

現場のコツ：Run Commandはインタラクティブ性がない分、監査に強い(誰が・どのドキュメントを・どのパラメータで実行したかが構造化されて残る)。恒常的な定型オペはSession Managerで手打ちするより、Run Command用のカスタムSSMドキュメントに落として承認フローを付ける方が、統制と再現性の両面で優れます。

05Automation — 手順のコード化と自己修復

Automationは、複数ステップの運用手順をランブックとしてコード化し、条件分岐・承認・待機を含むワークフローとして実行する機能です。Run Commandが「1コマンドの一斉実行」なら、Automationは「一連の運用手順の自動化」です。AWSが多数の定義済みランブック(AWS-*)を提供しており、自作もできます。

実務での主な使いどころは次の通りです。

ゴールデンAMIの定期作成：起動→パッチ適用→検証→AMI作成→古いAMIの棚卸し、を無人で回す。
自己修復：EventBridgeやCloudWatchアラームを起点にランブックを起動し、「ディスク使用率超過でクリーンアップ」「非準拠リソースの是正」を自動化。監視・アラート設計と組み合わせると効果的です。
承認付きオペ：本番へのステップ実行前にaws:approveで承認待ちを挟み、承認者と実行履歴を証跡化する。

ランブックはIAMロールの権限で動くため、Automation用ロールの権限設計が統制の要になります。ランブックが実行できる操作＝そのロールで許可された操作、という原則を崩さないことが重要です。

図：アラームやイベントを起点に、Automationランブックが診断・是正・検証を無人実行する自己修復パターン。実行はIAMロール権限の範囲に限定される。

06Parameter Store — 設定値と軽量シークレット

Parameter Storeは、設定データや軽量なシークレットを階層構造で安全に保存する機能です。/prod/app/db/hostのようなパス設計ができ、SecureString型でKMS暗号化した値も扱えます。EC2/ECS/Lambdaから実行時に参照でき、IAMでパス単位のアクセス制御が可能です。

選定でよく迷うのがSecrets Managerとの使い分けです。判断軸はシンプルです。

自動ローテーションが要るか：RDS認証情報など定期ローテーションが必要ならSecrets Manager。
コストと量：大量の設定値・フラグ・エンドポイントは、標準パラメータが無料枠内で扱えるParameter Storeが有利。
クロスアカウント共有や高スループット：要件次第でSecrets Manager、あるいはParameter Storeのadvancedパラメータを検討。

この使い分けはSecrets Manager vs Parameter Storeで詳しく掘り下げています。暗号化キーの設計はKMS暗号化設計も参照してください。

現場のコツ：パスの命名規約を最初に決めることが最重要です。/{env}/{app}/{component}/{key}のように環境を先頭に置くと、arn:aws:ssm:...:parameter/prod/*のようなIAM条件で「本番パラメータは本番ロールだけ」を綺麗に表現できます。命名が崩れると後からIAMで統制できなくなります。

07Inventory — 資産の可視化とドリフト検知

Inventoryは、管理対象ノードのメタデータ(インストール済みアプリケーション、ネットワーク構成、Windowsの更新プログラム、AWSコンポーネント、指定ファイルなど)を定期収集する機能です。AWS-SetupInventoryランブックでアソシエーションを作成すると、スケジュールに従って各ノードから情報が集まります。

収集データはS3に集約してAthenaでクエリできます。「特定バージョンのライブラリが入っているノードを全アカウント横断で洗い出す」といった、脆弱性対応やライセンス棚卸しで威力を発揮します。State Manager(アソシエーション)と組み合わせれば、望ましい状態からのドリフトを継続検知する運用も作れます。マルチアカウントでの集約はマルチアカウント統制の考え方と地続きです。

現場のコツ：Inventoryは「収集して終わり」になりがちです。S3集約→Athena→定期レポート、までを最初に組んでおかないと、いざCVE対応で「影響台数を出せ」と言われた時に手作業になります。監査で必ず問われる「資産一覧の鮮度」を、Inventoryの収集スケジュールで担保する設計にしておきましょう。

08踏み台レス運用への移行と落とし穴

SSM前提運用への移行は、機能を有効化すれば終わりではありません。現場で詰まりやすいポイントを挙げます。

Agentとネットワーク到達性：Agentが古い/停止している、あるいはssm/ssmmessages/ec2messagesへの到達性がない(NATもエンドポイントもない)と、そもそも管理対象になりません。まず「マネージドノード一覧に全台出るか」を確認します。
IAMロールの付与漏れ：インスタンスプロファイルにAmazonSSMManagedInstanceCore相当の権限がないノードは接続できません。新規AMI/起動テンプレートに組み込んでおきます。
ログの取り漏らし：セッションログのS3/CloudWatch出力を有効化していないと、監査時に「証跡なし」になります。前述の通りポートフォワード経由は記録されない点も要注意です。
組織レベルの統制：SCPで「Session Managerのログ設定を無効化させない」「特定リージョン以外を禁止」といったガードレールを敷くと、アカウント横断で緩みを防げます(Organizations SCPガードレール参照)。

移行の進め方としては、(1)全台Agent導入と到達性確保、(2)Session Managerで踏み台を段階的に停止、(3)Patch Managerをまずスキャンで導入、(4)定型オペをRun Command/Automation化、(5)Parameter Store/Inventoryで設定と資産を可視化、の順が安全です。既存の踏み台をいきなり消さず、SSM併用期間を設けて切り替えるのが実務的です。

—まとめ

Systems Managerは、Session Managerで「ネットワーク境界の防御」から「IDと記録による統制」へ運用を移し、Patch Manager/Run Command/Automationで作業を標準化・コード化し、Parameter Store/Inventoryで設定と資産を可視化する、一貫した運用基盤です。個別機能を単発で使うのではなく、「踏み台レス＋監査＋統制」という設計思想で束ねると、監査対応が定型化し、運用の属人性が落ちます。

まず着手すべきは、全ノードをマネージド状態に揃え、Session Managerのログ出力を標準化すること。そこから段階的にパッチ・オペ・設定・資産へ広げていくのが、事故を起こさない移行の王道です。設計の全体像はクラウド設計ガイドラインも併せてご覧ください。

—参考(一次情報)

SSM前提の踏み台レス運用や統制設計でお困りなら、お問い合わせください。既存環境の棚卸しから移行設計まで支援します。

相談する

← ブログ一覧へ戻る