KR20170018882A - 개인정보 보호를 위한 정보등록과 조회통제 방법 - Google Patents

Abstract

본 발명은 종래의 개인정보 유출의 위험을 원천적으로 차단하기 위한 개인정보 등록 방법 및 장치에 관한 것으로서, 본 발명에서는, 등록하고자 할 개인정보(등록정보)의 정보요소를 최대한 세분하여 분할하고 각 분할된 세그먼트를 별도의 테이블에 소정의 방식으로 저장한다. 정보요소의 분할은 다양한 기준으로 행할 수 있는데, 최대한 잘게 다수의 세그먼트로 쪼개는 것이 본 발명의 목적 달성을 위해 유리하다.

Description

개인정보 보호를 위한 정보등록과 조회통제 방법 {Information registration and query control method for the protection of private information}

본 발명은 데이터베이스에 해커가 침입하여 정보가 들어있는 테이블을 훔쳐가더라도 이 테이블만으로는 개인정보를 복구할 수 없도록 하고 개인정보 조회자를 체계적으로 통제할 수 있는 정보등록 및 관리 방식에 관한 것이다.

우리나라는 그 동안 정부의 행정서비스, 금융기관 거래를 비롯하여 모든 일에 주민등록번호를 편의적으로 이용하여 왔다. 그러나 주민등록번호는 몇 자리의 숫자만으로 그 사람의 생년월일, 성별 등을 쉽게 확인할 수 있도록 코드화되어 있고, 이를 악용하고자 하는 사람이 몇 가지 외부 정보만 추가 확보하면 얼마든지 이를 부정 목적에 이용할 수 있게 되어 있다. 이와 같은 문제는 주민등록번호만의 문제가 아니다. 예를 들어, 금융기관에서 사용하고 있는 계좌번호도 금융기관에 종사하는 사람이라면 그 숫자만 보아도 어느 은행, 어느 지역의 어느 지점인지를 쉽게 파악할 수 있도록 되어 있다. 왜냐하면, 계좌번호를 부여할 때 체계적인 규칙을 갖고 부여하기 때문이다.

현대 정보화 사회 이전에는 사람이 수작업으로 번호의 특성 내지는 체계를 파악해야 업무를 용이하게 처리할 수 있기 때문에 주민등록번호, 계좌번호, 사원번호 등을 일정 규칙과 체계 하에 정해야 할 필요가 있었다. 그러나 정보화 시대인 현재 그러한 규칙적이고 체계화된 번호는 더 이상 필요가 없다. 컴퓨터 등의 정보시스템이 해당 번호를 읽고 그 정보를 필요로 하는 사람에게 필요한 정보만을 제공해 줄 수 있으면 되기 때문이다.

도 1은 종래의 일반적인 관계형 데이터베이스(relational database)를 사용한 개인정보 저장 및 조회의 구성도이다. 관계형 데이터베이스에서는 각 DB 테이블(DB table) 간에 관계 설정이 되어 있기 때문에 어느 하나가 노출될 경우에 나머지 것들도 노출된다. 또한, 조회를 위한 각 응용 프로그램(Application Prog.)들은 애플리케이션 모듈로서, 각각의 프로세스(Process)에 포함되어 있으므로 데이터베이스에서의 정보유출을 감시하기가 어렵다. 만일 일부 프로세스의 수정은 있었으나 상시 모니터링 트랜잭션 로그(Transaction log)에 연계되지 못하였을 경우에는, 정보유출을 적발 또는 차단하지 못할 위험이 커진다. 일반적으로 정보노출은 개인정보 등을 일괄적으로 다운로드하는 경우에 발생하므로 이를 사전에 인지하거나 차단할 필요가 있다. 여기서 상기 응용 프로그램은 Java 등과 같이 역해독(decompile)이 용이한 프로그램이다.

