패스키 도입 전 헬프데스크가 먼저 정해야 할 것

패스키는 비밀번호를 재사용하거나 피싱 사이트에 입력하는 문제를 줄이는 데 유리하다. 그러나 조직 배포가 시작되면 사용자는 정상 로그인보다 기기 교체, 분실, 고장, 출장, 퇴사 같은 예외 상황에서 더 많은 지원을 요청한다. 이때 복구 절차가 느슨하면 공격자는 패스키를 깨는 대신 헬프데스크를 설득해 새 인증 수단을 등록하려 한다.

따라서 패스키 프로젝트의 첫 산출물은 로그인 화면이 아니라 복구 플레이북이어야 한다. 피싱 저항 MFA 전환 로드맵이 기술 전환 순서를 다룬다면, 이 글은 지원 조직이 실제로 처리할 티켓과 증거를 중심으로 본다.

배포 전에 결정할 운영 경계

패스키라고 모두 같은 운영 특성을 갖는 것은 아니다. 동기화형 패스키와 기기 귀속형 패스키, 관리 기기와 개인 기기, 일반 사용자와 관리자 계정은 복구 방식과 위험이 다르다. 최소한 다음 결정을 문서로 고정해야 한다.

결정 항목	운영 질문	기록할 필드
허용 유형	동기화형·기기 귀속형 중 무엇을 허용하는가	유형, 공급자, 관리 여부
등록 기기	개인 기기와 비관리 기기를 허용하는가	기기 식별자, 소유 형태, 등록일
다중 등록	사용자가 몇 개의 인증 수단을 가져야 하는가	주 인증기, 백업 인증기
복구 권한	누가 본인 확인과 재등록을 승인하는가	담당자, 승인자, 근거
관리자 계정	일반 직원과 같은 복구 절차를 쓰는가	별도 승인선, 대체 인증 수단
예외	임시 비밀번호·OTP·보안 키를 허용하는가	사유, 범위, 만료일
퇴사·반납	인증기와 세션을 언제 폐기하는가	폐기 시각, 실행자, 확인 결과

고위험 계정은 하나의 인증기만 등록해 두지 않는 편이 안전하다. 다만 “여러 개 등록”이 곧 “아무 기기나 등록”을 의미해서는 안 된다. 관리자, 재무 승인자, 고객정보 접근자는 관리형 기기나 승인된 하드웨어 인증기 등 조직의 위험 기준에 맞는 방식을 사용해야 한다.

복구 요청을 두 단계로 분리하기

복구 티켓은 신원 확인과 인증 상태 정리를 분리해야 한다. 요청자가 누구인지 확인했다고 해서 바로 새 패스키를 등록하면 안 된다. 기존 기기와 세션이 살아 있는지, 공격자가 이미 계정에 들어와 있는지 확인해야 한다.

1단계: 요청자의 신원을 확인한다

친분, 목소리, 직급, 급한 사정은 증거가 아니다. 사전에 정한 채널과 증거를 사용한다. 예시는 다음과 같다.

• 관리 기기에서 시작된 인증된 지원 포털 요청
• 등록된 관리자 또는 직속 책임자의 별도 승인
• 인사 시스템과 일치하는 재직 상태 및 업무 정보
• 기존에 등록된 다른 인증기로 수행한 재인증
• 고위험 계정의 경우 두 명 승인 또는 영상 확인 등 강화 절차

헬프데스크 직원이 요청자에게 어떤 답을 기대하는지 알려 주지 않도록 질문 순서와 금지 항목도 정한다. 주민번호 전체, 비밀번호, 보안 질문처럼 유출되기 쉬운 정보에 의존하는 방식은 피한다.

2단계: 기존 인증 상태를 정리한다

새 패스키 등록만으로 복구가 끝나지 않는다. 다음 항목이 함께 완료되어야 한다.

• 분실·도난 기기의 패스키 또는 기기 신뢰 해제
• 기존 장기 세션과 리프레시 토큰 폐기
• 의심스러운 최근 로그인과 새 기기 등록 검토
• 임시 우회 수단의 자동 만료 설정
• 사용자와 관리자에게 복구 완료 알림
• 새 패스키로 주요 애플리케이션 재인증 확인

제로 트러스트 신원 경계 관점에서는 계정 복구 후 사용자만 확인할 것이 아니라 기기 상태, 세션, 애플리케이션 권한을 함께 다시 평가해야 한다.

반드시 리허설할 다섯 가지 시나리오

시나리오	실패 모드	플레이북에 들어갈 조치
휴대폰 교체	기존 기기를 초기화한 뒤 백업 인증기가 없음	신원 확인, 기존 등록 해제, 새 기기 등록, 세션 점검
노트북 분실	분실 기기의 로그인 세션이 계속 유효함	기기 격리, 세션 폐기, 위험 로그인 조사
해외 출장 중 실패	시간 압박으로 관리자에게 영구 예외를 부여함	제한된 범위의 임시 수단, 만료, 귀국 후 재등록
관리자 계정 잠김	같은 팀원이 단독으로 복구를 승인함	독립 승인자, 별도 보안 키, 모든 조치 기록
퇴사자 기기 반납	계정은 비활성화했지만 동기화된 인증기가 남음	계정·세션·기기 신뢰·연결 앱 토큰 일괄 폐기

