BitLocker 실무 가이드 ── 복구 키 관리부터 시작하는 드라이브 암호화

「PC를 초기화했더니 다음 부팅에서 처음 보는 파란 화면이 나오고 48자리 키를 요구받았다」「BIOS만 업데이트했는데 복구 키 입력 화면이 떴다. 그런 키는 맡긴 적이 없다」「새 PC 설정을 보니 ‘디바이스 암호화’가 멋대로 켜져 있다. 업무 앱이 느려질 것 같으니 꺼도 되는가」── 최근 1년 남짓, 고객에게서 이런 상담이 눈에 띄게 늘었습니다.

배경은 분명합니다. Windows 11 버전 24H2 이후, 클린 설치한 PC에서는 ‘디바이스 암호화’(BitLocker 자동 활성화)가 기본으로 동작하기 때문입니다. 하드웨어 요구 사항도 완화되어 대상 PC가 크게 늘었습니다. 즉 BitLocker는 더 이상 ‘대기업이 의식하고 도입하는 것’이 아니라 ‘중소기업 PC에도 말없이 들어오는 것’으로 바뀌었습니다. 이때 유일한 생명줄이 복구 키이며, 누구의 관리에도 없는 채로 암호화만 진행되는 상태가 가장 위험합니다.

이 글에서는 중소기업의 정보시스템 담당자·경영자와, 업무 앱이나 장치 PC를 맡은 개발자를 대상으로 BitLocker를 ‘끄는 것’이 아니라 ‘다루는 것’으로 정리합니다. 에디션별 차이, TPM과 키의 관계라는 최소한의 원리, 복구 키 저장 위치 판단표, 조직에서의 활성화와 운영, 사고 대응, 그리고 폐기와의 관계까지 2026년 8월 시점의 Microsoft Learn 등 1차 정보를 바탕으로 설명합니다.

1. 먼저 결론

• BitLocker는 드라이브 전체를 암호화하는 Windows 기능으로, 분실·도난·부적절한 폐기로 인한 데이터 유출을 막습니다. 디스크를 뽑아 다른 PC에 연결하는 공격에 대해서도, 암호화되어 있으면 데이터를 읽을 수 없습니다.¹
• 전체 기능 BitLocker를 켤 수 있는 것은 Pro/Enterprise/Pro Education/Education입니다. 간소화된 ‘디바이스 암호화’는 Home을 포함한 모든 에디션에서 이용할 수 있습니다.¹
• Windows 11 24H2 이후 자동 디바이스 암호화 요구 사항이 완화되었습니다. HSTI/Modern Standby 요구 사항과 ‘허가되지 않은 DMA 인터페이스가 없을 것’ 요구 사항이 없어져, 클린 설치 후 OOBE(초기 설정) 완료 시 TPM+UEFI Secure Boot를 충족하는 많은 PC에서 암호화가 기본으로 초기화됩니다.²
• 암호화의 ‘시작’과 보호의 ‘활성화’는 별개입니다. Microsoft 계정·Entra ID·(복구 정책이 구성된) AD DS 중 하나로 복구 키 백업이 성공할 때까지 보호는 활성화(arm)되지 않습니다. 어디에도 백업되지 않는 로컬 계정만의 PC는 암호화되어 있어도 보호되지 않은 채로 남습니다.¹²
• 복구 키(48자리 복구 암호)의 저장 위치는 Entra ID / AD DS / Microsoft 계정 / 인쇄·파일의 네 가지입니다. Entra ID 조인이면 Entra ID로, AD 도메인 가입이면 AD DS로, 어느 쪽도 아니면 관리자의 Microsoft 계정으로 가는 것이 기본 흐름입니다.¹³
• 복구 키가 요구되는 것은 이상 상황만이 아닙니다. 펌웨어 업데이트, Secure Boot 설정 변경, TPM 지우기, 메인보드 교체, 드라이브 교체 등 부팅 환경 변화는 모두 트리거가 될 수 있습니다. 계획 작업 전에는 보호 일시 중지(suspend)가 정석입니다.³
• 기본 암호화 방식은 XTS-AES 128비트입니다. 방식을 나중에 바꾸려면 복호화→재암호화가 필요하므로, 처음에 정해 두는 편이 낫습니다. 새 드라이브라면 ‘사용한 공간만 암호화’로 첫 암호화 시간을 크게 줄일 수 있습니다.⁴⁵
• 복구 키를 물었는데 내놓지 못하는 PC의 데이터는 포기할 수밖에 없습니다. Microsoft 지원도 분실한 키는 꺼낼 수 없습니다. 그래서 이 글의 주제는 ‘암호화할지’가 아니라 ‘복구 키를 어디에 저장하고 누가 꺼낼 수 있게 할지’입니다.⁶

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 48건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. BitLocker와 디바이스 암호화의 차이 ── 에디션별로 무엇을 쓸 수 있는가

먼저 용어를 정리합니다. 「BitLocker」와 「디바이스 암호화」는 같은 암호화 기술의 두 얼굴입니다.

