확장 가능한 Windows 가상 머신 패치 관리

이 문서에서는 워크로드의 Windows VM(가상 머신)에서 운영 체제 업데이트를 운영하기 위한 권장 방법을 설명합니다. 권장 프로세스는 워크로드의 Windows VM에 대해 일관되고 확장 가능하며 관리되는 패치 관리 솔루션을 제공합니다. 이를 통해 프로덕션 환경으로 승격하기 전에 사전 프로덕션 환경에서 업데이트의 유효성을 검사할 수 있습니다.

효과적인 패치 관리는 업데이트를 설치하는 것 이상으로 확장됩니다. 패치 관리 전략에는 VM이 패치 관리 솔루션에 온보딩되고, 워크로드 표준에 따라 구성되고, 규정 준수를 위해 지속적으로 모니터링되도록 하기 위해 일관된 거버넌스가 필요합니다.

메모

이 문서에서는 Azure Virtual Machines를 중점적으로 다룹니다. Azure 업데이트 관리자 Azure Arc 지원 서버를 지원하지만 하이브리드 시나리오에는 추가 고려 사항이 포함되며 여기서는 다루지 않습니다.

Virtual Machine Scale Sets 대한 자세한 내용은 Azure Virtual Machine Scale Set 자동 OS 이미지 업그레이드를 참조하세요.

Azure 업데이트 관리자

Azure Windows VM에서 Windows OS 업데이트를 관리하는 데 권장되는 방법은 업데이트 관리자를 사용하는 것입니다. 이 서비스는 중앙 집중식 일정 및 규정 준수 보고와 VM에 대해 준비된 OS 업데이트 배포를 수행할 수 있는 기능을 제공합니다. Update Manager는 워크로드의 각 VM에 설치된 사이드카 Azure VM 확장을 통해 작동합니다. 업데이트 관리자는 패치 자체를 호스트하거나 배포하지 않습니다. 각 VM에서 네이티브 Windows 업데이트 에이전트(WUA)를 제어하고 활성화합니다.

업데이트 관리자는 워크로드 팀에게 사용자 환경에서 VM의 패치 상태를 중앙에서 볼 수 있게 해줍니다. 패치 대상 및 주기를 설정하고 주문형 패치 롤아웃을 사용하도록 설정할 수 있습니다.

Tip

Update Manager는 WUA API를 사용하여 Windows 업데이트를 설치합니다. 이러한 업데이트는 Windows 설정에서 사용하는 Windows 업데이트 오케스트레이터 워크플로를 무시하므로 설정>Windows 업데이트>업데이트 기록에 표시되지 않을 수 있습니다. 이 동작은 예상된 것입니다. 업데이트 설치를 확인하려면 Windows 이벤트 뷰어 WindowsUpdateClient 이벤트를 검토합니다.

Azure 리소스 조직

업데이트 관리자는 Azure 리소스가 아닙니다. 이를 사용자의 워크로드 구독에 배포하지 않습니다. Azure 포털에서 사용할 수 있으며 포털의 환경은 RBAC 기반 및 구독에 구애받지 않습니다. 유지 관리 구성, OS 패치 적용, 패치 시 및 워크로드의 VM에 대한 구성 연결을 Azure 리소스로 유지 관리합니다.

각 유지 관리 구성은 단일 일정을 가질 수 있으며 연결을 통해 여러 리소스를 대상으로 지정할 수 있습니다. 유지 관리 구성은 지역 리소스입니다. 단일 유지 관리 구성 및 연결 집합을 사용하여 동일한 지역 및 구독 내의 VM만 포함합니다. 이 방법을 사용하는 경우 모든 환경에 대해 별도의 유지 관리 구성 리소스가 있고 워크로드가 다중 리소스이거나 워크로드의 여러 부분에 대해 다른 업데이트 일정이 있는 경우 환경당 리소스가 두 개 이상 있을 수 있습니다.

해당 환경에 대한 워크로드 IaC의 일부로 유지 관리 구성 리소스를 유지 관리합니다. 이 방법을 사용하면 변경 제어 프로세스 및 안전한 배포 사례를 수행할 수 있으며 재해 복구 옵션을 제공합니다.

VM 요구 사항

Windows VM은 지원되는 사용자 지정 또는 Azure Marketplace 이미지를 사용해야 합니다. 원본에 관계없이 업데이트를 지원하도록 OS를 구성해야 합니다. 권장되는 방법은 필요한 OS 설정을 구성하는 VM의 IaC를 사용하는 것입니다. 특히 VM에 적어도 다음 설정이 있는지 확인합니다.

