2. DB 접근제어 설계

가. 접근제어 규칙 정의

ISO/IEC 17799는“정보는 다른 중요한 비즈니스 자산과 같이 가치를 가진 자산이며, 따 라서 적절하게 보호되어야 한다.(Information is an asset which, like other important business assets, has value to an organization and consequently needs to be suitably protected.)”라고 말한다.
이런 정보가 올바로 사용되기 위해서는 다음과 같은 특성을 만족하여야 한다.

■ 정보 식별(Right Information)

접근제어를 할 대상 정보를 식별해야 한다. DBMS 가 관리하고 있는 DB내에는 다양한 정보가 있고 정보의 종류에 따라 적용되는 법규나 제도가 다르기 때문이다. 예를 들어, 개인정보의 경우에 일명 '정보통신망 이용 촉진 및 정보보호 등에 관한 법률(정보통신 망법)'에서는 주민등록번호, 카드번호, 계좌번호 등을 암호화하여 관리해야 하는 대상 으로 시행규칙에 명시했지만, 개인정보보호법의 경우에는 주민등록번호, 여권번호, 운 전면허번호, 외국인등록번호 등을 개인식별번호의 범주에 넣고 해당 정보를 암호화하 여 특별히 관리하도록 하고 있다.

DB에 저장된 정보 중에 개인정보만이 접근을 제어할 가치가 있는 것은 아니다. 금융기 관의 경우 각종 원장 정보는 매우 중요한 정보이고, ERP 시스템에 있는 회계 정보 또 한 회사의 사활을 좌우할 만큼 중요한 정보를 담고 있는 경우가 많다. 법적으로 규제를 받고 있는 대상 정보 이외에 조직의 성격에 따라 분류하여 특별히 관리해야 하는 정보 는 다를 수 있다.

'제 2장 DB보안 정책 수립'의 '제 1절 DB 보안 정책 수립 개요'에서 설명하고 있는 바와 같이, 조직에서 총괄적으로 수립한 보안정책에 따라 DB 접근제어를 해야 하는 정보를 정의해야 한다.

■ 사용자 식별(Right People)

관리 대상 정보로 식별된 정보에 접근할 수 있는 사용자를 파악해야 한다. 일반적으로 DB에 직접 접속이 필요한 사람은 조직 내에서 많지 않지만, 직접 DB에 접속하면서 고 객응대를 하도록 시스템이 구성된 경우에는 수백 명의 내부 직원이 DB에 접속할 수도 있다.
DB에 로그인할 때, 대부분의 DB 접근제어 솔루션은 로그인 하는 사용자의 IP 및 MAC 주소까지 사용하여 식별을 하는데 사용자의 IP는 바뀔 수 있다. 따라서, 개개인에게 별 도의 ID와 패스워드를 부여하여 추가로 인증을 수행한 후에 로그인 하도록 할 수도 있 다. 이런 경우, 인증을 위한 프로그램을 DB에 접속하는 모든 사용자 단말기에 설치해 야 한다.

■ 접근 방법(Right Form)

정보에 접근할 수 있는 방법을 정의해야 한다. DB 사용자들이 DB에 접속하기 위해 사 용할 수 있는 단말기, 접속 툴, 접속 프로토콜 등을 지정한다. DB에 대한 접속 툴을 표 준화한 조직이 많다. 알려지지 않은 툴을 통해 접속할 경우 보안 관점에서 취약점이 노 출될 수 있기 때문에 통제를 하기도 하고, 정당한 라이센스가 없는 툴의 사용을 제한하 기 위하여 통제하기도 한다.

또한, DB에 로그인을 한 이후에 수행할 수 있는 SQL의 종류를 통제할 수 있다. 일반적 인 DB 사용자의 경우에는 SELECT 문장을 수행할 수 있는 권한이면 대부분의 업무를 수행하는데 지장이 없다. 이런 경우에는 SELECT 문장만 수행 가능하도록 권한을 제한 하면 사용자의 실수 혹은 고의로 정보의 무결성이 깨지는 상황을 방지할 수 있다. DBA나 운영자의 경우에는 모든 종류의 SQL을 수행하도록 하고 각 정보에 관리책임이 있는 담당자는 SELECT, UPDATE, DELETE, INSERT, COMMIT, ROLLBACK 등의 명령 수행이 가능하도록 한다. 기타 일반 사용자에게는 SELECT 문장만 수행이 가능하도록 제한한다.

