ビュー ステートのメッセージ認証コード (MAC) エラーの解決

文書翻訳 文書翻訳
文書番号: 2915218 - 対象製品
すべて展開する | すべて折りたたむ

ビュー ステートの概要

ビュー ステートとは、ASP.NET アプリケーションの Web フォーム (.aspx) ページ間でラウンドトリップされる情報です。__VIEWSTATE フィールドの HTML マークアップは次のような形式です。

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..."/>

__VIEWSTATE フィールドに格納されるアイテムの 1 つの例としては、Button コントロールのテキストがあります。ユーザーがボタンをクリックすると、Button_Click イベント ハンドラーでは、ビュー ステート フィールドから Button のテキストを抽出できるようになります。ASP.NET ビュー ステートの概要の説明については、MSDN (Microsoft Developer Network) Web サイトの「ASP.NET ビュー ステートの概要」トピックを参照してください。

__VIEWSTATE フィールドにはポストバックでのページの再構築に使用される重要な情報が含まれているため、攻撃者がこのフィールドを改ざんできないようにします。攻撃者が悪意のある __VIEWSTATE ペイロードを送信した場合、攻撃者は、アプリケーションをトリックで操作し、他の手段では実行されない処理を実行させる可能性があります。

この種類の改ざんの攻撃を防止するため、__VIEWSTATE フィールドは MAC (Message Authentication Code) により保護されています。ポストバックが発生すると、ASP.NET は、__VIEWSTATE ペイロードと共に送信される MAC を検証します。MAC を計算するために使用されるキーは、Web.config ファイルにあるアプリケーションの <machineKey> 要素で指定されています。攻撃者は <machineKey> 要素の内容を推測できないため、攻撃者が __VIEWSTATE ペイロードを改ざんしようとしても、攻撃者は有効な MAC を提示できません。ASP.NET は有効な MAC が提示されていないことを検出し、ASP.NET は悪意のある要求を拒否します。

MAC 検証エラーの原因

MAC 検証エラーは、次の例のような形式です。

'/' アプリケーションでサーバー エラーが発生しました。

viewstate MAC の検証に失敗しました。このアプリケーションが Web Farm またはクラスターによってホストされている場合、<machineKey> 構成が同一の validationKey および検証アルゴリズムを指定していることを確認してください。AutoGenerate をクラスターで使用することはできません。

説明: 現在の Web 要求を実行中に、ハンドルされていない例外が発生しました。エラーに関する詳細および例外の発生場所については、スタック トレースを参照してください。

例外の詳細: System.Web.HttpException: viewstate MAC の検証に失敗しました。このアプリケーションが Web Farm またはクラスターによってホストされている場合、<machineKey> 構成が同一の validationKey および検証アルゴリズムを指定していることを確認してください。AutoGenerate をクラスターで使用することはできません。

ソース エラー:[関連するソース行なし]

ソース ファイル: ... 行: 0

スタック トレース:

[ViewStateException: 無効な viewstate です。
クライアント IP:::1
ポート: 40653
参照元: http://localhost:40643/MyPage.aspx
パス: /MyPage.aspx
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
ビューステート:...]

[HttpException (0x80004005): viewstate MAC の検証に失敗しました。このアプリケーションが Web Farm またはクラスターによってホストされている場合、<machineKey> 構成が同一の validationKey および検証アルゴリズムを指定していることを確認してください。AutoGenerate をクラスターで使用することはできません。

詳細は http://go.microsoft.com/fwlink/?LinkID=314055 を参照してください。]
System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +190
System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) +46
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose) +861
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Purpose purpose) +51
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose) +67
System.Web.UI.HiddenFieldPageStatePersister.Load() +444
System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +368
System.Web.UI.Page.LoadAllState() +109
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +7959
System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +429
System.Web.UI.Page.ProcessRequest() +125
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +48
System.Web.UI.Page.ProcessRequest(HttpContext context) +234
ASP.mypage_aspx.ProcessRequest(HttpContext context) in ...:0
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +1300
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +140

原因 1: Web アプリケーションがファーム (複数サーバー環境) で実行されている

