- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Windows DPAPI(Data Protection API) 마스터키 손상 또는 불일치로 인해 저장된 암호·자격 증명·인증서 등이 “복호화 실패”로 깨질 때, 원인을 신속히 분류하고 데이터 손실을 최소화하는 복구 절차를 현장에서 바로 적용할 수 있도록 정리하는 것이다.
1. DPAPI 마스터키 손상 문제를 먼저 정확히 정의하다
DPAPI는 Windows가 “사용자/컴퓨터 컨텍스트”로 민감정보를 암호화·복호화하는 기본 구성요소이다. 사용자 프로필 내 마스터키를 기반으로 Credential Manager 저장 암호, 브라우저 저장 비밀번호(Windows 계정 기반 보호), 일부 VPN/클라이언트 인증정보, Wi-Fi 프로필 키(환경에 따라), EFS와 일부 인증서 개인키 접근 등 다양한 기능이 영향을 받는다.
1-1. 대표 증상
| 증상 | 사용자 체감 | 자주 보이는 범위 | 우선 의심 포인트 |
|---|---|---|---|
| 저장된 암호 자동 입력 실패 | RDP/파일서버/웹사이트 로그인 저장이 풀리거나 반복 재입력 | 자격 증명 관리자, 브라우저, 앱 | DPAPI 사용자 마스터키 불일치 |
| 복호화 오류 팝업/로그 | “암호를 해독할 수 없음”, “Key not valid for use in specified state” 등 | 앱 이벤트 로그, 보안 로그, 앱 자체 로그 | 마스터키 손상, 암호 변경 이력 문제 |
| 암호 변경 이후 기존 데이터 접근 불가 | 비밀번호 변경 후 이전에 저장한 항목이 전부 실패 | 로컬 계정/도메인 계정 모두 | 정상 변경인지(Windows UI) vs 강제 초기화/리셋 |
| 프로필/디스크 복원 이후 깨짐 | 프로필만 복사했는데 저장 암호가 깨짐 | 프로필 마이그레이션/백업 복원 | Protect 폴더/시스템 보호키/자격 증명 파일 불일치 |
주의 : DPAPI 문제는 “마스터키를 새로 만들면 해결”처럼 보일 수 있으나, 새 키 생성은 기존에 암호화된 데이터의 영구 손실로 이어질 수 있다. 원인 분류와 백업 확보가 먼저이다.
2. 가장 중요한 분기점: 로컬 계정/도메인 계정/암호 변경 방식
DPAPI 복구 가능성은 “어떤 계정 유형인지”와 “암호가 어떻게 바뀌었는지”에 의해 거의 결정된다. 특히 암호 변경이 정상 흐름(현재 암호를 알고 변경)인지, 강제 재설정(현재 암호를 모른 채 Reset)인지가 핵심이다.
2-1. 복구 가능성 빠른 판정표
| 상황 | 예시 | 복구 가능성 | 우선 조치 |
|---|---|---|---|
| 현재 암호를 알고 Windows에서 “변경(Change)” | Ctrl+Alt+Del로 암호 변경 | 높음 | CREDHIST 체인이 유지되는지 확인하다 |
| 현재 암호를 모른 채 “재설정(Reset)” | 관리자가 AD에서 Reset, 로컬 관리자에서 강제 변경 | 낮음(도메인은 예외 가능) | 도메인 백업키/PRD/이전 암호 확보 여부 확인하다 |
| 프로필만 백업/복원 | Users 폴더만 복사, 이미지 복원 일부 | 중간~낮음 | Protect 폴더, 자격 증명 파일, 시스템 상태 일치 여부 점검하다 |
| 도메인 사용자, DC가 정상, 정책 정상 | 도메인 환경에서 기존 데이터 복구 필요 | 중간~높음 | 조직의 복구 절차(도메인 DPAPI 백업키)로 복구하다 |
3. 작업 전 필수: 증거 보존과 안전 백업을 먼저 수행하다
DPAPI 관련 파일을 건드리기 전에, 최소한 사용자 프로필 내 DPAPI 관련 폴더를 복사 백업해야 한다. 문제가 악화되면 되돌릴 방법이 급격히 줄어든다.
3-1. 반드시 백업할 경로
| 구분 | 경로 | 설명 |
|---|---|---|
| 사용자 마스터키(핵심) | %APPDATA%\Microsoft\Protect\<사용자SID>\ | 마스터키 GUID 파일들이 존재하다 |
| CREDHIST(암호 변경 이력) | %APPDATA%\Microsoft\Protect\CREDHIST | 이전 암호 체인 기반 복구에 사용되다 |
| 자격 증명 파일 | %APPDATA%\Microsoft\Credentials\ | 저장된 자격 증명 데이터가 위치하다 |
| 로컬 자격 증명 보조 | %LOCALAPPDATA%\Microsoft\Credentials\ | 앱에 따라 추가 저장소가 사용되다 |
3-2. 백업 명령 예시(관리자 PowerShell)
$stamp = Get-Date -Format "yyyyMMdd_HHmmss" $src1 = Join-Path $env:APPDATA "Microsoft\Protect" $src2 = Join-Path $env:APPDATA "Microsoft\Credentials" $src3 = Join-Path $env:LOCALAPPDATA "Microsoft\Credentials" $dst = "D:\DPAPI_Backup_$stamp"
New-Item -ItemType Directory -Path $dst | Out-Null
Copy-Item -Path $src1 -Destination (Join-Path $dst "Protect") -Recurse -Force -ErrorAction SilentlyContinue
Copy-Item -Path $src2 -Destination (Join-Path $dst "Roaming_Credentials") -Recurse -Force -ErrorAction SilentlyContinue
Copy-Item -Path $src3 -Destination (Join-Path $dst "Local_Credentials") -Recurse -Force -ErrorAction SilentlyContinue
Write-Host "Backup done:" $dst주의 : 백업 경로는 가급적 외장/별도 디스크를 사용해야 한다. 동일 디스크의 복원 지점/이미지 작업은 실수로 덮어쓰기를 유발할 수 있다.
4. 원인 진단 1단계: 이벤트 로그로 “무슨 키가 문제인지” 좁히다
DPAPI 오류는 증상만 보면 애매하지만, 이벤트 로그에는 힌트가 남는 경우가 많다. 특히 사용자 로그인 직후, 자격 증명 접근 시점, 암호 변경 직후의 로그를 우선 확인해야 한다.
4-1. 확인 위치
| 로그 | 경로 | 포인트 |
|---|---|---|
| 이벤트 뷰어(일반) | Windows Logs → Application / System | Cryptographic, DPAPI, CAPI2, 앱 오류를 확인하다 |
| 운영 로그(상세) | Applications and Services Logs | 앱별로 DPAPI 호출 오류가 남을 수 있다 |
4-2. 로그를 PowerShell로 필터링하다
# 최근 3일간 "DPAPI" 키워드가 포함된 이벤트를 Application/System에서 찾다 $since = (Get-Date).AddDays(-3)
Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=$since} |
Where-Object { $_.Message -match 'DPAPI|Data Protection|Cryptographic|CAPI2' } |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$since} |
Where-Object { $_.Message -match 'DPAPI|Data Protection|Cryptographic|CAPI2' } |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List5. 복구 전략 A: “정상 암호 변경”이라면 CREDHIST 연동 문제를 먼저 해결하다
사용자가 기존 암호를 알고 정상적으로 변경했다면, Windows는 CREDHIST를 통해 과거 암호로도 마스터키를 단계적으로 풀 수 있게 설계되어 있다. 따라서 이 경우는 “파일 손상/권한 꼬임/프로필 일부 누락”이 흔한 원인이다.
5-1. Protect 폴더 권한과 소유권이 깨진 경우를 복구하다
프로필 마이그레이션, 권한 도구 사용, 보안 소프트웨어 격리 등으로 Protect 폴더 ACL이 깨지면 접근 실패가 발생할 수 있다. 이때는 소유권/권한을 정상화한 뒤 재로그인을 시도해야 한다.
REM 관리자 CMD에서 실행하다 set P=%APPDATA%\Microsoft\Protect takeown /f "%P%" /r /d y icacls "%P%" /inheritance:e /t icacls "%P%" /grant "%USERNAME%:(OI)(CI)F" /t주의 : 도메인 환경에서는 조직의 표준 권한 정책이 있을 수 있다. 무조건 Full Control을 남발하면 보안 정책 위반이 될 수 있으므로, 테스트 계정 또는 최소 범위에서 적용해야 한다.
5-2. “프로필 일부만 복원”이 의심될 때 점검하다
Protect 폴더만 가져오고 Credentials 폴더를 누락했거나, 반대로 Credentials만 가져오고 Protect를 누락하면 복호화가 실패한다. 또한 로컬/로밍 경로가 섞이면 앱별로 불일치가 발생한다.
| 점검 항목 | 정상 기준 | 이상 시 조치 |
|---|---|---|
| Protect\<SID> 폴더 존재 | SID 하위에 GUID 파일 다수 존재하다 | 백업본에서 누락분을 동일 사용자에게 복원하다 |
| CREDHIST 파일 존재 | %APPDATA%\Microsoft\Protect\CREDHIST 존재하다 | 암호 변경 이력이 있다면 누락 여부를 우선 확인하다 |
| Credentials 폴더 2곳 | Roaming/Local 모두 존재할 수 있다 | 둘 중 하나만 복원했다면 전체를 맞춰 복원하다 |
6. 복구 전략 B: 도메인 사용자에서 “암호 재설정(Reset)”이 있었다면 조직 절차로 복구하다
도메인 사용자가 암호를 잊었고 관리자가 AD에서 Reset을 수행하면, 사용자는 새 암호로 로그인 가능해도 DPAPI는 이전 마스터키를 현재 암호로 풀지 못하는 상황이 발생할 수 있다. 이때 도메인 환경은 “도메인 DPAPI 백업키”를 통해 복구가 가능하도록 설계되어 있다. 다만 이 백업키는 보안상 매우 민감하여 도메인 관리자만 접근해야 하며, 조직 정책에 따라 처리해야 한다.
6-1. 현장 대응 절차(권장 흐름)
| 단계 | 목표 | 실행 주체 |
|---|---|---|
| 1 | 사용자 계정이 “Change”로 변경되었는지 “Reset”인지 확인하다 | 헬프데스크/AD 관리자 |
| 2 | 사용자 프로필 DPAPI 자료(Protect/CREDHIST/Credentials) 백업을 확보하다 | 현장 엔지니어 |
| 3 | 조직 표준에 따라 도메인 DPAPI 복구를 수행하다 | 도메인 관리자(승인된 절차) |
| 4 | 복구 성공 후 사용자가 새로 저장하도록 정리하다 | 사용자/현장 엔지니어 |
주의 : 도메인 DPAPI 백업키는 사실상 도메인 사용자 DPAPI 보호 데이터의 “범용 복구 열쇠” 역할을 한다. 키 추출·보관·사용은 내부통제와 감사가 전제되어야 한다.
7. 복구 전략 C: 시스템/프로필 손상이라면 “되돌리기”가 가장 현실적이다
마스터키 파일 자체가 손상된 경우, 가장 성공률이 높은 방법은 “정상 시점의 시스템 상태 또는 사용자 프로필을 통째로 되돌리는 것”이다. 특히 로컬 계정 환경에서는 이전 암호를 모르면 복구가 거의 불가능해지므로, 복원 지점/이미지 백업이 사실상 유일한 수단이 되기 쉽다.
7-1. 시스템 복원 지점 또는 이미지 복원 시 유의점
DPAPI는 사용자 프로필 파일뿐 아니라 시스템 측의 보호 요소와 결합되는 경우가 있어, “부분 복구”보다 “일관된 시점 복구”가 유리하다. 단, 복원 이후에 추가 생성된 데이터는 손실될 수 있으므로 사전 백업이 필수이다.
| 복구 방식 | 장점 | 리스크 | 권장 상황 |
|---|---|---|---|
| 시스템 복원 | 빠르고 간단하다 | 최근 설치/설정이 되돌아가다 | 최근 업데이트/정책 변경 이후 발생 |
| 전체 이미지 복원 | 일관성 최고 수준이다 | 복원 범위가 커서 영향이 크다 | 업무PC 표준 이미지/백업 체계가 있을 때 |
| 프로필 단독 복원 | 영향 범위가 작다 | 불일치가 남아 실패할 수 있다 | 정상 백업본이 있고 변경 폭이 작을 때 |
8. “최후의 방법”: DPAPI를 초기화해 로그인 문제를 해소하되, 기존 암호는 포기하다
업무상 “이 PC에서 저장 암호가 전부 깨져도 된다”는 판단이 내려지면, 손상된 DPAPI 저장소를 초기화하여 오류 루프를 끊을 수 있다. 이 방법은 복구가 아니라 리셋이므로 기존 DPAPI 보호 데이터는 복호화 불가로 남을 수 있다.
8-1. 리셋 절차(데이터 손실 전제)
REM 1) 반드시 3장의 백업을 먼저 수행하다 REM 2) 사용자 로그오프 후, 관리자 권한으로 진행하다
set P=%APPDATA%\Microsoft\Protect
set C1=%APPDATA%\Microsoft\Credentials
set C2=%LOCALAPPDATA%\Microsoft\Credentials
REM 폴더를 삭제하지 말고 이름을 바꿔 롤백 가능성을 남기다
ren "%P%" "Protect.broken_%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%"
ren "%C1%" "Credentials.broken_%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%"
ren "%C2%" "CredentialsLocal.broken_%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%"
REM 이후 재로그인하면 새 DPAPI 저장소가 생성되다주의 : 이 리셋은 “새로 저장되는 항목은 정상”으로 만들 수 있으나, 과거에 저장된 자격 증명·암호·인증서·EFS 접근은 영구적으로 잃을 수 있다. 승인 절차와 영향 평가가 선행되어야 한다.
9. 실무 체크리스트: 현장에서 빠르게 재현·판단·조치하다
| 체크 | 확인 방법 | 판정 | 다음 액션 |
|---|---|---|---|
| 암호 변경 방식 | 사용자 진술 + AD 기록 + 헬프데스크 티켓 | Change/Reset 구분 | Reset이면 도메인 복구 절차 우선이다 |
| DPAPI 관련 폴더 백업 | Protect/CREDHIST/Credentials 백업 여부 | 백업 완료/미완 | 미완이면 어떤 조치도 시작하지 말아야 한다 |
| 권한 꼬임 여부 | Protect 폴더 접근, ACL 확인 | 정상/이상 | 이상이면 권한 복구 후 재부팅·재로그인하다 |
| 프로필 불완전 복원 여부 | 백업/마이그레이션 이력 점검 | 의심/비의심 | 의심이면 동일 시점의 전체 복원으로 정합성을 맞추다 |
| 업무 영향도 | EFS/인증서/저장 암호 필요성 | 높음/낮음 | 높으면 리셋 금지, 복구 중심으로 진행하다 |
10. 재발 방지: DPAPI 손상·불일치가 반복되는 환경을 줄이다
10-1. 운영 권장사항
첫째, 사용자 암호 변경은 반드시 “현재 암호를 알고 변경”하는 표준 절차로 유도해야 한다. 둘째, 프로필 마이그레이션은 사용자 폴더 복사만으로 끝내지 말고, 표준 마이그레이션 도구 또는 조직 표준 방식으로 정합성을 유지해야 한다. 셋째, 도메인 환경에서는 DPAPI 복구 절차를 문서화하고 승인된 관리자만 수행하도록 통제해야 한다. 넷째, 중요한 계정은 EFS/인증서/업무용 자격 증명에 대한 백업 정책을 별도로 설계해야 한다.
10-2. 백업 정책 예시
| 대상 | 권장 백업 | 주기 | 비고 |
|---|---|---|---|
| 업무용 PC | 시스템 이미지 + 사용자 프로필 표준 백업 | 주 1회 또는 변경 전 | 업데이트/대규모 정책 변경 전에는 필수이다 |
| 중요 계정 | 인증서/키 자료의 별도 백업 | 발급/갱신 시 | EFS 사용 시 특히 중요하다 |
| 도메인 | 복구 절차 문서 + 접근통제 + 감사로그 | 정기 점검 | 키 자료는 최고 수준으로 보호해야 한다 |
FAQ
DPAPI 마스터키 손상인지, 단순 앱 설정 문제인지 어떻게 빨리 구분하나?
여러 앱에서 동시에 “저장 암호가 풀림/복호화 실패”가 발생하면 DPAPI 가능성이 높다. 반대로 특정 앱 하나에서만 발생하면 앱 자체 저장소 손상일 수 있다. 가장 빠른 방법은 자격 증명 관리자에 저장된 항목이 여러 개에서 동시에 실패하는지 확인하고, Protect/CREDHIST/Credentials의 정합성을 점검하는 것이다.
암호를 바꾼 적이 없는데 갑자기 복호화가 실패하는 경우는 무엇이 흔한가?
프로필 복원/동기화 도구가 일부 폴더만 덮어쓴 경우, 보안 제품이 Protect 또는 Credentials 폴더를 격리·복구하며 권한이 깨진 경우, 디스크 오류로 파일이 손상된 경우가 흔하다. 이때는 우선 백업을 확보하고 권한을 정상화한 뒤, 가능하면 정상 시점으로 되돌리는 것이 현실적이다.
Protect 폴더를 지우거나 이름 변경하면 바로 정상으로 돌아오나?
재로그인 후 신규 DPAPI 저장소가 생성되면서 “앞으로 저장하는 항목”은 정상 동작할 수 있다. 그러나 기존에 DPAPI로 암호화된 데이터는 과거 키가 없으면 복호화되지 않으므로 데이터 손실이 발생할 수 있다. 업무 영향도 평가 없이 시행하면 사고가 커질 수 있다.
도메인에서 비밀번호 Reset을 했더니 이전 저장 암호가 전부 깨진다. 해결책이 있나?
도메인 환경에서는 설계상 복구 가능성이 남아 있을 수 있으나, 이는 조직의 승인된 절차와 권한을 가진 관리자가 수행해야 한다. 현장에서는 사용자 DPAPI 관련 자료를 백업하고, Reset 여부를 확정한 뒤, 내부 표준 절차로 복구를 요청하는 흐름이 안전하다.
EFS로 암호화된 파일도 DPAPI 리셋으로 풀 수 있나?
일반적으로 EFS는 사용자 인증서/개인키 접근과 연관되며, 키 접근이 깨지면 복호화가 불가능해질 수 있다. DPAPI 리셋은 문제를 해결하는 것이 아니라 새로운 저장소로 갈아타는 성격이므로, EFS가 관련된 환경에서는 리셋을 최후의 선택으로 두고 복원·정상 시점 복구를 우선해야 한다.