3. DB 보안 범위

가. DB 보안 범위 정의 목적

내·외부로부터의 다양한 위협에 효과적으로 대응하기 위해서는 견고하고 치밀한 보안 구 축이 필요하다. 일반적으로 정보와 정보시스템을 보호하기 위한 보안 구축에는 광범위한 범위에 걸쳐 많은 구성요소들이 복잡하게 보안 계층을 형성하게 되는데, DB 보안 영역에 있어서도 다양하고 많은 보안 구성요소들이 역할을 하게 된다.
그러나 DB 보안에 대한 영역은 그 타겟이 비록 DB와 그 속에 저장된 데이터라는 명확한 목표물이 존재하더라도 정보와 정보시스템에 대한 전체 보안 영역에서 많은 부분이 서로 중복되기 때문에 DB 보안이 어느 부분을 담당하는지 명확하게 선을 긋는 것이 다소 모호 할 수 있다.
그럼에도 불구하고 보다 체계적이고 견고한 보안 구축을 위해서는 구현하고자 하는 DB 보 안의 범위를 정의할 필요가 있다. 명확한 범위를 설정하고 세분화함으로써 보다 치밀한 보안 구축이 가능하고 문제가 발생했을 때 책임 소재를 분명하게 할 수 있다.
DB 보안의 범위를 정의하는 것은 DB의 구성과 그 사용성, 영향 범위 등에 따라 보다 세밀 하게 구분하고 보안 대상 영역을 정의해 볼 수 있다. 이와 같은 세분화는 고려 대상이 되는 영역을 손쉽게 인식 가능하도록 한정할 수 있기 때문에 각 범위별로 가장 효과적인 보안 기법을 디자인하고 구현할 수 있다. 이것은 구현 후 효과적인 관리에까지 영향을 주게 되 고, 문제가 발생했을 때 각 범위별로 분석하여 증상과 원인, 영향의 범위를 손쉽게 추적할 수 있는 장점을 제공한다.

나. DB 보안 범위 정의

1) 일반적인 보안 통제 범위의 구분

보안 통제(Security Control)는 보안 위험을 회피, 대응하거나 최소화하도록 하는 보호장 치 또는 대응조치라고 할 수 있다. 앞서 설명한 여러 위험으로부터 정보 자산을 안전하게 보호하고 위험을 완화시키기 위해 보안 통제를 적용하는 범위는 보안 통제 성격에 따라 3 가지로 나누어 볼 수 있다. 이 3개의 보안 통제 범위는 하나 또는 그 이상을 복합적으로 적 용할 수 있다.

① 관리적 보안 통제

절차적 보안 또는 절차적 통제로도 불리는 관리적 보안 통제는 명문화되어 승인된 정책, 절차, 표준, 그리고 가이드라인 등으로 구성된다. 또한 업무를 운영하고 인력을 관리하기 위한 프레임워크를 구성함으로써 이를 통해 구성원들이 업무 수행 방법과 일상적 운영 방 법 등을 알 수 있도록 한다.
정부기관에서 만든 법규나 지침 등은 업무에 대한 정보를 알려주기 때문에 관리적 보안 통 제의 한 유형이라고 할 수 있다. 금융권의 경우는 이와 같은 형태의 보안 통제가 비교적 잘 이루어고 있는 편이며, 정책, 절차, 표준, 가이드라인 등을 갖추고 준수하도록 하고 있다. 전사보안정책, 비밀번호정책, 고용정책 등도 관리적 보안 통제의 한 예라 할 수 있다. 관리적 보안 통제는 논리적(또는 기술적) 및 물리적 보안 통제의 선택과 적용에 대한 기초 가 되며, 논리적(또는 기술적) 및 물리적 보안 통제는 관리적 보안 통제를 구체적으로 형상 화한 것이라 할 수 있다. 이 때문에 관리적 보안 통제는 가장 기본적이면서 중요한 영역으 로 취급된다.

② 논리적 보안 통제(또는 기술적 보안 통제)

논리적 보안 통제는 정보와 정보시스템에 대한 접근을 감시하고 제어하기 위해 소프트웨 어와 데이터를 사용한다. 예를 들면, 비밀번호, 네트워크 및 호스트 기반 방화벽, 네트워 크 침입 탐지 시스템, 접근제어목록, 데이터 암호화 등이 논리적 보안 통제에 해당한다. 자주 간과되는 중요한 논리적 보안 통제는 '최소권한의 원칙(The Principle of Least Privilege)'이다. 이것은 개별 프로그램이나 시스템 프로세스가 태스크(Tast)를 수행하는 데 필요한 그 이상의 접근 권한을 개별 프로그램이나 시스템 프로세스에게 허용하지 않는 것이다.

