안녕하세요, IISKOREA 팀블로그의 송원석 입니다.
만일 개발자분들과 시스템 관리자분들, 그리고 그 밖에도 IIS 에 관심을 갖고 계시는 많은 분들에게 기존 버전의 IIS 에서 부족한 부분을 지적해달라고 요청해본다면, 아마도 그 중 수위에 FTP 서비스에 대한 불만이 자리잡고 있을 것이라는 것이 제 개인적인 의견입니다. 사실상 그 동안 IIS 에 기본적으로 포함되어져 있던 FTP 서비스의 기능이 대단히 미약했었기 때문에, 많은 분들이 이에 대한 개선을 열망해 왔던 것이 사실입니다.
물론 다양한 이유들을 찾아볼 수 있겠지만, 그 중에서 제가 생각하고 있는 대표적인 문제점 몇 가지를 정리해보면 다음과 같습니다.
- 가장 첫 번째 문제점은 로그인에 적용할 수 있는 사용자 계정의 유형이 제한되어져 있다는 것입니다. 즉, FTP 서비스가 운영되는 서버의 로컬 계정이나 엑티브 디렉터리의 계정을 통해서만 FTP 서비스에 로그인이 가능했던 것이죠. 즉, 데이터베이스에 저장된 임의의 사용자 아이디와 비밀번호 등을 사용하여 FTP 서비스에 로그인 할 수 있는 제 3 의 방법이 전혀 제공되지 않았던 것입니다.
이 점이 문제가 되는 것은 바로 비용 때문입니다. 결국 위의 얘기가 의미하는 바는 모든 사용자들에게 윈도우 계정을 하나씩 제공해야 한다는 뜻이고, 이는 결과적으로 라이센스 비용이 증가한다는 의미가 됩니다. (물론 IIS 가 서비스되는 윈도우 서버와 같이 불특정 다수가 접근하는 윈도우 서버의 라이센스 이슈에는 조금 더 복잡한 내용이 포함되어 있다고 알고 있습니다만, 본문에서는 간단한 설명을 위해서 무시합니다. 이에 대해서는 다른 분이 보다 정확한 내용을 올려주시기를 기대합니다. ^_^) 즉, 웹 호스팅 업체가 윈도우 기반의 서버를 이용하여 서비스를 제공한다고 가정해 볼 때, 1,000 명의 고객을 갖고 있다면 1,000 개의 계정을, 2,000 명의 고객을 갖고 있다면 2,000 개의 계정을 만들어야만 하고, 그 계정 수 만큼의 라이센스 비용을 지불해야만 하게 되는 것이죠. 따라서, 결론은 비용이 지나치게 높아진다는 것입니다. - 두 번째 문제점은 가상 호스트 기능이 제공되지 않는다는 점이었습니다. 반면, IIS 의 WWW 서비스는 이미 예전부터 이 기능을 제공해주고 있었지요. 이번에도 역시 앞의 예를 다시 들어 보겠습니다. 1,000 명의 고객을 확보하고 있는 웹 호스팅 업체가 있다고 가정해볼 때, 이 1,000 명의 고객을 위해서 각각 IP 를 1,000 개나 확보하는 것은 현실적으로 불가능합니다. 그리고 설령 가능하다고 하더라도, 역시나 다시 한 번 비용이 문제가 됩니다.
따라서, 이런 경우에는 보통 가상 호스트 기능을 사용하여 IP 와 Port 는 공유하지만 도메인 명을 달리 부여하는 방식으로 해결하게 됩니다. (이를 프로그래밍적인 용어로 유니크한 서버 바인딩 정보를 부여한다고 표현합니다. 서버 바인딩 정보, 즉 IP + Port + 호스트 명의 조합은 한 IIS 내에서 유일해야만 하는데, 이 세 가지 요소 중에서 호스트 하나만 유니크하게 부여되면 IP와 Port 는 여러 번 사용이 가능한 것을 이용한 것입니다.) 그러나, FTP 서비스에서는 지금까지 이 기능을 지원해주지 않았기 때문에, 타사의 FTP 서버 제품을 사용하지 않는다면, Port 를 여러 개로 찢어서 사용하는 등의 방법을 사용할 수 밖에 없었습니다.
이 문제로 인해서 비단, 웹 호스팅 업체가 아니더라도 여러 가지 재미있는 서비스를 구현하는데도 문제가 많았습니다. 한 가지 예를 들어 볼까요? http://www.domain.co.kr/ 이라는 도메인으로 서비스를 제공하는 커뮤니티 업체가 있다고 생각해보죠. 그리고 아이디가 asp 인 사용자와 idc 라는 두 명의 사용자가 있다고 가정해보겠습니다. 이 업체에서는 IIS 를 사용하여 다음과 같은 도메인을 제공하면서 단 하나의 IP 주소로 이 사용자들에게 미니 사이트(가칭)를 서비스 해줄 수가 있을 겁니다.- asp 사용자의 미니 사이트 : http://asp.domain.co.kr/
- idc 사용자의 미니 사이트 : http://idc.domain.co.kr/
- asp 사용자의 개인 FTP 서비스 : ftp://ftp.domain.co.kr:8001/
- idc 사용자의 개인 FTP 서비스 : ftp://ftp.domain.co.kr:8002/
그러나, 만약 FTP 서비스를 위해서 다음과 같은 도메인을 사용할 수 있었다면 금상첨화였을 것입니다. 프로토콜이 http:// 가 아니라 ftp:// 로 지정되었다는 점에 유의하십시오.
- asp 사용자의 개인 FTP 서비스 : ftp://asp.domain.co.kr/
- idc 사용자의 개인 FTP 서비스 : ftp://idc.domain.co.kr/
- 세 번째 문제점은 흔히 쿼터라고 얘기하는 사용자별 용량 제한을 지정할 수가 없었고, 단일 FTP 사이트 내에서 사용자들의 격리가 자유롭지 않았다는 점입니다. 웹 호스팅 업체에서는 보통 제공해주는 용량에 따라서도 과금 내용이 달라지므로 사용자별 용량 제한을 관리하는 작업은 거의 필수적이라고 볼 수 있을 것입니다. 반대로 기업체 등에서는 하나의 FTP 서비스를 운영하면서 사원들을 직급별, 업무별로 접근할 수 있는 디렉터리 등을 제안해야 할 필요가 있습니다. 이를테면 과장급 이상은 '경영계획'이라는 디렉터리에 접근할 수 있지만, 평사원이나 대리급에서는 해당 디렉터리에 접근이 불가능하다던지 말입니다. 물론, 최근에는 이런 서비스들의 경우, 웹 하드나 기타 웹 기반의 시스템을 통해서 제공해주는 추세이긴 합니다만, 기술적으로는 그렇다는 말입니다.
그러나, 지금까지의 FTP 서비스에서는 이를 세부적인 부분까지 조절할 수 있는 방법이 없었지요. 사실 윈도우 서버 2008 및 R2 에서는 쿼터와 사용자 격리에 대한 기능을 구현할 수 있는 방법이 제공되었던 것으로 알고 있습니다만, 아쉽게도 그 기능이 입맛게 딱맞게 제공되지는 않았었고 그리 큰 반향을 얻어내지도 못한 것으로 압니다. - 그리고, 마지막으로 제가 지적하고 싶은 부분은 바로 보안이 취약하다는 점입니다. 비단 이 문제는 IIS 가 제공해주는 FTP 에 관한 문제가 아닌, FTP 라는 프로토콜이 갖고 있는 근본적인 문제점이긴 합니다만, 그래도 문제는 문제니까요. FTP 프로토콜 자체가 보안에 대한 부분에 대단히 취약하기 때문에, 비밀번호 뿐만 아니라 데이터의 흐름도 너무나 손쉽게 노출되는 등의 문제점들이 있었습니다.
이렇듯 기존의 FTP 서비스가 갖고 있던 문제점들은 결코 사용자들이 간과할 수 있는 수준이 아니었고, 그래서 보통은 서드파티 업체들의 제품을 사용할 수 밖에 없는 상황이 아니었나 싶습니다. 그러나 FTP 7.x 에서는 상황이 바뀌었죠. 최소한 제가 지금까지 언급했던 문제점들은 모두 해결되었습니다. 자 그러면, 다음 포스트에서 부터는 차근차근 한 가지씩 어떤 부분들이 어떻게 개선되었는지를 살펴보도록 하겠습니다.
감사합니다.
Comments