Azure の「Normalization and the Advanced Security Information Model（ASIM）」で押さえるべき結論は、Microsoft Sentinel のログを“製品ごとの独自形式”ではなく“共通スキーマ”で扱えるようにする更新だという点です。これにより、Azure Firewall、Key Vault、AWS CloudTrail、各種サードパーティ製品など、複数のログソースに対して同じ検出ルールやハンティングクエリを適用しやすくなります。既存環境ですぐ全設定を変更する必要はありませんが、ASIM パーサーを使っている分析ルール、ハンティングクエリ、ワークブック、カスタムパーサーは棚卸しが必要です。特に、2026年6月の Microsoft Sentinel 更新では ASIM の対応範囲拡大と、Asset Entity、Agent Event という新しいスキーマの追加が重要な確認ポイントです。(Microsoft Learn)
Azure の ASIM 更新でまず確認すべきポイント
ASIM は、Microsoft Sentinel に取り込まれる多様なログを、分析しやすい共通形式に正規化するためのモデルです。Microsoft Learn では、ASIM を「多様なデータソースとユーザーの間に位置するレイヤー」と説明しており、各製品固有のテレメトリを扱いやすいデータへ変換する仕組みとして整理されています。(Microsoft Learn)
今回の確認ポイントは、単に「ASIM という機能がある」という話ではありません。実務では、次の4点を確認する必要があります。
| 確認ポイント | 実務への影響 | 管理者が見るべき場所 |
|---|---|---|
| ASIM パーサーの対応ソース拡大 | 既存の検出ルールが、より多くのログソースに届く可能性がある | Microsoft Sentinel の分析ルール、ハンティングクエリ、関数 |
| Asset Entity スキーマ追加 | ファイル、サイトなどの資産情報を共通形式で相関分析しやすくなる | データ資産管理、DSPM、外部共有監視 |
| Agent Event スキーマ追加 | AI エージェントの実行、ツール利用、トークン使用量などを横断的に分析しやすくなる | AI エージェント基盤、監査ログ、SOC 運用 |
| Defender ポータル移行 | Sentinel の操作場所が Azure ポータルから Defender ポータルへ移る | 運用手順、権限、インシデント対応フロー |
ASIM 自体の更新は「すべてのテナントで即時に設定変更が必要」という種類の変更ではありません。一方で、ASIM を前提にした検出コンテンツやカスタム KQL を使っている組織では、クエリ互換性、パフォーマンス、パーサーの更新状況を確認しないと、検出漏れやクエリエラーにつながる可能性があります。
ASIM は何を解決する仕組みなのか
セキュリティ運用では、同じ「認証失敗」や「ネットワーク接続」でも、ログソースによってテーブル名、列名、値の表現が異なります。たとえば、Windows、Okta、AWS、VPN、Firewall のログを横断してブルートフォース攻撃を検出したい場合、各ログ形式に合わせて個別の KQL を書くと、ルール数が増え、保守も難しくなります。
ASIM は、この問題を「共通スキーマ」と「パーサー」で解決します。Microsoft Sentinel では、ASIM パーサーが KQL のユーザー定義関数として動作し、CommonSecurityLog、Syslog、カスタムログテーブルなどの既存データを正規化スキーマに変換します。クエリを書く側は、元テーブル名ではなく _Im_<schema> 形式の統合パーサーを使うことで、同じスキーマに正規化された複数ソースをまとめて検索できます。(Microsoft Learn)
たとえば DNS ログでは、次のように _Im_Dns を使います。
_Im_Dns(starttime=ago(1d), responsecodename="NXDOMAIN")
| summarize Count=count() by SrcIpAddr, bin(TimeGenerated, 15m)この書き方のポイントは、DnsEvents や CommonSecurityLog のような元テーブルを直接指定していないことです。ASIM の統合パーサーを使うことで、対応する DNS ソースを横断して同じフィールド名で分析できます。Microsoft は、パーサー利用時には starttime などのフィルターパラメーターを使うことで、正規化後に絞り込むのではなく、可能な範囲で正規化前に絞り込み、パフォーマンスを改善できると説明しています。(Microsoft Learn)
2026年6月下旬時点の主な更新ポイント
ASIM パーサーの対応範囲が広がった
2026年6月の Microsoft Sentinel 更新では、ASIM の正規化対象が広がり、Azure サービス、AWS CloudTrail のより広いアクティビティ、サードパーティのファイアウォール、ID、プロキシ製品などへの対応拡大が案内されています。Microsoft Community Hub の Microsoft Sentinel 更新情報では、ASIM により「1つの分析ルールがより多くのソースに届く」ことが強調されています。(TECHCOMMUNITY.MICROSOFT.COM)
管理者にとって重要なのは、対応ソースが増えても自動的にすべての検出が最適化されるわけではない点です。既存の分析ルールが元テーブルを直接参照している場合、ASIM の恩恵を受けにくくなります。逆に、ASIM の統合パーサーを使ったルールであれば、対応パーサーが追加された際に、ルールを書き換えずにカバレッジを広げられる可能性があります。
Asset Entity スキーマが追加された
Asset Entity スキーマは、ファイルやサイトなどの資産情報を共通形式に正規化するためのスキーマです。Microsoft Learn では、Asset Entity スキーマが非 Microsoft データソースの資産を標準化し、所有者、権限、秘密度ラベル、リスク指標などのセキュリティ関連メタデータを扱うためのものとして説明されています。(Microsoft Learn)
実務上は、次のような用途で重要です。
| 活用シーン | 具体例 |
|---|---|
| 過剰共有の検出 | 機密ファイルに外部ユーザーが多数アクセスできる状態を検出する |
| データ分類との連携 | Confidential や Highly Confidential などのラベルをもとに監視対象を絞る |
| 所有者ベースの調査 | 資産所有者ごとにリスクの高いファイルやサイトを集計する |
| DSPM との連携 | Microsoft Purview Data Security Posture Management などのデータセキュリティ運用に活用する |
Asset Entity では、統合パーサーとして _Im_AssetEntity が使われます。カスタムパーサーを作る場合は、vimAssetEntity<vendor><Product> や ASimAssetEntity<vendor><Product> という命名規則を使うことが示されています。(Microsoft Learn)
たとえば、機密度の高いファイル資産を所有者別に確認する場合は、次のような考え方でクエリを組み立てます。
_Im_AssetEntity(starttime=ago(7d), assettype_in="File")
| where AssetSensitivityLabel in ("Confidential", "Highly Confidential")
| summarize Assets=count(), ExternalUsers=sum(ExternalUsersCount) by AssetOwnerId
| order by ExternalUsers descこのようなクエリは、単なるログ検索ではなく「どの所有者のどの資産がリスクを抱えているか」を見るための入口になります。
Agent Event スキーマが追加された
Agent Event スキーマは、AI エージェントの活動やテレメトリを表すための ASIM スキーマです。Microsoft Learn では、AI エージェントのモデル呼び出し、ツール利用、トークン消費、思考プロセス、エージェント間通信などを対象にするスキーマとして説明されています。(Microsoft Learn)
これは、AI エージェントを社内業務に導入している組織にとって重要です。従来のセキュリティログでは、ユーザー、端末、アプリケーション、ネットワーク通信を中心に監視していました。しかし、AI エージェントがツールを呼び出し、別システムにアクセスし、データを生成・要約・転送する運用では、「誰が」「どのエージェントを」「どのツールと組み合わせて」「どれだけ実行したか」を監査できる必要があります。
Agent Event では、統合パーサーとして _Im_AgentEvent を使います。Microsoft Learn では、エージェント名やユーザー名、期間などのフィルターパラメーターを使えることが示されています。(Microsoft Learn)
_Im_AgentEvent(agentname_has_any=dynamic(["M365Planner"]), starttime=ago(1d), endtime=now())
| summarize Events=count(), InputTokens=sum(InputTokensUsed), OutputTokens=sum(OutputTokensUsed)
by ActorUsername, Agent=SrcAgentNameこのクエリは一例ですが、AI エージェントの利用量、異常な利用者、想定外のツール呼び出しを調査する際の出発点になります。
影響範囲：誰が何を確認すべきか
今回の ASIM 更新で特に影響を受けるのは、Microsoft Sentinel を単なるログ保管先ではなく、検出、調査、ハンティング、可視化の基盤として使っている組織です。
| 役割 | 確認すべき内容 |
|---|---|
| SOC アナリスト | ハンティングクエリが ASIM 統合パーサーを使っているか |
| 検出エンジニア | 分析ルール、カスタム関数、コンテンツが元テーブル依存になっていないか |
| Sentinel 管理者 | パーサー更新、カスタムパーサー、Watchlist、Content hub の状態 |
| クラウド管理者 | Azure Firewall、Key Vault、Storage、AWS CloudTrail などのログ取り込み状況 |
| AI 基盤管理者 | AI エージェントの操作ログを Sentinel に取り込めるか |
| データセキュリティ担当 | Asset Entity を使った機密資産、所有者、外部共有の可視化 |
特に注意したいのは、ASIM 対応ソースが増えても、ログを Sentinel に取り込んでいなければ検出対象にはならないことです。ASIM は「取り込まれたログを共通形式で扱う仕組み」であり、データコネクタの有効化、ログ収集設定、権限設定の代わりにはなりません。
設定変更は必要か
ASIM の利用に、単一の「有効化スイッチ」があるわけではありません。Microsoft Learn では、ASIM パーサーは Microsoft Sentinel ワークスペースで組み込みとして利用できる一方、開発や修正が必要な場合はワークスペースにデプロイするパーサーも利用できると説明されています。推奨される基本方針は、通常の ASIM コンテンツ開発では組み込みパーサーを使い、開発・修正・カスタム対応が必要な場合にワークスペース配置パーサーを使うことです。(Microsoft Learn)
実務では、次の判断で進めると安全です。
| 現在の状態 | 推奨対応 |
|---|---|
| Microsoft 標準の ASIM 対応ルールだけを使っている | まずは検出結果と対象ソースを確認する |
| 元テーブル名を直接参照する独自 KQL が多い | ASIM 統合パーサーへ置き換えられる箇所を棚卸しする |
| カスタムログや独自製品ログを取り込んでいる | カスタムパーサーを作成し、統合パーサーに追加できるか検討する |
| 大量ログで ASIM クエリが重い | フィルターパラメーター、集計単位、取り込み時正規化を検討する |
| AI エージェントを業務利用している | Agent Event スキーマで監査できるログがあるか確認する |
| 機密ファイルや外部共有を監視したい | Asset Entity スキーマで資産情報を扱えるか確認する |
カスタムパーサーを追加する場合、組み込みの統合パーサーは直接編集できません。Microsoft Learn では、カスタム統合パーサー、Watchlist、ソース固有パーサーを使って、追加・除外・置き換えを管理する手順が示されています。(Microsoft Learn)
移行期限：ASIM 固有の期限と Sentinel ポータル移行を分けて考える
ASIM の正規化モデルそのものについて、すべての環境に一律で適用される「ASIM への移行期限」が示されているわけではありません。既存の元テーブル参照クエリも、すぐに使えなくなるとは限りません。
ただし、Microsoft Sentinel の操作ポータルについては期限があります。Microsoft Learn では、2027年3月31日以降、Microsoft Sentinel は Azure ポータルでサポートされず、Microsoft Defender ポータルでのみ利用可能になると案内されています。Azure ポータルで Sentinel を運用している組織は、ASIM のクエリやパーサーだけでなく、インシデント対応、ワークブック、ハンティング、権限、運用手順を Defender ポータル前提で確認する必要があります。(Microsoft Learn)
また、Defender ポータルへの移行自体には追加コストはなく、Microsoft Sentinel の利用量に基づく通常の課金が継続されると説明されています。(Microsoft Learn)
クエリとパーサーで失敗しやすいポイント
元テーブルを直接参照していて ASIM の恩恵を受けられない
よくある失敗は、分析ルールやハンティングクエリが SecurityEvent、CommonSecurityLog、Syslog、OfficeActivity などの元テーブルを直接参照しているケースです。これ自体が誤りではありませんが、ASIM 対応ソースが増えても、そのクエリの対象範囲は自動的には広がりません。
新規に作る検出ルールでは、最初に「ASIM 統合パーサーで表現できるか」を確認するのが安全です。認証なら _Im_Authentication、DNS なら _Im_Dns、ネットワークセッションなら _Im_NetworkSession、Web セッションなら _Im_WebSession のように、スキーマ単位で設計します。(Microsoft Learn)
フィルターパラメーターを使わずにクエリが重くなる
ASIM は便利ですが、正規化処理を伴うため、大量データに対して無条件で統合パーサーを実行するとクエリが重くなります。Microsoft Learn では、パーサーに starttime などの名前付きフィルターパラメーターを渡し、最適なパフォーマンスを得ることが推奨されています。(Microsoft Learn)
避けたい例は次のような書き方です。
_Im_Dns
| where TimeGenerated > ago(30d)
| summarize count() by SrcIpAddr改善するなら、最初からパーサーに期間や条件を渡します。
_Im_Dns(starttime=ago(30d))
| summarize count() by SrcIpAddrさらに、特定の応答コード、宛先、ユーザー、ホスト名などで絞れる場合は、スキーマごとのフィルターパラメーターを優先して使います。
すべてのフィールドが必ず入ると考えてしまう
ASIM スキーマには、Mandatory、Recommended、Optional、Conditional、Alias などのフィールド分類があります。Mandatory はパーサーで実装されるべき項目ですが、Recommended や Optional はソースによって存在しないことがあります。Microsoft Learn でも、コンテンツ側はフィールドの可用性を考慮すべきと説明されています。(Microsoft Learn)
そのため、検出ルールでは次のような設計が重要です。
- Optional フィールドだけに依存した検出にしない
isnotempty()で値の有無を確認する- 複数ソースで同じ結果になるかテストする
- Alias は便利だが、再利用コンテンツでは元の正規化フィールドを優先する
特に Alias について、Microsoft Learn では対話的なクエリを助ける用途とし、分析ルールやワークブックなどの再利用コンテンツでは、Alias ではなく元のフィールドを使うことが推奨されています。(Microsoft Learn)
Process Event のパラメーター変更を見落とす
2026年6月の ASIM 関連更新では、ProcessEvent パーサーの破壊的変更に関する注意喚起も示されています。特に _Im_ProcessCreate 周辺のパラメーター名は、古いクエリやカスタムルールに残っていないか確認しておくべきです。Microsoft の ASIM パーサー管理ドキュメントでは、ProcessEvent のカスタム統合パーサー行に targetusername_has や actorusername_has が含まれています。(TECHCOMMUNITY.MICROSOFT.COM)
確認時は、Microsoft Sentinel の分析ルール、ハンティングクエリ、ワークブック、保存済み関数、GitHub 管理の KQL を対象に、次の文字列を検索します。
_Im_ProcessCreate
imProcessCreate
targetusername=
targetusername_has
actorusername_has古いパラメーター名が見つかった場合は、テスト用ワークスペースまたはクエリ画面で結果件数とエラーの有無を確認してから本番ルールに反映します。
取り込み時正規化を検討すべきケース
ASIM には、クエリ時にパーサーで正規化する方法と、取り込み時に正規化して保存する方法があります。クエリ時正規化は元データを変更せず、既存データにも修正が反映されやすいというメリットがあります。一方、大量データではクエリが遅くなる場合があります。Microsoft Learn では、大規模データセットでは取り込み時正規化により、正規化済み形式で保存することでパフォーマンス面の利点があると説明されています。(Microsoft Learn)
取り込み時正規化を検討すべき典型例は、次のような環境です。
| 条件 | 判断 |
|---|---|
| DNS、Firewall、Proxy などのログ量が非常に多い | 取り込み時正規化の候補 |
| 毎日同じ ASIM クエリを分析ルールで実行している | 正規化済みテーブルの利用を検討 |
| 調査よりも定型検出が中心 | 取り込み時正規化と相性がよい |
| パーサーを頻繁に修正する開発段階 | まずはクエリ時正規化が扱いやすい |
| 元ログ形式をそのまま保持したい | クエリ時正規化を優先 |
現在、ASIM の取り込み時正規化先として案内されているネイティブ正規化テーブルには、Audit、Authentication、DHCP、DNS、File、Network Session、Process、Registry、User Management、Web Session などがあります。Asset Entity や Agent Event を使う場合は、対応コネクタ、パーサー、保存先テーブルの最新状況を個別に確認する必要があります。(Microsoft Learn)
管理者向けチェックリスト
ASIM 更新への対応は、機能を眺めるだけでは不十分です。次の順番で確認すると、検出漏れや運用影響を抑えながら進められます。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 1 | Sentinel 内の分析ルール、ハンティングクエリ、関数、ワークブックを棚卸しする | ASIM 使用箇所と元テーブル直接参照箇所を分類できている |
| 2 | _Im_ または im で始まる ASIM パーサー利用箇所を確認する | 利用スキーマ、対象ソース、実行頻度が分かる |
| 3 | 新しく追加・拡張されたパーサーの対象ソースを確認する | 自社の Azure、AWS、サードパーティ製品と照合できている |
| 4 | Asset Entity と Agent Event の利用可否を確認する | 資産ログ、AI エージェントログの取り込み候補が整理できている |
| 5 | クエリ性能を確認する | starttime などのフィルターパラメーターを使っている |
| 6 | カスタムパーサーを確認する | 命名規則、統合パーサーへの追加、Watchlist 設定に問題がない |
| 7 | Defender ポータル移行の影響を確認する | 2027年3月31日以降の運用手順に更新できている |
次に取るべき行動
まずは、Microsoft Sentinel ワークスペース内で ASIM を使っている KQL を棚卸ししてください。次に、元テーブルを直接参照している検出ルールのうち、認証、DNS、ネットワーク、プロセス、Web、ファイル、資産、AI エージェントのように ASIM スキーマで表現できるものを洗い出します。
優先順位は、ログ量が多いもの、インシデント対応で頻繁に使うもの、複数ソースを横断して検出したいものからです。特に Azure Firewall、Key Vault、AWS CloudTrail、サードパーティのファイアウォールや ID 製品、AI エージェント基盤を使っている組織では、ASIM パーサーの対応状況を確認する価値があります。
ASIM は、単なるログ変換ではなく、検出ルールを「製品依存」から「スキーマ依存」へ移すための設計です。今回の更新を機に、Microsoft Sentinel の KQL、パーサー、データコネクタ、Defender ポータル移行計画をまとめて見直すことで、SOC 運用の保守性と検出範囲を大きく改善できます。
コメント