Systems Manager — Session Manager・Patch・Automation

AWS Systems Manager 概要

AWS Systems Manager（SSM）は、AWS リソースのリモートアクセス・パッチ管理・状態管理・自動化を統一的に行うサービスです。SCS-C03 試験では、特にセキュリティ視点での運用が問われます。従来の SSH/RDP とは異なり、IAM ポリシーで粒度高く制御でき、すべての操作ログをクラウドに記録できる点が核心です。

Session Manager フロー（SSH/RDP 不要なシェルアクセス）

Patch Manager ワークフロー

---

Systems Manager の構成要素（SCS-C03対象）

---

Session Manager — SSH/RDP のセキュアな代替

Session Manager が必要とされる背景

従来のリモートアクセス（SSH/RDP）の課題：

• ポート開放の手間と危険性：セキュリティグループで 22/3389 を開く必要があり、侵入の足掛かりになる
• 鍵管理の複雑性：EC2 キーペアの配布・回収・ローテーション
• 監査ログの欠落：シェルレベルの操作ログが残りにくい
• 認証スキーム統一の難しさ：SSH 公開鍵とIAM権限の乖離

Session Manager は IAM 認証のみでシェルアクセスを実現し、これらの課題を一掃します。

基本的な仕組み

IAM認証ユーザー → AWS Systems Manager Session Manager API → SSM Agent（EC2/On-premises に必須） → インスタンス内シェル起動 → ログ → S3/CloudWatch Logs

必須条件:

1. インスタンスに SSM Agent がインストール済み（Amazon Linux 2 など主要 AMI には標準搭載）
2. インスタンスに IAM ロールがアタッチされている
3. ロールに AmazonSSMManagedInstanceCore ポリシーがアタッチされている
4. ネットワーク疎通:
   • EC2 Instance Connect Endpoint を使用する場合は、プライベートサブネット内のインスタンスにも対応
   • NAT Gateway または VPC Endpoint（Systems Manager 用）経由での通信
5. Session Manager 利用に必要な IAM ポリシーをユーザーに付与

セキュアなアクセス制御：IAM ポリシー例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:StartSession",
        "ssm:TerminateSession"
      ],
      "Resource": [
        "arn:aws:ssm:us-east-1:123456789012:document/AWS-StartInteractiveCommand"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ec2:us-east-1:123456789012:instance/i-0123456789abcdef0"
      ],
      "Condition": {
        "StringEquals": {
          "ssm:resourceTag/Environment": "production"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "ssm:TerminateSession",
      "Resource": "*"
    }
  ]
}

注目ポイント：

• ssm:StartSession でドキュメントとインスタンス の両方を制御
• タグベースのアクセス制御（ABAC）で環境ごとに分離
• ssm:TerminateSession の Deny で、一度起動したセッションを終了できない特定ロールを作成可能

セッションログの記録と暗号化

Session Manager のすべての操作（コマンド入力・出力）をログ記録します。

CloudWatch Logs への記録

{
  "sessionId": "session-0123456789abcdef0",
  "documentName": "AWS-StartInteractiveCommand",
  "s3BucketName": null,
  "s3KeyPrefix": null,
  "cloudWatchLogGroupName": "/aws/ssm/session-logs",
  "cloudWatchEncryptionEnabled": true,
  "iamInstanceProfile": "AmazonSSMManagedInstanceCore",
  "outputs": ["cloudwatch"]
}

CloudWatch Logs にログを送信する際、KMS 暗号化を有効化すれば、ログ保存時に暗号化されます：

CloudWatch Logs → KMS キー（カスタマー管理キー推奨） → 暗号化保存

S3 への記録と監査

{
  "sessionId": "session-0123456789abcdef0",
  "documentName": "AWS-StartInteractiveCommand",
  "s3BucketName": "my-audit-bucket",
  "s3KeyPrefix": "ssm-logs/",
  "s3EncryptionEnabled": true,
  "outputs": ["s3"]
}

S3 に送信されたログは以下のように保存されます：

s3://my-audit-bucket/ssm-logs/
  ├── year=2026/month=04/day=27/
  │   └── {sessionId}-{timestamp}.zip

セキュリティベストプラクティス：

• S3 バケットに ブロックパブリックアクセス 設定
• バージョニング を有効化（意図しない削除防止）
• S3 Object Lock で WORM（Write Once Read Many）化
• CloudTrail で S3 アクセスも監視
• 暗号化キーを カスタマー管理キー（CMK） にして、CloudTrail で鍵使用を追跡

