4. DB 접근제어 운영

가. 보안 규칙 관리

보안 규칙은 접근제어 시스템을 운영하는데 핵심적인 정보이다. 또한, 추후 보안 사건이 발생했을 때 적정하게 권한을 갖고 있었는지 추적해야 한다. 이런 이유로 개인정보보호법 에서는 접근권한 기록을 최소 3년이상 보관하도록 강제하고 있다. 1) 관리 대상 보안 규칙은 DB 접근제어의 핵심에 해당 하므로 권한이 없는 사람이 함부로 변경해서는 안된다. 정당한 절차에 의한 변경이라고 하더라도 관련 기록을 보존하여야 한다. 또한, 다 수의 보안 서버가 설치된 경우에는 보안 서버를 중앙에서 관리하여 편의성을 도모하고, 보 안 규칙에 대한 백업을 실시하여 시스템 장애 시 백업된 보안 규칙을 이용하여 새로운 보 안 서버를 생성하여 운영할 수 있어야 한다. ① 이력 관리 보안 규칙의 구성요소를 살펴보면 다음과 같다.

앞의 표에서 권한 설정의 핵심적인 역할을 하는 통제 규칙 정보는 관련 변경 이력을 저장 하여 추후 감사 등의 과정에서 권한 변경 이력을 요구할 때 제시할 수 있어야 한다.

② 백업 관리
보안정책에 대한 백업을 하여야 한다. 보안 정책은 일정 시간 동안 변경이 될 수 있으므로 주기적으로 백업하여야 한다. DB 접근제어 솔루션의 특성에 따라 별도의 보안 정책 저장 기능을 제공할 수도 있고 로그와 함께 백업되어 관리될 수도 있다.

③ 보안 정책 중앙 관리
DB 보안 서버가 2개 이상 구축된 경우에는 보안 규칙에 대한 중앙 관리를 고려하여야 한 다. 프록시 게이트웨이의 경우 장애 대응을 위해 이중화로 구성을 한다.

이런 경우 보안 정책도 2대의 서버에 존재하게 되는데, 보안 정책 변경 시에 각각의 서버 에 이중으로 작업하는 경우에는 작업자의 실수에 의하여 두 대의 보안 정책이 서로 상이하 게 설정될 수 있다. 또한, 다수의 DB 접근제어 에이전트를 설치한 경우 에이전트 마다 독 자적인 DB 보안 규칙을 가지고 있는데, DBMS 수가 많은 경우 개별적으로 관리하기가 매 우 어렵다.
이때 규칙 정보가 자동으로 복제되도록 하는 기능을 가진 솔루션의 경우에는 관리의 편의 성을 도모함과 동시에 보안 관리자의 실수로 인한 보안정책의 일관성이 훼손되지 않도록 하여야 한다.

2) 주요 체크 사항
① 이력 확인
보안 정책의 변경은 반드시 로깅하여 추후에 확인할 수 있어야 한다. 보안 정책은 다양한 요소를 포함한다. 즉, DB 접근제어에 관련된 직접적인 규칙도 보안정책에 포함되지만, 사용자의 각종 설정 정보(IP, ID 등), 그룹핑 정보(DB 그룹, DB 계정 그룹 등) 등도 핵심 적인 보안 규칙에 해당 되므로 그에 대한 로깅 여부를 확인하여야 한다.

나. 사용자 로그 관리

DB 사용자가 DBMS에서 로그인한 정보 및 수행한 모든 SQL 정보는 로그 형태로 저장되 는데, DB 접근제어 시스템의 중요한 목적 중의 하나가 로그를 수집 보관하여 추후에 문제 가 발생할 때 로그를 이용한 추적이 가능하도록 하는 것이다. 그러므로 수집된 로그 정보 는 철저히 관리 되어야 한다.
DB 접근제어 솔루션에 관계없이 관리되어야 하는 로그의 종류는 다음과 같다.