• BitLocker(전체 기능): 드라이브 단위로 켜고, TPM+PIN·startup key 등의 인증 방식, 그룹 정책/Intune 제어, manage-bde.exe나 PowerShell 관리까지 포함하는 관리자용 모습.
• 디바이스 암호화(Device Encryption): 요구 사항을 충족하는 PC에서 BitLocker를 자동으로 켜는 구조. 설정 앱에 「디바이스 암호화」 스위치가 나타나며, OS 드라이브와 내장 고정 드라이브만 암호화합니다(외장/USB 드라이브는 대상 밖).¹

에디션별 대응은 다음과 같습니다.¹

Windows 11 24H2에서 무엇이 바뀌었는가

자동 디바이스 암호화는 이전부터 있었지만, 대상은 「Modern Standby 또는 HSTI 준수」「외부에서 DMA 접근 가능한 포트가 없음」 같은 조건을 충족하는, 비교적 새로운 모바일 PC가 중심이었습니다. Windows 11 버전 24H2에서 이 두 요구 사항이 없어졌고, 남은 주요 조건은 「TPM(1.2 또는 2.0) 탑재」「UEFI Secure Boot가 켜져 있음」 등으로 좁혀졌습니다. OEM이 허가되지 않은 DMA 버스를 레지스트리(AllowedBuses)에 등록하는 운용도 필요 없어졌고, 이 키 자체는 24H2 이후 무시됩니다. 이 요구 사항 완화는 Windows IoT 에디션에는 적용되지 않습니다.²

그 결과, 클린 설치(초기화·재설정을 포함) 후 OOBE를 마치면 아주 흔한 데스크톱 PC에서도 암호화가 기본으로 초기화됩니다. 여기서 중요한 것이 「초기화」와 「보호 활성화」의 구분입니다.

• OOBE 완료 시점에는 드라이브가 clear key(보호 없는 임시 키)로 암호화된 상태입니다. Explorer에는 경고 아이콘이 표시됩니다.¹
• Microsoft 계정·Entra ID 계정으로 로그인하거나, 도메인 가입 PC라면 (복구 정책이 구성된) AD DS로의 백업이 성공하면 TPM protector가 만들어지고 clear key가 제거됩니다. 이때 처음으로 보호가 켜집니다.¹²
• 로컬 계정만 쓰는 PC는 암호화되어 있어도 보호되지 않은 채입니다.¹

이 흐름을 그림으로 그리면 다음과 같습니다.

flowchart TB
    A["클린 설치·초기화<br/>(Windows 11 24H2 이후)"] --> B{"TPM+UEFI Secure Boot 등의<br/>요구 사항을 충족하는가"}
    B -- "충족하지 않음" --> Z["암호화되지 않음"]
    B -- "충족함" --> C["OOBE 완료 시 암호화 초기화<br/>(clear key=보호 없는 임시 키)"]
    C --> D{"복구 키의<br/>백업 위치는?"}
    D -- "Microsoft 계정 / Entra ID /<br/>AD DS(복구 정책 구성됨)" --> E["복구 키 백업 성공"]
    E --> F["TPM protector 생성·clear key 제거<br/>=보호가 활성화(arm)됨"]
    D -- "로컬 계정만<br/>(백업 위치가 없음)" --> G["암호화된 채로 보호는 꺼짐<br/>(경고 아이콘이 표시됨)"]

「어느새 암호화되어 있었다」의 실체는 이 구조입니다. Windows 10 지원 종료 대응으로 Windows 11 PC 교체를 진행하는 조직은(Windows 10 지원 종료의 판단), 새 PC가 처음부터 이 상태로 온다는 전제로 복구 키 관리를 키팅 절차에 넣어야 합니다.

자기 기기의 대응 여부는 시스템 정보(msinfo32.exe)를 관리자로 열고 「디바이스 암호화 지원」 행에서 확인할 수 있습니다. 「전제 조건을 충족합니다」이면 대상입니다.¹

3. 최소한의 원리 ── TPM과 키의 관계

BitLocker의 키를 지키는 것은 TPM(Trusted Platform Module)입니다. TPM은 OS가 오프라인인 동안 디바이스가 변조되지 않았음을 확인하는 역할을 맡고, 부팅 시 검증을 통과했을 때만 암호화 키를 쓸 수 있게 합니다. 그래서 정상적인 Windows가 정상 부팅되면 사용자는 아무것도 입력하지 않고 쓰고, 디스크만 뽑힌 경우에는 읽을 수 없다는 양립이 됩니다.¹ TPM 자체의 구조(키를 밖으로 내지 않는 구조, PCR, 측정 부팅)는 「Windows의 TPM이란 무엇인가」에서 그림으로 설명합니다.

부팅마다 일어나는 일을 그림으로 그리면 이렇습니다.

flowchart TB
    ON["전원 켜기"] --> M["TPM이 부팅 환경을 측정<br/>(펌웨어·부팅 구성 등)"]
    M --> Q{"측정 결과가<br/>평소와 같은가"}
    Q -- "같음" --> UN["TPM이 암호화 키를 해제"]
    UN --> BOOT["일반 부팅<br/>(사용자는 아무것도 입력하지 않음)"]
    Q -- "다름" --> REC["복구 모드<br/>48자리 복구 키를 요구"]
    REC --> K1["복구 키를 입력하면 부팅"]
    REC --> K2["입력하지 못하면<br/>데이터를 꺼낼 수 없음"]

