なぜ我々は苦しんでいるのか
日々たくさんのAWSリソースを作成し運用する我々はAWSリソースに様々な設定を施します。
その中で以下のような苦しみを抱えています。
多数のAWSリソースに共通する設定があることを担保したい！
- 「多数のVPCでVPCフローログの設定を統一できてたっけ・・・・・・？」
- 「rootユーザーのMFA設定を忘れてないか心配・・・・・・」
我々はたくさんのAWSリソースに対して共通の設定を入れるようにします。
それらの共通設定を維持するには作成時の設定だけでなく定期的な抜け漏れのチェックする運用が必要になります。
セキュリティ上危ない設定をAWSリソースに入れられないようにしたい！
- 「セキュリティグループに許可ルールを足すとき大は小を兼ねるで広すぎるIPレンジに許可しちゃう人がいないか怖い・・・・・・」
- 「TLSが下位バージョンの通信を受け入れてしまう箇所がうっかりできていないか心配で眠れない・・・・・・」
共通する設定を「入れる」仕組みはCloudformationが提供されています。
しかし共通する設定を「入れない」仕組みは意外と思いつきません。
結局IaCなんて絵空事なのか
Cloudformationなどで綺麗に同じ設定のリソースを作っても、均一さが維持されないかもしれません。
例外的な対応の中でセキュリティグループルールを足してしまったり、手動で間違った設定をしてしまったり。
Configルールは我々に何をもたらすのか
簡単に言ってしまうと、「我々が常に入れたい/入れたくない設定があるかチェック」してくれる機能です。
AWS Config を使用して AWS リソースの設定内容を評価します。
ルール違反リソースを見つける
Config マネージドルールを使うと以下のような状態を検知できます。
- 「ELBがルールで定められたS3バケットにアクセスログを出力していない」
- 「セキュリティグループが0.0.0.0/0に対してSSHポートを開放している」
すぐ使えるマネージドルールたち
以下がAWSマネージドルールの一覧です。
これらのルールについてはパラメータを渡すだけでアカウント内のリソース設定の監視が実現できます。
以下のルールならパラメータすら渡す必要がなく、入れるだけお得なルールになっています。
- セキュリティグループがsshポートを0.0.0.0/0に開放しているか（INCOMING_SSH_DISABLED）
- rootユーザーのMFAチェック（ROOT_ACCOUNT_MFA_ENABLED）
でもお高いんでしょう？
賢明な参加者のみなさんは機能の便利さだけに目を奪われず、ここでコストのことが気になっていることでしょう。
結論だけ言うと、マネージドルールは日次のチェックであれば1ルール月々3円程度でご利用いただけます。
1つのConfigルールの評価(日次チェック)
0.001USD * 30 = 0.03USD
≒ 3円
価格はルールでリソースをスキャンした「回数」によって決まります。
スキャン対象のリソースの数は無関係です。
なのでたくさんのリソースがある環境でも安心して利用できます。
Configの設定履歴の料金は別途かかります。