이 글의 목적은 Windows에서 LSA 보호 모드(LSASS 보호 프로세스)가 활성화된 뒤 드라이버·보안모듈·인증 확장 구성요소가 충돌하거나 로그인/인증이 불안정해지는 문제를 원인부터 진단 절차, 안전한 조치 순서까지 실무 수준으로 정리하는 것이다.
1. LSA 보호 모드에서 “드라이버 호환 충돌”이 발생하는 이유
LSA(Local Security Authority)는 로그인 검증, 보안 정책 적용, 자격 증명 처리에 관여하는 핵심 구성요소이다.
LSA 보호 모드(일명 RunAsPPL, LSASS 보호 프로세스)는 LSASS에 로드되는 플러그인·드라이버·인증 관련 모듈에 대해 서명 수준과 보안 요구 조건을 강화하는 기능이다.
이때 서명 요구를 충족하지 못하거나, 공유 섹션 등 보안 요구 조건을 충족하지 못하는 모듈이 있으면 LSA 로드가 실패하거나 일부 기능이 비정상 동작하는 구조이다.
1-1. 충돌로 나타나는 대표 증상
| 증상 | 현장 체감 | 자주 얽히는 구성요소 | 우선 확인 지점 |
|---|---|---|---|
| 로그인 지연/간헐 실패 | 부팅 후 로그인 창에서 멈춤 또는 인증 실패 | SSP, 인증 패키지, 암호 필터, SSO/보안 에이전트 | CodeIntegrity 운영 로그 이벤트 |
| 스마트카드/보안토큰 오류 | PIN 입력 후 인증 실패, 카드 미인식 | 스마트카드 미니드라이버, CSP/KSP, 관련 LSA 플러그인 | 드라이버 서명/WHQL 여부 |
| VPN/EDR/백신 기능 이상 | 접속 실패, 정책 미적용, 서비스 재시작 반복 | 자격증명 가로채기 방지 모듈, LSA 연동 모듈 | 문제 파일 식별 후 버전 업데이트 |
| “LSA 패키지 서명이 예상과 다름”류 경고 | 보안 앱에서 경고 또는 이벤트만 누적 | 서명 불일치 모듈 또는 OS 업데이트/보안 플랫폼 | 실제 LSA 보호 동작 여부 확인 |
2. 현재 LSA 보호 상태를 정확히 확인하는 방법
먼저 “LSA 보호가 켜져 있는지”, “UEFI 잠금 방식인지”를 확인해야 하다.
2-1. 레지스트리로 확인하는 방법
다음 경로의 값으로 상태를 판정할 수 있다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa - RunAsPPL (REG_DWORD)| RunAsPPL 값 | 의미 | 운영 관점 |
|---|---|---|
| 0 또는 값 없음 | LSA 보호 비활성 상태이다. | 충돌은 줄지만 자격 증명 보호 수준이 낮아지다. |
| 1 | UEFI 변수를 사용한 방식이다. | 원격/레지스트리만으로 쉽게 해제되지 않을 수 있지 않다. |
| 2 | UEFI 잠금 없이 활성화 방식이다. | 정책/레지스트리로 비교적 관리가 단순하다. |
2-2. 이벤트 로그로 “LSASS가 보호 프로세스로 뜨는지” 확인하는 방법
보안 앱 표시가 애매하거나 경고가 반복될 때는 실제 실행 상태를 이벤트로 확인하는 방식이 안정적이다.
이벤트 뷰어에서 시스템/부팅 관련 로그에 “LSASS.exe가 보호 프로세스로 시작되었다” 유형의 기록이 있는지 확인하는 방식이 유효하다.
3. 충돌 원인 파일을 로그로 ‘특정’하는 진단 절차
LSA 보호 문제는 “어떤 파일이 LSA에 로드되며 실패했는지”를 특정하는 단계가 핵심이다.
3-1. CodeIntegrity 운영 로그에서 봐야 하는 이벤트 ID
이벤트 뷰어에서 다음 경로를 확인해야 하다.
응용 프로그램 및 서비스 로그 > Microsoft > Windows > CodeIntegrity > Operational| 이벤트 ID | 의미 | 실무 해석 |
|---|---|---|
| 3033 | 서명 수준 요구를 충족하지 못한 이미지 로드 시도 기록이다. | LSA 보호가 실제로 강하게 작동 중일 때 ‘문제 파일 후보’로 취급해야 하다. |
| 3063 | 공유 섹션 등 보안 요구를 충족하지 못한 이미지 로드 시도 기록이다. | 일부 구형 모듈에서 빈번하며 업데이트가 정답인 경우가 많다. |
| 3065 | 감사 성격의 기록이며 공유 섹션 요구 미충족을 알리다. | 정책이 허용이라 실제 차단이 아니어도 향후 충돌 가능성 신호로 취급해야 하다. |
| 3066 | 감사 성격의 기록이며 서명 수준 요구 미충족을 알리다. | 차단 전 사전 점검 단계에서 중요도가 높다. |
3-2. 감사 로그를 강제로 켜서 문제 후보를 더 잘 잡는 방법
Windows 11 특정 빌드에서는 기본적으로 감사가 활성화되는 경우가 있으나, 환경에 따라 누락될 수 있으므로 강제 설정이 유용하다.
다음 레지스트리 경로에 AuditLevel 값을 설정하는 방식이 대표적이다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe - AuditLevel (REG_DWORD) = 0x00000008설정 후 재부팅하여 3065/3066 이벤트를 추가로 확보하는 방식이 실무적으로 유효하다.
3-3. wevtutil로 문제 이벤트를 빠르게 추출하는 방법
현장에서는 GUI 대신 명령으로 이벤트를 뽑아 “문제 파일 목록”을 빠르게 정리하는 방식이 효율적이다.
:: 최근 200개를 텍스트로 조회하다 wevtutil qe Microsoft-Windows-CodeIntegrity/Operational /c:200 /f:text
:: 특정 이벤트 ID만 필터링하여 조회하다
wevtutil qe Microsoft-Windows-CodeIntegrity/Operational /q:"*[System[(EventID=3033 or EventID=3063 or EventID=3065 or EventID=3066)]]" /c:200 /f:text
:: 운영 로그를 파일로 내보내다(분석/증빙용)
wevtutil epl Microsoft-Windows-CodeIntegrity/Operational C:\Temp\CodeIntegrity_Operational.evtx4. 문제 파일의 “소속 제품/드라이버 패키지”를 역추적하는 방법
이 단계는 “무엇을 업데이트하거나 제거해야 하는지”를 결정하는 단계이다.
4-1. PowerShell로 서명자와 파일 정보를 확인하는 방법
# 문제 파일 경로를 정확히 넣어 확인하다 $path = "C:\Windows\System32\drivers\example.sys" Get-Item $path | Select-Object FullName, Length, LastWriteTime
디지털 서명 상태를 확인하다
Get-AuthenticodeSignature -FilePath $path | Format-List4-2. 드라이버(.sys)라면 pnputil로 패키지 연결을 확인하는 방법
:: 설치된 드라이버 패키지를 열거하다 pnputil /enum-drivers
:: 장치 드라이버 인스턴스가 특정되면 장치 관리자에서 드라이버 세부 정보와 함께 확인하다4-3. LSA에 붙는 확장 모듈 여부를 레지스트리에서 확인하는 방법
LSA 관련 확장 구성은 제품에 따라 다음 위치에 등록되는 경우가 많다.
| 경로 | 값 이름 | 설명 | 대표 위험 |
|---|---|---|---|
| HKLM\SYSTEM\CurrentControlSet\Control\Lsa | Notification Packages (REG_MULTI_SZ) | 암호 변경 알림, 암호 필터 등과 연관되는 로드 지점이다. | 잘못 제거하면 로그인/암호 변경 흐름에 영향이 있을 수 있지 않다. |
| HKLM\SYSTEM\CurrentControlSet\Control\Lsa | Security Packages / Authentication Packages | SSP/인증 패키지 계열이 등록될 수 있는 지점이다. | 불명확한 항목 삭제는 즉시 장애로 이어질 수 있지 않다. |
5. 해결 절차의 정석: 업데이트 → 제거/대체 → (불가피 시) LSA 보호 조정
5-1. 1순위 조치: 문제 제품의 드라이버·모듈 업데이트를 적용하다
LSA 보호 모드 충돌은 대부분 “구버전 드라이버/보안모듈”에서 발생하며, 최신 WHQL 서명 또는 최신 호환 버전에서 해결되는 경우가 많다.
다음 업데이트 경로를 우선 적용해야 하다.
- 장치 제조사 정식 드라이버 업데이트를 적용하다.
- 보안 제품(EDR/백신/SSO/VPN) 에이전트의 최신 버전을 적용하다.
- 스마트카드·인증서 모듈은 공급사에서 “LSA 보호(보호 프로세스) 지원”을 명시한 버전을 적용하다.
5-2. 2순위 조치: 문제 모듈이 ‘선택 기능’이라면 비활성/제거로 분리하다
문제 파일이 특정 기능에만 필요하다면 해당 기능을 분리하는 방식이 효과적이다.
5-2-1. Notification Packages에 추가된 항목을 정리하는 방식
다음은 “제품이 추가한 항목만” 정리하는 접근이다.
1) regedit에서 HKLM\SYSTEM\CurrentControlSet\Control\Lsa 로 이동하다 2) Notification Packages 값을 내보내기(백업)하다 3) 문제 제품이 추가한 DLL 이름(확장자 없이 등록되는 경우가 많다)을 확인하다 4) 해당 제품 제거 또는 공급사 가이드에 따른 등록 해제를 수행하다 5) 재부팅 후 CodeIntegrity 이벤트가 사라지는지 확인하다5-2-2. 보안 패키지/인증 패키지 등록을 정리하는 방식
SSP/인증 패키지 계열은 영향도가 크므로 “제품 제거가 먼저”라는 원칙으로 접근해야 하다.
제품 제거 후에도 등록이 남는 경우에만 백업 후 잔여 항목을 정리하는 방식이 안전하다.
5-3. 3순위 조치: 불가피할 때만 LSA 보호를 일시 해제하다
업데이트/대체가 즉시 불가능하고 업무 중단을 막아야 하는 상황에서는 임시로 LSA 보호를 해제하는 선택지가 존재하다.
5-3-1. 레지스트리로 해제하는 방법
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa - RunAsPPL (REG_DWORD) = 0 또는 값 삭제하다
재부팅하여 적용하다5-3-2. 로컬 그룹 정책으로 해제하는 방법
gpedit.msc 컴퓨터 구성 > 관리 템플릿 > 시스템 > 로컬 보안 기관 > "보호된 프로세스 정책으로 실행되도록 LSASS 구성"을 '사용'으로 두고 옵션을 '사용 안 함'으로 선택하다 재부팅하여 적용하다5-3-3. UEFI 잠금 방식(값 1)에서 해제가 어려운 경우의 현실적 대응
RunAsPPL 값이 1 형태로 구성된 장치는 설정이 펌웨어 변수로 저장되는 구조일 수 있다.
이 경우 단순 레지스트리 변경이 기대대로 동작하지 않을 수 있으므로, 공급되는 UEFI 변수 제거 도구를 이용하는 절차가 필요할 수 있지 않다.
현장에서는 “원격에서 레지스트리만 만지다 실패”가 흔하므로, 사전에 구성 방식을 2로 운영하는 표준을 채택하는 것이 운영 안정성 측면에서 유리하다.
6. 재발 방지 운영 기준
6-1. 배포 전 점검 체크리스트를 운영하다
| 점검 항목 | 방법 | 판정 기준 |
|---|---|---|
| LSA 관련 확장 구성요소 목록화 | 문제 장비에서 LSA 관련 레지스트리 값과 설치 제품 목록을 수집하다 | “왜 필요한지 설명 가능한 항목”만 유지하는 것이 바람직하다 |
| 감사 이벤트 기반 사전 검증 | AuditLevel 설정 후 3065/3066 이벤트를 모으다 | 문제 후보가 0이 되도록 공급사 업데이트를 완료하다 |
| 표준 이미지/골든 빌드 기준화 | 표준 OS와 표준 에이전트 조합을 고정하다 | 예외 장비는 별도 정책과 검증 절차를 적용하다 |
6-2. 중앙 수집으로 “문제 파일 Top N”을 관리하다
조직에서는 이벤트 전달(이벤트 포워딩) 또는 중앙 로그 수집을 통해 3033/3063/3065/3066을 모아 “가장 많이 충돌하는 모듈”을 상시 관리하는 방식이 효과적이다.
이 방식은 특정 공급사 모듈이 업데이트 후 다시 문제를 만들 때도 조기 감지에 유리하다.
FAQ
LSA 보호를 켰는데 경고가 계속 뜨고 재부팅을 반복 요구하는 상황은 어떻게 판단하다?
표시 경고와 실제 동작이 불일치하는 경우가 존재하다. 이때는 레지스트리의 RunAsPPL 값과 이벤트 로그에서 LSASS 보호 프로세스 기동 흔적을 함께 확인하여 “실제로 켜졌는지”를 판단하는 방식이 안전하다.
로그에 3065/3066만 있고 3033/3063이 없는 경우는 무엇을 의미하다?
감사 성격의 이벤트만 누적되는 상황일 수 있다. 즉시 장애는 없더라도 해당 모듈이 요구 조건을 충족하지 못한다는 신호이므로, 향후 정책 강화나 OS 업데이트 이후 실제 차단으로 전환될 가능성을 고려하여 업데이트 계획을 수립하는 것이 바람직하다.
문제 파일이 어느 제품 것인지 도저히 식별이 안 되는 상황은 어떻게 접근하다?
PowerShell로 서명자, 파일 버전, 경로를 먼저 확보하는 것이 1단계이다. 드라이버라면 pnputil로 패키지를 추적하고, DLL이라면 설치 프로그램 목록과 서비스 등록, LSA 관련 레지스트리 등록 지점을 교차 확인하는 방식이 실무적으로 유효하다.
LSA 보호를 끄면 모든 문제가 즉시 해결되는가?
일부는 해결될 수 있으나, 근본 원인이 공급사 모듈의 호환성 결함인 경우 다른 보안 기능 또는 업데이트 이후 다른 형태로 재발할 수 있다. 따라서 임시 복구 후 반드시 호환 버전으로 교체하는 것이 정석이다.