1. DB 암호화 개요

DB는 기업의 IT자산 중 가장 가치 있는 핵심으로서 고객 정보, 재무 데이터, 거래 기록 등을 유지·관리하고 있다. 이러한 DB를 보호해야 하는 중요성은 점점 증가하고 있지만 이를 수행해야 하는 일은 매우 어렵고 특히 암호화를 수행하는 경우는 더욱 그렇다. 분명 한 것은 핵심 비즈니스 가치를 지닌 DB의 존재는 공격대상이 될 수 밖에 없고, 이러한 공 격을 통해 DB가 유출이 된다면 관련 조직의 재정 및 기업 이미지에 엄청난 피해를 줄 것 이다.

언론상에 자주 오르는 소비자 거래 기록과 신용카드 및 개인 정보의 유출 사고는 새로운 규정과 DB 보안에 관한 법률들을 강화하게 만들고 결국 기업들은 이러한 법률적 요구사항 과 악의적 공격에 대응하기 위해 DB 보안에 관심을 두게 되었다. 본 절에서는 이러한 요구 사항에 맞추어 DB 암호화에 대한 요구사항과 가이드라인을 언급하고자 한다. 분명한 것 은 조직의 DB를 보호하기 위해 조직내 모든 네트워크의 연결통로에 대한 보안이 필수적으 로 병행되어야 하며 이것은 DB 보안을 위한 기본적인 요구사항이다. DB 암호화뿐만 아닌 DB 접근제어를 통해 암호화로 인한 보안홀을 방어해야 함을 명심해야 한다.

DB에 대한 공격위협은 방화벽 밖의 외부 네트워크에서 진행될 수 있지만, 오늘날의 현실 은 인가된 내부자에 의한 유출사고가 빈번하므로 이에 대한 방어가 절대적으로 필요하게 되었다. DB는 IT 인프라의 다양한 시스템에서 접속하게 되므로 그만큼 복잡하고 취약한 부분이 노출될 수 밖에 없다. 따라서, DB에서 관리되는 민감한 정보를 보호하기 위한 전 략이 필요하다. 앞의 언급처럼 단순히 해커들만이 공격 위협의 주체가 아니라 방화벽이나 침입탐지 시스템에 의해 통제되지 않는 내부자에 의한 정보수집이 더욱 위험한 상황이다.
DB 접근제어 외에 DB 보안에 대해 국내외 법률과 규정은 주요 2가지를 강조하는데 첫 번 째는 암호화를 통한 DB 보안이며 두 번째는 엄격한 암호키 관리를 통해 데이터를 보호하 라는 것이다. 잘 다듬어진 데이터 암호화뿐만 아니라 안전한 암호키 관리를 통해 데이터가 유출되더라 데이터를 복호화할 수 없도록 암호키에 대한 기록과 소수의 인가자에 의한 접 근만 허용하도록 하는 것이 최종적인 DB 암호화의 완성이라고 할 수 있다.
데이터를 암호화는 것은 단순히 첫 번째 수행 단계에 불과하다. 강력한 암호키에 대한 인 증 및 권한관리가 없다면 내부자에 의해 손쉽게 유출되고 암호화된 데이터는 풀려버릴 것이다. 예를 들어, 직원의 인사정보, 연봉정보들이 관리되는 데이터가 쉽게 풀렸다고 생각해보면 이것은 단순한 데이터 유출이 아닌 직원 간의 불만 조성 등 더 큰 악재가 될 것이다.
DB 암호화를 위해 고려해야 할 중요한 3가지가 있다. 첫째, "어떻게 암호화를 수행 할 것 인가?" 둘째, "기업의 IT 인프라에서 데이터의 흐름이 어떻게 되는가?" 셋째, "DB 암호화 가 어떻게 기업내의 보안 규칙과 연동되는가?"이다.

가. 암호화 요건 분석