ASP.NET は、各アプリケーション用の暗号化キー自動的に生成し、そのキーを HKCU レジストリ ハイブに格納します。アプリケーションの構成に明示的な <machineKey> 要素がない場合、この自動生成されたキーが使用されます。ただし、この自動生成されたキーは、キーを作成したコンピューターにローカルであるため、このような状況はファームで実行されるアプリケーションの問題の原因になります。ファーム内の各サーバーが独自のローカル キーを生成するため、ファーム内のサーバーはどのキーを使用するかについて一致しません。その結果、あるサーバーが __VIEWSTATE ペイロードを生成し、それを別のサーバーが消費した場合、消費するサーバーでは MAC 検証エラーが発生します。
  • 解決策 1a: 明示的な <machineKey> 要素を作成する

    アプリケーションの Web.config ファイルに明示的な <machineKey> 要素を追加することで、開発者は、自動生成される暗号化キーを使用しないように ASP.NET に通知します。<machineKey> 要素を生成する方法の手順については、「付録 A」を参照してください。Web.config ファイルにこの要素を追加した後、ファーム内の各サーバーにアプリケーションを再展開します。

    注: Microsoft Azure Web サイトなどの一部の Web ホスティング サービスでは、バックエンド サーバーで各アプリケーションの自動生成されたキーを同期させる手順を実行します。この処理により、アプリケーションがファームで実行されている場合であっても、明示的な <machineKey> 要素を指定していないアプリケーションがこれらの環境で継続して動作できます。アプリケーションがサードパーティのホスティング サービスで実行されている場合は、ご利用のホスティング プロバイダーに問い合わせて、この状況が該当するかどうかを確認してください。

  • 解決策 1b: ロード バランサーでアフィニティを有効にする

    サイトがロード バランサーの背後で動作している場合、サーバー アフィニティを有効にすると問題を一時的に回避できます。これにより、すべての暗号化ペイロードが同じサーバーにより生成と消費の両方が行われるように、どのクライアントもロード バランサーの背後にある 1 台の物理サーバーのみと通信するようにできます。

    この方法は、問題に対する長期的な解決策にはしないでください。サーバー アフィニティが有効である場合であっても、ロード バランサーが関連付けられている元のサーバーがオフラインになると、多くのロード バランサーはクライアントを別の物理サーバーにリダイレクトします。これにより、新しいサーバーは、クライアントが現在所有する暗号化ペイロード (__VIEWSTATE、フォーム認証チケット、MVC の偽造対策トークン、およびその他のサービスなど) を拒否します。

    サーバー アフィニティを有効にするよりも、明示的な <machineKey> 要素を使用し、アプリケーションを再展開する方を優先させる必要があります。

原因 2: ワーカー プロセスが IIS 7.0 アプリケーション プール ID を使用している

インターネット インフォメーション サービス (IIS) 7.0 (Windows Vista、Windows Server 2008) では、アプリケーション プール ID (英語情報) が導入されました。これは、ASP.NET アプリケーションを実行するサーバーのセキュリティを強化できるようにする新しい分離メカニズムです。ただし、アプリケーション プール ID の下で実行されているサイトは、HKCU レジストリにアクセスできません。このレジストリは、ASP.NET ランタイムが、自動生成された <machineKey> キーを格納する場所です。この結果、アプリケーション プールがリセットされると、ASP.NET は自動生成されたキーを永続化することができません。そのため、w3wp.exe がリセットされるたびに、新しい一時キーが生成されます。

