【ガイドライン】AWS Config

作成日: 2024/01/02, 更新日: 2024/01/02

AWS Config は、AWS リソースの構成管理よび変更記録ができる機能と、AWS リソースの設定値を評価することができる機能を有するサービスです。
本記事では、AWS Config を組織で導入する際に検討すべきポイントを記載いたしました。

目次

AWS Config とは？
導入検討
1. ① AWS リソースの変更記録をどのように行うか？
2. ② 会社で満たさなければならないセキュリティルールは何か？
ガイドライン策定
関連ドキュメント

AWS Config とは？

AWS Config （以下略：Config）は、AWS リソースの構成管理と変更を監視するサービスです。Config で取得可能なのは AWS リソースの構成情報となるため、 OS やアプリケーション、データベースなどの構成情報は取得できません。
Config で記録可能な AWS リソースは制限があるため注意が必要です。例えば、Organizations、IAM Identity Center のすべてのリソースや、Systems Manager のパラメータストア、ドキュメントなどなど、記録できないリソースがあります。
- 参考：サポートされているリソースタイプ - AWS Config

Config は AWS リソースの構成管理の機能に加え、AWS Config ルール（以下略：Config ルール）というルールを設定することで、AWS リソースの設定を監視することができます。
- Config によって設定変更が検知された場合、設定したルールによってリソースが違反しているかどうかを判定し、違反している場合は通知を送信することが可能です。

導入検討

① AWS リソースの変更記録をどのように行うか？

クラウドの環境ではなくオンプレミス環境で構成管理や変更を記録する場合、エクセルやワードなどのドキュメントを用いて管理する場合が多く、自動化が進んでいるシステムにおいては、Ansible で OS の構成管理を行っている場合もありました。
AWS における構成情報は、AWS Config で記録することができますが、前述した通り、記録できるリソースには制限があります。主要な AWS リソースは記録できるものの、記録ができない AWS リソースも踏まえて変更記録方法を検討する必要があります。
一方で、Config ルールを利用する場合、前提として Config で対象の AWS リソースの変更記録を行っておく必要があります。

基本的に Config はすべての AWS アカウントで有効化することを推奨しておりますが、「Config を使わず別の構成管理ツールで構成管理及び変更管理を行う」かつ「Config ルールを利用せず、別のセキュリティチェックツールで設定不備をチェックする」のであれば導入しない選択肢もあります。

「Config を使わず別の構成管理ツールで構成管理及び変更管理を行う」ケースとして、IaC ツールを利用するのが１つの案としてありますが、システムすべてで IaC ツールを利用することを必須とするのは、開発／運用者のスキルレベルも合わせていく必要がありなかなか難しいと考えます。
Config 以外の SaaS ツールが全社的に導入されている場合はそちらのツールを利用するのが良いでしょう。
- 僕の知る限りだと、あまり有名なツールは聞いたことがなく、、基本は AWS のサービスに頼るのが良いと思います。

「Config ルールを利用せず、別のセキュリティチェックツールで設定不備をチェックする」ケースとして、以下のものがあります。
1. Prowler を利用
2. Microsoft Defender for Cloud を利用
3. CI/CD パイプラインにより、デプロイ前に静的解析を行う

Config ルールにおいても AWS がマネージドサービスとして提供している機能のため、他のツールよりも柔軟性や後方互換性が優れており、基本的には利用を推奨しております。上で上げたどの手段でも設定不備をチェックすることは可能なため、会社の方針に合わせて選択するのが良いと思います。

② 会社で満たさなければならないセキュリティルールは何か？

セキュリティツールとして Config ルールを利用する場合、会社で満たさなければならないセキュリティルールを明確にしておく必要があります。セキュリティルールによっては、Config ルールを利用せず、別のセキュリティチェックツールで設定不備をチェックするのが良い場合もあります。

Config ルールを一から検討していくのは大変なため、セキュリティルールをベースにコンフォーマンスパックや Security Hub の標準を利用して、セキュリティルールを満たすための Config ルールを作成するのが良いです。
- コンフォーマンスパックテンプレート - AWS Config
- Security Hub 標準のリファレンス - AWS Security Hub