일단 애플리케이션에서 수집되는 민감한 정보들의 보안 레벨과 암호화 요구를 평가하고 그 데이터들이 DB 내에서 암호화되어 관리되기 위한 전략을 생각하여야 한다. DB 암호화 를 위해서는 데이터베이스관리시스템(DBMS, Database Management System)이 제 공하는 암·복호화 기능을 사용할 수도 있고, DBMS 외부에서 암·복호화가 수행될 수도 있다. 각각의 방법은 장단점이 존재하므로 조직내의 환경에 맞게 선택하여야 한다. 민감한 정보의 보안성을 높이는데는 암호화된 형태로 데이터를 저장하고 관리하는 DB 암호 화가 최선의 선택이다. DB 암호화의 목적은 비인가자에 의한 데이터 오용을 방지하기 위한 것으로 비정상적 데이터 유출이 발생할 경우 복호화를 어렵게 만드는 것이다. 암호키는 암 호화뿐만 아니라 복호화 할때도 사용하므로 암호키는 매우 신중하게 관리하여야 하며, 랜덤 키(Random Key)에 의해 암호화된 데이터는 해커들에 의한 복호화를 어렵게 만든다.

DB 암호화라고 모두 동일하지는 않다. 암호화될 데이터의 중요성에 따라 어떤 암호화 알 고리즘이 사용되는가와 암호키 사이즈가 어떤가에 따라 달라지게 된다. DB 암호화를 위 해 DES 알고리즘이 많이 사용되고는 있지만, 다소 보안성이 약한 것으로 여겨지기도 한 다. 반면, 3DES 알고리즘은 속도 면에서 뒤떨어지기는 하나 보안성 측면에서 강한 면으 로 인해 널리 사용되고 있다. 사실상 3DES 알고리즘은 보안 알고리즘 중에서 속도가 제일 뒤떨어지는 알고리즘 중의 하나로 평가 되기도 하지만 DB 암호화를 구축할 때는 산업계에 서 안전하다고 평가되는 알고리즘을 사용할 것을 권고한다.

암호화 알고리즘의 성능과 보안성을 떠나 더욱 중요한 것은 암호키 관리이다. 암호키에 접 근할 수 있는 사람(혹은 시스템)과 접근할 수 없는 사람을 명확히 해야 한다. 즉, 복호화를 해야만 하는 사용자(혹은 시스템) 외에 다른 사용자에 의한 암호키 접근을 통제하여야 한 다. 물론, 암호키 접근 통제 정책에 의해 관리의 효율성이 떨어질 수 있지만 매우 중요한 요소임에는 틀림 없다.

DB 암호화를 통해 민감한 데이터의 보안성이 강화되는 것에는 의심할 여지가 없지만 암 호화로 인한 데이터 사이즈의 증가나 성능 저하 등을 고려할 사항이다. 시스템 성능에 미 치는 영향은 애플리케이션 초기 설계부터 DB 암호화를 고려한다면 좋은 결과를 가져올 수 있다. 즉, 어떤 데이터를 암호화 할 것인가를 결정하고 데이터 사이즈 증감에 대한 예 측을 한다면 더 효율으로 암호화된 DB를 완성할 수 있을 것이다. 예를 들면, 카드번호 전 체를 암호화할 것인가? 혹은 부분 암호화를 진행할 것인가? 등의 사전 결정을 통해 DB 설 계의 중요한 결정 요소를 정하게 될 것이고 이는 시스템의 전반적인 성능과 구조를 결정 하게 한다.

DB 암호화를 하게 되면 원본 데이터의 사이즈가 변하게 될 수 있는데, 몇몇 암호모듈은 암 호화 이후 고정크기의 결과물로 인해 암호화 전과 동일한 크기로 만들거나 패딩(Padding) 하는 경우가 있다. 그러나 작은 크기의 원본 데이터를 암호화하여 데이터 사이즈가 증가하 게 되면 DB 컬럼의 사이즈까지 조정해야 하는 경우도 발생한다. 또한, 텍스트 블록을 이 진데이터로 암호화한 경우에는 다시 텍스트형태로 변환하여야 하기 때문에 사이즈의 변화 를 가져오게 된다.