TPM에 더해, 부팅 때 PIN 입력이나 startup key(USB 메모리 안의 키 파일) 삽입을 필수로 하는 다요소 구성도 고를 수 있습니다. TPM이 없는 PC에서도 startup key 방식으로 OS 드라이브를 암호화할 수 있지만, 암호(password) 방식은 lockout 구조가 없어 무차별 대입에 약하므로 기본값에서 꺼져 있습니다.¹

복구 키가 요구되는 때는 언제인가

TPM은 「부팅 환경이 평소와 같은가」를 보기 때문에, 환경이 바뀌면 정당한 소유자도 복구 모드로 들어갑니다. Microsoft가 드는 대표적인 트리거는 다음과 같습니다.³

• BIOS/UEFI 펌웨어 업데이트 등, 부팅 초기 구성 요소의 업데이트
• TPM을 끄거나 비활성화하거나 지웠거나, TPM 자체 테스트 실패
• TPM 검증 프로필이 쓰는 PCR(플랫폼 구성 레지스터) 변경 ── Secure Boot 설정 변경이 여기에 해당합니다
• 메인보드 교체(새 TPM으로의 교체)
• BitLocker로 보호된 드라이브를 다른 PC로 옮긴 경우
• 도킹 스테이션 착탈, NTFS 파티션 테이블 변경, 부팅 관리자 변경, PXE 부팅
• PIN 오입력을 반복한 경우, (TPM 1.2 기종에서) 부팅 장치 순서를 바꾼 경우

즉 「BIOS 업데이트로 복구 키를 물었다」는 고장도 공격도 아니고, 설계대로의 동작입니다. 계획된 작업(펌웨어 업데이트나 하드웨어 교체) 전에는 보호를 일시 중지(suspend)하는 것이 정석이며, 일시 중지해도 드라이브는 암호화된 채로 남고, 작업 후에는 복구 키 입력 없이 재개할 수 있습니다. 기본값에서는 재부팅하면 보호가 자동으로 다시 켜집니다(재부팅 횟수 지정도 가능).³

# 펌웨어 업데이트 전에 일시 중지. 기본값에서는 재부팅 1회로 보호가 자동 재개되므로,
# 여러 번 재부팅하는 업데이트에서는 2회째 이후 재부팅이 복구 화면에서 멈출 수 있습니다.
# -RebootCount 0 으로 자동 재개를 끄고, 작업 완료 후 재개를 절차에 넣습니다
Suspend-BitLocker -MountPoint C: -RebootCount 0
# 작업 후에 반드시 재개(-RebootCount 0 에서는 자동 재개되지 않으므로 이 실행이 필수)
Resume-BitLocker -MountPoint C:

용어에 대해. 기술 문서에서는 48자리 숫자를 「복구 암호」, USB 메모리에 저장하는 .bek 파일을 「복구 키」로 구별하지만³, 일반 화면과 이 글에서는 널리 쓰이는 이름에 맞춰 48자리 숫자를 「복구 키」라고 부릅니다.

4. 복구 키 저장 위치 판단표 ── 네 가지를 어떻게 고르는가

이 글의 핵심입니다. 복구 키 저장 위치는 사실상 네 가지이며, PC의 로그인 방식으로 거의 자동으로 정해집니다. 먼저 판단표를 제시합니다.

하이브리드 조인(AD와 Entra ID 양쪽) 디바이스에서는 복구 암호가 양쪽에 백업됩니다.⁴

조직으로서 잡을 지점은 세 가지입니다.

1. 「조직의 저장 위치」를 하나로 정한다. Entra ID 조인이 진행 중이면 Entra ID, 온프레미스 AD이면 AD DS입니다. 담당자 개인 Microsoft 계정에 회사 PC 복구 키가 들어 있는 상태는 퇴사·이동 때 바로 무너집니다.
2. AD DS는 「자동으로 들어간다」고 믿지 않는다. AD DS 백업에는 정책 구성(후술)이 전제입니다. 또한 Active Directory는 복구 암호 이력을 계속 유지하며, 오래된 키는 컴퓨터 개체를 삭제하지 않는 한 자동으로는 사라지지 않습니다.³
3. 파일 저장을 고른다면 저장 위치를 엄격히. 복구 키 파일은 그 PC 자신이 아닌 곳(네트워크 폴더 등)에 저장해야 합니다.⁵ 복구 키를 가진 사람은 드라이브의 모든 데이터에 접근할 수 있으므로, 보호 대상 PC와 분리해 보관하고 접근을 통제하는 것이 필수입니다.³

지금 자기 PC가 어떤 상태인지 확인하기

관리자 권한 터미널에서 다음 중 하나를 실행합니다.⁵

# PowerShell: 암호화 상태와 protector 종류 확인
Get-BitLockerVolume C: | Format-List
# 복구 암호(48자리)와 그 ID 확인
(Get-BitLockerVolume -MountPoint C).KeyProtector

:: 명령 프롬프트: 상태 확인
manage-bde -status
:: protector(TPM, 복구 암호 등) 목록과 48자리 값
manage-bde -protectors -get C:

manage-bde -protectors -get C: 출력에 「숫자 암호」(Numerical Password)로 나오는 것이 48자리 복구 키이며, 함께 나오는 ID의 앞 8자리가 복구 화면에서 「어느 키인가」를 대조하는 단서가 됩니다.⁶

이미 암호화된 PC의 복구 암호를 나중에 Entra ID나 AD DS로 백업할 수도 있습니다.⁵

# 복구 암호 ID를 확인한 뒤에 실행
# Entra ID로 백업
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"
# AD DS로 백업
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"

:: manage-bde인 경우
manage-bde -protectors -aadbackup C: -id {ID}
manage-bde -protectors -adbackup C: -id {ID}

「모든 PC의 복구 키가 조직 저장 위치에 들어 있는가」의 전수 확인은, IPA의 중소기업 가이드라인에서 말하는 정보 보안의 기본 대책과 마찬가지로, 한 번 하고 끝이 아니라 대장 운용에 올리는 종류의 일입니다(「중소기업의 보안 대책, 무엇부터 시작하는가」).

5. 조직에서의 활성화와 운영 ── 정책·명령·암호화 방식

5.1. 정책으로 「복구 키 없는 활성화」를 막는다

BitLocker 설정은 그룹 정책(GPO)과 MDM(Intune 등의 BitLocker CSP) 양쪽에서 구성할 수 있습니다.⁴ 복구 키 관리 관점에서 가장 중요한 정책은 「BitLocker로 보호된 운영 체제 드라이브의 복구 방법을 선택」입니다. 여기서 다음을 구성합니다.⁴³

• AD DS에 복구 정보를 저장한다(복구 암호만, 또는 키 패키지도 포함)
• 「복구 정보가 AD DS에 저장될 때까지 BitLocker를 사용하지 않음」을 사용 ── 백업이 성공하지 않는 한 암호화를 시작하지 못하게 하는, 사고 방지의 핵심입니다. 이 구성에서는 복구 암호가 자동 생성됩니다

Entra ID 조인 디바이스를 Intune으로 관리하는 경우도 생각은 같고, 복구 키 백업을 필수로 한 뒤에 암호화를 켭니다. Entra ID 위의 복구 키는 Entra 관리 센터·Intune 관리 센터·PowerShell·Microsoft Graph에서 가져올 수 있고, 헬프데스크에 위임할 수도 있습니다.³

5.2. 암호화 방식 ── 기본값은 XTS-AES 128

암호화 방식을 구성하지 않으면 BitLocker는 기본값으로 XTS-AES 128비트를 씁니다. 디바이스 암호화의 기본값도 XTS-AES 128입니다. 정책 「드라이브 암호화 방법 및 암호 강도 선택」에서 XTS-AES 256 등으로 바꿀 수 있지만, Microsoft의 권장은 모든 드라이브를 XTS-AES로 하되 키 길이는 디바이스 성능(과 업계 규제 요건)에 따라 128/256을 고르는 것입니다.⁴¹

주의할 점은 이미 암호화된 드라이브의 방식은 나중에 바꿀 수 없다는 것입니다. 방식이나 키 길이를 바꾸려면 일단 복호화한 뒤 다시 암호화해야 합니다.¹ 「규제 요건으로 256비트가 필요」 같은 사정이 있으면 배포 첫 번에 정해 두십시오.

5.3. 사용한 공간만 암호화 vs 드라이브 전체

활성화 때 하나 더 고르는 것이 암호화 범위입니다. Microsoft의 구분 지침은 분명합니다.⁵

• 사용한 공간만 암호화: 데이터를 둔 적 없는 새 드라이브용. 첫 암호화가 빠릅니다
• 드라이브 전체 암호화: 이미 써 온 드라이브 ── 데이터를 둔 적이 있고, 삭제된 파일이 남아 있을 수 있는 드라이브용

이유는, 삭제된 파일 영역은 파일 시스템상 「빈 공간」으로 보이므로 「사용한 공간만」에서는 암호화되지 않고, 덮어쓰기될 때까지 포렌식 도구로 복원될 수 있기 때문입니다.⁵ 키팅 직후의 새 PC라면 「사용한 공간만」으로 충분하고, 오래 쓴 PC에 나중에 적용한다면 전체 암호화, 정도로 기억하면 실무에는 충분합니다.

5.4. PowerShell로 활성화하기

스크립트 배포의 기본형은 다음과 같습니다.⁵

# 1. 먼저 복구 암호(48자리) protector를 추가합니다(이 시점에서는 암호화가 시작되지 않음).
#    재시도 등으로 복구 암호가 여러 개 남아 있어도, 이번에 추가한 하나만
#    특정할 수 있도록 추가 전후 ID 차이로 고릅니다
$before = (Get-BitLockerVolume -MountPoint C).KeyProtector.KeyProtectorId
Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector | Out-Null
$rpId = (Get-BitLockerVolume -MountPoint C).KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $before } |
    Select-Object -ExpandProperty KeyProtectorId

