이 글의 목적은 Windows 11에서 LSA 보호(LSASS 보호 프로세스, RunAsPPL)를 활성화했을 때 발생하는 드라이버·보안 모듈 호환 충돌을 원인별로 진단하고, 보안을 약화시키지 않으면서 정상 동작으로 복구하는 실무 절차를 제공하는 것이다.
1. LSA 보호 모드에서 “드라이버 호환 충돌”이 발생하는 이유
LSA(Local Security Authority)는 로그인 인증과 자격 증명 처리를 담당하는 핵심 구성요소이다.
LSA 보호(추가 LSA 보호, LSA 보호 프로세스, RunAsPPL)는 lsass.exe를 보호된 프로세스로 실행하여 비정상 코드 주입과 메모리 덤프 등 공격 표면을 줄이는 목적의 보안 기능이다.
이 모드에서는 LSA에 로드되는 플러그인, 인증 패키지, 보안 지원 공급자(SSP), 관련 드라이버가 더 엄격한 서명·무결성 요구사항을 만족해야 한다.
기존 보안 제품, SSO 모듈, 구형 VPN·프린트·스마트카드 미들웨어, 레거시 인증 모듈 등이 요구사항을 충족하지 못하면 충돌 경고 또는 기능 장애가 발생할 수 있다.
주의 : LSA 보호는 자격 증명 탈취 방어에 직접적인 영향을 주는 보안 기능이다. “문제 해결”만을 이유로 무작정 비활성화하면 계정 탈취 리스크가 커질 수 있으므로, 먼저 감사(Audit) 기반으로 원인을 특정한 뒤 교체·업데이트 중심으로 해결해야 한다.
2. 증상 유형을 먼저 분류해야 해결이 빨라지다
LSA 보호 관련 문제는 크게 “실제 호환 충돌”과 “표시/상태 꼬임”으로 나뉘다.
| 유형 | 대표 증상 | 우선 진단 포인트 | 주요 해결 방향 |
|---|---|---|---|
| 실제 호환 충돌 | LSA 패키지 서명 경고, 특정 인증/SSO/VPN/보안 프로그램 로그인 실패, 부팅 후 보안 기능 비정상 | CodeIntegrity 이벤트(3065/3066 등), lsass 로드 실패 항목 | 문제 모듈 업데이트·교체, 필요 시 감사 모드로 영향 최소화 후 조치 |
| 상태 표시 꼬임 | Windows 보안에서 “켜짐”인데 경고가 뜨거나 반대로 표시됨 | 실제 lsass 보호 실행 여부 확인, 레지스트리/정책 값 점검 | 정책 값 정리, 재부팅, 보안 앱/Defender 구성 요소 업데이트 후 재확인 |
| 혼합형 | 표시 꼬임 + 실제 경고가 동시에 존재함 | 표시 문제와 충돌 로그를 분리해 각각 처리 | 로그로 원인 특정 후 조치, 표시 문제는 별도 정리 |
3. 1단계 진단: LSA 보호 관련 이벤트 로그로 “충돌 주범”을 특정하다
가장 중요한 원칙은 “어떤 드라이버/모듈이 LSA 보호 요구조건을 위반하는지”를 로그로 특정하는 것이다.
작업 순서는 이벤트 뷰어에서 CodeIntegrity 운영 로그를 확인하는 방식이 가장 재현성이 높다.
3.1 이벤트 뷰어 경로
이벤트 뷰어에서 다음 경로를 확인해야 한다.
응용 프로그램 및 서비스 로그 → Microsoft → Windows → CodeIntegrity → Operational 항목을 확인해야 한다.
3.2 대표 이벤트 ID 해석
현장에서 자주 보는 것은 다음 패턴이다.
| 이벤트 ID | 의미 | 실무 해석 | 다음 조치 |
|---|---|---|---|
| 3065 | 무결성 요구사항을 만족하지 못한 이미지가 LSA 관련 로드 과정에서 감지되었으나 정책상 허용됨 | 감사 모드 또는 허용 정책 때문에 “차단되지는 않았지만” 문제 후보로 기록된 상태이다 | 이벤트 상세에 표시되는 파일/드라이버 경로, 제품명, 서명 상태를 확인하여 업데이트 또는 교체 후보로 등록해야 한다 |
| 3066 | Microsoft 서명 수준 요구사항을 만족하지 못한 이미지가 감지되었으나 정책상 허용됨 | 서명 수준이 더 민감한 케이스로 분류해야 하며, 향후 “강제” 모드에서는 차단될 가능성이 높다 | 해당 구성요소를 최신 버전으로 교체하거나 공급사 패치 적용을 우선해야 한다 |
| 3089 등 | LSA가 보호 프로세스로 실행되지 않음으로 해석되는 신호로 사용되는 경우가 있음 | 정책은 켰는데 실제로는 보호 실행이 되지 않는 경우를 의심해야 한다 | 정책 값, 보안 부팅/UEFI 잠금 조건, 충돌로 인한 자동 폴백 여부를 점검해야 한다 |
주의 : 이벤트 상세에는 파일 경로와 드라이버/모듈 이름이 노출되는 경우가 많다. 해당 값을 그대로 공유하면 조직 환경 정보가 노출될 수 있으므로, 외부 공유 시에는 식별정보를 마스킹해야 한다.
4. 2단계 진단: 감사(Audit) 기반으로 “차단 없이” 영향도를 측정하다
LSA 보호를 곧바로 강제 적용하면 로그인 실패나 보안 제품 오동작이 발생할 수 있다.
따라서 감사 모드로 먼저 돌려서 “차단될 후보”를 수집한 뒤 대응하는 방식이 안정적이다.
4.1 감사 모드의 목적
감사 모드는 실제 차단을 수행하지 않고, 보호 모드에서 실패할 구성요소를 이벤트로만 남기는 운영 전략이다.
기업 환경에서는 이 단계에서 후보 목록을 만들고 공급사 업데이트를 받은 뒤 강제 모드로 전환하는 것이 정석이다.
4.2 감사 모드에서 확보해야 하는 체크리스트
| 체크 항목 | 확인 방법 | 기록해야 할 값 | 의사결정 기준 |
|---|---|---|---|
| 문제 모듈 식별 | CodeIntegrity Operational 이벤트 상세 확인 | 파일명, 경로, 제품/게시자, 서명 상태 | 공급사 최신 버전으로 해결 가능한지 판단해야 한다 |
| 업무 영향도 | 해당 모듈이 쓰이는 기능 테스트 | 로그인, SSO, VPN, 프린트, 스마트카드 등 시나리오별 결과 | 업무 필수 기능이면 “교체 또는 공급사 패치” 우선이다 |
| 대체 가능성 | 동일 목적의 제품/모듈 대체 조사 | 대체 제품명, 배포 방식, 비용/보안 등급 | 구형 모듈 유지 비용이 크면 교체가 정답이다 |
5. 해결 전략: “비활성화”보다 “업데이트·교체·정리”가 우선이다
원인 모듈을 특정했다면, 다음 우선순위로 처리해야 한다.
5.1 공급사 업데이트 적용이 1순위이다
LSA 보호 호환성 문제는 공급사가 최신 드라이버/모듈에서 서명 체계를 개선하여 해결하는 경우가 많다.
특히 SSO, EDR, VPN, 프린트 클라이언트, 스마트카드/PKI 미들웨어는 운영체제 보안 강화에 따라 업데이트가 필수인 제품군이다.
업데이트 후에는 동일 이벤트 ID가 재발하는지, 기능 테스트가 정상인지 재검증해야 한다.
5.2 더 이상 사용하지 않는 레거시 인증 모듈을 제거해야 한다
예전 프로젝트에서 설치된 구형 로그인 모듈이나 네트워크 인증 패키지가 남아 충돌하는 사례가 흔하다.
프로그램 제거만으로 남지 않는 드라이버/서비스도 있으므로, 제거 후에도 이벤트 로그가 사라지는지 확인해야 한다.
5.3 커널 드라이버 기반 제품은 서명 수준과 호환 정책을 함께 점검해야 한다
LSA 보호는 사용자 모드 보호이지만, 실제 충돌의 시작점이 커널 드라이버 또는 Code Integrity 정책과 연동되는 경우가 있다.
해당 제품이 최신 Windows 11 빌드와 호환되는지, 서명 체계가 최신인지, 보안 부팅 환경에서 정상인지 확인해야 한다.
주의 : “서명 우회” 또는 “보안 요구사항 완화”를 유도하는 설정 변경은 보안 사고로 직결될 수 있다. 실무에서는 반드시 공급사 공식 업데이트 또는 대체 제품으로 해결해야 한다.
6. 레지스트리·정책 설정 점검: LSA 보호 값이 꼬이면 증상이 반복되다
LSA 보호 관련 설정은 로컬 보안 정책, 그룹 정책, 레지스트리 값이 혼재될 수 있다.
특히 조직 환경에서는 그룹 정책이 주기적으로 값을 덮어쓰므로 “로컬에서만 바꿨는데 다시 원복”되는 현상이 발생할 수 있다.
6.1 주요 레지스트리 경로
다음 경로가 대표적인 제어 지점이다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa6.2 현장에서 자주 쓰는 값의 의미
환경에 따라 값이 다를 수 있으므로, 변경 전 현재 값을 백업하고 기록해야 한다.
| 값 이름 | 형식 | 대표 의미 | 실무 포인트 |
|---|---|---|---|
| RunAsPPL | DWORD | LSASS를 보호 프로세스로 실행하도록 구성하는 핵심 플래그로 이해하는 것이 일반적이다 | 조직 정책과 충돌하면 수시로 덮어써질 수 있으므로 정책 우선순위를 확인해야 한다 |
| RunAsPPLBoot | DWORD | 부팅 단계에서의 적용과 연관된 값으로 취급되는 경우가 많다 | 일부 환경에서 이 값의 유무가 상태 표시/동작에 영향을 줄 수 있으므로 함께 점검해야 한다 |
| AuditLevel | DWORD | 감사 모드 운용과 관련된 값으로 안내되는 경우가 있다 | 감사 모드에서 로그를 수집한 뒤 강제 모드로 전환하는 운영이 안전하다 |
주의 : 레지스트리 변경은 시스템 부팅 및 로그인에 직접 영향을 줄 수 있다. 변경 전 내보내기(Export)로 백업하고, 원복 절차를 준비한 뒤 적용해야 한다.
6.3 PowerShell로 현재 상태 확인에 도움 되는 기본 점검
다음 명령은 레지스트리 값을 빠르게 확인하는 데 유용하다.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPLBoot reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v AuditLevel값이 존재하지 않는다고 해서 곧바로 비정상이라고 단정하면 안 된다.
조직 정책, 보안 부팅, UEFI 잠금 구성, Windows 빌드 정책에 따라 활성화 방식이 달라질 수 있으므로 “이벤트 로그 기반”과 함께 해석해야 한다.
7. 실전 복구 시나리오: 가장 흔한 케이스별 처리 순서
7.1 케이스 A: 3065/3066 이벤트에 특정 드라이버 또는 모듈이 반복 등장하다
이 경우는 실제 호환성 이슈일 가능성이 높다.
처리 순서는 다음과 같이 가져가야 한다.
| 순서 | 조치 | 목적 | 성공 판정 |
|---|---|---|---|
| 1 | 이벤트 상세에서 파일명·경로·게시자 확인을 수행하다 | 주범 특정이다 | 동일 파일이 반복되는지 확인되다 |
| 2 | 공급사 최신 버전 업데이트 또는 패치를 적용하다 | 서명·호환성 개선이다 | 동일 이벤트가 더 이상 발생하지 않다 |
| 3 | 불필요한 레거시 구성요소를 제거하거나 대체하다 | 재발 제거이다 | 기능 테스트가 정상이며 로그가 깨끗하다 |
| 4 | 감사 모드에서 충분히 관찰 후 강제 적용을 검토하다 | 운영 안정성 확보이다 | 업무 기능 장애가 없고 보안 상태가 안정적이다 |
7.2 케이스 B: Windows 보안에서 “LSA 보호가 꺼짐” 경고가 뜨지만 실제로는 켜져 보이다
이 케이스는 상태 표시 불일치일 수 있다.
우선 “이벤트 로그에서 보호 모드 관련 로그가 정상적으로 생성되는지”와 “lsass 보호 실행 여부”를 확인해야 한다.
표시만 꼬인 경우라면 레지스트리 값 정리, 누적 업데이트 적용, 재부팅으로 해소되는 경우가 있다.
다만 혼합형일 수 있으므로, 3065/3066 같은 호환성 이벤트가 동반되는지 반드시 함께 확인해야 한다.
7.3 케이스 C: 특정 로그인/SSO/VPN이 실패하면서 사용자 인증이 불가능해지다
이 경우는 해당 제품이 LSA에 인증 패키지 또는 SSP 형태로 깊게 연결되어 있을 가능성이 있다.
무작정 LSA 보호를 끄는 방식 대신, 다음 원칙으로 접근해야 한다.
첫째, 공급사에 Windows 11 버전별 LSA 보호 호환 버전이 있는지 확인해야 한다.
둘째, 호환 버전이 없다면 동일 목적의 대체 제품 또는 Windows 기본 기능으로 전환을 검토해야 한다.
셋째, 긴급 복구가 필요하면 감사 모드 기반으로 일시 운영 후 근본 해결을 진행해야 한다.
주의 : “로그인이 안 된다”는 압박 때문에 보안을 영구적으로 낮추는 선택을 하면, 이후 계정 탈취 사고에서 방어선이 사라질 수 있다. 긴급 대응은 임시 운영으로 제한하고, 근본 조치는 제품 교체·업데이트로 마무리해야 한다.
8. 적용 후 검증: 재부팅만으로 끝내면 재발하다
LSA 보호 관련 조치는 반드시 검증 절차까지 포함해야 한다.
8.1 기능 검증 항목
다음 기능을 실제로 수행해 정상 여부를 확인해야 한다.
| 검증 항목 | 테스트 방법 | 정상 기준 |
|---|---|---|
| 로컬 로그인 | 재부팅 후 로컬 계정 및 도메인 계정 로그인 | 지연 없이 정상 로그인되다 |
| 원격 접속 | RDP 또는 원격 관리 도구 접속 | 인증 오류 없이 접속되다 |
| SSO/VPN | 업무 시스템 로그인 및 VPN 연결 | 인증 모듈 오류 없이 동작하다 |
| 이벤트 로그 | CodeIntegrity Operational 확인 | 문제 파일이 반복적으로 기록되지 않다 |
8.2 로그 검증 기준
동일 파일이 3065/3066으로 반복 등장하면, 당장은 동작해도 향후 강제 정책 또는 빌드 업데이트에서 차단될 가능성이 높다.
따라서 반복 항목은 “기술 부채 목록”으로 관리하며 계획적으로 제거해야 한다.
FAQ
LSA 보호를 끄지 않고도 호환성 문제를 해결할 수 있는가?
대부분의 경우 공급사 업데이트 적용, 레거시 모듈 제거, 대체 제품 전환으로 해결 가능하다.
핵심은 감사 모드로 문제 구성요소를 특정하고, 해당 구성요소만 정리하는 방식으로 접근하는 것이다.
이벤트 3065/3066이 있는데도 당장 장애가 없으면 그냥 둬도 되는가?
단기적으로 장애가 없더라도 장기적으로는 위험 신호로 보는 것이 안전하다.
운영체제 업데이트, 보안 정책 강화, 보안 부팅 구성 변경 등으로 “허용되던 것”이 차단될 수 있으므로, 반복 항목은 계획적으로 제거해야 한다.
Windows 보안에서 LSA 보호 상태가 이상하게 표시되면 무엇을 먼저 봐야 하는가?
표시만 꼬인 경우가 있으므로, 먼저 CodeIntegrity Operational 로그와 실제 기능 장애 유무를 확인해야 한다.
로그상 문제 모듈이 없고 기능이 정상이라면, 누적 업데이트 적용과 재부팅, 정책 값 정리로 정상 표시로 돌아오는 경우가 있다.
조직에서 그룹 정책을 쓰는데 로컬에서 바꾼 설정이 계속 되돌아가다
그룹 정책이 우선이기 때문에 발생하는 정상 동작일 수 있다.
이 경우에는 로컬 조치가 아니라 정책 서버에서 LSA 보호 구성과 감사 운영 정책을 함께 설계해야 한다.
LSA 보호 충돌 원인을 빠르게 공유하려면 어떤 정보가 필요하나?
이벤트 3065/3066 상세의 파일명, 경로, 게시자, 발생 시각, 해당 시점에 수행한 기능 동작 결과가 핵심 정보이다.
다만 파일 경로와 제품명이 조직 환경 식별로 이어질 수 있으므로 외부 공유 시에는 마스킹이 필요하다.