1. DB 접근제어 개요

가. 정의

DB는 조직에 필요한 정보로서 DBMS라는 관리 시스템에 의해 관리되며 인증과정을 거쳐 로그인한 후에 SQL이라는 질의어를 통해서만 해당 정보에 정상적으로 접근할 수 있다. 일반적으로 DB는 DMZ를 거쳐 조직의 가장 내부에 위치하고 있고 DBMS 자체가 강력한 보안기능을 제공하기 때문에 해킹보다는 DB에 접근 권한을 가진 사용자가 권한을 남용하 여 정보를 유출하거나 변조하는 것이 가장 중요한 위협이다.

이런 위협에 따라 정부는 각종 규제를 만들어 개인정보 등의 중요한 정보를 관리하는 개인 정보처리시스템에 대한 안전한 관리를 하도록 요구하고 있다.

■「정보통신망 이용촉진 및 정보보호 등에 관한 법률」의 기술적 관리적 보호조치 기준(방통위고시 제 2011-1호)

제4조(접근제어)

①정보통신서비스 제공자등은 개인정보처리시스템에 대한 접근권한을 서비스 제공을 위하여 필요한 개인정보관리책임자 또는 개인정보취급자에게만 부여한다.
②정보통신서비스 제공자등은 전보 또는 퇴직 등 인사이동이 발생하여 개인정보취급자가 변경되었을 경우 지체 없이 개인정보처리시스템의 접근권한을 변경 또는 말소한다.
③ 정보통신서비스 제공자등은 제1항 및 제2항에 의한 권한 부여, 변경 또는 말소에 대한 내역을 기록 하고, 그 기록을 최소 5년간 보관한다.
④ 정보통신서비스 제공자등은 개인정보취급자가 정보통신망을 통해 외부에서 개인정보처리시스템에 접속이 필요한 경우에는 공인인증서 등 안전한 인증 수단을 적용하여야 한다.
⑤ 정보통신서비스 제공자등은 정보통신망을 통한 불법적인 접근 및 침해사고 방지를 위해 다음 각 호 의 기능을 포함한 시스템을 설치_운영하여야 한다.

1. 개인정보처리시스템에 대한 접속 권한을 IP주소 등으로 제한하여 인가 받지 않은 접근을 제한
2. 개인정보처리시스템에 접속한 IP주소 등을 재분석하여 불법적인 개인정보 유출 시도를 탐지

⑥ 정보통신서비스 제공자등은 이용자가 안전한 비밀번호를 이용할 수 있도록 비밀번호 작성규칙을 수립하고, 이행한다.
⑦ 정보통신서비스 제공자등은 개인정보취급자를 대상으로 다음 각 호의 사항을 포함하는 비밀번호 작성규칙을 수립하고, 이를 적용_운용하여야 한다.

1. 다음 각 목의 문자 종류 중 2종류 이상을 조합하여 최소 10자리 이상 또는 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성
가. 영문 대문자(26개)
나. 영문 소문자(26개)
다. 숫자(10개)
라. 특수문자(32개)

2. 연속적인 숫자나 생일, 전화번호 등 추측하기 쉬운 개인정보 및 아이디와 비슷한 비밀번호는 사용하지 않는 것을 권고
3. 비밀번호에 유효기간을 설정하여 반기별 1회 이상 변경

⑧ 정보통신서비스 제공자등은 취급중인 개인정보가 인터넷 홈페이지, P2P, 공유설정 등을 통하여 열람권한이 없는 자에게 공개되거나 외부에 유출되지 않도록 개인정보처리시스템 및 개인정보취급 자의 컴퓨터에 조치를 취하여야 한다.

제5조(접속기록의 위·변조방지)

① 정보통신서비스 제공자등은 개인정보취급자가 개인정보처리시스템에 접속한 기록을 월 1회 이상 정기적으로 확인_감독하여야 하며, 시스템 이상 유무의 확인 등을 위해 최소 6개월 이상 접속기록 을 보존_관리하여야 한다.
② 단, 제1항의 규정에도 불구하고「전기통신사업법」제5조의 규정에 따른 기간통신사업자의 경우에 는 보존_관리해야 할 최소 기간을 2년으로 한다.
③ 정보통신서비스 제공자등은 개인정보취급자의 접속기록이 위_변조되지 않도록 별도의 물리적인 저 장 장치에 보관하여야 하며 정기적인 백업을 수행하여야 한다.

