보기 상태 MAC(메시지 인증 코드) 오류 해결

기술 자료 번역 기술 자료 번역
기술 자료: 2915218 - 이 문서가 적용되는 제품 보기.
모두 확대 | 모두 축소

보기 상태란?

보기 상태는 ASP.NET 응용 프로그램에서 WebForms(.aspx) 페이지 간에 왕복되는 정보입니다. __VIEWSTATE 필드의 HTML 태그는 다음과 비슷합니다.

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

__VIEWSTATE 필드에 저장될 수 있는 항목의 예 하나는 단추 컨트롤의 텍스트입니다. 사용자가 단추를 클릭하면 Button_Click 이벤트 처리기가 보기 상태 필드에서 단추의 텍스트를 추출할 수 있습니다. ASP.NET 보기 상태에 대한 훨씬 더 자세한 개요는 MSDN(Microsoft Developer Network) 웹 사이트의 ASP.NET 보기 상태 개요 항목을 참조하십시오.

__VIEWSTATE 필드에는 포스트백의 페이지를 다시 구성하는 데 사용되는 중요 정보가 포함되어 있으므로, 공격자가 이 필드를 변조할 수 없는지 확인하십시오. 공격자가 악성 __VIEWSTATE 페이로드를 제출한 경우 이 공격자는 잠재적으로 응용 프로그램이 그렇지 않으면 수행하지 않을 작업을 수행하도록 속일 수 있습니다.

이러한 유형의 변조 공격을 방지하기 위해 __VIEWSTATE 필드가 MAC(메시지 인증 코드)에 의해 보호됩니다. ASP.NET은 포스트백 발생 시 __VIEWSTATE 페이로드와 함께 제출되는 MAC의 유효성을 검사합니다. MAC을 계산하는 데 사용되는 키는 Web.config 파일에서 응용 프로그램의 <machineKey> 요소에 지정됩니다. 공격자가 <machineKey> 요소의 내용을 추측할 수 없기 때문에 __VIEWSTATE 페이로드를 사용하여 변조하려고 시도하는 경우 유효한 MAC을 제공할 수 없습니다. ASP.NET은 유효한 MAC이 제공되지 않았음을 감지하고 악의적인 요청을 거부합니다.

MAC 유효성 검사 오류의 원인은 무엇입니까?

MAC 유효성 검사 오류는 다음 예와 유사합니다.

'/' 응용 프로그램에 서버 오류가 있습니다.

viewstate MAC의 유효성 검사가 실패했습니다. 이 응용 프로그램이 웹 팜 또는 클러스터에서 호스트되는 경우 <machineKey> 구성이 동일한 validationKey 및 유효성 검사 알고리즘을 지정하는지 확인하십시오. 클러스터에서는 AutoGenerate를 사용할 수 없습니다.

설명: 현재 웹 요청을 실행하는 동안 처리되지 않은 예외가 발생했습니다. 스택 추적을 검토하여 발생한 오류 및 코드에서 오류가 발생한 위치에 대한 자세한 정보를 확인하십시오.

예외 정보: System.Web.HttpException: viewstate MAC의 유효성 검사가 실패했습니다. 이 응용 프로그램이 웹 팜 또는 클러스터에서 호스트되는 경우 <machineKey> 구성이 동일한 validationKey 및 유효성 검사 알고리즘을 지정하는지 확인하십시오. 클러스터에서는 AutoGenerate를 사용할 수 없습니다.

소스 오류: [관련된 소스 줄 없음]

소스 파일: ... 줄: 0

스택 추적:

[ViewStateException: viewstate가 잘못되었습니다.
클라이언트 IP: ::1
포트: 40653
참조 페이지: http://localhost:40643/MyPage.aspx
경로: /MyPage.aspx
사용자 에이전트: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
ViewState: ...]

