Microsoft 보안 부팅 인증서 만료 가이드

2026년에 여러 Microsoft 보안 부팅 인증서가 만료되므로 이 문서에서는 업데이트된 Microsoft 보안 부팅 인증서가 UEFI (Unified Extensible Firmware Interface) 보안 부팅을 신뢰하도록 Compute Engine 보안 VM 인스턴스를 업데이트하는 방법을 안내합니다. 만료가 임박한 가장 중요한 인증서는 Linux Shim과 같은 서드 파티 부트 로더에 서명하는 Microsoft Corporation UEFI CA 2011 (2026년 6월 27일 만료)과 2026년 10월 19일에 만료되고 Windows 부트 로더에 서명하는 Microsoft Windows Production PCA 2011입니다.

UEFI 보안 부팅은 보안 VM이 VM 부팅 프로세스 중에 신뢰할 수 있는 소프트웨어와 펌웨어만 실행되도록 하는 데 사용하는 보안 표준입니다. 다양한 운영체제에서 보안 부팅을 지원하기 위해 Microsoft는 UEFI 인증서를 관리하여 인스턴스 펌웨어 내의 키 교환 키 (KEK) 및 허용된 서명 데이터베이스 (db) 변수에 저장합니다.

보안 부팅 인증서 및 만료일

인증서 이름	역할	만료일
Microsoft Corporation UEFI CA 2011	Linux Shim과 같은 서드 파티 부트로더에 서명	2026년 6월 27일
Microsoft Windows Production PCA 2011	Windows 부트로더에 서명합니다.	2026년 10월 19일
Microsoft Corporation KEK CA 2011	DB 및 DBX를 업데이트하는 데 사용됩니다.	2026년 6월 24일

이 인증서 만료는 컴퓨팅 인스턴스가 다음 필수 기본 요건을 모두 충족하는 경우에만 영향을 미칩니다.

1. 생성 날짜: 2025년 11월 7일 (Compute Engine에서 UEFI 펌웨어의 기본 보안 부팅 인증서를 업데이트한 날짜) 이전에 컴퓨팅 인스턴스를 만들었으며 업데이트하지 않았습니다.
2. 보안 부팅 상태: 인스턴스에서 보안 부팅을 사용 설정했습니다. Google Cloud 보안 VM 인스턴스를 만들 때 기본적으로 보안 부팅이 사용 설정되지 않습니다.

2025년 11월 7일 이후에 생성된 인스턴스는 기본 인증서 세트를 사용하는 이미지를 사용하는 경우 펌웨어 변수에 업데이트된 인증서가 이미 포함되어 있습니다.

인스턴스가 두 가지 필수 요건을 모두 충족하지 않으면 인증서 만료가 영향을 미치지 않으므로 조치를 취하지 않아도 됩니다.

이 문서에서는 영향을 받는 인스턴스를 식별하고 필요한 업데이트를 실행하는 방법을 설명합니다.

Google Cloud 2025년 11월 7일에 새로운 인증서 출시를 완료했습니다. 이 날짜 당일 또는 이후에 기본 인증서 세트를 사용하는 이미지에서 생성된 인스턴스에는 NVRAM/펌웨어 변수 (db 및 KEK)에 업데이트된 인증서가 포함되어 있으며 추가 작업이 필요하지 않습니다. 하지만 이 날짜 이전 몇 주 동안 생성된 일부 인스턴스에도 새 인증서가 포함될 수 있습니다. 시스템이 최신 상태인지 확인하려면 이 문서의 확인 섹션에 있는 명령어를 사용하세요.

참고: 보안 부팅 인증서 만료는 다음에 영향을 미치지 않습니다.

• 보안 부팅이 사용 설정되지 않은 인스턴스 보안 비밀 실링에 vTPM 플랫폼 구성 등록 (특히 PCR7)을 사용하는 경우 보안 부팅이 사용 중지되어 있어도 UEFI 변수를 업데이트하거나 인스턴스를 다시 만들면 PCR7 측정값이 변경됩니다. 이러한 구성은 매우 드물지만 참고하세요.
• Container-Optimized OS (COS)를 실행하는 인스턴스
• 자체 보안 부팅 플랫폼 키 (PK) 또는 키 등록 키 (KEK)를 제공하는 인스턴스