도 1과 같이 이루어지는 종래의 방식에서 데이터베이스 테이블에 저장되는 개인정보의 형태는 도 2의 (a) 및 (b)와 같다. 도 2의 (a)는 성명, 주민등록번호, 주소, 전화번호, 계좌번호, ID, 패스워드 등의 개인정보를 모두 하나의 테이블에 일괄적으로 저장하는 경우이고, (b)는 관계형 데이터베이스의 개념 하에 변수의 종류를 구분한 다음에 각 변수별로 각기 다른 테이블에 저장하는 경우이다(즉, 주민등록번호 테이블, 주소 테이블, 전화번호 테이블, 접근권한 테이블 등).

그러나 (a)의 경우는 말할 것도 없고, (b)와 같이 개인정보를 관계형 데이터베이스에서 여러 테이블로 구분하여 저장하더라도 개인정보 유출의 위험은 줄어들지 않는다. 해커가 침입하여 관계형 데이터베이스의 테이블을 빼갈 경우에 해커는 그 데이터간에 설정되어 있는 관계를 통하여 개인의 모든 정보를 훔칠 수 있는 것이다. 또한 설령 데이터베이스를 암호화한다 하더라도 해커의 암호 해독 능력이 진화하고 있기 때문에 여전히 정보 유출의 위험은 존재한다.

여기서, 개인정보는 숫자 문자 기호 등의 정보는 물론이고, 각종 생체정보(예를 들어, 지문, 홍채, 유전자, 손금, 얼굴(안면), 정맥문, 입술주름, 음성 등)도 포함되는 개념이다. 특히 지문의 경우에는, 지문을 이미지 형태로 저장하여 활용하거나 이미지를 디지털화한 다음 주민등록번호, 성명 등이 저장되어 있는 테이블과 관계를 설정하여서 사용한다. 이러한 생체정보는 개개인 별로 평생 바꿀 수 없는 것으로, 일단 유출되면 그 사람은 평생 해당 생체정보를 사용할 수 없게 된다. 만일 생체정보가 데이터베이스 통째로 유출되면 각종 범죄 등 국가적인 대란이 발생하며, 비록 암호화 해둔다고 하더라도 데이터베이스 자체가 해킹을 당하면 해커에게 암호해독은 시간문제일 뿐이다.

이러한 개인정보의 보호를 위한 종래의 다양한 방식에 관련된 몇 가지 선행기술을 소개한다.

등록특허 10-1220992(인터넷을 이용한 전자상거래에서의 고객 주소정보관리시스템 및 그 방법)는 인터넷을 통해 연결된 고객의 단말로부터 입력되는 고객의 상세 주소정보를 제공받아 이에 대응되는 고유 주소번호를 생성하고, 상기 생성된 고유 주소번호와 이에 해당하는 상세 주소정보를 서로 분리된 데이터베이스(DB)에 각각 따로따로 저장하여 관리함으로써, 고객의 상세 주소정보를 해커(hacker) 또는 악성 프로그램 등에 의해 외부로 쉽게 유출되는 사고를 효과적으로 방지할 수 있도록 하고 있다.

공개특허 10-2013-0049623(데이터 분산 저장 시스템 및 그 방법)은 원본 데이터를 복수의 노드에 분산 저장하면서 동시에 암호화하여 저장하여 가용성과 보안성을 동시에 높이는 데이터 분산 저장 시스템 및 그 방법을 개시한다.

등록특허 10-0788278(정보의 익명화를 위한 데이터 저장 시스템 및 방법)은 정보의 익명화를 위하여, 저장할 정보를 신원 확인의 근거가 되는 헤더 정보인 ID 데이터와, 상기 정보로부터 ID 데이터를 제외한 바디 정보인 PD 데이터로 분리하여 저장하는 데이터 저장 시스템 및 방법을 개시하고 있다.

본 발명은 종래의 외부로부터의 개인정보 유출의 위험을 원천적으로 차단하고 내부이용자에 의한 개인정보 유출을 사전 통제하기 위한 개인정보 등록과 조회통제 방법을 제공하는 것을 목적으로 한다.