ポートフォワーディング：Session Manager 経由のプロキシ

Session Manager は標準的なシェルアクセスだけでなく、ポートフォワーディングもサポートします。

# ローカルマシンのポート 3306 を、リモートの MySQL（プライベートサブネット）に転送
aws ssm start-session \
  --target i-0123456789abcdef0 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3306"],"localPortNumber":["3306"]}'

このコマンド実行後、ローカルの localhost:3306 はリモートインスタンスの localhost:3306 にトンネリングされます。

使用例：

# リモートの RDS に接続（プライベートサブネット内）
aws ssm start-session \
  --target i-0123456789abcdef0 \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["database.123456789012.us-east-1.rds.amazonaws.com"],"portNumber":["3306"],"localPortNumber":["3306"]}'

# その後、ローカルで
mysql -h 127.0.0.1 -u admin -p

利点：

• NAT Gateway が不要（コスト削減）
• インスタンスのセキュリティグループで細かく制御可能
• ログに記録される
• 即座に切れる（セッション終了で自動的にポート転送も停止）

---

試験で狙われるポイント：Session Manager

❌ よくある誤解：

• Session Manager は「EC2 インスタンスのシェルアクセスだけ」だと思っている → ✅ ポートフォワーディング、RDS/プライベートリソースへのアクセスも可能
• SSM Agent が起動していれば、IAM ポリシーなしでもアクセス可能と思っている → ✅ IAM ポリシーが必須。Agent は認証の前段階にすぎない
• Session Manager のログは CloudWatch Logs だけと思っている → ✅ S3 に出力でき、複数出力先を同時指定可能

試験頻出問題パターン：

1. 「プライベートサブネット内の RDS に Session Manager 経由でアクセスしたい」 → ポートフォワーディング + インスタンスの IAM ロール + Parameter Store で接続情報管理
2. 「セッションログが改ざんされないようにしたい」 → S3 Object Lock + CloudTrail 監視 + CloudWatch Logs のカスタマー管理キー
3. 「特定ユーザーは本番環境へのセッションを禁止したい」 → IAM Deny ポリシー + タグベースのアクセス制御

できないこと：

• SSM Agent がインストールされていない/起動していないインスタンスには接続不可
• オフラインインスタンス（インターネット接続がなく VPC Endpoint もない）には接続不可
• Systems Manager の API 呼び出しにのみ IAM 権限で制御。インスタンス内のコマンド実行の細粒度制御は不可（OS レベルの制御が必要）

---

Patch Manager — 組織全体のパッチ管理

Patch Manager の位置付け

Patch Manager は、OS（Windows/Linux）およびアプリケーション（第三者製ソフトウェア）のパッチを一元的に管理・配布・コンプライアンス報告するサービスです。特に企業のセキュリティコンプライアンス で必須です。

パッチベースラインとは

パッチベースライン は「どのパッチを、いつ、どの条件で承認するか」を定義するテンプレートです。

{
  "Name": "Production-Servers-Baseline",
  "Description": "Critical and Important security patches for production",
  "ApprovalRules": {
    "PatchRules": [
      {
        "PatchFilterGroup": {
          "PatchFilters": [
            {
              "Key": "CLASSIFICATION",
              "Values": ["Security", "Bugfix"]
            },
            {
              "Key": "SEVERITY",
              "Values": ["Critical", "Important"]
            },
            {
              "Key": "PRODUCT",
              "Values": ["Windows Server 2022"]
            }
          ]
        },
        "ApproveAfterDays": 0,
        "EnableNonSecurity": false
      }
    ]
  },
  "GlobalFilters": {
    "PatchFilters": [
      {
        "Key": "PRODUCT",
        "Values": ["Windows Server 2022", "*"]
      }
    ]
  }
}

フィルター条件：

パッチグループとメンテナンスウィンドウ

パッチグループ は、EC2 インスタンスの論理グループです。タグで定義します。

インスタンスA（タグ: PatchGroup=web-servers）
インスタンスB（タグ: PatchGroup=web-servers）
インスタンスC（タグ: PatchGroup=database）

メンテナンスウィンドウ は、パッチが実行される時間枠を指定します。

