데이터베이스 암호화 편집하기

'''데이터베이스 암호화'''(database encryption) 또는 간략히 '''DB 암호화'''란 [[데이터베이스]]의 내용을 [[암호화]]하는 것을 말한다. 주민등록번호, 신용카드번호 등 민감한 [[개인정보]]를 데이터베이스에 저장한 경우, [[해킹]] 등으로 유출될 것에 대비하여 DB 내용을 암호화하는 것이 필요하다. 구현 방식에 따라 여러 가지가 있고, 각각의 [[데이터]] 처리 메커니즘이 다르다.

==개요==
데이터의 자산 가치가 증가하고, 내부자에 의한 정보 유출 및 보안 사고가 급증하며, 개인정보 유출에 대한 불안감이 고조되거나 신뢰성이 저하되는 등 여러 가지의 이유로 데이터베이스 암호화의 필요성은 날이 갈수록 높아지고 있다. 게다가 개인정보 보호법이 제정되면서 고객의 개인정보를 소홀히 관리하거나, 암호화하지 않은 고객정보가 외부로 유출될 경우 대규모 집단 소송 및 경영진의 형사 처벌 등 강력한 처벌을 요구하기 때문에 데이터베이스 암호화는 이제 거의 필수적인 요소가 되었다. 국가 정보원 [[IT]] 보안 인증 사무국은 데이터베이스 암호화 제품 구축에 있어 안정성이 검증된 암호 [[모듈]] 및 [[알고리즘]]의 사용, 암호화 키 생성, 접근, 갱신, 폐기 등의 안정성 확보, 암호문, [[인덱스]] 등 중요 데이터의 안정성 확보, 암호 키, 암호문 등에 대한 비인가자의 접근 통제, 전송 데이터의 기밀성, [[무결성]] 유지, 제품 사용자의 신원 확인 및 검증, 제품 관련 중요 [[이벤트]]에 대한 감사 기록 [[시스템]] 구축 등을 권고하고 있다. 전문가들은 데이터베이스 암호화 구축 시 핵심 고려사항으로 암호화 대상 및 범위를 위험도 분석 결과에 따라 철저하게 분석, 국내외 연구기관에서 검증된 암호화 알고리즘의 적용, 개인 정보는 양방향 개인정보 필수 적용, 암호화 인덱스 지원, 성능을 고려해 부분 암호화 적용, 암호화, [[복호화]] 키, 마스터 키 등 모든 키를 생성에서 폐기까지 안전하게 관리해야 한다고 조언했다.<ref>신동규 기자, 〈[http://www.dt.co.kr/contents.htm?article_no=2012112902011860785002 (알아봅시다) 다양한 DB 암호화 방식의 장단점]〉, 《디지털타임스》, 2012-11-28</ref>

데이터베이스 암호화는 데이터를 암호화하여 저장하고, 권한이 있는 사람 혹은 [[서버]]만이 해당 데이터를 복호화할 수 있도록 하여 데이터를 보호하는 기술이다. 암호화를 사용하면 [[해커]]가 데이터베이스를 [[해킹]]해서 데이터를 들고 나가더라도, 암호화된 데이터를 읽을 수 없다. 암호화 방식과 암호화 알고리즘 등에 관한 결정은 업무 목적이나 데이터 중요도 등에 따라 달라질 수 있지만, 관련 기관에서 기본 규약으로 정의하여 권고 또는 강제하는 사항에 대한 확인 및 적용해야 한다. 암호화를 구축한 이후에는 암호화키에 대한 관리 및 복호화 권한 소유자, 복호화 관련 로깅 정보 확인 등을 통해 암호화에 대한 통제가 적절하게 이루어지고 있는지, 보완하거나 개선할 사항은 없는지 등에 대한 지속적인 모니터링이 필요하다. 데이터베이스 접근 제어 외에 데이터베이스 [[보안]]에 관한 국내외 법률과 규정은 2가지를 주요하게 강조하는데 첫 번째는 암호화를 통한 데이터베이스 보안이고, 두 번째는 엄격한 암호키 관리를 통해 데이터를 보호하라는 것이다. 데이터베이스 암호화의 목적은 비정상적 데이터 유출이 발생할 경우, 복호화를 어렵게 만드는 것이다. 암호키는 암호화 뿐만 아니라 복호화할 때도 사용하므로 매우 신중하게 관리하여야 한다. 랜덤 키에 의해 암호화된 데이터는 해커들이 복호화를 하기 어렵게 만든다. 따라서 복호화를 해야만 하는 사용자나 시스템 이외에 다른 사용자가 암호키에 접근하는 것을 통제해야 한다.<ref>euishin0110, 〈[https://m.blog.naver.com/PostView.nhn?blogId=euishin0110&logNo=220741868061&proxyReferer=https:%2F%2Fwww.google.com%2F DB 보안 (DB 암호화)]〉, 《네이버 블로그》, 2016-06-21</ref>

==특징==
데이터베이스 암호화의 보안성은 강화된 국정원 보안 적합성 검증 기준을 만족하여야 한다. 데이터베이스 보안 솔루션의 주목적은 중요한 정보를 안전한 알고리즘으로 암호화하고, 이 데이터를 암호화 또는 복호화 할 수 있는 키를 기준에 맞도록 안전한 관리체계를 제공하는 것이다. 따라서 개정된 보안 적합성 검증 기준에서 요구하는 “암호 모듈 검증 기준”을 만족하여야 한다. 또한, 데이터베이스 운영을 불가능하게 할 정도의 제약사항이나 성능 저하는 최소한으로 해야 한다. 데이터베이스가 운영되지 못한다면 데이터베이스 암호화는 있으나 마나 한 것이기 때문이다. 이 외에도 데이터베이스 암호화는 안전한 알고리즘으로 최고의 보안성을 보장하는 안전한 알고리즘, 인덱스를 암호화하고 암호화된 인덱스를 통한 색인검색을 지원하는 인덱스  암호화 및 검색, 장시간 소요되는 데이터베이스 암호화 작업으로 인한 서비스의 중단이 없거나 최소로 하는 가용성 등 여러 가지 요소들을 필요로 한다.<ref>날으는 물고기, 〈[https://blog.pages.kr/618 DB 암호화, 그 특성 및 구축 방법]〉, 《블로그》, 2010-02-02</ref>

==분류==
데이터베이스의 데이터를 암호화할 수 있는 방식은 일반적으로 컬럼 암호화 방식과 블록 암호화 방식으로 나눌 수 있다. 칼럼 암호화 방식은 암·복호화 위치에 따라 플러그인, API 및 혼합 방식인 하이브리드 등의 방식이 있고 블록 암호화 방식은 TDE, 파일 암호화 방식이 있다.

===플러그인 방식===
[[파일:DB암호화 플러그인.JPG|썸네일|525픽셀|'''플러그인 방식의 구성 예''']]

암호화 관련된 보안정책 데이터베이스와 암호화 및 복호화 처리를 위한 서버 엔진을 데이터베이스 관리 시스템에 플러그인시킨 방식으로, 필터 방식이라고도 한다. 데이터베이스 레벨의 확장성 프로시져 기능을 이용하여 데이터베이스 관리 시스템에 플러그인 모듈로 동작한다. 구축이 용이하고, 애플리케이션으로부터 독립성을 제공한다. 모든 작업이 그래픽유저인터페이스(GUI) 기반으로 이루어져 관리 편의성이 높고, 암호화 컬럼에 대한 일치검색, 범위 검색 인덱스 지원이 용이하다는 장점이 있다. 대표적인 단점은 암·복호화 시 데이터베이스 서버의 CPU를 사용하기 때문에 성능 이슈가 발생했을 때 쿼리 수정이 필요하고, 데이터베이스 서버에 직접적인 부하가 걸려 성능을 고려할 필요가 있다는 것이다. 그러므로 트랜잭션 처리량이 많지 않아 성능에 대한 민감성이 낮은 시스템의 경우 저렴한 비용으로 구축할 수 있다. 애플리케이션 서버에서 DB계정이 탈취될 경우 복호화된 평문 데이터 유출이 가능하므로 이에 대한 보안 조치가 필요하며, 암호화 컬럼 사이즈 증가, 성능 이슈 등이 있는 경우 일부 애플리케이션을 수정하여 적용이 가능하다. 플러그인 방식의 구성에서 데이터베이스 테이블 또는 컬럼 단위의 암호화를 적용하면 암호화된 테이블 이용을 위하여 추가적인 오브젝트들이 생성되므로, 운영 및 백업 등 데이터베이스에 관련된 작업을 수행할 때 이러한 오브젝트들을 함께 고려하여야 한다.
:{|class=wikitable width=700
|+플러그인 방식의 기능
!align=center|항목
!align=center|내용
|-
|align=center|암호 알고리즘
|align=center|SHA-256·384·512 및 키 길이 128 비트 이상의<br>AES, TDES, SEED, ARIA 등 지원
|-
|align=center|암·복호화 위치
|align=center|DB 서버
|-
|align=center|DB 서버의 부하
|align=center|높음
|-
|align=center|색인 검색
|align=center|가능, 별도 인덱스 기능 필요
|-
|align=center|배치 처리
|align=center|가능
|-
|align=center|애플리케이션
|align=center|수정 없이 적용할 수 있는 구조이나 암호화 칼럼 사이즈 증가<br>성능 이슈 등이 있는 경우 일부 수정 필요
|-
|align=center|접근통제
|align=center|DB에 접속하는 DB 클라이언트에서 사용자 식별 가능
|}
기존 테이블과 동일한 이름의 뷰가 생성되는 뷰어 방식과, 복호화 뷰에 [[DML]] 요청이 들어오면 평문 데이터를 암호화하여 암호화 테이블에 DML 처리하는 역할을 하는 트리거 방식이 있다. 이미 구축되어 운영 중인 시스템에 사용하는 것이 좋다.

; 뷰
플러그인 방식의 구성에서 테이블/컬럼을 암호화하게 되면 기존 테이블 이름과 동일한 뷰와 변경된 이름의 암호화된 테이블이 생성되고, 암호화 전 원본 테이블은 삭제하게 된다. 암호화 후 생성된 뷰는 암호화된 데이터를 복호화하여 보여주는 통로 역할을 한다. 뷰 이름을 암호화하기 전의 테이블 이름과 같게 생성함으로써 원본 테이블을 사용하던 기존 애플리케이션의 쿼리를 수정 없이 또는 수정을 최소화하여 사용이 가능하도록 하며, 권한이 있는 사용자가 복호화된 데이터를 간편하게 사용할 수 있도록 만들어준다. 또한 DMIL을 사용하는 사용자의 유형을 체크하여 쿼리를 제한하는 등의 기능을 수행할 수 있다.

; 트리거
트리거의 역할은 복호화 뷰에 DML 요청이 들어오는 경우 평문 데이터를 암호화시켜 암호화 테이블에 DML 처리를 하는 역할을 한다. 뷰에 암호화 트리거를 연결시켜줌으로써 기존 애플리케이션 및 사용자의 DML 쿼리를 수정 없이 또는 최소화하여 사용할 수 있도록 한다.

===API 방식===
[[파일:API 방식의 구성 예.JPG|썸네일|526픽셀|'''API 방식의 구성 예''']]

API 방식은 암·복호화 모듈을 애플리케이션 서버 내에 설치하고 이곳에서 암·복호화를 수행하는 구조로 애플리케이션의 수정을 동반한다. 따라서 API 방식의 DB 암호화 기술 도입은 기존에 운영 중인 시스템에 적용하기보다 차세대 시스템 개발 등 기존 애플리케이션에 대한 전면적인 수정이 가능한 경우 적용하면 효과적이다. API 방식의 구성에서는 DB시스템의 영향도가 낮고 DBMS의 부하를 분산하는 효과가 있으며, 애플리케이션 서버에서 DB계정이 탈취되더라도 데이터가 암호화되어 있기 때문에 유출 위험이 적다. 또한 데이터베이스 서버의 성능 저하 없이 구축이 가능하고, 구축 비용이 상대적으로 저렴하다는 장점이 있다. 반면 각각의 애플리케이션 서버에서 암·복호화 처리를 수행하므로 중앙화된 접근 통제가 어려워 데이터베이스 내부에서 수행되는 연산 처리 과정에서 암호화한 데이터 처리가 불가능하다는 단점이 있다. 또한 암호화 대상 데이터와 관련된 모든 소스 영역의 수정이 필요하며 내부에서 업무 처리가 필요한 경우 별도의 데이터베이스 관리 시스템 API 모듈이 필요하다. 게다가 향후에 응용 시스템의 신규/ 변경 등에 따라 관리 효율성이 저하되고, 접근제어 솔루션을 추가 도입하게 되면 비용이 발생한다. 플러그인방식에 비해 암·복호화 속도가 빨라 대용량 온라인 트랜잭션 서비스 등에 적용 가능하나, 애플리케이션 수정으로 인해 소요되는 인력 및 시간은 API 방식이 가장 많이 소요된다.
:{|class=wikitable width=700
|+API 방식의 기능
!align=center|항목
!align=center|내용
|-
|align=center|암호 알고리즘
|align=center|SHA-256/384/512 및 키 길이 128 비트 이상의<br>AES, TDES, SEED, ARIA 등 지원
|-
|align=center|암·복호화 위치
|align=center|애플리케이션 서버(DB 서버가 어플리케이션 기능을<br>수행할 경우 DB 서버에서 암‧복호화 가능)
|-
|align=center|DB 서버의 부하
|align=center|낮음(애플리케이션 서버에 부하 발생)
|-
|align=center|색인 검색
|align=center|일치검색 가능, 부분일치검색 불가(부분 암호화 시 가능)
|-
|align=center|배치 처리
|align=center|가능
|-
|align=center|애플리케이션
|align=center|애플리케이션의 소스(암호화 테이블과 관련된 부분)를 수정해야 함
|-
|align=center|접근통제
|align=center|암복호화 작업이 어플리케이션 서버 상에서 수행되기 때문에<br>DB 접속정보를 통한 사용자 식별은 불가,<br>애플리케이션 서버에 접속하는 서비스 접속자만 식별 가능
|}

===하이브리드 방식===
[[파일:하이브리드 방식의 구성 예.JPG|썸네일|520픽셀|'''하이브리드 방식의 구성 예''']]

하이브리드 방식은 API 방식과 플러그인 방식이 합쳐진 것으로 플러그인 방식의 성능 저하 이슈 개선을 위해 API 방식의 장점을 채용한 것이다. 메시지는 대칭 키로 암호화하고, 대칭 키 암호는 암호화에서 사용한 세션 키는 의사난수생성기로 생성한 뒤, 세션 키는 공개키 암호로 암호화하는 방식이다.<ref>사용자 제나나, 〈[https://jennana.tistory.com/54 (암호시스템)하이브리도 암호]〉, 《티스토리》, 2020-09-15</ref> 플러그인 방식의 단점인 배치 업무의 성능 저하를 보완하기 위해 API 방식을 이용하는 구성으로서, 성능이 우선시 되는 환경에서는 API를 적용하고, 성능 영향이 덜 민감한 환경에서는 플러그인 방식을 적용하는 식으로 유동성 있게 구축한다. 어떤 애플리케이션에 API 방식을 적용할 것인지에 대한 분석은 기존 시스템에서 수행되는 SQL정보를 수집 및 분석하는 방법을 활용할 수 있다. 특정 기간 동안 암호화 대상 DBMS에서 수행된 모든 SQL 정보를 수집한 후, 각 SQL별로 사용한 테이블/컬럼, DB 암호화 적용 시 영향을 받는 SQL 사용 빈도, [[CPU]], [[메모리]], [[스토리지]] 등의 영향도를 파악하여 SQL을 사용하는 프로그램에 대해 API방식을 적용하면 적용대상을 최소화하면서 효과를 높일 수 있다. 두 방식의 장점을 모아놓은 것이기 때문에 속도와 성능 개선의 일석이조 효과를 볼 수 있지만, 구축 투자 비용이 상대적으로 높다는 단점이 있다.
:{|class=wikitable width=700
|+하이브리드 방식의 기능
!align=center|항목
!align=center|내용
|-
|align=center|암호 알고리즘
|align=center|SHA-256/384/512 및 키 길이 128 비트 이상의<br>AES, TDES, SEED, ARIA 등 지원
|-
|align=center|암·복호화 위치
|align=center|애플리케이션 서버 및 DB 서버
|-
|align=center|DB 서버의 부하
|align=center|보통
|-
|align=center|색인 검색
|align=center|가능
|-
|align=center|배치 처리
|align=center|가능<br>(플러그인 방식에 비해 API방식이 대량 데이터 처리에 용이하여 API방식 활용)
|-
|align=center|애플리케이션
|align=center|API를 적용하는 부분은 소스 수정 필요
|}

===TDE 방식===
[[파일:TDE 방식의 구성 예.JPG|썸네일|524픽셀|'''TDE 방식의 구성 예''']]

암호를 풀 수 있는 암호화 키를 데이터베이스 서버에 파일 형태로 두는 방식으로, 데이터베이스 관리 시스템의 암호화 기능을 이용하여 데이터 파일을 저장할 때 암호화하고, 파일에 저장된 내용을 메모리로 가져올 때 복호화한다. DBMS 종류 및 버전에 따라 기능 지원 여부가 다르다. DBMS 커널 레벨에서 처리되므로 애플리케이션에 대한 수정이 없고 인덱스의 경우 DBMS 자체 인덱스 기능과 연동이 가능하다. 암호화 파일을 사용하여 테이블 스페이스를 생성하고, 암호화 대상 테이블을 해당 테이블 스페이스로 이동시키는 방식이고, 운영체제 커널에서 데이터베이스 블록 단위로 자동으로 암호화와 복호화를 수행한다.<ref>i kiss you, 〈[https://nakyungpapa.tistory.com/74 DB 암호화]〉, 《티스토리》, 2012-09-06</ref> 암호화로 인해 기존 시스템에 미치는 영향이 적고 속도가 빠르며 애플리케이션을 수정하지 않아도 된다는 장점이 있지만, CPU 부하가 많이 걸리고, 키 관리가 어려워 데이터베이스 서버 해킹 시 키가 유출될 수 있다는 단점이 있다.<ref>열린 기술자, 〈[https://sarc.io/index.php/oracledatabase/616-2016-09-21-16-28-36 데이터베이스 암호화 기초]〉, 《삵》, 2017-10-23</ref> DBMS에 로그인한 사용자 중 암호화된 데이터에 접근 권한이 있는 모든 사용자에게 암호화된 정보가 복호화되어 조회되므로, 이에 대한 보완책으로 실시간 마스킹 기능 등을 함께 고려하여야 한다.
:{|class=wikitable width=700
|+TDE 방식의 기능
!align=center|항목
!align=center|내용
|-
|align=center|암호 알고리즘
|align=center|SHA-256/384/512 및 키 길이 128 비트 이상의<br>AES, TDES 등 지원
|-
|align=center|암·복호화 위치
|align=center|DB 서버
|-
|align=center|DB 서버의 부하
|align=center|낮음
|-
|align=center|색인 검색
|align=center|가능(DBMS 연동)
|-
|align=center|배치 처리
|align=center|가능
|-
|align=center|애플리케이션
|align=center|수정 없음
|-
|align=center|접근통제
|align=center|DB 자체 ACL에 의해 DB계정만 통제하여 접근권한이<br>있는 DB사용자들은 복호화된 데이터 열람 가능
|}

===파일 암호화 방식===
[[파일:파일 암호화 방식.JPG|썸네일|522픽셀|'''파일 암호화 방식의 구성 예''']]

운영체제 영역의 파일 전체에 암호화, 복호화를 적용하는 방식이다. 운영체제에 대한 의존도가 높으나, 파일에 대해 직접적으로 암호화를 수행하므로 데이터베이스의 데이터 파일뿐 아니라 로그파일, 이미지파일, 음성/영상 등의 비정형 데이터에 대한 암호화 적용이 가능하다. 이 방식으로 구성하면 애플리케이션의 수정이 없고, 인덱스의 경우 DBMS 자체 인덱스 기능을 사용할 수 있으며, 거의 모든 DBMS에 적용이 가능하다. 또한 애플리케이션 환경에서 완벽한 독립성을 제공한다는 장점이 있기는 하지만, 하드웨어나 운영체제 자체에서 발생하는 오류로 인해 서비스 장애가 발생할 수 있다.<ref>따, 〈[https://m.blog.naver.com/PostView.nhn?blogId=futureds&logNo=90158653671&proxyReferer=https:%2F%2Fwww.google.com%2F 다양한 DB 암호화 방식의 장단점]〉, 《네이버 블로그》, 2012-12-10</ref> 또한 TDE 방식과 마찬가지로 DBMS에 로그인한 모든 사용자에게 암호화된 정보가 복호화되어 조회되므로 마스킹 기능 도입 등 이를 보완하는 방안도 함께 고려하여야 하며, 파일 시스템을 사용하지 않는 데이터베이스에서는 사용할 수 없기 때문에 운영체제 지원 가능 여부를 확인해야 할  필요가 있다는 단점이 있다.
:{|class=wikitable width=700
|+파일 암호화 방식의 기능
!align=center|항목
!align=center|내용
|-
|align=center|암호 알고리즘
|align=center|SHA-256/384/512 및 키 길이 128 비트 이상의<br>AES, TDES, ARIA 등 지원
|-
|align=center|암·복호화 위치
|align=center|DB 서버(OS커널)
|-
|align=center|DB 서버의 부하
|align=center|낮음
|-
|align=center|색인 검색
|align=center|가능
|-
|align=center|배치 처리
|align=center|가능
|-
|align=center|애플리케이션
|align=center|수정 없음
|-
|align=center|접근통제
|align=center|OS계정 및 응용 프로그램 단위로 접근 통제 수행,<br>DB 내에 존재하는 DB사용자들은 복호화된 데이터 열람 가능
|}

===기타===
====토큰 방식====
데이터의 숫자나 형태, 구조를 그대로 유지하면서 난수와 같은 임의의 토큰(대체값)과 별도의 테이블에 저장한 암호화 데이터를 연결하고 평문데이터의 일부 또는 전체를 토큰으로 대체하여 원본 데이터의 식별이 불가능하도록 하는 방식으로 하이브리드 방식과 같이 DB 서버 또는 애플리케이션 서버에서 암ž복호화 작업이 가능하다. 토큰의 데이터 타입을 원래 암호화 대상 데이터 타입과 동일하게 설정하면 기존 테이블의 구조를 변경하지 않아도 되며, 암호화 이후 컬럼 사이즈가 변경되지 않아 DB 서버 및 메모리 증설 등이 필요하지 않다. 다만 토큰 값과 암호화 데이터를 저장하기 위한 별도의 관리 서버가 필요할 수 있으며, 일부 API 방식의 애플리케이션에 한하여 수정 및 변경이 필요하다. 이러한 토큰 방식을 적용할 때에는 데이터 값을 대체하는 난수의 생성 방식이 원본 데이터를 유출할 수 없는 알고리즘으로 구성되었는지 보안성 측면의 검토가 필요하다. 

====시큐어프록시 방식====
독립된 프로세스로 구동하여 애플리케이션과 DBMS 중간에서 암·복호화 처리를 하는 방식으로 플러그인 방식과 동일하게 DBMS에서 암·복호화를 수행하나 뷰 또는 트리거를 사용하지 않고 암·복호화 함수를 사용하여 원 테이블의 데이터를 입력 또는 조회할 수 있다. DB 서버 부하 등을 보완하기 위해 암 복호화 작업을 수행하는 에이전트를 별도의 서버에 탑재하여 암·복호화 작업을 수행하는 것이 가능하나 보안 및 관리에 대해 추가적인 고려가 필요하다.

====필터 방식====
독립된 프로세스로 구동하여 애플리케이션과 DBMS 중간에서 암·복호화 처리를 하는 방식으로 API 방식과 동일하게 애플리케이션 서버에서 암 복호화 처리를 하는 방식이다. [[자바]] 기반의 애플리케이션에서 소스 수정 없이 암 복호화 할 수 있다. 하지만 등록된 SQL만 암 복호화가 가능하여 암 복호화 대상이 되는 SQL의 수집 및 변경이 필요하다. 암 복호화 작업을 수행하는 에이전트를 별도의 서버에 탑재하여 암 복호화 작업을 수행하는 것이 가능하나 보안 및 관리에 대해 추가적인 고려가 필요하다.

====어플라이언스 방식====
애플리케이션 서버와 DB 서버 사이에 어플라이언스 장비를 설치 또는 프록시 방식으로 구성하여 해당 장비에서 테이블 컬럼 분석을 통해 암·복호화 컬럼 여부를 파악하여 실시간으로 암·복호화 처리 및 키 관리가 수행되는 방식이다. 애플리케이션 수정 및 변경을 수행하지 않고 구현이 가능하고, 필요 시 DB 서버 또는 애플리케이션 서버에 별도의 에이전트를 설치하여야 한다. 어플라이언스 장비에서 암 복호화 및 키 관리가 수행되어 암 복호화 및 키 관리에 대한 보안성이 높고 암호화에 따른 DB 서버나 애플리케이션 서버의 부하가 상대적으로 적다. 그러나 이 방식을 적용하려면 암·복호화 처리가 필요한 데이터양에 따라 다수의 어플라이언스 장비가 필요할 수 있어 어플라이언스 장비의 장애에 대한 대비 및 배치작업 수행 시 성능 등을 추가적으로 검토할 필요가 있다.

====인플레이스 방식====
플러그인 방식에 데이터베이스 엔진 내부에서 암호화, 복호화 기능을 수행하게 한 것으로, 애플리케이션 환경에서 완벽한 독립성을 제공하고, 플러그인 방식보다 더 빠른 암호화 성능을 보인다. 다만 암호화 이외의 접근제어, 보안 감사 등 데이터베이스 보안 기능 지원을 위해 별도의 패키지를 사용해야 한다는 단점이 있다.

==계층별 데이터 암호화==
완벽한 암호화를 하기 위해서는 애플리케이션과 시스템, 네트워크 계층 모두 적절한 암호화가 적용되고 안전한 키 관리와 권한 관리 및 접근 제어가 이루어져야 한다. 따라서 각 계층의 역할과 암호화가 이루어지는 방식을 알아야 할 필요가 있다.

===네트워크 계층===
[[네트워크 계층]]은 서버와 [[클라이언트]]가 서로 교차 연결되어 데이터의 송신과 수신이 이루어지는 곳으로, 응용 서버와 데이터베이스 서버, 네트워크로 연결된 [[저장장치]]와 서버, 서버와 [[단말]] 등의 통신이 이루어지는 계층이다. 공격자는 통신 채널을 도청하여 송수신 데이터를 수집하거나, 데이터를 탈취할 수 있다. 이때 데이터를 보호하기 위해 송신자와 수신자 사이의 통신 채널 자체를 암호화하거나 송수신 되는 데이터 중 이미 지정한 정보만을 선택적으로 암호화하는 방식이 있다. 송신자와 수신자 사이의 통신 채널 자체를 암호화하는 방식은 모든 데이터를 암호화하기 때문에 효율이 떨어질 수 있지만, 송수신 사실까 감출 수 있어 안전성이 높다. 송수신되는 데이터 중에서 이미 지정한 정보만을 선택적으로 암호화하는 방식은 꼭 필요한 정보만을 암호화함으로써 효율을 높인 것으로, 선택적 암호화 기술이 요구된다. 네트워크 계층의 암호화는 물리적으로 분리되어 있는 송신자와 수신자 사이에서 안전한 암호화를 제공해 줄 수 있는데, 안전한 암호화를 위해서는 송신자와 수신자 사이에서 암호화 키를 안전하게 생성하고 관리해야 한다. 데이터를 보호하기 위해 다음과 같은 방법으로 암호화를 한다. 

===운영 체제 계층===
모든 데이터는 컴퓨터에 저장될 때 파일의 형태로 저장되는데, [[운영체제 계층]]에서의 암호화는 [[운영체제]]가 파일을 저장하는 과정에 암호화 단계를 추가한 것이다. 암호화 방식에는 저장장치에 암호화 기능을 탑재하거나 파일 시스템이 암호화와 복호화를 수행하는 방식 또는 특정 파일만 암호화하여 저장하는 방식이 있다. 이렇게 암호화를 하게 되면 데이터베이스나 애플리케이션은 암호화 처리를 고려하지 않아도 되어, 기존 시스템에 적용할 때 번거로운 수정이나 변경이 필요하지 않다는 장점이 있다. 하지만 대부분의 운영체제 레벨 암호화 제품이 암호화 키를 사용자 기기나 서버의 내부에 저장하고, 세분화된 보안 정책 설정 및 접근 제어가 어렵다는 등의 한계성이 있다. 저장장치에 암호화 기능을 탑재하는 방식은 [[HDD]] 등의 저장장치가 암호화와 복호화를 자체적으로 수행하는 것으로 저장되는 모든 파일이 암호화된다. 파일 시스템이 암호화와 복호화를 수행하는 방식은 OS 파일 시스템이 암호화를 수행하는 것으로 저장되는 모든 파일이 암호화된다. 특정 파일만 암호화하여 저장하는 방식은 선택적으로 파일을 암호화하여 관리하는 것으로 [[디렉터리]]나 폴더 단위로 암호화도 가능하다.

===DBMS 엔진 계층===
데이터베이스 관리 시스템 엔진(DBSM)은 데이터베이스 서버의 내부에서 데이터의 입출력과 저장을 관리하는 핵심 모듈로 많은 데이터베이스 관리 시스템 제품들이 자체적으로 암호화 기능을 제공한다. 데이터베이스에 정보를 저장하거나 읽을 때 암호화 적용 전후로 동일한 동작을 하기 때문에, 운영체제 계층 암호화 방법과 마찬가지로 기존 응용 프로그램은 수정할 필요가 없다는 것이 장점이다. 이와 같은 특징을 응용 프로그램에 대한 투명성이라고 정의해 투명한 데이터 암호화(Transparent Data Encryption, TDE)라고도 한다. 하지만 대부분의 투명한 데이터 암호화 방식 암호화 제품은 복호화된 데이터를 메모리에 두는 등 유출의 위험을 안고 있고 키 관리 측면에서 암호화 키가 데이터와 동일한 저장소에 있기 때문에 보안 측면에서 완벽하다 할 수 없어, 데이터베이스 관리 시스템 레벨의 암호화 제품을 적용하기 전 키 관리와 메모리상 복호화 데이터 처리 등을 고려해야 한다.

===DBMS 패키지 계층===
이 계층에서는 외부 요청을 수신하고 엔진이 처리하도록 지시와 관리가 이루어진다. 이 계층에서의 암호화는 상위 계층의 앱은 수행하지 않아도 되고, 데이터베이스 관리 시스템 엔진이 이미 암호화된 데이터를 받고 처리하기 때문에 메모리 보안 위협 문제가 없다는 장점이 있다. 선택적으로 데이터베이스 테이블을 지정하여 암호화할 수 있기 때문에 성능 면에서도 우수한 방법이다. 데이터베이스 관리 시스템 패키지 계층 암호화 제품은 데이터가 처리될 때마다 암호화나 복호화가 일어나기 때문에 서버에 부담을 줄 수 있다. 따라서 실제 환경에 적용할 때는 적절한 방법을 선택 적용하여 서버 부담을 줄일 수 있는 방법을 제공해야 한다.

===DBMS 프로시져 계층===
이 계층에 암호화를 적용하려면, 데이터베이스 서버와 정보를 주고받을 때 암호화를 지원하는 별도의 [[API]]를 사용하여 암호화를 처리해야 한다. 앱과 데이터베이스 서버와 별도 시스템에 존재한다면 네트워크 계층 암호화를 추가로 적용할 수 있다. 기존 데이터베이스 관리 시스템 API를 대신해 암호화 API를 호출하여 데이터베이스 관리 시스템 패키지 계층 암호화가 가지는 모든 장점을 그대로 가지고, 암호화, 복호화 연산 처리 부담이 데이터베이스 서버에 전가되지 않는다는 장점이 있다. 네트워크 환경에서도 네트워크 구간에서 발생하는 보안 위협에 대응할 수 있다는 것 또한 큰 장점이다. 다만 어느 정도의 응용프로그램 수정이 필요하다는 것이 단점이다.

===웹 애플리케이션 계층===
[[웹]] 서버, 웹 애플리케이션 서버, 데이터베이스 서버로 구성되는 multi-tier 구성으로 이루어지고, 웹 서버와 데이터베이스 서버를 중개하며 데이터의 흐름을 제어하는 역할을 한다. 데이터베이스 서버와 연결하는 부분의 기능은 데이터베이스관리 시스템 [[프로시져]]의 애플리케이션과 같은 기능을 수행하기 때문에, 암호화가 이루어지는 위치만 다를 뿐, 이 계층에서의 암호화 방법은 데이터베이스 관리 시스템 프로시져 계층 암호화 방법과 동일하며 동일한 장단점을 가진다.

===비즈니스 애플리케이션 계층===
내부 데이터 관리를 위해 데이터베이스 관리 시스템을 사용하더라도 저장소를 관리하는 별도의 시스템 형태로 포함되어 있어, 비즈니스 애플리케이션 개발자가 데이터베이스 관리 시스템을 직접 호출하거나 이용하는 것이 불가능하다. 이 계층 암호화를 위해서는 저장소 관리 서브 시스템을 수정하거나 보조 서브 시스템을 추가해야 한다. 이 계층은 독자의 설계와 구현 원칙에 비해 복잡하게 구현되기 때문에, 새로운 서브 시스템을 추가하고 수정하는 일에 많은 노력과 비용이 소요된다. 웹 애플리케이션 계층의 방법과 동일하므로 동일한 장단점을 가진다. <ref>펜타시큐리티시스템 공식 홈페이지 - https://www.pentasecurity.co.kr/database-encryption/</ref>

==구축 방안==
===구축 전략===
; 단계별 적용
DB 암호화 기술 적용을 위해 단계별로 적용 단위를 나눌 수 있다면 효과적으로 구축할 수 있다. 적용단위를 구분하는데 있어 고려해야할 사항은 업무프로그램 단위와 적용 시점이다. DB 암호화를 하게 되면 암호화된 테이블별로 관련된 SQL들이 영향을 받기 때문에 업무프로그램 단위로 관계된 테이블들을 1차 적용 단위로 정하고, 추가적으로 테이블 들끼리 또는 DBMS끼리 연결되어 있다는 점을 고려하여 일시에 적용할 것인지 또는 그 이후 적용 단위로 적용할 것인지를 결정해야 한다. 이 때 업무프로그램의 영향을 세밀히 파악할 수 있어야 하며, 사전에 분석된 ERD(Entity Relation Diagram)에 따라 암호화할 테이블과 관련된 모든 SQL들이 포함된 업무프로그램과 DB 링크 등을 통한 타 DB와의 데이터 연계 부분을 체크해야 한다. DB 암호화 구축 일정을 계획할 때는 먼저 업무 단위로 분류하여 관계된 테이블들을 암호화 대상으로 선정할 수 있으며, 다른 DB와 DB 링크 등으로 연계된 경우는 운영 측면과 성능 측면에서 함께 구축 대상에 포함할 수도 있다.

; 리스크 관리
DB 암호화 기술은 대단위의 데이터를 암호화하고 기존의 평문상태의 테이블을 삭제한 후에야 비로소 DB 암호화 기술이 적용된 암호화 데이터 운영이 가능하다. 그러므로 암호화 구축을 이행한 후에 운영에 대해 사전에 충분히 검증하는 절차가 매우 중요하다.
* 컬럼암호화 방식 : 테스트 DB에서 SQL 테스트 미흡으로 인해 발생할 수 있는 문제점들을 충분히 검증하는 절차가 필요
* 블록암호화 방식 : 주요 온라인 업무에 대한 부하테스트, 최대 용량의 배치 작업에 대한 테스트 등 사전 검증이 필요
DB 암호화 구축 시 운영 DB에 적용 후 문제가 발생하지 않도록 암호화 구축을 이행한 이후에 충분한 테스트를 통해 리스크를 최소화하여야 하지만, 혹시라도 검증 미비로 말미암아 발생할 수 있는 사태에 대한 대비책으로 즉각적인 원복 체계 등을 강구해야 한다.

===구축 절차===
; 사전 협의
DB 암호화를 구축하기에 앞서 참여하는 모든 조직은 사전에 충분히 필요한 정보를 공유할 목적으로 본 단계를 수행해야 한다. 또한 DB 암호화 방식에 따른 암호화 대상, 적용 환경, 보안 등 사전에 필요한 사항에 대해 협의하여야 한다.

; 영향도 분석
암호화 적용 이전에 운영서버에 대한 모니터링을 통해 애플리케이션과 DBMS의 영향도를 분석하는 단계이다. DB 암호화 구축 단계에서 테스트/검증 단계와 함께 가장 중요한 단계로 DB 암호화 기술을 선정하거나 도입할 때에 반드시 검토되어야 한다. 운영시스템에 암호화를 적용하기 전에 암호화 대상 추출, 암호화 관련 SQL 쿼리 등을 미리 추출하여 테스트 시스템에서 성능 테스트를 수행하는 등 암호화 사전 진단을 수행하는 것이 필요하다. 전체적으로 DBMS 분석, 응용 프로그램 분석의 단계를 수행하여 암호화 이후 성능 및 시스템 리소스, 오브젝트 변화 등의 영향도를 분석한다.
* 암호화 대상 추출 : 전체 DBMS의 테이블과 컬럼을 검색하여 암호화 대상이 되는 데이터 컬럼을 추출한다.
* 오브젝트 검색 : DBMS 내부의 뷰, 트리거, 기능, 절차 등의 오브젝트를 검색하여 암호화 대상 컬럼과 테이블을 포함하는 즉, DB 암호화에 영향을 받을 수 있는 오브젝트를 추출한다.
* 쿼리 수집 및 분석 : 실제 DB에 접근하는 단위는 쿼리이며 전체 쿼리 요청 대비 암호화 쿼리 요청의 비율을 도출하여 암호화 이후 영향도를 분석할 수 있다. 전체 쿼리 요청량 수집, 암호화 쿼리 요청량 수집, 최적화 대상 쿼리 도출의 단계를 거친다.
# 전체 쿼리 요청량 수집 : 암호화 대상 DBMS에 요청되는 모든 쿼리에 대해 시간대별, 일별, 월별 등 전체 쿼리 요청량을 수집하여 DBMS의 피크 타임 추이를 분석
# 암호화 쿼리 요청량 수집 : 암호화 대상 DBMS에 요청되는 쿼리 중에서 암호화 대상 컬럼에 접근하는 쿼리에 대해 시간대별, 일별, 월별 등의 요청량을 수집하여 전체 쿼리 대비 암호화 쿼리의 비율을 분석
# 최적화 쿼리 도출 : 암호화 쿼리 중 최적화가 필요할 것으로 판단되는 유형의 쿼리를 분석
* DBMS 분석 : DBMS에 대한 리소스에 대해 확인하고 암호화 적용에 따라 적정 수준의 리소스를 확보해야 한다. 시스템 환경에 따라 차이가 있기 때문에 사전에 DB 운영 자체 검사를 분석하여 기준 값을 설정하고 암호화 이후 변동될 수 있는 사항을 확인한다.
* 응용 프로그램 분석 : 응용 프로그램의 모든 암호화 관련 쿼리를 수집하여 테스트하고 성능 최적화 방안을 수립한다. 사전에 성능 영향도를 분석함으로써 안전하게 암호화를 구축할 수 있다. 응용 프로그램 분석 단계는 아래와 같은 수행 단계를 거치게 된다.
# 암호화 관련 모든 쿼리를 수집
# 해당 쿼리에 대해 암호화 전 성능 및 암호화 후 성능 측정
# 암호화 후 성능이 느린 쿼리에 대해 최적화 작업 수행

; 테스트 검증
운영 환경과 동일한 테스트 환경을 구축하여 암호화를 적용한 후에 애플리케이션 등의 업무 테스트를 진행하는 단계이다. 테스트를 통해 운영 환경에 이행 시 발생할 수 있는 문제를 도출하고 모든 이슈를 해결하여 운영 환경에 대한 이행을 준비해야 한다. 해당 절차에서 컬럼암호화 방식의 경우, 사전 SQL검증 작업을 위해 테스트 DB(개발 DB)에서 먼저 암호화한 후 암호화된 테이블을 접근하는 모든 SQL들을 테스트 및 검증해야 한다. 이 절차가 완료되면 운영 DB의 암호화 일정을 정하고, 상세한 테스크별 실행 시나리오를 만든 다음 각각의 테스크 별로 소요되는 시간을 측정하며 업무 프로세스를 감안하여 각각의 암호화 대상 테이블별로 암호화 순서를 정한다. 블록 암호화 방식은 SQL 검증 작업에 비중을 두지 않고 주요 업무에 대한 테스트 검증을 수행한다. 일반적으로 테스트 DB 서버와 운영 DB 서버의 사양이 다르기 때문에 정확한 소요 시간을 측정하기 위해서는 테스트 DB에서 암호화 한 테이블을 운영 DB에서도 암호화 해 보면 H/W의 성능 차이에 의한 암호화 시간 차이를 알 수 있다. 이를 근거로 소요 시간을 산정하면 된다. 먼저 테스트 환경은 운영 환경과 동일한 데이터와 애플리케이션을 준비한 후 암호화 대상 테이블/컬럼을 암호화하여 성능 및 이상 처리 여부를 확인한다. 만일 문제가 발견되면 SQL 수정을 통해 해결토록 하고 수정된 SQL이 반영된 애플리케이션을 따로 준비해 둔 후, 운영 시스템의 암호화가 종료되면 수정된 애플리케이션으로 교체하는 순서로 진행한다. 운영 중인 업무와 관련된 DB 암호화에서는 이미 사용되고 있는 애플리케이션 내의 SQL문들의 테스트가 가장 중요하며 많은 시간이 소요된다. 이 부분의 테스트/검증 정확도에 따라 프로젝트의 성공 여부가 결정지어 진다. 따라서 애플리케이션 개발/운영 조직의 협조가 매우 중요하다. 운영 중인 업무와 관련된 DB 암호화와는 달리 차세대 등의 애플리케이션 재개발 시에 적용하게 되면 SQL문의 테스트 과정이 생략 될 수 있고 최적의 성능이 실현될 수 있는 등 다양한 방법 적용이 가능하다.

; 구축 및 안정화
테스트 단계에서 검증된 사항을 종합하여 운영 환경에 DB 암호화를 적용하는 단계이다. 데이터에 대한 암호화 적용뿐만 아니라 테스트 검증 단계에서 변경된 소스코드 또는 최적화 쿼리를 함께 반영해야 한다. 또한, 테스트를 통해 도출된 이슈를 해결하여 운영환경에 적용하여야 한다. 실제 운영 시 시스템의 안정화를 위해서는 DB 보안관리자 및 DB관리자와 애플리케이션 개발자에 대한 교육을 실시하여 DB 암호화 솔루션의 안정적인 운영 및 관리를 위한 기술이 전수되도록 하고, 지속적인 모니터링을 수행해야 한다.

==고려사항==
DB에 저장된 정보들은 DB내부의 인덱스, 내외부 애플리케이션 등과 밀접하게 상호 작용을 하므로 DB 암호화 후에도 이러한 시스템적 관계유지가 필요하다. 또한 DB서비스의 영속성을 위해 DB 암호화 후 기존 제약사항 이나 서비스의 안전성 유지가 무엇보다 중요하다. 이를 위한 DB 암호화 기술 도입 시 주요 고려사항은 암호화 대상, 암호 알고리즘, 암·복호화 범위, 암·복호화 키 관리, 암·복호화, 접근통제, 인증, 암호통신, 보안감사 등으로 구분할 수 있다.

===암호화 대상===
암호화 대상은 국내 법·규정 등에서 규정한 개인정보 및 그 외 중요 데이터를 우선적으로 선정한다. 각 법률 및 규정에서 명시한 DB 암호화 대상은 비밀번호(패스워드), 고유식별정보4)(주민등록번호, 여권번호, 운전면허번호, 외국인등록번호 등), 신용카드번호, 계좌번호, 거래로그, 바이오정보(생체정보) 등이 있다. 정보의 특성에 따라 암호화 방식을 다르게 하도록 규정하고 있으며, 각 특성에 맞는 암호화 알고리즘으로 DB 암호화 기술을 적용해야한다. 원칙적으로, 금융회사에서는 개인신용정보는 신용정보법 및 관련 고시에 따라, 그 밖의 개인정보는 개인정보보호법 및 관련 고시에 따라 필요한 조치를 취해야 한다. 다만, 고유식별정보의 암호화는 개인정보보호법에서 특별히 정하는 의무사항이므로 금융회사가 업무상 수집․관리하는 모든 개인(신용)정보 전반에 대하여 적용됨을 유의하여야 한다. 개인정보보호법 상에서는 정보통신망을 통하여 개인정보를 송 수신하거나 보조저장매체 등을 통하여 전달하는 경우에 암호화하도록 규정하며, 인터넷구간 및 DMZ구간과 내부망으로 구분하여 내부망은 개인정보 영향평가(공공기관) 또는 위험도 분석결과5)에 따라 DB 암호화 적용 여부와 적용범위를 정하여 시행가능하나, 인터넷 구간 및 DMZ구간에 개인정보를 저장하는 경우 위험도 분석과 관계없이 DB 암호화를 적용하도록 하고 있다. 고유식별정보 중 주민등록번호(2016년 1월 1일부터 시행)는 영향평가 또는 위험도 분석결과와 무관하게 암호화 처리해야 하며, 영향평가 또는 위험도 분석 후 내부망에 DB 암호화를 적용할 경우, 송 수신되는 내부자 및 이용자의 비밀번호 또는 바이오정보는 암호화해야 한다. 그 외의 고유식별정보는 업무상 필요할 경우 암호화 대상에서 제외할 수 있다. 전용선을 이용하여 개인정보를 송 수신할 경우 암호화 적용이 필수적이진 않지만 내부사용자에 의한 개인정보 유출에 대비하기 위해선 암호화 기술 적용을 고려하여야 한다.

===암호 알고리즘===
DB 암호화를 위해 사용하는 암호 알고리즘 및 키 길이 선택 시 보안강도, 안전성 유지기간 등에 따라 성능과 보안성의 차이가 존재할 수 있다. 암호화 대상 DB의 용도 및 연계시스템 간의 관계, 특히 DB 암호화 시스템의 운영 기간 등을 고려하여 보안강도 및 암호 알고리즘의 안전성 유지기간을 선택하여야 한다. 만약 112비트 보안강도의 암호 알고리즘을 적용을 고려할 경우, 2030년 이후에는 112비트 보안강도의 암호 알고리즘이 안전하지 않으므로 2030년 이후까지 사용하는 것을 고려한다면 더 높은 보안강도의 알고리즘을 선택하여야 한다. DB의 중요 데이터를 암호화하는데 적용되는 암호 알고리즘은 크게 일방향 알고리즘과 양방향 알고리즘이 있다.

; 양방향 알고리즘
양방향 알고리즘은 암호화, 복호화 모두가 가능한 알고리즘으로이다. 주민등록번호 등의 개인정보를 암호화할 때 사용한다. 양방향 알고리즘은 보안 강도에 따라 112비트 이상 알고리즘을 적용하어야 한다. 대표적으로 대칭 키(비공개키)와 비대칭 키(공개키) 방식으로 나눠진다. 대칭키 방식은 암호화, 복호화 시 모두 동일한 키를 사용하기 때문에 키를 비공개로 한다. 속도가 빠르지만, 송신 측에서 수신 측에 암호를 전달하는 과정에서 키가 노출될 수 있다. DES, AES가 대표적인 예다. 1975년부터 DES가 주로 사용되어왔지만 시간이 흐르면서 취약점이 발견됨에 따라 이를 대처하기 위해 만들어진 것이 AES로 현재는 AES를 보편적으로 사용한다. 비대칭 키 방식은 암호화 복호화에 서로 다른 키를 사용해 하나의 키는 공개키로 하고, 다른 하나의 키는 비공개 키로하여 대칭키의 키 배송 문제를 근본적으로 차단했다. RSA가 대표적이고, 대칭 키 방식에 비해 현저하게 느리다는 단점이 있다. 따라서 현실적으로는 비대칭형 암호를 이용해서 대칭형 암호의 키를 배송하고, 실제 암호문은 대칭형 암호를 사용하는 등 상호보완적으로 이용하는 것이 좋다.<ref name=“양방향단방향”>Leejisoo, 〈[https://javaplant.tistory.com/26 암호화 양방향,단방향,공개키(비대칭키),비공개키(대칭키) 개념/분류 알고리즘 정리]〉, 《티스토리》, 2018-05-08</ref>

; 단방향 알고리즘
단방향 알고리즘은 암호화는 수행하지만, 복호화가 불가능한 알고리즘으로 [[비밀번호]]를 암호화할 때 사용한다. 임의 길이의 정보를 입력으로 받아 고정된 길이의 암호문(해쉬값)을 출력하는 암호기술로 암호화된 정보는 복호화가 불가능한 특징을 가지고 있으며, 일반적으로 비밀번호 등을 암호화 할 때 사용된다. 이때 해시 함수는 해시 된 값이 주어져 있을 때 계산을 하여 입력된 값을 계산하기가 어려워야 하고, 해시 충돌에 대한 저항성이 있고, 절대적으로 복호화가 불가능해야 한다는 특성들을 가져야 한다.<ref>김승민, 〈[https://k0102575.github.io/articles/2020-03/hash (Security) 암호화 알고리즘 – 단방향 암호화, Hash]〉, 《깃허브》, 2020-03-25</ref> 일방향 알고리즘은 암호 알고리즘 보안강도에 따른 안전성 유지 기간을 고려했을 때 112비트 이상의 알고리즘을 사용하여야 한다.  일방향 알고리즘 적용 시 암호화 값에 대한 사전 공격, 무작위 대입 공격 등을 대비하기 위해 Salt라는 비밀값을 추가할 수 있다. Salt는 동일한 평문 값인 경우에도, 암호화된 결과값을 다르게 만들어 비밀번호 노출 위협을 막을 수 있다. Salt는 암호화하는 데이터와 따로 분리하여 저장하여야 하며, 서버 프로그램 노출에 따른 Salt 값의 노출 위험을 막기 위해, 서버 프로그램은 Salt를 외부에서 호출하여 사용하는 형태로 구현하는 것이 적합하다. 해시 함수에는 MD5, SHA, HAS 등이 있는데, MD5, SHA-1, HAS-180은 보안상 취약하기 때문에 SHA-256,512를 쓰는 것이 좋다. 특히 MD5는 단시간 내에 충돌값을 찾아낼 수 있기 때문에 패스워드 암호화에 MD5를 이용하고 있는 사이트가 있다면 즉시 탈퇴해야 한다. 중복이 적을수록 좋은 해시이다.<ref name=“양방향단방향”></ref>
:{|class=wikitable width=600
|+암호 알고리즘 보안강도 비교표
!align=center|보안강도
!align=center|양방향 알고리즘<br>(대칭키 암호)
!align=center|일방향 알고리즘<br>(해시함수)
!align=center|암호 알고리즘<br>안정성 유지기간
|-
|align=center|80 비트
|align=center|80
|align=center|80
|align=center|2010년까지
|-
|align=center|112 비트
|align=center|112
|align=center|112
|align=center|2011년에서 2030년까지<br>(최대 20년)
|-
|align=center|128비트
|align=center|128
|align=center|128
|align=center rowspan="3"|2030년 이후
|-
|align=center|192 비트
|align=center|192
|align=center|192
|-
|align=center|256 비트
|align=center|256
|align=center|256
|}

===암·복호화 범위===
[[파일:암복호화 범위.JPG|썸네일|568픽셀|'''방식별 암·복호화 범위''']]

DB 암호화 기술은 각 방식 특성(암호화 또는 복호화 처리되는 시점 등)에 기반하여 데이터의 암호화 또는 복호화의 범위(데이터가 암호문 또는 평문으로 조회 가능한 범위)가 다르며, 데이터의 특성 및 활용도에 따라 적합한 기술을 적용하여야 한다. 예를 들어 Plug-In 방식의 경우, DB 서버 내에암·복호화 모듈을 설치하여 암·복호화를 수행하기 때문에, 스토리지 및 DB 서버 상에서는 데이터가 암호화된 형태로 존재하나, 데이터를 활용하기 위해 애플리케이션 서버로 데이터를 전송할 경우에는 데이터가 DB 서버 내에서 복호화 되어 애플리케이션 서버로 전송된다.

===키 관리===
암호화 시 키가 노출되면 암호화된 데이터를 복호화 할 수 있기 때문에 키를 안전하게 관리하는 것은 매우 중요하다. DB의 암·복호화를 위해 사용되는 암·복호화 키의 종류는 암·복호화 키와 마스터 키 두 가지로 크게 나눌 수 있는데, 암·복호화 키는 DB 내 데이터의 암·복호화를 위해 사용되며, 마스터 키는 암·복호화 키를 암호화하기 위해 사용 된다. 암호화된 데이터 유출 시 이를 해독할 수 있는 암 복호화 키는 암호화 대상이 되는 데이터만큼이나 중요한 정보이다. 아무리 강력한 암호를 사용한다 할지라도 메모리 덤프 공격 등을 통해 암호화 키 정보가 외부에 노출되면 해당 키로 암호화된 데이터는 평문으로 저장된 것과 마찬가지이므로 사용되는 키는 공유 메모리에 로드될 경우 평문으로 존재하지 않아야 한다. 암 복호화 키는 마스터키를 사용하여 암호화하고, 실제 암·복호화 키를 사용하는 시점에만 임시로 복호화하여 사용하여야 한다. 마스터키 또한 유출이 불가능하도록 하거나 유출이 되어도 활용할 수 없도록 생성부터 폐기까지 안전하게 관리되어야 한다. 암호키가 하나일 경우 데이터베이스 암호화를 하게 되면 손쉽게 구축이 되지만, 해당 키가 유출되면 매우 위험한 상황에 처하게 된다는 단점이 있다. 따라서 업무의 범위나 시스템의 역할에 따라 암호 키를 분리하고, 암호 키의 접근 제어 정책이 수반되어야 한다. 데이터베이스 관리 시스템의 암호화 기능을 사용하는 경우, 암호 키를 보관하는 가장 손쉬운 방법은 제한된 [[테이블]]이나 [[파일]]에 저장하는 것이다. 이 방법은 데이터베이스 관리자가 접근 권한을 가진 경우가 대부분이고 임의의 복호화 작업이 가능하기 때문에 위험할 수 있어, 데이터베이스 서버와 별개의 독립된 기계로 암호 키를 관리하는 것이 바람직하다. 이렇게 관리되는 암호키는 시스템 상의 접근제어는 물론 강력한 인증과 파일 접근 제한 등의 보안 조치를 통해 안전하게 관리되고, 접근제어 기능을 통해 관리자나 임의의 사용자에 의한 암호 키 유출도 막을 수 있다. 단계별 키 관리 절차는 다음과 같다.
 키 생성 → 키 분배 → 키 저장 → 키 사용 → 키 백업/복구 → 키 교체 → 키 폐기

; 키 생성
암·복호화 키를 생성하기 이전에 보안을 위해 유효기간을 설정할 필요가 있다. 유효기간은 사용자 또는 관리자가 암·복호화 키를 사용할 수 있도록 허용된 기간과 사용기간이 완료된 이후라도 추후 복호화 과정에서 해당 암·복호화 키를 사용하도록 허용된 기간으로 구분할 수 있는데 NIST(National Institute of Standards and Technology)의 키 관리 권고안에서는 해당 유효기간을 각각 최대 2년, 최대 5년으로 설정하도록 제시하였다. 암·복호화 키를 생성하기 위해서는 다음의 두 가지를 고려하여야 한다. 첫째, 암·복호화 키 생성시 안전한 난수 발생기를 이용하여야 하며 둘째, 사용자 입력으로부터 유도되는 암·복호화 키 또한 안정성이 검증된 알고리즘을 사용하여 생성하여야 한다. 각각의 업무를 처리하기 위해 시스템들은 DB의 암호화된 데이터를 복호화하는 키를 사용할 것이고 하나의 암·복호화 키로 구성된 데이터는
암·복호화 키가 유출되면 기밀성이 유지되지 않아 암호화의 의미를 잃게 된다. 그러므로 업무 범위나 시스템의 역할 등을 고려하여 암·복호화 키를 테이블 또는 컬럼에 따라 다르게 생성하여 사용한다면 암·복호화 키에 대한 보안성을 강화하고, 개별적으로 키 교환이나 폐기를 처리할 수 있어 하나의 암·복호화 키를 사용하여 전체를 암호화 하는 방식보다 유연한 세부적 정책 설정이 가능하다. 다수의 암·복호화 키로 분리하여 보안성을 강화하여도 해당 암·복호화 키에 대한 접근제어 정책이 반드시 수반되어야 한다.

; 키 분배
키 분배라 함은 암·복호화 키를 생성한 후에 이를 안전하게 분배하는 것을 말한다. 키 분배 시에도 암호화 등의 방법을 통하여 보안성을 유지하여야 한다. 키 관리 서버가 별도로 존재하는 경우에도 생성된 암·복호화 키 분배 및 정책 배포를 위해 암호화 등의 방법을 통하여 암·복호화 키의 외부 노출을 차단하여야 한다.

; 키 저장
암·복호화 키를 저장하는 방법 중 쉬운 방법은 제한된 테이블이나 파일에 암·복호화 키를 저장하는 것이다. 이러한 방법은 DB 관리자가 접근권한을 가지고 있다면, 데이터를 임의로 복호화 할 수 있고 해당 테이블이나 파일이 함께 유출된 경우, 데이터를 해독할 수 있어 내 외부 위협에 노출될 가능성이 있다. 따라서 DBMS 내부에 암·복호화 키를 저장하기 보다는 DBMS와 분리된 별도의 키 관리 서버, HSM 장비 등을 통해 암호화 하여 저장하는 것을 고려하여야 한다. 별도에 장비에 암·복호화 키를 분리하여 관리할 시에도 시스템에 대한 접근통제 및 인증 정책이 수반되어야 하며, 해당 장비는 물리적으로 안전하게 보호해야 할 것이다.

; 키 사용
[[파일:암복호화 키 보호.JPG|썸네일|540픽셀|'''공개키를 이용한 암·복호화 키 보호]]

암·복호화 키에 대한 접근제어 정책이 없다면, 개발자부터 DB 관리자까지 누구나 해당 암·복호화 키를 접근할 수 있게 되므로 기본적으로 DB 관리자는 암호화된 데이터를 직접 조회하거나 데이터 및 암·복호화 키에 대한 접근 권한을 가질 수 없도록 DB 관리자와 보안 관리자의 권한을 분리하여야 한다. 또한, 하나의 테이블에 존재하는 서로 다른 컬럼이라 하더라도 사용자를 식별하여 복호화할 수 있도록 암·복호화 키 분리 정책 및 복호화의 권한 제한을 설정할 필요가 있다. 복호화 권한 없는 사용자에게는 암호화된 데이터나 부분 암호화(Maskimg 등) 데이터를 전송하여야 한다. 공유 메모리에 로드된 암·복호화 키도 평문으로 저장해서는 안 되며, 마스터키와 같이 키를 암호화하는 핵심보안 매개변수도 안전하게 관리되어야 한다. 암·복호화 키와 마찬가지로 접근 및 변경은 인가된 사용자에게만 허가 되어야 한다. 또한 공개키를 이용하여 암·복호화 키를 암호화하는 등 암·복호화 키를 안전하게 사용 할 수 있는 방안을 마련해야 한다.

; 키 백업 및 복구
암·복호화 키 및 패스워드의 분실 또는 훼손, 키 관리자의 퇴사 등으로 암·복호화 키와 패스워드를 알 수 없는 경우에 대비하여 암·복호화 키를 복구하기 위한 백업 절차를 수립하여야 한다. 또한 암·복호화 키 분실 시 데이터 복호화가 불가능하므로 분실, 훼손, 파괴 등의 경우에 대비하여 키를 복구하기 위한 방안도 마련해야 한다. 암·복호화 키는 백업 정책에 따라 주기적으로 백업되어야 하며, 백업된 키 정보는 암호화 하여 저장해야 한다. 또한 키 백업에 사용한 암·복호화 키는 별도로 관리되어야 한다. 암호화된 데이터를 백업하는 경우 해당 데이터를 암호화 한 암·복호화 키도 백업해야 향후 백업된 암호화 데이터를 복호화 하여 이용할 수 있다.

; 키 교체
암·복호화 키는 기업 내부 정책에 부합하는 기간마다 교체하여 보안성을 유지하도록 해야 한다. 키를 교체하기 전 기존 키로 암호화된 데이터는 복호화 후 새로운 키로 다시 암호화하여야 한다. 암·복호화 키가 노출된 경우 키 교체 등의 보안 방안이 필요하다.
* 신규 데이터 : 변경된 키를 사용하여 암호화
* 기존 암호문 : 마이그레이션 작업을 통하여 신규 암호문으로 변경

; 키 폐기
암·복호화 키는 여러 가지 이유로 폐기 될 수 있다. 예를 들어, 암·복호화 키 또는 마스터키를 분실하거나 키의 비밀성이 깨진 경우 등에 대비하여 키를 폐기하기 위한 절차 및 방법을 수립함으로써 허가된 관리자가 절차에 따라 폐기할 수 있도록 하여야 한다. 암·복호화 키를 폐기하게 되면 기존에 암호화 된 데이터는 더 이상 복호화 할 수 없으므로, 암·복호화 키 폐기 전 복호화 후 폐기하여야 한다. 또한 제품 종료 후 메모리에 로드된 암·복호화 키와 핵심보안 매개변수는 모두 제거하여 유추할 수 없도록 해야 한다.

===암·복호화===
데이터의 분실, 도난, 유출 등의 위협에 대응하여 보안성을 보장하기 위해서는 인가된 사용자만이 안전성이 검증된 알고리즘을 사용하여 암호화하여야 한다. 

; 인덱스 검색
암호화 컬럼의 데이터 타입에 따라 인덱스의 컬럼 값이 그대로 노출되는 경우가 있기 때문에 인덱스를 통한 원본 데이터의 유출 위협에 대응하기 위해서는 인덱스 컬럼에 대한 암호화를 수행하여야 한다. 그러나 인덱스 컬럼에 대해 암호화를 적용하면, 인덱스를 활용할 수 없어 부하 및 성능 저하가 발생할 수 있다. 이러한 경우는 별도의 다른 컬럼으로 유도하는 등 데이터 검색 속도 등을 향상시키기 위해 암호화 적용 후 해당 컬럼에 대해서 기존 인덱스를 유지할 수 있는 방안을 강구하는 것이 좋다. 

; 부분암호화
주민등록번호, 신용카드번호, 계좌번호 등 인덱스로 사용되는 데이터 전체를 암호화하게 되면 암호문을 통한 일치 검색은 가능하지만 범위 검색 시 성능 저하가 발생하여 원활한 서비스 제공 및 기존 환경과 동일한 수준의 가용성 보장이 어려울 수 있다. 이러한 경우 인덱스 컬럼의 보안성을 유지하며 가용성을 보장받기 위한 방안으로서 인덱스 컬럼에 부분 암호화 기술을 사용하여 최소한의 필수 정보만을 평문으로 유지하고 이외에 데이터는 암호화하여 검색 속도를 향상 시킬 수 있다. 부분 암호화 기술를 적용하면 암호화 후에도 인덱스를 통한 전방 일치 검색, 일치 검색, 범위 검색을 할 수 있다.

; 데이터 저장 공간
암호화 솔루션을 설치하고 암호화 적용을 위해서는 설치 및 로그 파일 저장 공간과 암호화 작업 공간이 필요하다. 적용하는 암호화 방식 및 암호 모듈에 따라 데이터 사이즈가 증가하는 다양한 케이스가 존재할 수 있다. 
* 작은 크기의 원본 데이터를 암호화 후 데이터 사이즈가 증가하여 DB 컬럼의 사이즈까지 조정해야 하는 경우
* 텍스트 블록을 이진데이터로 암호화한 경우 다시 텍스트 형태로 변환하여야 하기 때문에 사이즈가 변화하는 경우 등
일반적으로는 암호화 적용 시 생성되는 암호화 테이블은 원본 사이즈보다 커지게 되므로 원본 테이블 이상의 추가적인 저장 공간이 필요하다. 암호화 적용 도중 원복을 해야 하는 경우도 발생할 수 있으므로 롤백 크기 확보도 필요하다.

; 원본 데이터 삭제
데이터 암호화 완료 후에는 원본 데이터 유출 방지를 위하여 원본 데이터는 모두 폐기 되어야 한다. 서비스가 진행 중인 DB와 백업 스토리지에 저장된 원본데이터가 그 대상이며, DB서버 내 디스크의 원본 데이터는 테이블의 컬럼 값 및 인덱스 정보까지 포함하여야 한다. 

; 성능
DB 암호화를 적용하면, 데이터 길이의 증가, 시스템 메모리 사용량 증가 등으로 인해 암호화 적용 전보다 성능이 저하된다. 이외에도 암호화 알고리즘의 종류와 키 길이에 따라 암/복호화 성능에 영향을 미칠 수 있고, 암호화 방식 및 서비스 특징에 따라서도 DB 암호화 적용 후 성능에 영향을 미치는 정도가 다를 수 있다. 그러므로 다양한 암호화 방식을 검토하여 부하를 감소시키기 위한 전략이 필요하다. 암호화 후의 성능저하를 방지하기 위한 다양한 방법 및 구성이 존재하므로 적합한 방법을 선택하여야 한다. 이러한 방법의 하나로 암호화 후 컬럼사이즈 증가에 따른 성능저하를 방지할 수 있는 형태보존함수(Format Preserving Encryption, 이하 FPE)를 사용하거나 암호화 데이터의 순서를 유지하여 암호화 후 발생하는 복호화 연산의 부담을 해결하는 순서유지 암호화함수(Order Preserving Encryption, 이하 OPE)를 사용하는 방법이 있다. FPE는 주민등록번호, 신용카드번호 등에 대한 암호문이 평문과 같은 형태를 유지하도록 하는 암호화 방식으로 금융정보, 데이터 완전삭제, DB 보안에 활용될 수 있는 암호화 알고리즘이다. 현재 NIST15)에는 FCEM16), FFX17), BPS18), VEPE19), CSPEM20) 등 5가지 FPE 암호화 알고리즘이 제안되어 있으며, 국내에서는 FEA21) 알고리즘이 제안되어 있다. 많은 전문가들이 보안성과 효율성 등의 검증을 계속적으로 진행 중이므로, 향후에는 DB 암호화 기술에 적용될 수 있을 것으로 예상된다. OPE는 암호화를 적용하더라도 암호화된 데이터들이 원본 데이터와 동일한 순서로 정렬될 수 있도록 해주는 방법으로 암호화된 데이터에 대해서도 DB의 검색 색인을 용이하게 만들 수 있다는 장점이 있으나 암호문에서‘순서’라는 정보를 얻을 수 있고 이를 바탕으로 평문을 유추할 가능성이 있다. 예를 들어 ABCD의 암호문(A)과 CDEF의 암호문(B)을 안다면, 암호문(A)와 암호문(B) 사이에 정렬될 수 있는 암호문(C)는 ABCD와 CDEF의 사이에 있는 어떤 값으로부터 만들어진 암호문임을 알 수 있다. 이렇듯 OPE는 어떤 수를
암호화한 값인지를 구분할 수 없는 비구별성(Indistinguishability)를 만족하지 못하기 때문에 검증받은 암호화 알고리즘을 함께 사용하거나 순서정보만을 한번 더 암호화 하는 등 OPE를 활용하여 DB 암호화로 인한 성능 영향을 감소시키기 위해서는 안전성을 보완해줄 보안장치 및 기술 적용이 필요하다.

===접근통제===
데이터 유출을 방지하기 위해 DB 암호화를 적용하지만 암호화 데이터, 암·복호화 키, 핵심보안 매개변수 등의 보안성 유지와 이들에 대한 내부 사용자의 불법적 접근을 방지하기 위해서는 접근통제 기능도 고려해야 한다.

; 권한분리
DB에 접근하는 경우는 웹이나 애플리케이션 서버의 정형적인 접근, DB관리자 등에 의한 비정형적인 접근24)으로 구분할 수 있는데, 접근 유형에 따라 사용자는 적합한 접근 권한을 부여 받아야 한다. 암호화가 적용된 데이터는 애플리케이션 프로그램(DB접속 프로그램, 사용할 수 있는 SQL 종류 등 통제), 접속자 IP 및 포트·MAC주소, 접속 기간 시간 요일, DB 사용자 계정 등에 의한 접근 통제 정책에 따라 인가되지 않은 사용자의 불법적인 접근을 통제하여야 한다. 또한 보안관리자, DB 관리자, 개발자 등의 권한을 명확히 분리 하여야 한다. 특히 DB관리 권한과 접근통제 관리권한은 반드시 분리하여야 한다. 보안관리자(접근통제 관리)는 암·복호화 키 관리, 암호화 정책 등을 관리하되 DB에 접근할 수 없어야 하며, DB 관리자는 암호화된 상태의 DB는 관리하되 암·복호화 키에 대한 접근을 통제하여 DB의 내용을 복호화 할 수 없도록 한다. 개발자는 암·복호화 키에 접근하지 못하며 불필요한 DB 접근 권한을 갖지 않도록 하여 정보 유출 및 오·남용이 발생하지 않도록 고려하여야 한다.

; 사용자 인증 및 식별
DB 사용자 계정 및 비밀번호가 노출 되면 해당 사용자에게 부여된 권한을 그대로 사용할 수 있기 때문에 식별 및 인증 과정을 통해 DB에 접근이 가능한 정당한 사용자임을 보증하여야 한다. 사용자 인증은 일반 사용자 및 관리자 인증으로 나뉠 수 있다. 일반 사용자는 인증 실패 횟수 제한 등 계정 및 비밀번호 관리 정책에 따라 복잡도 수준을 결정하고, 관리자는 보안 정책 설정, 감사기록 관리 등의 보안 수준이 높은 업무를 수행하기 때문에 다양한 인증 방법 및 다단계 인증을 고려하여 인증 수준을 강화할 수 있다. 사용자를 식별하는 인증 방법은 크게 3가지로 구분할 수 있다.
* 지식기반 : 사용자가 가진 지식이나 알고 있는 정보를 확인하여 인증 (아이디/비밀번호 등)
* 소유기반 : 소지한 인증수단을 이용하여 인증 (보안카드, OTP 등)
* 생체기반 : 사용자가 가진 특징을 이용하여 인증 (지문, 홍채 등)
계정 및 비밀번호와 같은 인증데이터도 제3자에게 노출되거나 변경되지 않아야 하며, 인증데이터의 재사용 공격을 방지해야 한다.

===암호통신===
데이터 암·복호화를 수행하는 시스템 및 모듈 간에 통신 구간을 통하여 데이터, 암·복호화 키, 정책 등의 중요 정보가 전송된다. 통신 구간이 보호되지 않을 경우 네트워크 도청으로 정보수집 및 분석이 가능하기 때문에 전송 데이터의 기밀성·무결성 유지를 위해 전송 구간에 대한 보안 수준을 보장하는 것은 중요하다. 물리적으로 분리된 모듈 구성인 경우 송·수신되는 통신 데이터는 SSL, IPSec 등을 사용할 수 있다.

===보안감사===
; 보안감사
암호화 대상 컬럼에 대한 암·복호화 수행 및 정책 관리에 대한 행위를 추적하는 보안 감사 정책을 통해 개인정보 및 업무 활동상의 중요 정보 자산을 보호해야 한다. 보안 감사를 크게 분류하면 감사 수준에 따른 정보 기록과 감사 정보에 대한 보호의 측면으로 나눌 수 있다. 감사 수준에 따른 보안 감사를 통하여 암호화 정책 설정 및 변경 이력, 암·복호화 키의 변경 및 사용 이력, 접근 및 작업 내역, 성능 변화 등에 대한 기록이 가능하다.
* 정책 설정 및 변경 : 암호화 대상 DB등록, 백업 및 복구 내역 등
* 암·복호화 키의 변경(생성/폐기) 및 사용 이력
* 접근 및 작업 내역 : 암호화 대상(테이블, 컬럼 등)에 대한 접근내역과 비인가 사용자에 대한 통제 결과, 데이터 조회·수정·추가·삭제 내역
* 성능 변화 : 암/복호화 엔진의 성능(분당/처리속도, 암/복호화 처리량 등) 변화를 기록
특히 이벤트 주체, 암호화 대상, 접근 정보 및 시간, 작업 내역 등의 상세한 감사 기록은 감사 자료를 활용한 탐지 및 추적에 유용한 자료로서 활용이 가능하기 때문에 다양한 수준의 보안 감사는 중요 정보 자산의 보호를 위해 중요한 고려 사항이다. 감사 정보의 보호를 위하여 감사 데이터는 인가된 관리자만이 접근할 수 있도록 하고 감사 관리자는 감사 데이터의 조회 및 모니터링만 가능하도록 하여 관리자 권한의 남용을 방지하여야 하며, 감사 데이터의 유출 및 위·변조가 발생하지 않도록 조치하여야 한다. 추가적으로 감사 정보 저장 시 저장소가 포화상태가 되어 정보 손실이 발생하지 않도록 정기적으로 저장소의 상태를 체크하여야 하고, 보안 수준이 높은 감사 정보는 보안 관리자에게 통보하여 다양한 위협에 대비하여야 한다.

; 보안관리
암·복호화 키와 정책은 안전하게 관리되지 않으면 다양한 공격에 노출될 수 있다. 암·복호화 키와 정책이 노출되면 암호화된 데이터의 복호화가 가능하고 암·복호화 키 및 정책의 파괴, 유출, 변조 등의 다양한 위협이 발생할 수 있다. 암·복호화 키 및 저장소의 보호를 위하여 마스터키, 암·복호화 키 및 정책은 인가된 관리자만이 생성·변경·삭제할 수 있도록 하여야 한다. DB 서버에 암·복호화 키와 정책을 저장하는 경우에는 반드시 암호화시켜 저장하여야 하며, 암·복호화 키의 사용을 위해 복호화하는 경우에는(여러 차례에 걸쳐 서로 다른 키로 암호화 하였더라도) 최종적으로는 패스워드 입력에 의해 복호화 되거나 공개키 기반의 안전한 구조에 의해 복호화 되어야 한다. 암·복호화 키 및 정책의 복구는 인가된 관리자에 의하여 수행되어야 하며 암·복호화키가 생성·변경되면 해당 암·복호화 키의 백업을 수행하는 등 안전하게 백업 및 복구가 되도록 절차를 마련하여야 한다.

{{각주}}

==참고자료==
* 김영린, 〈DB 암호화 기술 가이드〉, 《금융보안연구원》, 2014-12
* 이호균·이승민·남택용, 〈[https://ettrends.etri.re.kr/ettrends/103/0905000762/22-1_105_113.pdf 데이터베이스 암호화 기술과 제품 동향]〉, 《전자통신동향분석》, 2007-02
* 날으는 물고기, 〈[https://blog.pages.kr/618 DB 암호화, 그 특성 및 구축 방법]〉, 《블로그》, 2010-02-02
* i kiss you, 〈[https://nakyungpapa.tistory.com/74 DB 암호화]〉, 《티스토리》, 2012-09-06
* 신동규 기자, 〈[http://www.dt.co.kr/contents.htm?article_no=2012112902011860785002 (알아봅시다) 다양한 DB 암호화 방식의 장단점]〉, 《디지털타임스》, 2012-11-28
* 따, 〈[https://m.blog.naver.com/PostView.nhn?blogId=futureds&logNo=90158653671&proxyReferer=https:%2F%2Fwww.google.com%2F 다양한 DB 암호화 방식의 장단점]〉, 《네이버 블로그》, 2012-12-10
* 김태형 기자, 〈[https://www.boannews.com/media/view.asp?idx=50713&kind=3 개인정보보호 관련 법·규제 강화로 DB암호화 시장 ‘파죽지세’]〉, 《보안뉴스》, 2016-05-25
* euishin0110, 〈[https://m.blog.naver.com/PostView.nhn?blogId=euishin0110&logNo=220741868061&proxyReferer=https:%2F%2Fwww.google.com%2F DB 보안 (DB 암호화)]〉, 《네이버 블로그》, 2016-06-21
* 열린 기술자, 〈[https://sarc.io/index.php/oracledatabase/616-2016-09-21-16-28-36 데이터베이스 암호화 기초]〉, 《삵》, 2017-10-23
* Leejisoo, 〈[https://javaplant.tistory.com/26 암호화 양방향,단방향,공개키(비대칭키),비공개키(대칭키) 개념/분류 알고리즘 정리]〉, 《티스토리》, 2018-05-08
* 김승민, 〈[https://k0102575.github.io/articles/2020-03/hash (Security) 암호화 알고리즘 – 단방향 암호화, Hash]〉, 《깃허브》, 2020-03-25
* 사용자 제나나, 〈[https://jennana.tistory.com/54 (암호시스템)하이브리도 암호]〉, 《티스토리》, 2020-09-15

== 같이 보기 ==
* [[데이터베이스]]
* [[암호화]]
* [[복호화]]
* [[대칭 키]]
* [[비대칭 키]]

{{보안|검토 필요}}