최소권한의 원칙에 어긋나는 대표적인 사례는 애플리케이션 개발자가 DB에 로그인할 때 사용하는 사용자 계정에 DBA 권한을 부여하는 경우이다. 이 원칙에 대한 위배는 개인이 허용 범위를 넘어서 추가적인 접근 권한을 끌어 모을 때도 발생할 수 있다. 이것은 직원의 직무가 변경될 때, 또는 새로운 지위로 승진했을 때, 혹은 다른 부서로 전배되었을 때 종종 발생하는데, 더 이상 필요하지 않거나 적합하지 않게 된 기존의 접근권한에 그들의 새로운 직무에 따른 접근권한이 추가되면서 발생한다.

③ 물리적 보안 통제

물리적 보안 통제는 작업 장소의 환경과 컴퓨팅 장비들을 감시하고 통제하는 것을 말한다. 도어락과 같은 출입통제장치나 경보장치, 감시카메라 등이 그 사례가 될 수 있다. 자주 간과되는 중요한 물리적 보안 통제는 의무의 분리(The Separation of Duties)이다. 의무의 분리는 개인이 혼자서 핵심적인 업무를 완료할 수 없도록 하는 것이다. 예를 들면, 배상요구를 제출한 직원이 지불을 인증하거나 검사표를 인쇄할 수 없어야 한다. 애플리케 이션 개발자는 서버 관리자나 DB 관리자가 될 수 없어야 하며, 이러한 역할과 책임은 다른 직원에게 분산되어야 한다.

2) 심층방어(Defense in Depth)1)

DB 보안은 데이터가 생성되어서 소멸에 이르기까지 데이터의 전체 생애주기에 걸쳐서 데 이터가 보호되어야 한다. 생성된 데이터는 활발하게 사용되고 있을 때에나 사용되지 않고 단순히 과거 이력으로서 저장되어 있을 때에나 항상 보호되어야 한다.
데이터는 그 가치 여부와 상관없이 생애주기 동안 많은 관련 시스템들을 거치게 되면서 그 과정에서 데이터와 정보시스템이 다양한 위험에 노출되고 다양한 방법으로 위협을 받을 수 있다. 따라서, 생애주기 동안 데이터를 완전하게 보호하기 위해 정보처리시스템의 각 컴포넌트들은 그들만의 보호 매커니즘을 갖고 있어야 한다. 이러한 목적을 위해 보안 수단 을 겹겹이 중첩되게 구성할 수 있는다. 이와 같은 보안 수단의 중첩 구성을 심층방어 (Defense in Depth) 라고 부른다. 중첩 구성에 사용되는 어느 하나의 방어 수단만으로는 역부족일 수 있지만 심층방어 전략을 사용하면 하나의 방어 수단이 실패했을 때 다른 방어 수단이 계속해서 보호를 제공할 수 있게 된다.

앞에서 설명한 관리적·논리적·물리적 보안 통제로 구분한 3가지 유형의 통제는 심층방 어 전략을 그 바탕에 깔고 구성한다. 이러한 접근을 통해 심층방어는 3개의 구분된 레이어 나 혹은 한 계층 위에 다른 하나가 올려지는 판구조의 개념으로 형상화할 수 있다. 심층방 어의 개념을 도식화하면 가운데에 데이터가 있고 바깥으로 네트워크, 서버, 애플리케이션 등에 대한 보안 통제 계층이 겹겹이 둘러 쌓인 껍질층을 형성하며, 그 외부에 사람이 존재 하는 양파 껍질 층과 같은 형상으로 생각할 수 있다.

3) 액세스 흐름에 따른 DB 보안의 범위 구분

DB 보안을 위한 보안 통제를 구축하는데 있어서 앞에서 설명한 심층방어 전략은 데이터와 DB를 보호하기 위한 기본적인 통제 계층 구성 전략이라 할 수 있다. 심층방어에 대한 개념을 표현한 앞의 그림에서는 시스템 레이어를 따라서 보안 통제가 중층의 보안 계층을 형성한다 는 개념이 표현된 것이다. 한 가지 더 염두에 둘 것은 앞의 그림에서의 한 계층이 하나의 보 안 통제 계층만을 의미하는 것은 아니라는 것이다. 이를 테면 Database 영역에 대한 보안 통제를 구성하는데 있어서도 심층방어 전략을 적용할 필요가 있다. 이에 따라 Database 영 역에 대한 보안 통제를 구축하는 데에도 몇 겹의 보안 통제가 이루어질 수 있다는 것이다.

