요약 ASP.NET 과 IIS, 이 두가지 조건이라면, 보안 웹 사이트를 쉽게 만들 수 있습니다. 하지만, 그 두가지 특성과 서로간의 관계를 정확히 파악하고 있어야 제대로 된 보안 웹 사이트를 만들 수 있습니다. 2회 연재 중에서, 이번 기사에는 우선 ASP.NET 의 관점에서 본 웹 사이트 보안에 대한 기본적인 설명과 함께, 윈도우 인증 / ACL 권한 부여를 다루는 실제적인 예를 보여드립니다. 또한 기본 인증, 다이제스트 인증, 역할 기반 보안 에 관한 것도 함께 논의되어 집니다.
개발자들은 웹 사이트 보안의 중요성을 충분히 인지하고 있습니다. 또한 개발 초기 단계에서부터 보안에 대한 고려를 해야 한다는 것을 잘 알고 있지만, 그러한 생각과는 다르게 실제로 보안이 적용되는 시기는, 개발 단계에서 더 이상 미룰 수 없는 시기가 되어서야 어쩔 수 없이 하게 되어집니다. 아마도, 이런 양상은 세금을 낼 때와 비슷하지 않을까 생각해 봅니다. 한가지 차이점이라면, 세금과는 달리 보안이 허술한 응용 프로그램을 만들었다고 해서 감옥에 가지 않는 다는 점이지만, 그 중요도는 세금을 내는 일 못지 않습니다. 특히 웹 응용 프로그램을 포함해서 대부분의 응용 프로그램에 대해 보안은, 더 이상 선택이 아닌 필수입니다. 네트워크 응용 프로그램의 특성상, 해당 응용 프로그램을 대다수의 사용자들이 접근한다는 점에서 보안은 가장 우선시 되어야 할 고려 사항입니다. 더군다나, 해당 응용 프로그램이 인터넷을 통해서 배포되는 경우에는 전세계의 인터넷 사용자들이 그 대상이 되므로 보안이 더욱 절실해 질 수 밖에 없습니다. 웹에 대한 보안을 한다는 것은 광범위하면서도 상당히 복잡한 주제이며, 최근 들어 웹 서버를 안전하게 만드는 것과 관계된 연구들이 많이 진행되고 있는 실정입니다. Microsoft가 내놓은 IIS 역시 많은 보안 결함을 가지고 있었으며 그에 따른 업데이트도 나와 있습니다. 이번 글의 주제는 버퍼 오버런이나 그 외의 결함에 대한 공격으로부터 웹 서버를 보호하는 방법을 설명하기 보다는, ASP.NET으로 만든 페이지를 권한이 있는 사용자에 대해서만 서비스를 하도록 하는 방법을 주로 다루도록 하겠습니다. ASP.NET으로 개발된 웹 사이트들은 크게 아래의 3가지 경우로 나뉠 수 있습니다.
모든 사용자들이 자유롭게 이용할 수 있는 사이트
사용자 인증이 필요하다는 점을 제외하고는 역시 모든 사용자들이 이용할 수 있는 사이트. 예를 들어 eBay같은 경매 사이트가 그 좋은 예일 텐데, 누구나 eBay 웹 사이트를 방문할 수 있고 진행되는 경매를 열람까지 가능하지만, 경매에 입찰하기 위해서는 사용자의 계정과 암호가 필요하게 됩니다. 해당 사용자 계정으로 입찰한 경매만을 열람할 수 있는 "My eBay" 메뉴역시 제공해 주고 있습니다. "My eBay" 페이지는 최대 입찰가와 같은 해당 사용자만 알아야 하는 정보들을 포함하고 있기 때문에 당연히 그러한 정보를 열람하기 위해서는 사용자 인증을 거치게 됩니다.
제한된 사용자들을 대상으로 하는 인트라넷 사이트. 여기에서 제한된 사용자란, 예를 들어 회사 내부의 사원들을 생각해 볼 수 있습니다. 때로는 외부 인터넷으로부터의 접근을 허용할 수도 있는데, 그런 경우에는 정상적인 계정과 암호를 알고 있는 사용자라면 인터넷에 접속 가능한 어떠한 환경에서도 사내 정보를 접근할 수 있습니다.
우선 첫 번째 사이트의 경우에는 특별히 보호할 것이 없기 때문에 제외하고, 두 번째 와 세 번째 유형의 사이트만을 살펴보겠습니다. 두 가지 모두 응용 프로그램 수준에서, 접근하려는 사용자가 적절한 인증 정보를 가지고 있는지를 알아 낼 수 있는 폼이 필요합니다. ASP.NET에서는 응용 프로그램 수준의 보안 장치를 제공해주고 있는 데, IIS와 윈도우 운영체제의 보안 시스템과 맞물리게 되면 더욱 안정적인 보안 웹 사이트를 구현하는 것이 가능하고, 최대한 쉽게 보안 웹사이트를 배포할 수 있습니다. 2부에 걸쳐서 연재가 되어질 텐데, 우선 이번 호에서는 ASP.NET과 관련한 보안 웹사이트 구현을 다루고, 이를 통해 여러분들은 어떻게 ASP.NE이 IIS/윈도우 운영체제와 연동이 되는지에 대한 방법, 파일 제어 목록에 기반한 권한 부여, 윈도우 인증을 사용하여 리소스를 보호하는 방법을 배우게 될 것입니다. 다음 2부에서는, ASP.NET에서 자랑할 만한 기능중의 하나인 폼인증에 대해서 알아봅니다. 말 그대로, 폼 인증이란 윈도우 운영체제와 결합된 인증이 아닌, 기존 웹 사이트에서 사용하던 폼에 기반을 둔 인증방식으로, 이를 이용해 쉽고 간편하게 보안 웹 사이트를 개발할 수 있는 기능을 제공합니다.
웹 보안에 대한 이해 응용 프로그램에서, 허가 받지 않은 사용자로 하여금 보안이 필요한 페이지를 방문하지 못하도록 하는 보안 설정은 가장 중요한 요소임에 틀림 없습니다. 예를 들어, 관리자의 직위에 있지 않은 사용자가 월급 및 업무 능력 평가에 관한 자료를 열람하지 못하도록 하는 작업이나, eBay 예를 든 것처럼 아무 사용자나 "My eBay" 페이지를 방문하지 못하도록 하는 작업이 이에 포함됩니다. 좀 더 세부적으로 들어가 본다면, 요청을 한 사용자에 맞는 데이터를 보여주기 위해서는 그 요청에 대한 사용자를 인식해야 할 필요가 있는 것입니다. 이를 위해, 해당 응용 프로그램에서 정확히 2가지의 기능을 구현해 주어야 합니다 즉, 요청을 보낸 사용자의 신원을 식별할 수 있어야 하며, 해당 페이지를 접근할 수 있는 규칙을 만들어 두어, 그 요청을 보낸 사용자가 그 규칙의 범위에 있는지를 판단하는 것입니다. 웹 서버에서는 인증이라는 방법을 통해 사용자 신원을 식별하게 됩니다. 일단, 인증 단계를 거쳐 사용자의 신원이 확인이 되면, 권한 부여 단계를 통해 해당 사용자가 요청했던 그 페이지를 볼 수 있는 권한이 있는지를 판단하게 됩니다. ASP.NET에서는 다양한 유형의 인증과 권한부여 방법을 제공해 주고 있습니다. 각각의 설정에 대해서 숙지하고 어떤 경우에 활용될 수 있는지를 파악하는 것이 웹 사이트를 안전하게 설계하는 첫째 요건입니다.
인증 인증은, 요청을 받는 측에서 호출자의 신원을 확인하는 것입니다. 호출자는 "Bob" 이라는 사용자라고 우길 수는 있지만, 호출자로 하여금 인증을 거치지 않는 한 그가 실제로 "Bob" 이라는 것을 단정지을 수 있는 아무런 근거가 없습니다. ASP.NET은 윈도우 인증, 패스포트 인증, 폼 인증까지 해서 3가지 유형의 인증을 지원합니다. 윈도우 인증을 선택한 경우, ASP.NET은 IIS의 도움을 받게 됩니다. IIS는 사용자 인증을 위한 복잡한 작업을 대신해 주고, 호출자의 신원을 ASP.NET에 넘겨줍니다. 간단한 시나리오를 예로 들어 설명해 보자면, "Bob"이란 사용자가 ASPX 파일을 요청하게 되는 경우, IIS는 Bob이란 사용자를 인증하고, 요청을 ASP.NET으로 전달하면서 Bob 사용자에 대한 액세스 토큰을 함께 넘겨 줍니다. ASP.NET은 그 토큰을 이용해서 Bob 사용자가 해당 ASPX 파일에 대해서 접근 권한이 있는지를 확인합니다. ASP.NET은 또한 그 요청을 처리하는 작업자 프로세스 측에서 Bob이란 신원으로 가장 할 수 있도록 토큰을 넘겨주게 됩니다. 왜냐 하면, 해당 요청은 Bob이 발생시켰으므로 그 요청에 대한 처리를 하는 코드들은 Bob이란 사용자의 신원으로 실행될 수 있도록 해주어야 하기 때문입니다. 윈도우 인증이 쓰이는 전형적인 웹 사이트의 응용 예는 다음과 같습니다.
응용 프로그램이 회사 인트라넷에 배포되는 경우, 모든 사용자들이 네트워크 자원에 대한 접근과 로그인이 가능한 계정을 가지고 있어야 합니다.
응용 프로그램이 주로 회사 인트라넷에서만 사용되는 한편, 방화벽 너머의 원격에서도 접근할 수 있도록 하고 싶은 경우.
윈도우 인증은 들어오는 요청에 대해 웹 서버 또는 해당 웹 서버의 도메인 사용자 계정으로 연결시켜 주는 기능을 가집니다. 즉, 윈도우 운영체제 차원에서 제공하는 보안 시스템을 그대로 웹 사이트의 보안에 적용하므로, 정상적인 윈도우 로그인 계정이 없는 사용자에 대해 접근을 허용하지 못하게 함은 물론이고, 웹 사이트에 접근이 허가된 사용자일지라도 접근하려는 리소스에 대해 적절한 권한이 없다면 이용이 불가능합니다. 패스포트 인증은 마이크로소프트 패스포트 서비스에 사용자 인증을 맡기는 것입니다. 패스포트 서비스는 웹 서비스로 구현되어 있으며, 사용자 계정과 암호는 마이크로소프트에 의해서 관리됩니다. 마이크로소프트 패스포트 서비스에 등록된 사용자는 패스포트 인증을 지원하는 모든 웹 사이트에 대해서 동일한 자격증명으로 인증됩니다. 제공된 자격증명이 올바르다고 판단되면, 쿠키에 인코드할 수 있는 인증 티켓을 반환합니다. 패스포트 인증에 대해 보다 자세한 내용을 원하면 마이크로소프트 웹 사이트에서 다운로드 할 수 있는 Passport SDK를 참조하십시오.
표 1폼 인증
마지막으로, 폼 인증은 사용자 인증을 웹 페이지 내부의 코드에서 직접 작성할 수 있도록 하는 것입니다. 표 1은 eBay에서 사용중인 폼 인증의 한 예를 보여주고 있습니다. eBay 사이트에 있는 대부분의 웹 페이지는 로그인 절차를 거치지 않고도 방문이 가능합니다. 하지만, 입찰을 한다거나 "My eBay" 페이지를 보려고 하면 반드시 사용자 계정과 암호를 입력해서 자신에 대한 인증 단계를 거쳐야만 가능합니다. 윈도우 인증 방식은 eBay의 사례에서는 적합한 응용이라고 볼 수는 없습니다. 왜냐 하면 eBay 웹 사이트를 방문하는 사용자들은 전 세계에서도 수백만 사용자일 수 있을 텐데 그들 각각에 대한 사용자 계정을 윈도우 서버에 등록시켜 두고 싶지는 않을 것이기 때문입니다. 반면 폼 인증은 윈도우 계정이 없이도 사용자 인증을 할 수 있으므로 eBay와 같은 사이트에서 활용하기에 적합합니다. 즉, 일반인을 대상으로 하면서도, 특정 페이지에 대해서 인증을 요구해야 하는 목적의 웹 사이트로서는 폼 인증이야 말로 최적의 선택입니다. 사실, 폼 인증은 웹의 역사만큼이나 오래된 방식이지만 이전의 ASP에서는 그에 대한 기술적인 지원이 전혀 없었습니다. 기사의 후반부를 통해서 살펴보겠지만, ASP.NET은 폼 인증을 지원함으로써 개발자들로 하여금 코드를 최소한으로 구현할 수 있도록 해줍니다. 어떤 인증 유형을 사용할 지에 대해서는 web.config을 통해서 ASP.NET 에 알려주게 됩니다. 다음은 폼 인증을 사용하는 응용 프로그램의 web.config 파일 예입니다. <configuration> <system.web> <authentication mode="Forms" /> </system.web> </configuration>그 외 "mode" 속성에 넣을 수 있는 값은 "None", "Windows", "Passport"가 있습니다. 기본값은 machine.config에 지정되어 있는 "Windows"입니다. 인증 모드를 설정하면 해당 응용 프로그램 범위에서 유효하며, 그 응용 프로그램이 위치한 하위의 폴더에서 별도로 생성한 web.config에서는 변경할 수 없습니다. 따라서, 하나의 응용 프로그램에 대해 윈도우 인증과 폼인증 방식을 모두 사용할 수는 없습니다.
권한 부여 웹 사이트뿐만 아니라 일반적인 네트워크 보안에 있어 인증은 매우 중요한 요소입니다. 왜냐 하면 상대방이 누구인지도 모르는 데 신뢰를 할 수는 없기 때문입니다. 권한 부여는 보안에 있어서 인증 만큼이나 중요한 요소입니다. 일단, 상대방이 누구인지 파악이 되었다면 해당 네트워크 자원에 대해 접근이 허용되었는지를 판단합니다. 일례로 회사의 인트라넷 같은 경우, 일반사원으로 하여금 급여 데이터를 접근할 수 없도록 처리하고 싶은 경우일 텐데, 바로 그것이, "권한 부여"에 해당하는 기능입니다. ASP.NET은 ACL 권한 부여 (파일 권한 부여라고도 알려져 있습니다.)와 URL 권한 부여라는 2가지 방식을 지원합니다. ACL (액세스 제어 목록: Access Control List) 권한 부여는 파일 시스템 기반으로 동작합니다. IIS와 ASP.NET을 채택한 대부분의 웹 서버는 NTFS 파일 시스템을 사용하고 있습니다. NTFS는 ACL을 이용해서 파일 시스템 자원, 즉 파일과 디렉토리를 보호합니다. 운영체제 차원에서 ACL이 지원되기 때문에, 관리자만이 읽을 수 있는 파일 권한을 설정하는 등의 작업이 쉽게 구현이 가능합니다. 단지, 해당 파일의 속성창을 띄우고 "보안" 탭을 클릭한 후, 보여지게 되는 보안 구성 단위 (사용자와 그룹)를 모두 제거하고, 관리자만을 추가해 주면 됩니다. 마찬가지로, "Bob"이란 사용자에 대해 특정 ASPX 파일을 볼 수 없도록 하고 싶다면, 해당 파일의 ACL에서 "Bob"의 읽기 권한을 "거부"하도록 설정하면 됩니다. 이후로는 Bob이 그 파일을 보려 하면 접근이 차단되었다는 오류메시지가 나타납니다. ACL 확인은 윈도우 보안 기본 요소인 액세스 토큰(Access Token)에 대해서 수행되기 때문에 ACL 권한 부여를 사용하기 위해서는 인증 방식이 "Windows"인 경우에만 사용될 수 있습니다. URL 권한 부여는 작동 방식이 다소 다릅니다. 그와 관련된 설정은 Web.config 파일 안에서 이루어집니다. URL 권한 부여는 ASP.NET 자체에서 구현된 것이므로 웹 서버가 반드시 IIS라는 것에 의존하지 않습니다. 대개의 경우 폼 인증과 사용되는 것을 볼 수 있지만 다른 인증 방식과도 같이 사용될 수 있습니다.
IIS 보안 IIS가 웹 서버라는 점을 상기시켜 보면, 기본적인 용도는 사실 원격지 클라이언트로부터의 연결을 받아들이고 그 연결을 통해 들어오는 HTTP 요청을 처리하여, 그 결과를 응답으로 보내주는 것이라고 요약해 볼 수 있습니다. 대부분은 GET과 POST 방식의 HTTP 요청이며 HTML 파일, JPEG 파일, ASPX 파일 이나 그 외의 파일을 요청합니다. 여기서 간과할 수 없는 것은, 웹 서버에 있는 모든 파일에 대해서 사용자가 접근 할 수 있도록 해서는 안 된다는 것입니다. IIS는 서버의 자원을 다음과 같은 4가지 방법으로 보호하고 있습니다.
웹 응용 프로그램은 URL로 지정 가능한 웹 서버 상의 가상 디렉토리에 배포되어야 합니다. 원격 클라이언트는 가상 디렉토리와 그 하위의 디렉토리를 제외하고는 다른 어떠한 파일도 임의로 접근할 수 없습니다.
IIS는 모든 요청에 대해서 요청이 처리되는 동안 접근하게 될 자원들에 대한 권한이 부여되었는지를 확인하기 위해 액세스 토큰을 할당합니다. 요청을 발생한 사용자가 "Bob"이고 "Hello.html" 파일에 대한 읽기 권한이 없는 경우, "Hello.html" 파일을 접근하려는 모든 요청은 실패하게 됩니다. 또한, IIS는 Bob에 대한 액세스 토큰을 ASP.NET에서 사용 가능하게 해주어, ASP.NET 내부의 코드에서도 권한 부여에 대한 확인작업이 수행되도록 해줍니다.
IIS는 IP 주소와 도메인 명에 대한 제한을 지원하는데, 요청을 보내는 클라이언트 측 IP 주소 또는 도메인에 기반해서 접근을 허가 또는 거부할 수 있습니다.
IIS는 보안 소켓 레이어 ( SSL: Secure Sockets Layer ) 표준의 암호화된 HTTP 연결, 즉 HTTPS를 지원합니다. SSL 그 자체는 서버상의 자원을 보호하는 목적으로 사용할 수는 없지만, 웹 서버와 원격지 클라이언트 사이에서의 오고 가는 내용을 도청하지 못하도록 해 줍니다.
위의 4가지 항목 모두 ASP.NET 프로그래머가 반드시 숙지를 해야 합니다. 그 중에서 2번째 항목이 가진 장점을 좀더 살펴보면, ACL 확인 작업은 전적으로 요청을 보낸 사용자의 신원에 의존합니다. 따라서 윈도우 인증을 사용함으로써, ASP.NET은 사용자 신원과 관계된 처리를 IIS 와 좀더 밀접하게 연동할 수 있습니다. IIS는 Inetinfo.exe라는 이름의 프로세스로 실행됩니다. Inetinfo.exe는 윈도우 운영체제에 내장되어 있는 (변경하지 않았다면)"SYSTEM" 계정으로 동작되고 있습니다. SYSTEM 계정은 호스트 컴퓨터에 대해서는 최고의 권한을 가집니다. 그러나, IIS에 의해서 ASP.NET으로 전달된 요청은 SYSTEM 계정 문맥으로 실행되지 않고 요청을 발생시켰던 해당 사용자의 신원으로 적용됩니다. 관리 도구 메뉴의 "인터넷 정보 서비스(IIS) 관리" 툴을 이용해서, 각각의 파일과 디렉토리에 대해서 "인증 및 액세스 제어"를 설정하게 됩니다. 주어진 파일 또는 디렉토리에 대해서 "익명 액세스", "인증된 액세스", 또는 그 두 가지 유형 전부 가능합니다. 익명 액세스가 가능하도록 설정된 파일에 대한 요청이 왔다고 가정해 보면, 기본적으로 해당 요청은 "IUSR_machinename" 사용자 계정 (여기서 "machinename"은 해당 웹 서버의 컴퓨터 명입니다.)으로 실행됩니다. "IUSR_machinename "은 IIS 가 설치될 때 같이 생성되는 특수한 계정입니다. "인터넷 정보 서비스(IIS) 관리" 툴을 이용해서 익명으로 접근의 사용자 신원을 다른 사용자 계정으로 바꿀 수도 있지만, 여기서는 여러분이 그 값을 바꾸지 않았다고 가정합니다. 그렇게 기본값인 "IUSR_machinename "이 지정된 경우, 모든 익명요청에 대해서 "IUSR_machinename " 계정의 액세스 토큰이 따라붙게 됩니다. 우리가 그 동안 웹 서버를 통해서 서비스를 했던 모든 파일이나 폴더는 실제로 "IUSR_machinename" 계정에 대해 읽기 권한이 "거부"로 설정되어 있지 않았다는 것을 미뤄 짐작 할 수 있습니다. 반면에, 인증을 받은 사용자가 특정 파일에 대해 요청을 보낸 경우, IIS는 바로 그 요청에 대해 인증 받은 사용자의 액세스 토큰을 할당하게 됩니다. 요청을 보낸 사용자가 Bob이고 IIS에 의해서 확인이 되었다면, 해당 요청에 대해서 Bob 계정의 액세스 토큰이 따라 붙도록 합니다. 하지만, 어떻게 해서 IIS는 요청자의 신원을 알 수 있습니까? 어떻게 요청을 보내 온 사람이 실제 Bob이란 것을 알 수 있냐는 것에 대해 궁금할 수 있습니다. 그것은 사용되는 인증 유형에 따라서 확인 방법이 달라집니다. IIS는 "기본 인증", "다이제스트 인증", "윈도우 통합 인증", "클라이언트 인증서 매핑 사용"까지 총 4가지 유형의 인증을 지원합니다. ASP.NET의 입장에서는 이러한 4가지 방법 모두 "윈도우 인증" 방식으로 분류됩니다. 기본 인증과 다이제스트 인증은 사용자 계정과 암호에 기반합니다. 클라이언트가 브라우저인 경우라면, 해당 브라우저는 서버에 전달해야 할 사용자 계정과 암호를 묻는 과정을 거치며, HTTP 프로토콜을 따르기 때문에 인터넷 상에서도 잘 동작합니다. 윈도우 통합인증은 윈도우만의 로그온 자격 증명을 통해 사용자를 인증합니다. 일반적인 인터넷 환경에서 사용하기에는 부적절한 방법으로, 클라이언트와 서버 측 모두 윈도우 보안 프로토콜을 지원해야 하는 데다 클라이언트가 도메인 컨트롤러에 접근해야 하므로 방화벽이 존재하는 경우에는 접근 포트가 막히기 때문에 더욱 활용도가 떨어집니다. SSL 클라이언트 인증서를 통한 방식 역시 디지털 인증서를 준비해 둬야 한다는 선행 조건으로 인해 그 활용을 인트라넷으로 제한하는 것이 보통입니다.
ASP.NET 보안 표 2는 IIS와 ASP.NET의 관계를 보여주고 있습니다. IIS는 ASP.NET 측에서 처리하도록 등록된 파일에 대한 요청을 수신하게 되면 (예를 들어, aspx 파일), Aspnet_isapi.dll이라는 ISAPI DLL에게 넘겨줍니다. Aspnet_isapi.dll은 IIS 프로세스 ( Inetinfo.exe ) 내에 로드 되어 실행됩니다. ASP.NET 응용 프로그램은 별도의 Aspnet_wp.exe라는 프로세스에서 실행됩니다. Aspnet_isapi.dll은 넘겨받은 요청을 명명된 파이프 (Named Pipe)를 사용해서 Aspnet_wp.exe 프로세스에 전달합니다. ASP.NET 작업자 프로세스로 요청이 도착되면, 또 다시 작업자 프로세스 내에서 그 요청과 관계된 AppDomain으로 전달됩니다. AppDomain 내부에서는 ASP.NET이 구현하는 HTTP 파이프라인을 통해서, HTTP 모듈들과 HTTP 처리기 등이 담당하는 각 단계별로 요청에 대한 처리가 이루어지기 시작합니다. 파일 확장자에 따른 HTTP 처리기에 대한 기본적인 설정들은 Machine.config에 있습니다.
표 2IIS와 ASP.NET의 관계도
IIS 6.0으로 오면서, 표 2의 구조에 변경이 가해졌습니다. Windows 2003 서버에 포함된 IIS 6.0 은 보다 더 강화된 보안 모델을 기반으로 IIS로 하여금 Aspnet_wp.exe와 유사한 대리자 프로세스에 응용 프로그램들을 격리시켜서 관리할 수 있도록 했습니다. 따라서 IIS 6.0부터는 Aspnet_wp.exe 프로세스를 작업 관리자에서 볼 수 없게 되었고, 대신에 IIS 가 작업자 프로세스를 제공해 줍니다. 또한 IIS 6.0에서는 Inetinfo.exe 와 작업자 프로세스를 명명된 파이프 방식이 아닌 로컬 함수 호출 (LPC : Local Procedures Calls) 방식을 사용해서 연결하도록 변경되었습니다. 이러한 것들이 보안과 어떤 관계를 맺고 있는지를 살펴봐야 할 필요가 있습니다. Aspnet_isapi.dll이 HTTP 요청을 Aspnet_wp.exe로 전달할 때, Aspnet_isapi DLL이 IIS로부터 받은 액세스 토큰 까지도 넘겨주게 됩니다. 넘겨주게 될 그 액세스 토큰은 인증 받은 않은 사용자인 경우에는 "IUSR_machinename " 계정일 것이고, 인증된 사용자의 경우에는 그 사용자의 계정에 대한 토큰이 됩니다. 넘겨받은 요청을 해당 응용 프로그램의 HTTP 파이프라인을 통해 본격적으로 처리를 하기 전에, Aspnet_wp.exe는 다음과 같은 작업을 하게 됩니다.
액세스 토큰을 이용해서 요청 받은 자원에 대한 ACL 권한 확인을 수행합니다. 예를 들어, 액세스 토큰이 Bob 사용자이면서, Bob에 대해 읽기가 거부된 Foo.aspx 파일로 GET 명령이 전달된 경우, ASP.NET은 해당 요청에 대해서 "Access Denied"라는 오류 메시지와 함께 처리를 그만 둡니다. 이러한 ACL 확인 작업은 ASP.NET 설정에서 "Impersonation" 값이 어떻게 설정되었는지에 상관없이 수행됩니다.
응용 프로그램으로 하여금 원하는 경우 호출자의 신원으로 가장할 수 있도록 액세스 토큰을 넘겨주게 됩니다. 이후의 처리는 호출자의 보안 문맥으로 코드들이 수행되고 접근하게 되는 자원의 ACL에 의한 보안 적용을 받게 됩니다.
요청에 대한 처리를 하기 전에 ASP.NET이 ACL 확인 작업을 먼저 한다는 것은, 예를 들어 "Bob" 사용자에게 해당 ASPX 파일을 접근하지 못하게 만들려면 단지 ACL 목록에서 Bob에 대한 읽기 권한을 거부로 설정해주면 된다는 것을 의미합니다. ASP.NET이 호출자의 액세스 토큰을 가장화 할 수 있도록 한다는 사실로 인해 개발자는 해당 요청을 처리하는 자격증명을 선택할 수 있습니다. 올바른 결정은 그 응용 프로그램이 어떤 작업을 할 것인지, 어떻게 그것을 처리하도록 설계되었는지에 따라 달라질 수 있습니다. 기본적으로, Aspnet_wp.exe 프로세스는 ASP.NET이 설치될 때 생성되는 ASPNET 계정으로 실행됩니다. ASPNET은 "Users" 그룹의 멤버이므로 일반적인 응용 프로그램이 수행할 수 있는 대부분의 작업에 대한 권한을 가지고 있지만, 보안에 대한 공격을 받을 수 있는 부분에 대해서는 거의 권한이 없습니다. 별도로 다른 것을 지정하지 않는 한, 들어온 요청에 대해 ASP.NET은 Aspnet_wp.exe 프로세스의 신원을 사용합니다. 즉, ASPNET 계정으로 요청이 처리됩니다. 따라서, HKEY_LOCAL_MACHINE 레지스트리 섹션에 있는 항목을 변경하는 것 같은 몇몇 작업들은 ASP.NET 응용 프로그램에서 수행될 수 없습니다. IIS에 의해서 제공된 액세스 토큰을 사용하기 위해서는 "가장(impersonation)" 이라는 방법이 필요합니다. "가장" 기법을 사용하기 위해서는 Machine.config의 요소를 변경하거나, 웹 응용 프로그램 범위에서 변경하고자 하는 경우에는 가장 상위 Web.config 파일의 하위에 있는 요소 값을 변경해 주면 됩니다. 다음은 그 예입니다. <identity impersonate="true" />만약, IIS 가 들어온 요청에 대해 IUSR_machinename 자격증명을 할당한 경우라면, 상황은 이전과 크게 다르지 않습니다. IUSR_machinename 계정 역시 호스트 컴퓨터에 대해서는 권한이 많이 축소되어 있기 때문입니다. 하지만, 윈도우 인증을 사용하겠다고 지정하고 IIS가 ASP.NET에 실제 호출자의 액세스 토큰을 넘겨주면, 호출자의 자격증명으로 가장해서 작업을 처리하게 됩니다. 마지막 방법으로, Aspnet_wp.exe 프로세스 자체의 자격증명을 ASPNET 계정 이외의 것으로 동작될 수 있도록 설정하는 방법이 남아 있습니다. 여러분이 만약, ASPNET 계정이 가진 권한으로는 불가능한 작업을 하려는 경우, (예를 들어, 레지스트리의 어떠한 영역에서도 자유롭게 쓰기를 원한다면) 다음과 같이 값을 바꿔줌으로써 Aspnet_wp.exe 프로세스 자체의 자격증명을 SYSTEM 계정으로 바꿔 줄 수가 있습니다. <processModel userName="machine" ... />Machine.config에 보면 위와 같은 설정 값이 있는데, 이를 아래와 같이 바꿔줍니다. <processModel userName="SYSTEM" ... />이러한 설정을 통해 응용 프로그램은 호스트 컴퓨터에서 하고자 하는 일을 대부분 할 수 있게 됩니다. 물론, 그에 대한 반작용으로 보안 공격에 대해 좀더 취약해 지게 됩니다. ASP.NET이 베타 버전이었을 때는 Aspnet_wp.exe 프로세스의 실행 권한이 SYSTEM 계정이었지만, 정식버전이 출시되면서 ASPNET 계정으로 바뀐 것입니다. 이러한 설정도 IIS 6.0에서 다소 변경이 되었습니다. 따라서 ASP.NET 의 요청에 대한 처리는 이제 ASPNET 계정이 아닌 "Network Service" 계정으로 대체되었습니다. 만약에, ASPNET 계정 이외의 접근은 거부하도록 설정된 ACL 파일을 가진 응용 프로그램이 있다면, IIS 6.0을 적용시키면서 "Access Denied" 오류가 발생하여 당황스러울지 모릅니다. 물론, 그런 경우 다시 "Network Service" 계정에 대해서 접근 권한을 갖도록 ACL을 조정해 준다면 다시 정상적으로 응용 프로그램이 동작하게 됩니다. 간단히 말하면, ASP.NET 작업자 프로세스에서 실행될 요청에 대해 할당된 자격 증명은 해당 응용 프로그램이 작업을 수행하는 데에 있어 얼마나 많은 권한을 부여해 줄 수 있는가에 결정적인 역할을 합니다. 이해를 돕기 위해, 아래에 흔히 발생하는 경우에 대한 가이드 라인을 제시했습니다.
응용 프로그램이 특별한 보안이 필요 없는 경우, 즉 누구라도 웹 사이트의 모든 페이지를 자유롭게 접근할 수 있고 각각의 사용자에 대한 개인화 설정이 필요 없다면, 응용 프로그램 수준에서 굳이 보안에 대한 고민을 할 필요는 없습니다. 단지, "Everyone" 계정에 대해 모든 파일을 접근할 수 있도록 허용해 둡니다.
인트라넷 웹 응용 프로그램 또는 서버에 대해 윈도우 계정과 요청을 연결시켜 권한을 관리하는 응용 프로그램을 만들게 된다면, 여러분은 윈도우 인증과 ACL 권한 부여를 선택할 수 있습니다. 그런 경우 운영체제의 보안과 연결되어 관리되어집니다. 또한 응용 프로그램이 구현해야 할 기능에 따라서 "가장(Impersonation)"을 사용할 것인지에 대해서도 선택할 수 있습니다.
eBay 와 같은 인터넷 응용 프로그램을 작성하는 경우라면 폼 인증과 URL 권한 부여를 사용하는 것이 일반적입니다. "가장(Impersonation)" 옵션은 디폴트 값으로 그대로 둘 수 있고, 권한 부여를 위해 로그인 폼에 입력된 자격 증명에 기반한 처리를 할 수 있습니다. 지금까지 계속 설명했던 IIS 와 액세스 토큰에 대한 고려는 이 방식에서는 해당되지 않습니다. 왜냐 하면 응용 프로그램의 모든 파일에 대해 "Evenyone" 계정으로 접근할 수 있도록 허가해 두고, ACL로 했던 그 자원들에 대한 접근 제어를 Web.config 의 URL 권한 부여 설정에서 대신할 수 있기 때문입니다.
마지막으로, ASP.NET 응용 프로그램에서 파일과 디렉토리에 대한 접근 제어를 ACL을 이용해서 구현하고 싶다면, ASPNET 계정 또는 Aspnet_wp.exe 프로세스에 명시적으로 지정된 계정 만큼은 해당 파일들을 읽을 수 있는 접근 권한을 주어야 한다는 것을 기억해 두십시오. 그렇지 않으면 ASP.NET 자체가 해당 자원에 대해 읽을 수 없기 때문에, 예측할 수 없는 접근 거부와 관계된 각종 오류를 접하게 됩니다.
윈도우 인증 윈도우 인증 방법은 ASP.NET으로 선택할 수 있는 인증 옵션중의 하나입니다. 윈도우 인증을 선택함으로써, 들어오는 요청에 대해 웹 서버 또는 웹 서버가 포함되어 있는 도메인의 사용자 계정으로 연결 시킬 수 있습니다. 일반적으로 이 방법은 인터넷상으로 배포되는 웹 사이트의 경우에는 잘 사용되지 않습니다. 대신에, 윈도우 사용자 계정으로 묶을 수 있는 대상으로 한정이 되는 경우에 이 방법을 사용해 볼 수 있습니다. 프런트 엔드 측의 윈도우 인증은, 여러분들이 제공하고 싶은 자원에 대해 접근을 제어하는 백 엔드 측의 ACL 권한 부여와 짝으로 이루어 집니다. 물론, URL 권한 부여 방법과도 잘 어울릴 수 있습니다. 윈도우 인증은 기본, 다이제스트, 통합, 클라이언트 인증서 매핑, 이렇게 4가지 유형으로 나뉩니다. 4가지 방식 모두 들어오는 요청에 대해서 사용자 계정과 연결시켜 주는 데에는 변함이 없습니다. 단지 동작하는 방식이 각각 차이가 날 뿐입니다. 이후의 섹션에서는 4가지 방식의 내부 동작에 대해서 각각 살펴보고, 사용자 입장에서는 어떻게 다른지를 보겠습니다. 모든 설명이 끝나고 나서, 실제 ASP.NET 응용 프로그램에서 윈도우 인증을 사용하는 예를 들어 보겠습니다.
기본 인증 기본 인증은 HTTP 표준 방식으로 ftp://ftp.isi.edu/in-notes/rfc2617.txt에 공개된 RFC 2617 번에 공식적으로 문서화 되어 있습니다. 기본 인증은 매 요청마다 사용자 계정과 암호를 전송합니다. IIS는 해당 사용자 계정과 암호를 서버측 계정과 연결하고, 일치하는 경우 ACL 기반의 보안 확인 작업을 수행할 수 있도록 액세스 토큰을 생성합니다. 간단하게 설명한 듯 하지만, 실제로 기본 인증 자체의 구현은 매우 간단합니다. 어떻게 기본 인증이 동작되는지에 대한 예로, 여러분 회사에서 사원들에게만 공개되는 정보를 보여주는 일련의 웹 페이지를 배포하는 것을 가정해 보겠습니다. IT 관리자는 관련 파일을 웹 서버의 가상 디렉토리에 위치시키고, 익명 액세스 허용 해제와 기본 인증 옵션을 선택해 둡니다. 이제 클라이언트 측에서 해당 폴더의 파일을 접근하는 첫 번째 시도에서 웹 서버는 401 상태 코드를 반환함으로써, 브라우저로 인증이 필요하다는 것을 알립니다. 또한, 그 응답의 WWW-Authenticate 헤더에 서버에서 수용할 수 있는 인증 유형을 함께 설정해서 보냅니다. (세부적인 통신 방법은 프록시 서버의 유무에 따라서 달라질 수 있지만 기본적인 방식은 변함이 없습니다.) 다음은 IIS 5.0에서 응답한 데이터의 일부를 보여주고 있습니다. 보시는 것처럼 해당 자원을 접근하기 위해서는 기본 인증이 필요하다고 알려주고 있습니다. HTTP/1.1 401 Access Denied Server: Microsoft IIS-5.0 ??? WWW-Authenticate: Basic realm="jupiter"위와 같은 응답을 받은 클라이언트 측 브라우저는 사용자 계정과 암호를 입력 받을 수 있는 표 3과 같은 대화창을 띄웁니다.
표 3 기본 인증
대화창을 통해 입력 받은 사용자 계정과 암호를 Base64 인코딩 시키고, 그 결과를 인증 유형을 명시하는 문자열과 연결시켜서 HTTP 요청의 "Authorization" 헤더에 실어서 서버로 전송을 합니다. 다음은 인터넷 익스플로러 6.0 인 경우에 "imbatman" 암호를 가진 "Jeff" 사용자 정보를 전송하는 헤더를 보여주고 있습니다. Authorization: Basic SmVmZjppbWJhdG1hbg==위의 문자열에서 뒷부분의 인코딩된 문자열을 Base64 디코딩으로 다시 풀어보면 다음과 같은 문자열이 나옵니다. Jeff:imbatman한번 인증이 이루어지면, 재차 사용자 로그인 정보를 받지 않도록 하기 위해서, 브라우저는 동일한 영역에 대해 같은 내용의 "Authorization" 헤더를 매 요청 시마다 전송을 해줍니다. 동일한 영역에 대한 기준은 해당 웹 사이트의 전체 또는 부분을 포함하는 논리적인 보안 공간을 말합니다. 모든 인증은 제각각 그 나름대로의 장단점을 가지고 있습니다. 그렇다면 기본 인증에서의 장점은 무엇이겠습니까? 바로 어떠한 브라우저와도 호환이 가능하다는 점입니다. 구현이 직관적이므로 브라우저 측에서도 해당 기능을 손쉽게 구현할 수 있기 때문입니다. 하지만, 기본인증에는 심각한 결함이 있는데, 사용자 계정과 암호를 평문으로 전달한다는 문제점이 있습니다. 만약 암호화되지 않은 채널을 사용해서 클라이언트와 서버가 통신 중이라면, 해당 HTTP 패킷들이 가로채인 경우 그 헤더에 포함된 사용자 계정과 암호가 노출되지 않는다고는 아무도 장담할 수 없습니다. 심지어 사용자 계정과 암호를 입력 받는 대화상자를 띄우도록 웹 서버 측의 헤더를 가로채서 클라이언트에 보내면, 사용자는 아무 의심 없이 계정과 암호를 입력할 것이고, 평문으로 된 그 요청 헤더를 쉽게 가로챌 수 있게 됩니다. 웹 서버와의 회선이 물리적으로 보호되지 않은 상태에서 기본인증을 사용하는 경우라면, 반드시 HTTP가 아닌 HTTPS 기반에서 통신이 되도록 해야 합니다. 그렇지 않으면, 전문적인 지식이 없는 사용자들을 대상으로는 보안이 적용될지언정, 전문적인 크래커들에게는 보안 허점을 제공해 주는 것이라고 보면 됩니다.
다이제스트 인증 다이제스트 인증은 기본 인증과 구현 방법이 유사합니다. 다이제스트 인증으로 보호된 자원을 액세스 하려고 하면, 브라우저는 대화창을 띄워 사용자 계정과 암호를 받아들입니다. 그러면 웹 서버는 해당 요청에 대한 신원을 연결시켜 줍니다. 동일하게 보이는 이 두 가지 인증 유형에서 가장 뚜렷한 차이점이 있는데, 그것은 바로 다이제스트 인증은 평문으로 암호를 보내지 않는 다는 점입니다. 대신에, 암호화시켜 안전해진 인증 토큰을 전달합니다. 그와 같은 장점으로, 보안되지 않은 채널을 통해서도 안전하게 다이제스트 인증을 사용할 수 있습니다. 다이제스트 역시 RFC 2617 에 문서화되어 있는 인증 방식입니다. 클라이언트에서 다이제스트 인증으로 보호된 자원을 요청하는 경우, 서버는 401 에러 코드와 함께 "WWW-Authenticate" 헤더에 "1"과 "0"으로 뒤섞인 문자열(nonce 라고 부릅니다.)을 실어서 응답합니다. 브라우저는 이번에도 사용자 계정과 암호를 묻고, WWW-Authenticate에서 지정된 "1/0" 문자열과 값과 함께 해시 또는 다이제스트 시킨 값을 서버로 전송합니다. 서버 측에서는 클라이언트 측으로 보냈던 WWW-Authenticate 헤더 값과 해당 사용자의 계정, 암호를 통해서 해시 작업을 수행한 후 클라이언트에서 넘겨 받은 해시 값과 비교하는 작업을 통해 인증할 것인지를 판단합니다. 이 과정에서 서버는 클라이언트로부터 암호를 직접 요구하지 않습니다. 사용자 계정을 클라이언트로부터 받으면 그와 관련된 암호를 서버 측에서 구하게 되고, 해시 후 값이 일치하는 것으로 인증이 이루어지는 것입니다. 뚜렷한 특징은, 다이제스트 인증은 결코 암호를 평문으로 요구하지 않기 때문에 HTTP 연결을 통해 전달되는 헤더의 내용을 가로챈다고 해도 안전하다는 점입니다. 프록시 서버를 경유하는 경우에도 문제 없이 사용되는 인증 유형입니다. 다이제스트 인증에는 다음과 같은 장점들이 있습니다. 우선, 기본 인증처럼 호출자를 인식하는 방법이 복잡하지 않고 방화벽 환경에서도 잘 동작합니다. 또한 해시된 값의 전달로 인해 보안이 적용되지 않은 HTTP 연결에서도 안전하게 사용할 수 있습니다. 단점으로는, 다이제스트 인증을 구현하지 않은 이전 버전의 브라우저에서는 사용할 수 없습니다. 마이크로소프트의 인터넷 익스플로러 사용자의 경우, 5.0 이상의 버전부터 지원되고 있습니다. 또 다른 단점으론, 서버 측에 암호가 평문으로 저장되어 있거나 암호화 되어 있다 해도 다시 평문으로 복원될 수 있어야 합니다. 이런 점은, 평문 암호를 단방향 해시 알고리즘을 적용하거나 보호를 위해 암호호화 시켜서 저장해 두는 윈도우 운영체제의 일반적인 보안 원칙에 위배됩니다. 마지막으로 단점 하나를 더 들어 본다면, 기본 인증처럼 다이제스트 인증 역시 사용자 계정과 암호를 묻기 위해 대화창을 띄운다는 것입니다. 이러한 제약 사항과 함께 윈도우 2000 서버에서 다이제스트 방식이 위임을 지원하진 않는 등의 이유로 인해, 다이제스트 인증은 그다지 많이 사용되고 있지는 않습니다.
윈도우 통합인증 윈도우 통합인증은 사용자 인증을 위해 윈도우 운영체제만의 로그온 방식을 사용합니다. 사용자 계정과 암호를 묻고 HTTP 연결로 그것들을 전달하는 방식은 사용하지 않습니다. 윈도우 통합인증으로 사용자 신원을 확인하도록 요청을 받은 브라우저는 웹 서버로 클라이언트 측 컴퓨터에 로그온 한 사용자의 신원을 직접 전달합니다. 예를 들어, 만약 "Bob"이란 사용자가 PC에 로그인 하고 인터넷 익스플로러를 실행시켜 윈도우 통합인증으로 보호된 서버 측 자원을 요청하는 경우를 가정해 보겠습니다. 그러면, 인터넷 익스플로러와 웹 서버 간의 쌍방향 협약을 거쳐서 요청들이 "Bob"의 신원으로 서버상에서 실행되게 됩니다. 이를 위해, 클라이언트의 Bob 계정이 서버 또는 서버가 인증으로 사용하는 도메인에서의 Bob 계정과 일치해야 한다는 것입니다. 그렇지 않으면 접근 권한이 없다는 통상적인 오류가 발생하게 됩니다. 별도 설정을 하지 않았다면, 브라우저는 웹 서버에 Bob 계정이 유효하지 않은 경우 사용자 계정과 암호를 묻는 대화창을 띄우게 됩니다. 윈도우 통합인증은 인터넷 표준은 아닙니다. 윈도우 로그온 자격 증명을 HTTP 통신에서도 사용할 수 있도록 적절하게 만들어진 인증 프로토콜일 뿐입니다. 내부 작동 방식에 대해서도, 서드파티 회사들의 노력으로 어느 정도는 공개되어 있지만 정작 마이크로소프트 측에서는 완전하게 문서화된 형태로 공개하지는 않았습니다. 세부적인 사항들은 사용되어지는 보안 제공자 (NTLM 또는 Kerberos ) 에 따라 가변적입니다. 하지만 기본 원리는, 클라이언트와 서버가 사용자 계정과 도메인 명, 보조 변수 값, 해시와 관계된 일련의 협약을 거치는 방식으로 신뢰여부를 결정하는 것입니다. 이 방식 역시 장점과 단점이 있습니다. 우선, 사용자 계정과 암호를 서버에 전송하기 위해 한번 더 입력해야 하는 불편함이 없어졌다는 장점을 꼽을 수 있겠습니다. 물론, 암호자체가 평문으로 전달되지 않으므로 보안되지 않은 채널을 통해서도 안전하게 통신할 수 있습니다. 단점들을 나열해 보면, 마이크로소프트가 제공하는 인터넷 익스플로러 2.0 이상의 버전에서만 동작할 뿐 그 외의 다른 브라우저에서는 지원되지 않습니다. 또한 대부분의 방화벽들이 NTLM 또는 Kerberos 쌍방향 협약 시 필요로 하는 포트를 막아버려 동작이 불가능합니다. 이런 요소들을 따져 볼 때, 윈도우 통합인증은 방화벽 안쪽에 놓인 내부 네트워크와, 적절하게 설정된 브라우저를 클라이언트로 사용되는 경우에 한해서 가장 최적화된 솔루션으로 사용될 수 있습니다. (물론, 브라우저는 인터넷 익스플로러로 제한됩니다.) 당연히, 인터넷 대상의 목적으로는 적합하지 않습니다.
인증된 사용자의 정보를 구하는 방법 ASP.NET 에서는 HttpContext 클래스의 User 속성을 통해서 호출자의 신원에 대한 정보를 제공해 주고 있습니다. HttpContext 개체는 모든 요청마다 각각 할당되며, Page, WebService와 HttpApplication과 같은 ASP.NET 에서 제공되는 여러 개체들에서 Context 라는 속성을 통해 접근할 수 있습니다. 일례로, ASPX 파일에서는 User 개체를 Page.Context.User 또는 Page.User와 같은 식으로 접근합니다. User 개체는 IPrincipal 인터페이스를 구현한 클래스입니다. IPrincipal은 System.Security.Principal 네임스페이스에 정의된 인터페이스로 WindowsPrincipal 클래스와 GenericPrincipal 클래스가 상속받아서 구현하고 있습니다. 사용자가 윈도우 인증 방식을 통해 인증되어졌다면, Page.User 속성은 WindowsPrincipal 개체를 참조하게 됩니다. 그 외의 다른 유형의 인증방식이 사용되어졌다면, Page.User 속성은 GenericPrincipal 개체를 참조합니다. IPrincipal 인터페이스는 역할에 기반한 자격을 확인하기 위한 IsInRole 메서드를 가지고 있습니다. (윈도우 인증의 경우에는, 역할그룹은 곧 윈도우 보안 그룹을 나타내며 폼 인증인 경우에는 별도 코드를 작성하지 않는 한 대응되는 것이 없습니다.) 또한 Identity 속성으로 인증된 사용자에 관계된 정보를 제공해 주도록 하고 있습니다. Identity 속성은 IIdentity 인터페이스 형으로 표 4 에 IIdentity 인터페이스 멤버를 실어 놓았습니다. 다소 혼동될지도 모르겠는데, 구체적으로 살펴보면 User 개체는 호출자에 대한 정보를 가져오는 방법을 제공해 줍니다. 만약, 호출자가 인증된 사용자인지를 판별하고 싶다면, 다음과 같은 코드를 통해 그 여부를 알 수 있습니다. if (User.Identity.IsAuthenticated) { // 호출자가 인증된 경우 }그 외에도, Request 개체에서 제공해주는 IsAuthenticated 속성을 통해서도 사용자의 인증여부를 확인할 수 있는데, 사실 내부를 살펴보면 결국 User.Identity.IsAuthenticated를 호출하고 있는 것에 불과합니다. 호출자의 계정이름을 알고 싶다면, 다음과 같은 코드로 가능합니다. string name = User.Identity.Name;윈도우 인증 방식인 경우 이름의 표현 방식은 " 도메인명\사용자이름" 입니다. 여기서 도메인 이름은 사용자 계정이 등록된 도메인 이름이거나 해당 컴퓨터의 로컬 계정에 존재한다면 컴퓨터 이름이 될 수 있습니다. 폼 인증이라면, 이름은 로그인 폼에 입력된 사용자 ID를 보통 반환하게 됩니다. 개인화된 페이지를 보여주려는 경우에 사용자 계정이 필요할 수 있습니다. 다음 절에서는 예제와 함께 설명해 보겠습니다.
윈도우 인증 구현 표 5 는 CorpNet 회사를 예로, 간단한 인트라넷 형식의 응용 프로그램 을 보여주고 있습니다. 보시는 것처럼 윈도우 인증 방식을 사용하고 있으며 개인화된 페이지를 비롯해 몇 개의 페이지가 ACL 권한 부여에 따른 접근 제한이 되어 있습니다.
General.aspx: 회사에 대한 내용과 사용자 정보를 제공
Salaries.aspx: 해당 페이지를 열람하는 사원의 급여 정보를 제공
Bonuses.aspx: 사원들의 올해 상여금 목록을 제공
일단, Gernal.aspx 페이지에 대해서는 누구라도 볼 수 있도록 CorpNet 응용 프로그램을 배포합니다. 하지만, Salaries.aspx와 Bonuses.aspx 페이지는 특정 사용자들만이 볼 수 있도록 해야 합니다. 동작 확인을 하기 전에, 해당 응용 프로그램을 웹 서버에 배포하고, 보안의 요구 정도에 따라 설정을 해줘야 합니다. 다음과 같은 순서로 진행해 줍니다.
웹 서버의 원하는 위치에 "Basic" 이라는 이름으로 디렉토리를 생성해 둡니다.
"인터넷 정보 서비스(IIS) 관리" MMC 툴을 이용해서 1번 단계에서 생성한 "Basic" 폴더를 가상 디렉토리로 만듭니다.
이어서, 해당 가상 디렉토리의 "익명 액세스 가능" 선택을 해제하고 "기본 인증" 을 선택해 둡니다. 아래의 표 6에서 그 설정을 보여주고 있습니다.
표 6 인증 유형을 선택하는 화면
테스트를 위한 목적으로 웹 서버에 사용자 계정을 2개, "Bob" 과 "Alice" 를 생성합니다. 암호 설정은 임의로 하십시오.
General.aspx, Salaries.aspx, Bonuses.aspx, Bonuses.xml, Web.config 파일 모두를 웹 서버의 "Basic" 디렉토리에 복사합니다.
Salaries.aspx 파일은 "Bob" 계정과 ASPNET 계정만 접근하도록 설정합니다. 최소한 "읽기" 권한은 주어야 합니다. 그 이외의 권한은 필요 시에만 설정해 주면 됩니다.
Bonuses.xml 파일은 "Everyone" 계정에 접근 권한을 주되, "Alice" 계정에 대해서는 접근 거부를 명시합니다.
표 7 배포된 응용 프로그램 테스트
배포는 완료되었고, 이제 다음의 6가지 동작을 테스트 해봅니다.
http://localhost/basic/general.aspx 주소로 브라우저에서 해당 페이지를 호출합니다. Basic 디렉토리가 기본 인증을 요구하기 때문에 사용자 계정 정보를 묻는 대화창이 뜨게 됩니다. 생성해 두었던 계정인 "Bob" 과 그 암호를 입력하면 General.aspx 파일이 표 7과 같이 사용자 계정 정보와 함께 내용을 보여줍니다.
브라우저를 종료 후 다시 실행하고 1번 단계를 다시 반복합니다. 단지 사용자 계정만 "Alice" 의 것으로 해줍니다. "Bob" 과 "Alice" 모두 해당 페이지를 접근할 수 있는 권한이 있으므로 이번에도 정상적으로 General.aspx 내용이 보여집니다.
2번을 테스트한 브라우저에서 바로 Salaries.aspx를 호출합니다. Salaries.aspx 페이지의 경우 "Alice" 에 대해 읽기 권한이 없으므로 서버는 접근이 거부되었다는 오류를 보고하게 됩니다. (인터넷 익스플로러를 사용하고 있다면, 다시 정정할 기회를 몇 번 주게 되고 그 이후에 접근이 거부되었다는 메시지를 볼 수가 있습니다.)
브라우저를 종료 후 재 시작 하고 다시 Salaries.aspx 페이지를 방문합니다. 이번에는 "Bob" 계정 정보를 입력합니다. "Bob" 에 대해서는 읽기 권한이 있으므로 Bob 사용자의 급여 정보를 보게 됩니다. Salaries.aspx 파일은 다른 사원들도 방문할 수가 있는데, 보여주는 정보는 방문을 한 사용자의 계정 이름에 따라서 달라지게 됩니다.
4번을 테스트한 브라우저에서 바로 Bonuses.aspx를 호출합니다. 별다른 일 없이, 사원들의 상여금 목록이 보여집니다.
브라우저를 종료 후 재 시작 하고 다시 Bonuses.aspx 페이지를 방문합니다. 이번에는 "Alice" 계정 정보를 입력합니다. 그럼, 어떤 결과가 나올지 예측해 보기 바랍니다. 상황을 대강 요약해 보자면, Bonuses.aspx 페이지는 누구라도 접근할 수 있지만 해당 ASPX 파일 내부의 코드에서 DataSet.ReadXml 메서드를 통해서 읽는 Bonuses.xml 파일이 "Alice" 사용자에 대해서 접근이 거부되도록 설정되어 있습니다. 과연, "Alice"로 로그인한 현재 상태에서 "Bonuses.aspx"를 방문하면 오류가 발생하겠습니까?
결과를 보시면 아시겠지만, Bonuses.aspx 파일은 정상적으로 사원들의 상여금 목록을 보여줍니다. 정확히 말하면, Bonuses.aspx에서는 Bonuses.xml 파일을 정상적으로 읽어낸 것입니다. 도대체 "Alice" 사용자는 Bonuses.xml 파일을 접근할 권한이 없는 데도 어떻게 그것이 가능했겠습니까? 해답은 간단하지만, 정작 그 차이를 구별하는 것은 쉽지 않습니다. IIS 는 해당 요청에 대해서 "Alice" 사용자 계정의 액세스 토큰을 붙여주었습니다. 그것을 ASP.NET 에 넘겨 주었고 ASP.NET 은 호출자가 Alice 라는 사실을 기반으로 Alice 사용자에게 권한이 없는 페이지에 대해서는 볼 수 없도록 해줍니다. 하지만, Web.config에 "가장(impersonation)" 하도록 설정되어 있지 않기 때문에, 해당 요청은 "Alice" 계정이 아닌 "ASPNET" 계정의 보안 문맥으로 실행됩니다. ASPNET 계정은 Bonuses.xml 파일을 읽는 권한이 있고, Alice 계정으로 로그인한 사용자일지라도 정상적으로 Bonuses.aspx 파일을 볼 수 있게 되는 것입니다. ASP.NET 은 ASPX 파일 및 그 이외의 ASP.NET 이 처리하는 파일에 대해서 호출자의 자격증명을 이용해서 ACL 권한 확인 작업을 수행합니다. 이로 인해, 특정 사용자에 대해서 읽기 권한을 거부함으로써 원하는 ASPX 파일을 접근하는 것을 막을 수 있다는 것을 알 수 있습니다. 그러나, 호출자가 읽어낸 ASPX 파일 내부에서 다른 파일을 프로그래밍 코드를 통해서 접근하는 것까지도 호출자의 자격증명에 기반한 ACL 권한 확인을 하고 싶다면 ASP.NET으로 하여금 명시적으로 가장(impersonation) 하도록 설정해 주어야 합니다. 따라서, 위의 예제에서 "Alice" 사용자가 Bonuses.xml 파일 안에 있는 데이터를 열람하는 것을 막고 싶다면, Web.config 파일의 다음과 같은 부분을 수정해 주어야 합니다. <configuration> <system.web> <authentication mode="Windows" /> <identity impersonate="true" /> </system.web> </configuration>새롭게 추가된 identity 노드의 설정으로 ASP.NET 은 가장(impersonation) 이 가능하도록 합니다. Web.config을 위와 같이 변경 후, 브라우저를 재 시작하고 "Alice" 계정으로 다시 Bonuses.aspx 파일을 방문해 봅니다. 이번에는 해당 페이지를 처리하는 동안 오류가 발생했다는 화면을 보게 됩니다. 예외 핸들러에 의해 보여지는 메시지에는 Bonuses.xml 파일을 ReadXml 메서드가 읽으려 할 때 발생한 XmlException이 포함되어 있습니다. 다시 브라우저를 재 시작해서 "Bob" 사용자 계정으로 방문하게 되면 정상적으로 Bonuses.aspx 파일을 볼 수 있습니다. 위에 보여드린 CorpNet 예제는 ASP.NET 과 윈도우 인증을 함께 사용할 때 기억해 두어야 할 중요한 몇 가지 사항을 잘 나타내 주고 있습니다.
ASP.NET 에서 윈도우 인증을 사용하기 위해서는 Web.config에 다음과 같은 구문을 포함해야 합니다. <authentication mode="Windows" />
윈도우 인증을 사용하고 있는 ASP.NET 응용 프로그램에서, 특정 사용자로 하여금 접근을 못하도록 하고 싶은 페이지에 대해서는 ACL 권한 항목을 적절하게 조정해 주는 것으로 그 목적을 달성할 수 있습니다.
윈도우 인증을 사용하고 있는 ASP.NET 응용 프로그램에서는, 요청을 처리하는 코드에 의해서 접근이 되는 파일에 대해서도 호출자의 자격증명에 기반한 ACL 권한 확인을 하고 싶다면 가장(impersonation) 옵션을 켜두어야 합니다.
윈도우 인증을 사용하고 있는 ASP.NET 응용 프로그램에서는 Page.User.Identity.Name을 사용해서 사용자 계정을 알아낼 수 있고, 그 정보를 기반으로 웹 사이트의 내용을 개인화 시킬 수가 있습니다.
한가지 더 기억해 두어야 할 것이 있는데, ASPX 파일과 같은 ASP.NET 에 의해서 처리되는 파일들이 ACL 권한으로 관리되고 있는 경우 Aspnet_wp.exe 가 실행되고 있는 계정(기본값은 ASPNET 계정) 에 대해서는 반드시 읽기 권한이 있어야 합니다. 그렇지 않다면, ASP.NET 은 해당 파일을 읽을 수 조차 없게 됩니다. 실제로 테스트 해보고 싶다면, Salaries.aspx 파일의 ACL 목록에서 ASPNET 계정에 대해 읽기 권한을 거부하도록 설정하면, "Bob" 사용자 계정으로도 Salaries.aspx 페이지를 볼 수 없는 것을 확인할 수 있습니다.
윈도우 인증과 URL 권한 부여 위의 예제에서 보여준CorpNet 예제는 ACL 권한 부여를 사용해서 해당 페이지의 접근을 제어하고 있습니다. 이 방법 외에도 ASP.NET 은 URL 권한 부여 방식을 지원합니다. 예를 들기 위해, CorpNet 예제의 Basic 디렉토리 하위에 Secret 디렉토리를 생성해 주고 Salaries.aspx, Bonuses.aspx, Bonuses.xml 파일을 새로운 폴더로 이동시킵니다. 그런 후, Secret 디렉토리에 Web.config 파일을 생성하고 아래와 같은 내용으로 채워줍니다. (주의해야 할 것은 Bob 계정으로 명시한 users 속성값에서 "domainname "을 여러분이 테스트 하는 컴퓨터의 환경에 맞게 적절하게 설정해 주어야 합니다.) <configuration> <system.web> <authorization> <allow users="domainname\Bob" /> <deny users="*" /> </authorization> </system.web> </configuration>이제, 브라우저에서 Bob 사용자 계정으로 로그인 하면 Salaries.aspx와 Bonuses.aspx 파일을 정상적으로 접근 할 수 있습니다. 물론, 그 이외의 사용자 계정으로 로그인한 경우에는 해당 파일들이 없는 것처럼 동작하게 됩니다. URL 권한 부여를 사용하는 최대 단점은, ASP.NET에 등록된 파일에 대해서만 보안이 적용된다는 점입니다. 즉, 그 외의 다른 확장자를 가지는 .html파일과 같은 경우에는 URL 권한 부여 설정을 통해서 제어할 수 없습니다. URL 권한 부여가 가지는 또 다른 한계점이라면, 윈도우 보안 ID (SID) 가 아닌 문자열로 된 이름에 기반해서 구현되었다는 것입니다. 이런 저런 이유로 인해, 윈도우 인증이 사용되는 경우에 URL 권한 부여 보다는 ACL 권한 부여가 일반적으로 쓰여지게 됩니다.
윈도우 인증과 역할 기반 보안 역할 기반 보안은 웹 응용 프로그램에서 잘 활용될 수 있는 방식입니다. 사용자 계정 이름에 기반하여 호출자를 구분해서 접근제한을 하기 보다는, 회사 같은 경우 "대표", "관리자", "개발자", "사무원" 등으로 해당 사용자가 소속된 역할을 기반으로 제한 하는 것이 바로 "역할 기반 보안" 입니다. 다시 예제로 돌아가서, Secret 디렉토리에 대해 "관리자" 그룹의 모든 구성원들에게만 접근을 허용하도록 변경한다면, 바로 그런 경우가 역할 기반 보안을 적용해 보는 좋은 사례가 되는 것입니다. 그렇게 변경시키면, Salaries.aspx와 Bonuses.aspx는 관리자 그룹에 속한 구성원들에 대해서만 접근할 수 있게 되는 것입니다. 역할 기반 보안 역시 URL 권한 부여와 함께 적용될 수 있습니다. 다음의 Web.config 파일은 가상 디렉토리를 접근하기 위해 "관리자" 그룹의 구성원이어야 한다는 제약을 설정하는 예를 보여주고 있습니다. 내부적으로 ASP.NET 은 와 속성에 제공된 역할 이름과 호출자를 연결시키는 작업을 처리해 줍니다. <configuration> <system.web> <authorization> <allow roles="domainname\Managers" /> <deny users="*" /> </authorization> </system.web> </configuration>역할 기반 보안이 URL 권한 부여와 함께 사용되는 경우, 사용자 기반 보안에서 다루었던 그와 똑같은 단점을 그대로 지니고 있습니다. 활용가능성은 그다지 많지 않지만, 폼 인증과도 함께 사용될 수도 있습니다.
마치면서 윈도우 인증과 ASP.NET 의 결합은 ASP.NET 이 인트라넷 용도 또는 제한된 사용자들을 대상으로 하는 웹을 위한 개발 환경으로 훌륭한 조건을 제시하고 있습니다. 그러나, 모든 사용자들을 대상으로 인터넷 웹 사이트를 개발하는 데에는 그다지 적합하지 않습니다. 다음 달에는, 폼 인증과 실제로 폼 인증이 웹 서버의 도메인에 사용자 계정을 가지고 있는 않은 상태에서 웹 사이트 보안을 구현하는 것에 대해, 자세히 살펴보는 것을 마지막으로 ASP.NET 보안에 대한 설명을 마무리할 것입니다.
Jeff Prosise 윈도우 프로그래머, 강사로 활동하고 있으며, .NET 개발 교육 관련해서 개발자 교육과 컨설팅을 주로 하는 업체인 Wintellect의 공동 설립자입니다. 그의 이메일은 wicked@microsoft.com 입니다. 이번 기사에 실린 내용은 Microsoft Press 에서 2002년 5월에 출판 예정인 Programming Microsoft .NET 책에도 포함됩니다.
네트워크 응용 프로그램의 특성상, 해당 응용 프로그램을 대다수의 사용자들이 접근한다는 점에서 보안은 가장 우선시 되어야 할 고려 사항입니다. 더군다나, 해당 응용 프로그램이 인터넷을 통해서 배포되는 경우에는 전세계의 인터넷 사용자들이 그 대상이 되므로 보안이 더욱 절실해 질 수 밖에 없습니다. 웹에 대한 보안을 한다는 것은 광범위하면서도 상당히 복잡한 주제이며, 최근 들어 웹 서버를 안전하게 만드는 것과 관계된 연구들이 많이 진행되고 있는 실정입니다. Microsoft가 내놓은 IIS 역시 많은 보안 결함을 가지고 있었으며 그에 따른 업데이트도 나와 있습니다. 이번 글의 주제는 버퍼 오버런이나 그 외의 결함에 대한 공격으로부터 웹 서버를 보호하는 방법을 설명하기 보다는, ASP.NET으로 만든 페이지를 권한이 있는 사용자에 대해서만 서비스를 하도록 하는 방법을 주로 다루도록 하겠습니다. 
