인증 정보

서버의 정보에 액세스하기 전에 사용자에게 유효한 Microsoft Windows 사용자 계정 이름 및 암호를 제공하도록 요구할 수 있습니다. 이 확인 과정을 인증이라고 합니다. IIS의 많은 기능과 마찬가지로, 인증은 웹 사이트, 디렉터리 또는 파일 수준에 설정될 수 있습니다. IIS에서는 서버에서 컨텐트 액세스를 제어하는 아래와 같은 인증 방법을 제공합니다.

WWW 방법

FTP 방법

인증 설정에 대한 내용은 인증 설정 및 구성을 참조하십시오.


인증 방법 요약

방법 보안 수준 암호 보내기 방법 프록시 서버 및 방화벽을 통한 사용 여부 클라이언트 요구 사항
익명 없음 N/A 예 모든 브라우저
기본 낮음 Base64로 인코드된 일반 텍스트 예. Base64로 인코드된 일반 텍스트는 암호가 아니기 때문에 프록시 서버나 방화벽을 통해 일반 텍스트로 암호를 보내는 것은 위험합니다. 대부분의 브라우저
다이제스트 보통 해시 예. Internet Explorer 5.0 이상
고급 다이제스트 보통 해시 예. Internet Explorer 5.0 이상
Windows 통합 높음 NTLM 사용 시: 해시
Kerberos 사용 시: Kerberos 티켓
아니오. PPTP 연결을 통해 사용된 경우는 제외됩니다. NTLM의 경우는 Internet Explorer 2.0 이상, Kerberos의 경우는 Internet Explorer 5.0 이상이 설치된 Windows 2000 이상
인증서 높음 N/A 예. SSL 연결을 사용합니다. Internet Explorer 및 Netscape
FTP 익명 없음 N/A 예. 모든 FTP 클라이언트
FTP 기본 낮음 일반 텍스트 예. 모든 FTP 클라이언트


익명 인증

익명 인증을 통해 사용자 이름이나 암호를 입력하지 않고도 웹 사이트 또는 FTP 사이트의 공개 영역에 액세스할 수 있습니다. 사용자가 공개 웹 사이트 또는 FTP 사이트로의 연결을 시도할 때, 웹 서버는 사용자를 IUSR_computername이라는 Windows 사용자 계정에 할당합니다. 여기서 computername은 IIS가 실행되는 서버의 이름입니다. IUSR_computername 계정은 기본적으로 Windows 사용자 그룹 게스트에 포함됩니다. 이 그룹은 NTFS 권한이 부여한 보안 제한을 받으며, 이 제한은 일반 사용자가 액세스할 수 있는 수준과 사용할 수 있는 컨텐트 형식을 지정합니다.

서버에 여러 사이트가 있거나 서로 다른 액세스 권한을 필요로 하는 사이트 영역이 있는 경우, 각 웹 사이트나 FTP 사이트, 디렉터리, 파일마다 하나씩 여러 개의 익명 계정을 만들 수 있습니다. 이 계정에 액세스 권한을 다르게 주거나 다른 Windows 사용자 그룹에 이 계정을 할당함으로써, 사용자에게 다른 영역의 공개 웹 컨텐트 및 FTP 컨텐트에 대해 익명 액세스를 허용할 수 있습니다.

다음 프로세스는 IIS가 IUSR_computername 계정을 사용하는 방법을 설명합니다.

  1. IUSR_computername 계정은 설치하는 동안 IIS 컴퓨터의 게스트 그룹에 추가됩니다.
  2. 요청을 받으면 IIS는 코드를 실행하거나 파일에 액세스하기 전에 IUSR_computername 계정을 가장합니다. IIS는 이 계정의 사용자 이름과 암호를 알고 있기 때문에 IUSR_computername 계정을 가장할 수 있습니다.
  3. 클라이언트에게 페이지를 반환하기 전에, IIS는 NTFS 파일과 디렉터리 권한을 확인하여 IUSR_computername 계정이 파일에 액세스하는 것이 허용되는지 확인합니다.
  4. 액세스가 허용되면 인증이 완료되고 사용자는 리소스를 사용할 수 있습니다.
  5. 액세스가 허용되지 않은 경우, IIS는 다른 인증 방법 사용을 시도합니다. 없음이 선택되면, IIS는 브라우저에 "HTTP 403 액세스 거부" 오류 메시지를 반환합니다.

