고정 헤더 영역
상세 컨텐츠
본문
|
이 문서는 아파치에서 사용자를 인증하는 방법에 대해 유닉스를 기반으로 기술한 것입니다. 앞으로 많은 분들이 이러한 작업에 동참해 주셨으면 하며, 많은 내용들이 축적되고 하면 하나의 책으로도 엮어 보는 생각도 가지고 있습니다. |
오늘날 웹(World Wide Web) 이라는 새로운 매체의 등장은 현재의 일상생활에 없어서는 안될 아주 중요한 부분으로 자리매김 하였다. 비록 눈에 띌 정도로 세상을 바꿔놓고 있을 정도는 아니라 할지라도 보이지 않는 곳에서 이미 시각적, 청각적인 감각을 통합하는 이른바 Emotional (감성적) 정보의 유통은 기존의 모든 상식을 뒤엎는 패러다임을 제시하며 꾸준하게 그 인프라를 넓히고 있는 중이다.
당장 지금 이 순간에도 인터넷을 통하여 상상할 수 없을만큼 엄청난 양의 정보들이 서로 오가고 있으며, 엔드유저 차원에서 접근하는 모든 사이트들은 이러한 정보를 제공하기 위해서 일차적으로 존재하게 되는 웹서버에의 접근을 필요로 하게 된다. 만일 정보만을 취득하려 접속하는 상황이 아니라 직접 웹서버를 구축하는 상황이라면 우선 본인의 시스템 상황과 웹서버 구축용 프로그램들을 찾게 될 것이다.
하지만 아무런 정보도 없이 이러한 작업을 시작하는 것은 상당히 무모한 일이라고 볼 수 있다. 과연 무엇이 가장 일반적이고 통상적인 방법일까? 아마도 웹서버를 직접 설치해 보고 실제 구동되는 상황과 모니터링을 하고 직접 그 결과물을 보는 것이 가장 적절할 것이라 생각된다.
아파치의 기본적인 설정 및 운영방법보다는 실제 웹서버를 운영하는데 있어서 여러분들에게 좀더 실용적이고 유용한 방법들에 대해 다룰것이며, 글을 진행해 나가면서 여러분들이 많이 의문을 가질만한 부분에 대해서는 중간중간 그 부분에 대해 부가설명을 덧붙일 예정이니 시작하기에 앞서 갖는 두려움보다는 앞으로 이 글을 읽고 해보아야 겠다는 자신감을 가졌으면 한다.
앞으로 시간이 되는 대로 아파치의 기능들에 대해 좀더 자세히 소개해 보고자 한다. 아파치의 소개 및 설치에 대한 것은 http://www.apache.kr.net 을 참고하기 바라며, 문의사항은 아파치 게시판을 이용해 주기를 바란다.
사용자 인증은 어떻게 작동되어 지나요 ?
접근제어방법은 HTTP 프로토콜의 한 부분이다. 브라우저가 서버에 문서를 요청하면, 이때 서버는 클라이언트(브라우저) 에게 문서의길이, 마지막으로 수정된 날짜, 문서의 타입등의 헤더정보를 포함하여 함께 클라이언트에게 되돌려준다. 지금 이 글을 읽고 있는 여러 분들은 인터넷을 서핑 하다 한번쯤은 사용자 아이디와 패스워드를 필요로 하는 사이트를 방문해 보았을것이다. 이때 나타나는 자그마한 인증창을 보았을것이며, 그렇다면 과연 이러한 인증창은 어떻게 구현되어졌는지 궁금하지 않은가? 쉽게 생각하자. 지금 이순간 아파치로 웹서버를 운영하고 있다면 하나이상의 많은 디렉토리에 여러분들이 원하는대로 접근제한을 할 수가 있는것이다.
미리 언급하건데, 본인이 제시하는 인스트럭션을 그대로 옮기면 아주 전문적인 웹서버가 아닌 기초적인 웹서버 제작에는 전혀 무리가 없으니 부담없이 보아 주기를 바란다.
먼저, 시작하기 전에 인증이 설정되어져 있는 사이트와 그렇지 않은 사이트를 비교해 보겠다. 일반적으로 웹서버에 접근을 하기 위해서는 다음과 같이 브라우저 창 안에 있는 텍스트필드에 URL 을 입력하여 문서를 요청하게 된다..
http://www.apache.kr.net/documents
접근하는 프로토콜이름은 http, 서버이름은 www.apache.kr.net 이며, 요청하는 문서이름은 /documents/ 이다. 왜 문서이름이라 해 놓고서 디렉토리 이름인지 궁금한가? 그것은 아파치를 포함한 대부분의 웹서버 프로그램은 디렉토리를 요청하였을 때 “index.html” 을 요청하는 것으로 간주하게 되기 때문이다.
|
▶ 잠깐, 이것이 궁금하세요 ? 윈도우환경에서 HTML 문서를 작성하였더니 확장자가 미처 “htm” 으로 되어 있다는 생각을 하지 못했습니다. 유닉스 환경에 올려야 하는데 방법이 없나요 ? conf/httpd.conf 파일을 잠깐 보실까요 ? DirectoryIndex index.html 이라고 되어 있는 부분을 간단하게 “index.html” index.htm 으로 바꾸어 주시기만 하면 됩니다. |
documents 디렉토리를 요청하였는데 ,왜 index.html 이 출력되었는지 이해가 가는가? 쉽게 생각해서 일반적인 방법으로 URL 을 요청한다면 다음과 같은 뜻이 된다 :
http://www.apache.kr.net/documents/index.html
브라우저가 www.apache.kr.net 에게 documents의 문서를 요청하였을 때 이러한 행동 들은 웹서버에서 실제로 어떻게 구동되는 것일까? 지금 바로 여러분의 시스템 앞에 이 글을 펼쳐놓고 다음과 같이 TELNET 명령어를 이용하여 외부에 있는 시스템에 접근을 해보기 바란다.
telnet www.apache.kr.net 80 / apache.kr.net 이 아닌 다른 주소를 입력하여도 무방하다.
|
▶ 잠깐, 이것이 궁금하세요 ? telnet www.apache.kr.net 은 시스템에 접속하는 것으로 이해할 수가 있겠는데 뒤에 붙은 “80” 은 무엇일까? 80은 웹서버의 포트번호를 의미한다. 21번은 FTP, 25번은 SMTP 를 의미하듯이, 각 프토토콜에는 포트번호가 할당되어져 있다. |
웹서버에 접속이 성공적으로 이루어지면, HTTP 요청을 한다.
GET /documents/ HTTP/1.0
이뜻은 어떤 문서를 내려받기 원하는지와 사용하는 HTTP 버전을 서버에게 말해주는 것이다. HTTP/1.0 뒤로는 클라이언트의 브라우저에 대한 더 많은 정보의 헤더가 더해질수 있는데, 사용자가 바라는 문서의 종류 및 과거에 설정되어졌던 쿠키 및 다른 유용한 정보가 될 수 있다. 위와 같이 입력한 후에는 ENTER를 두 번 입력해준다. – 왜 ENTER 가 한번도 아니고 두번인지 궁금한가? 처음에 입력하게 되는 ENTER 의 의미는 추가적인 헤더를 입력할 수가 있으며, 두번째의 ENTER 의 값은 서버로부터 응답받고자 하는 모든헤더의 정보를 보냈다는 것이다.
모든 것을 올바르게 수행하였다면 서버는 요청한대로 문서를 출력 할 것이다.
|
HTTP/1.1 200 OK |
서버에서 응답한 메시지의 상위에 있는 200 은 현 웹서버의 상태에 대한 코드를 나타내는것으로 모든 것을 제대로 다 수행했다는 것과 동시에 요청한 문서를 보내주었다는 것이다. Content-Type 은 이 문서가 HTML 포맷으로 작성되어져 있다는 것을 의미한다.
이와 반대로 접근제한이 설정되어져 있는 곳에서의 요청은 약간 좀더 복잡해 진다. 복잡하다는 말에 겁먹지는 말기를 바란다.
접근제한이 되어 있는 “/private” 에서 문서를 받아오기 위한 절차는 다음과 같이 진행된다.
telnet www.apache.kr.net 80 // 접속이 이루어진후 , “private” 디렉토리를 요청하게 된다.
GET /private/ HTTP/1.0
“/private” 디렉토리 안에 들어있는 “index.html” 을 받아 오려고 시도하면 서버에서는 다음과 같은 응답을 하게된다.
|
HTTP/1.1 401 Authorization Required WWW-Authenticate: Basic realm="staff area" Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.<P> |
위와 같은 메시지가 의미하는 바는 서버에 의해 요청이 거부되었다는 것이다. 이유인즉, 우선 인증이 선행되어지지 않았기 때문이다. 이렇게 인증이 필요한 부분은 인증에 대한부분의 헤더를 입력해 주어야 한다. 고로, 사용자이름이 “intexp” 이며 패스워드가 “intexp007” 일 경우에는 telnet 을 이용하여 포트80번에 접속한 후에 다음과 같이 요청하여야 한다.
GET /private/ HTTP/1.0
Authorization: Basic aW50ZXhwOmludGV4cDAwNw==
“Authorization”으로 시작하는 부분의 뜻은, 인증방법중의 하나인 “Basic”을 사용하여 시스템에게 인증정보를 보낸다는 것이다. “Basic” 뒤에 붙은 뜻모를 문자들은 사용자 아이디와 패스워드를 의미하는 것으로 “username:password”로 구성되어져 Base64 라는 기법으로 엔코딩 되어있다는 뜻이며, 다음과 같은 방법으로 Base64로 엔코딩 할 수가 있다.
perl -e ‘use MIME::Base64; print encode_base64(“intexp:intexp007”);’ 입력 후 엔터 :
aW50ZXhwOmludGV4cDAwNw==
위와 같은 방법을 사용하기 위해서는 MIME::Base64 모듈이 시스템에 설치되어져 있어야 한다. 이 모듈은 CPAN (http://www.perl.com/CPAN/) 사이트에서 구할 수가 있다.
|
▶ 잠깐 쉬어 가세요 아파치 차기 버전인 2.0에 대한 실체가 3월 10일 알파버전의 발표로 드러났다. 이번 버전의 새로운 기능은 MPM(Multiple-Processing Modules), APR(Apache Portable Run-Time)등 많은 기능 등이 추가되어져 있으며, 전반적으로 안정성 및 확장성이 증대되었다고 할 수 있겠다. 현재 http://www.apache.kr.net 을 통해서 다운로드 받을 수 있다. |
패스워드 파일을 한번 만들어 볼까요 ?
지금까지 주욱 언급해왔듯이 인증이 수행되기 위해서는 기본적으로 필요한 것은 무엇일까? 바로 사용자들의 유저네임(아이디)과 패스워드를 기억하고 있는 파일이 된다. 보안적인 측면에서 본다면, 이 파일은 아파치 웹서버의 Document Root 로 지정된 곳에는 들어 있지않도록 주의 하여야 한다. 예를 들면, 패스워드 파일을 httpd.conf에서 DocumentRoot로 지정한 곳이 아닌 아파치 웹 서버가 위치하는 ServerRoot 의 /usr/local/apache/ 등에 위치하도록 해 주어야 한다.
파일에는 각각 사용자의 유저네임과 패스워드가 저장되어져 있으며, 이러한 포맷은 일반 유닉스의 패스워드와 비슷하게 “:” 로 나누어져 있다. 그러나, 이 파일을 단순히 TEXT로만은 써 넣을 수 없다. 왜냐하면, 유닉스를 사용하는 여러분들도 잘 알다시피 패스워드 파일은 암호화되어 있기 때문에 아파치에서 제공하는 htpasswd 프로그램을 이용하면 간단하게 파일을 만들거나 수정할 수가 있다.
htpasswd 파일은 C 로 작성되어져 있으며, support 디렉토리 안에 들어있다. 컴파일 되어져 있지 않다면 다음과 같이 컴파일 할 수도 있다.
make htpasswd
이 프로그램의 Syntax 는 다음과 같다 :
htpasswd [-c] passwordfile username
새로운 패스워드 파일을 만들고자 할 경우에는(또는 존재하는 파일을 다시 Overwrite 할때) 다음과 같이 문법을 사용하면 된다.
htpasswd -c /usr/local/apache/etc/passwords intexp
위 명령어를 수행하면, intexp에 대한 패스워드를 묻는 프롬프트가 나타나며 이때, 패스워드를 입력 후 엔터를 치면 다시 한번 패스워드를 재차 확인하며, “/usr/local/apache/etc” 아래에 passwords 파일을 생성하게 될 것이다. -c 옵션은 새로운 파일을 생성하거나 존재하는 파일에 대해 덮어씌우기를 수행하므로, 새 유저를 추가하고자 하는 경우에는 -c 옵션을 제외하고 같은 방법으로 위 명령어를 수행하면 된다.
▶ 주의 : -c 옵션을 사용하는 경우에는 기존에 존재하는 패스워드 파일을 경고나 백업의 절차없이 Overwrite 하게 되므로 다른 곳에 복사해 두거나 하는 등의 조치가 필요하다.
몇몇 사용자를 새로이 추가한 후 /usr/local/apache/etc/password 의 파일을 살펴보면 :
(패스워드파일에는 유저네임과 암호화된 패스워드를 제외한 다른 것은 포함되어져 있지않다)
jjlee:LDLvW1Za4Jmbw
maria:QRhIc5AEgC/Yg
intexp:ZFEoNHJGYIzXY
여기서 한가지, 많은 수의 사용자에 대해 인증을 수행하려 하거나 또는 인증을 요청하여 접속할 경우에는 효율적인 측면에서 DBM 또는 DB를 사용하는 방법을 권장하고싶다. 아파치 웹서버는 현재 DB, DBM에 대해서 지원을 하고 있으며, Msql 그리고 MySQL과 같은 관계형 데이터베이스 또한 지원을 하고 있다. 보다 많은 정보를 원한다면 “apache.kr.net” 를 참고해 보기 바란다.
|
▶ 잠깐, 이것이 궁금하세요 ? /etc/passwd 파일을 이용해 인증을 하는 방법에 대해 궁금해 하시는 분들이 있습니다. 아파치 웹서버에게 불가능한 것이 어디 있겠습니까? ^^ 물론 가능합니다. 그러나 저로서는 절대 이 방법을 권장하고 싶지 않습니다. 보안적인 문제가 가장 크겠으며, 이 이유에 대해서는 여러분들의 생각에 맡기겠습니다. |
디렉토리 접근 제한 설정하기
이 글의 목표라고 하면 목표라고 할 수 있는 디렉토리에 사용자인증을 설정하기 위하여 필요한 내용중의 하나인 인증이 실제 이루어지는 과정과 패스워드파일을 생성하는 방법에 대하여 앞에서 다루어 보았다. 이제 남은 일은 여러분 들이 원하는 디렉토리에 사용자인증이 될수 있도록 환경을 설정하는 일만 남은 것이다.
정확한 포맷형식에 맞추어져 리스트화 된 사용자 이름과 패스워드가 들어있는 파일을 이용하여 서버에 디렉토리 보호를 해주면 된다. 각각의 디렉토리에는 또 다른 유저의 이름과 패스워드가 들어있는 파일을 이용하여도 되므로, 중요한 내용의 정보는 패스워드파일을 따로 이용하여 접근제어를 하는 것도 하나의 운영방법이 될 수가 있겠다.
아파치 웹서버에서 파일 및 디렉토리를 보호하는 방법으로는 두 가지가 이용되어질 수 있는데, 하나는 디폴트로 .htaccess라 불리는 파일을 인증되기 원하는 디렉토리에 만들어 넣어두는 방법과 나머지 다른 하나는 아파치 설정파일중의 하나인 httpd.conf(or access.conf)를 이용하여 모든 접근제어를 중앙집중화 하는 것이다. 전자는 각 디렉토리에 적용되어 지므로, 그 디렉토리에 권한을 가지고 있는 사람은 쉽고 빠르게 수정 및 적용을 할 수가 있는 반면 후자의 방법은 아파치 웹서버의 설정파일을 수정하여야 하기 때문에 .htaccess와 달리 변경이 있을 시마다 아파치를 재시동해야만 한다.
.htaccess에 어떠한 내용이 들어가야 하는지 아래예제를 통해서 한번 알아보자 :
|
AuthName “staff area” // 공백이 들어갈 경우에는 “ 를 사용해야 한다. |
처음의 “AuthName” 은 보호하고자 하는 디렉토리에 대한 이름을 넣어준다고 생각하면 되겠고, “AuthType” 은 인증하는데 있어서 어떠한 방법으로 인증을 수행할 것인지에 대해 지정하는 것인데, 현재는 기본인증(Basic)만이 가능하다. Digest 라는 새로운 방법도 이용 가능하지만, 브라우저가 Digest 인증에 대한 부분을 포함하고 있어야만 하기 때문에 현 시점에서 이 방법을 도입하는 것은 시기상조일 수 있다. 아파치 설정파일에 넣어주고자 하는 경우에는 <Directory /usr/local/apache/htdocs/private>와 </Directory>의 사이 안에 위의 내용을 포함시켜주면 되며 /usr/local/apache/htdocs/private는 인증을 하고자 하는 디렉토리로 변경하여준다.
“AuthUserFile” 은 htpasswd에 의해 만들어진 파일이 어디에 위치하고 있는지 지정해 준다. 이와 유사하게 위의 예제에서는 언급하지 않았지만 “AuthGroupFile” 은 그룹파일이 어디에 있는지 서버에게 말해주는 것이다. 관리해야하는 유저가 많을 경우에는 Group으로 설정해 접근제어를 하는 것이 .htaccess파일에 많은 정보를 입력하는 것보다 관리면에서 좀더 효율적인 방법이 될 것이다. 마지막으로 남은 일은 어떠한 사용자에 대해서 접근을 허용 할 것 인지에 관한 것인데, 이것은 require 지시자를 이용하게 되며, 이 예에서는 valid-user 라는 인수를 주었다. 이 의미는 파일에 들어있는 어느 유저에 대해서도 인증을 허용하는 것이며, 다음과 같이 인수를 주면 특정 유저에 한해서만 접근을 허용 할 수 있다.
require user intexp maria
오직 intexp와 maria라는 이름을 가진 사용자만이 접근이 가능하다는 것이며, 만약 다른 유저가 접근을 할 경우에는 그 패스워드가 정확하더라 하더라도 접근이 거부 될 것이다. 이 방법은 같은 유저파일을 이용하여 각기 다른 디렉토리에 접근을 서로 다르게 설정할 때 유용하게 사용할 수 있다. 인증이 필요한 디렉토리에 접근을 하면 <그림 2> 와 같은 화면을 볼 수 있다.
올바른 유저아이디와 패스워드를 입력하면 원래의 클라이언트가 요청한 문서를 보여주게 되며, 패스워드 오류와 같은 경우에는 <그림 3> 과 같은 접근 불가 메시지를 보게 될 것이다.
|
▶ 잠깐, 이것이 궁금하세요 ? .htaccess 의 내용은 눈을 씻고 찾아보아도 정확한데 인증창이 나타나지 않는경우가 있다. 이런 경우에는 httpd.conf에서 .htaccess를 통하여 인증을 수행할 수 있도록 설정되어져 있어야 하는데 이 부분이 빠진 경우이다. AllowOverride 에 AuthConfig가 되어있나 확인해 보자. All로 되어 있는 경우 에는 따로 필요치 않으나, 필자는 All로 설정하는 것은 바람직하다고 보지 않으며 AuthConfig와 같이 필요한 기능에 대해서만 설정하여 사용하기를 바라는 바이다. |
그룹을 이용한다면 다음과 같이 사용하여 내부 직원들만이 접근하여 볼 수 있도록 설정할 수 도 있다.
require group staff
valid-user 와 마찬가지로 그룹 또한 여러 개로 설정하여 사용 되어질 수 있는데,
require group staff business
require user tech
staff, business 그룹에 속한 사용자들과 tech 사용자의 올바른 패스워드가 주어진다면 제한된 자원에 접근할 수 있는 것이다. 그룹파일의 유저구분은 공백으로 나누어진다.
staff:maria netizen4
business: blue jjlee diorkim
|
▶ 잠깐, 이것이 궁금하세요 ? 그룹파일의 한 라인 길이는 대략 8KB 정도까지 입력할 수 있다. 더 많은 유저를 그룹에 포함시키고 싶다면 다음 라인에 또 다른 그룹을 만들어 포함시켜야 한다. (설마~ 이 정도까지 되시는 분은 안계시죠? ) |
위와 같이 지시어를 통하여 서버는 어떠한 방법으로 인증을 수행하고, 유저네임과 패스워드정보를 어디에서 찾아야 할지를 알게 된다.
<그림 2>
<그림 3>
그렇다면 이 메시지를 여러분들이 원하는 대로 바꿀 수는 없을까? 여느 다른 웹사이트에서 인증에 실패하였을 때 기본 에러메시지 말고 좀더 그 사이트에 맞게 꾸며진 페이지를 한번쯤 보았으리라 생각되어진다. 사용자에게는 딱딱한 에러메시지 대신 친밀감 있어 보이는 문구 또는 페이지로 좀더 가깝게 다가 갈수도 있는 이러한 설정은 어떻게 하는 것 일까?
다행이도 우리가 지금 다루고 있는 이 아파치 웹서버는 서버에서 에러 또는 문제가 있다는 것을 검출하였을 때 응답되는 메시지를 커스트마이즈하여 보여줄 수 있다.
예를 들어, 만약 CGI 스크립트가 “500 Server Error” 라는 메시지와 함께 응답하였을 때, 이 메시지를 좀더 친근한 메시지로 교체하거나 또는 내부/외부의 URL로 리다이렉션 시킬 수 있는 것이다. 이 기능은 다음과 같이 요약될수 있으며,
1. 기본적으로 하드코딩된 메시지 대신 다른 메시지로 출력할 수 있다.
2. 로컬 URL로 리다이렉트할 수 있다.
3. 외부 URL로 리다이렉트할 수 있다.
사용하는 방법은 다음과 같다.
Syntax / ErrorDocument <3-digit-code> action
Example:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /Subscription/how_to_subscribe.html
ErrorDocument 403 "Sorry can't allow you access today
ErrorDocument 500 /cgi-bin/crash-recover
아마 눈치가 빠른 몇몇 분은 이미 ErrorDocument 뒤에 의미하는 숫자가 어떤 것을 의미하는지 파악한 분도 있을 것이다. 이 숫자가 의미하는 뜻은 서버 에러 코드 번호이다. 이것을 사용할경우 한가지 주의할점은 텍스트를 표시하고자 하는 경우에는 (“)를 앞에만 써주며 문구가 끝날 때 는 붙이지 않는다는 것이다. 처음의 (“) 은 출력되어지지 않으며 이후에 나오는 것은 출력이 된다. 인증에 실패 하였을 때에 <그림 4>와 같이 커스트마이즈된 에러메시지를 볼 수가 있다.
▶ 잊지마세요 !!! ErrorDocument 지시어를 사용하여 401 코드에 대하여 에러메시지를 작성할 경우, 외부 URL 로 리다이렉트 시킬 수는 없다. 이 이유는 인증구조상 그렇게 설계되어져 있기 때문이다. |
<그림 4>
이 방법이 인터넷상에서 정말 안전한가?
정말 안전할까? 아마 여러분들은 클라이언트의 브라우저와 웹서버 사이에 패스워드가 아무런 암호화 없이 전송 되어 진다는 것을 알면 놀라게 될 것이다. 물론 100% 문자 그대로(Clear TEXT)전송 되는 것은 아니며, 유저네임과 패스워드를 ASCII 에서 Base64 형식으로 엔코딩하여 전송한다.
하지만 대부분의 사람들은 이 방법이 매우 안전하지 않은 방법이라 생각을 한다. 그 이유는 Base64 형식으로 엔코딩되어 있기 때문인데 단순 Clear TEXT 보다는 캡쳐해내는 것이 더 어렵지만 그래도 완전히 확신할 수는 없는 법이다. 따라서 이런 보안적인 면을 최소화하기 위해서는 여러분들의 시스템에 등록되어 있는 /etc/passwd 의 유저네임과 패스워드를 웹상에서의 유저 인증을 하는데 사용되지 않도록 하여야 한다. 또한 외부에 유출되어져서는 안될 중요한 문서는 Web 상에 올려지지 않도록 주의하여야 한다. 그러나 시스템이 외부의 공격에 많이 노출되어져 있다면 이러한 노력도 수포로 돌아갈 것이다. 왜냐하면 100% 완벽한 방어란 있을 수 없고 또 그 상대가 익명으로 접근해오는 수 많은 크래커들이라면 그 중 일부가 여러분의 컴퓨터에 침입할 수 있을지도 모르며 순간적으로 막대한 양의 자료를 유실하거나 훼손할 수 있기 때문이다.
이러한 기본인증구조와 달리 초반에 잠깐 언급한 “Digest“ 라는 인증을 이용하게 되면 유저네임과 패스워드에 추가적인 파라미터를 덧붙여 전송하게 되며, 기본인증 방법보다는 안전하게 전송할 수가 있다.
MD5 Digest 인증방식은 의외로 아주 간단하다. 기본인증설정과 같이 간단하지만 Digest에 대한 부분은 한정된 지면상으로 자세히 다루지는 못하고, 잠깐 살펴보기로 한다. 아래 예를 보면 알겠지만, Basic인증때 사용하던 AuthType Baisc 과 AuthUserFile 이 “AuthType Digest” 와 “AuthDigestFile” 로 대신 바뀌었다. 또한, “AuthGroupFile” 이 “AuthDigestGroupFile” 로 바뀌었으며, “AuthDigestDomain” 이라는 새로운 것이 추가되었다.
<Location /private/>
AuthType Digest
AuthName "private area"
AuthDigestDomain /private/ http://mirror.my.dom/private2/
AuthDigestFile /web/auth/.digest_pw
require valid-user
</Location>
참고: MD5 인증은 Basic 인증방식보다 보다 안전한 방법의 인증을 제공해 주고 있기는 하나 MD5 Authentication 을 지원해주는 브라우저에서만 작동한다. 현재 필자가 알고있는 바로는 많이 사용하는 브라우저중의 하나인 인터넷익스플로서 5.0 이 Digest Authentication 을 지원하는 것으로 알고있다. 그러므로, 규모가 큰 인터넷사이트를 운영하고자 할 경우에는 이 모듈을 사용하는것을 권장하지 않는다. 그러나 회사 내부에서 사용하는 브라우저가 명시적으로 지정되어져 있다면, 인트라넷용도로 이 Digest 모듈을 사용해 보는것도 보안을 좀더 높일 수 있는 방법중의 하나다.
이로써 아파치 웹서버에서의 사용자 인증하는 부분을 끝마쳤다. 끝내기 전에 여러분들에게 한가지 전해주고 싶은 말은 이 글을 읽었다면 절대 읽는 그 자체에 준하지 않고 꼭 실행에 옮겨보라는 말을 전해주고 싶다. 백번보는 것보다 한번 수행해 보는 것이 그야말로 진정한 경험이며, 여러분들의 웹서버 운영에 큰 도움이 될 것 이다.
Enjoy!
Copyright (c) 2000 Kwan-jin,Jung All Rights Reserved.
