2026年5月21日公開・更新の「Microsoft Defender documentation update: Updating Solution Metadata」で最初に押さえるべき結論は、これはMicrosoft Defender全体のエンドポイント更新ではなく、Microsoft SentinelのSailPoint IdentityNow Connectorに関するSolution Metadataとパッケージ情報の更新だという点です。影響を受けるのは、SailPoint IdentityNowのログをMicrosoft Sentinel、またはMicrosoft Defenderポータル上の統合セキュリティ運用で利用している組織です。
今回の更新では、SailPoint IdentityNow Connectorのソリューションメタデータが更新され、Public Previewとして公開するための準備が行われました。PR上ではバージョンは3.0.1、テスト完了はYesとされ、Azure/Azure-Sentinelリポジトリのmasterブランチへ2026年5月20日にマージされています。(GitHub)
Microsoft Defenderのセキュリティ更新で管理者がまず確認すべきこと
今回の「Updating Solution Metadata」は、Microsoft Defender Antivirusの定義ファイル更新やMicrosoft Defender for Endpointのセンサー更新とは性質が異なります。実務上は、Microsoft SentinelのContent HubにあるSailPoint IdentityNowソリューションの表示情報、サポート情報、パッケージバージョン、データコネクタ説明が更新されたものとして扱うのが適切です。
特に確認すべき対象は、次のいずれかに該当する環境です。
- Microsoft SentinelでSailPoint IdentityNow Connectorを利用している
- Microsoft DefenderポータルにMicrosoft Sentinelワークスペースを接続している
- SailPoint IdentityNowの監査ログや検索イベントをSIEMに取り込んでいる
- Azure Functionsベースの旧コネクタからCCFベースのコネクタへの移行を検討している
- Content Hubのソリューション更新を本番ワークスペースへ展開する運用ルールがある
Microsoft Sentinelのソリューションは、データコネクタ、分析ルール、プレイブック、ワークブックなどをまとめて提供するパッケージです。データコネクタ付きのソリューションを展開すると、関連するセキュリティコンテンツも同じ展開に含まれます。(Microsoft Learn)
今回の変更点
GitHub PR #14297では、SailPoint IdentityNow ConnectorのSolution Metadataが更新され、Public Previewとして公開するためのメタデータ整備が行われています。変更ファイルには、SolutionMetadata.json、Solution_SailpointIdentityNow.json、createUiDefinition.json、mainTemplate.json、3.0.1.zipが含まれます。(GitHub)
| 確認項目 | 今回の内容 | 管理者への意味 |
|---|---|---|
| 対象ソリューション | SailPoint IdentityNow Connector | SailPoint IdentityNowを利用していない環境への直接影響は限定的 |
| 更新理由 | Public Preview公開に向けたメタデータ更新 | プレビュー機能としての扱い、検証、社内承認が必要 |
| バージョン | 3.0.1 | 既存のContent Hubソリューションが旧バージョンの場合は更新確認が必要 |
| テスト状況 | Testing Completed: Yes | ただし本番展開前の自社検証は省略しない |
| 変更範囲 | メタデータ、UI説明、パッケージ、ソリューション定義 | ログ取り込み方式や運用手順の見直しが必要になる可能性あり |
現在のSolutionMetadata.jsonでは、publisherIdがazuresentinel、offerIdがazure-sentinel-solution-sailpointidentitynow、サポート情報はMicrosoft Corporation、サポート階層はMicrosoftとして定義されています。(GitHub)
影響範囲は「SailPoint IdentityNowのログ取り込み」と「Content Hub運用」
今回の更新で最も注意すべき点は、ソリューション説明に2種類のデータコネクタが明示されたことです。SailPoint IdentityNowソリューションには、従来のAzure Functionsベースのコネクタと、Codeless Connector Framework、つまりCCFベースのコネクタが含まれると説明されています。(GitHub)
Azure Functionsベースのコネクタは、Function Appをデプロイし、SailPoint IdentityNow APIからログを取得してMicrosoft Sentinelへ送る構成です。一方、CCFベースのコネクタは、Microsoft Sentinelのコネクタ定義を使って、よりパッケージ化された形でデータ接続を管理する方向の仕組みです。Microsoftのドキュメントでも、CCFコネクタの作成ではデータコネクタの構築、ARMテンプレートの作成、デプロイ、Microsoft Sentinelへの接続という流れが示されています。(Microsoft Learn)
また、Microsoft SentinelではCodeless Connector Platform、略称CCPという名称がCodeless Connector Framework、略称CCFへ変更されています。古い手順書や社内ドキュメントに「CCP」と書かれている場合でも、現在の文脈ではCCFとして読み替える必要があります。(Microsoft Learn)
管理者が確認すべき設定項目
まず、SailPoint IdentityNowソリューションがどのワークスペースに展開されているかを確認してください。Microsoft SentinelをDefenderポータルに接続している場合でも、既存のAzure RBAC権限は引き続きMicrosoft Sentinel機能へのアクセス制御に使われます。ワークスペースやロール変更はAzureポータル側の権限設計にも反映されるため、更新作業者、監査担当者、SOC担当者の権限を事前に確認しておくべきです。(Microsoft Learn)
| 確認対象 | 見るべきポイント | 失敗しやすい点 |
|---|---|---|
| Content Hub | SailPoint IdentityNowソリューションのバージョンが3.0.1か | 更新済みだと思い込んで旧パッケージのまま運用する |
| データコネクタ | Azure Functionsベース、CCFベースのどちらを使っているか | 両方を有効化して同一イベントを重複取り込みする |
| ログテーブル | SailPointIDN_Events_CLなどにデータが入っているか | ソリューション更新後に取り込み確認をしない |
| 分析ルール | 6件の分析ルールテンプレートが展開・有効化されているか | テンプレートはあるがルール作成を忘れる |
| パーサー | 既存のクエリやブックが新しい取り込み方式で動くか | テーブル名や列名の差異を検証しない |
| サポート情報 | サポート先やpublisher表示が社内手順と一致するか | 障害時に古いベンダー連絡先へエスカレーションする |
createUiDefinition.jsonでは、このソリューションにData Connectorsが2件、Parsersが1件、Analytic Rulesが6件、Custom Azure Logic Apps Connectorsが1件含まれることが示されています。更新後は「コネクタだけ更新された」と考えるのではなく、関連する検出ルール、パーサー、プレイブックまで確認してください。(GitHub)
Azure FunctionsベースとCCFベースの使い分け
既存環境でAzure FunctionsベースのSailPoint IdentityNow Connectorを使っている場合、今回の更新をきっかけにCCFベースへの移行を検討する価値があります。ただし、すぐに本番切り替えするのではなく、ログ量、検出ルール、運用コスト、障害時の調査方法を比較してから判断してください。
| 観点 | Azure Functionsベース | CCFベース |
|---|---|---|
| 運用負荷 | Function App、アプリ設定、シークレット、実行ログの管理が必要 | コネクタ定義ベースで管理しやすい |
| 移行しやすさ | 既存運用がある場合は継続しやすい | 新規導入や標準化に向く |
| コスト管理 | Function Appや取り込み量の確認が必要 | 取り込み量に加えてプレビュー仕様の確認が必要 |
| トラブルシュート | Function Appの実行ログを見られる | コネクタ定義、接続状態、Sentinel側の状態確認が中心 |
| 推奨判断 | 既存運用が安定している場合は段階移行 | 新規導入や再設計時に優先検討 |
重要なのは、「新しいコネクタがあるから即移行」ではなく、「どちらの方式で、どのイベントを、どのテーブルへ、どの頻度で取り込むか」を決めることです。両方のコネクタを同時に有効化すると、同一イベントの重複取り込み、分析ルールの二重検知、Log Analyticsコスト増につながる可能性があります。
展開前に実施する検証手順
本番ワークスペースへ更新する前に、可能であれば検証用のMicrosoft Sentinelワークスペースで動作確認してください。特にPublic Previewに向けた更新は、UI上の表示やメタデータが整っていても、自社の運用手順、監査要件、障害対応フローにそのまま適合するとは限りません。
| 手順 | 作業内容 | 合格基準 |
|---|---|---|
| 事前確認 | 既存のSailPoint IdentityNow Connectorの方式とバージョンを確認 | 利用中のコネクタと対象ワークスペースが一覧化されている |
| 検証展開 | 検証ワークスペースで3.0.1を展開 | エラーなくソリューションが展開される |
| データ確認 | SailPoint IdentityNowのイベントが取り込まれるか確認 | 直近データが期待したテーブルに入る |
| 検出確認 | 6件の分析ルールテンプレートを確認 | 必要なルールが作成・有効化できる |
| 重複確認 | 既存コネクタとの同時稼働有無を確認 | 同一イベントの二重取り込みがない |
| 運用確認 | 障害時のサポート先、手順書、担当者を更新 | 社内ドキュメントが最新状態になっている |
ログ取り込みの確認には、次のようなKQLを使えます。環境によってテーブル名や列名が異なる場合があるため、実際のワークスペースに合わせて調整してください。
SailPointIDN_Events_CL
| summarize LastSeen=max(TimeGenerated), EventCount=count()トリガー系のログも利用している場合は、次の確認も行います。
SailPointIDN_Triggers_CL
| summarize LastSeen=max(TimeGenerated), EventCount=count()直近のデータが入っていない場合は、SailPoint側のAPI資格情報、Function Appのアプリ設定、CCFコネクタの接続状態、Log Analyticsワークスペースの権限を順に確認してください。
開発者・パートナーが見るべきメタデータ上の注意点
SailPoint IdentityNowに限らず、Microsoft Sentinel向けソリューションやデータコネクタを開発・保守している場合、今回の更新はメタデータ品質の重要性を示す例として参考になります。
特に注意すべきなのは、SolutionMetadata.json、mainTemplate.json、createUiDefinition.json、パッケージZIPの整合性です。バージョン番号だけを上げても、UI説明、サポート情報、publisher情報、Content Hub表示、データコネクタ定義が一致していなければ、ユーザーは「どのコネクタを使うべきか」「誰に問い合わせるべきか」を判断できません。
PR上でも、ソリューション説明が更新され、Azure FunctionsベースのコネクタとCCFベースのコネクタの両方に触れる形になっています。これにより、利用者は旧方式と新方式の存在をContent Hub上で把握しやすくなります。(GitHub)
開発側で避けたい失敗は、次のようなものです。
SolutionMetadata.jsonではMicrosoftサポートなのに、UI上の説明では別のサポート先に見える- パッケージのバージョンは3.0.1なのに、コネクタ定義やZIPファイルが旧内容のまま
- Public Previewの説明がなく、利用者がGA機能と誤解する
- 旧コネクタと新コネクタの役割が曖昧で、重複展開を誘発する
createUiDefinition.jsonの説明が古く、実際の依存技術とずれている
メタデータ更新は見た目の修正に見えますが、Content Hubでの検索性、管理者の判断、サポート導線、展開ミスの防止に直結します。特にセキュリティ運用では、表示名やサポート階層の揺れがインシデント対応時の遅れにつながるため、軽視すべきではありません。
Public Previewとして扱う場合の運用判断
今回の変更理由は、SailPoint IdentityNowソリューションをPublic Previewとして公開するためのメタデータ更新です。Public Previewは、本番利用を完全に禁止するものではありませんが、正式提供版と同じ前提で無条件に展開するのは避けるべきです。
次の条件を満たす場合は、早めに検証する価値があります。
| 状況 | 推奨対応 |
|---|---|
| SailPoint IdentityNowを新規にSentinel連携する予定がある | CCFベースを優先候補として検証 |
| 既存のFunction App運用が複雑化している | CCFベースへの段階移行を検討 |
| SOCでSailPointの失敗イベントを監視している | 分析ルールとパーサーの動作確認を実施 |
| 本番ワークスペースで安定稼働中 | すぐ切り替えず、検証環境で比較 |
| 監査・規制要件が厳しい | Public Preview利用の社内承認を取得 |
一方で、SailPoint IdentityNowを使っていない組織、またはMicrosoft Sentinelに同ソリューションを入れていない組織では、緊急対応は不要です。ただし、DefenderポータルでSentinel機能を統合管理している場合は、Content Hubの更新管理フローにこの種のソリューション更新を含めておくと、将来の変更に対応しやすくなります。
更新後のチェックリスト
今回のMicrosoft Defender documentation updateを受けて、管理者は次の順番で確認すると効率的です。
| 優先度 | チェック項目 | 目的 |
|---|---|---|
| 高 | SailPoint IdentityNowソリューションの利用有無を確認 | 影響対象か切り分ける |
| 高 | Content Hub上のバージョンを確認 | 3.0.1への更新要否を判断する |
| 高 | どちらのデータコネクタを使うか決める | 重複取り込みを防ぐ |
| 中 | 分析ルール、パーサー、プレイブックを確認 | 検出・自動化の抜けを防ぐ |
| 中 | KQLで直近ログを確認 | 更新後の取り込み停止を早期発見する |
| 中 | 社内手順書のサポート先を更新 | 障害時のエスカレーションミスを防ぐ |
| 低 | 将来のCCF移行計画を作る | Azure Functions依存を整理する |
特に本番環境では、Content Hubの更新を適用しただけで作業完了にしないことが重要です。ログが入る、パーサーが動く、分析ルールが期待どおり発火する、SOCの運用手順が更新されている、という4点まで確認して初めて実運用上の対応完了といえます。
まとめ：まずは利用有無とバージョン確認から始める
今回の「Microsoft Defender documentation update: Updating Solution Metadata」は、SailPoint IdentityNow ConnectorのSolution Metadata更新であり、Microsoft SentinelのContent Hub運用に関わる変更です。対象バージョンは3.0.1で、Public Preview公開に向けてソリューション説明、パッケージ、メタデータが整備されています。(GitHub)
管理者が最初に取るべき行動は、自社のMicrosoft SentinelまたはDefenderポータル統合環境でSailPoint IdentityNowソリューションを使っているかを確認することです。利用している場合は、コネクタ方式、バージョン、ログ取り込み、分析ルール、サポート手順を順に確認してください。利用していない場合でも、Content Hub更新を本番へ展開する前に検証する運用ルールを整えておくと、今後のMicrosoft Defender関連更新に対応しやすくなります。
コメント