중요   \par 익명 인증을 설정하면 추가 인증 방법을 설정해도 IIS는 항상 처음에는 익명 인증을 사용하여 사용자를 인증하려고 합니다.

웹 서버 서비스 수준에서든 개인 가상 디렉터리 및 파일용이든 IIS 스냅인에서 익명 인증으로 사용되는 계정을 변경할 수 있습니다. 익명 계정에는 로컬로 로그인할 수 있는 사용자 권한이 있어야 합니다. 이 계정에 로컬 로그인 권한이 없으면 IIS가 익명 요청을 전혀 처리할 수 없게 됩니다. IIS 설치 프로그램은 IUSR_computername 계정에 특별히 로컬 로그온 권한을 허용합니다. 도메인 컨트롤러의 IUSR_computername 계정은 기본적으로 게스트 계정으로 주어지지 않습니다. 익명 로그온을 허용하려면 로컬로 로그온할 수 있도록 IUSR_computername 계정을 변경해야 합니다.

참고   ADSI(Active Directory Service Interfaces)를 사용하여 로컬 로그온 권한의 요구 사항을 바꿀 수 있습니다. 자세한 내용은 Active Server Pages 가이드의 LogonMethod 참조를 참조하십시오.

또한, MMC의 Group Policy Manager 스냅인을 사용하여 Windows의 IUSR_computername 계정에 대한 보안 권한을 바꿀 수도 있습니다. 그러나, 익명 사용자 계정이 특정 파일이나 리소스에 액세스할 권한이 없는 경우, 사용자 웹 서버는 그 리소스에 대한 익명 연결 만들기를 거부할 것입니다. 자세한 내용은 웹 서버 권한 설정을 참조하십시오.

중요   IUSR_computername 계정을 변경하면 웹 서버가 서비스하는 모든 익명 HTTP 요청에 영향이 있습니다. 이 계정을 변경할 때는 주의해야 합니다.

기본 인증

기본 인증 방법은 사용자 이름과 암호 정보를 수집하는 데 널리 사용되는 업계 표준 방법입니다.

클라이언트 인증 프로세스

  1. Internet Explorer 웹 브라우저에서는 사용자에게 이전에 할당된 Windows 계정 사용자 이름 및 암호를 입력할 수 있는 자격 증명이라고 하는 대화 상자가 표시됩니다.
  2. 웹 브라우저는 사용자의 자격 증명을 사용하여 서버에 연결을 시도합니다. 일반 텍스트 암호는 네트워크를 통해 보내지기 전에 Base64로 인코드됩니다.
  3. 중요   Base64 인코딩은 암호로 만드는 것이 아닙니다. Base64로 인코드된 암호가 네트워크 스니퍼에 의해 도용되면 인증되지 않은 사람이 그 암호를 쉽게 해독하여 다시 사용할 수 있습니다.

  4. 사용자의 자격 증명이 거절되면 Internet Explorer에서는 사용자가 자신의 자격 증명을 다시 입력할 수 있도록 인증 대화 상자가 표시됩니다. Internet Explorer에서는 연결에 실패하여 오류가 보고되기 전에 사용자가 세 번 연결을 시도할 수 있습니다.
  5. 사용자 이름과 암호가 올바른 Windows 사용자 계정과 일치하는지를 웹 서버가 확인해야 사용자가 연결됩니다.

기본 인증 설정에 대한 자세한 내용은 인증 설정 및 구성을 참조하십시오.

