패치를 사용하여 Compute Engine VM 인스턴스(VM) 조합에 운영체제 패치를 적용합니다. 장기 실행 VM의 경우 결함 및 취약점으로부터 보호를 위해 정기적으로 시스템을 업데이트해야 합니다.
패치 기능에는 두 가지 주요 구성요소가 있습니다.
- Windows 및 Linux 배포판에서 VM 인스턴스의 패치 상태에 대한 통계를 제공하는 패치 규정 준수 보고 통계와 함께 VM 인스턴스에 대한 권장사항도 볼 수 있습니다.
- 운영체제 및 소프트웨어 패치 업데이트 프로세스를 자동화하는 패치 배포 패치 배포는 패치 작업을 예약합니다. 패치 작업은 VM 인스턴스에서 실행되며 패치를 적용합니다.
혜택
패치 서비스를 사용하면 다음 프로세스를 유연하게 수행할 수 있습니다.
- 패치 승인을 만듭니다. 특정 운영체제에 사용할 수 있는 전체 업데이트 조합에서 시스템에 적용할 패치를 선택할 수 있습니다.
- 유연한 예약을 설정합니다. 패치 업데이트를 실행할 시기(일회성 및 반복 일정)를 선택할 수 있습니다.
- 고급 패치 구성 설정을 적용합니다. 패치 전후 스크립트와 같은 구성을 추가하여 패치를 맞춤설정할 수 있습니다.
- 중앙 위치에서 이러한 패치 작업 또는 업데이트를 관리합니다. 패치 작업과 규정 준수 상태의 모니터링 및 보고에 패치 대시보드를 사용할 수 있습니다.
가격 책정
가격 책정에 대한 자세한 내용은 VM Manager 가격 책정을 참조하세요.
패치 작동 방식
패치 기능을 사용하려면 OS Config API를 설정하고 OS 구성 에이전트를 설치해야 합니다. 자세한 안내는 VM Manager 설정을 참조하세요. OS 구성 서비스를 사용하면 OS 구성 에이전트가 각 운영체제의 업데이트 메커니즘을 사용하여 패치를 적용하는 동안 사용자 환경에서 패치를 관리할 수 있습니다. 업데이트는 패키지 저장소(배포 소스 패키지라고도 함) 또는 운영체제의 로컬 저장소에서 가져옵니다.
다음 업데이트 도구는 패치를 적용하는 데 사용됩니다.
- Red Hat Enterprise Linux(RHEL), Rocky Linux and CentOS -
yum upgrade - Debian 및 Ubuntu -
apt upgrade - SLES(SUSE Linux Enterprise Server) -
zypper update - Windows - Windows 업데이트 에이전트
패치 및 패키지 소스
VM Manager에서 패치 기능을 사용하려면 VM이 패키지 업데이트 또는 패치에 액세스할 수 있어야 합니다. 패치 서비스는 패키지 업데이트 또는 패치를 호스팅하거나 유지보수하지 않습니다. 일부 경우에는 VM이 업데이트에 액세스하지 못할 수 있습니다. 예를 들어 VM이 공개 IP를 사용하지 않거나 비공개 VPC 네트워크가 사용될 수 있습니다. 이러한 시나리오에서는 업데이트 또는 패치에 액세스할 수 있도록 추가 단계를 완료해야 합니다. 다음 옵션을 고려하세요.
- 패치 기준을 완전히 제어할 수 있도록 자체 로컬 저장소 또는 WSUS(Windows Server Update Service)를 호스팅하는 것이 좋습니다.
- 또는 Cloud NAT나 다른 프록시 서비스를 사용하여 VM에 외부 업데이트 소스를 제공할 수 있습니다.
패치 관리는 패치 배포와 패치 규정 준수의 두 가지 서비스로 구성됩니다. 각 서비스는 다음 섹션에 설명되어 있습니다.
패치 배포 개요
패치 배포는 VM Manager API(OS Config API라고도 함)를 호출하여 시작됩니다. 이 작업은 Google Cloud Console, Google Cloud CLI 또는 직접 API 호출을 사용하여 수행할 수 있습니다. 그런 다음 VM Manager API가 대상 VM에서 실행 중인 OS 구성 에이전트에 패치를 시작하도록 알립니다.
OS 구성 에이전트는 각 배포에 사용할 수 있는 패치 관리 도구를 사용하여 각 VM에서 패치를 실행합니다. 예를 들어 Ubuntu VM은 apt 유틸리티 도구를 사용합니다. 유틸리티 도구는 운영체제의 배포 소스에서 업데이트(패치)를 가져옵니다. 패치가 진행되면 OS 구성 에이전트는 VM Manager API에 진행 상황을 보고합니다.
패치 규정 준수 개요
VM에서 VM Manager를 설정한 후 다음 작업이 VM에서 수행됩니다.
- OS 구성 에이전트는 10분마다 주기적으로 OS 인벤토리 데이터를 보고합니다.
- 패치 규정 준수 백엔드는 주기적으로 이 데이터를 읽고 OS 배포에서 가져온 패키지 메타데이터를 상호 참조하여 저장합니다.
- 그런 다음 Google Cloud 콘솔이 패치 규정 준수 데이터를 가져와 콘솔에 이 정보를 표시합니다.
패치 규정 준수 데이터가 생성되는 원리
패치 규정 준수 백엔드는 주기적으로 다음 작업을 완료합니다.
- VM의 OS 인벤토리 데이터에서 수집된 보고서를 읽습니다.
각 운영체제의 취약점 소스에서 분류 데이터를 스캔하고 이 데이터를 심각도를 기준으로 내림차순으로 정렬합니다.
다음 표에는 각 운영체제에 사용되는 취약점 소스가 요약되어 있습니다.
운영체제 취약점 소스 패키지 RHEL, CentOS https://access.redhat.com/security/data Debian https://security-tracker.debian.org/tracker Ubuntu https://launchpad.net/ubuntu-cve-tracker SLES 해당 없음 SLES에서는 패치 규정 준수 보고가 지원되지 않습니다.
Rocky Linux 해당 사항 없음 Rocky Linux에서는 패치 규정 준수 보고가 지원됩니다. 그러나 심각도에 따른 취약점 데이터 분류는 사용할 수 없습니다.
Windows Windows에서는 취약점 소스 패키지를 사용할 수 없습니다. 패치 규정 준수 백엔드는 Windows Update Agent API에서 분류 데이터를 가져옵니다.
취약점 소스에서 제공된 이러한 분류를 Google의 패치 규정 준수 상태에 매핑합니다.
다음 표에는 Google의 패치 규정 준수 상태를 생성하는 데 사용되는 매핑 시스템이 요약되어 있습니다.
배포 소스 카테고리 Google의 패치 규정 준수 상태 - 심각
- 긴급
- WINDOWS_CRITICAL_UPDATE
심각(빨간색) - 중요
- 높음
- WINDOWS_SECURITY_UPDATE
중요/보안(주황색) - 기타
기타(노란색) - 사용 가능한 업데이트 없음
최신 상태(녹색) 사용 가능한 업데이트 중 심각도가 가장 높은 데이터를 선택하여 Google Cloud 콘솔 대시보드 페이지에 표시합니다. VM 세부정보 페이지에서 VM에 사용 가능한 모든 업데이트의 전체 보고서를 확인할 수도 있습니다.
예를 들어 RHEL 7 VM의 OS 인벤토리 데이터 에 다음과 같은 패키지 데이터가 있는 경우:
- 패키지 이름: package1
- 설치된 버전: 1.4
- 버전 업데이트: 2.0
패치 규정 준수 백엔드는 소스 배포에서 분류 데이터를 스캔하고 다음 정보를 가져옵니다.
- 버전 1.5 => 중요, CVE-001 수정
- 버전 1.8 => 낮음, CVE-002 수정
- 버전 1.9 => 낮음, CVE-003 수정
그런 다음 Google Cloud Console 대시보드에서 이 RHEL 7 VM이 Critical 업데이트가 있는 VM 목록에 추가됩니다. 이 VM의 세부정보를 검토해 보면 3개의 CVE, CVE-001, CVE-002, CVE-003과 함께 Critical 업데이트 1개(버전 2.0)가 표시됩니다.
동시 패치
패치 작업을 시작할 때 서비스는 사용자가 제공한 인스턴스 필터를 사용하여 패치할 특정 인스턴스를 결정합니다. 인스턴스 필터를 사용하면 많은 인스턴스를 동시에 패치할 수 있습니다. 작업이 예약된 후 패치 작업이 환경 변화를 보고하기 시작할 때 이 필터링이 수행됩니다.
예약된 패치
패치를 필요할 때 실행하거나, 미리 예약하거나, 반복 일정으로 구성할 수 있습니다. 즉시 중지가 필요한 경우 진행 중인 패치 작업을 취소할 수도 있습니다.
지정된 실행 빈도와 기간의 패치 배포를 만들어 패치 유지보수 기간을 설정할 수 있습니다. 지정된 기간으로 패치 작업을 예약하면 패치 작업이 지정된 유지보수 기간을 벗어나 시작되지 않습니다.
특정 시점에 완료할 패치 배포를 만들어서 패치 설치 기한을 시행할 수도 있습니다. 이 날짜까지 대상 VM에 패치되지 않으면 예약된 배포가 이 날짜에 패치를 설치하기 시작합니다. VM이 이미 패치된 경우 패치 전 또는 패치 후 스크립트가 지정되거나 재부팅이 필요한 경우가 아니면 해당 VM에 대해 아무 작업도 수행되지 않습니다.
패치 작업에는 무엇이 포함되나요?
패치 작업이 VM에서 실행되면 운영체제에 따라 업데이트 조합이 적용됩니다. 특정 업데이트나 패키지를 대상으로 지정할 수 있습니다. Windows 운영체제의 경우 업데이트할 KB ID를 지정할 수 있습니다.
또한 특정 배포에 대해 표준 패키지로 설치된 Google 에이전트를 업데이트하도록 패치 작업을 사용할 수 있습니다. 사용 가능한 패키지를 쿼리하려면 해당 배포에 대해 업데이트 도구를 사용합니다. 예를 들어 Ubuntu 운영체제에 사용할 수 있는 Google 에이전트를 보려면 apt list --installed | grep -P 'google'를 실행합니다.
Windows
Windows 운영체제의 경우 다음 업데이트를 모두 적용하거나 일부를 선택할 수 있습니다.
- 정의 업데이트
- 드라이버 업데이트
- 기능 팩 업데이트
- 보안 업데이트
- 도구 업데이트
RHEL/Rocky/CentOS
Red Hat Enterprise Linux, Rocky Linux, CentOS 운영체제의 경우 다음 업데이트를 모두 적용하거나 일부를 선택할 수 있습니다.
- 시스템 업데이트
- 보안 업데이트
Debian/Ubuntu
Debian 및 Ubuntu 시스템의 경우 다음 업데이트를 모두 적용하거나 일부를 선택할 수 있습니다.
- 배포 업데이트
- 패키지 관리자 업데이트
SUSE
SUSE Enterprise Linux Server(SLES) 및 openSUSE 운영체제의 경우 다음 업데이트를 모두 적용하거나 일부를 선택할 수 있습니다.
- 시스템 패키지 업데이트
- Zypper 패치(특정 버그 수정 및 보안 수정)
VM의 패치 요약 액세스
VM의 패치 요약을 보려면 다음 옵션을 사용합니다.
조직 또는 폴더의 모든 VM에 대한 패치 요약 정보를 보려면 Google Cloud 콘솔의 패치 대시보드를 사용합니다. VM의 패치 요약 보기를 참조하세요.
패치 작업 상태를 보려면 Google Cloud 콘솔의 패치 작업 페이지를 사용합니다. Google Cloud CLI 또는 OS Config API를 사용할 수도 있습니다. 자세한 내용은 패치 작업 관리를 참조하세요.
OS 패키지 업데이트 및 취약점 보고서와 같은 다른 정보를 보려면 운영체제 세부정보 보기를 참조하세요.
패치 대시보드
Google Cloud 콘솔에는 VM 인스턴스의 패치 규정 준수를 모니터링하는 데 사용할 수 있는 대시보드가 있습니다.
패치 대시보드 이해
운영체제 개요
이 섹션에는 총 VM 수가 운영체제별로 정리되어 반영됩니다. 이 목록에 VM이 표시되려면 OS 구성 에이전트가 설치되고 OS 인벤토리 관리가 사용 설정되어 있어야 합니다.
VM이 운영체제와 함께 No data로 나열되는 경우 다음 시나리오 중 하나에 해당될 수 있습니다.
- VM이 응답하지 않습니다.
- OS 구성 에이전트가 설치되어 있지 않습니다.
- OS 인벤토리 관리가 사용 설정되지 않았습니다.
운영체제가 지원되지 않습니다. 지원되는 운영체제 목록은 지원되는 운영체제를 참조하세요.
패치 규정 준수 상태
이 섹션에서는 운영체제별로 구성된 각 VM의 규정 준수 상태를 자세히 설명합니다.
규정 준수 상태는 다음과 같은 네 가지 주요 카테고리로 구성됩니다.
- 중요: VM에 사용 가능한 중요 업데이트가 있음을 의미합니다.
- 중요 또는 보안: VM에 사용 가능한 중요 업데이트나 보안 업데이트가 있음을 의미합니다.
- 기타: VM에 사용 가능한 업데이트가 있지만 중요 업데이트나 보안 업데이트로 분류되지 않습니다.
- 최신: VM에 사용 가능한 업데이트가 없습니다.