데이터베이스 암호화 편집하기
최신판 | 당신의 편집 | ||
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> |
==특징== | ==특징== | ||
15번째 줄: | 15번째 줄: | ||
[[파일:DB암호화 플러그인.JPG|썸네일|525픽셀|'''플러그인 방식의 구성 예''']] | [[파일:DB암호화 플러그인.JPG|썸네일|525픽셀|'''플러그인 방식의 구성 예''']] | ||
− | 암호화 관련된 보안정책 데이터베이스와 암호화 및 복호화 처리를 위한 서버 엔진을 데이터베이스 관리 시스템에 플러그인시킨 방식으로, 필터 방식이라고도 한다. 데이터베이스 레벨의 확장성 | + | 암호화 관련된 보안정책 데이터베이스와 암호화 및 복호화 처리를 위한 서버 엔진을 데이터베이스 관리 시스템에 플러그인시킨 방식으로, 필터 방식이라고도 한다. 데이터베이스 레벨의 확장성 프로시져 기능을 이용하여 데이터베이스 관리 시스템에 플러그인 모듈로 동작한다. 구축이 용이하고, 애플리케이션으로부터 독립성을 제공한다. 모든 작업이 그래픽유저인터페이스(GUI) 기반으로 이루어져 관리 편의성이 높고, 암호화 컬럼에 대한 일치검색, 범위 검색 인덱스 지원이 용이하다는 장점이 있다. 대표적인 단점은 암·복호화 시 데이터베이스 서버의 CPU를 사용하기 때문에 성능 이슈가 발생했을 때 쿼리 수정이 필요하고, 데이터베이스 서버에 직접적인 부하가 걸려 성능을 고려할 필요가 있다는 것이다. 그러므로 트랜잭션 처리량이 많지 않아 성능에 대한 민감성이 낮은 시스템의 경우 저렴한 비용으로 구축할 수 있다. 애플리케이션 서버에서 DB계정이 탈취될 경우 복호화된 평문 데이터 유출이 가능하므로 이에 대한 보안 조치가 필요하며, 암호화 컬럼 사이즈 증가, 성능 이슈 등이 있는 경우 일부 애플리케이션을 수정하여 적용이 가능하다. 플러그인 방식의 구성에서 데이터베이스 테이블 또는 컬럼 단위의 암호화를 적용하면 암호화된 테이블 이용을 위하여 추가적인 오브젝트들이 생성되므로, 운영 및 백업 등 데이터베이스에 관련된 작업을 수행할 때 이러한 오브젝트들을 함께 고려하여야 한다. |
:{|class=wikitable width=700 | :{|class=wikitable width=700 | ||
|+플러그인 방식의 기능 | |+플러그인 방식의 기능 | ||
202번째 줄: | 202번째 줄: | ||
이 계층에서는 외부 요청을 수신하고 엔진이 처리하도록 지시와 관리가 이루어진다. 이 계층에서의 암호화는 상위 계층의 앱은 수행하지 않아도 되고, 데이터베이스 관리 시스템 엔진이 이미 암호화된 데이터를 받고 처리하기 때문에 메모리 보안 위협 문제가 없다는 장점이 있다. 선택적으로 데이터베이스 테이블을 지정하여 암호화할 수 있기 때문에 성능 면에서도 우수한 방법이다. 데이터베이스 관리 시스템 패키지 계층 암호화 제품은 데이터가 처리될 때마다 암호화나 복호화가 일어나기 때문에 서버에 부담을 줄 수 있다. 따라서 실제 환경에 적용할 때는 적절한 방법을 선택 적용하여 서버 부담을 줄일 수 있는 방법을 제공해야 한다. | 이 계층에서는 외부 요청을 수신하고 엔진이 처리하도록 지시와 관리가 이루어진다. 이 계층에서의 암호화는 상위 계층의 앱은 수행하지 않아도 되고, 데이터베이스 관리 시스템 엔진이 이미 암호화된 데이터를 받고 처리하기 때문에 메모리 보안 위협 문제가 없다는 장점이 있다. 선택적으로 데이터베이스 테이블을 지정하여 암호화할 수 있기 때문에 성능 면에서도 우수한 방법이다. 데이터베이스 관리 시스템 패키지 계층 암호화 제품은 데이터가 처리될 때마다 암호화나 복호화가 일어나기 때문에 서버에 부담을 줄 수 있다. 따라서 실제 환경에 적용할 때는 적절한 방법을 선택 적용하여 서버 부담을 줄일 수 있는 방법을 제공해야 한다. | ||
− | ===DBMS | + | ===DBMS 프로시져 계층=== |
이 계층에 암호화를 적용하려면, 데이터베이스 서버와 정보를 주고받을 때 암호화를 지원하는 별도의 [[API]]를 사용하여 암호화를 처리해야 한다. 앱과 데이터베이스 서버와 별도 시스템에 존재한다면 네트워크 계층 암호화를 추가로 적용할 수 있다. 기존 데이터베이스 관리 시스템 API를 대신해 암호화 API를 호출하여 데이터베이스 관리 시스템 패키지 계층 암호화가 가지는 모든 장점을 그대로 가지고, 암호화, 복호화 연산 처리 부담이 데이터베이스 서버에 전가되지 않는다는 장점이 있다. 네트워크 환경에서도 네트워크 구간에서 발생하는 보안 위협에 대응할 수 있다는 것 또한 큰 장점이다. 다만 어느 정도의 응용프로그램 수정이 필요하다는 것이 단점이다. | 이 계층에 암호화를 적용하려면, 데이터베이스 서버와 정보를 주고받을 때 암호화를 지원하는 별도의 [[API]]를 사용하여 암호화를 처리해야 한다. 앱과 데이터베이스 서버와 별도 시스템에 존재한다면 네트워크 계층 암호화를 추가로 적용할 수 있다. 기존 데이터베이스 관리 시스템 API를 대신해 암호화 API를 호출하여 데이터베이스 관리 시스템 패키지 계층 암호화가 가지는 모든 장점을 그대로 가지고, 암호화, 복호화 연산 처리 부담이 데이터베이스 서버에 전가되지 않는다는 장점이 있다. 네트워크 환경에서도 네트워크 구간에서 발생하는 보안 위협에 대응할 수 있다는 것 또한 큰 장점이다. 다만 어느 정도의 응용프로그램 수정이 필요하다는 것이 단점이다. | ||
===웹 애플리케이션 계층=== | ===웹 애플리케이션 계층=== | ||
− | [[웹]] 서버, 웹 애플리케이션 서버, 데이터베이스 서버로 구성되는 multi-tier 구성으로 이루어지고, 웹 서버와 데이터베이스 서버를 중개하며 데이터의 흐름을 제어하는 역할을 한다. 데이터베이스 서버와 연결하는 부분의 기능은 데이터베이스관리 시스템 [[ | + | [[웹]] 서버, 웹 애플리케이션 서버, 데이터베이스 서버로 구성되는 multi-tier 구성으로 이루어지고, 웹 서버와 데이터베이스 서버를 중개하며 데이터의 흐름을 제어하는 역할을 한다. 데이터베이스 서버와 연결하는 부분의 기능은 데이터베이스관리 시스템 [[프로시져]]의 애플리케이션과 같은 기능을 수행하기 때문에, 암호화가 이루어지는 위치만 다를 뿐, 이 계층에서의 암호화 방법은 데이터베이스 관리 시스템 프로시져 계층 암호화 방법과 동일하며 동일한 장단점을 가진다. |
===비즈니스 애플리케이션 계층=== | ===비즈니스 애플리케이션 계층=== | ||
379번째 줄: | 379번째 줄: | ||
==참고자료== | ==참고자료== | ||
− | * | + | *펜타시큐리티시스템 공식 홈페이지 – https://www.pentasecurity.co.kr/database-encryption/ |
− | * 이호균·이승민·남택용, 〈[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://blog.pages.kr/618 DB 암호화, 그 특성 및 구축 방법]〉, 《블로그》, 2010-02-02 | + | *날으는 물고기, 〈[https://blog.pages.kr/618 DB 암호화, 그 특성 및 구축 방법]〉, 《블로그》, 2010-02-02 |
− | * i kiss you, 〈[https://nakyungpapa.tistory.com/74 DB 암호화]〉, 《티스토리》, 2012-09-06 | + | *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 | + | *신동규 기자, 〈[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://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 | + | *김태형 기자, 〈[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 | + | *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 | + | *열린 기술자, 〈[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 | + | *Leejisoo, 〈[https://javaplant.tistory.com/26 암호화 양방향,단방향,공개키(비대칭키),비공개키(대칭키) 개념/분류 알고리즘 정리]〉, 《티스토리》, 2018-05-08 |
− | * 김승민, 〈[https://k0102575.github.io/articles/2020-03/hash (Security) 암호화 알고리즘 – 단방향 암호화, Hash]〉, 《깃허브》, 2020-03-25 | + | *김승민, 〈[https://k0102575.github.io/articles/2020-03/hash (Security) 암호화 알고리즘 – 단방향 암호화, Hash]〉, 《깃허브》, 2020-03-25 |
− | * 사용자 제나나, 〈[https://jennana.tistory.com/54 (암호시스템)하이브리도 암호]〉, 《티스토리》, 2020-09-15 | + | *사용자 제나나, 〈[https://jennana.tistory.com/54 (암호시스템)하이브리도 암호]〉, 《티스토리》, 2020-09-15 |
== 같이 보기 == | == 같이 보기 == |