IIS 6.0 및 IIS 7 이상 간 보안 변경

아티클
07/19/2023

작성자: IIS 팀

소개

IIS 7 이상은 IIS 6.0에서 많은 새로운 보안 향상을 제공합니다. 이 문서에서는 인증, 권한 부여, SSL, 웹 서비스 확장 제한 목록 및 IP 제한 사항과 관련하여 이러한 개선 사항을 간략하게 설명합니다.

인증

ASP.NET 애플리케이션 개발자의 경우 IIS 7 이전에는 프로그래밍에 필요한 두 가지 인증 모델이 있었습니다. 이러한 모델은 IIS 및 ASP.NET 파이프라인이었습니다. 먼저 IIS는 요청을 검사하고 인증 루틴을 수행한 다음, 유사한 작업을 수행할 수 있도록 ASP.NET 전달합니다.

IIS 7 이상에서는 이러한 두 모델을 통합하여 두 이전 모델 모두에 가장 적합한 새로운 강력한 파이프라인을 생성했습니다. IIS는 여전히 모든 이전 인증 프로토콜을 지원하지만 이제는 모든 콘텐츠 형식으로부터 보호할 수 있고 Windows 계정에 의존하지 않는 양식 인증도 지원합니다. 알고 사랑하게 된 모든 이전 기능을 지원하는 것 외에도 익명 인증 기능과 같은 일부 기능을 향상시켰습니다.

이러한 변경 내용은 향후 섹션에서 설명합니다.

익명 인증 변경 내용

IIS 7 이상에서는 익명 인증이 이전 버전과 비슷한 방식으로 동작하며 작업자 프로세스 ID의 콘텐츠로 실행되는 기능인 변경 내용이 하나뿐입니다. 각 애플리케이션 풀은 사용자 계정의 콘텐츠로 실행되도록 구성되며 이 계정의 기본값은 NETWORKSERVICE입니다.

ASP.NET 애플리케이션은 web.config 파일에서 다음 코드를 사용하여 가장을 해제하고 애플리케이션 풀 ID에서 실행하는 것이 매우 일반적이었습니다.

<identity impersonate="false"/>

프로세스 ID의 컨텍스트에서 애플리케이션을 실행해야 하는 몇 가지 시나리오가 있습니다.

프로세스 ID는 낮은 권한 계정이며 관리자는 해당 계정에 대한 시스템을 잠갔습니다.
프로세스 ID에 네트워크 액세스 권한이 부여되었으며 데이터베이스와 같은 백 엔드 리소스에 액세스하는 데 사용됩니다.

IIS 7 이상을 위한 재설계의 일환으로 이 시나리오를 안전하고 쉽게 수행할 수 있도록 하고 싶었습니다. 이 시나리오를 구현하려면 IIS에서 다음이 필요합니다.

익명 인증 모듈 설치 및 사용
익명 사용자 이름 및 암호를 빈 문자열로 설정

이렇게 하려면 다음과 같이 표시되도록 익명 인증에 대한 구성을 수정합니다.

<anonymousAuthentication enabled="true" userName="" defaultLogonDomain="" />

이 구성은 IIS에 작업자 프로세스 ID의 컨텍스트에서 항상 실행하도록 지시합니다.

기본적으로 IIS 7.0 이상의 익명 인증 ID는 IUSR 계정입니다. 이 계정은 최소한의 권한과 권한을 가진 낮은 권한 ID입니다. 새 기본 제공 계정에 대한 자세한 내용은 IIS 7 이상 문서의 기본 제공 계정 및 그룹 이해 문서를 참조하세요.

여권 변경 내용

레거시 Passport 인증에 대한 지원은 IIS 5/6 및 Windows Server 2000 및 2003에 기본 제공되었습니다. IIS 5 및 6의 Passport 지원은 "Passport 인증 사용"에 대한 IIS 서비스 관리자의 디렉터리 보안 탭에 검사box로 노출되었습니다. 이 검사box는 IIS에 레거시 Tweener 프로토콜 챌린지를 보낼 수 있는 기능을 제공했습니다. 또한 IIS 통합이 작동하기 전에 웹 사이트를 Passport 서비스 프로비저닝 포털에 등록하고, 암호화 키를 가져오고, 서버에서 레거시 Passport Manager를 구성해야 했습니다.

Windows Server 2008 이상에서는 레거시 Passport 이진 파일 및 IIS와의 통합이 제거되었습니다.

