DB보안

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

DB 작업결재 설계

DB 보안 실무
DB 작업결재
DB 작업결재 설계
작성자
admin
작성일
2021-02-15 17:40
조회
2745

2. DB 작업결재 설계

가. DB 작업결재 규칙 정의

1) 개요 작업결재 규칙의 핵심은 어떤 SQL을 수행하거나 어떤 정보에 접근할 때 결재를 받아야 하 는지 여부와 결재를 누구에게 받아야 하는가이다.

① 결재대상 정의
결재를 받아야 하는 대상을 정의하는 방식은 DB 접근제어와 유사하다.
■ 사용자 중심 정의
결재를 받아야 하는 대상을 사용자 중심으로 정의하는 것이다. 사용자를 그룹으로 설정 할 수도 있고, IP, 사용툴 등의 조합으로 정의할 수 도 있다. 예를 들어, “회계팀에 소 속된 모든 사용자는 SQL을 수행할 때, 항상 결재를 받아야 한다”와 같은 내용으로 규 칙을 정의할 수 있다.
■ 정보 중심 정의
SQL을 통해 접속하고자 하는 정보를 중심으로 정의하는 것이다. 즉, “중요정보에 접 근할 경우에는 접근하는 사람에 상관없이 항상 결재를 받아야 한다”와 같이 정의하는 것이다.
예를 들어, 개인정보의 경우에“정보통신망 이용 촉진 및 정보보호 등에 관한 법률(정 보통신망법)”에서 주민등록번호, 카드번호, 계좌번호 등을 암호화하여 관리해야 하는 대상으로 시행규칙에 명시했지만, 개인정보보호법의 경우에는 주민등록번호, 여권번 호, 운전면허번호, 외국인등록번호 등을 개인식별번호의 범주에 넣고 해당 정보를 암 호화하여 특별 관리하도록 하고 있다. DB에 저장된 정보 중에 개인정보만이 접근을 제 어할 가치가 있는 것은 아니다. 금융기관의 경우 각종 원장 정보는 매우 중요한 정보이 고, ERP 시스템에 있는 회계 정보 또한 회사의 사활을 좌우할 만큼 중요한 정보를 담 고 있는 경우가 많다. 법적으로 규제를 받고 있는 대상 정보 이외에 조직의 성격에 따라 분류하여 특별히 관리해야 하는 정보는 상이하다. 이와 같이 중요한 정보에 대해서만 결재를 거치도록 정의하는 방식이다.
다음 표는 정보 중심으로 정의를 할 때 사용하는 요소들에 대한 설명이다.

[표 3-3-1] 결재대상 정보 / (제어대상 정보, 설명,  비고 순) DB : DBMS에서 관리하고 있는 DB이다. 정보의 가장 큰 단위에 속하게 되며, 일반적으로 DB 단위보다는 더 세밀하게 접근제어를 수행 / DB 계정 : DB 정보에 접근 가능한 DB 계정이다. DB종류에 따라 단순의 DB에 로그인 할 수 있는 계정일 수도 있고, 테이블이 생성된 스키마를 의미할 수도 있음. 시스템에 따라 정보를 접근하는 통로의 의미를 가지는 논리적 계정과 실제로 테이블을 소유권을 가지고 있는 물리적 계정이 분리되어 있을 수 있음. / 테이블/뷰 : DB에서 정보가 저장되어 있는 논리적인 집합체. 테이블을 물리적으로 데이터를 보관하고 있는 실체이지만, 뷰는 테이블을 바탕으로 정보를 재 구성했지만 실제로 데이터를 관리하지는 않는 논리적 실체임. 다만 DB 작업결재는 DB 서버 외부에서 접근제어를 구성하므로 SQL 분석단계에서 테이블과 뷰를 구별할 수 없는 제품이 많으므로, 뷰와 테이블 모두에 대하여 규칙을 정의해 주어야 할 수 있음 / 칼럼 : 테이블에 소속된 정보의 일부 속성값, 주민등록 번호, 성명, 급여 정보 등과 같이 매우 민감한 정보의 경우에는 컬럼 단위로 통제를 해야 할 수 있음