DB 컬럼 암호화 시 유의해야 할 항목은 인덱스(Index)를 가진 컬럼이다. 대용량 DB에서 인덱스를 가진 컬럼이 암호화 되면 인덱스를 활용할 수 없기 때문에 특정한 레코드 값을 찾기 위해 엄청난 부하 발생과 응답시간의 저하가 발생할 것이다. DB 암호화의 대상 컬럼 은 대부분 인덱스를 가지는데 이로 인해 DB 암호화의 구축이 쉽지 않은 경우가 많기 때문 에 별도의 다른 컬럼으로 유도하는 전략도 필요하다.

나. 데이터 흐름 분석

DB 암호화를 수행하기 앞서 IT 인프라 내의 데이터가 어떻게 흘러가고 있고 어떤 시스템 이 해당 데이터를 사용하는가를 파악하는 것이 중요하다.
일단 DB가 암호화가 되면 그 자체로서 데이터 보안성을 강화할 수 있다. 하지만 애플리케 이션 서버와 통신하는 상황에서 해당 애플리케이션 서버가 복호화된 데이터를 처리하는 과정에서 내부적으로 캐시를 사용하여 임시 저장하거나 다른 연계 시스템으로 복호화된 평문 데이터를 전송할 수 있다. 경우에 따라서는 애플리케이션 서버로 암호화된 데이터가 전송되고 애플리케이션 서버에서 복호화하는 경우도 있다. 따라서, 암호화된 데이터와 복 호화된 데 복호화된 데이터로 존재할 수 있기 때문에 이에 대한 정확한 정의가 필요하다.

다. 암호키 관리 지표

DB 암호화의 가장 중요한 요소는 암호키 관리이며 암호키를 어떻게 안전하게 보호하는 것 인가가 매우 중요하다. 암호키 관리의 2가지 측면으로 "어디에 암호키를 저장할 것인가?" 와 "누가 그 암호키에 접근할 수 있는가?"를 들 수 있다. 안전한 암호키 관리는 DB 보안 전 략의 매우 중요한 요소로 다음 항목들은 암호키 관리를 위한 개괄적 지표이다.

■얼마나 많은 암호키를 가질 것인가?
■어떻게 암호키를 관리할 것인가?
■암호키가 어디에 저장되는가?
■암호키를 위한 접근정책을 어떻게 할 것인가?
■얼마나 자주 암호키를 변경하는가?
■암호키에 대한 사용 이력을 관리하는가?
■암호키 분식에 대한 대책은 어떻게 세우고 있는가?

암호키 관리는 매우 까다롭지만 반드시 해결해야 할 사안이다. 하나의 암호키로 DB 암호 화를 하게 된다면 구축이 매우 손쉽게 이루어지겠지만, 해당 키가 유출될 경우에는 매우 위험한 상황에 처할 수 있는 단점이 있다. 기업 내에는 수많은 시스템들이 있고 각자의 비 즈니스를 처리하기 위해 암호화된 데이터를 복호화 하는 암호키를 사용할 것이다. 이러한 경우 하나의 암호키로 구성된 DB 내의 데이터는 데이터 보호 영역이 사라지고 암호화의 의미를 잃게 된다. 따라서, 업무의 범위나 시스템의 역할에 따라 암호키를 분리하고 이에 따른 암호키의 접근제어 정책이 수반되어야 한다. 즉, 암호키 관리의 불편함을 해소함과 동시에 한 개가 아닌 소수의 암호키를 분리하여 적용하는 것이 보안강도를 높이는 좋은 전 략이라 할 수 있다.
다음으로 결정해야 할 일은 "어디에 암호키를 저장하고 관리할 것인가?"이다. DBMS의 암 호화의 기능을 사용하는 경우 가장 손쉬운 방법은 제한된 테이블(Table)이나 파일(File)에 저장하는 것이다. 그러나, 이러한 방법은 DB 관리자(DBA)가 접근 권한을 가진 경우가 대 부분이고 임의의 복호화작업이 가능할 수 있으므로 위험할 수 있다. 따라서, DB 서버와 별개의 독립된 머신(HSM, Hardware Security Module)에 암호키를 관리하는 것이 바 람직하다. 이렇게 관리되는 암호키는 시스템상의 접근제어는 물론 강력한 인증과 파일 접 근 제한 등의 강력한 보안조치를 통해 안전하게 관리된다. 또한, 암호키는 접근제어를 통 해 관리자나 임의의 사용자에 의한 암호키 유출도 막을 수 있다.

