Systems Manager — SSHなしでサーバーを管理する世界

Systems Manager について今回は深く掘り下げます。一種の「統合運用フレームワーク」ですね。

Systems Manager が必要な背景

従来の SSH/RDP アクセスの問題って何だったか。セキュリティグループで「22 番ポート開く」必要があります。その時点で侵入の足掛かりが生まれちゃう。

それで Session Manager ですよ。SSH なし、RDP なし。IAM 認証だけ。全操作がログに記録される。つまり、セキュリティグループを一切触らなくていい。

Session Manager の仕組み

IAM 認証 → Systems Manager API → SSM Agent（EC2内）→ シェル起動 → ログ出力（S3 / CloudWatch Logs）

必須条件：

1. インスタンスに SSM Agent がインストール（Amazon Linux 2 は標準）
2. IAM ロール + AmazonSSMManagedInstanceCore ポリシー
3. ネットワーク疎通（VPC Endpoint または NAT Gateway）
4. IAM ポリシーで StartSession 許可

IAM ポリシーの落とし穴

よくある誤解として、「ssm:StartSession を Allow すれば OK」と思ってる人がいます。

でも実際には、ドキュメント ARN とインスタンス ARN の両方 を Resource に指定する必要あります。

さらに、タグベース制御（ABAC）で「prod タグだけ許可」みたいな条件も可能。

セッションログの不変化

ここ重要。Session Manager のログを S3 に出力できます。その時 Object Lock で WORM（Write Once Read Many）化すると、誰も削除・改ざんできない。

CloudTrail で「ログが削除された」という操作まで記録されます。つまり、完全な監査証跡が確保できます。

ポートフォワーディング

Session Manager はシェルアクセス以外も可能。ポートフォワーディングですね。

例えば、プライベートサブネット内の RDS に Session Manager 経由でアクセスします。その後、ローカルの mysql コマンドで localhost:3306 に接続すると、リモートの RDS に接続されます。

NAT Gateway が不要。コスト削減。即座に切断可（セッション終了で自動）。

Run Command — 非対話的一括実行

これと Session Manager は異なります。Session Manager は「対話型シェル」。Run Command は「一括実行」。

例えば「100台の EC2 に security update を実行」という場合、Run Command で実行します。

—max-concurrency “50%” ——対象の50%ずつ実行。—max-errors “10%” ——10%までエラー許容。

Patch Manager — 組織全体のパッチ戦略

Patch Manager の核が「ベースライン」。つまり「どのパッチを、いつ承認するか」のテンプレート。

例えば本番環境なら：

• Critical Security：ApproveAfterDays = 0（即座）
• Important Security：ApproveAfterDays = 7（検証期間）
• Bugfix：ApproveAfterDays = 14

パッチグループは EC2 のタグで定義。例えば PatchGroup=web-servers タグを持つインスタンス全部に一括適用。

メンテナンスウィンドウで「毎週日曜 02:00 UTC に実行」と指定します。

Patch Manager の落とし穴

よくある誤解。「メンテナンスウィンドウの Cutoff は『パッチ実行まで待機する時間』」と思ってる人がいます。

実際には、「その時間から新規パッチ実行を開始しない」 という意味。既に開始されたパッチは完了まで実行継続。

つまり、ウィンドウが 02:00～06:00 で Cutoff = 1時間なら、05:00 以降は新規パッチ実行なし。ただし 04:00 に開始したパッチは 05:30 まで実行続きます。

Automation — 複雑ワークフロー

これは「ランブック」という概念。つまり複数ステップの自動化手順。

例えば：

1. 検査（Security Group を確認）
2. 承認待機（SNS で人に通知）
3. 修復（不適切なルール削除）
4. 検証（接続テスト）
5. レポート（CloudWatch Logs に記録）

Config Rule と連携：「非準拠を検出 → Lambda → Automation 実行」という自動修復パイプライン。

DLQ（Dead Letter Queue）を併設して、修復失敗時は SQS に保留。セキュリティチームが後で確認。

Parameter Store — シークレット管理

DB パスワード、API キー、設定値を一元管理。

SecureString タイプなら KMS で暗号化。—with-decryption フラグで復号化時に CloudTrail 記録。

階層構造で IAM ポリシーで Resource: “arn:aws:ssm::123456789012:parameter/prod/” と指定すれば「/prod 配下のみアクセス」。

パラメータポリシーという機能で「30日ごとに SNS で有効期限通知」も可能。

Inventory と State Manager

Inventory は「インスタンス内のソフトウェア・ファイルの棚卸し」。EC2 に CloudWatch Agent をインストールしたバージョン、インストール済みパッケージ一覧などを自動収集。

State Manager は「望ましい状態の強制維持」。例えば「CloudWatch Agent は常に最新版」と定義すれば、30分ごとにチェックして古かったら自動更新。

ドリフト検出機能で「設定ファイルが勝手に変更された」ことに即座に気づけます。

Systems Manager の統合フロー

実運用ではこんな流れ：

1. Config Rule が「セキュリティグループが 0.0.0.0/0:22 を許可」と検出
2. EventBridge が Automation トリガー
3. Automation が自動修復（インバウンド削除）
4. Run Command で修復確認
5. Inventory に修復前後を記録
6. State Manager で設定ドリフト監視
7. Patch Manager で定期パッチ適用
8. CloudTrail で全操作を監査ログ化

つまり、「人的介入を最小化しながら、セキュリティ態勢を継続的に強化」——これが本番環境のやり方です。

試験で狙われるポイント

必出：Session Manager の IAM ポリシーに「ドキュメント ARN とインスタンス ARN の両方」が必須。

必出：Patch Manager の Cutoff は「新規パッチ開始を禁止する時間」。

よく出る：Automation の DLQ で修復失敗を保留し、手動確認。

できないこと

SSM Agent が起動していないインスタンスには接続不可。オフラインインスタンスも無理。

IAM ポリシーで Deny されたら Session Manager も起動不可。つまり、IAM レイヤーが最高権限。

インスタンス OS レベルのコマンド実行制御（SELinux、AppArmor）は別途必要。

まとめ

Systems Manager は「運用のワンストップショップ」。

Session Manager で SSH 不要。Patch Manager で一括パッチ。Automation で複雑ワークフロー。Parameter Store でシークレット管理。

これらすべてが IAM で統一的に制御されます。つまり、完全な監査証跡と権限管理が実現する——これが SCS-C03 のキーテイクアウェイです。