㈜이글로벌시스템
DB암호화의 목적
- 가장 강력하고 근본적인 보안 방법, 하지만 신중한 선정이 요구되는 보안 솔루션
보안을 농구 경기에 비교해 보자.
공격수는 수비수를 따돌리기 위해 다양한 루트를 이용해 바스켓에 공을 넣으려 한다.
보안에서는 공을 넣는 대신 자료를 빼가려 하는 것 만 다를 뿐 나머지는 똑 같다고 볼 수 있다.
즉 공격자는 수비를 따돌리는 새로운 방법을 계속 연구해내고, 방어를 하는 수비자는 이에 대응하는
방어방법을 만들어야 한다. (항상 공격자는 먼저 새로운 테크닉을 생각하고, 수비자는 항상 나중에
대처방법을 생각한다.)
이것을 보안에 적용해 보면, 해커는 항상 보안툴이 가진 새로운 보안 취약성을 알고 있기 때문에 이런 방어체계를 뚫고 DB에 접근할 수 있다.
더구나 아군이 자살 골을 넣으려 한다면 이런 방어체계 자체가 아무런 소용이 없다.
즉, 외부 침입자는 물론 내부자가 DB전체를 들고 나간다 하더라도 권한이 없으면 암호화된 데이터는
영원히 볼 수 없다.
DB암호화를 하는 이유가 바로 이것 때문이다. 가장 확실하고 강력한 보안 수단이기 때문이다.
(그림 1)
사례를 통해 본 데이터 유출 사고의 심각성
- 국민적 지탄은 불론, 기업의 존립 자체가 위협
많이들 알고 있는 이야기 이지만 내부자에 의한 데이터 유출은 발생 빈도는 높지 않지만
일단 발생 하게 되면 그 피해액은 이루 말할 수 없을 정도로 크다.
(한국산업기술진흥원의 조사 자료에 의하면 자료유출의 약 70%가 내부자에 의한 소행
이라 함.)
더구나 최근에는 우리나라 여권이 아주 많은 나라와 비자면제 협정이 되어 있는 점 때문에
중국의 해커들로부터 여권위조 등의 목적으로 개인정보 유출 시도가 끊이지 않고 있는
실정이다.
게다가 첨예한 경쟁상황에 처해 있는 제조업의 경우 도면 등의 기술자료 유출사고도 내부
자에 의해 빈번히 저질러지고 있는 실정이다.
주지하다시피 옥션의 고객정보 DB유출 사고로 인한 법정 소송이 본격화 되었으며 이로
인한 기업의 피해액은 리니지 사고 때의 예로 비추어 보건 데 1인당 50만원씩 배상하게
되면 수 조원에 육박하게 될 것으로 전망된다.
만일 DB의 개인정보를 암호화해 놓았다면 당사자들 모두 지금처럼 심각한 상황에 처하지
는 않았을 것이다.
비밀번호만 암호화해 놓는 것은 이 같은 사고에서는 도움이 안 된다. 비밀번호야 바꾸면
되지만 그 사람들의 목적은 유출된 주민번호 등의 개인정보로 2차 범죄에 이용할 것으로
예상되기 때문 이다.
또, 얼마 전에 일어난 보 조선회사의 도면 유출로 인한 피해액이 5천억 원으로 예상 된다고
한다. 게다가 최근 한 LCD제조사의 생산공장 배치도 유출도 내부자에 의해 저질러진 전형
적인 피해 사례이며, 이런 유출 사고로 인한 피해는 그 액수도 클뿐더러 민감한 자료의
유출로 인해 기업 경쟁력이 사라질 수 있다는데 더 큰 문제가 있다.
즉 엄청난 국민적 지탄에 직면하게 되고 기업의 존립 자체가 위협받게 된다는 이야기 이다.
DB(데이터) 암호화의 법적근거
(표 1) 2007년 11월 현재 시행중인 법률
성공적인 DB암호화를 위한 솔루션의 필수기능
- DB암호화 솔루션은 나무와 같다.
DB암호화 솔루션은 나무와 같다고 생각하면 쉽게 이해될 수 있다. 즉, 줄기와 뿌리로 이루어 진다는
이야기 이다.
줄기에 해당하는 부분은 실제로 이용 되어지는 기능, 즉 보안기능 영역에 해당 한다.
뿌리에 해당하는 부분은 드러나지는 않지만 부실할 경우 나무가 제대로 자랄 수 가 없다.
이 부분이 바로 DB 운영성 영역에 해당되며 성공/실패를 판가름 짓는 근간이 되는 부분 이다.
성공적인 구축/운영을 위하여 위의 큰 두 가지 영역 (보안성 + DB운영성)은 너무나도 중요하다.
지금까지의 실패 사례의 원인은 대부분 줄기에 해당하는 보안 부분만 검토하고, DB운영성
부분의 필수 기능을 검토하지 않았기 때문으로 분석된다.
그럼, 반드시 필요한 기능요소들은 어떤 것 들이 있는지 살펴 보자.
① 강화된
DB암호화 에서 줄기에 해당하는 부분은 바로 안전한 알고리즘과 안전한 키관리 체계
이다.
DB보안 솔루션의 주 목적은 중요한 정보를 안전한 알고리즘으로 암호화하고 이 데이
터를 암.복호 할 수 있는 키를 기준에 맞도록 안전한 관리체계를 제공 하여야 한다는
것이다. 나머지 보안 기능들은 모두 잔 가지에 해당 된다.
이를 위해서는 반드시 개정된 보안적합성 검증기준에서 요구하는 “암호모듈검증
기준”을 만족 하여야 한다.
② DB운영을 불가능하게 하는 제약사항과 성능저하가 최소 일 것
뿌리가 부실하면 나무가 곧 죽게 되는 것처럼, DB암호화 솔루션으로 말미암아 원래
운영하던 바 대로 시스템 운영을 하는데 심각한 제약이 오게 되면 곧 도입 실패로 이어
진다. 결국 차.포 떼고 나면 검색할 가능성이 없는 비밀번호만 암호화하던가 그도 아니
면 쳐 박아 놓고 있는 것이 작금의 딱한 현실이다.
최소한 법규에서 정한 보안성을 지킴은 물론, 개인정보(또는 중요 기업정보)를 암호화
하고도 DB를 큰 문제없이 운영 하려면 다음과 같은 요소들이 필수적이다.
(참고자료 : 논문 “개인정보 침해사례를 통한 개인정보 보호에 관한 연구 –
자료
“DB보안 기술의 현황과 문제점 분석 -
“금융권 DB암호화 솔루션 도입시 고려사항 검토– 금융보안연구원”,
“금융권 정보보호 이슈분석 – 금융결제원”)
(표 2)
|
기능 요소 |
내용 |
미지원시 문제점 |
|
안전한 알고리즘 (ARIA,SEED,AES,TDES,DES) |
안전한 알고리즘으로 최고의 보안성 보장 |
보안성 미비 |
|
안전한 키관리 |
암호모듈검증기준이 요구하는 안전한 키관리 (불법접근 불가, 키 제로화) |
보안성 상실 (대문 열쇠를 벽에 걸어둔것과 같음) |
|
인덱스 암호화 및 검색 |
인덱스도 암호화 되어야 하며 암호화된 인덱스를 통한 색인검색이 지원될 것 |
인덱스를 통한 색인검색이 안되면 수백 배나 더 시간이 걸리는 Full Table Scan이 발생함. (결국 비밀번호밖에는 암호화할 수 없어 짐.) |
|
성능 |
구축성능 및 검색성능의 저하가 최소일 것 |
구축성능이 느리면 작업시간을 잡기가 어려워지며, 구축 후 검색성능이 느리면 고객 서비스에 지장을 줌. |
|
가용성 |
장시간이 소요되는 DB암호화 작업으로 인한 서비스중단이 없거나 최소일 것 |
수 십 시간 이상 DB가 정지 하므로 서비스 중단을 초래 (24x365 서비스 업무에서는 도입자체가 불가능해짐) |
|
최소의 제약사항 |
제약사항이 가능한 한 적을 것 (NULL 데이터 암호화, PK/UK 암호화 가능할 것) |
암호화 적용 자체가 이러한 제약사항들로 인해 원래 목적한대로 구축이 불가능해짐. |
첨부 “표 3”은 위의 기준이 반영되어 최근 많이 사용되고 있는 체크리스트 이다.
(“DB암호화 솔루션 선정을 위한 기능평가표”)
DB암호화 솔루션으로 적용 가능한 업무 분야
- 어디에, 어떻게 적용을 하면 좋을까?
1. 암호화대상 선정의 기본 방향
① 법규 충족 : 암호화의 대상의 증가는 곧 DB성능 저하와 직결 되므로, 법규를 확대 해석
하여 적용 하기에 앞서, 명시된 대상 (주민번호, 패스워드)을 우선적으로 반드
시 암호화 한다.
② DB운영성 고려 : 성능저하와 DB제약사항을 고려하여 추가로 암호화가 필요한 대상을
선정 한다.
2. 암호화 구축작업의 기본 절차
① 영향 분석 : 암호화로 인한 기존 애플리케이션의 운영에 어떤 영향이 있을 것 인지를
사전에 면밀히 분석 한다. 방법으로는 월말 배치 작업이 있다면 이 기간을
포함하여 약 1주간 모니터링하고 DB서버에 요청하는 쿼리문장을 분석해
본 후 영향을 줄 수 있는 문제 쿼리를 찾아낸다.
② 대책 수립 : 문제 쿼리가 만일 배치작업의 쿼리이고 Tuning 차원의 수정이 가능한 상태
라면 쿼리 문장의 Optimizing 을 실시 한다.
③ 환경 체크 : 작업에 필요한 여분의 Temporary Disk 공간은 있는지, 기타 DB의 환경변수
들은 적절한지, 필요한 패키지나 패치 레벨 등이 적절히 설치되어 있는지
등을 체크 한다.
④ 작업 시작 : 전체 예상 작업시간 중 업무에 지장이 없도록 작업 대상 테이블의 순서와
작업 시간대를 조정한다.
서버의 성능을 고려하여 비 업무시간대일 경우 가능한 한 Parallel 처리를
하여 짧은 시간내에 마치도록 한다.
이 작업을 하는 동안 서비스를 계속할 수 있는 무 중단 구축의 필요성과
효과를 절감 할 수 있을 것이다.
⑤ 완료 후 테스트 : 작업이 완료되고 나면 필요에 따라 암호화한 데이터가 정확히 변환
되었는지 정합성 체크를 실시한다.
애플리케이션을 수행하여 문제가 있지는 않은지 성능저하는 어느 정도인지
를 확인 한다.
여기까지 문제가 없다면 성공한 것이다.
3. 암호화 가능한 데이터 및 적용 업무
DB암호화 솔루션으로 암호화 구축이 가능한 업무 및 데이터 종류는 대체적으로 다음과
같다. ( * 표시는 CubeOne™ 의 기능임.)
① 적용 가능 업무 : 고객DB (개인정보, 본인확인용 스캔문서*),
인사DB (개인정보, 고과/연봉 정보),
기술DB (도면, 기술문서) *,
기타DB (CCTV영상-사건 조사기록 등) *
② 암호화 가능 데이터 : CHAR, VARCHAR, VARCHAR2, DATE, INT, NUMBER, FLOAT,
LONG, LOB(도면,동영상) *
DB암호화를 둘러싼 오해와 진실
- DB암호화에 대해 속 시원히 알고 가자!
부하에 관한 오해와 진실
오해 : 암호화를 하면 암.복호 작업이 전체 부하의 전부이다?
따라서 DB바깥에서 이를 수행하면 부하가 없다. (그럴듯한 이야기임에 틀림 없다.)
진실 : 이 경우 DB자체에 암.복호 부하가 없어지는 것은 사실 이지만 암호화된 데이터만 가지
고는 색인검색이 불가능해지기 때문에 Full Table Scan 이 발생하게 되므로 결과적으로
DB는 이전에 없던 엄청난 부하를 지게 된다.
또한 Application 형태로 DB외부에 설치하여 여기에서 암.복호를 수행하는 경우, 이
Appliance에 얼마나 많고 빠른 CPU를 장착할 수 있을까? 원가 때문에 많이 넣지 못할
것이다.
암.복호는 거의 CPU cycle에 의존한다. 최근 수 십 개의 4GHz를 넘어가는 Clock을 가진
CPU가 장착되는 서버들이 대부분 이다. 4GHz로 동작하는 20개의 CPU를 가진 서버가
있다고 가정하자,
가용한 총 CPU cycle은 80GHz/초당 이다. 반면에 Appliance 에 통상 장착되는 CPU들은
이 보다 낮은 2GHz 대의 CPU 가 4개정도 장착 된다. 그러면 가용 cycle은 약 8GHz
정도가 된다. 과연 어느 쪽이 빠를까?
(그림 2)
DB접근제어 및 감사 제품 과 DB암호화 솔루션과의 관계
오해 : 접근제어(약칭)를 도입하면 DB암호화는 안 해도 된다?
진실 : 법규를 아무리 살펴봐도 그런 얘기는 없다. ‘중요한 개인정보에 대한 접근제어와
감사를 실시하고, 이를 저장할 때에는 암호화하여 저장 하라’고 되어 있다.
이 문제는 우선순위의 문제일 뿐 양자택일의 문제는 아니다. 즉, 투자비 지출계획에
의한 도입 순서의 문제라는 것이다. 법규만 충족하기 위해 ‘중요한 개인정보(즉 주민
번호, 패스워드)는 암호화 하고, 이 데이터에 대한 접근제어와 감사를 실시한다’ 라
는 명제가 성립되며 이 명제만 본다면 DB암호화 솔루션이 가진 접근제어와 감사
기능만으로도 충분하다.
하지만, 내부적인 이유에서 암호화 까지는 필요 없지만 접근제어와 감사가 필요한
경우도 많으므로 결국 두 가지 솔루션을 병행하여 구축하여 서로 보완 관계가
되도록 해야 한다.
DB암호화 솔루션과 접근제어 제품이 겹치는 기능의 차이점
오해 : DB암호화 솔루션의 접근제어 및 감사 기능으로 DB전체를 Cover 할 수 있다?
진실 : 기술적으로는 가능할 수도 있다.
하지만 DB내부에 설치되는 암호화 솔루션으로 암호화하지 않은 데이터 까지 모두
제어/기록 하게 되면 엄청난 DB부하를 수반하게 되므로, 현실적이지 못하다.
접근제어 제품은 그 대상을 접근제어 및 감사 대상을 DB전체로 하지만 일부 hole
(콘솔 접속 및 WAS와 같은 미들웨어에서 XA세션을 통한 접속시)이 존재하는 한편,
DB암호화 제품은 암호화된 컬럼 만을 대상으로 하지만 hole은 없다.
이것은 솔루션이 설치되는 위치에 기인한 문제이며, 이 같은 속성을 잘 알고 필요
하다면 두 가지 제품을 함께 구축하여 서로 보완이 되도록 하는 것이 보다 완벽한
방안이다.
어떤 형태의 DB암호화 제품이 좋은지
오해 : 암호화 제품은 다 똑 같다?
진실 : 그렇지 않다. 현재 DB용 암호화 제품은 크게 3종류가 있으며 각각의 특성은 다음과
같다.
API 방식의 제품 – AP서버에 설치, 애플리케이션을 수정 하여야 하며, 암.복호 부하는
AP서버에 생기고 색인검색이 불가능함. (주로 비밀번호 암호화 용도로 쓰임)
Appliance 제품 - AP서버와 DB서버 사이에 설치, 애플리케이션을 수정 하여야 하며,
암.복호 부하는 Appliance에 생김. 색인검색은 불가능함. (주로 비밀번호
암호화 용도로 쓰임)
Plug-In 제품 - DB서버에 설치, 애플리케이션의 수정이 불필요하며 암.복호 부하는
DB서버에 생김. 색인검색이 가능(제품별로 암호화된 인덱스를 통한 검색을
모두 지원 하지는 못함)
DBMS별 특성
오해 : 모든 DBMS에서 암호화된 인덱스를 통한 색인검색이 가능하다?
진실 : 그렇지 않다. 현재 Oracle은 지원되고 있고, 조사해본 바에 의하면 Informix 정도만
이 가능한 것으로 보인다. 그 이유는, 암호화된 인덱스를 통한 색인검색이 가능하도록
하는 기술은 생각보다 매우 까다롭다.
또한 DBMS에서 제공되어야 하는 몇 가지 특별한 기능을 필요로 하는데, 현재 이
기능을 제공하고 있는 DBMS가 별로 없기 때문이다.
결국 국내에서 많이 사용하고 있는 DBMS들 중 Oracle을 제외하고는, 색인검색이
필요 없는 데이터(비밀번호 정도)는 암호화 할 수 있지만 주민번호는 암호화할 수
없다는 현실적 결론에 도달하게 된다.
맺는 말
DB암호화는 이제까지의 보안 제품들과는 상당히 복잡한 측면이 있다.
또한 한번 구축하고 나면 되돌리기도 만만치 않다. 따라서 처음 선정할 때 반드시 테스트를
해 보는 것이 좋다. 테스트용 데이터 말고 개발서버를 이용하여 실제 환경에서 테스트 해
보아야 한다.
그리고, 레퍼런스 정보를 요구만 하고 실제 잘 쓰이고 있는지에 대한 확인은 안 하는 고객
들이 대다수인데, 이 분야의 제품이야말로 ‘도입 레퍼런스 실적’이 아닌, ‘운영 레퍼런스
실적’을 살펴 보아야 한다.
그것도 어떤 데이터들을 암호화 하였고, 색인은 어떻게 되어 있는지(암호화 하였는지 여부)
등에 이르기까지 세밀한 검토가 필요 하다.
이러한 시각에서 제품선정을 한다면 아마도 원하는 제품을 선택할 수 있을 것이다.
(표 3)
[ DB 암호화 솔루션 기능 평가표 ]
|
제품명 |
|
제조사 |
|
확 인 |
(인) |
|
1. 보안 기능 |
|
|
대항목 |
중요도 |
소항목 |
평가 방법 |
평가 |
|
암호모듈 ( 15점 |
상 |
국가기관 및 민간용 KS표준 비밀키 암호알고리즘인 ARIA를 포함 하여 SEED, AES, TDES, DES등 지원 |
O,X |
|
|
상 |
국가기관용 표준 공개키 알고리즘 지원 [RSA (PKCS #1), RSAES-OAEP, RSASSA-PSS, 1024bit key 사용] |
O,X |
| |
|
상 |
난수발생기 규격 (DSA_RNG_SHA-1_160) |
O,X |
| |
|
상 |
정책 및 암복호 키는 유출 또는 위변조 되지 않도록 되어야 하고 DB서버에 존재하는 경우 비 인가자의 접근이 불가능 한 구조일 것 |
O,X |
| |
|
상 |
암호화 모듈 종료 시 키 제로화가 될 것 |
O,X |
| |
|
접근통제 10점 |
상 |
DB사용자별 접근통제 지원 |
O,X |
|
|
중 |
IP 주소별 접근통제 지원 |
O,X |
| |
|
중 |
애플리케이션별 접근통제 지원 |
O,X |
| |
|
중 |
기간, 시간대, 요일별 접근통제 |
O,X |
| |
|
하 |
데이터 복호화 선택적 허용 및 특정값 표시 |
O,X |
| |
|
감사 기록 10점 |
중 |
암호화 컬럼 접근대상 및 시간 기록 |
O,X |
|
|
중 |
접근 IP별 실행명령 및 수행결과 기록 |
O,X |
| |
|
중 |
다양한 로그기록 항목 및 저장용량 최소화 |
O,X |
| |
|
중 |
DML 종류별 / 성공 여부별 기록설정 기능 |
O,X |
| |
|
하 |
일정 주기별 통계자료 생성 |
O,X |
| |
|
하 |
로그 검색의 신속성 |
O,X |
| |
|
보안성 12점 |
상 |
제품 자체 보호능력 : 암호모듈검증기준의 VSL1 등급이상 충족 |
O,X |
|
|
상 |
암호화대상 데이터는 절대로 복호화된 상태로 저장하지 말 것 (테이블 및 Index 모두 암호화 할 것) |
O,X |
| |
|
중 |
SA와 DBA의 역할 분리가 될 수 있게 GUI를 통해 모든 구축 및 운영을 쉽게 할 수 있을 것 |
O,X |
| |
|
중 |
모든 암호화에 유추해석이 불가능하도록 초기벡터(IV)를 지원 |
O,X |
| |
|
중 |
안전한 키백업 및 복구 기능 지원 |
O,X |
| |
|
점수 계 (총47점) |
| |||
|
2. DB관련 기능 |
|
|
대항목 |
중요도 |
소항목 |
평가 |
평가 | ||
|
중요기능 55점 |
상 |
테이블 및 컬럼 단위의 선택적 암호화 지원 |
O,X |
| ||
|
상 |
Index 및 우선키(PK,FK) 암호화 지원 |
O,X |
| |||
|
상 |
NULL 데이터 암호화 지원 |
O,X |
| |||
|
상 |
초기구축 또는 운영중 컬럼 단위의 추가 암호화 작업시 실시간(DB무중단) 암호화 지원 |
O,X |
| |||
|
상 |
암호화한 Index컬럼의 색인검색(일치/조건) 지원 |
O,X |
| |||
|
상 |
특정 데이터 타입 컬럼으로 인해 다른 컬럼의 암호화 제약 여부 |
O,X |
| |||
|
상 |
전체컬럼 단위의 암호화 작업시 과도한Lock 발생 여부 |
O,X |
| |||
|
상 |
암호화 적용 후 Index 기능 유지 여부 |
O,X |
| |||
|
상 |
제품설치로 인한 애플리케이션 수정 필요성 여부 |
O,X |
| |||
|
상 |
네트워크 또는 제품 장애로 인한 구축중단 또는 서비스 중단 가능성 |
O,X |
| |||
|
중 |
암호화된 컬럼에 대한 배치(update)시 일반 DML 처리에 지장이 없을 것 |
O,X |
| |||
|
중 |
제품 작동시 시스템 리소스 사용률의 적정성 (CPU 부하 증가량) |
O,X |
| |||
|
중 |
제품(관리모듈 및 Plug-In Daemon)의 장애시 DB서비스의 장애 발생 여부 |
O,X |
| |||
|
하 |
테이블에 설정된 Dependency 및 Constraint 속성 유지 기능 |
O,X |
| |||
|
중 |
Default 컬럼에 대한 암호화 지원 |
O,X |
| |||
|
중 |
암호화된 테이블에 대한 Backup/Recovery에 문제점 유무 |
O,X |
| |||
|
중 |
필수 암호화 가능 DATA TYPE |
CHAR |
O,X |
| ||
|
중 |
VARCHAR2 |
O,X |
| |||
|
중 |
NUMBER |
O,X |
| |||
|
중 |
INTEGER |
O,X |
| |||
|
중 |
DATE |
O,X |
| |||
|
중 |
FLOAT |
O,X |
| |||
|
중 |
LONG |
O,X |
| |||
|
점수 계 (총 55점) |
|
| ||||
|
2. 일반 기능 및 기타 |
|
|
대항목 |
중요도 |
소항목 |
평가 방법 |
평가 |
|
사용자 편의성 6점 |
중 |
사용자 인터페이스의 편이성 (GUI의 제공) |
O,X |
|
|
하 |
이 기종 DBMS 동시 지원 기능 |
O,X |
| |
|
하 |
다수의 DB서버를 1대의 Management 콘솔로 통합관리 기능 |
O,X |
| |
|
하 |
암호화 구축 작업시 작업 진척도 정보 표시 |
O,X |
| |
|
하 |
시스템 자원 사용량 표시 |
O,X |
| |
|
기술지원 6점 |
하 |
기술지원 요원 (Skill) |
O,X |
|
|
중 |
구축 및 운영 실적 |
O,X |
| |
|
하 |
교육 지원 |
O,X |
| |
|
하 |
유지보수 형태 및 지원 내용 |
O,X |
| |
|
하 |
별도의 업그레이드 비용 유무 |
O,X |
| |
|
점수 계 (총 12점) |
| |||
|
점수 총계 (총 114점) |
| |||
※ 의미 : DB암호화 제품의 핵심 보안 기능은 안전한 암호 알고리즘 및 키 관리 시스템인 만큼,
향후 전면 시행 예정인
중요도 “상”인 항목은 반드시 지원 되어야 한다.
※ 평가방법 : 각 항목별 중요도에 따라 배점을 달리(상:3, 중:2, 하:1) 하며, 지원되지 않으면(X) 0점 처리한다. 특히 보안
기능 중, 중요도 “상”인 항목은 명확히 지원 되지 않으면 배점 만큼 감점(상:-3, 중:-2, 하:-1점) 처리 한다.
출처 : http://cafe.naver.com/securityplus.cafe
댓글