2025년 11월 7일 이전에 생성되었으며 업데이트된 인증서가 없는 컴퓨팅 인스턴스의 경우 KEK 및 db 업데이트 가이드에 따라 인증서를 업데이트하세요. 어떤 이유로든 이 작업을 할 수 없는 경우 인스턴스를 다시 만드는 것이 좋습니다.

보안 부팅 인증서 만료가 보안 VM에 미치는 영향

사용 설정된 경우 보안 VM은 UEFI 펌웨어를 사용하여 보안 부팅을 적용합니다. UEFI 펌웨어는 부팅 시퀀스 바이너리의 서명을 확인하기 위해 신뢰할 수 있는 인증서 집합 (db 변수)을 유지합니다. 예를 들어 OS 업데이트로 인해 Microsoft UEFI CA 2023에서만 서명한 부트로더로 대체되고 컴퓨팅 인스턴스의 펌웨어에서 이 인증서의 기관을 신뢰하지 않는 경우 보안 부트 확인이 실패하고 보안 부트에서 부팅 프로세스를 중지합니다.

이 전환에 대한 자세한 내용은 Microsoft 및 기타 OS 공급업체의 안내를 참고하세요.

• Windows 보안 부트 인증서 만료 및 CA 업데이트 - Microsoft 지원
• 2026년 보안 부팅 인증서 변경사항: RHEL 환경 안내 - Red Hat 고객 포털

운영체제 영향

2025년 11월 7일 이전에 생성된 보안 VM 인스턴스에서 보안 부팅을 사용 설정한 경우 2023 인증서가 설치되어 있는지 확인하는 것이 좋습니다. 그렇지 않으면 Microsoft UEFI CA 2023 인증서로만 서명된 (2011 인증서로 이중 서명되지 않음) 부트 로더가 포함된 업데이트를 적용하면 컴퓨팅 인스턴스에 부팅 문제가 발생합니다. 아무 조치를 취하지 않으면 2023 인증서로만 서명된 바이너리가 포함된 향후 부트로더 또는 커널 업데이트를 적용하지 못할 수 있습니다. OS 공급업체는 당분간 2011년 및 2023년 인증서로 부트로더와 shim 업데이트에 이중 서명할 계획이므로 부팅 실패나 업데이트 차단이 즉시 발생하지는 않을 것으로 예상됩니다. 2025년 11월 7일 이전에 생성된 컴퓨팅 인스턴스: 인증서 업데이트를 적용하지 않은 경우 Windows 고객에게 시스템 이벤트 로그에 이벤트 ID 1801 ('보안 부트 CA/키를 업데이트해야 합니다')이 표시될 수 있습니다.

• Google 제공 공개 이미지: KEK 및 db 업데이트 가이드에 따라 DB 및 KEK 인증서를 업데이트합니다. 또는 2025년 11월 7일 이전에 생성된 장기 실행 VM은 다시 만드는 것이 좋습니다.

• 맞춤 또는 가져온 이미지: 대부분의 맞춤 또는 가져온 이미지는 기본 보안 부팅 인증서를 사용합니다. 이미지를 만들 때 db 또는 KEK 보안 부트 변수를 명시적으로 재정의하지 않은 경우 이미지는 기본 키 세트를 사용하며 이미지 수준에서 아무 작업도 필요하지 않습니다. 이러한 기본값을 사용하는 이미지에서 인스턴스를 만들면 Compute Engine에서 업데이트된 인증서를 자동으로 제공합니다.

  이미지 빌드 프로세스 중에 이미지 메타데이터에 맞춤 db 또는 KEK 보안 부팅 변수를 명시적으로 정의한 경우 (예: 기본 Microsoft 인증서와 함께 서드 파티 보안 공급업체의 인증서를 포함하기 위해)에만 조치를 취하면 됩니다. 맞춤 db 또는 KEK 변수를 지정하면 기본값이 완전히 재정의되고 시스템에서 기본 공개 키를 무시하므로 맞춤 변수에 업데이트된 'Microsoft UEFI CA 2023' 또는 2023 KEK 인증서가 없을 수 있습니다. 맞춤 이미지 구성에 이러한 업데이트된 인증서가 포함되지 않는 경우 이를 포함하도록 차폐 이미지를 다시 만들거나 업데이트해야 합니다. 자세한 내용은 커스텀 보안 VM 이미지 만들기를 참고하세요.