{
  "WindowId": "mw-0123456789abcdef0",
  "Name": "ProductionPatchingWindow",
  "Schedule": "cron(0 2 ? * SUN *)",
  "Duration": 4,
  "Cutoff": 1,
  "AllowUnassociatedTargets": false,
  "Targets": [
    {
      "Key": "tag:PatchGroup",
      "Values": ["production"]
    }
  ],
  "TaskInvocationParameters": {
    "RunCommand": {
      "Parameters": {
        "Operation": ["Install"],
        "RebootOption": ["RebootIfRequired"]
      }
    }
  }
}

パラメータの意味：

• Schedule：Cron 式。cron(0 2 ? * SUN *) = 毎週日曜 02:00
• Duration：ウィンドウの継続時間（時間）
• Cutoff：ウィンドウの何時間前からパッチ実行を開始しないか。ここでは 1 時間前から新規パッチ実行を開始しない
• RebootOption：RebootIfRequired（必要に応じて再起動）か NoReboot（再起動なし）

カスタムパッチベースラインの例

デフォルトベースラインではなく、組織の要件に応じてカスタマイズします。

例：段階的なパッチ適用（Blue-Green）

{
  "Name": "BlueGreen-Staggered-Baseline",
  "ApprovalRules": {
    "PatchRules": [
      {
        "PatchFilterGroup": {
          "PatchFilters": [
            {
              "Key": "CLASSIFICATION",
              "Values": ["Security"]
            },
            {
              "Key": "SEVERITY",
              "Values": ["Critical"]
            }
          ]
        },
        "ApproveAfterDays": 0,
        "EnableNonSecurity": false
      },
      {
        "PatchFilterGroup": {
          "PatchFilters": [
            {
              "Key": "CLASSIFICATION",
              "Values": ["Security"]
            },
            {
              "Key": "SEVERITY",
              "Values": ["Important"]
            }
          ]
        },
        "ApproveAfterDays": 7,
        "EnableNonSecurity": false
      }
    ]
  }
}

戦略：

• Critical Security：即座に（ApproveAfterDays=0）
• Important Security：7 日間検証ウィンドウを置く
• 本番環境では Blue 環境で検証→Green 環境に展開

パッチの例外（Exceptions）

特定のインスタンスやパッチを除外できます。

{
  "PatchFilters": [
    {
      "Key": "PATCH_ID",
      "Values": ["KB5019945"]  // このパッチは除外
    }
  ],
  "InstanceIds": [
    "i-0123456789abcdef0"  // このインスタンスは除外
  ]
}

例外が必要な理由：

• 古い OS が互換性を失うパッチがある
• ベンダーが特定パッチとの非互換性を報告している
• 本番環境で特定パッチのテストが未完了

コンプライアンスレポートと監視

Patch Manager は、各インスタンスのパッチ適用状況をリアルタイムで追跡します。

aws ssm list-compliance-items \
  --filters Key=Status,Values=COMPLIANT \
  --compliance-item-filter-type PATCH_COMPLIANCE

出力例：

{
  "ComplianceItems": [
    {
      "ComplianceType": "Patch",
      "ResourceId": "i-0123456789abcdef0",
      "ResourceType": "ManagedInstance",
      "Id": "KB5019945",
      "Title": "Security Update for Windows Server 2022",
      "Status": "COMPLIANT",
      "Severity": "CRITICAL"
    }
  ]
}

コンプライアンスステータス：

• COMPLIANT：ベースラインで承認されたパッチがすべて適用済み
• NON_COMPLIANT：承認パッチが未適用
• UNSPECIFIED：互換性がない、または無視されるパッチ

---

試験で狙われるポイント：Patch Manager

❌ よくある誤解：

• Patch Manager は AWS-managed インスタンスにのみ対応と思っている → ✅ On-premises サーバーにも対応（SSM Agent インストール必須）
• メンテナンスウィンドウの Cutoff は「パッチ実行まで待機する時間」と思っている → ✅ 新規パッチの実行を開始しない時間。既に開始されたパッチは実行継続
• パッチベースラインは AWS が自動更新すると思っている → ✅ 手動で更新する必要がある。定期的に見直し、新しい分類を追加

試験頻出パターン：