注: このことは、IIS 7.5 (Windows 7、Windows Server 2008 R2) およびそれ以降のバージョンでは問題にはなりません。これらのバージョンの IIS では、ASP.NET は、アプリケーション プールがリセットされた後も存続する別の場所に、自動生成されたキーを永続化できます。
  • 解決策 2a: aspnet_regiis ユーティリティを使用する

    ASP.NET のインストール環境には aspnet_regiis.exe ユーティリティが含まれています。このユーティリティにより、IIS を使用する ASP.NET インターフェイスは、マネージ アプリケーションの実行に必要な構成を実行することができます。これらのいずれかの構成により、レジストリ ハイブに必要なキーが作成され、自動生成されるマシン キーの永続化を有効にします。

    まず、サイトで使用しているアプリケーション プールを確認する必要があります。この情報は、IIS に含まれる inetmgr ユーティリティを使用すると確認できます。左側のツリー表示でサイトを選択し、[Manage Website] を右クリックし、[Advanced Settings] をクリックします。アプリケーション プール名を示すダイアログ ボックスが表示されます。

    元に戻す画像を拡大する
    Advanced Settings


    ASP.NET 4.0 アプリケーション プールに適したレジストリ キーをスキャフォールディングするには、以下の手順を実行します。
    1. 管理コマンド プロンプトを開きます。
    2. アプリケーション プールが 32 ビットと 64 ビットのどちらであるかに応じて、適切なディレクトリに移動します。
      • 32 ビット アプリケーション プール: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • 64 ビット アプリケーション プール: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

    3. そのディレクトリに移動し、次のコマンドを入力して、Enter キーを押します。

      aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

    アプリケーション プールが ASP.NET 2.0 または 3.5 アプリケーション プールである場合、以下の手順を実行します。
    1. 管理コマンド プロンプトを開きます。
    2. アプリケーション プールが 32 ビットと 64 ビットのどちらであるかに応じて、適切なディレクトリに移動します。
      • 32 ビット アプリケーション プール: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • 64 ビット アプリケーション プール: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. そのディレクトリに移動し、次のコマンドを入力して、Enter キーを押します。

      aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

    たとえば、アプリケーション プールが (上記の図にある) My App Pool という名前である場合は、次のコマンドを実行します。
    ?
    aspnet_regiis -ga "IIS APPPOOL\My App Pool"


    注: システム サービス APPHOSTSVC および WAS は、IIS APPPOOL\* の名前を適切に解決するには、aspnet_regiis ユーティリティに対して実行されている必要が生じる場合があります。

  • 解決策 2b: 明示的な <machineKey> 要素を作成する

    アプリケーションの Web.config ファイルに明示的な <machineKey> 要素を追加することで、開発者は、自動生成される暗号化キーを使用しないように ASP.NET に通知します。<machineKey> 要素を生成する方法の手順については、「付録 A」を参照してください。


原因 3: アプリケーション プールが LoadUserProfile=false を使用して構成されている

アプリケーション プールがカスタム ID を使用して実行されている場合、IIS は ID 用のユーザー プロファイルを読み込んでいない可能性があります。これには、ASP.NET が自動生成された <machineKey> を永続化するための HKCU レジストリが使用できなくなるという悪影響があります。そのため、アプリケーションが再起動するたびに新しい自動生成キーが作成されます。詳細については、マイクロソフト Web サイトの「ユーザー プロファイル (英語情報)」セクションを参照してください。
  • 解決策 3a: aspnet_regiis ユーティリティを使用する

    この解決策の手順は「解決策 2a」と同じです。詳細についてはそのセクションを参照してください。

  • 解決策 3b: 明示的な <machineKey> を使用する

    アプリケーションの Web.config ファイルに明示的な <machineKey> 要素を追加することで、開発者は、自動生成される暗号化キーを使用しないように ASP.NET に通知します。<machineKey> 要素を生成する方法の手順については、「付録 A」を参照してください。

  • 解決策 3c: 必要な HKCU レジストリ キーを手動でプロビジョニングする

    aspnet_regiis ユーティリティを実行できない場合は、Windows PowerShell スクリプトを使用すると、HKCU に適切なレジストリ キーをプロビジョニングできます。詳細については、「付録 B」を参照してください。

  • 解決策 3d: このアプリケーション プールに LoadUserProfile=true を設定する

    このアプリケーション プール内でのユーザー プロファイルの読み込みを有効にすることもできます。これにより、HKCU レジストリ ハイブ、一時フォルダー、およびその他のユーザー固有の保存場所がアプリケーションで使用できるようになります。ただし、これによりワーカー プロセスのディスクまたはメモリの使用量が増える可能性があります。この設定を有効にする方法に関する詳細については、「<processModel> 要素 (英語情報)」を参照してください。