상기 과제를 해결하기 위하여, 본 발명에서는, 등록하고자 할 개인정보(등록정보)에 고유의 고객번호를 할당한다. 이 고객번호는 무작위(랜덤) 숫자로 자동 생성되며 각 개인정보마다 고유로 지정된다. 그리고 모든 등록정보의 정보요소를 최대한 세분하여 분할한다. 예를 들어 성명은 성과 이름으로 분할하고, 주민등록번호는 앞자리와 뒷자리로 분할하고, 전화번호는 국번호와 뒷자리 번호로 분할하고, ID와 패스워드는 적정한(임의의) 경계를 기준으로 분할한다. 정보요소의 분할은 다양한 기준으로 행할 수 있는데, 최대한 잘게 다수의 세그먼트로 쪼개는 것이 본 발명의 목적 달성을 위해 유리할 것이다.

여기서 사용 용어에 대해 설명을 하자면, "등록정보"란 등록을 하고자 하는 개인정보 또는 등록되어 있는 개인정보를 의미하는 것으로, 이 등록정보에는 다수의 "정보요소"가 포함된다. 예를 들어서 [홍길동, 550101-1177xxx, 서울 관악구 신림동 xx번지, 888-8888]을 등록정보라 하고, 이 정보에 포함되어 있는 홍길동(성명), 550101-1177xxx(주민등록번호), 서울 관악구 신림동 xx번지(주소), 888-8888(전화번호)은 각각 정보요소라 한다. 본 명세서에서 등록정보는 I(X)라 표기하기로 한다. 여기서, I는 등록정보라는 의미이고, X는 I에 포함되어 있는 정보요소라는 의미이다. 또, "세그먼트"는 각 정보요소를 상기와 같이 소정의 규칙에 의하여 분할한 경우에 각 분할된 조각을 의미한다. 예를 들어 성명 홍길동은 '홍' 세그먼트와 '길동' 세그먼트로, 주민등록번호 550101-1177xxx는 '550101' 세그먼트와 '1177xxx' 세그먼트로, 주소 서울 관악구 신림동 xx번지는 '서울' 세그먼트, '관악구' 세그먼트, '신림동' 세그먼트, 'xxx번지' 세그먼트로, 전화번호 888-8888은 '888' 세그먼트와 '8888' 세그먼트로 분할된다.

이렇게 분할한 정보요소는 데이터베이스 내의 관계설정되지 않은 각기 다른 테이블에 저장한다. 테이블에 정보요소를 저장할 때에는, 앞에서 할당된 고객정보로부터 소정의 공식으로 산출된 각 키값을 함께 저장한다. 각 키값은 각 정보요소마다 상이한 공식으로 산출하여서 더욱 보안성을 높인다. 정보요소는 특정 변수명 아래에 저장하고, 키값은 특정 인덱스 번호 아래에 저장한다. 이 단계에서, 데이터베이스 내의 테이블에는 등록정보의 정보요소와 이 정보요소에 연계된 키값이 함께 저장된다.

각 테이블은 관계를 설정하지 않으며 그럴 필요도 없다. 또한, 테이블명은 이로부터 그 저장된 내용을 추론할 수 없도록 최대한 테이블 내에 저장되는 정보와 무관한 이름으로 짓는 것이 바람직하다. 마찬가지로, 변수명도 최대한 그 저장된 변수(즉, 정보요소)의 의미를 추론할 수 없도록 그 변수의 내용과 무관한 것으로 짓는다.

또한 해킹의 가능성을 더욱 더 줄이기 위하여 데이터 테이블(관계 설정 안하고 세분화된 테이블들)의　레코드에는 허위 레코드를 랜덤하게 섞어　넣을 수 있다.

등록정보의 모든 정보요소의 모든 세그먼트에 대해서 위와 같은 방식으로 저장을 한다.