1. 「本番環境のクリティカルパッチは即座に、重要度の低いパッチは 2 週間ウィンドウを置きたい」 → 複数の PatchRules を使用、ApproveAfterDays で段階化
2. 「特定のレガシーサーバーは KB12345 が互換性を失うので除外したい」 → PatchFilters の PATCH_ID で除外
3. 「日本時間で毎月第2木曜の 24:00 にパッチを当てたい」 → Cron 式で cron(0 15 ? * THU#2 *) を使用（UTC→JST の時差考慮）

---

Run Command — エージェント経由のコマンド実行

Run Command の基本

Run Command は、複数のインスタンスに対して、SSM Agent 経由で同時にコマンドを送信・実行・ログ記録 するサービスです。Session Manager の対話型シェルではなく、非対話的な一括実行 が特徴です。

コマンドドキュメント（Document）

Run Command はドキュメント（Document）というテンプレートを使用します。

{
  "schemaVersion": "2.2",
  "description": "Run a shell script",
  "parameters": {
    "commands": {
      "type": "StringList",
      "description": "Commands to run",
      "defaultValue": ["echo 'Hello'"]
    },
    "workingDirectory": {
      "type": "String",
      "description": "Working directory",
      "defaultValue": "/tmp"
    }
  },
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "runScriptLinux",
      "onFailure": "Continue",
      "inputs": {
        "commands": "{{ commands }}",
        "workingDirectory": "{{ workingDirectory }}"
      }
    }
  ]
}

AWS-RunShellScript（Linux）またはAWS-RunPowerShellScript（Windows）など、AWS が提供する標準ドキュメントを使うのが一般的です。

レートコントロール：同時実行数と成功率

aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["df -h"]' \
  --targets "Key=tag:Environment,Values=production" \
  --max-concurrency "50%" \
  --max-errors "10%" \
  --output-s3-bucket-name "command-logs" \
  --output-s3-key-prefix "run-command/"

パラメータの意味：

• --max-concurrency：同時実行インスタンス数。"50%" は対象インスタンスの 50%、"5" は 5 個固定
• --max-errors：許容エラー数。"10%" なら対象の 10% までエラーを許容
• 指定インスタンス数 100、max-concurrency=50% なら 50 個ずつ実行

実行フロー：

第1バッチ（インスタンス 1-50）を実行
    ↓
バッチ実行完了待機
    ↓
エラー数をチェック。10% 以下なら続行
    ↓
第2バッチ（インスタンス 51-100）を実行

出力先の指定と暗号化

aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["aws s3 ls"]' \
  --targets "Key=tag:Environment,Values=staging" \
  --output-s3-bucket-name "my-logs-bucket" \
  --output-s3-key-prefix "ssm-command-logs/" \
  --service-role-arn "arn:aws:iam::123456789012:role/SSMRunCommandRole" \
  --cloudwatch-output-config "CloudWatchLogGroupName=/aws/ssm/run-command,CloudWatchOutputEnabled=true"

出力先オプション：

• S3：出力結果を JSON または テキスト で保存。バージョニング＋Object Lock で改ざん防止
• CloudWatch Logs：リアルタイムモニタリング。KMS 暗号化対応
• 両方：同時指定可能

EventBridge 連携による自動化

Run Command の実行状況（成功・失敗）をイベントとして EventBridge に送信し、自動化トリガーができます。

{
  "Name": "SSMCommandFailureAlert",
  "EventPattern": {
    "source": ["aws.ssm"],
    "detail-type": ["EC2 Command Invocation Status-change Notification"],
    "detail": {
      "status": ["Failed"]
    }
  },
  "State": "ENABLED",
  "Targets": [
    {
      "Arn": "arn:aws:sns:us-east-1:123456789012:security-alerts",
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeSSMRole"
    }
  ]
}

ユースケース：

• Run Command 失敗時に SNS で即座通知
• 成功時に Lambda を トリガーして記録更新
• Config Rule 違反時に Run Command で自動修復（Automation と組み合わせ）

---

試験で狙われるポイント：Run Command

❌ よくある誤解：

• Run Command と Session Manager は同じだと思っている → ✅ Session Manager は対話型シェル。Run Command は非対話的な一括実行
• max-concurrency=100% なら全インスタンス同時実行と思っている → ✅ デフォルトの最大同時数は10 個（パラメータで上書き）
• CloudWatch Logs への出力はパラメータとしてドキュメント内に書くと思っている → ✅ AWS CLI または Management Console で指定

試験頻出パターン：

1. 「セキュリティアップデート確認コマンドを 100 台に対して 5 台ずつ実行したい」 → --max-concurrency "5"
2. 「1 台でも失敗したら残りの実行を中止したい」 → --max-errors "1" または "0%"
3. 「実行結果が改ざんされないようにログを保存したい」 → S3 + Object Lock + CloudTrail 監視

---

Automation — 自動修復と複雑ワークフロー

