Google Cloud Next Tokyo ‘24、『Security Command Center と BigQuery を 利用したセキュリティ ガバナンス事例の紹介』のセッションを聞いてきましたので、そのイベントレポートです。

はじめに

Security Command Center は、Google Cloud を利用している方であればだれもが知っていると (個人的に) 考えているセキュリティサービス群です。

セキュリティ機能は、会社のガバナンスと合わさって真価を発揮します。

このセッションで、BigQuery を活用して、組織としてどのように対策するか聞きたいと思います。

セッション内容

株式会社リクルート 宮崎 幸恵 様によるセッションとなります。

リクルートの IT 基盤は、社内 ICT 基盤とプロダクト基盤に分かれているとのことです。

今回ご説明をいただく宮崎様は、プロダクト向けの基盤を管理されているとのことで、オンプレミスとパブリッククラウドのハイブリッド基盤とのことでした。

インフラの範囲としては、ログ、認証などの共通機能の提供と、コスト管理、支払いなどの取りまとめを実施されているとのことでした。

OS などの領域は、各プロダクトでの対応とのことで、今回は対象外となります。

リクルート様では、2020 年に Security Command Center の検証を実施し、2024 年から Security Command Center Enterpriseの検証を行っているとのことでした。

リクルート様では、1,200 程度のプロジェクトが存在しているとのことです。

セキュリティの全体設計としては、各種ログを集約し、分析を行っているとのことです。

セキュリティ運用の面では、クラウド基盤に対してセキュリティリスクを横断的に可視化し、修正運用を行うことがニーズとのことでした。

ログの集約としては、最低限のログを集約して、運用を実施したいとのことです。

Google Cloud では管理アクティビティのログを集約するとともに、データアクティビティでは BigQuery や Google Cloud Storage などのデータを保管するサービスのログ集約を実施しているとのことです。

それ以外では、Firewall Log や Network flow log を集約しているとのことでした。

Google では、Cloud Logging の集約 Sink を用いてログを管理し、データアクセスが出来ないように管理しているとのことでした。

アセット情報の取得と監視では、Cloud Asset Inventory の情報を BigQuery に集約しているとのことです。

BigQuery にデータを集約しているため、確認したい情報を Query で記載し、View を用いて公開しているとのことです。

監視項目としては、ログの取得ができていない環境や、Firewall などの公開不備、Google Cloud Storage や BigQuery のパブリックアクセス、企業以外の ID の付与などをアラートとして定義しているとのことです。

これらのセキュリティ運用は、人力で実施しているとのことでした。

各セキュリティ担当者を通じて、プロジェクト担当者に通知しているとのことで、これらの調整が大変とのことです。

担当者探しや、過去経緯が不明な場合があることや、対応手順の提示などが課題とのことです。

Security Command Center の活用

2020年の導入時は、Asset Inventory によるアセット可視化のようなニーズが強く、また、コスト負荷の増加が懸念だったとのことです。

そのため、2020 年は Security Command Center の導入を断念しましたが、その後、Securiry Command Center Enterprise を導入したとのことでした。

Security Command Center を導入したことで、今後は Security Command Center の運用が課題とのことでした。

まとめ

リクルート様では、情報集約の課題や、関係部署との調整が課題とのことでした。

今後は、グラフィカルな可視化や自動修復に取り組んでいきたいとのことです。