原因 4: Page.ViewStateUserKey プロパティの値が正しくない

ソフトウェア開発者は Page.ViewStateUserKey プロパティを使用して、__VIEWSTATE フィールドにサイト間要求の偽造保護を追加することができます。Page.ViewStateUserKey プロパティを使用した場合、このプロパティは通常、現在のユーザーのユーザー名またはユーザーのセッション ID などの値に設定されます。Microsoft Visual Studio 2012 およびそれ以降のバージョンの Web フォーム アプリケーションのプロジェクト テンプレートには、このプロパティを使用するサンプルが含まれています。詳細については、MSDN (Microsoft Developer Network) Web サイトのトピック「Page.ViewStateUserKey プロパティ」を参照してください。

ViewStateUserKey プロパティが指定されている場合、生成時にその値は __VIEWSTATE に書き込まれます。__VIEWSTATE フィールドが消費される場合、サーバーは現在のページの ViewStateUserKey プロパティをチェックし、それを __VIEWSTATE フィールドの生成に使用された値と照合して検証します。値が一致しない場合、要求は悪意のある可能性がある要求として拒否されます。

ViewStateUserKey に関連するエラーの例としては、ブラウザーで 2 つのタブを開いているクライアントがあります。クライアントが User A としてログインし、第 1 のタブで、ViewStateUserKey プロパティに "User A" が含まれる __VIEWSTATE を使用してページがレンダリングされます。第 2 のタブでは、クライアントがログアウトし、User B としてログインして戻ります。クライアントが第 1 のタブに戻り、フォームを送信します。ViewStateUserKey プロパティには "User B" が含まれている可能性があります (これは、クライアントの認証 Cookie が通知する情報であるためです)。ただし、クライアントが送信した __VIEWSTATE フィールドには "User A" が含まれています。この不一致がエラーの原因です。
  • 解決策 4a: ViewStateUserKey が正しく設定されていることを確認する

    アプリケーションで ViewStateUserKey プロパティを使用する場合は、そのプロパティの値が、ビュー ステートが生成される時点とビュー ステートが消費される時点の両方で同じであることを確認します。現在ログインしているユーザーのユーザー名を使用している場合は、そのユーザーがまだログインしていて、ユーザーの ID がポストバックの時点で変更されていないことを確認します。現在のユーザーのセッション ID を使用している場合は、セッションがタイムアウトしていないことを確認します。

    ファーム環境で実行されている場合は、<machineKey> 要素が一致することを確認します。これらの要素を生成する方法の手順については、「付録 A」を参照してください。

付録 A: <machineKey> 要素を生成する方法

セキュリティに関する警告

ボタンをクリックすると <machineKey> 要素を生成する多くの Web サイトが存在します。これらのいずれかのサイトから取得した <machineKey> 要素は絶対に使用しないでください。これらのキーがセキュリティで保護されて作成されたかどうか、または秘密のデータベースに記録されているかどうかを知ることは不可能であるためです。使用するのは、自分で作成した <machineKey> 構成要素に限定する必要があります。


自分で <machineKey> 要素を生成するには、以下の Windows PowerShell スクリプトを使用する方法があります。

