오프라인 복구를 위해 암호화된 Linux 디스크 잠금 해제

아티클
03/27/2024

이 문서에서는 오프라인 복구를 위해 ADE(Azure Disk Encryption) 사용 OS 디스크의 잠금을 해제하는 방법을 설명합니다.

Azure Disk Encryption은 Microsoft 보증 Linux VM(가상 머신)에 적용할 수 있습니다. Linux VM에서 Azure Disk Encryption을 사용하도록 설정하기 위한 몇 가지 기본 요구 사항은 다음과 같습니다.

Azure Key Vault
Azure CLI 또는 Windows PowerShell cmdlet
디바이스 매퍼(DM)-Crypt

증상

OS 디스크에서 ADE를 사용하도록 설정한 경우 복구 VM에 디스크를 탑재하려고 하면 다음과 같은 오류 메시지가 표시될 수 있습니다.

mount: 잘못된 fs 유형, 잘못된 옵션, /dev/sda2의 잘못된 슈퍼블록, 코드 페이지 또는 도우미 프로그램 누락 또는 기타 오류

mount: 알 수 없는 파일 시스템 유형 'LVM2_member'

준비

오프라인 복구를 위해 암호화된 OS 디스크의 잠금을 해제하기 전에 다음 작업을 완료합니다.

디스크에서 ADE가 사용하도록 설정되어 있는지 확인합니다.
OS 디스크가 ADE 버전 0(이중 패스 암호화) 또는 ADE 버전 1(단일 패스 암호화)을 사용하는지 여부를 결정합니다.
OS 디스크가 관리되는지 아니면 관리되지 않는지 확인합니다.
암호화된 디스크의 잠금을 해제하는 방법을 선택합니다.

디스크에서 ADE가 사용하도록 설정되어 있는지 확인합니다.

Azure Portal, PowerShell 또는 Azure CLI(Azure 명령줄 인터페이스)에서 이 단계를 수행할 수 있습니다.

Azure Portal

Azure Portal 실패한 VM에 대한 개요 블레이드를 봅니다. 다음 스크린샷과 같이 디스크 아래에 Azure 디스크 암호화 항목 이 사용 또는 사용 안 함으로 표시됩니다.

디스크에서 AD E가 사용하도록 설정되어 있음을 보여 주는 Azure Portal의 V M에 대한 개요 블레이드의 스크린샷.

PowerShell

cmdlet을 Get-AzVmDiskEncryptionStatus 사용하여 VM의 OS 또는 데이터 볼륨이 ADE를 사용하여 암호화되는지 여부를 확인할 수 있습니다. 다음 예제 출력은 OS 볼륨에서 ADE 암호화를 사용하도록 설정되어 있음을 나타냅니다.

Get-AzVmDiskEncryptionStatus -ResourceGroupName "ResourceGroupName" -VMName "VmName"

cmdlet에 Get-AzureRmDiskEncryptionStatus 대한 자세한 내용은 Get-AzVMDiskEncryptionStatus(Az.Compute)를 참조하세요.

Azure CLI

명령을 사용하여 az vm encryption show VM 디스크에서 ADE를 사용할 수 있는지 여부를 검사 수 있습니다.

az vm encryption show --name MyVM --resource-group MyResourceGroup --query "disks[].encryptionSettings[].enabled"

명령에 대한 az vm encryption show 자세한 내용은 az vm encryption show를 참조하세요.

참고

디스크에서 ADE를 사용하도록 설정하지 않은 경우 복구 VM에 디스크를 연결하는 방법을 알아보려면 다음 문서를 참조하세요. OS 디스크를 복구 VM에 연결하여 Linux VM 문제 해결

OS 디스크가 ADE 버전 0(이중 패스 암호화) 또는 ADE 버전 1(단일 패스 암호화)을 사용하는지 확인합니다.

VM의 속성을 연 다음 확장을 선택하여 확장 블레이드를 열어 Azure Portal ADE 버전을 식별할 수 있습니다. 확장 블레이드에서 AzureDiskEncryptionForLinux의 버전 번호를 확인합니다.

버전 번호가 인 0.*경우 디스크는 이중 패스 암호화를 사용합니다.
버전 번호가 이상 버전인 1.* 경우 디스크는 단일 패스 암호화를 사용합니다.