암호키 분리 정책과 암호키에 대한 접근제어 정책 없다면 애플리케이션을 개발하고자 하 는 개발자부터 DB를 관리하는 DBA까지 누구나 해당 암호키를 접근할 수 있게 된다.

라. DB 암호화 구축 계획

DB 암호화의 효율적인 구축 방법은 "어디서 암호화를 수행할 것인가?", "어디에 암호키를 저장할 것인가?", 그리고 "누가 암호키를 접근할 수 있는가?"를 결정하는 것이다. DBMS가 암호화 기능을 지원할 경우 DB 서버 내에서 수행하는 경우가 있고 별도의 머신 에서 암호키가 관리되는 경우가 있다. 물론, 솔루션의 종류에 따라서는 DB 서버 내에 암 호화 엔진을 별도 장착하여 암호화를 수행하는 경우도 있다.

DB 서버 내에서 암복호화를 수행하는 경우에는 애플리케이션에 대한 영향이 최소화되는 장점이 있지만, 성능 저하에 따른 부담과 추가적으로 고려해야 할 보안 요소들이 많다. 물 론 사용되는 암호화 알고리즘에 따라서는 성능 저하가 더욱 심화될 수도 있다. 즉, 알고리 즘에 따라 DB 성능에 막대한 지장을 줄 수 있으므로, 알고리즘에 의한 암호화로 데이터의 보안성을 확인하기 위해서는 어떠한 암호화 알고리즘이 사용되는지를 파악할 필요가 있 다. 일반적으로 DES 알고리즘은 보안성이 약하고, 3DES 알고리즘은 속도가 느리다. 또 한, 어떤 대칭형 알고리즘은 128-bit 키를 사용해야만 한다.

DBMS가 제공하는 암호화 기능을 사용할 경우에는 암호키가 DB 내의 테이블에 존재하고 DBMS가 제공하는 접근제어에 의해서만 보호되는 단점이 있다. 종종, 데이터 복호화 권 한을 가지는 사용자가 암호키에 접근할 권한을 가지게 되는데 이것은 암호화와 복호화가 가능한 방법이 상존하는 보안 취약점을 유발하게 된다. 그러나, 이러한 비인가 행위에 대 한 모니터링과 추적에 대한 방법이 거의 없는 것이 현실이기 때문에 DB 서버가 아닌 별도 의 머신에서 암호화하는 솔루션을 찾는 경향이 있다.

국제 의료정보보호법인 HIPPA나 Gramm-Leach-Bliley 법규에서는 엄격한 암호키 관 리와 분리 원칙을 권고하고 있고 다른 법규도 마찬가지다. 별도의 독립된 암호화 장비는 자체적으로 암복호화를 수행하는데 DB 서버나 애플리케이션 서버의 부하를 줄일 수 있 고, DB 내의 암호화문과 복호화가 가능한 방법인 암호키가 분리되는 강점을 가지게 된다. 또한, 구조적으로 암복호화 서버에서 분리되지 않고 암호키에 대한 강력한 접근제어 및 암 호키 사용에 대한 이력을 가질 수 있는 중요한 장점이 있다.

