3. DB 접근제어 구축

가. 우회 접근 방지

DB 접근제어를 아무리 체계적으로 갖추어도 해당 서버를 경유하지 않고 DB 서버에 접속 할 수 있도록 허용하면 아무런 의미가 없다. 그러므로 DB 접근제어 솔루션이 정상적으로 동작하게 하려면 반드시 우회 접근을 차단(혹은 최소한 행위에 대한 로깅)하도록 설정하여 야 한다.
특히, 프록시 게이트웨이 방식은 우회방지 정책을 수립하여야 한다. 프록시 게이트웨이 방식으로 설치한 경우, DB 접속 시 프록시 서버를 경유하도록 강제하기 위하여 내부 사용 자 단말기에 전용 프로그램을 설치하거나, 접속 정보가 저장된 파일(Oracle의 경우 tnsnames.ora)을 수정하여 프록시 서버를 경유하도록 설정한다.
이런 경우에 DB 사용자가 임의로 툴을 제거하거나, 해당 파일을 직접 접속이 가능하도록 변경한 후 접속하면 프록시 게이트웨이 서버는 해당 사실을 인지할 수 없게 된다. 따라서 DB 접근제어가 불가능해 진다. 또한 다른 방법으로 서버가 있는 전산실에 들어가 Dummy 콘솔로 직접 서버에 접속하여 작업하는 방법이 있다. 이런 경우에도 프록시 서버 에는 아무런 패킷이 들어오지 않아 해당 서버에 대한 작업 통제는 물론 감사를 위한 로깅 기능까지 모두 무력화된다.

앞의 설명에서와 같이 DB 서버를 우회하여 접속하는 것을 차단하는 방법은 다양하므로 시 스템의 구성여건 및 도입된 솔루션을 참고하여 우회차단 방안을 수립하여 구축하여야 한다.

1) 차단 방법
① 에이전트(Agent) 설치에 의한 차단
에이전트 방식으로 DB 접근제어 솔루션이 설치된 경우에는 콘솔 등을 이용하여 DB 서버 에 직접 접근하더라도 차단할 수 있다. 다만, 에이전트 방식의 경우에 DB 서버에 직접 설 치하여 운영하므로 기존 서버에 대한 영향을 최소화하여야 한다. 이런 이유로 애플리케이 션 서버 IP에서 접속하는 세션의 경우에는 바이패스를 하도록 설정하는 것이 일반적이다. 애플리케이션 서버 IP에서 내부 사용자가 접속을 하는 경우 우회할 수 있는 통로가 될 수 있으므로, 애플리케이션 서버에서 DB 서버로 접속할 수 있는 환경을 제거하여야 한다.
에이전트가 설치된 경우에도 에이전트의 방식에 따라 우회 통로가 있을 수 있다. 즉, 특정 툴을 hooking하는 방식으로 에이전트가 동작하는 경우에는 해당 툴을 사용하지 않고 접 속하는 세션에 대해서는 통제가 불가능하다. 따라서, 이러한 경우에는 해당 툴을 사용할 수 없도록 하거나 통제가 불가능한 툴을 사용하는 경우에 대비한 별도의 보안대책을 수립 하여야 한다.
② 서버 보안에 의한 차단
서버 보안이란 운영체제의 Kernel에 프로그램을 설치하여 특정 API가 호출될 때, 권한을 점검하여 권한이 있는 경우에만 실행하도록 OS의 보안기능을 강화하기 위한 솔루션이다. DBMS가 설치된 서버에 설치할 수 있으며 특정 프로그램 혹은 특정 포트(Port)에 대한 접 근을 제어할 수 있는 기능을 가지고 있다. DBMS에 대한 접근은 DB 리스너(Listener)가 대기하고 있는 포트에 접속 요청 패킷을 보내 접속을 시도하게 되는데 이때, 서버 보안은 접속을 요청하는 쪽의 신원을 파악하여 권한이 있는 경우에만 접속을 허용하도록 설정할 수 있다.
서버 보안에 의한 차단을 이용하여 DB 접근제어 서버 등 인가된 IP에서 접속하는 경우에 는 접속을 허용하고 비인가 IP에서 접속을 시도하는 경우에는 접속을 차단하여 DB 접근제 어 서버를 우회하여 접근하려는 시도를 차단할 수 있다. DB 접근제어 서버 이외에 DB Link 등을 통하여 DB간 직접 연결이 필요한 경우에는 접속 이 가능한 DB 서버는 모두 인가된 사용자로 포함하여 설정하여야 한다.

