| 믿을 건 DB암호화 뿐! | 2010.03.22 |
암호화와 OLTP 성능 보전 방안
해커에게 고객DB 털렸다면 데이터 암호화후 적절한 조치를 취하지 않을 경우 투명성 및 기능성을 확보하는데 어려움이 따를 수 있다. 적절한 조치를 취하지 않을 경우 발생하는 OLTP 업무 질의의 투명성 및 성능 저하를 살펴보고 이를 극복하기 위해 적용 가능한 방안을 논해 보고자 한다. 데이터베이스 관리자는 데이터가 암호화 된 이후에도 기존의 응용 프로그램을 수정하지 않기를 바라며(투명성), 또한 이러한 응용 프로그램의 성능이 저하되는 것을 원하지 않을 것이다(기능성). 하지만 간단한 데이터를 암호화 하더라도 암호화 값의 이진 속성에 따라 테이블의 정의까지 달라지는 경우가 발생하게 된다.
테이블의 암호화를 적용하고 난 이후에 발생하는 성능저하에 대해 많은 DBA들이 한번쯤 고민해 보았을 것이다. 데이터베이스에 암호화를 적용할 때 가장 먼저 거론되는 품질 요소는 성능 보존이라는 것이 많은 조사를 통해 알려진 바 있다. 이번에는 자주 사용되는 OLTP 업무 질의에 암호화를 적용할 경우 발생하는 성능 저하 현상을 살펴보고 이를 극복하기 위한 몇 가지 기법을 제시하고자 한다.
통상적으로 사용되는 ‘OLTP’의 의미는 대다수의 데이터베이스 관리자라면 어느 정도 파악하고 있으리라 믿는다. 하지만 이 기회에 이 둘 사이의 의미를 명확하게 짚고 넘어가는 것도 의미가 있을 것 같아 아래와 같이 정리해 보았다.
OLTP 질의 표 1에서 OLTP 시스템이 가지는 특성을 파악했다. 이런 특성 중에서 암호화와 가장 관련이 깊은 것으로 질의, 데이터 접근, 처리속도 등이 있다. 질의는 소수의 레코드를 반환하는 표준화되고 간단한 것, 데이터 접근은 인덱스를 통한 단일 접근 혹은 범위 스캔, 매우 빠른 처리 속도 등이 있다. 인덱스가 걸린 컬럼이 암호화될 경우 기존의 인덱스는 Drop되며 암호문을 사용하여 다시 생성되어야 한다. 또한 새롭게 생성된 인덱스를 사용하기 위해서는 질의문을 적절하게 변경해 주어야 한다. OLTP 질의의 Where 조건에 암호화된 컬럼이 사용될 경우 인덱스에 미치는 영향으로 인해 성능에 나쁜 영향이 나타나게 된다. 다음에서는 암호화된 컬럼이 Where 조건에 사용될 경우에 적절한 조치를 취하지 않음으로써 발생하는 성능 저하를 살펴보고자 한다.
국내에서 암호화 요구가 가장 많이 발생하는 부분은 아무래도 주민등록번호가 아닐까 한다. 또한 주민등록번호를 Where 조건에 추가하여 수행하는 OLTP 업무 질의도 상당히 많은 실정이다. 이번 절에서는 이러한 상황을 재현하기 위한 테이블을 정의하고 이 테이블의 주민등록번호 컬럼을 암호화한다. 이렇게 암호화된 테이블에서 암호화된 주민등록번호를 Where 조건에 주고 질의를 실행함으로써 암호화가 OLTP 질의 성능에 어떤 영향을 끼치는지 살펴보고자 한다.
암호화 인덱스 및 질의 재작성을 통한 성능 보전
이렇게 질의를 수정하여 개선된 실행 계획은 그림 6과 같다. 또한 수행 성능도 그림 7과 같이 암호화 이전으로 회복된 것을 확인할 수 있다.
투명성을 보장하는 성능 보전 우리는 앞선 단원에서 암호화된 컬럼에 인덱스를 생성하고 이를 사용하도록 질의를 수정함으로써 OLTP 질의의 성능을 보전할 수 있음을 알았다. 하지만 이 방법을 적용하기 위해서는 질의 수정이 필요하므로 이러한 질의를 사용하는 응용 프로그램 투명성이 심각하게 훼손될 수 있다. 이러한 질의가 다양하고 그 수가 많을 수록 암호화 적용에 많은 시간과 노력이 필요하게 되며 DB 관리자 및 개발자에게 거부감을 주게 되어 결국 실패할 확률이 높아지게 된다. 이번에는 앞서 살펴본 성능 보전 기법의 효과를 살리면서도 응용 프로그램의 투명성을 보장할 수 있는 방안에 대해서 살펴본다. ● 확장 인덱싱 Framework
다음 각 단계는 오라클 Optimzer에 의해 Domain Index가 선택되어 성능 향상을 가져오는 단계를 나타낸 것이다.
② 오라클의 Optimizer는 Operator에 대해 Select List에 사용될 때 Functional Evaluation과 Where 조건에 사용될 때 Domain Index Evaluation 등 두 가지 방향으로 해석함. ③ 이에 따라 Operator는 Domain Index Evaluation으로 동작하며 오라클은 Indextype에 구현된 ODCIIndexStart() 함수를 호출함. ④ ODCIIndexStart() 함수 구현 내에서 ‘암호 컬럼’ = 암호화 함수(‘암호값’) 형식으로 수정된 질의를 사용함. ⑤ ODCIIndexFetch() 함수에서 ‘암호 컬럼’ = 암호화 함수(‘암호값’) 형식의 인덱스 Fetch 루틴을 연속적으로 호출함. 다음은 Domain Index 동작을 위한 Indextype 구현의 일부이다. ● 확장 인덱싱 Framework 적용 결과 그림 8, 9는 확장 인덱싱을 적용한 후 원본 질의의 실행 계획을 나타낸 것이다. 확장 인덱싱 적용 후 수행 성능이 암호화 이전으로 회복된 것을 볼 수 있다. 각 운영 환경에 맞도록 적용해야 지금까지 OLTP 환경의 정의 및 응용 프로그램 특성을 간단히 정의하고 암호화를 적용함에 따라 응용 프로그램 투명성 훼손, 질의 성능 저하 등이 발생함을 살펴보았다. 나아가 암호화 이후의 질의 성능 보전을 위한 방법을 살펴보았고 확장 인덱싱 Framework를 사용하여 응용 프로그램 투명성까지 제공할 수 있는 기법을 제시해 보았다. 다양한 데이터베이스 및 응용 프로그램 환경으로 인하여 실제의 암호화 적용은 그리 쉬운 것이 아니다. 위에서 제시한 방법들 이외에도 각각의 운영 환경에 맞는 적용 방법을 관련된 모든 사람들이 머리를 맞대고 고민할 때 잘 보호된 데이터베이스 시스템이 탄생할 수 있을 것이다. <글 : 김상현 세이프넷 PSE(Professional Service Engineering) 팀장(sean,kim@safenet-inc.com)> [월간 정보보호21c 통권 제114호(info@boannews.com)] <저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지> |
|
 |