Passport 서비스는 이후 Windows Live ID로 변경되었습니다. 새로운 라이브 ID 서비스는 확실히 레거시 Passport 서비스에서 성장하지만, 주요 변경 사항이 있습니다. 가장 큰 변경 사항 중 하나는 파트너 사이트가 라이브 ID와 통합되는 방법입니다. 공개적으로 사용 가능한 Windows Live ID 웹 인증 SDK를 사용하여 라이브 ID 인증을 추가할 수 있습니다. Windows Live ID 서비스는 ID 페더레이션 및 ADFS도 지원하지만 해당 기능은 특정 사례에 대한 새로운 기능이며 "Passport"를 대체하지 않습니다.

양식 인증

양식 인증은 ASP.NET 일부로서 Windows 및 비 Windows ID를 모두 인증하고 애플리케이션에서 나중에 사용할 수 있는 사용자 개체를 가져올 수 있습니다. IIS 7 이상에서는 이제 양식 인증을 완벽하게 지원하며 모든 콘텐츠 형식에 대한 액세스를 보호하도록 구성할 수 있습니다.

IIS 7 이상에서 인증된 ID를 확인하는 방법

IIS 7 이상에서는 일부 사소한 변경만 있는 이전 버전의 IIS와 비슷한 방식으로 핵심 엔진에서 인증 규칙을 처리합니다. 처리 순서를 더 잘 이해하기 위해 IIS에서 평가하는 순서를 기반으로 하는 규칙은 다음과 같습니다.

먼저 IIS는 가상 디렉터리에서 사용자 이름 및 암호가 구성되었는지 여부를 결정합니다. 자격 증명 집합이 정의된 경우 해당 자격 증명이 사용됩니다. IIS 7 이전 관리자의 경우 이러한 자격 증명은 UNC 자격 증명입니다.
가상 디렉터리에 자격 증명이 구성되지 않은 경우 IIS는 인증 중에 제공된 자격 증명을 사용합니다. 이러한 자격 증명은 익명 인증을 위해 구성된 ID 또는 기본, 다이제스트 또는 Windows 인증 사용하도록 설정된 경우 인증 핸드셰이크 중에 사용자가 제공한 자격 증명에 속할 수 있습니다.
인증된 사용자가 설정되지 않은 경우(예: 양식 인증 사용) 프로세스 ID를 사용해야 하는지 여부를 결정합니다.
현재 ID가 없는 경우 IIS는 거부된 액세스를 반환합니다.

권한 부여

AzMan 지원

IIS 6.0에서는 AZMan 규칙을 기반으로 하는 새로운 권한 부여 모델을 도입했습니다. IIS 7 이상에서는 ASP.NET 권한 부여 모델과 매우 유사한 새 모델을 위해 이 기능을 더 이상 사용하지 않습니다(아래 URL 권한 부여 항목 참조).

URL 권한 부여

IIS 7 이상에는 두 가지 권한 부여 솔루션이 있습니다. 첫 번째는 ASP.NET 권한 부여 모델을 사용하는 것입니다. 이 메서드를 사용하려면 system.web> 구성에서 <모든 권한 부여 규칙을 정의해야 하며, 이미 ASP.NET 대해 작성된 규칙이 있는 애플리케이션에는 0개의 변경 내용이 필요합니다. 두 번째 모델은 새 IIS 권한 부여 아키텍처로 이동하는 것입니다. 이 모델은 ASP와 매우 유사합니다. 몇 가지 사소한 변경 사항이 있는 NET의 모델:

규칙은 순서에 따라 달라지지 않습니다.
거부 규칙은 목록의 맨 위로 정렬됩니다.
규칙은 ASP.NET 반대 방식으로 처리됩니다. 기본순으로: 조부모, 부모, 자식, ASP.NET 권한 부여는 반대 순서로 규칙을 처리합니다. 자식, 부모, 조부모

ASP.NET 권한 부여 모델과 IIS 권한 부여 모델 간의 차이점을 더 잘 이해하려면 먼저 ASP.NET 권한 부여 구성을 살펴보겠습니다.

<authorization>
    <allow users="Vik_Malhotra" />
    <deny roles="administrators" />
    <deny users="*" />
</authorization>

이 예제에서는 Vik_Malhotra 허용하지만 다른 모든 사용자는 거부합니다. IIS에서 구성은 매우 유사합니다.

<authorization>
    <add accessType="allow" users="Vik_Malhotra" />
    <add accessType="deny" roles="administrators" />
    <add accessType="deny" users="*" />
</authorization>

