パブリッククラウドのセキュリティ監視【MIXI TECH CONFERENCE 2023】

Slide 1

Slide 1 text

©MIXI パブリッククラウドのセキュリティ監視開発本部セキュリティ室軽部正太

Slide 2

Slide 2 text

©MIXI 自己紹介軽部正太開発本部セキュリティ室 / 開発本部 CTO室 SREグループ(兼務) 2018年中途入社 MIXIでやってきたこと・脆弱性診断・サーバー開発・クラウド監視・インフラ開発・SOC ・Android開発・mixirt(CSIRT) ・新卒研修・などなど 2

Slide 3

Slide 3 text

©MIXI アジェンダ 1. セキュリティ室の紹介 2. セキュリティ監視概要 3. 監視システムの紹介 4. 監視システムの構成 5. おわりに 3

Slide 4

Slide 4 text

©MIXI セキュリティ室の紹介 4

Slide 5

Slide 5 text

©MIXI 5 セキュリティ室の戦術の紹介自社サービスアプリインフラ関連ツール等社内システム端末全社ツール社内NW オフィス設備等人間アカウント運用脳内の情報等アタックサーフェス対策の主体事業部門社内システム部門各人・各部セキュリティ室の支援の例脆弱性診断（外注 / 内製） IaaS監視（AWS / GCP）新卒エンジニア研修ゼロトラスト支援（導入 / 啓発） EDRの共同運用、PFW設定見直し IDPの共同運用パスワードマネージャの共同運用ゼロトラスト支援（導入 / 啓発）全職種向け研修各種啓発や周知（全体朝会等）業務委託監督の支援（教育資料等）事故対応 mixirt (CSIRT)

Slide 6

Slide 6 text

©MIXI セキュリティ監視概要 6

Slide 7

Slide 7 text

©MIXI セキュリティ室による監視体制 ● ターゲットはAWSとGoogle Cloud(GCP) ● 設定の不備や侵害の検知がメイン ● 特定の設定を出来なくするなどの強制は行っていない ● 監視以外の施策に繋げることもあります ○ ゼロトラスト支援 ○ mixirt(CSIRT) ○ などセキュリティ監視概要 7

Slide 8

Slide 8 text

©MIXI セキュリティ監視概要監視アカウント ● AWS(Amazon Web Services) ○ 約50アカウント ○ ※ 全社対象ではない ○ ※ 事業部側で監視している部門もある ● Google Cloud(GCP) ○ 4組織 / 100プロジェクト以上 8

Slide 9

Slide 9 text

©MIXI AWSの監視設定 ● AWS CloudTrail ○ 監査ログ ● AWS CloudTrail Insights ○ 異常なアクティビティの検出 ● Amazon GuardDuty ○ 脅威検出サービス ● OSSの設定監視ツール ○ 各アカウントからRead権限を貰って設定の監視を行うツールセキュリティ監視概要 9

Slide 10

Slide 10 text

©MIXI AWSの監視設定図セキュリティ監視概要 10

Slide 11

Slide 11 text

©MIXI 監視の導入(AWS) ● 開発本部経由で作成されたアカウントについては、アカウント作成時点で必要なセキュリティ設定をしてお渡ししている ● それ以外のアカウントについては、必要に応じて個別に導入しています ○ TerraformやCloudFormationのテンプレートを用意 ○ IAMをもらってこちらで設定作業の支援も行っていますセキュリティ監視概要 11

Slide 12

Slide 12 text

©MIXI セキュリティ監視概要 Google Cloudの監視設定 ● Security Command Center ○ 設定の監視と脅威の検知 ● 内製のリソース収集ツール ○ Security Command Centerだけでは不十分な所を補っています ○ Google Cloud上の各種リソースの設定収集や、BigQueryを使って複数のリソースを組み合わせた情報を作っています ○ 監視システムに送って設定の精査をしてアラートを作ったりしています 12

Slide 13

Slide 13 text

©MIXI Google Cloudの監視設定図セキュリティ監視概要 13

Slide 14

Slide 14 text

©MIXI 監視の導入(Google Cloud) ● MIXIのOrganizationを使っている場合は最初から監視対象 ● それ以外のOrganizationについては必要に応じて個別に導入しています ○ Organizationにセキュリティ室用にProjectを作ってもらい各種設定を行っていますセキュリティ監視概要 14

Slide 15

Slide 15 text

©MIXI 監視システムの紹介 15

Slide 16

Slide 16 text

