MENU

.NETのMicrosoftSecurityProductName Struct更新ポイント｜SecurityInsights SDKで確認すべき影響範囲と移行対応

Azure

.NETアプリからMicrosoft SentinelなどのSecurity Insightsリソースを操作している場合、今回確認すべきポイントは「.NETランタイムの更新」ではなく、Azure.ResourceManager.SecurityInsights のモデル定義とパッケージ参照です。MicrosoftSecurityProductName Struct は、アラートの productName を表すSDK上の値型であり、管理ポータルの設定を直接変更する機能ではありません。したがって、まず見るべきなのは、利用中のNuGetパッケージのバージョン、ProductFilter の使い方、文字列で製品名を扱っている箇所、そしてプレビュー版を本番に取り込んでいないかの4点です。

2026年7月2日に公開または更新された公式情報を前提に整理すると、MicrosoftSecurityProductName Struct (Azure.ResourceManager.SecurityInsights.Models) - Azure for .NET Developers は、セキュリティ運用の挙動を突然変える変更というより、.NET開発者・運用管理者が「SDKの型定義を正しく理解し、依存パッケージを安全に管理するための確認項目」として読むべき内容です。Microsoft LearnのAPIリファレンスでは、名前空間、アセンブリ、対象パッケージ、プレビュー情報に関する注意が示されています。(Microsoft Learn)

目次

.NETのMicrosoftSecurityProductName Structでまず押さえるべき結論

MicrosoftSecurityProductName は、Azure.ResourceManager.SecurityInsights.Models 名前空間にある readonly struct です。公式リファレンスでは、Azure.ResourceManager.SecurityInsights.dll に含まれ、Azure.ResourceManager.SecurityInsights v1.1.0 と v1.2.0-beta.4 が対象パッケージとして示されています。説明文では「cases will be generated」と表現されており、アラートの productName を基準にケース、つまりインシデント生成系のフィルターで使われる値型と理解すると実務上分かりやすいです。(Microsoft Learn)

重要なのは、このページだけを見て「Azure側の設定変更が必要」「移行期限が発生した」と判断しないことです。APIリファレンスはSDKの型定義を説明するページであり、Microsoft Learn上にも、この構造体単体に紐づく強制移行日やポータル設定変更は示されていません。一方で、対象パッケージにプレビュー版が含まれているため、本番環境ではパッケージ更新ポリシーとCI/CDの復元設定を確認する必要があります。

MicrosoftSecurityProductName Structとは何か

MicrosoftSecurityProductName は、Security Insightsのアラートルールやテンプレートで、どのMicrosoftセキュリティ製品のアラートを対象にするかを表すための型です。公式リファレンスでは、IEquatable<MicrosoftSecurityProductName> を実装する値型として定義されています。(Microsoft Learn)

この構造体は、単なる列挙型ではありません。文字列を受け取るコンストラクターを持ち、string から MicrosoftSecurityProductName への暗黙変換も用意されています。つまり、SDKが用意している定義済みプロパティを使うことも、必要に応じて文字列から値を作ることもできます。コンストラクターでは value が null の場合に ArgumentNullException が発生するため、設定ファイルや環境変数から値を読み込む実装ではnullチェックが必要です。(Microsoft Learn)

たとえば、MicrosoftSecurityIncidentCreationAlertRuleTemplate.ProductFilter プロパティは、MicrosoftSecurityProductName? 型として定義されています。このことから、MicrosoftSecurityProductName は単体で完結する便利型ではなく、インシデント生成系のアラートルールテンプレートと組み合わせて使う値だと分かります。(Microsoft Learn)

更新ポイントを実務目線で整理

今回の確認ポイントは、機能追加の派手さよりも「安定版とプレビュー版を混同しないこと」にあります。公式リファレンスには安定版の v1.1.0 とプレビュー版の v1.2.0-beta.4 が併記され、プレビュー製品は正式リリース前に変更される可能性があるという注意書きもあります。(Microsoft Learn)