권장 조치

2025년 11월 7일 이전에 생성되고 보안 부트가 사용 설정된 컴퓨팅 인스턴스가 있는 경우 업데이트 경로를 계획하기 전에 다음 요구사항, 제한사항, 복잡한 요인을 검토하세요.

• 업데이트 전 요구사항:
  • 복구 키 액세스 확인: 인스턴스에서 FDE (Windows의 BitLocker 또는 Linux의 LUKS 포함)를 사용하는 경우 인증서를 업데이트하거나 인스턴스를 다시 만들기 전에 복구 키에 액세스할 수 있는지 확인해야 합니다. UEFI 변수를 수정하면 부팅 측정값이 변경되고 복구 메시지가 트리거됩니다.
  • vTPM 보안 비밀 관리: 인스턴스에서 보안 비밀 실링을 위해 vTPM 플랫폼 구성 등록 (특히 PCR7)을 사용하는 경우 액세스 권한이 영구적으로 손실되지 않도록 업데이트하기 전에 이러한 보안 비밀을 언실링하거나 백업해야 합니다.
• 복잡한 요인 및 경계:
  • 업데이트 순서 요구사항: CA 확인 실패 및 시스템 부팅 루프를 방지하려면 새 커널 또는 shim 업데이트를 적용하기 전에 새 db 및 KEK 인증서를 설치해야 합니다.
  • 펌웨어 롤백: 2025년 11월 7일 이전에 캡처된 기존 머신 이미지로 인스턴스를 복원하면 이전 펌웨어가 복원되고 2023년 인증서에 대한 신뢰가 삭제됩니다. 롤백하는 경우 인증서 업데이트를 다시 적용해야 합니다.

타임라인, 감사 단계, 이전 프로세스에 관한 자세한 내용은 다음 안내를 참고하세요.

특정 게스트 구성에 미치는 영향

인스턴스가 필수 기본 요건 (2025년 11월 7일 이전에 생성되었고 보안 부팅이 사용 설정됨)을 모두 충족하는 경우에만 인증서 만료가 각 구성에 미치는 영향을 이해하세요.

• vTPM PCR 비밀 봉인:
  • 영향을 미치는 경우: vTPM 플랫폼 구성 등록 (특히 PCR7)을 사용하여 복호화 키와 같은 보안 비밀을 봉인하는 경우
  • 영향: KEK 및 db 업데이트 가이드를 사용하거나 디스크 스냅샷에서 인스턴스를 다시 만들어 보안 부팅 인증서를 업데이트하면 UEFI 변수가 수정되어 다음 부팅 시 PCR7 측정값이 변경됩니다. 이 변경사항으로 인해 업데이트 전에 먼저 시크릿을 봉인 해제하거나 백업한 후 새 PCR7 값으로 다시 봉인하지 않으면 게스트 OS나 애플리케이션이 이러한 시크릿을 봉인 해제하거나 복호화할 수 없습니다.
  • 영향을 받지 않는 경우: 2025년 11월 7일 이후에 기본 인증서를 사용하는 이미지에서 VM을 만든 경우 인증서를 업데이트할 필요가 없으며 PCR7는 변경되지 않고 비밀 봉인이 정상적으로 작동합니다.
• BitLocker 또는 가상 보안 모드 (VSM)를 사용하는 Windows 컴퓨팅 인스턴스:
  • 영향을 미치는 경우: Windows VM이 BitLocker 전체 디스크 암호화 또는 VSM을 사용하는 경우. 둘 다 UEFI 보안 부트 및 PCR7를 신뢰하여 암호화 키를 봉인합니다.
  • 영향: UEFI 보안 부팅 인증서를 수정하거나 스냅샷에서 인스턴스를 다시 만들면 PCR7 부팅 측정이 변경됩니다. 후속 재부팅에서 BitLocker는 구성 변경사항을 감지하고 키를 자동으로 해제하지 못하며 복구 키를 요청하는 BitLocker 복구 화면으로 부팅됩니다.
  • 해결 방법: 인증서를 업데이트하거나 인스턴스를 이전하기 전에 BitLocker 복구 키를 사용할 수 있는지 확인해야 합니다. 그런 다음 Windows에서 db 및 KEK 업데이트의 안내를 따르세요.
  • 영향을 받지 않는 경우: 인증서 만료는 BitLocker 또는 VSM이 사용 설정되지 않은 Windows 인스턴스나 보안 부트가 사용 설정되지 않은 인스턴스에는 영향을 미치지 않습니다.
