Series 〉 AWS Certified Cloud Practitioner
여러분은 사용자 본인 확인을 어떻게 해결하고 계신가요? 이번 포스팅은 본인인증 프로세스를 개발할 때 빠질 수 없는 주요 개념인 CI & DI에 대해서 알아보려고 합니다.
회사에서 인증/인가 서비스 개발을 맡으면서 2차 인증 프로세스 개발도 진행하게 되었습니다. 2차 인증을 위해서 여러가지 방법으로 사용자 2차 인증을 구현할 수 있습니다. 예를 들어 임의의 코드를 사용자의 메일이나 휴대폰으로 발송하여 발송한 코드와 사용자가 입력한 코드를 비교하는 방식이나, Google OTP를 활용해서 인증하는 방법, 그리고 나이스 본인인증과 같이 본인확인기관에서 발급하는 암호화 정보들로 2차 인증을 구현할 수 있습니다. 이번 글에서는 본인확인기관에서 발급하는 암호화 정보인 CI와 DI에 대해서 알아보겠습니다.
CI (Connection Information)
CI (Connection Information), 직역하면 ‘연계 정보’로 본인확인(인증)기관에서 개인별로 고유하게 부여하는 개인 식별 정보입니다. 이 CI는 타사 제휴 및 온/오프라인 연계가 가능하도록 이용자를 식별할 수 있는 88byte의 암호화 정보로 타 웹사이트 간에 사용자 정보를 공유하거나 식별키로 활용할 수 있도록 만들어졌습니다. 쉽게 얘기하면 온라인에서 서로 다른 인터넷 업체 간 동일인을 식별하기 위해서 사용됩니다. 따라서, CI는 온라인 주민등록번호로 통칭하고 있습니다.
주민등록번호 체계
주민등록번호는 생년월일, 성별, 지역 등을 표시할 수 있는 13자리의 숫자입니다. 이 13자리의 숫자는 대한민국의 모든 국민이 발급 받게 되는 고유 번호입니다.
온라인 상의 주민등록번호의 문제점
주민등록번호는 13자리의 숫자로 구성되어 있지만 생년월일, 성별, 연령, 지역 등 개인 기초 정보를 확인할 수 있기 때문에 별도의 잘비 없이 이 번호 자체만으로 몇몇 개인정보를 알 수 있고 다른 개인정보를 알 수 있는 키(Key) 역할을 할 뿐만 아니라, 영구적으로 변하지 않기 때문에 한 번 노출되면 지속적으로 개인 정보를 침해당할 가능성이 매우 큰게 문제입니다. 그래서 실제로 예전에는 주민등록번호가 여러 사이트에서 관리되면서 주민등록번호가 유출되거나 불법적으로 사용되는 등의 문제가 발생하였고 주민등록번호를 연결고리로 한 개인의 성향이나 행태에 관한 정보를 재생산하면서 상업적으로 판매하는 경우도 등장했었습니다.
CI 암호 체계
CI는 주민등록번호를 일방향으로 암호화하여 생성된 정보입니다. 개인별로 고유하게 생성된 주민등록번호를 일방향으로 암호화하기 때문에 원본 데이터로 복원이 불가합니다. 그렇기 때문에 주민등록번호가 바뀌지 않는 한, CI 값은 수정 할 수 없습니다. 이러한 특성으로 포인트 제휴, 가맹점 할인, 내 정보 확인 서비스 등 본인 확인이 필요한 서비스에 다양하게 활용되고 있습니다.
아래는 CI값을 88byte의 해쉬로 처리하는 방식을 보여주는 그림입니다.
CI 특징
•
관리의 투명성 : 정보에 의한 높은 수준의 관리, 결과의 공개
•
범용성 : 온, 오프라인 연계
•
신뢰성 : 본인확인 절차에 의해 생성, 제공
•
낮은 식별성: 암호화된 문자열
•
사용 제한성 : 본인확인, 연계, 식별 및 그에 준하는 목적 외 사용 제한 (이는 아직 불분명하다는 논의가 존재합니다.)
결국 CI의 가장 큰 특징은 본인 인증 기관이 달라도 CI 값은 고유하기 때문에 공유가 가능하다는 것입니다. 만일 사용자의 성별, 연령 등의 기초 정보가 바뀌지 않는다면 CI 값은 바뀌지 않기 때문에 이 CI 값으로 카카오나 네이버 등 다른 사이트에서 연계가 가능합니다.
DI (Duplication Information)
DI(Duplication Information)는 중복 확인 정보라는 의미입니다. 이 정보 또한 개개인을 식별할 수 있는 키입니다. CI와 DI의 차이점은 본인 인증 기관이 달라도 같은 CI 정보를 공유할 수 있는 CI의 특징과 반대로 DI는 본인인증을 하는 인증 업체별로 같은 사람이라도 서비스에 따라 다르게 DI 값을 발급한다는 차이가 있습니다.
즉, 같은 사람이라도 DI 정보는 공유되지 않고 따로 발급되기 때문에 다른 서비스끼리 이 값을 공유할 수가 없습니다.
따라서, DI 정보는 동일한 웹 사이트 내에서만 동일 사용자를 식별해야하는 경우에 유용하게 사용될 수 있습니다.
DI 암호 체계
CI가 주민등록번호를 일방향으로 해싱한 88byte의 암호화 정보라면 일반적으로 DI는 이 CI 값과 사이트고유코드를 합쳐 해싱한 64byte의 암호화 정보입니다. 예를 들어 나이스 본인인증 서비스를 사용하여 본인인증을 구현할 때에 나이스 본인인증으로 부터 발급 받은 사이트코드에 따라 동일 사용자에 대한 동일한 DI 값을 확인할 수 있습니다. 반대로 얘기하면 사이트코드만 달라지면 동일 사용자라도 다른 DI 값을 받게 됩니다.
현재 CI가 개인 정보 보호의 논쟁이 되는 이유
주민등록번호를 대체하여 사용하는 CI는 기술적으로 주민등록번호의 복원을 불가능하지만, 역추적하면 결국 주민등록번호와 1:1 맵핑이 가능하여 특정 개인을 식별 할 수 있는 문제가 있습니다. 따라서 정보 활용 측과 개인정보보호 측, 양쪽의 이해관계자 간의 입장 차이가 존재합니다.
그렇기 때문에 개발에서 CI 정보를 다룰 때에는 매우 주의깊게 사용해야 합니다. 내부에서 CI 값을 사용자의 고유 키로 사용하는 것보다는 동일 사용자 중복 검증 용도로만 사용해야하고 혹여나 데이터베이스에 저장해야하는 경우 꼭 한 번 더 암호화하여 CI 정보를 저장한는 것이 올바르다고 생각됩니다.
CI의 제한된 활용 범위
CI는 결국 주민등록번호를 암호화한 정보이기 때문에 글로벌 타겟으로 동일인을 확인하는 것에는 큰 제약이 발생합니다. 왜냐하면 CI는 대한민국 한정으로 동일 사용자를 식별할 수 있는 값이기 때문입니다.
그래서 현재 개발하고 있는 서비스가 정말로 CI값이 필요한지 검토가 필요합니다. 물론 본인확인기관으로 부터 CI 값을 전달 받기 위해서는 까다로운 검증 절차를 통과해야 사용할 수 있겠지만 만일 글로벌 사용자를 타겟으로 서비스를 구축해야한다면 오히려 CI를 활용하기 위해서 들어가는 비용과 시간이 더 비쌀 수 있습니다.
내가 활용한 방식
저는 B2B SasS를 개발하면서 로그인할 때에 2차 인증으로 나이스 본인인증 서비스를 활용해서 2차 본인인증 서비스를 구현하였습니다. 처음 본인인증 서비스를 구현하다 보니 초기 개발할때 CI와 DI에 대한 개념이 없었어서 사용자 이름과 휴대전화번호로 동일인을 확인하는 로직을 구현하였습니다. 그러다 다른 사람의 나이스 본인인증을 활용한 프로필 정보 수정 코드를 리뷰할 때 동일인을 확인할 수 없는 결함을 발견하였습니다. 사용자가 개명을 하면 어떡하지? 사용자의 휴대전화번호가 바뀌면? 이러한 질문이 계속해서 되뇌였고 다시 한 번 나이스 본인인증 문서를 자세히 살펴 보았습니다. 거기서 CI와 DI 파라미터를 확인하면서 이렇게 두 개념을 정확히 파악하고 이해하였습니다.
CI와 DI의 개념과 현재 논점들을 파악하고 난 후에 곧바로 동일인 확인 로직을 DI값으로 모두 수정하였습니다. 그리고 다시 코드 리뷰를 진행하면서 현재 이슈에 대해서 PR을 생성한 이유와 수정된 방식을 팀원 모두에게 공유하였습니다. 물론 다른 2차 인증 방식을 구현해볼까도 생각해봤지만 국내 기업을 타겟으로 개발된 현재의 서비스에서 고객사 계정의 동일인을 정확히 확인하는 것이 기존 빌링 정책이나 회원 정책에 더 중요하다는 PO의 피드백을 받고 그대로 나이스 본인인증 서비스를 연동하여 개발하였습니다.
마치며
오래전부터 CI와 DI에 대해서 논쟁이 많고 개개인 마다 바라보는 시각이 달라 CI와 DI가 어떤 방향으로 나아갈지 의문입니다. 아직 정확히 해결점이 보이지 않는 것으로 보아 온라인 상에 개인정보보호의 큰 문제가 발생하지 않는다면 한동안 정부에서 CI와 DI 체제를 바꾸지 않을 것으로 조심스럽게 예상합니다. 다음에는 글로벌 타겟으로 2차 인증을 할 수 있는 다양한 방법을 조사해보려고 합니다.
More posts like this
Search
