第1章：CNAPPを軸にAWS Configを理解する
本章では、CNAPP（Cloud Native Application Protection Platform）の考え方を整理した上で、
AWSにおいて AWS Config がどの領域を担うサービスなのか を明確にします。
AWSでは単一サービスでCNAPPを実現することはできません。
そのため、本記事では 「CNAPPを構成する各要素の中で AWS Config が果たす役割」 に焦点を当てて整理していきます。
1.1 CNAPPとは何か（AWSサービスで分解する）
CNAPPとは、クラウドネイティブ環境におけるセキュリティを包括的に保護するための概念であり、
以下のような複数のセキュリティ領域を横断的にカバーします。
- CSPM（設定不備の検出）
- CWPP（ワークロード脆弱性の検出）
- CIEM（IAM権限管理）
- DSPM（データセキュリティ）
- CDR（検知・対応）
AWSではこれらを 複数のマネージドサービスの組み合わせ によって実現します。
CNAPPは「製品名」ではなく、「設計思想・運用モデル」である点が重要です。
1.2 AWS Config が担う CNAPP 領域
AWS Config は、クラウド環境の 設定状態を記録し、評価し続けるサービス です。
CNAPPの中では明確に CSPM（Cloud Security Posture Management）領域 に位置付けられます。
具体的には以下を実現します。
① 設定の継続記録（Configuration History）
- どのリソースが
- いつ
- どのように変更されたか
を履歴として保持します。
これは監査・インシデント調査の基盤になります。
② ルール評価（Config Rules）
例えば：
- S3がパブリック公開されていないか
- EBSが暗号化されているか
- CloudTrailが有効化されているか
- Security Groupが0.0.0.0/0を許可していないか
といった “あるべき姿”との比較評価 を継続実行します。
③ 組織全体の標準化（Organizations + Aggregator）
マルチアカウント環境では、
- 全アカウントへ標準ルール配布
- 準拠状況の横断可視化
- 逸脱の集中管理
といった 統制基盤 として機能します。
CNAPPにおける「統合的可視化」の土台は、実はConfigの記録データです。
1.3 CNAPP視点で見た AWS Config の重要性
Amazon InspectorやGuardDutyは「検知」に強いサービスです。
しかし、CNAPPの観点で考えると重要なのは次の問いです。
そもそも“危険な状態”を作らなければよいのでは？
多くのクラウド事故は、
- S3公開設定ミス
- IAM過剰権限
- 暗号化未設定
- ログ未取得
といった 設定不備 から発生します。
AWS Configは、これらを 事前に、継続的に、機械的に検出する仕組み を提供します。
つまり、
- Inspector：脆弱性を見つける
- GuardDuty：侵害を検知する
- Config：事故の“種”を見つける
という役割分担になります。
CNAPP運用では、
「検知後に対応する」だけでなく、
「逸脱を起こさせない構造を作る」ことが成熟度の指標 になります。
その起点が AWS Config です。
第2章：AWS Configの仕組みをCNAPP運用として理解する
2.1 AWS Configの全体アーキテクチャ
AWS Configは単なる「設定チェックツール」ではありません。
CNAPP運用においては、設定状態を継続的に記録し、評価し、統制する基盤 として機能します。
内部構造は大きく4つのコンポーネントで構成されます。
① Configuration Recorder（記録機能）
- 対象リソースの設定変更を記録
- 作成・更新・削除のタイミングでConfiguration Item（CI）を生成
- 「全リソース記録」または「対象タイプ限定」が選択可能
ここで重要なのは、
記録していないリソースは、評価もできない
という点です。
CNAPP観点では、記録設計＝統制設計 と言えます。
② Delivery Channel（配信機能）
記録された設定情報は、以下に配信されます。
- S3（設定履歴の保存）
- SNS（通知オプション）
S3にはJSON形式で履歴が蓄積され、
監査証跡やインシデント調査の基盤となります。
保存期間や暗号化（KMS）、ライフサイクル設計は、
セキュリティとコストの両面から重要な設計ポイント です。
③ Config Rules（評価機能）
AWS Configの中核です。
ルールには2種類あります。
- AWS管理ルール
- カスタムルール（Lambdaベース）
例：
- s3-bucket-public-read-prohibited
- encrypted-volumes
- root-account-mfa-enabled
- restricted-ssh
評価タイミングは以下の2種類。
- 変更トリガー型（Configuration change）
- 定期実行型（Periodic）
CNAPPでは、このルール設計が
セキュリティ成熟度を左右します。
④ Conformance Packs（標準化）
複数のルールをテンプレート化し、
一括適用できる仕組みです。
例えば：
- CIS Benchmark準拠
- PCI DSS準拠
- 社内セキュリティ標準
マルチアカウント環境では、
これが 統制の再現性を担保する仕組み になります。
2.2 マルチアカウント運用とAggregator設計
大規模環境では、単一アカウント運用は現実的ではありません。
ここで重要になるのが、
Organization連携 + Aggregator
- 全アカウントの評価結果を集約
- リージョン横断可視化
- 組織単位での準拠率管理
これにより、
- どのOUが逸脱しているか
- どのルールが頻発しているか
- どの環境がリスク高いか
を横断的に把握できます。
CNAPP視点では、
“分散環境の一元可視化”が成立して初めて統合管理と言える のです。
2.3 AWS ConfigとSecurity Hubの関係
AWS Config単体でも評価は可能ですが、
CNAPP運用では他サービスとの統合が前提になります。
代表例が Security Hub との連携です。
- Configの評価結果をコントロールとして統合表示
- 他サービス（Inspector / GuardDuty）と同一画面で管理
- 優先度や重要度を横断的に整理
つまり、
- Config → “設定の逸脱”
- Inspector → “脆弱性”
- GuardDuty → “侵害兆候”
を一つのセキュリティビューで扱えるようになります。
これが CNAPP的な統合運用の実装形 です。
2.4 設計時に考慮すべきポイント
CNAPP運用前提で見ると、以下は必須検討事項です。
① 記録範囲
- 全リソースか
- 主要リソースのみか
② リージョン戦略
- 利用リージョンのみ有効化
- すべてのリージョンで有効化
③ ノイズ制御
- 例外設計
- 重要度分類
- 運用チームの対応能力とのバランス
④ コスト制御
- 設定アイテム数
- ルール評価回数
- S3保管量
Configは“入れれば安全になる”サービスではありません。
正しく設計して初めて、統制基盤になる
これが実運用での最大のポイントです。
第3章：AWS Configの導入手順
本章では、CNAPP運用を前提とした AWS Config の導入手順 を整理します。
単なる有効化手順ではなく、設計判断ポイント込み でまとめます。
⚠ 2つの重要設定：①AWS Config の記録頻度は「継続的」を選択
AWS Config 有効化時に表示される
「デフォルトの記録頻度」は、Security Hub CSPM 利用時の最重要設定です。
結論
Security Hub CSPM を使う場合は「継続的な記録（Continuous recording）」を選択します。
日次（Daily recording）にすると、
- 検出が最大24時間遅延する可能性がある
- 変更直後の逸脱を即時検知できない
ため、CSPMの即時性が損なわれます。
AWS公式ドキュメントでも、
日次記録では検出遅延が発生し得ることが明記されています。
- 〇 Security Hub CSPM 利用時は「継続的な記録」
- ✕ コスト目的で安易に日次へ変更しない
この設定は、導入時に必ず確認すべき最重要ポイントです。
⚠ 2つの重要設定：②記録対象リソースタイプ
AWS Config 有効化時の
- 「すべてのリソースタイプ（オーバーライド可）」
- 「特定のリソースタイプ」
の選択も、Security Hub CSPM 利用時は重要です。
結論
原則は「すべてのリソースタイプ」を推奨します。
Security Hub のコントロールは、
対象リソースが AWS Config で記録されていることを前提に評価されます。
記録していないリソースは評価されません。
絞る場合の注意
「特定のリソースタイプ」を選ぶ場合は、
- 有効化する標準を確定
- 公式の Required AWS Config resources 一覧を確認
- 必要リソースを漏れなく選択
が必須です。
網羅性を欠くと、検知漏れや評価未実施が発生します。
AWSが公式記事を出しているのでこれを基に設定してください。
https://docs.aws.amazon.com/securityhub/latest/userguide/controls-config-resources.html?utm_source=chatgpt.com
3.1 事前設計チェック
① 記録対象リソース
- 全リソースを記録するか
- 主要リソースのみに絞るか
推奨（CNAPP視点）
- 原則「全リソース記録」
- コスト制約がある場合のみ限定
② リージョン戦略
- 利用リージョンのみ有効化
- 全リージョン有効化
推奨
- ガバナンス重視なら全リージョン有効化
- 最低でも将来利用可能性のあるリージョンは含める
③ S3保存設計
- 専用ログバケット作成
- SSE-KMS暗号化有効化
- アクセスログ取得
- ライフサイクルポリシー設計
④ 運用責任分界
- 誰がルール違反を確認するか
- SLAは何時間か
- 例外申請フローはあるか
ここを決めないと、
アラートが“ただのノイズ”になります。
3.2 単一アカウントでの有効化手順
Step1：Config有効化
- AWS Config コンソールへ移動
- 「記録を開始」を選択
- 記録対象リソースを選択
- S3バケット指定
- IAMロール自動作成
Step2：Config Rules追加
- 「ルールを追加」
- AWS管理ルールを選択
- 代表的ルールを有効化
例：
- s3-bucket-public-read-prohibited
- encrypted-volumes
- root-account-mfa-enabled
- cloudtrail-enabled
Step3：評価結果確認
- 準拠 / 非準拠の確認
- リソース単位で詳細表示
- 修正 or 例外判断
3.3 Organizations環境での展開手順
Step1：委任管理アカウント設定
- OrganizationsでConfigを有効化
- Delegated Administrator設定
- 集約用アカウント決定
Step2：Organization全体へ自動有効化
- 新規アカウントも自動適用
- リージョン戦略を統一
Step3：Aggregator作成
- Aggregatorを作成
- 全アカウント・全リージョン選択
- 横断的な準拠状況確認
これにより、
- OU単位の逸脱率
- 重大違反の傾向
- 組織横断KPI管理
が可能になります。
Step4：Conformance Packs適用
例：
- CISベンチマーク
- 社内標準テンプレート
テンプレート化により、
統制の再現性を担保 できます。
3.4 自動是正の実装
Configは検知が中心ですが、
EventBridgeと組み合わせることで自動修正が可能です。
代表的構成
Config Rule違反
↓
EventBridge
↓
Lambda / SSM Automation
↓
修正実行
自動化に向く例
- S3パブリックブロック強制
- タグ付与
- 暗号化設定
自動化に向かない例
- IAM権限剥奪
- セキュリティグループ大幅変更
影響範囲の大きい変更は
人間の承認を挟む設計が安全 です。
3.5 よくある導入失敗パターン
- 全ルール有効化 → ノイズ過多
- 記録対象不足 → 検知漏れ
- S3/KMS権限不備 → 配信失敗
- 運用フロー未定義 → 放置アラート
第4章：AWS Configの運用設計とコスト最適化（CNAPPとして回し続ける）
AWS Configは「導入して終わり」のサービスではありません。
CNAPP運用として重要なのは、継続的に回し続けられる設計です。
本章では、
- 運用設計の考え方
- コスト構造の理解
- ノイズ制御
- KPI設計
まで整理します。
4.1 AWS Configのコスト構造を理解する
AWS Configのコストは、主に以下で構成されます。
① 設定アイテム（Configuration Items）
- リソース変更ごとに生成
- 記録対象が多いほど増加
- Auto Scaling / ECS / Lambda多用環境では増えやすい
② ルール評価回数
- 変更トリガー型
- 定期評価型
ルール数 × リソース数 × 評価頻度
でコストが増加します。
③ S3保存コスト
- 履歴JSON保存
- スナップショット保存
- 長期保管による蓄積
④ Aggregator利用
- マルチアカウント集約時に発生
4.2 コストを抑える設計ポイント
記録対象の最適化
- 原則全記録が理想
- ただし短命リソースが多い場合は設計検討
定期評価ルールの見直し
- 本当に定期実行が必要か
- 変更トリガーで十分か
S3ライフサイクル設計
例：
- 90日標準保存
- 半年後Glacier移行
- 監査要件に応じた削除
リージョン統制
- 利用していないリージョンの有効化はコスト増要因
- 統制方針に合わせて設計
4.3 ノイズ制御と例外管理
Config運用が失敗する最大要因は
「アラート疲れ」
です。
よくある失敗
- CISルールを全有効化
- 例外申請フローなし
- 優先度分類なし
結果：
- 非準拠が常態化
- 誰も見なくなる
- 形骸化
対策
① 重要度分類
- High：即時対応
- Medium：計画対応
- Low：監視継続
② 例外管理ルール化
- 正当な例外はタグ管理
- 期限付き例外承認
- 例外の棚卸し実施
③ 対応責任の明確化
- アプリ担当
- 基盤担当
- セキュリティ担当
責任分界が曖昧だと
Configは“誰も触らない画面”になります。
4.4 CNAPP運用としてのKPI設計
Configは“可視化ツール”ではなく、
統制の成熟度を測る指標になります。
代表的KPI：
- 準拠率（Compliance %）
- 重大違反件数
- 平均修正時間（MTTR）
- 例外件数
- 再発率
成熟度モデル例：
| レベル | 状態 |
|---|---|
| Lv1 | 有効化のみ |
| Lv2 | 主要ルール監視 |
| Lv3 | 組織標準化 |
| Lv4 | KPI管理 |
| Lv5 | 自動是正＋継続改善 |
4.5 AWS Configは「守りの起点」
Inspectorは脆弱性を見つけます。
GuardDutyは侵害兆候を検知します。
しかしConfigは、
- 事故の芽を潰す
- 統制を維持する
- ガードレールを機能させる
という役割を担います。
CNAPPにおいて、
「設定の正しさを継続監視できているか？」
は、成熟度の分岐点になります。
最終まとめ
AWS Configは、
- CSPMの中核
- 組織統制基盤
- 証跡管理基盤
- 自動是正トリガー
として機能します。
しかし、
- 設計せずに有効化
- 運用設計なし
- ノイズ管理なし
では意味がありません。
Configは、
導入してからが本番
です。
CNAPP運用を本気で実装するなら、
AWS Configは避けて通れない存在なので必ずものにしましょう。