windowsConfiguration: {
  provisionVMAgent: true
  enableAutomaticUpdates: true

  patchSettings: {
    patchMode: 'AutomaticByPlatform'  // Turns off automatic updates in the OS; now platform triggers updates
    assessmentMode: 'AutomaticByPlatform' // Scans for missing updates every 24 hours

    automaticByPlatformSettings: {
      bypassPlatformSafetyChecksOnUserSchedule: true  // Allows Azure Update Management to honor defined schedules
      rebootSetting: 'IfRequired'  // Or 'Never' if required in your workload
    }
  }
}

Windows 게스트 에이전트는 Microsoft.CPlat.Core.WindowsPatchExtension라는 사이드카 확장을 설치합니다. 이 권한 있는 확장은 VM에서 실행되어 일정을 확인하고 구성을 업데이트합니다. 또한 네이티브 Windows OS 업데이트 API를 호출하여 업데이트를 수행합니다. 이 확장은 VM IaC의 일부로 정의하지 않습니다. 업데이트 관리자는 자동으로 설치하고 수명 주기를 유지 관리합니다.

WindowsPatchExtension 확장은 해당 컴퓨터에서 업데이트 원본 설정을 재정의하지 않습니다. 여전히 VM에 대한 업데이트 원본을 구성할 책임이 있습니다.

지원되는 원본에 대한 자세한 내용은 지원되는 업데이트 원본, 유형, Microsoft 애플리케이션 업데이트 및 비 Microsoft 업데이트를 참조하세요.

규정 준수 보고가 현재 데이터를 반영하도록 자동 평가를 사용하도록 설정합니다. 이 기능은 패치 기준과 관련하여 각 VM의 상태를 표시하고 다음 예약된 실행 전에 새로 공개된 노출을 강조 표시합니다. 평가는 실행 중인 VM만 다룹니다. 중지되거나 할당 취소된 VM은 검색되지 않습니다.

중요합니다

Update Manager는 네이티브 Windows OS 기능을 직접 호출하므로 OS 설정이 패치를 지원하도록 올바르게 구성된 상태로 유지하는 것이 중요합니다.

  • 그룹 정책, Microsoft Intune 또는 기타 구성 관리 도구가 업데이트 관리자가 VM에서 올바르게 작동하는 데 필요한 OS 설정을 재정의하지 않는지 확인합니다. 특정 구성 값은 Azure 업데이트 관리자 Windows 업데이트 설정 구성을 참조하세요.
  • OS 수준 방화벽은 업데이트 트래픽을 차단해서는 안 됩니다.

정책 적용

또한 워크로드는 Azure Policy 사용하여 VM이 업데이트 관리자에 대해 올바르게 구성되도록 해야 합니다. 기본 제공 Azure 업데이트 관리자 정책을 적용하여 구성 드리프트를 방지합니다. 기본 제공 정책은 DINE(deployIfNotExists)을 지원하고 비규격 VM을 자동으로 수정하도록 적용을 수정합니다.

패치 관리에 대한 정책 기반 접근 방식은 정책을 사용하여 Azure VM에서 주기적인 평가 및 예약된 패치 사용을 참조하세요. 워크로드가 IaC를 사용하여 VM을 배포하고 구성하지 않는 경우 이 방법을 사용합니다.

네트워킹 요구 사항

직접 아웃바운드 인터넷 액세스가 가능한 Azure VM의 경우, 게스트 OS 업데이트 소스, DNS, 프록시, TLS 검사 및 로컬 정책 설정에서 Windows 업데이트/Microsoft Update 트래픽을 허용하면 일반적으로 추가 네트워크 허용 목록 구성 없이 Windows 업데이트가 작동합니다. 그러나 대부분의 워크로드는 아웃바운드 액세스가 제한된 잠긴 가상 네트워크에서 작동합니다. 이러한 경우 송신하는 모든 네트워크 보안 그룹 및 방화벽에서 엔드포인트를 Microsoft 트래픽을 허용해야 합니다.

네트워크 보안 그룹

Windows 업데이트 포함한 기본 업데이트 원본은 DNS 기반이며 안정적인 고정 IP 목록을 게시하지 않습니다. 따라서 인터넷 호스팅 업데이트 원본의 경우 VM의 NIC 또는 해당 서브넷에 연결된 네트워크 보안 그룹은 TCP:443 및 TCP:80에 대한 인터넷 송신 트래픽을 지원해야 합니다. 출구 방화벽 내부에서의 접근을 추가로 제한해야 합니다. 업데이트가 고정 IP 주소 범위(예: 온-프레미스 원본)에서 제공되는 경우 네트워크 보안 그룹에서 해당 아웃바운드 대상을 명시적으로 정의해야 합니다.