Automation の位置付け

Automation は、複数ステップからなる自動化ワークフロー（ランブック）を実行するサービスです。単なるコマンド実行ではなく、条件分岐、並列実行、ポーリング、承認ワークフローなどが可能です。

ランブックの構造

{
  "schemaVersion": "0.3",
  "description": "Auto-remediate non-compliant EC2 security group",
  "parameters": {
    "InstanceId": {
      "type": "String",
      "description": "The ID of the EC2 instance"
    },
    "ApprovalRole": {
      "type": "String",
      "description": "IAM role that approves the action",
      "default": "arn:aws:iam::123456789012:role/AutomationApprovalRole"
    }
  },
  "mainSteps": [
    {
      "name": "CheckComplianceStep",
      "action": "aws:executeScript",
      "onFailure": "Continue",
      "inputs": {
        "Runtime": "python3.8",
        "Handler": "check_sg",
        "Script": "def check_sg(events, context):\n    # Check if security group allows 0.0.0.0/0:22\n    return {'Compliant': False}"
      },
      "outputs": [
        {
          "Name": "ComplianceResult",
          "Selector": "$.Payload.Compliant",
          "Type": "Boolean"
        }
      ]
    },
    {
      "name": "WaitForApproval",
      "action": "aws:pause",
      "onFailure": "Continue",
      "inputs": {}
    },
    {
      "name": "RemediateSecurityGroup",
      "action": "aws:executeAwsApi",
      "inputs": {
        "Service": "ec2",
        "Api": "RevokeSecurityGroupIngress",
        "GroupId": "sg-0123456789abcdef0",
        "IpPermissions": [
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "IpRanges": [{"CidrIp": "0.0.0.0/0"}]
          }
        ]
      }
    }
  ]
}

ステップの種類：

Config Rule → SSM Automation の自動修復パターン

これは SCS-C03 で頻出の連携パターンです。

Config Rule：非準拠を検出
    ↓
SNS トリガー
    ↓
Lambda
    ↓
SSM Automation 実行
    ↓
自動修復（例：セキュリティグループの不適切なルール削除）

具体例：セキュリティグループの自動修復

Config Rule：

{
  "ConfigRuleName": "restricted-ssh",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "RESTRICTED_INCOMING_TRAFFIC"
  },
  "Scope": {
    "ComplianceResourceTypes": ["AWS::EC2::SecurityGroup"]
  }
}

Config が非準拠と判定した SecurityGroup に対して、Automation ランブックを起動：

# Config が非準拠を検出すると自動実行
aws ssm start-automation-execution \
  --document-name "Remediate-Unrestricted-SSH" \
  --parameters '{"SecurityGroupId":["sg-0123456789abcdef0"]}'

ランブック側の処理：

{
  "mainSteps": [
    {
      "name": "RevokeUnrestrictedSSH",
      "action": "aws:executeAwsApi",
      "inputs": {
        "Service": "ec2",
        "Api": "RevokeSecurityGroupIngress",
        "GroupId": "{{ SecurityGroupId }}",
        "IpPermissions": [
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "IpRanges": [{"CidrIp": "0.0.0.0/0"}]
          }
        ]
      }
    }
  ]
}

承認ワークフロー

本番環境での変更は、人の承認を必須にできます。

{
  "name": "WaitForApproval",
  "action": "aws:approveAwsServiceAction",
  "inputs": {
    "Notification": "Please approve the security group change",
    "Approvers": [
      "arn:aws:iam::123456789012:role/SecurityTeamApprovalRole"
    ],
    "ActionId": "{{ automation:EXECUTION_ID }}"
  }
}

フロー：

1. Automation 実行
2. aws:approveAwsServiceAction ステップで停止
3. SNS 経由で承認者に通知（事前にメールアドレスをサブスクライブ）
4. 承認者がコンソールまたはメールのリンクで承認
5. Automation 再開

クロスアカウント実行

複数の AWS アカウント全体に対して Automation を実行できます。

リソースベースポリシー例（受け取り側アカウント）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "ssm:StartAutomationExecution",
      "Resource": "arn:aws:ssm:*:222222222222:automation-definition/*",
      "Condition": {
        "StringEquals": {
          "ssm:resourceTag/SharedAutomation": "true"
        }
      }
    }
  ]
}

呼び出し側（アカウント A から B へ）：