마. DB 서버 내부에서의 암호화 구축

DB 서버가 제공하는 암호화 기능을 사용하는 경우 손쉽게 암복호화가 구현이 가능하고 DB 서버와 연계되는 애플리케이션들의 수정이 별도로 필요로 하지 않는 투명성 (Transparent)를 제공한다. DB 서버 내부에서의 암호화는 평문의 데이터를 암호화하여 저장하고, 암호화된 데이터를 평문으로 변환하여 전달하기 때문에 DB 암호화의 가장 쉬 운 방법 중에 하나이다. 그러나, DB 서버의 부하와 동일한 DB 서버 내의 암호키 관리에 따른 보안 위험성을 반드시 고려하여야 한다.

DB 암호화의 또 다른 방식은 DBMS가 제공하는 암호화 기능이 아닌 3rd Party 벤더 (Vendor)사에서 제공하는 에이전트 방식(Agent)으로 정의되는 플러그인(Plug-In)방식 이다. 이 경우는 DB 서버의 부하를 발생시키지만 암호키 관리를 외부에서 수행하기 때문 에 보안 취약점을 극복할 수 있는 장점이 있다.

일반적으로 DB 내에서의 암호화는 프로시저(Procedure)나 뷰(View) 혹은 트리거(Trigger) 를 활용해서 수행하는데, DBMS의 제조사에 따라 기능적 차이가 있기 때문에 암호화 구축 에서 고려해야 할 항목이다. 종종 특정 DBMS 벤더는 DB 전체를 암호화만을 지원하는 경 우가 있는데 이러한 경우는 불필요한 컬럼까지 암호화를 수행해야 하는 부담으로 인해 성 능을 저하시킨다. DB가 암호화되면 모든 데이터가 저장될 때 마다 혹은 데이터를 읽을 때 마다 암복호화 작업이 진행되기 때문에 부하를 얼마나 감소시킬 수 있는가를 위한 전략이 필요하게 된다.

데이터가 저장될 때 암호화가 진행되면서 해당 프로시저(Procedure)가 호출되고 해당 프로 시저는 암호키를 조회하여 지정된 알고리즘을 통해 암호화하여 데이터를 저장한다. 데이터 가 조회될 때에는 동일한 프로세스가 반대 방향으로 처리된다. 대용량의 데이터를 처리하기 위해서는 인덱스가 부여되지 않은 컬럼에 대해 암호화를 진행하는 것이 이상적이지만, 인덱 스가 부여된 컬럼에 대한 암호화가 필요할 때는 인덱스 처리를 통한 검색을 어떻게 처리할 것인지를 고민하여야 한다. 이를 위해 인덱스 컬럼에 대한 검색을 지원해 주는 솔루션들이 있으나 DB가 제공하는 기능을 활용하는 것이므로 DBMS의 종류에 따라 제한적인 적용이 될 수는 것은 기존 애플리케이션의 수정이 필요없는 장점이 있기 때 문에 애플리케이션의 재설계 및 재개발에 대한 비용이 발생하지 않는다. 그러나, 이러한 방 식은 DB 서버와 애플리케이션 간의 데이터가 암호화된 데이터가 아닌 평문(Plain Text)이기 때문에 데이터를 전송하는 구간에서 보안 취약점을 가진다. 또한, 암호키가 DB 서버 내에 함 께 존재하여 DB 관리자에 의한 암호키 접근을 방어하기가 어려운 점도 동시에 존재한다. DBMS의 암호화 기능은 대체로 제한적인 암호화 알고리즘을 사용하는데 대부분 DES 혹 은 3DES만을 지원하고 있고 이것은 전반적으로 DB의 성능 저하를 가져오기 때문에 최근 에는 AES를 도입하여 보다 안전하고 좋은 성능을 확보하고 있다. 그러나, DBMS의 암호 화 기능은 대체로 제한적인 암호화 알고리즘만을 지원된다.