기본 인증의 이점은 기본 인증이 HTTP 지정의 일부이고 대부분의 브라우저가 지원한다는 것입니다. 반면, 단점은 기본 인증을 사용하는 웹 브라우저는 암호를 암호화하지 않은 형태로 전송한다는 것입니다. 네트워크상의 통신을 모니터링하면 공개적으로 사용할 수 있는 도구를 사용하여 아무나 쉽게 이 암호를 가로채 해독할 수 있습니다. 따라서, 기본 인증은 케이블 직접 연결이나 SSL(Secure Sockets Layer)과 같이 사용자와 웹 서버 간의 연결이 안전하다고 신뢰할 수 있는 경우가 아니면 권장하지 않습니다. 자세한 내용은 암호화를 참조하십시오.

참고   Windows 통합 인증은 기본 인증보다 우선권을 가집니다. 브라우저가 Windows 통합 인증을 선택하고 사용자 이름과 암호를 입력하라는 메시지가 나타나기 전에 현재의 Windows 로그온 정보를 사용하여 먼저 시도합니다. 현재는 Internet Explorer 2.0 이후 버전만이 Windows 통합 인증을 지원합니다.

다이제스트 인증

다이제스트 인증은 기본 인증과 같은 기능을 제공합니다. 하지만, 다이제스트 인증은 사용자의 자격 증명이 네트워크를 통해 보내진다는 점에서 보안이 향상된 것이라고 할 수 있습니다. 다이제스트 인증은 메시지 다이제스트라는 MD5 해시로 네트워크를 통해 자격 증명을 전송합니다. 이 MD5 해시에서는 원래 사용자 이름과 암호를 해시로부터 해독할 수 없습니다. 다이제스트 인증은 WebDAV(Web Distributed Authoring and Versioning) 디렉터리에서 사용할 수 있습니다.

클라이언트 소프트웨어를 추가로 설치할 필요는 없지만, 다이제스트 인증은 W3C(World Wide Web Consortium) 웹 사이트에 있는 RFC 2617 지정에서 정의된 HTTP 1.1 프로토콜에 의존합니다. 다이제스트 인증은 HTTP 1.1 사용권이 필요하므로 모든 브라우저가 다이제스트 인증을 지원하는 것은 아닙니다. HTTP 1.1이 지원되는 않는 브라우저가 다이제스트 인증을 사용하여 서버에 파일을 요청하면 서버는 클라이언트에게 다이제스트 자격 증명을 요구합니다. 다이제스트는 클라이언트에 의해 지원되지 않으므로 HTTP 1.1을 사용하지 않는 클라이언트는 요청을 거부합니다.

다이제스트에 대한 요구 사항

IIS 서버에서 다이제스트 인증을 사용하기 전에 다음의 최소 요구 사항을 만족시키는지 확인하십시오. 도메인 관리자만이 도메인 컨트롤러(DC) 요구 사항을 만족시키는지 확인할 수 있습니다. 사용자의 DC가 다음 요구 사항을 만족시키는지 확인하려면 도메인 관리자에게 문의하십시오.

클라이언트 인증 프로세스

다음 단계에서는 다이제스트 인증을 사용하여 클라이언트가 인증되는 방법에 대해 개략적으로 설명합니다. 다이제스트 인증 클라이언트 인증

  1. 클라이언트는 IIS 서버로부터 파일을 요청합니다.
  2. IIS는 요청을 거부하고 클라이언트에 다음과 같은 정보를 보냅니다.
  3. Internet Explorer는 사용자에게 자격 증명(사용자 이름과 암호)을 입력하라는 메시지를 표시합니다. 그러면 Internet Explorer는 이 자격 증명을 MD5 해시를 만드는 영역 이름과 결합시키고, MD5 해시를 보냄으로써 IIS 서버로 파일 요청을 재전송합니다.
  4. IIS 서버는 클라이언트의 해시를 받고 이것을 확인하기 위해 도메인 컨트롤러에 보냅니다.
  5. 도메인 컨트롤러는 IIS 서버에 인증 결과를 알립니다.
  6. 클라이언트가 인증되면 IIS는 요청한 문서나 데이터를 클라이언트에 보냅니다.

