リリース日:2025 年 2 月 25 日

Version:.NET 8 以降.NET Framework、すべてのバージョン

概要

Microsoft は、最新バージョンの Windows に対してセキュリティの強化をロールアウトしました。 これらのセキュリティの強化により、一時パスの処理が変更され、修正プログラムが適用された後、System.IO.Path.GetTempPath()などの特定の.NET Frameworkおよび .NET API から別の場所が返される可能性があります。

必要な操作:

.NET Framework または のアクションは必要ありません。NET ベースのアプリケーション。 アプリケーションは、環境に適用されるセキュリティの強化によって自動的に恩恵を受けます。 ほとんどのアプリケーションでは、動作の変化は観察されません。 

この記事の残りの部分では、これらのセキュリティ強化がアプリケーションのランタイム動作に影響を与える可能性があるかどうかを判断する方法について詳しく説明します。 この記事では、必要に応じてランタイム動作をカスタマイズする手順も示します

該当するソフトウェア

この記事は、次のソフトウェアに適用されます。 

次の Windows 更新プログラムのバージョンで実行されている場合にのみ。 

  • KB5052077がインストールされている場合のバージョン 22H2 Windows 10

  • Windows Server 2019(KB5053594がインストールされている場合) 

  • Windows Server 2016、KB5053594がインストールされている場合 

この記事は、Windows 11、Windows Server 2022 以降で実行されている.NET Frameworkまたは .NET には適用されません。 

この記事 は、 Windows 以外のプラットフォームで実行されている場合、.NET には適用されません。 

詳細な説明と影響に関するステートメント

上記の Windows 更新プログラム KB の時点で、Microsoft は、以前の Win32 GetTempPath API のより安全な置き換えとして機能するように、Win32 GetTempPath2 API を以前の市場バージョンの Windows にバックポートしました。 内部的には、.NET Framework と .NET は、 System.IO.Path.GetTempPath() メソッドの実装を提供するために、これらの Win32 API に依存しています。存在する場合は Win32 GetTempPath2 API が推奨され、GetTempPath2 が存在しない場合はフォールバックとして Win32 GetTempPath API が使用されます。 

これらの KB を使用すると、新しい Win32 GetTempPath2 API が該当するプラットフォームで使用できるようになるため、KB がインストールされると、.NET Framework と .NET は GetTempPath2 の使用を開始します。 

主な動作の変更は、SYSTEM ID として実行されている呼び出し元は、 System.IO.Path.GetTempPath() メソッドが既定で %WINDIR%\SystemTemp を返すのに対し、SYSTEM ID 以外のものとして実行されている呼び出し元は、メソッドが引き続き既存の値を返すのを観察することです。 

アプリケーションが以下 のすべての 条件を満たしている場合は、この変更の影響を受ける可能性があります。 

  • アプリケーションは、前の "該当するソフトウェア" 見出しの下に記載されているランタイムと OS プラットフォームを利用します。そして

  • アプリケーションは SYSTEM ID として実行されます。そして

  • 標準の一時ファイルの場所をリダイレクトするには、 %TMP% または環境変数 %TEMP% 手動で設定します。 (Win32 GetTempPath API ドキュメントの 「解説」セクション を参照してください)。

これらの 条件をすべて 満たしている場合は、Windows KB がインストールされると、意図したディレクトリ以外の一時ディレクトリにアプリケーションが書き込まれる可能性があります。 

この動作の変更は、任意の.NET Frameworkまたは を通じて確認できます。最終的に GetTempPath2 に依存する NET 提供の API。 最も一般的なエントリ ポイントは次のとおりです。 

これは、KB がインストールされると動作が変更される可能性があるメソッドの完全な一覧ではありません。 

アプリケーションが SYSTEM ID の下で実行されるかどうかを判断する 

.NET Frameworkまたは .NET アプリケーションの ID を決定するためのいくつかの異なるメカニズムがあります

IIS ベースの Web アプリケーション 

IIS は、SYSTEM ID を "LOCALSYSTEM" と呼びます。 IIS マネージャー (inetmgr.exe) で、[アプリケーション プール] タブに移動して、すべてのアプリ プールとそれに関連付けられている ID を表示します。 [ グループ 化] ドロップダウンから [ID] を選択して、LOCALSYSTEM ID として実行されているアプリ プールを簡単に確認することもできます。 

次のスクリーンショットは、LOCALSYSTEM として実行するように構成されたアプリ プール ("MyAppPool") の例を示しています。 このアプリ プール内で実行されているアプリケーションはすべて、SYSTEM ID として実行されます。 

スクリーンショットは、LOCALSYSTEM として実行するように構成されたアプリ プール ("MyAppPool") の例を示しています。 このアプリ プール内で実行されているアプリケーションはすべて、SYSTEM ID として実行されます。

次のスクリプトを使用して、管理者特権の PowerShell セッションからプログラムでこの情報にアクセスすることもできます。 

Import-Module IISAdministration  Get-IISAppPool | where {$_.ProcessModel.IdentityType -eq "LocalSystem"} 

上のスクリーンショットに示すように、SYSTEM レベルの "MyAppPool" アプリ プールを使用して構成されたマシンでは、この PowerShell スクリプトによって次が出力され、SYSTEM ID で "MyAppPool" が実行されていることを示します。 