디스크에서 ADE 버전 0(이중 패스 암호화)을 사용하는 경우 메서드 3 을 사용하여 디스크의 잠금을 해제합니다.

OS 디스크가 관리되는지 아니면 관리되지 않는지 확인

OS 디스크가 관리되는지 아니면 관리되지 않는지 모르는 경우 OS 디스크가 관리되는지 아니면 관리되지 않는지 확인합니다.

OS 디스크가 관리되지 않는 디스크인 경우 메서드 3 의 단계에 따라 디스크의 잠금을 해제합니다.

암호화된 디스크의 잠금을 해제하는 방법을 선택합니다.

다음 방법 중 하나를 선택하여 암호화된 디스크의 잠금을 해제합니다.

디스크가 ADE 버전 1을 사용하여 관리 및 암호화되고 인프라 및 회사 정책을 통해 복구 VM에 공용 IP 주소를 할당할 수 있는 경우 방법 1: az vm repair 명령을 사용하여 암호화된 디스크의 잠금을 자동으로 해제합니다.
디스크가 ADE 버전 1을 사용하여 관리 및 암호화되지만 인프라 또는 회사 정책으로 인해 복구 VM에 공용 IP 주소를 할당할 수 없는 경우 메서드 2: BEK 볼륨의 키 파일로 암호화된 디스크 잠금을 해제합니다. 이 방법을 선택하는 또 다른 이유는 Azure에서 리소스 그룹을 만들 수 있는 권한이 없는 경우입니다.
이러한 방법 중 하나가 실패하거나 ADE 버전 1(이중 패스 암호화)을 사용하여 디스크를 관리하지 않거나 암호화하는 경우 메서드 3 의 단계에 따라 디스크 잠금을 해제합니다.

방법 1: az vm repair 명령을 사용하여 자동으로 암호화된 디스크 잠금 해제

이 메서드는 az vm repair 명령을 사용하여 복구 VM을 자동으로 만들고, 실패한 Linux VM의 OS 디스크를 해당 복구 VM에 연결한 다음, 암호화된 경우 디스크의 잠금을 해제합니다. 이 메서드는 복구 VM에 공용 IP 주소를 사용해야 하며, ADE 키가 KEK(키 암호화 키)를 사용하여 래핑되었는지 여부에 관계없이 암호화된 디스크의 잠금을 해제합니다.

이 자동화된 방법을 사용하여 VM을 복구하려면 Azure Virtual Machine 복구 명령을 사용하여 Linux VM 복구의 단계를 수행합니다.

인프라 및 회사 정책에서 공용 IP 주소를 할당할 수 없거나 명령이 az vm repair 디스크의 잠금을 해제하지 않는 경우 다음 메서드로 이동합니다.

방법 2: BEK 볼륨의 키 파일로 암호화된 디스크 잠금 해제

암호화된 디스크의 잠금을 해제하고 수동으로 탑재하려면 다음 단계를 수행합니다.

새 복구 VM을 만들고 VM을 만드는 동안 암호화된 디스크를 이 VM에 연결합니다.

복구 VM을 만들 때 암호화된 디스크를 연결해야 합니다. 시스템이 연결된 디스크가 암호화되었음을 감지하기 때문입니다. 따라서 Azure 키 자격 증명 모음에서 ADE 키를 가져온 다음 키 파일을 저장하기 위해 "BEK VOLUME"이라는 새 볼륨을 만듭니다.
복구 VM에 로그인한 다음, 암호화된 디스크에 탑재된 파티션을 분리합니다.
BEK 볼륨에서 ADE 키 파일을 식별합니다.
암호화된 OS의 부팅 파티션에서 헤더 파일을 식별합니다.
ADE 키 파일 및 헤더 파일을 사용하여 암호화된 디스크의 잠금을 해제합니다.
파티션을 탑재합니다( LVM, RAW 또는 비 LVM).

복구 VM 만들기