한편, 개인정보의 조회를 위한 쿼리가 들어오면 관리 프로그램은 각 테이블에 분할되어 저장되어 있는 정보요소들을 검색해서 각각 불러온다. 그리고 상기 등록시에 각 정보요소의 인덱스번호 아래 저장된 키값을 불러와서 상기 등록시에 사용한 소정의 공식을 이용해 역산을 하여, 고객번호를 산출한다. 이 고객번호에 해당되는 정보요소들을 다 찾은 후에 이들 정보요소들을 조합하여서 조회 쿼리에 대한 결과로서 출력한다.

(1) 정보를 최대한 쪼개어(분할), 관계설정 안된 테이블에 저장. 키값은 일련번호가 아닌 랜덤 수로 하되 암호화 또는 체크디지트 등을 적용하여 생성.

(2)　정보 등록시 정보를 잘게 쪼개어 인코딩하고 테이블에 분배하는 난독화된 코드(obfuscated code)로 작성된 인코딩 프로그램과 디코딩 프로그램을 운용.

　　　　 - 이 두 가지 사항에 의하여 외부 침입자의 해킹을 무력화할 수 있다.

(3) 　권한이 없거나 권한을 넘어서는 내부이용자에 의한 정보 유출 차단(예방)을 위하여 디코딩 프로그램에서 통합적으로 정보생산 및 조회 통제

이상에서 본 발명의 기술 사상을 설명하였으나, 이에 대한 구체적인 구성과 작용은 이하에서 도면과 함께 설명한 상세한 설명 항목에서 명확해질 것이다.

본 발명에 따르면 데이터베이스에 해커가 침입하여 테이블을 훔쳐가더라도 이 테이블만으로는 개인정보(지문 홍채 안면 등의 생체정보를 포함함)를 복구할 수 없게 된다. 또한 내부 이용자가 개인정보를 유출하고자 할 때 개인정보생성 단계에서 원천적으로 차단할 수 있다. 과거의 시스템에서는 애플리케이션 서버(프로그램)에서 개인정보 이용에 대한 차단을 시도하였으나 애플리케이션 프로그램의 수많은 곳에서 개인정보를 조회 활용하기 때문에 프로그램을 업데이트 할 때 통제의 순간이나 통제 필요 위치 등을 놓칠 수 있고 개인정보 이용을 통제하는데 많은 비용(별도 장비, 별도 프로그램 등)이 소요된다. 본 발명에서는 이와 같은 통제를 개인정보를 디코딩하는 프로그램에서 통합적, 체계적으로 통제 관리함으로써 권한이 없거나 권한을 넘어서는 내부자에 의한 개인정보의 접근을 근본적으로 차단할 수 있다.

만일 해커가 본 발명에도 불구하고 개인정보를 획득하려면 다음과 같은 단계를 거쳐야 할 것이다.

(1) 1단계: 역해독(decompile)이 용이하지 않은 난독화코드(obfuscated code)로 작성된 개인정보 코딩 프로그램을 해킹한 후 역해독을 통해 그 프로그램에 담긴 개인정보 테이블명을 확인

(2) 2단계: 데이터베이스를 해킹하여 필요한 테이블들을 확보

(3) 3단계: 디코딩 프로그램을 데이터베이스로부터 가져온 테이블들과 연결한 후 작동시켜서 개인정보 생산.

이러한 방법 이외에는 본 발명에 따른 데이터베이스의 테이블들만 수집해서는 개인정보를 절대로 생산해 낼 수 없다.

도 1은 종래의 일반적인 관계형 데이터베이스를 사용한 개인정보 저장 및 조회의 구성도이다.
도 2는 종래의 방식에서 데이터베이스 테이블에 저장되는 개인정보의 형태의 두 가지 예시도이다.
도 3은 본 발명에 따른 개인정보 저장(등록) 및 이용(조회)의 기본 개념을 설명하기 위한 구성도이다.
도 4는 정보 등록시에 수행되는 프로세스의 플로우챠트를 나타낸다.
도 5a는 등록정보가 저장되는 테이블과 변수명에 대해서 예시해 놓은 것이다.
도 5b는 지문 이미지를 여러 세그먼트로 분할하는 개념을 나타낸다.
도 6은 정보 조회시에 수행되는 프로세스의 플로우챠트를 나타낸다.

