1. DB 작업결재 개요

가. 정의

DB 작업결재는 SQL 수행 과정에서 관리자의 승인을 획득하도록 하는 관리적 보안을 추 가한 기술이다. 매우 민감한 데이터에 대한 조작이 필요하거나 조회가 필요한 경우에 해당 데이터에 대한 권한을 갖고 있을지라도 승인을 거치도록 하여 엄격하게 관리해야 하는 경 우에 적용한다.

참고로 금융위원회에서 공고한 전자금융감독 규정은 다음과 같이 규정하고 있다.

금융 기관에서 매우 민감한 원장 정보의 경우, 해당 정보를 변경할 때에는 반드시 변경 전 후 정보를 저장하고 변경 내용이 정당한가를 제 3자가 확인하도록 되어 있다. 이를 위해서 는 변경 작업을 다른 사람과 같이 수행하여 확인하는 방법이 있고, 작업 수행 이전에 승인 을 받도록 하여 확인을 받는 방법이 있다. 결재는 문서를 기안하는 기안자와 기안된 문서 를 처리하는 결재자의 업무로 구분되며, 각각의 프로세스는 다음과 같다.

DB 작업결재는 앞의 그림과 같이 민감한 정보를 통제하기 위해서 사용되는데, 3가지 방식 의 결재로 세분화할 수 있다.

■ 사전 결재
수행하고자 하는 SQL에 대해 수행 이전에 결재를 받는 방식이다. 예를 들어, 원장 정 보를 변경하고자 하는 경우에는 미리 수행할 SQL 및 변경 전후 정보를 같이 결재안에 포함하여 관리자의 승인을 받은 후에 SQL을 수행한다.
사전 결재는 SQL 단위로 결재를 받을 수도 있지만 DB 계정, 테이블, 컬럼 등의 다양한 단위로 결재를 미리 받을 수 있다. 즉, SCOTT이라는 계정의 EMP 테이블에 대해 SELECT 문장을 수행하는 것에 대해 미리 결재를 받으면 DB 작업자가 해당 계정에서 결재 받은 SQL을 수행할 수 있는 방식이다.
사전 결재는 작업 시간도 지정할 수 있다. 즉, 결재 대상 정보에 접근할 수 있는 시간을 특정하는 것으로 시스템에 대한 정기 점검 시간에 수행하도록 하려면 2011년 11월 20 일 오후 11시부터 다음날 오전 11시까지만 해당 정보에 접근할 수 있도록 설정하는 것 이다.

■ 즉시 결재
즉시 결재는 SQL을 수행하는 도중에 결재를 받는 방식이다. 사원 테이블의 급여 정보 에 접근하는 경우 결재를 설정해 놓으면, DB 사용자가 해당 테이블의 컬럼을 포함한 SQL 문장을 수행할 때 관리자에게 SQL의 문장 정보가 제공된다. 즉, 결재를 요청하 는 화면이 같이 나타나는 방식으로 관리자가 승인을 해야만 해당 SQL이 DB 서버에 전 달되어 수행이 가능한다. 이 방식은 관리자가 승인을 할 수 있는 상태에 있어야 하며 승 인받지 못한 SQL은 대기 상태에서 기다리게 된다.

■ 사후 결재
SQL 수행 후 결재를 하는 방식이다. DB 사용자는 자유롭게 필요한 SQL을 수행한다. 다만, 사후 결재를 받도록 되어 있는 SQL 문장을 수행하거나 특정 테이블 혹은 컬럼에 접근하는 SQL을 수행한 경우 사후에 승인받는 방식이다. 솔루션에 따라서는 SQL을 수행하는 과정에 수행 사유를 입력하도록 하여 사후 승인 신청시 입력된 사유 정보를 사용하여 승인 신청을 하도록 할 수도 있다.

나. 구성방법

DB 작업결재는 수행하는 방식에 따라 시스템의 구성이 달라지며, DB 작업결재와 DB 접 근제어가 결합되어 결재 방식에 따라 통제하게 된다.

1) 사전 결재 방식
사전 결재를 구현하기 위해서는 결재 시스템이 필요하다. 결재 시스템은 DB 작업결재 솔 루션에 포함된 결재 시스템을 사용할 수도 있고, 기본적으로 사용하고 있는 결재 시스템에 일부 기능을 추가하여 구현할 수도 있다.