確認項目実務上の見方管理者・開発者の判断
対象パッケージAzure.ResourceManager.SecurityInsights v1.1.0 と v1.2.0-beta.4 が表示される本番は原則として安定版を基準にし、プレビュー版は検証環境で扱う
影響範囲.NETアプリ、IaC補助ツール、運用自動化、CI/CDの依存関係Azureポータル設定ではなく、コードとパッケージ管理を確認する
変更の性質Security Insightsモデルの型定義・定義済み値・変換処理の確認「サービス仕様変更」と「SDK参照更新」を切り分ける
移行期限この構造体単体の強制移行期限は公式ページ上では確認できない期限対応ではなく、依存パッケージ棚卸しとして扱う
注意点プレビュー版は将来変更される可能性があるDirectory.Packages.props やロックファイルでバージョンを固定する

NuGetのパッケージページでは、Azure.ResourceManager.SecurityInsights がSecurity Insightsリソースを管理する.NET向けライブラリであり、インストール方法として dotnet add package Azure.ResourceManager.SecurityInsights が示されています。また、バージョン一覧には 1.2.0-beta.4 と 1.1.0 が並んでおり、プレビュー版を意図せず取得していないか確認する材料になります。([NuGet][4])

v1.1.0とv1.2.0-beta.4で見ておきたい違い

ソースを見ると、安定版側の MicrosoftSecurityProductName には、Microsoft Cloud App Security、Azure Security Center、Azure Advanced Threat Protection、Azure Active Directory Identity Protection、Azure Security Center for IoT などの定数が含まれています。(GitHub)

一方、プレビュー版側のソースでは、上記に加えて Office 365 Advanced Threat Protection と Microsoft Defender Advanced Threat Protection の定義済み値が確認できます。公式リファレンスのプロパティ一覧にも、これらの値が表示されています。(GitHub)

この差は、実務では「サンプルコードをコピーしたらビルドが通らない」という形で表面化しやすいです。たとえば、プレビュー版で追加されている定義済みプロパティを、安定版 v1.1.0 のプロジェクトでそのまま使うと、プロパティが見つからずコンパイルエラーになる可能性があります。対策は、利用中のパッケージで定義済みプロパティが存在するか確認し、必要に応じて文字列コンストラクターを使うことです。

using Azure.ResourceManager.SecurityInsights.Models;

// 安定版でも扱いやすい、定義済みプロパティを使う例
MicrosoftSecurityProductName productName =
    MicrosoftSecurityProductName.AzureSecurityCenter;

// 定義済みプロパティがパッケージにない場合は、文字列から生成できる
var defenderProductName =
    new MicrosoftSecurityProductName("Microsoft Defender Advanced Threat Protection");

ただし、文字列から生成できるからといって、自由な値を入れてよいわけではありません。Security Insights側のテンプレートやルールが受け付ける値と一致している必要があります。特に製品名はブランド変更や旧称が絡みやすいため、コードレビューでは「文字列が合っているか」だけでなく、「対象のアラートルールテンプレートでその値がサポートされているか」を確認してください。

ProductFilterを使うコードで確認すべきポイント

MicrosoftSecurityProductName は、主に ProductFilter のようなプロパティで使われます。ProductFilter は、アラートの productName を基準に、どの製品のアラートからケースを生成するかを指定する役割を持ちます。(Microsoft Learn)

実装時は、次の観点で見直すと安全です。

確認する箇所よくある失敗推奨対応
.csprojパッケージバージョンを未固定にしているVersion を明示し、プレビュー版を本番に入れない
Directory.Packages.props複数プロジェクトで異なるバージョンを参照しているソリューション単位でバージョンを統一する
ProductFilter 設定文字列を直接書き散らしている定義済みプロパティまたは共通定数にまとめる
CI/CD--prerelease 相当の設定で意図せずベータを取得する復元ログとロックファイルを確認する
テストコンパイルだけで確認を終えている実際のSecurity Insightsワークスペースでルール取得・更新を検証する

特にグローバル展開している組織では、開発チームごとにSDKのバージョンがずれていることがあります。米国チームはプレビュー版で検証し、日本や欧州の運用チームは安定版のまま、という状態になると、同じサンプルコードでもビルド結果が変わります。共通ライブラリや内部テンプレートで Azure.ResourceManager.SecurityInsights のバージョンを固定し、利用可能な MicrosoftSecurityProductName の値を一覧化しておくと、運用時の混乱を減らせます。