■ 접근 시간(Right Time)

정보에 접근할 수 있는 시간을 통제해야 한다. 특별히 민감한 정보는 업무 시간에만 접 속이 가능하도록 설정해야 하며, 그 외에 해당 정보에 접근하는 경우에는 차단하거나 경보를 발령하도록 하여 보안관리자가 해당 상황을 인지하도록 해야 한다. 또한 장시간 단말기를 떠나 있다가 다시 DB에 명령을 수행하려고 하는 경우에도 동일 인인지 여부를 확인하여 SQL을 수행하도록 하거나, 해당 세션을 차단한 후 재 접속하 도록 설정하여야 한다.

2) 접근제어 규칙 종류 및 설정

DB 접근제어 솔루션마다 나름의 철학이 있고, 아키텍처가 상이하여 접근제어 규칙의 구 성에 차이가 있다. 그렇지만 일반적으로 규칙은 다음과 같이 구성된다.

■ 명칭부

명칭부는 규칙의 명칭을 정의한 것이다. 명칭은 규칙의 내용을 간명하게 표현할 수 있 도록 작성하고 규칙을 개인단위로 관리하는 경우에는 규칙명에 개개인을 식별할 수 있 도록 사용자 ID 혹은 사용자 IP를 추가하여 구성한다.

■ 조건부

조건부는 규칙이 적용되는 조건을 설정한 것이다. 조건은 다양한 요소(Factor)의 결합 으로 구성되는데, 사용자를 식별하는 속성, 접근 수단 속성, 접근대상 정보 속성 등으 로 구분할 수 있다.
규칙조건 사례로“홍길동이라는 DB 사용자가 GDHONG 이라는 ID를 사용하여 192.168.1.10 번 IP에서 TOAD라는 툴을 통해 HRDB1 의 HR_USER 계정에 접속 하는 할 때”라는 규칙은 다음과 같이 입력할 수 있다.

앞의 그림은 '*' 값이나 'ALL' 은 해당속성은 어떤 값이 와도 상관없다는 것을 의미한다.

■ 제어부

제어부는 주어진 조건으로 사용자가 접속을 하는 경우에 어떻게 제어할지를 정의한 것 이다. 제어부에서 정의해야 하는 통제 종류는 로그인 통제, SQL 통제, 로깅 통제, 경 보 통제 등이 있다.
？로그인 통제 : DBMS에 DB 사용자가 로그인 하는 과정에서 권한이 없는 계정에는 로그인할 수 없도록 통제되어야 한다.
？SQL 통제 : DB 사용자가 DBMS에 로그인 한 후에 사용할 수 있는 SQL의 종류를 통제하는 규칙이다. 사용자 별로 권한이 있는 SQL만을 사용할 수 있도록 통제되어 야 한다. 또한 테이블·칼럼 단위로 권한이 없는 사용자의 접근이 통제되어야 한다.
？로깅 통제 : 저장되는 SQL을 설정한다. 기본적으로 모든 SQL을 저장하도록 설정하 지만, 불필요한 SQL을 저장하지 않도록 설정을 한다. 또한, SELECT 문장의 경우 조??보 통제 : DB 접근제어 과정에서 보안정책을 위반하는 사건이 발생하게 되는데, 이런 경우에는 보안 관리자에게 통지하여 즉각적인 대응을 할 수 있도록 해야 한다.

① 로그인 통제 규칙

DBMS에 로그인 하는 과정을 통제하는 규칙이다. DBMS에 로그인 하기 위해서는 반드시 DBMS내에 생성된 계정 및 패스워드가 필요하다. 예전의 클라이언트/서버 모델의 환경에 서는 DBMS에 접속하는 모든 사용자에게 개별 계정을 부여하였고, 해당 계정에 따라 권한 을 통제하였다. 이런 환경에서는 제3의 솔루션을 통한 로그인 제어가 필요가 없다. 현재에 도 이런 방식으로 사용자 개개인별로 DB 계정을 부여하여 로그인 통제를 실시하고 있는 조직도 많이 있다.