구문 변경의 이유는 애플리케이션 개발자가 이러한 두 모델이 실제로 다르다는 것을 알고 있지만 동시에 최소한의 노력으로 한 구현에서 다른 구현으로 규칙을 이동할 수 있도록 하기 위한 것이었습니다.

SSL

IIS 6.0에서 IIS는 메타베이스에 SSL 관련 정보를 저장하고 HTTP.SYS 함께 SSL 협상 프로세스의 상당 부분을 관리했습니다. IIS 7 이상에서는 이 구성의 대부분을 HTTP로 이동했습니다. SYS의 저장소입니다.

각 IIS 6.0 구성 설정이 IIS 7 이상 구성(또는 HTTP.SYS 구성)으로 전달되는 방법을 설명하기 위해 다음 차트가 아래에 구성되었습니다.

IIS 6.0 메타베이스 구성	속성 설명	IIS 7.0 이상 아키텍처
AccessSSLFlags	AccessSSLFlags는 AccessSSL AccessSSL128 AccessSSLNegotiateCert AccessSSLRequireCert AccessSSLMapCert 0 값이 SSL이 없음을 의미하는 비트 마스크입니다.	액세스> 섹션의 IIS 7.0 이상 구성에서 <계속 지원되는 속성
CertCheckMode	CRL(인증서 해지 목록) 검사 사용하거나 사용하지 않도록 설정합니다.	이제 이 값은 PHTTP_SERVICE_CONFIG_SSL_PARAM 개체의 http.sys 저장됩니다.
RevocationFreshnessTime	RevocationFreshnessTime 속성이 1(true)로 설정된 경우 인증서 클라이언트에 캐시된 CRL이 유효한 경우에도 인증서 클라이언트의 CRL(인증서 해지 목록)이 원격 위치에서 CRL에 의해 업데이트됩니다. RevocationURLRetrievalTimeout을 사용하여 다른 시간 제한 간격(분)을 지정하지 않는 한 기본 시간 제한 간격은 1일입니다.	이제 이 값은 PHTTP_SERVICE_CONFIG_SSL_PARAM 개체의 http.sys 저장됩니다.
SecureBindings	SecureBindings 속성은 서버 인스턴스에서 사용되는 보안 네트워크 엔드포인트를 결정하기 위해 IIS에서 사용하는 문자열을 지정합니다.	이 속성은 사이트의> 바인딩> 섹션에서 <IIS 7.0 이상 구성에서 <계속 지원됩니다. 사용되는 프로토콜은 "https"에 의해 필요합니다.
SSLAlwaysNegoClientCert	SSLAlwaysNegoClientCert 속성은 SSL 클라이언트 연결 협상을 제어합니다. 이 속성이 true로 설정된 경우 SSL 연결이 협상될 때마다 서버는 클라이언트 인증서를 즉시 협상하여 비용이 많이 드는 재협상을 방지합니다. SSLAlwaysNegoClientCert를 설정하면 클라이언트 인증서 재협상 교착 상태를 제거하는 데 도움이 되며, 이는 재협상 요청이 수신될 때 클라이언트가 큰 요청 본문을 보낼 때 차단될 때 발생할 수 있습니다.	이제 이 값은 PHTTP_SERVICE_CONFIG_SSL_PARAM 개체의 http.sys 저장됩니다.
SSLCertHash	SSLCertHash 속성은 사용 중인 SSL 인증서의 해시를 저장하는 데 사용됩니다.	이제 이 값은 PHTTP_SERVICE_CONFIG_SSL_PARAM 개체의 http.sys 저장됩니다.
SslCtlIdentifier	SslCtlIdentifier 속성에는 CTL(특정 인증서 신뢰 목록)을 식별하는 고유 값이 포함되어 있습니다. CTL을 정확하게 참조하려면 SslCtlStoreName과 함께 사용해야 합니다.	이제 이 값은 PHTTP_SERVICE_CONFIG_SSL_PARAM 개체의 http.sys 저장됩니다.
SslCtlStoreName	SslCtlStoreName 속성에는 CTL(인증서 신뢰 목록)이 포함된 CryptoAPI 저장소의 이름이 포함됩니다. CTL을 정확하게 참조하려면 SslCtlIdentifier와 함께 사용해야 합니다.	이제 이 값은 PHTTP_SERVICE_CONFIG_SSL_PARAM 개체의 http.sys 저장됩니다.
SSLStoreName	SSLStoreName 속성은 인증서의 키 쌍이 있는 저장소의 이름을 저장하는 데 사용됩니다.	이제 이 값은 PHTTP_SERVICE_CONFIG_SSL_PARAM 개체의 http.sys 저장됩니다.
SslUseDsMapper	SslUseDsMapper 속성은 IIS가 Windows 디렉터리 서비스 인증서 매퍼 또는 IIS 인증서 매퍼를 사용할지 여부를 지정합니다. SSLUseDSMapper가 false로 설정된 경우 IIS는 IIS 인증서 매퍼를 사용합니다.	이제 이 값은 PHTTP_SERVICE_CONFIG_SSL_PARAM 개체의 http.sys 저장됩니다.

