パブリッククラウドのセキュリティ監視【MIXI TECH CONFERENCE 2023】

MIXI TECH CONFERENCE 2023
にてお話した軽部の資料です。

動画：https://youtu.be/wWfaHaqkcec
セッション詳細：https://techcon.mixi.co.jp/2023/d1-10

1. ©MIXI パブリッククラウドのセキュリティ監視 開発本部 セキュリティ室 軽部 正太
2. ©MIXI 自己紹介 軽部 正太 開発本部 セキュリティ室 / 開発本部 CTO室 SREグループ(兼務) 2018年中途入社 MIXIでやってきたこと ・脆弱性診断 ・サーバー開発 ・クラウド監視 ・インフラ開発 ・SOC ・Android開発 ・mixirt(CSIRT) ・新卒研修 ・などなど 2
3. ©MIXI アジェンダ 1. セキュリティ室の紹介 2. セキュリティ監視概要 3. 監視システムの紹介 4. 監視システムの構成 5. おわりに 3
4. ©MIXI セキュリティ室の紹介 4
5. ©MIXI 5 セキュリティ室の戦術の紹介 自社サービス アプリ インフラ 関連ツール 等 社内システム 端末 全社ツール 社内NW オフィス 設備 等 人間 アカウント 運用 脳内の情報 等 アタックサーフェス 対策の主体 事業部門 社内システム部門 各人・各部 セキュリティ室の支援の例 脆弱性診断（外注 / 内製） IaaS監視（AWS / GCP） 新卒エンジニア研修 ゼロトラスト支援（導入 / 啓発） EDRの共同運用、PFW設定見直し IDPの共同運用 パスワードマネージャの共同運用 ゼロトラスト支援（導入 / 啓発） 全職種向け研修 各種啓発や周知（全体朝会等） 業務委託監督の支援（教育資料等） 事故対応 mixirt (CSIRT)
6. ©MIXI セキュリティ監視概要 6
7. ©MIXI セキュリティ室による監視体制 • ターゲットはAWSとGoogle Cloud(GCP) • 設定の不備や侵害の検知がメイン • 特定の設定を出来なくするなどの強制は行っていない • 監視以外の施策に繋げることもあります ◦ ゼロトラスト支援 ◦ mixirt(CSIRT) ◦ など セキュリティ監視概要 7
8. ©MIXI セキュリティ監視概要 監視アカウント • AWS(Amazon Web Services) ◦ 約50アカウント ◦ ※ 全社対象ではない ◦ ※ 事業部側で監視している部門もある • Google Cloud(GCP) ◦ 4組織 / 100プロジェクト以上 8
9. ©MIXI AWSの監視設定 • AWS CloudTrail ◦ 監査ログ • AWS CloudTrail Insights ◦ 異常なアクティビティの検出 • Amazon GuardDuty ◦ 脅威検出サービス • OSSの設定監視ツール ◦ 各アカウントからRead権限を貰って設定の監視を行うツール セキュリティ監視概要 9
10. ©MIXI AWSの監視設定図 セキュリティ監視概要 10
11. ©MIXI 監視の導入(AWS) • 開発本部経由で作成されたアカウントについては、アカウント作成時点で必要なセ キュリティ設定をしてお渡ししている • それ以外のアカウントについては、必要に応じて個別に導入しています ◦ TerraformやCloudFormationのテンプレートを用意 ◦ IAMをもらってこちらで設定作業の支援も行っています セキュリティ監視概要 11
12. ©MIXI セキュリティ監視概要 Google Cloudの監視設定 • Security Command Center ◦ 設定の監視と脅威の検知 • 内製のリソース収集ツール ◦ Security Command Centerだけでは不十分な所を補っています ◦ Google Cloud上の各種リソースの設定収集や、BigQueryを使って複数のリ ソースを組み合わせた情報を作っています ◦ 監視システムに送って設定の精査をしてアラートを作ったりしています 12
13. ©MIXI Google Cloudの監視設定図 セキュリティ監視概要 13
14. ©MIXI 監視の導入(Google Cloud) • MIXIのOrganizationを使っている場合は最初から監視対象 • それ以外のOrganizationについては必要に応じて個別に導入しています ◦ Organizationにセキュリティ室用にProjectを作ってもらい各種設定を行って います セキュリティ監視概要 14
15. ©MIXI 監視システムの紹介 15
16. ©MIXI 監視システムって何？ 監視の効率化や強化、アラートの管理などを行うためにAWS上に構築した内製のシス テムです。 平和を司る女神の名前であるIreneという名前がついています。 既存のアラート対応の課題を解決しつつ、監視を効率化するために構築しました。 監視システムの紹介 16
17. ©MIXI 監視システムの紹介 既存の課題 既存の運用ではこんな課題がありました。 • 当初はアラートをSlackに通知しているだけだった ◦ プロジェクトも多く、それに比例してアラートも大量にあるため管理がかなり辛 い ◦ 過去の似たような対応を探すのも大分辛い • アラートの通知や、フィルタなどの処理がサービスごとにばらけてる • アラートの調査で時間がかかるので効率的に自動でやりたい 17
18. ©MIXI 監視システムの紹介 18 課題の解決 前ページの課題を解決するため、Ireneには以下のようないくつかの機能があります。 今回はその中からいくつかピックアップしてご紹介いたします。 • アラート管理 / 通知 • アラート調査機能 • アラート効率化のためのBot / Batch • 管理画面 ◦ 通知設定管理 ◦ アラート調査 ◦ 各種ドキュメント • etc…
19. ©MIXI アラートの評価・管理機能 アラートを管理するメイン機能からご紹介します。 • アラートの管理を設定できる機能で、AWSとGoogle Cloudのアラートを効率 的に管理するために作成しました • アラートを監視システムに通知するだけで、アラートの管理ができるようになっ ています • 各アラートに対して5段階の重大度で評価するルールを設定でき、重大度毎 にSlackやGitHub、PagerDutyでアラートの管理ができます 監視システムの紹介 19
20. ©MIXI 監視システムの紹介 ルールによるアラートの重大度の決定 • アラートに対して、内容に応じて独自で重大度を定義したルールを設定できます ◦ 元のアラートの定義より高くなるものもあれば、低くなるものもあります • 独自で定義することにより実際の運用に合った優先度で対応が行えます • 多数の似たアラートを抑制してアラート対応の効率化が行えたり、 また逆に、優先的に対応したいアラートが他のアラートに埋もれることなく素 早く対応出来るようになっています • 元のアラートの重大度をそのまま使うことも可能です ◦ そのため、優先して対応したいものや、対応不要なものだけ個別のルールを 設定するだけで済みます 20
21. ©MIXI ルールによるアラートの重大度の決定 • ルールによる評価はアラート単体の情報だけではなく、他の情報と組み合わせた りと柔軟に設定することができます ◦ 累積でXX回発生したら重大度を高くする ◦ 最初の１回以外は重大度を低くする ◦ 認証などなくインターネットからアクセスが出来るため重大度を高くする ◦ などなど 監視システムの紹介 21
22. ©MIXI 重大度の説明 • 緊急・高・中・低・対応不要の5段階をアラートに対して設定 ◦ 基本的には中以上のアラートを確認しています • 中以上はGitHubのIssueに自動で起票されアラートが管理されます • 緊急や高は優先して対応できるようにPagerDutyと連携 ◦ 緊急はPagerDutyと連携して24/7/365で対応できる体制 • 低はSlackへの通知のみで指摘内容に目を通すくらいの対応です ◦ 新規に追加したアラートの経過観察時など 監視システムの紹介 22
23. ©MIXI アラートのIssue管理 • 中以上のアラートは自動的にGitHub Issueに起票され管理されます ◦ アラートをIssueにすることで、対応が必要なアラートの可視化や対応記録を 残せるようにしています ◦ Issueにはアラートの情報も自動で記録されるため、基本的にサービスのコン ソールを見に行く必要がありません • 同一のアラートは同じIssueで管理されます ◦ 過去の対応が記録されているので、アラートの状況把握が簡単に出来るよう になっています 監視システムの紹介 23
24. ©MIXI アラートのIssue管理 IAMにMFAが設定されてないアラートのIssueです 監視システムの紹介 24
25. ©MIXI アラートのIssue管理 OPEN_FIREWALLのアラートが再度オープンされている様子です FIREWALLの設定が変わったため、再度アラートが飛んできています 過去の対応が記載されているため素早く状況把握と対応が可能です 監視システムの紹介 25
26. ©MIXI アラートのクローズルール • アラートをクローズするルールも設定できます ◦ リソースの設定が修正された時やリソースが削除された時など、問題が解決 した時 • クローズのルールにマッチした場合は自動でGitHubのIssueやPagerDutyのイン シデントのステータスがClose、Resolveに変更されます ◦ 自動でクローズされるため、対応の確認が不要です ◦ クローズ理由もコメントされるので対応記録としてもバッチリ 監視システムの紹介 26
27. ©MIXI アラートのクローズルール リソースが削除されたため、Issueが自動でクローズされた様子 監視システムの紹介 27
28. ©MIXI リソースの設定や監査ログのルール • サービスのアラートとは別に、リソースの設定に危険な設定がないか、監査ログに 危険なログがないかなどのルールを作成してアラートの通知も可能です • 設定はアラートと同様にルールを追加するだけです 監視システムの紹介 28
29. ©MIXI リソースの設定に対してのルール • リソースの設定に対してのルールは、既存の検知で上がってこないものを追加で 定義しています ◦ 例えば/3などの広範囲に公開しているFirewallの設定 ▪ 過去に/32で設定しようとした場合に誤って/3になっていたなどのケース があった ▪ 0.0.0.0/0ではないので既存のアラートでは上がらない ◦ Cloud Runなどサービスのアラートで見れないもの ▪ 非公開にすべきコンテンツを公開されてしまった等のインシデントの検出 監視システムの紹介 29
30. ©MIXI 監査ログに対してのルール • 監査ログは例えば以下のようなイベントを検知してアラートしています ◦ セキュリティサービスの設定の変更や停止 ◦ 国外からのサインイン ◦ 短期間の連続したサインインの失敗 ◦ などなど 監視システムの紹介 30
31. ©MIXI アラートの自動調査 アラートを自動で調査する機能もあるのでご紹介します。 • アラートの対応に必要な情報を自動で調査する機能です • 調査結果はアラートと同一のIssueに自動でコメントされるため、必要な情報が Issueに揃うようになっています • PagerDutyとも連携しています ◦ 調査内容で至急確認が必要なものがあった場合などに発報 • アラートをトリガーとするパターンと、バッチから定期確認されるパターンがありま す 監視システムの紹介 31
32. ©MIXI アラートの自動調査 - 例① • SecurityGroupやFirewallの公開設定のアラートはルールに該当しているインスタ ンスやIPを一覧化してチェックしています ◦ TCPでコネクションの試行 ▪ 接続ができれば追加でHTTPやSSHなどでの試行も行う ◦ 稼働しているサービスがHTTPの場合は画面キャプチャを取得 ▪ どんなWebサービスが動いているか一目でわかって便利 ◦ ルール自体は許可されてる場合もあるため、一定間隔で公開してはいけない リソースが作られていないか自動でチェックしています ▪ 前回から差分があった場合のみIssueにはコメントされる 監視システムの紹介 32
33. ©MIXI Firewallに紐づいているインスタンスの自動調査例 該当のFIREWALLのIssueにインスタンスと紐づいているIPの一覧が自動でコメントさ れている様子です 監視システムの紹介 33
34. ©MIXI アラートの自動調査 - 例② • IPやドメインなどが危険なものでないか調査する ◦ 例えば監査ログのコール元がTorなどの不審なものでないか調査してIssueに 自動でコメント ◦ 侵害検知のアラートの場合、Actorにどういった脅威があるかを調査して Issueに自動でコメント • 他にもアラートやリソースに応じて色々チェックしています 監視システムの紹介 34
35. ©MIXI キャプチャ機能 次にWebサービスに対して自動でキャプチャする機能のご紹介です。 SecurityGroupやFirewallの公開ルールに紐づいているIP、またCloud Runなどのイン ターネット公開が可能なサービス、後述のドメインクローリング機能でHTTPアクセスが 可能な場合は自動でキャプチャを取得しています。 キャプチャはSlackに投稿され、人間の目でチェックしています。 (GitHubのIssueにも紐づいています) しかし対象の数が膨大で人間の目で全て確認するのは限界があるため、 初回アクセス or 前回アクセスからサイトの差分が大きいものだけ通知されるように工 夫しています。 監視システムの紹介 35
36. ©MIXI キャプチャ機能の通知例(初回) キャプチャの取得に成功すると、以下のようにSlackに通知されます。 監視システムの紹介 36
37. ©MIXI キャプチャ機能の通知例(差分) ２回目以降は前回との差分が一定以上あった場合に通知され、 前回との差分がわかるようになっています。(右半分が差分) 監視システムの紹介 37
38. ©MIXI 監視システムの紹介 ドメインクローリング機能 監視下のドメインを一定時間ごとにクローリングしてキャプチャする機能もあります。 以下の検出を目的としており、この機能で問題のある設定を多数発見できています。こ の機能はAWSとGoogle Cloud以外も対象にしています。 • 管理画面など公開してはいけないサイトの公開の検知 ◦ 外部のサービスのリソースにドメインが紐づいているのを検出したケースもあ ります ▪ 既存のアラートでは検知できないパターン • サイトの改竄 • 消し忘れレコード ◦ 管理外のIPに紐づいてしまうケースを多数検出しています 38
39. ©MIXI アラート調査画面 Ireneには管理画面もあります。 その中にアラートを調査する機能があり、 アラートに関するイベントを時系列順に表示してくれるものがありますので ご紹介いたします。 ※ 現在はAWSのみ対応 監視システムの紹介 39
40. ©MIXI アラート調査画面 必要な情報を入力して検索ボタンを押下します。 「書き込みのみ」にチェックを入れると、作成/変更/削除系などのイベントのみにフィル ターされます 監視システムの紹介 40
41. ©MIXI アラート調査画面 書き込みオンにして検索した場合の画面です。 ※ CloudTrailのログはアラートの前後 xx件を取得しているので、 Createdから少し時間が飛んでいます 監視システムの紹介 41
42. ©MIXI アラート調査画面 アラートがあった付近のログ ※ 検索対象のイベントは背景が赤くなります 監視システムの紹介 42
43. ©MIXI アラート調査画面 アラート発生後のログ 監視システムの紹介 43
44. ©MIXI アラート調査画面 アラートの詳細を表示するにチェックすると対象のアラートの情報が表示されます。 監視システムの紹介 44
45. ©MIXI アラート調査画面 アラートに対して、時系列順に必要な情報を追えるので便利 今後は...以下のようなところを強化していきたい • Google Cloud対応 • 侵害対象がインスタンスであれば中の調査も ◦ GuardDutyのMalwareScanと連携 ◦ その他スキャンツールなどとも連携 監視システムの紹介 45
46. ©MIXI 監視システムの構成 46
47. ©MIXI • インフラ ◦ AWS (Lambda / DynamoDB / S3 / SQSなど) ◦ リソースはCloudFormationで管理 ◦ Production環境とStaging環境の２つの環境が存在 • アプリケーション ◦ 全てLambdaで動かしている ◦ 言語はGoと一部にPython ◦ 管理画面のフロントでJS(TS / Next.js) • CICD環境 ◦ GitHub Actions / CodePipeline / CodeBuild 監視システムの構成 47
48. ©MIXI 全体構成図 監視システムの構成 48
49. ©MIXI 設計のコンセプト アプリケーション/インフラ含め設計時に考えてたのは主に以下の３つ • なるべく低コストで運用 ◦ 設計~運用が一人だったのでなるべく負荷を下げたかった • アラートは見逃さないように ◦ バグやエラーなどで必要なアラートがなくならないように • 汎用的にする ◦ AWSとGoogle Cloud特有の処理をなるべくなくす ◦ AWSとGoogle Cloud以外でも使えるように ◦ 簡単にシステムに乗せられるように 監視システムの構成 49
50. ©MIXI 低コストで運用する • サーバー管理はしない • マネージドに寄せる。設定もシンプルなものを採用 ◦ ほぼこれに尽きる ◦ LambdaやDynamoDBを駆使している ▪ アプリケーションは全てLambda ▪ 管理画面もALB + Lambda ▪ 色々制約はある...が今のところ対応できている ◦ アラートの管理はGitHubのIssueを採用 ▪ コード管理でも使っているため環境の準備が不要 監視システムの構成 50
51. ©MIXI アラートは見逃さないようにする • SQSでメッセージのエラー管理(再送/DLQ) ◦ Lambdaがエラーになってもメッセージが消えないように ▪ 一定回数失敗するとDLQに入る ◦ LambdaとSQSのコンボはかなり便利でお気に入りです • エラーの検知と通知を充実させる ◦ アプリケーションエラーや障害など ◦ DLQにキューが残っている場合 ◦ エラー時にはSlackにメンション付きで飛ばしている 監視システムの構成 51
52. ©MIXI アラートは見逃さないようにする • アラートはS3に保存して、S3イベントをトリガーにする ◦ 万が一メッセージが消えた場合でもファイルとして残っているためアラートの 復元が容易 • Staging環境で検証できるように ◦ 検証してからProductionに反映することでミスを減らせるので必須 ◦ Stagingも実際のアラートの発報で検証できるようにしている • テストコードも充実させている ◦ アラートが期待通りに発砲するかなど 監視システムの構成 52
53. ©MIXI 汎用的にする • 特定のサービスに依存しない ◦ アラートやログをパースするだけで、ルールの作成、通知機能、アラート管理 など色々使えるように ◦ 他クラウドだけでなく、アプリケーションログやEDRのログなども取り込めるよ うにしている • 連携はS3を起点に ◦ S3にファイルを送ればよいだけなので連携が簡単 監視システムの構成 53
54. ©MIXI おわりに 54
55. ©MIXI いかがでしたでしょうか。 思い切って内製のシステムを作ってみましたが、期待以上に監視の 効率化が行え、必要なアラートを素早く対応することが出来ました。 その結果、重大なインシデントの発生を抑えられており、MIXIの安 全に貢献できると感じています。 おわりに 55
56. ©MIXI