[レポート]MIXI TECH CONFERENCE 2023 D1-10「パブリッククラウドのセキュリティ監視」 #mixitechcon

こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。

みなさん、株式会社 MIXIさんが下記日程でTechカンファレンスを開催されているのはご存知でしょうか。

• 2023年03月01日（水）13:00〜18:45
• 2023年03月02日（木）13:00〜17:50
• 2023年03月03日（金）13:00〜17:50

connpassはこちら↓ （本記事のセッション含め、各セッションの登壇資料がアップロードされています。）

公式サイトはこちら↓

本記事はそんなカンファレンス内のセキュリティ系セッション「パブリッククラウドのセキュリティ監視」のレポートです。

セッション概要

MIXI TECH CONFERENCE 2023 - 3/1(水) 18:10 〜 18:35 パブリッククラウドのセキュリティ監視

パブリッククラウドのセキュリティ監視

MIXI では多数のパブリッククラウドを運用しており、日々増え続けています。
これらのサービスでは一つの設定ミスで深刻なセキュリティ事故が起きてしまうため、セキュリティ監視は必要不可欠です。
本セッションでは我々がどのようにセキュリティ監視を運用しているか、またどのように効率化しているかについてご紹介します。

登壇者

軽部 正太 / Shota Karube
開発本部 セキュリティ室
2018年に株式会社ミクシィ(現 株式会社MIXI)に入社。セキュリティ室とSREGを兼務しており、セキュリティ対策の支援や、バックエンド開発の支援を行っている。

レポート3行まとめ

• MIXIの開発本部 セキュリティ室でIaaS環境監視の効率化を図るために「Irene（イレーネ）」という監視システムを構築した
• IreneはAWSやGCPだけでなく汎用的にサービスのアラートを集め可視化可能で、監視だけでなく調査も自動化出来ている
• 期待以上に監視の効率化が行えていて、重大なインシデントの発生を抑えられている

レポート

セッションの構成は下記でした。

• セキュリティ室の紹介
• セキュリティ監視概要
• 監視システムの紹介
• 監視システムの構成

それぞれのパートに分けて内容をまとめていきます。

セキュリティ室の紹介

まずは軽部さんが所属する開発本部セキュリティ室の紹介。

セキュリティ室は、自社サービスや社内システムに対するセキュリティ支援、社内に対する研修や啓蒙周知などを行なっている部署です。

株式会社MIXIでは自社サービスのインフラ基盤としてAWSやGCPを採用しており、その環境を監視することもセキュリティ室の業務の一つです。

セキュリティ監視概要

そんなIaaSセキュリティ監視の概要は次の通り

• 対象の環境はAWSとGCP
• 設定の不備や侵害の検知がメイン
• 「特定の設定を出来なくする」などの強制は行わない方針
• 監視以外の施策に繋げることもある
  • ゼロトラスト支援
  • mixirt(CSIRT)

上述の通り、対象の環境はAWSとGCPの2つのIaaSが使われています。

監視対象のアカウントの規模は、AWSが約50アカウント、GCPが4組織/100プロジェクト以上とのこと。

AWSの監視

AWSの監視にはAWS CloudTrailやAmazon GuardDuty、OSSの設定監視ツールが使われています。

下図が構成図ですが、監視対象のアカウントのログ等を監視アカウントにまとめていますね。

監視設定の導入については、開発本部経由で作成されたアカウントについてはアカウント作成時点で必要なセキュリティ設定を行なっているとのこと。それ以外のアカウントについては個別導入らしいですが、IaCテンプレートが用意されていたり設定作業の支援も行われているようです。

弊社のセキュアアカウントに近いことをやられているのかな、と思いました。

[安全なAWSセキュリティ運用ナレッジ2022]セキュアアカウントの使い方 | DevelopersIO

GCPの監視

GCPの監視にはBigQueryなどのGCPサービスを複数組み合わせた内製のリソース収集ツールやSecurity Command Centerが使われているそうです。

Security Command CenterってAWSで言うところのAmazon GuardDutyやAWS Config Rulesのような機能を持っているんですね。

構成図は下図。収集したログ等はS3にまとめられるようです。S3にまとめられている理由や背景が気になりますね。

こちらの導入もMIXIのOrganizationを使っている場合は最初から監視対象、それ以外の場合は個別に導入対応を行なっているようです。

監視システムの紹介

ここからは監視システムのお話です。

上述した監視の効率化や強化、アラートの管理などを行うためにAWS上に内製システムを思い切って構築してみたとのこと。

その名も「Irene」（読み方はイレーネ（確か））

平和を司るギリシャ神話の女神から名付けられたようです。最高に格好良い。

Ireneは下記のような運用課題を解決するために作られました。

• アラートはSlackに通知しているだけ
  • 監視対象の規模が大きいため、アラートが大量で管理が辛い
  • 過去の似たような対応を探すのが辛い
• アラートの通知やフィルタなどの処理がサービスごとにばらけている
• アラートの調査で時間がかかるので自動化したい

上記を解決するため、あくまでも一部の機能ですがIreneには下記のような機能が備わっています。

