본문 바로가기
  • (개인)정보보호/최신ICT 정보 공유 블로그
(부제) 나는 CISO 이다/ISMS-P 인증심사

(ISMS-P) DB 암호화 솔루션

by 노벰버맨 2021. 3. 27.

1. 개요

- 개인 정보의 유출 사고 등 악의적인 공격에 대응 필요

- DB 보안을 위해 법률 강화

- 외부 유협 외에도 내부자에 의한 유출 사고 방비

- DB 보안을 위한 요구사항은 DB암화, 암호키 관리

 

2. 암호화 요건

- 민감한 정보의 보안 레벨과 암호화 요구 사항 평가

- 요구사항에 따라 DBMS 자체 또는 외부 솔루션에 의한 암호화 수행

- 암호화, 복호화 키 관리

  랜덤키에 의해 암호화된 데이터는 복호화가 어려워짐

- 데이터의 중요성에 따라 암호화 알고리즘, 키 사이즈 선택

  어떤 데이터를 암호화할 것인가를 결정하고 데이터 사이즈 증감을 예측한다면 효율적인 암호화된 DB 완성 가능

- 인덱스 암호화 시 주의 필요

  대용량 DB에서 인덱스를 가진 컬럼이 암호화되면 인덱스를 활용할 수 없기 때문에 특정한 레코드 값을 찾기 위해 엄청난 부하 발생과 응답 시간의 저하 발생

 

3. 데이터 흐름 파악

- IT 인프라 내의 데이터가 어떻게 흐르고 어떻게 사용하는지 파악

- 애플리케이션 서버가 복호화된 데이터를 캐시에 임시 저장, 다른 연계 시스템으로 복호화된 평문 데이터 전송

- 애플리케이션 서버로 암호화된 데이터가 전송되고 전송받은 애플리케이션이 복호화

 

4. 암호키 관리

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

- 하나의 암호키로 암호화된 DB 내의 데이터는 암호화의 의미가 약해짐

- 업무의 범위나 시스템의 역할에 따라 암호키를 분리하고 이에 따른 암호키의 접근제어 정책이 수반되어야 함

- 암호키 관리의 불편함을 해소함과 동시에 소수의 암호키를 분리하여 적용하는 것이 보안강도를 높일 수 있는 좋은 방안

DBMS의 암호화의 기능을 사용하는 경우 가장 손쉬운 방법은 제한된 테이블(Table)이나 파일(File)에 저장

이 방법은 DB 관리자(DBA)가 접근 권한을 가진 경우가 대부분이며 임의의 복호화 작업이 가능

- DB 서버와 별개의 독립된 머신(HSM, Hardware Security Module)에 암호키를 관리하는 것이 바람직함

이 방법은 시스템 상의 접근 제어는 물론 강력한 인증과 파일 접근 제한 등의 강력한 보안조치를 통해 안전하게 관리

- 암호키는 접근제어를 통해 관리자나 임의의 사용자에 의한 암호키 유출 방지 가능

 

5. DB 암호화 구축 계획

가. DB 서버 내(DBMS)에서 수행

- 애플리케이션의 수정 최소화(투명성)

- 성능 저하에 따른 부담

- 암호키가 DB 내의 테이블에 존재

- DBMS가 제공하는 접근 제어에 의해서 보호

- 모니터링과 추적이 어려움

 

나. 별도의 머신에서 암호키가 관리

- DB 서버 외부에 암호화 엔진을 별도 장착하여 암호화 수행

- 어플리케이션의 수정에 따른 부담 증가

- DB 서버나 애플리케이션 서버의 부하 감소 가능

- DB와 암호키가 분리되는 강점

- 암복호화 서버의 강력한 접근 제어 정책으로 보안성 강화

- DB 관리자에 대한 권한 분리 기능과 데이터 열람의 제한 기능

- 다수의 DB/어플리케이션과 연계 가능

- 데이터 전송 시에 유출 가능성 감소

 

6. 암호화 범위

- 디스크 전체 암호화

- 컬럼 레벨 암호화

 

7. DB암호화 방식

 

8. 암호화 요구사항

 

9. 관련 벤더 및 제품

- 신시웨이(Petra Cipher)

- 펜타시큐리티(D'Amo)

- 케이사인(SecureDB)

- 보메트릭(Vormetric Transparent Encryption)

- 세이프넷(데이터시큐어)

- 소프트포럼(XecureDB)

- 웨어밸리(GALEA) 

- 모노커뮤니케이션즈(ECHELON)

댓글