特にセキュリティルールが定められていない場合、Security Hub の AWS Foundational Security Best Practices (FSBP) や AWS Well-Architected フレームワークのコンフォーマンスパックで推奨されている Config ルールをまずは導入するのが良いでしょう。

AWS Foundational Security Best Practices (FSBP) と AWS Well-Architected フレームワークはどちらも AWS が提供しているベストプラクティスとはなりますが、AWS Foundational Security Best Practices の方がよりセキュリティに特化したルールを選定されてます。

ガイドライン策定

① Config で記録する AWS リソースは誰がどのように選択するか？

Config で記録する AWS リソースは、以下のパターンにおいて記録から除外するケースがあります。
1. 一時的なワークロード（スポットインスタンス、Auto Scaling など）を実行している場合
2. グローバルリソース（IAM、Aurora グローバルクラスター）を特定のリージョンのみで記録する場合
3. CI/CD でデプロイしており、Git レポジトリで構成/変更管理、ビルド処理でコードの静的解析によりセキュリティチェックできている場合

ガードレールとして Config ルールを設定する場合、Config で記録する AWS リソースを選択する必要がありますが、1. や 2. のケースのように過剰に記録してコストがかかるケースもあるため、AWS アカウントに構築するリソースの特性に応じて記録するリソースを選択する必要があります。
- Config は基盤側で管理することが多いですが、AWS アカウントに構築するリソースはシステム担当者しか把握できないため、社内のワークフローなどを利用し申請ベースで管理するのが良いでしょう。

1. のケースのように Config の発見的統制よりも、CI/CD パイプラインのセキュリティチェックによる予防的統制ができている場合、Config で記録する必要はありません。ただし、運用の中でデプロイしたリソースを手動で変更するケースがある場合は、Config で記録する必要があります。

参考： AWS Config で記録するリソースの選択 - AWS Config

② Config ルールは何を設定するか？

② 会社で満たさなければならないセキュリティルールは何か？でざっくりとしたセキュリティルールやフレームワークを決めたのち、より詳細なルールを設定する必要があります。
Config ルールのコンフォーマンスパックや Security Hub の標準をそのまま適応すると、そこまで重要ではないルールも含めて設定されてしまうため、本当に対応が必要なルールのみ選択していきます。

このルール選定は力技の作業になります。。。
SCP や IDアクセス管理のような予防的統制の AWS サービス。GuardDuty のような他の発見的統制の AWS サービスなど、他の統制によって対応できるルールは除外するのが良いでしょう。

会社によって選定作業は異なっており、例示することが難しいため、ここでの説明は以上とさせていただきます。

③ Config の運用が誰が行うか？

Config を利用する場合、以下のような Config の運用を誰が行うかを決める必要があります。

AWS アカウント発行時の Config の有効化 / Config ルールの設定
Config ルールのアップデート
Config ルールに違反した場合の対応（リスクの回避、低減、移転、受容）
Config のログ解析

1. 1. は基本的に基盤側で行うことが多いですが、3. はシステム担当者が行うことが多いです。
例えば、EC2 の EBS が暗号化されていないとの検知がされた場合、変更時の影響も考慮しながら修正対応をする必要があるため、システム担当者側で操作を行います。
Config では修復アクションを実行することもできるため、非準拠のリソースを強制的に修正する実装をするケースもあります。
- IaC でデプロイしている場合、ソースコードで定義した構成と乖離が出てしまうので、実装した場合は開発者に仕様を伝える必要があります。

Config において記録されたリソースの変更履歴は、基盤側とシステム担当とも利用する場合がありますが、Config のログはログ管理アカウントへ一元的に蓄積しているケースが多く、システム担当者側は Athena ではログ分析することができません。
組織単位で Config を有効化した場合でも、高度なクエリを利用すればシステム担当自身の AWS アカウントのログを分析することが可能です。
- 参考： AWS リソースの現在の設定状態のクエリ - AWS Config

関連ドキュメント

AWS Config とは? - AWS Config ユーザーガイド