# 2. 추가한 복구 암호를 조직 저장 위치로 백업합니다. 여기서 실패하면
#    암호화로 나아가면 안 되므로, -ErrorAction Stop 으로 오류 시 처리를 멈춥니다
#    (Entra 관리 센터/AD에서 키가 보이는 확인까지가 이 절차)
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop
# AD DS라면: Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop

# 3. 백업이 성공한 뒤에 암호화를 시작합니다. 3a와 3b는 배타 ──
#    어느 한쪽만 실행합니다(방식·범위도 여기서 정합니다)

# 3a. 표준 구성: TPM만(무인 재부팅이 필요한 단말은 이쪽)
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector

# 3b. TPM+PIN 구성(거치형 고보안 단말용). 3a 대신 실행합니다.
#     PIN은 단말마다 다른 값을 그 자리에서 입력합니다. 스크립트에 평문으로 넣으면
#     모든 단말이 같은 PIN이 되고, 스크립트 자체가 유출 지점이 됩니다
$Pin = Read-Host -AsSecureString -Prompt "이 단말의 PIN"
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $Pin -TPMandPinProtector

「복구 암호를 맡긴 뒤에 암호화를 시작한다」는 이 순서가 중요합니다. 반대로 Enable-BitLocker -TpmProtector부터 시작하면, 처리가 중간에 멈춘 시점에 복구 수단 사본이 없는 채로 TPM 보호만 걸린 PC가 남아, 다음 펌웨어 업데이트나 하드웨어 변경에서 데이터까지 잃을 수 있습니다. 위의 순서라면 중간에 멈춰도 암호화는 아직 시작되지 않았고, 다시 하면 됩니다. 조직 배포에서는 5.1의 「복구 정보가 저장될 때까지 BitLocker를 사용하지 않음」 정책을 먼저 켜 두면, 이 어중간한 상태는 정책 쪽으로도 막을 수 있습니다. 「백업 성공 확인보다 먼저 암호화를 시작하지 않는다」가 조직 배포의 철칙입니다.

6. 사고 대응 ── 「복구 키를 물었다」「찾을 수 없다」일 때

6.1. 복구 화면이 나오면 먼저 키 ID 앞 8자리

파란 복구 화면에는 복구 키 ID가 표시됩니다. 사본이 여러 개여도 ID 앞 8자리를 맞추면 올바른 키를 특정할 수 있습니다.⁶ 찾을 곳은 4장의 표와 같고, 순서대로 확인합니다.

1. 조직의 저장 위치(Entra ID 관리 센터/Intune, 또는 AD DS) ── 관리자·헬프데스크 경유
2. 이용자 본인 계정 ── 직장 계정이면 aka.ms/aadrecoverykey, 개인 Microsoft 계정이면 aka.ms/myrecoverykey⁶
3. 활성화 때 사본 ── 인쇄한 종이, USB 메모리 안의 파일, 저장한 텍스트 파일⁶

flowchart TB
    REC["파란 복구 화면<br/>복구 키 ID가 표시됨"] --> ID["키 ID 앞 8자리를 적어 둔다"]
    ID --> ORG["1. 조직의 저장 위치<br/>(Entra ID 관리 센터·Intune / AD DS)"]
    ORG -- "ID가 일치하는 키 있음" --> INPUT["48자리를 입력해 부팅"]
    ORG -- "없음" --> SELF["2. 이용자 본인 계정<br/>aka.ms/aadrecoverykey / aka.ms/myrecoverykey"]
    SELF -- "일치하는 키 있음" --> INPUT
    SELF -- "없음" --> PAPER["3. 활성화 때 사본<br/>(인쇄한 종이·USB 메모리·파일)"]
    PAPER -- "일치하는 키 있음" --> INPUT
    PAPER -- "없음" --> LOST["초기화(모든 데이터 소실)뿐<br/>Microsoft도 꺼낼 수 없음"]
    INPUT --> AFTER["원인을 확인하고, 사용한 복구 키는<br/>무효화한 뒤 재발급(6.3절)"]

함께 「왜 복구 모드로 들어갔는가」의 원인 확인을 습관으로 두십시오. 전날에 BIOS 업데이트를 했다, Secure Boot 설정을 만졌다, 같은 짐작이 있으면 설계대로의 동작입니다. 짐작이 없는데 반복되면 하드웨어 이상이나, 물리 접근에 의한 변조 가능성까지 포함해 조사할 가치가 있습니다.³

6.2. 도저히 찾을 수 없는 경우

가혹한 이야기지만, 복구 키를 찾지 못하면 그 암호화 드라이브의 데이터를 꺼낼 방법은 없습니다. 조직 관리 PC라면 IT 부서 확인이 마지막 보루이고, 그래도 없으면 디바이스 초기화(모든 데이터 소실)뿐입니다. Microsoft 지원은 분실한 복구 키를 제공하거나 다시 만들 수 없습니다.⁶

이를 「암호화 때문에 데이터가 사라졌다」고 보는 것은 인과가 반대입니다. 복구 키 관리를 구조로 만들지 않은 것이 원인이며, 같은 관리 허술은 도난 때 정보 유출로 드러났을 것입니다.

6.3. 사용한 복구 키는 일회용으로 쓴다 ── 수리·분실·퇴사의 운영

