• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.
# Patch Manager 작업 작동 방식
이 섹션에서는 AWS Systems Manager의 도구인 Patch Manager가 설치할 패치를 결정하는 방법 및 지원되는 각 운영 체제에 이러한 패치가 설치되는 방법에 대한 기술적인 정보를 제공합니다. Linux 운영 체제의 경우 관리형 노드에 구성된 기본 소스 리포지토리 이외의 패치를 위해 사용자 지정 패치 기준에서 소스 리포지토리를 지정하는 방법에 대한 정보도 제공합니다. 이 단원에서는 Linux 운영 체제의 서로 다른 배포에서 패치 기준 규칙이 작동하는 방법에 대해서도 설명합니다.
**참고**
다음 항목의 정보는 패치 작업에 사용하는 구성 방법 또는 유형에 관계없이 적용됩니다.
Quick Setup에서 구성된 패치 정책
Quick Setup에서 구성된 호스트 관리 옵션
패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
온디맨드 **Patch now**(지금 패치) 작업
**Topics**
+ [패키지 릴리스 날짜 및 업데이트 날짜 계산 방법](patch-manager-release-dates.md)
+ [보안 패치 선택 방법](patch-manager-selecting-patches.md)
+ [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md)
+ [패치 설치 방법](patch-manager-installing-patches.md)
+ [Linux 기반 시스템에서 패치 기준 규칙 사용 방법](patch-manager-linux-rules.md)
+ [Linux 및 Windows Server 간 패치 작업 차이점](patch-manager-windows-and-linux-differences.md)
# 패키지 릴리스 날짜 및 업데이트 날짜 계산 방법
**중요**
이 페이지의 정보는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스용 Amazon Linux 2 및 Amazon Linux 2023 운영 체제(OS)에 적용됩니다. Amazon Web Services에서 이러한 OS 유형에 대한 패키지를 생성하고 유지 관리합니다. 다른 운영 체제의 제조업체가 패키지와 리포지토리를 관리하는 방법은 릴리스 날짜와 업데이트 날짜를 계산하는 방법에 영향을 줍니다. Amazon Linux 2 및 Amazon Linux 2023(예: Red Hat Enterprise Linux) 이외의 OS의 경우 패키지 업데이트 및 유지 관리 방법에 대한 자세한 내용은 제조업체 설명서를 참조하세요.
생성하는 [사용자 지정 패치 기준선](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) 설정에서 대부분의 OS 유형에 대해 특정 일 수 후 설치를 위해 패치가 자동 승인되도록 지정할 수 있습니다. AWS는 7일의 자동 승인 날짜를 포함하는 미리 정의된 여러 패치 기준선을 제공합니다.
자동 승인 지연은 패치가 릴리스된 후 패치 적용을 위해 자동 승인되기까지 대기하는 일 수입니다. 예를 들어, `CriticalUpdates` 분류를 사용하여 규칙을 생성하고 7일 자동 승인 지연으로 구성합니다. 결과적으로 릴리스 날짜 또는 마지막 업데이트 날짜가 7월 7일인 새로운 중요 패치는 7월 14일에 자동으로 승인됩니다.
Amazon Linux 2 및 Amazon Linux 2023에서 자동 승인 지연으로 인한 예기치 않은 결과를 방지하려면 릴리스 날짜와 업데이트 날짜가 계산되는 방식을 이해하는 것이 중요합니다.
**참고**
Amazon Linux 2 또는 Amazon Linux 2023 리포지토리가 패키지 릴리스 날짜 정보를 제공하지 않는 경우 Patch Manager는 패키지의 빌드 시간을 자동 승인 날짜 사양 날짜로 사용합니다. 패키지의 빌드 시간을 확인할 수 없는 경우 Patch Manager는 기본 날짜인 1970년 1월 1일을 사용합니다. 이에 따라 Patch Manager에서 1970년 1월 1일 이후 모든 날짜에 대한 패치를 승인하도록 구성된 패치 기준의 자동 승인 날짜 사양이 무시됩니다.
대부분의 경우 패치가 설치되기 전 자동 승인 대기 시간은 `Release Date` 값이 아닌 `updateinfo.xml`의 `Updated Date` 값에서 계산됩니다. 다음은 이러한 날짜 계산에 대한 중요한 세부 정보입니다.
+ `Release Date`는 공지가 릴리스된 날짜입니다. 이는 아직 패키지가 관련 리포지토리에서 반드시 사용 가능함을 의미하지는 않습니다.
+ `Update Date`는 공지가 업데이트된 마지막 날짜입니다. 공지 업데이트는 텍스트 또는 설명 업데이트와 같은 작은 것을 나타낼 수 있습니다. 이는 아직 패키지가 해당 날짜부터 릴리스되었거나 관련 리포지토리에서 반드시 사용 가능함을 의미하지는 않습니다.
이는 패키지의 `Update Date` 값이 7월 7일 수 있지만 7월 13일(예)까지 설치할 수 없음을 의미합니다. 이 경우 7일 자동 승인 지연을 지정하는 패치 기준선이 7월 14일에 `Install` 작업에서 실행된다고 가정합니다. `Update Date` 값이 실행 날짜 7일 전이므로 패키지의 패치 및 업데이트는 7월 14일에 설치됩니다. 패키지가 실제 설치 가능한 상태가 되고 단 하루가 지났는데 설치가 진행됩니다.
+ 운영 체제 또는 애플리케이션 패치를 포함하는 패키지는 최초 릴리스 후 두 번 이상 업데이트할 수 있습니다.
+ 패키지는 AWS 관리형 리포지토리로 릴리스될 수 있지만 나중에 문제가 발견되면 롤백됩니다.
일부 패치 작업에서는 이러한 요인이 중요하지 않을 수 있습니다. 예를 들어, 심각도 값이 `Low` 및 `Medium`이고 분류가 `Recommended`인 패치를 설치하도록 패치 기준선이 구성된 경우 자동 승인 지연은 작업에 거의 영향을 미치지 않을 수 있습니다.
그러나 중요하거나 심각도가 높은 패치의 타이밍이 더 중요한 경우 패치 설치 시기를 더 세밀하게 제어할 수 있습니다. 이를 수행하는 데 권장되는 방법은 관리 노드에서 작업을 패치하기 위해 기본 리포지토리 대신 대체 패치 소스 리포지토리를 사용하는 것입니다.
사용자 지정 패치 기준을 만들 때 대체 패치 소스 리포지토리를 지정할 수 있습니다. 각 사용자 지정 패치 기준에서 지원되는 최대 20개의 Linux 운영 체제 버전에 대해 패치 소스 구성을 지정할 수 있습니다. 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
# 보안 패치 선택 방법
AWS Systems Manager의 도구인 Patch Manager의 주 기능은 관리형 노드에 운영 체제 보안 관련 업데이트를 설치하는 것입니다. 기본적으로 Patch Manager는 사용 가능한 모든 패치를 설치하기 보다는 보안에 관련된 소규모의 패치만 설치합니다.
기본적으로 Patch Manager는 패키지 리포지토리에서 더 이상 사용되지 않는 것으로 표시된 패키지를 다른 패키지 업데이트 설치에 이 대체가 필요하지 않은 한 다른 이름의 대체 패키지로 대체하지 않습니다. 대신 패키지를 업데이트하는 명령의 경우 Patch Manager는 설치되었지만 더 이상 사용되지 않는 패키지에 대해 누락된 업데이트만 보고하고 설치합니다. 더 이상 사용되지 않는 패키지를 교체하려면 일반적으로 기존 패키지를 제거하고 대체 패키지를 설치해야 하기 때문입니다. 더 이상 사용되지 않는 패키지를 교체하면 의도하지 않은 주요 변경 사항이나 추가 기능이 발생할 수 있습니다.
이 동작은 기능 업그레이드가 아닌 보안 업데이트에 초점을 맞춘 YUM 및 DNF의 `update-minimal` 명령과 일치합니다. 자세한 내용은 [패치 설치 방법](patch-manager-installing-patches.md) 섹션을 참조하세요.
**참고**
패치 기준 규칙에서 `ApproveUntilDate` 파라미터 또는 `ApproveAfterDays` 파라미터를 사용하는 경우 Patch Manager는 협정 세계시(UTC)를 사용하여 패치 릴리스 날짜를 평가합니다.
예를 들어 `ApproveUntilDate`의 경우 `2025-11-16` 같은 날짜를 지정하면 `2025-11-16T00:00:00Z` \$1 `2025-11-16T23:59:59Z`에 릴리스된 패치가 승인됩니다.
관리형 노드에서 네이티브 패키지 관리자가 표시하는 패치 릴리스 날짜는 시스템의 현지 시간대에 따라 다른 시간을 표시할 수 있지만 Patch Manager는 승인 계산에 항상 UTC 날짜/시간을 사용합니다. 이를 통해 공식 보안 권고 웹 사이트에 게시된 패치 릴리스 날짜와 일관성을 보장할 수 있습니다.
패치의 심각도 수준을 보고하는 Linux 기반 운영 체제 유형의 경우 Patch Manager는 업데이트 알림 또는 개별 패치에 대해 소프트웨어 게시자가 보고한 심각도 수준을 사용합니다. Patch Manager는 CVSS([Common Vulnerability Scoring System](https://www.first.org/cvss/))와 같은 서드 파티 소스 또는 NVD([National Vulnerability Database](https://nvd.nist.gov/vuln))에서 발표한 지표에서 심각도 수준을 도출하지 않습니다.
**참고**
Patch Manager에서 지원하는 모든 Linux 기반 시스템에서 관리형 노드에 대해 구성된 다른 소스 리포지토리를 선택하여 비보안 업데이트를 설치할 수도 있습니다. 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
Patch Manager가 운영 체제에 맞는 보안 패치를 선택하는 방법을 알아보려면 다음 탭에서 선택합니다.
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
사전 구성된 리포지토리는 Amazon Linux 2에서 Amazon Linux 2023와 다르게 처리됩니다.
Amazon Linux 2의 경우 Systems Manager 패치 기준 서비스는 관리형 노드의 사전 구성된 리포지토리를 사용합니다. 하나의 노드에는 보통 다음과 같은 두 개의 사전 구성된 리포지토리가 있습니다.
**Amazon Linux 2**
+ **리포지토리 ID**: `amzn2-core/2/architecture`
**리포지토리 이름**: `Amazon Linux 2 core repository`
+ **리포지토리 ID**: `amzn2extra-docker/2/architecture`
**리포지토리 이름**: `Amazon Extras repo for docker`
**참고**
*아키텍처*는 x86\$164 또는 (Graviton 프로세서의 경우) aarch64일 수 있습니다.
Amazon Linux 2023(AL2023) 인스턴스를 생성할 때 AL2023 버전에서 사용 가능한 업데이트와 사용자가 선택한 특정 AMI 업데이트가 포함됩니다. AL2023 인스턴스에는 시작 시 심각하고 중요한 추가 보안 업데이트가 자동으로 수신되지 않습니다. 그 대신에 기본적으로 켜져 있는 AL2023의 *버전 관리형 리포지토리를 통한 결정적 업그레이드* 기능을 사용하여 특정한 니즈를 충족하는 업데이트를 일정에 따라 적용할 수 있습니다. 자세한 내용은 **Amazon Linux 2023 사용 설명서의 [버전 지정 리포지토리를 통한 결정적 업그레이드](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)를 참조하세요.
AL2023의 사전 구성된 리포지토리는 다음과 같습니다.
+ **리포지토리 ID**: `amazonlinux`
**리포지토리 이름**: Amazon Linux 2023 리포지토리
Amazon Linux 2023(평가판 릴리스)의 사전 구성된 리포지토리는 패키지 업데이트의 *잠긴 버전*에 연결됩니다. 새로운 Amazon Linux 2023용 Amazon Machine Images(AMIs)가 릴리스될 때 특정 버전으로 잠겨 있습니다. 패치 업데이트의 경우 Patch Manager는 패치 업데이트 리포지토리의 최신 잠긴 버전을 검색한 다음 잠긴 버전의 콘텐츠를 기반으로 관리 노드의 패키지를 업데이트합니다.
**패키지 관리자**
Amazon Linux 2 관리형 노드에서는 Yum을 패키지 관리자로 사용합니다. Amazon Linux 2023은 DNF를 패키지 관리자로 사용합니다.
두 패키지 관리자 모두 *업데이트 알림* 개념을 `updateinfo.xml`이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. Patch Manager는 업데이트 알림에 있는 모든 패키지를 보안으로 간주합니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당합니다.
**참고**
**패치 기준선 생성** 페이지에서 **비보안 업데이트 포함** 확인란을 선택하면 `updateinfo.xml` 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.
**비보안 업데이트 포함** 옵션에 대한 자세한 내용은 [패치 설치 방법](patch-manager-installing-patches.md) 및 [Linux 기반 시스템에서 패치 기준 규칙 사용 방법](patch-manager-linux-rules.md)의 내용을 참조하세요.
------
#### [ CentOS Stream ]
CentOS Stream에서 Systems Manager 패치 기준 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 다음 목록에는 가상의 CentOS 9.2 Amazon Machine Image(AMI)에 대한 예가 나와 있습니다.
+ **리포지토리 ID**: `example-centos-9.2-base`
**리포지토리 이름**: `Example CentOS-9.2 - Base`
+ **리포지토리 ID**: `example-centos-9.2-extras`
**리포지토리 이름**: `Example CentOS-9.2 - Extras`
+ **리포지토리 ID**: `example-centos-9.2-updates`
**리포지토리 이름**: `Example CentOS-9.2 - Updates`
+ **리포지토리 ID**: `example-centos-9.x-examplerepo`
**리포지토리 이름**: `Example CentOS-9.x – Example Repo Packages`
**참고**
모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.
CentOS Stream 노드는 DNF를 패키지 관리자로 사용합니다. 패키지 관리자는 업데이트 알림 개념을 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다.
하지만 CentOS Stream 기본 리포지토리는 업데이트 알림으로 구성되지 않습니다. 따라서 Patch Manager는 기본 CentOS Stream 리포지토리에서 패키지를 탐지하지 못합니다. Patch Manager가 업데이트 알림에 포함되지 않은 패키지를 처리하게 하려면 패치 기준 규칙에서 `EnableNonSecurity` 플래그를 설정해야 합니다.
**참고**
CentOS Stream 업데이트 알림이 지원됩니다. 업데이트 알림을 포함하는 리포지토리는 시작 후 다운로드할 수 있습니다.
------
#### [ Debian 서버 ]
Debian Server의 경우 Systems Manager 패치 기준 서비스가 인스턴스에 있는 사전 구성된 리포지토리를 사용합니다. 사용 가능한 패키지 업그레이드의 업데이트된 목록을 가져오기 위해 3개의 사전 구성된 리포지토리가 사용됩니다. 이를 위해, Systems Manager는 `sudo apt-get update` 명령과 동등한 명령을 수행합니다.
그런 다음 패키지는 `debian-security codename` 리포지토리에서 필터링됩니다. 즉, 각 Debian Server 버전에서 Patch Manager는 다음과 같이 해당 버전의 관련 리포지토리에 속하는 업그레이드만 식별합니다.
+ Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`
------
#### [ Oracle Linux ]
Oracle Linux에서 Systems Manager 패치 기준 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 하나의 노드에는 보통 다음과 같은 두 개의 사전 구성된 리포지토리가 있습니다.
**Oracle Linux 7**:
+ **리포지토리 ID**: `ol7_UEKR5/x86_64`
**리포지토리 이름**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **리포지토리 ID**: `ol7_latest/x86_64`
**리포지토리 이름**: `Oracle Linux 7Server Latest (x86_64)`
**Oracle Linux 8**:
+ **리포지토리 ID**: `ol8_baseos_latest`
**리포지토리 이름**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **리포지토리 ID**: `ol8_appstream`
**리포지토리 이름**: `Oracle Linux 8 Application Stream (x86_64)`
+ **리포지토리 ID**: `ol8_UEKR6`
**리포지토리 이름**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`
**Oracle Linux 9**:
+ **리포지토리 ID**: `ol9_baseos_latest`
**리포지토리 이름**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **리포지토리 ID**: `ol9_appstream`
**리포지토리 이름**: `Oracle Linux 9 Application Stream Packages(x86_64)`
+ **리포지토리 ID**: `ol9_UEKR7`
**리포지토리 이름**: `Oracle Linux UEK Release 7 (x86_64)`
**참고**
모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.
Oracle Linux 관리형 노드는 Yum을 패키지 관리자로 사용하며, Yum은 업데이트 알림의 개념을 `updateinfo.xml`이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당하고 패치 기준에 지정된 분류 필터를 기반으로 패키지를 설치합니다.
**참고**
**패치 기준선 생성** 페이지에서 **비보안 업데이트 포함** 확인란을 선택하면 `updateinfo.xml` 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
AlmaLinux, Red Hat Enterprise Linux 및 Rocky Linux의 Systems Manager 패치 기준선 서비스에서는 관리형 노드의 사전 구성된 리포지토리(repos)를 사용합니다. 하나의 노드에는 보통 다음과 같은 세 개의 사전 구성된 리포지토리가 있습니다.
모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.
**참고**
**패치 기준선 생성** 페이지에서 **비보안 업데이트 포함** 확인란을 선택하면 `updateinfo.xml` 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.
Red Hat Enterprise Linux 7 관리형 노드에서는 Yum을 패키지 관리자로 사용합니다. AlmaLinux, Red Hat Enterprise Linux 8 및 Rocky Linux 관리형 노드에서는 DNF를 패키지 관리자로 사용합니다. 두 패키지 관리자 모두 업데이트 알림 개념을 `updateinfo.xml`이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당하고 패치 기준에 지정된 분류 필터를 기반으로 패키지를 설치합니다.
RHEL 7
다음 리포지토리 ID는 RHUI 2와 연결되어 있습니다. RHUI 3는 2019년 12월에 출시되었으며 Yum 리포지토리 ID에 대한 다른 이름 지정 체계를 도입했습니다. 관리형 노드를 생성하는 RHEL-7 AMI에 따라 명령을 업데이트해야 할 수도 있습니다. 자세한 내용은 *Red Hat Customer Portal*의 [Repository IDs for RHEL 7 in AWS Have Changed](https://access.redhat.com/articles/4599971)를 참조하세요.
+ **리포지토리 ID**: `rhui-REGION-client-config-server-7/x86_64`
**리포지토리 이름**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **리포지토리 ID**: `rhui-REGION-rhel-server-releases/7Server/x86_64`
**리포지토리 이름**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **리포지토리 ID**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`
**리포지토리 이름**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`
AlmaLinux, 8 RHEL 8 및 Rocky Linux 8
+ **리포지토리 ID**: `rhel-8-appstream-rhui-rpms`
**리포지토리 이름**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **리포지토리 ID**: `rhel-8-baseos-rhui-rpms`
**리포지토리 이름**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **리포지토리 ID**: `rhui-client-config-server-8`
**리포지토리 이름**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`
AlmaLinux 9, RHEL 9 및 Rocky Linux 9
+ **리포지토리 ID**: `rhel-9-appstream-rhui-rpms`
**리포지토리 이름**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **리포지토리 ID**: `rhel-9-baseos-rhui-rpms`
**리포지토리 이름**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **리포지토리 ID**: `rhui-client-config-server-9`
**리포지토리 이름**: `Red Hat Enterprise Linux 9 Client Configuration`
------
#### [ SLES ]
SUSE Linux Enterprise Server(SLES) 관리형 노드에 있는 ZYPP 라이브러리는 다음 위치에서 사용 가능한 패치 목록(패키지 모음)을 가져옵니다.
+ 리포지토리 목록: `etc/zypp/repos.d/*`
+ 패키지 정보: `/var/cache/zypp/raw/*`
SLES 관리형 노드는 Zypper를 패키지 관리자로 사용하며, Zypper는 패치 개념을 사용합니다. 패치는 단순히 특정 문제를 수정하는 패키지 모음입니다. Patch Manager는 패치에서 참조하는 모든 패키지를 보안 관련으로 처리합니다. 개별 패키지에는 분류 또는 심각도가 지정되지 않았기 때문에 Patch Manager는 해당 패키지를 이들이 속한 패치의 속성에 할당합니다.
------
#### [ Ubuntu 서버 ]
Ubuntu Server에서 Systems Manager 패치 기준 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 사용 가능한 패키지 업그레이드의 업데이트된 목록을 가져오기 위해 3개의 사전 구성된 리포지토리가 사용됩니다. 이를 위해, Systems Manager는 `sudo apt-get update` 명령과 동등한 명령을 수행합니다.
그런 다음 `codename-security` 리포지토리에서 패키지가 필터링됩니다. 여기서 코드명은 Ubuntu Server 14의 경우 `trusty`와 같이 릴리스 버전마다 고유합니다. Patch Manager는 이러한 리포지토리의 일부인 업그레이드만 식별합니다.
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS(`jammy-security`)
+ Ubuntu Server 24.04 LTS(`noble-security`)
+ Ubuntu Server 25.04(`plucky-security`)
------
#### [ Windows Server ]
Microsoft Windows 운영 체제에서 Patch Manager는 Microsoft가 Microsoft Update에 게시하고 WSUS(Windows Server Update Services)에서 자동으로 사용할 수 있는 사용 가능한 업데이트 목록을 검색합니다.
**참고**
Patch Manager는 Patch Manager에 지원되는 Windows Server 운영 체제 버전에 대해서만 패치를 제공합니다. 예를 들어 Patch Manager는 Windows RT 패치에 사용할 수 없습니다.
Patch Manager는 모든 AWS 리전에서 새로운 업데이트를 지속적으로 모니터링합니다. 사용 가능한 업데이트 목록은 최소한 하루에 한 번씩 리전별로 갱신됩니다. Microsoft의 패치 정보가 처리되면 Patch Manager는 해당 패치 목록에서 최신 업데이트로 대체된 업데이트를 제거합니다. 그러므로 최신 업데이트만 표시되며 설치 시 사용 가능한 상태가 됩니다. 예를 들어 `KB4012214`가 `KB3135456`을 대체하는 경우 `KB4012214`만 Patch Manager에서 업데이트로 사용됩니다.
마찬가지로 Patch Manager는 패치 작업 중에 관리형 노드에서 사용할 수 있는 패치만 설치할 수 있습니다. 기본적으로 Windows Server 2019 및 Windows Server 2022는 이후 업데이트로 대체되는 업데이트를 제거합니다. 따라서 Windows Server 패치 기준의 `ApproveUntilDate` 파라미터를 사용하지만 `ApproveUntilDate` 파라미터에서 선택한 날짜가 최신 패치 날짜 **이전인 경우 다음과 같은 시나리오가 발생합니다.
+ 대체된 패치는 노드에서 제거되므로 Patch Manager를 사용하여 설치할 수 없습니다.
+ 최신 대체 패치가 노드에 있지만 `ApproveUntilDate` 파라미터의 지정된 날짜에 따라 아직 설치가 승인되지 않았습니다.
즉, 관리형 노드는 이전 달의 중요한 패치가 설치되지 않았더라도 Systems Manager 운영 측면에서 규정을 준수합니다. `ApproveAfterDays` 파라미터를 사용할 때도 이와 동일한 시나리오가 발생할 수 있습니다. Microsoft의 대체 패치 동작으로 인해 Microsoft에서 제공하는 최신 패치가 `ApproveAfterDays`의 일수가 경과하기 전에 릴리스되는 경우 Windows Server에 대한 패치가 설치되지 않도록 숫자(일반적으로 30일 이상)를 설정할 수 있습니다. 관리형 노드에서 대체된 패치를 사용할 수 있도록 Windows 그룹 정책 개체(GPO) 설정을 수정한 경우에는 이 시스템 동작이 적용되지 않습니다.
**참고**
경우에 따라 Microsoft는 업데이트된 날짜와 시간을 지정하지 않는 애플리케이션에 대한 패치를 릴리스합니다. 이 경우 업데이트된 `01/01/1970`의 날짜 및 시간은 기본적으로 제공됩니다.
------
# 대체 패치 소스 리포지토리를 지정하는 방법(Linux)
패치 작업에 대해 관리형 노드에 구성된 기본 리포지토리를 사용하는 경우 AWS Systems Manager의 도구인 Patch Manager는 보안 관련 패치를 찾거나 설치합니다. 이는 Patch Manager의 기본 동작입니다. Patch Manager가 보안 패치를 선택 및 설치하는 방법에 대한 모든 정보는 [보안 패치 선택 방법](patch-manager-selecting-patches.md) 섹션을 참조하세요.
그러나 Linux 시스템에서는 Patch Manager를 사용하여 보안과 관련되지 않은 패치 또는 관리형 노드에 구성된 기본 소스 리포지토리가 아닌 다른 소스 리포지토리에 있는 패치를 설치할 수도 있습니다. 사용자 지정 패치 기준을 만들 때 대체 패치 소스 리포지토리를 지정할 수 있습니다. 각 사용자 지정 패치 기준에서 지원되는 최대 20개의 Linux 운영 체제 버전에 대해 패치 소스 구성을 지정할 수 있습니다.
예를 들어, Ubuntu Server 플릿에 Ubuntu Server 25.04 관리형 노드가 모두 포함된다고 가정해 보겠습니다. 이 경우, 동일한 사용자 지정 패치 기준으로 각 버전에 대체 리포지토리를 지정할 수 있습니다. 각 버전에 대해 이름을 입력하고, 운영 체제 버전 유형(제품)을 지정하고, 리포지토리 구성을 제공합니다. 또한 지원되는 모든 운영 체제 버전에 적용되는 단일의 대체 소스 리포지토리를 지정할 수도 있습니다.
**참고**
관리형 노드에 대한 대체 패치 리포지토리를 지정하는 사용자 정의 패치 기준을 실행해도 해당 리포지토리가 운영체제의 새 기본 리포지토리로 지정되지 않습니다. 패치 작업이 완료된 후 이전에 노드의 운영체제에서 기본값으로 구성된 리포지토리는 기본값으로 유지됩니다.
이 옵션 사용에 대한 예제 시나리오 목록은 이 주제 후반부의 [대체 패치 소스 리포지토리의 사용 샘플](#patch-manager-alternative-source-repository-examples) 섹션을 참조하세요.
기본 및 사용자 지정 패치 기준에 대한 자세한 내용은 [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md) 섹션을 참조하세요.
**예: 콘솔 사용**
Systems Manager 콘솔에서 작업 중인 경우 대체 패치 소스 리포지토리를 지정하려면 **패치 기준 생성(Create patch baseline)** 페이지의 **패치 소스(Patch sources)** 섹션을 사용합니다. **패치 소스(Patch sources)** 옵션 사용에 대한 자세한 내용은 [Linux를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-linux.md) 섹션을 참조하세요.
**예: AWS CLI 사용**
AWS Command Line Interface(AWS CLI)와 함께 `--sources` 옵션을 사용하는 예는 [다른 OS 버전에 대한 사용자 지정 리포지토리가 있는 패치 기준 생성](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources) 섹션을 참조하세요.
**Topics**
+ [대체 리포지토리에 대한 중요 고려 사항](#alt-source-repository-important)
+ [대체 패치 소스 리포지토리의 사용 샘플](#patch-manager-alternative-source-repository-examples)
## 대체 리포지토리에 대한 중요 고려 사항
대체 패치 리포지토리를 사용하여 대치 전략을 계획할 경우 다음 사항에 유의하세요.
**리포지토리 업데이트 확인 적용(YUM 및 DNF)**
리포지토리에 연결할 수 없는 경우 Linux 배포의 패키지 관리자에 대한 기본 구성을 설정하여 연결할 수 없는 패키지 리포지토리를 건너뛸 수 있습니다. 리포지토리 업데이트 확인을 적용하려면 `skip_if_unavailable=False`를 리포지토리 구성에 추가합니다.
`skip_if_available` 옵션에 대한 자세한 내용은 [패치 소스에 대한 연결](patch-manager-prerequisites.md#source-connectivity) 섹션을 참조하세요.
**지정된 리포지토리만 패치를 적용하는 데 사용됩니다.**
대체 리포지토리를 지정하는 것이 *추가* 리포지토리를 지정하는 것을 의미하지는 않습니다. 관리형 노드에 대해 기본으로 구성되지 않은 리포지토리를 지정할 수 있습니다. 하지만 업데이트를 적용하려면 기본 리포지토리도 대체 패치 소스 구성의 일부로 지정해야 합니다.
예를 들어 Amazon Linux 2 관리형 노드의 기본 리포지토리는 `amzn2-core` 및 `amzn2extra-docker`입니다. 패치 적용 작업에 EPEL(Extra Packages for Enterprise Linux) 리포지토리를 포함하려면 세 리포지토리를 모두 대체 리포지토리로 지정해야 합니다.
**참고**
관리형 노드에 대한 대체 패치 리포지토리를 지정하는 사용자 정의 패치 기준을 실행해도 해당 리포지토리가 운영체제의 새 기본 리포지토리로 지정되지 않습니다. 패치 작업이 완료된 후 이전에 노드의 운영체제에서 기본값으로 구성된 리포지토리는 기본값으로 유지됩니다.
**YUM 기반 배포에 대한 패치 동작은 updateinfo.xml 매니페스트에 따라 다릅니다.**
YUM 기반 배포(예: Amazon Linux 2 또는 Red Hat Enterprise Linux)에 대해 대체 패치 리포지토리를 지정할 경우 패치 동작은 완전하고 올바른 형식의 `updateinfo.xml` 파일 형태의 업데이트 매니페스트가 리포지토리에 포함되는지 여부에 따라 달라집니다. 이 파일은 다양한 패키지의 릴리스 날짜, 분류 및 심각도를 지정합니다. 패치 동작에 영향을 주는 항목은 다음과 같습니다.
+ **분류(Classification)**와 **심각도(Severity)**를 기준으로 필터링하지만 `updateinfo.xml`에 지정되어 있지 않은 경우 해당 패키지는 필터에 포함되지 않습니다. 즉, `updateinfo.xml` 파일이 없는 패키지는 패치에 포함되지 않습니다.
+ **ApprovalAfterDays**를 기준으로 필터링하지만 패키지 릴리스 날짜가 Unix Epoch 형식이 아니거나 릴리스 날짜가 지정되지 않은 경우 해당 패키지는 필터에 포함되지 않습니다.
+ **패치 기준선 생성** 페이지에서 **비보안 업데이트 포함** 확인란을 선택한 경우는 예외입니다. 이 경우 `updateinfo.xml` 파일이 없거나 적절하게 서식 지정된 **분류(Classification)**, **보안(Severity)** 및 **날짜(Date)** 값이 없는 이 파일을 포함하는 패키지는 사전 필터링된 패치 목록에 포함*됩니다*. 이 경우에도 설치를 위한 다른 패치 기준 규칙 요건을 충족해야 합니다.
## 대체 패치 소스 리포지토리의 사용 샘플
**예제 1 - Ubuntu Server에 대한 비보안 업데이트**
이미 Patch Manager를 사용하여 AWS에서 제공하는 미리 정의된 패치 기준인 `AWS-UbuntuDefaultPatchBaseline`을 사용하는 Ubuntu Server 관리형 노드의 플릿에 보안 패치를 설치했습니다. 이 기본 패치 기준을 기반으로 하는 새 패치 기준을 생성하되, 승인 규칙에서 기본 배포의 일부인 비보안 관련 업데이트도 설치하도록 지정할 수 있습니다. 이 패치 기준이 노드에 대해 실행될 때 보안 및 비보안 문제에 대한 패치가 적용됩니다. 또한 기준에 대해 지정하는 패치 예외의 비보안 패치를 승인할 수도 있습니다.
**예제 2 - Ubuntu Server의 PPA(Personal Package Archives)**
Ubuntu Server 관리형 노드가 [Ubuntu의 PPA(Personal Package Archives)](https://launchpad.net/ubuntu/+ppas)를 통해 배포된 소프트웨어를 실행합니다. 이 경우 관리형 노드에 구성한 PPA 리포지토리를 패치 적용 작업에 대한 소스 리포지토리로 지정하는 패치 기준을 생성합니다. 그런 다음 Run Command를 사용하여 노드에서 패치 기준 문서를 실행합니다.
**예제 3 - 지원되는 Amazon Linux 버전의 사내 애플리케이션**
Amazon Linux 관리형 노드에서 산업 규정 준수에 필요한 애플리케이션을 실행해야 합니다. 노드에 이러한 애플리케이션의 리포지토리를 구성하거나, YUM을 사용하여 애플리케이션을 처음 설치한 후 업데이트하거나, 이 새로운 기업 리포지토리를 포함하도록 새 패치 기준을 생성할 수 있습니다. 그런 다음 Run Command를 사용하여 `Scan` 옵션으로 `AWS-RunPatchBaseline` 문서를 실행하여 기업 패키지가 설치된 패키지로 나열되고 관리형 노드에서 최신 상태인지 확인할 수 있습니다. 최신이 아닌 경우 애플리케이션을 업데이트하도록 `Install` 옵션을 사용하여 문서를 다시 실행하면 됩니다.
# 패치 설치 방법
AWS Systems Manager의 도구인 Patch Manager는 운영 체제 내장 패키지 관리자를 사용하여 관리형 노드에 업데이트를 설치합니다. 예를 들어 및 Amazon Linux 2023의 Windows Server 및 `DNF`에서 Windows Update API를 사용합니다. 패치 관리자는 리포지토리 상태, 미러 URL, GPG 확인 및 `skip_if_unavailable`와 같은 옵션 등의 설정을 포함하여 노드의 기존 패키지 관리자 및 리포지토리 구성을 준수합니다.
Patch Manager는 현재 설치된 더 이상 사용되지 않는 패키지를 대체하는 새 패키지를 설치하지 않습니다. (예외: 새 패키지가 설치 중인 다른 패키지 업데이트의 종속성이거나 새 패키지의 이름이 더 이상 사용되지 않는 패키지와 동일합니다.) 대신 Patch Manager는 설치된 패키지에 대해 사용 가능한 업데이트를 보고하고 설치합니다. 이 접근 방식은 한 패키지로 다른 패키지를 교체할 때 발생할 수 있는 예기치 않은 시스템 기능 변경을 방지하는 데 도움이 됩니다.
더 이상 사용되지 않는 패키지를 제거하고 대체 패키지를 설치해야 하는 경우 사용자 지정 스크립트를 사용하거나 Patch Manager의 표준 작업 밖에서 패키지 관리자 명령을 사용해야 할 수 있습니다.
Patch Manager가 운영 체제에 패치를 설치하는 방법을 알아보려면 다음 탭 중 하나를 선택합니다.
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
Amazon Linux 2 및 Amazon Linux 2023 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. YUM 업데이트 API(Amazon Linux 2) 또는 DNF 업데이트 API(Amazon Linux 2023)는 다음과 같이 승인된 패치에 적용됩니다.
+ AWS에서 제공하는 미리 정의된 기본 패치 기준선의 경우 `updateinfo.xml`에 지정된 패치만 적용됩니다(보안 업데이트만 해당). **비보안 업데이트 포함** 확인란이 선택되지 않았기 때문입니다. 미리 정의된 기준선은 다음과 같은 사용자 지정 기준선과 동일합니다.
+ **비보안 업데이트 포함** 확인란은 선택되지 않음
+ `[Critical, Important]`의 심각도 목록
+ `[Security, Bugfix]`의 분류 목록
Amazon Linux 2의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
Amazon Linux 2023의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.
```
sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**비보안 업데이트 포함** 확인란이 선택된 경우 `updateinfo.xml`에 포함된 패치 및 `updateinfo.xml`에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).
Amazon Linux 2의 경우 **비보안 업데이트 포함**이 선택된 기준선에 `[Critical, Important]`의 심각도 목록 및 `[Security, Bugfix]`의 분류 목록이 포함된 경우 이와 동등한 yum 명령은 다음과 같습니다.
```
sudo yum update --security --sec-severity=Critical,Important --bugfix -y
```
Amazon Linux 2023의 경우 이와 동등한 dnf 명령은 다음과 같습니다.
```
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**참고**
현재 사용되지 않는 패키지를 대체하는 다른 이름의 새 패키지는 `yum` 또는 `dnf` 명령을 Patch Manager 외부에서 실행하는 경우에 설치됩니다. 그러나 동일한 Patch Manager 작업으로는 설치되지 *않습니다*.
**Amazon Linux 2023에 대한 추가 패치 세부 정보**
심각도 수준 '없음' 지원
Amazon Linux 2023는 DNF 패키지 관리자가 인식하는 패치 심각도 수준 `None`도 지원합니다.
심각도 수준 '중간' 지원
Amazon Linux 2023의 경우 `Medium`의 패치 심각도 수준은 일부 외부 리포지토리에 정의될 수 있는 `Moderate`의 심각도와 동일합니다. 패치 기준에 `Medium` 심각도 패치를 포함하면 외부 패치의 `Moderate` 심각도 패치도 인스턴스에 설치됩니다.
API 작업 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html)를 사용하여 규정 준수 데이터를 쿼리하는 경우 심각도 수준 `Medium`을 필터링하면 심각도 수준이 `Medium` 및 `Moderate`인 패치가 모두 보고됩니다.
Amazon Linux 2023의 전이적 종속 항목 처리
Amazon Linux 2023의 경우 Patch Manager는 동등한 `dnf` 명령이 설치하는 것과는 다른 버전의 전이적 종속 항목을 설치할 수 있습니다. 전이적 종속 항목은 다른 패키지의 요구 사항(종속 항목의 종속 항목)을 충족하기 위해 자동으로 설치되는 패키지입니다.
예를 들어 `dnf upgrade-minimal --security`는 알려진 보안 문제를 해결하는 데 필요한 전이적 종속 항목의 *최소* 버전을 설치하는 반면, Patch Manager는 동일한 전이적 종속 항목의 사용 가능한 **최신 버전을 설치합니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
**참고**
Linux 배포의 패키지 관리자에 대한 기본 구성을 설정하여 오류 없이 연결할 수 없는 패키지 리포지토리를 건너뛸 수 있습니다. 이러한 경우 관련 패치 적용 작업은 리포지토리에서 업데이트를 설치하지 않고 진행되며 성공적으로 완료됩니다. 리포지토리 업데이트를 적용하려면 `skip_if_unavailable=False`를 리포지토리 구성에 추가합니다.
`skip_if_available` 옵션에 대한 자세한 내용은 [패치 소스에 대한 연결](patch-manager-prerequisites.md#source-connectivity) 섹션을 참조하세요.
------
#### [ CentOS Stream ]
CentOS Stream 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. CentOS Stream의 DNF 업데이트가 승인된 패치에 적용됩니다.
**참고**
CentOS Stream의 경우 Patch Manager는 동등한 `dnf` 명령이 설치하는 것과는 다른 버전의 전이적 종속 항목을 설치할 수 있습니다. 전이적 종속 항목은 다른 패키지의 요구 사항(종속 항목의 종속 항목)을 충족하기 위해 자동으로 설치되는 패키지입니다.
예를 들어 `dnf upgrade-minimal ‐‐security`는 알려진 보안 문제를 해결하는 데 필요한 전이적 종속 항목의 *최소* 버전을 설치하는 반면, Patch Manager는 동일한 전이적 종속 항목의 *사용 가능한 최신 버전*을 설치합니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ Debian 서버 ]
Debian Server 인스턴스에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. `python3-apt`(`libapt`에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. (**Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
**참고**
Debian Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **Include nonsecurity updates(비보안 업데이트 포함)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
**참고**
Debian Server의 경우 패치 후보 버전은 `debian-security`에 포함된 패치로 제한됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. APT 라이브러리가 사용되어 패키지가 업그레이드됩니다.
**참고**
Patch Manager에서는 APT `Pin-Priority` 옵션을 사용하여 패키지에 우선순위를 지정하는 기능을 지원하지 않습니다. Patch Manager에서는 활성화된 모든 리포지토리에서 사용 가능한 업데이트를 집계하고 설치된 각 패키지의 기준과 일치하는 최신 업데이트를 선택합니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ macOS ]
macOS 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `/Library/Receipts/InstallHistory.plist` 속성 목록은 `softwareupdate` 및 `installer` 패키지 관리자를 사용하여 설치 및 업그레이드된 소프트웨어의 레코드입니다. `pkgutil` 명령줄 도구(`installer`용)와 `softwareupdate` 패키지 관리자를 사용하여 CLI 명령을 실행하여 이 목록을 구문 분석합니다.
`installer`의 경우 CLI 명령에 대한 응답에 `package name`, `version`, `volume`, `location` 및 `install-time` 세부 정보가 포함되지만 Patch Manager는 `package name`과 `version`만 사용합니다.
`softwareupdate`의 경우 CLI 명령에 대한 응답에 패키지 이름(`display name`), `version` 및 `date`가 포함되지만 패치 관리자는 패키지 이름과 버전만 사용합니다.
Brew 및 Brew Cask의 경우 Homebrew는 루트 사용자로 실행되는 명령을 지원하지 않습니다. 결과적으로 Patch Manager는 Homebrew 디렉터리의 소유자 또는 Homebrew 디렉터리의 소유자 그룹에 속하는 유효한 사용자로 Homebrew 명령을 쿼리하고 실행합니다. 명령은 `softwareupdate` 및 `installer`와 유사하며 Python 하위 프로세스를 통해 실행되어 패키지 데이터를 수집하고 출력을 구문 분석하여 패키지 이름 및 버전을 식별합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. 관리형 노드에서 적절한 패키지 CLI를 호출하여 다음과 같이 승인된 패치를 처리합니다.
**참고**
`installer`에는 업데이트를 확인하고 설치하는 기능이 없습니다. 따라서 `installer`의 경우 Patch Manager는 설치된 패키지만 보고합니다. 그 결과 `installer` 패키지는 `Missing`으로 보고되지 않습니다.
+ AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 **비보안 업데이트 포함** 확인란이 선택되지 *않은* 사용자 지정 패치 기준선의 경우 보안 업데이트만 적용됩니다.
+ **비보안 업데이트 포함** 확인란이 *선택된* 사용자 지정 패치 기준선의 경우 보안 및 비보안 업데이트가 모두 적용됩니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ Oracle Linux ]
Oracle Linux 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. 버전 7 관리형 노드에서 다음과 같이 YUM 업데이트 API가 승인된 패치에 적용됩니다.
+ AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 **비보안 업데이트 포함** 확인란이 선택되지 *않은* 사용자 지정 패치 기준선의 경우 `updateinfo.xml`에 지정한 패치만 적용됩니다(보안 업데이트만 해당).
이 워크플로와 동등한 YUM 명령은 다음과 같습니다.
```
sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
```
+ **비보안 업데이트 포함** 확인란을 *선택한* 사용자 지정 패치 기준선의 경우 `updateinfo.xml`에 포함된 패치 및 `updateinfo.xml`에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).
이 워크플로와 동등한 YUM 명령은 다음과 같습니다.
```
sudo yum update --security --bugfix -y
```
버전 8 및 9 관리형 노드에서 다음과 같이 DNF 업데이트 API가 승인된 패치에 적용됩니다.
+ AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 **비보안 업데이트 포함** 확인란이 선택되지 *않은* 사용자 지정 패치 기준선의 경우 `updateinfo.xml`에 지정한 패치만 적용됩니다(보안 업데이트만 해당).
이 워크플로와 동등한 YUM 명령은 다음과 같습니다.
```
sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
```
**참고**
Oracle Linux의 경우 Patch Manager는 동등한 `dnf` 명령이 설치하는 것과는 다른 버전의 전이적 종속 항목을 설치할 수 있습니다. 전이적 종속 항목은 다른 패키지의 요구 사항(종속 항목의 종속 항목)을 충족하기 위해 자동으로 설치되는 패키지입니다.
예를 들어 `dnf upgrade-minimal --security`는 알려진 보안 문제를 해결하는 데 필요한 전이적 종속 항목의 *최소* 버전을 설치하는 반면, Patch Manager는 동일한 전이적 종속 항목의 *사용 가능한 최신 버전*을 설치합니다.
+ **비보안 업데이트 포함** 확인란을 *선택한* 사용자 지정 패치 기준선의 경우 `updateinfo.xml`에 포함된 패치 및 `updateinfo.xml`에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).
이 워크플로와 동등한 YUM 명령은 다음과 같습니다.
```
sudo dnf upgrade --security --bugfix
```
**참고**
현재 사용되지 않는 패키지를 대체하는 다른 이름의 새 패키지는 `yum` 또는 `dnf` 명령을 Patch Manager 외부에서 실행하는 경우에 설치됩니다. 그러나 동일한 Patch Manager 작업으로는 설치되지 *않습니다*.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
**참고**
Linux 배포의 패키지 관리자에 대한 기본 구성을 설정하여 오류 없이 연결할 수 없는 패키지 리포지토리를 건너뛸 수 있습니다. 이러한 경우 관련 패치 적용 작업은 리포지토리에서 업데이트를 설치하지 않고 진행되며 성공적으로 완료됩니다. 리포지토리 업데이트를 적용하려면 `skip_if_unavailable=False`를 리포지토리 구성에 추가합니다.
`skip_if_available` 옵션에 대한 자세한 내용은 [패치 소스에 대한 연결](patch-manager-prerequisites.md#source-connectivity) 섹션을 참조하세요.
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
Red Hat Enterprise Linux 및 Rocky Linux 관리형 노드의 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. YUM 업데이트 API(RHEL 7의 경우) 또는 DNF 업데이트 API(AlmaLinux 8 및 9, RHEL 8, 9 및 10, Rocky Linux 8 및 9의 경우)는 다음 규칙에 따라 승인된 패치에 적용됩니다.
**시나리오 1: 비보안 업데이트 제외**
+ **적용 대상**: AWS에서 제공하는 사전 정의된 기본 패치 기준 및 사용자 지정 패치 기준.
+ **비보안 업데이트 포함** 확인란: 선택하지 *않음*.
+ **패치 적용**: `updateinfo.xml`(보안 업데이트만 해당)에 지정된 패치는 패치 기준 구성과 일치하고 구성된 리포지토리에서 찾을 수 있는 *경우에만* 적용됩니다.
경우에 따라 `updateinfo.xml`에 지정된 패치를 구성된 리포지토리에서 더 이상 사용하지 못할 수 있습니다. 구성된 리포지토리에는 일반적으로 모든 이전 업데이트의 누적 롤업인 최신 버전의 패치만 있지만 최신 버전은 패치 기준 규칙과 일치하지 않을 수 있으며 패치 적용 작업에서 생략됩니다.
+ **명령**: RHEL 7의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
AlmaLinux, RHEL 8 및 Rocky Linux의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.
```
sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
```
**참고**
AlmaLinux, RHEL 및 Rocky LinuxRocky Linux의 경우 Patch Manager는 동등한 `dnf` 명령이 설치하는 것과는 다른 버전의 전이적 종속 항목을 설치할 수 있습니다. 전이적 종속 항목은 다른 패키지의 요구 사항(종속 항목의 종속 항목)을 충족하기 위해 자동으로 설치되는 패키지입니다.
예를 들어 `dnf upgrade-minimal --security`는 알려진 보안 문제를 해결하는 데 필요한 전이적 종속 항목의 *최소* 버전을 설치하는 반면, Patch Manager는 동일한 전이적 종속 항목의 *사용 가능한 최신 버전*을 설치합니다.
**시나리오 2: 비보안 업데이트 포함**
+ **적용 대상**: 사용자 지정 패치 기준.
+ **비보안 업데이트 포함** 확인란: 선택.
+ **패치 적용**: `updateinfo.xml`에 있는 패치*와* `updateinfo.xml`에 없는 패치가 적용됩니다(보안 및 비보안 업데이트).
+ **명령**: RHEL 7의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.
```
sudo yum update --security --bugfix -y
```
AlmaLinux 8 및 9, RHEL 8 및 9 Rocky Linux 8 및 9의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.
```
sudo dnf update --security --bugfix -y
```
**참고**
현재 사용되지 않는 패키지를 대체하는 다른 이름의 새 패키지는 `yum` 또는 `dnf` 명령을 Patch Manager 외부에서 실행하는 경우에 설치됩니다. 그러나 동일한 Patch Manager 작업으로는 설치되지 *않습니다*.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
**참고**
Linux 배포의 패키지 관리자에 대한 기본 구성을 설정하여 오류 없이 연결할 수 없는 패키지 리포지토리를 건너뛸 수 있습니다. 이러한 경우 관련 패치 적용 작업은 리포지토리에서 업데이트를 설치하지 않고 진행되며 성공적으로 완료됩니다. 리포지토리 업데이트를 적용하려면 `skip_if_unavailable=False`를 리포지토리 구성에 추가합니다.
`skip_if_available` 옵션에 대한 자세한 내용은 [패치 소스에 대한 연결](patch-manager-prerequisites.md#source-connectivity) 섹션을 참조하세요.
------
#### [ SLES ]
:SUSE Linux Enterprise Server(SLES) 관리형 노드, 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. Zypper 업데이트 API가 승인된 패치에 적용됩니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ Ubuntu 서버 ]
Ubuntu Server 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. `python3-apt`(`libapt`에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. (**Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
**참고**
Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **Include nonsecurity updates(비보안 업데이트 포함)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 [**비보안 업데이트 포함(Include nonsecurity updates)**] 확인란을 선택했는지 여부에 따라 달라집니다.
**참고**
Ubuntu Server의 각 버전에서 패치 후보 버전은 다음과 같이 해당 버전의 관련 리포지토리에 속하는 패치로 제한됩니다.
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS): `focal-security`
Ubuntu Server 22.04 LTS: `jammy-security`
Ubuntu Server 24.04 LTS(`noble-security`)
Ubuntu Server 25.04(`plucky-security`)
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. APT 라이브러리가 사용되어 패키지가 업그레이드됩니다.
**참고**
Patch Manager에서는 APT `Pin-Priority` 옵션을 사용하여 패키지에 우선순위를 지정하는 기능을 지원하지 않습니다. Patch Manager에서는 활성화된 모든 리포지토리에서 사용 가능한 업데이트를 집계하고 설치된 각 패키지의 기준과 일치하는 최신 업데이트를 선택합니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ Windows Server ]
Windows Server 관리형 노드에서 패치 작업이 수행되는 경우 노드가 Systems Manager에서 해당되는 패치 기준 스냅샷을 요청합니다. 이 스냅샷에는 배포하도록 승인된 패치 기준에 있는 사용 가능한 모든 업데이트 목록이 들어 있습니다. 이 업데이트 목록이 Windows 업데이트 API로 전송되며, 여기서 관리형 노드에 적용 가능한 업데이트를 결정하고 필요 시 이를 설치합니다. Windows에서는 사용 가능한 최신 KB 버전만 설치할 수 있습니다. Patch Manager는 KB의 최신 버전 또는 KB의 이전 버전이 적용된 패치 기준과 일치하는 경우 KB의 최신 버전을 설치합니다. 업데이트가 설치되면, 필요한 모든 패치 적용 작업을 완료하기 위해 필요한 만큼 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.) 패치 적용 작업에 대한 정보는 Run Command 요청의 결과에 요약되어 표시됩니다. 추가 로그는 `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` 폴더의 관리형 노드에서 찾을 수 있습니다.
KB를 다운로드하고 설치하는 데 Windows Update API가 사용되므로 Windows Update에 대한 모든 그룹 정책 설정이 유지됩니다. Patch Manager를 사용하는 데는 그룹 정책 설정이 필요하지 않지만, 관리형 노드가 Windows Server Update Services(WSUS) 서버로 향하도록 하는 것과 같은 정의된 설정은 적용됩니다.
**참고**
Patch Manager는 Windows Update API를 사용하여 KB의 다운로드 및 설치를 진행하므로 기본적으로 Windows는 Microsoft의 Windows Update 사이트로부터 모든 KB를 다운로드합니다. 따라서 관리형 노드에서 Microsoft Windows Update 사이트에 연결할 수 있어야 하며, 그렇지 않으면 패치가 적용되지 않습니다. 또는 WSUS 서버가 KB 리포지토리 역할을 수행하도록 구성하고, 관리형 노드가 그룹 정책을 사용하는 해당 WSUS 서버를 대상으로 지정하도록 구성할 수 있습니다.
Patch Manager는 **승인된 패치** 목록 또는 **거부된 패치** 목록이 기준 구성에 포함된 경우와 같이 Windows Server에 대한 사용자 지정 패치 기준을 생성할 때 KB ID를 참조할 수 있습니다. Microsoft Windows Update 또는 WSUS 서버에서 KB ID가 할당된 업데이트만 Patch Manager에 의해 설치됩니다. KB ID가 없는 업데이트는 패치 작업에 포함되지 않습니다.
사용자 지정 패치 기준 생성에 대한 자세한 내용은 다음 주제를 참조하세요.
[Windows Server를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-windows.md)
[패치 기준 생성(CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Windows 운영 체제의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)
------
# Linux 기반 시스템에서 패치 기준 규칙 사용 방법
Linux 배포용 패치 기준의 규칙은 배포 유형에 따라 다르게 작동합니다. Windows Server 관리형 노드의 패치 업데이트와 달리 규칙은 인스턴스의 구성된 리포지토리를 고려하기 위해 각 노드에서 평가됩니다. AWS Systems Manager의 도구인 Patch Manager는 기본 패키지 관리자를 사용하여 패치 기준에서 승인한 패치 설치를 진행합니다.
패치의 심각도 수준을 보고하는 Linux 기반 운영 체제 유형의 경우 Patch Manager는 업데이트 알림 또는 개별 패치에 대해 소프트웨어 게시자가 보고한 심각도 수준을 사용합니다. Patch Manager는 CVSS([Common Vulnerability Scoring System](https://www.first.org/cvss/))와 같은 서드 파티 소스 또는 NVD([National Vulnerability Database](https://nvd.nist.gov/vuln))에서 발표한 지표에서 심각도 수준을 도출하지 않습니다.
**Topics**
+ [Amazon Linux 2 및 Amazon Linux 2023에서 패치 기준 규칙이 작동하는 방식](#linux-rules-amazon-linux)
+ [CentOS Stream에서 패치 기준 규칙 작동 방법](#linux-rules-centos)
+ [Debian Server에서 패치 기준 규칙 작동 방법](#linux-rules-debian)
+ [macOS에서 패치 기준 규칙 작동 방법](#linux-rules-macos)
+ [Oracle Linux에서 패치 기준 규칙 작동 방법](#linux-rules-oracle)
+ [AlmaLinux, RHEL 및 Rocky Linux의 패치 기준선 규칙 작동 방식](#linux-rules-rhel)
+ [SUSE Linux Enterprise Server에서 패치 기준 규칙 작동 방법](#linux-rules-sles)
+ [Ubuntu Server에서 패치 기준 규칙 작동 방법](#linux-rules-ubuntu)
## Amazon Linux 2 및 Amazon Linux 2023에서 패치 기준 규칙이 작동하는 방식
**참고**
Amazon Linux 2023(AL2023)은 하나 이상의 시스템 설정을 통해, 잠글 수 있는 버전 관리형 리포지토리를 특정 버전에 사용합니다. AL2023 EC2 인스턴스의 모든 패치 작업에서 Patch Manager는 시스템 구성과 관계없이 최신 리포지토리 버전을 사용합니다. 자세한 내용은 **Amazon Linux 2023 사용 설명서의 [버전 지정 리포지토리를 통한 결정적 업그레이드](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)를 참조하세요.
Amazon Linux 2 및 Amazon Linux 2023에서 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드에서 YUM 라이브러리(Amazon Linux 2) 또는 DNF 라이브러리(Amazon Linux 2023)는 구성된 각 리포지토리에 대한 `updateinfo.xml` 파일에 액세스합니다.
`updateinfo.xml` 파일이 없는 경우 **비보안 업데이트 포함** 및 **자동 승인** 설정에 따라 패치 설치 여부가 결정됩니다. 예를 들어 비보안 업데이트가 허용된 경우 자동 승인 시간이 되면 설치됩니다.
1. `updateinfo.xml`에 있는 각 업데이트 알림에는 다음 표에 설명된 대로, 패키지의 속성을 알림에 나타내는 여러 속성이 들어 있습니다.
**업데이트 알림 속성**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
1. SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## CentOS Stream에서 패치 기준 규칙 작동 방법
CentOS Stream 기본 리포지토리에는 `updateinfo.xml` 파일이 포함되지 않습니다. 하지만 만들거나 사용하는 사용자 지정 리포지토리에는 이 파일이 포함될 수 있습니다. 이 항목에서 `updateinfo.xml` 참조는 이러한 사용자 지정 리포지토리에만 적용됩니다.
CentOS Stream에서 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드에서 DNF 라이브러리는 구성된 리포지토리마다 사용자 지정 리포지토리에 `updateinfo.xml` 파일이 있는 경우 이 파일에 액세스합니다.
항상 기본 리포지토리를 포함하는 `updateinfo.xml`이 없는 경우 **비보안 업데이트 포함** 및 **자동 승인** 설정에 따라 패치 설치 여부가 결정됩니다. 예를 들어 비보안 업데이트가 허용된 경우 자동 승인 시간이 되면 설치됩니다.
1. `updateinfo.xml`이 있는 경우 해당 파일의 각 업데이트 알림에는 다음 표에 설명된 대로, 패키지의 속성을 알림에 나타내는 여러 속성이 들어 있습니다.
**업데이트 알림 속성**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
1. 모든 경우 SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## Debian Server에서 패치 기준 규칙 작동 방법
Debian Server에서 패치 기준 서비스는 *우선 순위* 및 *섹션* 필드에 필터링을 제공합니다. 이러한 필드는 일반적으로 모든 Debian Server 패키지에 존재합니다. 패치가 패치 기준에 의해 선택된 것인지를 확인하기 위해 Patch Manager는 다음 작업을 수행합니다.
1. Debian Server 시스템의 경우, `sudo apt-get update`와 동등한 명령이 실행되어 사용 가능한 패키지 목록을 새로 고칩니다. 리포지토리는 구성되지 않으며 데이터는 `sources` 목록에 구성되어 있는 리포지토리로부터 가져옵니다.
1. `python3-apt`(`libapt`에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. (**Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)
1. 다음으로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 및 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 목록이 적용됩니다.
**참고**
Debian Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **Include nonsecurity updates(비보안 업데이트 포함)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다. 이 경우 Debian Server의 패치 후보 버전은 다음 리포지토리에 포함된 패치로 제한됩니다.
이러한 리포지토리는 다음과 같이 이름이 지정됩니다.
+ Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
*우선순위* 및 *섹션* 필드의 내용을 보려면 다음 `aptitude` 명령을 실행하세요.
**참고**
먼저 Debian Server 시스템에 Aptitude를 설치해야 할 수 있습니다.
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
이 명령에 대한 응답으로, 업그레이드 가능한 모든 패키지가 다음 형식으로 보고됩니다.
```
name, priority, section, archive, candidate version
```
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## macOS에서 패치 기준 규칙 작동 방법
macOS에서 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드에서 Patch Manager는 `InstallHistory.plist` 파일의 구문 분석된 내용에 액세스하고 패키지 이름과 버전을 식별합니다.
구문 분석 프로세스에 대한 자세한 내용은 [패치 설치 방법](patch-manager-installing-patches.md)의 **macOS** 탭을 참조하세요.
1. SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## Oracle Linux에서 패치 기준 규칙 작동 방법
Oracle Linux에서 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드에서 YUM 라이브러리는 구성된 각 리포지토리에 대한 `updateinfo.xml` 파일에 액세스합니다.
**참고**
리포지토리가 Oracle에서 관리하는 것이 아닌 경우 `updateinfo.xml` 파일을 사용할 수 없을 수 있습니다. `updateinfo.xml`이 없는 경우 **비보안 업데이트 포함** 및 **자동 승인** 설정에 따라 패치 설치 여부가 결정됩니다. 예를 들어 비보안 업데이트가 허용된 경우 자동 승인 시간이 되면 설치됩니다.
1. `updateinfo.xml`에 있는 각 업데이트 알림에는 다음 표에 설명된 대로, 패키지의 속성을 알림에 나타내는 여러 속성이 들어 있습니다.
**업데이트 알림 속성**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
1. SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## AlmaLinux, RHEL 및 Rocky Linux의 패치 기준선 규칙 작동 방식
AlmaLinux, Red Hat Enterprise Linux (RHEL) 및 Rocky Linux의 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드의 YUM 라이브러리(RHEL 7) 또는 DNF 라이브러리(AlmaLinux 8 및 9, RHEL 8, 9 및 10, Rocky Linux 8 및 9)에서는 구성된 리포지토리마다 `updateinfo.xml` 파일에 액세스합니다.
**참고**
리포지토리가 Red Hat에서 관리하는 것이 아닌 경우 `updateinfo.xml` 파일을 사용할 수 없을 수 있습니다. `updateinfo.xml`을 찾을 수 없는 경우, 패치가 적용되지 않습니다.
1. `updateinfo.xml`에 있는 각 업데이트 알림에는 다음 표에 설명된 대로, 패키지의 속성을 알림에 나타내는 여러 속성이 들어 있습니다.
**업데이트 알림 속성**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
1. SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## SUSE Linux Enterprise Server에서 패치 기준 규칙 작동 방법
SLES에서 각 패치에는 패치에 있는 패키지 속성을 나타내는 다음 속성이 포함되어 있습니다.
+ **카테고리**: 패치 기준선의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 **분류 키** 속성의 값에 해당합니다. 업데이트 알림에 들어 있는 패치 유형을 나타냅니다.
AWS CLI 명령 **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** 또는 API 작업 **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**를 사용하여 지원되는 값 목록을 볼 수 있습니다. 또한 Systems Manager 콘솔의 [**패치 기준 생성(Create patch baseline)**] 페이지 또는 [**패치 기준 편집(Edit patch baseline)**] 페이지의 [**승인 규칙(Approval rules)**] 영역에서 목록을 볼 수 있습니다.
+ **심각도**: 패치 기준선의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 **심각도** 키 속성의 값에 해당합니다. 패치의 심각도를 나타냅니다.
AWS CLI 명령 **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** 또는 API 작업 **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**를 사용하여 지원되는 값 목록을 볼 수 있습니다. 또한 Systems Manager 콘솔의 [**패치 기준 생성(Create patch baseline)**] 페이지 또는 [**패치 기준 편집(Edit patch baseline)**] 페이지의 [**승인 규칙(Approval rules)**] 영역에서 목록을 볼 수 있습니다.
SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준선의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 **제품** 키 속성의 값에 해당합니다.
각 패치에 대해 패치 기준이 필터로 사용되어, 자격을 갖춘 패키지만 업데이트에 포함되도록 허용합니다. 패치 기준 정의를 적용한 후에도 여러 패키지가 남아 있으면 최신 버전이 사용됩니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
## Ubuntu Server에서 패치 기준 규칙 작동 방법
Ubuntu Server에서 패치 기준 서비스는 *우선 순위* 및 *섹션* 필드에 필터링을 제공합니다. 이러한 필드는 일반적으로 모든 Ubuntu Server 패키지에 존재합니다. 패치가 패치 기준에 의해 선택된 것인지를 확인하기 위해 Patch Manager는 다음 작업을 수행합니다.
1. Ubuntu Server 시스템의 경우, `sudo apt-get update`와 동등한 명령이 실행되어 사용 가능한 패키지 목록을 새로 고칩니다. 리포지토리는 구성되지 않으며 데이터는 `sources` 목록에 구성되어 있는 리포지토리로부터 가져옵니다.
1. `python3-apt`(`libapt`에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. (**Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)
1. 다음으로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 및 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 목록이 적용됩니다.
**참고**
Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **Include nonsecurity updates(비보안 업데이트 포함)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다. 이 경우 Ubuntu Server의 패치 후보 버전은 다음 리포지토리에 포함된 패치로 제한됩니다.
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS(`jammy-security`)
+ Ubuntu Server 24.04 LTS(`noble-security`)
+ Ubuntu Server 25.04(`plucky-security`)
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
*우선순위* 및 *섹션* 필드의 내용을 보려면 다음 `aptitude` 명령을 실행하세요.
**참고**
먼저 Ubuntu Server 16 시스템에 Aptitude를 설치해야 할 수 있습니다.
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
이 명령에 대한 응답으로, 업그레이드 가능한 모든 패키지가 다음 형식으로 보고됩니다.
```
name, priority, section, archive, candidate version
```
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
# Linux 및 Windows Server 간 패치 작업 차이점
이 주제에서는 AWS Systems Manager의 도구인 Patch Manager의 Linux 패치와 Windows Server 패치 간 주요 차이점에 대해 설명합니다.
**참고**
Linux 관리형 노드에 패치를 실행하려면 노드가 SSM Agent 버전 2.0.834.0 이상을 실행 중이어야 합니다.
SSM Agent의 업데이트된 버전은 Systems Manager에 새 도구가 추가되거나 기존 도구가 업데이트될 때마다 릴리스됩니다. 최신 버전의 에이전트를 사용하지 못하면 관리형 노드에서 다양한 Systems Manager 도구를 사용하지 못할 수 있습니다. 이러한 이유로 시스템의 SSM Agent 상태를 최신 상태로 유지하는 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 [SSM Agent 업데이트 자동화](ssm-agent-automatic-updates.md) 섹션을 참조하세요. SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 페이지를 구독합니다.
## 차이점 1: 패치 평가
Patch Manager는 Windows 관리형 노드와 Linux 관리형 노드에 적용되는 패치를 평가할 때 서로 다른 프로세스를 사용합니다.
**Linux**
Linux 패치의 경우 Systems Manager는 패치 기준 규칙과 *각* 관리형 노드에서 승인 및 거부된 패치 목록을 평가합니다. 서비스가 관리형 노드에 구성된 리포지토리에서 알려진 패치 및 업데이트 목록을 검색하기 때문에 Systems Manager는 각 노드에서 패치를 평가해야 합니다.
**Windows**
Windows 패치의 경우 Systems Manager는 패치 기준 규칙과 승인/거부된 패치 목록을 *직접 서비스에서* 평가합니다. Windows 패치는 단일 리포지토리(Windows 업데이트)에서 가져오기 때문에 이것이 가능합니다.
## 차이점 2: `Not Applicable` 패치
Linux 운영 체제에서는 사용할 수 있는 패키지가 매우 많기 때문에 Systems Manager가 [*해당 사항 없음(Not Applicable)*] 상태의 패치에 대해서는 세부 정보를 보고하지 않습니다. 예를 들어 `Not Applicable` 패치는 인스턴스에 Apache가 설치되어 있지 않은 경우 Apache 소프트웨어용 패치입니다. Systems Manager는 요약에서 `Not Applicable` 패치 수를 보고하지만 관리형 노드에 대해 [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API를 호출하면 상태가 `Not Applicable`인 패치는 반환된 데이터에 포함되지 않습니다. Windows에서는 이러한 동작이 다릅니다.
## 차이점 3: SSM 문서 지원
`AWS-ApplyPatchBaseline` Systems Manager 문서(SSM 문서)는 Linux 관리형 노드를 지원하지 않습니다. Linux, macOS 및 Windows Server 관리형 노드에 패치 기준을 적용하기 위해 권장되는 SSM 문서는 `AWS-RunPatchBaseline`입니다. 자세한 내용은 [관리형 노드 패치를 위한 SSM 명령 문서](patch-manager-ssm-documents.md) 및 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)(을)를 참조하세요.
## 차이점 4: 애플리케이션 패치
Patch Manager는 운영 체제를 패치하는 데 중점을 둡니다. 그러나 Patch Manager를 사용하여 관리형 노드의 일부 애플리케이션을 패치할 수도 있습니다.
**Linux**
Linux 운영 체제에서 Patch Manager는 업데이트를 위해 구성된 리포지토리를 사용하며 운영 체제와 애플리케이션 패치를 구분하지 않습니다. Patch Manager를 사용하여 업데이트를 가져올 리포지토리를 정의할 수 있습니다. 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
**Windows**
Windows Server 관리형 노드에서는 Microsoft Word 2016, Microsoft Exchange Server 2016과 같이 Microsoft에서 출시한 애플리케이션에 대해 *승인된* 패치와 *거부된* 패치 예외는 물론, 승인 규칙을 적용할 수 있습니다. 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
## 차이점 5: 사용자 지정 패치 기준의 거부된 패치 목록 옵션
사용자 지정 패치 기준을 생성할 때 **거부된 패치** 목록에 하나 이상의 패치를 지정할 수 있습니다. Linux 관리형 노드의 경우 패치가 기준에서 허용되는 다른 패치의 종속 항목인 경우 설치될 수 있도록 선택할 수도 있습니다.
하지만 Windows Server에서는 패치 종속성의 개념을 지원하지 않습니다. Windows Server에 대한 사용자 지정 기준선의 **거부된 패치** 목록에 패치를 추가할 수 있지만 (1) 거부된 패치가 관리형 노드에 이미 설치되어 있는지 여부와 (2) **거부된 패치 작업**에 대해 선택하는 옵션에 따라 결과가 달라집니다.
Windows Server의 거부된 패치 옵션에 대한 자세한 내용은 다음 표를 참조하세요.
| 설치 상태 | 옵션: “종속성으로 허용” | 옵션: “블록” |
| --- | --- | --- |
| 패치가 이미 설치됨 | 보고된 상태: INSTALLED\$1OTHER | 보고된 상태: INSTALLED\$1REJECTED |
| 패치가 아직 설치되지 않음 | 패치 건너뜀 | 패치 건너뜀 |
Microsoft에서 릴리스하는 Windows Server에 대한 각 패치에는 일반적으로 설치하는 데 필요한 모든 정보가 포함됩니다. 하지만 경우에 따라 수동으로 설치해야 하는 사전 필수 패키지가 필요할 수 있습니다. Patch Manager는 이러한 사전 필수 조건에 대해 정보를 보고하지 않습니다. 관련 정보는 Microsoft 웹 사이트의 [Windows 업데이트 문제 해결](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)을 참조하세요.