©MIXI 監視システムって何？監視の効率化や強化、アラートの管理などを行うためにAWS上に構築した内製のシステムです。平和を司る女神の名前であるIreneという名前がついています。既存のアラート対応の課題を解決しつつ、監視を効率化するために構築しました。監視システムの紹介 16

Slide 17

Slide 17 text

©MIXI 監視システムの紹介既存の課題既存の運用ではこんな課題がありました。 ● 当初はアラートをSlackに通知しているだけだった ○ プロジェクトも多く、それに比例してアラートも大量にあるため管理がかなり辛い ○ 過去の似たような対応を探すのも大分辛い ● アラートの通知や、フィルタなどの処理がサービスごとにばらけてる ● アラートの調査で時間がかかるので効率的に自動でやりたい 17

Slide 18

Slide 18 text

©MIXI 監視システムの紹介 18 課題の解決前ページの課題を解決するため、Ireneには以下のようないくつかの機能があります。今回はその中からいくつかピックアップしてご紹介いたします。 ● アラート管理 / 通知 ● アラート調査機能 ● アラート効率化のためのBot / Batch ● 管理画面 ○ 通知設定管理 ○ アラート調査 ○ 各種ドキュメント ● etc…

Slide 19

Slide 19 text

©MIXI アラートの評価・管理機能アラートを管理するメイン機能からご紹介します。 ● アラートの管理を設定できる機能で、AWSとGoogle Cloudのアラートを効率的に管理するために作成しました ● アラートを監視システムに通知するだけで、アラートの管理ができるようになっています ● 各アラートに対して5段階の重大度で評価するルールを設定でき、重大度毎にSlackやGitHub、PagerDutyでアラートの管理ができます監視システムの紹介 19

Slide 20

Slide 20 text

©MIXI 監視システムの紹介ルールによるアラートの重大度の決定 ● アラートに対して、内容に応じて独自で重大度を定義したルールを設定できます ○ 元のアラートの定義より高くなるものもあれば、低くなるものもあります ● 独自で定義することにより実際の運用に合った優先度で対応が行えます ● 多数の似たアラートを抑制してアラート対応の効率化が行えたり、また逆に、優先的に対応したいアラートが他のアラートに埋もれることなく素早く対応出来るようになっています ● 元のアラートの重大度をそのまま使うことも可能です ○ そのため、優先して対応したいものや、対応不要なものだけ個別のルールを設定するだけで済みます 20

Slide 21

Slide 21 text

©MIXI ルールによるアラートの重大度の決定 ● ルールによる評価はアラート単体の情報だけではなく、他の情報と組み合わせたりと柔軟に設定することができます ○ 累積でXX回発生したら重大度を高くする ○ 最初の１回以外は重大度を低くする ○ 認証などなくインターネットからアクセスが出来るため重大度を高くする ○ などなど監視システムの紹介 21

Slide 22

Slide 22 text

©MIXI 重大度の説明 ● 緊急・高・中・低・対応不要の5段階をアラートに対して設定 ○ 基本的には中以上のアラートを確認しています ● 中以上はGitHubのIssueに自動で起票されアラートが管理されます ● 緊急や高は優先して対応できるようにPagerDutyと連携 ○ 緊急はPagerDutyと連携して24/7/365で対応できる体制 ● 低はSlackへの通知のみで指摘内容に目を通すくらいの対応です ○ 新規に追加したアラートの経過観察時など監視システムの紹介 22

Slide 23

Slide 23 text

©MIXI アラートのIssue管理 ● 中以上のアラートは自動的にGitHub Issueに起票され管理されます ○ アラートをIssueにすることで、対応が必要なアラートの可視化や対応記録を残せるようにしています ○ Issueにはアラートの情報も自動で記録されるため、基本的にサービスのコンソールを見に行く必要がありません ● 同一のアラートは同じIssueで管理されます ○ 過去の対応が記録されているので、アラートの状況把握が簡単に出来るようになっています監視システムの紹介 23

Slide 24

Slide 24 text

©MIXI アラートのIssue管理 IAMにMFAが設定されてないアラートのIssueです監視システムの紹介 24

Slide 25

Slide 25 text

©MIXI アラートのIssue管理 OPEN_FIREWALLのアラートが再度オープンされている様子です FIREWALLの設定が変わったため、再度アラートが飛んできています過去の対応が記載されているため素早く状況把握と対応が可能です監視システムの紹介 25

Slide 26

Slide 26 text

