見出し画像

MicrosoftSentinelでGoogleWorkspaceのログを取得する

tnkt

GoogleDriveのログを長期間保存したいという要件が出てきたので、要件を満たすついでに以前から試してみたかったMicrosoft Sentinel(以下、Sentinel)を触ってみました。

有効化からGoogle Workspace(以下、GWS)のログを取得するところまでやっていきます。



Sentinelを有効化する

手順は下記公式ページを参照して行います。有効化に関してはサービスからSentinelを探して数クリックするだけで難しいところは無いので割愛します。


とりあえずデータコネクタを設定してみる

Sentinelを有効化後、Sentinelのページから設定を行っていきます。手順によるとログを収集するにはデータコネクタを設定する必要があるようなので、「コンテンツハブ」から適当にデータコネクタをインストールしてみることにします。

「Microsoft Entra ID」というわかりやすそうなコンテンツがあったので、試しにいれてみることにしました。「おすすめ」らしいですしね。


Microsoft Entra IDデータコネクタを設定する

インストールすると「データコネクタ」に「Microsoft Entra ID」のデータコネクタが表示されるので、クリックして「コネクタページを開く」をクリックします。


コネクタページが表示されたら、試しにサインインログと監査ログを取得してみることにします。「構成」で「Sign-in Logs」と「監査ログ」にチェックを入れて「変更の適用」をクリックします。


変更を適用して少し待つと、データコネクタが接続状態になってSentinelにデータが入ってきました。


これでとりあえず、Sentinelの有効化からデータの取得までの流れは分かりました。


GWSのログをSentinelで取り込む

ここからが本題。GWSのログをSentinelに取り込むための作業を行っていきます。

GWSに接続するための情報を取得する

公式でGWSへ接続する手順が公開されているので、こちらを参照して進めていきます。

特に難しい手順は無いのですが、

Google Pickel String をフェッチするには、credentials.json が保存されているのと同じフォルダーから python スクリプトを実行します。

上記のPythonスクリプトを叩くところで、Python環境が端末に入ってなかった＆構築が面倒だったのでcredentials.jsonをGoogleDriveにアップしてColaboratoryから叩いて済まそうとしたのですが、ローカル環境で実行しないとGoogle Pickle Stringが確認できませんでした。

仕方なくVSCodeをインストールしてPythonを実行→GWSへのログイン要求が出てくるのでログインして許可します。許可すると、VSCodeのターミナルにGoogle Pickle Stringが表示されるのでメモしておきます。


手順3では、テンプレを使うか手動でやるかの2パターンの手順が案内されています。せっかくテンプレがあるので、Azure Resource Manager (ARM) テンプレートからの作成でやってみます。

ただ、手順内の下記の記述が意味不明で少し時間を取られました。

重要: Workspace データ コネクタをデプロイする前に、ワークスペース ID とワークスペース主キー (以下からコピーできます)、および Workspace GooglePickleString をすぐに使用できるようにしておいてください。

「以下」と書いてありますが、もちろん手順には何も書いてありません。なんのこっちゃと調べたら、下記の「ワークスペース ID とキー」のセクションに説明がありました。

ワークスペース ID とキー
使用するインストール方法に関係なく、エージェントが接続する Log Analytics ワークスペースのワークスペース ID とキーが必要になります。 Azure portal の [Log Analytics ワークスペース] メニューからワークスペースを選択します。 次に、[設定] セクションで、[エージェント] を選択します。


Log AnalyticsのワークスペースIDとキー、ということでした。Sentinelを接続しているLog Analyticsを確認して確認できたので手順を進めます。

手順内にある「Deploy to Azure」のボタンをクリックするとカスタムデプロイという画面が表示されるので、必要な情報を適宜入力していきます。


作成を実行すると、必要なリソースが勝手に作成されていきます。テンプレートなので仕方ないですが、いくらかかるかよくわからないリソースを勝手に作られるのって気持ち悪いですよね・・・。

作成されたリソースを確認する

展開が終わったあとリソースを見てみると、

  • App Service プラン

  • Application Insights

  • ストレージ アカウント

  • Azure Functions

  • アクション グループ

  • スマート検出機能アラートルール