• FDE를 사용하는 Linux VM:
  • 영향을 미치는 경우: Linux 인스턴스에서 LUKS와 같은 FDE를 사용하는 경우, 여기서는 복호화 키를 vTPM PCR(특히 PCR7)에 봉인합니다.
  • 영향: 보안 부팅 인증서를 업데이트하거나 VM을 다시 만들면 PCR7이 변경되어 부팅 볼륨의 자동 복호화가 방지됩니다. 부팅 중에 시스템이 중지되고 복호화 비밀번호를 묻는 메시지가 표시됩니다.
  • 해결 방법: 업데이트를 실행하기 전에 복구 암호 또는 키가 있는지 확인합니다. 업데이트 전에 TPM에서 LUKS 키를 바인딩 해제하거나 봉인 해제하고 업데이트 완료 후 새 PCR7 값에 다시 바인딩하거나 다시 봉인합니다.
  • 영향을 받지 않는 경우: 인증서 만료는 FDE 또는 vTPM으로 봉인된 LUKS 복호화를 사용하지 않거나 보안 부트가 사용 설정되지 않은 Linux VM에는 영향을 미치지 않습니다.
• 2025년 11월 이전 머신 이미지로 롤백되는 인스턴스:
  • 영향을 미치는 경우: 2025년 11월 7일 이전에 보안 부트가 사용 설정된 상태로 캡처된 머신 이미지로 VM을 복원하거나 롤백하는 경우
  • 영향: 롤백된 인스턴스는 2023년 인증서가 없는 이전 UEFI 펌웨어 구성과 인증서 저장소를 복원합니다. 이렇게 하면 후속 부트로더 업데이트 후 인스턴스가 향후 부팅 실패에 취약해지므로 인증서 업데이트를 다시 적용해야 합니다.
  • 영향을 받지 않는 경우: 보안 부팅을 사용 중지하거나 2025년 11월 7일 이후에 기본 인증서를 사용하는 이미지에서 머신 이미지를 만든 경우 머신 이미지로 롤백해도 인스턴스에 영향을 미치지 않습니다.

영향을 받는 컴퓨팅 인스턴스 식별 및 업데이트 계획

2026년 동안 영향을 받는 컴퓨팅 인스턴스를 식별하고 다음 단계에 따라 업데이트를 준비하는 것이 좋습니다.

1. 인스턴스 식별: gcloud compute instances list 명령어를 사용하여 보안 부팅이 사용 설정되어 있고 기준일 이전에 생성된 인스턴스를 식별할 수 있습니다.

   gcloud compute instances list \
   --filter="creationTimestamp < '2025-11-07' AND shieldedInstanceConfig.enableSecureBoot=true" \
   --format="table(name, zone, creationTimestamp, shieldedInstanceConfig.enableSecureBoot:label=SECURE_BOOT)"
   

2. 맞춤 변수 확인 (선택사항): 맞춤 이미지나 가져온 이미지를 사용하는 경우 맞춤 db 또는 KEK 보안 부팅 변수를 명시적으로 정의하는지 확인합니다 (기본값을 완전히 재정의함). 기본 인증서를 사용하는 경우 이미지 수준에서 조치가 필요하지 않습니다.

   • VM 인스턴스를 확인하려면 다음을 실행합니다.

     gcloud compute instances describe INSTANCE_NAME \
         --zone=ZONE \
         --format="yaml(shieldedInstanceInitialState)"
     

   • 소스 디스크 이미지를 확인하려면 다음을 실행합니다.

     gcloud compute images describe IMAGE_NAME \
         --format="yaml(shieldedInstanceInitialState)"
     

   출력이 비어 있거나 null를 반환하는 경우 인스턴스 또는 이미지가 기본 인증서를 사용하며 이미지 수준에서 조치가 필요하지 않습니다.