다만, DB 접근제어 솔루션에 따라 명칭 및 저장되는 정보는 차이가 있을 수 있다. 이렇게 수집된 로그는 필요 시 로그 정보를 조회할 수 있어야 한다.

1) 로그 백업
로그의 백업은 현재 DB 접근제어 서버의 레파지토리(일반적으로 DBMS를 이용)내에 저 장된 정보를 파일 형태로 저장하여 보관하는 것이다. 로그에 대한 백업은 DB 접근제어 솔 루션에서 제공하는 백업 기능을 이용한다. 백업은 DB 접근제어 솔루션에서 사용하는 DBMS에 따라 달라진다.
로그를 백업한 후에 해당 정보는 레파지토리에서 삭제될 수도 있고 남겨질 수도 있는데, 필요 이상의 로그를 보관하는 경우에는 보고서 생성 등의 작업에 시간이 오래 걸려 비효율 적이 될 수 있다. Live 상태로 유지하는 로그는 생성되는 로그량에 따라 다른데, 대량의 로그가 발생하는 경우에는 6개월에서 1년 정도의 로그를 Live 상태로 유지하고 나머지 로 그는 백업하여 보관한다. 그렇지만 로그 발생량이 적은 경우에는 백업한 정보도 모두 Live 상태로 유지하며 장기간의 보고서 생성에 활용할 수 있다.
스니핑 방식을 이용하여 로그를 수집하는 경우에는 대량의 로그가 발생하므로 백업된 로 그는 삭제할 필요가 있다. 스니핑 방식의 경우에도 자주 사용되지만 보안상 로깅이 불필요 한 SQL을 로깅 대상에서 제외할 경우에는 로그 발생량을 획기적으로 줄여서 로그 보관 기 간을 오래 유지할 수도 있으므로 조직의 보안정책 수립 시 이런 기술적인 사항을 고려하여 야 한다.
다음 그림은 DB 접근제어 전용 DBMS를 사용하여 로그를 수집하는 시스템의 구성 예시 이다.

수집된 로그를 저장하기 위해 저장 스케줄을 수립하여야 한다. 로그는 일별 백업을 할 수도 있고, 주별, 월별로 백업할 수도 있는데 백업 주기는 로그 발생량에 따라 설정하여야 한다.

DB 보안 관리자는 주기적으로 백업된 이력을 체크하여 백업이 정상적으로 이루어지고 있 는지 확인하여야 한다.

DB 접근제어 솔루션에서 제공하는 백업 기능은 접근제어 서버 내의 지정된 디렉토리로 로그 파일을 백업하게 되는데, DB 접근제어 서버 외부로 백업 파일을 복사하거나 테이프장치 등으 로 저장하여 DB 보안 서버의 하드디스크 장애로 인한 백업파일의 손실을 방지하여야 한다.

2) 로그 복구
저장된 로그는 필요 시 복구할 수 있어야 한다. 복구가 필요한 경우는 DB 접근제어 서버의 디스크 장애로 현재의 로그가 망실되었거나, 백업 후 삭제된 로그 기록을 이용하여 추적하 여야 하는 경우이다.
설치 과정에서 백업된 로그가 잘 복구되는지 시험을 하여야 한다. 복구는 특정 시점의 로 그를 찾아서 복구가 가능해야 한다. 예를 들어, 2008년 11월부터 12월 사이의 로그를 추 적해야 하는 경우에는 해당 기간의 백업 정보를 이용하여 복구를 수행한다.

3) 로그 조회
로그에 대한 조회가 가능하여야 한다. 일반적인 점검을 위해서는 검색 기간을 입력한 후에 전체적인 로그를 조회한다. 보안 위반 사건이 발생한 경우에는 발생 테이블에 접근한 이력 을 조회하게 되는데 이를 위해서는 테이블별 혹은 SQL 종류별 조회가 가능해야 한다. 일반적으로 다음과 같은 조건으로 조회를 한다.

① 사용자 속성
추적해야 하는 사용자를 특정할 수 있는 경우에는 해당 사용자의 속성으로 조회한다. 조회 가능한 사용자 속성은 다음과 같다.

