- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Windows에서 DPAPI(Data Protection API) 마스터키 손상 또는 불일치로 인해 저장된 암호·토큰·자격 증명 복호화가 실패하는 상황을 정확히 진단하고, 복구 가능 범위를 구분하여 안전하게 복구 또는 재초기화까지 완료할 수 있도록 실무 절차를 제공하는 것이다.
1. DPAPI 마스터키 손상 문제의 본질과 영향 범위
DPAPI는 Windows에서 “현재 사용자” 또는 “로컬 컴퓨터” 범위로 데이터를 암호화·복호화하기 위한 기본 기능이다. Windows 자격 증명 관리자, Windows Vault, 브라우저(Chromium 계열 포함)의 로컬 비밀값, 일부 VPN/업무 클라이언트의 토큰, 인증서 개인키 보관소, Wi-Fi/원격접속 구성 요소 등 다양한 영역이 DPAPI에 의존한다.
DPAPI 복호화 실패는 “앱이 비밀번호를 잊어버린” 문제가 아니라 “복호화 열쇠 체계(마스터키)가 손상되었거나, 열쇠를 여는 조건(계정 암호, 도메인 복구, 프로필 상태)이 바뀌어 더 이상 열 수 없는” 상태이다. 따라서 복구는 반드시 (1) 기존 마스터키를 정상 상태로 되돌리는 접근과 (2) 기존 암호문을 포기하고 새로 생성하는 접근을 분리하여 진행해야 한다.
2. 대표 증상과 확인 포인트
현장에서 자주 관찰되는 증상은 다음과 같이 정리할 수 있다.
| 증상 | 사용자 체감 | 자주 연관되는 영역 | 우선 확인 위치 |
|---|---|---|---|
| 저장된 암호/토큰이 갑자기 모두 풀리지 않음 | 자동 로그인 실패, 동기화 중단, 앱이 반복 로그인 요구 | 자격 증명 관리자, 브라우저, 업무 클라이언트 | 이벤트 뷰어 Crypto-DPAPI, Security 감사 이벤트 |
| 브라우저가 계속 로그아웃되거나 “암호 저장”이 깨짐 | 동기화 일시중지, 쿠키/세션이 유지되지 않음 | Chromium 기반 브라우저 비밀 저장소 | Crypto-DPAPI 로그, 브라우저 내부 로그 |
| Windows Hello, 인증서/개인키 관련 오류가 동반됨 | PIN 재설정 요구, 인증서 사용 실패 | 키 저장소, CNG/TPM 연동 | 관련 서비스 상태, CAPI2 로그 |
| 문제 발생 시점이 “암호 재설정/프로필 재생성/도메인 연결 불량”과 일치함 | 갑자기 기존 데이터가 전부 무효화됨 | 계정 암호-마스터키 결합 구조 | 암호 변경 방식(변경/재설정)과 도메인 연결 상태 |
주의 : DPAPI 문제는 “한 번 초기화하면 끝”이 아니라, 초기화 순간 기존 암호문(이전 비밀값)을 영구적으로 잃을 수 있는 유형이다. 따라서 어떤 파일·폴더도 삭제하기 전에 반드시 백업을 선행해야 한다.
3. DPAPI 관련 핵심 폴더와 백업 대상
DPAPI 마스터키와 자격 증명 데이터는 사용자 프로필 하위에 분산되어 있다. Windows 빌드/정책/기능 구성에 따라 경로가 약간 다를 수 있으므로, 아래 목록은 “존재하는 것은 모두 백업”한다는 기준으로 접근하는 것이 안전하다.
| 구분 | 대표 경로 | 설명 | 복구 시 중요도 |
|---|---|---|---|
| 마스터키(사용자) | %APPDATA%\Microsoft\Protect\<SID>\ 또는 %APPDATA%\Microsoft\Windows\Protect\<SID>\ | DPAPI 마스터키 파일이 SID 폴더 아래에 GUID/식별자 형태로 저장되다. | 최상 |
| 자격 증명(로밍/로컬) | %APPDATA%\Microsoft\Credentials\ / %LOCALAPPDATA%\Microsoft\Credentials\ | 저장된 자격 증명(응용 프로그램이 등록한 비밀값 포함)이 저장되다. | 상 |
| Vault | %LOCALAPPDATA%\Microsoft\Vault\ | Windows Vault 데이터가 저장되다. | 상 |
| 암호 이력(환경에 따라 존재) | %APPDATA%\Microsoft\Protect\<SID>\CREDHIST 등 | 암호 변경(사용자 주도 변경) 시 이전 암호 기반 복구를 돕는 요소가 존재할 수 있다. | 중 |
| 프로필 레지스트리 | HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID> | 프로필 재생성/경로 꼬임 여부를 판단하는 기준이 되다. | 중 |
3.1 백업 명령 예시(삭제 전에 반드시 수행)
아래 예시는 “현재 로그인 사용자”의 DPAPI 관련 폴더를 안전하게 백업하는 방식이다. 경로는 환경에 맞게 변경하여 사용해야 한다.
REM 관리자 권한 CMD 또는 PowerShell에서 실행하는 것을 권장하다. REM 백업 위치 예: D:\DPAPI_Backup\%USERNAME%_YYYYMMDD
set BK=D:\DPAPI_Backup%USERNAME%_20251224
mkdir "%BK%" 2>nul
mkdir "%BK%\AppData_Roaming" 2>nul
mkdir "%BK%\AppData_Local" 2>nul
REM Roaming 백업
robocopy "%APPDATA%\Microsoft" "%BK%\AppData_Roaming\Microsoft" Protect Credentials /E /COPYALL /R:1 /W:1
REM Local 백업
robocopy "%LOCALAPPDATA%\Microsoft" "%BK%\AppData_Local\Microsoft" Credentials Vault /E /COPYALL /R:1 /W:1주의 : robocopy는 권한/소유권을 포함해 복사할 수 있으므로 /COPYALL 사용 시 백업 위치 접근 권한을 통제해야 한다. 백업 폴더를 공유 드라이브에 무심코 올리면 자격 증명 유출 위험이 커지다.
4. 원인 유형을 먼저 분류해야 복구가 성공한다
DPAPI 복호화 실패의 대표 원인은 다음 네 가지 축으로 분류하는 것이 실무적으로 효율적이다.
| 원인 유형 | 특징 | 복구 가능성 | 핵심 포인트 |
|---|---|---|---|
| 프로필 손상/프로필 경로 꼬임 | 업데이트/강제 종료/로밍 프로필 장애 후 발생하는 경향이 있다. | 중~상 | 동일 SID 유지 상태에서 Protect/자격 증명 파일이 정상인지를 확인해야 하다. |
| 로컬 계정 암호 “재설정” | 관리자가 강제로 바꾼 경우가 많다. | 낮음 | 도메인 복구 경로가 없으면 기존 암호문 복호화는 사실상 불가능한 경우가 많다. |
| 도메인 계정 암호 재설정/도메인 복구 실패 | 암호 재설정 후, DC 접속 또는 복구 프로토콜 동작이 핵심이다. | 중~상 | 도메인 연결, RWDC 가용성, 네트워크/VPN 상태가 관건이다. |
| 서비스/권한/키 격리 구성 문제 | CryptSvc, KeyIso, VaultSvc 상태 또는 폴더 ACL 이상이 동반되다. | 중 | 서비스 정상화 후에도 파일 손상이라면 파일 복구로 넘어가야 하다. |
5. 진단 절차: 서비스 상태 확인과 이벤트 로그 확보
5.1 필수 서비스 상태 점검
DPAPI 자체는 API이지만, 실제 운영에서는 다음 서비스가 복합적으로 얽혀 문제가 확대되는 경우가 있다. 아래 서비스는 최소 “실행 중” 상태인지 확인해야 한다.
REM 관리자 권한 CMD
sc query CryptSvc
sc query KeyIso
sc query VaultSvcPowerShell을 사용하는 경우에는 다음 방식이 간단하다.
Get-Service CryptSvc, KeyIso, VaultSvc | Format-Table -AutoSize Name, Status, StartType5.2 Crypto-DPAPI 로그 채널 확인과 Debug 채널 활성화
이벤트 뷰어에서 “Applications and Services Logs > Microsoft > Windows > Crypto-DPAPI” 하위 채널을 확인해야 한다. 환경에 따라 Operational 채널만으로는 원인 파악이 제한될 수 있으므로, 필요 시 Debug 채널을 활성화하여 호출 프로세스 식별 수준까지 확보하는 방식이 있다.
# 관리자 권한 PowerShell # Crypto-DPAPI Debug 채널 활성화 예시 $log = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration "Microsoft-Windows-Crypto-DPAPI/Debug" $log.IsEnabled = $true $log.SaveChanges()필요한 로그를 파일로 내보내면 재부팅/재로그온 후 비교가 쉬워진다.
REM 관리자 권한 CMD wevtutil epl "Microsoft-Windows-Crypto-DPAPI/Operational" "D:\DPAPI_Backup\Crypto-DPAPI_Operational.evtx" wevtutil epl "Microsoft-Windows-Crypto-DPAPI/Debug" "D:\DPAPI_Backup\Crypto-DPAPI_Debug.evtx"주의 : Debug 채널은 기본적으로 비활성인 경우가 많고, 이벤트 양이 늘어날 수 있다. 진단이 끝나면 비활성화하여 운영 부담을 줄이는 것이 바람직하다.
5.3 보안 감사 이벤트(선택)로 복구 시도 여부 확인
운영 정책상 허용된다면 “Audit DPAPI Activity”를 통해 DPAPI 마스터키 복구 시도 이벤트를 보안 로그에서 확인할 수 있다. 이 방법은 “복구 시도가 발생했는지”를 판단하는 데 유용하지만, 호출 프로세스 식별은 별도 로그와 함께 해석해야 한다.
6. 복구 절차(중요): ‘복구 가능한 시나리오’부터 처리한다
6.1 1단계: DC/VPN/네트워크 정상화(도메인 계정인 경우 최우선)
도메인 계정 환경에서는 사용자 마스터키 복구가 도메인 컨트롤러와의 통신에 의해 좌우되는 경우가 있다. 암호 재설정 이후 캐시 로그온만 반복하고 DC에 붙지 못하면 복구가 진행되지 못할 수 있다. 따라서 다음을 먼저 점검해야 한다.
첫째, 사내망 또는 VPN에 정상 접속되어야 한다. 둘째, 도메인 컨트롤러 검색이 가능해야 한다. 셋째, 시간 동기화가 크게 어긋나면 인증 과정이 실패할 수 있으므로 시간도 확인해야 한다.
REM 도메인 컨트롤러 확인 예시 nltest /dsgetdc:YOURDOMAIN도메인 환경에서 특정 상황에서는 RWDC(쓰기 가능한 도메인 컨트롤러) 가용성 문제가 DPAPI 마스터키 백업/복구 흐름에 영향을 줄 수 있다. 이 경우 네트워크 경로, 사이트/서브넷 구성, AD 서비스 상태를 점검하여 “RWDC에 실제로 닿는지”부터 확인하는 것이 실무적으로 빠르다.
6.2 2단계: 프로필 손상 여부 판정(가장 흔한 운영 장애)
프로필 손상 또는 프로필 경로 꼬임은 “파일이 존재하지만 읽을 수 없는” 상황을 만들 수 있다. 이 경우 무작정 Protect 폴더를 지우면 복구 기회를 잃는다. 다음 순서로 진행해야 한다.
첫째, 동일 사용자로 새 로컬/도메인 로그온이 가능한지 확인한다. 둘째, 동일 PC에서 다른 사용자 계정은 정상인지 확인한다. 셋째, 동일 사용자로 “새 프로필 생성”을 테스트하되, 기존 프로필을 삭제하지 말고 분리하여 보존한다.
6.3 3단계: 프로필 재생성(삭제가 아니라 ‘분리’) 후 복구 시도
아래 절차는 운영에서 자주 쓰이는 “프로필 재생성 후 파일 복원” 방식이다. 핵심은 기존 프로필을 삭제하지 않고, SID 기반 매핑을 깨끗하게 재구성한 뒤 백업본을 되돌려 복호화 가능 여부를 확인하는 것이다.
| 순서 | 작업 | 의도 | 실무 팁 |
|---|---|---|---|
| 1 | 해당 사용자 로그오프 | 파일 잠금 해제 | 가능하면 재부팅 후 관리자 계정으로 진행하다. |
| 2 | C:\Users\사용자 폴더를 .old로 변경 | 기존 프로필 보존 | 디스크 여유 공간을 확인해야 하다. |
| 3 | ProfileList에서 해당 SID의 ProfileImagePath 정리 | 새 프로필 재생성 유도 | 레지스트리 변경 전 내보내기 백업을 권장하다. |
| 4 | 사용자 재로그온으로 새 프로필 생성 | 기본 구조 재구성 | 로그온 직후 바로 로그오프하여 최소 변경 상태를 유지하다. |
| 5 | 백업한 Protect/Credentials/Vault를 새 프로필에 복원 | 기존 비밀값 복구 시도 | 권한/소유권이 깨지지 않게 복원해야 하다. |
주의 : “새 프로필 생성”은 DPAPI를 새로 만드는 효과가 있으므로, 기존 비밀값을 살리려면 반드시 기존 Protect 및 관련 데이터가 같은 사용자 SID 문맥에서 정상적으로 다시 읽혀야 하다. 파일을 일부만 복사하면 오히려 상태가 더 꼬일 수 있다.
6.4 4단계: 로컬 계정 암호 재설정이 원인인 경우의 현실적인 처리
로컬 계정에서 관리자가 강제로 암호를 재설정하면, 기존 DPAPI 마스터키를 여는 데 필요한 연계 정보가 단절되는 경우가 많다. 이 경우 “이전 암호문을 복호화하여 되살리는 복구”는 제한적이며, 실무적으로는 다음 두 갈래로 판단해야 한다.
첫째, 사용자가 이전 암호를 정확히 알고 있고, 이전 암호로 되돌려 로그인 가능한 상태를 만들 수 있다면(동일 계정에 이전 암호를 다시 설정하여) DPAPI 복호화가 정상화될 여지가 있다. 둘째, 이전 암호를 알 수 없고 도메인 복구 경로도 없다면 기존 저장 비밀값은 복구 불가로 결론 내리고 “재초기화 후 재등록” 절차로 전환해야 한다.
이전 암호를 알고 있어 “암호 되돌림”을 시도하는 경우의 예시는 다음과 같다.
REM 관리자 권한 CMD REM 로컬 계정 암호를 '이전 암호'로 되돌린 뒤 해당 계정으로 로그인하여 복호화 가능 여부를 확인하다. net user USERNAME "OLD_PASSWORD"주의 : 조직 정책상 암호를 임의 문자열로 되돌리는 행위가 금지된 환경이 존재하다. 또한 이 방식은 보안상 민감하므로 최소 시간으로 수행하고 즉시 “사용자 주도 암호 변경(기존 암호 입력 방식)”으로 정상 변경 흐름을 복원해야 하다.
6.5 5단계: 권한/소유권/ACL 이상 복구(파일 손상과 구분 필요)
DPAPI 관련 폴더는 권한이 매우 중요하다. 운영 중 권한 템플릿 적용, 무리한 Take Ownership, 보안 제품의 격리 조치로 인해 ACL이 변형되면 “파일은 있으나 접근이 실패”하는 문제가 발생할 수 있다. 이 경우에는 삭제가 아니라 “권한을 정상화”한 뒤 재로그온하여 재시도하는 흐름이 맞다.
아래는 “현재 사용자 프로필 하위 Protect 폴더”의 상속을 되살리는 보수적 예시이다. 환경별 보안 정책이 다르므로 적용 전 백업이 선행되어야 한다.
REM 사용자 컨텍스트에서 실행하는 것을 권장하다. icacls "%APPDATA%\Microsoft\Protect" /inheritance:e권한 문제가 의심될 때는 다음 표처럼 “기대 소유자/권한” 관점으로 점검하는 것이 실무적으로 빠르다.
| 대상 | 일반적인 소유/접근 주체 | 이상 징후 | 권장 대응 |
|---|---|---|---|
| %APPDATA%\Microsoft\Protect\... | 해당 사용자 계정 | 관리자/임의 계정으로 소유권이 넘어가 있음 | 삭제하지 말고 백업 후 권한/상속을 점검하다. |
| %LOCALAPPDATA%\Microsoft\Vault\... | 해당 사용자 및 시스템 구성요소 | 접근 거부, 파일 0바이트, 갑작스러운 대량 생성/삭제 | 백업 후 이벤트 로그와 시점 상관관계를 분석하다. |
7. 복구 불가로 결론 날 때의 ‘재초기화’ 표준 절차
기존 마스터키 또는 복구 경로로도 복호화가 불가능하다고 판단되면, 목표는 “깨진 상태를 정상 상태로 되돌려 운영을 재개”하는 것이다. 이때의 핵심은 “이전 저장 비밀값을 포기하되, 시스템을 깨끗하게 재등록”하는 것이다.
7.1 자격 증명 관리자 및 Vault 재등록
저장된 자격 증명은 복호화 실패 상태에서 계속 오류를 유발할 수 있으므로, 정책에 따라 정리 후 재등록해야 한다. 정리 전에는 반드시 3장의 백업을 확보해야 한다. 이후 필요한 계정(업무 시스템, 원격 접속, 네트워크 자원 등)은 수동으로 다시 저장하여 새로운 DPAPI 체계로 암호화되게 해야 한다.
7.2 브라우저(Chromium 계열) 저장 데이터 재생성
브라우저가 DPAPI 기반으로 로컬 비밀값을 관리하는 환경에서는, DPAPI 복호화 실패가 “동기화 일시중지, 계속 로그아웃, 저장 암호가 비어 보임”으로 나타날 수 있다. 이 경우 기존 로컬 저장 암호를 되살리는 것이 아니라, 계정 동기화 또는 기업용 정책에 따라 저장소를 재구성해야 한다.
주의 : 브라우저 프로필 폴더를 무작정 삭제하면 북마크, 확장 구성, 로컬 캐시까지 함께 손실될 수 있다. 반드시 “업무에 필요한 데이터 목록”을 정리한 뒤, 정책에 맞는 초기화 범위로 진행해야 한다.
8. 현장 체크리스트(실무용)
다음 체크리스트는 장애 접수 후 30분 내에 “복구 가능성”을 빠르게 판정하기 위한 항목이다.
| 체크 항목 | 예/아니오 | 조치 |
|---|---|---|
| 문제 발생 직전에 암호가 ‘재설정’되었는가 | 로컬 계정이면 복구 가능성이 낮으므로 백업 후 재초기화 플랜을 준비하다. | |
| 도메인 계정이며 현재 DC/VPN 연결이 정상인가 | 네트워크 정상화 후 재로그온 및 로그 확인을 우선 수행하다. | |
| CryptSvc/KeyIso/VaultSvc가 실행 중인가 | 서비스 정상화 후 동일 증상 지속 여부를 확인하다. | |
| Protect/Credentials/Vault를 삭제한 이력이 있는가 | 즉시 추가 삭제를 중단하고, 남아 있는 데이터와 백업본을 확보하다. | |
| 새 프로필 생성 후에도 동일 증상이 재현되는가 | 프로필 손상보다 계정/암호/복구 경로 문제 가능성이 커지다. |
FAQ
DPAPI 마스터키 파일만 복구하면 저장된 암호가 전부 살아나는가?
마스터키 파일만으로 항상 복구되는 것은 아니다. 마스터키는 계정 암호(또는 도메인 복구 키)와 결합되어 열리는 구조이므로, 파일이 정상이어도 암호 재설정 방식이나 도메인 복구 경로가 끊기면 복호화가 실패할 수 있다. 따라서 파일 복원과 함께 계정 인증 조건을 함께 정상화해야 한다.
로컬 계정에서 암호를 잊어버려 재설정했는데, 예전 저장 암호를 복구할 수 있는가?
도메인 복구 경로가 없는 로컬 계정에서 강제 재설정이 이루어진 경우, 이전에 DPAPI로 암호화된 비밀값은 복구가 어려운 경우가 많다. 사용자가 이전 암호를 정확히 알고 있어 이전 암호로 로그인 가능한 상태를 재현할 수 있다면 정상화 여지가 있으나, 그렇지 않다면 재초기화 후 재등록을 전제로 운영 복구를 진행해야 한다.
도메인 계정인데 사내망 밖에서 캐시 로그인만 가능한 상태이다. 이때 복구가 안 되는 이유는 무엇인가?
도메인 계정의 특정 복구 흐름은 도메인 컨트롤러와의 통신이 필요할 수 있다. 캐시 로그인만 반복하면 해당 복구가 수행되지 못해 마스터키 복호화가 실패 상태로 남을 수 있다. 따라서 VPN 접속 등으로 도메인 연결을 먼저 정상화한 뒤 재로그온 및 로그 확인을 진행해야 한다.
Debug 로그를 켰는데 이벤트가 너무 많이 쌓인다. 운영에 문제는 없는가?
Debug 채널은 진단 목적의 상세 로그가 기록될 수 있어 이벤트 양이 증가할 수 있다. 장애 원인 파악이 끝나면 Debug 채널을 비활성화하고, 필요한 기간의 로그만 보관하는 방식이 운영상 적절하다.
복구를 시도할 때 가장 흔한 실수는 무엇인가?
가장 흔한 실수는 Protect/Credentials/Vault 폴더를 먼저 삭제하는 것이다. 삭제는 “복구 가능성”을 즉시 낮추는 행위가 될 수 있다. 항상 (1) 백업, (2) 서비스/로그 기반 진단, (3) 프로필 분리 재생성, (4) 복원 시도, (5) 재초기화 순서로 진행해야 한다.