【AWS】小学生でもわかる！AWS Configを徹底解説！

叡智に富んだ読者の皆様、ご機嫌よう。

晴れて無事に転職先が見つかり、配属された案件で運よくAWS童貞を卒業しつつあるすぎちゃんです！

AWS童貞を卒業するからにはセキュリティも順守しなきゃいけねぇなと思い、AWSのセキュリティ専門知識の学習を始めました

AWS クラウドにおけるセキュリティソリューションの作成と実装に関する知識を検証します。この認定では、専門的なデータ分類と AWS のデータ保護メカニズム、データ暗号化方法とそれらを実装するための AWS メカニズム、および安全なインターネットプロトコルとそれらを実装するための AWS メカニズムについての理解も検証されます。
（引用元：AWS公式）

ほぼ3年前に取得したSAAよりもセキュリティ知識の深堀りされるので、ギャーヒー言いつつ日々知識の取得に励んでおります

さて今回はセキュリティ専門知識でほぼ出題されると言っても過言ではないAWS Configさんについて解説します。

< AWSの治安維持は僕に任せてくれ！

擬人化シリーズは本記事の他でもまとめているので是非ご覧になってください。

AWS Configについて

AWS Configさんは、どんなリソースも「規則正しく整っているか」を見守る几帳面な性格です。

毎日、リソースが「ルール通り」に設定されているか確認し、違反を見つけるとそっと教えてくれます。

彼の手元には、AWS公式が用意したAWSマネージドルールという分厚いルールブックがあり、このルールブックをもとにお仕事をこなしています。

< 歩く六法全書みたいな存在だぞ！

AWSマネージドルール

さて、彼がいつも持ち歩ているAWSマネージドルールを覗いてみましょう。

全部紹介しようとなると記事を埋め尽くしてしまうことになるので、実際の試験に出題されそうなものをピックアップして紹介致します。

ルール名	説明	非準拠となる基準
cloudfront-s3-origin-access-control-enabled	Amazon Simple Storage Service (Amazon S3) オリジンタイプの Amazon CloudFront ディストリビューションで、オリジンアクセスコントロール (OAC) が有効になっているかどうかを確認します。	OAC が有効になっていない Amazon S3 オリジンを持つ CloudFront ディストリビューションの場合
EC2-ebs-encryption-by-default	Amazon Elastic Block Store (EBS) 暗号化がデフォルトで有効になっているかどうかを確認します。	暗号化が有効になっていない場合
ec2-stopped-instance	許可されている日数を超えて停止された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがあるかどうかを確認します。	Amazon EC2インスタンスの状態が許容される日数よりも長く停止している場合、または時間を特定できない場合
rds-multi-az-support	RDS DBインスタンスで高可用性が有効になっているかどうかを確認します。	RDS DBインスタンスがマルチAZ配置になっていない場合
s3-default-encryption-kms	S3 バケットがAWS Key Management Service (AWS KMS) で暗号化されているかどうかを確認します	S3 バケットが キーで AWS KMS暗号化されていない場合

以上で説明した５つのルールの他にも沢山あるので、興味のある方は読んでみて下さい。

なお各マネージドルールは一部の例外を除き後述のSystem Managerオートメーションのランブックと対応していることも頭に入れておきましょう！

< お小言が多いと思われるかもしれないけど、これも皆を守るためだ！

カスタムルール

AWS Configのカスタムルールというのは「自分たちだけの特別なルールを作れる仕組み」です。

< 意外とにサービス精神はあるんだぞ！

前述のマネージドルールが憲法や法律だとすると、カスタムルールはいわば校則のようなもの。

例を挙げると・・・

• 「朝顔を育てているから、水やり当番を決めましょう！」
• 「大事な図鑑は先生の机にしまっておきましょう！」

自分達の環境に合ったルールを独自に決めるイメージです。

もしカスタムルール違反が発覚すれば、後述のLambdaによる自動修復が行われます。

他のサービスとの連携

configさんはリソース構成を見守り、ルールに準拠していない変更があればお叱りを入れるというイメージがございますが、実は連携プレーもお得意だったりします。

連携できるのは以下３つのサービスでそれぞれ以下の用途で使用されます。

1. System Managerオートメーション(AWSマネージドルール非準拠時の自動修復)
2. Lambda(カスタムルール非準拠時の自動修復)
3. EventBridge → SNS(AWSマネージド・カスタムルール非準拠時の通知)

System Managerオートメーション

AWSマネージドルールに違反しているリソースを見つけた場合、System Manager オートメーションと連携しリソースの自動修復を行います。

< 誰かが間違えてSSHを全開放してしまっているぞ？これはrestricted-sshに非準拠だ！System Managerオートメーション！早速修復をしてもらえるかな？

< Hey, Boss!セキュリティグループの修復に行ってまいります！

～10 minutes later ～

< ふぅ・・・ランブック（手順書）通りにやったお陰でセキュリティホールが解消されたぞ！