？사용자 IP
？사용자 ID(부가적인 인증을 사용하는 경우)
？조직 정보(팀명, 부서명)
？단말기 명
？OS 계정명
？MAC 주소

솔루션에 따라서는 위 사항을 모두 지원할 수도 있고 일부만 지원할 수도 있다.

② 정보 및 행위 속성
DB 사용자가 DB에 로그인 한 후 접근한 정보의 속성과 정보에 접근하기 위해 수행한 행 위를 기반으로 조회한다. DBMS에서 정보에 접근할 수 있는 수단은 SQL을 통해 이루어 지므로 행위는 SQL 종류를 이용하여 추적한다.
다음과 같은 정보 및 행위 속성이 있다

？DB명
？DB 계정명
？테이블명
？컬럼명
？SQL 종류

③ 수단 속성
DB 사용자가 정보에 접근하기 위해 이용한 수단을 기반으로 조회한다. 다음과 같은 수단이 존재한다.
？DB 접근툴 (Toad, Golden, Orange, SQL*Plus 등)

4) 주요 체크 사항
① 로그 백업 확인
각종 사용자 행위로그에 대한 백업은 접근제어 시스템 관리에 있어서 가장 중요한 요소이 다. 백업 기능의 편리성은 솔루션의 기능에 따라 달라지며 효과적으로 로그를 관리할 수 있는 기능을 제공할 수도 있다. 그러나 솔루션 기능과 상관없이 솔루션이 생성한 로그는 반드시 백업되고 필요 시에 복구되는지를 확인하여야 한다.

다. 모니터링

1) 모니터링 종류
모니터링은 DB 접근제어 시스템에 이상 징후가 있는지 감시하는 활동이다. DB 접근제어 를 전담하는 인력이 있는 경우에는 로그를 주기적으로 확인하는 등의 활동을 한다. 그러나 전담인력이 없는 경우에는 특정한 보안사건이 발생하기 전에는 별도로 로그를 확인하지 않 는 경우가 많다. 로그를 주기적으로 확인하는 과정을 수행하지 않으면 보안위반 상황을 인 지하거나, 징후가 있는지 여부를 사전에 알 수 없다. 따라서, 효율적으로 현재 상황을 파악 하고 상태의 추이를 파악하기 위해 중요지표에 대한 일상적인 모니터링은 매우 중요하다. 모니터링 지표에 대한 표준화가 아직은 이루어지지 않아서 솔루션마다 제공하는 지표에 차이가 있어 해당 지표만으로 DB 접근제어를 위해 충분하다고 볼 수 없다. 가장 좋은 방법 은 조직별로 DB 접근제어 관점에서 보안 현황을 손쉽게 확인할 수 있는 지표를 개발하여 모니터링 하는 것이다. 예를 들어, 평상시 보안 지표는 50수준에 있어야 하는데 갑자기 60이 되면 문제가 있는 것으로 인지하여 문제의 원인을 파악하도록 하는 등의 관리가 가능 하도록 지표를 개발하여 실시간으로 모니터링하는 것이 가장 좋다.
만약, 적합한 지표를 개발하지 못하는 경우에는 솔루션에서 제공하는 다양한 지표의 흐름 으로 이상여부를 확인해야 한다.

① 추이 분석 모니터링
DB 접근제어 서버의 보안현황을 추이 그래프를 통해 보여주는 기능이다.

추이 그래프를 통해 관찰해야 하는 최소한의 지표는 다음과 같다.

DB 접근제어 관점에서 매우 중요한 지표는 경보 발생 및 SQL 차단 현황, SQL 수행 현황 등이다. 또한, 개인정보를 관리하는 조직의 경우에는 개인정보에 대한 접근현황도 모니터 링 해야 한다.
조직에서 중요하다고 판정된 지표의 경우 추이 흐름을 감시해야 한다. 일정 범위 이내에서 움직이는 지표의 경우에는 MIN·MAX 값을 설정하여 해당 범위를 벗어나면 보안 관리자 가 즉각 인지할 수 있도록 하여야 한다. 경보가 발생한 경우에 보안관리자는 해당 경보의 원인을 파악해야 한다.