암호화된 OS 디스크의 스냅샷.
스냅샷 디스크를 만듭니다. 새 디스크의 경우 복구하려는 문제 VM과 동일한 위치 및 가용성 영역을 선택합니다.
다음 지침에 따라 VM을 만듭니다.
- Azure Marketplace 실패한 VM에 사용된 복구 VM에 대해 동일한 이미지를 선택합니다. (OS 버전은 동일해야 합니다.)
- VM에 8GB 이상의 메모리를 할당하는 크기를 선택합니다.
- 이 새 VM을 2단계에서 만든 새 디스크에 사용한 것과 동일한 리소스 그룹, 지역 및 가용성 설정에 할당합니다.
가상 머신 만들기 마법사의 디스크 페이지에서 새 디스크(방금 스냅샷 만든 디스크)를 데이터 디스크로 연결합니다.

중요

암호화 설정은 VM을 만드는 동안에만 검색되므로 VM을 만들 때 디스크를 연결해야 합니다. 이렇게 하면 ADE 키 파일이 포함된 볼륨을 VM에 자동으로 추가할 수 있습니다.

암호화된 디스크에 탑재된 파티션 분리

복구 VM을 만든 후 복구 VM에 SSH를 실행하고, 적절한 자격 증명을 사용하여 로그인한 다음, 계정을 루트로 승격합니다.
```
sudo -s 
```
lsblk 명령을 사용하여 연결된 디바이스를 나열합니다. 출력에 연결된 디스크가 여러 대 표시됩니다. 이러한 디스크에는 활성 OS 디스크 및 암호화된 디스크가 포함됩니다. 순서대로 표시할 수 있습니다.
다음 정보를 사용하여 암호화된 디스크를 식별합니다.
- 디스크에 여러 파티션이 있습니다.
- 디스크는 루트 디렉터리("/")를 파티션의 탑재점으로 나열하지 않습니다.
- 디스크는 스냅샷 만들 때 기록한 크기와 일치합니다.
다음 예제에서 출력은 "sdd"가 암호화된 디스크임을 나타냅니다. 여러 파티션이 있고 탑재 지점으로 "/"를 나열하지 않는 유일한 디스크입니다.
파일 시스템에 탑재된 암호화된 데이터 디스크의 파티션을 분리합니다. 예를 들어 이전 예제에서는 "/boot/efi"* 및 "/boot"를 모두 분리해야 합니다.
```
umount /boot/efi 

umount /boot 
```

ADE 키 파일 식별

암호화된 디스크의 잠금을 해제하려면 키 파일과 헤더 파일이 모두 있어야 합니다. 키 파일은 BEK 볼륨에 저장되고 헤더 파일은 암호화된 OS 디스크의 부팅 파티션에 있습니다.

BEK 볼륨인 파티션을 확인합니다.
```
lsblk -fs | grep -i bek 
```
다음 예제 출력은 sdb1이 BEK 볼륨임을 나타냅니다.
```
>sdb1  vfat   BEK VOLUME      04A2-FE67 
```
BEK 볼륨이 없는 경우 암호화된 디스크를 연결하여 복구 VM을 다시 만듭니다. BEK 볼륨이 여전히 자동으로 연결되지 않는 경우 메서드 3을 시도 하여 BEK 볼륨을 검색합니다.
"/mnt" 폴더 아래에 "azure_bek_disk"라는 디렉터리를 만듭니다.
```
mkdir /mnt/azure_bek_disk 
```
"/mnt/azure_bek_disk" 디렉터리에 BEK 볼륨을 탑재합니다. 예를 들어 sdb1이 BEK 볼륨인 경우 다음 명령을 입력합니다.
```
mount /dev/sdb1 /mnt/azure_bek_disk 
```
사용 가능한 디바이스를 다시 나열합니다.
```
lsblk -o NAME,SIZE,LABEL,PARTLABEL,MOUNTPOINT  
```
참고: BEK 볼륨으로 결정한 파티션이 이제 "/mnt/azure_bek_disk"에 탑재된 것을 볼 수 있습니다.
"/mnt/azure_bek_disk/" 디렉터리에서 내용을 봅니다.
```
ls -l /mnt/azure_bek_disk
```
출력에 다음 파일이 표시됩니다(ADE 키 파일은 "LinuxPassPhraseFileName").
```
>total 1 

 -rwxr-xr-x 1 root root 148 Aug  4 01:04 CRITICAL_DATA_WARNING_README.txt 
 -r-xr-xr-x 1 root root 172 Aug  4 01:04 LinuxPassPhraseFileName
```
둘 이상의 디스크가 암호화된 VM에 연결된 경우 여러 개의 "LinuxPassPhraseFileName"이 표시될 수 있습니다. "LinuxPassPhraseFileName"은 LUN(논리 단위 번호)과 동일한 순서로 디스크 수에 따라 열거됩니다.