중요   다이제스트 인증은 DC가 Active Directory에 저장된 요청한 사용자의 암호에 대한 일반 문서 복사본을 가지고 있는 경우에만 완료됩니다. DC는 암호의 일반 문서 복사본을 저장하므로 Active Directory는 물리적인 충격과 네트워크 공격으로부터 보안되어야 합니다.

고급 다이제스트 인증

고급 다이제스트 인증은 사용자 자격 증명이 도메인 컨트롤러(DC)에 저장된다는 것 외에는 다이제스트 인증과 똑같습니다. 고급 다이제스트는 MD5 해시로 네트워크를 통해 사용자 자격 증명을 보내므로 다이제스트 인증보다 보안이 향상된 것입니다. 또한 고급 다이제스트는 메시지 다이제스트인 MD5 해시로 DC의 Active Directory에 사용자 자격 증명을 저장합니다. 자격 증명이 Active Directory에 MD5 해시로 저장되기 때문에 사용자 암호는 DC를 액세스하는 사용자에 의해 제대로 발견되지 않습니다. 고급 다이제스트 인증은 WebDAV(Web Distributed Authoring and Versioning) 디렉터리에 사용할 수 있고 다이제스트 인증을 대체하지는 않습니다.

고급 다이제스트 인증은 클라이언트 소프트웨어를 추가로 설치할 필요는 없지만, W3C(World Wide Web Consortium) 웹 사이트에 있는 RFC 2617 지정에서 정의된 HTTP 1.1 프로토콜에 의존합니다. 고급 다이제스트 인증은 HTTP 1.1 사용권이 필요하므로 모든 브라우저가 고급 다이제스트 인증을 지원하는 것은 아닙니다. HTTP 1.1을 지원하지 않는 브라우저가 다이제스트 인증을 사용하여 서버에 파일을 요청하면, 서버는 클라이언트에게 다이제스트 자격 증명을 제공하도록 요청합니다. 다이제스트 인증은 클라이언트에서 지원되지 않으므로 HTTP 1.1을 사용하지 않는 클라이언트는 요청을 거부합니다.

고급 다이제스트 요구 사항

IIS 서버에서 고급 다이제스트 인증을 사용하기 전에 다음의 모든 최소 요구 사항을 만족시키는지 확인하십시오. 도메인 관리자만이 도메인 컨트롤러(DC) 요구 사항을 만족시키는지 확인할 수 있습니다. 사용자의 DC가 다음 요구 사항을 만족시키는지 확인하려면 도메인 관리자에게 문의하십시오

중요   DC와 IIS 서버 모두 Windows XP를 실행하고 있을 경우에만 고급 다이제스트 인증을 사용할 수 있습니다. DC나 IIS 서버 중 하나가 Windows 2000 또는 이전 버전이면, IIS는 다이제스트 인증을 기본값으로 하며 이 작업에 대해서는 사용자에게 경고하지 않습니다.

클라이언트 인증 프로세스

다음 단계에서는 고급 다이제스트 인증을 사용하여 클라이언트가 인증되는 방법에 대해 개략적으로 설명합니다.

다이제스트 인증 클라이언트 인증

  1. 클라이언트는 IIS 서버에 파일을 요청합니다.
  2. IIS 서버는 초기 요청을 거부하고 클라이언트에게 다음 정보를 보냅니다.
  3. Internet Explorer는 사용자에게 자격 증명(사용자 이름과 암호)을 입력하라는 메시지를 표시합니다. 그러면 Internet Explorer는 이 자격 증명을 MD5 해시를 만드는 영역 이름과 결합시키고, 이번에도 HTTP 요청 헤더에 있는 MD5 해시를 보냄으로써 IIS 서버로 파일 요청을 재전송합니다.
  4. IIS 서버는 클라이언트의 해시를 받고 이것을 확인하기 위해 도메인 컨트롤러에 보냅니다.
  5. 도메인 컨트롤러는 Active Directory에 저장된 복사본과 클라이언트의 해시를 비교합니다. 해시 값이 일치하면 도메인 컨트롤러는 IIS 서버에 클라이언트가 인증되었음을 알립니다.
  6. IIS 서버는 클라이언트에게 요청한 파일을 보냅니다.