아웃바운드 방화벽

아웃바운드 방화벽은 업데이트 소스에서 사용하는 FQDN으로의 트래픽을 허용해야 합니다. Azure Firewall 및 Microsoft 제공된 업데이트 원본을 사용하는 경우 WindowsUpdate FQDN 태그를 사용하여 Windows 업데이트 엔드포인트에 대한 아웃바운드 액세스를 허용합니다. 네트워크 경로에서 다른 송신 방화벽을 구성하는 방법에 대한 자세한 내용은 방화벽 구성을 참조하세요. 이 트래픽은 워크로드의 관련 없는 서브넷이 아닌 Windows VM에서 시작된 경우에만 허용해야 합니다.

VM을 유지 관리 구성과 연결

유지 관리 구성과 VM 간에 정적 연결을 만들 수 있지만 대신 동적 범위 지정을 사용합니다. 동적 범위는 리소스 그룹, 위치 및 태그와 같은 특성에 따라 유지 관리 구성과 연결된 VM을 결정합니다. 동적 범위가 아닌 유지 관리 구성은 설치된 업데이트와 설치 시기를 정의합니다. 동적 범위 지정을 사용하면 VM별 구성 연결 리소스를 관리하지 않고도 조건에 맞는 새 VM을 온보딩할 수 있습니다.

동적 범위 지정 규칙을 사용하는 경우 다음 권장 사항을 따릅니다.

  • 워크로드의 일부로 IaC에서 동적 범위 지정 규칙을 관리합니다.
  • 환경 간 종속성을 방지하려면 사용자 환경의 VM만 포함하고 필요에 따라 환경 간에 구성 및 동적 범위 지정 규칙을 복제합니다.
  • 태그를 연결의 기본 메커니즘으로 사용하고 Azure Policy 사용하여 사용을 적용합니다.

준비된 패치 일정 디자인

워크로드에 대한 일반적인 패치 일정은 준비된 배포 일정을 사용합니다. 월별 Microsoft 업데이트 릴리스 후 먼저 개발 및 테스트 VM에 업데이트를 적용합니다. 이러한 업데이트의 유효성을 검사한 후 업데이트의 동일한 분류를 사전 프로덕션으로 승격한 다음 별도의 유지 관리 기간으로 프로덕션을 승격합니다.

되풀이, 유지 관리 기간, 업데이트 분류 및 다시 부팅 동작을 정의하는 유지 관리 구성을 만듭니다. 그런 다음, 워크로드의 VM을 대상으로 하는 동적 범위 지정 연결을 만들어 일상적인 패치 일정을 수행합니다.

패치 화요일 정렬 일정은 일반적으로 프로덕션 배포 전에 유효성 검사를 위해 며칠을 허용합니다. Microsoft 월별 보안 업데이트는 일반적으로 매월 두 번째 화요일에 릴리스되기 때문에 제안된 접근 방식은 다음과 같습니다. 이 예제에서 대상 VM은 태그를 사용하는 동적 범위 지정 규칙을 통해 관리됩니다.

Environment 일정 VM 리소스 태그 업데이트 Reboot
발달 두 번째 화요일
2200-0000		 PatchGroup = Backend 또는 PatchGroup=Frontend 위험 + 보안 필요한 경우
Test 두 번째 수요일
2200-0000		 PatchGroup = Backend 또는 PatchGroup=Frontend 위험 + 보안 필요한 경우
프로덕션 백 엔드(웨이브 1) 두 번째 토요일
2200-0100		 PatchGroup=Backend 위험 + 보안 필요한 경우
프로덕션 프런트 엔드(웨이브 2) 다음 일요일
2200-0100		 PatchGroup=Frontend 위험 + 보안 필요한 경우

업데이트 동시성 처리

유지 관리 구성은 연결된 모든 VM에서 동시에 업데이트를 시작합니다. Azure 일반 가용성 집합의 VM에 대해서만 업데이트 도메인으로 재부팅을 직렬화합니다. 이 예제의 백 엔드 및 프런트 엔드 웨이브는 중복 용량이 아닌 계층별로 일정을 구분하므로 계층의 모든 인스턴스가 함께 다시 부팅되고 해당 계층이 필요한 용량 아래로 떨어질 수 있습니다.

각 프로덕션 계층 내에서 가용성 영역, 업데이트 도메인 또는 워크로드 정의 인스턴스 그룹에 맞는 용량 유지 웨이브로 패치를 분할합니다. 웨이브당 고유 태그 값 및 유지 관리 구성을 사용합니다.