헤더 파일 식별

암호화된 디스크의 부팅 파티션에는 헤더 파일이 포함됩니다. 이 파일을 "LinuxPassPhraseFileName" 키 파일과 함께 사용하여 암호화된 디스크의 잠금을 해제합니다.

다음 명령을 사용하여 사용 가능한 디스크 및 파티션의 선택한 특성을 표시합니다.
```
lsblk -o NAME,SIZE,LABEL,PARTLABEL,MOUNTPOINT
```
암호화된 디스크에서 OS 파티션(루트 파티션)을 식별합니다. 암호화된 디스크에서 가장 큰 파티션입니다. 이전 예제 출력에서 OS 파티션은 "sda4"입니다. 잠금 해제 명령을 실행할 때 이 파티션을 지정해야 합니다.
파일 구조의 루트 디렉터리("/")에서 암호화된 디스크의 루트 파티션을 탑재할 디렉터리를 만듭니다. 디스크가 잠금 해제된 후 나중에 이 디렉터리를 사용합니다. 복구 VM의 활성 OS 파티션과 구분하려면 "investigateroot"라는 이름을 지정합니다.
```
mkdir /{investigateboot,investigateroot}
```
암호화된 디스크에서 헤더 파일이 포함된 부팅 파티션을 식별합니다. 암호화된 디스크에서 부팅 파티션은 LABEL 또는 PARTLABEL 열에 값을 표시하지 않는 두 번째로 큰 파티션입니다. 이전 예제 출력에서 암호화된 디스크의 부팅 파티션은 "sda2"입니다.
4단계에서 식별한 부팅 파티션을 /investigateboot/ 디렉터리에 탑재합니다. 다음 예제에서는 암호화된 디스크의 부팅 파티션이 sda2입니다. 그러나 시스템의 위치는 다를 수 있습니다.
```
mount /dev/sda2 /investigateboot/ 
```
파티션 탑재가 실패하고 "잘못된 fs 유형, 잘못된 옵션, 잘못된 슈퍼블록" 오류 메시지를 반환하는 경우 다음 예제와 같이 명령을 사용하여 mount -o nouuid 다시 시도합니다.
```
mount -o nouuid /dev/sda2 /investigateboot/ 
```
/investigateboot/ 디렉터리에 있는 파일을 나열합니다. "luks" 하위 디렉터리에는 디스크의 잠금을 해제해야 하는 헤더 파일이 포함되어 있습니다.
/investigateboot/luks/ 디렉터리에 있는 파일을 나열합니다. 헤더 파일의 이름은 "osluksheader"입니다.
```
ls -l /investigateboot/luks 
```

ADE 키 파일 및 헤더 파일을 사용하여 디스크 잠금 해제

cryptsetup luksOpen 명령을 사용하여 암호화된 디스크에서 루트 파티션의 잠금을 해제합니다. 예를 들어 암호화된 OS를 포함하는 루트 파티션의 경로가 /dev/sda4이고 잠금 해제된 파티션에 이름 "osencrypt"를 할당하려는 경우 다음 명령을 실행합니다.
```
cryptsetup luksOpen --key-file /mnt/azure_bek_disk/LinuxPassPhraseFileName --header /investigateboot/luks/osluksheader /dev/sda4 osencrypt 
```
이제 디스크의 잠금을 해제했으므로 /investigateboot/ 디렉터리에서 암호화된 디스크의 부팅 파티션을 분리합니다.
```
umount /investigateboot/ 
```
참고: 나중에 이 파티션을 다른 디렉터리에 탑재해야 합니다.

