13. 개인정보 보호의 기술적 내용

 

◎ 개인정보 보호의 기술적 내용

 

1. 개인정보 생명주기 전체에 걸친 개인정보 종합 관리 기술

개인정보 보호 관련 기술들은 각기 자신만의 보호 기술과 영역을 갖고 있다. 따라서 조직에서는 이러한 솔루션을 종합적으로 관리하여 개인정보 전체 상황을 파악할 필요가 있다. 이렇게 개인정보의 전체 상황을 파악하는 것을 EPM(Enterprise Privacy Management)이라고 하는데, EPM은 기존 보안솔루션들을 통합한 솔루션인 ESM(Enterprise Security Management)과 같은 개념이라 할 수 있다. EPM은 ESM과 같이 암호화 관련 솔루션보다는 접근제어와 내역 로깅을 하는 제품들을 주로 연동한다. 개인정보 종합 관리기술은 단지 관리적인 목적 외에도 『개인정보 보호법』상의 조항을 통해 그 필요성을 알 수 있다.

 

제34조 (개인정보 유출 통지 등)

① 개인정보처리자는 개인정보가 유출되었음을 알게 되었을 때에는 지체없이 해당 정보주체에게 다음 각 호의 사실을 알려야 한다.

 - 유출된 개인정보의 항목

 - 유출된 시점과 그 경위

 - 유출로 인하여 발생할 수 있는 피해를 최소화하기 위하여 정보주체가 할 수 있는 방법 등에 관한 정보

 - 개인정보처리자의 대응조치 및 피해 구제절차

 - 정보주체에게 피해가 발생한 경우 신고 등을 접수할 수 있는 담당부서 및 연락처

② 개인정보처리자는 개인정보가 유출된 경우 그 피해를 최소화하기 위한 대책을 마련하고 필요한 조치를 하여야 한다. 

③ 개인정보처리자는 대통령령으로 정한 규모이상의 개인정보가 유출된 경우에는 제 1항에 따른 통지 및 제 2항에 따른 조치 결과를 지체 없이 행정자치부장관 또는 대통령령으로 정하는 전문기관에 신고하여야 한다. 이 경우 행정자치부장관 또는 대통령령으로 정하는 전문기관은 피해 확산방지, 피해 복구 등을 위한 기술을 지원할 수 있다.

④ 제1항에 따른 통지의 시기,방법 및 절차 등에 관하여 필요한 사항은 대통령령으로 정한다.

 

 

2. 개인정보 취급자를 최소화하기 위한 직무분리 프로세스 개선안

고객정보 데이터베이스 접근자

① DBMS에는 직접 접근하지만, 데이터베이스 내 정보의 내용 자체에는 관심이 없는 부류

 : 단순히 DBMS의 원활한 운영이나 정보자체의 무결성, 정보시스템 개발 등을 위해서 정보를 다루는 데이터베이스 관리자, 개발자와 같은 사람이 대표적.

② DBMS에 대해서는 잘 모르지만 저장된 정보의 내용 자체에 대해서 관심이 있는 부류

 : 마케팅, CRM, 영업활동을 위해 정보의 내용을 활용하는 마케팅징원, 영업사원과 같은 사람이 대표적. 이 사람들은 기술자가 아니기 때문에 대부분 DB에 접근하는 방법을 모르거나 직접 접근할 수 있는 권한도 없다. 이들은 정보시스템을 사용하여 데이터베이스 내의 정보를 얻는 것이 보통이지만, 때로는 다음과 같은 시나리오를 이용하기도 한다.

 

- 한국전자에서 마케팅 업무를 담당하는 홍길동 씨는 고객의 상품취향을 분석하기 위해, 데이터베이스 관리자 이순신씨에게 최근 TV를 구입한 고객의 정보를 요청한다.

- 이순신씨는 DB에 SQL쿼리를 실행하여 해당 고객의 거주지, 나이, 성별 등을 조회한 뒤 파일로 저장한다.

- 이순신 씨는 그 파일을 전자메일이나 USB에 담아서 홍길동 씨에게 전달한다.

 

이 과정에서 DB관리자는 고객의 개인정보에 대한 조회권한이 없음에도, 개인정보를 조회하게 되며, 그 정보를 자신의 PC에 잠시라도 저장할 수 밖에 없다. 이런 식으로 DB관리자가 중간경로에서 개인정보를 취급하게 되면, 견제할 수 있는