그러나 최근에는 웹 기반으로 시스템 구성이 변경되면서 하나의 DB 계정을 다수의 사용자 가 공유하는 경우가 많아졌다. 특히, 다수의 DBMS를 관리하는 DBA 입장에서 DB 계정 을 사용자 별로 관리하는 것은 매우 노력이 많이 드는 일이다. 이런 이유로 DB 계정을 다 수의 사용자에게 개방하는 경우가 많은데, 개개인 별로 실제로 접속한 사용자를 식별할 수 없는 문제가 있다.

DB 접근제어에서는 개개인을 좀더 상세히 식별하기 위하여 DB 계정 이외에, 접속하는 사 용자의 다른 속성을 추가하여 제어를 하는데, IP, 접속 툴, 접속자 단말기 명, 접속 프로토 콜(TCP, BEQ 등) 등의 다중 요소(Multi-Factor)를 조합하여 DBMS에 대한 접속 허용 여부를 결정한다. 이들 외에도 접속자의 접속 시간대를 추가하여 통제하기도 하는데, 일 반적인 업무 시간 이외에 중요한 계정에 접속하는 것을 통제하는 방식이다.
로그인 규칙을 통해 DB에 접속하는 사용자마다 접속 가능한 DB 및 DB 계정을 설정한다. DB 및 DB 계정의 그룹을 만들어 허용 혹은 차단할 수도 있다. 이런 작업이 진행되려면 미 리 사용자 별로 접근 가능 혹은 차단해야 하는 DB 및 DB 계정이 정의되어 있어야 한다. DB 및 DB 계정에 대한 통제는 조직의 보안 수준 및 정책에 따라 결정된다. 그러나 보안의 기본 원칙인 최소 권한의 원칙에 따라 가급적 사용자에게 필요한 DB 및 DB 계정만 접근 가능하도록 관리하여야 한다.

DB 사용자별로 접근 가능한 DB 및 DB 계정을 조사하기 위하여 다음과 같은 양식을 사용 할 수 있다.

사용자 별로 로그인 권한에 대한 정의가 완료되면 정의된 내용을 DB 접근제어 솔루션에서 설정한다.

DB 계정 및 패스워드가 있으면 DB에 로그인 할 수 있지만 DB 접근제어에서는 부가적으 로 자체 인증기능을 제공하고 있다. 보안의 최소 권한의 원칙에 따라 개인별로 필요한 최소한의 정보만 접근가능 하도록 해야 한다. 그러나 현실적으로 수백 명이 DB에 접근하는 상황에서 개인별로 권한을 관리하기는 매우 어렵고 많은 인력이 필요하게 된다.
이런 경우에는 그룹으로 묶어서 관리할 수 있다. 즉, DB명 그룹, DB계정명 그룹 등을 생 성하며 테이블명과 칼럼명 그룹을 만들어 관리할 수 있다.

■ 인증(Authentication) 기능

DB 계정을 공유하여 사용하고 있는 환경에서는 실제로 DB에 접속한 사용자를 정확히 식별하지 못하는 경우가 발생할 수 있다. 이런 경우를 방지하기 위하여 DB 접근제어에 서는 부가적으로 인증하는 기능을 제공한다.

접속하는 사용자를 식별하는 인증에는 크게 3가지 방식이 있다.
① 접속하는 당사자만이 알 수 있는 것을 이용하는 방식(ID/Password 방식)
② 접속하는 당사자가 소유한 것을 이용하는 방식(인증서 방식)
③ 접속하는 당사자의 생물학적 속성을 이용하는 방식(지문, 홍채인식 등)
이중에 가장 보편적으로 쓰이는 방식이 개인별로 ID를 정하고, 패스워드를 설정할 수 있도록 하는 것이다. 일반적으로 개인별 ID는 직원번호 혹은 메일 계정 ID 등을 이용할 수 있다. 패스워드는 초기화된 값을 개인별로 변경하도록 한다.

인증 기능을 사용하는 경우에 DB 사용자는 DB에 접속할 때, 항상 개인의 ID와 패스워 드를 별도의 인증 창에 입력하여 DB 접근제어 솔루션에서 인증이 통과된 경우에만 최 종적으로 DB에 로그인 할 수 있게 된다. IP가 자주 바뀌는 환경이거나, 변동 IP를 사용 하는 환경에서 DB 작업이 이루어지는 경우에는 반드시 인증 기능을 사용하여 개인을 정확히 식별하여야 한다.