[HttpException (0x80004005): viewstate MAC의 유효성 검사가 실패했습니다. 이 응용 프로그램이 웹 팜 또는 클러스터에서 호스트되는 경우 <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: 웹 응용 프로그램이 팜(다중 환경)에서 실행되고 있습니다.

ASP.NET은 각 응용 프로그램에 대한 암호화 키를 자동으로 생성하고 HKCU 레지스트리 하이브에 해당 키를 저장합니다. 응용 프로그램 구성에 명시적 <machineKey> 요소가 없는 경우 자동 생성된 이 키가 사용됩니다. 하지만 자동 생성된 이 키가 해당 키를 생성한 컴퓨터에 로컬인 경우 이 시나리오는 팜에서 실행되는 응용 프로그램에 대한 문제를 일으킵니다. 팜의 각 서버가 고유한 로컬 키를 생성하고 팜의 어느 서버도 사용할 키에 동의하지 않게 됩니다. 따라서 하나의 서버가 다른 서버에서 이용하는 __VIEWSTATE 페이로드를 생성하는 경우 소비자는 MAC 유효성 검사 실패를 경험하게 됩니다.
  • 해결 방법 1a: 명시적 <machineKey> 요소 생성

    명시적 <machineKey> 요소를 응용 프로그램의 Web.config 파일에 추가하여 개발자는 자동 생성된 암호화 키를 사용하지 않도록 ASP.NET에 지시합니다. <machineKey> 요소를 생성하는 방법에 대한 지침은 부록 A를 참조하십시오. 이 요소가 Web.config 파일에 추가된 후 팜의 각 서버에 응용 프로그램을 다시 배포하십시오.

    참고?Microsoft Azure 웹 사이트와 같은 일부 웹 호스팅 서비스는 해당 백 엔드 서버에서 각 응용 프로그램의 자동 생성된 키를 동기화하는 단계를 수행합니다. 이를 통해 명시적 <machineKey> 요소를 지정하지 않은 응용 프로그램이 팜에서 실행되고 있더라도 이러한 환경에서 계속 작동할 수 있습니다. 응용 프로그램이 타사 호스팅 서비스에서 실행되고 있는 경우 호스팅 공급자에게 문의하여 이 경우가 사용자에게 해당되는지 확인하십시오.

  • 해결 방법 1b: 부하 분산 장치에서 선호도를 사용하도록 설정

    사이트가 부하 분산 장치 뒤에서 작동하고 있는 경우 서버 선호도를 사용하도록 설정하여 일시적으로 이 문제를 해결할 수 있습니다. 그러면 모든 암호화 페이로드가 같은 서버에서 생성되고 이용되도록 부하 분산 장치 뒤에 있는 하나의 실제 서버와만 지정된 클라이언트가 상호 작용하게 할 수 있습니다.

    이를 문제에 대한 장기적인 해결 방법으로 간주해서는 안 됩니다. 서버 선호도가 사용되도록 설정된 경우에도, 부하 분산 장치의 선호도가 높은 원래 서버가 오프라인이 되는 경우 대부분의 부하 분산 장치는 클라이언트를 다른 실제 서버로 리디렉션합니다. 이로 인해 새 새버는 클라이언트가 현재 가지고 있는 암호화 페이로드(예: __VIEWSTATE, 폼 인증 티켓, MVC 위조 방지 토큰 및 기타 서비스)를 거부하게 됩니다.

    서버 선호도를 사용하도록 설정하는 것보다 명시적 <machineKey> 요소를 사용하고 응용 프로그램 다시 배포하는 것을 우선적으로 사용해야 합니다.

원인 2: 작업자 프로세스가 IIS 7.0 응용 프로그램 풀 ID를 사용합니다.

IIS(인터넷 정보 서비스) 7.0(Windows Vista, Windows Server 2008)은 ASP.NET 응용 프로그램을 실행하는 서버에 대한 강화된 보안을 제공하는 새 격리 메커니즘인 응용 프로그램 풀 ID를 도입했습니다. 하지만 응용 프로그램 풀 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 유틸리티가 포함됩니다. 이 유틸리티를 통해 ASP.NET이 IIS와 상호 작용하여, 관리되는 응용 프로그램을 실행해야 하는 구성을 수행할 수 있습니다. 이러한 구성 중 하나는 레지스트리 하이브에서 필요한 키를 만들어 자동 생성된 컴퓨터 키 지속성을 사용하도록 설정합니다.

    먼저 해당 사이트가 사용하고 있는 응용 프로그램 풀을 확인해야 합니다. IIS에 포함된 inetmgr 유틸리티를 사용하여 확인할 수 있습니다. 왼쪽의 트리 뷰에서 해당 사이트를 선택하고 웹 사이트 관리를 마우스 오른쪽 단추로 클릭한 다음 고급 설정을 클릭합니다. 나타나는 대화 상자에 응용 프로그램 풀 이름이 표시됩니다.

    그림 축소그림 확대
    고급 설정


    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"


    참고 적절하게 IIS APPPOOL\* 이름을 확인하기 위해 aspnet_regiis 유틸리티용으로 시스템 서비스 APPHOSTSVC 및 WAS가 실행되고 있어야 합니다.

  • 해결 방법 2b: 명시적 <machineKey> 요소 생성

    명시적 <machineKey> 요소를 응용 프로그램의 Web.config 파일에 추가하여 개발자는 자동 생성된 암호화 키를 사용하지 않도록 ASP.NET에 지시합니다. <machineKey> 요소를 생성하는 방법에 대한 지침은 부록 A를 참조하십시오.


원인 3: 응용 프로그램 풀이 LoadUserProfile=false를 사용하여 구성되었습니다.

응용 프로그램 풀이 사용자 지정 ID로 실행 중인 경우 IIS가 해당 ID에 대한 사용자 프로필을 로드하지 않았을 수 있습니다. 여기에는 자동 생성된 <machineKey>를 유지하기 위해 ASP.NET에 대해 HKCU 레지스트리를 사용 가능하지 않게 만드는 부작용이 있습니다. 따라서 응용 프로그램이 다시 시작될 때마다 새로운 자동 생성된 키가 만들어집니다. 자세한 내용은 Microsoft의 웹 사이트의 사용자 프로필 절을 참조하십시오.
  • 해결 방법 3a: aspnet_regiis 유틸리티 사용

    해당 지침은 해결 방법 2a와 동일합니다. 자세한 내용은 해당 절을 참조하십시오.

  • 해결 방법 3b: 명시적 <machineKey> 사용

    명시적 <machineKey> 요소를 응용 프로그램의 Web.config 파일에 추가하여 개발자는 자동 생성된 암호화 키를 사용하지 않도록 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?속성을 사용하는 경우 일반적으로 현재 사용자의 사용자 이름 또는 사용자의 세션 식별자와 같은 값으로 설정됩니다. Microsoft Visual Studio 2012 이상 버전의 WebForms 응용 프로그램에 대한 프로젝트 템플릿에는 이 속성을 사용하는 샘플이 포함되어 있습니다. 자세한 내용은 MSDN(Microsoft Developer Network) 웹 사이트의 Page.ViewStateUserKey Property 항목을 참조하십시오.

ViewStateUserKey 속성이 지정된 경우 생성 시간에 해당 값이 __VIEWSTATE에 기록됩니다. __VIEWSTATE 필드가 이용되는 경우 서버는 현재 페이지의 ViewStateUserKey 속성을 확인하고 __VIEWSTATE 필드를 생성하는 데 사용된 값에 대해 이 속성의 유효성을 검사합니다. 이 값이 일치하지 않으면 해당 요청이 잠재적인 악성 요청으로 거부됩니다.

ViewStateUserKey 관련 실패의 예로 브라우저에 두 개의 탭이 열려 있는 클라이언트가 있습니다. 클라이언트가 사용자 A로 로그인되었으며, 첫 번째 탭에서 페이지가 ViewStateUserKey?속성에 "사용자 A"가 포함된 __VIEWSTATE를 사용하여 렌더링됩니다. 두 번째 탭에서 클라이언트가 로그아웃하고 사용자 B로 다시 로그인합니다. 클라이언트가 첫 번째 탭으로 돌아가고 양식을 제출합니다. 클라이언트의 인증 쿠키가 나타내는 내용이기 때문에 ViewStateUserKey?속성에 "사용자 B"가 포함될 수 있습니다. 하지만 클라이언트가 제출한 __VIEWSTATE 필드에는 "사용자 A"가 포함되어 있습니다. 이러한 불일치로 인해 실패하게 됩니다.
  • 해결 방법 4a: ViewStateUserKey가 올바르게 설정되었는지 확인

    해당 응용 프로그램이 ViewStateUserKey?속성을 사용하는 경우, 보기 상태가 생성되고 이용될 때 해당 속성 값이 같은지 확인합니다. 현재 로그인한 사용자의 사용자 이름을 사용 중인 경우 해당 사용자가 계속 로그인되어 있고 사용자 ID가 포스트백 시간에 변경되지 않았는지 확인합니다. 현재 사용자의 세션 식별자를 사용 중인 경우 세션 시간이 초과되지 않았는지 확인합니다.

    팜 환경에서 실행 중인 경우 <machineKey> 요소가 일치하는지 확인합니다. 이러한 요소를 생성하는 방법에 대한 지침은 부록 A를 참조하십시오.

부록 A: <machineKey> 요소를 생성하는 방법

보안 경고

단추를 클릭하면 <machineKey> 요소를 생성하는 여러 웹 사이트가 있습니다. 이러한 사이트 중 하나에서 얻은 <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 "이 cmdlet을 사용하려면 관리자 권한이 필요합니다."
        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
    # 시스템, 관리자 및 대상 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"

대신 응용 프로그램 풀이 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.config 파일의 <connectionStrings> 및 <machineKey> 요소를 보호하는 방법에 대한 자습서가 포함되어 있습니다.
참고 이것은 Microsoft 기술 지원 서비스 내에서 직접 작성한 “빠른 게시” 문서입니다. 여기에 포함된 정보는 발생한 문제에 대해 있는 그대로 제공됩니다. 이 문서는 즉시 참조할 수 있도록 빠르게 작성되어서 표기상의 오류가 포함되어 있을 수 있고 언제든지 예고 없이 수정될 수 있습니다. 기타 고려 사항은사용 약관을 참조하십시오. 정보

속성

기술 자료: 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

피드백 보내기

 

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