수단이 별로 없다. 데이터베이스에 특화된 쿼리 대리 실행기반의 직무분리 기능은 데이터베이스에 직접 접근하는 관리자나 개발자에게 작업은 가능하게 하지만, 정보를 대량으로 조회할 수 없도록 하여 개인정보의 유출사고를 미연에 방지하도록 도와준다.

 

< 고객 데이터베이스 접근자의 권한 및 접근 기술 능력 >

	DB관리자, 개발자	마케터, 영업사원
DB 스키마 이해도	O	X
정보 조회권한	△	O
쿼리 작성능력	O	X
개인정보취급자여부	△	O

>> 결과물이 DB관리자를 거치지 않고 마케터에게 제공됨으로써 기존 문제 해결

 

 

3. WAS 로깅 기능

WAS(Web Application Serve)로 대표되는 정보시스템이 데이터베이스에서 정보를 조회할 때에는 데이터베이스 방화벽 시스템이 저장하는 로그 상에서 WAS가 사용자가 되며, 실제 그 정보를 누가 조회했는지 알 수 없다. 하지만, 법 규정은 그 행위자가 누구인지를 정확하게 식별하는 것이 주요 목표 중에 하나이므로 문제가 된다.

 

이러한 문제점을 해결하기 위해 많은 해결방식이 시도되었는데 WAS의 애플리케이션이 쿼리를 전송할 때, 주석으로 실제 사용자의 IP를 삽입하고 그것을 DB방화벽 시스템이 해석하는 것이 대표적이라고 할 수 있다.

 

 

4. 로그 위변조방지와 기업 효율성을 충족시키는 스토리지

기존에 데이터 백업방식인 ‘로그를 데이터베이스에 저장하고, 이를 테이프 드라이브에 저장’하는 방식은 백업 전후에 관리자가 로그를 임의적으로 위변조할 수 있는 문제가 있음. 이 문제를 없애기 위해서 로그를 DVD에 저장하는 방식이 사용되기도 하지만, 이 방식은 DVD를 교체하는 것에 대한 번거로움과 로그를 로딩하는 데 시간이 많이 걸리는 한계가 있음.

 

로그 위변조가 불가능하도록 한 스토리지를 웜(WORM,Write Once Read Many Times)디바이스라고한다. 웜 디바이스는 쓰기는 오직 한 번만 허용하고 그 정보를 읽는 것은 자유로운 장치다. 데이터베이스 관리자나, 백업 테이프 관리자, 시스템 관리자 등이 그 안에 들어가 있는 내용을 위변조하거나 삭제하는 것은 원천적으로 불가능하다.

 

최근에는 HDD의 일부 영역을 웜 영역으로 설정하여 운영하는 기술이 개발되었다. HDD를 사용하면 로그에 대한 쓰기 읽기 속도가 CD/DVD,TAPE에 비해 10~30배 이상 빠르다는 장점이 있다. 별도의 테이프 드라이브를 사용할 때의 백업과 리스토어 과정을 거치지 않는 다는 편리함도 있다. 

 

 

5. 데이터베이스 암호화 방식의 장단점

데이터베이스에 저장되는 정보를 암호화하는 방식

- DBMS 자체에서 암호화

- 프록시에서 암호화

- 데이터베이스 접속 애플리케이션에서 암호화

항 목	DBMS 암호화	Proxy 암호화	애플리케이션 암호화
암호화와 복호화가 이루어지는 위치	DBMS	proxy	애플리케이션 프로그램
DB 스키마 변경 여부	필요	필요	필요
애플리케이션 변경	최소화	최소화	가장 많음
키 관리부담	최소화	최소화	가장 많음
데이터 마이그레이션	필요	필요	필요
DB성능저하	가장 높음	낮음	낮음
통신구간 스니핑 공격 취약성	여전히 존재	여전히 존재	없음

어떤 암호화 방식이라도 기존의 데이터베이스 스키마가 변경되어야 하고 데이터를 마이그레이션 해야 하는 부담이 존재한다. 따라서 데이터베이스 보안을 위해서는 데이터베이스 방화벽 기술과 암호화 기술을 적절히 혼용해야 높은 수준의 보안이 가능하다고 할 수 있다.

 

 

6. 셰도우 마스킹(Shadow Masking) 기능