암호키는 안전성을 위해 랜덤(Random) 발생기에 의해 생성되어야 바람직하기 때문에 DBMS의 암호화 기능에서 제공되는 랜덤 발생기가 얼마나 많이 지원되고 어떤 타입이 지 원되는 것인가를 반드시 이해하여야 한다.
만약, 암호키를 DB 내의 테이블에 저장하기를 원하지 않는다면 어떻게 암호키를 분리해 서 저장할 것인가를 결정해야 한다. 가장 강력한 방법은 DB 서버와 연동되는 별도의 하드 웨어 머신에 암호키를 저장하는 방법이다. 보안성의 강도에 따라 HSM(Hardware Security Module)을 별도로 구매하여 암호키를 저장하고, 이를 통해 암호키 저장을 위한 안전한 장소를 확보함과 동시에 암호화를 위한 추가적인 기능 지원도 받을 수 있다. 최초 HSM 장비는 암호키의 백업 장소로도 각광 받고 있다.

바. DB 서버 외부에서의 암호화 구축

DB 내의 데이터가 유출 위험이 있는 상황에서 애플리케이션과의 전송 단계에서 유출에 대 한 보안성을 고려해야 한다면, 암호화 수행을 애플리케이션 지점으로 옮겨서 수행하는 방 식을 고민할 필요가 있다. DB 서버 외부에서 암호화를 구축하는 것은 애플리케이션에서 처리된 데이터는 암호화된 상태로 DB로 전송되고 안전하게 DB 내에 저장 관리되며, 반대 로 요청에 의해 암호화된 데이터를 가져와서 처리하게 되는 방식이다. 이 방식은 보안성 측면에서 좋은 결과를 가져오지만 기존 애플리케이션의 경우 데이터 처리를 위한 암복호 화 모듈을 탑재하기 위한 프로그램 수정이 불가피하게 된다. 애플리케이션 서버들은 업무 에 따라 여러 대의 서버로 분산될 수 있고, 이럴 경우 각각의 애플리케이션 서버에서 암복 호화를 진행하게 된다면 이것 역시 큰 부담이 될 수 밖에 없다.

따라서, 이를 해결하기 이한 좋은 방법은 암복호화 전용 서버를 두고 이 암복호화 전용서 버가 각각의 애플리케이션 서버의 암복호화 요청을 받아들여 수행하게 하는 방법이다. 이 렇게 되면 다수의 DB 서버와 다수의 애플리케이션 서버가 존재하는 복잡한 환경에서도 손 쉽게 DB 암호화의 운영이 가능하다.

이 방식의 최대 장점은 안전한 키 관리와 중앙집중형 통합관리가 가능하다는 점이다. 암호 키가 DB 서버로부터 분리되어 있기 때문에 DB 내의 암호화된 데이터가 유출되더라도 데 이터의 불법적인 복호화 위험이 사라지게 된다. 병행적으로 암복호화 서버내의 암호키에 대한 강력한 접근제어를 실시하여 보안성을 높여야 한다. 암복호화 서버는 명확히 HSM 장비와는 다르다. DB 외부에서의 암복호화를 수행하는 방식에 따라 별도의 하드웨어 머 신에 존재하지만, HSM 장비의 경우 암호키를 관리하는 전문 장비로서 산업계에서 널리 사용되고 있다.

사. DB 암호화 방식 비교

DB 암호화는 디스크 전체를 암호화하거나 암호화 대상이 되는 기밀정보를 담고 있는 컬럼 레벨로 암호화하는 경우가 있다. 후자인 컬럼 레벨 암호화의 경우 기존 Legacy 애플리케 이션의 수정이 필요 없는 Plug-In 방식과 애플리케이션의 수정이 필요한 API 방식이 널 리 사용되고 있다.