참고   단계 2에서 IIS는 고급 다이제스트 인증이 아닌, 다이제스트 인증을 사용하는 클라이언트(Internet Explorer)에게 알립니다. 왜냐하면, 다이제스트 인증과 고급 다이제스트 인증 모두에 대해 IIS 서버와 클라이언트 사이에는 다이제스트 알고리즘이 사용되기 때문입니다.

Windows 통합 인증

NTLM 또는 Windows NT Challenge/Response 인증이라고 했던 Windows 통합 인증은 사용자 이름과 암호를 해시하여 네트워크상에 보내는 것이므로 보안 형태의 인증입니다. Windows 통합 인증을 사용할 경우 사용자의 브라우저는 웹 서버와의 암호화된 교환을 통해 자신이 암호를 알고 있음을 증명합니다.

Windows 통합 인증은 Kerberos v5 인증과 NTLM 인증을 사용합니다. Active Directory Services가 Windows 2000 이후 버전 도메인 컨트롤러에 설치되어 있고 사용자 브라우저가 Kerberos v5 인증 프로토콜을 지원하는 경우, Kerberos v5 인증이 사용되고 그렇지 않으면 NTLM 인증이 사용됩니다.

Kerberos v5 인증 프로토콜은 Windows 2000 Distributed Services 아키텍처의 기능입니다. Kerberos v5 인증이 성공하려면, 클라이언트와 서버가 KDC(Key Distribution Center)에 연결되어 있고 디렉터리 서비스와 호환할 수 있어야 합니다. Kerberos와 NTLM에 대한 자세한 내용은 Windows XP 온라인 설명서를 참조하십시오.

Windows 통합 인증 프로세스

다음 단계에서는 Windows 통합 인증을 사용하여 클라이언트가 인증되는 방법에 대해 개략적으로 설명합니다.
  1. 기본 인증과 달리, Windows 통합 인증은 처음에 사용자 이름과 암호를 입력하라는 메시지가 나타나지 않습니다. 클라이언트 컴퓨터에 대한 현재 Windows 사용자 정보는 Windows 통합 인증용으로 사용됩니다.
  2. 참고   Internet Explorer 버전 4.0 이상에서는 필요한 경우 사용자 정보를 입력하라는 메시지를 처음에 표시하도록 구성할 수 있습니다. 자세한 내용은 Windows 설명서를 참조하십시오.

  3. 그러나 인증 교환이 초기에 사용자를 식별하지 못하면 브라우저에 Windows 사용자 계정 사용자 이름과 암호를 입력하라는 메시지가 나타나고 Windows 통합 인증을 사용하여 이 사용자 이름과 암호를 처리합니다.
  4. Internet Explorer는 사용자가 올바른 사용자 이름과 암호를 입력하거나 프롬프트 대화 상자를 닫을 때까지 계속 사용자에게 메시지를 나타냅니다.

Windows 통합 인증은 안전하긴 하지만 두 가지 제한 사항이 있습니다.

  1. Microsoft Internet Explorer 2.0 이상 버전만 이 인증 방법을 지원합니다.
  2. Windows 통합 인증은 HTTP 프록시 연결 상에서 작동하지 않습니다.

따라서 Windows 통합 인증은 인트라넷 환경에서 유용합니다. 인트라넷 환경에서는 사용자와 웹 서버 컴퓨터가 모두 같은 도메인에 있으며 관리자는 모든 사용자에게 Microsoft Internet Explorer 2.0 이상의 버전이 있음을 확인할 수 있습니다.

인증서 인증