도 3은 본 발명의 기본 개념을 설명하기 위한 도식이다.

정보의 등록 프로세스와 이용(조회) 프로세스를 구분하여 인코딩/디코딩함으로써 애플리케이션 서버의 정보노출에 대비한다.

정보등록자(10)가 정보등록 애플리케이션 프로그램(20)을 이용하여 개인정보(성명, 주민등록번호, 주소, 전화번호 등 그리고 지문, 홍채 등의 생체정보)를 입력하면 등록용 정보생산 모듈(30)에서는 입력된 정보를 등록용 정보로 재생산(즉, 인코딩)하여 데이터베이스(40)에 저장한다. 이때 등록용 정보로의 재생산시에는 개인정보를 여러 세그먼트로 분할하고, 각 세그먼트마다 개인정보와 무관한 임의의 거짓정보를 생성하여 삽입한다. 이렇게 거짓정보가 삽입된 개인정보를 데이터베이스(40)에 저장하는 것이다. 여기서 등록정보 생산모듈은 디컴파일(decompile)이 불가능한 프로그램으로 작성한다. 그리고 데이터베이스에서 개인정보 테이블은 관계 설정이 없으며 각 테이블에 거짓정보가 포함되어 있으므로 해커는 개인정보를 조립할 수 없게 된다.

한편, 정보이용자(50)가 정보이용 애플리케이션 프로그램(60)을 이용하여 정보 조회를 요청하면, 조회용 정보생산모듈(70)은 데이터베이스(40)의 관련 테이블 정보를 불러와 이를 재생산(즉, 디코딩)해서 정보이용자(50)에게 제공한다. 여기서도 조회용 정보생산모듈(70)은 디컴파일(decompile)이 불가능한 프로그램으로 작성한다. 그리고 상기 애플리케이션 프로그램(20, 60)은 웹에 기반하여서 디컴파일이 용이하여도 본 시스템에서는 문제가 되지 않는다.

이러한 개인정보의 등록정보 생산에 있어서 보안성을 강화하기 위하여, 생체정보를 포함한 개인정보 변환 규칙을 정기적으로 변경하여 다시 저장할 수 있다. 그리고 거짓정보 생산 모듈을 분리하여 운용함으로서 보안성을 더욱 강화할 수 있다. 개인정보 유출은 조회 프로그램만 통합적으로 상시 감시하여서 예방 및 차단을 할 수 있다. 그리고 해킹 징후 발생시에는 개인정보 저장 규칙을 변경하여서 데이터를 다시 저장한다.

도 4는 정보 등록시에 이루어지는 구체적인 프로세스를 나타내는 플로우챠트이다. 도 4의 프로세스는 관리 시스템 내에 자동화된 관리 프로그램에서 이루어지지만 이에 한정되는 것은 아니다. 예를 들어, 관리 시스템이 아닌 클라이언트 단말기측에 설치된 어플리케이션 프로그램에서 이루어질 수도 있고 기타 웹기반이나 제3자 시스템에서 이루어질 수도 있다.

도 4에서, 등록정보를 등록하는 자(예를 들어 고객관리 담당자)가 등록정보 I(X)를 입력하여 등록 요청을 한다(100). 가령, 특정의 애플리케이션 화면에 고객 개인의 성명, 주민등록번호, 주소, 전화번호, 및 생체정보 등의 등록정보를 입력한다.

이 때 이 개인에 대한 고객번호가 랜덤 숫자로 자동 생성되고 입력된 I(X)에 할당된다(200). 고객번호는 지금까지와는 달리 절대 일련번호가 되어서는 안되고 반드시 랜덤하게 생성하여야 한다.