제9조(개인정보 표시 제한 보호조치)

정보통신서비스 제공자 등은 개인정보 업무처리를 목적으로 개인정보의 조회, 출력 등의 업무를 수행 하는 과정에서 개인정보보호를 위하여 개인정보를 마스킹하여 표시제한 조치를 취하는 경우에는 다음 의 원칙으로 적용할 수 있다.
1. 성명 중 이름의 첫 번째 글자 이상
2. 생년월일
3. 전화번호 또는 휴대폰 전화번호의 국번
4. 주소의 읍_면_동
5. 인터넷주소는 버전 4의 경우 17_24비트 영역, 버전 6의 경우 113_128비트 영역

DB 접근제어는 사용자가 DBMS에 로그인 하거나 SQL을 수행하려고 할 때 미리 정의된 보안규칙에 따라 권한 여부를 판단하여 통제하는 솔루션이다. 일반적으로 SQL을 통제할 뿐만 아니라 로깅이 필요한 SQL에 대하여 SQL 수행과 관련된 정보를 저장하는 기능을 제공하고 있다.
다음 그림은 DB 접근제어가 DBMS의 각 영역에서 어떻게 보안을 강화하는지 보여준다.

DBMS에도 강력한 접근제어 기능이 있지만 부가적으로 별도의 DB 접근제어 솔루션을 도 입하여 DB를 보호하고 있다. 부가적으로 DB 접근제어가 필요한 이유를 살펴보면, 첫째, 세분화된 사용자 식별이 필요하기 때문이다. DBMS에서 수행하는 통제는 DBMS 내부 의 계정 단위로 구성되어 있다. 많은 조직에서 하나 혹은 소수의 계정에 필요한 모든 테이블 을 생성한 후에, 다수의 내부 사용자가 동일 계정을 이용하여 DB에 접근한다. 이럴 경우 DBMS에서 제공하는 보안 기능은 개개인을 식별할 수 없어서 제대로 접근을 통제할 수 없다. 둘째, DBMS에 대한 부하가 증가되기 때문이다. 모든 로그를 남겨야 하는 금융권 등의 시 스템은 DBMS에서 제공하는 감사 기능을 활성화할 경우 DBMS 시스템에 많은 부하가 발 생하게 된다. 이런 이유로 DB 접근제어 솔루션은 기존 DB 서버 외부에 설치하여 DBMS 에 대한 부하를 주지 않으면서 모든 로그를 기록하는 기능을 제공한다.

셋째, DBMS에서 제공하는 기능만으로 편리하게 관리할 수 없기 때문이다. 주민번호의 뒷자리만을 '*'로 치환하는 마스킹(Masking) 기능, 각종의 보고서 기능, 로그 통합 기능, 모니터링 기능 등이 필요한데 DBMS에서 제공하는 기능은 다양한 고객의 요구를 만족시 켜줄 만큼 폭 넓은 기능을 제공하지 못한다.

마지막으로 다양한 종류의 DBMS에 대한 통합관리가 필요하기 때문이다. 대부분의 민간 기업 및 공공기관의 경우 2종 이상의 DBMS를 사용하고 있다. 규모가 큰 경우에는 4~5가 지 종류의 DBMS를 운영하고 있는데 개별 DBMS의 보안 기능을 이용할 경우 통합된 관리 가 어렵다. DBMS를 운영하고 있는 조직마다 보안정책에 차이가 있고 보안의 수준도 다르 다. 이러한 이유에서 DB 접근제어 솔루션을 도입하는 경우에 여러 가지 방식으로 특성에 맞게 구성할 수 있어야 하며, 이를 통합적으로 관리할 수 있어야 한다.

DB 접근제어에서 고려해야 할 것은 보안은 심층방어(Defense-in-Depth)라는 개념으로 구성해야 한다는 것이다. 단일 보안 솔루션만으로는 보안이 완성되지는 못한다. 조직에서 관리하는 모든 정보 기기를 하나의 (Instruction Detection System)/IPS(Instruction Prevention System), PKI, VPN(Virtual Private Network) 등 다양한 솔루션을 통해 여러 겹의 방어막을 구축하여 방어를 한다. 이것은 거시적으로 정보시스템에 대한 방어를 바라보는 관점이지만 DB자체 에 대한 보안에도 동일한 개념이 적용되어야 한다.