디스크 전체(DB 파일)를 암호화 하는 것은 DB 파일을 보호하고 비인가 사용자에 의한 불 법적인 파일 열람을 제한하는 것이다. 인가된 서버만이 정상적인 암호화된 데이터를 해독 하고 열람할 수 있게 하는 것으로 DB 암호화 중 가장 편한 방법 중 하나이다.
하지만 DB 파일을 암호화하는 것은 인가된 DB 호스트 서버에 접속하는 다양한 시스템들 과 사용자들을 식별하지 못하므로 이를 위해 컬럼(Column) 레벨의 암호화가 요구된다. 컬 럼 레벨의 암호화는 개인정보나 기업의 민감한 정보를 담고 있는 특정 테이블의 컬럼만을 암호화 하는 것으로 DB 서버에 접속하는 사용자들을 구분하고 정의된 암복호화 정책에 따 라 데이터를 제공하므로 DB 암호화 솔루션 중에 현장에서 가장 널리 쓰이는 솔루션이다.

컬럼 레벨의 암호화는 DB 서버내의 플러그 인을 장착하여 암복호화를 수행하는 방식과 애 플리케이션 서버가 암복호화를 위한 API을 호출하여 수행하는 방식으로 나뉘는데, 선택 시에 고려점은 DB 서버의 자원 사용량, 속도 개선 그리고 기존 애플리케이션의 수정 여부 등이다.

아. 컬럼 암호화의 주요 순서

DB 내의 특정 컬럼을 암호화하기 위한 주요 절차는 다음과 같다.

1) 신규 암호화 계획(Encryption Plan) 생성 (혹은 기존 Encryption Plan 활용)
※ 암호화 계획이란 암호화 대상 DB 선택부터 테이블, 컬럼, 암호키, 알고리즘, 백업 등을 모두 고려함을 의미하는 포괄적인 계획을 의미함.

2) 암호화 계획에 사용될 신규 암호화 키를 등록하거나 기존 암호화 키를 활용 (하나의 Encryption Plan은 여러 개의 Encryption Key를 포함)한다.

3) 암호화 계획에 의해 적용 될 암호화 대상 DB를 설정하고, DC모듈(플러그 인 방식의 Component 모듈)을 설치한다.

. DC 모듈은 암호화 대상 DB 인스턴스 별로 설치가 되므로 매번 DC 모듈을 설치할 필요는 없게 된다.
. DC 모듈은 동일한 DB 인스턴스 내의 다른 DB에 의해 공유가 될 수 있다.
. 암호화 대상 DB는 다른 암호화 계획에 의해서도 동시 적용이 될 수 있다. 예를 들 어, 테이블의 컬럼A는 암호화 계획 A에 의해 적용되고, 컬럼 B는 암호화 계획 B에 의해 적용 될 수 있다.

4) 암호화 대상 DB의 스키마(Schem)를 결정한 뒤에 암호화 대상 테이블과 컬럼을 차례대 로 결정하면 테이블의 컬럼들이 보이게 되는데, 암호화 대상 컬럼에 대한 암호화 키를 선택한다. 추가적으로 부분 암호화나 비인가 사용자에게 반환할 값을 결정하는 파라미터들을 설정하게 된다.

6) 모든 설정이 끝난 후에 암호화 진행이 결정되면 암호화를 위한 데이터 이관(Data Migration)이 수행되게 되는데 사고방지를 위한 관리 절차를 준수한다.

7) 암호화를 위한 데이터 이관(Data Migration)은 암호화 대상 테이블의 레코드 개수에 따라 시간이 증가할 수 있으며 암호화가 완료될 때까지 기다리게 된다. 암호화와 마찬 가지로 암호화 대상 테이블의 레코드 개수에 따라 시간이 증가할 수 있으며 암호화가 완료될 때까지 기다리게 된다.