두 가지 유형의 인증에 대해 웹 서버의 SSL(Secure Sockets Layer) 보안 기능을 사용할 수 있습니다. 첫째 서버 인증서를 사용하면 신용 카드 번호 같은 개인 정보를 전송하기 전에 사용자에게 사용자 웹 사이트를 인증하도록 할 수 있습니다. 둘째 클라이언트 인증서를 사용하여 웹 사이트에 대해 사용자가 요청한 정보를 인증할 수도 있습니다. SSL은 로그온 과정 동안 사용자의 웹 브라우저에 전송된 암호화된 디지털 ID의 내용을 확인하여 인증합니다. (사용자는 상호 신뢰할 수 있는 제 3사 조직에서 클라이언트 인증서를 얻습니다. ) 서버 인증서에는 대개 사용자 회사와 인증서를 발행한 조직에 대한 정보가 포함되어 있습니다. 클라이언트 인증서에는 대개 사용자와 인증서를 발행한 조직에 대한 식별 정보가 포함되어 있습니다. 자세한 내용은 인증서 정보를 참조하십시오.

클라이언트 인증서 매핑

파일 등의 리소스에 액세스할 때 Windows 사용자 계정이 필요하므로, 웹 서버상의 Windows 사용자 계정에 클라이언트 인증서를 연결하거나 매핑할 수 있습니다. 인증서 매핑을 만들어서 사용할 수 있게 되면, 사용자가 클라이언트 인증서를 갖고 로그온할 때마다 웹 서버는 사용자를 해당 Windows 사용자 계정에 자동으로 연결시킵니다. 이런 방식으로 기본 인증, 다이제스트 인증 또는 Windows 통합 인증 사용을 요구하지 않고 클라이언트 인증서로 로그온하는 사용자를 자동으로 인증할 수 있습니다. 또한 하나의 Windows 사용자 계정에 하나의 클라이언트 인증서를 매핑하거나 하나의 계정에 많은 클라이언트 인증서를 매핑할 수 있습니다. 예를 들어, 서버에 여러 다른 부서 또는 기업이 있고 또한 이 부서와 기업들이 각자의 웹 사이트를 가지는 경우, 다대일 매핑을 사용하여 자신의 웹 사이트에 각 부서나 회사의 모든 클라이언트 인증서를 매핑할 수 있습니다. 이런 방식으로 각 사이트는 자신의 클라이언트에게만 액세스를 제공하게 됩니다. 자세한 내용은 사용자 계정에 클라이언트 인증서 매핑을 참조하십시오.

FTP 인증

익명 FTP 인증

FTP 서버를 구성하여 FTP 리소스에 익명 액세스를 허용할 수 있습니다. 리소스에 대해 익명 인증을 선택하면, 그 리소스에 대한 모든 요청은 사용자에게 사용자 이름이나 암호를 요구하지 않고 받아들여집니다. 이것은 IIS가 IUSR_computername이라는 Windows 사용자 계정을 자동으로 만들기 때문에 가능한 일입니다. 여기서 computername은 IIS가 실행되는 서버의 이름입니다. 익명 FTP 인증은 웹 기반의 익명 인증과 매우 유사합니다. 익명 FTP 인증을 사용하는 경우, IIS는 기본 FTP 인증이 사용 가능 상태이더라도 우선적으로 익명 FTP 인증을 사용할 것입니다. 자세한 내용은 익명 인증을 참조하십시오.

기본 FTP 인증

기본 FTP 인증을 사용하여 사용자 웹 서버에 FTP 연결을 하려면, 올바른 Windows 사용자 계정에 맞는 사용자 이름과 암호로 로그온해야 합니다. FTP 서버는 사용자의 ID를 확인할 수 없으면 오류 메시지를 반환합니다. FTP 인증은 사용자가 네트워크를 통해 암호화되지 않은 형태의 암호와 사용자 이름을 전송하므로 보안이 되지 않습니다. 자세한 내용은 액세스 제어 정보를 참조하십시오.


© 1997-2001 Microsoft Corporation. All rights reserved.