신시웨이 [페트라 3], 2세대 DB접근제어 솔루션

원문보기 http://www.datanet.co.kr/news/articleView.html?idxno=73385



DBMS 내부에 원래 권한 설정 기능이 있기 때문에 DB접근제어가 별도의 솔루션 영역으로 자리를 잡게 된 것은 DBMS의 역사를 볼 때 그리 오래된 일이 아니다. 우리나라의 경우에는 그런 개념이 2000년 초반에 생성되어 실제로 제품화 되어 나오기 시작한 것은 2003년 무렵부터이다.
그 동안 국내 DB접근제어 시장은 여러 종류의 제품들이 나름대로 에이전트, 게이트웨이, 스니핑 등의 기술을 바탕으로 차별화된 모습으로 시장에 나와서 치열한 경쟁을 해 오고 있고, 이제는 어느 정도 시장이 성숙 단계에 도달했다.
이렇게 시장은 성숙/안정화 단계에 도달했지만, DB접근제어 솔루션은 새로운 국면에 접어들고 있고, 1세대를 지나 2세대 제품의 출시가 필요한 단계에 도달하였다. DB접근제어 솔루션 태동부터 카드사 유출사고 전까지 도입된 시스템을 1세대라 볼 수 있는데, 효과적으로 DB에 대한 통제 및 관리를 수행한다는 측면보다는, 정보통신망법에서 출발하여 개인정보보호법으로 완성된 규제에 대한 대응 측면이 많았다. 그렇다 보니 DB접근제어 시스템을 구축해 놓고도, 매우 간단한 통제 규칙으로 통제를 하거나 아무런 통제 없이 로그만 남기도록 운영하는 사례가 많았다. 저장된 로그를 통해 보안 위반 사건에 대한 추적을 하는 등의 개선활동은 하지 않고, 문제가 발생할 경우를 대비하여 단순히 저장하고 있는 경우가 훨씬 많다.
이런 틀에서 벗어나 실질적인 통제가 가능한 DB접근제어솔루션이 필요한데, 이를 2세대 DB접근제어 솔루션이라 규정하며 아래와 같은 특징들을 가져야 한다고 생각한다.

1. 보안정책 중앙관리
DB접근제어 시스템을 단순히 구성한 곳은 2대의 게이트웨이 서버만으로 구성한다. 그렇지만 좀더 확장하여 구성한 경우에는 스니핑 서버가 별도로 구성되고, DB서버마다 에이전트 서버를 구축한다. 운영시스템의 경우에 위와 같이 구성되고, 재해복구(DR) 시스템이 구축된 경우에는 운영시스템과 동일하게 DB접근제어 시스템이 구성되어야 한다.
이런 관점에서 보면 아무리 단순하게 구성해도 2대의 게이트웨이 서버, DR까지 고려하면 총 4대의 게이트웨이 서버가 구축되며, 규모가 큰 곳은 수십 개의 DB보안 시스템이 설치되어 운영된다. 이렇게 많은 DB접근제어 시스템이 구축되는 경우에, 보안정책을 일관성 있게 유지하며 적용하는게 매우 어려운 일이 된다. 모든 시스템 및 사용자에게 일관성 있는 정책이 유지되어야 하는데, 각각의 DB접근제어서버 마다 보안규칙을 별도로 관리하는 경우에는 일관성이 꺠지기 쉽고, 일관성 있게 관리하려면 매우 많은 노력이 들어가게 된다. 그러므로 2세대 보안 솔루션은 중앙에서 단일한 보안규칙만을 관리하고, 중앙에서 관리되는 규칙이 자동으로 모든 DB접근제어 서버에 배포되는 구조를 지원해야 한다. 더구나 앞으로의 추세는 보안 정책을 개인별로 상세히 설정하는 것이 일반화될 가능성이 큰데, 이렇게 많은 보안 규칙을 관리하기 위해서는 중앙관리 기능이 반드시 지원되어야 한다.

2. 딕셔너리 기반의 SQL 파싱
SQL에 대한 세분화된 통제가 필요한데, 특히 개인정보가 저장된 테이블/컬럼에 대한 세밀한 통제가 필요하다. 이런 통제가 가능하기 위해서는 SQL을 파싱 처리하여 개인정보 테이블/컬럼에 접근하고 있는지 정확한 판단을 내릴 수 있어야 한다. 특히 보안 대상 DBMS에 저장된 테이블/컬럼 정보를 이용하여 파싱을 수행함으로써 그 정확도를 DBMS 수준으로 올려야 한다.

3. 강화된 결재 기능
개인정보를 포함하여 중요한 정보가 저장된 테이블/컬럼에 대한 정보 접근이 이루어지는 경우, 반드시 해당 책임자의 결재를 얻도록 요구하고 있는데, 이런 결재를 지원해야 한다. 수행하는 시점에 결재를 받기 어려운 작업환경에서는 사후에 소명처리해야 하는데, 개인정보를 처리하여 업무를 수행하고 해당 업무를 처리한 사유를 나중에 결재를 올려 담당 책임자의 결재를 받을 수 있어야 한다. 물론 SQL을 수행하기 이전에 해당 작업내용을 미리 결재를 받는 기능도 제공해야 한다.

4. 안전한 로그 관리
로그에 대한 안전한 관리를 위하여 민감한 로그를 암호화 하여 저장하여야 한다. 특히 주민등록번호 등의 개인정보를 로그 형태로 저장하는 경우에 개인정보보호법에 따라 암호화 하여 저장해야 한다. 또한 저장된 로그에 대한 위변조 방지를 위해 변경(update), 삭제(delete), 테이블 제거(drop) 등의 행위를 할 수 없도록 로그용 DBMS 차원에서 해당 명령어를 차단하는 기능을 가져야 한다.