다만, 인가된 IP로 인정되어 DB 서버에 접근하는 경우, 해당 세션이 DB 접근제어 솔루션 을 경유하지 않은 경우 등은 통제가 불가능하므로 인가된 IP 관리에 매우 주의를 기울여야 한다.

③ 스니핑 방식에 의한 차단
스니핑 방식의 경우 기본적으로는 DB 서버에 대한 영향없이 패킷을 복사하여 로깅하는 기 능을 제공한다. 솔루션에 따라 로그인 된 세션이 권한 로그인 권한이 없거나 권한이 없는 SQL을 수행할 경우 해당 세션을 종료시키는 기능을 제공하고 있다.
스니핑 방식에 의한 차단을 이용하여 우회접근을 방지할 수 있다. 프록시 게이트웨이 서버 를 경유하지 않고 DB서버에 로그인 한 것에 대해 차단하도록 설정을 하면 우회하여 로그 인한 세션을 차단할 수 있다.

다만, 이 방법을 사용할 경우 사전에 철저한 테스트가 필요하다. 스니핑 서버 구성의 경우 조직의 일반 업무 혹은 대외 서비스 애플리케이션 서버에서 로그인하는 세션의 경우에도 로깅하도록 설정하는 것이 일반적이다. 이것이 가능한 이유는 스니핑 방식이 기존 서버에 미치는 영향이 없어서 장애 시에도 서비스가 중단되는 사태가 없기 때문이다. 그런데 스니 핑 서버에 차단 기능을 부여하면 차단 기능이 정상적으로 작동하지 않아서 업무 서버의 세 션을 차단하는 경우도 발생할 수 있으므로 충분히 테스트하여 장애 상황이 발생하지 않도 록 하여야 한다.
스니핑 방식으로 우회차단 기능을 설정하더라도 전산실 내부에서 콘솔을 이용하여 직접 서버에 접속하는 경우를 통제할 수 없다. 따라서, 콘솔 등의 이용에 대한 별도의 보안대책 을 수립하여 시행하여야 한다.

④ N/W 장치에 의한 차단
DB 서버에 대한 접근 시에 네트워크 접근을 통제할 수 있는 Firewall 같은 통제 장치를 경 유하는 경우에는 해당 장치를 통하여 통제할 수 있다. 예를 들어, 출발지 IP, 포트 정보와 목적지 IP, 포트 정보 등을 통하여 직접 DB 서버로 접근을 시도하는 세션을 차단할 수 있 다. 다만, 내부 사용자와 DB 서버가 동일 건물 내에 있어서 이런 통제 장치가 없는 경우가 많은데 이런 경우에는 별도의 통제 방법을 사용하여야 한다.

⑤ DBMS 기능을 이용하여 차단
DBMS자체에서 접속이 가능한 IP 혹은 접속을 차단하여야 하는 IP를 설정하도록 하는 기 능을 제공하는 제품이 있다. 또한, 로그인 시에 작동되는 로그인 트리거를 제공하는 제품 도 있다. 이런 기능을 이용하여 우회 접속에 대한 차단이 가능하다.
■ DB 접속 가능 IP 통제
오라클에서 임의의 사용자에 의한 원격 접속을 차단하기 위해 리스너(Listener)의 IP 접근제한을 설정할 수 있다. 특정 클라이언트에서의 접근만 가능하도록 접근 가능 IP 를 설정하여 불필요한 외부 사용자 접근을 차단한다.
환경설정 파일에서 접근 가능한 IP 대역과 접근 불가능한 IP대역을 설정하여 네트워크 접 근제어를 할 수 있다. 오라클 8i 버전에서는 $ORACLE_HOME/network/admin/protocol. ora파일에, 오라클 9i 이후 버전에서는 $ORACLE_HOME/network/admin/sql- net.ora 파일에 설정을 한다.
SQLNET.ORA 및 PROTOCOL.ORA파일을 OS상에서 텍스트 편집기로 열어 다음과 같 이 편집하여 설정한다.