다음에, 각 정보요소(X)를 소정의 규칙에 따라 세그먼트 X1, X2, ..., Xn으로 분할한다(300). 예컨대, 성명, 주민등록번호, 주소, 전화번호의 정보요소를 이루는 컨텐트를 분할하여 세그먼트를 만든다. 생체정보(가령, 지문)의 경우에는 도 5b에서와 같이 지문의 이미지를 임의의 다수 영역으로 분할하여 세그먼트를 만든다. 매우 간단하게는 각기 다른 모양이 아닌 일정한 규격으로 생체정보를 분리하여 각기 다른 데이터 테이블에 저장할 수도 있다. 데이터 테이블에는 순서가 나타나지 않도록 한다.

그리고 각 세그먼트를 각 세그먼트에 사전 할당되어 있는 테이블에 변수명 Var 아래에 저장한다(500). 세그먼트를 저장할 테이블은 사전에 정해놓는다. 예컨대, '성' 세그먼트는 'youngsu and chulee' 테이블에, '이름' 세그먼트는 'seoul soedae' 테이블에, '주민등록번호 앞자리' 세그먼트는 'jarzak' 테이블에, '주민등록번호 뒷자리' 세그먼트는 'yeonpil_ball' 테이블에 저장하도록 정해놓는다. 각 테이블명은 거기에 저장되는 정보요소 세그먼트의 내용을 전혀 추론할 수 없는 다소 엉뚱한 이름으로 지어져 있음을 알 수 있다.

한편, 테이블에 세그먼트 X1, X2, ... Xn을 저장하기 전에, 각 세그먼트에 대해서, 앞서 단계 200에서 등록정보에 할당된 고객번호를 이용하여 각 세그먼트의 키값(거짓정보) K1, K2, ..., Kn을 산출한다(400). 키값의 산출은 고객번호를 이용하여서 임의의 방식으로 다양하게 산출할 수 있다. 본 발명의 효과를 극대화하기 위해서는 예측할 수 없을 정도로 복잡한 공식을 사용하는 것이 바람직하다.

키값 산출의 예를 들면, 상기 단계 200에서 랜덤으로 생성한 고객번호에 소정의 계산공식에 따라 소정의 수치를 대입하여 산출된 값을 해당 테이블 내의 해당 정보요소에 대한 키값으로 사용할 수 있다. 예를 들어 고객번호가 376543이고 공식이 [(고객번호×3)-7]/1.346이라고 정해진 경우에는 839243.6849925705가 나온다. 보안성을 더욱 강화하기 위하여 이 번호 중에서도 소숫점 이하의 소정 자리의 값, 가령, 6849925를 키값으로 정할 수 있다.

인덱스 번호를 산정하는 다른 예를 들자면, 성씨마다 특정 숫자를 부여하여서 일정 공식으로 변환된 숫자정보를 키값으로 정할 수 있다. 예를 들어 '김'씨 성의 경우 49763이라는 특정 숫자를 부여하여 정해진 공식에 투입하여 정할 수 있다.

키값을 정하는 방식은 각 세그먼트마다 다르게 적용하는 것이 바람직하다. 이렇게 함으로써 해커로부터의 역해독 가능성이 더욱 줄어들게 된다.

이렇게 산출한 키값은 인덱스 번호(Idx) 아래에 각 세그먼트별로 저장한다(500). 도 4에서 세그먼트 X1은 테이블1의 변수 Var1 아래에 저장되고, 이 세그먼트 X1에 대한 키값 K1은 인덱스 Idx1 아래에 저장됨을 알 수 있다.

도 5a는 상술한 내용을 정리해서 보여주기 위한 테이블 구조도이다. 'youngsu and chulee' 테이블(51)은 '성' 세그먼트가 저장되는 테이블이고, 'seoul soedae' 테이블(52)에는 '이름' 세그먼트가 저장되고, 'jarzak' 테이블(53)에는 '주민등록번호 앞자리' 세그먼트가, 'yeonpil_ball' 테이블(54)에는 '주민등록번호 뒷자리' 세그먼트가 저장된다.

각 테이블(51~54) 안에서 인덱스 번호에는 키값 K1, ..., K4가 저장되어 있고, 각 테이블의 변수명 yungsu, chulee, busan, pen에는 소정의 해당 세그먼트(즉, 성, 이름, 주민등록번호 앞번호, 뒷번호)가 저장되어 있다.