5. 보안 위험 분석 기능
기본적으로 단일 SQL의 경우에는 SQL이 처리하는 데이터 건 수 기반으로 통제를 할 수 있어야 한다. 즉 개인정보를 10건 이상 취급하는 경우에는 결재 혹은 경보 처리를 한다든가, 아니면 마스킹 처리를 할 수 있어야 한다. 또한 보안 위험에 대한 판단도 단순히 사용자의 SQL 종류나 접근하는 테이블 종류가 아니라, DB 사용자의 행위 패턴을 분석하여 과거 행위 패턴과 다르게 사용하는 경우를 인지할 수 있어야 한다. 즉, 일반적으로 하루에 50건의 개인정보를 취급하는 사람이 오늘 오후에 200건의 개인정보를 조회하는 상황은 비정상적이라고 보고 해당 사실을 보안관리자에게 경보로 전송하거나, 결재를 받아서 진행하도록 해야 하는데 이런 비정상적인 상황을 단순히 특정 값을 기준으로 하는 것이 아니라 각 사용자별 패턴에 따라서 문제 상황 여부를 판단하는 기능을 제공해야 한다.

6. 다양한 인증 기능
보안의 시작은 행위자에 대한 명확한 식별이다. DB접근제어 시스템이 없는 경우에는, DBMS내에 생성된 DB계정을 통해 사용자를 식별했는데, 이런 경우 개인별로 DB 계정을 가지고 있어야 한다. DB계정을 공유하는 환경에서는 접속자의 IP를 이용하여 식별하거나, 별도의 ID/PW를 입력하는 인증과정을 통해 식별한다. 현재의 추세는 이런 과정을 다단계 인증을 통해서 수행하는 것인데, 접속자 단말기의 OS계정 인증, DB계정인증, OTP인증 등 여러 인증을 복합적으로 수행하여 DB접속자의 신원을 파악하는 기능을 제공해야 한다.

7. 세밀한 접근통제 규칙
사용자에 대한 통제를 정확히 수행하기 위하여 세밀한 접근통제 정책을 수립할 수 있어야 한다.
세밀한 접근통제는 아래와 같은 기능을 포괄하는 것이다.
1) SQL 타입별 통제 : 사용 DBMS에서 사용중인 SQL의 종류를 분석하면 약 650종 정도가 된다. 각 DBMS 별로 지원하는 SQL 타입이 각각 다른데, 이에 맞게 상세한 수준까지 통제가 가능해야 한다.
2) 정규식 통제 : SQL TEXT에 들어 있는 내용 중 정규식 패턴을 통해 체크하여 통제하는 것이다.
DBMS가 암호화 되어 있는 경우에 복호화 함수는 일부 사용자만 사용할 수 있어야 하는데,
SELECT PT_DECRYPT(JUMINNO$$) FROM EMP
와 같은 SQL에 대하여 PT_DECRYPT 라는 문자열이 포함된 SQL은 일반 사용자가 사용할 수 없도록 통제할 수 있어야 한다.
3) 건 수 기준 통제 : 대량의 개인정보를 취급하는 경우 통제하는 것이다. 주민등록번호가 포함된 테이블은 100건 이상 조회하는 경우 조회를 불가능하게 하거나, 경보를 발행하는 것이다.
4) 요일, 공휴일, 시간대별 통제 : 업무 시간과 비업무 시간에 수행할 수 있는 작업은 달라야 한다. 이런 측면에서 요일, 공휴일, 시간대 등의 복합 조건으로 규칙을 통제할 수 있어야 한다. 또한 각 조직마다 공휴일이 다를 수 있는데, 예로 회사 창립기념일은 회사마다 다를 수 있다. 이런 것을 위하여 공휴일을 등록 관리할 수 있어야 한다.

8. 보안관리자 분할 기능
다수의 DB사용자를 한두 명의 보안 관리자가 모두 관리하는 것은 현실적으로 매우 어렵다. 공공 기관의 경우 각 조직별로 관리자를 세분화하여 관리하도록 할 필요가 있을 수 있는데, 이를 지원해야 한다. DB사용자 그룹을 만들고 해당 그룹 마다 담당 보안관리자를 지정하여 해당 그룹의 사용자를 관리하게 하고, 보안관리자는 자신이 담당하는 사용자 규칙만 관리가 가능하며 수집된 로그도 해당 사용자들이 수행한 결과 로그만 조회가 가능하도록 해야 한다.

9. 보안 모니터링
현재 보안 상황을 한눈에 파악할 수 있는 모니터링 기능을 제공하여야 한다. 로그인 차단, SQL 차단, 경보 발생 현황, SQL 수행 현황, 로그인 현황 등을 보안서버별, 각 DBMS 별로 제공하며, 특정 기간(즉, 1주일 전)과 현재를 비교하여 문제가 없는지 식별할 수 있어야 한다.

당사는 이런 시대적 흐름에 맞추어 제품을 개발하고 있고, 2세대 기능을 모두 포괄하는 제품을 단계별로 출시할 예정이다. 이런 과정의 일부로 Petra V3.1 R2를 출시하였고, 위에서 소개한 차세대 기능 대부분을 포함하고 있다. DB접근제어시스템을 구축하여 사용하고 있지만 기능을 한층 업그레이드 하고자 하는 경우나 이제 신규로 DB접근제어 시스템을 구축하고자 하는 경우에는 당사에서 출시한 Petra V3.1 R2를 꼭 검토해 보고 결정하길 바란다.