DB 영역의 범위는 사용자가 화면 상에서 취급하는 데이터부터 네트워크를 따라 WAS 서 버를 경유하여 DB 서버와 DBMS를 지나 저장된 데이터에 이르기까지 모든 부분에서 데이 터가 다루어지기 때문에 다소 모호한 면이 있을 수 있다. 일반적으로 데이터를 액세스하는 흐름 상에서 사용자가 직접 대면하게 되는 외부 애플리케이션과 네트워크, 서버 계층에 대 한 부분을 제외한 DBMS와 그 속에 저장된 데이터를 기본으로 하여, 데이터를 직접적으로 액세스하는 DB 프로그램(예:저장 프로시져)과 SQL 까지도 고려해야 할 수 있다. 다음 그 림은 데이터 액세스 흐름 관점에서 DB에 대한 영역을 형상화한 것이다. 이와 같이 DB 영 역을 구분하는 것은 책임 소재를 명확히 하고, 세분화된 범위 식별을 통해 보다 정교하고 효과적인 보안 통제를 설계할 수 있도록 하기 위함이다.

앞의 그림에서 DBMS로 표현된 부분은 DBMS를 구성하는 다양한 소프트웨어 모듈과 이 들에 의해 구현된 보안 통제 장치를 의미한다. 이 부분에서는 주로 DB 사용자 계정과 패스 워드, 롤, 권한 등이 고려된다. DB 프로그램으로 표현한 부분은 패키지, 프로시저, 함수, 트리거 등을 비롯하여 SQL까지 포함한다.
DB Objects 및 Data로 표현한 부분은 실제로 데이터를 저장하고 있는 저장체인 테이블 과 이들에 대한 시노님(Synonym), 뷰(View)를 비롯하여 그 속에 저장된 데이터값까지를 의미한다. 이들을 DB 영역으로 정의하여 앞으로의 DB 보안 통제에 대한 논의를 이 영역 에 집중하도록 할 것이며, 세분화된 각 DB 영역에서의 구체적인 보안 통제 방법에 대해서 는 DB 보안 기법을 중심으로 다음 장에서 보다 상세하게 설명할 것이다.

다. DB 보안 요구사항

발생 가능한 위협으로부터 DB를 보호한다는 것은 우연이든 고의적이든 비권한자의 부정 당한 읽기접근이나 변경으로부터 저장 데이터를 보호하는 것을 뜻한다. 이와 같은 DB 보 안에 대한 요구사항은 일반적으로 다음과 같이 요약할 수 있다.

■ 정당한 사용자의 데이터 접근 보장

정당하게 권한을 부여받은 사용자에게만 DB 접근을 허용한다. 이와 같은 사용자나 응 용 프로그램의 접근 요청이 발생하면 권한을 검사하여 허용된 범위 내에서 데이터에 자 유롭게 접근할 수 있도록 한다.
DB에서의 접근 제어는 운영체제가 관리하는 파일에서보다 훨씬 복잡하여 레코드, 속 성, 값들과 같은 더 작은 정보 단위의 객체에까지 적용될 수 있다. 이와 같은 복잡하고 세밀한 수준에 접근 제어를 적용하는데 있어서 주의할 점은 DB 내의 데이터가 의미적 으로 연관되어 있기 때문에 데이터 항목의 값을 직접 접근하지 않아도 알려진 값들로부 터 추론을 통해 원하는 정보를 얻을 수 있는 가능성이 있다는 것이다.

■ 추론 방지

추론이란 기밀성이 없는 데이터로부터 기밀 정보를 얻어내는 가능성을 의미한다. 특히 추론 문제는 통계 DB에서 중요시되며 통계적 집계 정보에서 시작하여 개개의 개체에 대한 정보를 추적하지 못하도록 해야 한다.
예를 들어, 어떤 사용자가 여성 직원의 평균 급여를 DB에 질의한 후, 여성 직원의 인원 수를 질의한다고 가정했을 때, 여성 직원의 수가 '1'이라면 결국 평균과 Count라는 통 계 질의만으로도 여성 직원의 급여를 추론할 수 있게 된다.

■ 데이터의 무결성(Integrity) 유지

이것은 데이터 내용을 수정할 수 있는 비권한 접근, 오류나 바이러스 등에 의해 데이터 를 손상시킬 수 있는 시스템 고장(Failure) 등으로부터 DB를 보호하는 것을 의미한다. 이러한 종류의 보호는 적절한 시스템 제어나 다양한 백업 및 복구 프로세스 등을 통해 서 가능하다. 즉, 정상적으로 종료된 트랜잭션의 변경 결과는 영구적이며 비정상적으 로 종료된 트랜잭션은 트랜잭션에 의해 처리된 변경을 모두 취소시켜 원래의 변경 전 상태로 되돌려 놓게 된다.