DB 암호화를 위한 DBMS의 암호화 기능은 제조사별로 차이가 있어 특정 제조사의 사례보 다 산업계에서 가장 널리 쓰이는 플러그인 방식의 DB 암호화를 기반으로 암호화 운영에 대한 요소들을 이해할 필요가 있다.
플러그 인 방식의 경우 암호화 대상 DB의 엔진 위에서 동작하는 컬럼 레벨의 DB 암호화 소프트웨어 방식이다. DB에 접속하여 수행되는 기존 DB 클라이언트 애플리케이션의 수 정이 필요하지 않도록 설계되어 암호화 적용을 수월하게 진행할 수 있다.
예를 들어, 암호화를 원하는 데이터가 DB 내에 테이블과 컬럼 형태로 존재하고 있다면, 비인가 사용자들로부터 데이터를 보호하기 위한 DB 암호화 작업은 다양한 암호화 대상 컬 럼 값의 암호화된 값을 유지 관리하기 위하여 별도의 컬럼 데이터(using base64- encoded strings 혹은 BLOB등의 기타 형식)를 생성하게 된다. 이때, 암복호화 프로세스 를 감추기 위해 암호화 대상 테이블과 동일한 이름의 뷰를 생성하게 되므로 기존 DB에 접 속하는 애플리케이션들은 별도의 수정 없이 DB 암호화가 가능하게 된다.
인가된 사용자를 위해 필요한 데이터들은 자동으로 복호화가 수행되어 애플리케이션의 동 작을 지원하게 하고 복호화는 내부적으로 정의된 접근정책에 따라 복호화 여부가 판별된 다. 복호화 대상이 되는 DB 클라이언트는 클라이언트 OS 이름, DB 사용 계정, 클라이언 트 IP 주소, 애플리케이션 이름 및 시간설정에 따라 접근정책이 적용되고, 이렇게 생성된 정책에 의해 복호화 대상 DB 클라이언트가 정해진다. 접근정책에 의해 정해진 비인가 사 용자들은 암호화된 데이터만을 볼 수 있기 때문에 조회나 데이터 수정이 불가하게 된다.

자. DB 암호화의 주요 모듈 구성

DB 암호화 작업은 크게 4개의 구성요소로 나뉘게 되는데, 운영자 관리 콘솔인 Key Management Site(KMS), 암호화 키를 보관하는 Key Store (KS), 암복호화 엔진인 Network Encryption(NE) 혹은 Local Encryption(LE) 그리고 DB 내부에 설치되는 Plug-In Database Component(DC) 모듈로 구성이 된다.

차. DB 암호화 제품의 보안 요구사항

데이터 암복호화 자체는 암호화 알고리즘에 따라 진행되므로 매우 간단하지만, 암복호화 에 사용되는 키 관리가 매우 중요하며 신중한 관리절차가 필요하게 된다. 본 절에서 다루 는 암복호화의 대상이 일반 파일이나 네트워크 구간이 아닌 DB이기 때문에, DB 서비스의 영속성을 위해서 DB 암호화 후 기존 DB 제약사항 유지나 서비스의 안정성이 무엇보다 중 요하다. DB에는 중요한 정보들이 여러 테이블내의 컬럼들 속에 존재하고 있고, 이러한 정 보들은 DB 내부의 인덱스(Index), 내장 애플리케이션(Stored Application), 패키지 (Package), 함수(Function) 그리고 DB 외부의 애플리케이션들과 밀접하게 상호 작용을 하므로 DB 암호화 후에도 이러한 시스템적 관계유지가 절대적으로 필요하다. 또한, DB 암호화를 위해 솔루션 도입 시에는 다음의 국가정보원“DB 암호화 제품의 핵심 보안요구 사항(http://www.kecs.go.kr)”을 준수해야 한다.

또한, DB 암호화 시에 사용되는 모듈은 다음 국가정보원의 검증대상 알고리즘(암호 검증 기준 - KS X ISO/IEC 19790)을 사용해야 한다.