HTTP.SYS PHTTP_SERVICE_CONFIG_SSL_PARAM 개체에 대한 자세한 내용은 다음 설명서를 참조하세요.

이러한 모든 변경 내용은 커버 아래에서 투명하게 처리되므로 서버 관리이스트레이터는 특별한 작업이 없습니다. IIS는 모든 작업을 자동으로 수행합니다. 이전 IIS 6.0 속성에 액세스하는 애플리케이션이 있는 경우 이제 HTTP에 있습니다. SYS의 구성 저장소인 ABO 매퍼 인터페이스는 올바른 값을 읽고 쓸 수 있도록 하므로 애플리케이션이 실패하지 않고 계속 작동합니다.

웹 서비스 확장 제한 목록

IIS 7 이상에서는 이 기능이 약간 수정되어 이름이 "isapiCgiRestrictionList"를 읽지만 그렇지 않으면 IIS 6.0에서와 같이 작동하고 동작합니다.

이 변경의 이유는 실제 사용을 강조하기 위한 것이었습니다. IIS 6.0에서 이 기능은 불량 ISAPI 또는 CGI 이진 파일을 IIS 서버에 복사한 다음 실행할 수 없도록 하기 위해 추가되었습니다. IIS 7 이상의 재설계를 통해 지원되는 두 가지 모델이 있습니다.

"클래식" ISAPI 파이프라인
새 통합 파이프라인

"클래식" ISAPI 파이프라인에 있는 경우 IIS 6.0을 사용할 때 예상한 대로 모든 것이 계속 작동합니다. 이 점을 설명하기 위해 ISAPI 모드에서 실행할 때 ASP.NET 작동하는 방식을 고려합니다. 먼저 aspnet_isapi.dll 전체 경로를 추가하고 아래와 같이 allowed="true"로 설정해야 합니다.

<isapiCgiRestriction>
    <add path="F:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
    allowed="true" groupId="ASP.NET v2.0.50727" description="ASP.NET v2.0.50727" />
</isapiCgiRestriction>

이제 이 코드(aspnet_isapi.dll)를 실행할 수 있습니다. 파이프라인 모드를 통합 모드로 전환하고 allowed="false"를 변경한 경우 ASP.NET 코드가 계속 실행됩니다.

이유는 무엇입니까? 그 이유는 isapiCgiRestrictionList가 ISAPI 및 CGI 코드에만 적용하기 때문입니다. 통합 모드에서 ASP.NET 이제 새 아키텍처의 일부이므로 isapiCgiRestrictionList의 영향을 받지 않습니다. 새 통합 파이프라인에서 ASP.NET 코드를 실행하지 않으려면 모듈 목록에서 managedEngine을 제거하면 됩니다.

IP 제한

IP 제한은 "allowUnlisted"라는 새 속성을 지원한다는 점을 제외하면 과거와 똑같은 방식으로 작동합니다. 이 속성은 전역 수준에서 시스템에 대한 보안 정책을 보다 쉽게 구성할 수 있도록 추가되었습니다. 예를 들어 정책에서 특정 IP 주소만 허용해야 하지만 나열되지 않은 다른 모든 주소를 거부해야 하는 경우 과거에는 그렇게 하기가 쉽지 않았습니다. 마찬가지로, 지정된 IP 주소 집합만 거부하고 나열되지 않은 모든 주소를 허용하면 이제 쉽게 수행할 수 있습니다. 서버 관리자는 전역 정책을 설정한 다음, 애플리케이션 또는 사이트 관리자가 서버에서 변경할 수 없도록 이 값을 잠글 수 있습니다.

설명하려면 사용자가 로컬로만 액세스하도록 하려는 개발 머신을 고려합니다. 다음 구성은 allowUnlisted="false"를 설정하여 해당 정책을 구현한 다음 localhost(127.0.0.1) 액세스만 명시적으로 허용합니다.

<system.webServer>
    <security>
        <ipSecurity allowUnlisted="false">
            <add ipAddress="127.0.0.1" allowed="true" />
        </ipSecurity>
    </security>
</system.webServer>

다음을 통해 공유