규칙의 구성은 개인별로 하는 방식과 그룹별로 하는 방식이 있다. DB에 접근하는 사용 자의 수가 10명 이내의 경우에는 개인별로 규칙을 할당하더라도 관리상의 부담이 크지 않는다. 하지만 수백 명의 사용자가 DB에 직접 접속할 수 있는 경우에는 개인별로 규 칙을 관리하면 보안관리자가 많은 시간을 투여해야 한다. 그러나 높은 보안 수준을 유 지한다는 관점에서는 개인별로 권한을 관리하는 것이 더 좋다.
그룹별로 규칙을 할당하는 경우에는 먼저 사용자 그룹을 설정한다. 보안정책을 팀 단위 로 적용한다면, 팀 단위로 사용자 그룹을 만들어야 하고 팀 단위로 접속 가능한 DB 및 DB 계정 그룹을 만든다. 그런 후에 팀 단위로 로그인 규칙에서 사용자 그룹과 DB 및 DB 계정 그룹을 매칭하여 규칙을 생성한다.

개인별로 규칙을 할당하는 경우에는 사용자 그룹을 만들지 않으며, 개인마다 로그인 규 칙을 만들어 사용자가 접근할 DB 및 DB 계정을 할당한다.

개인별로 접속 가능한 DB 및 DB 계정의 수가 여러 개인 경우가 많으므로, 계정을 개인 별로 그룹을 만들어 할당하는 것이 더 효율적이다. 개인별로 규칙을 관리하는 것이 보 안 관점에서는 좋지만, DB 접근제어를 담당할 전담 인력이 확보되지 않고 DB 사용자 가 많은 경우에는 그룹별로 관리하는 것이 효율적이다.

② SQL 수행 통제 규칙

SQL 수행 통제 규칙은 DB 사용자가 SQL을 수행할 때마다, 해당 SQL 수행의 권한을 체 크하여 실행을 허용할 것인가 말 것인가를 결정하는 규칙이다. 권한을 체크하는 범주는 SQL의 종류일 수도 있고, SQL이 접근하려고 하는 테이블 또는 컬럼일 수도 있다. 개발 환경에 있는 DB의 경우에는 개발자가 조회, 수정, 추가, 삭제의 권한을 가져야 하지 만, 운영환경에서는 개발자에게 조회 권한만 부여하도록 한다. 개발환경이라고 하더라도 개발자에게 테이블의 구조를 변경할 수 있는 DROP, ALTER TABLE 등의 SQL은 수행 할 수 없도록 하는 것이 안정적으로 개발 환경을 유지하는 방법이다.
다음 그림은 SQL 종류별로 규칙을 설정하는 예시 화면이다.

SQL Injection 같은 공격을 방어하기 위해 보안서버 내에 저장된 SQL만 수행할 수 있도 록 제어할 수도 있다.
SQL Injection이란 내부 로직이 SQL에 입력된 문자열을 붙여서 구성하는 경우에 행할 수 있는 공격이다. 만일 내부적으로 정상적인 상황의 SQL을 모두 저장하여 관리하고 있 다면, SQL Injection 공격에 의하여 변형된 SQL을 쉽게 인지할 수 있다.이런 경우에는 SQL을 차단 하거나 경보를 발령하여 대응하도록 설정할 수 있다.

사용자 별로 사용할 수 있는 SQL 종류를 지정하는 것도 중요하지만, 중요한 테이블의 경 우에는 컬럼 단위까지 접근권한을 통제해야 한다. 이를 위해 중요한 테이블에 대한 정의가 선행되어야 하는데, 자세한 사항은 '제2장 제 1절의 DB 보안 정책 수립 개요'를 참조한다. 조직에 의해 테이블·컬럼 단위까지 접근제어가 이루어져야 하는 정보에 대해 정의가 되 어야 한다. 테이블·컬럼 정보를 개인마다 다르게 관리하는 것은 매우 어려우므로 정보를 분류하여 분류된 단위로 권한을 관리해야 한다.

주민등록번호, 성명, 전화번호, 주소, 이메일 주소 등과 같은 기본정보는 물론 교육, 병 력, 재무상태, 종교적 신념 등의 다양한 개인정보는 허용된 사람만 접근할 수 있도록 통제 하여야 한다. 또한 조직의 중요한 정보, 원장정보, 회계정보, 재무정보 등과 같이 대외비 로 분류된 정보에 대해서도 엄격하게 접근을 통제하여야 한다.