다음 단계는 방금 잠금 해제한 파티션을 탑재하는 것입니다. 파티션을 탑재하는 데 사용하는 방법은 디스크에서 사용하는 디바이스 매퍼 프레임워크(LVM 또는 비 LVM)에 따라 달라집니다.
파일 시스템 유형과 함께 디바이스 정보를 나열합니다.
```
lsblk -o NAME,FSTYPE 
```
잠금 해제된 파티션과 할당한 이름이 표시됩니다(이 예제에서는 해당 이름이 "osencrypt").
- "LVM_member"과 같은 LVM 파티션의 경우 LVM 파티션 RAW 또는 비 LVM 탑재를 참조하세요.
- LVM이 아닌 파티션의 경우 LVM이 아닌 파티션 탑재를 참조하세요.

잠금 해제된 파티션을 탑재하고 크로트 환경(LVM에만 해당)을 입력합니다.

디스크가 LVM 디바이스 매퍼 프레임워크를 사용하는 경우 디스크를 탑재하고 크로트 환경에 진입하기 위한 추가 단계를 수행해야 합니다. chroot 도구를 암호화된 디스크와 함께 사용하려면 잠금 해제된 파티션("osencrypt") 및 논리 볼륨을 rootvg라는 볼륨 그룹으로 인식해야 합니다. 그러나 기본적으로 복구 VM의 OS 파티션 및 논리 볼륨은 rootvg라는 이름의 볼륨 그룹에 이미 할당되어 있습니다. 우리는 이 충돌을 계속하기 전에 resolve 합니다.

pvs 명령을 사용하여 LVM 물리적 볼륨의 속성을 표시합니다. 다음 예제와 같이 잠금 해제된 파티션("/dev/mapper/osencrypt") 및 다른 디바이스가 UUID(중복 범용 고유 식별자)를 사용하고 있음을 나타내는 경고 메시지가 표시될 수 있습니다. 또는 rootvg에 할당된 두 개의 파티션이 표시될 수 있습니다.

참고

chroot 유틸리티를 통해 논리 볼륨에 액세스할 수 있도록 잠금 해제된 파티션("osencrypt")만 rootvg 볼륨 그룹에 할당하려고 합니다. 이 문제를 해결하려면 일시적으로 파티션을 다른 볼륨 그룹으로 가져오고 해당 볼륨 그룹을 활성화합니다. 다음으로 현재 rootvg 볼륨 그룹의 이름을 바꿉니다. chroot 환경을 입력한 후에만 암호화된 디스크의 볼륨 그룹의 이름을 "rootvg"로 바꿉니다.

잠금 해제된 파티션 할당(예)

새로 잠금 해제된 파티션을 새 볼륨 그룹으로 가져옵니다. 이 예제에서는 새 볼륨 그룹 "rescuemevg"의 이름을 일시적으로 지정합니다. 새로 잠금 해제된 파티션을 새 볼륨 그룹으로 가져옵니다. 이 예제에서는 새 볼륨 그룹 "rescuemevg"의 이름을 일시적으로 지정합니다.

새 볼륨 그룹을 활성화합니다.

vgimportclone -n rescuemevg /dev/mapper/osencrypt
vgchange -a y rescuemevg

이전 rootvg 볼륨 그룹의 이름을 바꿉니다. 이 예제에서는 "oldvg"라는 이름을 사용합니다.
```
vgrename rootvg oldvg 
```
를 실행 lsblk -o NAME,SIZE,LABEL,PARTLABEL,MOUNTPOINT 하여 사용 가능한 디바이스를 검토합니다. 이제 할당한 이름으로 나열된 두 볼륨 그룹이 모두 표시됩니다.
중복 UUID를 사용하지 않고 rescuemevg/rootlv 논리 볼륨을 /investigateroot/ 디렉터리에 탑재합니다.
```
umount /investigateboot
mount -o nouuid /dev/rescuemevg/rootlv /investigateroot/ 
```
이제 실패한 VM의 루트 파티션이 잠금 해제되고 탑재되며 루트 파티션에 액세스하여 문제를 해결할 수 있어야 합니다. 자세한 내용은 파일 시스템 오류로 인한 Linux 가상 머신 부팅 문제 해결을 참조하세요.

