.svg)
AI 솔루션 문의하기
비대면 본인확인 시스템의 보안 취약점 점검은 한 곳에서 한 번에 끝나지 않습니다. 사업자의 앱과 연동 서버, 그리고 외부 eKYC API와 SDK가 각각 다른 주체의 관리 아래 있기 때문에 구간별로 나누어 점검하고 책임을 정해 두어야 합니다. 이 글에서는 점검 범위를 나누는 기준과 업데이트·패치 운영 방식을 정리합니다.
외부 eKYC 솔루션을 쓰는 금융사와 핀테크 실무자가 가장 먼저 부딪히는 질문은 우리가 어디까지 점검해야 하느냐입니다. 솔루션 제공사가 자사 SDK와 API를 점검하더라도, 그 결과물을 앱에 넣고 서버와 연결하는 책임은 서비스 사업자에게 남습니다.
그래서 점검 주체는 보통 세 곳으로 나뉩니다. 사업자는 자체 앱, 연동 서버, 로그와 키 관리를 맡고, 솔루션 제공사는 SDK와 API 자체의 품질과 업데이트를 맡습니다. 마지막으로 두 주체가 만나는 연동 지점은 양쪽이 함께 확인해야 합니다.
이 구분이 문서로 남아 있지 않으면 취약점이 발견된 뒤에 누가 고치는지 논의하느라 시간을 쓰게 됩니다. 점검 항목보다 먼저 책임 구분표를 만드는 것이 순서상 맞습니다.
모호함은 대부분 구성 요소가 섞여 있다는 데서 생깁니다. 같은 인증 화면 안에서도 카메라 호출은 SDK가, 결과 전달은 사업자 서버가, 신분증 진위 확인은 외부 API가 처리하는 식입니다.
공격 유형별 대응은 별도로 정리한 안면인식 보안 가이드에서 다루었습니다. 이 글은 공격 방식이 아니라 발견된 취약점을 누가 어떤 순서로 반영하는지에 집중합니다.
점검을 세 구간으로 나누면 항목이 훨씬 구체적으로 정리됩니다. 각 구간에서 누가 확인하고 누가 고치는지를 함께 적어 두는 것이 핵심입니다.
취약점 점검의 결과는 결국 업데이트로 반영됩니다. 그래서 점검만큼 중요한 것이 공지를 받고, 영향을 따지고, 안 되면 되돌리는 흐름입니다.
업데이트 공지는 받는 사람이 정해져 있어야 합니다. 개인 메일 한 곳으로만 오면 담당자 변경 때 누락되므로 보안, 개발, 운영 담당이 함께 받는 공용 채널을 권장합니다. 공지를 받으면 변경 내용이 SDK, 서버 설정, API 호출 방식 중 어디에 해당하는지 먼저 분류합니다.
영향 평가에서는 인증 성공률, 응답 시간, 지원 단말 범위가 달라지는지를 테스트 환경에서 확인합니다. 신규 SDK를 일부 사용자에게 먼저 배포하고 지표를 본 뒤 전체로 넓히는 방식이 운영상 안전합니다.
알체라 eKYC를 연동할 때는 앞서 정리한 책임 구분표에 SDK 버전과 업데이트 공지 수신 담당을 함께 적어 두는 방식으로 운영할 수 있습니다. 알체라는 신분증 OCR과 진위확인, 얼굴 인증과 라이브니스, 1원 계좌 인증 등을 SaaS 또는 설치형으로 제공하므로, 사용하는 기능 단위로 어떤 SDK와 API가 앱과 서버에 들어가는지 목록화하면 점검 범위가 분명해집니다.
도입 단계에서는 SaaS 연동 30분, 개발을 포함한 전체 도입 평균 1~3개월 기준으로 일정을 잡고, 이 기간 안에 버전 기록 방식과 공지 수신 채널, 롤백 기준을 함께 합의해 두면 운영 이후 혼선이 줄어듭니다. 알체라는 고객사 110곳 이상과 계약 연장률 95.5%를 기반으로 연동 이후 운영 단계의 협의를 이어 가고 있습니다.
보안 체계 측면에서는 자회사 유스비와 함께 ISMS 인증을 보유하고 있으며, 인증 현황은 ISMS 인증으로 검증된 eKYC 보안 글에서 확인하실 수 있습니다. 다만 사업자의 앱과 서버 구간 점검은 사업자의 몫이므로, 알체라 구간과 사업자 구간의 경계를 문서로 맞추는 작업을 도입 초기에 함께 진행하시기를 권합니다.
.png)
.svg)
.svg)