시스템 이상(Abnormality) 발생 시 로그 파일에 기록된 트랜잭션 동안의 연산(Read, Write, Insert, Delete) 내역과 트랜잭션 제어 연산(Begin/End transaction, Commit, Rollback, Abort 등) 내역, 그리고 관련 레코드의 변경 전후 값들을 이용하여 복구 프로 세스(Recovery Process)가 취소(Undo)할 트랜잭션들과 재수행(Redo)할 트랜잭션들 을 로그파일로부터 읽어 처리함으로써 데이터의 무결성을 유지할 수 있게 한다.

■ 데이터의 의미 무결성(Semantic Integrity) 유지

허용된 범위의 제어 데이터 값을 유지하여 수정될 데이터의 논리적 일치성을 보장하는 무결성 제약조건(Integrity Constraints)이 대표적인 예가 될 수 있다. 여기에는 Primary Key, Foreign Key, Unique, Check, Not Null Constraint 등이 해당된다.

■ 시스템 감사 지원

데이터에 대한 모든 접근을 기록한다는 의미로, 모든 데이터에 대해 감사 기록을 유지 하는 것은 시간과 비용 측면에서 비효율적이다. 따라서, 데이터에 대한 분류를 통해 중 요 정보에 대해 감사 기록을 유지하여 중요 데이터에 대한 비인가 또는 비정상적 접근 을 효과적으로 기록하고 감지할 수 있어야 한다.

■ 사용자 인증

DB 사용자를 유일하게 식별할 수 있어야 한다. 사용자 식별은 모든 권한부여 체계 수 립에 대한 기초가 된다. 시스템이 권한 있는 사용자로 식별할 때 사용자는 허용된 데이 터에 접근할 수 있다.

■ 기밀 데이터 관리와 보호

DB에는 공개되서는 안될 기밀 데이터가 포함될 수 있다. 어떤 DB는 기밀 데이터만 포 함할 수도 있고, 또 어떤 DB는 전부 공개 가능한 데이터만을 포함하고 있을 수도 있다. 기밀 데이터와 일반 데이터가 혼재된 DB는 매우 복잡한 보호 문제를 안고 있다. 데이 터 항목은 그 자체로, 또는 다른 데이터와 결합되어, 혹은 기밀 데이터에 포함되거나 DBA가 기밀로 선언하는 경우와 같이 다양한 상황에서 기밀성을 갖게 된다.
기밀 데이터를 갖고 있는 DB에서의 접근 제어는 정당하게 권한을 부여받은 사용자만이 기밀 데이터에 접근할 수 있도록 허용하면서도 이 권한을 전파할 수 없어야 한다. 또한 권한을 부여받은 사용자라도 기밀 데이터에 대한 동시 접근은 허용하지 않을 수도 있다.

■ 다단계 보호(Multilevel Protection)

다단계 보호는 보호 요구사항의 집합을 의미한다. 정보를 다양한 보호 등급(Level)으 로 분류하고, 다양한 정보 항목에 분류등급을 할당하거나 분류등급에 따라서 다양한 접 근 수준을 할당할 수 있다.

라. DB 보안의 전략적 접근 필요성

DB 보안은 다양하고 복잡한 기술과 관리적·제도적 장치가 복합?? 분야이다. DB 보안을 구축한다는 것은 간단한 작업이 아니다. 각 기업들의 DB는 복잡한 아키텍처로 구성되어 있고 다수의 인가된 사용자, 아웃소싱 개발 자, 유지보수 작업자들과 WEB·WAS 등과 같은 업무 관계의 연동 서버들이 정형적·비 정형적인 방법으로 불특정하게 데이터에 접근하기 때문에 체계적인 보안정책을 구현하기 가 매우 어렵다.

포레스터 리서치의 2009년 IT보안시장 분석 보고서(Forrester Market Overview: IT Security in 2009, Forrester Research)에 따르면, DBA는 DB 보안을 위해 5% 미만의 시간을 투자하는 형편이다. 게다가 그들 대부분은 어느 DB, 테이블, 혹은 칼럼에 중요 데 이터를 저장하고 있는지 조차도 모르고 있다. 또한, 90% 이상의 조직에서 두 가지 이상의 DBMS를 사용하고 있으며, 이와 연동되는 애플리케이션의 수도 수십에서 수천 개나 되기 때문에, 단순히 한두 대의 보안 시스템을 설치하거나 보안 규정을 강화하는 것만으로는 DB 보안 문제를 해결할 수 없다. 따라서, 성공적인 DB 보안을 위해서는 다음의 모든 사항 을 종합적으로 고려한 전략적인 접근이 이루어져야 한다.

■암호화
■접근제어
■감사 및 모니터링
■취약점 분석
■작업결재
■사용자 인증
■운영, 개발, 테스트 환경의 분리