3. 데이터 무결성 보장: 변경을 진행하기 전에 최신 데이터 백업이 있고 FDE 또는 BitLocker 복구 키에 액세스할 수 있는지 확인합니다.

4. 인증서 업데이트: KEK 및 db 업데이트 가이드에 따라 DB 및 KEK 인증서를 업데이트합니다. 또는 디스크 스냅샷에서 컴퓨팅 인스턴스 다시 만들기의 안내에 따라 2025년 11월 7일 이후에 생성한 컴퓨팅 인스턴스로 마이그레이션합니다. 이 인스턴스에는 2023 인증서가 포함되어 있습니다 (새 인스턴스에서 기본 인증서를 사용하는 이미지를 사용하는 경우).

디스크 스냅샷에서 컴퓨팅 인스턴스 다시 만들기

디스크 스냅샷을 만들고 스냅샷에서 새 인스턴스를 만들면 새 컴퓨팅 인스턴스는 업데이트된 기본값을 신뢰하고 이전 인증서를 삭제하는 최신 펌웨어 (vTPM/NVRAM) 상태를 상속합니다.

스냅샷에서 컴퓨팅 인스턴스를 다시 만들기 전에 게스트 OS에 2023년 인증서를 신뢰하는 데 필요한 모든 업데이트 (예: Windows의 관련 Microsoft KB 또는 Linux 배포의 최신 Shim)가 설치되어 있는지 확인하세요.

다음 gcloud 명령어 시퀀스를 사용하여 이 이전을 관리할 수 있습니다.

1. 부팅 디스크 식별: 소스 컴퓨팅 인스턴스에 연결된 부팅 디스크의 이름을 확인합니다.

   SOURCE_DISK=$(gcloud compute instances describe SOURCE_INSTANCE_NAME \
       --zone=ZONE \
       --format="value(disks[0].source.basename())")
   

2. 디스크 스냅샷 만들기: 해당 부팅 디스크의 스냅샷을 만듭니다. 데이터 무결성을 최적화하려면 이 명령어를 실행하기 전에 컴퓨팅 인스턴스를 중지하세요.

   gcloud compute disks snapshot $SOURCE_DISK \
       --snapshot-names="migration-snapshot-$(date +%s)" \
       --zone=ZONE \
       --storage-location=REGION
   

3. 새 컴퓨팅 인스턴스 만들기: 스냅샷을 부팅 소스로 사용하여 새 컴퓨팅 인스턴스를 프로비저닝합니다. 소스 인스턴스에서 보안 부팅이 사용 설정된 경우 --shielded-secure-boot 플래그를 포함하여 새 인스턴스에서 보안 부팅을 사용 설정합니다.

   gcloud compute instances create NEW_INSTANCE_NAME \
       --zone=ZONE \
       --machine-type=MACHINE_TYPE \
       --create-disk=name=NEW_DISK_NAME,source-snapshot=SNAPSHOT_NAME,boot=yes \
       --shielded-secure-boot
   

참고: 이 방법을 사용하여 프로비저닝된 인스턴스는 고정적으로 할당되고 명시적으로 재할당되지 않는 한 새 내부 및 외부 IP 주소를 받습니다. 인스턴스 수준 메타데이터, 태그, 서비스 계정은 자동으로 복제되지 않으며 다시 생성하는 동안 명시적으로 구성해야 합니다.

인증

컴퓨팅 인스턴스의 펌웨어와 OS를 업데이트한 후 2023 인증서가 있는지 확인할 수 있습니다. KEK 및 db 변수 모두에 2023 인증서가 표시되면 인스턴스가 최신 상태이므로 추가 조치가 필요하지 않습니다.

Linux

efitools 패키지에서 efi-readvar 명령어를 사용하거나 (RHEL 8/9와 같이 efitools를 사용할 수 없는 배포판의 경우) mokutil를 사용하여 Linux에서 서명 데이터베이스를 확인할 수 있습니다.

방법 1: efi-readvar 사용

