이번 chpater에서는 관계형 데이터베이스(RDB)에 쓰이는 Encryption에 대해 알아보자. 당연한 얘기지만 DB에 저장된 데이터를 보호하기 위해 데이터베이스를 암호화하려 한다. DB를 암호화하려면 언제나 운영자(관리자)는 권한이 없는 자에게 데이터를 노출해서는 안되는 안정성 문제와 빠른 시간내에 데이터를 가져다 쓸 수 있어야하는 가용성 문제를 고려해야한다.
데이터베이스 암호화 알고리즘
인덱스와 암호화
인덱스를 사용하는 칼럼을 암호화하는 방법을 알아보자.
기존의 데이터베이스에 새로운 열을 추가할수 있는데 DB는 그열에 입력될 값의 데이터 속성과 크기를 정의한다. 그런데 만약 추가한 열이 검색조건으로 자주 사용된다면 검색 성능을 높이기 위해 index(색인)을 생성하도록 설정한다. 실제로 데이터를 새로 입력하면 DBMS는 자동으로 index를 생성한다.
index는 DBMS에 들어있는 수많은 data의 순서 정보로 데이터마다 붙여 놓은 꼬리표라고도 할 수 있다.
위사진과 같이 TABLE에 자주쓰이는 3번째 열으로 index생성하여서 데이터를 효과적으로 찾을수 있다. 주의할것은 index은 위 사진에서도 보이듯이 순서대로 나타난다.
하지만 인덱스를 암호화하게되면 데이터 순서가 섞이게 될것이다. 그러면 효율적인 인덱스의 강점도 잃어버리게된다. 이제 밑에 나올 해결방법을 읽어보기 전에 각자 어떻게 해야할지 생각해보자.....
그래서 고심끝에 생각한 것이 암호화된 데이터를 기준으로 검색이 가능한 새로운 인덱스를 생성하는 것이다. 그래서 암호화된 데이터에도 인덱스를 만들면 데이터를 찾을때 인덱스를 복호화해야 할 데이터를 지정하거나 그 양을 줄일수 있게 하였다.
수많은 방식(해시 인덱스 , B 트리 인덱스)으로 발전해온 결과 암호화된 데이터를 검색하는 인덱스 방식을 조금 다르게 접근하는 방식을 가진 OPE(Order Preserving Encryption)가 나타났다.
OPE
OPE는 말 그대로 데이터의 정렬 순서를 유지하면서 암호화를 수행한다. 원래 원문을 암호화하면 원문을 알아볼 수 없게되서 순서 정보를 잃게 된다. 하지만 OPE Encryption은 암호화해도 원문은 알아볼 수 없게하면서 순서정보를 잃지 않게 한다.
위 사진이 OPE 암호화를 한 모습이다. 원문의 값 순서와 암호화된 값의 순서가 같은것을 볼수 있다. 이 알고리즘은 암호화된 값이 원문의 값 순서와 같은것을 보면 원본 데이터를 유추할 수 있다는 안정성 문제가 생긴다. 그래서 이를 피하려면 위의 그래프에서 최대한 암호문 사이의 간격을 들쑥날쑥하게 해야한다.
또 다른 문제점으로 123의 암호문 A와 456의 암호문 C를 안다면 A와 C암호문 사이에 올수 있는 암호문 B는 123~456사이의 어떤 값으로 만든 암호문이라는 것을 알수 있다. 그렇다면 공격자는 CPA공격이 가능하게 된다.
그래서 OPE는 검색 성능에 좋은 보안성 기준에서는 절대 안전한 암호화 방식이라고는 할 수없다. OPE는 인덱스가 설정된 컬럼을 암호화하는 특별한 케이스에 대한 암호화라는 것을 잊지 말자.
일반적 데이터베이스 암호화
DB는 DBMS와 Storage로 나뉘고 Storage는 정보를 기록하는 물리적 저장공간이고 DBMS는 저장소에서 데이터를 읽고 쓰는 동작을 수행하고 사용자의 권한을 관리하는 프로그램이다. 외부 애플리케이션은 DBMS에 정보 처리를 요청하고 저장소에 저장된 데이터를 사용하게 된다. 그리고 데이터베이스를 활용하는 모든 시스템은 데이터베이스를 이용하는 외부 애플리케이션이 있다.
이런 구조에서 데이터베이스 암호화는 암호화와 키 관리 위치에 따라 네가지 방식으로 구분한다.
- API(Application Programming Interface) 방식
- 플러그인(Plug-in) 방식
- 하이브리드(Hybrid) 방식
- TDE(Transparent Data Encryption) 방식
API 방식
Application 서버에 암호화 모듈을 설치하는 것으로 애플리케이션 수정이 필요하다. 즉 , 애플리케이션에서 데이터를 암호화해서 DB에 넣는 구조이다. 애플리케이션이 수정이 가능할때 적용시 효과적인 방법이다. 이렇게 되면 DB정보도 보호할뿐만 아니라 애플리케이션 기능까지 보호하게 되기때문이다. 또한 DB 종류에 제약없이 적용가능하고 DB에 부하도 주지않는다.
하지만 암호화 대상 데이터와 관련이 있는 Application 모든 부분을 수정해야하므로 비용과 시간이 많이 든다는 단점이 있다. 또 다른 단점으로는 애플리케이션에서 암호화한 데이터가 데이터베이스에 들어가면 DB의 기존 성능에 문제를 줄 수도있다.
Plug-in 방식
DBMS에 암호화를 수행하는 모듈을 설치하는 것으로 DBMS 패키지 방식이라고도 한다. 이 방식의 장점은 데이터를 column단위로 암호화할 수 있어 데이터에 세부적으로 암호화를 적용하고 관리한다. 개인정보 등 중요한 정보를 선별해서 암호화하거나 권한 관리할때 효과적인 방법이다.
단점은 암.복호화를 할때 DBMS에 있는 자원을 사용한다는 것이다. 따라서 플러그인 방식을 적용할때에는 DBMS의 성능이 뛰어나야한다.
Hybrid 방식
Plug-in 방식과 API 방식을 적절히 섞어서 쓰는 방식이다. DB와 Application의 활용 정도에 따라 어느 부분에서 어떤 암호화 방식을 사용할지 결정한다. 잘만 한다면 두가지 방식의 장점을 모두 살릴 수 있다.
하지만 구조적으로 복잡하고 키 관리의 복잡성도 증가하게 된다.
TDE 방식
DBMS가 제공하는 암호화 기능을 이용한다. DB내부에서 DBMS가 저장소에 저장된 데이터를 통째로 암호화한다고 이해하면 된다. 그래서 Plug-in방식처럼 column단위로 세분화해서 관리하지 못하는 한계점을 가진다.
TDE방식을 제외한 앞의 3가지 방식은 데이터를 보호하는 것에 중점을 둔다면 TDE는 저장소가 물리적으로 도난당했을 때 데이터를 보호하는 수단에 가깝다. TDE는 DBMS 동작의 바탕이 되는 엔진 수준에서 암호화하므로 애플리케이션을 수정할 필요가 없다.
이 네가지 방식 외에 파일 단위로 암호화를 수행하는 방식도 있다. 이 방식은 OS의 개체인 파일을 통채로 암호화하는 것으로 DB와 OS 의존도가 높다.
DB 암호화 주의사항
0 개의 댓글:
댓글 쓰기