OLTP vs. OLAP
인덱스 컬럼의 암호화 및 OLTP 질의 성능
앞서 암호화를 적용한 이후에 현저히 저하되는 질의 성능을 확인한 바 있다(10ms -> 18.95s). 이번에는 암호화된 값을 사용하여 인덱스를 생성한 후 생성된 인덱스를 사용하도록 질의를 수정함으로써 성능저하를 방지하는 방법을 살펴보고자 한다. 이런 과정은 아래와 같은 두 개의 단계를 거쳐서 수행된다.
암호화 컬럼에 인덱스 생성 : ‘JUMINNUM_NEW’가 암호화된 컬럼이다.
오라클의 경우에는 기본적으로 제공되는 B-Tree 인덱스 이외에도 사용자가 인덱스의 동작을 재정의하여 사용할 수 있는 확장 인덱싱 Framework를 제공한다. 확장 인덱스 Framework는 세부 내용이 많아 여기에서 모든 내용을 다룰 수는 없지만 중요한 개념을 정리하면 Indextype은 응용 프로그램이 정의한 인덱스 동작 유형을 구현하고 Operator는 적절한 인덱스 유형을 선택하고 인덱스 검색을 수행, 그리고 Domain Index는 indextype의 인스턴스로서 특정한 열에 대해 정의되며 질의 실행 시 Optimizer에 의해 선택된다.
① 응용 프로그램 투명성 뷰에서 암호화가 적용된 컬럼을 Operator로 구성함.