1. efi-readvar가 없으면 efitools 패키지를 설치합니다. Linux에 설치하려면 배포판에 맞는 명령어를 실행합니다.

   Debian/Ubuntu

   sudo apt update && sudo apt install efitools
   

   RHEL/CentOS/Fedora (Fedora만 해당, RHEL/CentOS 저장소에서는 efitools를 사용할 수 없음)

   sudo yum install efitools
   

   SLES

   sudo zypper install efitools
   

2. KEK 및 db 변수에서 인증서를 확인합니다.

   sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
   sudo efi-readvar -v db | grep "UEFI CA 2023"
   

방법 2: mokutil 사용

efitools를 사용할 수 없는 Red Hat Enterprise Linux (RHEL)와 같은 배포에서는 기본적으로 설치되는 mokutil 유틸리티를 사용합니다.

sudo mokutil --kek | grep "KEK 2K CA 2023"
sudo mokutil --db | grep "UEFI CA 2023"

Windows(PowerShell)

관리자 PowerShell 프롬프트에서 다음을 실행합니다. 각 명령어는 True을 반환해야 합니다.

# Check for Microsoft KEK 2K CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

# Check for UEFI CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'UEFI CA 2023'

# Confirm general Secure Boot enrollment state
Confirm-SecureBootUEFI

문제 해결

2026년 6월 이후에 보안 부팅 오류로 인해 인스턴스가 부팅되지 않으면 다음 옵션 중 하나를 사용하여 복구해 보세요.

• 보안 부팅을 일시적으로 사용 중지: 이렇게 하면 인스턴스를 부팅하여 업데이트를 적용할 수 있습니다.

  참고: 보안 부팅을 사용 중지하면 PCR 값(특히 PCR7)이 변경되어 비밀 봉인 또는 디스크 암호화 기능에 영향을 줄 수 있습니다.

  보안 부팅을 사용 중지하려면 다음 명령어를 실행합니다.

  gcloud compute instances update INSTANCE_NAME --no-shielded-secure-boot
  

  부트로더/shim에 필요한 업데이트를 적용한 후 보안 부팅을 다시 사용 설정합니다.

  gcloud compute instances update INSTANCE_NAME --shielded-secure-boot
  

• 백업에서 복원: 부팅 문제가 시작되기 전에 생성된 머신 이미지에서 인스턴스를 복원합니다.

• 인스턴스 다시 만들기: 인스턴스를 다시 만들고 스냅샷에서 데이터를 복구합니다.

문제가 계속되거나 도움이 필요한 경우 Cloud Customer Care에 문의하세요.

자주 묻는 질문(FAQ)

이 섹션에서는 Microsoft 보안 부팅 인증서 만료에 관한 일반적인 질문에 대한 답변을 제공합니다.

보안 부팅 인증서는 언제 만료되나요?

Microsoft의 보안 부팅 인증서가 2026년에 만료됩니다. 구체적으로는 다음과 같습니다.

• 지원 종료가 임박한 가장 중요한 두 인증서는 Linux Shim과 같은 서드 파티 부트로더에 서명하는 Microsoft Corporation UEFI CA 2011(2026년 6월 만료)과 Windows 부트로더에 서명하는 Microsoft Windows Production PCA 2011(2026년 10월 만료)입니다.

인증서 만료의 영향을 받는 사용자는 누구인가요?

이 인증서 만료는 컴퓨팅 인스턴스가 다음 필수 기본 요건을 모두 충족하는 경우에만 영향을 미칩니다.

1. 2025년 11월 7일(Compute Engine에서 UEFI 펌웨어의 기본 보안 부팅 인증서를 업데이트한 날짜) 전에 인스턴스를 만들었으며 업데이트하지 않았습니다.
2. 인스턴스에서 보안 부팅을 사용 설정했습니다.

2025년 11월 7일 이후에 생성하는 인스턴스는 기본 인증서 세트를 사용하는 이미지에서 생성하는 경우 영향을 받지 않습니다.

인스턴스가 두 필수 요소를 모두 충족하는 경우 특정 상황에서 인증서 만료가 다음 구성에 영향을 미칩니다.