그러나 문제 해결을 위해 chroot 유틸리티를 사용하려면 다음 단계를 계속 사용합니다.
중복된 UUID를 사용하지 않고 암호화된 디스크의 부팅 파티션을 디렉터리 /investigateroot/boot/에 탑재합니다. (암호화된 디스크의 부팅 파티션은 파티션 레이블이 할당되지 않은 두 번째로 큰 파티션입니다.) 현재 예제에서 암호화된 디스크의 부팅 파티션은 sda2입니다.
```
mount -o nouuid /dev/sda2 /investigateroot/boot
```
암호화된 디스크의 EFI 시스템 파티션을 /investigateroot/boot/efi 디렉터리에 탑재합니다. 레이블로 이 파티션을 식별할 수 있습니다. 현재 예제에서 EFI 시스템 파티션은 sda1입니다.
```
mount /dev/sda1 /investigateroot/boot/efi
```

암호화된 디스크의 볼륨 그룹에 탑재되지 않은 나머지 논리 볼륨을 "/investigateroot/"의 하위 디렉터리에 탑재합니다.

mount -o nouuid /dev/mapper/rescuemevg-varlv /investigateroot/var
mount -o nouuid /dev/mapper/rescuemevg-homelv /investigateroot/home
mount -o nouuid /dev/mapper/rescuemevg-usrlv /investigateroot/usr
mount -o nouuid /dev/mapper/rescuemevg-tmplv /investigateroot/tmp
mount -o nouuid /dev/mapper/rescuemevg-optlv /investigateroot/opt

Active Directory를 암호화된 디스크의 탑재된 루트 파티션으로 변경합니다.
```
cd /investigateroot
```

다음 명령을 입력하여 chroot 환경을 준비합니다.

mount -t proc proc proc
mount -t sysfs sys sys/
mount -o bind /dev dev/
mount -o bind /dev/pts dev/pts/
mount -o bind /run run/

chroot 환경을 입력합니다.
```
chroot /investigateroot/
```
grub 및 initramfs와 충돌하거나 가능한 문제를 방지하기 위해 rescuemevg 볼륨 그룹의 이름을 "rootvg"로 바꿉니다. initramfs를 다시 생성할 때 동일한 명명 규칙을 유지합니다. vg 이름이 변경되어 구조 VM에서 작업합니다. 다시 시작하면 더 이상 유용하지 않습니다. 구조 VM은 임시 VM으로 간주되어야 합니다.
```
vgrename rescuemevg rootvg
```
크로트 환경의 문제를 해결합니다. 예를 들어 로그를 읽거나 스크립트를 실행할 수 있습니다. 자세한 내용은 chroot 환경에서 수정 수행을 참조하세요.
chroot를 종료하고 OS 디스크를 교환합니다.

잠금 해제된 디스크를 탑재하고 크로트 환경(RAW/비 LVM)을 입력합니다.

파일 구조의 루트 디렉터리("/")에서 암호화된 디스크의 루트 파티션을 탑재할 디렉터리를 만듭니다. 디스크가 잠금 해제된 후 나중에 이 디렉터리를 사용합니다. 복구 VM의 활성 OS 파티션과 구분하려면 이름을 "investigateroot"로 지정합니다.
```
mkdir /{investigateboot,investigateroot}
```
새로 잠금 해제된 파티션("osencrypt")을 /investigateroot/ 디렉터리에 탑재합니다.
```
mount /dev/mapper/osencrypt /investigateroot/ 
```
파티션을 탑재하지 못하고 "잘못된 fs 유형, 잘못된 옵션, 잘못된 슈퍼블록" 오류 메시지를 반환하는 경우 mount -o nouuid 명령을 사용하여 다시 시도합니다.
```
mount -o nouuid /dev/mapper/osencrypt /investigateroot/ 
```
탑재된 파티션의 잠금이 해제되었는지 확인하려면 /investigateroot/ 디렉터리의 내용을 표시합니다.
```
ls /investigateroot/ 
```
이제 실패한 VM의 루트 파티션이 잠금 해제되고 탑재되었으므로 루트 파티션에 액세스하여 문제를 해결할 수 있습니다. 자세한 내용은 파일 시스템 오류로 인한 Linux 가상 머신 부팅 문제 해결을 참조하세요.