민감한 정보를 통제하는 방법은 두 가지가 있다. 첫째, 민감한 정보에 접근하는 SQL을 차단하는 것이다. 수행하는 SQL을 파싱(Parsing) 한 후, 민감한 정보가 들어있는 테이블·컬럼을 사용하는지 여부를 판단하여 해당 사용자 가 접근할 수 없는 테이블·컬럼인 경우 해당 SQL을 차단한다.
둘째, 마스킹 처리하는 방법이다. 권한이 없는 사용자가 민감한 정보를 조회하는 경우에 는 일부 정보를 '*'로 치환하여 정보를 보호할 수 있다.
마스킹 기능은 조회 결과 변조 방식과 SQL 변조 방식으로 구분할 수 있다.

■조회 결과 변조 방식
조회 결과의 패턴을 분석하여 마스킹하는 방법이다. 예를 들어, 주민번호의 경우 6자 리의 생년월일 정보와 7자리의 부가 정보로 총 13개의 숫자로 구성된다. 이런 형식으 로 정보가 조회되는 경우, 주민번호라고 간주하고 뒤의 7자리 정보를 마스킹하는 방법 이다.

조회결과 변조 방식은 패턴을 기반으로 동작하므로 SQL에 대한 분석이 필요 없다. 또 한 테이블·컬럼별로 지정해 주지 않더라도 패턴만 맞으면 변조가 되므로 설정이 매우 간편하다. 그러나 패턴이 변경된 경우 마스킹이 제대로 동작하지 않는다는 문제점이 있 어 DB 사용자가 매우 간단한 방법으로 우회하여 접근할 수 있다는 한계가 있다.

■ SQL 변조 방식
SQL 변조 방식의 마스킹은 마스킹이 되도록 SQL을 변경하여 DB 서버에 제공하는 방 식이다. SQL을 파싱하여 마스킹 대상 정보에 접근여부를 판별하고 보호해야 할 정보 접근의 경우 일부분을 미리 정의된 마스킹 함수 사용 코드로 변경한다.

SQL 변조 방식은 조회결과 변조 방식과 달리 우회하여 접근하기가 어렵다. SQL 변조 방식은 패턴을 기반으로 하지 않으므로 주민번호의 패턴을 변경하여 조회하더라도 마 스킹을 유지하기 때문에 보안관점에서 더욱 안전한 방식이라 할 수 있다. 다만, DB 접 근제어 솔루션이 SQL에 대한 파싱을 정교하게 할 수 있는 기술력이 있어야 하며, 테이 블·컬럼 단위로 마스킹 여부를 설정해야 하므로 설정 과정에 좀 더 많은 노력이 필요 하다.

③ 로깅 통제 규칙

DBMS에 로그인하는 정보 및 로그인 한 후 수행한 SQL 정보는 저장되어야 한다. 그러나 애플리케이션 서버를 통해 수행되는 SQL 중에 수행 횟수는 많지만 보안적으로 의미 없는 SQL도 많이 저장된다. 이렇게 저장된 무의미한 SQL(예 : 코드화된 메타정보 조회 등)은 로그량을 증가시켜 보고서 생성이나 원하는 정보를 추적하는데 시간이 많이 소요되고 하 드디스크 사용량은 증가시킨다.

이런 경우처럼 보안 관점에서 무의미한 SQL은 저장되지 않도록 설정할 필요가 있다. 또 한, SQL 수행 정보를 저장할 때는 바인드(Bind) 변수, 리턴(Return) 값 등을 저장하는 수준도 설정해서 반드시 필요한 경우에는 모든 정보가 저장되도록 하고, 그렇지 않은 경우 에는 표본 정도만 저장하도록 설정한다,
다음 그림은 SQL 문장 단위로 로깅 여부를 설정하는 예시인데, 수행 횟수로 정렬을 한 후 에 보안 관점에서 의미가 없는 SQL은 로깅하지 않도록 설정한 것이다.

④ 경보 통제 규칙

DB 접근제어 과정에서 보안정책을 위반하는 사건이 발생하게 되는데, 이런 경우에는 보 안 관리자에게 통지하여 즉각적인 대응을 할 수 있도록 해야 한다. 기본적으로 경보를 설 정해야 하는 중요한 이벤트는 다음과 같다.

？반복적인 인증 실패
？접근이 금지된 DB 계정, 테이블·컬럼에 접근 시도
？허용되지 않은 종류의 SQL 수행 시도
？대량 데이터 조회