• 수리에 맡길 때: 수리 업체에 복구 키를 넘겼거나(또는 넘겼을 가능성이 있으면), 돌아온 뒤에 먼저 새 복구 암호를 추가하고 Entra ID / AD DS 백업 성공을 확인한 다음, 넘긴 복구 암호를 삭제합니다. 먼저 삭제하면 추가나 백업이 실패한 시점에 그 드라이브는 복구 수단이 없는 상태가 되므로 순서가 중요합니다. Microsoft도 사용 후 복구 암호 무효화를 권하며, 추가→백업→삭제의 일련은 명령으로 끝낼 수 있습니다.⁵ Entra ID 조인 디바이스에서는 사용된 복구 암호를 자동으로 순환(rotate)하는 정책도 있습니다. 기본값은 Entra ID 조인 디바이스에서 켜져 있지만, 복구 정보 백업을 필수로 하는 정책(5.1)이 구성되어 있을 때만 동작합니다. 자동 순환을 믿기 전에 이 전제 구성과, 실제로 키가 바뀌는지를 확인하십시오.⁴
• PC를 분실했을 때: 보호가 켜져 있었는지(TPM protector 생성 완료·clear key 제거 완료)를 4장의 명령 출력 기록이나 관리 도구로 확인하고, 암호화되어 있었다면 「디스크상의 데이터는 읽을 수 없다」고 설명할 수 있는 상태가 됩니다. 이것이 평시에 전수 확인해 두는 가장 큰 이유입니다.
• 퇴사·PC 반납 때: 반납된 PC의 복구 키가 퇴사자 개인 Microsoft 계정에만 있는 상태를 만들지 않는 것이 첫째입니다. 조직 저장 위치로의 집약(4장)이 되어 있으면, 반납 시 작업은 재키팅과 복구 암호 재발급만으로 끝납니다.

예를 들어 수리의 경우를 흐름으로 그리면 다음과 같습니다.

flowchart LR
    S["수리에 맡김<br/>(복구 키를 넘겼을 가능성)"] --> B["PC가 돌아옴"]
    B --> N["새 복구 암호를 추가"]
    N --> BK["Entra ID / AD DS로의<br/>백업 성공을 확인"]
    BK --> D["넘긴 복구 암호를<br/>무효화(삭제)한다"]
    D --> OK["대장을 갱신하고 완료"]

7. 폐기와의 관계 ── 암호화된 디스크는 폐기가 수월해진다

BitLocker의 효과는 사용 중만이 아닙니다. 드라이브가 처음부터 암호화되어 있으면, 폐기 때 디스크에 남는 것은 암호문뿐입니다. BitLocker는 원래 분실·도난뿐 아니라 「부적절하게 폐기된 디바이스」에서의 데이터 유출을 막는 기능으로 설계되었고, 보호된 디바이스의 폐기·재활용 때 데이터를 읽을 수 없게 하는 것이 목적에 포함됩니다.¹

다만 암호화되어 있다고 해서 폐기 시 삭제 절차(초기화·전용 삭제 도구·물리 파괴)를 생략해도 되는 것은 아닙니다. 암호화는 「삭제 전·삭제할 수 없을 때 디스크에서 평문을 읽히는 위험을 낮추는」 보험이며, 검증 가능한 삭제의 대체는 아니기 때문입니다. 그 위에서 암호화 운영 조직에는 고유 작업이 하나 더해집니다 ── 복구 키 사본(종이·파일·AD나 Entra ID 위의 등록)의 정리입니다. 디스크를 지워도 사본 복구 키가 남아 있으면 대장상의 폐기는 끝나지 않았습니다. 오래된 키 삭제까지 포함해 폐기 절차의 일부로 두십시오.

다만 PC 폐기에는 암호화 이외의 논점 ── 계정이나 라이선스 해제, 자산 대장, 증적 ── 도 있습니다. 전체 절차는 「Windows PC를 폐기하기 전에 해 두고 싶은 것」에 체크리스트로 정리되어 있으니, 암호화를 전제로 한 폐기 흐름을 갖출 때 함께 쓰십시오.

8. 업무 앱 개발자의 관점 ── 성능·장치 PC·클론 배포

마지막으로, 업무 앱이나 장치 제어 PC를 맡은 입장에서의 주의점입니다.

