보안 부팅 인증서 업데이트: IT 전문가 및 조직을 위한 지침
적용 대상
원래 게시 날짜: 2025년 6월 26일
KB ID: 5062713
이 문서에는 다음 지침이 있습니다.
IT 관리 Windows 디바이스 및 업데이트를 사용하는 조직(엔터프라이즈, 중소기업 및 교육).
참고: 개인 Windows 디바이스를 소유한 개인인 경우 Microsoft 관리형 업데이트를 사용하여 가정용 사용자, 기업 및 학교용 Windows 디바이스 문서를 참조하세요.
|
변경 날짜 |
변경 설명 |
|---|---|
|
2025년 11월 10일 |
|
|
2025년 11월 11일 |
"보안 부팅 인증서 배포 지원" 에서 두 개의 오타를 수정했습니다.
|
이 문서에서는 다음을 수행합니다.
개요
이 문서는 디바이스 전체에서 업데이트를 적극적으로 관리하는 전담 IT 전문가가 있는 조직을 위한 것입니다. 이 문서의 대부분은 organization IT 부서가 새 보안 부팅 인증서를 성공적으로 배포하는 데 필요한 활동에 중점을 줍니다. 이러한 활동에는 펌웨어 테스트, 디바이스 업데이트 모니터링, 배포 시작 및 발생하는 문제 진단이 포함됩니다. 배포 및 모니터링의 여러 방법이 제공됩니다. 이러한 핵심 활동 외에도 특히 인증서 배포를 위해 CFR(제어 기능 롤아웃)에 참여하기 위해 클라이언트 디바이스를 옵트인하는 옵션을 포함하여 여러 배포 지원을 제공합니다.
섹션 내용
보안 부팅 인증서 만료
Microsoft에서 보안 부팅 인프라의 일부로 제공하는 인증서라고도 하는 CA(인증 기관)의 구성은 Windows 8 및 Windows Server 2012 이후로 동일하게 유지되었습니다. 이러한 인증서는 펌웨어의 DB(서명 데이터베이스) 및 KEK(키 교환 키) 변수에 저장됩니다. Microsoft는 디바이스의 펌웨어에 포함할 OEM(원래 장비 제조업체) 에코시스템에서 동일한 세 개의 인증서를 제공했습니다. 이러한 인증서는 Windows에서 보안 부팅을 지원하며 타사 OS(운영 체제)에서도 사용됩니다. Microsoft에서 제공하는 인증서는 다음과 같습니다.
-
Microsoft Corporation KEK CA 2011
-
Microsoft Windows Production PCA 2011
-
Microsoft Corporation UEFI CA 2011
중요: Microsoft에서 제공하는 세 가지 인증서는 모두 2026년 6월부터 만료되도록 설정됩니다. Microsoft는 에코시스템 파트너와 협력하여 향후 보안 부팅 보안 및 연속성을 보장하는 데 도움이 되는 새로운 인증서를 출시하고 있습니다. 이러한 2011 인증서가 만료되면 부팅 구성 요소에 대한 보안 업데이트가 더 이상 가능하지 않아 부팅 보안이 손상되고 영향을 받는 Windows 디바이스가 위험에 노출되고 보안 규정 준수가 중단됩니다. 보안 부팅 기능을 유지하려면 2011 인증서가 만료되기 전에 2023 인증서를 사용하도록 모든 Windows 디바이스를 업데이트해야 합니다.
변경 내용
현재 Microsoft 보안 부팅 인증서(Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011)는 2026년 6월부터 만료되며 2026년 10월까지 만료됩니다.
보안 부팅 보안 및 연속성을 유지하기 위해 새로운 2023 인증서가 출시되고 있습니다. 디바이스는 2011 인증서가 만료되기 전에 2023 인증서로 업데이트해야 합니다. 그렇지 않으면 보안 규정 준수가 중단되고 위험에 처하게 됩니다.
2012년부터 제조된 Windows 디바이스에는 업데이트해야 하는 만료된 버전의 인증서가 있을 수 있습니다.
용어
|
CA |
인증 기관 |
|
PK |
플랫폼 키 – OEM에 의해 제어됨 |
|
KEK |
키 교환 키 |
|
DB |
보안 부팅 서명 데이터베이스 |
|
DBX |
보안 부팅 해지된 서명 데이터베이스 |
인증서
|
인증서 만료 |
만료 날짜 |
위치 저장 |
새 인증서 |
용도 |
|---|---|---|---|---|
|
Microsoft Corporation KEK CA 2011 |
2026년 6월 |
KEK에 저장됨 |
Microsoft Corporation KEK 2K CA 2023 |
DB 및 DBX에 대한 업데이트에 서명합니다. |
|
Microsoft Windows Production PCA 2011 |
2026년 10월 |
DB에 저장됨 |
Windows UEFI CA 2023 |
Windows 부팅 로더에 서명합니다. |
|
Microsoft Corporation UEFI CA 2011*† |
2026년 6월 |
DB에 저장됨 |
Microsoft UEFI CA 2023 Microsoft Option ROM UEFI CA 2023 |
타사 부팅 로더 및 EFI 애플리케이션에 서명합니다. 타사 옵션 ROM에 서명합니다. |
*Microsoft Corporation UEFI CA 2011 인증서를 갱신하는 동안 ROM 서명 옵션에서 부팅 로더 서명을 분리하기 위해 두 개의 인증서가 만들어집니다. 이렇게 하면 시스템 트러스트를 더 세밀하게 제어할 수 있습니다. 예를 들어 옵션 ROM을 신뢰해야 하는 시스템은 타사 부팅 로더에 대한 신뢰를 추가하지 않고 Microsoft Option ROM UEFI CA 2023을 추가할 수 있습니다.
† 모든 디바이스에 펌웨어에 Microsoft Corporation UEFI CA 2011이 포함된 것은 아닙니다. 이 인증서를 포함하는 디바이스에 대해서만 새 인증서인 Microsoft UEFI CA 2023 및 Microsoft Option ROM UEFI CA 2023을 모두 적용하는 것이 좋습니다. 그렇지 않으면 이러한 두 개의 새 인증서를 적용할 필요가 없습니다.
IT 전문가를 위한 배포 플레이북
준비, 모니터링, 배포 및 수정을 통해 디바이스 플릿에서 보안 부팅 인증서 업데이트를 계획하고 수행합니다.
섹션 내용
전체에서 보안 부팅 상태 확인: 보안 부팅을 사용할 수 있나요?
2012년 이후 제조된 대부분의 디바이스는 보안 부팅을 지원하며 보안 부팅을 사용하도록 설정된 상태로 제공됩니다. 디바이스에 보안 부팅이 사용하도록 설정되어 있는지 확인하려면 다음 중 하나를 수행합니다.
-
GUI 메서드: 시작 > 설정 > 개인 정보 보호 & 보안 > Windows 보안 >디바이스 보안으로 이동합니다. 디바이스 보안에서 보안 부팅 섹션은 보안 부팅이 사용 중임을 나타내야 합니다.
-
명령줄 메서드: PowerShell의 관리자 권한 명령 프롬프트에서 Confirm-SecureBootUEFI를 입력한 다음 Enter 키를 누릅니다. 명령은 보안 부팅이 설정되어 있음을 나타내는 True를 반환해야 합니다.
디바이스를 대규모로 배포할 때 IT 전문가가 사용하는 관리 소프트웨어는 보안 부팅을 위한 검사 제공해야 합니다.
예를 들어 Microsoft Intune 관리 디바이스에서 보안 부팅 상태를 검사 방법은 Intune 사용자 지정 규정 준수 스크립트를 만들고 배포하는 것입니다. Intune 규정 준수 설정은 Microsoft Intune Linux 및 Windows 디바이스에 대한 사용자 지정 규정 준수 설정 사용에서 다룹니다.
보안 부팅이 사용하도록 설정된 경우 검사 Powershell 스크립트 예제:
# 보안 부팅 상태를 확인하기 위한 준비로 결과 개체 초기화
$result = [PSCustomObject]@{
SecureBootEnabled = $null
}
try {
$result. SecureBootEnabled = Confirm-SecureBootUEFI -ErrorAction 중지
Write-Verbose "보안 부팅 사용: $($result. SecureBootEnabled)"
} catch {
$result. SecureBootEnabled = $null
Write-Warning "보안 부팅 상태 확인할 수 없음: $_"
}
보안 부팅을 사용하도록 설정하지 않은 경우 해당되지 않으므로 아래의 업데이트 단계를 건너뛸 수 있습니다.
업데이트 배포 방법
보안 부팅 인증서 업데이트에 대한 디바이스를 대상으로 지정하는 방법에는 여러 가지가 있습니다. 설정 및 이벤트를 포함한 배포 세부 정보는 이 문서의 뒷부분에서 설명합니다. 업데이트를 위해 디바이스를 대상으로 지정하면 디바이스에서 새 인증서를 적용하는 프로세스를 시작해야 함을 나타내는 설정이 디바이스에 설정됩니다. 예약된 작업은 12시간마다 디바이스에서 실행되며 디바이스가 업데이트 대상임을 감지합니다. 태스크가 수행하는 작업에 대한 개요는 다음과 같습니다.
-
Windows UEFI CA 2023이 DB에 적용됩니다.
-
디바이스에 DB에 Microsoft Corporation UEFI CA 2011이 있는 경우 작업은 Microsoft Option ROM UEFI CA 2023 및 Microsoft UEFI CA 2023을 DB에 적용합니다.
-
그런 다음 Microsoft Corporation KEK 2K CA 2023을 추가합니다.
-
마지막으로 예약된 작업은 Windows 부팅 관리자를 Windows UEFI CA 2023에서 서명한 작업으로 업데이트합니다. Windows는 부팅 관리자를 적용하기 전에 다시 시작이 필요하다는 것을 감지합니다. 부팅 관리자 업데이트는 다시 시작이 자연스럽게 발생할 때까지 지연됩니다(예: 월별 업데이트가 적용되는 경우). 그런 다음 Windows에서 부팅 관리자 업데이트를 다시 적용하려고 시도합니다.
예약된 작업이 다음 단계로 이동하기 전에 위의 각 단계를 성공적으로 완료해야 합니다. 이 프로세스 동안 이벤트 로그 및 기타 상태 배포 모니터링에 도움이 될 수 있습니다. 모니터링 및 이벤트 로그에 대한 자세한 내용은 아래에 나와 있습니다.
보안 부팅 인증서를 업데이트하면 향후 2023 부팅 관리자를 더 안전하게 업데이트할 수 있습니다. 부팅 관리자에 대한 특정 업데이트는 향후 릴리스에서 제공됩니다.
배포 단계
-
준비: 인벤토리 및 테스트 디바이스.
-
펌웨어 고려 사항
-
모니터링: 모니터링이 작동하는지 확인하고 함대를 기준으로 합니다.
-
배포: 작은 하위 집합으로 시작하고 성공적인 테스트에 따라 확장하는 업데이트를 위한 디바이스를 대상으로 합니다.
-
수정: 로그 및 공급업체 지원을 사용하여 문제를 조사하고 resolve.
준비
인벤토리 하드웨어 및 펌웨어. 시스템 제조업체, 시스템 모델, BIOS 버전/날짜, BaseBoard 제품 버전 등을 기반으로 하는 대표적인 디바이스 샘플을 빌드하고 광범위한 배포 전에 해당 디바이스에서 업데이트를 테스트합니다. 이러한 매개 변수는 일반적으로 시스템 정보(MSINFO32)에서 사용할 수 있습니다. 포함된 샘플 PowerShell 명령을 사용하여 보안 부팅 업데이트 상태 검사 organization 디바이스를 인벤토리합니다.
참고: 보안 부팅 상태가 사용하도록 설정된 경우 이러한 명령이 적용됩니다.
참고: 이러한 명령의 대부분은 작동하려면 관리자 권한이 필요합니다.
샘플 보안 부팅 인벤토리 데이터 수집 스크립트
이 샘플 스크립트를 복사하여 붙여넣고 사용자 환경에 필요한 대로 수정합니다. 샘플 보안 부팅 인벤토리 데이터 수집 스크립트입니다.
보안 부팅을 사용하는 경우 첫 번째 단계는 최근에 업데이트된 보류 중인 이벤트가 있거나 보안 부팅 인증서를 업데이트하는 과정에서 검사 것입니다. 특히 관심은 1801 년과 1808 년에 가장 최근의 이벤트입니다.
이러한 이벤트는 보안 부팅 DB 및 DBX 변수 업데이트 이벤트에 자세히 설명되어 있습니다. 또한 이벤트가 보류 중인 업데이트의 상태를 표시할 수 있는 방법에 대한 모니터링 및 배포 섹션을 검사.
보류 중인 이벤트 1801 및 1808의 가장 최근 상태 다음 샘플 PowerShell 명령으로 캡처할 수 있습니다.
보안 부팅을 사용하는 #If 기존 로그 집계 도구(예: Splunk)를 사용하거나 다음과 같은 명령을 통해 직접 디바이스에서 이벤트 1801을 끌어오는 것이 좋습니다.
# 1. 먼저 명령을 실행하여 사용할 관련 이벤트를 가져옵니다.
$allEventIds = @(1801,1808)
$events = @(Get-WinEvent -FilterHashtable @{LogName='System'; ID=$allEventIds} -MaxEvents 20 -ErrorAction SilentlyContinue)
# 2. 가장 최근 1801 이벤트 가져오기
$latest_1801_Event = $events | {$_를 Where-Object. Id -eq 1801} | Sort-Object TimeCreated -Descending | Select-Object -First 1
# 3. 가장 최근 1808 이벤트 가져오기
$latest_1808_Event = $events | {$_를 Where-Object. Id -eq 1808} | Sort-Object TimeCreated -Descending | Select-Object -First 1
# 4. 1801 이벤트 메시지 텍스트에서 신뢰도 추출
if ($latest_1801_Event) {
if ($latest_1801_Event.Message -match '(High Confidence|더 많은 데이터 필요|알 수 없음|일시 중지됨)') {
$confidence = $matches[1]
Write-Host "신뢰도: $confidence"
} else {
Write-Host "이벤트 1801이 발견되었지만 신뢰도 값이 예상 형식이 아님"
}
} else {
Write-Host "1801 이벤트를 찾을 수 없음"
}
값이 "높은 신뢰도"인 #If 레지스트리 키를 수정하여 업데이트를 시작할 수 있으며, 디바이스에서 이벤트 1808이 존재하여 성공이 비슷하게 결정됩니다. 디바이스에 1808 이벤트가 이미 있는 경우 CA는 이미 업데이트되었습니다. 인증서를 업데이트하여 확인한 후 "$latest_1808_Event" 값을 캡처하고 검사.
# 5. 이벤트 1808 확인(보안 부팅 CA 업데이트 성공 표시)
if ($latest_1808_Event) {
Write-Host "이벤트 1808 발견 - 보안 부팅 CA 인증서가 업데이트되었습니다."
Write-Host "이벤트 시간: $($latest_1808_Event.TimeCreated)"
# CA(보안 부팅 인증 기관) 업데이트가 성공적으로 완료되면 이벤트 1808이 기록됩니다.
} else {
Write-Host "1808 이벤트를 찾을 수 없음 - 보안 부팅 CA 인증서가 아직 업데이트되지 않았습니다."
}
다음 단계는 organization 디바이스를 인벤토리하는 것입니다. PowerShell 명령을 사용하여 다음 세부 정보를 수집하여 대표적인 샘플을 빌드합니다.
기본 식별자(2개 값)
1. HostName - $env: COMPUTERNAME
2. CollectionTime - Get-Date
레지스트리: 보안 부팅 기본 키(3개 값)
3. SecureBootEnabled - Confirm-SecureBootUEFI cmdlet 또는 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
4. HighConfidenceOptOut - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
5. AvailableUpdates - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
레지스트리: 서비스 키(3개 값)
6. UEFICA2023Status -HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
7. UEFICA2023Capable - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
8. UEFICA2023Error - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
레지스트리: 디바이스 특성(7개 값)
9. OEMManufacturerName - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes
10. OEMModelSystemFamily - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes
11. OEMModelNumber - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes
12. FirmwareVersion - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes
13. FirmwareReleaseDate - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes
14. OSArchitecture - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes
15. CanAttemptUpdateAfter - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes
이벤트 로그: 시스템 로그(5개 값)
16. LatestEventId - 최신 보안 부팅 이벤트
17. BucketID - 이벤트 1801/1808에서 추출됨
18. 신뢰도 - 이벤트 1801/1808에서 추출됨
19. Event1801Count - 이벤트 수
20. Event1808Count - 이벤트 수
WMI/CIM 쿼리(4개 값)
21. OSVersion - Get-CimInstance Win32_OperatingSystem
22. LastBootTime - Get-CimInstance Win32_OperatingSystem
23. BaseBoardManufacturer - Get-CimInstance Win32_BaseBoard
24. BaseBoardProduct - Get-CimInstance Win32_BaseBoard
25. (Get-CIMInstance Win32_ComputerSystem). 생산자
26. (Get-CIMInstance Win32_ComputerSystem). 모델
27. (Get-CIMInstance Win32_BIOS). Description + ", " + (Get-CIMInstance Win32_BIOS). ReleaseDate.ToString("MM/dd/yyyy")
28. (Get-CIMInstance Win32_BaseBoard). 제품
펌웨어 고려 사항
디바이스에 새 보안 부팅 인증서를 배포하려면 디바이스 펌웨어가 업데이트를 완료하는 데 중요한 역할을 해야 합니다. Microsoft는 대부분의 디바이스 펌웨어가 예상대로 수행될 것으로 예상하지만 새 인증서를 배포하기 전에 신중한 테스트가 필요합니다.
다음과 같은 고유한 기준에 따라 하드웨어 인벤토리를 검사하고 디바이스의 대표적인 작은 샘플을 빌드합니다.
-
Manufacturer
-
모델 번호
-
펌웨어 버전
-
OEM 베이스보드 버전 등
플릿의 디바이스에 광범위하게 배포하기 전에 대표적인 샘플 디바이스(제조업체, 모델, 펌웨어 버전과 같은 요인에 따라 정의됨)에서 인증서 업데이트를 테스트하여 업데이트가 성공적으로 처리되었는지 확인하는 것이 좋습니다. 각 고유 범주에 대해 테스트할 샘플 디바이스 수에 대한 권장 지침은 4개 이상입니다.
이렇게 하면 배포 프로세스에 대한 신뢰도를 구축하는 데 도움이 되며 광범위한 함대에 예기치 않은 영향을 방지하는 데 도움이 됩니다.
경우에 따라 보안 부팅 인증서를 성공적으로 업데이트하려면 펌웨어 업데이트가 필요할 수 있습니다. 이러한 경우 디바이스 OEM으로 확인하여 업데이트된 펌웨어를 사용할 수 있는지 확인하는 것이 좋습니다.
가상화된 환경의 Windows
가상 환경에서 실행되는 Windows의 경우 보안 부팅 펌웨어 변수에 새 인증서를 추가하는 두 가지 방법이 있습니다.
-
가상 환경(AWS, Azure, Hyper-V, VMware 등)의 작성자는 환경에 대한 업데이트를 제공하고 가상화된 펌웨어에 새 인증서를 포함할 수 있습니다. 이는 새로운 가상화된 디바이스에서 작동합니다.
-
VM에서 장기적으로 실행되는 Windows의 경우 가상화된 펌웨어가 보안 부팅 업데이트를 지원하는 경우 다른 장치와 마찬가지로 Windows를 통해 업데이트를 적용할 수 있습니다.
모니터링 및 배포
배포 전에 디바이스 모니터링을 시작하여 모니터링이 올바르게 작동하고 선단의 상태를 미리 파악할 수 있도록 하는 것이 좋습니다. 모니터링 옵션은 아래에 설명되어 있습니다.
Microsoft는 보안 부팅 인증서 업데이트를 배포하고 모니터링하는 여러 방법을 제공합니다.
자동화된 배포 지원
Microsoft는 두 가지 배포 지원을 제공합니다. 이러한 지원은 새 인증서를 함대에 배포하는 데 유용할 수 있습니다. 두 지원 모두 진단 데이터가 필요합니다.
-
신뢰도 버킷이 있는 누적 업데이트에 대한 옵션: Microsoft는 진단 데이터를 공유할 수 없는 시스템 및 조직에 혜택을 주기 위해 현재까지 공유된 진단 데이터를 기반으로 하는 월별 업데이트에 신뢰도가 높은 디바이스 그룹을 자동으로 포함할 수 있습니다. 이 단계에서는 진단 데이터를 사용하도록 설정할 필요가 없습니다.
-
진단 데이터를 공유할 수 있는 조직 및 시스템의 경우 디바이스가 인증서를 성공적으로 배포할 수 있다는 가시성과 확신을 Microsoft에 제공합니다. 진단 데이터 사용에 대한 자세한 내용은 organization Windows 진단 데이터 구성에서 확인할 수 있습니다. 각 고유한 디바이스에 대해 "버킷"을 만들고 있습니다(제조업체, 마더보드 버전, 펌웨어 제조업체, 펌웨어 버전 및 추가 데이터 요소를 포함하는 특성으로 정의됨). 각 버킷에 대해 여러 디바이스에 대한 성공 증거를 모니터링하고 있습니다. 충분한 성공적인 업데이트와 실패를 확인했으면 버킷을 "신뢰도 높음"으로 간주하고 해당 데이터를 월별 누적 업데이트에 포함합니다. 신뢰도가 높은 버킷의 디바이스에 월별 업데이트가 적용되면 Windows는 펌웨어의 UEFI 보안 부팅 변수에 인증서를 자동으로 적용합니다.
-
신뢰도가 높은 버킷에는 업데이트를 올바르게 처리하는 디바이스가 포함됩니다. 당연히 모든 디바이스가 진단 데이터를 제공하는 것은 아니며, 이렇게 하면 업데이트를 올바르게 처리하는 디바이스의 기능에 대한 Microsoft의 신뢰가 제한될 수 있습니다.
-
이 지원은 기본적으로 신뢰도가 높은 디바이스에 대해 사용하도록 설정되며 디바이스별 설정으로 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 향후 Windows 릴리스에서 공유될 예정입니다.
-
-
CFR(제어된 기능 롤아웃): 진단 데이터가 사용하도록 설정된 경우 Microsoft 관리형 배포를 위해 디바이스를 옵트인합니다.
-
제어된 CFR(기능 롤아웃)은 organization 플릿의 클라이언트 디바이스와 함께 사용할 수 있습니다. 이렇게 하려면 디바이스가 필요한 진단 데이터를 Microsoft로 보내고 디바이스가 디바이스에서 CFR을 허용하도록 옵트인한다는 신호를 보내야 합니다. 옵트인 방법에 대한 자세한 내용은 아래에 설명되어 있습니다.
-
Microsoft는 진단 데이터를 사용할 수 있고 디바이스가 CFR(제어 기능 롤아웃)에 참여하는 Windows 디바이스에서 이러한 새 인증서에 대한 업데이트 프로세스를 관리합니다. CFR은 새 인증서를 배포하는 데 도움이 될 수 있지만 조직은 CFR을 사용하여 함대를 수정할 수 없습니다. 자동화된 지원에서 다루지 않는 배포 방법 섹션의 이 문서에 설명된 단계를 따라야 합니다.
-
제한: CFR이 사용자 환경에서 작동하지 않을 수 있는 몇 가지 이유가 있습니다. 예시:
-
진단 데이터를 사용할 수 없거나 CFR 배포의 일부로 진단 데이터를 사용할 수 없습니다.
-
디바이스는 지원되는 클라이언트 버전의 Windows 11 없으며 ESU(확장 보안 업데이트)를 사용하는 Windows 10.
-
-
자동화된 지원에서 다루지 않는 배포 방법
환경에 맞는 메서드를 선택합니다. 동일한 디바이스에서 메서드를 혼합하지 않도록 합니다.
-
레지스트리 키: 배포를 제어하고 결과를 모니터링합니다.인증서 배포 동작을 제어하고 결과를 모니터링하는 데 사용할 수 있는 여러 레지스트리 키가 있습니다. 또한 위에서 설명한 배포 보조 기능을 옵트인 및 옵트아웃하는 두 가지 키가 있습니다. 레지스트리 키에 대한 자세한 내용은 보안 부팅용 레지스트리 키 업데이트 - IT 관리형 업데이트가 있는 Windows 디바이스를 참조하세요.
-
그룹 정책 개체(GPO): 설정을 관리하고 레지스트리 및 이벤트 로그를 통해 모니터링합니다.Microsoft는 향후 업데이트에서 그룹 정책 사용하여 보안 부팅 업데이트를 관리하기 위한 지원을 제공할 예정입니다. 그룹 정책 설정용이므로 레지스트리 키 및 이벤트 로그 항목 모니터링을 비롯한 대체 방법을 사용하여 디바이스 상태 모니터링해야 합니다.
-
WinCS(Windows 구성 시스템) CLI: 도메인에 가입된 클라이언트에 명령줄 도구를 사용합니다.도메인 관리자는 Windows OS 업데이트에 포함된 WinCS(Windows 구성 시스템)를 사용하여 도메인에 가입된 Windows 클라이언트 및 서버에 보안 부팅 업데이트를 배포할 수 있습니다. 보안 부팅 구성을 로컬로 쿼리하고 컴퓨터에 적용하기 위한 일련의 명령줄 유틸리티(기존 실행 파일 및 PowerShell 모듈 모두)로 구성됩니다. 자세한 내용은 보안 부팅을 위한 WinCS(Windows 구성 시스템) API를 참조하세요.
-
Microsoft Intune/Configuration Manager: PowerShell 스크립트를 배포합니다. CSP(구성 서비스 공급자)는 Intune 사용하여 배포할 수 있도록 향후 업데이트에서 제공됩니다.
이벤트 로그 모니터링
보안 부팅 인증서 업데이트를 배포하는 데 도움이 되는 두 가지 새로운 이벤트가 제공됩니다. 이러한 이벤트는 보안 부팅 DB 및 DBX 변수 업데이트 이벤트에 자세히 설명되어 있습니다.
-
이벤트 ID: 1801 이 이벤트는 업데이트된 인증서가 디바이스에 적용되지 않음을 나타내는 오류 이벤트입니다. 이 이벤트는 디바이스 특성을 포함하여 디바이스와 관련된 몇 가지 세부 정보를 제공하며, 이는 여전히 업데이트해야 하는 디바이스의 상관 관계를 지정하는 데 도움이 됩니다.
-
이벤트 ID: 1808 이 이벤트는 디바이스에 디바이스의 펌웨어에 적용되는 필수 새 보안 부팅 인증서가 있음을 나타내는 정보 이벤트입니다.
배포 전략
위험을 최소화하려면 보안 부팅 업데이트를 한 번에 배포하지 않고 단계적으로 배포합니다. 디바이스의 작은 하위 집합으로 시작하고 결과의 유효성을 검사한 다음, 추가 그룹으로 확장합니다. 디바이스의 하위 집합으로 시작하고 이러한 배포에 대한 확신을 얻으면 디바이스의 하위 집합을 추가하는 것이 좋습니다. 샘플 디바이스 및 organization 구조 등에 대한 테스트 결과를 포함하여 하위 집합에 들어가는 내용을 결정하는 데 여러 요소를 사용할 수 있습니다.
배포하는 디바이스에 대한 결정은 사용자에게 달려 있습니다. 몇 가지 가능한 전략이 여기에 나열되어 있습니다.
-
대규모 디바이스 플릿: 관리하는 가장 일반적인 디바이스에 대해 위에서 설명한 어시스트에 의존하여 시작합니다. 병렬로 organization 관리되는 덜 일반적인 디바이스에 집중합니다. 작은 샘플 디바이스를 테스트하고 테스트에 성공하면 동일한 유형의 나머지 디바이스에 배포합니다. 테스트에서 문제가 발생하는 경우 문제의 원인을 조사하고 수정 단계를 확인합니다. 또한 플릿에서 더 높은 가치를 가진 디바이스의 클래스를 고려하고 테스트 및 배포를 시작하여 해당 디바이스가 보호를 조기에 업데이트하도록 할 수 있습니다.
-
작은 함대, 큰 다양성 : 관리하는 함대에 개별 디바이스 테스트가 금지되는 다양한 머신이 포함된 경우, 특히 시장에서 일반적인 디바이스가 될 가능성이 있는 디바이스에 대해 위에서 설명한 두 가지 지원에 크게 의존하는 것이 좋습니다. 처음에는 일상적인 작업에 중요한 디바이스에 초점을 맞추고 테스트한 다음 배포합니다. 우선 순위가 높은 디바이스 목록을 계속 이동하고, 함대를 모니터링하는 동안 테스트 및 배포하여 지원이 나머지 디바이스에 도움이 되는지 확인합니다.
참고
-
오래된 디바이스, 특히 제조업체에서 더 이상 지원되지 않는 디바이스에 주의하세요. 펌웨어가 업데이트 작업을 올바르게 수행해야 하지만 일부는 그렇지 않을 수 있습니다. 펌웨어가 제대로 작동하지 않고 디바이스가 더 이상 지원되지 않는 경우 디바이스를 교체하여 차량 전체에서 보안 부팅 보호를 보장하는 것이 좋습니다.
-
지난 1~2년 동안 제조된 새 디바이스에는 이미 업데이트된 인증서가 있을 수 있지만 Windows UEFI CA 2023 서명 부팅 관리자가 시스템에 적용되지 않았을 수 있습니다. 이 부팅 관리자를 적용하는 것은 각 디바이스에 대한 배포의 중요한 마지막 단계입니다.
-
업데이트를 위해 디바이스를 선택한 후에는 업데이트가 완료되기까지 다소 시간이 걸릴 수 있습니다. 인증서가 적용될 48시간 및 하나 이상의 다시 시작을 예상합니다.
자주 묻는 질문(FAQ)
자주 묻는 질문은 보안 부팅 FAQ 문서를 참조하세요.
문제 해결
섹션 내용
일반적인 문제 및 권장 사항
이 가이드에서는 보안 부팅 인증서 업데이트 프로세스의 작동 방식에 대해 자세히 설명하고 디바이스에 배포하는 동안 문제가 발생하는 경우 문제를 해결하는 몇 가지 단계를 제공합니다. 이 섹션에 업데이트 필요에 따라 추가됩니다.
보안 부팅 인증서 배포 지원
보안 부팅 인증서 업데이트를 지원하기 위해 Windows는 12시간마다 한 번씩 실행되는 예약된 작업을 유지 관리합니다. 작업은 처리가 필요한 AvailableUpdates 레지스트리 키에서 비트를 찾습니다. 인증서를 배포하는 데 사용되는 관심 있는 비트는 다음 표에 있습니다. Order 열은 비트가 처리되는 순서를 나타냅니다.
|
순서 |
비트 설정 |
사용법 |
|---|---|---|
|
1 |
0x0040 |
이 비트는 예약된 작업에 Windows UEFI CA 2023 인증서를 보안 부팅 DB에 추가하도록 지시합니다. 이렇게 하면 Windows에서 이 인증서로 서명된 부팅 관리자를 신뢰할 수 있습니다. |
|
2 |
0x0800 |
이 비트는 예약된 작업에 Microsoft Option ROM UEFI CA 2023을 DB에 적용하도록 지시합니다. 0x4000 설정된 경우 예약된 작업은 DB를 검사 Microsoft Corporation UEFI CA 2011이 이미 DB에 있는 경우에만 Microsoft UEFI CA 2023을 적용합니다. |
|
3 |
0x1000 |
이 비트는 예약된 작업에 Microsoft UEFI CA 2023을 DB에 적용하도록 지시합니다. 0x4000 설정된 경우 예약된 작업은 DB를 검사 Microsoft Corporation UEFI CA 2011이 이미 DB에 있는 경우에만 Microsoft Option ROM UEFI CA 2023을 적용합니다. |
|
2 & 3 |
0x4000 |
이 비트는 DB에 Microsoft Corporation UEFI CA 2011이 이미 있는 경우 Microsoft UEFI CA 2023 및 Microsoft Option ROM UEFI CA 2023만 적용하도록 0x0800 및 0x1000 비트의 동작을 수정합니다. 디바이스의 보안 프로필이 동일하게 유지되도록 하기 위해 이 비트는 디바이스가 Microsoft Corporation UEFI CA 2011 인증서를 신뢰하는 경우에만 이러한 새 인증서를 적용합니다. 모든 Windows 디바이스가 이 인증서를 신뢰하는 것은 아닙니다. |
|
4 |
0x0004 |
이 비트는 예약된 작업에 디바이스의 PK(플랫폼 키)에서 서명한 키 교환 키를 찾도록 지시합니다. PK는 OEM에서 관리됩니다. OEM은 PK로 Microsoft KEK에 서명하고 누적 업데이트에 포함된 Microsoft에 전달합니다. |
|
5 |
0x0100 |
이 비트는 예약된 작업에 Windows UEFI CA 2023에서 서명한 부팅 관리자를 부팅 파티션에 적용하도록 지시합니다. 그러면 Microsoft Windows Production PCA 2011 서명된 부팅 관리자가 대체됩니다. |
각 비트는 위의 표에 지정된 순서대로 예약된 이벤트에 의해 처리됩니다.
비트를 통한 진행은 다음과 같습니다.
-
시작: 0x5944
-
0x0040 → 0x5904(Windows UEFI CA 2023을 성공적으로 적용)
-
0x0800 → 0x5104(필요한 경우 Microsoft 옵션 ROM UEFI CA 2023 적용)
-
0x1000 → 0x4104(필요한 경우 Microsoft UEFI CA 2023 적용)
-
0x0004 → 0x4100(Microsoft Corporation KEK 2K CA 2023 적용)
-
0x0100 → 0x4000(Windows UEFI CA 2023 서명 부팅 관리자 적용)
참고
-
비트와 연결된 작업이 성공적으로 완료되면 해당 비트가 AvailableUpdates 키에서 지워집니다.
-
이러한 작업 중 하나가 실패하면 이벤트가 기록되고 다음에 예약된 작업이 실행될 때 작업이 다시 시도됩니다.
-
비트 0x4000 설정되면 지워지지 않습니다. 다른 모든 비트가 처리되면 AvailableUpdates 레지스트리 키가 0x4000 설정됩니다.
문제 1: KEK 업데이트 실패: 디바이스는 인증서를 보안 부팅 DB로 업데이트하지만 보안 부팅 KEK에 새 키 교환 키 인증서를 배포한 후에는 진행되지 않습니다.
참고 현재 이 문제가 발생하면 이벤트 ID: 1796 이 기록됩니다(보안 부팅 DB 및 DBX 변수 업데이트 이벤트 참조). 이 특정 문제를 나타내기 위해 이후 릴리스에서 새 이벤트가 제공됩니다.
디바이스의 AvailableUpdates 레지스트리 키는 0x4104 설정되며 여러 번 다시 부팅하고 상당한 시간이 경과한 후에도 0x0004 비트를 지우지 않습니다.
문제는 디바이스에 대한 OEM의 PK에서 서명한 KEK가 없는 것일 수 있습니다. OEM은 디바이스에 대한 PK를 제어하며 새 Microsoft KEK 인증서에 서명하고 Microsoft에 반환하여 월별 누적 업데이트에 포함할 수 있도록 합니다.
이 오류가 발생하면 OEM과 검사 Windows 보안 부팅 키 만들기 및 관리 지침에 설명된 단계를 수행했는지 확인합니다.
문제 2: 펌웨어 오류: 인증서 업데이트를 적용할 때 인증서가 펌웨어에 전달되어 보안 부팅 DB 또는 KEK 변수에 적용됩니다. 경우에 따라 펌웨어가 오류를 반환합니다.
이 문제가 발생하면 보안 부팅은 이벤트 ID 1795를 기록합니다. 이 이벤트에 대한 자세한 내용은 보안 부팅 DB 및 DBX 변수 업데이트 이벤트를 참조하세요.
이 문제를 resolve 디바이스에 사용할 수 있는 펌웨어 업데이트가 있는지 확인하려면 OEM으로 확인하는 것이 좋습니다.
추가 리소스
팁: 이러한 추가 리소스를 책갈피로 지정합니다.
Microsoft 고객 지원 리소스
Microsoft 지원 문의하려면 다음을 참조하세요.
-
Microsoft 지원 다음 Windows를 클릭합니다.
-
비즈니스에 대한 지원을 클릭한 다음 만들기 를 클릭하여 새 지원 요청을 만듭니다.새 지원 요청을 만든 후에는 다음과 같이 표시됩니다.