경보는 다양한 방법으로 보안 관리자에게 전송될 수 있다. 일반적으로 이메일에 경보 메시 지를 송신하거나 SMS를 통해 문자메시지를 전송한다. 또한, 보안 관리자의 관리 화면으 로 경보 메시지를 전송하기도 한다. 보안 솔루션에서 메일 서버를 같이 제공하는 경우도 있고, 조직 내에 구축된 메일 서버를 이용하여 구축할 수도 있다. 문자메시지 전송의 경우 에는 전송 체계가 조직 내에 갖추어진 경우에 가능하다.

⑤ 모니터링 지표 설정

설정된 정책에 따라 정상적으로 운영되고 있는지, 평상 시와 차이가 있는지 등을 즉각적으 로 인지하기 위하여 현재의 보안 상황을 평가할 수 있는 지표를 관리하여야 한다.
■ 시스템 상태 지표
보안 서버의 상태를 총괄적으로 보여주는 지표

보안 지표의?에 한정하여 SQL 발생 건 수 및 차단 건수 등에 대한 지표를 별도로 관리할 수도 있다.
모니터링 지표는 DB보안 시스템을 관리하는데 있어서 핵심적인 부분이다. 조직의 특 성에 따라 필요한 지표를 생성한 후, 해당 지표를 솔루션에서 제공하지 못하는 경우에 는 솔루션을 커스터마이징하여 해당 지표의 추이를 볼 수 있도록 확장해야 한다.

3) 주요 체크 사항 접근제어 규칙이 제대로 설정되어 있는지를 진단하는 것은 매우 어려운 일이다. 그러나 보 안 위반 사건이 발생했을 때, 적절하게 추적할 수 있도록 일관성 있는 통제와 로깅이 이루 어 질 수 있도록 접근제어 규칙이 설정되어야 한다.

① 사용자 식별 및 추적성 확보

보안 사건이 발생했을 때, 해당 사건을 일으킨 사용자를 추적할 수 있어야 한다. 이를 위해 서는 기본적으로 DB에 로그인 할 때, 사용자에 대한 적절한 식별이 가능해야 한다. DB 접근제어 솔루션은 DB 사용자와 DB 서버 사이에서 중계 역할을 담당하는데, 부가적 인 장치가 없다면 사용자 식별에 사용할 수 있는 일반적인 방법은 통신이 이루어지고 있는 양쪽 끝 지점의 IP 및 Port, MAC 주소를 가지고 사용자를 식별하는 방법을 사용한다. 하 지만 이것의 가장 큰 문제는 개인별로 할당된 IP 가 변경될 수 있다는 점이다.

예를 들어, 김갑수라는 사용자에게 192.168.1.100 이라는 IP가 부여 되었다가, 인사이 동이나 내부 네트워크 구성 변경으로 인하여 192.168.102 라는 번호를 할당할 수도 있 다. 그런 후에 192.168.1.100 이라는 IP 를 이남선에게 할당을 한다면 과거 김갑수가 했 던 모든 작업이 이남선이 수행한 것으로 오해 받을 수 있는 상황이 된다.
이런 상황을 방지하기 위해서는 DB에 로그인 한 정보를 저장하기 전에 사용자에 대한 식 별이 이루어져야 한다. 가장 좋은 방법은 DB에 접속하는 모든 사용자에 대해 인증을 수행 하도록 하거나, 인증이 불가능한 사용자 혹은 애플리케이션 서버의 경우에는 현재의 IP 정 보를 기반으로 사용자를 식별하여 ID로 치환한 후에 저장하는 것이다.

이렇게 ID로 치환하여 저장이 가능하도록 하기 위해서는 반드시 다음과 같은 운영이 가능 해야 한다.
■ 인증
DB 사용자가 DBMS에 로그인 하기 위해서 개인별로 부여된 ID 및 패스워드를 입력한 후 로그인(DB계정 및 패스워드와는 별도임)
■ 내부사용자 등록
DB에 접속 가능한 내부 사용자 정보를 모두 파악하여 현재 접속 IP 및 개인별 ID 정보 저장. 접근제어 솔루션은 이 정보를 이용하여 로그인 정보를 저장할 때, ID 정보로 전 환하여 저장 인증을 사용하거나, 내부 사용자 정보를 관리하는 대신 DBMS계정을 개인별로 할당하는 방법도 가능하다. 즉, DBMS내부에 테이블 생성된 계정 이외에 개개인 별로 별도의 계정 을 생성한 후 필요한 권한 및 뷰, 동의어(Synonym) 등을 생성하여 사용할 수 있다. 이 방 법은 매우 정교한 통제가 가능한 반면에 개인별로 계정을 관리해 주어야 하므로 DBA의 업 무량이 증가하는 부담이 있다.

