해시넷
"데이터베이스 암호화"의 두 판 사이의 차이
(218.146.11.195 (토론)의 409654판 편집을 되돌림) |
|||
| 4번째 줄: | 4번째 줄: | ||
개인정보보호법이 제정되면서 고객의 개인정보를 소홀히 관리하거나, 암호화하지 않은 고객정보가 외부로 유출될 경우 대규모 집단 소송 및 경영진의 형사처벌 등 강력한 처벌을 요구하기 때문에 데이터베이스 암호화는 거의 필수적인 요소가 되었다. 국가 정보원 IT 보안 인증 사무국은 데이터베이스 암호화 제품 구축에 있어 안정성이 검증된 암호모듈 및 알고리즘의 사용, 암호화 키 생성, 접근, 갱신, 폐기 등의 안정성 확보, 암호문, 인덱스 등 중요 데이터의 안정성 확보, 암호키, 암호문 등에 대한 비인가자의 접근 통제, 전송 데이터의 기밀성, 무결성 유지, 제품 사용자의 신원 확인 및 검증, 제품 관련 중요 이벤트에 대한 감사 기록 시스템 구축 등을 권고하고 있다. 전문가들은 데이터베이스 암호화 구축 시 핵심 고려사항으로 암호화 대상 및 범위를 위험도 분석 결과에 따라 철저하게 분석,국내외 연구기관에서 검증된 암호화 알고리즘의 적용, 개인 정보는 양방향 개인정보 필수 적용, 암호화 인덱스 지원, 성능을 고려해 부분 암호화 적용, 암호화, 복호화 키, 마스터 키 등 모든 키를 생성에서 폐기까지 안전하게 관리해야 한다고 조언했다.<ref>신동규 기자, 〈[http://www.dt.co.kr/contents.htm?article_no=2012112902011860785002 (알아봅시다) 다양한 DB 암호화 방식의 장단점]〉, 《디지털타임스》, 2012-11-28</ref> | 개인정보보호법이 제정되면서 고객의 개인정보를 소홀히 관리하거나, 암호화하지 않은 고객정보가 외부로 유출될 경우 대규모 집단 소송 및 경영진의 형사처벌 등 강력한 처벌을 요구하기 때문에 데이터베이스 암호화는 거의 필수적인 요소가 되었다. 국가 정보원 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> | + | 데이터베이스 암호화는 데이터를 암호화하여 저장하고, 권한이 있는 사람 혹은 서버만이 해당 데이터를 복호화할 수 있도록 하여 데이터를 보호하는 기술이다. 암호화를 사용하면 해커가 데이터베이스를 해킹해서 데이터를 들고 나가더라도, 암호화된 데이터를 읽을 수 없다. 암호화 방식과 암호화 알고리즘 등에 대한 결정은 업무 목적이나 데이터 중요도 등에 따라 달라질 수 있지만 관련 기관에서 기본 규약으로 정의하여 권고 또는 강제하는 사항에 대한 확인 및 적용해야한다. 암호화를 구축한 이후에는 암호화키에 대한 관리 및 복호화 권한 소유자, 복호화 관련 로깅정보 확인 등을 통해 암호화에 대한 통제가 적절하게 이루어지고 있는지, 보완하거나 개선할 사항은 없는지 등에 대한 지속적인 모니터링이 필요하다. 데이터베이스 접근 제어 외에 데이터베이스 보안에 대한 국내외 법률과 규정은 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> | ||
==암호키 관리== | ==암호키 관리== | ||
| 11번째 줄: | 14번째 줄: | ||
==알고리즘== | ==알고리즘== | ||
===양방향 알고리즘=== | ===양방향 알고리즘=== | ||
| − | + | 암호화, 복호화 모두가 가능한 알고리즘으로, 개인정보를 암호화 할 때 사용한다. 대표적으로 대칭키(비공개키)와 비대칭키(공개키)방식으로 나눠진다. 대칭키 방식은 암호화, 복호화 시 모두 동일한 키를 사용하기 때문에 키를 비공개로한다. 속도가 빠르지만, 송신 측에서 수신 측에 암호를 전달하는 과정에서 키가 노출될 수 있다. DES, AES가 대표적인 예다. 비대칭키 방식은 암호화 복호화에 서로 다른 키를 사용해 하나의 키는 공개키로 하고, 다른 하나의 키는 비공개키로하여 대칭키의 키 배송 문제를 근본적으로 차단했다. 대칭키 방식에 비해 느리다는 단점이 있다. RSA가 대표적이다. | |
===단방향 알고리즘=== | ===단방향 알고리즘=== | ||
| − | + | 암호화는 수행하지만, 복화하가 불가능한 알고리즘으로 비밀번호를 암호화 할 때 사용한다. 해쉬 방식이 대표적이다. 해쉬 함수에는 MD5, SHA, HAS 등이 있는데, MD5, SHA-1, HAS-180은 보안상 취약하기 때문에 SHA-256,512를 쓰는 것이 좋다. 중복이 적을수록 좋은 해쉬이다.<ref>Leejisoo, 〈[https://javaplant.tistory.com/26 암호화 양방향,단방향,공개키(비대칭키),비공개키(대칭키) 개념/분류 알고리즘 정리]〉, 《티스토리》, 20118-05-08</ref> | |
| + | |||
==시스템 구성 요소== | ==시스템 구성 요소== | ||
| 53번째 줄: | 57번째 줄: | ||
==분류== | ==분류== | ||
| − | + | 데이터베이스 접근 제어 솔루션과 암호화 솔루션 두 가지의 솔루션이 있다. 데이터베이스 접근 제어 솔루션에는 게이트웨이, 스니핑, 에이전트 방식등이 있다. 데이터베이스 암호화 솔루션 중 컬럼 암호화 방식은 암호화, 복호화의 위치에 따라 플러그인 방식과 API방식, 하이브리드 방식 등이 있고, 블록 단위 암호화 방식에는 TDE 방식과 파일 암호화 방식 등이 있다. | |
===API 방식=== | ===API 방식=== | ||
외부 애플리케이션 영역에서 암호화, 복호화를 수행하는 것으로 데이터베이스 서버의 성능저하 없이 구축이 가능하고, 구축 비용이 상대적으로 저렴하다는 장점이 있다. 단점으로는 데이터베이스 내부에서 수행되는 연산처리 과정에서 암호화한 데이터 처리가 불가능하고, 내부에서 업무 처리가 필요한 경우 별도의 데이터베이스 관리 시스템 API 모듈이 필요하다는 것과 암호화 대상 데이터와 관련된 모든 소스 영역의 수정이 필요하다는 점이 있다. 또한 향후에 응용 시스템의 신규/ 변경 등에 따라 관리 효율성이 저하되고, 접근제어 솔루션을 추가 도입하게 되면 비용이 발생한다. | 외부 애플리케이션 영역에서 암호화, 복호화를 수행하는 것으로 데이터베이스 서버의 성능저하 없이 구축이 가능하고, 구축 비용이 상대적으로 저렴하다는 장점이 있다. 단점으로는 데이터베이스 내부에서 수행되는 연산처리 과정에서 암호화한 데이터 처리가 불가능하고, 내부에서 업무 처리가 필요한 경우 별도의 데이터베이스 관리 시스템 API 모듈이 필요하다는 것과 암호화 대상 데이터와 관련된 모든 소스 영역의 수정이 필요하다는 점이 있다. 또한 향후에 응용 시스템의 신규/ 변경 등에 따라 관리 효율성이 저하되고, 접근제어 솔루션을 추가 도입하게 되면 비용이 발생한다. | ||
===플러그인 방식=== | ===플러그인 방식=== | ||
| − | 데이터베이스 관리 | + | 암호화 관련된 보안정책 데이터베이스와 암호화 및 복호화 처리를 위한 서버엔진을 데이터베이스 관리 시스템에 플러그인 시킨 방식으로 필터 방식이라고도 한다. 데이터베이스 레벨의 확장성 프로시져 기능을 이용하여 데이터베이스 관리 시스템에 플러그인 모듈로 동작한다. 구축이 용이하고, 애플리케이션으로부터 독립성을 제공한다. 모든 작업이 그래픽유저인터페이스(GUI) 기반으로 이루어져 관리 편의성이 높고, 암호화 컬럼에 대한 일치검색, 범위 검색 인덱스 지원이 용이하다는 장점이 있다. 대표적인 단점은 성능 이슈가 발생했을 때 쿼리 수정이 필요하고, 데이터베이스 서버에 직접적인 부하가 걸려 성능을 고려할 필요가 있다는 것이다. 기존 테이블과 동일한 이름의 뷰가 생성되는 뷰어방식과, 복호화 뷰에 DML 요청이 들어오면 평문 데이터를 암호화하여 암호화 테이블에 DML 처리하는 역할을 하는 트리거 방식이 있다. |
===하이브리드 방식=== | ===하이브리드 방식=== | ||
| 70번째 줄: | 74번째 줄: | ||
===TDE 방식=== | ===TDE 방식=== | ||
| − | 암호를 풀 수 있는 암호화 키를 데이터베이스 서버에 파일 형태로 두는 방식으로, 속도가 빠르고 애플리케이션을 수정하지 않아도 된다는 장점이 있지만, CPU 부하가 많이 걸리고, 키 관리가 어려워 데이터베이스 서버 해킹 시 키가 유출될 수 있다는 단점이 있다.<ref>열린 기술자, 〈[https://sarc.io/index.php/oracledatabase/616-2016-09-21-16-28-36 데이터베이스 암호화 기초〉, | + | 암호를 풀 수 있는 암호화 키를 데이터베이스 서버에 파일 형태로 두는 방식으로, 속도가 빠르고 애플리케이션을 수정하지 않아도 된다는 장점이 있지만, CPU 부하가 많이 걸리고, 키 관리가 어려워 데이터베이스 서버 해킹 시 키가 유출될 수 있다는 단점이 있다.<ref>열린 기술자, 〈[https://sarc.io/index.php/oracledatabase/616-2016-09-21-16-28-36 데이터베이스 암호화 기초〉, 《삵》, 2017-10-23</ref> |
{{각주}} | {{각주}} | ||
==참고자료== | ==참고자료== | ||
| + | *신동규 기자, 〈[http://www.dt.co.kr/contents.htm?article_no=2012112902011860785002 (알아봅시다) 다양한 DB 암호화 방식의 장단점]〉, 《디지털타임스》, 2012-11-28 | ||
*euishin0110, 〈[https://m.blog.naver.com/PostView.nhn?blogId=euishin0110&logNo=220741868061&proxyReferer=https:%2F%2Fwww.google.com%2F DB 보안 (DB 암호화)]〉, 《네이버 블로그》, 2016-06-21 | *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://blog.pages.kr/618 DB 암호화, 그 특성 및 구축 방법]〉, 《블로그》, 2010-02-02 | ||
| + | *Leejisoo, 〈[https://javaplant.tistory.com/26 암호화 양방향,단방향,공개키(비대칭키),비공개키(대칭키) 개념/분류 알고리즘 정리]〉, 《티스토리》, 20118-05-08 | ||
*이호균·이승민·남택용, 〈[https://ettrends.etri.re.kr/ettrends/103/0905000762/22-1_105_113.pdf 데이터베이스 암호화 기술과 제품 동향]〉, 《전자통신동향분석》, 2007-02 | *이호균·이승민·남택용, 〈[https://ettrends.etri.re.kr/ettrends/103/0905000762/22-1_105_113.pdf 데이터베이스 암호화 기술과 제품 동향]〉, 《전자통신동향분석》, 2007-02 | ||
*펜타시큐리티시스템 – https://www.pentasecurity.co.kr/database-encryption/ | *펜타시큐리티시스템 – https://www.pentasecurity.co.kr/database-encryption/ | ||
*따, 〈[https://m.blog.naver.com/PostView.nhn?blogId=futureds&logNo=90158653671&proxyReferer=https:%2F%2Fwww.google.com%2F 다양한 DB 암호화 방식의 장단점]〉, 《네이버 블로그》, 2012-12-10 | *따, 〈[https://m.blog.naver.com/PostView.nhn?blogId=futureds&logNo=90158653671&proxyReferer=https:%2F%2Fwww.google.com%2F 다양한 DB 암호화 방식의 장단점]〉, 《네이버 블로그》, 2012-12-10 | ||
| − | *열린 기술자, 〈[https://sarc.io/index.php/oracledatabase/616-2016-09-21-16-28-36 데이터베이스 암호화 기초〉, | + | *열린 기술자, 〈[https://sarc.io/index.php/oracledatabase/616-2016-09-21-16-28-36 데이터베이스 암호화 기초〉, 《삵》, 2017-10-23 |
| 85번째 줄: | 92번째 줄: | ||
* [[데이터베이스]] | * [[데이터베이스]] | ||
* [[암호화]] | * [[암호화]] | ||
| + | * [[복호화]] | ||
| + | * [[대칭 키]] | ||
| + | * [[비대칭 키]] | ||
{{보안|토막글}} | {{보안|토막글}} | ||
2021년 1월 11일 (월) 17:04 판
데이터베이스 암호화(database encryption) 또는 간략히 DB 암호화란 데이터베이스의 내용을 암호화하는 것을 말한다. 주민등록번호, 신용카드번호 등 민감한 개인정보를 데이터베이스에 저장한 경우, 해킹 등으로 유출될 것에 대비하여 DB 내용을 암호화하는 것이 필요하다. 구현 방식에 따라 여러 가지가 있고, 각각의 데이터 처리 메커니즘이 다르다. DB 암호화 솔루션에는 펜타시큐리티시스템㈜의 디아모(D’Amo), ㈜한컴시큐어의 제큐어디비(XecureDB), ㈜케이사인의 시큐어디비(SecureDB) 등이 있다.
개요
개인정보보호법이 제정되면서 고객의 개인정보를 소홀히 관리하거나, 암호화하지 않은 고객정보가 외부로 유출될 경우 대규모 집단 소송 및 경영진의 형사처벌 등 강력한 처벌을 요구하기 때문에 데이터베이스 암호화는 거의 필수적인 요소가 되었다. 국가 정보원 IT 보안 인증 사무국은 데이터베이스 암호화 제품 구축에 있어 안정성이 검증된 암호모듈 및 알고리즘의 사용, 암호화 키 생성, 접근, 갱신, 폐기 등의 안정성 확보, 암호문, 인덱스 등 중요 데이터의 안정성 확보, 암호키, 암호문 등에 대한 비인가자의 접근 통제, 전송 데이터의 기밀성, 무결성 유지, 제품 사용자의 신원 확인 및 검증, 제품 관련 중요 이벤트에 대한 감사 기록 시스템 구축 등을 권고하고 있다. 전문가들은 데이터베이스 암호화 구축 시 핵심 고려사항으로 암호화 대상 및 범위를 위험도 분석 결과에 따라 철저하게 분석,국내외 연구기관에서 검증된 암호화 알고리즘의 적용, 개인 정보는 양방향 개인정보 필수 적용, 암호화 인덱스 지원, 성능을 고려해 부분 암호화 적용, 암호화, 복호화 키, 마스터 키 등 모든 키를 생성에서 폐기까지 안전하게 관리해야 한다고 조언했다.[1]
데이터베이스 암호화는 데이터를 암호화하여 저장하고, 권한이 있는 사람 혹은 서버만이 해당 데이터를 복호화할 수 있도록 하여 데이터를 보호하는 기술이다. 암호화를 사용하면 해커가 데이터베이스를 해킹해서 데이터를 들고 나가더라도, 암호화된 데이터를 읽을 수 없다. 암호화 방식과 암호화 알고리즘 등에 대한 결정은 업무 목적이나 데이터 중요도 등에 따라 달라질 수 있지만 관련 기관에서 기본 규약으로 정의하여 권고 또는 강제하는 사항에 대한 확인 및 적용해야한다. 암호화를 구축한 이후에는 암호화키에 대한 관리 및 복호화 권한 소유자, 복호화 관련 로깅정보 확인 등을 통해 암호화에 대한 통제가 적절하게 이루어지고 있는지, 보완하거나 개선할 사항은 없는지 등에 대한 지속적인 모니터링이 필요하다. 데이터베이스 접근 제어 외에 데이터베이스 보안에 대한 국내외 법률과 규정은 2가지를 주요하게 강조하는데 첫 번째는 암호화를 통한 데이터베이스 보안이고, 두 번째는 염격한 암호키 관리를 통해 데이터를 보호하라는 것이다. 데이터베이스 암호화의 목적은 비정상적 데이터 유출이 발생할 경우, 복호화를어렵게 만드는 것이다. 암호키는 암호화 뿐만 아니라 복호화 할 때도 사용하므로 매우 신중하게 관리하여야 한다. 랜덤 키에 의해 암호화된 데이터는 해커들이 복호화를 하기 어렵게 만든다. 따라서 복호화를 해야만 하는 사용자나 시스템 이외에 다른 사용자가 암호키에 접근하는 것을 통제해야 한다.[2]
특징
데이터베이스 암호화의 보안성은 강화된 국정원 보안 적합성 검증 기준을 만족하여야 한다. 데이터베이스 보안 솔루션의 주 목적은 중요한 정보를 안전한 알고리즘으로 암호화하고, 이 데이터를 암호화 또는 복호화 할 수 있는 키를 기준에 맞도록 안전한 관리체계를 제공하는 것이다. 따라서 개정된 보안 적합성 검증 기준에서 요구하는 “암호 모듈 검증 기준”을 만족하여야 한다. 또한 데이터베이스 운영을 불가능하게 할 정도의 제약사항이나 성능저하는 최소한으로 해야 한다. 데이터베이스가 운영되지 못한다면 데이터베이스 암호화는 있으나마나 한 것이기 때문이다. 이 외에도 데이터베이스 암호화는 안전한 알고리즘으로 최고의 보안성을 보장하는 안전한 알고리즘, 인덱스를 암호화하고 암호화된 인덱스를 통한 색인검색을 지원하는 인덱스 암호화 및 검색, 장시간 소요되는 데이터베이스 암호화 작업으로 인한 서비스의 중단이 없거나 최소로 하는 가용성 등 여러 가지 요소들을 필요로 한다.[3]
암호키 관리
암호키가 하나일 경우 데이터베이스 암호화를 하게 되면 손쉽게 구축이 되지만, 해당 키가 유출되면 매우 위험한 상황에 처하게 된다는 단점이 있다. 따라서 업무의 범위나 시스템의 역할에 따라 암호키를 분리하고, 암호키의 접근 제어 정책이 수반되어야 한다. 데이터베이스 관리 시스템의 암호화 기능을 사용하는 경우, 암호키를 보관하는 가장 손쉬운 방법은 제한된 테이블이나 파일에 저장하는 것이다. 이 방법은 데이터베이스 관리자가 접근 권한을 가진 경우가 대부분이고 임의의 복호화 작업이 가능하기 때문에 위험할 수 있어, 데이터베이스 서버와 별개의 독립된 머신으로 암호키를 관리하는 것이 바람직하다. 이렇게 관리되는 암호키는 시스템 상의 접근제어는 물론 강력한 인증과 파일 접근 제한 등의 보안조치를 통해 안전하게 관리되고, 접근제어 기능을 통해 관리자나 임의의 사용자에 의한 암호키 유출도 막을 수 있다.
알고리즘
양방향 알고리즘
암호화, 복호화 모두가 가능한 알고리즘으로, 개인정보를 암호화 할 때 사용한다. 대표적으로 대칭키(비공개키)와 비대칭키(공개키)방식으로 나눠진다. 대칭키 방식은 암호화, 복호화 시 모두 동일한 키를 사용하기 때문에 키를 비공개로한다. 속도가 빠르지만, 송신 측에서 수신 측에 암호를 전달하는 과정에서 키가 노출될 수 있다. DES, AES가 대표적인 예다. 비대칭키 방식은 암호화 복호화에 서로 다른 키를 사용해 하나의 키는 공개키로 하고, 다른 하나의 키는 비공개키로하여 대칭키의 키 배송 문제를 근본적으로 차단했다. 대칭키 방식에 비해 느리다는 단점이 있다. RSA가 대표적이다.
단방향 알고리즘
암호화는 수행하지만, 복화하가 불가능한 알고리즘으로 비밀번호를 암호화 할 때 사용한다. 해쉬 방식이 대표적이다. 해쉬 함수에는 MD5, SHA, HAS 등이 있는데, MD5, SHA-1, HAS-180은 보안상 취약하기 때문에 SHA-256,512를 쓰는 것이 좋다. 중복이 적을수록 좋은 해쉬이다.[4]
시스템 구성 요소
- 암호화 엔진(Cryptographic engine): 암호화 기능을 수행한다.
- 키 저장소(Key vault): 안전한 키 저장소이다.
- 키 목록(key mainfest): 앨리어스, 패밀리, 상태, 엔진 등을 포함하는 키의 세부정보 트랙이다.
- 키 관리자(key manager): 키 저장소와 키 목록 안에서 키를 관리한다
- 보호 데이터(protected data): 암호화를 통해서 보호되는 데이터들이다.
- 암호 소비자(cryptographic consumer): 암호화, 복호화가 필요한 데이터를 관리하고 처리하는 주체이다.
- 암호 제공자(Cryptographic provider): 암호 엔진과 암호 소비자 사이를 연결하는 주체이다.[5]
계층별 데이터 암호화
네트워크 계층
네트워크 계층은 서버와 클라이언트가 서로 교차 연결되어 데이터의 송신과 수신이 이루어지는 곳으로, 응용 서버와 데이터베이스 서버, 네트워크로 연결된 저장장치와 서버, 서버와 단말 등의 통신이 이루어지는 계층이다. 공격자는 통신 채널을 도청하여 송수신 데이터를 수집하거나, 데이터를 탈취할 수 있다. 네트워크 계층의 암호화는 물리적으로 분리되어 있는 송신자와 수신자 사이에서 안전한 암호화를 제공해 줄 수 있는데, 안전한 암호화를 위해서는 송신자와 수신자 사이에서 암호화 키를 안전하게 생성하고 관리해야 한다. 데이터를 보호하기 위해 다음과 같은 방법으로 암호화를 한다.
- 송신자와 수신자 사이의 통신 채널 자체를 암호화하는 방식은 모든 데이터를 암호화하기 때문에 효율이 떨어질 수 있지만, 송수신 사실까 감출 수 있어 안전성이 높다.
- 송수신되는 데이터 중에서 이미 지정한 정보만을 선택적으로 암호화하는 방식은 꼭 필요한 정보만을 암호화함으로써 효율을 높인 것으로, 선택적 암호화 기술이 요구된다.
운영 체제 계층
모든 데이터는 컴퓨터에 저장될 때 파일의 형태로 저장되는데, 운영체제 계층에서의 암호화는 운영체제가 파일을 저장하는 과정에 암호화 단계를 추가한 것이다. 이렇게 암호화를 하게 되면 데이터베이스나 앱은 암호화 처리를 고려하지 않아도 되어, 기존 시스템에 적용할 때 번거로운 수정이나 변경이 필요하지 않다는 장점이 있다. 하지만 대부분의 운영체제 레벨 암호화 제품이 암호화 키를 사용자 기기나 서버의 내부에 저장하고, 세분화된 보안 정책 설정 및 접근 제어가 어렵다는 등의 한계성이 있다.
- 저장장치에 암호화 기능을 탑재하는 방식은 HDD 등의 저장장치가 암호화와 복호화를 자체적으로 수행하는 것으로 저장되는 모든 파일이 암호화된다.
- 파일 시스템이 암호화와 복호화를 수행하는 방식은 OS 파일 시스템이 암호화를 수행하는 것으로 저장되는 모든 파일이 암호화된다.
- 특정 파일만 암호화하여 저장하는 방식은 선택적으로 파일을 암호화하여 관리하는 것으로 디렉터리나 폴더 단위로 암호화도 가능하다.
데이터베이스 관리 시스템 엔진 계층
데이터베이스 관리 시스템 엔진(DBSM)은 데이터베이스 서버의 내부에서 데이터의 입출력과 저장을 관리하는 핵심 모듈로 많은 데이터베이스 관리 시스템 제품들이 자체적으로 암호화 기능을 제공한다. 데이터베이스에 정보를 저장하거나 읽을 때 암호화 적용 전후로 동일한 동작을 하기 때문에, 운영체제 계층 암호화 방법과 마찬가지로 기존 응용 프로그램은 수정할 필요가 없다는 것이 장점이다. 이와 같은 특징을 응용 프로그램에 대한 투명성이라고 정의해 투명한 데이터 암호화(Transparent Data Encryption, TDE)라고도 한다. 하지만 대부분의 투명한 데이터 암호화 방식 암호화제품은 복호화된 데이터를 메모리에 두는 등 유출의 위험을 안고 있고 키 관리 측면에서 암호화 키가 데이터와 동이란 저장소에 있기 때문에 보안적으로 완벽하다 할 수 없어, 데이터베이스 관리 시스템 레벨의 암호화제품을 적용하기 전 키 관리와 메모리상 복호화 데이터 처리등을 고려해야 한다.
데이터베이스 관리 시스템 패키지 계층
이 계층에서는 외부 요청을 수신하고 엔진이 처리하도록 지시와 관리가 이루어진다. 이 계층에서의 암호화는 상위 계층의 앱은 수행하지 않아도 되고, 데이터베이스 관리 시스템 엔진이 이미 암호화된 데이터를 받고 처리하기 때문에 메모리 보안 위협 문제가 없다는 장점이 있다. 선택적으로 데이터베이스 테이블을 지정하여 암호화할 수 있기 때문에 성능면에서도 우수한 방법이다. 데이터베이스 관리 시스템 패키지 계층 암호화 제품은 데이터가 처리될 때 마다 암호화나 복호화가 일어나기 때문에 서버에 부담을 줄 수 있다. 따라서 실제 환경에 적용할 때는 적절한 방법을 선택 적용하여 서버 부담을 줄일 수 있는 방법을 제공해야 한다.
데이터베이스 관리 시스템 프로시져 계층
이 계층에 암호화를 적용하려면, 데이터베이스 서버와 정보를 주고받을 때 암호화를 지원하는 별도의 API를 사용하여 암호화를 처리해야 한다. 앱과 데이터베이스 서버와 별도 시스템에 존재한다면 네트워크 계층 암호화를 추가로 적용할 수 있다. 기존 데이터베이스 관리 시스템 API를 대신해 암호화 API를 호출하여 데이터베이스 관리 시스템 패키지 계층 암호화가 가지는 모든 장점을 그대로 가지고, 암호화, 복호화 연산 처리 부담이 데이터베이스 서버에 전가되지 않는다는 장점이 있다. 네트워크 환경에서도 네트워크 구간에서 발생하는 보안 위협에 대응할 수 있다는 것 또한 큰 장점이다. 다만 어느 정도의 응용프로그램 수정이 필요하다는 것이 단점이다.
웹 어플리케이션 계층
웹 서버, 웹 어플리케이션 서버, 데이터베이스 서버로 구성되는 multi-tier 구성으로 이루어지고, 웹 서버와 데이터베이스 서버를 중개하며 데이터의 흐름을 제어하는 역할을 한다. 데이터베이스 서버와 연결하는 부분의 기능은 데이터베이스관리 시스템 프로시져의 어플리케이션과 같은 기능을 수행하기 때문에, 암호화가 이루어지는 위치만 다를 뿐, 이 계층에서의 암호화 방법은 데이터베이스 관리 시스템 프로시져 계층 암호화 방법과 동일하며 동일한 장단점을 가진다.
비즈니스 어플리케이션 계층
내부 데이터 관리를 위해 데이터베이스 관리 시스템을 사용하더라도 저장솔ㄹ 관리하는 별도의 시스템 형태로 포함되어 있어, 비즈니스 어플리케이션 개발자가 데이터베이스 관리 시스템을 직접 호출하거나 이용하는 것이 불가능하다. 이 계층 암호화를 위해서는 저장소 관리 서브 시스템을 수정하거나 보조 서브 시스템을 추가해야한다. 이 계층은 독자의 설계와 구현 원칙에 비해 복잡하게 구현되기 때문에, 새로운 서브 시스템을 추가하고 수정하는 일에 많은 노력과 비용이 소요된다. 웹 어플리케이션 계층의 방법과 동일하므로 동일한 장단점을 가진다. [6]
분류
데이터베이스 접근 제어 솔루션과 암호화 솔루션 두 가지의 솔루션이 있다. 데이터베이스 접근 제어 솔루션에는 게이트웨이, 스니핑, 에이전트 방식등이 있다. 데이터베이스 암호화 솔루션 중 컬럼 암호화 방식은 암호화, 복호화의 위치에 따라 플러그인 방식과 API방식, 하이브리드 방식 등이 있고, 블록 단위 암호화 방식에는 TDE 방식과 파일 암호화 방식 등이 있다.
API 방식
외부 애플리케이션 영역에서 암호화, 복호화를 수행하는 것으로 데이터베이스 서버의 성능저하 없이 구축이 가능하고, 구축 비용이 상대적으로 저렴하다는 장점이 있다. 단점으로는 데이터베이스 내부에서 수행되는 연산처리 과정에서 암호화한 데이터 처리가 불가능하고, 내부에서 업무 처리가 필요한 경우 별도의 데이터베이스 관리 시스템 API 모듈이 필요하다는 것과 암호화 대상 데이터와 관련된 모든 소스 영역의 수정이 필요하다는 점이 있다. 또한 향후에 응용 시스템의 신규/ 변경 등에 따라 관리 효율성이 저하되고, 접근제어 솔루션을 추가 도입하게 되면 비용이 발생한다.
플러그인 방식
암호화 관련된 보안정책 데이터베이스와 암호화 및 복호화 처리를 위한 서버엔진을 데이터베이스 관리 시스템에 플러그인 시킨 방식으로 필터 방식이라고도 한다. 데이터베이스 레벨의 확장성 프로시져 기능을 이용하여 데이터베이스 관리 시스템에 플러그인 모듈로 동작한다. 구축이 용이하고, 애플리케이션으로부터 독립성을 제공한다. 모든 작업이 그래픽유저인터페이스(GUI) 기반으로 이루어져 관리 편의성이 높고, 암호화 컬럼에 대한 일치검색, 범위 검색 인덱스 지원이 용이하다는 장점이 있다. 대표적인 단점은 성능 이슈가 발생했을 때 쿼리 수정이 필요하고, 데이터베이스 서버에 직접적인 부하가 걸려 성능을 고려할 필요가 있다는 것이다. 기존 테이블과 동일한 이름의 뷰가 생성되는 뷰어방식과, 복호화 뷰에 DML 요청이 들어오면 평문 데이터를 암호화하여 암호화 테이블에 DML 처리하는 역할을 하는 트리거 방식이 있다.
하이브리드 방식
하이브리드 방식은 API 방식과 플러그인 방식이 합쳐진 것으로 플러그인 방식의 성능 저하 이슈 개선을 위해 API 방식의 장점을 채용한 것이다. 성능이 우선시 되는 환경에서는 API를 적용하고, 성능 영향이 덜 민감한 환경에서는 플러글인 방식을 적용하는 식으로 유동성 있게 구축한다. 두 방식의 장점을 모아놓은 것이기 때문에 속도와 성능 개선의 일석이조 효과를 볼 수 있지만, 구축 투자 비용이 상대적으로 높다는 단점이 있다.
인플레이스 방식
플러그인 방식에 데이터베이스 엔진 내부에서 암호화, 복호화 기능을 수행하게 한 것으로, 애플리케이션 환경에서 완변한 독립성을 제공하고, 플러그인 방식보다 더 빠른 암호화 성능을 보인다. 다만 암호화 이외의 접근제어, 보안감사 등 데이터베이스 보안 기능 지원을 위해 별도의 패키지를 사용해야 한다는 단점이 있다.
파일 암호화방식
운영체제 영역의 파일 전체에 암호화, 복호화를 적용하는 방식으로 애플리케이션 환경에서 완벽한 독립성을 제공한다는 장점이 있기는 하지만, 하드웨어나 운영체제 자체에서 발생하는 오류로 인해 서비스 장애가 발생할 수 있다. 파일 시스템을 사용하지 않는 데이터베이스에서는 사용할 수 없고, 운영체제 지원 가능 여부를 확인해야 할 필요가 있다는 단점이 있다.[7]
TDE 방식
암호를 풀 수 있는 암호화 키를 데이터베이스 서버에 파일 형태로 두는 방식으로, 속도가 빠르고 애플리케이션을 수정하지 않아도 된다는 장점이 있지만, CPU 부하가 많이 걸리고, 키 관리가 어려워 데이터베이스 서버 해킹 시 키가 유출될 수 있다는 단점이 있다.[8]
각주
- ↑ 신동규 기자, 〈(알아봅시다) 다양한 DB 암호화 방식의 장단점〉, 《디지털타임스》, 2012-11-28
- ↑ euishin0110, 〈DB 보안 (DB 암호화)〉, 《네이버 블로그》, 2016-06-21
- ↑ 날으는 물고기, 〈DB 암호화, 그 특성 및 구축 방법〉, 《블로그》, 2010-02-02
- ↑ Leejisoo, 〈암호화 양방향,단방향,공개키(비대칭키),비공개키(대칭키) 개념/분류 알고리즘 정리〉, 《티스토리》, 20118-05-08
- ↑ 이호균·이승민·남택용, 〈데이터베이스 암호화 기술과 제품 동향〉, 《전자통신동향분석》, 2007-02
- ↑ 펜타시큐리티시스템 - https://www.pentasecurity.co.kr/database-encryption/
- ↑ 따, 〈다양한 DB 암호화 방식의 장단점〉, 《네이버 블로그》, 2012-12-10
- ↑ 열린 기술자, 〈[https://sarc.io/index.php/oracledatabase/616-2016-09-21-16-28-36 데이터베이스 암호화 기초〉, 《삵》, 2017-10-23
참고자료
- 신동규 기자, 〈(알아봅시다) 다양한 DB 암호화 방식의 장단점〉, 《디지털타임스》, 2012-11-28
- euishin0110, 〈DB 보안 (DB 암호화)〉, 《네이버 블로그》, 2016-06-21
- 날으는 물고기, 〈DB 암호화, 그 특성 및 구축 방법〉, 《블로그》, 2010-02-02
- Leejisoo, 〈암호화 양방향,단방향,공개키(비대칭키),비공개키(대칭키) 개념/분류 알고리즘 정리〉, 《티스토리》, 20118-05-08
- 이호균·이승민·남택용, 〈데이터베이스 암호화 기술과 제품 동향〉, 《전자통신동향분석》, 2007-02
- 펜타시큐리티시스템 – https://www.pentasecurity.co.kr/database-encryption/
- 따, 〈다양한 DB 암호화 방식의 장단점〉, 《네이버 블로그》, 2012-12-10
- 열린 기술자, 〈[https://sarc.io/index.php/oracledatabase/616-2016-09-21-16-28-36 데이터베이스 암호화 기초〉, 《삵》, 2017-10-23
같이 보기