が作られていました。何を作られたかわからないので、中身を見ておきます。

  • App Service プラン

    • プランは「Y1」。これはAzure Functions用の従量課金プランらしい。コスト垂れ流しじゃないのはありがたいが、いくら掛かるかは不明。

  • Application Insights

    • 実行中のアプリケーションを監視するサービスで、Azure Functionsの状態を監視するように組まれている。料金は取り込んだログの量に応じた従量課金。

  • ストレージ アカウント

    • 構成は下記。

      • パフォーマンス：Standard

      • レプリケーション：ローカル冗長ストレージ (LRS)

      • アカウントの種類：StorageV2 (汎用 v2)

      • 既定のアクセス層：Hot

    • 中身を見ると、関数の実行ログとか環境設定ファイルらしきものが入っている。

  • Azure Functions

    • GWSのデータを取得するためのコードが書いてある。コードを書き換えればコントロールはできそう。

  • アクション グループ

  • スマート検出機能アラートルール

    • スマート検出機能アラートルールで検出ルールが設定してあって、そのルールに則ってApplication Insightsが監視している？

    • アラートの送り先にアクショングループを指定してある

    • アクショングループでは、アラートの通知先がロールで指定してある


間違ってるかもしれませんが、こんな感じでした。むやみにリソースを削除したりすると動かなくなったりする可能性があるので、一旦様子を見ることにします。

GWSのログを確認する

リソースを色々調べているうちに30分くらい経っていたのですが、Functionsの実行状況を見てみたら既に何度か関数が実行されていました。

Sentinelに接続されているLog Analyticsのテーブルを見ると、GWSのテーブルも確認できました。


また、データコネクタを確認すると、GWSのデータコネクタが作成されていました。


とりあえず繋がった様子なので、取り込んだデータがちゃんと見れるかを確認します。「コネクタページを開く」>「ログ分析に移動」と遷移するとクエリの実行画面になるので、下記のKQLを叩いてみます

GWorkspace_ReportsAPI_drive_CL
| sort by TimeGenerated desc

すると、ちゃんとデータが確認できました。


しっかり取れていてひとまず安心です。

コストについて

ここで気になるのがコストです。Sentinelには31日間の無料期間があり、無料期間中は10GB/日の取り込み料が無料です。

ただ、Sentinelは結構料金体系が複雑で、ログも実際にログを取り込んでみるまでどの程度の量が流れ込んでくるか分からなかったので、GWSに繋いだ瞬間課金死しないか心配だったのですが、アカウント数200弱のGWSだけなら数日間取り込み続けていても取り込み料は無料枠で収まっていました。

また、今回はテンプレートを利用して展開しましたが、関数をいじりたければ下記URLのZIP(展開された関数の元ファイル)を再編集してAzure Functionsに上げなおせば良さそうです。Azure Functionsは全然詳しくないので、このあたりは要勉強。

【Azure Functionsのコード 】
https://aka.ms/sentinel-GWorkspaceReportsAPI-functionapp

下記は上記コードの一部ですが、恐らくこれでGWSの取得するログの項目を管理しているので、要らないログはコメントアウトしてしまえば取らなくなるのではないかと考えています。

activities = [
            "user_accounts",
            "access_transparency", 
            "admin",
            "calendar",
            "chat",
            "drive",
            "gcp",
            "gplus",
            "groups",
            "groups_enterprise",
            "jamboard", 
            "login", 
            "meet", 
            "mobile", 
            "rules", 
            "saml", 
            "token", 
            "context_aware_access", 
            "chrome", 
            "data_studio"
            ]


ログ取り込みの次は

とりあえず、GWSのログ取り込みまで作業してみました。ここまでの作業でGWSのログを長期保管したいという最初の目的は達成できますが、それだけだとSentinelを利用する意味があまりありません。

脅威検出、分析、ハンティング、アラートが発生した際の自動化などの設定も入れてなんぼなので、まだまだこれからが本番です。と、言いつつSIEMはSentinelが触るのが初めてなので、勉強しながら構築していく形になるのですが。自分もまだまだこれからです。

あと、数週間ほど動かしてみてコストについてもなんとなく見えてきたので、それは別でまとめてみようと思います。

この記事が気に入ったらサポートをしてみませんか？