DB 접근제어 서버가 여러 대 설치된 경우에는 경보를 취합하여 하나의 화면에서 볼 수 있 도록 관리할 필요가 있다. 다만, 경보 설정을 너무 과다하게 하여 경보 발생이 빈번한 경우 에는 중요한 경보 발생 시 대응을 늦게 하는 요인이 될 수 있으므로 조직의 보안 관점에서 의미 있는 이벤트가 발생한 경우에만 경보가 발생하도록 설정해야 한다.
총괄적인 현황에 대한 모니터링이 가능한 형태로 대시보드를 구성하는 것이 바람직하다. 대시보드 상에서 이상 현상이 발생하면 즉, 특정 지표가 평상시와 다르게 높거나 낮으면 해당 원인을 분석하는 방향으로 진행해야 한다.

지표를 구하는 기준은 보안서버 단위로 할 수도 있고 DB 서버 단위로 할 수도 있는데, 구 축된 솔루션의 기능에 따라 선택할 수 있는 폭이 달라진다. 다만, 관리해야 하는 DB의 수 가 많은 경우에는 앞의 그림에서 보여주고 있는 것처럼 관련있는 DB 서버를 그룹으로 묶 고, 해당 그룹 단위로 보안 서버를 설치하여 보안 서버 단위로 지표를 관리하는 것이 효율 적이다.
다수의 DB 서버에 대하여 에이전트 방식으로 DB 서버마다 DB 접근제어 에이전트가 설치 되어 있는 경우에는 DB접근제어 에이전트만을 모니터링 하기 위한 서버를 별도로 구축하 는 방법도 있다.

② 로그인(세션) 모니터링
로그인 모니터링이란 DBMS에 접속한 로그인 세션에 대한 모니터링이다. 접속한 로그인 정보를 보여주고 해당 세션이 수행한 SQL 정보를 보여준다.

로그인(세션) 모니터링 화면에서는 현재 접속하고 있는 세션(Active 세션)을 기본적으로 보여주며 SQL 수행 정보는 수행 순서에 따라 보여준다. 로그인(세션) 모니터링 기능을 통 해 정상적으로 DB 접근제어가 실시되고 있는지 현황을 파악하고 접속한 사용자 별로 어떤 SQL을 수행하였는지 파악할 수 있다. 또한, 경보가 발생한 경우에 경보를 발생시킨 세션 의 수행 이력을 손 쉽게 추적할 수 있다.

2) 주요 체크 사항
모니터링 지표는 솔루션마다 차이가 있고 조직의 성격에 따라 중점적으로 관리해야 하는 지표가 다를 수 있다. 이런 차이를 인정하더라도 다음과 같은 지표는 기본적으로 GUI 화면 을 통해 추이를 볼 수 있거나 즉각적으로 해당 지표의 현재 상태를 파악할 수 있어야 한다.

■ 보안 서버의 생사 감시
DB 접근제어 서버가 현재 정상적으로 작동 중인지 버그나 기타 환경적인 요인에 의하 여 중단된 상태인지를 확인할 수 있어야 한다. 특히, 하이브리드 방식으로 구성되어 프 록시 게이트웨이 서버, 스니핑 서버, 에이전트 서버 등 다수의 서버가 존재하는 경우에 는 해당 서버들의 상태를 일목요연하게 볼 수 있는 모니터링 기능이 구현되어야 한다. DB 접근제어 솔루션이 생사 감시 기능을 제공하지 않는 경우에는 ESM 같은 별도의 툴 에 의해 생사를 감시할 수 있어야 한다.
■ 경보 지표
DB 접근제어 솔루션을 구축한 경우에는 다양한 경보 상황을 설정하게 된다. 가능한 모 니터링이 필요한 상황은 경보로 설정해야 한다. 즉, SQL이 권한이 없어서 차단된다거 나, 패스워드 오류로 로그인이 거부된다거나하는 이벤트는 보안 관점에서 매우 중요하 므로 꼭 경보로 설정하여 감시하여야 한다.
이렇게 설정된 경보가 현재 어느 정도 발생하고 있는지 정보를 즉각적으로 인지할 수 있 어야 한다. 일반적으로 경보는 자주 발생하지 않으므로 일단위로 관리되어 당일에 몇 건 정도 발생했는지 정보를 볼 수 있어야 한다.