DB 보안을 위해 DB 접근제어, DB 암호화, DB 작업결재, DB 취약점 분석 등의 다양한 솔 루션을 구축할 수 있는데, 이런 솔루션의 구축과 더불어 DB 자체에 제공하고 있는 기능을 이용한 보안의 강화도 필수적이다. 일반적으로 DBMS 자체의 보안 강화를 위해서 다음 조 치를 취해야 한다.

？DBMS를 설치한 계정을 엄격하게 관리하고, DB 파일 및 Binary 파일에 대한 접근은 엄격히 제한해야 한다.
？불필요한 기능은 설치하지 않거나, 설치되었다면 Disable 처리해야 한다.
？최소권한만을 부여해야 한다. DBMS내에서 작업을 수행하는 내부 사용자나, 자동으로 수행하는 태스크 및 서버의 프로세스들에 대하여 DB에 접근하여 작업할 수 있는 꼭 필 요한 권한만을 부여해야 한다.

DBMS에서 제공하는 기본적인 기능을 이용하여 권한을 설정하는 것이 필요하다. 물론 DB 접근제어 솔루션을 통해 접근 권한을 관리하지만, 해당 솔루션을 우회하여 접근하는 경우가 있으므로 DBMS에서 제공하는 기능을 이용하여 권한 설정을 하는 것이 심층방어 의 원칙을 유지하는 길이다.

■ DBMS 자체보안 강화 사례(오라클)

오라클의 권한은 시스템 계열 권한과 객체 계열 권한으로 구분된다. 먼저 시스템 계열의 권 한을 조회하는 방법은 다음과 같다.

SQL> select name from sys.system_privilege_map order by name ;
ADMINISTER ANY SQL TUNING SET
ADMINISTER DATABASE TRIGGER
ADMINISTER RESOURCE MANAGER
ADMINISTER SQL TUNING SET
ADVISOR
ALTER ANY CLUSTER
ALTER ANY DIMENSION
ALTER ANY EVALUATION CONTEXT
ALTER ANY INDEX
ALTER ANY INDEXTYPE
ALTER ANY LIBRARY
… 166 rows selected.

시스템 계열의 권한은 DB 내에서 데이터를 대상으로 하는 작업을 제외한 나머지 영역에서 사용자가 수행할 수 있는 모든 액션을 대상으로 하는데, 객체 종류 전체에 대하여 실행할 수 있는 'ANY' 권한과 ALTER DATABASE, ALTER SYSTEM, ALTER USER 등과 같 이 시스템 단위로 적용하는 권한으로 분류할 수 있다.
DBMS의 최고 계정인 SYS 소유의 객체에 대한 권한을 안전하게 관리하기 위해 07_DIC- TIONARY_ACCESSIBILITY 파라미터는 FALSE 값으로 설정하여, SYS 관련 객체의 권한이 자동으로 할당되지 않도록 해야 한다.
객체 관련 권한을 조회하는 방법은 다음과 같다.

SQL> select name from sys.table_privilege_map order by name ;
ALTER
AUDIT
COMMENT
CREATE
DEBUG
DELETE
DEQUEUE
ENQUEUE
EXECUTE
…
24 rows selected.

이런 권한은 오라클 계정 단위로 부여가 가능한데, 특정 계정에 부여된 권한을 조회하는 방법은 다음과 같다.

SQL> select * from dba_sys_privs where grantee = 'SCOTT'; GRANTEE PRIVILEGE ADM --------------------------------------------- SCOTT CREATE ANY TABLE NO SCOTT SELECT ANY DICTIONARY NO SCOTT CREATE VIEW NO SCOTT QUERY REWRITE NO SCOTT UNLIMITED TABLESPACE NO SCOTT ALTER SESSION NO 6 rows selected. SQL> select * from dba_tab_privs where grantee = 'SCOTT'; GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRA HIE -------- ---------- ------------- -------- -------- --- --- SCOTT SYS DBMS_UTILITY SYS EXECUTE NO NO SCOTT SYS DBMS_SQL SYS EXECUTE NO NO

