Slide 1
Slide 1 text
AWS Config 設定しておけ OK！
…じゃないって本当？
AWS Config 運用あるあるを
どう乗りこなしているか
Slide 2
Slide 2 text
自己紹介
アカツキゲームス
Yuto Komai / 駒井 祐人
e__koma
過去 実績等
● AWS Summit Online 2020
○ 今回 クラウドセキュリティ 話
● AWS Summit Tokyo 2019
○ モバイルゲーム ECS 運用
+ 大規模負荷テスト 話
● AWS official YouTube channel
○ ECS スケーリング 簡易的な説明
Slide 3
Slide 3 text
話すこと
AWS Config 具体的な運用例
Slide 4
Slide 4 text
話 前提
● Organizations 配下に AWS アカウントが数十個以上存在し
定期的に増減するような状況を想定
● Config 社内セキュリティポリシーを守るため 1つ ツール
○ （脅威検知や脆弱性管理など総合的な仕組みが必要で、
Config 運用しときゃクラウド
セキュリティ バッチリ、という話で ないことを事前に補足）
Slide 5
Slide 5 text
AWS Config と （今回 必須知識）
AWS セキュリティ監査を自動化できるサービス
例：
● 全世界にパブリックな Security Group が作られた
● S3 にパブリック読み取りアクセスが許可されている
● RDS スナップショットが公開されてしまっている
適切に運用すれ 「誰かが」「知らない間に」 「手動で」「別リージョンで」全世界公開
サーバを立ててしまった。こんなサーバも自動検知できる。
Slide 6
Slide 6 text
最高じゃん！
… と思いきや？
Slide 7
Slide 7 text
あるある①
意図した公開サーバも問答無用に NG
Slide 8
Slide 8 text
公開サーバ 全て非準拠 (NG) として検知する
意図した公開まで全てルール非準拠 (NG) となってしまう。
柔軟性がないルール 多く、NG 結果を多く残しておくと
本当に対応すべきリソースかどうか判断が鈍る で対処したい。
Slide 9
Slide 9 text
解決策: カスタムルール Lambda 運用
※ アーキテクチャ 後ほど話します
Slide 10
Slide 10 text
カスタムルール Lambda 運用
1. 例外登録
個別アカウント 個別 ResourceId を検知対象外にする仕組みを構築
Slide 11
Slide 11 text
Q. マネージドで実現する方法 ？
A. Config 単体で できませんが、
Security Hub と統合することで、
例外登録に準ずる機能が 最近 (やっと...) 可能に。
※ 登録できるルール 個数上限やメンバーアカウント Config 見え方など
まだもう一声という印象 あるが、かなり改善した
Slide 12
Slide 12 text
カスタムルール Lambda 運用
2. カスタムポリシー 実現
社内ポリシーに合わせて Config ルールを作成している
△ Config ルールがあるから、それに準ずる
◯ 社内ポリシー(※1) を整備し、マッチするも Config を利用。
足りない部分 カスタムルールで解決する。(※2)
(※1) ISO など業界標準に準拠しつつ自社向けにカスタマイズしたポリシー
(※2) awslabs に PR を投げてマージされたことも
Slide 13
Slide 13 text
カスタムルール Lambda 運用
2. カスタムポリシー 実現
例: セキュリティグループに許可できる IP 数 N 個以下まで
（頼むからやめてくれ 図
Slide 14
Slide 14 text
カスタムルール Lambda 運用
Slide 15
Slide 15 text
カスタムルール Lambda 運用
3. 全アカウント一括自動デプロイ
● CloudFormation StackSets で全アカウントに一括デプロイ
● 新規 AWS アカウント作成時にも自動的にデプロイされる
詳細 AWS Summit 2020 資料を参考に
( 最近で Config を Organization に一括デプロイする機能もあるが、
StackSets 他 リソースで
も利用している で引き続き StackSets を利用している )
Slide 16
Slide 16 text
あるある②
例 アラート
対応してくれてる ？
Slide 17
Slide 17 text
クラウドセキュリティ担当 スコープ
#マルチクラウド
#全アカウント
#全リージョン
#子会社
加えて Config 以外 アラートもある。日々発生するアラート 反応できるが、
新しいアラートがどんどん通知されるため、1個1個対応状況を管理してられな
い。
あれ...例 アラートって
「反応 してもらえたけど、対応 進んでる ...？」
Slide 18
Slide 18 text
アラート管理 工夫
● リアルタイム通知
管理者へ自動メンション
● 定期サマリ
対応状況 定期まとめ通知
セキュリティ担当 インシデントレベルが高そうな通知と
まとめ通知 みに反応していれ 運用スケール可能に
Slide 19
Slide 19 text
あるある③
NG 検知 ゴミ
Slide 20
Slide 20 text
NG 検知がゴミとして残ってしまう
AWS アカウントを解約しても90日間 リソースが残り続けてしまう
● Config NG 結果を放置して解約すると
集約アカウントに 消せないNG結果 (ゴミ) が残り続けてしまう
● 集約している EventBridge なども飛んでくる
● Route53 なども消しておく が吉
アカウント解約時 事前にリソース削除をしましょう
Slide 21
Slide 21 text
あるある④
知らない間に Config ルールが増える
Slide 22
Slide 22 text
あなた 知らない Config 世界
AWS blog を毎日チェックしているみなさん！
残念ながら Config 最新情報 キャッチアップできておりません
Slide 23
Slide 23 text
あなた 知らない Config 世界
AWS blog を毎日チェックしているみなさん！
残念ながら Config 最新情報 キャッチアップできておりません
なぜなら、マネージド Config Rule 定期的にしれっと追加されるから
昔 ブログになってたんだけど ...
Slide 24
Slide 24 text
最新 Config ルール 取得と管理
最新 Config ルールを自動チェックする仕組みを作り
定期的に導入可否を判断している
● チェック済み ルール一覧を保持
● チェックしてない Config ルールがあれ 定期通知
● 一覧を更新
Slide 25
Slide 25 text
そ 他
Slide 26
Slide 26 text
そ 他、色んなパターン 検知
カスタムルールを充実させる運用が回ると
クラウド設定以外 ポリシー検知も捗ります
例
● EDR がサーバ上で動いているか自動検知
● WordPress 管理画面に IP 制限がかかっているか検知
などなど
Slide 27
Slide 27 text
運用を工夫すれ 、アカウントが増えても
スケールする仕組みを実現可能です
幸せな CSPM ライフを！！