• vTPM PCR 보안 비밀 실링: 인스턴스에서 가상 신뢰 플랫폼 모듈 (vTPM) 플랫폼 구성 등록 (특히 PCR7)을 사용하여 암호화 키 또는 보안 비밀을 실링하는 경우
• Windows BitLocker / VSM: Windows 인스턴스에서 보안 부팅과 함께 BitLocker 디스크 암호화 또는 가상 보안 모드 (VSM)를 사용하는 경우
• Linux FDE: Linux 인스턴스에서 vTPM PCR (특히 PCR7)에 봉인하는 FDE를 사용하는 경우
• 인스턴스 롤백: 2025년 11월 7일 이전에 생성한 머신 이미지로 VM을 복원하거나 롤백하는 경우

이러한 각 구성의 영향 및 수정 단계에 관한 자세한 내용은 특정 게스트 구성에 미치는 영향을 참고하세요.

인증서 만료의 영향을 받지 않는 사용자는 누구인가요?

다음 중 하나에 해당하는 경우 인증서 만료가 영향을 미치지 않습니다.

• 보안 부팅이 사용 중지됨: 보안 VM 인스턴스에서 보안 부팅이 사용 설정되어 있지 않으면 만료되는 UEFI 인증서를 검증하거나 사용하지 않습니다. 안전한 부팅은 기본적으로 사용 중지됩니다. 하지만 보안 비밀 실링에 vTPM 플랫폼 구성 등록(특히 PCR7)을 사용하는 경우 보안 부팅이 사용 중지되어 있어도 UEFI 변수를 업데이트하거나 인스턴스를 다시 만들면 PCR7 측정값이 변경됩니다. 이러한 구성은 매우 드물지만 참고하세요.
• 2025년 11월 7일 이후에 생성됨: 이 날짜 이후에 인스턴스를 생성했으므로 기본 인증서 세트를 사용하는 이미지에서 생성한 경우 펌웨어에 업데이트된 2023 인증서가 이미 포함되어 있습니다.
• Container-Optimized OS (COS) 실행: 이러한 인증서 업데이트는 COS 환경에 영향을 미치지 않습니다.
• 맞춤 PK, KEK 또는 db 변수: 기본 Microsoft UEFI 인증서를 사용하지 않고 자체 맞춤 보안 부팅 PK, KEK 또는 db 변수를 명시적으로 정의하고 관리하는 경우 기본 인증서의 만료가 영향을 미치지 않습니다. 하지만 자체 인증서를 업데이트하고 유지할 책임은 사용자에게 있습니다.

아무 조치도 취하지 않으면 어떻게 되나요?

아무 조치를 취하지 않으면 인스턴스가 기존 바이너리로 정상적으로 부팅되고 작동합니다. 하지만 2023년 인증서로만 서명된 바이너리가 포함된 향후 부트로더 또는 커널 업데이트는 적용하지 못할 수 있습니다. OS 공급업체는 2011년 및 2023년 인증서로 부트로더 및 shim 업데이트에 이중 서명하므로 부팅 실패 또는 업데이트 차단이 즉시 발생하지는 않습니다.

인증서를 업데이트하지 않으면 Windows 인스턴스가 부팅되지 않나요?

아니요. 수정하지 않아도 Windows 시스템 시작이 차단되지 않습니다. 하지만 시스템 이벤트 로그에 이벤트 ID 1801 ('보안 부트 CA/키를 업데이트해야 합니다')이 표시될 수 있으며, 새 2023 인증서로만 서명된 바이너리가 포함된 새 커널 또는 부트로더 보안 업데이트를 적용할 수 없습니다.

Linux에서 부팅 실패를 트리거하는 구체적인 조건은 무엇인가요?

특정 조건에서 Linux에서 부팅 실패가 발생할 수 있습니다.

• 인스턴스에 보안 부팅이 사용 설정되어 있습니다.
• 'Microsoft UEFI CA 2023' 인증서를 신뢰하도록 db UEFI 변수가 업데이트되지 않습니다.
• OS가 해당 인증서에만 엄격하게 의존하는 부트로더 (또는 shim)를 업데이트합니다 (2011 인증서로 이중 서명되지 않음).

새 인증서를 참조하는 인증서 업데이트나 shim 업데이트를 적용하지 않으면 Linux 인스턴스가 계속 정상적으로 부팅됩니다.

인스턴스에 업데이트된 인증서가 있는지 어떻게 알 수 있나요?

