本記事について
2022年2月に Azure Monitor / Azure Log Analytics の大型アップデートとして、Basic Logs と Archived Logs のプレビューリリースが発表されました。特によりコスト効率良く Log Analytics を活用したい方には強力なオプションになります。本記事では、その利用方法や今後の想定活用シナリオを見ていきたいと思います。
Basic Logs とは？
今まで、Azure Log Analytics に格納されたログは、どのテーブルも基本的に同じストレージ領域に保存されていました。今後、それらのログは、Analytics Logs と呼ばれ、Log Analytics のフル機能を利用できるティアとなります。一方、Analytics Logs のほかに新たに、Basic Logs という新しいティアが追加されました。こちらは、デフォルトの保持期間が8日間、サポートされるクエリ文が限定、アラート発行に利用できない、などの制限あるティアになります。
クエリでサポートされるオペレーターは現時点では下記のみになります。
- where
- extend
- project – including all its variants (project-away, project-rename, etc.)
- parse and parse-where
ですので、基本的には Microsoft Sentinel の Analytics や Hunting でも使えない形となります。下記の表に、Analytics Logs と Basic Logs の違いを簡単にまとめています。
制限がある分、利用料金はかなり安く設定されています。（下記は2022年2月時点での情報です。必ず公式サイトで最新の情報をご確認ください。）
Analytics Logs のインジェスト料金
Basic Logs のインジェスト料金
Basic Logs の使い方
ログを Analytics Logs として格納するか、Basic Logs として登録するかは、Log Analytics のテーブル単位で設定します。2022年2月時点では、Rest API でテーブルごとに指定してあげる必要があります。（デフォルトは Analytics Logs になっています。）
2022年2月現在、まだ対応ログがまだかなり少ないです。最新の対応ログテーブルについては、こちらをご参照ください。
なお、Azure Rest API を使うには、例えば Service Principal を作成し、その Service Principal に共同作成者権限などを与えるなどの準備が必要になります。
その Service Principal に対して、Bearer Token を取得するには以下の HTTP リクエストを実行します。
POST https://login.microsoftonline.com/<テナントID>/oauth2/token
Body は、x-www-form-urlencoded 形式で、下記の値を Key と Value に入れます。
Key: Value
grant_type: client_credentials
client_id: <Service Principal の Application Id>
client_secret: <Service Principal の Secret>
resource: https://management.azure.com/
たとえば、Postman を利用する場合は、このような形でアクセストークンが取れます。
そして、テーブルごとに Basic Logs に変更する PATCH リクエストを投げます。
PATCH https://management.azure.com/subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<workspaceName>/tables/<tableName>?api-version=2021-12-01-preview
Authorization は Bearer Token にして、さきほど取得したアクセストークンを入れます。一方、Body は JSON 形式で、下記のように入れます。
{
"properties": {
"plan": "Basic"
}
}
Postman で実行してみるとこんな感じです。（ContainerLog テーブルに対して変更をかけています。）
また、Azure Portal から Basic Logs にテーブルが変わっていることも確認できます。
Basic Logs の活用方法
Basic Logs はすぐにクエリを書けられる状態が8日間のみになっていたり、アラートの作成が出来なかったりするので、それが許容できるログのみで使うことになるかと思います。今後 Basic Logs のテーブルがサポート対応していけば、ストレージのアクセスやネットワークフローログなどが利用候補に挙がってくるかもしれません。
Archived Logs とは？
Basic Logs に並んで、新しい機能として入ってきたのが Archived Logs 機能です。こちらは名前の通りログを通常の領域から移し、長期保管していくためのオプションになります。
Analytics Logs は 30-730日、Basic Logs は 8日しか通常の領域にはログを保持できません。それを最大7年間保管しておきたい場合に、Archived Logs 機能が利用できます。各ログの関係図は下記になります。
Archived Logs の使い方
Archived Logs の有効化
Archived Logs の有効化も Basic Logs と同じく、テーブル単位で Rest API を使います。
PATCH https://management.azure.com/subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<workspaceName>/tables/<tableName>?api-version=2021-12-01-preview
Authorization は Bearer Token, Body には同じく JSON 形式で項目を入れます。
{
"properties": {
"retentionInDays": <通常の領域に入れておきたい日数, null も可能で null の場合はデフォルト設定>,
"totalRetentionInDays": <通常の領域＋Archive領域で保持しておきたい日数>
}
}
Postman で試しに投げてみるとこのような形になります。
この例では、Basic Logs に設定された ContainerLog に対してリクエストを投げており、Basic Logs には 8日間、その後 Archived Logs に 357日間、計365日間保存するという内容になっています。
Archived Logs の検索
Archived Logs のログを検索するには、通常の検索ではなく、Search job または Restore を行う必要があります。上記のログの関係図の矢印に書かれている機能群になります。
Search job
Search job はもともと、通常のクエリが 10 分でタイムアウトしてしまう問題を解決するための仕組みです。ですので、Archived Logs だけでなく、通常の Analytics Logs や Basic Logs にも横断的にお使いいただける機能です。
使い方としては、GUI または Rest API で、大規模なデータに対して簡単なフィルター条件をセットし、結果として取得したレコードを通常の検索が可能なテーブルに入れていきます。
Microsoft Sentinel を有効化している場合、Portal Sentinel のページの GUI は下記のようになっていて、テーブル名や時間の範囲、含まれる単語などを入れ、Search job をキックできます。
search をクリックすると job が流れ、_SRCH と Suffix が付いたテーブルが新規作成され、引っ張ってこられたデータが格納されます。そのテーブルに対して検索をかけることができます。
また、Rest API で行う方法については、公式ドキュメントをご確認ください。
Search job には実行回数やジョブの対象にできるログの量に制限があるので、利用前に公式ドキュメントで要件に合致するか確認しておくことが必要です。
Restore
一方、Restore は名前の通り、Archived Logs を通常のログ領域に戻すための機能です。こちらも Portal の GUI と Rest API の利用が可能です。
Microsoft Sentinel を有効化している場合、Portal の Sentinel の検索ページではテーブル名や時間の範囲を指定し、データを復元することができます。_RST と Suffix が付いたテーブルに格納され、検索をかけることができます。
また、Rest API で行う方法については、公式ドキュメントをご覧ください。
Restore も実行回数やジョブの対象にできるログの量に制限があるので、利用前に公式ドキュメントをご確認下さい。
Archived Logs の活用方法
Archived Logs にログを移すのは、2年以上ログを保持する必要があり、かつ Blob Storage に JSON/CSV などで保持するのではなく、いざというときに Log Analytics 上で検索や分析ができることが要件になる場合でしょう。たとえば Compliance 要件で 5年間アクセスログを保持する必要があり、かつセキュリティインシデント時は自分でそのログを分析しないといけない、といったシーンでは、Archived Logs が活用できるかと思います。ただし、Search job も Restore も一回のジョブで扱える量やジョブの回数に制限があるので、いざというときに対応する際に問題が無い制限か、あらかじめ確認して置く必要があります。
最後に
本記事では、Log Analytics の新しい機能である、Basic Logs や Archived Logs の使い方を Rest API や Azure Portal を使ってみてきました。今後よりコスト効率よく Log Analytics を利用するために重要な機能となってくるかと思いますので、プレビューリリース中にもぜひご体験いただければと思います。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。