DB 암호화

출처 - http://nakyungpapa.tistory.com/74

 

[출처 : 보안뉴스]

 

1. 기업의 존속과 직결되는 DB의 암호화 필요성

 

- 데이터 자산가치의 증가

- 내부자에 의한 정보 유출 및 보안 사고 급증

- 피해규모, 확산속도 가속 및 막대한 사회적 비용 발생

- 개인정보 유출에 대한 불안감 고조 및 신뢰성 저하

- 어플리케이션 구축 및 운영시의 보안 허점

 

2. DB 암호화의 법적 기준

 

구분	소관	내용
정보통신망법	방통위	시행령 제15조 (개인정보의 보호조치) - 주민등록번호 및 계좌번호 등 금융정보의 암호화 저장
개인정보보호법	행안부	개인정보의 안정성 확보 조치 기술 고시 제7조 - 외부망 저장시 개인정보 모두 암호화 - 내부망 저장시 공공기관은 영향평가 결과를 통해, 그 외 기업들은 위험도 분석 결과에 따라 시행

 

3. DB 암호화 방식과 장단점 비교

 

1) DB 암호화 방식

구분	암호화 기술	내용
컬럼단위	Plug - in 방식	- 암/복호화 모듈이 DBMS 안에서 실행 - 원래의 테이블과 동일한 이름의 뷰가 생성 - 실제 테이블을 변경하기 위해 instead of trigger 생성 - ORACLE, MS-SQL, DB2 사용하는 환경에 적합
	API 방식	- 암/복호화 모듈이 어플리케이션에서 실행 - 저장/변경 시 암호화하고, 조회 시 복호화하는 API 함수 호출 - 뷰나 트리거 등이 생성되지 않음
블럭단위	TDE	- DB 커널에서 암호화된 테이블 스페이스를 생성하고, 암호화 대상 테이블을 해당 테이블 스페이스로 이동 - DBMS 커널에서 DB의 블록 단위로 자동으로 암/복호화 수행 - HSM(Hard Security Machine) 어플라이언스와 연동하여 키 관리
	File 암호화	- 암호화 파일을 사용하여 테이블 스페이스를 생성하고, 암호화 대상 테이블을 해당 테이블 스페이스로 이동 - OS 커널에서 DB 의 블록 단위로 자동으로 암/복호화 수행 - HSM(Hard Security Machine) 어플라이언스와 연동하여 키 관리

 

2) DB 암호화 방식 장단점 비교

 

암호화 기술	장점	단점	보안인증
Plug-in	- 기존 소스 변경 최소화 - 기존의 쿼리 변경 없음 - 구축에 소요되는 기간 짧음 - 최소비용	- DBMS 서버에 부하 - 암호화 대상 컬럼 증가시 추가 암 호화 작업 필요 - SQL 튜닝 필요 - 별도 인덱스 기능 필요 - 일부 어플리케이션 변경 필요	국정원 인증 (CC, 암호모듈 검증제품)
API	- DB 서버에 부하가 없음 - 속도 빠름	- 다수의 프로그램 수정 - 장기간 소요 - 프로그램 수정, 테스트를 위한 비용이 크게 발생 - 별도의 인덱스 기능 필요 - 대량의 데이터 암/복호화 수행시 Network Jam, 암복호화 성능 저하
TDE	- 어플리케이션 변경 없음 - 성능 우수 - 모든 데이터 타입 지원 - DBMS 자체 인덱스 모두 사용 가능	- DB 에 직접 접속 시, 보안성 떨어짐 - oracle 11g 업그레이드 필요	국정원 인증 제품 없음
File 암호화		- DB 에 직접 접속 시, 보안성 떨어짐 - 일부 OS, Volume Manager 의 경우 지원 불가

 

4. DB 암호화 방안 선택 기준 및 보완 방안

 

1) DB 암호화 방안

 

- 금융회사 차세대 개발 계획중/개발중 -> API 방식

- 이미 구축되어 운영중인 시스템 -> Plug-In 방식

- Plug-In 방식이 불가능하다면 -> TDE, File 암호화 방식

 

2) DB 암호화 보완 방안

 

- Gateway 방식의 접근제어 솔루션 사용 시 개별 접속 컴퓨터의 IP 식별이 가능해야함

- 블럭단위 암호화 방식의 경우 암호화 컬럼을 마스킹으로 보호

 

[참고 문헌]

- 코스콤 Security Story