권한을 개별적으로 관리할 경우 관리해야 할 권한이 많아지면 매우 복잡해진다. 이런 문제 를 해결하기 위해 오라클은 롤(Role)이라는 개념을 제공하는데, 롤은 권한의 묶음을 의미 한다.
예를 들어, 오라클에서 기본적으로 제공하는 롤은 CONNECT, RESOURCE 롤 등이 있 다. 오라클 계정을 만든 후에, 기본적으로 CONNECT, RESOURCE 롤을 부여하는데 해 당 롤에 포함된 권한을 조회하는 방법은 다음과 같다.

SQL> select privilege from dba_sys_privs where grantee='CONNECT'; PRIVILEGE ------------------------------ CREATE SESSION SQL> select privilege from dba_sys_privs where grantee='RESOURCE'; PRIVILEGE ------------------------------ CREATE TRIGGER CREATE SEQUENCE CREATE TYPE CREATE PROCEDURE CREATE CLUSTER CREATE OPERATOR CREATE INDEXTYPE CREATE TABLE

대부분의 계정에 적용되는 기본 롤이므로 최소의 권한만 갖도록 유지하여야 한다. 오라클은 PUBLIC 이라는 개념을 제공하는데 다음과 같은 특성을 가진다.

？모든 사용자가 디폴트로 소속되는 그룹이다.
？어떠한 권한이나 롤을 할당할 수 있다.
？PUBLIC에게 할당되는 모든 권한은 DBMS에 있는 모든 사용자에게 자동으로 할당된다.

이런 특성을 갖고 있으므로 PUBLIC에 할당되는 권한은 매우 세심하게 관리되어야 하며 반드시 필요한 권한만 가지도록 해야 한다. PUBLIC에 할당된 권한을 조회하는 방법은 다음과 같다.

SQL> select privilege, table_name, grantable from dba_tab_privs 2 where owner = 'SYS' and grantee = 'PUBLIC' order by privilege … PRIVILEGE TABLE_NAME GRANTABLE ------------------------------ ------------------------------ UPDATE OLAPI_MEMORY_OP_HISTORY NO UPDATE OLAPI_MEMORY_HEAP_HISTORY NO UPDATE OLAP_OLEDB_MEASDIMS_PVT NO UPDATE OLAP_OLEDB_CUBES NO UPDATE OLAP_OLEDB_DIMENSIONS NO UPDATE OLAP_OLEDB_HIERARCHIES NO UPDATE OLAP_OLEDB_LEVELS NO UPDATE OLAP_OLEDB_PROPERTIES NO UPDATE OLAP_OLEDB_MEASURES NO UPDATE OLAP_OLEDB_ACTIONS NO UPDATE OLAP_OLEDB_FUNCTIONS NO UPDATE OLAPTABLEVELTUPLES NO UPDATE OLAPTABLEVELS NO UPDATE OLAP_OLEDB_SETS NO UPDATE PLAN_TABLE$ NO 18055 rows selected. 다음과 같은 PL/SQL 패키지는 악용될 수 있으므로 PUBLIC에게 권한을 허가하지 않는다.

패스워드의 경우에 가능하면 최소 8자리 이상으로 특수문자와 숫자 등을 포함한다 SQL> alter user scott identified by test1; User altered. SQL> select password from dba_users where username = 'SCOTT'; 776C113FE830DA3A 오라클 102R2에서 생성한 간단한 패스워드의 경우에는 다음과 같이 Brute Force 공격에 의하여 일반적인 노트북을 이용하여 38초만에 간단히 알아낼 수 있다.

나. 구성방법

DB 접근제어를 구축하는 방법은 크게 3가지로 나눌 수 있다. 각 방법의 특성은 다음 표와 같이 정리할 수 있다.

DB 접근제어는 하나의 단일 방식으로 구성하기도 하지만, 각 방식마다 장점을 취하고 단 점을 보완하기 위하여 여러 가지 방식을 혼합한 하이브리드 방식을 많이 사용한다. 일반적 인 하이브리드 구성방식은 '에이전트 + 스니핑', '게이트웨이 + 스니핑', '게이트웨이 + 에 이전트 + 스니핑' 등이 있다.
각 방식에 대하여 구체적으로 살펴보면 다음과 같다.