그러나 문제 해결에 chroot 유틸리티를 사용하려면 다음 단계로 이동합니다.
명령을 lsblk -o NAME,SIZE,LABEL,PARTLABEL,MOUNTPOINT 사용하여 사용 가능한 디바이스를 검토합니다. 암호화된 디스크의 부팅 파티션을 레이블이 할당되지 않은 두 번째로 큰 파티션으로 식별합니다.
다음 예제와 같이 암호화된 디스크의 부팅 파티션을 "/investigateroot/boot/" 디렉터리에 탑재합니다.
```
mount /dev/sdc2 /investigateroot/boot/ 
```
Active Directory를 암호화된 디스크의 탑재된 루트 파티션으로 변경합니다.
```
cd /investigateroot 
```

다음 명령을 입력하여 chroot 환경을 준비합니다.

mount -t proc proc proc 

mount -t sysfs sys sys/ 

mount -o bind /dev dev/ 

mount -o bind /dev/pts dev/pts/ 

mount -o bind /run run/

chroot 환경을 입력합니다.
```
chroot /investigateroot/ 
```
크로트 환경의 문제를 해결합니다. 로그를 읽거나 스크립트를 실행할 수 있습니다. 자세한 내용은 chroot 환경에서 수정 수행을 참조하세요.
chroot를 종료하고 OS 디스크를 교환합니다.

방법 3: 디스크를 다시 암호화하여 키 파일을 검색하고 암호화된 디스크의 잠금을 해제합니다.

복구 VM을 만들고 잠긴 디스크의 복사본을 복구 VM에 연결합니다.
- 관리 디스크의 경우 관리되는 OS 디스크를 복구 VM에 연결하여 Linux VM 문제 해결을 참조하세요.
- 관리되지 않는 디스크의 경우 Storage Explorer 사용하여 영향을 받는 VM의 OS 디스크 복사본을 만듭니다. 자세한 내용은 오프라인 복구를 위해 VM에 관리되지 않는 디스크 연결을 참조하세요.

암호화된 디스크를 복구 VM에 데이터 디스크로 연결한 후 원래 VM에 사용된 Key Vault 및 KEK(키 암호화 키)를 사용하여 이 데이터 디스크를 다시 암호화합니다. 이 프로세스는 복구 VM에서 BKE 키 파일을 사용하여 BEK 볼륨을 자동으로 생성하고 탑재합니다. ADE 확장이 데이터 디스크의 부팅 섹터를 암호화할 수 있으므로 EncryptFormatAll 옵션을 사용하면 안 됩니다.

원래 VM이 래핑된 BEK로 암호화된 경우 다음 명령을 실행합니다.

 az vm encryption enable -g "resource group" --name "VMName" --disk-encryption-keyvault "keyvault"  --key-encryption-key "kek" --volume-type "data"

원래 VM이 BEK로 암호화된 경우 다음 명령을 실행합니다.

az vm encryption enable -g "resource group" --name "VMName" --disk-encryption-keyvault "keyvault"  --volume-type "data"

disk-encryption-keyvault 및 key-encryption-key에 대한 값을 확인하려면 다음 명령을 실행합니다.

az vm encryption show --name "OriginalVmName" --resource-group "ResourceGroupName"

다음 표에서 출력의 값을 찾습니다. keyEncryptionKey 값이 비어 있으면 VM이 BEK로 암호화됩니다.

매개 변수	출력의 값	예
disk-encryption-keyvault	diskEncryptionKey:id	/subscriptions/deb73ff9-0000-0000-0000-0000c7a96d37/resourceGroups/Thomas/providers/Microsoft.KeyVault/vaults/ContosoKeyvault
key-encryption-key	keyEncryptionKey:KeyURI	`https://ContosoKeyvault.vault.azure.net/keys/mykey/00000000987145a3b79b0ed415fa0000`

다음 명령을 실행하여 새 디스크가 연결되어 있는지 여부를 검사.
```
lsblk -f
```
새 디스크가 연결된 경우 BEK 볼륨에서 ADE 키 파일 식별으로 이동한 다음 제공된 단계에 따라 디스크 잠금을 해제합니다.

다음 단계

VM에 연결하는 데 문제가 있는 경우 Azure VM에 대한 SSH 연결 문제 해결을 참조하세요.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유