equalityとGetHashCodeの扱いにも注意する

MicrosoftSecurityProductName は値の比較演算子を持ち、Equals では大文字・小文字を区別しない比較が行われます。プレビュー版のソースでは、Equals が StringComparison.InvariantCultureIgnoreCase を使い、GetHashCode も StringComparer.InvariantCultureIgnoreCase に基づいています。(GitHub)

この挙動を前提にすると、"Azure Security Center" と "azure security center" のような大小文字違いは同一扱いになり得ます。ただし、実務では構造体そのものを辞書キーとして広く使うより、ToString() で値を取り出し、StringComparer.InvariantCultureIgnoreCase を指定した Dictionary<string, TValue> に寄せるほうがトラブルを追いやすくなります。ToString() は内部値を返す実装になっているため、ログ出力や正規化キーの作成にも使いやすいです。(GitHub)

var product = new MicrosoftSecurityProductName("Azure Security Center");

var rulesByProduct = new Dictionary<string, string>(
    StringComparer.InvariantCultureIgnoreCase);

rulesByProduct[product.ToString()] = "Incident creation rule";

このようにしておくと、設定ファイル、環境変数、管理画面入力など、複数経路から製品名が渡される場合でも、大文字・小文字の違いによる重複登録を避けやすくなります。

設定変更は必要か

この MicrosoftSecurityProductName Struct の更新情報だけを理由に、AzureポータルやMicrosoft Sentinelの設定を一律変更する必要はありません。確認すべき対象は、主に.NETコード、NuGet依存関係、CI/CD、内部ドキュメントです。

ただし、次の条件に当てはまる場合は、変更作業が必要になる可能性があります。

条件必要になる作業
旧SDKから移行していないAzure.ResourceManager.SecurityInsights への移行計画を立てる
プレビュー版のプロパティを使いたい本番適用前に検証環境で互換性テストを行う
文字列で製品名をハードコードしている定義済みプロパティまたは共通定数に置き換える
複数地域・複数チームで同じ自動化を使うSDKバージョンとサポート値の一覧を共通化する
CIで自動更新を有効にしているプレビュー版を拾わない制御を追加する

特に、Microsoft.Azure.Management.SecurityInsights をまだ使っている環境は注意が必要です。NuGetではこの旧パッケージがレガシーで保守されていないものとして扱われ、代替として Azure.ResourceManager.SecurityInsights へのアップグレードが推奨されています。旧パッケージについては、2023年9月30日時点でobsoleteとされ、以後の更新を受けるには置き換えパッケージへの移行が案内されています。([NuGet][7])

移行期限はあるか

MicrosoftSecurityProductName Struct そのものについて、2026年7月2日の公式リファレンスから読み取れる強制移行期限はありません。したがって、「いつまでにこのStructへ移行しなければならない」という種類の対応ではなく、「Security Insights管理ライブラリを使う.NETコードが、現在の公式SDKに沿っているか」を確認する作業と捉えるのが適切です。

一方で、旧世代の Microsoft.Azure.Management.SecurityInsights を使っている場合は話が別です。これはすでに保守対象外として案内されているため、移行期限の有無に関係なく、次の開発サイクルで Azure.ResourceManager.SecurityInsights への置き換えを進めるべきです。旧SDKのままでは、新しいモデル定義、依存関係更新、Azure SDK for .NETの標準的な認証・HTTPパイプライン・テレメトリ改善を取り込みにくくなります。Azure.ResourceManager.SecurityInsights は、Azure SDKのガイドラインに沿ったライブラリとして、MSAL.NET、Azure.Identity、OpenTelemetry、HTTPパイプラインなどの機能を備えると説明されています。([NuGet][4])

管理者が今すぐ確認すべきチェックリスト

まず、リポジトリ全体で Azure.ResourceManager.SecurityInsights の参照状況を確認します。Visual Studioだけでなく、GitHub Actions、Azure DevOps、JenkinsなどのCI環境でも同じバージョンが復元されているかを見てください。