tcp.validnode_checking를 YES 로 설정한 후 접속을 허용·차단할 IP 또는 호스트 네 임을 ','를 구분자로 하여 넣어주면 된다.
다음과 같이 접근을 제어할 IP를 넣어 설정할 수 있다.

TCP.VALIDNODE.CHECKING = YES
TCP.INVITED_NODES =(192.168.10.1, 192.168.10.3, abc.com)
TCP.EXCLUDED_NODES =(192.168.20.0)
tcp.invited_nodes 만을 사용할 경우 허용된 IP에서만 접근이 가능하며 그 외의 IP에 대 해서는 접근이 불가능하다. 이때 DBMS 서버의 IP를 추가해주어야 하며 접근제어 서버의 IP도 추가해 주어야 한다. 애플리케이션 서버의 경우에는 안정성을 위하여 프록시 게이트 웨이 서버를 경유하지 않고 직접 DB 서버에 접속할 수 있도록 허용해야 한다. 따라서, 모 든 애플리케이션 서버의 IP를 포함하여야 한다. 또한, DB Link에 의해서 DB 서버로 직 접 접속하는 것이 필요한 경우에는 접속을 허용할 DBMS 서버의 IP들도 포함하여야 한 다. tcp.excluded_nodes를 같이 사용하여 차단할 IP를 추가하여도 된다.
SQLNET.ORA 및 PROTOCOL.ORA파일을 수정한 후에는 리스너를 재시작해야 해당 설정이 적용된다.

■ 로그인 트리거를 이용한 통제
DBMS에서 제공하는 로그인 트리거 혹은 로그인 시에 수행되는 프로시저를 이용하는 방 식이다. 로그인 트리거란 DBMS에 로그인 하려고 하는 경우 작동하는 트리거이고, 로그 인 프로시저는 DBMS에서 로그인 시마다 항상 수행하도록 되어 있는 프로시저이다.
오라클의 경우 다음과 같이 트리거를 만들 수 있다.

사이베이스 IQ의 경우에는“sp_iq_process_login”라는 프로시져가 IQ에 로그인하는 모 든 사용자에 대해 수행되도록 되어 있다.
이 경우 다음과 같이 특정 IP에서 오는 경우를 제외한 나머지 모든 세션은“'DB 보안접속 을 하셔야 하다.”라는 경고 메시지와 함께 로그인 접속을 차단하도록 설정할 수 있다.

MS-SQL 2005 SP2 부터 MS SQL 서버도 로그인 트리거를 제공하는데, 다음과 같은 구 조로 로그인 트리거를 생성하여 로그인한 사용자를 통제할 수 있다.

2) 주요 체크 사항 DB 접근제어 시스템이 완벽하게 접근을 제어하려면, 반드시 우회하여 접근하는 통로를 차단하여야 한다. 다음과 같은 사항들을 점검하여 우회방지가 제대로 구현되어 있는지 확 인한다.

① DB 서버 직접 접근
Telnet, SSH 등을 통하여 DB 서버에 로그인 한 후, DB에 접근하는 것에 대해 대응책이 수립되어 있어야 한다. 프록시 게이트웨이 등이 설치되어 있는 경우에는 Telnet, SSH 로 접근하는 경우에도 프록시 게이트웨이를 경유하도록 하여 최소한 로그를 남기는 기능을 제 공하기도 하므로 이런 방법을 사용하거나 별도의 솔루션을 통하여 접근을 제어해야 한다. 전산실에 출입이 가능한 관리자의 경우에는 직접 DB 서버에 콘솔 등의 장비로 직접 연결하 여 작업할 수 있다. 이런 경우에도 통제를 하거나 행위에 대한 로깅 방안을 수립하여야 한다.

