Kanji
・クラウドエンジニア / フリーランス ・1993年生まれ ・愛媛県出身 / 東京都渋谷区在住 ・AWS歴5年 プロフィールの詳細
目次
AWS Config（以下、Config）は、AWS リソースの構成管理と変更を監視するサービスです。Config で取得可能なのは AWS リソースの構成情報であり、OS やアプリケーション、データベースなどの構成情報は取得できません。
Config で記録可能な AWS リソースには制限があるため注意が必要です。例えば、Organizations、IAM Identity Center のすべてのリソースや、Systems Manager のパラメータストア、ドキュメントなど、記録できないリソースがあります。
Config は AWS リソースの構成管理機能に加え、AWS Config ルール（以下、Config ルール）を設定することで、AWS リソースの設定を監視することができます。
クラウド環境ではなくオンプレミス環境で構成管理や変更を記録する場合、エクセルやワードなどのドキュメントを用いて管理することが多く、自動化が進んでいるシステムでは Ansible で OS の構成管理を行っている場合もあります。
AWS における構成情報は AWS Config で記録できますが、前述の通り、記録できるリソースには制限があります。主要な AWS リソースは記録できますが、記録できない AWS リソースも踏まえて変更記録方法を検討する必要があります。
一方で、Config ルールを利用する場合、前提として Config で対象の AWS リソースの変更記録を行っておく必要があります。
基本的に Config はすべての AWS アカウントで有効化することを推奨しますが、「Config を使わず別の構成管理ツールで構成管理および変更管理を行う」かつ「Config ルールを利用せず、別のセキュリティチェックツールで設定不備をチェックする」のであれば導入しない選択肢もあります。
「Config を使わず別の構成管理ツールで構成管理および変更管理を行う」ケースとして、IaC ツールを利用するのが一つの案ですが、システム全体で IaC ツールを利用することを必須とするのは、開発／運用者のスキルレベルも合わせていく必要があり難しいと考えます。
Config 以外の SaaS ツールが全社的に導入されている場合はそちらのツールを利用するのが良いでしょう。
「Config ルールを利用せず、別のセキュリティチェックツールで設定不備をチェックする」ケースとして、以下のものがあります。
Config ルールは AWS が提供するマネージドサービスのため、他のツールよりも柔軟性や後方互換性が優れており、基本的には利用を推奨します。上記の手段でも設定不備をチェックできますが、会社の方針に合わせて選択するのが良いでしょう。
セキュリティツールとして Config ルールを利用する場合、会社で満たさなければならないセキュリティルールを明確にしておく必要があります。セキュリティルールによっては、Config ルールを利用せず、別のセキュリティチェックツールで設定不備をチェックするのが良い場合もあります。
Config ルールを一から検討するのは大変なため、セキュリティルールをベースにコンフォーマンスパックや Security Hub の標準を利用して、セキュリティルールを満たすための Config ルールを作成するのが効率的です。
特にセキュリティルールが定められていない場合、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 ルールを設定する場合、Config で記録する AWS リソースを選択する必要がありますが、1.や 2.のケースのように過剰に記録してコストがかかるケースもあるため、AWS アカウントに構築するリソースの特性に応じて記録するリソースを選択する必要があります。
3.のケースのように Config の発見的統制よりも、CI/CD パイプラインのセキュリティチェックによる予防的統制ができている場合、Config で記録する必要はありません。ただし、運用の中でデプロイしたリソースを手動で変更するケースがある場合は、Config で記録することを検討する必要があります。
参考： AWS Config で記録するリソースの選択 - AWS Config
Control Tower を利用して Config を有効化した場合、以下のブログに記載のソリューションを利用することによって AWS アカウントの発行時に自動的に Config で記録するリソースを除外することが可能です。
② 会社で満たさなければならないセキュリティルールは何か？ でざっくりとしたセキュリティルールやフレームワークを決めたのち、より詳細なルールを設定する必要があります。
Config ルールのコンフォーマンスパックや Security Hub の標準をそのまま適用すると、そこまで重要ではないルールも含めて設定されてしまうため、本当に対応が必要なルールのみ選択していきます。
このルール選定は力技の作業になります。
SCP や ID アクセス管理のような予防的統制の AWS サービス、GuardDuty のような他の発見的統制の AWS サービスなど、他の統制によって対応できるルールは除外するのが良いでしょう。
会社によって選定作業は異なっており、例示することが難しいため、ここでの説明は以上とさせていただきます。