本記事はAsiaQuest Advent Calendarの19日目です。
はじめに
はじめまして、アジアクエストでクラウドをメインで開発している中島 嶺(ナカシマ レイ)です。
先日過去分のAzure更新情報を見ていると、以下の機能が目にとまりました。
Public Preview: Azure Log Alerts support for Azure Resource Graph (ARG)
Azureのリソース情報が格納されているAzure Resource Graph(以下ARG)にLog Analyticsからクエリを投げることができるようになったとのことです。クエリが投げれられるということはログアラート機能により、通知ができるようになります。これにより、Azureリソースの構成情報からログアラートが発火でき、できることが大幅に広がったと思われます。
世に出回っている記事にて、ログアラートを設定する方法を解説した記事はありますが、実際に使った所感まで述べた記事は見かけておりません。そのため、本記事ではアラートおよびメール通知を設定し2~3日動かした感想含めて執筆させていただきます。
想定読者
読者としては以下のような方を想定しております。
- Azureの更新内容に興味がある方
- どうやって設定するのか興味がある方
- 実際触った所感を知りたい方
Azure Resource Graphとは
ARGはAzure環境上のリソースに対してKQLクエリで検索できるサービスであり、Azure PortalやAzure PowerShell、Azure CLIなどから利用できます。
先述の通り、ARGにはAzureリソースの構成情報が格納されています。そのため、よく使われているパターンとしてはクエリで取得した情報を整形、グラフ化しダッシュボードやレポートの作成が行われています。 また、タグなどの検索もできますので、ポリシーに準拠していないリソースの発見などセキュリティ・ガバナンスの向上にも用いられています。
ちょっと触ってみるならば、Azure Portalを用いると簡単です。検索バーからResource Graph エクスプローラーを検索することで使用できます。
※Azure Resource Graph エクスプローラーにKustoクエリを入力し、Azureリソース情報を取得する。
設定内容
設定手順
以下に設定手順を示します。
モニターより、左ブレードの"アラート"を選択後、"アラートルール"を押下し作成します。
"スコープ"セクションにてクエリを実行するLog Analytics ワークスペースを選択します。
"条件"セクションでは以下スクショのように設定していきます。検索クエリに関しては時間さえわかればよいので最小限にしています。
arg("").resourcechanges
| extend timestamp = todatetime(properties["changeAttributes"]["timestamp"])
| where timestamp >= ago(5min)
"アクション"セクションに関して、メール通知ができるアクショングループを選択します。
"詳細"セクションでは以下スクショのように設定します。ログアラートでARGへクエリを発行するにはサブスクリプションスコープでの閲覧者権限が必要です。そのため、IdentityにてSystem assigned managed identityを有効にしてください。
"確認及び作成"セクションにて作成を押下して、アラートルールを作成してください。
"アラートルール" - "ID(プレビュー)"にてRBACロールを割り当てます。先述した通り、サブスクリプションスコープでの閲覧者ロールが必要ですので、Azureロールの割り当てより閲覧者ロールを割り当てます。
設定完了です。
動作確認
適当なリソースを変更すると、以下のメールが届きました。
動作確認完了です。
考察
2~3日動かし、以下の点が気になりました。
変更内容を1件ごとに通知することができない
ログアラートの仕様上、指定した時間範囲にリソースの変更があったことを通知するのみで、変更内容ごとに通知することができません。 変更があった事実はもちろん知りたいですが、何件変更があったのか?を知りたいと感じました。単純にログアラートを使用したのみではできないと思われます。そのため、アクショングループを用いた後続の処理もしくは、別途作りこむ必要があると感じます。
メールにて変更内容を把握できない
前述のログアラートの仕様にも関わりますが、通知されたメールを見ても変更内容を把握することはできません。あくまで、変更されたことしかわかりません。
メール本文にAzure Portalへのリンクがあるため、Portalを確認すればよいのはその通りです。ただ、実運用にて予期せぬリソース変更が発生した場合、リソースの特定・以降の対応など迅速に対応したい状況となります。メールからどういった変更があったかを把握できればとは思います。
※Filtered search resultsおよびSearch resultsよりAzure Portalに遷移する。
あとがき
本更新内容を見たときは、結構使えるんじゃないか?と思ったため、設定はもうちょっと精査・模索していきたいです。 ついでに言えば、当初は以下のような使い方ができると想定していました。
- 攻撃者によるリソースロックの更新・削除によりログアラートが発火
- 紐づけたアクショングループにより攻撃者のIDなどがメールによって通知
- Azure Logic Appsなどの後続処理にて変更されたリソースロックを修復
しかし、ARGを触るうちに気づきましたが、resourcechangeテーブルにはリソースロック変更によるログが保管されないようです。思ったような使い方ができなかったため、代替の方法を考えて実現していきたいです。
参考