② WAS 서버에서 접근 통제
WAS 서버에서 DB 서버로 접근하는 경우는 일반적으로 통제하지 않는다. 왜냐하면 WAS 서버에서 오는 세션을 프록시 게이트웨이 등을 이용하여 통제하는 경우에는 속도가 느려 지고 장애시 업무에 많은 영향을 줄 수 있기 때문이다. 이런 경우 대책이 필요한데 가장 쉽 게 할 수 있는 방법은 WAS 서버에서 DB에 접근할 수 없도록 관련 툴을 제거하는 것이다. 예를 들어, 오라클을 사용하는 경우에 오라클 클라이언트를 WAS 서버에 설치하지 않는 것도 좋은 방법이다. 물론 WAS는 JDBC 방식으로 접근해야 하므로 그에 대한 라이브러 리는 설치해야 한다. 만일 WAS 서버에서 JDBC 이외의 방법으로 DB에 접근을 허용해야 하는 경우에는 서버 보안 솔루션을 설치하여 접근을 통제할 수도 있다. 다른 방법은 스니 핑 기능을 이용하여 차단하거나 접근하여 수행한 모든 작업에 대한 로깅을 하는 것이다.

③ DB 사용자 단말기 프로그램 점검
프록시 게이트웨이를 설치한 경우에는 DB 로그인 시 프록시 서버를 경유하도록 하는 프로 그램을 설치한다. 일반적으로 이런 프로그램은 DB 사용자가 임의로 삭제할 수 없도록 해 야 한다. 또한, DB에 접속이 가능한 모든 사용자는 반드시 해당 프로그램을 설치한 후에 DB에 접속하도록 하여야 한다.

나. 환경 보완

DB 접근제어와 관련하여 설치되는 서버는 DMZ 내부에 위치하며 DBMS와 동일 수준에 서 안전하게 관리되어야 한다.
DB 접근제어 서버가 안전하게 관리되지 않으면 접근제어 규칙을 임의로 변경하여 권한이 없는 DB 서버에 접근할 수도 있고, 접근제어 서버가 수집한 각종의 로그 정보를 훼손할 수 도 있다. 따라서, 이를 방지할 수 있도록 환경 설정을 해야 한다.

1) 주요 관리 대상
보안의 기본 원칙 중의 하나가 역할의 분리(Separation of Duty)이다. 이에 따라 시스템 (DB)관리자와 보안 관리자의 역할을 동일한 사람이 수행해서는 안된다. DB 접근제어 서 버에 대한 관리는 시스템(DB)관리자가 담당하지만, DB 접근제어 서버에 설치된 DB 관리 자 솔루션에 대한 관리 권한은 보안관리자가 수행해야 한다.

① OS 계정 보호
DB 접근제어 서버에 대한 계정을 보호해야 한다. DB 접근제어 서버는 제한된 사용자만 접근이 가능해야 하며 불필요한 계정은 삭제하여야 한다. 루트(root) 계정에 대한 패스워 드는 시스템(DB)관리자가 관리한다. 또한, 조직의 패스워드 정책에 따라 안전한 길이의 패스워드를 사용해야 하고 주기적으로 변경해 주어야 한다.
또한, DB 접근제어 솔루션이 설치된 OS 계정의 패스워드도 보안정책에 따라 관리해야 한다.

② DB 접근제어 관리자 계정 보호
DB 접근제어 관리는 관리자가 1인으로 관리를 하는 경우도 있고, 관리자를 세분화하여 관 리할 수도 있는데, DB 접근제어 솔루션에 따라 관리자 정책이 다르다.

DB 접근제어 서버 관리자는 DB 접근제어 정책에 대한 전반적인 사항을 관리하는 책임을 가짐으로 모든 보안 규칙의 설정과 해제의 권한을 가진다. 그러므로 DB 접근제어 서버 관 리자 중에서 최고의 권한은 1인에게만 부여하여 관리하고, 다른 관리자의 경우에는 운영 하는데 필요한 최소의 권한만을 설정하여 관리하여야 한다.

③ 포트 보호
DB 접근제어 서버의 포트도 필요한 포트만을 개방하여야 한다. 관리를 위해 SSH 통신을 위한 포트가 필요하다. 솔루션에 따라 웹 기반으로 동작하는 경우에는 80 포트가 필요하 며, 클라이언트 서버 방식으로 관리 툴을 제공하는 경우에는 로그인을 위한 포트가 개방되 어야 한다. 이외에도 프록시 게이트웨이의 경우에는 DB 리스너와 DB 사용자 사이의 세션 중계를 위해 별도의 포트가 필요하다.