©MIXI アラートのクローズルール ● アラートをクローズするルールも設定できます ○ リソースの設定が修正された時やリソースが削除された時など、問題が解決した時 ● クローズのルールにマッチした場合は自動でGitHubのIssueやPagerDutyのインシデントのステータスがClose、Resolveに変更されます ○ 自動でクローズされるため、対応の確認が不要です ○ クローズ理由もコメントされるので対応記録としてもバッチリ監視システムの紹介 26

Slide 27

Slide 27 text

©MIXI アラートのクローズルールリソースが削除されたため、Issueが自動でクローズされた様子監視システムの紹介 27

Slide 28

Slide 28 text

©MIXI リソースの設定や監査ログのルール ● サービスのアラートとは別に、リソースの設定に危険な設定がないか、監査ログに危険なログがないかなどのルールを作成してアラートの通知も可能です ● 設定はアラートと同様にルールを追加するだけです監視システムの紹介 28

Slide 29

Slide 29 text

©MIXI リソースの設定に対してのルール ● リソースの設定に対してのルールは、既存の検知で上がってこないものを追加で定義しています ○ 例えば/3などの広範囲に公開しているFirewallの設定 ■ 過去に/32で設定しようとした場合に誤って/3になっていたなどのケースがあった ■ 0.0.0.0/0ではないので既存のアラートでは上がらない ○ Cloud Runなどサービスのアラートで見れないもの ■ 非公開にすべきコンテンツを公開されてしまった等のインシデントの検出監視システムの紹介 29

Slide 30

Slide 30 text

©MIXI 監査ログに対してのルール ● 監査ログは例えば以下のようなイベントを検知してアラートしています ○ セキュリティサービスの設定の変更や停止 ○ 国外からのサインイン ○ 短期間の連続したサインインの失敗 ○ などなど監視システムの紹介 30

Slide 31

Slide 31 text

©MIXI アラートの自動調査アラートを自動で調査する機能もあるのでご紹介します。 ● アラートの対応に必要な情報を自動で調査する機能です ● 調査結果はアラートと同一のIssueに自動でコメントされるため、必要な情報が Issueに揃うようになっています ● PagerDutyとも連携しています ○ 調査内容で至急確認が必要なものがあった場合などに発報 ● アラートをトリガーとするパターンと、バッチから定期確認されるパターンがあります監視システムの紹介 31

Slide 32

Slide 32 text

©MIXI アラートの自動調査 - 例① ● SecurityGroupやFirewallの公開設定のアラートはルールに該当しているインスタンスやIPを一覧化してチェックしています ○ TCPでコネクションの試行 ■ 接続ができれば追加でHTTPやSSHなどでの試行も行う ○ 稼働しているサービスがHTTPの場合は画面キャプチャを取得 ■ どんなWebサービスが動いているか一目でわかって便利 ○ ルール自体は許可されてる場合もあるため、一定間隔で公開してはいけないリソースが作られていないか自動でチェックしています ■ 前回から差分があった場合のみIssueにはコメントされる監視システムの紹介 32

Slide 33

Slide 33 text

©MIXI Firewallに紐づいているインスタンスの自動調査例該当のFIREWALLのIssueにインスタンスと紐づいているIPの一覧が自動でコメントされている様子です監視システムの紹介 33

Slide 34

Slide 34 text

©MIXI アラートの自動調査 - 例② ● IPやドメインなどが危険なものでないか調査する ○ 例えば監査ログのコール元がTorなどの不審なものでないか調査してIssueに自動でコメント ○ 侵害検知のアラートの場合、Actorにどういった脅威があるかを調査して Issueに自動でコメント ● 他にもアラートやリソースに応じて色々チェックしています監視システムの紹介 34

Slide 35

Slide 35 text

©MIXI キャプチャ機能次にWebサービスに対して自動でキャプチャする機能のご紹介です。 SecurityGroupやFirewallの公開ルールに紐づいているIP、またCloud Runなどのインターネット公開が可能なサービス、後述のドメインクローリング機能でHTTPアクセスが可能な場合は自動でキャプチャを取得しています。キャプチャはSlackに投稿され、人間の目でチェックしています。 (GitHubのIssueにも紐づいています) しかし対象の数が膨大で人間の目で全て確認するのは限界があるため、初回アクセス or 前回アクセスからサイトの差分が大きいものだけ通知されるように工夫しています。監視システムの紹介 35

Slide 36

Slide 36 text

©MIXI キャプチャ機能の通知例(初回) キャプチャの取得に成功すると、以下のようにSlackに通知されます。監視システムの紹介 36

Slide 37

Slide 37 text

©MIXI キャプチャ機能の通知例(差分) ２回目以降は前回との差分が一定以上あった場合に通知され、前回との差分がわかるようになっています。(右半分が差分) 監視システムの紹介 37