롤아웃의 일관성을 고려하세요

업데이트 관리자는 각 실행 시 새 평가를 수행합니다. 따라서 분류 기반 일정은 이후 웨이브에서 다른 KB(기술 자료) 문서와 연결된 업데이트 패키지를 선택할 수 있습니다. 각 웨이브가 정확한 유효성을 검사한 업데이트 집합을 설치 해야 하는 경우 분류에만 의존하는 대신 명시적 KB 포함을 구성합니다.

Update Manager REST API를 사용하여 첫 번째 웨이브의 평가 결과를 쿼리한 다음 후속 웨이브에 대한 유지 관리 구성을 업데이트하여 이 구성을 자동화할 수 있습니다.

완전한 웨이브 일관성을 달성하기 위해 치러야 하는 대가는 오케스트레이션 복잡성이 크게 증가한다는 점입니다. 워크로드가 첫 번째 웨이브와 다른 업데이트 패키지를 설치하는 이후 웨이브의 위험을 허용할 수 있는 경우 분류 기반 일정을 사용합니다.

핫패치를 사용하여 다시 부팅 줄이기

재부팅은 종종 패치 일정에서 가장 파괴적인 부분입니다. 이전 표에서 유지 관리 기간 크기 및 다시 부팅 동작을 결정합니다. 지원되는 이미지에서 핫패칭은 실행 중인 프로세스의 메모리 내 코드를 패치하여 Windows 보안 업데이트를 설치하므로 대부분의 달에 대한 업데이트는 다시 시작하지 않고 적용됩니다. 핫패치는 Windows 업데이트 확장되므로 Update Manager는 다른 VM에 사용하는 것과 동일한 유지 관리 구성 및 동적 범위 지정을 사용하여 핫패치를 설치합니다.

워크로드가 다시 시작에 중요한 경우 핫패치를 지원하는 OS SKU 및 디자인을 채택합니다.

  • 핫패치는 특정 Windows 이미지에서만 사용할 수 있습니다. 임의의 사용자 지정 이미지에서는 핫패치를 사용하도록 설정할 수 없습니다.
  • Windows 보안 업데이트만 핫패치됩니다. 비보안 업데이트, .NET 업데이트 및 드라이버 또는 펌웨어 업데이트는 릴리스된 후 몇 달 동안 다시 부팅해야 합니다. 분기별 핫패치 기준선과 Microsoft에서 제로 데이 수정을 위해 배포하는 모든 계획되지 않은 기준선도 재부팅이 필요합니다. 다시 시작을 흡수할 수 있는 유지 관리 기간을 유지합니다.

"before" 및 "after" 문제 처리

Update Manager는 운영 체제 업데이트를 평가하고 설치하지만, 성공적인 패치 프로세스에는 필요한 재부팅 또는 애플리케이션 관련 문제를 정상적으로 처리하기 위한 유지 관리 기간 전후의 활동이 포함될 수 있습니다. Update Manager는 워크로드의 자동화에 사용할 수 있는 사전 이벤트 및 사후 이벤트를 제공합니다. Azure 함수와 같은 이벤트 처리기를 워크로드의 아키텍처에 추가합니다. 이벤트 처리기는 예약된 패치 실행 전후에 Azure Event Grid 알림에 응답합니다.

Update Manager 사전 패치 작업을 사용하여 다음과 같은 작업을 수행합니다.

  • 중지되거나 할당 취소된 VM을 시작합니다. 중지되거나 할당 취소된 VM은 패치할 수 없으며 건너뜁니다.
  • 백업 복구 지점을 사용할 수 있는지 확인합니다.
  • VM 및 애플리케이션 상태의 유효성을 검사합니다.
  • 유지 관리 기간 동안 오탐을 방지하기 위해 모니터링 경고를 일시적으로 억제하세요.

업데이트가 설치되면 패치 후 작업을 사용하여 다음과 같은 작업을 수행합니다.

  • 모니터링을 복원합니다.
  • 애플리케이션 및 서비스 상태 검사를 수행합니다.
  • Microsoft Teams 채널에 알림을 게시합니다.

Event Grid 및 이벤트 처리기 컴퓨팅을 워크로드 리소스로 처리합니다. IaC를 사용하여 배포하고 환경 간에 격리합니다.

주문형 업데이트 준비