# Web.config ファイルにコピーして貼り付けることができる <machineKey> 要素を生成する。
function Generate-MachineKey {
[CmdletBinding()]
param (
[ValidateSet("AES", "DES", "3DES")]
[string]$decryptionAlgorithm = 'AES',
[ValidateSet("MD5", "SHA1", "HMACSHA256", "HMACSHA384", "HMACSHA512")]
[string]$validationAlgorithm = 'HMACSHA256'
  )
process {
function BinaryToHex {
[CmdLetBinding()]
param($bytes)
process {
$builder = new-object System.Text.StringBuilder
foreach ($b in $bytes) {
$builder = $builder.AppendFormat([System.Globalization.CultureInfo]::InvariantCulture, "{0:X2}", $b)
            }
$builder
        }
    }
switch ($decryptionAlgorithm) {
"AES" { $decryptionObject = new-object System.Security.Cryptography.AesCryptoServiceProvider }
"DES" { $decryptionObject = new-object System.Security.Cryptography.DESCryptoServiceProvider }
"3DES" { $decryptionObject = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider }
    }
$decryptionObject.GenerateKey()
$decryptionKey = BinaryToHex($decryptionObject.Key)
$decryptionObject.Dispose()
switch ($validationAlgorithm) {
"MD5" { $validationObject = new-object System.Security.Cryptography.HMACMD5 }
"SHA1" { $validationObject = new-object System.Security.Cryptography.HMACSHA1 }
"HMACSHA256" { $validationObject = new-object System.Security.Cryptography.HMACSHA256 }
"HMACSHA385" { $validationObject = new-object System.Security.Cryptography.HMACSHA384 }
"HMACSHA512" { $validationObject = new-object System.Security.Cryptography.HMACSHA512 }
    }
$validationKey = BinaryToHex($validationObject.Key)
$validationObject.Dispose()
[string]::Format([System.Globalization.CultureInfo]::InvariantCulture,
"<machineKey decryption=`"{0}`" decryptionKey=`"{1}`" validation=`"{2}`" validationKey=`"{3}`" />",
$decryptionAlgorithm.ToUpperInvariant(), $decryptionKey,
$validationAlgorithm.ToUpperInvariant(), $validationKey)
  }
}

ASP.NET 4.0 アプリケーションの場合、パラメーターを使用せずに Generate-MachineKey を呼び出すだけで、次のように <machineKey> 要素を生成できます。

PS> Generate-MachineKey
<machineKey decryption="AES" decryptionKey="..." validation="HMACSHA256" validationKey="..."/>

ASP.NET 2.0 および 3.5 アプリケーションは HMACSHA256 をサポートしていません。代わりに、SHA1 を指定して、次のように互換性のある <machineKey> 要素を生成することができます。

PS> Generate-MachineKey -validation sha1
<machineKey decryption="AES" decryptionKey="..." validation="SHA1" validationKey="..."/>

<machineKey> 要素が用意できたらすぐに、Web.config ファイル内に配置できます。<machineKey> 要素は、アプリケーションのルートにある Web.config ファイル内でのみ有効で、サブフォルダー レベルでは有効ではありません。

<configuration>
<system.web>
<machineKey ... />
</system.web>
</configuration>

サポートされるアルゴリズムの完全なリストを表示するには、Windows PowerShell プロンプトから help Generate-MachineKey を実行します。

付録 B: レジストリをプロビジョニングして自動生成されたキーを永続化する

既定では、ASP.NET の自動生成されたキーは HKCU レジストリで永続化されるため、ユーザー プロファイルが IIS ワーカー プロセスに読み込まれずにアプリケーション プールのリサイクルが行われると、これらのキーが失われる可能性があります。この状況は、標準的な Windows ユーザー アカウントとしてアプリケーション プールを実行している共有ホスティング プロバイダーに影響する可能性があります。

この状況を回避するため、ASP.NET は、HKCU レジストリではなく HKLM レジストリで自動生成キーの永続化を有効にします。これを行うには、通常、aspnet_regiis ユーティリティを使用します (「解決策 2a: aspnet_regiis ユーティリティを使用する」セクションの手順を参照)。ただし、このユーティリティを実行したくない管理者の場合は、代わりに以下の Windows PowerShell スクリプトを使用できます。

# 指定のユーザー アカウントが自動生成されたマシン キーを永続化できるように、HKLM レジストリをプロビジョニングする。
function Provision-AutoGenKeys {
[CmdletBinding()]
param (
[ValidateSet("2.0", "4.0")]
[Parameter(Mandatory = $True)]
[string] $frameworkVersion,
[ValidateSet("32", "64")]
[Parameter(Mandatory = $True)]
[string] $architecture,
[Parameter(Mandatory = $True)]
[string] $upn
  )
process {
# 続行するには管理者権限が必要。
if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
Write-Error "This cmdlet requires Administrator permissions."
return
    }
# レジストリに対して適切なビューを使用して HKLM を開く
if ($architecture -eq "32") {
$regView = [Microsoft.Win32.RegistryView]::Registry32;
} else {
$regView = [Microsoft.Win32.RegistryView]::Registry64;
    }
$baseRegKey = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $regView)
# ASP.NET 基本キーを開く
if ($frameworkVersion -eq "2.0") {
$expandedVersion = "2.0.50727.0"
} else {
$expandedVersion = "4.0.30319.0"
    }
$aspNetBaseKey = $baseRegKey.OpenSubKey("SOFTWARE\Microsoft\ASP.NET\$expandedVersion", $True)
# まだ存在していない場合は AutoGenKeys サブキーを作成する
$autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
if ($autoGenBaseKey -eq $null) {
$autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
# 問題のユーザーの SID を取得し、そのユーザーの AutoGenKeys サブキーを取得できるようにする
$sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
# SYSTEM、ADMINISTRATORS、およびターゲットの SID がフル アクセスを取得する
$regSec = New-Object System.Security.AccessControl.RegistrySecurity
$regSec.SetSecurityDescriptorSddlForm("D:P(A;OICI;GA;;;SY)(A;OICI;GA;;;BA)(A;OICI;GA;;;$sid)")
$userAutoGenKey = $autoGenBaseKey.OpenSubKey($sid, $True)
if ($userAutoGenKey -eq $null) {
# サブキーが存在しないため、適切に ACL を作成する
$userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
} else {
# サブキーが存在するため、ACL が適切であることを確認する
$userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

以下の例に、ユーザー example@contoso.com (Windows ユーザー アカウントの UPN) として実行されるアプリケーション プールの適切な HKLM レジストリ エントリをプロビジョニングする方法を示します。このアプリケーション プールは、CLR v2.0 (ASP.NET 2.0 または 3.5) を実行している 32 ビットのアプリケーション プールです。

PS> Provision-AutoGenKeys -FrameworkVersion 2.0 -Architecture 32 -UPN "example@contoso.com"

32 ビットではなく、アプリケーション プールが CLR v4.0 (ASP.NET 4.0 または 4.5) を実行している 64 ビットのアプリケーション プールである場合、コマンドは以下のようになります。

PS> Provision-AutoGenKeys -FrameworkVersion 4.0 -Architecture 64 -UPN "example@contoso.com"

自動生成されたキーが HKLM に格納される場合であっても、他のユーザー アカウントが暗号化に関する情報を読み取ることができないようにするため、各ユーザー アカウントの秘密の暗号化に関する情報を保持するレジストリ サブキーがアクセス制御リスト (ACL) に追加されます。

付録 C: 構成ファイルでの <machineKey> 要素の暗号化

サーバー管理者は、<machineKey> キーに関する情報などの機密性の高い情報を、構成ファイルのプレーンテキスト形式にはしたくない場合があります。このような場合、管理者は .NET Framework の「保護された構成」と呼ばれる機能を利用できます。この機能では、.config ファイルの特定のセクションを暗号化できます。これらの構成ファイルの内容が公開されなければ、これらのセクションの内容は秘密のままになります。

簡潔な概要は、MSDN Web サイトの「保護された構成」で参照できます。また、このページには Web.config ファイルの <connectionStrings> 要素と <machineKey> 要素を保護する方法に関するチュートリアルもあります。
注意 : これは、マイクロソフトのサポート組織内で直接作成された "緊急公開" の資料です。 この資料には、確認中の問題に関する現状ベースの情報が記載されています。 情報提供のスピードを優先するため、資料には誤植が含まれる可能性があり、予告なしに随時改定される場合があります。 その他の考慮事項については、使用条件を参照してください。

プロパティ

文書番号: 2915218 - 最終更新日: 2014年6月20日 - リビジョン: 2.0
この資料は以下の製品について記述したものです。
  • Microsoft .NET Framework 4.5.1 Release Candidate
  • Microsoft .NET Framework 4.5.1
  • Microsoft .NET Framework 4.5
  • Microsoft .NET Framework 4.0
  • Microsoft .NET Framework 3.5.1
  • Microsoft .NET Framework 3.5
  • Microsoft .NET Framework 2.0 Service Pack 2
  • Microsoft .NET Framework 1.1 Service Pack 1
キーワード:?
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218
Microsoft Knowledge Base の免責: Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com