IT 종합뉴스서비스

[지디넷코리아]이 내용은 필자가 여러 번 강조했던 이야기이다. 그리고 그다지 프로그래밍을 하는데 번거로움이 존재하지도 않는다. 하지만, 다들 그다지 즐기지는 않는 것만 같아 책을 통해서 다시금 이야기하고자 한다. ASP관련 보안문제가 발생할 경우 가장 문제가 되는 것은 데이터베이스 연결계정이 외부로 노출된다는 것이다. 이 계정이 비록 가장 제한적인 계정이라고 하더라도, 이 계정을 통해서 웹과 연관된 데이터베이스는 완전하게 공개가 되어지게 된다. 물론, 중요한 알고리즘이나 로직이 공개되어지는 것이 두려울 수도 있지만, 가장 큰 문제는 역시 데이터베이스의 공개여부일 것이다.

필자는 이에 대해서 데이터베이스 연결문자열을 하나의 파일에 저장해놓고, 웹 어플리케이션에서 분리하기를 추천한다. 그리고, ASP 페이지에서는 FileSystemObject를 통해서 이 파일의 내용을 가져오게 하는 것이다. 이렇게 되면 ASP 소스가 오픈되어도 데이터베이스 연결문자열은 공개되어지지 않을 것이며, 적어도 데이터베이스의 안전은 어느 정도 안심할 수 있게된다. 잘 이해가 가지 않는다면 다음 예를 보도록 하자.

대부분의 ASP 페이지에서 데이터베이스를 연동하는 부분은 다음과 같은 코드들이 존재한다.

<%

Option Explicit



Dim Con

Dim strConnect, sql, LngRecs



strConnect = "Provider=SQLOLEDB.1;Persist Security Info=False;" & _

     "User ID=sa;Initial Catalog= pubs;DataSource=TAEYO;Password=avc"



set Con = Server.CreateObject("ADODB.Connection")

Con.Open strConnect

......

......

물론, 이러한 데이터베이스 연결문자열이나 Connection Open 과정을 따로 함수로 때어내던가 하나의 ASP 파일로 만들어서 사용하고 있을 수도 있을 것이다. SSI 로써 말이다. 하지만, 이도 역시 결과적으로는 위와 같은 모습이다. 어쨋든 데이터베이스 연결계정은 완전하게 보안에 노출되어져 있는 것임에는 틀림이 없다. 게다가 위의 경우는 최악이다. 데이터베이스 연결계정으로 어드민계정인 sa를 사용하고 있으니 말이다. 가장 제한적인 계정이 아닌 어드민 계정이 노출되었으니 여러분의 데이터베이스는 그 전멸의 위기가 눈앞에 놓여있다고 보아도 과언은 아니다.

그렇다. 연결문자열은 대단히 중요하다. 그렇기에 필자는 이 연결문자열을 ASP 페이지에 바로 넣어서 사용하지 말라고 조언하고 싶다. 이를 완전하게 웹에서 분리시키라고 권유하고 싶은 것이다. 해서 필자가 제안하는 방법은 다음과 같다.

이 연결문자열을 하나의 Dat 파일로 만들어서 로컬서버의 루트나 기타 디렉토리에 따로 저장하게 하라. 그 위치는 결코 웹 디렉토리가 아닌 구역에 있어야 할 것이다. C:\ 도 나빠보이지는 않는다. 다음처럼 말이다.

Provider=SQLOLEDB; User ID=계정아이디;Initial Catalog=pubs;Data Source=

데이터베이스 서버이름;Password=암호

ConnectString4Web.dat



Dat 파일을 C 루트에 지정하자

그리고, 데이터베이스 연결문자열이 필요한 ASP 페이지에서는 다음과 같이 FileSystemObject를 통해서 ConnectString4Web.dat에서 그 문자열을 가져와 사용하게 구성하는 것이다.



<%

Option Explicit



Dim Con, fso, f

Dim strConnect, sql, LngRecs



set fso = Server.CreateObject("Scripting.FileSystemObject")

set f = fso.OpenTextFile("C:\ConnectString4Web.dat")

strconnect = f.Readline



set Con = Server.CreateObject("ADODB.Connection")

Con.Open strConnect

.....

소스에서 볼 수 있다시피 데이터베이스 연결문자열은 이제 완전하게 웹에서 모습을 감추었다. 그 연결문자열은 C 루트에 파일속에 존재하고 있기에 직접 로컬 PC 앞에 앉아서 로그온하지 않으면 그 문자열정보를 알아낼 수가 없다. 여러분은 위에서 추가된 굵은 부분의 소스를 따로 하나의 ASP 페이지로 만들어 인클루드해서 사용할 수도 있다. 그러한 것은 여러분의 선택의 자유이다.

FSO로 연결문자열을 읽어오는 부분을 Global.asa에서 수행하고 그 연결문자열을 어플리케이션 변수에 담아놓는다면, 매 페이지마다 위와 같은 로직을 수행할 필요없이 그 어플리케이션 변수를 사용할 수 있을 것이다. 그리고, 이는 약간의 성능향상을 가져다 줄 것이다.

이 방법은 여러분의 사이트의 데이터베이스 연결문자열을 완전하게 숨길 수 있도록 하였다. 하지만, 그 외에 다른 ASP 코드들은 백도어로 인해 완전하게 노출되어진다. 중요한 비즈니스 로직이나, 알고리즘 같은 것이 이러한 백도어로 누출되는 것이 여러분은 또한 걱정될 것이다.

그렇다면, 이들의 공개까지도 막을 수 있는 방법은 없을까? 없다면 이야기를 꺼내지 않았을 것이다. 그것은 바로 컴포넌트의 제작, 즉 COM의 사용이다. 사이트의 중요한 비즈니스 로직들을 분류하여 각각의 비즈니스 COM 개체로 만들게 된다면 이들은 서버상에 DLL로 존재하게 되며, ASP 소스 Open 에도 상관없이 모든 로직들을 COM안으로 숨어들 수 있을 것이다. 또한 이는 유지보수나 확장성면에서도 기존의 ASP 페이지보다 뛰어난 성능을 가질 수 있다.

비즈니스 로직이 바뀌면 단지 COM내부의 로직만을 수정하면 되는 것이니 말이다. 이것이 COM의 필요성이다. 사이트의 보안에 완전하게 대처할 수 있는 기본적인 방법. IIS 보안문제에 미연에 대비하는 것은 Windows DNA에 맞추어 비즈니스 로직들을 COM 개체로 분리시키는 것이다.

해서, 이제의 여러분은 COM, COM+ 등의 마이크로소프트의 최신 기술에도 눈을 조금씩은 주어야 할 시기가 된 것이다. @