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

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

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

AWS童貞を卒業するからにはセキュリティも順守しなきゃいけねぇなと思い、[AWSのセキュリティ専門知識](https://qiita.com/sugichaaaan/items/1258d760ea3efd4e4410)の学習を始めました :pen_ballpoint: 

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



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

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

https://aws.amazon.com/jp/config/

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/b7823a64-f530-0509-cc2e-60cfce84f11d.png" height="70" width="70"> < AWSの治安維持は僕に任せてくれ！

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

https://qiita.com/sugichaaaan/items/1258d760ea3efd4e4410

https://qiita.com/sugichaaaan/items/01b8d5ab93514dd24c86

## AWS Configについて

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

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

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

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/b7823a64-f530-0509-cc2e-60cfce84f11d.png" height="70" width="70"> < 歩く六法全書みたいな存在だぞ！


https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/evaluate-config_use-managed-rules.html

### AWSマネージドルール

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

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

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

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

https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/managed-rules-by-aws-config.html

なお各マネージドルールは[一部の例外](https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/required-tags.html)を除き後述の[**System Managerオートメーションのランブック**](https://docs.aws.amazon.com/ja_jp/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html)と対応していることも頭に入れておきましょう！



<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/b7823a64-f530-0509-cc2e-60cfce84f11d.png" height="70" width="70"> < お小言が多いと思われるかもしれないけど、これも皆を守るためだ！

### カスタムルール

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

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/b7823a64-f530-0509-cc2e-60cfce84f11d.png" height="70" width="70"> < 意外とにサービス精神はあるんだぞ！

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

例を挙げると・・・

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

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



https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/evaluate-config_develop-rules.html

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

## 他のサービスとの連携

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

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

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


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

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/dd1a04af-b0b7-fdcc-70ed-5e7bd7158220.png" height="70" width="70"> < 誰かが間違えてSSHを全開放してしまっているぞ？これは[`restricted-ssh`](https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/restricted-ssh.html)に非準拠だ！**System Managerオートメーション**！早速修復をしてもらえるかな？

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/e9d2cea4-f7a2-96eb-9752-45c12ca8d595.png" height="70" width="70"> < Hey, Boss!セキュリティグループの修復に行ってまいります！

～10 minutes later ～

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/e9d2cea4-f7a2-96eb-9752-45c12ca8d595.png" height="70" width="70"> < ふぅ・・・ランブック（手順書）通りにやったお陰でセキュリティホールが解消されたぞ！



https://www.geekfeed.co.jp/geekblog/config-restricted-ssh/

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


### Lambda

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


https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/evaluate-config_develop-rules_nodejs.html


<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/dd1a04af-b0b7-fdcc-70ed-5e7bd7158220.png" height="70" width="70"> < 大変だ！このEC2インスタンス、タグ付けルールを守ってないじゃないか？


<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/41386bd4-9f71-1204-1cc3-f6e9d6399e48.png" width="70" height="70"> < タグ付けルールですか？どんな内容なんですか？

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/dd1a04af-b0b7-fdcc-70ed-5e7bd7158220.png" height="70" width="70"> < プロジェクト名や環境情報（例えば`Environment=Production`）を必ず付けることになってるんだけど、このインスタンス、タグが一切ついてないんだ！

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/41386bd4-9f71-1204-1cc3-f6e9d6399e48.png" width="70" height="70"> < タグなしインスタンスは[**運用上の優秀性**](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.pillar.operationalExcellence.ja.html)の観点からしてあまりよろしくないですね……すぐに修復プロセスを実行します！

～Next day ～

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/dd1a04af-b0b7-fdcc-70ed-5e7bd7158220.png" height="70" width="70"> < Lambdaさん、あの修復のおかげで運用部門からお礼が届いたぞ！これで監査にもちゃんと対応できるね。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/41386bd4-9f71-1204-1cc3-f6e9d6399e48.png" width="70" height="70"> < やったー！Configさんのルール管理があってこそですよ！また何かあればお任せください！！！


### EventBridge → SNS（Simple Notification Service）

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

https://qiita.com/ej2kd/items/f3ccbd7cfad76f9f78bf

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

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


<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/dd1a04af-b0b7-fdcc-70ed-5e7bd7158220.png" height="70" width="70"> < おっと、**S3バケットがパブリックアクセスを許可している**ようだ。これは[`s3account-level-public-access--blocks`](https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/s3-account-level-public-access-blocks.html)に従っていない！ちょっと**EventBridge**さん、**SNS**さんに連携しないとな！

～司令塔にて～

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/f6ceca7d-9bbf-eed1-4636-eadff9418e91.png" height="70" width="70"> < **SNS**さん！**Config**さんからルール違反を見つけたという報告が入りました！管理者の方にメッセージを届けてください！

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/8fb274ca-2156-65a5-936f-c5ded5fee3e1.png" height="70" width="70"> < 任せてください！通知を作成して、管理者全員にメールとLINEメッセージを送ります！それにSlack通知も必要ですよね？

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

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

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


## AWS CloudTrailとの違い

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

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

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

https://aws.amazon.com/jp/cloudtrail/


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


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

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

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/b7823a64-f530-0509-cc2e-60cfce84f11d.png" height="70" width="70"> < おや？すぎちゃん。ちょっと腹の肉がズボンに乗っかっているぞ？前はそんなことなかったのに。（**リソースの変更をモニタリング**）


<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/61c03f1c-59a6-9cce-de1a-d5f712c4281c.jpeg" width="70" height="70"> < 確かに2kg増えたけど・・・。何もしてないんだからねっ！

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/b7823a64-f530-0509-cc2e-60cfce84f11d.png" height="70" width="70">　< 何もしてないのに太るわけがない！そうだ**CloudTrail**。すぎちゃんの**行動履歴**を調べてくれ！

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/42f661ea-2e16-6ab3-ece6-bc8441be8099.png" height="70" width="70"> < ちょっと僕で色々監視させてもらったのですが、どうやらここ30日間で20回も家系ラーメンを平らげているようですね。（**いつ・だれが・何をしたのか を残す**）

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/dd1a04af-b0b7-fdcc-70ed-5e7bd7158220.png" height="70" width="70"> <最後に喋ったときに「減量するからラーメンは一切食べない！」と宣言していたのに・・・。自分で決めたルールを守れないなんて人として**非準拠**だ！よし**Lambdaさん!** すぎちゃんを徹底的に修復（ボコ）してしまえ！(**非準拠時の自動修復**)

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/41386bd4-9f71-1204-1cc3-f6e9d6399e48.png" width="70" height="70"> < 畏まりました。Config様。


<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401561/61c03f1c-59a6-9cce-de1a-d5f712c4281c.jpeg" width="70" height="70"> < お、お許しを～～～～～！！！！！！（このあと滅茶苦茶ダイエットした。）

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

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

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

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



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

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

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