aws ssm start-automation-execution \
  --document-name "arn:aws:ssm:us-east-1:222222222222:automation-definition/Remediate-SG:1" \
  --parameters '{"SecurityGroupId":["sg-0123456789abcdef0"]}' \
  --region us-east-1

---

試験で狙われるポイント：Automation

❌ よくある誤解：

• Automation ランブックはドキュメントと同じだと思っている → ✅ ドキュメント=テンプレート、Automation 実行=インスタンス（実際の実行）
• aws:pause ステップは自動で承認を待つと思っている → ✅ aws:pause は単にステップ停止。承認通知は aws:approveAwsServiceAction が必要
• aws:executeAwsApi と aws:executeAwsCommand は同じだと思っている → ✅ 前者は AWS API 直接呼び出し。後者は SSM Run Command を呼び出し

試験頻出パターン：

1. 「非準拠インスタンスを 1 時間待ってから自動修復したい」 → aws:sleep ステップを追加、Duration: "PT1H"
2. 「修復前に必ず人の承認を得たい」 → aws:approveAwsServiceAction + Approvers 指定
3. 「修復結果をログに記録したい」 → aws:executeScript で結果をカスタムパラメータに出力

---

Inventory と State Manager — 常時監視と状態強制

Inventory：リソース台帳の自動化

Inventory は、EC2 インスタンスのソフトウェア、設定、ネットワークメタデータを定期的に収集し、S3 に JSON で保存します。

{
  "ContentHash": "abcd1234",
  "InstanceId": "i-0123456789abcdef0",
  "InventoryType": "AWS:Application",
  "TypeName": "AWS:Application",
  "SchemaVersion": "1.0",
  "CaptureTime": "2026-04-27T10:30:00Z",
  "Content": [
    {
      "Name": "openssl",
      "Version": "1.1.1k",
      "Release": "1.amzn2",
      "Epoch": "0",
      "PackageType": "RPM",
      "Architecture": "x86_64"
    }
  ]
}

収集対象（メタデータ）：

Inventory の設定例：

{
  "Description": "Collect software and Windows updates",
  "InstanceInformationFilterList": [
    {
      "key": "tag:Environment",
      "valueSet": ["production"]
    }
  ],
  "TypesInformation": [
    {
      "TypeName": "AWS:Application",
      "SchemaVersion": "1.0"
    },
    {
      "TypeName": "AWS:WindowsUpdate",
      "SchemaVersion": "1.0"
    }
  ]
}

State Manager：望ましい状態の強制

State Manager は、インスタンスが特定の望ましい状態を常時保つよう強制します。SSM Document と組み合わせ、定期的に「ドリフト検出＆修復」を行います。

{
  "DocumentType": "Command",
  "Name": "ConfigureFileDefaults",
  "Description": "Enforce specific configuration files",
  "Parameters": {
    "TargetType": {
      "Type": "StringList",
      "Description": "Targets for the association",
      "DefaultValue": ["EC2 instances"]
    }
  }
}

Association（関連付け）の設定：

aws ssm create-association \
  --name "AWS-ConfigureAWSPackage" \
  --targets "Key=tag:Environment,Values=production" \
  --schedule-expression "rate(30 minutes)" \
  --parameters '{"action":["Install"],"name":["AmazonCloudWatchAgent"],"version":["latest"]}' \
  --output-s3-location "S3Location=s3://my-bucket/state-manager-logs/"

スケジュール式：

rate(30 minutes)        # 30分ごと
cron(0 2 ? * SUN *)     # 毎週日曜 02:00

State Manager の用途：

• CloudWatch Agent のインストール・更新
• セキュリティエージェント（antivirus 等）の常時有効化
• ログローテーション設定の強制
• OS 設定（NTP, DNS 等）の漂流防止

---

Parameter Store — セキュリティ視点での設定管理

SecureString によるシークレット保護

Parameter Store には 2 つのタイプがあります：

SecureString パラメータの作成：

aws ssm put-parameter \
  --name "/prod/db/password" \
  --type "SecureString" \
  --value "MyDatabasePassword123!" \
  --key-id "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012" \
  --description "RDS master password for production"

取得時：

aws ssm get-parameter \
  --name "/prod/db/password" \
  --with-decryption

セキュリティポイント：

• --with-decryption フラグで明示的に復号化
• CloudTrail に「キーの使用」が記録される
• IAM ポリシーで kms:Decrypt を制限