■ SQL 중심 정의
특정 종류의 SQL을 수행하는 경우에 결재를 수행하도록 하는 방식이다. 즉, DROP, TRUNCATE 등의 스키마 구조에 중대한 영향을 미치는 명령을 사용한다든가, GRANT 등의 권한 설정에 중대한 영향을 미치는 SQL에 대해서만 결재를 수행하도록 하는 방식으로 설정하는 것이다.
SQL 단위로 결재를 받는 경우에는 SQL에 대한 수행 횟수에 대해서도 통제할 수도 있 다. 즉, 특정 SQL에 대하여 5회까지만 반복하여 수행할 수 있도록 제한하는 것이다.

② 결재자 정의
결재를 수행할 결재자를 정의하는 것이다. 결재는 특정 1인이 수행할 수도 있지만 결재라 인을 구성하여 다수의 결재자가 순차적으로 결재를 진행하도록 설정할 수 있다. 또한, 특 정 분야는 A 결재경로를 통해 결재를 진행하고, 다른 분야는 B 결재경로를 통해 결재를 진 행하도록 설정한다.

[그림 3-3-8] 결재 경로 등록 예시

“개발팀의 SQL 수행에 대한 결재는 개발팀 결재경로를 통해서 진행한다. 개발팀 결재경 로는 1차 개발팀장, 2차 개발팀 과장 순으로 구성한다”와 같이 결재자를 지정할 수 있다.
2) 작업결제 규칙 설정
① 작업결재 규칙의 구성
DB 작업결재 솔루션마다 나름의 철학이 있고, 아키텍처가 상이하여 작업결재 규칙의 구 성에 차이가 있지만 일반적인 구성은 다음과 같다.

[그림 3-3-9] 결재규칙의 구성

■ 명칭부
규칙의 명칭을 정의하는 구성부분으로 명칭은 규칙의 내용을 간단명료하게 표현할 수 있도록 작성한다. 규칙을 개인단위로 관리하는 경우에는 규칙명에 개개인을 식별할 수 있도록 사용자 ID 혹은 사용자 IP를 추가하여 구성한다.
■ 조건부
규칙이 적용되는 조건을 설정하는 구성부분이다. 조건은 다양한 요소(Factor)의 결합 으로 구성되는데, 사용자를 식별하는 속성, 접근 수단 속성, 접근대상 정보 속성 등으 로구분할수있다. 예를들어,“ 홍길동이라는DB 사용자가GDHONG 이라는ID를사 용하여 192.168.1.10번 IP에서 TOAD라는 툴을 통해 HRDB1 의 HR_USER 계정에 접속하여 SQL을 수행할 때”라는 규칙은 다음과 같이 입력할 수 있다.

[그림 3-3-10] 규칙 조건부 예시

앞의 그림에서 '*' 값이나 'ALL' 은 해당속성은 어떤 값이 와도 상관없다는 의미이다.
■ 제어부
주어진 조건으로 사용자가 접속을 하는 경우에, 어떻게 제어할지를 정의한다. 제어부 에서는 사전 결재, 즉시 결재, 사후 결재 등과 같이 결재 방식을 선택하여 설정한다. 또 한, 결재를 수행할 결재경로를 지정한다.
규칙의 구성은 개인별로 구성하는 방식과 그룹별로 구성하는 방식이 있다. DB에 접근하 는 사용자의 수가 10명 이내의 경우에는 개인별로 규칙을 할당하더라도 관리상의 부담이 크지 않는다. 그러나 수백 명의 사용자가 DB에 직접 접속할 수 있는 경우에 개인별로 규칙 을 관리하면, 보안관리자가 많은 시간을 투여해야 한다는 단점이 있다. 그렇지만 높은 보 안 수준을 유지한다는 관점에서는 꼭 필요한 권한을 개인별로 권한을 관리하는 것이 더 바 람직하다.
그룹별로 규칙을 할당하는 경우에는 먼저 사용자 그룹을 생성한다. 보안정책을 팀 단위로 적용한다면, 팀 단위로 사용자 그룹을 만들어야 한다. 그런 후에 팀 단위로 접속 가능한 DB와 DB 계정 그룹을 만든다. 그리고 팀 단위로 작업결재 규칙에서 사용자 그룹과 DB와 DB 계정 그룹을 매칭하여 규칙을 생성한다.

[그림 3-3-11] 그룹별 규칙 관리

