Log Analytics / Sentinel のログ取り込み時にフィルターをかけるワークスペース変換 DCR の使い方

本記事について

Azure Log Analytics や Microsoft Sentinel にログを送るときに、不要なデータを削減したり、逆に列を追加して取り込み後に利用しやすくしたりしたいケースがあるかと思います。Azure Monitor Agent で取り込むデータについては、Data Collection Rule (DCR) にて簡単に扱えますが、Azure リソースログなどプラットフォーム側で送られるログなどは別の方式でこのフィルタリングを行います。その方式が、本記事でご紹介するワークスペース変換 DCR です。

なお本機能は、2022年11月に（ひっそりと) 一般提供開始のアナウンスがされています。

この記事では、Azure AD サインインログ (SigninLogs) を例に、ワークスペース変換DCRで不要なレコードやカラムを削減したり、逆にユーザー独自のカラムを追加したりする方法を見ていきます。

Azure Log Analytics における変換について

Azure Log Analytics での変換は、大きく分けて以下の3方式があります

• Azure Monitor Agent の DCR による変換

• カスタムログ用のログインジェスト API の DCR による変換

• Log Analytics ワークスペースに直接適用されるワークスペース変換 DCR による変換

本記事では３つめのワークスペース変換 DCR を扱います。それ以外の変換について確認されたい方は下記をご覧ください。

また、変換の構造体について詳細を確認されたい方は下記の公式ドキュメントをご参照ください。

ワークスペース変換 DCR を実際に使ってみる

設定

ここから実際に、ワークスペース変換 DCR を Azure AD サインインログに対して適用していきます。比較のため DCR 無しのワークスペースとワークスペース変換 DCR を適用するワークスペースの２つを用意してみます。あらかじめ両ワークスペースに Azure AD からサインインログが転送されるよう設定しておきます。

ワークスペース変換 DCR の適用はとても簡単です。Log Analytics ワークスペースのテーブルタブで対象にしたいテーブルを選びます。右の・・・をクリックし、「変換の作成」を選択します。

まず基本タブでルールを格納することになるデータ収集ルール (DCR) をひとつ作成します。

次にスキーマと変換では、変換エディターを開きます。クエリは下記のようにしてみます。

source
| where UserDisplayName contains "Yoshiaki"
| extend City_CF = LocationDetails.city
| project-away AlternateSignInName

あとはこのルールを作成して30分ほど待てば、自動的にフィルター処理が開始されます。

補足として、下記でフィルターで利用できる KQL を簡単に解説します。

行を削減する - where 句の利用

テーブルに入ってくるデータで不要な行を削減するには where 句が利用できます。上記の例では、UserDisplayName に "Yoshiaki" という文字列があるときのみログを格納することになります。このように特定の条件にあてはまるレコードのみ残したい場合は、where 句で記述します。

列を追加する - extend 句の利用

列を追加したい時は、extend 句を利用します。上記では、LocationDetails の中に入ってしまっている City の情報を列として追加しています。注意点としては、この列名の最後を _CF としなければならないことがあります。

列を削減する - project-away 句の利用

元々入っている列で、削減したいものは project-away で落とすことができます。上記では、AlternateSignInName 列を削減しています。

結果の確認

DCR の確認

まず、作成された DCR の中身を見て見ましょう。今回、DCRTest2 というワークスペースにのみ DCRTest という名前の DCR をセットしました。

DCR の中身は ARM テンプレートで見ることができます。テンプレートのエクスポートタブを開きます。

重要なのは、下記の部分です。

"dataFlows": [
                    {
                        "streams": [
                            "Microsoft-Table-SigninLogs"
                        ],
                        "destinations": [
                            "dc86c4b58296480f9f424b9ad83189b0"
                        ],
                        "transformKql": "source\n| where UserDisplayName contains \"Yoshiaki\"\n| extend City_CF = LocationDetails.city\n| project-away AlternateSignInName\n\n"
                    }
                ]

"transformKql" というキーに対して、値としてさきほどの KQL クエリが入っていることが分かります。この書き方は他の DCR とも共通です。

クエリによるデータの確認

ワークスペース変換 DCR をセットしていないワークスペースとセットしたワークスペースで、サインインログの中身を比較してみます。下記のように全く同じログを転送しているはずなのにレコード数が違うことが分かります。これは、上記の where 句で特定のレコードしか来ないように設定したことによります。また、DCR により AlternateSignInName 列が削除され、City_CF 列が追加されていることもわかります。

• ワークスペース変換 DCR をセットしていないワークスペース

• ワークスペース変換 DCR をセットしたワークスペース

注意点

こちらのワークスペース変換 DCR はデータの圧縮にも強力な手段となります。ただし、課金体系として50%以上料金を減らすことはできないようになっています。

変換によって受信データが 50% を超えて削減された場合、50% を超えるフィルター処理されたデータ量に対して課金されます。

詳細は下記をご参照ください。

最後に

本記事では、Log Analytics のワークスペース変換 DCR を使って取り込むログデータを加工する過程を見ていきました。本記事の内容が Azure Log Analytics や Sentinel を活用する際の一助となれば幸いです。

＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。