패스키 등록 피싱은 신뢰하는 서비스의 등록 페이지를 정교하게 복제한 가짜 사이트를 이용한다. 사용자가 공격자의 공개키를 서비스에 등록하게 만들거나, 등록 과정의 세션을 탈취해 공격자의 장치를 인증 수단으로 추가하는 원리다. Entra ID 환경이라도 등록 단계의 세션 관리와 도메인 검증 절차가 미흡하면 패스키의 기술적 무결성과 상관없이 계정을 탈취당할 수 있다.
패스키/WebAuthn 및 피싱 방어 기초
패스키는 FIDO2 및 WebAuthn 표준 기반의 무비밀번호(Passwordless) 인증 체계다. 공개키 암호화 방식을 사용해 사용자의 기기(Authenticator)에는 개인키를, 서버에는 공개키만 저장한다. 서버가 해킹되어도 개인키가 유출되지 않는 구조다. 특히 WebAuthn 표준은 브라우저가 현재 접속 중인 도메인(Origin)을 확인해, 등록된 도메인과 일치하지 않는 사이트에서는 인증 응답을 보내지 않는다. 전통적인 피싱 공격을 원천적으로 차단한다는 점이 입증된 셈이다.
다만 이러한 보안성은 패스키가 이미 ‘올바르게 등록된’ 상태여야 가능하다. 최근 CanSecWest, Zero Night, RSA Conference 같은 글로벌 보안 컨퍼런스에서는 패스키의 이론적 완벽함보다 구현 방식과 등록/인증 플로우의 의존성에서 오는 실무적 취약점이 집중적으로 보고되고 있다. 인증 단계가 아닌 등록 단계의 허점을 이용하면 패스키 역시 공격 대상이 된다.
패스키 등록 피싱 원리 및 취약점 분석
패스키 등록 피싱의 핵심은 사용자가 계정에 인증 수단을 추가하는 ‘등록 프로세스’를 공격자가 제어하는 것이다. 공격자는 정교하게 설계한 가짜 랜딩 페이지로 사용자를 유인한다. 이때 WebAuthn 응답 변조나 브라우저 및 OS의 구현 버그를 이용해 공격자의 공개키를 사용자의 Entra ID 계정에 등록하려 시도한다. 등록 단계에서 세션 하이재킹이 발생하거나 AppID 및 Origin 식별 과정의 AllowList 우회 취약점이 있다면, 사용자는 안전하게 등록하고 있다고 믿지만 실제로는 공격자에게 백도어를 열어주는 꼴이 된다.
구체적인 취약점 경로는 세 가지 관점에서 분석할 수 있다. 첫째는 등록 단계의 세션 관리 미흡이다. 공격자가 등록 프로세스 중 사용자의 세션 토큰을 탈취하거나 재사용하면, 사용자가 인증을 마친 직후 공격자의 장치를 인증 수단으로 등록할 수 있다. 둘째는 도메인 및 앱 식별 정책의 허점이다. 와일드카드(*)를 사용한 과도한 AllowList 설정은 공격자가 유사 도메인이나 신뢰받는 서브도메인으로 RP ID(Relying Party ID)를 우회하는 경로가 된다. 셋째는 사회공학적 기법과 UX의 결합이다. 복잡한 등록 및 복구 플로우 때문에 사용자가 보안 경고를 무시하게 되고, 이는 등록 UI 클로닝을 통한 피싱 성공으로 이어진다.
Microsoft Entra ID에서 FIDO2/패스키 등록 플로우와 구성 가이드
Microsoft Entra ID(구 Azure AD) 환경에서 패스키를 안전하게 운영하려면 테넌트 수준의 정책 설정과 조건부 액세스(Conditional Access)를 정밀하게 결합해야 한다. 단순히 FIDO2 보안 키 사용을 허용하는 수준을 넘어, 어떤 기기에서 어떤 조건으로 등록할 수 있을지 정의해야 한다. 특히 SOP(Same-Origin Policy)와 Lax-Redirect 흐름에서 발생할 수 있는 공격면을 최소화하도록 API 앱 권한과 리다이렉트 URI를 엄격히 관리해야 한다.
보안 관리자는 Entra ID의 FIDO2 정책 설정으로 인증 방법의 등록 및 사용 권한을 제어하고, 등록 시점의 트러스트 경계를 명확히 설정해야 한다. 모바일 앱과 웹 브라우저 간의 트러스트 경계가 모호할 때 발생하는 세션 고정 공격을 막으려면 TLS 1.2 이상의 최신 프로토콜을 적용하고, COOP(Cross-Origin-Opener-Policy), COEP(Cross-Origin-Embedder-Policy) 헤더로 오리진 격리를 검토하는 것이 좋다.
| 보안 요소 | 취약한 설정 (Risk) | 권장 설정 (Hardening) |
|---|---|---|
| RP ID / AllowList | 와일드카드(*) 사용, 광범위한 도메인 허용 | 명확한 FQDN 명시, 최소 권한 원칙 적용 |
| 세션 및 쿠키 | 긴 세션 수명, HttpOnly 미설정 | 짧은 수명의 Challenge, SameSite=Strict, HttpOnly |
| 등록 인증 | 단순 로그인 후 즉시 등록 허용 | 민감 작업 전 재인증(Step-up Auth) 및 MFA 결합 |
| 인프라 헤더 | 기본 HTTP 헤더 사용 | COOP/COEP 헤더 적용을 통한 오리진 격리 |
완화 및 하드닝 체크리스트와 운용 모범 사례
패스키 도입률이 2023~2024년 대비 2배 이상 증가하면서, 등록 단계의 세션/토큰 재사용이나 악의적 리다이렉트를 이용한 실제 인시던트 사례가 보고되고 있다. 이를 방지하기 위해 IT 보안 담당자는 다음과 같은 실무 체크리스트를 적용해 보안 수준을 높여야 한다.
- 등록 단계 트러스트 경계 강화
- 신뢰할 수 있는 특정 앱과 도메인에서만 등록이 가능하도록 제한하고, AppID/RP ID를 AllowList에 명확히 명시해 와일드카드 사용을 피한다.
- 사용자가 브라우저 주소창의 도메인과 인증서, 앱 출처를 직접 확인할 수 있게 UI 프롬프트를 강화하고 랜딩 페이지에 현재 도메인을 명확히 표시한다.
- 세션 및 토큰 보안 최적화
- 일회용 세션 및 짧은 수명의 challenge로 세션 고정 공격을 방지하고, CSRF 보호 및 토큰 회전(Rotation) 메커니즘을 구현한다.
- 모든 쿠키에 Secure, HttpOnly 속성을 부여하고 SameSite 설정을 Lax 또는 Strict로 지정해 크로스 사이트 요청 위협을 차단한다.
- 인증 플로우 및 UX 고도화
- 패스키 등록 같은 민감한 설정 변경 시에는 반드시 현재 로그인 상태를 재검증하는 재로그인 또는 추가 MFA 인증 단계를 둔다.
- 신규 패스키 등록 시 사용자에게 즉시 알림을 보내고, 관리자 로그에 등록 시간, IP, 장치 정보, RP ID를 상세히 기록해 감사 추적성을 확보한다.
- 복구 및 재등록 프로세스 설계
- 패스키 분실 시의 복구 절차가 가장 취약하므로, 단순 이메일 인증이 아닌 강력한 MFA나 이미 등록된 신뢰 기기, 물리적 복구 코드를 결합한 다중 인증 체계를 구축한다.
- 재등록 시에는 기존에 등록된 불필요한 키를 자동으로 해제하거나 기록을 유지해, 공격자가 몰래 추가한 키가 남지 않도록 관리한다.
- 지속적인 모니터링과 교육
- Entra ID 테넌트 정책과 조건부 액세스를 연동해 알 수 없는 지역이나 예상치 못한 RP ID에서의 등록 시도를 실시간으로 감지하고 차단한다.
- 최종 사용자에게 공식 채널 외의 인증 및 등록 요청은 피싱일 가능성이 높음을 교육하고, 의심 사례 발생 시 즉시 신고하는 절차를 마련한다.
결론 및 제언
패스키가 기존 비밀번호 기반 인증보다 강력한 피싱 저항성을 제공하는 것은 분명하다. 하지만 보안의 핵심은 기술 그 자체가 아니라 기술이 구현되는 ‘프로세스’에 있다. Microsoft Entra ID 환경에서도 등록 단계의 세션 관리, 도메인 검증, 복구 플로우에 허점이 있다면 공격자는 패스키의 방어막을 무력화할 수 있다.
완벽한 보안은 없다. 지속적인 하드닝과 모니터링만이 최선의 방책이다. 위에서 제시한 하드닝 체크리스트를 바탕으로 자사 테넌트의 FIDO2 정책을 재검토하고, 특히 등록 단계의 트러스트 경계를 다시 한번 점검하자. 지금 바로 Entra ID의 로그인 로그와 등록 기록을 분석해 비정상적인 RP ID나 장치 등록 사례가 없는지 확인하는 것부터 시작해야 한다.