피싱 저항 MFA 전환 로드맵: 패스키 도입 전 확인할 것
패스키와 FIDO2 기반 MFA를 도입하려는 조직이 계정 복구, 예외 승인, 관리자 권한을 어떻게 재설계해야 하는지 정리했다.
핵심 요약
피싱 저항 MFA 전환은 로그인 버튼을 패스키로 바꾸는 프로젝트가 아니다. 사용자·관리자·기기 유형별 인증 강도, 등록과 복구, 예비 인증기, 레거시 프로토콜, 예외 만료, 비상 계정을 함께 설계해야 한다. 가장 약한 복구 경로가 전체 인증 수준을 결정한다.
일회용 코드와 푸시 알림을 사용하는 MFA는 비밀번호만 쓰는 것보다 낫지만, 가짜 로그인 화면이나 승인 피로 공격을 완전히 막지는 못한다. FIDO2/WebAuthn 기반 보안 키와 패스키는 서비스 도메인에 결합된 공개키 인증을 사용해 피싱 저항성을 높일 수 있다.
하지만 기술 선택만으로 전환이 끝나지 않는다. 등록하지 못한 기기, 분실한 보안 키, 신규 직원, 외주 인력, 공유 단말, 오프라인 환경, 관리자 비상 접근을 처리하지 못하면 조직은 결국 SMS·이메일·헬프데스크 우회로를 남긴다. 공격자는 바로 그 복구 경로를 노린다.
먼저 현재 인증 경로를 전수 조사한다
| 항목 | 확인할 내용 | 위험 신호 |
|---|---|---|
| 사용자 로그인 | 비밀번호, SMS, TOTP, 푸시, FIDO 비율 | 비밀번호만 가능한 앱 존재 |
| 관리자 접근 | 별도 계정, 인증기 종류, 기기 제한 | 일반 계정과 동일한 약한 MFA |
| 복구 | 본인 확인, 헬프데스크 권한, 승인 기록 | 이메일 한 번으로 MFA 초기화 |
| 레거시 | IMAP/SMTP, 앱 비밀번호, 오래된 VPN | MFA를 우회하는 프로토콜 |
| 서비스 계정 | 대화형 로그인 여부, 키 수명 | 사람이 공유하는 장기 비밀번호 |
| 예외 | 대상, 이유, 만료일, 보완 통제 | 소유자·기한 없는 SMS 예외 |
인증 로그에서 “MFA 사용률”만 보지 말고 실제 방법별 성공 건수, 관리자 계정의 인증 강도, 복구 후 로그인, 예외 경로 사용을 분리한다.
패스키 유형과 보증 수준을 구분한다
- 동기화 패스키: 사용자의 플랫폼 계정과 기기 간 동기화돼 편의성과 복구성이 높다. 조직은 해당 패스키 제공자의 계정 보호와 복구 방식을 검토해야 한다.
- 기기 바인딩 패스키·보안 키: 내보내기 어려워 고위험 관리자와 규제 환경에 적합할 수 있지만 분실·예비 키 배포와 물류가 필요하다.
- 플랫폼 인증기: 노트북·휴대폰의 생체인증 또는 PIN과 결합해 도입이 쉽지만 회사 기기 상태와 등록 정책이 중요하다.
- 로밍 보안 키: 여러 환경에서 사용할 수 있고 관리자가 예비 키를 보관할 수 있지만 자산 관리와 분실 대응이 필요하다.
모든 사용자에게 한 종류만 강제하기보다 위험도에 따라 조합한다. 예를 들어 일반 직원은 관리 기기의 동기화 또는 플랫폼 패스키를 사용할 수 있고, 최고 권한 관리자는 회사가 관리하는 기기 바인딩 인증기 두 개를 요구할 수 있다.
전환 우선순위
1단계: 최고 권한과 공격 표적부터
클라우드·IdP 관리자, 재무, 인사, 경영진, 고객 데이터 운영자를 먼저 전환한다. 관리자 계정은 일반 업무 계정과 분리하고 개인 기기에서 등록하지 못하게 한다. 정상 인증이 불가능할 때는 약한 복구를 열지 말고 별도의 관리자 비상 계정을 사용한다.
2단계: 핵심 SaaS와 원격접속
메일, 파일 공유, 소스 저장소, VPN·ZTNA, 클라우드 콘솔처럼 계정 탈취 영향이 큰 서비스를 연결한다. 앱마다 지원 수준이 다르므로 SSO에서 강한 인증을 요구하고, 직접 로그인·로컬 계정 우회가 남아 있는지 확인한다.
3단계: 전사 등록과 기본값 전환
사용자에게 주 인증기와 예비 인증기를 등록하게 한다. 등록 완료율과 실제 사용률이 목표에 도달한 뒤 피싱 가능한 방법을 기본값에서 제거한다. “등록은 했지만 계속 푸시 MFA를 쓰는” 상태를 별도로 추적한다.
4단계: 레거시와 예외 종료
SMS, 음성, 앱 비밀번호, 기본 인증, 구형 VPN 경로를 종료한다. 업무상 예외는 사용자 단위가 아니라 시스템 개선 티켓과 연결하고 만료일 이후 자동 차단한다.
복구 정책이 인증보다 약해지지 않게 한다
계정 복구는 다음 원칙을 따른다.
- 가능하면 사용자가 두 개 이상의 인증기를 사전 등록한다.
- 복구 요청자는 기존 세션·관리 기기·관리자 확인 등 복수 증거로 검증한다.
- 헬프데스크 한 명이 최고 권한 계정의 MFA를 초기화하지 못하게 한다.
- 복구 후 일정 시간 고위험 작업을 제한하거나 추가 승인을 요구한다.
- 기존 인증기 폐기와 새 인증기 등록을 하나의 감사 이벤트로 남긴다.
- 복구 알림을 기존 연락 채널과 보안 담당자에게 보낸다.
- 공격자가 연락처를 먼저 바꾼 뒤 복구하지 못하도록 변경 대기시간을 둔다.
공유 질문, 생년월일, 개인 이메일만으로 피싱 저항 인증을 복구하게 하면 전체 보증 수준이 그 약한 경로로 낮아진다.
사용자 경험에서 실패하는 지점
- 브라우저·OS·가상 데스크톱 호환성을 충분히 시험하지 않는다.
- 등록 화면이 주 인증기와 예비 인증기의 차이를 설명하지 않는다.
- 기기 교체와 신규 입사 절차가 별도로 문서화되지 않는다.
- 보안 키를 한 개만 지급해 분실 시 즉시 약한 우회로를 연다.
- 개인 플랫폼 계정 동기화 허용 여부가 불명확하다.
- 외주·현장·공용 단말 사용자를 일반 직원과 같은 방식으로 처리한다.
- 패스키 등록 후 레거시 MFA를 무기한 유지한다.
파일럿에는 보안팀뿐 아니라 Windows·macOS·모바일·VDI·현장 사용자, 접근성 요구가 있는 사용자, 외주 인력을 포함한다.
탐지 신호와 성공 지표
| 지표 | 의미 |
|---|---|
| 사용자별 패스키 등록 수 | 단일 인증기 의존 여부 |
| 피싱 저항 방식의 실제 로그인 비율 | 등록만 하고 사용하지 않는 문제 |
| 관리자 계정의 약한 MFA 성공 건수 | 우회 경로 잔존 |
| MFA 초기화·복구 요청률 | UX 또는 공격 시도 이상 |
| 복구 후 새 기기·새 국가 로그인 | 계정 탈취 가능성 |
| 예외 계정 수와 평균 만료 기간 | 전환 부채 |
| 앱 비밀번호·레거시 프로토콜 사용 | MFA 우회 가능성 |
| 인증 실패 후 헬프데스크 호출 | 호환성과 교육 문제 |
도입 성공은 등록률 100%가 아니라 약한 인증 사용량과 예외가 실제로 감소하고, 복구가 통제된 상태에서 업무 중단이 관리되는지로 판단한다.
전환 중 사고 대응
피싱 또는 계정 탈취가 의심되면 비밀번호만 바꾸지 않는다. 활성 세션, refresh token, 앱 비밀번호, OAuth 동의, 등록된 인증기 변경, 헬프데스크 복구 기록을 함께 확인한다. 관리자 계정은 관련 API 키와 클라우드 세션까지 조사한다.
원격 근무 환경에서는 원격근무 보안 기준선과 BYOD 기기 신뢰도 정책을 연결해 등록된 인증기가 안전한 기기에서 사용되는지 확인한다.
운영 체크리스트
- 인증 방법별 사용량과 우회 경로를 전수 조사한다.
- 관리자·재무·경영진 등 고위험 사용자부터 전환한다.
- 일반 계정과 관리자 계정의 인증 정책을 분리한다.
- 주 인증기와 예비 인증기를 함께 등록한다.
- 복구가 기존 인증보다 약한 단일 증거에 의존하지 않는다.
- 복구 후 세션·기존 인증기·연락처 변경을 검토한다.
- SMS·앱 비밀번호·레거시 프로토콜 종료 일정을 정한다.
- 예외에 소유자·보완 통제·만료일이 있다.
- 등록률뿐 아니라 실제 피싱 저항 로그인 비율을 측정한다.
함께 읽을 글
패스키 전환 전 공유 비밀번호를 줄이려면 전사 비밀번호 관리자 도입 순서를, 정상 IdP 장애에 대비하려면 관리자 비상 계정 운영을 함께 점검한다.
참고 기준
- CISA: Implementing Phishing-Resistant MFA
- CISA: More Than a Password
- FIDO Alliance: Deploying Passkeys in the Enterprise
- NIST Digital Identity Guidelines
결론
패스키 도입의 가장 어려운 부분은 암호 기술이 아니라 등록, 복구, 예외와 레거시 종료다. 고위험 사용자부터 실제 사용을 늘리고, 복구를 강하게 만들며, 피싱 가능한 우회 경로를 계획적으로 닫는 전환이어야 보안 효과가 남는다.
전체 댓글 0개