라. 운영 리뷰

DB 접근제어 구축만으로 DB에 대한 보안이 완성되지 않는다. 보안은 조직의 보안정책에 따라 보안 지침이나 절차 등이 제대로 준수되고 있는지 점검하면서 완벽하게 유지되도록 해야 한다.

1) 운영 관리 활동
DB 접근제어의 보안 상태를 유지하거나 높이기 위해서는 끊임없는 점검이 필요하다. 예 를 들어, 어떤 직원에게 특정 계정이나 테이블에 대한 접근 권한을 주었다가 해당 직원이 인사 발령으로 수행하던 업무가 바뀌게 되면, 그 전에 주어진 권한이 필요 없는 상황이 발 생할 수 있는데, 이런 상황의 변화에 따라 권한의 회수가 정상적으로 이루어지고 있는지 점검을 해야 한다.
기본적으로 올바른 보안 시스템 운영을 위해서 다음과 같은 사항이 명확히 정의 되어야 한다.

위에서 정의된 내용을 기반으로 보안관리 활동을 수행하여야 한다.

① 보안규칙 변경 관리
DB 접근제어 구축 단계에서 설정한 보안 규칙은 변경이 생길 수 밖에 없다. 보안 규칙이 변경되는 이유는 다음과 같다.

■ DB 사용자 변경
인사이동, 입사 및 퇴사 등의 활동에 따라 DB 사용자가 변동되고, 이에 따라 DB 사용 자에게 할당된 권한이 변경되어야 한다.
■ 보안 목표 상향
DB 접근제어 시스템 도입 시에 신규로 DB가 생성되는 경우에는 높은 수준의 보안 규 칙 설정이 가능하다. 그러나 이미 나름의 프로세스가 정립되어 업무가 이루어지는 상황 에서 높은 수준의 DB 접근제어 규칙을 적용하려면, 업무의 편의성이 낮아져서 많은 반 발을 가져올 수 있다. 그러므로 점진적으로 보안 수준을 높여 나가는 전략을 선택하게 되는데 보안 수준을 높임에 따라 보안 규칙이 변경되어야 한다. 가장 흔한 예로, 계정 단위로 접근제어를 수행하다가, 테이블 단위로 세분화하여 접근제어를 수행하는 경우 가 이에 해당한다.
■ 보안 대상 추가 및 변경
DB 접근제어를 전체 DB에 대해 적용하기도 하지만 순차적으로 적용할 수도 있다. 이 런 경우 적용대상의 확대에 따라 관련 규칙이 추가되어야 한다. 또한, 기존의 운영 중 인 DBMS가 필요에 따라 재구성되는 경우에도 해당 보안 규칙이 변경되어야 한다.
■ 관리적 요건
이미 구성된 보안 규칙을 점검한 결과, 장기간 DB를 사용하지 않는 사용자가 발견되거나 사용되지 않는 보안 규칙이 발견되는 경우 해당 사용자 및 보안 규칙을 삭제해야 한다. 이런 다양한 이유로 보안 규칙이 변경될 수 있는데, 보안 규칙에 대한 변경에 대한 절차를 마련하여 그 절차대로 시행하여야 한다. 사용자 변경의 경우에는 해당 부서에서 신규 사용 자에 대한 신청이나 퇴사자에 대한 삭제 요청 등 변경 요청 절차에 따라 관리자의 승인을 득한 후에 신청하여 보안관리자가 처리해야 한다. 보안팀 자체적으로 보안규칙을 변경해 야 하는 경우에는 보안팀 내부의 승인 과정을 거쳐서 변경해야 한다.