1) 게이트웨이 방식

게이트웨이(Gateway) 방식은 DBMS에 접속하기 위한 통로를 별도로 설치한 후 DB 사용 자가 해당 통로를 통해서만 접근하도록 하는 방식이다. 예를 들어, 자동차를 타고 고속도 로에 진입을 하기 위해서 반드시 톨게이트를 거쳐 통행료 징수를 위한 체크를 하듯이 DBMS에 로그인하거나 로그인 한 후에 SQL을 수행하기 위해서는 반드시 게이트웨이를 거치도록 구성하여 모든 로그인과 SQL에 대하여 철저하게 통제하는 방식이다.
게이트웨이를 거치도록 하는 기술에 따라 프록시(Proxy) 게이트웨이 방식과 인라인(In- Line) 게이트웨이 방식으로 구분된다. 먼저 프록시 게이트웨이는 별도의 서버(안정성을 위해 이중화 구성 필요)를 설치한 후에 독립적인 IP 및 포트를 부여하고, DB로그인 시 해 당 IP 및 포트로 로그인 하도록 한다.

프록시 게이트웨이를 경유하도록 하기 위해 내부사용자 단말기에 별도의 프로그램을 설치 하는데 해당 프로그램은 DBMS 서버의 IP와 포트로 로그인 할 때 자동으로 프록시를 경유 하도록 패킷(Packet)의 정보를 수정하여 전송한다.
프록시 게이트웨이는 전송 받은 SQL을 조사한 후에 해당 SQL을 수행할 수 있는 권한을 가진 사용자가 수행한 경우에는 해당 SQL을 DBMS 서버로 전달하고, 권한이 없는 사용 자가 수행할 경우에는 SQL을 DBMS 서버에 전달하지 않고 해당 SQL을 수행한 내부 사 용자에게 수행 권한이 없음을 알리는 메시지를 보낸다. 필요에 따라 보안관리자가 권한 없 는 SQL을 수행하려는 사건이 발생했음을 인지하도록 하기 위해 SMS, 메일 등을 이용하 여 경보를 보내도록 설정하기도 한다.

별도의 장치에 의해 모든 패킷이 자동으로 게이트웨이를 거치게 되므로 내부 사용자 단말 기에는 아무런 프로그램을 설치할 필요가 없다.
프록시 게이트웨이와 인라인 게이트웨이의 가장 큰 차이점은 게이트웨이를 거치는 패킷의 조정 여부이다. 즉, 프록시 게이트웨이는 게이트웨이를 거치도록 구성된 사용자들만 게이 트웨이를 거치므로 애플리케이션 서버는 프록시 게이트웨이를 거치지 않는다. 반면, 인라 인 방식은 모든 패킷이 게이트웨이를 거치도록 설정되므로 애플리케이션 서버에서 오는 패킷도 게이트웨이를 거치게 되어 속도 저하가 발생하고, 장애 발생 시 업무 시스템에 대 한 영향이 있을 수 있다.

인라인 게이트웨이는 설치 및 관리가 용이하지만 업무 시스템의 장애 가능성이 있기 때문 에 규모가 작은 기업이나 공공기관에서 주로 사용한다.

2) 스니핑 방식

스니핑 방식은 스니핑 DB 사용자와 DBMS 서버간에 주고 받는 패킷을 복사하여 DB접근 제어 서버에 전달하는 방식이다. 이것은 마치 고속도로 상의 감시 카메라가 지나가는 자동 차의 속도를 측정하여 과속 차량이 발생하는 경우에만 사진을 찍어 과태료를 부과하므로 전혀 교통 흐름에 영향을 주지 않는 것과 같은 방식이다. 스피닝 방식은 DBMS 서버의 패 킷 흐름에 전혀 영향을 주지 않아 성능 저하 등의 문제가 발생하지 않는다.

다만, 게이트웨이 방식은 권한 없는 SQL에 대하여 개개의 SQL 단위로 즉각적인 통제가 가능하지만, 스니핑 방식은 개개의 SQL 단위로 통제할 수 없고 로깅만 가능하다. 다만, 권한이 없는 SQL을 수행하는 세션의 경우 DB 서버로 해당 세션을 종료시키는 명령어를 보내는 방법 등으로 통제하는 기능을 일부 제공하기도 한다.