2) 주요 체크 사항
DB 접근제어 솔루션이 안전한 환경에서 운용되도록 유지하여야 한다.

① OS 계정 보호
DB 접근제어 솔루션이 설치된 서버의 Root 계정이나, 설치 계정은 패스워드 등을 통해 접근을 통제하여야 한다. 그리고 불필요한 OS 계정이 서버에 설치되어 있지 않도록 관리 하여야 한다.

② DB 접근제어 솔루션 계정 보호
DB 접근제어 솔루션에 로그인하여 보안 정책 등을 변경하고 이력을 조회할 수 있다. 많은 조직에서 DBA 1인에게 DB 관리 권한 및 DB 접근제어 솔루션 관리권한을 일임하는 경우 가 있는데 반드시 분리하여야 한다.

③ OS 취약점 점검
접근제어 솔루션이 설치된 서버의 OS 상에 취약점이 있는지 점검하여야 한다. 취약점이 발견된 버전의 경우에는 패치를 적용하여 취약점을 제거하여야 한다. 또한, 사용하지 않 는 포트는 시스템 구성 파일에서 사용할 수 없도록 설정되어 있는지 확인한다.

다. 보안적용 시험

DB 접근제어 솔루션을 구축한 후에 각각의 기능들이 제대로 동작하는지 시험을 실시하여 야 한다. 개발 혹은 테스트 DB가 별도로 구축되어 있는 상태에서 DB에 대하여 DB 접근제 어가 구축된 경우에는 해당 환경에서 시험을 실시한다. 시험의 결과는 '시험결과서' 산출물 로 관리되어야 한다.

1) 시험 항목
DB 접근제어 구축 후 시험을 해야 하는 사항은 구축된 내용에 따라 다르지만 기본적으로 시험을 해야 하는 기능은 다음과 같다.

앞의 표에서 명시된 테스트 항목 이외에도 조직의 필요에 의하여 다른 기능들을 추가로 시 험하거나 앞의 항목에 대하여 세분화하여 자세히 테스트 할 수 있다.

■ 시험 환경 구성
다음 그림은 시험환경을 구성한 사례이며 실제 시험은 요건에 따라 다르게 구성할 수 있다.

DB에 접속할 단말기는 2대를 준비하여 1대는 접속이 가능한 규칙 점검, 다른 1대는 접속 이 불가능한 사용자에 대하여 차단이 정상적으로 수행되는지 여부를 테스트 한다. 또한, SQL을 수행하는 툴을 설치하여 일정량의 SQL 수행 시에 DB 보안 서버의 지연(delay) 기 간 측정이나, 패킷 손실이 얼마나 발생하는지 등의 테스트를 진행한다.

2) 시험 관리 및 추가 시험
DB 접근제어를 위해 필요한 기능을 명시하고 해당 기능이 정상적으로 동작하는지 확인해 야 한다.

① 기능 시험서
'가. 방법'에서 제시한 필수 기능과 함께 부가적으로 조직에 필요한 기능을 추가하여 시험 을 실시한 후 시험결과서를 작성해야 한다. 시험결과서에 전체적인 시스템 환경 구성 방 법, 시험 항목명, 시험 방법, 시험결과 등의 내용이 포함되어야 한다. 시험서의 시험은 필요한 모든 기능에 대하여 검증될 수 있는 형태로 진행되어야 하며 중요 한 화면은 식별 가능한 이미지로 저장하여 추후 반복하여 시험할 수 있도록 해야 한다.

② 완전성, 성능 시험
기능시험은 필요로 하는 기능의 제공 여부를 판단한다. 기능의 동작 여부와 더불어 기능이 완전하게 동작하는지 여부를 시험해야 하는 항목들이 있다.

