해커에게 고객DB 털렸다면
데이터 암호화후 적절한 조치를 취하지 않을 경우 투명성 및 기능성을 확보하는데 어려움이 따를 수 있다. 적절한 조치를 취하지 않을 경우 발생하는 OLTP 업무 질의의 투명성 및 성능 저하를 살펴보고 이를 극복하기 위해 적용 가능한 방안을 논해 보고자 한다.
데이터베이스 관리자는 데이터가 암호화 된 이후에도 기존의 응용 프로그램을 수정하지 않기를 바라며(투명성), 또한 이러한 응용 프로그램의 성능이 저하되는 것을 원하지 않을 것이다(기능성). 하지만 간단한 데이터를 암호화 하더라도 암호화 값의 이진 속성에 따라 테이블의 정의까지 달라지는 경우가 발생하게 된다.
테이블의 암호화를 적용하고 난 이후에 발생하는 성능저하에 대해 많은 DBA들이 한번쯤 고민해 보았을 것이다. 데이터베이스에 암호화를 적용할 때 가장 먼저 거론되는 품질 요소는 성능 보존이라는 것이 많은 조사를 통해 알려진 바 있다. 이번에는 자주 사용되는 OLTP 업무 질의에 암호화를 적용할 경우 발생하는 성능 저하 현상을 살펴보고 이를 극복하기 위한 몇 가지 기법을 제시하고자 한다.
OLTP vs. OLAP
통상적으로 사용되는 ‘OLTP’의 의미는 대다수의 데이터베이스 관리자라면 어느 정도 파악하고 있으리라 믿는다. 하지만 이 기회에 이 둘 사이의 의미를 명확하게 짚고 넘어가는 것도 의미가 있을 것 같아 아래와 같이 정리해 보았다.
OLTP 질의
표 1에서 OLTP 시스템이 가지는 특성을 파악했다. 이런 특성 중에서 암호화와 가장 관련이 깊은 것으로 질의, 데이터 접근, 처리속도 등이 있다. 질의는 소수의 레코드를 반환하는 표준화되고 간단한 것, 데이터 접근은 인덱스를 통한 단일 접근 혹은 범위 스캔, 매우 빠른 처리 속도 등이 있다.
인덱스가 걸린 컬럼이 암호화될 경우 기존의 인덱스는 Drop되며 암호문을 사용하여 다시 생성되어야 한다. 또한 새롭게 생성된 인덱스를 사용하기 위해서는 질의문을 적절하게 변경해 주어야 한다.
OLTP 질의의 Where 조건에 암호화된 컬럼이 사용될 경우 인덱스에 미치는 영향으로 인해 성능에 나쁜 영향이 나타나게 된다. 다음에서는 암호화된 컬럼이 Where 조건에 사용될 경우에 적절한 조치를 취하지 않음으로써 발생하는 성능 저하를 살펴보고자 한다.
인덱스 컬럼의 암호화 및 OLTP 질의 성능
국내에서 암호화 요구가 가장 많이 발생하는 부분은 아무래도 주민등록번호가 아닐까 한다. 또한 주민등록번호를 Where 조건에 추가하여 수행하는 OLTP 업무 질의도 상당히 많은 실정이다.
이번 절에서는 이러한 상황을 재현하기 위한 테이블을 정의하고 이 테이블의 주민등록번호 컬럼을 암호화한다. 이렇게 암호화된 테이블에서 암호화된 주민등록번호를 Where 조건에 주고 질의를 실행함으로써 암호화가 OLTP 질의 성능에 어떤 영향을 끼치는지 살펴보고자 한다.
-
테이블 정의 : 주민등록번호를 포함한 테이블을 정의한다. 테이블에 10,000 건의 레코드를 추가하여 테스트를 진행했다. 또한 Where 조건에 사용되는 JUMINNUM 컬럼에 인덱스를 생성한다. 그림 1은 테이블에 포함된 레코드의 일부를 나타낸 것이다.
-
테스트 질의 : 실제 상황을 반영할 수 있도록 주민등록번호가 Where 조건에 포함된 테스트 질의를 사용한다. 아래는 주민등록번호 뒤 7 자리를 ‘x’로 치환하여 보여준 것이며 실행 시에는 실제 값으로 테스트한다.
-
질의 성능(암호화 미적용) : 그림 2에서 보는 바와 같이 주민등록번호가 인덱스되어 있으므로 빠른 시간 내에(10ms) 결과를 얻을 수 있다.
-
테이블 암호화 : 그림 2 테이블의 ‘JUMINNUM’ 컬럼을 AES 알고리즘을 사용하여 암호화한다. 이 때 주의할 점은 기존의 인덱스는 삭제된다는 것이다. 그림 3은 암호화된 테이블의 레코드 일부이다.
-
질의 성능(암호화 적용 후) : 암호화 적용 중 인덱스가 삭제됨에 따라 빠르게 수행되던 질의의 성능이 현저히 저하됨을 알 수 있다(18.95 초). 이는 Table Full Scan을 행함으로써 발생하는 것으로 만약 테이블의 레코드 수가 많다면 현실적으로 암호화를 적용하기 힘들 정도로 수행 성능이 저하될 수 있다.
암호화 인덱스 및 질의 재작성을 통한 성능 보전
앞서 암호화를 적용한 이후에 현저히 저하되는 질의 성능을 확인한 바 있다(10ms -> 18.95s). 이번에는 암호화된 값을 사용하여 인덱스를 생성한 후 생성된 인덱스를 사용하도록 질의를 수정함으로써 성능저하를 방지하는 방법을 살펴보고자 한다. 이런 과정은 아래와 같은 두 개의 단계를 거쳐서 수행된다.
-
암호화 컬럼에 인덱스 생성 : ‘JUMINNUM_NEW’가 암호화된 컬럼이다. -
암호화된 컬럼 인덱스를 사용하도록 질의 재작성 : 암호화된 컬럼에 인덱스를 생성하였으므로 인덱스를 사용할 수 있도록 ‘암호 컬럼’ = 암호화 함수(‘암호값’) 형식으로 질의를 수정함. Select List에는 복호화 함수를 사용하여 암호 값을 복호화 낸 후 결과를 반환하도록 수정. Where 조건과 Select List에 쓰인 암호화/복호화 함수는 제품들마다 독자적인 형식을 지니고 있다. 다음은 암호화 전과 동일한 결과를 표시하는 수정된 질의다.
이렇게 질의를 수정하여 개선된 실행 계획은 그림 6과 같다. 또한 수행 성능도 그림 7과 같이 암호화 이전으로 회복된 것을 확인할 수 있다.
투명성을 보장하는 성능 보전
우리는 앞선 단원에서 암호화된 컬럼에 인덱스를 생성하고 이를 사용하도록 질의를 수정함으로써 OLTP 질의의 성능을 보전할 수 있음을 알았다.
하지만 이 방법을 적용하기 위해서는 질의 수정이 필요하므로 이러한 질의를 사용하는 응용 프로그램 투명성이 심각하게 훼손될 수 있다. 이러한 질의가 다양하고 그 수가 많을 수록 암호화 적용에 많은 시간과 노력이 필요하게 되며 DB 관리자 및 개발자에게 거부감을 주게 되어 결국 실패할 확률이 높아지게 된다.
이번에는 앞서 살펴본 성능 보전 기법의 효과를 살리면서도 응용 프로그램의 투명성을 보장할 수 있는 방안에 대해서 살펴본다.
● 확장 인덱싱 Framework
오라클의 경우에는 기본적으로 제공되는 B-Tree 인덱스 이외에도 사용자가 인덱스의 동작을 재정의하여 사용할 수 있는 확장 인덱싱 Framework를 제공한다. 확장 인덱스 Framework는 세부 내용이 많아 여기에서 모든 내용을 다룰 수는 없지만 중요한 개념을 정리하면 Indextype은 응용 프로그램이 정의한 인덱스 동작 유형을 구현하고 Operator는 적절한 인덱스 유형을 선택하고 인덱스 검색을 수행, 그리고 Domain Index는 indextype의 인스턴스로서 특정한 열에 대해 정의되며 질의 실행 시 Optimizer에 의해 선택된다.
다음 각 단계는 오라클 Optimzer에 의해 Domain Index가 선택되어 성능 향상을 가져오는 단계를 나타낸 것이다.
① 응용 프로그램 투명성 뷰에서 암호화가 적용된 컬럼을 Operator로 구성함.
② 오라클의 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) 무단전재-재배포금지>
[2024-05-18] 
.jpg)
.jpg)
