Windows 11 25H2의 Administrator Protection은 로컬 사용자가 필요한 순간에만 관리자 권한을 사용하도록 하고, 기존 UAC를 더 견고한 체계로 대체하려는 기능이다. 그런데 Google Project Zero는 Windows Administrator Protection 우회 분석을 공개해 새 권한 상승 경로 역시 공격 표면으로 검증해야 한다는 점을 드러냈다.

현재 제공된 자료만으로는 우회에 필요한 선행 조건, 영향받는 구성, 실제 피해 범위 또는 수정 여부를 확인할 수 없다. 따라서 기능 전체가 무의미하다고 단정하기보다, 권한 승인 화면 하나를 완전한 보안 경계로 간주해서는 안 된다는 교훈에 집중해야 한다.

Administrator Protection은 무엇을 바꾸려는가?

Project Zero가 설명한 핵심 목표는 로컬 사용자에게 관리자 권한을 상시 제공하지 않고, 필요한 작업에만 접근하게 하는 것이다. 일상적인 프로세스의 권한을 낮게 유지하고 관리 작업의 권한 상승을 제한하려는 방향으로 이해할 수 있다.

개발자 PC에서는 이 구분이 특히 중요하다. 패키지 설치, 디버깅, 로컬 서비스 구성, 빌드 도구와 자동화 스크립트가 시스템 권한을 요구할 수 있기 때문이다. IDE나 터미널 세션 전체를 관리자 권한으로 계속 실행하면, 그 안에서 손상된 프로세스가 필요 이상의 범위에 접근할 가능성도 커진다.

다만 적시 권한 부여가 실질적인 방어가 되려면 요청 사용자, 요청을 시작한 프로세스, 수행할 작업, 상승된 프로세스와 접근 대상 사이의 연결이 유지돼야 한다. 제공된 자료에는 Windows 11이 이를 내부적으로 어떻게 구현하는지 나오지 않으므로, 특정 토큰이나 프로세스 구조를 전제로 판단해서는 안 된다.

‘우회 가능’이라는 사실을 어디까지 해석해야 하나?

Project Zero의 연구 제목은 보호 기능을 우회하는 경로가 분석됐음을 보여준다. 그러나 이것만으로 모든 Windows 11 시스템이 영향을 받는다거나, 원격 공격만으로 즉시 관리자 권한을 얻을 수 있다거나, 초기 접근 권한이 전혀 필요하지 않다고 결론 내릴 수는 없다.

중요한 구분은 사용자 동의 절차와 실제 인가 경계다. 승인 창은 민감한 동작을 사용자에게 알릴 수 있지만, 운영체제가 올바른 프로세스에만 권한을 부여하고 해당 권한의 대상과 지속 시간을 제한해야 비로소 방어 통제가 된다.

권한을 얻은 뒤의 행위도 관찰해야 한다. 한 차례 인증이나 승인을 신뢰의 끝으로 보지 않는 지속적 ID 거버넌스와 행동 기반 탐지가 필요한 이유도 여기에 있다.

개발팀은 지금 무엇을 점검해야 하나?

우선 개발 과정에서 관리자 권한을 요구하는 지점을 목록화해야 한다. 시스템 구성 요소를 설치하기 위한 일회성 권한과 편집기, 터미널, 브라우저, 빌드 또는 테스트를 일상적으로 관리자 모드에서 실행하는 관행은 분리해 다뤄야 한다.

• 가능한 경우 IDE, 셸, 브라우저, Git 클라이언트와 빌드 에이전트를 표준 사용자 권한으로 실행한다.
• 시스템 단위 설치 작업을 평소의 의존성 설치, 컴파일 및 테스트 과정과 분리한다.
• 저장소 토큰, 클라우드 자격 증명과 코드 서명 키를 필요한 프로세스에만 노출한다.
• 권한 상승 프로세스 생성과 민감한 시스템 설정 변경에 대한 기존 로그를 수집한다.
• 사내 도구를 비관리자 계정으로 테스트해 숨은 권한 의존성을 찾는다.

이 조치들은 Project Zero가 다룬 문제를 직접 수정하는 패치가 아니다. 다만 로컬 프로세스가 침해됐을 때 피해 범위를 줄이고, 비정상적인 권한 상승을 조사할 근거를 확보하는 데 도움이 된다.

애플리케이션 역시 사용자가 로컬 관리자라는 사실만으로 민감한 동작을 허용해서는 안 된다. 업데이트 서비스, 플러그인, 로컬 에이전트처럼 사용자 컨텍스트와 시스템 컨텍스트를 연결하는 구성 요소는 작업 및 리소스 단위로 인가를 검증할 필요가 있다.

도입 확대 전에 어떤 검증이 필요한가?

조직은 영향받는 빌드, 공격의 전제 조건, 완화책과 업데이트 상태에 관한 권위 있는 안내를 기다려야 한다. 현재 자료에는 특정 설치 또는 정책에서 Administrator Protection이 기본 활성화되는지 여부도 제시돼 있지 않다.

별도의 테스트 그룹에서는 표준 사용자, 로컬 관리자, 조직이 사용하는 주요 애플리케이션 유형과 정상적인 권한 상승 작업을 조합한 검증표를 만들 수 있다. 각 작업이 필요한 권한만 얻는지, 작업 후 권한이 예상 밖으로 유지되지 않는지, 감사 로그로 사용자와 프로세스 흐름을 추적할 수 있는지 확인해야 한다.

검증되지 않은 익스플로잇을 운영 PC에서 시험하는 방식은 피해야 한다. Windows 11 25H2 자산을 먼저 파악하고, 격리된 환경에서 정책 변경을 검증하며, 개발 업무에 문제가 생길 경우 되돌릴 수 있는 경로를 준비하는 편이 안전하다.

결론

• Administrator Protection은 필요한 작업에만 관리자 권한을 제공하려는 기능이다.
• Project Zero의 우회 분석은 새 체계도 독립적인 보안 검증이 필요함을 보여준다.
• 공격 조건, 영향 범위와 수정 상태는 현재 제공된 자료로 확정할 수 없다.
• 최소 권한, 격리 테스트와 권한 상승 로깅은 지금 적용할 수 있는 현실적인 대응이다.

관련 글

• ID 보안, 지속적 거버넌스와 행동 기반 탐지로 전환
• AI 에이전트 보안은 모델 경계 밖까지 확장돼야 한다
• AI 에이전트, 보안 지원을 넘어 능동적 테스트와 대응으로

참고 자료

Bypassing Windows Administrator Protection