개인별로 규칙을 할당하는 경우에는 개인마다 작업결재 규칙을 만들어 사용자가 접근할 DB와 DB 계정을 할당한다.

[그림 3-3-12] 개인별 규칙 관리

개인별로 접속 가능한 DB와 DB 계정의 수가 여러 개인 경우가 많으므로 DB 와 DB 계정 을 개인별로 그룹을 만들어 할당하는 것이 더 효율적이다. 개인별로 규칙을 관리하는 것이 보안 관점에서는 좋지만, 작업결재를 담당할 전담 인력이 없고 DB 사용자가 많은 경우에 는 그룹별로 관리하는 것이 역량에 적합한 방식이다.

② 결재 사용자 관리
결재 시스템 사용을 위한 사용자 관리가 필요하다. 즉시 결재의 경우에는 DB 접근제어와 사용자를 공유한다. 그러나 사전 결재 및 사후 결재는 DB 접근제어에서 제공하는 결재 시 스템을 사용할 수도 있지만 별도의 결재 시스템을 이용하여 구현할 수도 있다. DB 접근제어의 인증 기능을 이용하여 사용자를 식별하는 경우에는 DB 접근제어의 사용 자 관리 방법에 따라 관리한다. 별도의 결재 시스템을 사용하는 경우에는, 결재 시스템에 서 사용하는 ID와 DB 접근제어에서 사용하는 ID를 일치시키는 것이 바람직하다. 예를 들DB 접근제어에서는 이메일 계정 을 ID로 사용하는 경우에는 사용자에 대한 식별이 어려워 결재에 대한 통제가 불가능하 다. 그러므로 결재 시스템을 사용하는 경우에는 사용자 식별 방식에 대해 DB 접근제어의 ID와 고려해야 한다.

③ 결재자 관리
결재를 수행할 결재자에 대한 관리가 필요하다. 결재자는 결재경로를 통해 결재자로 지정 된다. 결재자가 결재를 할 수 없을 경우 부재중임을 인지할 수 있는 기능과 다른 사람에게 결재를 위임할 수 있는 기능도 필요하다.
결재선은 다단계로 구성된다. 일반적으로 3단계 이내로 구성하지만 조직 체계가 복잡하거 나 감시부서를 결재경로에 포함할 경우 그 이상의 단계로 구성될 수도 있다.

[그림 3-3-13] 결재선 구성 사례

3) 주요 체크 사항
① 결재와 수행 간의 일치성 확인
사전 결재 혹은 사후 결재 방식으로 결재를 수행할 경우, 결재된 SQL과 실제 수행한 SQL 이 동일한지 여부를 확인해야 한다. SQL 문장을 미리 작성하여 사전 결재를 받은 후 수행 하는 경우에는 결재된 SQL과 실제 수행하고 있는 SQL이 동일하도록 강제해야 한다. 즉 사전 결재된 SQL을 수행할 때는 사용자가 임의의 SQL로 변경할 수 없도록 UI 를 제공하 거나 실제 수행할 때, 동일성 여부를 정확하게 체크해야 한다.
금융권에서 요구하는 원장 정정의 경우에는 사전·사후 정보를 포함하여 결재를 받게 되 는데, 이 경우 SQL을 수행하는 단계에서 변경 대상 정보의 상태가 결재를 받은 사전 정보 와 일치하는지 여부를 확인하여 일치하지 않을 경우에는 결재된 SQL을 수행할 수 없도록 해야 한다.
또한, SQL 수행 후 변경된 정보와 사후 정보에 있는 정보를 비교하여 동일하게 변경되었 는지 여부를 확인하여야 한다. 마찬가지로 사후 정보가 다른 경우에는 모든 작업을 (Rollback)하여 원상태로 복구하여야 한다. 변경 전·후가 달라서 수행하지 못하는 경우 에는 재기안하여 결재를 받도록 프로세스를 구축한다.

② 결재 규칙 확인 조직에서 결재를 받아야 하는 대상 정보 및 SQL 종류에 따라 결재 규칙이 적절하게 설정 되어 있는지 확인해야 한다. 최소 권한의 원칙에 따라 DB 사용자가 수행할 수 있는 필요한 권한만을 부여해야 하고, 권한이 부여된 경우라도 관리자의 승인을 거쳐 확인해야 하는 모 든 경우는 결재를 수행하도록 구축하여야 한다.