Update Manager는 예약된 유지 관리 기간 외에 주문형 패치 설치를 지원합니다. 이 기능은 긴급 패치 또는 중요한 주기 외 수정을 적용하거나 더 광범위한 예약된 롤아웃 전에 단일 VM에서 패치 동작의 유효성을 검사하는 데 유용합니다. 하나 이상의 VM에 대해 Azure 포털 또는 Update Manager REST API에서 직접 주문형 업데이트를 트리거할 수 있습니다. 워크로드 팀은 대역 외 업데이트를 수행하는 시기와 해당 프로세스가 워크로드 전체에서 오케스트레이션되는 방법에 대한 지침을 설정해야 합니다.

업데이트 되돌리기

업데이트 관리자는 OS 패치 롤백을 제공하지 않습니다. 패치를 적용한 후에는 업데이트 관리자를 통해 패치를 직접 제거하는 기본 제공 메커니즘이 없습니다.

워크로드가 "마지막으로 알려진 정상" 상태를 지원해야 하는 경우 유지 관리 실행 전에 스냅샷 또는 복구 지점을 만듭니다. 패치가 적용되기 전에 복구 지점이 항상 존재하도록 각 패치 창 전에 실행되도록 스냅샷 만들기를 자동화합니다. 또는 패치 없이 VM을 다시 배포하고, 배포에서 문제가 있는 KB 패치를 제외하고, 업데이트를 다시 적용합니다.

중요합니다

프로덕션 환경에서 예약된 패치를 사용하도록 설정하기 전에 복구 전략을 계획합니다.

규정 준수 보고

업데이트 관리자는 7일 동안 보류 중인 업데이트와 30일 동안의 설치 결과를 저장하는 Azure Resource Graph 평가 및 패치 설치 결과를 모두 푸시합니다. 업데이트 관리자에는 환경 전체의 업데이트 상태에 대한 가시성을 제공하는 기본 제공 규정 준수 보고 및 관리 보기가 포함되어 있습니다. 관리자는 이러한 대시보드를 통해 패치 준수를 모니터링하고, 주의가 필요한 컴퓨터를 식별하고, 중앙 위치에서 업데이트 배포 진행률을 추적할 수 있습니다.

미리 정의된 통합 문서는 워크로드 전반에 걸쳐 주요 정보를 보여 줍니다.

  • 컴퓨터 상태 및 구성의 전체 요약
  • 심각도 및 분류별 보류 중인 업데이트 분석
  • 일정, 유지 관리 구성 및 각 일정에 연결된 컴퓨터의 요약
  • 성공률 및 실패를 포함하여 이전 설치 실행에 대한 기록 보기

많은 조직에서는 애플리케이션 팀이 규정 준수 보고를 제공하도록 요구합니다. 이상적으로는 업데이트 관리자 포털 환경 및 통합 문서가 구독 경계를 넘어 작동할 수 있으며 워크로드에서 사용자 지정 패치 상태 보고를 제공할 필요가 없으므로 조직에서 해당 추적을 위해 업데이트 관리자를 이미 사용하고 있습니다.

사용자 또는 조직에서 미리 정의된 보기 이외의 사용자 지정 보고가 필요한 경우 통합 문서를 사용자 지정할 수 있습니다. 워크로드의 IaC 파일에 사용자 지정된 통합 문서를 포함하여 변경 제어 프로세스를 적용하고 재해 복구 옵션을 제공합니다. 대안은 Resource Graph 쿼리를 통해 필요한 규정 준수 보고 데이터를 제공하는 것입니다.

워크로드가 Resource Graph가 유지하는 것보다 더 오랜 시간 동안 패치 기록을 유지해야 하는 경우 제어하는 저장소로 데이터를 내보내는 프로세스를 빌드합니다.

대체 방법

워크로드에 대해 예약된 미리 구성된 업데이트 관리자 접근 방식을 채택하지 않기로 결정한 경우 사용자 지정 솔루션을 디자인하기 전에 자동 VM 게스트 패치를 평가합니다. 이 옵션을 사용하는 경우 Azure 패치를 오케스트레이션합니다. 그러나 이 방법을 사용하는 경우 다음과 같은 이점을 포기합니다.

  • 단계적 출시 업데이트는 개발, 테스트 및 프로덕션 웨이브를 통해 승격되지 않으므로 유효성 검사 게이트가 손실됩니다.
  • 유지 관리 기간 제어. Azure 각 VM의 표준 시간대에서 사용량이 많은 시간 동안 패치가 실행되는 시기를 결정합니다.
  • 분류 제어를 업데이트합니다. 중요 및 보안 업데이트만 적용됩니다. 다른 업데이트는 자동으로 설치되지 않습니다.

기여자

Microsoft는 이 문서를 유지 관리합니다. 이 문서를 작성한 기여자는 다음과 같습니다.

대표 저자:

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계

  • Last updated on