사용자의 IP를 ID로 전환하지 않고 그대로 저장하더라도 특정 시점의 IP를 누구에게 할당 하였는지 정보를 별도로 저장한다면 추적성이 확보되었다고 볼 수 있다. 다만, 이런 경우에 보고서 등을 작성할 때, 과거 시점의 정보는 과거 시점의 상황을 반영하여 작성하여야 한다.

② 로그인 가능 DB 및 계정 통제

사용자 별로 로그인 가능한 DB 및 계정을 통제하여야 한다. 많은 경우 하나의 사용자에 모 든 정보가 저장되도록 DB가 구성되어 있는데, 이런 경우에는 사용자 별로 접속 가능한 DB 계정을 통제할 수 없다. 그러나 여러 개의 DB가 있는 경우에 모든 DB에 접속이 필요 한 사용자는 극히 제한적이고 일반적으로 사용자 별로 필요한 DB는 다를 수 있다.
DB 접근제어를 설치하는 과정에서 민간회사나 공공기관의 경우 이런 사용자 별로 로그인 가능한 DB 및 계정 정보가 제대로 관리되지 않는 경우가 많다. DB 접근제어의 첫걸음은 접속 가능한 계정만을 접속하도록 하는 것에서부터 출발하므로 반드시 로그인 가능 범위 는 정의되고 통제되어야 한다.

③ SQL 종류 및 객체 단위 통제

DB에 접속하는 사용자의 경우 다음과 같이 그룹핑 할 수 있다.

■ 개발자
테스트 DB에 접속 가능. 경우에 따라 프로그램 검증을 위해 운영계 DB에 제한적으로 접속하도록 할 수 있음. SELECT, INSERT, UPDATE, DELETE, COMMIT, ROLLBACK 등의 제한 SQL 만 수행 가능하도록 제한하는 것이 바람직하다. 다만, 개 발자가 사용하는 접속 툴에 따라서 로그인 과정에서 별도의 SQL을 수행하는데 ALTER 같은 문장을 사용하는 경우가 있으므로 해당 SQL은 수행 가능하도록 설정해 야 DB 접속이 가능하다.

■ 업무 담당자
업무상 필요에 따라 개발, 테스트, 운영 환경의 DB에 접속이 필요한 DB 사용자. 일반 적으로 SELECT 권한만을 필요로 하지만, 경우에 따라서는 INSERT, UPDATE, DELETE 권한이 필요할 수도 있다.

■ DB 관리자
DB에 대한 제한 없는 접근이 가능하고 수행 가능한 SQL의 종류도 제한이 없다. ■ 애플리케이션 프로그램
애플리케이션 서버에 설치된 프로그램이 실행과정에서 DB에 SQL을 수행. 개발자와 거의 동일한 SQL 권한을 가짐. 다만 애플리케이션은 운영 DB에서 해당 SQL을 모두 수행 가능하도록 설정함
수행할 수 있는 SQL 종류에 대한 설정은 사용자를 앞의 설명과 같이 그룹핑 한 후에 해당 그룹에서 수행 가능한 SQL을 지정하는 방식으로 설정한다. 다만, 조직의 특성상 중요한 정보가 있는 테이블에 대해서는 접근 가능한 사용자 및 수행 가능 SQL을 별도로 지정하여 야 한다. 중요정보 테이블 및 컬럼도 정보의 성격에 따라 그룹핑하여 접근 가능한 사용자 들을 지정할 수 있다.

④ IDLE 사용자 통제