Name                 Status       CLR Ver  Pipeline Mode  Start Mode  ----                 ------       -------  -------------  ---------- MyAppPool            Started      v4.0     Integrated     OnDemand 

Windows サービス 

.NET Framework または の場合。NET ベースのアプリケーションは Windows サービスとして登録されています。サービス マネージャーを使用して、関連付けられている ID を表示できます。 

管理者特権のコマンド プロンプトから、 services.mscを実行します。 サービス マネージャー UI が表示されます。 

管理者特権のコマンド プロンプトから services.msc を実行します。 サービス マネージャー UI が表示されます。

[ログオン] 列にサービス ID の "ローカル システム" が一覧表示されている場合、サービスは SYSTEM ID で実行されます。 

Get-Service コマンドレットを使用して、PowerShell を使用してこのデータに対してクエリを実行することもできます。 たとえば、 MyServiceという名前のサービスに対してこの情報を照会するには、次のコマンドを使用します。 

(Get-Service MyService).UserName -ieq "LocalSystem" 

SYSTEM ID で実行するようにサービスが登録されている場合、コンソールに True が出力されます。 

その他のメカニズム 

タスク マネージャー (taskmgr.exe) や Sysinternals Process エクスプローラー などのツールは、アプリケーションが SYSTEM ID で実行されているかどうかを示すこともできます。 

タスク マネージャーで、[詳細] ビューを使用して、システムで実行中のすべてのプロセスを一覧表示し、目的のプロセスを見つけて、[ ユーザー名 ] 列の下のエントリを確認します。 

タスク マネージャーで、[詳細] ビューを使用して、システムで実行中のすべてのプロセスを一覧表示し、目的のプロセスを見つけて、[ユーザー名] 列の下のエントリを確認します。

ユーザー名の値が "SYSTEM" と読み取った場合、プロセスは SYSTEM ID で実行されます。 

または、Sysinternals Process エクスプローラーで、目的のプロセスを見つけて[プロパティ] ビューを入力し、[イメージ] タブの [ユーザー] フィールドを確認します。 

[Sysinternals Process エクスプローラーで、目的のプロセスを見つけて [プロパティ] ビューを入力し、[イメージ] タブの [ユーザー] フィールドを確認します。

ユーザー値が "NT AUTHORITY\SYSTEM" と読み取った場合、プロセスは SYSTEM ID で実行されます。 

SYSTEM レベルのプロセスの一時パスを変更する 

次の PowerShell スクリプトは、新しいディレクトリ C:\NewSystemTemp\ を作成し、SYSTEM ID で実行されているプロセスのみにディレクトリ アクセスを制限する方法を示しています。 ファイルが既に設定されているディレクトリの ACL を変更しないでください。 

このスクリプトは、管理者特権の PowerShell セッションから実行する必要があります。 

mkdir C:\NewSystemTemp\  $acl = New-Object System.Security.AccessControl.DirectorySecurity  $acl.SetSecurityDescriptorSddlForm("O:SYG:SYD:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)")  Set-Acl C:\NewSystemTemp\ -AclObject $acl 

この操作が成功したことを確認するには、 コマンドを実行します。 

icacls C:\NewSystemTemp\ 

これにより、成功を示す次の出力が生成されます。 

C:\NewSystemTemp\ NT AUTHORITY\SYSTEM:(OI)(CI)(F)                    BUILTIN\Administrators:(OI)(CI)(F)   Successfully processed 1 files; Failed processing 0 files 

ディレクトリが作成されたら、 %SYSTEMTEMP% 環境変数をシステム レベルのスコープで設定します。 これを設定するには、System コントロール パネル UI を使用するか、プログラムで PowerShell を使用して設定できます。 

[Environment]::SetEnvironmentVariable("SYSTEMTEMP", "C:\NewSystemTemp", [EnvironmentVariableTarget]::Machine) 

次に、マシンを再起動します。 

%SYSTEMTEMP% 環境変数を変更すると、SYSTEM 以外の ID として実行されている .NET Framework アプリケーションと .NET アプリケーションの System.IO.Path.GetTempPath() の戻り値は変更されません。 これらのアプリケーションは、 %TMP% を受け入れたり、環境変数が存在する場合は環境変数を %TEMP% するなど、常に持っているのと同じ解決ロジックに従い続けます。 

同様に、 %TMP% または %TEMP% 環境変数を設定すると、SYSTEM ID として実行されている.NET Frameworkおよび .NET アプリケーションの System.IO.Path.GetTempPath() の戻り値は変更されません。 

詳細については、次の情報を参照してください。

.NET Frameworkと .NET の動作の詳細については、Path.GetTempPath に関する .NET ドキュメントを参照してください。 

基になる Windows OS の動作の詳細については、 Win32 GetTempPath2 API に関する Windows ドキュメントを参照してください。

Facebook LinkedIn メール

ヘルプを表示

その他のオプションが必要ですか?

サブスクリプションの特典の参照、トレーニング コースの閲覧、デバイスのセキュリティ保護方法などについて説明します。

Microsoft 365 サブスクリプションの特典

Microsoft 365 のトレーニング

Microsoft Security

アクセシビリティ センター