다른 실시예에서, 각 테이블의 인덱스 번호의 엔트리인 키값은 고유의 체크디지트(check digit)로 설정할 수 있다. 그리고 이 체크디지트가 적용된 주요 키(primary key)를 별도로 저장한다.

체크디지트는 정보의 내부통제 기법 중의 하나이다. 가장 쉬운 체크디지트의 예을 들자면, 주민등록번호, UPC(소위 바코드) 등이다. 주민등록번호 13자리 끝자리는 12개 자릿수의 조합을 일정한 숫자(예, 11)로 나눈 후의 나머지로 채워진다. 복잡하고 원리를 해독하기 어려운 다양한 체크디지트 방식(log transform 등 수학적 방식의 도입)들이 실무에서 활용되고 있다. 본 발명에서도 그와 같은 방식을 활용할 수 있다. 즉, 체크디지트는 가짜 개인정보인지 식별하는 데 사용되나 여기서는 일부 테이블이 해킹되더라도 키값의 구성원리를 파악하지 못하면 테이블들을 결합하여 정보를 생산하지 못하게 하기 위한 것이다.

단계 300, 400, 500은 등록정보 내의 모든 정보요소에 대해서 동일하게 적용한다. 가령, 특정 개인의 성명과 주민등록번호에 이어서, 주소, 아이디, 전화번호, 계좌번호 등에 대해서 상기 단계를 적용하여서 각각의 해당 테이블에 저장 및 등록한다.

도 6은 등록된 정보를 이용(조회)하는 경우에 진행되는 프로세스를 나타내는 플로우챠트이다.

조회 질의자(예를 들어, 고객 신용평가사 또는 사회복지사 등)가 '홍길동'이라는 이름으로 정보조회 질의를 하면(600), 관리 프로그램에서는 정보를 구성하는 정보요소를 분할한다(700). 즉, 이 경우에는 '홍'과 '길동'으로 분할한다. 도 6의 경우는 설명으로 조회질의한 것을 나타낸 사례로, 그 외에 주민등록번호 또는 전화번호라도 방법은 동일하다.

관리 프로그램은 분할된 정보요소의 세그먼트 X1, X2, ..., Xn을 각 해당 테이블에서 검색한다(800). 즉, 이 경우에는 'youngsu and chulee' 테이블에서 '홍'을 검색하고 'seoul soedae' 테이블에서 '길동'을 검색한다. 그리고 각 테이블의 인덱스번호 하에 저장되어 있는 세그먼트에 대한 키값을 읽어서 이를 소정의 공식으로 역산한다(900). 즉, 앞에서 정보등록시에 사용된 세그먼트별 키값 산출 공식을 저장하고 있다가 이 공식에 키값을 대입하여서 등록시에 할당된 고객번호를 산출한다(1000).

이 고객번호에 일치하는 정보요소를 모두 추출(1100)한 다음에, 추출된 정보요소들을 조합하여 정보를 생산하여서 최종 결과로서 출력한다(1200).

정보등록자(10), 정보등록 애플리케이션 프로그램(20), 등록용 정보생산 모듈(30), 데이터베이스(40), 정보이용자(50), 테이블(51, 52, 53, 54), 정보이용 애플리케이션 프로그램(60), 조회용 정보생산모듈(70), 등록정보(I(X)), 정보요소(X)

Claims (1)

1. 개인정보 보호를 위한 정보등록 방법에 있어서,
   등록정보의 정보요소를 두 개 이상의 세그먼트로 분할하고,
   상기 할당된 고객정보로부터 상기 각 세그먼트에 연계되는 키값을 산출하고,
   상기 분할한 정보요소의 각 세그먼트를 데이터베이스 내의 관계설정되지 않은 각기 다른 사전 정해놓은 테이블에 상기 키값과 함께 저장하는 것을 포함하는, 정보등록 방법.
   
   

Images