■ 패킷 손실(Packet Loss) 시험
스니핑 방식으로 로깅하도록 설치한 경우에는 스니핑의 특성상 패킷 손실이 발생할 수 있다. 그리고 구성상의 오류나 시스템의 사양이 부족하여 패킷 손실이 발생할 수 있다. 현재 설치된 서버에 패킷 손실이 발생하는지, 얼마나 발생하는지 여부를 측정하여야 한 다. 가장 간단한 방법은 SQL을 반복해서 자동으로 수행해주는 툴을 이용하여 측정하 는 것이다.
패킷 손실률 = (손실된 SQL 건수/ 수행한 SQL 건수 ) * 100
측정된 패킷 손실률은 0.1% 이하로 관리하는 것이 바람직하다. 그 이상의 패킷 손실이 발생하는 경우에는 스니핑 서버의 사양을 높여야 하거나 네트워크 카드를 변경하여야 한다. 경우에 따라서는 스니핑 서버를 교체하여야 할 수도 있다.

■ Long SQL 시험
수행되는 SQL의 크기와 상관없이 모두 SQL을 수집하여 저장할 수 있어야 한다. 경우 에 따라서 500KB 이상의 SQL도 수행되는데 최악의 상황을 대비하여 1MB 정도의 임 의의 SQL을 만들어 해당 SQL이 온전히 저장되는지 시험한다.

■ 성능 시험
인라인 방식으로 게이트웨이를 구성하거나 스니핑 방식으로 WAS에서 오는 모든 SQL 을 수집하는 경우 대량의 트랙잭션 발생 시 부하가 높을 수 있다. 이를 위해, 시스템에 부과될 수 있는 최대의 트랜잭션을 계산하고, 30% 정도 여유율을 추가한 규모로 가상 의 트랜잭션을 발생시켜 전체적으로 무리없이 잘 관리되는지 확인하여야 한다.
보안 규칙의 수가 많아지는 경우에 시스템의 성능에 문제가 발생할 수 있다. 관리의 편 의성이나 관리 인원의 부족으로 접근제어 규칙을 DB 계정단위로 관리하는 곳이 많다. 그렇지만 개인정보나 중요정보 등은 더욱 세밀한 관리가 필요한데, 세밀한 관리란 결국 테이블 단위 혹은 컬럼 단위로 규칙을 구성하는 것을 의미한다.
민간 기업보다 공공기관의 경우 테이블이 중복되어 설계된 경우가 많다. 공공기관은 SI 사 업자가 프로젝트 마다 변경되어 일관된 관리가 어렵기 때문에 발생하는 현상일 수 있다. 경우에 따라서는 주민등록번호 등의 개인정보를 포함하고 있는 테이블이 1000개를 넘는 경우도 발생한다.
이런 경우에 테이블 단위로 규칙을 적용하게 되면 SQL 이 수행될 때마다 1000개의 테이 블 명과 비교하여 해당 테이블에 접근하는지 여부를 판단해야 한다. 초당 수백에서 수천의 SQL이 수행되는 상황에서 이런 작업은 접근제어 서버에 많은 부하를 초래하는데, 솔루션 에 따라서는 감당할 수 없는 경우도 발생한다. 이렇게 개인정보 혹은 중요정보를 보유한 다수의 테이블이 존재하고, 테이??의 규칙 적용 성능에 대한 테스트를 진행하여야 한다.

3) 주요 체크 사항
① 기능 확인
제안요청서(RFP) 등을 통하여 조직에서 DB 접근제어를 위하여 필요하다고 정의한 기능 들은 모두 체크 되어야 한다. 비록 도입한 솔루션에서 제공한다고 되어 있는 기능이라고 하더라도 구성상 혹은 버전 업그레이드 과정에서 동작하지 않는 경우가 발생할 수 있다. 그러므로 솔루션을 설치한 후에 정상적으로 모든 기능이 동작하는지 여부를 반드시 확인 하여야 한다. 가급적 기능 확인은 개발환경에서 진행한다. 다양한 요인을 반영하여 개발 환경에서 테스트를 진행한 후에 운영환경에 적용한다.

경우에 따라서는 운영환경에서 정책을 적용하는 과정의 테스트 모드로 운영할 수도 있다. 테스트 모드는 접근제어를 시행하지만 실제로 차단 등의 행위는 하지 않고 해당 사건에 대 한 로그만 남겨서 실제로 정상적인 동작이 이루어지고 있는지 확인할 수 있는 기능이다. 운영환경이 까다롭거나 매우 민감한 경우에는 테스트 모드로 먼저 운영하여 안정성을 확 인한 후 정상적인 통제 모드로 운영하는 것이 바람직하다.