인스턴스의 펌웨어에 새 인증서가 포함되어 있는지 확인하려면 확인 섹션에 설명된 명령어를 참고하세요. 인증서가 누락된 경우 KEK 및 db 업데이트 가이드에 따라 업데이트하거나 인스턴스를 다시 만들면 됩니다.

영향을 받는 인스턴스를 다시 시작하거나 재부팅하면 문제가 해결되나요?

아니요. 컴퓨팅 인스턴스를 다시 시작하거나 재부팅해도 보안 부팅 인증서가 업데이트되지는 않지만, 인스턴스는 2023 인증서로만 서명된 바이너리가 포함된 부트 로더 또는 커널 업데이트가 적용될 때까지 기존 인증서로 정상적으로 부팅되고 작동합니다. 컴퓨팅 인스턴스를 다시 시작하면 원래 2025년 11월 7일 이전에 생성된 경우 이전 인증서가 유지됩니다. 인증서는 인스턴스의 펌웨어 (vTPM/NVRAM)의 일부입니다. 따라서 KEK 및 db 업데이트 가이드를 따르거나 인스턴스를 다시 만들어 새 인증서를 적용해야 합니다.

인증서 만료에 대비하려면 어떻게 해야 하나요?

준비하려면 다음 단계를 따르세요.

• 식별: 보안 VM, 보안 부트, FDE, BitLocker 또는 vTPM PCR을 사용하는 소프트웨어 사용 현황을 점검합니다.
• 복구 키 및 백업: 복구 키(FDE/BitLocker용)와 최신 데이터 백업을 즉시 사용할 수 있는지 확인합니다.
• 이미지 관리: 기존 맞춤 이미지를 식별하여 사용을 중단하거나 새 인증서가 포함되도록 합니다.
• 업데이트 또는 이전: 인증서를 업데이트하려면 KEK 및 db 업데이트 가이드를 참고하세요. 또는 2025년 11월 7일 이전에 생성한 장기 실행 컴퓨팅 인스턴스를 다시 만드는 것이 좋습니다. 새 인스턴스에는 필요한 인증서가 이미 포함되어 있기 때문입니다 (기본 인증서를 사용하는 이미지에서 새 인스턴스를 만드는 경우).

영향을 받는 인스턴스를 다시 만들거나 마이그레이션하는 데 권장되는 방법은 무엇인가요?

표준 디스크 스냅샷이 가장 안정적인 방법을 제공합니다. 스냅샷은 디스크의 블록 수준 복사본이며 UEFI 변수나 인스턴스 수준 메타데이터를 포함하지 않습니다. 스냅샷을 사용하여 복원하려면 다음 단계를 따르세요.

1. 인스턴스의 부팅 디스크 스냅샷을 만듭니다.
2. 새 컴퓨팅 인스턴스를 만들고 스냅샷을 부팅 디스크의 소스로 선택합니다.

이 마이그레이션에는 머신 이미지, 인스턴스 클로닝 또는 백업 및 DR 서비스를 사용하면 안 됩니다. 이러한 방법은 인스턴스 펌웨어를 복제하고 2025년 11월 7일 전에 생성된 소스 컴퓨팅 인스턴스의 이전 인증서를 유지하기 때문입니다.

2026년 6월 이후 시스템 부팅이 중지되면 어떻게 해야 하나요?

이 문제로 인해 부팅이 실패했다고 생각되면 문제 해결을 참고하세요.

Google Cloud 에서는 Microsoft 보안 부트 인증서 만료를 어떻게 처리하나요?

Google Cloud 는 2025년 11월 7일 이후에 생성된 컴퓨팅 인스턴스에 새 인증서를 자동으로 포함했습니다. 2025년 11월 7일 이전에 생성된 컴퓨팅 인스턴스를 계속 실행하려는 고객만 향후 업데이트를 적용하면 됩니다. 하지만 2025년 11월 7일 이후에 생성된 인스턴스 (기본 인증서 사용)로 이전하는 것이 좋습니다.

다음 단계

• 보안 VM에 대해 자세히 알아보세요.
• 보안 VM 옵션을 수정하는 방법을 알아보세요.
• 보안 부트에 대해 자세히 알아보세요.