• 성능 영향은 「먼저 기본 128비트로 실측」이 기본입니다. Microsoft 스스로 키 길이 선택 기준을 「디바이스 성능에 따라」로 두고, 성능이 높은 드라이브·CPU면 256비트, 아니면 128비트로 합니다.⁴ 뒤집으면, 요즘 PC에서 기본 XTS-AES 128이 업무 앱의 체감을 좌우하는 일은 드물고, 당사에서도 파일 I/O가 특별히 무거운 앱 외에는 문제가 된 경험이 거의 없습니다. 의심스러우면 운영과 비슷한 데이터량으로 암호화 전후 I/O를 실측한 뒤 판단해야 하며, 느낌으로 「느려질 것 같으니 끈다」는 본말이 뒤집힌 것입니다.
• 암호화는 앱에서 투명합니다. BitLocker는 볼륨 전체 암호화이며, 파일 API 동작은 바뀌지 않습니다. 반대로 말하면 실행 중인 머신 위에서 앱이 다루는 비밀 정보(연결 문자열·API 키)는 BitLocker로는 지키지 못합니다. 로그온된 머신에서는 드라이브가 복호화되어 보이기 때문입니다. 그쪽은 DPAPI 등의 영역입니다(「Windows 앱의 비밀 정보는 어디에 저장하는가」).
• 장치 PC·키오스크 PC는 「무인 재부팅이 되는가」로 구성을 정합니다. TPM만의 구성이면 전원 차단 후 복귀도 무인으로 올라오지만, TPM+PIN이나 startup key는 부팅마다 사람이 필요하고 무인 운전 장치에는 맞지 않습니다. 한편 TPM만 구성은 3장의 트리거(펌웨어 업데이트 등)로 복구 화면 그대로 멈추는 위험을 안으므로, 현장에서 떨어진 곳(잠금 보관+대장)에 복구 키를 두고, 장치 보수 절차서에 「작업 전 Suspend-BitLocker」를 명시하는 것이 운영의 핵심이 됩니다. 무인 단말을 굳히는 전반은 「키오스크 모드로 업무 단말을 굳히기」에서 다룹니다. 참고로 24H2 자동 디바이스 암호화의 요구 사항 완화는 Windows IoT 에디션에는 적용되지 않지만², 이는 「IoT면 자동 암호화가 일어나지 않는다」는 뜻이 아닙니다. 완화 이전부터의 요구 사항(HSTI/Modern Standby 등)을 충족하는 기종에서는 예전과 같이 자동 암호화가 있을 수 있으므로, 장치 PC에서도 manage-bde -status로 상태 확인을 키팅 절차에 넣어 두는 것이 확실합니다.
• 클론 배포에서는 「암호화한 뒤 이미지화」를 하지 않는다. 복구 암호는 만든 디바이스에 고유합니다.³ 보호를 켠 상태의 부모 이미지를 복제하는 구성은 취하지 않고, 배포 후 PC마다 활성화(또는 OOBE에서의 자동 암호화)→복구 키 백업, 순서로 갑니다. 키팅을 스크립트화하고 있다면(「winget + PowerShell로 PC 키팅을 자동화하기」), 5.4절의 활성화와 백업 확인을 마지막 공정에 더하면 됩니다.

9. 정리

• Windows 11 24H2 이후의 클린 설치에서는 TPM+UEFI Secure Boot를 충족하는 PC에서 디바이스 암호화가 기본으로 초기화됩니다. HSTI/Modern Standby와 DMA 요구 사항은 없어졌고, 대상은 흔한 데스크톱 PC까지 넓어졌습니다.
• 「멋대로 암호화되었다」에 대한 올바른 대응은 비활성화가 아니라 복구 키 소재 확인입니다. 끄면 분실·도난·폐기 시의 보호를 잃고, 한 번 끄면 자동으로는 다시 켜지지 않습니다.
• 복구 키 저장 위치는 Entra ID / AD DS / Microsoft 계정 / 인쇄·파일의 네 가지이며, 로그인 방식으로 거의 정해집니다. 조직의 저장 위치를 하나로 정하고, 모든 PC가 거기에 들어 있는지를 전수 확인하십시오.
• 확인은 manage-bde -protectors -get C: 또는 (Get-BitLockerVolume -MountPoint C).KeyProtector, 뒤늦은 백업은 BackupToAAD-BitLockerKeyProtector / Backup-BitLockerKeyProtector로 끝납니다.
• 복구 키는 펌웨어 업데이트·Secure Boot 설정 변경·하드웨어 교체 등에서 정당한 소유자에게도 요구됩니다. 계획 작업 전의 Suspend-BitLocker를 절차서에 넣으십시오.
• 기본 방식은 XTS-AES 128이며, 나중에 바꾸려면 복호화→재암호화가 필요합니다. 새 드라이브라면 사용한 공간만 암호화로 충분합니다.
• 사용한 복구 키는 무효화하고 재발급한다, 퇴사자 계정에 키를 남기지 않는다, 폐기 때는 키 사본까지 처리한다 ── 복구 키는 「발급하고 끝」이 아니라 수명 주기로 관리하는 것입니다.
• 암호화는 폐기 시의 보험도 되지만, 삭제 절차(초기화·삭제 도구·물리 파괴)의 대체는 아닙니다. BitLocker를 끄는 것이 아니라, 복구 키 관리와 세트로 다루는 것이 중소기업에게는 현실적인 답입니다.

관련 글

• Windows의 TPM이란 무엇인가 ── 그림으로 보는 「키를 밖으로 내지 않는 금고」와 측정 부팅
• Windows PC를 폐기하기 전에 해 두고 싶은 것 ── 데이터 삭제·계정 해제·백업의 실무 체크리스트
• Windows 10 지원 종료 후의 현실적인 답 ── ESU·LTSC·교체의 판단표
• 중소기업의 보안 대책, 무엇부터 시작하는가 ── IPA 「중소기업의 정보보안 대책 가이드라인」 제4.0판의 읽는 법
• 키오스크 모드로 업무 단말을 굳히기 ── Assigned Access·Shell Launcher의 고르는 법과 운영 설계
• winget + PowerShell로 PC 키팅을 자동화하기 ── 절차서를 실행 가능하게 만들기
• Windows 앱의 비밀 정보는 어디에 저장하는가 ── DPAPI를 축으로 한 모범 사례