리허설에서는 성공 여부만 보지 않는다. 누가 어떤 시스템에서 어떤 버튼을 눌렀는지, 처리 시간이 얼마나 걸렸는지, 사용자가 어느 단계에서 막혔는지 기록한다. 문서와 실제 제품 화면이 다르면 문서를 즉시 고친다.

티켓에 남겨야 할 최소 로그

복구 로그는 공격 조사에 필요하지만 과도한 개인정보 저장소가 되어서는 안 된다. 다음 정도면 운영과 감사에 필요한 맥락을 남길 수 있다.

• 요청자 계정 ID와 부서
• 요청 유형과 시작 시각
• 사용한 본인 확인 방식의 종류
• 확인자와 승인자
• 해제한 인증기 ID 또는 기기 ID
• 폐기한 세션의 범위
• 새 인증기 등록 시각과 유형
• 임시 예외의 만료 시각
• 완료 알림 전송 결과
• 관련 보안 경보 또는 조사 티켓

신분증 이미지나 영상 같은 민감 증거가 꼭 필요하다면 일반 헬프데스크 티켓 첨부와 분리하고, 열람 권한과 삭제 시점을 명확히 둔다. 평상시 티켓에는 “어떤 방식으로 확인했는가”라는 결과와 참조 번호만 남기는 편이 안전하다.

헬프데스크를 노리는 신호

복구 요청 자체를 보안 이벤트로 다뤄야 한다. 다음 패턴은 추가 검토 대상이다.

• 같은 계정에서 짧은 시간에 여러 채널로 복구를 시도한다.
• 요청자 위치·시간대와 근무 맥락이 맞지 않는다.
• 고위험 계정인데 긴급 사유로 승인자 생략을 요구한다.
• 복구 직후 새 지역 로그인, 권한 변경, 대량 다운로드가 이어진다.
• 한 헬프데스크 담당자가 비정상적으로 많은 예외를 승인한다.
• 임시 우회 수단이 만료되지 않거나 반복 연장된다.

이 신호는 “경보가 울리면 누가 무엇을 할 수 있는가”를 기준으로 설계한다. 예를 들어 관리자 복구 후 30분 이내 권한 변경이 발생하면 자동으로 세션을 제한하고 보안팀 검토를 요청하도록 할 수 있다. 시간과 임계치는 조직의 정상 패턴에 맞게 검증해야 한다.

파일럿의 성공 지표

첫 파일럿은 고위험 계정과 자발적 참여자를 섞되, 한 번에 전사 배포하지 않는다. 로그인 성공률만 보면 운영 취약점을 놓칠 수 있으므로 다음 지표를 함께 본다.

• 최초 등록 완료율과 평균 소요 시간
• 기기 교체·분실 티켓의 처리 시간
• 복구 요청 중 추가 검토 비율
• 임시 예외의 생성 수와 만료 준수율
• 등록 후 다시 비밀번호 방식으로 돌아간 사용자 비율
• 반복 문의가 많은 화면과 문구
• 관리자 계정 복구 리허설 성공 여부
• 기존 세션 폐기 누락 건수

파일럿 종료 조건도 정한다. 예를 들어 관리자 계정 복구가 문서대로 수행되지 않거나, 임시 예외가 자동 만료되지 않거나, 지원팀이 계정 소유자를 확인할 수 없다면 확대를 중단한다.

적용 전 체크리스트

• 허용할 패스키 유형과 기기 정책이 문서화되어 있다.
• 사용자는 최소 하나의 승인된 백업 인증 수단을 가진다.
• 일반 계정과 관리자 계정의 복구 승인선이 분리되어 있다.
• 새 인증기 등록 전 기존 세션과 기기 상태를 검토한다.
• 임시 우회 수단에는 범위와 만료일이 강제된다.
• 복구·등록·해제 이벤트가 중앙 로그에 남는다.
• 휴대폰 교체, 분실, 출장, 퇴사, 관리자 잠금 시나리오를 리허설했다.
• 사용자 알림과 이의 제기 경로가 준비되어 있다.

참고 기준

• FIDO Alliance: Enterprise Passkey Deployment Resources
• FIDO Alliance: Deploying Passkeys in the Enterprise
• NIST SP 800-63B Digital Identity Guidelines
• OWASP Multifactor Authentication Cheat Sheet

패스키의 보안성은 정상 로그인 화면에서만 결정되지 않는다. 기기를 잃어버린 날에도 같은 증거와 승인 기준으로 복구되고, 기존 세션이 폐기되며, 임시 예외가 사라져야 한다. 이 운영 경계가 준비되었을 때 헬프데스크는 우회로가 아니라 패스키 배포의 안전장치가 된다.