사전 결재가 진행되는 프로세스의 흐름은 다음과 같다.

① 기안자가 사전 결재 문서를 기안
② 결재자는 결재 요청된 문서를 검토하여 승인결재자가 다수인 경우에는 모든 결재자를 거쳐서 승인 완료
③ 완료된 결재안에 따라 수행
④ DB 접근제어 시스템은 수행된 SQL을 체크하여 사전 결재를 받도록 되어 있는 정보에 대한 접근인 경우에는 결재 시스템에서 확인
⑤ 결재가 완료된 것으로 식별된 SQL의 경우에는 수행하도록 하고, 사전 결재되지 않은 SQL인 경우에는 차단 후 사전 결재가 필요하다는 메시지를 DB 사용자에게 전송
사전 결재 처리가 필요한 분야 중의 하나가 금융권의 원장정보 정정 업무이다.
'[그림 3-3-5] 원장정정 처리 프로세스'와 같이 현업으로부터 원장 정정 요청이 접수된 경 우에 담당자는 원장정정 요청을 수행하기 위해 수행할 SQL, 변경 전·후 정보 등을 포함 하여 원장정정 보고서를 기안하여 결재를 요청한다.

해당 결재안이 승인되면 결재를 받은 SQL을 수행함으로써 원장을 정정하게 된다. 원장정 정이 완료되면 원장정정 요청서를 처리하기 위한 별도의 승인 프로세스를 수행한다.

2) 즉시 결재 방식 즉시 결재 방식은 일반적으로 별도의 결재 시스템을 사용하지 않고 DB 접근제어 내부에 구현된 결재 시스템을 사용한다.

즉시 결재가 진행되는 프로세스의 흐름은 다음과 같다.

① 작업자가 SQL을 수행
② DB 접근제어는 해당 SQL이 결재를 받아야 하는지 여부를 판단하고 즉시 결재 대상 SQL의 경우에는 결재자에게 결재 요청
③ 결재자는 결재 요청된 문서를 검토하여 승인
④ 결재자가 다수인 경우에는 모든 결재자를 거쳐서 승인 완료
⑤ 결재가 완료된 경우, DB 접근제어 시스템은 SQL을 수행하고 결재가 실패한 경우에 결 재 실패 메시지를 제공하고 SQL을 차단함
즉시 결재 방식은 민감한 SQL에 대한 즉각적인 승인 통제 기능을 제공한다. 다만, 결재자 가 부재 시 장시간 대기하는 상황이 벌어질 수 있으므로 결재자 부재시의 처리 기능이 추 가로 필요하다. 결재자는 자신이 결재할 수 없는 경우에 다른 결재자에게 대리 결재하도록 설정하거나 자신의 결재를 득한 것으로 처리하도록 설정할 수 있어야 한다. 결재자가 여러 명일 경우에는 결재를 생략하는 것이 가능하지만 결재자가 1인인 경우에 부재처리는 대리 결재가 이루어질 수 있도록 하는 것이 바람직하다.

3) 사후 결재 방식
사후 결재 방식은 SQL 수행 후, 사후 결재 대상 SQL 정보를 결재 시스템에 보내어 추후 승인을 받도록 하는 방식이다.

사후 결재가 진행되는 프로세스의 흐름은 다음과 같다.

① 작업자가 SQL을 수행
② DB 접근제어는 해당 SQL이 결재를 받아야 하는지 여부를 판단하고 사후 결재 대상의 SQL인 경우에는 SQL을 결재 시스템에게 제공
③ 작업자는 수행한 SQL에 대해 결재를 요청
④ 결재자는 결재 요청된 문서를 검토하여 승인
⑤ 결재자가 다수인 경우에는 모든 결재자를 거쳐서 승인 완료

사후 결재는 기존의 업무 흐름에 영향을 주지 않으면서 승인 기능을 구현하는 방법이다. 즉, SQL을 수행한 후에 필요한 SQL에 대하여 사후 승인을 진행하므로 결재를 위한 대기 시간이 없어서 결재 프로세스 도입으로 인한 업무 지연이 발생하지 않는 방식이다.