.svg)
AI 솔루션 문의하기
제로 트러스트 아키텍처 생체 인증은 기기에 등록된 인증수단을 확인하는 단계와 그 인증수단을 사용하는 사람이 누구인지 증명하는 단계를 구분해야 합니다. FIDO 기반 패스키는 기기에서 암호키를 사용해 로그인을 확인하지만, 패스키 등록자가 실제 계약 당사자나 계정 명의인이라는 사실까지 자동으로 증명하지는 않습니다. 이 차이를 고려하지 않으면 최초 등록이나 계정 복구 시점에 잘못된 신원이 계정과 연결될 수 있습니다.
제로 트러스트의 기본 원칙은 사내망 접속이나 과거 로그인 성공만으로 이후 요청까지 신뢰하지 않는 것입니다. NIST의 제로 트러스트 아키텍처 역시 사용자·기기·리소스의 상태를 반영한 접근 판단과 지속적인 재평가를 일반적인 방향으로 제시합니다. 다만 지속 검증은 이용자의 얼굴을 항상 촬영한다는 뜻이 아닙니다. 접근 대상과 위험 신호가 바뀔 때 기존 인증의 신뢰 수준을 다시 판단하는 방식입니다.
제로 트러스트의 전반적인 구성과 접근 제어 원칙은 알체라의 제로 트러스트 보안 가이드에서 확인할 수 있습니다. 이 글에서는 원칙 자체보다 FIDO 로그인에 신원 증명을 추가하고, 어떤 순간에 얼굴 재인증을 요구할지에 집중합니다.
FIDO 인증과 신원 증명은 목적과 확인하는 정보가 다릅니다. 기업은 두 절차를 한 화면의 인증 경험으로 연결하더라도 시스템 설계에서는 별도로 관리해야 합니다.
FIDO2 기반 패스키는 공개키·개인키 방식으로 서비스에 로그인합니다. 사용자가 스마트폰에서 얼굴이나 지문, PIN 등으로 인증수단 사용을 승인하면 서비스는 암호학적 응답을 검증합니다. 기기 내 생체정보는 일반적으로 서비스 서버로 전달되지 않으며, 패스키 인증은 생체 원본을 중앙에서 대조하는 절차가 아닙니다.
또한 패스키는 기기에만 묶인 형태와 여러 기기에 동기화되는 형태가 있습니다. 기기 변경 정책을 설계할 때는 동기화 가능 여부와 새로운 인증수단 등록 경로를 함께 검토해야 합니다.
신원 증명(Identity Proofing)은 신분증에 적힌 신원정보와 인증을 진행하는 실제 사람을 연결하는 절차입니다. 사업자는 서비스 위험에 따라 신분증 OCR·진위확인·사본판별, 촬영 얼굴과 신분증 사진의 매칭, 라이브니스 검사 등을 조합할 수 있습니다.
이 단계에서 확인된 신원은 이후 인증수단을 추가하거나 복구할 때 비교 기준이 됩니다. 단, 얼굴 매칭과 라이브니스만으로 모든 신원 위조나 계정 탈취를 원천 차단할 수 있다고 보아서는 안 됩니다.
최초 등록은 계정의 신원 기준점을 만드는 과정입니다. 기기에서 얼굴 잠금 해제가 된다는 사실만으로 신원 등록을 완료하기보다, 본인확인 결과를 먼저 확보하고 그다음 패스키를 계정에 묶는 순서를 권장합니다.
가입자가 신분증을 촬영하면 서비스는 OCR로 신원정보를 추출하고, 지원되는 진위확인·사본판별 절차를 수행합니다. 이어 실시간 얼굴을 촬영해 신분증 사진과 얼굴 매칭을 진행하고, 필요 시 라이브니스로 사진 또는 영상 재생에 의한 위조 시도를 점검합니다. 확인되지 않은 신분증, 동일인 불일치, 위조 의심 결과는 자동 승인하지 않고 재촬영이나 별도 심사로 전환합니다.
신원확인이 완료되면 해당 결과를 이용자 계정과 연결하고 패스키 등록을 요청합니다. 서버는 등록된 공개키와 계정의 연관 관계를 관리하며, 이후 로그인 시 해당 패스키의 응답을 검증합니다. 신원확인 성공 기록과 패스키 등록 성공 기록은 별도로 남겨야 등록 과정에서 누가 어떤 인증수단을 추가했는지 추적할 수 있습니다.
등록 도중 앱을 종료하거나 촬영 검증에 실패한 경우에는 기존 인증 상태에 따라 재시도 범위를 제한합니다. 확인 절차를 우회해 패스키를 먼저 등록하도록 허용하지 않으며, 반복 실패·비정상 기기 변경이 동반되면 별도 검토 대상으로 분류합니다. 개인정보와 생체정보는 서비스 목적에 필요한 범위로 처리하고, 보관·폐기·접근 권한을 사전에 설계해야 합니다.
지속 검증은 매 요청마다 생체정보를 수집하는 방식보다 접속 맥락과 요청 위험도에 따라 인증 강도를 조정하는 방식이 적합합니다. 일반 조회는 등록된 패스키와 세션 상태로 처리하더라도, 계정 소유권이나 자산 이동에 직접 영향을 주는 요청에는 더 높은 확인 수준을 적용할 수 있습니다.
위 조건은 일률적인 차단 기준이 아닙니다. IP 위치나 접속 시각 하나만으로 악성 사용자를 확정하지 않고, 여러 신호와 업무 위험을 함께 평가해야 정상 이용자의 불필요한 인증 실패를 줄일 수 있습니다.
기존 패스키 로그인만으로 신원 신뢰를 다시 확인하기 어려운 새 인증수단 등록·고위험 거래 직전에는 알체라 eKYC의 신분증 검증·얼굴 매칭·위변조 판별을 추가 신원확인 단계로 연계할 수 있습니다. 예를 들어 고위험 요청을 감지한 고객사 시스템이 얼굴 재인증을 호출하면, 알체라의 검증 결과를 받아 계정의 기존 확인 정보와 대조한 뒤 요청을 진행할지 보류할지 결정하는 구조입니다. 알체라는 신원 검증 기능을 제공하며, 위험 점수 산정·접근 권한 부여·최종 거래 승인은 고객사의 정책 엔진이 담당합니다.
인증 정책은 정상 인증에 성공했을 때뿐 아니라 재인증이 실패하거나 인증수단을 잃어버렸을 때도 안전하게 작동해야 합니다. 기업은 FIDO 인증 오류, 신원 불일치, 라이브니스 실패, 기기 변경 요청을 하나의 실패 상태로 묶지 않고 원인별로 처리해야 합니다.
위험 수준의 임계값은 업종, 개인정보 민감도, 거래 규모, 오탐 허용 수준에 따라 정해야 합니다. 예시 정책을 규제상 고정 기준이나 알체라가 제공하는 자동 차단 기능으로 오해해서는 안 됩니다.
기기 분실이나 패스키 사용 불가 상황에서는 새로운 인증수단을 등록할 권한이 누구에게 있는지 다시 확인해야 합니다. 복구 이메일이나 휴대전화 인증에만 의존하면 탈취된 복구 수단이 새 패스키 등록으로 이어질 수 있습니다. 기존에 확인된 신원과 신분증·얼굴 재확인 결과를 대조하고, 새 인증수단 등록 시 기존 등록 기기에 알림을 제공하거나 고위험 기능에 일시적인 제한을 적용하는 방식을 검토할 수 있습니다.
한편 동기화 패스키를 이용한 정상적인 새 기기 로그인과 새 계정 인증수단 등록은 서로 다른 사건입니다. 각각의 신뢰 수준을 구분해 설계해야 정상적인 기기 교체까지 과도하게 막지 않을 수 있습니다.
접근 정책의 판단 근거, 추가 인증 요청 시점, 검증 결과, 최종 승인 주체를 기록해야 이후 오류 분석과 사고 대응이 가능합니다. 다만 로그에 신분증 원본 이미지나 생체정보를 무제한으로 남길 필요는 없습니다. 인증 이벤트·판정값·승인 이력을 우선 설계하고, 원본 데이터의 수집·보관은 관계 법령과 동의 및 운영 목적에 맞춰 최소화해야 합니다.
제로 트러스트 아키텍처 생체 인증을 구현할 때는 한 가지 인증 기술보다 최초 신원확인과 이후 접근 검증이 연결되는지를 우선 점검해야 합니다. 기기 내 FIDO 인증은 등록된 인증수단을 사용하는지 확인하고, 신분증·얼굴 매칭은 실제 사람과 계정의 신원을 연결합니다. 재인증 시점은 두 기술의 차이를 이해한 뒤 위험 기반으로 정하는 것이 적절합니다.
실무 점검 항목은 다음과 같습니다.
결국 기기 내 FIDO 로그인과 실명 기반 신원 증명, 위험에 따른 추가 얼굴 인증을 역할별로 나눠 설계해야 사용자 편의성을 유지하면서도 중요한 요청에 대한 검증 수준을 조정할 수 있습니다.
.png)
.svg)
.svg)