dotnet list package --include-transitive

次に、次のキーワードでコード検索します。

MicrosoftSecurityProductName
ProductFilter
MicrosoftSecurityIncidentCreation
Azure.ResourceManager.SecurityInsights
Microsoft.Azure.Management.SecurityInsights

検索結果を見ながら、以下を確認します。

  • MicrosoftSecurityProductName を辞書キーや比較条件に使っている箇所がないか
  • 製品名を文字列で直接書いている箇所がないか
  • プレビュー版でしか使えない定義済みプロパティを安定版プロジェクトで参照していないか
  • 旧パッケージ Microsoft.Azure.Management.SecurityInsights が残っていないか
  • 本番CIでプレビュー版を復元する設定になっていないか

グローバル運用では、リージョンごとのAzureサービス提供状況や組織内の変更凍結期間も考慮してください。SDKの型定義は同じでも、実際のSecurity Insightsワークスペース、データコネクター、アラートルールテンプレートの運用条件が拠点ごとに異なることがあります。共通コードを更新する前に、代表的なワークスペースで読み取り、差分確認、更新テストを行うのが安全です。

開発チームに伝えるべき実装ルール

MicrosoftSecurityProductName Struct を使うコードでは、次のルールを設けておくと保守しやすくなります。

ルール理由
本番では安定版パッケージを基本にするプレビュー版は正式リリース前に仕様が変わる可能性がある
製品名文字列を散在させないブランド名変更や表記揺れに対応しやすくする
null入力を許容しないコンストラクターがnullで例外を投げるため
ProductFilter の変更は実ワークスペースで検証するコンパイル成功だけではルールの有効性を判断できない
SDK更新とサービス設定変更を分けてレビューする不要なポータル変更や誤った移行作業を防ぐ

特に、セキュリティ運用の自動化コードは「動けばよい」ではなく、「どの製品のアラートを対象にしているか」が監査できることが重要です。ProductFilter に渡す値は、コード上の定数、設定ファイル、運用手順書で同じ表記にそろえ、変更履歴を追えるようにしましょう。

よくある誤解と対処法

誤解正しい見方
.NET自体の新機能だと思ってしまう.NETランタイムではなく、Azure SDK for .NETのSecurity Insightsモデルの話
Azureポータルで設定変更が必要だと思ってしまうこのStruct自体はSDK上の型であり、直接のポータル設定変更ではない
プレビュー版の値を安定版でも使えると思ってしまう定義済みプロパティはパッケージバージョンで差が出る可能性がある
移行期限が発生したと思ってしまうこのStruct単体の強制期限は確認できない。ただし旧SDKは移行対象
文字列コンストラクターなら何でも通ると思ってしまうSDK上は生成できても、Security Insights側で意味のある値とは限らない

次に取るべき行動

今回の MicrosoftSecurityProductName Struct 更新ポイントは、緊急パッチ対応ではなく、Security Insightsを扱う.NETコードの棚卸しに向いている内容です。まずはリポジトリ内の Azure.ResourceManager.SecurityInsights 参照を確認し、本番が安定版を使っているか、プレビュー版を意図せず取り込んでいないかを見てください。

次に、ProductFilter、MicrosoftSecurityProductName、旧パッケージ名でコード検索し、製品名のハードコードやバージョン不一致を洗い出します。旧SDKを使っている場合は、Azure.ResourceManager.SecurityInsights への移行を開発計画に入れるべきです。すでに新SDKを使っている場合は、定義済みプロパティと文字列生成の使い分け、CI/CDでのパッケージ固定、実ワークスペースでの検証を整えることで、今後のSDK更新にも対応しやすくなります。
[4]: https://www.nuget.org/packages/Azure.ResourceManager.SecurityInsights “
NuGet Gallery
| Azure.ResourceManager.SecurityInsights 1.1.0
“
[7]: https://www.nuget.org/packages/Microsoft.Azure.Management.SecurityInsights/2.0.0 “
NuGet Gallery
| Microsoft.Azure.Management.SecurityInsights 2.0.0
“

Azure
C# .NET Microsoft Sentinel Azure SDK SecurityInsights

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次