IAM ポリシー例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters"
      ],
      "Resource": "arn:aws:ssm:us-east-1:123456789012:parameter/prod/*"
    },
    {
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/*",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "ssm.us-east-1.amazonaws.com"
        }
      }
    }
  ]
}

パラメータポリシー：有効期限通知

Parameter Store のパラメータに ポリシー を設定し、有効期限切れ時に自動通知できます。

{
  "Type": "Expiration",
  "Version": "1.0",
  "Content": {
    "Rules": [
      {
        "Duration": {
          "Unit": "Days",
          "Value": 30
        },
        "TargetTemplate": "arn:aws:sns:us-east-1:123456789012:parameter-expiry-alerts"
      }
    ]
  }
}

設定方法：

aws ssm put-parameter-policy \
  --name "/prod/api-key" \
  --policy file://policy.json

効果：

• 30 日ごとに SNS で通知
• パラメータ値は自動更新されない（手動で更新が必須）
• Compliance レポートに「期限切れ」と表示

階層設計パターン

Parameter Store は / 区切りで階層構造を持たせ、整理できます。

/prod/db/host
/prod/db/port
/prod/db/password
/prod/app/api-key
/prod/logging/level
/staging/db/host
/dev/db/host

IAM ポリシーで階層ごとに制御：

{
  "Effect": "Allow",
  "Action": "ssm:GetParameter",
  "Resource": "arn:aws:ssm:*:123456789012:parameter/prod/*"
}

Application（EC2 起動スクリプト）での利用：

#!/bin/bash
DB_HOST=$(aws ssm get-parameter --name "/prod/db/host" --query 'Parameter.Value' --output text)
DB_PASSWORD=$(aws ssm get-parameter --name "/prod/db/password" --with-decryption --query 'Parameter.Value' --output text)

mysql -h $DB_HOST -u admin -p$DB_PASSWORD

---

試験で狙われるポイント：Inventory・State Manager・Parameter Store

❌ よくある誤解：

• Inventory は「クラウド上に存在するリソースの一覧」と思っている → ✅ インスタンス内のソフトウェア・ファイルを収集
• State Manager は「リソースの削除を防止する」と思っている → ✅ 設定ドリフトを検出・修復する。ファイルやパッケージの有無をチェック
• Parameter Store のセキュリティは KMS だけと思っている → ✅ IAM ポリシー + KMS + CloudTrail で多層保護

試験頻出パターン：

1. 「全インスタンスの CloudWatch Agent バージョンを把握したい」 → Inventory で AWS:Application 収集
2. 「CloudWatch Agent が常時最新バージョンに保たれているか確認したい」 → State Manager で AWS-ConfigureAWSPackage 30 分ごと実行
3. 「DB パスワードを安全に管理し、App 起動時に取得したい」 → SecureString + KMS + IAM ポリシー + CloudTrail 監視

---

実装上のベストプラクティス

1. SSM Agent の定期更新

{
  "Name": "KeepSSMAgentUpToDate",
  "DocumentName": "AWS-ConfigureAWSPackage",
  "Targets": [
    {
      "Key": "tag:ManagedBySSM",
      "Values": ["true"]
    }
  ],
  "ScheduleExpression": "rate(14 days)",
  "Parameters": {
    "action": ["Install"],
    "name": ["AmazonSSMAgent"],
    "version": ["latest"]
  }
}

2. セッションログの不変化

# S3 バケット設定
aws s3api put-object-lock-configuration \
  --bucket ssm-logs-bucket \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled"}'

aws s3api put-object-legal-hold \
  --bucket ssm-logs-bucket \
  --key "session-logs/*" \
  --legal-hold Status=ON

3. メトリクスベースのアラート

{
  "AlarmName": "SSMSessionTerminationRate",
  "MetricName": "SessionCount",
  "Namespace": "AWS/Systems Manager",
  "Statistic": "Sum",
  "Period": 300,
  "EvaluationPeriods": 1,
  "Threshold": 10,
  "ComparisonOperator": "GreaterThanThreshold",
  "AlarmActions": [
    "arn:aws:sns:us-east-1:123456789012:security-alerts"
  ]
}

4. ドリフト検出と修復の自動化

State Manager で検出したドリフトを、自動的に Automation で修復：

{
  "EventPattern": {
    "source": ["aws.ssm"],
    "detail-type": ["Association State-change Notification"],
    "detail": {
      "state": ["Failed"]
    }
  },
  "Targets": [
    {
      "Arn": "arn:aws:lambda:us-east-1:123456789012:function/TriggerAutomationRemedy",
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeRole"
    }
  ]
}

---

できないこと・制約

Session Manager の制約

• SSM Agent が起動していないインスタンスには接続不可
• インスタンスがオフライン状態（インターネット疎通がなく VPC Endpoint もない場合）には接続不可
• IAM ポリシーで拒否されたアクションは実行不可（インスタンス側での su/sudo 権限があっても IAM は上書き）
• インスタンス内でのOS レベルのコマンド実行制御は別途必要（SELinux、AppArmor 等）

Patch Manager の制約

• カスタムパッチベースラインは最大 100 個
• メンテナンスウィンドウは最大 10 個（アカウント/リージョン）
• パッチ実行中の再起動は避けられない（RebootOption で制御可能だが、再起動が必須なパッチは待機不可）
• サードパーティ製アプリのパッチ対応は限定的（OS パッチメインサポート）

Automation の制約

• ステップの最大数は 500 個
• ステップの最大実行時間は 3600 秒（必要に応じて複数 Automation に分割）
• 並列実行数制限あり（デフォルト 10、上限 100）
• クロスアカウント実行は追加の IAM 設定が必須

Parameter Store の制約

• 標準パラメータは最大 4 KB
• 高度なパラメータは最大 8 KB
• バージョン数無制限だが、古いバージョン削除は手動
• SecureString は KMS が必須（AWS managed key または customer managed key）

---

終章：Systems Manager を使った統合セキュリティ運用

Systems Manager の全機能を組み合わせた、企業規模のセキュリティ運用フロー：

1. Config Rule が非準拠検出
    ↓
2. EventBridge が Automation トリガー
    ↓
3. Automation が自動修復（例：セキュリティグループ設定）
    ↓
4. Run Command で修復確認コマンド実行
    ↓
5. Inventory で修復前後を記録
    ↓
6. State Manager で設定ドリフト監視
    ↓
7. Patch Manager で定期的なパッチ適用
    ↓
8. Session Manager で人的確認（必要に応じ）
    ↓
9. CloudTrail + Parameter Store で監査ログ保存

このエンドツーエンドの自動化により、人的介入を最小化しながらセキュリティ態勢を継続的に強化 できます。

---

試験での実践例

出題例 1：権限とセキュリティログ

問題： ユーザー Alice が本番 EC2 インスタンスに Session Manager で接続しようとしています。Alice は以下のポリシーを持っています：

{
  "Effect": "Allow",
  "Action": "ssm:StartSession",
  "Resource": "*"
}

この接続は成功しますか？（A）成功する（B）失敗する

答え： （B）失敗する

理由： IAM ポリシーで ssm:StartSession を許可していても、ドキュメント ARN がない。正しくは以下が必須：

{
  "Effect": "Allow",
  "Action": "ssm:StartSession",
  "Resource": [
    "arn:aws:ssm:*:*:document/AWS-StartInteractiveCommand",
    "arn:aws:ec2:*:*:instance/i-*"
  ]
}

出題例 2：パッチベースライン戦略

問題： 組織は本番環境で Critical セキュリティパッチを即座に、Important パッチを 2 週間後に適用したい。これを実現するコンフィグレーション方法は？

答え： 複数の PatchRules を持つ 1 つのベースライン（または 2 つのベースライン + メンテナンスウィンドウ）

{
  "ApprovalRules": {
    "PatchRules": [
      {
        "PatchFilterGroup": {
          "PatchFilters": [
            {"Key": "SEVERITY", "Values": ["Critical"]}
          ]
        },
        "ApproveAfterDays": 0
      },
      {
        "PatchFilterGroup": {
          "PatchFilters": [
            {"Key": "SEVERITY", "Values": ["Important"]}
          ]
        },
        "ApproveAfterDays": 14
      }
    ]
  }
}

出題例 3：Config + Automation 統合

問題： Config Rule で「セキュリティグループが 0.0.0.0/0:22 を許可していない」を検出した場合、自動的に修復したいです。実装は？

答え：

1. Config Rule の Remediation Actions で Automation ランブックを指定
2. ランブック内で aws:executeAwsApi アクション使用
3. ec2:RevokeSecurityGroupIngress API 呼び出し

---

参考：SCS-C03 適準試験での Systems Manager 関連問題は、セキュリティコンテキストでの自動化・監査・コンプライアンスにフォーカスされています。機能の使い方だけでなく、「なぜそれが必要か」「どのセキュリティリスクを低減するか」まで理解することが合格のカギです。