Config — 「あるべき姿」からのズレを見逃さない

前回の WAF は「リアルタイムで攻撃をブロック」という話でした。今回の Config は「リソースの設定が正しいか、継続的に監視して、ずっと見守る」という感じ。完全に違うアプローチです。CloudTrail との違いを理解するのが大事。CloudTrail は「誰が何をした」。Config は「その結果、リソースはどうなった」。

Config の基本仕組み

構成レコーダーという仕組みがあって、AWS API の変更を常に監視してます。EC2 起動した、セキュリティグループ変更した、S3 バケット作った。こういった変更を「スナップショット」として記録します。JSON 形式で S3 に保存されます。

このスナップショット。これが Config ルール評価の対象になります。「このセキュリティグループ、ポート 22 全開放されてる？」「この RDS、暗号化されてる？」こういうチェックが Config ルール。

重要な制約ね。Config はリアルタイム評価ではありません。変更トリガーで数秒以内には評価されるけど、「この瞬間に状態をチェック」ではなく「定期的に評価」という性格。デフォルト 24時間ごと。だから、セキュリティアラートには向かない。監視・継続的な状態管理向き。

ルール種別

マネージドルール。AWS が提供します。restricted-ssh（ポート 22 全開放検出）、required-tags（必須タグ確認）、そういったやつ。200 以上あります。

カスタムルール。Lambda で書きます。Python、Java、JavaScript 対応。「うちの API キーの形式 XYZ12345678 が S3 に保存されてないか検出」みたいな業界特有のルール。これは Lambda カスタムルール。

Guard という DSL もあります。JSON を評価する言語。Lambda より軽いし、バージョン管理もしやすい。最近は Guard を勧める人も多い。

適合パック

複数ルールをグループ化したテンプレート。CIS AWS Foundations Benchmark、PCI-DSS、HIPAA。こういった業界基準テンプレートが用意されてます。「CIS テンプレート適用」ボタン1つで、20個とか 30個のルールが一気に有効化される。

便利なんですが、覚えておく。テンプレートは CloudFormation スタックとして展開されます。だから、ルール削除したいときは CloudFormation から削除する。Config UI からは削除できない。これ、落とし穴。

自動修復

これが Config の本領。Non-Compliant なリソースを自動的に修正します。例えば、セキュリティグループでポート 22 が全開放されてる。Config がそれを検出。Lambda とか Systems Manager が自動実行。ポート 22 の全開放ルールを削除。完了。

だけどね。自動修復には順番があります。最初は「手動確認」モード。修復内容を確認してから、実行ボタンを押す。十分テストしたら「自動実行」に変更。ただし「削除」とか破壊的な修復は、絶対に手動のままにする。誤検知で重要なリソース削除されたら、大変。

Organizations との連携

複数アカウント。管理アカウントで「この Config ルール、全メンバーアカウントに適用」とか「この適合パック、全組織で共通」みたいに設定できます。新規アカウント作成されたら、自動的にそのルール適用される。規模が大きい組織では、これが必須。

委任管理者って制度があります。「このセキュリティチームに、全アカウントの Config ルール管理権を与える」みたいに。管理アカウント所有者じゃなくても、権限移譲できます。

アグリゲータ

複数リージョン・複数アカウントのデータを一箇所で見る。ただし、単一リージョンの Config では自アカウント・そのリージョンのデータしか見えない。複数リージョン検索したければ、アグリゲータ を作ります。

アグリゲータ作ると「全アカウント、全リージョン、非準拠リソースの一覧」をワンクリックで取得できます。SQL でクエリも撃てます。「非暗号化の RDS、すべてのアカウント・リージョンで何個？」こういうのが可能。

でもね。コスト増加します。アグリゲータ月額 0.5 ドル。小さい額に見えるけど、複数作ると積み重なります。本当に必要な場合だけ。

できないこと・制約

リアルタイム性。これね。重要。変更トリガーで数秒以内に評価されるけど、完全保証ではありません。リアルタイム警告が必要なら EventBridge 直結が必須。Config は「状態監視」用。

ルール数上限。単一アカウント 150 個。これ結構厳しい。大規模組織では 50 個超えることも。「あ、ルール上限に達しました」ってなるパターン。既存ルール整理してから追加する。

リソース読み取り権限が不足してると、スナップショット取得失敗します。IAM ロール、しっかり設定が必須。

試験ポイント

「Config ルールだけでは修復できない」って理解が大事。Config は「検出」。修復は「Systems Manager Automation」とか「Lambda」とか、別のサービス。

それから「マルチアカウントで何が可能か」。一発で管理アカウント・メンバーアカウント両方にルール適用。見た目はシンプルだけど、内部は複雑。Organizations SCP と組み合わせるときの相互作用も試験では狙われます。

「リアルタイムではない」という制約。これを理解してないと、「Config で即座に違反を検出」って思い込んでる人がいます。実際は遅延があります。

まとめ

Config は「継続的監視」の要。CloudTrail と一緒に使ってこそ、完全な監査証跡が完成します。CloudTrail で「誰が」を追跡。Config で「それ結果どうなった」を追跡。

次の講義は Secrets Manager、Parameter Store、ACM、CloudHSM。シークレット・証明書・暗号化キー管理の話。「何を使い分けるか」が試験のキーポイント。では次の動画で。