srenext2022-skaru - Speaker Deck

srenext2022-skaru

by MIXI ENGINEERS

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

アジェンダ 1. はじめに 2. セキュリティ監視概要 3. 監視システムの紹介 4. 監視システムの構成 5. 今後の展望 6. おわりに

Slide 4

Slide 4 text

はじめに

Slide 5

Slide 5 text

はじめに本セッションでは株式会社ミクシィセキュリティ室で行っている、AWS / GCP のパブリッククラウドサービスのセキュリティ監視の取り組みについてご紹介できればと思います。前半では監視の全体像のご紹介を、後半では内製の監視システムについてご紹介いたします。

Slide 6

Slide 6 text

セキュリティ監視概要

Slide 7

Slide 7 text

セキュリティ監視概要セキュリティ室による監視体制 ● ターゲットはAWSとGCP ● 設定の不備や侵害の検知がメイン ● 特定の設定を出来なくするなどの強制は行っていない ● 必要に応じて対策の支援も行っている ○ 非エンジニアへの設定の支援 ○ セキュアにアクセスする仕組みの構築支援 ○ などなど

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

セキュリティ監視概要 GCPの監視設定図

Slide 13

Slide 13 text

監視システムの紹介

Slide 14

Slide 14 text

監視システムの紹介監視システムって何？監視の効率化や強化、アラートの管理などを行うためにAWS上に構築した内製のシステムです。平和を司る女神の名前であるIreneという名前がついています。既存のアラート対応での以下の課題を解決しつつ、監視をパワーアップするために構築しました。 ● アラートの通知を自分達で評価できるようにしたい ● アラートの対応状況の管理や対応履歴を残したい ● AWS/GCPのアラートを集約して管理したい ● アラートの調査を自動でやりたい

Slide 15

Slide 15 text

監視システムの紹介それでは実際にどのような機能があり運用を改善しているか、ピックアップしてご紹介いたします。本当は全部紹介したかったのですが時間の関係で無理でした、、、

Slide 16

Slide 16 text

アラートの評価・管理機能 ● アラートを管理するメイン機能です ● アラートに対して5段階の重大度で評価し、重大度毎に設定されたサービスに通知され、管理されるようになっています ○ SlackやGitHub、PagerDutyに通知されます ● アラートを監視システムで受け取り、重大度を定義するルールを設定するだけでアラート対応や管理ができる環境が簡単に構築できます監視システムの紹介

Slide 17

Slide 17 text

ルールによるアラートの重大度の決定 ● AWSやGCPの重大度の定義をベースに独自でルールを作成できるようにしています ● 元の定義より高くなるものもあれば、低くなるものもあります ● 独自で定義することにより多数の似たアラートを抑制してアラート対応の効率化が行えたり、また逆に、優先的に対応したいアラートが他のアラートに埋もれることなく素早く対応出来るようになっています ● デフォルトの重大度が設定できるので、優先して対応したいものや、対応不要なものだけ個別にルールを設定するだけです監視システムの紹介

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

監視システムの紹介アラートのIssue管理 IAMにMFAが設定されてないアラートのIssueが起票されている様子です

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

監視システムの紹介リソースの設定や監査ログのルール ● リソースの設定に危険な設定がないか、監査ログに危険なログがないかなどのルールを作成してアラートの通知が可能です ● アラートと同様に評価ルールを設定して重大度を決定するだけです

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

監視システムの紹介その他機能他にも色々機能が盛りだくさんです！ ● プロジェクト単位でSlack通知を管理する機能 ● アラートやリソースの検索機能 ● アラート確認の催促通知 ● 脅威情報収集機能 ● 設定管理やドキュメント閲覧用のWeb管理画面 ● 効率化のためのバッチやボット ● などなど

Slide 36

Slide 36 text

監視システムの構成

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

監視システムの構成全体構成図

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

今後の展望

Slide 45

Slide 45 text

今後の展望 ● AWS Organizationsの検討 ○ アカウントも増えてきたのでそろそろ欲しくなってきました ● 監視アカウントの拡大 ○ 目指せ全社 ● レスポンスの強化 ○ 今のところ大きな事故もなく平和だが、何か起きたときの対応も強化したい ● AWS/GCP以外での監視システムの導入 ○ せっかく汎用的に作ったので何かに使ってみたい

Slide 46

Slide 46 text

おわりに

Slide 47

Slide 47 text

おわりにいかがでしたでしょうか。思い切って内製のシステムを作ってみましたが、期待以上に監視の効率化が行え、必要なアラートを素早く対応することが出来、結果重大なインシデントの発生を抑えられていると感じています。そして、これらのInsecure なクラウド設定を検出できることが事故や障害を未然に防ぎ、ひいては可用性に責任を持つSRE として寄与すると考えています。また、今回は監視システムの概要の話で終わってしまいましたが、コード実装の工夫の話とか、アラート対応の実運用の話とか、監視の導入周りの話とか、システム運用でのつらみの話とか...他の話もどこかでできればいいなと思っています！

Slide 48

Slide 48 text

We Are Hiring! We Are Hiring! SREの募集一覧  ミクシィ採用  SRE求人3件、サーバーサイド求人10件！  ミクシィグループでは、  SREの皆さんのご応募をお待ちしています  家族アルバムみてね言語：Ruby モンスターストライク言語：Ruby、Go 事業横断の開発本部では、通常の中途採用に加えて第二新卒採用も実施中！言語：Go、Ruby、Elixirなど採用サイト 

Slide 49

Slide 49 text

No content