DB 암호화를 해야 할 경우 대상 필드를 정하는데 고민을 많이 해야 하는 상황이 벌어질 수 있다.
특히나 이미 개발완료된 상황에서 암호화를 적용해야 한다면 더더욱이 그렇다.
쿼리를 전부 수정해야 하므로... 골 아픈 상황이 벌어진다.
아래의 암호화 대상 항목들을 참고해 보자.
여기에 적힌거 외에도 많다.
개인정보보호법, 정보통신 뭐시기... 뭐 하여튼 여기저기 걸리는게 많다.
대충 기억나는게 바이오 정보등도 암호화 대상이라는 거.
국내 DB 암호화 솔루션 디아모와 애슬론의 특징은 포스트 맨 아래에 별도 기록되어 있다.
(필요하면 참고하도록하세요)
개인정보보호 종합포털
위 내용들을 정리해 보면 대략적으로
필수 항목은 주민번호,여권번호, 운전면허번호, 외국인등록번호, 비밀번호, 바이오 정보 등은 필수로
암호화 해야 한다고 하는데, 주민번호 수집은 법적으로 금지를 시켰기 때문에
앞으로 모든 정부 관련기관에서 주민번호를 수집하지 않는다.
(주민등록번호를 수집하는 것 자체가 불법이다.)
그러면 여권번호, 운전면허번호, 외국인등록번호, 비밀번호, 바이오 정보가 남는데
바이오 정보라는 것이 사실 조금은 애매하다.
지문, 홍채(눈:안구) 정보등이야 명확하게 바이오 정보라고 인지할 수 있는데
고객이 장애인이라면, 장애인에 대한 장애유형이나 장애 등급등이 필요 할 수 있는데,
이런 정보까지도 장애유형이라고 할 수 있는지는 조금 애매 한 것 같다.
암호화 목적에 따라 현명하게 잘 판단해야 하는 것 같다.
추가적으로 DB 암호화를 위한 몇몇 솔루션들이 있다.
내가 아는 DB 암호화 솔루션 (상용)이 몇개가 있는데, 다음과 같다.
둘다 DB 암호화를 공공기관에서 요구하는 암호화 규격에 맞게끔 솔루션을 제공해 주고 있다.
특징은 다음과 같다.
a. 테이블을 직접 암호화 하거나
b. 암호화 된 뷰를 제공함으로써, 원본 데이터는 두고 암호화된 뷰를 제공
하는 2가지 방식이 있다.
2) 애슬론
a. 테이블을 직접 암호화
애슬론도 뷰형태로 제공해 주는 방식이 있긴 한것 같은데, 솔루션 업체측에서 권장하지 않는 다고 하여 적지 않았다.
(뷰형태가 맞는지는 모르겠다.)
그런데, 문제가 있다.
암호화 솔루션을 사용하게 되면, 필수적으로
개발 중인 프로젝트에서 사용중인 쿼리문을 수정해야 한다.
참고로 본인은 실무에서 약 1800개의 쿼리를 바꿀뻔 했으나 도저히 암호화 대상필드를 많이 선정해서는
답이 나오질 않아, 최소한으로 법으로 규정된 항목들만 암호화를 진행하여
600개만 바꿨다.
600개의 쿼리를 바꾼다고 생각해봐라 엄청난 노가다와 검증까지...
지금 생각해도 화가 난다.
잠깐 삼천포로 빠졌는데, 다시 본론으로 돌아가
뷰형태로 암호화해서 이용한다고 하면, 수정을 최소화 시킬 수 있으나,
아주 크리티컬한 문제가 있으니,
속도가 느려진다.(데이터 건수에 따라 별 차이가 없을 수 있으나, 조회되는 데이터 건수에 따라 성능이 현저하게 떨어진다.)
속도가 느려지는 문제는 두 솔루션 모두 마찬가지다.
결정적으로 쿼리문을 수정하는 작업이 굉장히 고단한 작업이 될 확률이 높다.
애슬론 같은 경우는 암호화,복호화 함수를 서브쿼리내에 적용할 수가 없다.
서브쿼리에 복호화 함수를 사용한다 해도 최종적으로 복호화가 안된다.
즉, 단일쿼리에서 복호화는 되지만, 쿼리와 쿼리가 이어지는 서브쿼리 함수 내에서는 복호화가 안되기 때문에
쿼리로 해결을 못하고 프로그래밍으로 해결을 해야 하는 경우가 생긴다.
나는 결코 두 암호화 솔루션을 추천하지는 않는다.
차라리 직접 암호화,복호화를 직접하고 말지.
댓글