마스킹이란 정보의 일부분을 알아볼 수 없도록 다른 값으로 바꾸는 것을 말한다. 업무나 비즈니스를 위해 개인정보를 다룰 때 정보 전체가 필요로 하지 않는다면, 정보의 일부분을 마스킹 하여 노출/유출을 최소화 할 수 있다.

ex) 710929-1123429 → 710929-1******, 홍길동 → 홍*동

특정 테이블의 특정 칼럼을 마스킹처리 하고 싶을 때 사용하는 기능이 셰도우 마스킹. 대상 테이블에 동일한 내용의 뷰를 만들되, 해당 칼럼만은 마스킹한 값으로 채워 넣는 방식을 사용. 셰도우 마스킹 기능은 원천 테이블을 뷰로 바꿔치기 하므로, 네트워크상에서 마스킹하는 것에 비해 복잡한 쿼리나 함수사용 등에 대해서도 항상 마스킹 된다는 장점이 있다.

 

 

7. 개인정보 유출 탐지 기술

불법적인 개인정보 유출 시도를 탐지하기 위해서는 데이터베이스에 대한 질의어 분석보다는 응답 값 분석에 더 중점을 둬야 한다. 예를 들면, “select name, jumin from employe_table”만 저장하고 응답 값인 “홍길동, 850416-1542174,박문수,670505-1275411” 등을 저장하지 않았다. 응닶 값을 정확하게 분석하는 기술적으로 매우 난이도가 높은작업이라 개발을 보류한 것이다. 또한, 응답 값을 모두 저장하는 경우 저장 공간이 크므로 비용적인 부담이 되기 때문이다.

 

그러나 클라이언트로부터 데이터베이스로 전달되는 질의어만의 분석을 통해 개인정보의 유출에 대한 이상 징후를 분석하는 것은 다음과 같은 문제점이 있다.

 

1. 질의어는 가독성이 낮다.

예) “select alias1, alias2, alias3, alias4 from(select 고객id as alias1, 유효연월 as alias2, 대표카드번호 as alias3, 대표카드유효연월일 as alias4, fromcm01. 개인회원기본 where 고객번호 in (100000000001,1000000002,1000000010))” 과 같은 질의어의 결과 값으로 개인정보가 포함되는지를 예측하기 어렵다.

 

DB관리자조차도 이러한 질의어가 쿼리에 사용된 카드번호와 같은 개인정보가 다른 테이블과의 조인을 위해서 사용되는 것인지, 카드번호자체를 조회하려고 하는 쿼리인지 식별하기가 어렵다.

 

2. 데이터베이스의 관리 범위를 벗어난 자료가 무엇인지가 주요한 관리대상이어야 한다.

개인정보의 유출통제라는 목적 측면에서 보았을 때는 클라이언트가 데이터베이스에 요청한 값이 무엇인지가 중요한 것이 아니라 데이터베이스 관리 범위를 벗어난 자료가 무엇인지가 더 중요하다.

 

쿼리 값이 중심이 되고, SQL 쿼리 자체는 부가적인 정보에 해당한다고 할 것이다. 또한 DB를 구성하는 자료들이 지속적으로 갱신되는 경우, 사후 동일한 질의어를 전달하더라도 그 해당내용이 동일하게 재현되지 않을 수도 있기 때문에 결과 값을 반드시 저장해야 한다.

 

3. 개인정보가 포함되어 있는 테이블과 칼럼의 정보를 사전에 획득하는 것은 실질적으로 불가능 하다.

개인정보 유출방지를 위해서는 개인정보가 포함되어 있는 테이블과 뷰의 칼럼을 정확하게 파악하여 쿼리 내용에 해당 필드나 칼럼이 포함되어 있을 경우에 차단하거나 경보, 혹은 쿼리 내용을 기록해서 보관하면 된다. 문제는 규모가 큰 조직에 구축된 DB는 기본적으로 수년에서 수십 년 동안 운영되며, 그 수 또한 몇 십대에서 몇 백대까지 매우 많으므로 그동안 수 많은 테이블이 생성되고, 갱신되고, 삭제되기 때문에 무수히 많은 또한 변경되는 테이블과 뷰에 대해서 하나씩 개인정보 포함 여부를 확인하는 작업이 현실적으로 불가능하다.

 

따라서 개인정보의 유출방지를 위해서는 DB에 대한 질의어 보다는 응답 값의 내용을 관리하고 통제할 수 있어야 한다. 최초 몇 건 정도만 저장하는 옵션을 제공한다면, 저장 공간의 제한성을 극복 할 수 있다.