AWS Configによる構成評価のシナリオ判断
新しく作った資源だけ暗号化されていませんでした。構成を見つける、基準と比較する、変更者を調べる、修復を確認するという段階を分け、Configを使った運用の抜けを探します。
この単元で学ぶこと
- 記録漏れやルールの対象不足を発見できる
- 非準拠の原因調査と修復を分けて判断できる
- 準拠評価の限界と変更後の検証を説明できる
本文解説
事例の構成 社内では対象ストレージの暗号化と部門タグが必須です。既存資源は点検済みですが、新しいアカウントで作られた資源について履歴が見つかりません。まず記録の対象範囲を確認し、一覧にない資源を正常と決めつけないようにします。
対象範囲の修正 新アカウントや別リージョンが記録・評価から外れていれば、必要な構成を整えます。対象種別の対応状況も確認します。設定後はサンプル資源の履歴と評価結果が届くかを検証し、設定したという事実だけで完了にしません。
ルールの意味を合わせる 部門タグの存在だけを確認するルールでは、値が誤った部門でも要件を満たしたように見える場合があります。自社が求めるのは存在か、正しい値か、特定の資源だけかを整理します。技術的なルールと業務の意味を照合します。
非準拠の変化を追う 昨日まで準拠だった資源が非準拠になったなら、Configの前後の構成を確認します。暗号化設定やタグなど何が変わったかを特定します。作成直後から不適合だった場合と、後から変更された場合では、直す手順も異なります。
実行主体を調べる 変更の操作主体はCloudTrailと突き合わせます。Configで状態の差が分かったことを、そのまま特定個人の操作の証拠とはしません。自動化ロールによる作成なら、手作業の修正だけでなくテンプレートや作成手順へ原因を戻します。
修復で業務を止めない 修復には権限と承認、対象範囲が必要です。設定変更で再起動や置換が必要になる場合、即時に変更してよいか業務要件を確認します。自動修復を構成する場合も、失敗結果の確認と再試行が意図しない変更を生まないかを検証します。
変更後を確かめる 修復処理が成功と返っても、評価対象の資源が期待した状態になったかを確認します。評価の時点や収集タイミングにも注意します。また準拠に戻ってもアプリが動かなくなれば、運用面の要件は満たしていないためログや指標も見ます。
例題：全項目が準拠でも不足 設定したルールはタグと暗号化だけなのに、担当者が「すべての法令と社内規程に適合」と報告しました。正しくは、記録対象の資源がその二つの条件へ準拠したという意味です。他の要件を列挙して、追加の評価や証拠が必要かを確認します。
図解
重要ポイント
- 新しいアカウントと資源を記録・評価範囲へ含める。
- タグの存在と値の正しさは別の要件。
- 構成差と操作主体の証拠を組み合わせる。
- 修復後は再評価と業務動作を確認する。
間違えやすい点
- 評価対象外を準拠扱いしない。
- 修復コマンド成功だけで再評価を省略しない。
- 二つのルール適合を全規程の適合と誇張しない。
用語解説
- メトリクス
- CPU使用率や要求数など、時刻とともに記録される数値。単位・集計期間・対象を合わせて読む。
- アラーム
- メトリクスなどの評価条件に応じて状態が変わり、設定した通知や対応へつなげる仕組み。
- 管理イベント
- AWSリソースの作成や設定変更など、管理面の操作を記録するイベント。
- データイベント
- S3オブジェクトへの取得・書込みなど、資源内のデータに対する操作を記録するイベント。対象の明示設定を確認する。
- 構成項目
- AWS Configが記録する、対象資源のある時点での属性や関係などの情報。
- 準拠評価
- 定めたルールに対象構成が合っているかを判定すること。未設定の要件まで保証するものではない。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。