② 로그 분석 및 보고
DB 접근제어 서버에서 생성되는 로그에 대하여 주기적으로 아래와 같은 사항을 검토해야 한다.
■ 로그 생성 기능 확인
DB 접근제어 서버의 버그나 디스크 부족 등의 요인으로 인하여 로그 생성에 문제가 있 는지 여부를 주기적으로 점검하여 안정적으로 로그가 생성되고 있음을 확인한다.
■ 경보 메시지 확인
DB 접근제어 시스템에 경보를 발생하도록 설정하여 경보가 발생되는 경우 해당 경보의 원인을 추적하여 보안적으로 이상이 없는지 점검해야 한다. 점검 주기 동안에 경보가 발생된 이벤트에 대하여 모두 점검을 하였는지 확인한다.
■ 로그 분석
사용자 혹은 팀별로 DB 접속 현황에 대한 보고서를 생성하여 특정 계정에 과도하게 접 속하거나, 중요 테이블에 대하여 과도한 데이터를 추출하는 등의 특이 동향이 없는지를 분석한다. 경보를 설정하였더라도 경보가 발생하지 않을 정도의 수준으로 반복하여 행 위를 취하는 경우 시스템적으로는 해당 상황을 파악할 수 없으므로 반드시 통계 보고서 를 작성하여 검토하여야 한다. 검토한 내용 혹은 전체적인 트렌드를 분석하여 상급 관 리자에게 보고한다.

③ 모니터링
모니터링은 2가지 관점에서 이루어져야 한다.
첫째, DB 접근제어 시스템이 제대로 동작하고 있는지에 대한 모니터링이 이루어져야 한 다. 시스템은 내부 버그나 리소스 부족 등 다양한 요소에 의해서 정상적인 동작을 하지 못 할 수 있다. 주기적으로 로그를 확인하는 방법이 있고, 시스템에서 동작하는 프로세스의 상태를 감시하는 방법이 있다. 해당 솔루션에서 시스템 모니터링 기능을 제공하는 경우에 는 해당 기능을 이용하거나, ESM 과 같은 전체적인 모니터링 체계와 연계하여야 한다.
둘째, DB 접근제어를 수행한 결과에 대한 모니터링이다. 자신의 권한 이상의 계정이나 테 이블에 접근하려고 시도하는 움직임이 있는지, 평상시보다 많은 데이터 특히, 개인정보나 중요정보 테이블의 데이터가 조회되고 있지 않은지, DB 서버에 로그인 할 때, 개인별로 부여된 ID/PW를 통해 인증을 수행하도록 한 경우 인증실패가 발생하고 있지 않은지 등을 실시간으로 모니터링 할 필요가 있다. 중대한 보안 사건이 발생하는 경우 모니터링을 통해 서 즉각적인 대응을 할 수 있다.

2) 주요 체크 사항

① 직무의 분리
보안 관리자와 DBA 역할을 동일한 사람이 수행해서는 안된다. 한 사람에게 모든 관리 권 한이 집중된 경우에 해당 사람에 대한 감시가 불가능하기 때문이다. 불가피하게 DBA 그 룹 내에서 보안관리를 수행하는 경우에도 실무적으로 DBA를 수행하는 사람은 보안관리 자의 역할을 맡지 않고 다른 사람이 맡아서 작업을 해야 한다.

② 로그 검토
DB 접근제어 서버에 저장되는 이력 정보는 주기적으로 검토되어야 한다. 주로 솔루션에 서 제공하는 보고서를 이용하여 검토를 하게 되는데, 접속 현황, 경보 현황, SQL 차단 현 황 등은 주기적으로 검토되어 특별한 이상 징후가 없는지 확인하고 상급자에게 보고하여 결재를 받아야 한다.