DB에 로그인한 후, 일정 시간 동안 SQL을 수행하지 않는 경우에는 해당 세션을 차단하거 나 재 인증 후 사용하도록 하여야 한다. DB 사용자가 자리를 비우는 경우에도 DB 사용자 단말기에 접속된 세션은 해당 사용자에게 부여된 모든 권한을 허용한 상태가 된다. 만일 다른 사람이 악의적으로 이용하는 경우에는 해당 행위를 통제할 수 없고 또 로깅된 기록에 대한 신뢰를 악화시키는 요인이 된다. 그러므로 DB 사용자가 장시간 자리를 비울 때에는 해당 세션들을 종료하는 것이 바람직하다. 이때, 접근제어 시스템은 해당 세션을 통제하 여야 한다.

⑤ 감사통제

DB에 로그인한 접속 기록 및 접속 후에 수행한 SQL에 대한 로깅을 하여야 한다. SQL 수 행 과정에서 BIND 변수를 사용한 경우에는 BIND 변수의 내용을 같이 저장하여야 한다. SELECT 문장의 경우 조회된 결과를 같이 저장하는 것이 바람직 하다. 다만, 조회 결과가 너무 많거나, 조회 결과를 저장하는 것이 보안 관점에서 또 다른 문제를 야기할 가능성이 있는 경우에는 조회 결과를 저장하지 않도록 설정할 수 있다.

내부 사용자가 수행한 SQL문장은 모두 저장하여야 한다. 다만, 스니핑 방식으로 애플리 케이션 서버에서 업무 프로그램 수행과정에서 실행한 SQL 중 보안 관점에서 의미가 없는 SQL은 효율적인 관리를 위해 저장 대상에서 제외한다. 예를 들어, 대부분의 업무 프로그 램의 경우 메타 정보를 코드화하여 관리하는 경우가 많은데, 코드 조회성 SQL은 보안상 문제가 발생할만한 정보를 제공하지 못하므로 저장 범위에서 제외한다.
대부분의 DB 접근제어 솔루션은 SQL 수행 건수별로 정렬하여 SQL을 보여주는 기능을 갖고 있으며, SQL 문장 단위로 로깅 통제 기능을 제공하고 있는데 이런 기능을 이용하여 불필요 SQL을 확인한 후 대상에서 제외한다. 금융권의 경우에는 법적인 규제에 따라 원 장 테이블과 같은 핵심 정보의 경우 변경 전·후 정보를 저장하여야 한다.

⑥ 경보통제

중대한 보안 위반 사건이나 점검해야 하는 이벤트가 발생한 경우에는 보안 관리자가 해당 사건을 조속히 인지할 수 있도록 경보를 발송하여야 한다. 경보 발송은 이메일, 문자메시 지, 관리자 화면, 메신저 등으로 발송하는데, 발송 매체는 조직의 보안정책 및 관련된 인 프라의 구축여부에 따라 달라질 수 있다.
중요 이벤트에 대해서 경보를 발송하도록 설정하여야 하며 발생한 경보는 모니터링을 통 하여 상시적으로 관리할 수 있어야 한다. 또한, 주기적으로 경보 발생 내용을 점검하고 필 요한 경우 상급관리자에게 보고한다.

⑦ 중요 정보 마스킹 통제

개인정보나 중요 정보에 대해서 권한 없는 사용자가 해당 정보를 접근하지 못하도록 하여 야 한다. 정보에 접근하지 못하도록 하는 방법은 두 가지가 있는데, 해당 정보를 조회하는 SQL을 차단하는 방법이 있고, 해당 정보의 중요 부분을 '*' 등으로 변경(마스킹)하여 보여 주는 방법이 있다.
DB 암호화 솔루션이 설치된 경우, 권한이 없는 정보는 마스킹 처리가 가능하다. 그러나 DB 접근제어 솔루션과 DB 암호화 솔루션이 같이 설치된 경우, 접근제어를 경유한 세션에 대하여 암호화 솔루션에서 통제할 수 없다. 이런 경우에는 DB 접근제어 솔루션에서 마스 킹 기능을 제공하여야 한다.

마스킹 대상은 주로 주민번호, 카드번호, 계좌 번호 같은 개인정보 관련된 사항이나 급여 및 인사 평가 정보, 재무 회계 정보 등과 같이 조직 내부에서 대외비로 분류되어 특별히 관 리해야 하는 정보이다.

⑧ 모니터링

조직 내에서 DB 보안 상태를 총괄적으로 파악할 수 있는 모니터링 체계를 구축해야 한다. 또한 조직의 특성에 맞게 모니터링 지표가 관리되어야 하며, 상태를 비교할 수 있도록 모 니터링 추이를 관측할 수 있어야 한다.