패킷을 복사하는 방법은 TAP이라는 패킷 복사 장치를 이용하는 방법이 있고, N/W 스위 치의 복사 기능을 이용하는 방법이 있다. TAP 을 사용하는 경우 모든 DB 서버 앞 단에 TAP을 설치하여야 하므로 비용이 증가하고 관리 부담이 있다. 반면, N/W 스위치에서 복 사하는 방식은 해당 스위치에 연결된 모든 DB서버의 패킷을 모아서 전송 받으므로 별도의 장치가 필요하지 않다. 그러나 N/W 스위치는 많은 트래픽이 발생한 경우에 일부 패킷을 복사하여 전송하지 않을 수 있어서 패킷 누수가 발생할 수 있다.

TAP 방식으로 설치하기 위해서 TAP과 보안서버간의 정상적인 연결이 필요한데, TAP이 정상적으로 설치되었다는 것은 네트워크 사용에 전혀 문제가 발생하지 않고 TAP의 모니터 포트에서 복제된 신호가 나오는 상태이다. Aggregation TAP이 아닌 일반 TAP인 경우 네트워크의 송수신 패킷이 별도의 포트로 복제되므로 보안 서버에는 송·수신용 두 개의 포트가 필요하다.

그러므로 일반 TAP인 경우에는 하나의 TAP에 대응하여 하나의 Dual Port 네트워크 카드 (하나의 카드로 두 개의 네트워크 포트를 제공) 혹은 두 개의 Single Port 네트워크 카드가 필요하다. Aggregation TAP인 경우에는 TAP에서 송·수신을 하나로 통합하여 하나의 모니터 포트로 내 보내므로 하나의 Single Port 네트워크 카드만 필요하다.

TAP을 연결한 후, 정상적으로 정보가 복사되어 오는지 다음과 같이 테스트 할 수 있다. $tcpdump -i eth0 -x => sniffing device 가 eth0

케이블 연결 혹은 Device 설정에 문제가 발생한 경우 위와 같은 Output이 화면에 출력되 지 않는다.

3) 에이전트 방식

에이전트 방식은 DB 서버에 접근제어를 설치하는 방식이다. 솔루션에 따라서 에이전트만 으로 접근이 제어되기도 한다. 어떤 솔루션은 별도로 외부에 서버를 설치한 후에 DB 서버 내부 패킷을 외부 서버로 전송하여 DB의 접근을 제어하기도 한다.

DB 서버에 설치되어 부하를 발생할 수 있으므로 어플리케이션 서버에서 오는 SQL은 바 이패스 설정을 통해 직접 DBMS에 전송하도록 구성한다.
DB 서버에 콘솔 등을 설치하여 전산실 내부에서 직접 접속하는 경우에는 게이트웨이 방식 과 스니핑 방식은 아무런 통제 및 로깅을 하지 못하게 된다. 콘솔 등으로 접속할 수 없도록 보안정책이 수립되어 있고 접근을 차단할 수 있는 보안 솔루션(예 : 서버보안 솔루션)이 설 치된 경우에는 문제가 없지만, 콘솔 접속이 허용된 경우에는 에이전트를 설치하여 전산실 내부에서 접속하는 관리자들이 수행한 SQL을 통제하도록 하여야 한다.
에이전트 방식은 로그가 각 에이전트에 생성되어 저장되므로 수십 개의 에이전트를 설치 한 경우에 로그를 통합하고 규칙을 중앙에서 분배하는 기능이 필요하다.

4) 하이브리드 방식

하이브리드 방식은 별도의 구성방식이 아니라, 스니핑, 게이트웨이, 에이전트를 모두 혹 은 일부를 사용하여 혼합한 방식이다.
게이트웨이 방식은 다수의 사용자에 대한 철저한 통제 및 통합관리가 용이하고, 스니핑 방 식은 DB서버에 부하없는 로깅이 가능하다. 또한 에이전트 방식은 우회하여 접근이 가능한 시스템 관리자들까지 통제가 가능하므로 이런 장점들을 취하기 위하여 여러 가지 방식을 혼용하여 구성한다.

하이브리드 방식은 구성이 복잡하여 관리의 부담이 있지만 가장 높은 수준의 보안통제 및 로깅이 가능한 방식이다.