디바이스 코드 피싱 대응 가이드: Entra ID 사용자 승인과 조건부 액세스 점검 포인트

디바이스 코드(Device Code) 플로우는 TV·프린터·IoT처럼 브라우저나 입력 장치가 제한된 환경을 위한 OAuth 2.0 인증 방식이다. 사용자는 다른 기기의 브라우저에서 인증하고, 원래 기기는 토큰을 받아 서비스를 이용한다. 이 편의 흐름은 공격자가 발급한 코드와 정상 Microsoft 로그인 페이지를 결합할 때 피싱에 악용될 수 있다.

위협을 정확히 구분하기

공격자는 사용자를 설득해 verification_uri에서 코드 입력과 로그인을 하게 만들 수 있다. 사용자가 인증을 마치면, 코드를 요청해 둔 클라이언트 세션이 해당 범위의 토큰을 받는다. Microsoft 문서는 디바이스 코드 플로우가 기기 코드·사용자 코드를 발급하고, 사용자가 다른 브라우저에서 인증한 뒤 클라이언트가 토큰을 받는 구조임을 설명한다.[^1]

여기서 디바이스 코드 로그인과 OAuth 애플리케이션 권한 동의는 같은 일이 아니다. 업무·학교 계정의 디바이스 코드 인증에 항상 별도 동의 화면이 뜨는 것은 아니다.[^1] 다만 낯선 앱의 권한 요청을 승인하면 피해 범위가 더 커질 수 있으므로, 사용자 안내와 앱 동의 정책을 별도로 점검해야 한다.

우선 대응: 사용 여부를 확인한 뒤 차단

Microsoft는 디바이스 코드 플로우를 가능한 한 전면 차단하고, 불가피한 레거시 도구 등 문서화되고 보호된 사례에만 허용하라고 권고한다.[^2] 무작정 즉시 차단하면 운영 도구가 멈출 수 있으므로 다음 순서가 안전하다.

1. 서비스·스크립트·현장 장비에서 디바이스 코드 인증이 실제 필요한지 소유자와 용도를 목록화한다.
2. Entra 관리 센터에서 Entra ID > Conditional Access > Policies > New policy를 연다.
3. 대상은 원칙적으로 모든 사용자와 모든 리소스로 잡고, 비상 접근 계정은 예외로 둔다.[^2]
4. Conditions > Authentication flows에서 Device code flow를 선택하고, Grant > Block access를 설정한다.[^2]
5. 처음에는 Report-only로 배포한다. 이 모드는 정책을 평가·기록하지만 강제하지 않으며, 결과는 로그인 로그의 Conditional Access/Report-only 탭에서 확인할 수 있다.[^3]
6. 업무 영향과 예외 목록을 검토한 뒤 정책을 On으로 전환한다.

비상 접근 계정은 잠금 사고를 막기 위한 계정이므로 차단 정책에서 제외하되, Microsoft가 안내하는 것처럼 두 개 이상을 두고 피싱 저항성 인증수단을 등록하며 정기적으로 로그인·감사 로그를 확인한다.[^4]

탐지와 조사

조사 시 Entra 로그인 로그에서 해당 사용자·시간·IP·위치·앱 표시 이름/앱 ID·클라이언트·조건부 액세스 적용 결과를 함께 확인한다. Microsoft Graph의 signIn 리소스는 앱 이름·앱 ID·IP·기기 정보·위치·위험 정보·적용된 Conditional Access 정책을 제공한다.[^5] 평소 쓰지 않던 앱 또는 위치, 사용자 신고 시점과 일치하는 대화형 로그인, Report-only에서 차단 대상이 된 이벤트를 우선 분류한다. 단일 필드나 IP만으로 침해를 단정하지 말고 사용자 확인과 앱/토큰 범위를 함께 대조한다.

의심이 확인되면 해당 계정의 세션·토큰을 무효화하고, 관련 애플리케이션의 권한과 사용자 동의를 검토·철회하며, 계정 자격 증명과 MFA 등록 수단도 점검한다. 실제 대응 절차는 조직의 IR 승인 체계와 Microsoft 권고에 맞춰 수행한다.

사용자 안내 문구

• 본인이 시작하지 않은 장치 연결을 이유로 받은 코드 입력 요청은 진행하지 않는다.
• 정상 Microsoft 로그인 페이지여도, 요청을 시작한 기기·앱·업무 목적이 확인되지 않으면 로그인하거나 권한을 승인하지 않는다.
• 코드를 입력했거나 낯선 권한 요청을 승인했다면 즉시 보안팀에 시간·앱 이름·스크린샷을 알린다.

배포 전 체크리스트

• [ ] 디바이스 코드 플로우의 실제 사용처와 담당자를 확인했다.
• [ ] 비상 접근 계정과 필수 예외를 문서화하고 정기 검토한다.
• [ ] 차단 정책을 Report-only로 먼저 평가하고 로그인 로그 결과를 검토했다.
• [ ] 사용하지 않는 경우 차단 정책을 적용했다.
• [ ] 사용자 신고 경로와 앱 권한·토큰 조사 절차를 운영 문서에 반영했다.

출처

[^1]: Microsoft Learn, OAuth 2.0 device authorization grant — 디바이스 코드 인증의 목적, 코드·토큰 흐름, 업무/학교 계정의 동의 동작.
[^2]: Microsoft Learn, Block authentication flows with Conditional Access policy — Device code flow 차단 권고 및 정책 설정 절차.
[^3]: Microsoft Learn, Conditional Access Policy Insights: Monitoring and Evaluation — Report-only 동작과 로그인 로그 검토 방법.
[^4]: Microsoft Learn, Manage emergency access admin accounts — 비상 접근 계정의 구성·예외·모니터링.
[^5]: Microsoft Learn, signIn resource type — Microsoft Graph — 로그인 로그에서 제공되는 앱, IP, 위치, 위험, 조건부 액세스 필드.

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.