こうしてルールに厳格なConfigさんと仕事に忠実なSystem Manager Automationさんの連携プレーによりAWSの平和が守られました。

Lambda

カスタムに違反しているリソースを見つけた場合、Lambdaと連携しリソースの自動修復を行います。

< 大変だ！このEC2インスタンス、タグ付けルールを守ってないじゃないか？

< タグ付けルールですか？どんな内容なんですか？

< プロジェクト名や環境情報（例えばEnvironment=Production）を必ず付けることになってるんだけど、このインスタンス、タグが一切ついてないんだ！

< タグなしインスタンスは運用上の優秀性の観点からしてあまりよろしくないですね……すぐに修復プロセスを実行します！

～Next day ～

< Lambdaさん、あの修復のおかげで運用部門からお礼が届いたぞ！これで監査にもちゃんと対応できるね。

< やったー！Configさんのルール管理があってこそですよ！また何かあればお任せください！！！

EventBridge → SNS（Simple Notification Service）

Configさんが違反を検知した場合、その旨をAWS管理者に伝達するためEventBridgeさん経由でSNSから通知を送ることも可能です。

以下のような流れで機能します。

1. Configがルール違反を検知
   AWS Configが「S3バケットがパブリックアクセスを許可している」という違反を検知
2. EventBridgeが非準拠イベントを受理
   EventBridgeがConfigのイベントを受け取りSNSを呼び出す
3. SNSによるメッセージ通知
   SNSが管理者グループ全体に通知を配信。

< おっと、S3バケットがパブリックアクセスを許可しているようだ。これはs3account-level-public-access--blocksに従っていない！ちょっとEventBridgeさん、SNSさんに連携しないとな！

～司令塔にて～

< SNSさん！Configさんからルール違反を見つけたという報告が入りました！管理者の方にメッセージを届けてください！

< 任せてください！通知を作成して、管理者全員にメールとLINEメッセージを送ります！それにSlack通知も必要ですよね？

EventBridgeさんとSNSさんの見事な連携によって、管理者はリソースポリシーの違反をいち早くキャッチし、迅速に対応することができました。

この仕組みのおかげで、ただ問題を解決するだけでなく、インシデント情報の周知や、将来的なセキュリティホールの予防にもつなげられるのです。

EventBridgeさんとSNSさんはまさに縁の下の力持ち。影響を最小限に抑え、システム全体の安定性を守るためには欠かせないパートナーです！

AWS CloudTrailとの違い

さてセキュリティ専門知識の学習を経験された方の中には、

「CloudTrailとAWS Configとの違いって一体なんやねん？」

と一度は疑問に感じた方がおられるかもしれません。

ざっくり説明すると・・・

CloudTrail : ユーザの操作に対して モニタリングをし、不正なことが起こってないかを確認する
Config : リソースに対して モニタリングをし、決定されたガイドラインに沿ってるかの確認を行う
引用元：cloudtrail と config の違い

↑を人に喩えて説明するとこんな感じです。

< おや？すぎちゃん。ちょっと腹の肉がズボンに乗っかっているぞ？前はそんなことなかったのに。（リソースの変更をモニタリング）

< 確かに2kg増えたけど・・・。何もしてないんだからねっ！

　< 何もしてないのに太るわけがない！そうだCloudTrail。すぎちゃんの行動履歴を調べてくれ！

< ちょっと僕で色々監視させてもらったのですが、どうやらここ30日間で20回も家系ラーメンを平らげているようですね。（いつ・だれが・何をしたのか を残す）

<最後に喋ったときに「減量するからラーメンは一切食べない！」と宣言していたのに・・・。自分で決めたルールを守れないなんて人として非準拠だ！よしLambdaさん! すぎちゃんを徹底的に修復（ボコ）してしまえ！(非準拠時の自動修復)

< 畏まりました。Config様。

< お、お許しを～～～～～！！！！！！（このあと滅茶苦茶ダイエットした。）

こうしてCloudTrailさんLambdaさんとの連携プレーにより、すぎちゃんの不正行為が暴露されてしまいました

はてさて、腹の肉がスケールインするのはいつのことやら？

まとめ

AWS Configさんは、AWS環境のリソースが正しく構成されているかを常にチェックしてくれる「AWSの委員長」。

AWS Configが得意なこと

• 監視：リソースがルールに従っているかを継続的に監視
• 記録：リソースの変更履歴を全て保存（リソースがどのように変更されたか追跡可能）
• 違反の検出：ルールに従っていないリソースを特定し通知
• 自動修復：違反が発生した際にSystemManagerオートメーション or Lambdaと連携し自動で修正プロセスを開始

既存のルール集であるマネージドルールを活用しながら、規則に準拠していないリソースを見つけ出し、記録やアラートで通知してくれます。また、カスタムルールを設定することで、環境に応じた独自のルールで監視を強化することも可能です。

さらに、違反が見つかった場合は、自動修復機能を使って即座に対応を取ることもできます。

マネージドルールではSystem Manager Automationと連携、カスタムルールではLambda関数で対応