srenext2022-skaru

SRE NEXT 2022
「AWS/GCPにおけるセキュリティ監視の取り組み」
での登壇資料です。
https://sre-next.dev/2022/schedule#sp05
#srenext #srenextA

Transcript

1. AWS/GCPにおける セキュリティ監視の取り組み 株式会社ミクシィ

2. 自己紹介 開発本部 セキュリティ室 / 開発本部 CTO室 SREグループ(兼務) 2018年中途入社 ミクシィでやってきたこと ・脆弱性診断 ・サーバー開発 ・クラウド監視 ・インフラ開発 ・SOC ・Android開発 ・CSIRT ・などなど
3. アジェンダ 1. はじめに 2. セキュリティ監視概要 3. 監視システムの紹介 4. 監視システムの構成 5. 今後の展望 6. おわりに
4. はじめに
5. はじめに 本セッションでは株式会社ミクシィ セキュリティ室で行っている、AWS / GCP のパブリッククラウドサービスのセキュリティ監視の取り組みについてご紹介 できればと思います。 前半では監視の全体像のご紹介を、 後半では内製の監視システムについてご紹介いたします。
6. セキュリティ監視概要
7. セキュリティ監視概要 セキュリティ室による監視体制 • ターゲットはAWSとGCP • 設定の不備や侵害の検知がメイン • 特定の設定を出来なくするなどの強制は行っていない • 必要に応じて対策の支援も行っている ◦ 非エンジニアへの設定の支援 ◦ セキュアにアクセスする仕組みの構築支援 ◦ などなど
8. セキュリティ監視概要 監視アカウント • AWS(Amazon Web Services) ◦ 約50アカウント ◦ ※ 全社対象ではない ◦ ※ 事業部側で監視している部門もある • GCP(Google Cloud Platform) ◦ 2組織 / 100プロジェクト以上
9. セキュリティ監視概要 AWSの監視設定 • AWS CloudTrail ◦ 監査ログ • AWS CloudTrail Insights ◦ 異常なアクティビティの検出 • Amazon GuardDuty ◦ 脅威検出サービス • OSSの設定監視ツール ◦ 各アカウントからRead権限を貰って設定の監視を行うツール
10. セキュリティ監視概要 AWSの監視設定図
11. セキュリティ監視概要 GCPの監視設定 • Security Command Center ◦ 設定の監視と脅威の検知 • 内製のリソース収集ツール ◦ Security Command Centerだけでは不十分な所を補っています ◦ GCP上の各種リソースの設定収集や、BigQueryを使って複数のリ ソースを組み合わせた情報を作っています ◦ 監視システムに送って設定の精査をしてアラートを作ったりしていま す
12. セキュリティ監視概要 GCPの監視設定図
13. 監視システムの紹介
14. 監視システムの紹介 監視システムって何？ 監視の効率化や強化、アラートの管理などを行うためにAWS上に構築した内 製のシステムです。 平和を司る女神の名前であるIreneという名前がついています。 既存のアラート対応での以下の課題を解決しつつ、 監視をパワーアップするために構築しました。 • アラートの通知を自分達で評価できるようにしたい • アラートの対応状況の管理や対応履歴を残したい • AWS/GCPのアラートを集約して管理したい • アラートの調査を自動でやりたい
15. 監視システムの紹介 それでは実際にどのような機能があり運用を改善しているか、ピックアップし てご紹介いたします。 本当は全部紹介したかったのですが時間の関係で無理でした、、、
16. アラートの評価・管理機能 • アラートを管理するメイン機能です • アラートに対して5段階の重大度で評価し、重大度毎に設定されたサービ スに通知され、管理されるようになっています ◦ SlackやGitHub、PagerDutyに通知されます • アラートを監視システムで受け取り、重大度を定義するルールを設定す るだけでアラート対応や管理ができる環境が簡単に構築できます 監視システムの紹介
17. ルールによるアラートの重大度の決定 • AWSやGCPの重大度の定義をベースに独自でルールを作成できるよう にしています • 元の定義より高くなるものもあれば、低くなるものもあります • 独自で定義することにより多数の似たアラートを抑制してアラート対応の 効率化が行えたり、 また逆に、優先的に対応したいアラートが他のアラートに埋もれることな く素早く対応出来るようになっています • デフォルトの重大度が設定できるので、優先して対応したいものや、対応 不要なものだけ個別にルールを設定するだけです 監視システムの紹介
18. ルールによるアラートの重大度の決定 • ルールによる評価はアラート単体の情報だけではなく、他の情報と組み 合わせたりと柔軟に設定することができます ◦ 累積でXX回発生したら重大度を高くする ◦ 最初の１回以外は重大度を低くする ◦ 特に認証などなくインターネットからアクセスが出来るため重大度を 高くする ◦ などなど 監視システムの紹介
19. 監視システムの紹介 重大度の説明 • 緊急・高・中・低・対応不要の5段階をアラートに対して設定 ◦ 基本的には中以上のアラートを確認しています • 中以上はGitHubのIssueに自動で起票されアラートが管理されます • 緊急や高は優先して対応できるようにPagerDutyと連携 ◦ 緊急はPagerDutyと連携して24/7/365で対応できる体制 • 低はSlackへの通知のみで指摘内容に目を通すくらいの対応です ◦ 新規に追加したアラートの経過観察時など
20. 監視システムの紹介 アラートのIssue管理 • 中以上のアラートは自動的にGitHub Issueに起票され管理されます ◦ アラートをIssueにすることで、対応が必要なアラートの可視化や対 応記録を残せるようにしています ◦ Issueにはアラートの情報も自動で記録されるため、基本的にサー ビスのコンソールを見に行く必要がありません • 同一のアラートは同じIssueで管理されます ◦ 過去の対応記録が記録されているので、アラートの状況把握が簡 単に出来ます
21. 監視システムの紹介 アラートのIssue管理 IAMにMFAが設定されてないアラートのIssueが起票されている様子です
22. 監視システムの紹介 アラートのIssue管理 OPEN_FIREWALLのアラートが再度オープンされている様子です FIREWALLの設定が変わったため、再度アラートが飛んできています 過去の対応記録が記載されているため素早く状況把握と対応が可能です
23. 監視システムの紹介 アラートのクローズルール • アラートをクローズするルールも設定できます ◦ リソースの設定が修正された時やリソースが削除された時など、問 題が解決した時 • アラートがルールにマッチした場合は自動でGitHubのIssueや PagerDutyのインシデントのステータスがClose、Resolveに変更されま す ◦ 自動でクローズされるため、対応の確認が不要です ◦ クローズ理由もコメントされるので対応記録としてもバッチリ
24. 監視システムの紹介 アラートのクローズルール リソースが削除されたため、Issueが自動でクローズされた様子
25. 監視システムの紹介 リソースの設定や監査ログのルール • リソースの設定に危険な設定がないか、監査ログに危険なログがないか などのルールを作成してアラートの通知が可能です • アラートと同様に評価ルールを設定して重大度を決定するだけです
26. 監視システムの紹介 リソースの設定に対してのルール • リソースの設定に対してのルールは、既存の検知で上がってこないもの を追加で定義しています ◦ 例えば/3などの広範囲に公開しているFirewallの設定 ▪ 過去に/32で設定しようとした場合に誤って/3になっていたなど のケースがあった ▪ 0.0.0.0/0ではないので既存のアラートでは上がらない ◦ Cloud Runなどサービスのアラートで見れないもの ▪ 意図せずインターネットに公開されてしまった等のインシデント の検出
27. 監視システムの紹介 監査ログに対してのルール • 監査ログは以下のようなイベントを検知してアラートしています ◦ セキュリティサービスの設定の変更や停止 ◦ 国外からのサインイン ◦ 短期間の連続したサインインの失敗 ◦ などなど
28. 監視システムの紹介 アラートの自動調査 • アラートの対応に必要な情報を自動で調査する機能です • 調査結果はアラートと同一のIssueに自動でコメントされるため、必要な 情報がIssueに揃うようになっています • PagerDutyとも連携しています ◦ 調査内容で至急確認が必要なものがあった場合などに発報 • アラートをトリガーとするパターンと、バッチから定期確認されるパターン があります
29. 監視システムの紹介 アラートの自動調査 - 例① • SecurityGroupやFirewallの公開設定のアラートはルールに該当してい るインスタンスやIPを一覧化してチェックしています ◦ TCPでコネクションの接続の試行 ▪ 接続ができれば追加でHTTPやSSHなどでの試行も行う ◦ 稼働しているサービスがHTTPの場合は画面キャプチャを取得 ▪ どんなWebサービスが動いているか一目でわかって便利 ◦ ルール自体は許可されてる場合もあるため、一定間隔で公開しては いけないリソースが作られていないか自動でチェックしています ▪ 前回から差分があった場合のみIssueにはコメントされる
30. 監視システムの紹介 アラートの自動調査 - 例② • IPやドメインなどが危険なものでないか調査する ◦ 例えば監査ログのコール元がTorなどの危険なIPでないか調査して Issueに自動でコメント ◦ 侵害検知のアラートの場合、Actorにどういった脅威があるかを調査 してIssueに自動でコメント • 他にもアラートやリソースに応じて色々チェックしています
31. 監視システムの紹介 Firewallに紐づいているインスタンスの自動調査例 該当のFIREWALLのIssueにインスタンスと紐づいているIPの一覧が自動で コメントされている様子です
32. 監視システムの紹介 キャプチャ機能 SecurityGroupやFirewallの公開ルールに紐づいているIP、またCloud Run などのインターネット公開が可能なサービス、後述のドメインクローリング機能 でHTTPアクセスが可能な場合は自動でキャプチャを取得しています。 キャプチャはSlackに投稿され、人間の目でチェックしています。 (GitHubのIssueにも紐づいています) しかし対象の数が膨大で人間の目で全て確認するのは限界があるため、 初回アクセス or 前回アクセスからサイトの差分が大きいものだけ通知される ように工夫しています。
33. 監視システムの紹介 キャプチャ機能の通知例 左は初回、右は２回目以降のキャプチャ通知です ２回目以降は前回との差分が一定以上あった場合に通知され、前回との差分 がわかるようになっています
34. 監視システムの紹介 ドメインクローリング機能 監視下のドメインを一定時間ごとにクローリングしてキャプチャする機能もあり ます。 以下の検出を目的としており、この機能で問題のある設定を多数発見できて います。この機能はAWSとGCP以外も対象にしています。 • 管理画面など公開してはいけないサイトの公開の検知 ◦ 外部のサービスのリソースにドメインが紐づいているのを検出した ケースもあります ▪ 既存のアラートでは検知できないパターン • サイトの改竄 • 消し忘れレコード ◦ 管理外のIPに紐づいてしまうケースを多数検出しています
35. 監視システムの紹介 その他機能 他にも色々機能が盛りだくさんです！ • プロジェクト単位でSlack通知を管理する機能 • アラートやリソースの検索機能 • アラート確認の催促通知 • 脅威情報収集機能 • 設定管理やドキュメント閲覧用のWeb管理画面 • 効率化のためのバッチやボット • などなど
36. 監視システムの構成
37. 監視システムの構成 • インフラ ◦ AWS (Lambda / DynamoDB / S3 / SQSなど) ◦ リソースはCloudFormationで管理 ◦ Production環境とStaging環境の２つの環境が存在 • アプリケーション ◦ 全てLambdaで動かしている ◦ 言語はGoと一部にPython ◦ 管理画面のフロントでJS(TS/Next.js) • CICD環境 ◦ Github Action / Code Pipeline / Code Build
38. 監視システムの構成 全体構成図
39. 監視システムの構成 設計のコンセプト アプリケーション/インフラ含め設計時に考えてたのは主に以下の３つ • なるべく低コストで運用 ◦ 設計~運用が一人だったのでなるべく負荷を下げたかった ◦ 現在は新卒の方がJoinしてくれたので二人体制で運用中 • アラートは見逃さないように ◦ バグやエラーなどで必要なアラートがなくならないように • 汎用的にする ◦ AWSとGCP以外でも使えるように ◦ 簡単にシステムに乗せられるように
40. 監視システムの構成 低コストで運用する • サーバー管理はしない • マネージドに寄せる。設定もシンプルなものを採用 ◦ ほぼこれに尽きる ◦ LambdaやDynamoDBを駆使している ▪ アプリケーションは全てLambda ▪ 管理画面もALB + Lambda ▪ 色々制約はある...が今のところ対応できている ◦ アラートの管理はGitHubのIssueを採用 ▪ コード管理でも使っているため環境の準備が不要
41. 監視システムの構成 アラートは見逃さないようにする • SQSでメッセージのエラー管理(再送/DLQ) ◦ Lambdaがエラーになってもメッセージが消えないように ▪ 一定回数失敗するとDLQに入る ◦ LambdaとSQSのコンボはかなり便利でお気に入りです • エラーの検知と通知を充実させる ◦ アプリケーションエラーやAWSサービスのエラー/障害など ◦ エラー時にはSlackにメンション付きで飛ばしている
42. 監視システムの構成 アラートは見逃さないようにする • アラートはS3に保存して、S3イベントをトリガーにする ◦ 万が一メッセージが消えた場合でもファイルとして残っているためア ラートの復元が容易 • Staging環境で検証できるように ◦ 検証してからProductionに反映することでミスを減らせるので必須 ◦ Stagingも実際のアラートの発報で検証できるようにしている • テストコードも充実させている
43. 監視システムの構成 汎用的にする • サービスに依存しない ◦ アラート等を特定のフォーマットにパースするだけで、ルールの作 成、通知機能、アラート管理など色々使えるように ◦ 他クラウドだけでなく、アプリケーションログやEDRのログなども取り 込めるようにしている • 連携はS3を起点に ◦ S3にファイルを送ればよいだけなので連携が簡単
44. 今後の展望
45. 今後の展望 • AWS Organizationsの検討 ◦ アカウントも増えてきたのでそろそろ欲しくなってきました • 監視アカウントの拡大 ◦ 目指せ全社 • レスポンスの強化 ◦ 今のところ大きな事故もなく平和だが、何か起きたときの対応も強化 したい • AWS/GCP以外での監視システムの導入 ◦ せっかく汎用的に作ったので何かに使ってみたい
46. おわりに
47. おわりに いかがでしたでしょうか。 思い切って内製のシステムを作ってみましたが、期待以上に監視の効率化が 行え、必要なアラートを素早く対応することが出来、結果重大なインシデントの 発生を抑えられていると感じています。 そして、これらのInsecure なクラウド設定を検出できることが事故や障害を未 然に防ぎ、ひいては可用性に責任を持つSRE として寄与すると考えていま す。 また、今回は監視システムの概要の話で終わってしまいましたが、コード実装 の工夫の話とか、アラート対応の実運用の話とか、監視の導入周りの話と か、システム運用でのつらみの話とか...他の話もどこかでできればいいなと 思っています！
48. We Are Hiring! We Are Hiring! SREの募集一覧
 ミクシィ 採用
 SRE求人3件、サーバーサイド求人10件！
 ミクシィグループでは、
 SREの皆さんのご応募をお待ちしています
 家族アルバム みてね 言語：Ruby モンスターストライク 言語：Ruby、Go 事業横断の開発本部 では、 通常の中途採用に加えて第二新卒採用も実施中！ 言語：Go、Ruby、Elixirなど 採用サイト