Slide 38

Slide 38 text

©MIXI 監視システムの紹介ドメインクローリング機能監視下のドメインを一定時間ごとにクローリングしてキャプチャする機能もあります。以下の検出を目的としており、この機能で問題のある設定を多数発見できています。この機能はAWSとGoogle Cloud以外も対象にしています。 ● 管理画面など公開してはいけないサイトの公開の検知 ○ 外部のサービスのリソースにドメインが紐づいているのを検出したケースもあります ■ 既存のアラートでは検知できないパターン ● サイトの改竄 ● 消し忘れレコード ○ 管理外のIPに紐づいてしまうケースを多数検出しています 38

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

©MIXI アラート調査画面アラートに対して、時系列順に必要な情報を追えるので便利今後は...以下のようなところを強化していきたい ● Google Cloud対応 ● 侵害対象がインスタンスであれば中の調査も ○ GuardDutyのMalwareScanと連携 ○ その他スキャンツールなどとも連携監視システムの紹介 45

Slide 46

Slide 46 text

Slide 47

Slide 47 text

©MIXI ● インフラ ○ AWS (Lambda / DynamoDB / S3 / SQSなど) ○ リソースはCloudFormationで管理 ○ Production環境とStaging環境の２つの環境が存在 ● アプリケーション ○ 全てLambdaで動かしている ○ 言語はGoと一部にPython ○ 管理画面のフロントでJS(TS / Next.js) ● CICD環境 ○ GitHub Actions / CodePipeline / CodeBuild 監視システムの構成 47

Slide 48

Slide 48 text

Slide 49

Slide 49 text

©MIXI 設計のコンセプトアプリケーション/インフラ含め設計時に考えてたのは主に以下の３つ ● なるべく低コストで運用 ○ 設計~運用が一人だったのでなるべく負荷を下げたかった ● アラートは見逃さないように ○ バグやエラーなどで必要なアラートがなくならないように ● 汎用的にする ○ AWSとGoogle Cloud特有の処理をなるべくなくす ○ AWSとGoogle Cloud以外でも使えるように ○ 簡単にシステムに乗せられるように監視システムの構成 49

Slide 50

Slide 50 text

©MIXI 低コストで運用する ● サーバー管理はしない ● マネージドに寄せる。設定もシンプルなものを採用 ○ ほぼこれに尽きる ○ LambdaやDynamoDBを駆使している ■ アプリケーションは全てLambda ■ 管理画面もALB + Lambda ■ 色々制約はある...が今のところ対応できている ○ アラートの管理はGitHubのIssueを採用 ■ コード管理でも使っているため環境の準備が不要監視システムの構成 50

Slide 51

Slide 51 text

©MIXI アラートは見逃さないようにする ● SQSでメッセージのエラー管理(再送/DLQ) ○ Lambdaがエラーになってもメッセージが消えないように ■ 一定回数失敗するとDLQに入る ○ LambdaとSQSのコンボはかなり便利でお気に入りです ● エラーの検知と通知を充実させる ○ アプリケーションエラーや障害など ○ DLQにキューが残っている場合 ○ エラー時にはSlackにメンション付きで飛ばしている監視システムの構成 51

Slide 52

Slide 52 text

©MIXI アラートは見逃さないようにする ● アラートはS3に保存して、S3イベントをトリガーにする ○ 万が一メッセージが消えた場合でもファイルとして残っているためアラートの復元が容易 ● Staging環境で検証できるように ○ 検証してからProductionに反映することでミスを減らせるので必須 ○ Stagingも実際のアラートの発報で検証できるようにしている ● テストコードも充実させている ○ アラートが期待通りに発砲するかなど監視システムの構成 52

Slide 53

Slide 53 text

©MIXI 汎用的にする ● 特定のサービスに依存しない ○ アラートやログをパースするだけで、ルールの作成、通知機能、アラート管理など色々使えるように ○ 他クラウドだけでなく、アプリケーションログやEDRのログなども取り込めるようにしている ● 連携はS3を起点に ○ S3にファイルを送ればよいだけなので連携が簡単監視システムの構成 53

Slide 54

Slide 54 text

©MIXI おわりに 54

Slide 55

Slide 55 text

©MIXI いかがでしたでしょうか。思い切って内製のシステムを作ってみましたが、期待以上に監視の効率化が行え、必要なアラートを素早く対応することが出来ました。その結果、重大なインシデントの発生を抑えられており、MIXIの安全に貢献できると感じています。おわりに 55