관련 상담 영역

KomuraSoft LLC에서는 업무 앱·장치 PC를 포함한 Windows 환경의 암호화 운영 설계(복구 키 저장 위치 설계, 키팅에 넣기, 장치 PC에서의 BitLocker 구성)와, 암호화 환경에서의 업무 앱 성능 검증·문제 조사를 다룹니다. 「장치 PC를 암호화해도 되는가」를 확인하는 단계부터 괜찮습니다.

• 기술 상담·설계 리뷰
• Windows 앱 개발
• 장애 조사·원인 분석
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

어느새 '디바이스 암호화'가 켜져 있었습니다. 꺼도 될까요?

끄는 것은 권하지 않습니다. Windows 11 버전 24H2 이후의 클린 설치에서는 TPM과 Secure Boot 등의 조건을 충족하는 PC에서 디바이스 암호화가 기본으로 초기화되므로, '멋대로 켜진' 것처럼 보입니다. 분실·도난 시 데이터를 지키는 기능이며, 끄면 보호를 잃는 데다 한 번 끄면 자동으로는 다시 켜지지 않습니다. 할 일은 비활성화가 아니라 manage-bde -protectors -get C: 등으로 복구 키를 확인하고, Microsoft 계정·Entra ID·AD 등 조직에서 정한 위치에 저장되어 있게 하는 것입니다.

BitLocker 복구 키는 어디에 있나요?

저장 위치는 PC의 로그인 방식에 따라 정해집니다. 개인 Microsoft 계정으로 설정한 PC라면 https://aka.ms/myrecoverykey 에 같은 계정으로 로그인하면 목록을 볼 수 있습니다. 회사 Entra ID(직장 계정)에 조인한 PC는 https://aka.ms/aadrecoverykey 의 'BitLocker 키 표시'에서 확인할 수 있습니다. 온프레미스 AD 도메인에 가입한 PC는 정책이 구성되어 있으면 컴퓨터 개체 아래에서 관리자가 꺼낼 수 있습니다. 그 밖에 인쇄한 종이나 USB 메모리·파일 사본이 있을 수도 있습니다. 복구 화면의 복구 키 ID 앞 8자리와 맞추면 올바른 키를 특정할 수 있습니다.

Windows 11 Home PC에서도 BitLocker를 쓸 수 있나요?

에디션마다 쓸 수 있는 기능이 다릅니다. PIN 추가나 정책 관리를 포함한 전체 기능 BitLocker를 켤 수 있는 것은 Pro/Enterprise/Education 계열이며, Home에서는 쓸 수 없습니다. 반면 간소화된 디바이스 암호화는 Home을 포함한 모든 에디션에서 이용할 수 있고, TPM과 UEFI Secure Boot 등의 요구 사항을 충족하면 자동으로 켜집니다. 다만 보호를 켜려면 관리자 권한 Microsoft 계정으로 로그인해야 하며, 로컬 계정만으로는 보호되지 않습니다. 회사 PC로 관리한다면 Pro를 전제로 Entra ID 또는 AD에서 복구 키를 중앙 관리하는 구성을 권합니다.

BIOS(UEFI 펌웨어)를 업데이트했더니 복구 키를 요구받았습니다. 왜인가요?

BitLocker는 TPM으로 부팅 환경이 변조되지 않았는지 검증합니다. 펌웨어 업데이트·Secure Boot 설정 변경·TPM 지우기·메인보드 교체 등으로 부팅 시 측정값이 바뀌면 '평소와 다른 환경'으로 판단해 복구 모드로 들어갑니다. 고장이 아니라 설계대로의 동작입니다. 계획된 업데이트 전에는 Suspend-BitLocker(또는 manage-bde -protectors -disable C:)로 보호를 일시 중지한 뒤 진행하면 복구 키 입력 없이 작업할 수 있습니다. 일시 중지 중에도 드라이브는 암호화된 채로 남고, 기본값에서는 다음 재부팅 때 보호가 자동으로 다시 켜집니다.

복구 키를 찾을 수 없으면 데이터를 꺼낼 수 있나요?

올바른 복구 키(48자리 복구 암호)나 다른 해제 수단이 없는 한, 암호화된 드라이브에서 데이터를 꺼낼 방법은 없습니다. Microsoft 지원도 분실한 복구 키를 재발급하거나 꺼낼 수 없다고 분명히 밝힙니다. 조직 관리 PC라면 먼저 IT 부서에 확인하고, 개인 PC라면 Microsoft 계정의 복구 키 페이지, 인쇄한 사본, USB 메모리 안의 .bek/.txt 파일을 찾으십시오. 그래도 없으면 PC 초기화(재설치)뿐이며, 데이터는 사라집니다. 그래서 암호화를 끌지를 논의하기 전에, 모든 PC의 복구 키가 조직 관리 아래 있는지를 먼저 확인해야 합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.