• アラート管理/通知
• アラート調査機能
• アラート効率化のためのBot/Batch
• 管理画面(GUI)の導入
  • 通知設定管理
  • アラート調査
  • 各種ドキュメント

これらを部分的にご紹介します。

アラート管理/通知

AWSとGCPのアラートを効率的に管理するためのIreneのメイン機能です。

AWSやGCPからアラートをIreneに通知することで、GitHubやPagerDuty、Slackでアラートの管理が出来るらしいです。

しかも各アラートは5段階の重大度（緊急、高、中、低、対応不要）からなる評価ルールを設定可能のようです。

評価ルールはアラート内容に応じて独自に定義したルールを設定可能とのこと。例えばGuardDutyで重要度が高く付けられているものであっても、実際にはそこまで重要視しなくて良いものについては低く付けているとのこと。逆も然り。

この独自定義可能なルールのおかげで、多数の似たアラートを抑制し対応の効率化を図れたり、逆に優先的に対応したいアラートが他のアラートに埋もれることを防げているとのことです。

もちろん、元のアラートの重大度をそのまま使うことも可能のようです。

上述した5段階の重大度ですが、基本的に普段は中以上のアラートを確認しているようで、中以上はGitHubのIssueとして自動起票されます。また、緊急や高のものは優先して対応出来るようにPagerDutyと連携されるようになっています。低はSlackへの通知のみ程度の対応。

GitHubのIssueは対応（設定変更、リソース削除）すると自動的にクローズされ、再度アラートが発生するとオープンする仕組みになっているようです。一つのIssueで管理されるため、過去の対応情報等も一目で分かって状況把握がしやすいとのこと。

ちなみに評価ルールはサービスのアラートとは別に、危険なリソース設定や監査ログなどに対しても設定可能みたいです。

アラート調査機能

なんとIreneにはアラートの管理機能だけでなく調査機能まであります。

調査はアラートをトリガーとして、もしくは定期的にバッチ実行で行われるようです。下記は調査の例。

• SecurityGroupの公開設定に関するアラートの場合
  • インスタンスやIPを一覧化してチェック
    • TCPでコネクションの試行
    • HTTP接続可能なサービスについては画面キャプチャを取得
      • Webページの改ざんを検知
• IPやドメインが危険なものでないか調査
  • 監査ログのコール元がTorなどの不審なものでないか
  • 侵害検知アラートの場合、Actorにどういった脅威があるか
• など

下図は画面キャプチャ機能（HTTP接続可能なサービスに対する調査）のイメージです。一目で分かるようになっていてめちゃくちゃ良い機能だなと私は思いました。

この調査結果はアラートと同一のIssueに自動でコメントされるため、アラート対応に必要な情報は全てIssueに揃うようになっています。

管理画面(GUI)の導入

なんとIreneには管理画面も存在します。

現在はAWSのアラートにのみ対応とのことですが、今後はGoogle Cloudにも対応していきたいとのこと。

また、現在は下図のように簡単なログやアラート情報の表示だけなので、侵害対象がインスタンスの場合であれば対象インスタンスの中の調査も行われるような機能追加をされていくそうです。

監視システムの構成

解像度が低くて申し訳ないですが、そんなIreneの構成図がこちら。

構成は下記の通り。

• インフラ
  • AWS(Lambda / DynamoDB / S3 / SQS など)
  • リソースはCloudFormationで管理
  • Production環境とStaging環境の2つの環境が存在
• アプリケーション
  • 全てLambdaで動かしている（管理画面も）
  • 言語はGoと一部にPython
  • 管理画面のフロントでJS(TS / Next.js)
• CICD環境
  • GitHub Actions
  • AWS CodePipeline
  • AWS CodeBuild

上記構成には以下のような設計のコンセプトがあります。

• なるべく低コストで運用
  • 設計〜運用が一人だったのでなるべく負荷を下げたかった
• アラートは見逃さないように
  • バグやエラーなどで必要なアラートが無くならないように
• 汎用的にする
  • AWSとGCP特有の処理をなるべく無くす
  • AWSとGCP以外でも使えるように
  • 簡単にシステムに乗せられるように

この記事を書いてる時に気付いたんですが、軽部さん一人でこのシステム作られたんですかね。。？凄すぎる。。。

上記のような設計のコンセプトがあるため、管理画面のバックエンドもLambdaだったり、連携の起点をS3にしたりしているようです。

特に汎用的にするってコンセプトは良いですね。クラウドだけでなくアプリケーションやEDRのログなども取り込めるようにしているとのことで拡張性が高く最高です。

まとめ

いかがだったでしょうか。

個人的にタイトルから非常に気になるセッションだったので聴講したのですが、非常に刺激を貰える内容でした。

発見的統制に関する知見も得られましたが、それ以上にシステムの設計思想のようなところで非常に見応えのあるセッションだったと思います。

色んな人に元の資料を見てもらいたいので、是非このセッションの登壇資料を公開して欲しいです。（公開されていたら参照可能なURLを本記事に追記させていただきます。）

似たような取り組みをされている/してみたい方は本セッションの内容を参考にされてはいかがでしょうか。

以上、べこみんでした。