• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.
# AWS Systems Manager Patch Manager
AWS Systems Manager의 도구인 Patch Manager는 보안 관련 업데이트 및 기타 유형의 업데이트로 관리형 노드를 패치하는 프로세스를 자동화합니다.
**참고**
Systems Manager는 AWS Systems Manager의 도구인 Quick Setup에서 **패치 정책을 지원합니다. 패치 정책을 사용하는 것이 패치 작업을 구성하는 데 권장되는 방법입니다. 단일 패치 정책 구성을 사용하여 조직 내 모든 리전의 모든 계정이나, 선택한 계정 및 리전이나, 단일 계정-리전 페어에 대한 패치 적용을 정의할 수 있습니다. 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
Patch Manager를 사용하면 운영 체제와 애플리케이션 모두를 패치할 수 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.) Patch Manager를 사용하여 Windows 노드에 서비스 팩을 설치하고 Linux 노드에서 부 버전 업그레이드를 실행할 수 있습니다. 운영 체제 유형별로 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 엣지 디바이스, 온프레미스 서버 및 가상 머신의 플릿에 패치를 적용할 수 있습니다. 여기에는 [Patch Manager 필수 조건](patch-manager-prerequisites.md)에 나와 있는 여러 운영 체제의 지원되는 버전이 포함됩니다. 인스턴스를 스캔하여 누락된 패치 보고서만 보거나, 혹은 스캔 후 누락된 패치를 모두 자동으로 설치할 수도 있습니다. Patch Manager를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com//systems-manager/patch-manager)을 엽니다. 탐색 창에서 **Patch Manager**를 선택합니다.
AWS는 Patch Manager에서 사용 가능성 여부를 확인하기 전에는 패치를 테스트하지 않습니다. 또한 Patch Manager는 주요 버전의 운영 체제 업그레이드를 지원하지 않습니다(예: Windows Server 2016에서 Windows Server 2019로 또는 (Red Hat Enterprise Linux)(RHEL) 7.0에서 RHEL 8.0으로).
패치의 심각도 수준을 보고하는 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가 조직에 주는 이점은 무엇인가요?
Patch Manager는 보안 관련 업데이트 및 기타 유형의 업데이트로 관리형 노드를 패치하는 프로세스를 자동화합니다. 다음과 같은 몇 가지 중요한 이점이 있습니다.
+ **중앙 집중식 패치 적용 제어** - 패치 정책을 사용하면 조직의 모든 리전, 특정 계정 및 리전 또는 단일 계정-리전 페어에 있는 모든 계정에 대해 반복 패치 적용 작업을 설정할 수 있습니다.
+ **유연한 패치 적용 작업** - 인스턴스를 스캔하여 누락된 패치 보고서만 보거나 스캔 후 누락된 패치를 모두 자동으로 설치할 수도 있습니다.
+ **포괄적인 규정 준수 보고** - 스캔 작업 후 패치 규정을 위반하는 관리형 노드와 누락된 패치에 관한 자세한 정보를 볼 수 있습니다.
+ **교차 플랫폼 지원** - Patch Manager는 다양한 Linux 배포판, macOS, Windows Server를 포함한 여러 운영 체제를 지원합니다.
+ **사용자 지정 패치 기준** - 설치가 승인된 패치를 지정하는 사용자 지정 패치 기준을 통해 조직의 패치 규정 준수를 구성하는 항목을 정의할 수 있습니다.
+ **다른 AWS 서비스와의 통합** - Patch Manager는 관리와 보안을 강화하기 위해 AWS Organizations, AWS Security Hub CSPM, AWS CloudTrail, AWS Config과 통합됩니다.
+ **결정적 업그레이드** - Amazon Linux 2023과 같은 운영 체제의 버전이 지정된 리포지토리를 통한 결정적 업그레이드를 지원합니다.
## Patch Manager는 누가 사용해야 하나요?
Patch Manager는 다음을 위해 설계되었습니다.
+ 관리형 노드 플릿에서 패치 규정 준수를 유지해야 하는 IT 관리자
+ 인프라 전반의 패치 규정 준수 상태에 대해 가시성이 필요한 운영 관리자
+ 대규모로 자동 패치 적용 솔루션을 구현하려는 클라우드 아키텍트
+ 패치 적용을 작업 워크플로에 통합해야 하는 DevOps 엔지니어
+ 중앙 집중식 패치 관리가 필요하며 다중 계정/다중 리전 배포가 있는 조직
+ AWS 관리형 노드, 엣지 디바이스, 온프레미스 서버, 가상 머신의 보안 태세 및 운영 상태를 유지할 책임이 있는 사람
## Patch Manager의 주요 기능은 무엇입니까?
Patch Manager는 다음과 같은 몇 가지 핵심 기능을 제공합니다.
+ **패치 정책** - AWS Organizations와의 통합을 통해 단일 정책을 사용하여 여러 AWS 계정 및 리전에서 패치 적용 작업을 구성합니다.
+ **사용자 지정 패치 기준** - 승인 및 거부된 패치 목록과 함께 릴리스 후 며칠 이내에 패치를 자동으로 승인하는 규칙을 정의합니다.
+ **여러 패치 적용 방법** - 특정 요구 사항에 적합하게 패치 정책, 유지 관리 기간 또는 온디맨드 '지금 패치' 작업 중에서 선택합니다.
+ **규정 준수 보고** - CSV 형식으로 Amazon S3 버킷으로 전송할 수 있는 패치 규정 준수 상태에 대한 세부 보고서를 생성합니다.
+ **교차 플랫폼 지원** -Windows Server, 다양한 Linux 배포판, macOS에서 운영 체제와 애플리케이션을 모두 패치합니다.
+ **일정 유연성** - 사용자 지정 CRON 또는 Rate 표현식을 사용하여 패치를 스캔하고 설치하기 위한 다양한 일정을 설정합니다.
+ **수명 주기 후크** - Systems Manager 문서를 사용하여 패치 작업 전후에 사용자 지정 스크립트를 실행합니다.
+ **보안 포커스** - 기본적으로 Patch Manager는 사용 가능한 모든 패치를 설치하는 대신 보안 관련 업데이트에 중점을 둡니다.
+ **속도 제어** - 운영 영향을 최소화하기 위해 패치 작업에 대한 동시성 및 오류 임곗값을 구성합니다.
## Patch Manager에서 규정 준수란 무엇인가요?
Systems Manager 플릿의 관리형 노드에 대한 *패치 규정 준수*를 구성하는 항목에 대한 벤치마크는 AWS, 운영 체제(OS) 공급업체 또는 보안 컨설팅 회사와 같은 타사에서 정의하지 않습니다.
대신 *패치 기준*에서 조직 또는 계정의 관리형 노드에 대한 패치 준수의 의미를 정의합니다. 패치 기준은 관리형 노드에 어떤 패치를 설치해야 하는지에 대한 규칙을 지정하는 구성입니다. 관리형 노드는 패치 기준에서 지정하는 승인 기준을 충족하는 모든 패치를 통해 최신 상태로 유지하면 패치를 준수하는 것입니다.
패치 기준을 *준수*한다고 해서 관리형 노드가 반드시 *안전*하다는 의미는 아닙니다. 규정 준수란 패치 기준에 의해 정의된 패치 중 *사용 가능*하고 *승인된* 패치가 노드에 설치되었음을 의미합니다. 관리형 노드의 전반적인 보안은 Patch Manager의 범위 밖의 여러 요인에 의해 결정됩니다. 자세한 내용은 [AWS Systems Manager의 보안](security.md) 섹션을 참조하세요.
각 패치 기준은 Red Hat Enterprise Linux(RHEL), macOS, Windows Server 등의 지원되는 특정 운영 체제(OS) 유형에 대한 구성입니다. 패치 기준은 지원되는 모든 OS 버전에 대한 패치 규칙을 정의하거나 RHEL 7.8. 및 RHEL 9.3과 같이 사용자가 지정한 버전으로만 제한할 수 있습니다.
패치 기준에서 특정 분류 및 심각도 수준의 모든 패치가 설치 승인을 받도록 지정할 수 있습니다. 예를 들어 `Security`로 분류된 모든 패치는 포함하되 `Bugfix`, `Enhancement` 등의 다른 분류는 제외할 수 있습니다. 또한 심각도가 `Critical`인 패치는 모두 포함하고 `Important` 및 `Moderate`인 다른 패치는 제외할 수 있습니다.
또한 승인 또는 거부할 특정 패치 목록에 패치의 ID를 추가하여 패치 기준에서 패치를 명시적으로 정의할 수 있습니다(예: Windows Server의 경우 `KB2736693`, Amazon Linux 2023(AL2023)의 경우 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`). 필요에 따라 패치가 제공된 후 패치 적용을 기다리는 일수를 지정할 수 있습니다. Linux 및 macOS의 경우 패치 기준 규칙에 정의된 패치 대신 규정 준수를 위한 외부 패치 목록(설치 재정의 목록)을 지정할 수 있습니다.
패치 작업이 실행되면 Patch Manager는 관리형 노드에 현재 적용된 패치를 패치 기준 또는 설치 재정의 목록에 설정된 규칙에 따라 적용해야 하는 패치와 비교합니다. Patch Manager가 누락된 패치에 대한 보고서만 표시하도록 선택하거나(`Scan` 작업), Patch Manager가 관리형 노드에서 누락된 모든 패치를 자동으로 설치하도록 선택할 수 있습니다(`Scan and install` 작업).
**참고**
패치 규정 준수 데이터는 가장 최근에 성공한 패치 작업의 특정 시점 스냅샷을 나타냅니다. 각 규정 준수 보고서에는 규정 준수 상태가 계산된 때를 식별하는 캡처 시간이 포함되어 있습니다. 규정 준수 데이터를 검토할 때 캡처 시간을 고려하여 작업이 예상대로 실행되었는지 확인합니다.
Patch Manager는 패치 작업에 사용할 수 있는 사전 정의된 패치 기준을 제공하지만, 이러한 사전 정의된 구성은 권장 모범 사례가 아닌 예제로 제공됩니다. 플릿에 대한 패치 규정 준수를 구성하는 항목을 더 잘 제어하려면 자체 사용자 지정 패치 기준을 생성하는 것이 좋습니다.
패치 기준에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md)
+ [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md)
+ [AWS가 미리 정의한 패치 기준 보기](patch-manager-view-predefined-patch-baselines.md)
+ [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md)
+ [패치 규정 준수 보고서 작업](patch-manager-compliance-reports.md)
## 주요 구성 요소
Patch Manager 도구 작업을 시작하기 전에 도구 패치 작업의 몇 가지 주요 구성 요소와 특성을 숙지해야 합니다.
**패치 기준**
Patch Manager는 승인 및 거부된 패치 목록(선택 사항)과 함께 릴리스 후 며칠 내에 패치를 자동 승인하는 규칙을 포함하는 *패치 기준선*을 사용합니다. 패치 작업이 실행되면 Patch Manager는 관리형 노드에 현재 적용된 패치를 패치 기준선에 설정된 규칙에 따라 적용해야 하는 패치와 비교합니다. Patch Manager가 누락된 패치에 대한 보고서만 표시하도록 선택하거나(`Scan` 작업), Patch Manager가 관리형 노드에서 누락된 모든 패치를 자동으로 설치하도록 선택할 수 있습니다(`Scan and install` 작업).
**패치 작업 방법**
Patch Manager는 현재 실행 `Scan` 및 `Scan and install` 작업을 위한 네 가지 방법을 제공합니다.
+ **(권장) Quick Setup에 구성된 패치 정책** - AWS Organizations와의 통합을 기반으로 하는 단일 패치 정책으로 여러 AWS 계정 계정 및 해당 계정을 운영하는 모든 AWS 리전 계정을 비롯하여 전체 조직의 패치 적용 일정과 패치 기준선을 정의할 수 있습니다. 패치 정책은 조직의 일부 조직 단위(OU)만 대상으로 할 수도 있습니다. 단일 패치 정책을 사용하여 다양한 일정에 따라 스캔하고 설치할 수 있습니다. 자세한 내용은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 및 [Quick Setup의 패치 정책 구성](patch-manager-policies.md)(을)를 참조하세요.
+ **Quick Setup에 구성된 호스트 관리 옵션** - 호스트 관리 구성도 AWS Organizations와의 통합을 통해 지원되므로, 최대 전체 조직을 대상으로 패치 작업을 실행할 수 있습니다. 단, 이 옵션은 현재 기본 패치 기준선을 사용하여 누락된 패치를 스캔하고 규정 준수 보고서에 결과를 제공하는 것으로 제한됩니다. 이 작업 방법으로 패치를 설치할 수는 없습니다. 자세한 내용은 [Quick Setup을 사용한 Amazon EC2 호스트 관리 설정](quick-setup-host-management.md) 섹션을 참조하세요.
+ **패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간** - Maintenance Windows라는 Systems Manager 도구에서 설정하는 유지 관리 기간은 사용자가 정의한 일정에 따라 다양한 유형의 태스크를 실행하도록 구성할 수 있습니다. Run Command 유형 태스크는 선택한 관리형 노드 세트에 대해 `Scan` 또는 `Scan and install` 태스크를 실행하는 데 사용할 수 있습니다. 각 유지 관리 기간 태스크는 단일 AWS 계정-AWS 리전 쌍의 관리형 노드만 대상으로 할 수 있습니다. 자세한 내용은 [자습서: 콘솔을 사용하여 패치를 위한 유지 관리 기간 생성](maintenance-window-tutorial-patching.md) 섹션을 참조하세요.
+ **Patch Manager의 주문형 **지금 패치** 작업** - **지금 패치** 옵션을 사용하면 관리형 노드에 최대한 빨리 패치를 적용해야 할 때 설정된 일정을 무시할 수 있습니다. **Patch now**(지금 패치)를 사용하여, `Scan` 또는 `Scan and install` 작업을 실행할지 여부와 작업을 실행할 대상 관리형 노드를 지정합니다. 패치 작업 중에 Systems Manager 문서(SSM 문서)를 수명 주기 후크로 실행하도록 선택할 수도 있습니다. 각각의 **Patch now**(지금 패치) 작업은 단일 AWS 계정-AWS 리전 쌍의 관리형 노드만 대상으로 할 수 있습니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
**규정 준수 보고**
`Scan`작업이 끝나면 Systems Manager 콘솔을 사용하여 어떤 관리형 노드가 패치 규정을 위반하지 않는지, 그리고 각 노드에서 어떤 패치가 누락되었는지에 대한 정보를 확인할 수 있습니다. 선택한 Amazon Simple Storage Service(S3) 버킷으로 전송되는 패치 규정 준수 보고서를 .csv 형식으로 생성할 수도 있습니다. 일회성 보고서를 생성하거나 정기적인 일정에 따라 보고서를 생성할 수 있습니다. 단일 관리형 노드의 경우 보고서에 노드에 대한 모든 패치의 세부 정보가 포함됩니다. 모든 관리형 노드에 대한 보고서의 경우 누락된 패치 수에 대한 요약만 제공됩니다. 보고서가 생성된 후 Amazon Quick과 같은 도구를 사용하여 데이터를 가져오고 분석할 수 있습니다. 자세한 내용은 [패치 규정 준수 보고서 작업](patch-manager-compliance-reports.md) 섹션을 참조하세요.
**참고**
패치 정책을 사용하여 생성된 규정 준수 항목의 실행 유형은 `PatchPolicy`입니다. 패치 정책 작업에서 생성도되지 않은 규정 준수 항목의 실행 유형은 `Command`입니다.
**통합**
Patch Manager는 다음과 같은 다른 AWS 서비스와 통합됩니다.
+ **AWS Identity and Access Management(IAM)** - IAM을 사용하여 Patch Manager 작업에 액세스할 수 있는 사용자, 그룹 및 역할을 제어할 수 있습니다. 자세한 내용은 [AWS Systems Manager에서 IAM을 사용하는 방식](security_iam_service-with-iam.md) 및 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
+ **AWS CloudTrail** - CloudTrail을 사용하여 사용자, 역할 또는 그룹에 의해 시작된 패치 작업 이벤트의 감사 가능한 기록을 기록할 수 있습니다. 자세한 내용은 [AWS CloudTrail를 사용하여 AWS Systems Manager API 호출 로깅](monitoring-cloudtrail-logs.md) 섹션을 참조하세요.
+ **AWS Security Hub CSPM** - Patch Manager에서 패치 규정 준수 데이터를 AWS Security Hub CSPM로 보낼 수 있습니다. Security Hub CSPM에서는 우선순위가 높은 보안 알림 및 규정 준수 상태를 포괄적으로 파악할 수 있습니다. 또한 플릿의 패치 상태를 모니터링합니다. 자세한 내용은 [Patch Manager와 AWS Security Hub CSPM 통합](patch-manager-security-hub-integration.md) 섹션을 참조하세요.
+ **AWS Config** - Patch Manager 대시보드에서 Amazon EC2 인스턴스 관리 데이터를 볼 수 있도록 AWS Config에서 기록을 설정합니다. 자세한 내용은 [패치 대시보드 요약 보기](patch-manager-view-dashboard-summaries.md) 섹션을 참조하세요.
**Topics**
+ [Patch Manager가 조직에 주는 이점은 무엇인가요?](#how-can-patch-manager-benefit-my-organization)
+ [Patch Manager는 누가 사용해야 하나요?](#who-should-use-patch-manager)
+ [Patch Manager의 주요 기능은 무엇입니까?](#what-are-the-main-features-of-patch-manager)
+ [Patch Manager에서 규정 준수란 무엇인가요?](#patch-manager-definition-of-compliance)
+ [주요 구성 요소](#primary-components)
+ [Quick Setup의 패치 정책 구성](patch-manager-policies.md)
+ [Patch Manager 필수 조건](patch-manager-prerequisites.md)
+ [Patch Manager 작업 작동 방식](patch-manager-patching-operations.md)
+ [관리형 노드 패치를 위한 SSM 명령 문서](patch-manager-ssm-documents.md)
+ [패치 기준](patch-manager-patch-baselines.md)
+ [Amazon Linux 2 관리형 노드에서 Kernel Live Patching 사용](patch-manager-kernel-live-patching.md)
+ [콘솔을 사용하여 Patch Manager 리소스 및 규정 준수 작업](patch-manager-console.md)
+ [AWS CLI를 사용하여 Patch Manager 리소스 작업](patch-manager-cli-commands.md)
+ [AWS Systems Manager Patch Manager 자습서](patch-manager-tutorials.md)
+ [Patch Manager 문제 해결](patch-manager-troubleshooting.md)
# Quick Setup의 패치 정책 구성
AWS에서는 *패치 정책*을 사용하여 조직 및 AWS 계정에 대한 패치 적용을 구성할 것을 권장합니다. 패치 정책은 2022년 12월 Patch Manager에 도입되었습니다.
패치 정책은 AWS Systems Manager의 도구인 Quick Setup을 사용하여 설정하는 구성입니다. 패치 정책은 이전 패치 구성 방법에서 제공되는 것보다 더 광범위하고 중앙 집중화된 패치 작업 제어 기능을 제공합니다. 패치 정책은 지원되는 Linux, macOS 및 Windows Server 버전을 포함하여 [Patch Manager에서 지원되는 모든 운영 체제](patch-manager-prerequisites.md#pm-prereqs)에서 사용할 수 있습니다. 정책 생성에 대한 자세한 지침은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 섹션을 참조하세요.
## 패치 정책의 주요 기능
노드를 패치하는 다른 방법을 사용하는 대신, 패치 정책을 사용하여 다음과 같은 주요 기능의 이점을 활용하세요.
+ **단일 설정** - 유지 관리 기간 또는 State Manager 연결을 사용하여 패치 작업을 설정하려면 Systems Manager 콘솔의 여러 부분에서 여러 태스크를 수행해야 할 수 있습니다. 패치 정책을 사용하면 모든 패치 작업을 단일 마법사에서 설정할 수 있습니다.
+ **다중 계정/다중 리전 지원** - Patch Manager에서 유지 관리 기간, State Manager 연결 또는 **Patch now**(지금 패치) 기능을 사용하면 단일 AWS 계정-AWS 리전 쌍의 관리형 노드에 대해서만 작업을 수행할 수 있습니다. 따라서 여러 계정과 여러 리전을 사용하는 경우, 각 계정-리전 쌍에서 설정 작업을 수행해야 하므로 설정 및 유지 관리 작업에 시간이 많이 소요될 수 있습니다. 반면, AWS Organizations를 사용하면 모든 AWS 리전에서 모든 AWS 계정의 모든 관리형 노드에 적용되는 단일 패치 정책을 설정할 수 있습니다. 또는 원하는 경우 계정 및 리전에서 선택한 일부 조직 단위(OU)에만 패치 정책을 적용할 수도 있습니다. 원하는 경우 패치 정책을 단일 로컬 계정에도 적용할 수 있습니다.
+ **조직 차원의 설치 지원** - Quick Setup의 기존 호스트 관리 구성 옵션은 관리형 노드의 패치 규정 준수를 매일 검사할 수 있도록 지원합니다. 하지만 이 검사은 미리 정해진 시간에 수행되며, 패치 규정 준수 정보만 제공합니다. 패치 설치 작업은 수행되지 않습니다. 패치 정책을 사용하여 다양한 스캐닝 및 설치 일정을 지정할 수 있습니다. 사용자 지정 CRON 또는 Rate 표현식을 사용하여 이들 작업의 빈도와 시간을 선택할 수도 있습니다. 예를 들어 매일 누락된 패치를 검사하여 정기적으로 업데이트되는 규정 준수 정보를 제공할 수 있습니다. 하지만 원치 않는 가동 중단을 방지하기 위해, 설치 일정을 일주일에 한 번으로 정할 수도 있습니다.
+ **간소화된 패치 기준선 선택** - 패치 정책에도 패치 기준선이 포함되어 있으며, 패치 기준선이 구성되는 방식에는 변화가 없습니다. 단, 패치 정책을 생성하거나 업데이트할 때, 각 운영 체제(OS) 유형에 사용할 AWS 관리형 기준선 또는 사용자 지정 기준선을 단일 목록에서 선택할 수 있습니다. 태스크마다 각 OS 유형에 대한 기본 기준선을 지정할 필요는 없습니다.
**참고**
패치 정책 실행을 기반으로 패치 작업을 수행할 때는 `AWS-RunPatchBaseline` SSM 문서를 사용합니다. 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
**관련 정보**
[Systems Manager Quick Setup을 사용하여 중앙에서 AWS 조직 전체에 패치 적용 작업 배포](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/)(AWS 클라우드 운영 및 마이그레이션 블로그)
## 패치 정책을 사용할 경우의 기타 차이점
이전 패치 구성 방법 대신 패치 정책을 사용할 때 주의해야 할 몇 가지 다른 차이점은 다음과 같습니다.
+ **패치 그룹이 필요 없음** - 이전 패치 작업에서는 패치 그룹에 속하도록 여러 노드에 태그를 지정한 다음, 해당 패치 그룹에 사용할 패치 기준선을 지정할 수 있었습니다. 패치 그룹이 없으면 Patch Manager가 OS 유형의 현재 기본 패치 기준선을 사용하여 인스턴스에 패치를 적용했습니다. 패치 정책을 사용하면 더 이상 패치 그룹을 설정하고 유지 관리할 필요가 없습니다.
**참고**
2022년 12월 22일에 패치 정책 지원이 릴리스될 당시에 패치 그룹을 사용하고 있지 않았던 계정-리전 페어에 대해서는 콘솔에서 패치 그룹 기능이 지원되지 않습니다. 이 날짜 이전에 패치 그룹을 사용하기 시작한 계정-리전 페어에서는 패치 그룹 기능을 계속 사용할 수 있습니다.
+ **'Configure patching(패치 구성)' 페이지 제거** - 패치 정책이 릴리스되기 전에는 **Configure patching**(패치 구성) 페이지에서 패치를 적용할 노드, 패치 일정 및 패치 작업에 대한 기본값을 지정할 수 있었습니다. 이 페이지가 Patch Manager에서 제거되었습니다. 이들 옵션은 이제 패치 정책에서 지정합니다.
+ **'Patch now(지금 패치)' 지원 안 함** - 온디맨드로 노드를 패치 기능은 여전히 한 번에 하나의 AWS 리전-AWS 계정 쌍으로 제한됩니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
+ **패치 정책 및 규정 준수 정보** - 패치 정책 구성에 따라 관리형 노드의 규정 준수를 검사하면, 규정 준수 데이터가 사용자에게 제공됩니다. 다른 규정 준수 검사 방법과 동일한 방식으로 데이터를 이 보고 관련 작업을 수행할 수 있습니다. 전체 조직 또는 여러 조직 단위에 대해 패치 정책을 설정할 수 있지만, 규정 준수 정보는 각 AWS 계정-AWS 리전 쌍에 대해 개별적으로 보고됩니다. 자세한 내용은 [패치 규정 준수 보고서 작업](patch-manager-compliance-reports.md) 섹션을 참조하세요.
+ **연결 규정 준수 상태 및 패치 정책**-Quick Setup 패치 정책이 적용되는 관리형 노드의 패치 상태는 해당 노드의 State Manager 연결 실행 상태와 일치합니다. 연결 실행 상태가 `Compliant`인 경우 관리형 노드의 패치 상태가 `Compliant`로 표시됩니다. 연결 실행 상태가 `Non-Compliant`인 경우 관리형 노드의 패치 상태가 `Non-Compliant`로 표시됩니다.
## 패치 정책이 지원되는 AWS 리전
Quick Setup의 패치 정책 구성은 현재 다음 리전에서 지원됩니다.
+ 미국 동부(오하이오)(us-east-2)
+ 미국 동부(버지니아 북부)(us-east-1)
+ 미국 서부(캘리포니아 북부)(us-west-1)
+ 미국 서부(오리건)(us-west-2)
+ 아시아 태평양(뭄바이)(ap-south-1)
+ 아시아 태평양(서울)(ap-northeast-2)
+ 아시아 태평양(싱가포르)(ap-southeast-1)
+ 아시아 태평양(시드니)(ap-southeast-2)
+ 아시아 태평양(도쿄)(ap-northeast-1)
+ 캐나다(중부)(ca-central-1)
+ 유럽(프랑크푸르트)(eu-central-1)
+ 유럽(아일랜드)(eu-west-1)
+ 유럽(런던) (eu-west-2)
+ 유럽(파리) (eu-west-3)
+ 유럽(스톡홀름)(eu-north-1)
+ 남아메리카(상파울루)(sa-east-1)
# Patch Manager 필수 조건
AWS Systems Manager의 도구인 Patch Manager를 사용하기 전에 필수 사전 조건을 충족했는지 확인합니다.
**Topics**
+ [SSM Agent 버전](#agent-versions)
+ [Python 버전](#python-version)
+ [추가 패키지 요구 사항](#additional-package-requirements)
+ [패치 소스에 대한 연결](#source-connectivity)
+ [S3 엔드포인트 액세스](#s3-endpoint-access)
+ [로컬에 패치를 설치할 수 있는 권한](#local-installation-permissions)
+ [Patch Manager에 지원되는 운영 체제](#supported-os)
## SSM Agent 버전
버전 2.0.834.0 이상의 SSM Agent가 Patch Manager로 관리형 노드에서 실행 중이어야 합니다.
**참고**
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) 페이지를 구독합니다.
## Python 버전
macOS 및 대부분의 리눅스 운영체제(OS)의 경우 Patch Manager에서는 현재 Python 버전 2.6\$13.12이 지원됩니다. AlmaLinux, Debian Server 및 Ubuntu Server OS에는 지원되는 Python 3 버전(3.0\$13.12)이 필요합니다.
## 추가 패키지 요구 사항
DNF 기반 운영 체제의 경우 리포지토리 정보 및 패치 파일의 압축을 풀려면 `zstd`, `xz` 및 `unzip` 유틸리티가 필요할 수 있습니다. DNF 기반 운영 체제에는 Amazon Linux 2023, Red Hat Enterprise Linux 8 이상 버전, Oracle Linux 8 이상 버전, Rocky Linux, AlmaLinux 및 CentOS 8 이상 버전이 포함됩니다. `unzip`이 없어 `No such file or directory: b'zstd'`, `No such file or directory: b'unxz'`, 패치 적용 실패 등과 유사한 오류가 표시되는 경우 이 유틸리티를 설치해야 합니다. `zstd`, `xz` 및 `unzip`은 다음을 실행하여 설치할 수 있습니다.
```
dnf install zstd xz unzip
```
## 패치 소스에 대한 연결
관리형 노드가 인터넷에 직접 연결되어 있지 않고 VPC 엔드포인트가 있는 Amazon Virtual Private Cloud(Amazon VPC)를 사용하는 경우 노드가 소스 패치 리포지토리에 액세스할 수 있는지 확인해야 합니다. Linux 노드에서 패치 업데이트는 일반적으로 노드에 구성된 원격 리포지토리에서 다운로드됩니다. 따라서, 노드에서 리포지토리에 연결할 수 있어야 패치를 적용할 수 있습니다. 자세한 내용은 [보안 패치 선택 방법](patch-manager-selecting-patches.md) 섹션을 참조하세요.
IPv6 전용 환경에서 실행 중인 노드에 패치를 적용할 때는 노드가 패치 소스에 연결되어 있는지 확인합니다. 패치 실행의 Run Command 출력을 확인하여 액세스할 수 없는 리포지토리에 대한 경고를 확인할 수 있습니다. DNF 기반 운영 체제의 경우 `/etc/dnf/dnf.conf`에서 `skip_if_unavailable` 옵션이 `True`로 설정되면 패치 적용 중에 사용할 수 없는 리포지토리를 건너뛰도록 구성할 수 있습니다. DNF 기반 운영 체제에는 Amazon Linux 2023, Red Hat Enterprise Linux 8 이상 버전, Oracle Linux 8 이상 버전, Rocky Linux, AlmaLinux 및 CentOS 8 이상 버전이 포함됩니다. Amazon Linux 2023에서는 `skip_if_unavailable` 옵션이 기본적으로 `True`로 설정됩니다.
**CentOS Stream: `EnableNonSecurity` 플래그 활성화**
CentOS Stream 노드는 업데이트 알림의 개념을 사용하는 패키지 관리자로 DNF를 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다.
하지만 CentOS Stream 기본 리포지토리는 업데이트 알림으로 구성되지 않습니다. 따라서 Patch Manager는 기본 CentOS Stream 리포지토리에서 패키지를 탐지하지 못합니다. Patch Manager가 업데이트 알림에 포함되지 않은 패키지를 처리하게 하려면 패치 기준 규칙에서 `EnableNonSecurity` 플래그를 설정해야 합니다.
**Windows Server: Windows Update 카탈로그 또는 Windows Server Update Services(WSUS)에 연결되었는지 확인합니다.**
Windows Server 관리형 노드는 Windows 업데이트 카탈로그 또는 Windows Server Update Services(WSUS)에 연결할 수 있어야 합니다. 노드가 인터넷 게이트웨이, NAT 게이트웨이 또는 NAT 인스턴스를 통해 [Microsoft Update 카탈로그](https://www.catalog.update.microsoft.com/home.aspx)에 연결되어 있는지 확인합니다. WSUS를 사용하는 경우 노드가 환경의 WSUS 서버에 연결되어 있는지 확인합니다. 자세한 내용은 [문제: 관리형 노드에 Windows 업데이트 카탈로그 또는 WSUS에 대한 액세스 권한이 없습니다.](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access) 섹션을 참조하세요.
## S3 엔드포인트 액세스
관리형 노드가 사설 네트워크에서 작동하는지 아니면 퍼블릭 네트워크에서 작동하는지에 관계없이 필수 AWS 관리형 Amazon Simple Storage Service(Amazon S3) 버킷에 액세스하지 못하면 패치 작업이 실패합니다. 관리형 노드가 액세스할 수 있어야 하는 S3 버킷에 대한 자세한 내용은 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 및 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md) 섹션을 참조하세요.
## 로컬에 패치를 설치할 수 있는 권한
Windows Server 및 Linux 운영 체제에서 Patch Manager는 패치를 설치하기 위해 각각 관리자 및 루트 사용자 계정을 수임합니다.
그러나 macOS에서 Brew 및 Brew Cask의 경우 Homebrew는 루트 사용자로 실행되는 명령을 지원하지 않습니다. 결과적으로 Patch Manager는 Homebrew 디렉터리의 소유자 또는 Homebrew 디렉터리의 소유자 그룹에 속하는 유효한 사용자로 Homebrew 명령을 쿼리하고 실행합니다. 따라서 패치를 설치하려면 `homebrew` 디렉터리의 소유자에게 `/usr/local` 디렉터리에 대한 재귀 소유자 권한도 필요합니다.
**작은 정보**
다음 명령은 지정된 사용자에게 이 권한을 제공합니다.
```
sudo chown -R $USER:admin /usr/local
```
## Patch Manager에 지원되는 운영 체제
Patch Manager 도구가 다른 Systems Manager 도구가 지원했던 동일한 운영 체제 버전을 모두 지원하지 않을 수 있습니다. Systems Manager에서 지원되는 운영 체제의 전체 목록은 [Systems Manager가 지원되는 운영 체제](operating-systems-and-machine-types.md#prereqs-operating-systems) 섹션을 참조하세요. 따라서 Patch Manager에서 사용하려는 관리형 노드에 다음 표에 나열된 운영 체제 중 하나를 실행 중인지 확인합니다.
**참고**
Patch Manager는 Windows용 Windows Update 카탈로그 및 Windows Server 업데이트 서비스와 같이 관리형 노드에 구성된 패치 리포지토리에 의존하여 설치 가능한 패치를 검색합니다. 따라서 EOL(For End of Life) 운영 체제 버전의 경우 사용 가능한 새 업데이트가 없으면 Patch Manager에서 새 업데이트를 보고하지 못할 수 있습니다. 이는 Linux 배포 관리자, Microsoft 또는 Apple에서 새 업데이트를 릴리스하지 않았기 때문이거나 관리형 노드에 새 업데이트에 액세스할 수 있는 적절한 라이선스가 없기 때문일 수 있습니다.
수명 종료(EOL)에 도달한 OS 버전은 사용하지 않는 것이 좋습니다. AWS를 포함한 OS 공급업체는 일반적으로 EOL에 도달한 버전의 보안 패치 또는 기타 업데이트를 제공하지 않습니다. EOL 시스템을 계속 사용하면 보안 수정 사항과 기타 운영 문제를 포함한 업그레이드를 적용할 수 없는 위험이 크게 증가합니다. AWS는 EOL에 도달한 OS 버전에서 Systems Manager 기능을 테스트하지 않습니다.
Patch Manager는 관리형 노드에서 사용 가능한 패치를 기준으로 규정 준수 상태를 보고합니다. 따라서 인스턴스가 EOL 운영 체제를 실행 중이고 사용 가능한 업데이트가 없는 경우 패치 작업에 대해 구성된 패치 기준에 따라 Patch Manager가 노드를 규정 준수 상태로 보고할 수 있습니다.
| 운영 체제 | 세부 정보 |
| --- | --- |
| Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-prerequisites.html) |
| macOS | *macOS는 Amazon EC2 인스턴스에서만 지원됩니다.* 13.0\$113.7(Ventura) 14*.x*(Sonoma) 15*.x*(Sequoia) macOS OS 업데이트 Patch Manager는 13.1\$113.2과 같은 macOS를 위한 운영 체제(OS) 업데이트 또는 업그레이드를 지원하지 않습니다. macOS에서 OS 버전 업데이트를 수행하려면 Apple에 내장된 OS 업그레이드 메커니즘을 사용하는 것이 좋습니다. 자세한 내용은 Apple 개발자 문서 웹사이트의 [장치 관리](https://developer.apple.com/documentation/devicemanagement)를 참조하세요. Homebrew 지원 Patch Manager에서는 오픈 소스 소프트웨어 패키지 관리 시스템인 Homebrew를 다음 기본 설치 위치 중 하나에 설치해야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-prerequisites.html) Homebrew가 설치되지 않은 경우 Patch Manager를 사용한 패치 적용 작업이 올바르게 작동하지 않습니다. 리전 지원 일부 AWS 리전에서는 macOS가 지원되지 않습니다. macOS용 Amazon EC2 지원에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 Mac 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)를 참조하세요. macOS 엣지 디바이스 AWS IoT Greengrass 코어 디바이스용 SSM Agent는 macOS에서 지원되지 않습니다. macOS 엣지 디바이스를 패치하기 위해 Patch Manager를 사용할 수 없습니다. |
| Windows | R2 버전을 포함하여 Windows Server 2012부터 Windows Server 2025까지 해당됩니다. AWS IoT Greengrass 코어 디바이스용 SSM Agent는 Windows 10에서 지원되지 않습니다. Windows 10 엣지 디바이스를 패치하기 위해 Patch Manager를 사용할 수 없습니다. Windows Server 2012 및 2012 R2 지원 Windows Server 2012 및 2012 R2는 2023년 10월 10일 이후로 지원이 종료되었습니다. 이러한 버전과 함께 Patch Manager를 사용하려면 Microsoft의 확장 보안 업데이트(ESU)도 사용하는 것이 좋습니다. 자세한 내용은 Microsoft 웹 사이트에서 [Windows Server 2012 및 2012 R2에 대한 지원 종료](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support)를 참조하세요. |
# 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)을 참조하세요.
# 관리형 노드 패치를 위한 SSM 명령 문서
이 주제에서는 보안과 관련된 최신 업데이트를 통해 관리형 노드를 계속 패치하는 데 활용할 수 있는 9개의 Systems Manager 문서(SSM 문서)에 대해 설명합니다.
패치 작업에서는 이들 문서 중 5개만 사용할 것을 권장하고 있습니다. 5개의 SSM 문서를 함께 참조하면 AWS Systems Manager를 사용한 다양한 패치 옵션에 대해 배울 수 있습니다. 이 문서 중 4개는 대체된 4개의 레거시 SSM 문서보다 나중에 발표되었으며 기능의 확장 또는 통합을 나타냅니다.
**패치 작업에 권장되는 SSM 문서**
패치 작업에서는 다음과 같은 5개의 SSM 문서를 사용할 것을 권장합니다.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**패치 작업을 위한 기존 SSM 문서**
다음 네 개의 레거시 SSM 문서는 일부 AWS 리전에서 계속 사용할 수 있지만 더 이상 업데이트되거나 지원되지 않습니다. 이러한 문서는 IPv6 환경에서 작동이 보장되지 않으며 IPv4만 지원합니다. 모든 시나리오에서 작동하도록 보장할 수 없으며 향후 지원이 중단될 수 있습니다. 패치 작업에 이러한 문서를 사용하지 않는 것이 좋습니다.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
IPv6만 지원하는 환경에서 패치 작업을 설정하는 단계는 [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md) 섹션을 참조하세요.
패치 적용 작업 시 이러한 SSM 문서를 사용하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.
**Topics**
+ [관리형 노드 패치를 위한 권장 SSM 문서 정보](#patch-manager-ssm-documents-recommended)
+ [관리형 노드 패치를 위한 SSM 레거시](#patch-manager-ssm-documents-legacy)
+ [관리형 노드 패치를 위한 SSM 문서의 알려진 제한 사항](#patch-manager-ssm-documents-known-limitations)
+ [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [`AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation`에 InstallOverrideList 파라미터를 사용하기 위한 샘플 시나리오](patch-manager-override-lists.md)
+ [BaselineOverride 파라미터 사용](patch-manager-baselineoverride-parameter.md)
## 관리형 노드 패치를 위한 권장 SSM 문서 정보
관리형 노드 패치 작업에서는 다음과 같은 5개의 SSM 문서를 사용할 것을 권장합니다.
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
기본적인 Windows Update 기능을 구성하고 이들을 사용하여 업데이트를 자동 설치하거나 자동 업데이트를 해제할 수 있도록 돕습니다. 모든 AWS 리전에서 사용 가능합니다.
이 SSM 문서에서는 Windows 업데이트에게 지정된 업데이트를 다운로드 및 설치하고 필요에 따라 관리형 노드를 재부팅할 것을 요구합니다. AWS Systems Manager의 도구인 State Manager에서 이 문서를 사용하여 Windows Update에서 구성을 유지할 수 있습니다. 또한 AWS Systems Manager의 도구인 Run Command를 사용하여 이를 수동으로 실행하여 Windows 업데이트 구성을 변경할 수도 있습니다.
이 문서에서 사용 가능한 파라미터는 설치할 업데이트의 범주나 자동 업데이트의 해제 여부를 지정하는 것은 물론이고, 패치 작업이 실행되는 요일과 시간을 지정할 수 있도록 지원합니다. 이 SSM 문서는 Windows 업데이트를 엄격하게 제어할 필요가 없고 규정 준수 정보를 수집할 필요가 없는 경우에 매우 유용합니다.
**기존 SSM 문서 대체: **
+ *없음*
### `AWS-InstallWindowsUpdates`
Windows Server 관리형 노드에 업데이트를 설치합니다. 모든 AWS 리전에서 사용 가능합니다.
이 SSM 문서는 특정 업데이트를 설치하고 싶은 경우(`Include Kbs` 파라미터 사용), 또는 특정 분류 또는 범주에 따라 패치를 설치하되, 패치 규정 준수 정보가 필요하지 않은 경우에 기본적인 패치 기능을 제공합니다.
**기존 SSM 문서 대체:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
3개의 레거시 문서는 서로 다른 역할을 수행하지만, 최신 SSM 문서인 `AWS-InstallWindowsUpdates`에서는 서로 다른 파라미터 설정을 사용해도 동일한 결과를 얻을 수 있습니다. 이러한 파라미터 설정은 [관리형 노드 패치를 위한 SSM 레거시](#patch-manager-ssm-documents-legacy)에 설명되어 있습니다.
### `AWS-RunPatchBaseline`
관리형 노드에 패치를 설치하거나 노드를 스캔하여 기준에 부합하는 패치의 누락 여부를 판단합니다. 모든 AWS 리전에서 사용 가능합니다.
`AWS-RunPatchBaseline`을 사용하면 운영 체제 유형에 대해 "기본값"으로 지정된 패치 기준을 사용하여 패치 승인을 제어할 수 있습니다. Systems Manager Compliance 도구를 사용하여 확인할 수 있는 패치 규정 준수 정보를 보고합니다. 이러한 도구들은 어떤 노드에서 패치가 누락되었는지, 어떤 패치가 누락되었는지와 같이 관리형 노드의 패치 규정 준수 상태에 대한 통찰력을 제공합니다. `AWS-RunPatchBaseline`을 사용하면 `PutInventory` API 명령을 사용하여 패치 규정 준수 정보가 기록됩니다. Linux 운영 체제의 경우 관리형 노드에 구성된 기본 소스 리포지토리와 사용자 지정 패치 기준에서 지정한 대체 소스 리포지토리의 패치에 대한 규정 준수 정보가 제공됩니다. 대체 소스 리포지토리에 대한 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요. Systems Manager Compliance 도구에 대한 자세한 내용은 [AWS Systems Manager Compliance](systems-manager-compliance.md) 섹션을 참조하세요.
**기존 문서 대체:**
+ `AWS-ApplyPatchBaseline`
레거시 문서 `AWS-ApplyPatchBaseline`은 Windows Server 관리형 노드에만 적용되며 애플리케이션 패치를 지원하지 않습니다. 최신 버전의 `AWS-RunPatchBaseline`은 Windows 및 Linux 시스템 모두를 동일하게 지원합니다. `AWS-RunPatchBaseline` 문서를 사용하려면 SSM Agent 버전 2.0.834.0 이상이 필요합니다.
`AWS-RunPatchBaseline` SSM 문서에 대한 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
### `AWS-RunPatchBaselineAssociation`
인스턴스에 패치를 설치하거나 인스턴스를 스캔하여 기준에 부합하는 패치의 누락 여부를 판단합니다. 모든 상용 AWS 리전에서 사용 가능합니다.
`AWS-RunPatchBaselineAssociation`은 다음과 같은 몇 가지 중요한 면에서 `AWS-RunPatchBaseline`과 다릅니다.
+ `AWS-RunPatchBaselineAssociation`은 주로 AWS Systems Manager의 도구인 Quick Setup을 사용하여 생성된 State Manager 연결에 사용하도록 만들어졌습니다. 특히 Quick Setup 호스트 관리 구성 유형을 사용하는 경우, **Scan instances for missing patches daily**(매일 인스턴스에서 누락된 패치 스캔) 옵션을 선택하면 작업에 `AWS-RunPatchBaselineAssociation`이 사용됩니다.
그러나 대부분의 경우 패치 작업을 직접 설정할 때 `AWS-RunPatchBaselineAssociation` 대신 [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 또는 [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)를 선택해야 합니다.
자세한 내용은 다음 주제를 참조하세요.
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation`은 실행 시 대상 집합에 사용할 패치 기준 식별을 위해 태그 사용을 지원합니다.
+ `AWS-RunPatchBaselineAssociation`을 사용하는 패치 작업의 경우 패치 규정 준수 데이터는 특정 State Manager 연결 측면에서 컴파일됩니다. `AWS-RunPatchBaselineAssociation` 실행 시 수집된 패치 규정 준수 데이터는 `PutInventory` 명령 대신 `PutComplianceItems` API 명령을 사용하여 기록됩니다. 이렇게 하면 이 특정 연결과 연결되지 않은 규정 준수 데이터를 덮어쓰는 것을 방지할 수 있습니다.
Linux 운영 체제의 경우 인스턴스에 구성된 기본 소스 리포지토리와 사용자 지정 패치 기준에서 지정한 대체 소스 리포지토리의 패치에 대한 규정 준수 정보가 제공됩니다. 대체 소스 리포지토리에 대한 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요. Systems Manager Compliance 도구에 대한 자세한 내용은 [AWS Systems Manager Compliance](systems-manager-compliance.md) 섹션을 참조하세요.
**기존 문서 대체:**
+ **없음**
`AWS-RunPatchBaselineAssociation` SSM 문서에 대한 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) 섹션을 참조하세요.
### `AWS-RunPatchBaselineWithHooks`
관리형 노드에 패치를 설치하거나 노드를 스캔하여 패치 주기 동안 세 지점에서 SSM 문서를 실행하는 데 사용할 수 있는 옵션 후크로 정규화된 패치의 누락 여부를 판단합니다. 모든 상용 AWS 리전에서 사용 가능합니다. macOS에서는 지원되지 않습니다.
`AWS-RunPatchBaselineWithHooks`는 `Install` 작업에 있어 `AWS-RunPatchBaseline`과 다릅니다.
`AWS-RunPatchBaselineWithHooks`는 관리형 노드 패치 중 지정된 지점에서 실행되는 수명 주기 후크를 지원합니다. 패치 설치 시 관리형 노드를 재부팅해야 하는 경우가 있기 때문에 패치 작업은 사용자 정의 기능을 지원하는 총 3개의 후크에 대한 2개의 이벤트로 나뉩니다. 첫 번째 후크는 `Install with NoReboot` 작업 전입니다. 두 번째 후크는 `Install with NoReboot` 작업 후입니다. 세 번째 후크는 노드 재부팅 후 사용할 수 있습니다.
**기존 문서 대체:**
+ **없음**
`AWS-RunPatchBaselineWithHooks` SSM 문서에 대한 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) 섹션을 참조하세요.
## 관리형 노드 패치를 위한 SSM 레거시
다음과 같은 4개의 SSM 문서는 일부 AWS 리전에서 계속 사용할 수 있습니다. 그러나 더 이상 업데이트되지 않으며 향후 지원되지 않을 수 있기 때문에 사용하지 않는 것이 좋습니다. 대신에 [관리형 노드 패치를 위한 권장 SSM 문서 정보](#patch-manager-ssm-documents-recommended)에 설명되어 있는 문서를 사용하세요.
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
Windows Server 관리형 노드만 지원하지만, 이를 대체하는 `AWS-RunPatchBaseline`에 있는 패치 애플리케이션에 대한 지원은 포함하지 않습니다. 2017년 8월 이후에 출시된 AWS 리전에서는 사용할 수 없습니다.
**참고**
이 SSM 문서 `AWS-RunPatchBaseline`을 대체하려면 버전 2.0.834.0 이상의 SSM Agent가 필요합니다. `AWS-UpdateSSMAgent` 문서를 사용하여 최신 버전의 에이전트로 관리형 노드를 업데이트할 수 있습니다.
### `AWS-FindWindowsUpdates`
`AWS-InstallWindowsUpdates`에 의해 대체되지만, 동일한 모든 작업을 수행할 수 있습니다. 2017년 4월 이후에 출시된 AWS 리전에서는 사용할 수 없습니다.
이 레거시 SSM 문서에서와 동일한 결과를 얻으려면 권장되는 대체 문서인 `AWS-InstallWindowsUpdates`에서 다음과 같이 파라미터 구성을 사용합니다.
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
`AWS-InstallWindowsUpdates`에 의해 대체되지만, 동일한 모든 작업을 수행할 수 있습니다. 2017년 4월 이후에 출시된 AWS 리전에서는 사용할 수 없습니다.
이 레거시 SSM 문서에서와 동일한 결과를 얻으려면 권장되는 대체 문서인 `AWS-InstallWindowsUpdates`에서 다음과 같이 파라미터 구성을 사용합니다.
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
`AWS-InstallWindowsUpdates`에 의해 대체되지만, 동일한 모든 작업을 수행할 수 있습니다. 2017년 4월 이후에 출시된 AWS 리전에서는 사용할 수 없습니다.
이 레거시 SSM 문서에서와 동일한 결과를 얻으려면 권장되는 대체 문서인 `AWS-InstallWindowsUpdates`에서 다음과 같이 파라미터 구성을 사용합니다.
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *KB 문서를 쉼표로 분리한 목록*
## 관리형 노드 패치를 위한 SSM 문서의 알려진 제한 사항
### 외부 재부팅 중단
패치 설치 중에 노드의 시스템에서 재부팅을 시작하는 경우(예: 펌웨어 또는 SecureBoot와 같은 기능에 업데이트를 적용하기 위해) 패치가 성공적으로 설치되었더라도 패치 문서 실행이 중단되고 실패로 표시될 수 있습니다. 이는 SSM 에이전트가 외부 재부팅에서 문서 실행 상태를 유지하고 재개할 수 없기 때문에 발생합니다.
실행 실패 후 패치 설치 상태를 확인하려면 `Scan` 패치 작업을 실행한 다음 패치 관리자의 패치 규정 준수 데이터를 확인하여 현재 규정 준수 상태를 평가합니다.
# 패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`
AWS Systems Manager는 AWS Systems Manager의 도구인 Patch Manager용 Systems Manager 문서(SSM 문서)인 `AWS-RunPatchBaseline`를 지원합니다. 이 SSM 문서는 보안 관련 업데이트 및 기타 유형의 업데이트 모두에 대해 관리형 노드에서 패치 작업을 수행합니다. 문서가 실행될 때 패치 그룹이 지정되지 않은 경우 운영 체제 유형에 대해 "기본값"으로 지정된 패치 기준을 사용합니다 그렇지 않으면 패치 그룹과 연결된 패치 기준을 사용합니다. 패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
문서 `AWS-RunPatchBaseline`을 사용하면 운영 체제와 애플리케이션 모두를 패치할 수 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.)
이 문서는 Linux, macOS, 및 Windows Server관리형 노드를 지원합니다. 문서에서 각 플랫폼에 적합한 작업을 수행합니다.
**참고**
Patch Manager는 레거시 SSM 문서 `AWS-ApplyPatchBaseline`도 지원합니다. 단, 이 문서는 Windows 관리형 노드에 대한 패치 적용 작업만 지원합니다. `AWS-RunPatchBaseline`이 Linux, macOS 및 Windows Server 관리형 노드 모두에서 패치 작업을 지원하므로 이를 대신 사용하는 것이 좋습니다. `AWS-RunPatchBaseline` 문서를 사용하려면 SSM Agent 버전 2.0.834.0 이상이 필요합니다.
------
#### [ Windows Server ]
Windows Server 관리형 노드에서는 `AWS-RunPatchBaseline` 문서가 PowerShell 모듈을 다운로드하고 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷에는 Windows Server Update Services(WSUS) 서버에 대해 패치 기준을 쿼리하여 컴파일된 승인된 패치 목록이 포함되어 있습니다. 이 목록은 Windows Update API에 전달되며, 이 API가 승인된 패치를 적절하게 다운로드하고 설치하는 작업을 제어합니다.
------
#### [ Linux ]
Linux 관리형 노드에서는 `AWS-RunPatchBaseline` 문서가 Python 모듈을 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷은 정의된 규칙과 승인 및 차단된 패치 목록을 사용하여 각 노드 유형에 적합한 패키지 관리자를 실행합니다.
+ Amazon Linux 2, Oracle Linux 및 RHEL 7 관리형 노드는 YUM을 사용합니다. YUM 작업의 경우 `Python 2.6` 이상의 지원되는 버전(2.6\$13.12)이 Patch Manager에 필요합니다. Amazon Linux 2023은 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다.
+ RHEL 8 관리형 노드는 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다. (두 버전 모두 RHEL 8에 기본적으로 설치되어 있지 않습니다. 둘 중 하나를 수동으로 설치해야 합니다.)
+ Debian Server 및 Ubuntu Server 인스턴스는 APT를 사용합니다. APT 작업의 경우 지원되는 `Python 3` 버전(3.0\$13.12)이 Patch Manager에 필요합니다.
------
#### [ macOS ]
macOS 관리형 노드에서는 `AWS-RunPatchBaseline` 문서가 Python 모듈을 호출합니다. 그런 다음, 해당 인스턴스에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 다음으로 Python 하위 프로세스는 노드에서 AWS Command Line Interface(AWS CLI)를 호출하여 지정된 패키지 관리자에 대한 설치 및 업데이트 정보를 검색하고 각 업데이트 패키지에 대해 적절한 패키지 관리자를 구동합니다.
------
각 스냅샷은 AWS 계정, 패치 그룹, 운영 체제 및 스냅샷 ID에 따라 다릅니다. 스냅샷은 스냅샷 생성 후 24시간이 지나면 만료되는 미리 서명된 Amazon Simple Storage Service(Amazon S3) URL을 통해 전송됩니다. 그러나 URL이 만료된 후 동일한 스냅샷 콘텐츠를 다른 관리형 노드에 적용하려는 경우 스냅샷이 생성된 후 최대 3일 이내에 미리 서명된 Amazon S3 URL을 새로 생성할 수 있습니다. 이렇게 하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 명령을 사용합니다.
승인되고 적용 가능한 모든 업데이트가 설치되고 필요한 만큼 재부팅이 수행되면, 패치 규정 준수 정보가 관리형 노드에 생성되며 Patch Manager에 다시 보고됩니다.
**참고**
`AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.
패치 규정 준수 데이터를 보는 방법에 대한 자세한 내용은 [패치 규정 준수 정보](compliance-about.md#compliance-monitor-patch) 섹션을 참조하세요.
## `AWS-RunPatchBaseline` 파라미터
`AWS-RunPatchBaseline`는 6개 파라미터를 지원합니다. `Operation` 파라미터가 필요합니다. `InstallOverrideList`, `BaselineOverride` 및 `RebootOption` 파라미터는 선택 항목입니다. `Snapshot-ID`는 엄밀히 말해 옵션이지만, 유지 관리 기간 이외에서 `AWS-RunPatchBaseline`을 실행하는 경우 이에 대한 사용자 정의 값을 제공하여, 유지 관리 기간 작업 동안에 문서가 실행되는 경우 Patch Manager가 값을 자동으로 제공하도록 하는 것이 좋습니다.
**Topics**
+ [파라미터 이름: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [파라미터 이름: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [파라미터 이름: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [파라미터 이름: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [파라미터 이름: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [파라미터 이름: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### 파라미터 이름: `Operation`
**사용 여부**: 필수.
**옵션**: `Scan` \$1 `Install`.
스캔
`Scan` 옵션을 선택하는 경우 `AWS-RunPatchBaseline`에 따라 관리형 노드의 패치 규정 준수 상태가 결정되며 이 정보가 Patch Manager에게 다시 보고됩니다. `Scan`은 업데이트를 설치하거나 관리형 노드를 재부팅하라는 메시지를 표시하지 않습니다. 대신, 작업이 승인되고 노드에 적용 가능한 업데이트가 누락된 위치를 식별해 줍니다.
설치
`Install` 옵션을 선택하는 경우 `AWS-RunPatchBaseline`이 관리형 노드에서 누락된 승인되고 적용 가능한 업데이트를 설치하려고 시도합니다. `Install` 작업의 일부로 생성된 패치 규정 준수 정보에는 누락된 업데이트가 나열되지 않지만, 어떠한 이유로든 업데이트 설치가 성공하지 못하면 실패 상태에 있는 업데이트를 보고할 수 있습니다. 관리형 노드에 업데이트가 설치될 때마다 업데이트가 설치되었는지 및 활성 상태인지를 확인하기 위해 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
Patch Manager가 관리형 노드를 업데이트하기 *전에* 기준 규칙에 의해 지정된 패치가 설치된 경우 시스템이 예상대로 재부팅되지 않을 수도 있습니다. 이는 패치가 사용자에 의해 수동으로 설치되어 있거나 Ubuntu Server의 `unattended-upgrades` 패키지와 같은 다른 프로그램에 의해 자동으로 설치되어 있는 경우에 발생할 수 있습니다.
### 파라미터 이름: `AssociationId`
**사용 여부**: 선택.
`AssociationId`는 AWS Systems Manager의 도구인 State Manager에 있는 기존 연결의 ID입니다. 이 ID는 Patch Manager에서 지정된 연결에 규정 준수 데이터를 추가하는 데 사용됩니다. 이 연결은 의 [Quick Setup에서 패치 정책에 설정한](quick-setup-patch-manager.md) 패치 작업과 관련이 있습니다.
**참고**
`AWS-RunPatchBaseline`을 사용하면 패치 정책 기준선 재정의와 함께 `AssociationId` 값이 제공될 경우, 패치 적용이 `PatchPolicy` 작업으로 수행되며, `AWS:ComplianceItem`에 보고되는 `ExecutionType` 값도 `PatchPolicy`가 됩니다. `AssociationId` 값이 제공되지 않으면, 패치 적용이 `Command` 작업으로 수행되며 제출된 `AWS:ComplianceItem`에 대해 보고되는 `ExecutionType` 값도 `Command`가 됩니다.
사용하려는 연결이 아직 없는 경우 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 명령을 실행하여 하나를 생성할 수 있습니다.
### 파라미터 이름: `Snapshot ID`
**사용 여부**: 선택.
`Snapshot ID`는 Patch Manager가 단일 작업으로 패치된 관리형 노드 집합 모두가 승인된 패치 집합과 정확히 일치하는지를 확인하기 위해 사용하는 고유 ID(GUID)입니다. 이 파라미터가 옵션으로 정의되어 있긴 하지만, 다음 표에 설명된 대로 유지 관리 기간에서 `AWS-RunPatchBaseline`를 실행하는지 여부에 따라 모범 사례 권장 사항이 달라집니다.
**`AWS-RunPatchBaseline` 모범 사례**
| Mode | 모범 사례 | 세부 정보 |
| --- | --- | --- |
| 유지 관리 기간 내 AWS-RunPatchBaseline 실행 | 스냅샷 ID를 제공하지 않습니다. Patch Manager가 제공합니다. | 유지 관리 기간을 사용하여 `AWS-RunPatchBaseline`을 실행하는 경우 자체 생성한 스냅샷 ID를 제공해선 안 됩니다. 이러한 경우에는 Systems Manager가 유지 관리 기간 실행 ID를 기반으로 GUID 값을 제공합니다. 이렇게 하면 해당 유지 관리 기간에 모든 `AWS-RunPatchBaseline` 호출에 올바른 ID가 사용됩니다. 이러한 경우에 값을 지정하는 경우 패치 기준선의 스냅샷이 3일 이상 적용되지 않을 수 있습니다. 해당 시간 경과 후에는 스냅샷 만료 후 동일한 ID를 지정하더라도 새로운 스냅샷이 생성됩니다. |
| 유지 관리 기간 외 AWS-RunPatchBaseline 실행 | 스냅샷 ID에 대해 사용자 정의 GUID 값을 생성하고 지정합니다.¹ | `AWS-RunPatchBaseline`을 실행하는 데 유지 관리 기간을 사용하고 있지 않은 경우 각 패치 기준에 대해 고유한 스냅샷 ID를 생성하고 지정하는 것이 좋습니다. 특히 동일한 작업에서 여러 관리형 노드에 `AWS-RunPatchBaseline` 문서를 실행하고 있는 경우 더욱 그러합니다. 이러한 경우에 ID를 지정하지 않으면 Systems Manager가 명령을 보내는 각 관리형 노드에 다른 스냅샷 ID를 생성합니다. 이렇게 되면 관리형 노드 간에 다양한 패치 집합이 지정될 수 있습니다. 예를 들어 AWS Systems Manager의 도구인 Run Command를 통해 직접 `AWS-RunPatchBaseline` 문서를 실행하고 50개의 관리형 노드로 이루어진 그룹을 대상으로 한다고 가정해 보겠습니다. 사용자 지정 스냅샷 ID를 지정하면 모든 노드를 평가하고 패치를 적용하는 데 사용되는 기준 스냅샷이 하나가 생성되어 일관적인 상태를 유지하도록 해줍니다. |
| ¹ GUID를 생성할 수 있는 도구라면 어떤 도구를 사용해서든 스냅샷 ID 파라미터의 값을 생성할 수 있습니다. 예를 들어 PowerShell의 경우 `New-Guid` cmdlet을 사용하여 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 형식으로 GUID를 생성할 수 있습니다. |
### 파라미터 이름: `InstallOverrideList`
**사용 여부**: 선택.
`InstallOverrideList`를 사용하면 설치하려는 패치 목록에 대해 https URL 또는 Amazon S3 경로 스타일 URL을 지정할 수 있습니다. YAML 형식으로 관리되는 이 패치 설치 목록은 현재 기본 패치 기준으로 지정된 패치를 재정의합니다. 그러면 관리형 노드에 설치되는 패치를 세부적으로 제어할 수 있습니다.
**중요**
`InstallOverrideList` 파일 이름에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자를 포함할 수 없습니다.
`InstallOverrideList` 파라미터를 사용할 때의 패치 작업 동작은 Linux 및 macOS 관리형 노드와 Windows Server 관리형 노드가 다릅니다. Linux 및 macOS에서는 Patch Manager가 패치가 패치 기준 규칙과 일치하는지 여부와 관계없이 노드에 활성화된 모든 리포지토리의 `InstallOverrideList` 패치 목록에 포함된 패치를 적용하려고 시도합니다. 그러나 Windows Server 노드에서는 `InstallOverrideList` 패치 목록의 패치가 패치 기준 규칙과도 일치하는 경우에만 적용됩니다.
규정 준수 보고서에서는 `InstallOverrideList` 패치 목록에 지정된 항목이 아니라 패치 기준선에 지정된 항목에 따라 패치 상태를 반영합니다. 다시 말해 스캔 작업에서 `InstallOverrideList` 파라미터를 무시합니다. 그래야만 규정 준수 보고서에서 특정 패치 적용 작업에 대해 승인된 내용이 아닌 정책에 따라 패치 상태를 일관되게 반영합니다.
**참고**
IPv6만 사용하는 노드에 패치를 적용할 때는 제공된 URL에 노드에서 연결할 수 있는지 확인합니다. SSM Agent 구성 옵션 `UseDualStackEndpoint`가 `true`로 설정된 경우 S3 URL이 제공될 때 듀얼 스택 S3 클라이언트가 사용됩니다. 듀얼 스택을 사용하도록 에이전트를 구성하는 방법에 대한 자세한 내용은 [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md) 섹션을 참조하세요.
`InstallOverrideList` 파라미터를 사용하여 단일 패치 기준을 계속 사용하면서 서로 다른 유형의 유지 관리 기간 일정에 따라 대상 그룹에 서로 다른 유형의 패치를 적용하는 방법에 대한 설명은 [`AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation`에 InstallOverrideList 파라미터를 사용하기 위한 샘플 시나리오](patch-manager-override-lists.md) 섹션을 참조하세요.
**유효한 URL 형식**
**참고**
파일이 공개적으로 사용 가능한 버킷에 저장된 경우 https URL 형식 또는 Amazon S3 경로 스타일 URL을 지정할 수 있습니다. 파일이 프라이빗 버킷에 저장된 경우 Amazon S3 경로 스타일 URL을 지정해야 합니다.
+ **https URL 형식**:
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon S3 경로 스타일 URL**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**유효한 YAML 콘텐츠 형식**
목록에서 패치를 지정하는 데 사용되는 형식은 관리형 노드의 운영 체제에 따라 다릅니다. 일반적인 형식은 다음과 같습니다.
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
YAML 파일에 추가 필드를 제공할 수 있지만 해당 필드는 패치 작업 중에 무시됩니다.
또한 S3 버킷에서 목록을 추가하거나 업데이트하기 전에 YAML 파일 형식이 올바른지 확인하는 것이 좋습니다. YAML 형식에 대한 자세한 내용은 [yaml.org](http://www.yaml.org)를 참조하세요. 유효한 도구 옵션을 보려면 웹에서 "yaml format validators"를 검색하세요.
------
#### [ Linux ]
**id**
**id** 필드는 필수입니다. 패키지 이름 및 아키텍처를 사용하여 패치를 지정하는 데 사용됩니다. 예를 들면 `'dhclient.x86_64'`입니다. id에서 와일드카드를 사용하여 여러 패키지를 나타낼 수 있습니다. 예를 들면 `'dhcp*'` 및 `'dhcp*1.*'` 등입니다.
**Title**
**title** 필드는 선택 사항이지만 Linux 시스템의 경우 이 필드는 추가 필터링 기능을 제공합니다. **title**을 사용할 경우 패키지 버전 정보를 다음 중 한 가지 형식으로 포함해야 합니다.
YUM/SUSE Linux Enterprise Server(SLES):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Linux 패치 제목의 경우 임의의 위치에서 하나 이상의 와일드카드를 사용하여 패키지 일치 수를 확장할 수 있습니다. 예를 들면 `'*32:9.8.2-0.*.rc1.57.amzn1'`입니다.
예:
+ apt 패키지 버전 1.2.25가 관리형 노드에 현재 설치되어 있지만 버전 1.2.27을 지금 사용할 수 있습니다.
+ apt.amd64 버전 1.2.27을 패치 목록에 추가합니다. apt utils.amd64 버전 1.2.27을 사용하지만 apt-utils.amd64 버전 1.2.25가 목록에 지정되어 있습니다.
이 경우 apt 버전 1.2.27은 설치 시 차단되고 “Failed-NonCompliant”로 보고됩니다.
------
#### [ Windows Server ]
**id**
**id** 필드는 필수입니다. id 필드는 Microsoft Knowledge Base ID(예: KB2736693)와 Microsoft Security Bulletin ID(예: MS17-023)를 사용하여 패치를 지정하는 데 사용됩니다.
Windows에 대한 패치 목록에 제공하려는 다른 필드는 선택 사항이며 정보 제공의 목적으로만 사용됩니다. **title**, **classification**, **severity** 등과 같은 추가 필드를 사용하여 지정된 패치에 대한 자세한 정보를 제공할 수 있습니다.
------
#### [ macOS ]
**id**
**id** 필드는 필수입니다. **id** 필드의 값은 `{package-name}.{package-version}` 형식 또는 \$1package\$1name\$1 형식을 사용하여 제공할 수 있습니다.
------
**샘플 패치 목록**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### 파라미터 이름: `RebootOption`
**사용 여부**: 선택.
**옵션**: `RebootIfNeeded` \$1 `NoReboot`
**기본값**: `RebootIfNeeded`
**주의**
기본 옵션은 `RebootIfNeeded`입니다. 사용 사례에 맞는 올바른 옵션을 선택해야 합니다. 예를 들어 구성 프로세스를 완료하기 위해 관리형 노드를 즉시 재부팅해야 하는 경우, `RebootIfNeeded`를 선택합니다. 또는 예약된 재부팅 시간까지 관리형 노드 가용성을 유지해야 하는 경우, `NoReboot`을 선택합니다.
**중요**
Amazon EMR(이전 명칭: Amazon Elastic MapReduce)에서 클러스터 인스턴스 패치를 적용하는 데는 Patch Manager를 사용하지 않는 것이 좋습니다. 특히 `RebootOption` 파라미터에 `RebootIfNeeded` 옵션을 선택하지 마세요. (이 옵션은 `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` 및 `AWS-RunPatchBaselineWithHooks` 패치 적용에 대한 SSM 명령 문서에서 제공되지 않습니다.)
Patch Manager를 사용하는 패치 적용에 대한 기본 명령에서는 `yum` 및 `dnf` 명령을 사용합니다. 따라서 패키지 설치 방식 때문에 작업이 호환되지 않을 수 있습니다. Amazon EMR 클러스터의 소프트웨어 업데이트용으로 기본 설정된 방법에 대한 자세한 내용은 **Amazon EMR 관리 안내서의 [Amazon EMR용 기본 AMI 사용](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)을 참조하세요.
RebootIfNeeded
`RebootIfNeeded` 옵션을 선택하면 다음과 같은 경우 관리형 노드가 재부팅됩니다.
+ Patch Manager가 하나 이상의 패치를 설치했습니다.
Patch Manager가 패치에 재부팅이 *필요*한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.
+ Patch Manager가 `Install` 작업 중 `INSTALLED_PENDING_REBOOT` 상태의 패치를 하나 이상 감지합니다.
`INSTALLED_PENDING_REBOOT` 상태는 `Install` 작업이 마지막으로 실행될 때 `NoReboot` 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.
이 두 가지 경우에 관리형 노드를 재부팅하면 업데이트된 패키지가 메모리에서 플러시되고 모든 운영 체제에서 패치 및 재부팅 동작이 일관되게 유지됩니다.
NoReboot
`NoReboot` 옵션을 선택하면 Patch Manager가 `Install` 작업 중에 패치를 설치한 경우에도 관리형 노드를 재부팅하지 않습니다. 이 옵션은 패치된 후 관리형 노드를 재부팅할 필요가 없다는 것을 알고 있거나 패치 작업 재부팅으로 인해 중단되지 않아야 하는 노드에서 실행되는 애플리케이션 또는 프로세스가 있는 경우에 유용합니다. 유지 관리 기간을 사용하는 등 관리형 노드 재부팅 시간을 보다 정확하게 제어하려는 경우에도 유용합니다.
`NoReboot` 옵션을 선택하고 패치가 설치되면 패치에 `InstalledPendingReboot` 상태가 할당됩니다. 그러나 관리형 노드 자체는 `Non-Compliant`로 표시됩니다. 재부팅이 발생하고 `Scan` 작업이 실행되면 관리형 노드 상태가 `Compliant`로 업데이트됩니다.
`NoReboot` 옵션은 운영 체제 수준의 재시작만 막습니다. 서비스 수준 재시작은 패치 프로세스의 일부로 계속 이루어질 수 있습니다. 예를 들어 Docker가 업데이트되면 Amazon Elastic Container Service와 같은 종속 서비스는 `NoReboot`가 활성화되어도 자동으로 다시 시작될 수 있습니다. 중단해서는 안 되는 중요한 서비스가 있는 경우 서비스에서 인스턴스를 일시적으로 제거하거나 유지 관리 기간 동안 패치 적용을 예약하는 등의 추가 조치를 고려하세요.
**패치 설치 추적 파일(Patch installation tracking file)**: 패치 설치, 특히 마지막 시스템 재부팅 이후에 설치된 패치를 추적하기 위해 Systems Manager는 관리형 노드에서 파일을 유지 관리합니다.
**중요**
추적 파일을 삭제하거나 수정하지 않습니다. 이 파일이 삭제되거나 손상된 경우 관리형 노드에 대한 패치 준수 보고서가 부정확하게 됩니다. 이 경우 노드를 재부팅하고 패치 스캔 작업을 실행하여 파일을 복원합니다.
이 추적 파일은 관리형 노드의 다음 위치에 저장됩니다.
+ Linux 운영 체제:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 운영 체제:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### 파라미터 이름: `BaselineOverride`
**사용 여부**: 선택.
`BaselineOverride` 파라미터를 사용하여 런타임에 패치 기본 설정을 정의할 수 있습니다. 이 기준 재정의는 S3 버킷에서 JSON 객체로 유지됩니다. 이는 패치 작업이 기본 패치 기준의 규칙을 적용하는 대신 호스트 운영 체제와 일치하는 제공된 기준을 사용하도록 합니다.
**중요**
`BaselineOverride` 파일 이름에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자를 포함할 수 없습니다.
`BaselineOverride` 파라미터 사용 방법에 대한 자세한 내용은 [BaselineOverride 파라미터 사용](patch-manager-baselineoverride-parameter.md) 섹션을 참조하세요.
### 파라미터 이름: `StepTimeoutSeconds`
**사용 여부**: 필수.
명령이 실패로 간주되기 전에 완료되어야 할 시간(초)으로, 1초\$136,000초(10시간) 사이여야 합니다.
# 패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`
`AWS-RunPatchBaseline` 문서와 마찬가지로 `AWS-RunPatchBaselineAssociation`은 보안 관련 업데이트 및 기타 유형의 업데이트 모두에 대해 인스턴스에서 패치 작업을 수행합니다. 문서 `AWS-RunPatchBaselineAssociation`을 사용하면 운영 체제와 애플리케이션 모두를 패치할 수도 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.)
이 문서는 Linux, macOS 및 Windows Server용 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 지원합니다. [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 노드는 지원되지 않습니다. 이 문서는 Linux 및 macOS 인스턴스에서 Python 모듈을 호출하고 Windows 인스턴스에서 PowerShell 모듈을 호출하여 각 플랫폼에 대해 적절한 작업을 수행합니다.
그러나 `AWS-RunPatchBaselineAssociation`은 다음과 같은 점에서 `AWS-RunPatchBaseline`과 다릅니다.
+ `AWS-RunPatchBaselineAssociation`은 주로 AWS Systems Manager의 도구인 [Quick Setup](systems-manager-quick-setup.md)을 사용하여 생성된 State Manager 연결에 사용하도록 만들어졌습니다. 특히 Quick Setup 호스트 관리 구성 유형을 사용하는 경우, **Scan instances for missing patches daily**(매일 인스턴스에서 누락된 패치 스캔) 옵션을 선택하면 작업에 `AWS-RunPatchBaselineAssociation`이 사용됩니다.
그러나 대부분의 경우 패치 작업을 직접 설정할 때 `AWS-RunPatchBaselineAssociation` 대신 [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 또는 [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)를 선택해야 합니다.
+ `AWS-RunPatchBaselineAssociation` 문서를 사용할 때 문서의 `BaselineTags` 파라미터 필드에 태그 키 페어를 지정할 수 있습니다. AWS 계정의 사용자 정의 패치 기준이 이러한 태그를 공유하는 경우 AWS Systems Manager의 도구인 Patch Manager는 운영 체제 유형에 대해 현재 지정된 ‘기본’ 패치 기준 대신 대상 인스턴스에서 실행할 때 태그가 지정된 기준을 사용합니다.
**참고**
Quick Setup을 사용하여 설정한 작업 이외의 패치 작업에서 `AWS-RunPatchBaselineAssociation`을 사용하도록 선택하고 옵션 `BaselineTags` 파라미터를 사용하려면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 [인스턴스 프로파일](setup-instance-permissions.md)에 몇 가지 추가 권한을 제공해야 합니다. 자세한 내용은 [파라미터 이름: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags) 섹션을 참조하세요.
다음 두 형식 모두 `BaselineTags` 파라미터에 대해 유효합니다.
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**중요**
태그 키 및 값에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자가 포함될 수 없습니다.
+ `AWS-RunPatchBaselineAssociation` 실행 시 `AWS-RunPatchBaseline`에서 사용하는 `PutInventory` 명령 대신 `PutComplianceItems` API 명령을 사용하여 수집된 패치 규정 준수 데이터가 기록됩니다. 이 차이는 특정 *연결*별로 저장 및 보고되는 패치 규정 준수 정보를 의미합니다. 이 연결 외부에서 생성된 패치 규정 준수 데이터는 덮어쓰지 않습니다.
+ `AWS-RunPatchBaselineAssociation` 실행 후 보고되는 패치 규정 준수 정보는 인스턴스가 준수하는지 여부를 나타냅니다. 다음 AWS Command Line Interface(AWS CLI) 명령의 출력에서 알 수 있듯이 패치 수준 세부 정보는 포함되지 않습니다. 이 명령은 `Association`을 규정 준수 유형으로 필터링합니다.
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
태그 키 페어 값이 `AWS-RunPatchBaselineAssociation` 문서의 파라미터로 지정된 경우 Patch Manager는 운영 체제 유형과 일치하고 동일한 태그 키 페어로 태그가 지정된 사용자 정의 패치 기준을 검색합니다. 이 검색은 현재 지정된 기본 패치 기준 또는 패치 그룹에 할당된 기준으로 제한되지 않습니다. 지정된 태그에 기준이 없으면 `AWS-RunPatchBaselineAssociation`을 실행하는 명령에 패치 그룹이 지정된 경우 Patch Manager는 다음으로 패치 그룹을 찾습니다. 일치하는 패치 그룹이 없으면 Patch Manager는 운영 체제 계정의 현재 기본 패치 기준으로 폴백합니다.
`AWS-RunPatchBaselineAssociation` 문서에 지정된 태그와 함께 둘 이상의 패치 기준이 발견되면 Patch Manager는 작업을 계속하기 위해 해당 키-값 페어로 하나의 패치 기준에만 태그를 지정할 수 있음을 나타내는 오류 메시지를 반환합니다.
**참고**
Linux 노드에서는 각 노드 유형에 대한 적절한 패키지 관리자가 패키지를 설치하는 데 사용됩니다.
Amazon Linux 2, Oracle Linux 및 RHEL 인스턴스는 YUM을 사용합니다. YUM 작업의 경우 `Python 2.6` 이상의 지원되는 버전(2.6\$13.12)이 Patch Manager에 필요합니다. Amazon Linux 2023은 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다.
Debian Server 및 Ubuntu Server 인스턴스는 APT를 사용합니다. APT 작업의 경우 지원되는 `Python 3` 버전(3.0\$13.12)이 Patch Manager에 필요합니다.
검사가 완료된 후 또는 승인되고 적용 가능한 모든 업데이트가 설치된 후 필요에 따라 재부팅이 수행되면 패치 규정 준수 정보가 인스턴스에서 생성되고 Patch Compliance 서비스에 다시 보고됩니다.
**참고**
`AWS-RunPatchBaselineAssociation` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 인스턴스가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption) 섹션을 참조하세요.
패치 규정 준수 데이터를 보는 방법에 대한 자세한 내용은 [패치 규정 준수 정보](compliance-about.md#compliance-monitor-patch) 섹션을 참조하세요.
## `AWS-RunPatchBaselineAssociation` 파라미터
`AWS-RunPatchBaselineAssociation`은 5개 파라미터를 지원합니다 `Operation` 및 `AssociationId` 파라미터가 필요합니다. `InstallOverrideList`, `RebootOption` 및 `BaselineTags` 파라미터는 옵션입니다.
**Topics**
+ [파라미터 이름: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [파라미터 이름: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [파라미터 이름: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [파라미터 이름: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### 파라미터 이름: `Operation`
**사용 여부**: 필수.
**옵션**: `Scan` \$1 `Install`.
스캔
`Scan` 옵션을 선택하는 경우 `AWS-RunPatchBaselineAssociation`에 따라 인스턴스의 패치 규정 준수 상태가 결정되며 이 정보가 Patch Manager에게 다시 보고됩니다. `Scan`은 업데이트를 설치하거나 인스턴스를 재부팅하라는 메시지를 표시하지 않습니다. 대신, 승인되고 인스턴스에 적용 가능한 업데이트가 누락된 위치를 식별해 줍니다.
설치
`Install` 옵션을 선택하는 경우 `AWS-RunPatchBaselineAssociation`이 인스턴스에서 누락된 승인되고 적용 가능한 업데이트를 설치하려고 시도합니다. `Install` 작업의 일부로 생성된 패치 규정 준수 정보에는 누락된 업데이트가 나열되지 않지만, 어떠한 이유로든 업데이트 설치가 성공하지 못하면 실패 상태에 있는 업데이트를 보고할 수 있습니다. 인스턴스에 업데이트가 설치될 때마다 업데이트가 설치되었는지 및 활성 상태인지를 확인하기 위해 인스턴스가 재부팅됩니다. (예외: `AWS-RunPatchBaselineAssociation` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 인스턴스가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption) 섹션을 참조하세요.)
Patch Manager가 인스턴스를 업데이트하기 *전에* 기준 규칙에 의해 지정된 패치가 설치된 경우 시스템이 예상대로 재부팅되지 않을 수도 있습니다. 이는 패치가 사용자에 의해 수동으로 설치되어 있거나 Ubuntu Server의 `unattended-upgrades` 패키지와 같은 다른 프로그램에 의해 자동으로 설치되어 있는 경우에 발생할 수 있습니다.
### 파라미터 이름: `BaselineTags`
**사용 여부**: 선택.
`BaselineTags`는 사용자가 선택하여 개별 사용자 정의 패치 기준에 할당하는 고유한 태그 키-값 페어입니다. 이 파라미터에 대해 값을 하나 이상 지정할 수 있습니다. 다음 형식이 모두 유효합니다.
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**중요**
태그 키 및 값에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자가 포함될 수 없습니다.
`BaselineTags` 값은 Patch Manager가 단일 작업으로 패치된 인스턴스 집합 모두가 승인된 패치 집합과 정확히 일치하는지를 확인하기 위해 사용합니다. 패치 작업이 실행될 때 Patch Manager는 운영 체제 유형에 대한 패치 기준에 사용자가 `BaselineTags`에 대해 지정한 동일한 키-값 페어로 태그가 지정되었는지 확인합니다. 일치 항목이 있는 경우 이 사용자 정의 패치 기준이 사용됩니다. 일치 항목이 없는 경우 패치 작업에 대해 지정된 패치 그룹에 따라 패치 기준이 식별됩니다. 아무 것도 없는 경우 해당 운영 체제에 대해 미리 정의된 AWS 관리형 패치 기준이 사용됩니다.
**추가 권한 요구 사항**
Quick Setup을 사용하여 설정한 작업 이외의 패치 작업에서 `AWS-RunPatchBaselineAssociation`을 사용하는 경우 옵션 `BaselineTags` 파라미터를 사용하려면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 [인스턴스 프로파일](setup-instance-permissions.md)에 다음 권한을 제공해야 합니다.
**참고**
Quick Setup 및 `AWS-RunPatchBaselineAssociation`은 온프레미스 서버와 가상 머신(VM)을 지원하지 않습니다.
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
*patch-baseline-arn*을 `arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE` 형식으로 액세스를 제공하려는 패치 기준의 Amazon 리소스 이름(ARN)으로 바꿉니다.
### 파라미터 이름: `AssociationId`
**사용 여부**: 필수.
`AssociationId`는 AWS Systems Manager의 도구인 State Manager에 있는 기존 연결의 ID입니다. 이 ID는 Patch Manager에서 지정된 연결에 규정 준수 데이터를 추가하는 데 사용됩니다. 이 연결은 [Quick Setup에서 생성한 호스트 관리 구성](quick-setup-host-management.md)에 활성화되어 있는 패치 `Scan` 작업과 관련이 있습니다. 패치 결과를 인벤토리 규정 준수 데이터 대신 연결 규정 준수 데이터로 전송하면 패치 작업 후 또는 다른 연결 ID에 대해 인스턴스의 기존 인벤토리 규정 준수 정보를 덮어쓰지 않습니다. 사용하려는 연결이 아직 없는 경우 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 명령을 실행하여 하나를 생성할 수 있습니다. 예제:
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows Server ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### 파라미터 이름: `InstallOverrideList`
**사용 여부**: 선택.
`InstallOverrideList`를 사용하여 설치하려는 패치 목록에 대해 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 지정합니다. YAML 형식으로 관리되는 이 패치 설치 목록은 현재 기본 패치 기준으로 지정된 패치를 재정의합니다. 그러면 인스턴스에 설치되는 패치를 세부적으로 제어할 수 있습니다.
**중요**
`InstallOverrideList` 파일 이름에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자를 포함할 수 없습니다.
`InstallOverrideList` 파라미터를 사용할 때의 패치 작업 동작은 Linux 및 macOS 관리형 노드와 Windows Server 관리형 노드가 다릅니다. Linux 및 macOS에서는 Patch Manager가 패치가 패치 기준 규칙과 일치하는지 여부와 관계없이 노드에 활성화된 모든 리포지토리의 `InstallOverrideList` 패치 목록에 포함된 패치를 적용하려고 시도합니다. 그러나 Windows Server 노드에서는 `InstallOverrideList` 패치 목록의 패치가 패치 기준 규칙과도 일치하는 경우에만 적용됩니다.
규정 준수 보고서에서는 `InstallOverrideList` 패치 목록에 지정된 항목이 아니라 패치 기준선에 지정된 항목에 따라 패치 상태를 반영합니다. 다시 말해 스캔 작업에서 `InstallOverrideList` 파라미터를 무시합니다. 그래야만 규정 준수 보고서에서 특정 패치 적용 작업에 대해 승인된 내용이 아닌 정책에 따라 패치 상태를 일관되게 반영합니다.
**유효한 URL 형식**
**참고**
파일이 공개적으로 사용 가능한 버킷에 저장된 경우 https URL 형식 또는 Amazon S3 경로 스타일 URL을 지정할 수 있습니다. 파일이 프라이빗 버킷에 저장된 경우 Amazon S3 경로 스타일 URL을 지정해야 합니다.
+ **https URL 형식 예시**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon S3 경로 스타일 URL 예시**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**유효한 YAML 콘텐츠 형식**
목록에서 패치를 지정하는 데 사용되는 형식은 인스턴스의 운영 체제에 따라 다릅니다. 일반적인 형식은 다음과 같습니다.
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
YAML 파일에 추가 필드를 제공할 수 있지만 해당 필드는 패치 작업 중에 무시됩니다.
또한 S3 버킷에서 목록을 추가하거나 업데이트하기 전에 YAML 파일 형식이 올바른지 확인하는 것이 좋습니다. YAML 형식에 대한 자세한 내용은 [yaml.org](http://www.yaml.org)를 참조하세요. 유효한 도구 옵션을 보려면 웹에서 "yaml format validators"를 검색하세요.
+ Microsoft Windows
**id**
**id** 필드는 필수입니다. id 필드는 Microsoft Knowledge Base ID(예: KB2736693)와 Microsoft Security Bulletin ID(예: MS17-023)를 사용하여 패치를 지정하는 데 사용됩니다.
Windows에 대한 패치 목록에 제공하려는 다른 필드는 선택 사항이며 정보 제공의 목적으로만 사용됩니다. **title**, **classification**, **severity** 등과 같은 추가 필드를 사용하여 지정된 패치에 대한 자세한 정보를 제공할 수 있습니다.
+ Linux
**id**
**id** 필드는 필수입니다. 패키지 이름 및 아키텍처를 사용하여 패치를 지정하는 데 사용됩니다. 예를 들면 `'dhclient.x86_64'`입니다. id에서 와일드카드를 사용하여 여러 패키지를 나타낼 수 있습니다. 예를 들면 `'dhcp*'` 및 `'dhcp*1.*'` 등입니다.
**제목**
**title** 필드는 선택 사항이지만 Linux 시스템의 경우 이 필드는 추가 필터링 기능을 제공합니다. **title**을 사용할 경우 패키지 버전 정보를 다음 중 한 가지 형식으로 포함해야 합니다.
YUM/Red Hat Enterprise Linux(RHEL):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Linux 패치 제목의 경우 임의의 위치에서 하나 이상의 와일드카드를 사용하여 패키지 일치 수를 확장할 수 있습니다. 예를 들면 `'*32:9.8.2-0.*.rc1.57.amzn1'`입니다.
예:
+ apt 패키지 버전 1.2.25가 인스턴스에 현재 설치되어 있지만 버전 1.2.27을 지금 사용할 수 있습니다.
+ apt.amd64 버전 1.2.27을 패치 목록에 추가합니다. apt utils.amd64 버전 1.2.27을 사용하지만 apt-utils.amd64 버전 1.2.25가 목록에 지정되어 있습니다.
이 경우 apt 버전 1.2.27은 설치 시 차단되고 “Failed-NonCompliant”로 보고됩니다.
**기타 필드**
Linux에 대한 패치 목록에 제공하려는 다른 필드는 선택 사항이며 정보 제공의 목적으로만 사용됩니다. **classification**, **severity** 등과 같은 추가 필드를 사용하여 지정된 패치에 대한 자세한 정보를 제공할 수 있습니다.
**샘플 패치 목록**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### 파라미터 이름: `RebootOption`
**사용 여부**: 선택.
**옵션**: `RebootIfNeeded` \$1 `NoReboot`
**기본값**: `RebootIfNeeded`
**주의**
기본 옵션은 `RebootIfNeeded`입니다. 사용 사례에 맞는 올바른 옵션을 선택해야 합니다. 예를 들어 구성 프로세스를 완료하기 위해 인스턴스를 즉시 재부팅해야 하는 경우, `RebootIfNeeded`를 선택합니다. 또는 예약된 재부팅 시간까지 인스턴스 가용성을 유지해야 하는 경우, `NoReboot`를 선택합니다.
**중요**
`NoReboot` 옵션은 운영 체제 수준의 재시작만 막습니다. 서비스 수준 재시작은 패치 프로세스의 일부로 계속 이루어질 수 있습니다. 예를 들어 Docker가 업데이트되면 Amazon Elastic Container Service와 같은 종속 서비스는 `NoReboot`가 활성화되어도 자동으로 다시 시작될 수 있습니다. 중단해서는 안 되는 중요한 서비스가 있는 경우 서비스에서 인스턴스를 일시적으로 제거하거나 유지 관리 기간 동안 패치 적용을 예약하는 등의 추가 조치를 고려하세요.
**중요**
Amazon EMR(이전 명칭: Amazon Elastic MapReduce)에서 클러스터 인스턴스 패치를 적용하는 데는 Patch Manager를 사용하지 않는 것이 좋습니다. 특히 `RebootOption` 파라미터에 `RebootIfNeeded` 옵션을 선택하지 마세요. (이 옵션은 `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` 및 `AWS-RunPatchBaselineWithHooks` 패치 적용에 대한 SSM 명령 문서에서 제공되지 않습니다.)
Patch Manager를 사용하는 패치 적용에 대한 기본 명령에서는 `yum` 및 `dnf` 명령을 사용합니다. 따라서 패키지 설치 방식 때문에 작업이 호환되지 않을 수 있습니다. Amazon EMR 클러스터의 소프트웨어 업데이트용으로 기본 설정된 방법에 대한 자세한 내용은 **Amazon EMR 관리 안내서의 [Amazon EMR용 기본 AMI 사용](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)을 참조하세요.
RebootIfNeeded
`RebootIfNeeded` 옵션을 선택하면 다음과 같은 경우 인스턴스가 재부팅됩니다.
+ Patch Manager가 하나 이상의 패치를 설치했습니다.
Patch Manager가 패치에 재부팅이 *필요*한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.
+ Patch Manager가 `Install` 작업 중 `INSTALLED_PENDING_REBOOT` 상태의 패치를 하나 이상 감지합니다.
`INSTALLED_PENDING_REBOOT` 상태는 `Install` 작업이 마지막으로 실행될 때 `NoReboot` 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.
이 두 가지 경우에 인스턴스를 재부팅하면 업데이트된 패키지가 메모리에서 플러시되고 모든 운영 체제에서 패치 및 재부팅 동작이 일관되게 유지됩니다.
NoReboot
`NoReboot` 옵션을 선택하면 Patch Manager가 `Install` 작업 중에 패치를 설치한 경우에도 인스턴스를 재부팅하지 않습니다. 이 옵션은 패치된 후 인스턴스를 재부팅할 필요가 없다는 것을 알고 있거나 패치 작업 재부팅으로 인해 중단되지 않아야 하는 인스턴스에서 실행되는 애플리케이션 또는 프로세스가 있는 경우에 유용합니다. 유지 관리 기간을 사용하는 등 인스턴스 재부팅 시간을 보다 정확하게 제어하려는 경우에도 유용합니다.
[**패치 설치 추적 파일(Patch installation tracking file)**]: 패치 설치, 특히 마지막 시스템 재부팅 이후에 설치된 패치를 추적하기 위해 Systems Manager는 관리형 인스턴스에서 파일을 유지 관리합니다.
**중요**
추적 파일을 삭제하거나 수정하지 않습니다. 이 파일이 삭제되거나 손상된 경우 인스턴스에 대한 패치 준수 보고서가 부정확하게 됩니다. 이 경우 인스턴스를 재부팅하고 패치 스캔 작업을 실행하여 파일을 복원합니다.
이 추적 파일은 관리형 인스턴스의 다음 위치에 저장됩니다.
+ Linux 운영 체제:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 운영 체제:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# 패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager는 AWS Systems Manager의 도구인 Patch Manager용 Systems Manager 문서(SSM 문서)인 `AWS-RunPatchBaselineWithHooks`를 지원합니다. 이 SSM 문서는 보안 관련 업데이트 및 기타 유형의 업데이트 모두에 대해 관리형 노드에서 패치 작업을 수행합니다.
`AWS-RunPatchBaselineWithHooks`는 다음과 같은 점에서 `AWS-RunPatchBaseline`과 다릅니다.
+ **래퍼 문서** - `AWS-RunPatchBaselineWithHooks`는 `AWS-RunPatchBaseline`의 래퍼이며 일부 작업에 대해 `AWS-RunPatchBaseline`에 의존합니다.
+ **`Install` 작업** – `AWS-RunPatchBaselineWithHooks`은 관리형 노드 패치 중 지정된 지점에서 실행되는 수명 주기 후크를 지원합니다. 패치 설치 시 관리형 노드를 재부팅해야 하는 경우가 있기 때문에 패치 작업은 사용자 정의 기능을 지원하는 총 3개의 후크에 대한 2개의 이벤트로 나뉩니다. 첫 번째 후크는 `Install with NoReboot` 작업 전입니다. 두 번째 후크는 `Install with NoReboot` 작업 후입니다. 세 번째 후크는 관리형 노드 재부팅 후 사용할 수 있습니다.
+ **사용자 정의 패치 목록 지원 없음** - `AWS-RunPatchBaselineWithHooks`가 `InstallOverrideList` 파라미터를 지원하지 않습니다.
+ **SSM Agent 지원** - `AWS-RunPatchBaselineWithHooks`이 SSM Agent를 사용하려면 패치할 관리형 노드에 3.0.502 이상 버전이 설치되어 있어야 합니다.
문서가 실행될 때 패치 그룹이 지정되지 않은 경우 운영 체제 유형에 대해 "기본값"으로 현재 지정된 패치 기준을 사용합니다 그렇지 않으면 패치 그룹과 연결된 패치 기준을 사용합니다. 패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
문서 `AWS-RunPatchBaselineWithHooks`을 사용하면 운영 체제와 애플리케이션 모두를 패치할 수 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.)
이 문서는 Linux 및 Windows Server 관리형 노드를 지원합니다. 문서에서 각 플랫폼에 적합한 작업을 수행합니다.
**참고**
`AWS-RunPatchBaselineWithHooks`는 macOS에서 지원되지 않습니다.
------
#### [ Linux ]
Linux 관리형 노드에서는 `AWS-RunPatchBaselineWithHooks` 문서가 Python 모듈을 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷은 정의된 규칙과 승인 및 차단된 패치 목록을 사용하여 각 노드 유형에 적합한 패키지 관리자를 실행합니다.
+ Amazon Linux 2, Oracle Linux 및 RHEL 7 관리형 노드는 YUM을 사용합니다. YUM 작업의 경우 `Python 2.6` 이상의 지원되는 버전(2.6\$13.12)이 Patch Manager에 필요합니다. Amazon Linux 2023은 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다.
+ RHEL 8 관리형 노드는 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다. (두 버전 모두 RHEL 8에 기본적으로 설치되어 있지 않습니다. 둘 중 하나를 수동으로 설치해야 합니다.)
+ Debian Server 및 Ubuntu Server 인스턴스는 APT를 사용합니다. APT 작업의 경우 지원되는 `Python 3` 버전(3.0\$13.12)이 Patch Manager에 필요합니다.
------
#### [ Windows Server ]
Windows Server 관리형 노드에서는 `AWS-RunPatchBaselineWithHooks` 문서가 PowerShell 모듈을 다운로드하고 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷에는 Windows Server Update Services(WSUS) 서버에 대해 패치 기준을 쿼리하여 컴파일된 승인된 패치 목록이 포함되어 있습니다. 이 목록은 Windows Update API에 전달되며, 이 API가 승인된 패치를 적절하게 다운로드하고 설치하는 작업을 제어합니다.
------
각 스냅샷은 AWS 계정, 패치 그룹, 운영 체제 및 스냅샷 ID에 따라 다릅니다. 스냅샷은 스냅샷 생성 후 24시간이 지나면 만료되는 미리 서명된 Amazon Simple Storage Service(Amazon S3) URL을 통해 전송됩니다. 그러나 URL이 만료된 후 동일한 스냅샷 콘텐츠를 다른 관리형 노드에 적용하려는 경우 스냅샷이 생성된 후 최대 3일 이내에 미리 서명된 Amazon S3 URL을 새로 생성할 수 있습니다. 이렇게 하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 명령을 사용합니다.
승인되고 적용 가능한 모든 업데이트가 설치되고 필요한 만큼 재부팅이 수행되면, 패치 규정 준수 정보가 관리형 노드에 생성되며 Patch Manager에 다시 보고됩니다.
`AWS-RunPatchBaselineWithHooks` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.
**중요**
`NoReboot` 옵션을 사용하면 운영 체제가 재시작되지 않지만 특정 패키지가 업데이트될 때 발생할 수 있는 서비스 수준 재시작을 막지는 않습니다. 예를 들어 Docker와 같은 패키지를 업데이트하면 `NoReboot`가 지정된 경우에도 종속 서비스(예: 컨테이너 오케스트레이션 서비스)가 자동으로 재시작될 수 있습니다.
패치 규정 준수 데이터를 보는 방법에 대한 자세한 내용은 [패치 규정 준수 정보](compliance-about.md#compliance-monitor-patch) 섹션을 참조하세요.
## `AWS-RunPatchBaselineWithHooks` 운영 단계
`AWS-RunPatchBaselineWithHooks`가 실행되면 다음 단계가 수행됩니다.
1. **스캔** - `AWS-RunPatchBaseline`을 사용하는 `Scan` 작업이 관리형 노드에서 실행되고 규정 준수 보고서가 생성되고 업로드됩니다.
1. **로컬 패치 상태 확인** - 선택한 작업과 1단계의 `Scan` 결과를 기반으로 수행할 단계를 결정하기 위해 스크립트가 실행됩니다.
1. 선택한 작업이 `Scan`이면 작업이 완료된 것으로 표시됩니다. 작업이 종료됩니다.
1. 선택한 작업이 `Install`이면 Patch Manager는 1단계의 `Scan` 결과를 평가하여 다음에 실행할 작업을 결정합니다.
1. 누락된 패치가 발견되지 않고 보류 중인 재부팅이 필요하지 않으면 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.
1. 누락된 패치가 발견되지 않았지만 보류 중인 재부팅이 필요하고 선택한 재부팅 옵션이`NoReboot`이면 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.
1. 그렇지 않으면 작업은 다음 단계로 진행됩니다.
1. **패치 전 후크 작업** - 첫 번째 수명 주기 후크인 `PreInstallHookDocName`에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.
1. **NoReboot로 설치** - 재부팅 옵션이 `NoReboot`이고 `AWS-RunPatchBaseline`을 사용하는 `Install` 작업이 관리형 노드에서 실행되고 규정 준수 보고서가 생성되어 업로드됩니다.
1. **설치 후 후크 작업** - 두 번째 수명 주기 후크인 `PostInstallHookDocName`에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.
1. **재부팅 확인** - 관리형 노드에 재부팅이 필요한지 여부와 실행할 단계를 결정하기 위해 스크립트가 실행됩니다.
1. 선택한 재부팅 옵션이 `NoReboot`인 경우 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.
1. 선택한 재부팅 옵션이 `RebootIfNeeded`인 경우 Patch Manager는 4단계에서 수집된 인벤토리에서 필요한 보류 중인 재부팅이 있는지 확인합니다. 즉, 작업이 7단계로 계속 진행되고 다음과 같은 경우 관리형 노드가 재부팅됩니다.
1. Patch Manager가 하나 이상의 패치를 설치한 경우(Patch Manager가 패치에 재부팅이 필요한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.)
1. Patch Manager가 설치 작업 중 `INSTALLED_PENDING_REBOOT` 상태의 패치를 하나 이상 감지합니다. `INSTALLED_PENDING_REBOOT` 상태는 설치 작업이 마지막으로 실행될 때 `NoReboot` 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.
이러한 기준을 충족하는 패치가 없으면 관리형 노드 패치 작업이 완료되고 작업은 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.
1. **재부팅 및 보고** - 재부팅 옵션이 `RebootIfNeeded`인 설치 작업이 `AWS-RunPatchBaseline`을 사용하여 관리형 노드에서 실행되고 규정 준수 보고서가 생성되어 업로드됩니다.
1. **재부팅 후 후크 작업** - 세 번째 수명 주기 후크인 `OnExitHookDocName`에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.
`Scan` 작업의 경우 1단계가 실패하면 문서 실행 프로세스가 중지되고 단계가 실패로 보고되지만 후속 단계는 성공으로 보고됩니다.
`Install` 작업의 경우 작업 중 `aws:runDocument` 단계 중 하나라도 실패하면 해당 단계는 실패로 보고되고 작업은 사용자가 제공한 후크를 포함하는 최종 단계(8단계)로 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다. 이 단계는 실패로 보고되고, 마지막 단계는 작업 결과의 상태를 보고하며, 그 사이의 모든 단계는 성공으로 보고됩니다.
## `AWS-RunPatchBaselineWithHooks` 파라미터
`AWS-RunPatchBaselineWithHooks`는 6개 파라미터를 지원합니다.
`Operation` 파라미터가 필요합니다.
`RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` 및 `OnExitHookDocName` 파라미터는 옵션입니다.
`Snapshot-ID`는 기술적으로 옵션이지만 유지 관리 기간 외에 `AWS-RunPatchBaselineWithHooks`를 실행할 때 사용자 정의 값을 제공하는 것이 좋습니다. 유지 관리 기간 작업의 일부로 문서가 실행될 때 Patch Manager가 자동으로 값을 제공하도록 합니다.
**Topics**
+ [파라미터 이름: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [파라미터 이름: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [파라미터 이름: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [파라미터 이름: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [파라미터 이름: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### 파라미터 이름: `Operation`
**사용 여부**: 필수.
**옵션**: `Scan` \$1 `Install`.
스캔
`Scan` 옵션을 선택하는 경우 시스템이 `AWS-RunPatchBaseline` 문서를 사용하여 따라 관리형 노드의 패치 규정 준수 상태를 결정하며 이 정보가 Patch Manager에게 다시 보고됩니다. `Scan`은 업데이트를 설치하거나 관리형 노드를 재부팅하라는 메시지를 표시하지 않습니다. 대신, 작업이 승인되고 노드에 적용 가능한 업데이트가 누락된 위치를 식별해 줍니다.
설치
`Install` 옵션을 선택하는 경우 `AWS-RunPatchBaselineWithHooks`이 관리형 노드에서 누락된 승인되고 적용 가능한 업데이트를 설치하려고 시도합니다. `Install` 작업의 일부로 생성된 패치 규정 준수 정보에는 누락된 업데이트가 나열되지 않지만, 어떠한 이유로든 업데이트 설치가 성공하지 못하면 실패 상태에 있는 업데이트를 보고할 수 있습니다. 관리형 노드에 업데이트가 설치될 때마다 업데이트가 설치되었는지 및 활성 상태인지를 확인하기 위해 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaselineWithHooks` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption) 섹션을 참조하세요.)
Patch Manager가 관리형 노드를 업데이트하기 *전에* 기준 규칙에 의해 지정된 패치가 설치된 경우 시스템이 예상대로 재부팅되지 않을 수도 있습니다. 이는 패치가 사용자에 의해 수동으로 설치되어 있거나 Ubuntu Server의 `unattended-upgrades` 패키지와 같은 다른 프로그램에 의해 자동으로 설치되어 있는 경우에 발생할 수 있습니다.
### 파라미터 이름: `Snapshot ID`
**사용 여부**: 선택.
`Snapshot ID`는 Patch Manager가 단일 작업으로 패치된 관리형 노드 집합 모두가 승인된 패치 집합과 정확히 일치하는지를 확인하기 위해 사용하는 고유 ID(GUID)입니다. 이 파라미터가 옵션으로 정의되어 있긴 하지만, 다음 표에 설명된 대로 유지 관리 기간에서 `AWS-RunPatchBaselineWithHooks`를 실행하는지 여부에 따라 모범 사례 권장 사항이 달라집니다.
**`AWS-RunPatchBaselineWithHooks` 모범 사례**
| Mode | 모범 사례 | 세부 정보 |
| --- | --- | --- |
| 유지 관리 기간 내 AWS-RunPatchBaselineWithHooks 실행 | 스냅샷 ID를 제공하지 않습니다. Patch Manager가 제공합니다. | 유지 관리 기간을 사용하여 `AWS-RunPatchBaselineWithHooks`을 실행하는 경우 자체 생성한 스냅샷 ID를 제공해선 안 됩니다. 이러한 경우에는 Systems Manager가 유지 관리 기간 실행 ID를 기반으로 GUID 값을 제공합니다. 이렇게 하면 해당 유지 관리 기간에 모든 `AWS-RunPatchBaselineWithHooks` 호출에 올바른 ID가 사용됩니다. 이러한 경우에 값을 지정하는 경우 패치 기준선의 스냅샷이 3일 이상 적용되지 않을 수 있습니다. 해당 시간 경과 후에는 스냅샷 만료 후 동일한 ID를 지정하더라도 새로운 스냅샷이 생성됩니다. |
| 유지 관리 기간 외 AWS-RunPatchBaselineWithHooks 실행 | 스냅샷 ID에 대해 사용자 정의 GUID 값을 생성하고 지정합니다.¹ | `AWS-RunPatchBaselineWithHooks`을 실행하는 데 유지 관리 기간을 사용하고 있지 않은 경우 각 패치 기준에 대해 고유한 스냅샷 ID를 생성하고 지정하는 것이 좋습니다. 특히 동일한 작업에서 여러 관리형 노드에 `AWS-RunPatchBaselineWithHooks` 문서를 실행하고 있는 경우 더욱 그러합니다. 이러한 경우에 ID를 지정하지 않으면 Systems Manager가 명령을 보내는 각 관리형 노드에 다른 스냅샷 ID를 생성합니다. 이렇게 되면 노드 간에 다양한 패치 집합이 지정될 수 있습니다. 예를 들어 AWS Systems Manager의 도구인 Run Command를 통해 직접 `AWS-RunPatchBaselineWithHooks` 문서를 실행하고 50개의 관리형 노드로 이루어진 그룹을 대상으로 한다고 가정해 보겠습니다. 사용자 지정 스냅샷 ID를 지정하면 모든 관리형 노드를 평가하고 패치를 적용하는 데 사용되는 기준 스냅샷이 하나가 생성되어 일관적인 상태를 유지하도록 해줍니다. |
| ¹ GUID를 생성할 수 있는 도구라면 어떤 도구를 사용해서든 스냅샷 ID 파라미터의 값을 생성할 수 있습니다. 예를 들어 PowerShell의 경우 `New-Guid` cmdlet을 사용하여 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 형식으로 GUID를 생성할 수 있습니다. |
### 파라미터 이름: `RebootOption`
**사용 여부**: 선택.
**옵션**: `RebootIfNeeded` \$1 `NoReboot`
**기본값**: `RebootIfNeeded`
**주의**
기본 옵션은 `RebootIfNeeded`입니다. 사용 사례에 맞는 올바른 옵션을 선택해야 합니다. 예를 들어 구성 프로세스를 완료하기 위해 관리형 노드를 즉시 재부팅해야 하는 경우, `RebootIfNeeded`를 선택합니다. 또는 예약된 재부팅 시간까지 관리형 노드 가용성을 유지해야 하는 경우, `NoReboot`을 선택합니다.
**중요**
Amazon EMR(이전 명칭: Amazon Elastic MapReduce)에서 클러스터 인스턴스 패치를 적용하는 데는 Patch Manager를 사용하지 않는 것이 좋습니다. 특히 `RebootOption` 파라미터에 `RebootIfNeeded` 옵션을 선택하지 마세요. (이 옵션은 `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` 및 `AWS-RunPatchBaselineWithHooks` 패치 적용에 대한 SSM 명령 문서에서 제공되지 않습니다.)
Patch Manager를 사용하는 패치 적용에 대한 기본 명령에서는 `yum` 및 `dnf` 명령을 사용합니다. 따라서 패키지 설치 방식 때문에 작업이 호환되지 않을 수 있습니다. Amazon EMR 클러스터의 소프트웨어 업데이트용으로 기본 설정된 방법에 대한 자세한 내용은 **Amazon EMR 관리 안내서의 [Amazon EMR용 기본 AMI 사용](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)을 참조하세요.
RebootIfNeeded
`RebootIfNeeded` 옵션을 선택하면 다음과 같은 경우 관리형 노드가 재부팅됩니다.
+ Patch Manager가 하나 이상의 패치를 설치했습니다.
Patch Manager가 패치에 재부팅이 *필요*한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.
+ Patch Manager가 `Install` 작업 중 `INSTALLED_PENDING_REBOOT` 상태의 패치를 하나 이상 감지합니다.
`INSTALLED_PENDING_REBOOT` 상태는 `Install` 작업이 마지막으로 실행될 때 `NoReboot` 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.
이 두 가지 경우에 관리형 노드를 재부팅하면 업데이트된 패키지가 메모리에서 플러시되고 모든 운영 체제에서 패치 및 재부팅 동작이 일관되게 유지됩니다.
NoReboot
`NoReboot` 옵션을 선택하면 Patch Manager가 `Install` 작업 중에 패치를 설치한 경우에도 관리형 노드를 재부팅하지 않습니다. 이 옵션은 패치된 후 관리형 노드를 재부팅할 필요가 없다는 것을 알고 있거나 패치 작업 재부팅으로 인해 중단되지 않아야 하는 노드에서 실행되는 애플리케이션 또는 프로세스가 있는 경우에 유용합니다. 유지 관리 기간을 사용하는 등 관리형 노드 재부팅 시간을 보다 정확하게 제어하려는 경우에도 유용합니다.
`NoReboot` 옵션을 선택하고 패치가 설치되면 패치에 `InstalledPendingReboot` 상태가 할당됩니다. 그러나 관리형 노드 자체는 `Non-Compliant`로 표시됩니다. 재부팅이 발생하고 `Scan` 작업이 실행되면 노드 상태가 `Compliant`로 업데이트됩니다.
**패치 설치 추적 파일(Patch installation tracking file)**: 패치 설치, 특히 마지막 시스템 재부팅 이후에 설치된 패치를 추적하기 위해 Systems Manager는 관리형 노드에서 파일을 유지 관리합니다.
**중요**
추적 파일을 삭제하거나 수정하지 않습니다. 이 파일이 삭제되거나 손상된 경우 관리형 노드에 대한 패치 준수 보고서가 부정확하게 됩니다. 이 경우 노드를 재부팅하고 패치 스캔 작업을 실행하여 파일을 복원합니다.
이 추적 파일은 관리형 노드의 다음 위치에 저장됩니다.
+ Linux 운영 체제:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 운영 체제:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### 파라미터 이름: `PreInstallHookDocName`
**사용 여부**: 선택.
**기본값**: `AWS-Noop`.
`PreInstallHookDocName` 파라미터에 제공할 값은 선택한 SSM 문서의 이름 또는 Amazon 리소스 이름(ARN)입니다. AWS 관리형 문서의 이름이나 생성했거나 공유한 사용자 정의 SSM 문서의 이름 또는 ARN을 제공할 수 있습니다. (다른 AWS 계정에서 공유한 SSM 문서의 경우 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`와 같이 전체 리소스 ARN을 지정해야 합니다.)
지정한 SSM 문서는 `Install` 작업 전에 실행되며 관리형 노드에서 패치가 수행되기 전에 애플리케이션 상태 확인을 점검하는 셸 스크립트와 같이 SSM Agent에서 지원하는 모든 작업을 수행합니다. 작업 목록은 [Command 문서 플러그인 참조](documents-command-ssm-plugin-reference.md) 섹션을 참조하세요. 기본 SSM 문서 이름은 `AWS-Noop`이며 관리형 노드에서 작업을 수행하지 않습니다.
사용자 정의 SSM 문서 생성에 대한 자세한 내용은 [SSM 문서 콘텐츠 생성](documents-creating-content.md) 섹션을 참조하세요.
### 파라미터 이름: `PostInstallHookDocName`
**사용 여부**: 선택.
**기본값**: `AWS-Noop`.
`PostInstallHookDocName` 파라미터에 제공할 값은 선택한 SSM 문서의 이름 또는 Amazon 리소스 이름(ARN)입니다. AWS 관리형 문서의 이름이나 생성했거나 공유한 사용자 정의 SSM 문서의 이름 또는 ARN을 제공할 수 있습니다. (다른 AWS 계정에서 공유한 SSM 문서의 경우 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`과 같이 전체 리소스 ARN을 지정해야 합니다.)
지정한 SSM 문서는 `Install with NoReboot` 작업 후에 실행되며 재부팅 전에 서드 파티 업데이트를 설치하기 위한 셸 스크립트와 같이 SSM Agent가 지원하는 모든 작업을 수행합니다. 작업 목록은 [Command 문서 플러그인 참조](documents-command-ssm-plugin-reference.md) 섹션을 참조하세요. 기본 SSM 문서 이름은 `AWS-Noop`이며 관리형 노드에서 작업을 수행하지 않습니다.
사용자 정의 SSM 문서 생성에 대한 자세한 내용은 [SSM 문서 콘텐츠 생성](documents-creating-content.md) 섹션을 참조하세요.
### 파라미터 이름: `OnExitHookDocName`
**사용 여부**: 선택.
**기본값**: `AWS-Noop`.
`OnExitHookDocName` 파라미터에 제공할 값은 선택한 SSM 문서의 이름 또는 Amazon 리소스 이름(ARN)입니다. AWS 관리형 문서의 이름이나 생성했거나 공유한 사용자 정의 SSM 문서의 이름 또는 ARN을 제공할 수 있습니다. (다른 AWS 계정에서 공유한 SSM 문서의 경우 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`와 같이 전체 리소스 ARN을 지정해야 합니다.)
지정한 SSM 문서는 관리형 노드 재부팅 작업 후에 실행되며 패치 작업이 완료된 후 노드 상태를 확인하기 위한 셸 스크립트와 같이 SSM Agent에서 지원하는 모든 작업을 수행합니다. 작업 목록은 [Command 문서 플러그인 참조](documents-command-ssm-plugin-reference.md) 섹션을 참조하세요. 기본 SSM 문서 이름은 `AWS-Noop`이며 관리형 노드에서 작업을 수행하지 않습니다.
사용자 정의 SSM 문서 생성에 대한 자세한 내용은 [SSM 문서 콘텐츠 생성](documents-creating-content.md) 섹션을 참조하세요.
# `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation`에 InstallOverrideList 파라미터를 사용하기 위한 샘플 시나리오
AWS Systems Manager의 도구인 Patch Manager에서 현재 기본 패치 기준으로 지정된 패치를 재정의하려는 경우 `InstallOverrideList` 파라미터를 사용할 수 있습니다. 이 주제에서는 이 파라미터를 사용하여 다음을 수행하는 방법을 보여주는 예를 제공합니다.
+ 대상 관리형 노드 그룹에 서로 다른 패치 세트를 적용합니다.
+ 이러한 패치 세트를 다른 빈도에 적용합니다.
+ 두 작업 모두에 동일한 패치 기준선을 사용합니다.
Amazon Linux 2 관리형 노드에 서로 다른 두 가지 범주의 패치를 설치한다고 가정해 보겠습니다. 유지 관리 기간을 사용하여 이러한 패치를 다른 일정에 설치하려고 합니다. 매주 하나의 유지 관리 기간을 실행하고 모든 `Security` 패치를 설치하려고 합니다. 한 달에 한 번 다른 유지 관리 기간을 실행하고 사용 가능한 모든 패치 또는 `Security` 이외 범주의 패치를 설치하려고 합니다.
그러나 한 번에 하나의 패치 기준선만 운영 체제의 기본값으로 정의할 수 있습니다. 이 요구 사항은 한 패치 기준이 패치를 승인하는 반면 다른 패치 기준선이 패치를 차단하여, 충돌하는 버전 간에 문제가 발생할 수 있는 상황을 피하는 데 도움이 됩니다.
다음 전략으로 `InstallOverrideList` 파라미터를 사용하여 동일한 패치 기준선을 계속 사용하면서 서로 다른 일정에 따라 대상 그룹에 서로 다른 유형의 패치를 적용할 수 있습니다.
1. 기본 패치 기준선에서 `Security` 업데이트만 지정되었는지 확인합니다.
1. 매주 `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation`이 실행되는 유지 관리 기간을 생성합니다. 재정의 목록을 지정하지 않습니다.
1. 매월 적용하려는 모든 유형의 패치에 대한 재정의 목록을 생성하여 Amazon Simple Storage Service(Amazon S3) 버킷에 저장합니다.
1. 한 달에 한 번 실행되는 두 번째 유지 관리 기간을 생성합니다. 그러나 이 유지 관리 기간에 등록한 Run Command 태스크의 경우 재정의 목록의 위치를 지정합니다.
결과: 기본 패치 기준선에 정의된 `Security` 패치만 매주 설치됩니다. 사용 가능한 모든 패치 또는 정의한 패치의 하위 집합은 매월 설치됩니다.
**참고**
IPv6만 사용하는 노드에 패치를 적용할 때는 제공된 URL에 노드에서 연결할 수 있는지 확인합니다. SSM Agent 구성 옵션 `UseDualStackEndpoint`가 `true`로 설정된 경우 S3 URL이 제공될 때 듀얼 스택 S3 클라이언트가 사용됩니다. 듀얼 스택을 사용하도록 에이전트를 구성하는 방법에 대한 자세한 내용은 [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md) 섹션을 참조하세요.
자세한 내용과 샘플 목록은 [파라미터 이름: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) 섹션을 참조하세요.
# BaselineOverride 파라미터 사용
AWS Systems Manager의 도구인 Patch Manager의 기준 재정의 기능을 사용하여 런타임 시 패치 기본 설정을 정의할 수 있습니다. 이렇게 하려면 패치 기준 목록과 함께 JSON 객체를 포함하는 Amazon Simple Storage Service(Amazon S3) 버킷을 지정합니다. 패치 작업은 기본 패치 기준의 규칙을 적용하는 대신 호스트 운영 체제와 일치하는 JSON 객체에 제공된 기준을 사용합니다.
**중요**
`BaselineOverride` 파일 이름에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자를 포함할 수 없습니다.
패치 작업이 패치 정책을 사용하는 경우를 제외하고 `BaselineOverride` 파라미터를 사용해도 파라미터에 제공된 기준선의 패치 규정 준수를 덮어쓰지 않습니다. 출력 결과는 AWS Systems Manager의 도구인 Run Command의 Stdout 로그에 기록됩니다. 결과는 `NON_COMPLIANT`로 표시된 패키지만 인쇄합니다. 이는 패키지가 `Missing`, `Failed`, `InstalledRejected` 또는 `InstalledPendingReboot`로 표시되었음을 의미합니다.
그러나 패치 작업이 패치 정책을 사용하는 경우 시스템은 관련 S3 버킷의 재정의 파라미터를 전달하고 관리형 노드에 대한 규정 준수 값이 업데이트됩니다. 패치 정책 동작에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
**참고**
IPv6만 사용하는 노드에 패치를 적용할 때는 제공된 URL에 노드에서 연결할 수 있는지 확인합니다. SSM Agent 구성 옵션 `UseDualStackEndpoint`가 `true`로 설정된 경우 S3 URL이 제공될 때 듀얼 스택 S3 클라이언트가 사용됩니다. 듀얼 스택을 사용하도록 에이전트를 구성하는 방법에 대한 자세한 내용은 [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md) 섹션을 참조하세요.
## 스냅샷 ID 또는 설치 재정의 목록 파라미터에 패치 기준 재정의 사용
패치 기준 재정의에 주목할 만한 동작이 있는 두 가지 경우가 있습니다.
**기준 재정의 및 스냅샷 ID 동시 사용**
스냅샷 ID는 특정 패치 명령의 모든 관리형 노드가 모두 동일한 것을 적용하도록 합니다. 예를 들어 한 번에 1,000개의 노드를 패치하는 경우 패치는 동일합니다.
스냅샷 ID와 패치 기준 재정의를 모두 사용하는 경우 스냅샷 ID가 패치 기준 재정의보다 우선합니다. 기준 재정의 규칙은 계속 사용되지만 한 번만 평가됩니다. 이전 예에서 1,000개 관리형 노드의 패치는 여전히 항상 동일합니다. 패치 중간에 참조된 S3 버킷의 JSON 파일을 다른 파일로 변경한 경우 적용되는 패치는 여전히 동일합니다. 스냅샷 ID가 제공되었기 때문입니다.
**기준 재정의 및 설치 재정의 목록 동시 사용**
이 두 파라미터를 동시에 사용할 수 없습니다. 두 파라미터가 모두 제공되면 패치 문서가 실패하고 관리형 노드에서 스캔이나 설치를 수행하지 않습니다.
## 코드 예제
Python의 다음 코드 예제에서는 패치 기준 재정의를 생성하는 방법을 보여줍니다.
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
이렇게 하면 다음과 같은 패치 기준 재정의가 생성됩니다.
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```
# 패치 기준
이 섹션의 주제에서는 관리형 노드에서 `Scan` 또는 `Install` 작업을 실행할 때, AWS Systems Manager의 도구인 Patch Manager에서 패치 기준의 작동 방식에 대한 정보를 제공합니다.
**Topics**
+ [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md)
+ [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md)
+ [패치 그룹](patch-manager-patch-groups.md)
+ [Microsoft에서 Windows Server에 릴리스한 애플리케이션 패치 적용](patch-manager-patching-windows-applications.md)
# 미리 정의된 사용자 지정 패치 기준
AWS Systems Manager의 도구인 Patch Manager는 Patch Manager에서 지원하는 운영 체제마다 미리 정의된 패치 기준을 제공합니다. 이러한 기준은 현재 구성된 대로 사용하거나(사용자 지정할 수 없음) 고유한 사용자 지정 패치 기준을 생성할 수 있습니다. 사용자 정의 패치 기준을 사용하면 환경에 대해 승인 또는 거부되는 패치를 더욱 효과적으로 제어할 수 있습니다. 또한 미리 정의된 기준은 해당 기준을 사용하여 설치된 모든 패치에 `Unspecified`의 규정 준수 수준을 할당합니다. 규정 준수 값을 할당하려면 미리 정의된 기준의 복사본을 생성하고 패치에 할당할 규정 준수 값을 지정할 수 있습니다. 자세한 내용은 [사용자 지정 기준](#patch-manager-baselines-custom) 및 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md)를 참조하세요.
**참고**
이 항목의 정보는 패치 작업에 사용하는 구성 방법 또는 유형에 관계없이 적용됩니다.
Quick Setup에서 구성된 패치 정책
Quick Setup에서 구성된 호스트 관리 옵션
패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
온디맨드 **Patch now**(지금 패치) 작업
**Topics**
+ [미리 정의된 기준](#patch-manager-baselines-pre-defined)
+ [사용자 지정 기준](#patch-manager-baselines-custom)
## 미리 정의된 기준
다음은 Patch Manager와 함께 제공되는 미리 정의된 패치 기준을 설명하는 표입니다.
Patch Manager가 지원하는 각 운영 체제 버전에 대한 자세한 내용은 [Patch Manager 필수 조건](patch-manager-prerequisites.md) 섹션을 참조하세요.
****
| 이름 | 지원되는 운영 체제 | 세부 정보 |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스 7일 후 자동 승인됩니다.¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 패치는 출시 7일 후 자동 승인됩니다. 또한 릴리스 후 7일간 "Bugfix"로 분류되는 모든 패치도 승인합니다. |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | 업데이트가 제공되고 7일 후에 모든 업데이트를 승인합니다(비보안 업데이트 포함). |
| AWS-DebianDefaultPatchBaseline | Debian Server | 우선순위가 "Required", "Important", "Standard," "Optional" 또는 "Extra"로 분류되는 모든 운영 체제 보안 관련 패치를 즉시 승인합니다. 신뢰할 수 있는 릴리스 날짜가 리포지토리에 제공되지 않으므로 승인되기까지 대기 시간이 없습니다. |
| AWS-MacOSDefaultPatchBaseline | macOS | “보안”으로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 현재 업데이트가 있는 모든 패키지를 승인합니다. |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | "Security"로 분류되고, 심각도 수준이 "Important" 또는 "Moderate"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 릴리스 후 7일간 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | "Security"로 분류되고, 심각도가 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | 우선순위가 "Required", "Important", "Standard," "Optional" 또는 "Extra"로 분류되는 모든 운영 체제 보안 관련 패치를 즉시 승인합니다. 신뢰할 수 있는 릴리스 날짜가 리포지토리에 제공되지 않으므로 승인되기까지 대기 시간이 없습니다. |
| AWS-DefaultPatchBaseline | Windows Server | "CriticalUpdates" 또는 "SecurityUpdates"로 분류되고, MSRC 심각도가 "Critical" 또는 "Important"로 분류되는 모든 Windows Server 운영 체제 패치를 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | "CriticalUpdates" 또는 "SecurityUpdates"로 분류되고, MSRC 심각도가 "Critical" 또는 "Important"로 분류되는 모든 Windows Server 운영 체제 패치를 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Windows Server 운영 체제의 경우, "CriticalUpdates" 또는 "SecurityUpdates"로 분류되고, MSRC 심각도가 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. Microsoft에서 릴리스한 애플리케이션의 경우 모든 패치를 승인합니다. OS 및 애플리케이션 모두에 해당하는 패치는 릴리스 또는 업데이트 7일 후 자동 승인됩니다.² |
¹ Amazon Linux 2의 경우 패치가 자동 승인되기까지의 7일 대기 시간은 `Release Date` 값이 아니라 `updateinfo.xml`의 `Updated Date` 값에서 계산됩니다. 다양한 요인이 `Updated Date` 값에 영향을 줄 수 있습니다. 다른 운영 체제에서는 릴리스 날짜와 업데이트 날짜를 다르게 처리합니다. 자동 승인 지연으로 인한 예상치 못한 결과를 방지하는 데 도움이 되는 정보를 알아보려면 [패키지 릴리스 날짜 및 업데이트 날짜 계산 방법](patch-manager-release-dates.md) 섹션을 참조하세요.
² Windows Server의 경우 기본 기준선에는 7일 자동 승인 지연이 포함됩니다. 릴리스 후 7일 내에 패치를 설치하려면 사용자 지정 기준선을 생성해야 합니다.
## 사용자 지정 기준
다음 정보를 사용하면 패치 적용 목표에 맞는 사용자 지정 패치 기준을 만들 수 있습니다.
**Topics**
+ [사용자 지정 기준에서 자동 승인 사용](#baselines-auto-approvals)
+ [패치 기준을 생성하는 데 필요한 추가 정보](#baseline-additional-info)
### 사용자 지정 기준에서 자동 승인 사용
자체 패치 기준선을 생성하는 경우 다음 카테고리를 사용하여 자동 승인할 패치를 선택할 수 있습니다.
+ **운영 체제**: Windows Server, Amazon Linux의 지원되는 버전, Ubuntu Server 등
+ **제품 이름**(운영 체제용): 예를 들어 RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2 등
+ **제품 이름**(Microsoft에서 릴리스한 Windows Server 기반 애플리케이션만 해당): 예를 들어 Word 2016, BizTalk Server 등
+ **분류**: 예를 들어 필수 업데이트, 보안 업데이트 등
+ **심각도**: 예를 들어 Critical, Important 등
생성한 각 승인 규칙에 대해 자동 승인 지연을 지정하거나 패치 승인 마감 날짜를 지정할 수 있습니다.
**참고**
Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
자동 승인 지연은 패치가 릴리스되거나 마지막으로 업데이트된 후 패치 적용을 위해 자동 승인되기까지 대기하는 일 수입니다. 예를 들어, `CriticalUpdates` 분류를 사용하여 규칙을 생성하고 자동 승인 지연 기간을 7일로 구성하면 7월 7일에 릴리스된 새 필수 패치가 7월 14일에 자동으로 승인됩니다.
Linux 리포지토리가 패키지 릴리스 날짜 정보를 제공하지 않는 경우 Patch Manager는 패키지의 빌드 시간을 Amazon Linux 2, Amazon Linux 2023, Red Hat Enterprise Linux(RHEL)의 자동 승인 날짜 사양 날짜로 사용합니다. 패키지의 빌드 시간을 확인할 수 없는 경우 Patch Manager는 기본 날짜인 1970년 1월 1일을 사용합니다. 이에 따라 Patch Manager에서 1970년 1월 1일 이후 모든 날짜에 대한 패치를 승인하도록 구성된 패치 기준의 자동 승인 날짜 사양이 무시됩니다.
자동 승인 마감 날짜를 지정하면 Patch Manager는 해당 날짜 또는 그 이전에 릴리스되거나 마지막으로 업데이트된 모든 패치를 자동으로 적용합니다. 예를 들어 2023년 7월 7일을 마감 날짜로 지정하면 2023년 7월 8일 당일 또는 이후에 릴리스되거나 마지막으로 업데이트된 모든 패치가 자동으로 설치되지 않습니다.
사용자 지정 패치 기준선을 생성할 때 해당 패치 기준선에서 승인된 패치의 규정 준수 심각도 수준을 지정할 수 있습니다(예: `Critical` 또는 `High`). 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
### 패치 기준을 생성하는 데 필요한 추가 정보
패치 기준을 생성하는 경우 다음 사항에 유의하세요.
+ Patch Manager는 지원되는 운영 체제에 따라 미리 정의된 패치 기준이 있습니다. 고유한 패치 기준을 생성하고 이를 해당 운영 체제 유형의 기본값으로 지정하지 않는 한, 이 미리 정의된 패치 기준이 각 운영 체제 유형의 기본 패치 기준으로 사용됩니다.
**참고**
Windows Server에는 3개의 미리 정의된 패치 기준이 제공됩니다. 패치 기준 `AWS-DefaultPatchBaseline` 및 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows 운영 체제 자체에서 운영 체제 업데이트만 지원합니다. `AWS-DefaultPatchBaseline`은 다른 패치 기준을 지정하지 않는 한 Windows Server 관리형 노드의 기본 패치 기준으로 사용됩니다. 이러한 두 패치 기준의 구성 설정은 동일합니다. 둘 중 더 새로운 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows Server에 대해 미리 정의된 세 번째 패치 기준과 구별하기 위해 생성되었습니다. 해당 패치 기준인 `AWS-WindowsPredefinedPatchBaseline-OS-Applications`는 Windows Server 운영 체제 및 Microsoft에서 릴리스한 지원되는 애플리케이션을 패치하는 데 사용될 수 있습니다.
+ 기본적으로 Windows Server 2019 및 Windows Server 2022는 이후 업데이트로 대체되는 업데이트를 제거합니다. 따라서 Windows Server 패치 기준의 `ApproveUntilDate` 파라미터를 사용하지만 `ApproveUntilDate` 파라미터에서 선택한 날짜가 최신 패치 날짜 이전인 경우 패치 작업이 실행될 때 새 패치가 설치되지 않습니다. Windows Server 패치 규칙에 대한 자세한 내용은 [보안 패치 선택 방법](patch-manager-selecting-patches.md)의 Windows Server 탭을 참조하세요.
즉, 관리형 노드는 이전 달의 중요한 패치가 설치되지 않았더라도 Systems Manager 운영 측면에서 규정을 준수합니다. `ApproveAfterDays` 파라미터를 사용할 때도 이와 동일한 시나리오가 발생할 수 있습니다. Microsoft의 대체 패치 동작으로 인해 Microsoft에서 제공하는 최신 패치가 `ApproveAfterDays`의 일수가 경과하기 전에 릴리스되는 경우 Windows Server에 대한 패치가 설치되지 않도록 숫자(일반적으로 30일 이상)를 설정할 수 있습니다.
+ Windows Server에 한해 패치 기준에서 승인되지 않은 사용 가능한 보안 업데이트 패치는 사용자 지정 패치 기준에 정의된 규정 준수 값 `Compliant` 또는 `Non-Compliant`를 가질 수 있습니다.
패치 기준을 생성하거나 업데이트할 때 사용 가능하지만 패치 기준에 지정된 설치 기준을 충족하지 않아 승인되지 않은 보안 패치에 할당할 상태를 선택합니다. 예를 들어 설치 전에 패치가 릴리스된 후 장기간 대기하도록 지정한 경우 설치하려는 보안 패치를 건너뛸 수 있습니다. 지정된 대기 기간 동안 패치 업데이트가 릴리스되면 패치 설치 대기 기간이 다시 시작됩니다. 대기 기간이 너무 길면 여러 버전의 패치가 릴리스될 수 있지만 설치되지는 않습니다.
콘솔을 사용하여 패치 기준을 생성하거나 업데이트하려면 **사용 가능한 보안 업데이트 규정 준수 상태** 필드에서 이 옵션을 지정합니다. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) 또는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html) 명령을 실행하는 경우 `available-security-updates-compliance-status` 파라미터에서 이 옵션을 지정합니다.
+ 온프레미스 서버 및 가상 머신(VM)의 경우 Patch Manager가 사용자 정의 기본 패치 기준을 사용하려고 시도합니다. 사용자 지정 기본 패치 기준선이 없는 경우 시스템은 해당 운영 체제에 사전 정의되어 있는 패치 기준선을 사용합니다.
+ 패치가 동일한 패치 기준선에 승인 및 거부로 나열되면 패치가 거부됩니다.
+ 관리형 노드마다 정의할 수 있는 패치 기준선은 각각 1개로 제한됩니다.
+ 패치 기준에 대한 승인된 패치 및 거부된 패치 목록에 추가할 수 있는 패키지 이름의 형식은 패치를 적용하는 운영 체제의 유형에 따라 다릅니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ Quick Setup에서 [패치 정책 구성](patch-manager-policies.md)을 사용하는 경우 사용자 지정 패치 기준선에 대한 업데이트는 한 시간에 한 번씩 Quick Setup과 동기화됩니다.
패치 정책에서 참조된 사용자 지정 패치 기준선이 삭제되면 해당 패치 정책의 Quick Setup **Configuration details**(구성 세부 정보) 페이지에 배너가 표시됩니다. 배너는 패치 정책에서 더 이상 존재하지 않는 패치 기준선을 참조하고 있으며 후속 패치 작업이 실패할 것임을 알려줍니다. 이 경우 Quick Setup **Configurations**(구성) 페이지로 돌아가서 Patch Manager 구성을 선택하고 **Actions**(작업), **Edit configuration**(구성 편집)을 선택합니다. 삭제된 패치 기준선 이름이 강조 표시되며, 영향을 받는 운영 체제의 새 패치 기준선을 선택해야 합니다.
+ `Classification` 및 `Severity` 값이 여러 개인 승인 규칙을 생성하면 사용 가능한 속성을 기반으로 패치가 승인됩니다. `Classification` 및 `Severity` 속성이 모두 있는 패키지는 두 필드 모두에 대해 선택한 기준 값과 일치합니다. `Classification` 속성만 있는 패키지는 선택한 기준 `Classification` 값과만 일치합니다. `Severity` 속성이 없는 패키지의 경우 동일한 규칙의 심각도 요구 사항은 무시됩니다.
패치 기준 생성에 대한 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 및 [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md) 섹션을 참조하세요.
# 승인 패치 및 거부 패치 목록의 패키지 이름 형식
승인된 패치 및 거부된 패치 목록에 추가할 수 있는 패키지 이름의 형식은 패치를 적용하는 운영 체제의 유형에 따라 다릅니다.
## Linux 운영 체제의 패키지 이름 형식
패치 기준의 승인 패치와 거부 패치에 지정할 수 있는 형식은 Linux 유형별로 다릅니다. 즉, 지원되는 형식은 Linux 운영 체제의 유형에서 사용하는 패키지 관리자에 따라 다릅니다.
**Topics**
+ [Amazon Linux 2, Amazon Linux 2023, Oracle Linux 및 Red Hat Enterprise Linux(RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server 및 Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)
### Amazon Linux 2, Amazon Linux 2023, Oracle Linux 및 Red Hat Enterprise Linux(RHEL)
**패키지 관리자**: DNF를 패키지 관리자로 사용하는 Amazon Linux 2023 및 RHEL 8을 제외한 YUM.
**승인된 패치**: 승인 패치에 다음을 지정할 수 있습니다.
+ Bugzilla ID, `1234567` 형식(숫자로만 구성된 문자열만 Bugzilla ID로 처리됨)
+ CVE IDs, `CVE-2018-1234567` 형식
+ Advisory ID, `RHSA-2017:0864` 및 `ALAS-2018-123` 형식
+ 패키지 이름 지정에 사용할 수 있는 구성 요소 중 하나 이상을 사용하여 구성한 패키지 이름입니다. 예를 들어 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`이라는 패키지의 구성 요소는 다음과 같습니다.
+ `name`: `dbus`
+ `architecture`: `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
다음과 같은 구성의 패키지 이름이 지원됩니다.
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
다음은 몇 가지 예제입니다.
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ 또한 다음과 같이 위 형식의 단일 와일드카드가 포함된 패키지 이름 구성 요소를 지원합니다.
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
**거부된 패치**: 거부 패치에 다음을 입력할 수 있습니다.
+ 패키지 이름 지정에 사용할 수 있는 구성 요소 중 하나 이상을 사용하여 구성한 패키지 이름입니다. 예를 들어 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`이라는 패키지의 구성 요소는 다음과 같습니다.
+ `name`: `dbus`
+ `architecture`; `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
다음과 같은 구성의 패키지 이름이 지원됩니다.
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
다음은 몇 가지 예제입니다.
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ 또한 다음과 같이 위 형식의 단일 와일드카드가 포함된 패키지 이름 구성 요소를 지원합니다.
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
### Debian Server 및 Ubuntu Server
**패키지 관리자**: APT
**승인된 패치**와 **거부된 패치**: 승인 패치와 거부 패치 모두에 다음을 지정할 수 있습니다.
+ 패키지 이름, `ExamplePkg33` 형식
**참고**
Debian Server 목록 및 Ubuntu Server 목록의 경우 아키텍처나 버전 등의 요소가 포함되지 않습니다. 예를 들어 패치 목록에 다음을 모두 포함시키려면 `ExamplePkg33` 패키지 이름을 지정합니다.
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`
### SUSE Linux Enterprise Server (SLES)
**패키지 관리자**: Zypper
**승인된 패치**와 **거부된 패치**: 승인 패치와 거부 패치 목록 모두에 다음을 지정할 수 있습니다.
+ 전체 패키지 이름, 형식 예:
+ `SUSE-SLE-Example-Package-15-2023-123`
+ `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ 와일드카드 한 개를 포함하는 패키지 이름, 예:
+ `SUSE-SLE-Example-Package-15-2023-*`
+ `example-pkg-2023.15.4-46.17.1.*.rpm`
## macOS의 패키지 이름 형식
**지원되는 패키지 관리자**: 소프트웨어 업데이트, 설치 관리자, Brew, Brew Cask
[**승인된 패치(Approved patches)**] 및 [**거부된 패치(rejected patches)**]: : 승인된 패치 목록과 거부된 패치 목록 모두에 대해 다음과 같은 형식으로 전체 패키지 이름을 지정합니다.
+ `XProtectPlistConfigData`
+ `MRTConfigData`
macOS에 대한 승인된 패치 및 거부된 패치 목록에서는 와일드카드가 지원되지 않습니다.
## Windows 운영 체제의 패키지 이름 형식
Windows 운영 체제의 경우 Microsoft Knowledge Base ID와 Microsoft Security Bulletin ID를 사용하여 패치를 지정합니다. 다음 예를 참조하세요.
```
KB2032276,KB2124261,MS10-048
```
# 패치 그룹
**참고**
패치 그룹은 *패치 정책*을 기반으로 하는 패치 적용 작업에 사용되지 않습니다. 패치 정책 작업에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
2022년 12월 22일에 패치 정책 지원이 릴리스될 당시에 패치 그룹을 사용하고 있지 않았던 계정-리전 페어에 대해서는 콘솔에서 패치 그룹 기능이 지원되지 않습니다. 이 날짜 이전에 패치 그룹을 사용하기 시작한 계정-리전 페어에서는 패치 그룹 기능을 계속 사용할 수 있습니다.
*패치 그룹*을 사용하여 AWS Systems Manager의 도구인 Patch Manager에서 관리형 노드를 특정 패치 기준과 연결할 수 있습니다. 패치 그룹을 사용하면 연결된 패치 기준 규칙을 기반으로 적절한 패치를 정확하게 해당 노드 집합에 배포할 수 있습니다. 패치 그룹은 거치기 전에 패치를 배포하는 것을 방지하는 데도 도움이 됩니다. 예를 들어 다양한 환경(예: 개발, 테스트 및 프로덕션)에 필요한 패치 그룹을 만들고 적절한 패치 기준에 각 패치 그룹을 등록할 수 있습니다.
`AWS-RunPatchBaseline` 또는 패치 작업을 위한 기타 SSM 명령 문서를 실행하면 ID 또는 태그를 사용하여 관리형 노드를 대상으로 지정할 수 있습니다. SSM Agent와 Patch Manager는 관리형 노드에 추가한 패치 그룹 값에 따라 사용할 패치 기준을 판단합니다.
## 태그를 사용하여 패치 그룹 정의
[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 비 EC2 노드에 적용된 태그를 사용하여 패치 그룹을 생성합니다. 패치 그룹에 태그를 사용하는 방법에 대한 다음 세부 정보를 참고하세요.
+
패치 그룹은 관리형 노드에 적용된 태그 키 `Patch Group` 또는 `PatchGroup`을 사용하여 정의해야 합니다. 패치 기준에 패치 그룹을 등록할 때 이 두 키에 지정된 동일한 *값*은 동일한 그룹의 일부로 해석됩니다. 예를 들어 다음 키-값 페어 중 첫 번째 페어로 노드 5개의 태그를 지정하고 두 번째 페어로 노드 5개의 태그를 지정했다고 가정해 보겠습니다.
+ `key=PatchGroup,value=DEV`
+ `key=Patch Group,value=DEV`
기준을 생성하는 Patch Manager 명령은 `DEV` 값을 기반으로 이러한 10개의 관리형 노드를 단일 그룹으로 결합합니다. 패치 그룹의 패치 기준을 생성하는 명령과 동등한 AWS CLI 명령은 다음과 같습니다.
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group DEV
```
다른 키의 값을 단일 대상으로 결합하는 작업은 새 패치 그룹을 생성하기 위한 이 Patch Manager 명령에 고유하며 다른 API 작업에서는 지원되지 않습니다. 예를 들어 값이 동일한 `PatchGroup` 및 `Patch Group` 키를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 작업을 실행하는 경우 완전히 다른 두 개의 노드 세트를 대상으로 합니다.
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:PatchGroup,Values=DEV"
```
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:Patch Group,Values=DEV"
```
+ 태그 기반 대상 지정에는 제한이 있습니다. `SendCommand`의 각 대상 배열은 최대 5개의 키-값 페어를 포함할 수 있습니다.
+ `PatchGroup`(공백 없음) 또는 `Patch Group`(공백 포함) 중 이러한 태그 키 규칙 중 하나만 선택하는 것이 좋습니다. 하지만 인스턴스의 [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`을 사용해야 합니다.
+ 키는 대/소문자를 구분합니다. '웹 서버' 또는 'US-EAST-PROD'와 같이 해당 그룹의 리소스를 식별하고 대상으로 지정하는 데 도움이 되는 *값*을 지정할 수 있지만 키는 `Patch Group` 또는 `PatchGroup`이어야 합니다.
패치 그룹 및 태그 관리형 노드를 생성한 이후 패치 그룹을 패치 기준선에 등록할 수 있습니다. 패치 기준으로 패치 그룹을 등록하면 패치 그룹 내부의 노드가 연결된 패치 기준에 정의된 규칙을 사용합니다.
패치 그룹을 생성하고 패치 기준에 연결하는 방법에 대한 자세한 내용은 [패치 그룹 생성 및 관리](patch-manager-tag-a-patch-group.md) 및 [패치 기준에 패치 그룹 추가](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline)를 참조하세요.
AWS Command Line Interface(AWS CLI)를 사용하여 패치 기준 및 패치 그룹을 생성하는 방법을 보려면 [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md) 섹션을 참조하세요. Amazon EC2 태그에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 리소스에 태그 지정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)을 참조하세요.
## 작동 방법
시스템이 패치 기준을 관리형 노드에 적용하기 위해 태스크를 실행하면 SSM Agent는 패치 그룹 값이 해당 노드에 대해 정의되었는지 확인합니다. 노드가 패치 그룹에 할당되는 경우 Patch Manager는 이제 그 그룹에 등록되는 패치 기준을 확인합니다. 해당 그룹에 대한 패치 기준이 검색되면 Patch Manager는 SSM Agent에 해당 패치 기준 사용을 알립니다. 노드가 패치 그룹에 대해 구성되지 않은 경우 Patch Manager는 SSM Agent에 현재 구성된 기본 패치 기준을 자동으로 사용함을 알립니다.
**중요**
관리형 노드는 하나의 패치 그룹에만 있을 수 있습니다.
패치 그룹은 각 운영 체제 유형에 대해 하나의 패치 기준에만 등록할 수 있습니다.
**Allow tags in instance metadata**(인스턴스 메타데이터의 태그 허용) 옵션이 인스턴스에서 활성화된 경우 `Patch Group` 태그(공백 포함)를 Amazon EC2 인스턴스에 적용할 수 없습니다. 인스턴스 메타데이터에서 태그를 허용하면 태그 키 이름에 공백이 포함되지 않습니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 태그 키 `PatchGroup`(공백 없음)을 사용해야 합니다.
**다이어그램 1: 패치 작업 프로세스 흐름의 일반적인 예**
다음 그림은 Patch Manager를 사용하여 패치하기 위해 Run Command 태스크를 서버 플릿으로 보낼 때 Systems Manager가 수행하는 프로세스의 일반적인 예를 보여줍니다. 이러한 프로세스는 패치 작업에서 사용할 패치 기준을 결정합니다. (유지 관리 기간이 Patch Manager를 사용하여 패치할 명령을 보내도록 구성된 경우에도 유사한 프로세스가 사용됩니다.)
전체 프로세스는 그림 아래에 설명되어 있습니다.
![\[패치 작업을 수행할 때 사용할 패치 기준을 결정하기 위한 Patch Manager 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
이 예제에서는 다음 태그가 적용된 세 개의 Windows Server용 EC2 인스턴스 그룹이 있습니다.
****
| EC2 인스턴스 그룹 | Tags |
| --- | --- |
| 그룹 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| 그룹 2 | `key=OS,value=Windows` |
| 그룹 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` |
이 예에서는 2개의 Windows Server 패치 기준도 있습니다.
****
| 패치 기준 ID | Default | 연결된 패치 그룹 |
| --- | --- | --- |
| `pb-0123456789abcdef0` | 예 | `Default` |
| `pb-9876543210abcdef0` | 아니요 | `DEV` |
AWS Systems Manager의 도구인 Run Command와 Patch Manager를 사용하여 패치를 검색하거나 설치하는 일반적인 프로세스는 다음과 같습니다.
1. **패치 명령 보내기**: Systems Manager 콘솔, SDK, AWS Command Line Interface(AWS CLI) 또는 AWS Tools for Windows PowerShell을 통해 문서 `AWS-RunPatchBaseline`을 사용하여 Run Command 태스크를 보냅니다. 이 다이어그램은 태그 `key=OS,value=Windows`를 대상으로 관리된 인스턴스를 패치하기 위한 Run Command 태스크를 보여줍니다.
1. **패치 기준 결정**: SSM Agent는 EC2 인스턴스에 적용된 패치 그룹 태그를 확인하고 Patch Manager에게 해당 패치 기준을 쿼리합니다.
+ **패치 기준과 연결된 일치하는 패치 그룹 값:**
1. 그룹 1의 EC2 인스턴스에 설치된 SSM Agent는 1단계에서 지시된 명령을 수신하여 패치 작업을 시작합니다. SSM Agent는 EC2 인스턴스에 패치 그룹 태그 값 `DEV`가 적용되었는지 확인하고 Patch Manager에게 연결된 패치 기준을 쿼리합니다.
1. Patch Manager는 패치 기준 `pb-9876543210abcdef0`에 패치 그룹 `DEV`가 연결되어 있는지 확인하고 SSM Agent에 알립니다.
1. SSM Agent는 `pb-9876543210abcdef0`에 구성된 승인 규칙 및 예외를 기반으로 Patch Manager에서 패치 기준 스냅샷을 검색하고 다음 단계로 진행합니다.
+ **패치 그룹 태그가 인스턴스에 추가되지 않은 경우:**
1. 그룹 2의 EC2 인스턴스에 설치된 SSM Agent는 1단계에서 지시된 명령을 수신하여 패치 작업을 시작합니다. SSM Agent는 EC2 인스턴스에 `Patch Group` 또는 `PatchGroup` 태그가 적용되지 않았음을 확인하고 그에 따라 SSM Agent는 Patch Manager에 기본 Windows 패치 기준선을 쿼리합니다.
1. Patch Manager는 기본 Windows Server 패치 기준이 `pb-0123456789abcdef0`인지 확인하고 SSM Agent에 알립니다.
1. SSM Agent는 기본 패치 기준 `pb-0123456789abcdef0`에 구성된 승인 규칙 및 예외를 기반으로 Patch Manager에서 패치 기준 스냅샷을 검색하고 다음 단계로 진행합니다.
+ **패치 기준과 연결된 일치하는 패치 그룹 값이 없는 경우:**
1. 그룹 3의 EC2 인스턴스에 설치된 SSM Agent는 1단계에서 지시된 명령을 수신하여 패치 작업을 시작합니다. SSM Agent는 EC2 인스턴스에 패치 그룹 태그 값 `QA`가 적용되었는지 확인하고 Patch Manager에게 연결된 패치 기준을 쿼리합니다.
1. Patch Manager는 패치 그룹 `QA`가 연결되어 있는 패치 기준을 찾지 못합니다.
1. Patch Manager는 SSM Agent에게 기본 Windows 패치 기준 `pb-0123456789abcdef0`을 사용할 것을 알립니다.
1. SSM Agent는 기본 패치 기준 `pb-0123456789abcdef0`에 구성된 승인 규칙 및 예외를 기반으로 Patch Manager에서 패치 기준 스냅샷을 검색하고 다음 단계로 진행합니다.
1. **패치 스캔 또는 설치**: 사용할 적절한 패치 기준을 결정한 후 SSM Agent는 1단계에서 지정한 작업 값을 기준으로 패치를 스캔하거나 설치합니다. 검사 또는 설치되는 패치는 Patch Manager가 제공하는 패치 기준 스냅샷에 정의된 승인 규칙 및 패치 예외에 의해 결정됩니다.
**추가 정보**
+ [패치 규정 준수 상태 값](patch-manager-compliance-states.md)
# Microsoft에서 Windows Server에 릴리스한 애플리케이션 패치 적용
이 주제의 정보를 사용하여 AWS Systems Manager의 도구인 Patch Manager로 Windows Server 기반 애플리케이션에 패치를 적용할 준비를 합니다.
**Microsoft 애플리케이션 패치**
Windows Server 관리형 노드의 애플리케이션에 대한 패치 지원은 Microsoft에서 릴리스한 애플리케이션으로 제한됩니다.
**참고**
경우에 따라 Microsoft는 업데이트된 날짜와 시간을 지정하지 않는 애플리케이션에 대한 패치를 릴리스합니다. 이 경우 업데이트된 `01/01/1970`의 날짜 및 시간은 기본적으로 제공됩니다.
**Microsoft에서 릴리스한 애플리케이션 패치를 위한 패치 기준**
Windows Server에는 3개의 미리 정의된 패치 기준이 제공됩니다. 패치 기준 `AWS-DefaultPatchBaseline` 및 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows 운영 체제 자체에서 운영 체제 업데이트만 지원합니다. `AWS-DefaultPatchBaseline`은 다른 패치 기준을 지정하지 않는 한 Windows Server 관리형 노드의 기본 패치 기준으로 사용됩니다. 이러한 두 패치 기준의 구성 설정은 동일합니다. 둘 중 더 새로운 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows Server에 대해 미리 정의된 세 번째 패치 기준과 구별하기 위해 생성되었습니다. 해당 패치 기준인 `AWS-WindowsPredefinedPatchBaseline-OS-Applications`는 Windows Server 운영 체제 및 Microsoft에서 릴리스한 지원되는 애플리케이션을 패치하는 데 사용될 수 있습니다.
Microsoft에서 릴리스한 Windows Server 시스템 기반 애플리케이션을 업데이트하는 사용자 정의 패치 기준을 생성할 수도 있습니다.
**Microsoft에서 릴리스한 온프레미스 서버, 엣지 디바이스, VM 및 기타 비EC2 노드 기반 애플리케이션 패치에 대한 지원**
Microsoft에서 릴리스한 가상 머신 및 기타 비 EC2 관리형 노드의 애플리케이션에 패치를 적용하려면 고급 인스턴스 티어를 설정해야 합니다. 고급 인스턴스 티어를 사용하는 데는 요금이 부과됩니다. **그러나 Microsoft에서 릴리스한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 기반 애플리케이션을 패치하는 데는 추가 요금이 부과되지 않습니다.** 자세한 내용은 [인스턴스 티어 구성](fleet-manager-configure-instance-tiers.md) 섹션을 참조하세요.
**“다른 Microsoft 제품”에 대한 Windows 업데이트 옵션**
Patch Manager가 Microsoft에서 릴리스한 Windows Server 관리형 노드 기반 애플리케이션을 패치할 수 있도록 관리형 노드에서 Windows 업데이트 옵션 **Windows를 업데이트할 때 다른 Microsoft 제품에 대한 업데이트 제공(Give me updates for other Microsoft products when I update Windows)**을 활성화해야 합니다.
단일 관리형 노드에서 이 옵션 허용에 대한 자세한 내용은 Microsoft Support 웹 사이트의 [Microsoft 업데이트를 사용하여 Office 업데이트](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282)를 참조하세요.
Windows Server 2016 이상을 실행하는 관리형 노드 플릿의 경우 그룹 정책 객체(GPO)를 사용하여 설정을 켤 수 있습니다. 그룹 정책 관리 편집기에서 [**컴퓨터 구성(Computer Configuration)**], [**관리 템플릿(Administrative Templates)**], [**Windows 구성 요소(Windows Components)**], [**Windows 업데이트(Windows Updates)**]로 이동하고 [**다른 Microsoft 제품에 대한 업데이트 설치(Install updates for other Microsoft products)**]를 선택합니다. 또한 계획되지 않은 자동 업데이트 및 Patch Manager 외부 재부팅을 방지하는 추가 파라미터를 사용하여 GPO를 구성하는 것이 좋습니다. 자세한 내용은 Microsoft 기술 문서 웹 사이트의 [Non-Active Directory 환경에서 자동 업데이트 구성](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499)을 참조하세요.
Windows Server 2012 또는 2012 R2를 실행하는 관리형 노드 플릿의 경우 Microsoft Docs 블로그 웹 사이트의 [Enabling and Disabling Microsoft Update in Windows 7 via Script](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script)에 설명된 대로 스크립트를 사용하여 옵션을 설정할 수 있습니다. 예를 들어 다음을 수행할 수 있습니다.
1. 블로그 게시물의 스크립트를 파일로 저장합니다.
1. 파일을 Amazon Simple Storage Service(Amazon S3) 버킷 또는 기타 액세스 가능한 위치에 업로드합니다.
1. AWS Systems Manager의 도구인 Run Command로 다음과 같은 명령에 Systems Manager 문서(SSM 문서) `AWS-RunPowerShellScript`를 사용하여 관리형 노드에서 스크립트를 실행합니다.
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**최소 파라미터 요구 사항**
사용자 정의 패치 기준에 Microsoft에서 릴리스한 애플리케이션을 포함하려면 최소한 패치할 제품을 지정해야 합니다. 다음 AWS Command Line Interface(AWS CLI) 명령은 Microsoft Office 2016과 같이 제품을 패치하는 데 필요한 최소 요구 사항을 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
Microsoft 애플리케이션 제품군을 지정하는 경우, 지정하는 각 제품은 선택한 제품군의 지원 구성원이어야 합니다. 예를 들어 "Active Directory 권한 관리 서비스 클라이언트 2.0" 제품을 패치하려면 해당 제품군을 "Office"또는 "SQL Server"가 아닌 "Active Directory"로 지정해야 합니다. 다음 AWS CLI 명령은 제품군 및 제품으로 구성된 일치된 페어를 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
**참고**
일치하지 않는 제품 및 제품군 페어링에 대한 오류 메시지가 표시되는 경우 [문제: 일치하지 않는 제품군/제품 페어](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch)에서 문제 해결을 위한 도움말을 찾아보세요.
# Amazon Linux 2 관리형 노드에서 Kernel Live Patching 사용
Amazon Linux 2용 Kernel Live Patching을 사용하면 실행 중인 애플리케이션을 재부팅하거나 중단하지 않고 실행 중인 Linux 커널에 보안 취약성 및 중요 버그 패치를 적용할 수 있습니다. 이를 통해 서비스 및 애플리케이션 가용성을 향상하는 동시에 인프라를 최신 상태로 안전하게 유지할 수 있습니다. Kernel Live Patching은 Amazon EC2 인스턴스와 Amazon Linux 2를 실행하는 AWS IoT Greengrass 코어 디바이스, [온프레미스 가상 머신](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html)에서 지원됩니다.
Kernel Live Patching에 대한 일반적인 내용은 *Amazon Linux 2 사용 설명서*에서 [AL2의 Kernel Live Patching](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html)을 참조하세요.
Amazon Linux 2 관리형 노드에서 Kernel Live Patching을 설정한 후 AWS Systems Manager의 도구인 Patch Manager를 사용하여 커널 라이브 패치를 인스턴스에 적용할 수 있습니다. 노드에서 기존 yum 워크플로를 사용하여 업데이트를 적용하는 대신 Patch Manager를 사용할 수 있습니다.
**시작하기 전 준비 사항**
Patch Manager를 사용하여 커널 라이브 패치를 Amazon Linux 2 관리형 노드에 적용하려면 노드가 올바른 아키텍처와 커널 버전을 기반으로 해야 합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [지원되는 구성 및 사전 조건](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)을 참조하세요.
**Topics**
+ [Patch Manager를 사용하는 Kernel Live Patching](#about-klp)
+ [Patch Manager를 사용하는 Kernel Live Patching의 작동 방식](#how-klp-works)
+ [Run Command를 사용하여 Kernel Live Patching 설정](enable-klp.md)
+ [Run Command을 사용하여 커널 라이브 패치 적용](install-klp.md)
+ [Run Command를 사용하여 Kernel Live Patching을 해제하려면](disable-klp.md)
## Patch Manager를 사용하는 Kernel Live Patching
커널 버전 업데이트
커널 라이브 패치 업데이트를 적용한 후 관리형 노드를 재부팅할 필요가 없습니다. 그러나 AWS는 릴리스 후 최대 3개월 동안 Amazon Linux 2 커널 버전에 대한 커널 라이브 패치를 제공합니다. 3개월 후 커널 라이브 패치를 계속 받으려면 최신 커널 버전으로 업데이트해야 합니다. 유지 관리 기간을 사용하여 커널 버전 업데이트를 요청하는 메시지를 표시하도록 최소 3개월에 한 번 노드 재부팅을 예약하는 것이 좋습니다.
커널 라이브 패치 제거
커널 라이브 패치는 Patch Manager를 사용하여 제거할 수 없습니다. 대신 Kernel Live Patching을 해제하여 적용된 커널 라이브 패치에 대한 RPM 패키지를 제거할 수 있습니다. 자세한 내용은 [Run Command를 사용하여 Kernel Live Patching을 해제하려면](disable-klp.md) 섹션을 참조하세요.
커널 규정 준수
경우에 따라 현재 커널 버전에 대한 라이브 패치에서 모든 CVE 수정 사항을 설치하면 해당 커널이 최신 커널 버전과 동일한 규정 준수 상태가 될 수 있습니다. 이 경우 최신 버전은 `Installed`으로 보고되고 관리형 노드는 `Compliant`로 보고됩니다. 그러나 최신 커널 버전에서는 설치 시간이 보고되지 않습니다.
하나의 커널 라이브 패치, 여러 CVE
커널 라이브 패치가 여러 CVE를 해결하고 해당 CVE가 다양한 분류 및 심각도 값을 갖는 경우, CVE에서 가장 높은 분류 및 심각도만 해당 패치에 대해 보고됩니다.
이 섹션의 나머지 부분에서는 Patch Manager를 사용하여 이러한 요구 사항을 충족하는 관리형 노드에 커널 라이브 패치를 적용하는 방법을 설명합니다.
## Patch Manager를 사용하는 Kernel Live Patching의 작동 방식
AWS는 Amazon Linux 2를 위한 2가지 유형의 커널 라이브 패치인 보안 업데이트와 버그 수정 사항을 릴리스합니다. 이러한 유형의 패치를 적용하려면 다음 표에 나열된 분류 및 심각도만 대상으로 하는 패치 기준 문서를 사용합니다.
| 분류 | 심각도 |
| --- | --- |
| Security | Critical, Important |
| Bugfix | All |
이러한 패치만 대상으로 하는 사용자 지정 패치 기준을 생성하거나, 미리 정의된 `AWS-AmazonLinux2DefaultPatchBaseline` 패치 기준을 사용할 수 있습니다. 즉, Kernel Live Patching이 설정된 Amazon Linux 2 관리형 노드에서 `AWS-AmazonLinux2DefaultPatchBaseline`을 사용할 수 있으며 커널 라이브 업데이트가 적용됩니다.
**참고**
`AWS-AmazonLinux2DefaultPatchBaseline` 구성은 패치가 릴리스되거나 마지막으로 업데이트된 후 자동으로 설치되기 전에 7일의 대기 기간을 지정합니다. 7일 동안 커널 라이브 패치 자동 승인을 기다리지 않으려면 사용자 정의 패치 기준선을 생성하여 사용합니다. 패치 기준에서 자동 승인 대기 기간을 지정하거나 더 짧거나 긴 대기 기간을 지정할 수 있습니다. 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
커널 라이브 업데이트로 관리형 노드를 패치하려면 다음 전략을 사용하는 것이 좋습니다.
1. Amazon Linux 2 관리형 노드에서 Kernel Live Patching 활성화
1. AWS Systems Manager의 도구인 Run Command를 사용하여 미리 정의된 `AWS-AmazonLinux2DefaultPatchBaseline` 또는 심각도가 `Critical`과 `Important`로 분류되었고 `Bugfix` 심각도가 `All`인 `Security` 업데이트만 대상으로 하는 사용자 정의 패치 기준을 사용하여 관리형 노드에서 `Scan` 작업을 실행합니다.
1. AWS Systems Manager의 도구인 Compliance를 사용하여 스캔된 관리형 노드에 대해 패치 규정 미준수가 보고되는지 검토합니다. 그렇다면 노드 규정 준수 세부 정보를 보고, 관리형 노드에서 누락된 커널 라이브 패치가 있는지 확인합니다.
1. 누락된 커널 라이브 패치를 설치하려면 이전에 지정한 것과 동일한 패치 기준에서 Run Command을 사용합니다. 하지만 이번에는 `Scan` 작업 대신 `Install` 작업을 실행합니다.
커널 라이브 패치는 재부팅할 필요 없이 설치되므로 이 작업에 대해 `NoReboot` 재부팅 옵션을 선택할 수 있습니다.
**참고**
노드에 설치된 다른 유형의 패치가 필요하거나 최신 커널로 업데이트하려는 경우에도 관리형 노드를 재부팅할 수 있습니다. 이러한 경우 `RebootIfNeeded` 재부팅 옵션을 대신 선택합니다.
1. 규정 준수로 돌아가서 커널 라이브 패치가 설치되었는지 확인합니다.
# Run Command를 사용하여 Kernel Live Patching 설정
Kernel Live Patching을 설정하기 위해 관리형 노드에서 `yum` 명령을 실행하거나 Run Command와 생성한 사용자 정의 Systems Manager 문서(SSM 문서)를 사용할 수 있습니다.
관리형 노드에서 직접 `yum` 명령을 실행하여 Kernel Live Patching을 켜는 것에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Kernel Live Patching 활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)를 참조하세요.
**참고**
커널 라이브 패칭을 설정할 때 관리형 노드에서 이미 실행 중인 커널이 `kernel-4.14.165-131.185.amzn2.x86_64`(지원되는 최소 버전)보다 *이전* 버전이면 프로세스가 사용 가능한 최신 커널 버전을 설치하고 관리형 노드를 재부팅합니다. 노드가 `kernel-4.14.165-131.185.amzn2.x86_64` 이상을 이미 실행하고 있는 경우 프로세스가 최신 버전을 설치하지 않고 노드를 재부팅하지 않습니다.
**Run Command를 사용하여 Kernel Live Patching을 설정하려면(콘솔)**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(Run 명령)를 선택합니다.
1. [**Command 문서(Command document)**] 목록에서 사용자 정의 SSM 문서 `AWS-ConfigureKernelLivePatching`을 선택합니다.
1. **명령 파라미터** 섹션에서 이 작업의 일부로 관리형 노드를 재부팅할지 여부를 지정합니다.
1. 이 페이지의 나머지 컨트롤 작업에 대한 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
1. **Run(실행)**을 선택합니다.
**Kernel Live Patching을 설정하려면(AWS CLI)**
+ 로컬 시스템에서 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--parameters "EnableOrDisable=Enable" \
--targets "Key=instanceids,Values=instance-id"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--parameters "EnableOrDisable=Enable" ^
--targets "Key=instanceids,Values=instance-id"
```
------
*instance-id*를 기능을 설정할 Amazon Linux 2 관리형 노드의 ID로 바꿉니다(예: i-02573cafcfEXAMPLE). 여러 관리형 노드에서 기능을 설정하기 위해 다음 형식 중 하나를 사용할 수 있습니다.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
명령에서 사용할 수 있는 기타 옵션에 대한 자세한 내용은 **AWS CLI 명령 레퍼런스의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 를 참조하세요.
# Run Command을 사용하여 커널 라이브 패치 적용
커널 라이브 패치를 적용하기 위해 관리형 노드에서 `yum` 명령을 실행하거나, Run Command 및 SSM 문서 `AWS-RunPatchBaseline`을 사용할 수 있습니다.
관리형 노드에서 직접 `yum` 명령을 실행하여 커널 라이브 패치를 적용하는 것에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [커널 라이브 패치 적용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply)을 참조하세요.
**Run Command을 사용하여 커널 라이브 패치를 적용하려면(콘솔)**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(Run 명령)를 선택합니다.
1. [**Command 문서(Command document)**] 목록에서 SSM 문서 `AWS-RunPatchBaseline`을 선택합니다.
1. **명령 파라미터** 섹션에서 다음 중 하나를 수행합니다.
+ 새 커널 라이브 패치가 사용 가능한지 확인하려는 경우 [**작업(Operation)**]에서 [`Scan`]을 선택합니다. 이 작업 후에 관리형 노드를 재부팅하지 않으려면 **재부팅 옵션(Reboot Option)**에서 `NoReboot`를 선택합니다. 작업이 완료되면 Compliance에서 새 패치 및 규정 준수 상태를 확인할 수 있습니다.
+ 패치 규정 준수를 이미 확인하고 사용 가능한 커널 라이브 패치를 적용할 준비가 된 경우 **작업**에서 `Install`를 선택합니다. 이 작업 후에 관리형 노드를 재부팅하지 않으려면 **재부팅 옵션(Reboot Option)**에서 `NoReboot`를 선택합니다.
1. 이 페이지의 나머지 컨트롤 작업에 대한 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
1. **Run(실행)**을 선택합니다.
**Run Command을 사용하여 커널 라이브 패치를 적용하려면(AWS CLI)**
1. Compliance에서 결과를 확인하기 전에 `Scan` 작업을 수행하려면 로컬 시스템에서 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
```
------
명령에서 사용할 수 있는 기타 옵션에 대한 자세한 내용은 **AWS CLI 명령 레퍼런스의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 를 참조하세요.
1. Compliance에서 결과를 확인한 후 `Install` 작업을 수행하려면 로컬 시스템에서 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
```
------
앞의 두 명령 모두에서 *instance-id*를 커널 라이브 패치를 적용할 Amazon Linux 2 관리형 노드의 ID로 바꿉니다(예: i-02573cafcfEXAMPLE). 여러 관리형 노드에서 기능을 설정하기 위해 다음 형식 중 하나를 사용할 수 있습니다.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
이러한 명령에서 사용할 수 있는 기타 옵션에 대한 자세한 내용은 **AWS CLI 명령 레퍼런스의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 를 참조하세요.
# Run Command를 사용하여 Kernel Live Patching을 해제하려면
Kernel Live Patching을 해제하기 위해 관리형 노드에서 `yum` 명령을 실행하거나, Run Command 및 사용자 정의 SSM 문서 `AWS-ConfigureKernelLivePatching`을 사용할 수 있습니다.
**참고**
커널 라이브 패치를 더 이상 사용할 필요가 없는 경우 언제든지 해제할 수 있습니다. 대부분의 경우 이 기능을 해제할 필요가 없습니다.
관리형 노드에서 직접 `yum` 명령을 실행하여 Kernel Live Patching 설정을 비활성화하는 것에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Kernel Live Patching 활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable)를 참조하세요.
**참고**
Kernel Live Patching을 해제하면 프로세스가 Kernel Live Patching 플러그인을 제거하고 관리형 노드를 재부팅합니다.
**Run Command를 사용하여 Kernel Live Patching을 해제하려면(콘솔)**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(Run 명령)를 선택합니다.
1. [**Command 문서(Command document)**] 목록에서 SSM 문서 `AWS-ConfigureKernelLivePatching`을 선택합니다.
1. **명령 파라미터** 섹션에서 필요한 파라미터의 값을 지정합니다.
1. 이 페이지의 나머지 컨트롤 작업에 대한 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
1. **Run(실행)**을 선택합니다.
**Kernel Live Patching을 해제하려면(AWS CLI)**
+ 다음과 유사한 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--targets "Key=instanceIds,Values=instance-id" \
--parameters "EnableOrDisable=Disable"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--targets "Key=instanceIds,Values=instance-id" ^
--parameters "EnableOrDisable=Disable"
```
------
*instance-id*를 기능을 비활성화할 Amazon Linux 2 관리형 노드의 ID로 바꿉니다(예: i-02573cafcfEXAMPLE). 여러 관리형 노드에서 기능을 비활성화하기 위해 다음 형식 중 하나를 사용할 수 있습니다.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
명령에서 사용할 수 있는 기타 옵션에 대한 자세한 내용은 **AWS CLI 명령 레퍼런스의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 를 참조하세요.
# 콘솔을 사용하여 Patch Manager 리소스 및 규정 준수 작업
AWS Systems Manager의 도구인 Patch Manager를 사용하려면 다음 태스크를 완료합니다. 이러한 작업은 이 단원에서 더 자세히 설명합니다.
1. 사용 중인 각 운영 체제 유형에 따라 AWS 미리 정의된 패치 기준이 필요를 충족하는지 확인하십시오. 그렇지 않은 경우 해당 관리형 노드 유형에 대한 표준 패치 집합을 정의하는 패치 기준을 생성하고, 기본값으로 설정합니다.
1. Amazon Elastic Compute Cloud(Amazon EC2) 태그를 사용하여 관리형 노드를 패치 그룹으로 구성합니다(옵션이지만 권장됨).
1. 다음 중 하나를 수행하세요.
+ (권장) Systems Manager의 도구인 Quick Setup에서 패치 정책을 구성하여 전체 조직, 일부 조직 단위 또는 단일 AWS 계정의 일정에 따라 누락된 패치를 설치할 수 있습니다. 자세한 내용은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 섹션을 참조하세요.
+ Run Command 태스크 유형에서 Systems Manager 문서(SSM 문서) `AWS-RunPatchBaseline`을 사용하는 유지 관리 기간을 생성합니다. 자세한 내용은 [자습서: 콘솔을 사용하여 패치를 위한 유지 관리 기간 생성](maintenance-window-tutorial-patching.md) 섹션을 참조하세요.
+ Run Command 작업에서 `AWS-RunPatchBaseline`을 수동으로 실행합니다. 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
+ **Patch now**(지금 패치) 기능을 사용하여 필요에 따라 노드를 수동으로 패치합니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
1. 패치 적용을 모니터링하여 규정 준수 여부를 확인하고 오류를 조사합니다.
**Topics**
+ [패치 정책 생성](patch-manager-create-a-patch-policy.md)
+ [패치 대시보드 요약 보기](patch-manager-view-dashboard-summaries.md)
+ [패치 규정 준수 보고서 작업](patch-manager-compliance-reports.md)
+ [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md)
+ [패치 기준 작업](patch-manager-create-a-patch-baseline.md)
+ [사용 가능한 패치 보기](patch-manager-view-available-patches.md)
+ [패치 그룹 생성 및 관리](patch-manager-tag-a-patch-group.md)
+ [Patch Manager와 AWS Security Hub CSPM 통합](patch-manager-security-hub-integration.md)
# 패치 정책 생성
패치 정책은 AWS Systems Manager의 도구인 Quick Setup을 사용하여 설정하는 구성입니다. 패치 정책은 다른 패치 구성 방법에서 제공되는 것보다 더 광범위하고 중앙 집중화된 패치 작업 제어 기능을 제공합니다. 패치 정책은 노드와 애플리케이션에 자동으로 패치를 적용할 때 사용할 일정과 기준선을 정의합니다.
자세한 정보는 다음 주제를 참조하세요.
+ [Quick Setup의 패치 정책 구성](patch-manager-policies.md)
+ [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md)
# 패치 대시보드 요약 보기
Patch Manager의 **대시보드** 탭에서는 통합 보기에서 패치 작업을 모니터링하는 데 사용할 수 있는 콘솔의 요약 보기를 제공합니다. Patch Manager는 AWS Systems Manager의 도구입니다. **대시보드(Dashboard)** 탭에서 다음을 볼 수 있습니다.
+ 패치 규정을 준수 및 준수하지 않는 관리형 노드의 수를 보여주는 스냅샷입니다.
+ 관리형 노드에 대한 패치 규정 준수 결과 기간에 대한 스냅샷입니다.
+ 규정 미준수의 가장 일반적인 사유 각각에 대해 규정을 준수하지 않는 관리형 노드의 연결 수입니다.
+ 최신 패치 작업의 연결된 목록입니다.
+ 설정된 반복 패치 작업의 연결된 목록입니다.
**패치 대시보드 요약을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **대시보드(Dashboard)** 탭을 선택합니다.
1. 보고자 하는 요약 데이터가 포함된 섹션으로 스크롤합니다.
+ **Amazon EC2 인스턴스 관리**
+ **규정 준수 요약**
+ **미준수 건수**
+ **규정 준수 보고서**
+ **비패치 정책 기반 작업**
+ **비패치 정책 기반 반복 태스크**
# 패치 규정 준수 보고서 작업
다음 주제의 정보를 사용하여 패치 규정 준수 보고서를 AWS Systems Manager의 도구인 Patch Manager에 생성하고 작업할 수 있습니다.
다음 항목의 정보는 패치 작업에 사용하는 구성 방법 또는 유형에 관계없이 적용됩니다.
+ Quick Setup에서 구성된 패치 정책
+ Quick Setup에서 구성된 호스트 관리 옵션
+ 패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
+ 온디맨드 **Patch now**(지금 패치) 작업
**중요**
패치 규정 준수 보고서는 성공적인 패치 작업에 의해서만 생성되는 특정 시점 스냅샷입니다. 각 보고서에는 규정 준수 상태가 계산된 때를 식별하는 캡처 시간이 포함되어 있습니다.
인스턴스에서 패치 규정 준수를 검사하기 위해 여러 유형의 작업을 수행하는 경우, 스캔할 때마다 이전 스캔의 패치 규정 준수 데이터를 덮어씁니다. 따라서 패치 규정 준수 데이터에 예상치 못한 결과가 발생할 수 있습니다. 자세한 내용은 [패치 규정 준수 데이터를 생성한 실행 식별](patch-manager-compliance-data-overwrites.md) 섹션을 참조하세요.
최신 규정 준수 정보를 생성하는 데 어떤 패치 기준선이 사용되었는지 확인하려면, Patch Manager의 **규정 준수 보고** 탭으로 이동하여 정보를 얻으려는 관리형 노드에 해당하는 행을 찾은 다음, **사용된 기준선 ID** 열에서 기준선 ID를 선택합니다.
**Topics**
+ [패치 규정 준수 결과 보기](patch-manager-view-compliance-results.md)
+ [.csv 패치 규정 준수 보고서 생성](patch-manager-store-compliance-results-in-s3.md)
+ [Patch Manager로 규정 미준수 관리형 노드 문제 해결](patch-manager-noncompliant-nodes.md)
+ [패치 규정 준수 데이터를 생성한 실행 식별](patch-manager-compliance-data-overwrites.md)
# 패치 규정 준수 결과 보기
다음 절차를 사용하여 관리형 노드에 대한 패치 규정 준수 정보를 봅니다.
이 절차는 `AWS-RunPatchBaseline` 문서를 사용하는 패치 작업에 적용됩니다. `AWS-RunPatchBaselineAssociation` 문서를 사용하는 패치 작업에 대한 패치 규정 준수 정보 보기에 대한 자세한 내용은 [규정 미준수 관리형 노드 식별](patch-manager-find-noncompliant-nodes.md) 섹션을 참조하세요.
**참고**
Quick Setup 및 Explorer에 대한 패치 검사 작업에서는 `AWS-RunPatchBaselineAssociation` 문서를 사용합니다. Quick Setup 및 Explorer는 둘 다 AWS Systems Manager의 도구입니다.
**특정 CVE 문제에 대한 패치 솔루션 식별(Linux)**
많은 Linux 기반 운영 체제의 경우 패치 규정 준수 결과에 따라 어느 일반적인 취약성 및 노출도(CVE) 게시판 문제가 어느 패치로 해결되는지 확인할 수 있습니다. 이 정보는 누락되거나 실패한 패치를 얼마나 긴급하게 설치해야 하는지를 결정하는 데 도움이 됩니다.
다음 운영 체제 유형의 지원되는 버전에 대한 CVE 세부 정보가 포함되어 있습니다.
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux
**참고**
기본적으로 CentOS Stream은 업데이트에 대한 CVE 정보를 제공하지 않습니다. 그러나 Fedora가 게시하는 EPEL(Extra Packages for Enterprise Linux) 리포지토리와 같은 서드 파티 리포지토리를 사용하여 이러한 지원을 허용할 수 있습니다. 자세한 내용은 Fedora Wiki의 [EPEL](https://fedoraproject.org/wiki/EPEL)을 참조하세요.
현재 CVE ID 값은 `Missing` 또는 `Failed` 상태인 패치에 대해서만 보고됩니다.
상황과 패치 목표가 보장하는 대로 패치 기준의 승인 또는 거부된 패치 목록에 CVE ID를 추가할 수도 있습니다.
승인 및 거부된 패치 목록 작업에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md)
+ [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md)
+ [Linux 기반 시스템에서 패치 기준 규칙 사용 방법](patch-manager-linux-rules.md)
+ [패치 설치 방법](patch-manager-installing-patches.md)
**참고**
경우에 따라 Microsoft는 업데이트된 날짜와 시간을 지정하지 않는 애플리케이션에 대한 패치를 릴리스합니다. 이 경우 업데이트된 `01/01/1970`의 날짜 및 시간은 기본적으로 제공됩니다.
## 패치 규정 준수 결과 보기
AWS Systems Manager 콘솔에서 패치 규정 준수 결과를 보려면 다음 절차를 따릅니다.
**참고**
Amazon Simple Storage Service(Amazon S3) 버킷에 다운로드되는 패치 규정 준수 보고서 생성에 대한 자세한 내용은 [.csv 패치 규정 준수 보고서 생성](patch-manager-store-compliance-results-in-s3.md) 섹션을 참조하세요.
**패치 규정 준수 결과를 보려면**
1. 다음 중 하나를 수행하세요.
**옵션 1**(권장) - AWS Systems Manager의 도구인 Patch Manager에서 이동합니다.
+ 탐색 창에서 **Patch Manager**를 선택합니다.
+ **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
+ **노드 패치 적용 세부 정보**에서 패치 규정 준수 결과를 검토할 관리형 노드의 노드 ID를 선택합니다. `stopped` 또는 `terminated` 상태인 노드는 여기에 표시되지 않습니다.
+ **세부 정보** 영역의 **속성** 목록에서 **패치**를 선택합니다.
**옵션 2** - AWS Systems Manager의 도구인 Compliance에서 이동합니다.
+ 탐색 창에서 **Compliance**를 선택합니다.
+ [**Compliance 리소스 요약(Compliance resources summary)**]에서 검토하려는 패치 리소스 유형의 열(예: [**규정 미준수 리소스(Non-Compliant resources)**])에서 숫자를 선택합니다.
+ 아래의 **리소스** 목록에서 패치 규정 준수 결과를 검토할 관리형 노드의 ID를 선택합니다.
+ **세부 정보** 영역의 **속성** 목록에서 **패치**를 선택합니다.
**옵션 3** - AWS Systems Manager의 도구인 Fleet Manager에서 이동합니다.
+ 탐색 창에서 **Fleet Manager**를 선택합니다.
+ **관리형 인스턴스** 영역에서 패치 규정 준수 결과를 검토할 관리형 노드의 ID를 선택합니다.
+ **세부 정보** 영역의 **속성** 목록에서 **패치**를 선택합니다.
1. (옵션) 검색 상자(![\[The Search icon\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/search-icon.png))에서 사용 가능한 필터 중에서 선택합니다.
예를 들어 Red Hat Enterprise Linux(RHEL)의 경우 다음 중에서 선택합니다.
+ 이름
+ 분류
+ State
+ 심각도
Windows Server에 대해 다음 중에서 선택합니다.
+ KB
+ 분류
+ State
+ 심각도
1. 선택한 필터 유형에 사용할 수 있는 값 중 하나를 선택합니다. 예를 들어 [**상태(State)**]를 선택한 경우 [**InstalledPendingReboot**], [**실패(Failed)**], [**누락(Missing)**] 등의 규정 준수 상태를 선택합니다.
**참고**
현재 CVE ID 값은 `Missing` 또는 `Failed` 상태인 패치에 대해서만 보고됩니다.
1. 관리형 노드의 규정 준수 상태에 따라 규정을 준수하지 않는 노드를 수정하기 위해 수행할 작업을 선택할 수 있습니다.
예를 들어 미준수 관리형 노드를 즉시 패치하도록 선택할 수 있습니다. 온디맨드로 관리형 노드 패치에 대한 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
패치 규정 준수 상태에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
# .csv 패치 규정 준수 보고서 생성
AWS Systems Manager 콘솔을 사용하여 선택한 Amazon Simple Storage Service(Amazon S3) 버킷에 .csv 파일로 저장되는 패치 규정 준수 보고서를 생성할 수 있습니다. 단일 온디맨드 보고서를 생성하거나 보고서를 자동으로 생성하는 일정을 지정할 수 있습니다.
단일 관리형 노드 또는 선택한 모든 AWS 계정 및 AWS 리전에 대해 보고서를 생성할 수 있습니다. 단일 노드의 경우 보고서의 경우 규정을 준수하지 않는 노드와 관련된 패치의 ID를 비롯한 포괄적인 세부 정보가 포함됩니다. 모든 관리형 노드에 대한 보고서의 경우 비준수 노드의 패치 수와 요약 정보만 제공됩니다.
보고서가 생성된 후 Amazon Quick과 같은 도구를 사용하여 데이터를 가져오고 분석할 수 있습니다. Quick은 대화형 시각적 환경에서 정보를 탐색하고 해석하는 데 사용할 수 있는 비즈니스 인텔리전스(BI) 서비스입니다. 자세한 내용은 [Amazon Quick 사용 설명서](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html)를 참조하세요.
**참고**
사용자 지정 패치 기준선을 생성할 때 해당 패치 기준선에서 승인된 패치의 규정 준수 심각도 수준을 지정할 수 있습니다(예: `Critical` 또는 `High`). 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
보고서가 생성될 때 알림을 보내는 데 사용할 Amazon Simple Notification Service(Amazon SNS) 주제를 지정할 수도 있습니다.
**패치 규정 준수 보고서 생성을 위한 서비스 역할**
보고서를 처음 생성할 때 Systems Manager에서는 S3로 내보내기 프로세스에 사용할 `AWS-SystemsManager-PatchSummaryExportRole`이라는 Automation 수임 역할을 생성합니다.
**참고**
규정 준수 데이터를 암호화된 S3 버킷으로 내보내는 경우 연결된 AWS KMS 키 정책을 업데이트하여 필요한 `AWS-SystemsManager-PatchSummaryExportRole` 권한을 제공해야 합니다. 인스턴스의 경우 이와 비슷한 권한을 S3 버킷의 AWS KMS 정책에 추가합니다.
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "role-arn"
}
```
*role-arn*을 계정에서 생성된 Amazon 리소스 이름(ARN)으로 바꿉니다(형식: `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`).
자세한 내용은 AWS Key Management Service 개발자 안내서**의 [AWS KMS의 키 정책](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)을 참조하세요.
일정에 따라 보고서를 처음 생성할 때 Systems Manager는 내보내기 프로세스에 사용할 서비스 역할 `AWS-SystemsManager-PatchSummaryExportRole`(아직 생성되지 않은 경우)과 함께 `AWS-EventBridge-Start-SSMAutomationRole`이라는 다른 서비스 역할을 생성합니다. `AWS-EventBridge-Start-SSMAutomationRole`은 Amazon EventBridge가 실행서 [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3)을 사용하여 자동화를 시작할 수 있도록 합니다.
이러한 정책 및 역할을 수정하지 않는 것이 좋습니다. 이렇게 하면 패치 규정 준수 보고서 생성이 실패할 수 있습니다. 자세한 내용은 [패치 규정 준수 보고서 생성 문제 해결](#patch-compliance-reports-troubleshooting) 섹션을 참조하세요.
**Topics**
+ [생성된 패치 규정 준수 보고서에는 무엇이 포함되어 있나요?](#patch-compliance-reports-to-s3-examples)
+ [단일 관리형 노드에 대한 패치 규정 준수 보고서 생성](#patch-compliance-reports-to-s3-one-instance)
+ [단일 관리형 노드에 대한 패치 규정 준수 보고서 생성](#patch-compliance-reports-to-s3-all-instances)
+ [패치 규정 준수 보고 기록 보기](#patch-compliance-reporting-history)
+ [패치 규정 준수 보고 일정 보기](#patch-compliance-reporting-schedules)
+ [패치 규정 준수 보고서 생성 문제 해결](#patch-compliance-reports-troubleshooting)
## 생성된 패치 규정 준수 보고서에는 무엇이 포함되어 있나요?
이 주제에서는 지정된 S3 버킷에 생성되어 다운로드되는 패치 규정 준수 보고서에 포함된 콘텐츠 유형에 대한 정보를 제공합니다.
### 단일 관리형 노드에 대한 보고서 형식
단일 관리형 노드에 대해 생성된 보고서는 요약 정보와 세부 정보를 모두 제공합니다.
[샘플 보고서 다운로드(단일 노드)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)
단일 관리형 노드에 대한 요약 정보에는 다음이 포함됩니다.
+ 인덱스
+ 인스턴스 ID
+ 인스턴스 이름
+ 인스턴스 IP
+ 플랫폼 이름
+ 플랫폼 버전
+ SSM Agent 버전
+ 패치 기준
+ 패치 그룹
+ 규정 준수 상태
+ 규정 준수 심각도
+ 규정 미준수 중요 심각도 패치 수
+ 규정 미준수 높음 심각도 패치 수
+ 규정 미준수 중간 심각도 패치 수
+ 규정 미준수 낮음 심각도 패치 수
+ 규정 미준수 정보 심각도 패치 수
+ 규정 미준수 지정되지 않음 심각도 패치 수
단일 관리형 노드에 대한 세부 정보에는 다음이 포함됩니다.
+ 인덱스
+ 인스턴스 ID
+ 인스턴스 이름
+ 패치 이름
+ KB ID/패치 ID
+ 패치 상태
+ 최근 보고 시간
+ Compliance 수준
+ 패치 심각도
+ 패치 분류
+ CVE ID
+ 패치 기준
+ 로그 URL
+ 인스턴스 IP
+ 플랫폼 이름
+ 플랫폼 버전
+ SSM Agent 버전
**참고**
사용자 지정 패치 기준선을 생성할 때 해당 패치 기준선에서 승인된 패치의 규정 준수 심각도 수준을 지정할 수 있습니다(예: `Critical` 또는 `High`). 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
### 모든 관리형 노드에 대한 보고서 형식
모든 관리형 노드에 대해 생성된 보고서는 요약 정보만 제공합니다.
[샘플 보고서 다운로드(모든 관리형 노드)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)
모든 관리형 노드에 대한 요약 정보에는 다음이 포함됩니다.
+ 인덱스
+ 인스턴스 ID
+ 인스턴스 이름
+ 인스턴스 IP
+ 플랫폼 이름
+ 플랫폼 버전
+ SSM Agent 버전
+ 패치 기준
+ 패치 그룹
+ 규정 준수 상태
+ 규정 준수 심각도
+ 규정 미준수 중요 심각도 패치 수
+ 규정 미준수 높음 심각도 패치 수
+ 규정 미준수 중간 심각도 패치 수
+ 규정 미준수 낮음 심각도 패치 수
+ 규정 미준수 정보 심각도 패치 수
+ 규정 미준수 지정되지 않음 심각도 패치 수
## 단일 관리형 노드에 대한 패치 규정 준수 보고서 생성
다음 절차에 따라 AWS 계정의 단일 관리형 노드에 대한 패치 요약 보고서를 생성합니다. 단일 관리형 노드에 대한 보고서는 패치 이름 및 ID를 포함하여 규정을 위반하는 각 패치에 대한 세부 정보를 제공합니다.
**단일 관리형 노드에 대한 패치 규정 준수 보고서 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
1. 보고서를 생성할 관리형 노드의 행에 대한 버튼을 선택한 다음 **세부 정보 보기(View detail)**를 선택합니다.
1. **패치 요약(Patch summary)** 섹션에서 **S3로 내보내기(Export to S3)**를 선택합니다.
1. [**보고서 이름(Report name)**]에 나중에 보고서를 식별하는 데 도움이 되는 이름을 입력합니다.
1. [**보고 빈도(Reporting frequency)**]에서 다음 중 하나를 선택합니다.
+ [**온디맨드(On demand)**] - 일회성 보고서를 생성합니다. 9단계로 건너뜁니다.
+ [**일정에 따라(On a schedule)**] - 보고서를 자동으로 생성하기 위한 반복 일정을 지정합니다. 계속해서 8단계를 진행합니다.
1. [**일정 유형(Schedule type)**]에서 3일마다와 같은 비율 표현식을 지정하거나 cron 표현식을 제공하여 보고서 빈도를 설정합니다.
Cron 표현식에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요.
1. [**버킷 이름(Bucket name)**]에서 .csv 보고서 파일을 저장할 S3 버킷의 이름을 선택합니다.
**중요**
2019년 3월 20일 이후에 시작된 AWS 리전에서 작업하는 경우 동일한 리전의 S3 버킷을 선택해야 합니다. 이 날짜 이후에 시작된 리전은 기본적으로 해제되어 있습니다. 자세한 내용과 이러한 리전의 목록은 **Amazon Web Services 일반 참조의 [리전 활성화](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)를 참조하세요.
1. (옵션) 보고서가 생성될 때 알림을 보내려면 다음 위치에서 **SNS 주제(SNS topic)** 섹션을 확장하고, **Amazon Resource Name(ARN)**에서 기존 Amazon SNS 주제를 선택합니다.
1. **제출**을 선택합니다.
생성된 보고서의 기록 보기에 대한 자세한 내용은 [패치 규정 준수 보고 기록 보기](#patch-compliance-reporting-history) 섹션을 참조하세요.
생성한 보고 일정의 세부 정보 보기에 대한 자세한 내용은 [패치 규정 준수 보고 일정 보기](#patch-compliance-reporting-schedules) 섹션을 참조하세요.
## 단일 관리형 노드에 대한 패치 규정 준수 보고서 생성
다음 절차에 따라 AWS 계정의 모든 관리형 노드에 대한 패치 요약 보고서를 생성합니다. 모든 관리형 노드에 대한 보고서에는 규정을 위반하는 노드와 규정 미준수 패치 수가 나와 있습니다. 패치의 이름이나 다른 식별자는 제공하지 않습니다. 이러한 추가 세부 정보를 보려면 단일 관리형 노드에 대한 패치 규정 준수 보고서를 생성합니다. 자세한 내용은 이번 주제 전반부의 [단일 관리형 노드에 대한 패치 규정 준수 보고서 생성](#patch-compliance-reports-to-s3-one-instance) 섹션을 참조하세요.
**모든 관리형 노드에 대한 패치 규정 준수 보고서 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
1. [**S3로 내보내기(Export to S3)**]를 선택합니다. (노드 ID를 먼저 선택하지 마세요.)
1. [**보고서 이름(Report name)**]에 나중에 보고서를 식별하는 데 도움이 되는 이름을 입력합니다.
1. [**보고 빈도(Reporting frequency)**]에서 다음 중 하나를 선택합니다.
+ [**온디맨드(On demand)**] - 일회성 보고서를 생성합니다. 8단계로 건너뜁니다.
+ [**일정에 따라(On a schedule)**] - 보고서를 자동으로 생성하기 위한 반복 일정을 지정합니다. 계속해서 7단계를 진행합니다.
1. [**일정 유형(Schedule type)**]에서 3일마다와 같은 비율 표현식을 지정하거나 cron 표현식을 제공하여 보고서 빈도를 설정합니다.
Cron 표현식에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요.
1. [**버킷 이름(Bucket name)**]에서 .csv 보고서 파일을 저장할 S3 버킷의 이름을 선택합니다.
**중요**
2019년 3월 20일 이후에 시작된 AWS 리전에서 작업하는 경우 동일한 리전의 S3 버킷을 선택해야 합니다. 이 날짜 이후에 시작된 리전은 기본적으로 해제되어 있습니다. 자세한 내용과 이러한 리전의 목록은 **Amazon Web Services 일반 참조의 [리전 활성화](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)를 참조하세요.
1. (옵션) 보고서가 생성될 때 알림을 보내려면 다음 위치에서 **SNS 주제(SNS topic)** 섹션을 확장하고, **Amazon Resource Name(ARN)**에서 기존 Amazon SNS 주제를 선택합니다.
1. **제출**을 선택합니다.
생성된 보고서의 기록 보기에 대한 자세한 내용은 [패치 규정 준수 보고 기록 보기](#patch-compliance-reporting-history) 섹션을 참조하세요.
생성한 보고 일정의 세부 정보 보기에 대한 자세한 내용은 [패치 규정 준수 보고 일정 보기](#patch-compliance-reporting-schedules) 섹션을 참조하세요.
## 패치 규정 준수 보고 기록 보기
이 주제의 정보를 사용하여 AWS 계정에서 생성된 패치 규정 준수 보고서에 대한 세부 정보를 볼 수 있습니다.
**패치 규정 준수 보고 기록을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
1. [**모든 S3 내보내기 보기(View all S3 exports)**]를 선택하고 [**내보내기 기록(Export history)**] 탭을 선택합니다.
## 패치 규정 준수 보고 일정 보기
이 주제의 정보를 사용하여 AWS 계정에서 생성된 패치 규정 준수 보고 일정에 대한 세부 정보를 볼 수 있습니다.
**패치 규정 준수 보고 기록을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
1. **모든 S3 내보내기 보기(View all S3 exports)**를 선택하고 **보고서 예약 역할(Report schedule rules)** 탭을 선택합니다.
## 패치 규정 준수 보고서 생성 문제 해결
다음 정보를 사용하여 AWS Systems Manager의 도구인 Patch Manager에서 패치 규정 준수 보고서 생성 문제를 해결할 수 있습니다.
**Topics**
+ [`AWS-SystemsManager-PatchManagerExportRolePolicy` 정책이 손상되었다는 메시지가 나타납니다.](#patch-compliance-reports-troubleshooting-1)
+ [패치 규정 준수 정책 또는 역할을 삭제한 후 예약된 보고서가 성공적으로 생성되지 않습니다.](#patch-compliance-reports-troubleshooting-2)
### `AWS-SystemsManager-PatchManagerExportRolePolicy` 정책이 손상되었다는 메시지가 나타납니다.
**문제**: `AWS-SystemsManager-PatchManagerExportRolePolicy`가 손상되었음을 나타내는 다음과 비슷한 오류 메시지가 나타납니다.
```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any
role that uses it, then try again. Systems Manager recreates the roles and policies
you have deleted.
```
+ **솔루션**: 새 패치 규정 준수 보고서를 생성하기 전에 Patch Manager 콘솔 또는 AWS CLI를 사용하여 영향을 받는 역할과 정책을 삭제합니다.
**콘솔을 사용하여 손상된 정책을 삭제하는 방법**
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. 다음 중 하나를 수행하세요.
**온디맨드 보고서** - 일회성 온디맨드 보고서를 생성하는 동안 문제가 발생한 경우 왼쪽 탐색에서 [**정책(Policies)**]을 선택하고 `AWS-SystemsManager-PatchManagerExportRolePolicy`를 검색한 다음 정책을 삭제합니다. 그런 다음 [**역할(Roles)**]을 선택하고 `AWS-SystemsManager-PatchSummaryExportRole`을 검색한 다음 역할을 삭제합니다.
**예약된 보고서** - 일정에 따라 보고서를 생성하는 동안 문제가 발생한 경우 왼쪽 탐색에서 **정책**을 선택하고, 한 번에 하나씩 `AWS-EventBridge-Start-SSMAutomationRolePolicy` 및 `AWS-SystemsManager-PatchManagerExportRolePolicy`를 검색하고, 각 정책을 삭제합니다. 그런 다음 [**역할(Roles)**]을 선택하고 한 번에 하나씩 `AWS-EventBridge-Start-SSMAutomationRole` 및 `AWS-SystemsManager-PatchSummaryExportRole`을 검색한 다음 각 역할을 삭제합니다.
**AWS CLI를 사용하여 손상된 정책을 삭제하는 방법**
*자리 표시자 값*을 계정 ID로 바꿉니다.
+ 일회성 온디맨드 보고서를 생성하는 동안 문제가 발생한 경우 다음과 같은 명령을 실행합니다.
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
일정에 따라 보고서를 생성하는 동안 문제가 발생한 경우 다음과 같은 명령을 실행합니다.
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
```
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
두 절차 중 하나를 완료한 후 단계에 따라 새 패치 규정 준수 보고서를 생성하거나 예약합니다.
### 패치 규정 준수 정책 또는 역할을 삭제한 후 예약된 보고서가 성공적으로 생성되지 않습니다.
**문제**: 보고서를 처음 생성할 때 Systems Manager는 내보내기 프로세스에 사용할 서비스 역할과 정책을 생성합니다(`AWS-SystemsManager-PatchSummaryExportRole` 및 `AWS-SystemsManager-PatchManagerExportRolePolicy`). 일정에 따라 보고서를 처음 생성할 때 Systems Manager는 다른 서비스 역할과 정책을 생성합니다(`AWS-EventBridge-Start-SSMAutomationRole` 및 `AWS-EventBridge-Start-SSMAutomationRolePolicy`). 이를 통해 Amazon EventBridge는 실행서 [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3)을 사용하여 자동화를 시작할 수 있습니다.
이러한 정책 또는 역할을 삭제하면 일정과 지정된 S3 버킷 및 Amazon SNS 주제 간의 연결이 끊어질 수 있습니다.
+ **해결 방법**: 이 문제를 해결하려면 이전 일정을 삭제하고 문제가 발생한 일정을 대체할 새 일정을 만드는 것이 좋습니다.
# Patch Manager로 규정 미준수 관리형 노드 문제 해결
이 섹션의 주제에서는 패치 규정을 위반하는 관리형 노드를 식별하는 방법과 노드가 규정을 준수하도록 하는 방법을 간략히 소개합니다.
**Topics**
+ [규정 미준수 관리형 노드 식별](patch-manager-find-noncompliant-nodes.md)
+ [패치 규정 준수 상태 값](patch-manager-compliance-states.md)
+ [규정 미준수 관리형 노드 패치 적용](patch-manager-compliance-remediation.md)
# 규정 미준수 관리형 노드 식별
2개의 AWS Systems Manager 문서(SSM 문서) 중 하나를 실행하면 규정 위반 관리형 노드가 식별됩니다. 이들 SSM 문서는 AWS Systems Manager의 도구인 Patch Manager의 각 관리형 노드에 대한 적절한 패치 기준을 참조합니다. 그런 다음 관리형 노드의 패치 상태를 평가하고 규정 준수 결과를 제공합니다.
규정 미준수 관리형 노드를 식별하거나 업데이트하는 데 사용하는 두 가지 SSM 문서가 있습니다(`AWS-RunPatchBaseline` 및 `AWS-RunPatchBaselineAssociation`). 각 문서는 서로 다른 프로세스에서 사용되며 규정 준수 결과는 여러 채널을 통해 제공됩니다. 다음 표에는 이러한 문서 간의 차이점이 요약되어 있습니다.
**참고**
Patch Manager에서 패치 규정 준수 데이터를 AWS Security Hub CSPM로 보낼 수 있습니다. Security Hub CSPM에서는 우선순위가 높은 보안 알림 및 규정 준수 상태를 포괄적으로 파악할 수 있습니다. 또한 플릿의 패치 상태를 모니터링합니다. 자세한 내용은 [Patch Manager와 AWS Security Hub CSPM 통합](patch-manager-security-hub-integration.md) 섹션을 참조하세요.
| | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` |
| --- | --- | --- |
| 문서를 사용하는 프로세스 | **온디맨드로 패치** - **지금 패치(Patch now)** 옵션을 사용하여 온디맨드로 관리형 노드를 스캔하거나 패치할 수 있습니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요. **Systems Manager Quick Setup 패치 정책** - AWS Systems Manager의 도구인 Quick Setup에서 전체 조직, 일부 조직 단위 또는 단일 AWS 계정에 대해 별도의 일정에 따라 누락된 패치를 검색하거나 설치할 수 있는 패치 구성 기능을 생성할 수 있습니다. 자세한 내용은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 섹션을 참조하세요. **명령 실행** - AWS Systems Manager의 도구인 Run Command의 작업에서 `AWS-RunPatchBaseline`을 수동으로 실행할 수 있습니다. 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요. **유지 관리 기간** - Run Command 태스크 유형에서 SSM 문서 `AWS-RunPatchBaseline`을 사용하는 유지 관리 기간을 생성할 수 있습니다. 자세한 내용은 [자습서: 콘솔을 사용하여 패치를 위한 유지 관리 기간 생성](maintenance-window-tutorial-patching.md) 섹션을 참조하세요. | **Systems Manager Quick Setup 호스트 관리** - Quick Setup에서 Systems Manager 호스트 관리 구성 옵션을 활성화하여 관리형 인스턴스의 패치 규정 준수 여부를 검사할 수 있습니다. 자세한 내용은 [Quick Setup을 사용한 Amazon EC2 호스트 관리 설정](quick-setup-host-management.md) 섹션을 참조하세요. **Systems Manager [Explorer](Explorer.md)** - AWS Systems Manager의 도구인 Explorer를 허용하면 정기적으로 관리형 인스턴스의 패치 규정 준수 여부를 검사하여 Explorer 대시보드에 결과를 보고합니다. |
| 패치 검사 결과 데이터의 형식 | `AWS-RunPatchBaseline` 실행 후 Patch Manager가 AWS Systems Manager의 도구인 Inventory에 `AWS:PatchSummary` 객체를 전송합니다. 이 보고서는 패치 작업이 성공하는 경우에만 생성되며 규정 준수 상태가 계산된 시기를 식별하는 캡처 시간을 포함합니다. | `AWS-RunPatchBaselineAssociation` 실행 후 Patch Manager가 Systems Manager Inventory에 `AWS:ComplianceItem` 객체를 전송합니다. |
| 콘솔에서 패치 규정 준수 보고서 보기 | [Systems Manager Configuration Compliance](systems-manager-compliance.md) 및 [관리형 노드 작업](fleet-manager-managed-nodes.md)에서 `AWS-RunPatchBaseline`을 사용하는 프로세스에 대한 패치 규정 준수 정보를 볼 수 있습니다. 자세한 내용은 [패치 규정 준수 결과 보기](patch-manager-view-compliance-results.md) 섹션을 참조하세요. | Quick Setup을 사용하여 관리형 인스턴스의 패치 준수 여부를 스캔하는 경우에는 [Systems Manager Fleet Manager](fleet-manager.md)에서 규정 준수 보고서를 볼 수 있습니다. Fleet Manager 콘솔에서 관리형 노드의 노드 ID를 선택합니다. **일반** 메뉴에서 **구성 준수**를 선택합니다. Explorer를 사용하여 관리형 인스턴스의 패치 규정 준수 여부를 검사하는 경우 Explorer와 [Systems Manager OpsCenter](OpsCenter.md) 모두에서 규정 준수 보고서를 볼 수 있습니다. |
| 패치 규정 준수 결과를 보기 위한 AWS CLI 명령 | `AWS-RunPatchBaseline`을 사용하는 프로세스의 경우 다음 AWS CLI 명령을 사용하여 관리형 노드의 패치에 대한 요약 정보를 볼 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | `AWS-RunPatchBaselineAssociation`을 사용하는 프로세스의 경우 다음 AWS CLI 명령을 사용하여 인스턴스의 패치에 대한 요약 정보를 볼 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) |
| 패치 작업 | `AWS-RunPatchBaseline`을 사용하는 프로세스의 경우 작업에서 `Scan` 작업만 실행할지 아니면 `Scan and install` 작업을 실행할지 지정합니다. (규정 미준수 관리형 노드를 식별하고 문제를 해결하지는 않는 것이 목표라면 `Scan` 작업만 실행합니다.) | AWS-RunPatchBaselineAssociation을 사용하는 Quick Setup 및 Explorer 프로세스는 Scan 작업만 실행합니다. |
| 추가 정보 | [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) |
보고되는 다양한 패치 규정 준수 상태에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
패치 규정을 위반하는 관리형 노드 수정에 대한 자세한 내용은 [규정 미준수 관리형 노드 패치 적용](patch-manager-compliance-remediation.md) 섹션을 참조하세요.
# 패치 규정 준수 상태 값
관리형 노드의 패치에 대한 정보에는 각 개별 패치의 상태에 대한 보고서가 포함됩니다.
**작은 정보**
관리형 노드에 특정 패치 규정 준수 상태를 할당하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface(AWS CLI) 명령 또는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 작업을 사용합니다. 콘솔에서는 규정 준수 상태를 할당할 수 없습니다.
다음 표의 정보를 사용하여 관리형 노드가 패치 규정을 위반하는 이유를 식별할 수 있습니다.
## Debian Server 및 Ubuntu Server의 패치 규정 준수 값
Debian Server 및 Ubuntu Server의 경우 다양한 규정 준수 상태로 패키지를 분류하는 규칙은 다음 표에 설명되어 있습니다.
**참고**
`INSTALLED`, `INSTALLED_OTHER`, `MISSING` 상태 값을 평가할 때 다음 사항에 유의하세요. 패치 기준을 생성하거나 업데이트할 때 **비보안 업데이트 포함** 확인란을 선택하지 않으면 패치 후보 버전이 다음 리포지토리의 패치로 제한됩니다.
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`)
`debian-security` (Debian Server)
[**비보안 업데이트 포함(Include nonsecurity updates)**] 확인란을 선택하면 다른 리포지토리의 패치도 고려됩니다.
| 패치 상태 | 설명 | 규정 준수 상태 |
| --- | --- | --- |
| **`INSTALLED`** | 패치가 패치 기준에 나열되고 관리형 노드에 설치됩니다. 개인이 수동으로 설치하거나 `AWS-RunPatchBaseline` 문서가 관리형 노드에서 실행되었을 때 개인이나 Patch Manager가 자동으로 설치했을 수 있습니다. | 규정 준수 |
| **`INSTALLED_OTHER`** | 패치가 기준에 포함되지 않았거나 기준에서 승인되지 않았지만 관리형 노드에 설치되었습니다. 패치가 수동으로 설치되었거나 패키지가 승인된 다른 패치의 필수 종속성이거나 패치가 InstallOverrideList 작업에 포함되었을 수 있습니다. [**거부된 패치(Rejected patches)**] 작업으로 `Block`을 지정하지 않으면 `INSTALLED_OTHER` 패치에는 설치되었지만 거부된 패치도 포함됩니다. | 규정 준수 |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT`는 다음 중 하나를 의미할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-compliance-states.html) 어느 쪽도 모두 패치가 이 상태일 때 재부팅이 *필요*하다는 의미가 아니며, 패치가 설치된 이후 노드가 재부팅되지 않았다는 것만을 의미합니다. | 규정 미준수 |
| **`INSTALLED_REJECTED`** | 패치가 관리형 노드에 설치되었지만 **거부된 패치(Rejected patches)** 목록에 지정되었습니다. 이는 일반적으로 패치가 거부된 패치 목록에 추가되기 이전에 설치된 경우에 해당합니다. | 규정 미준수 |
| **`MISSING`** | 패치가 기준에 승인되었지만 관리형 노드에 설치되지 않았습니다. `AWS-RunPatchBaseline` 문서 태스크를 (설치 대신) 검사하도록 구성하는 경우 시스템은 검사 도중에 있었지만 설치되지는 않은 패치에 대해 이 상태를 보고합니다. | 규정 미준수 |
| **`FAILED`** | 패치가 기준에 승인되었지만 인스턴스에 설치될 수 없었습니다. 이 상황을 해결하려면 문제를 이해하는 데 도움이 될 수 있는 정보에 대한 명령 출력을 검토합니다. | 규정 미준수 |
## 다른 운영 체제의 패치 규정 준수 값
Debian Server 및 Ubuntu Server 외에 모든 운영 체제의 경우 다양한 규정 준수 상태로 패키지를 분류하는 규칙은 다음 표에 설명되어 있습니다.
| 패치 상태 | 설명 | Compliance 값 |
| --- | --- | --- |
| **`INSTALLED`** | 패치가 패치 기준에 나열되고 관리형 노드에 설치됩니다. 개인이 수동으로 설치하거나 `AWS-RunPatchBaseline` 문서가 노드에서 실행되었을 때 개인이나 Patch Manager가 자동으로 설치했을 수 있습니다. | 규정 준수 |
| 6 | 패치가 기준에 없지만 관리형 노드에 설치되었습니다. 이에 대한 원인은 다음 두 가지가 있을 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-compliance-states.html) | 규정 준수 |
| **`INSTALLED_REJECTED`** | 패치가 관리형 노드에 설치되었지만 거부된 패치(Rejected patches) 목록에 지정되었습니다. 이는 일반적으로 패치가 거부된 패치 목록에 추가되기 이전에 설치된 경우에 해당합니다. | 규정 미준수 |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT`는 다음 중 하나를 의미할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-compliance-states.html) 어느 쪽도 모두 패치가 이 상태일 때 재부팅이 *필요*하다는 의미가 아니며, 패치가 설치된 이후 노드가 재부팅되지 않았다는 것만을 의미합니다. | 규정 미준수 |
| **`MISSING`** | 패치가 기준에 승인되었지만 관리형 노드에 설치되지 않았습니다. `AWS-RunPatchBaseline` 문서 태스크를 (설치 대신) 검사하도록 구성하는 경우 시스템은 검사 도중에 있었지만 설치되지는 않은 패치에 대해 이 상태를 보고합니다. | 규정 미준수 |
| **`FAILED`** | 패치가 기준에 승인되었지만 인스턴스에 설치될 수 없었습니다. 이 상황을 해결하려면 문제를 이해하는 데 도움이 될 수 있는 정보에 대한 명령 출력을 검토합니다. | 규정 미준수 |
| 6 | *이 규정 준수 상태는 Windows Server 운영 체제에 대해서만 보고됩니다.* 패치가 기준에 승인되었지만 패치를 사용하는 서비스 또는 기능이 관리형 노드에 설치되지 않았습니다. 예를 들어 인터넷 정보 서비스(IIS)와 같은 웹 서버 서비스에 대한 패치는 해당 패치가 기준에 승인되었지만 웹 서비스가 관리형 노드에 설치되지 않은 경우 `NOT_APPLICABLE`로 표시됩니다. 패치가 후속 업데이트로 대체된 경우에도 패치를 `NOT_APPLICABLE`로 표시할 수 있습니다. 즉, 이후 업데이트가 설치되고 `NOT_APPLICABLE` 업데이트가 더 이상 필요하지 않습니다. | 해당 사항 없음 |
| AVAILABLE\$1SECURITY\$1UPDATES | *이 규정 준수 상태는 Windows Server 운영 체제에 대해서만 보고됩니다.* 패치 기준에서 승인되지 않은 사용 가능한 보안 업데이트 패치는 사용자 지정 패치 기준에 정의된 규정 준수 값 `Compliant` 또는 `Non-Compliant`를 가질 수 있습니다. 패치 기준을 생성하거나 업데이트할 때 사용 가능하지만 패치 기준에 지정된 설치 기준을 충족하지 않아 승인되지 않은 보안 패치에 할당할 상태를 선택합니다. 예를 들어 설치 전에 패치가 릴리스된 후 장기간 대기하도록 지정한 경우 설치하려는 보안 패치를 건너뛸 수 있습니다. 지정된 대기 기간 동안 패치 업데이트가 릴리스되면 패치 설치 대기 기간이 다시 시작됩니다. 대기 기간이 너무 길면 여러 버전의 패치가 릴리스될 수 있지만 설치되지는 않습니다. 패치 요약 수에서 패치가 `AvailableSecurityUpdate`로 보고되면 패치는 항상 `AvailableSecurityUpdateCount`에 포함됩니다. 이러한 패치를 `NonCompliant`로 보고하도록 기준이 구성된 경우 `SecurityNonCompliantCount`에도 포함됩니다. 이러한 패치를 `Compliant`로 보고하도록 기준이 구성된 경우 `SecurityNonCompliantCount`에 포함되지 않습니다. 이러한 패치는 항상 심각도가 지정되지 않은 상태로 보고되며 `CriticalNonCompliantCount`에 포함되지 않습니다. | 사용 가능한 보안 업데이트에 대해 선택한 옵션에 따라 Compliant 또는 Non-Compliant. 콘솔을 사용하여 패치 기준을 생성하거나 업데이트하려면 **사용 가능한 보안 업데이트 규정 준수 상태** 필드에서 이 옵션을 지정합니다. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) 또는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html) 명령을 실행하는 경우 `available-security-updates-compliance-status` 파라미터에서 이 옵션을 지정합니다. |
¹ 상태가 `INSTALLED_OTHER` 및 `NOT_APPLICABLE`인 패치의 경우 Patch Manager는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html) 명령에 기반을 둔 쿼리 결과에서 `Classification` 및 `Severity`의 값과 같은 일부 데이터를 생략합니다. 이 작업은 AWS Systems Manager의 도구인 Inventory의 개별 노드에 대한 데이터 제한을 초과하는 것을 방지하기 위해 실시됩니다. 모든 패치 세부 정보를 보려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 명령을 사용합니다.
# 규정 미준수 관리형 노드 패치 적용
관리형 노드의 패치 규정 준수 여부를 확인하는 데 사용할 수 있는 것과 동일한 AWS Systems Manager 도구와 프로세스를 사용하여 노드가 현재 적용되는 패치 규정을 준수하도록 할 수 있습니다. 관리형 노드가 패치 규정을 준수하도록 하려면 AWS Systems Manager의 도구인 Patch Manager가 `Scan and install` 작업을 실행해야 합니다. (규정 미준수 관리형 노드를 식별만 하고 해결은 하지 않는 것이 목표라면 그 대신에 `Scan` 작업을 실행합니다. 자세한 내용은 [규정 미준수 관리형 노드 식별](patch-manager-find-noncompliant-nodes.md) 섹션을 참조하세요.)
**Systems Manager 사용하여 패치 설치**
여러 도구 중에서 선택하여 `Scan and install` 작업을 실행할 수 있습니다.
+ (권장) Systems Manager의 도구인 Quick Setup에서 패치 정책을 구성하여 전체 조직, 일부 조직 단위 또는 단일 AWS 계정의 일정에 따라 누락된 패치를 설치할 수 있습니다. 자세한 내용은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 섹션을 참조하세요.
+ Run Command 태스크 유형에서 Systems Manager 문서(SSM 문서) `AWS-RunPatchBaseline`을 사용하는 유지 관리 기간을 생성합니다. 자세한 내용은 [자습서: 콘솔을 사용하여 패치를 위한 유지 관리 기간 생성](maintenance-window-tutorial-patching.md) 섹션을 참조하세요.
+ Run Command 작업에서 `AWS-RunPatchBaseline`을 수동으로 실행합니다. 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
+ [**지금 패치(Patch now)**] 옵션을 사용하여 온디맨드로 패치를 설치합니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
# 패치 규정 준수 데이터를 생성한 실행 식별
패치 규정 준수 데이터는 가장 최근에 성공한 패치 작업의 특정 시점 스냅샷을 나타냅니다. 각 규정 준수 보고서에는 어떤 작업이 규정 준수 데이터를 언제 생성했는지 식별하는 데 도움이 되는 실행 ID와 캡처 시간이 모두 포함되어 있습니다.
인스턴스에서 패치 규정 준수를 검사하기 위해 여러 유형의 작업을 수행하는 경우, 스캔할 때마다 이전 스캔의 패치 규정 준수 데이터를 덮어씁니다. 따라서 패치 규정 준수 데이터에 예상치 못한 결과가 발생할 수 있습니다.
예를 들어 현지 시간으로 매일 오전 2시에 패치 규정 준수를 스캔하는 패치 정책을 생성한다고 가정해 보겠습니다. 이 패치 정책은 심각도가 `Critical`, `Important` 및 `Moderate`로 표시된 패치를 대상으로 하는 패치 기준선을 사용합니다. 이 패치 기준선은 몇 가지 명시적으로 거부된 패치도 지정합니다.
또한 현지 시간으로 매일 오전 4시에 동일한 관리형 노드 세트를 스캔하도록 유지 관리 기간이 이미 설정되어 있고, 사용자가 이 설정은 삭제하거나 비활성화하지 않는다고 가정해 보겠습니다. 해당 유지 관리 기간의 태스크에는 심각도 `Critical`인 패치만 대상으로 하고 특정 패치를 제외하지 않는 다른 패치 기준선을 사용합니다.
유지 관리 기간에 의해 이 두 번째 스캔이 수행되면 첫 번째 스캔의 패치 규정 준수 데이터가 삭제되고 두 번째 스캔의 패치 규정 준수로 교체됩니다.
따라서 패치 작업에서 스캔 및 설치에는 자동화된 한 가지 방법만 사용하는 것이 좋습니다. 패치 정책을 설정하는 경우 패치 규정 준수를 검사하는 다른 방법을 삭제하거나 비활성화해야 합니다. 자세한 내용은 다음 항목을 참조하세요.
+ 유지 관리 기간에서 패치 작업을 제거하려면 - [콘솔을 사용하여 유지 관리 기간 태스크 업데이트 또는 등록 취소](sysman-maintenance-update.md#sysman-maintenance-update-tasks)
+ State Manager 연결을 삭제하려면 – [연결 삭제](systems-manager-state-manager-delete-association.md).
호스트 관리 구성에서 일일 패치 규정 준수 검사를 비활성화하려면 Quick Setup에서 다음을 수행합니다.
1. 탐색 창에서 **Quick Setup**를 선택합니다.
1. 업데이트할 호스트 관리 구성을 선택합니다.
1. **Actions(작업), Edit configuration**(구성 편집)을 차례로 선택합니다.
1. **Scan instances for missing patches daily**(매일 누락된 패치에 대한 인스턴스 스캔) 확인란의 선택을 취소합니다.
1. **업데이트**를 선택합니다.
**참고**
**Patch now**(지금 패치) 옵션을 사용하여 관리형 노드의 규정 준수를 검사하면 패치 규정 준수 데이터도 덮어쓰여집니다.
# 관리형 노드 온디맨드 패치
AWS Systems Manager의 도구인 Patch Manager의 **지금 패치** 옵션을 사용하여 Systems Manager 콘솔에서 온디맨드 패치 작업을 실행할 수 있습니다. 즉, 관리형 노드의 규정 준수 상태를 업데이트하거나 비준수 노드에 패치를 설치하기 위해 일정을 생성할 필요가 없습니다. 또한 예약된 패치 기간을 설정하거나 수정하기 위해 AWS Systems Manager의 도구인 Patch Manager와 Maintenance Windows 사이에서 Systems Manager 콘솔을 전환할 필요가 없습니다.
**지금 패치(Patch now)**는 가능한 한 빨리 관리형 노드에 제로데이 업데이트를 적용하거나 다른 중요한 패치를 설치해야 할 때 특히 유용합니다.
**참고**
온디맨드 패치는 한 번에 하나의 AWS 리전-AWS 계정 쌍에 대해서만 지원됩니다. *패치 정책*을 기반으로 한 패치 작업에는 사용할 수 없습니다. 모든 관리형 노드를 규정 준수 상태로 유지하려면 패치 정책을 사용하는 것이 좋습니다. 패치 정책 작업에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
**Topics**
+ ['지금 패치(Patch now)' 작동 방식](#patch-on-demand-how-it-works)
+ ['지금 패치(Patch now)' 실행](#run-patch-now)
## '지금 패치(Patch now)' 작동 방식
**지금 패치(Patch now)**를 실행하려면 2가지 필수 설정만 지정하면 됩니다.
+ 누락된 패치만 스캔할지 아니면 관리형 노드에서 패치를 스캔 *및* 설치할지 여부
+ 작업을 실행할 관리형 노드
**지금 패치(Patch now)** 작업이 실행되면 다른 패치 작업에 대해 선택한 것과 동일한 방식으로 사용할 패치 기준선을 결정합니다. 관리형 노드가 패치 그룹과 연결된 경우 해당 그룹에 대해 지정된 패치 기준선이 사용됩니다. 관리형 노드가 패치 그룹에 연결되어 있지 않은 경우 작업은 관리형 노드의 운영 체제 유형에 대한 기본값으로 현재 설정된 패치 기준을 사용합니다. 미리 정의된 기준 또는 기본값으로 설정한 사용자 정의 기준일 수 있습니다. 패치 기준 선택에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
**지금 패치(Patch now)**에 대해 지정할 수 있는 옵션으로는 패치 후 관리형 노드 재부팅 시기 또는 재부팅 여부 선택, 패치 작업을 위해 로그 데이터를 저장할 Amazon Simple Storage Service(Amazon S3) 버킷 지정, 패치 중 수명 주기 후크로 Systems Manager 문서(SSM 문서) 실행 등이 있습니다.
### '지금 패치'에 대한 동시성 및 오류 임계값
**패치 지금(Patch now)** 작업의 경우 동시성 및 오류 임계값 옵션은 Patch Manager에서 처리합니다. 한 번에 패치할 관리형 노드 수 또는 작업이 실패하기 전에 허용되는 오류 수를 지정할 필요가 없습니다. Patch Manager는 온디맨드로 패치할 때 다음 표에 설명된 동시성 및 오류 임계값 설정을 적용합니다.
**중요**
다음 임계값은 `Scan and install` 작업에만 적용됩니다. `Scan` 작업의 경우 Patch Manager는 최대 1,000개의 노드를 동시에 스캔하고 최대 1,000개의 오류가 발생할 때까지 계속 스캔합니다.
**동시성: 설치 작업**
| **지금 패치(Patch now)** 작업의 총 관리형 노드 수 | 한 번에 스캔 또는 패치되는 관리형 노드 수 |
| --- | --- |
| 25개 미만 | 1 |
| 25\$1100개 | 5% |
| 101\$11,000개 | 8% |
| 1,000개 이상 | 10% |
**오류 임계값: 설치 작업**
| **지금 패치(Patch now)** 작업의 총 관리형 노드 수 | 작업이 실패하기 전에 허용되는 오류 수 |
| --- | --- |
| 25개 미만 | 1 |
| 25\$1100개 | 5 |
| 101\$11,000개 | 10 |
| 1,000개 이상 | 10 |
### '지금 패치' 수명 주기 후크 사용
**지금 패치(Patch now)**에서는 패치 작업 `Install` 중에 SSM 명령 문서를 수명 주기 후크로 실행할 수 있는 기능을 제공합니다. 패치를 적용한 후 또는 재부팅 후 애플리케이션에 패치를 적용하거나 상태 확인을 실행하기 전에 애플리케이션을 종료하는 등의 작업에 이러한 후크를 사용할 수 있습니다.
수명 주기 후크 사용에 대한 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) 섹션을 참조하세요.
다음 표에는 각 후크에 대한 샘플 사용 외에도 세 가지 **지금 패치(Patch now)** 재부팅 옵션 각각에 사용할 수 있는 수명 주기 후크가 나열됩니다.
**수명 주기 후크 및 샘플 사용**
| 재부팅 옵션 | 후크: 설치 전 | 후크: 설치 후 | 후크: 종료 시 | 후크: 예약된 재부팅 후 |
| --- | --- | --- | --- | --- |
| 필요한 경우 재부팅 | 패치가 시작되기 전에 SSM 문서를 실행합니다. 사용 예: 패치 프로세스가 시작되기 전에 애플리케이션을 안전하게 종료합니다. | 패치 작업 종료 시 및 관리형 노드 재부팅 전에 SSM 문서를 실행합니다. 사용 예: 잠재적 재부팅 전에 서드 파티 애플리케이션 설치와 같은 작업을 실행합니다. | 패치 적용 작업이 완료되고 인스턴스가 재부팅되면 SSM 문서를 실행합니다. 사용 예: 패치 후 애플리케이션이 예상대로 실행되고 있는지 확인합니다. | 사용할 수 없음 |
| 인스턴스 재부팅 안 함 | 위와 동일합니다. | 패치 작업 종료 시 SSM 문서를 실행합니다. 사용 예시: 패치 후 애플리케이션이 예상대로 실행되고 있는지 확인합니다. | *사용할 수 없음* | *사용할 수 없음* |
| 재부팅 시간 예약 | 위와 동일합니다. | 인스턴스 재부팅 안 함과 동일합니다. | 사용할 수 없음 | 예약된 재부팅이 완료된 후 바로 SSM 문서를 실행합니다. 사용 예: 재부팅 후 애플리케이션이 예상대로 실행되고 있는지 확인합니다. |
## '지금 패치(Patch now)' 실행
다음 절차에 따라 온디맨드로 관리형 노드를 패치합니다.
**'지금 패치(Patch now)'를 실행하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. [**지금 패치(Patch now)**]를 선택합니다.
1. [**패치 작업(Patching operation)**]에서 다음 중 하나를 선택합니다.
+ **스캔(Scan)**: Patch Manager가 관리형 노드에서 누락된 패치를 찾지만 설치하지는 않습니다. [**Compliance**] 대시보드 또는 패치 규정 준수를 보는 데 사용하는 다른 도구에서 결과를 볼 수 있습니다.
+ **스캔 및 설치(Scan and install)**: Patch Manager가 관리형 노드에서 누락된 패치를 찾아 설치합니다.
1. 이전 단계에서 [**검사 후 설치(Scan and install)**]를 선택한 경우에만 이 단계를 사용합니다. [**재부팅 옵션(Reboot option)**]에서 다음 중 하나를 선택합니다.
+ **필요한 경우 재부팅(Reboot if needed)**: 설치 후 패치 설치를 완료하는 데 필요한 경우에만 Patch Manager가 관리형 노드를 재부팅합니다.
+ **인스턴스 재부팅 안 함(Don't reboot my instances)**: 설치 후 Patch Manager가 관리형 노드를 재부팅하지 않습니다. Patch Manager 밖에서 재부팅을 선택하거나 관리할 때 노드를 수동으로 재부팅할 수 있습니다.
+ **재부팅 시간 예약(Schedule a reboot time)**: Patch Manager가 관리형 노드를 재부팅할 날짜, 시간 및 UTC 시간대를 지정합니다. **지금 패치(Patch now)** 작업을 실행한 후, 예약된 재부팅이 `AWS-PatchRebootAssociation`이라는 이름과 함께 State Manager에 연결로 나열됩니다.
**중요**
기본 패치 작업이 시작된 후에 기본 패치 작업을 취소하면 State Manager의 `AWS-PatchRebootAssociation` 연결이 자동으로 취소되지 않습니다. 예기치 않은 재부팅을 방지하기 위해 예약된 재부팅이 발생하는 것을 더 이상 원하지 않는 경우 State Manager에서 `AWS-PatchRebootAssociation`을 수동으로 삭제해야 합니다. 이렇게 하지 않으면 예기치 않은 시스템 재부팅이 발생하여 프로덕션 워크로드에 영향을 미칠 수 있습니다. 이 연결은 Systems Manager 콘솔의 **State Manager** > **연결**에서 찾을 수 있습니다.
1. [**패치를 적용할 인스턴스(Instances to patch)**] 섹션에서 다음 중 하나를 선택합니다.
+ **모든 인스턴스 패치(Patch all instances)**: Patch Manager가 현재 AWS 리전의 AWS 계정에서 모든 관리형 노드에 대해 지정된 작업을 실행합니다.
+ **지정한 대상 인스턴스만 패치(Patch only the target instances I specify)**: 다음 단계에서 대상으로 지정할 관리형 노드를 지정합니다.
1. 이전 단계에서 [**지정한 대상 인스턴스만 패치(Patch only the target instances I specify)**]를 선택한 경우에만 이 단계를 사용합니다. **대상 선택(Target selection)** 섹션에서 태그를 지정하거나, 수동으로 노드를 선택하거나, 리소스 그룹을 지정하여 이 작업을 실행할 노드를 식별합니다.
**참고**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
리소스 그룹을 대상으로 선택하는 경우 AWS CloudFormation 스택을 기반으로 하는 리소스 그룹은 여전히 기본 `aws:cloudformation:stack-id` 태그로 태그를 지정해야 합니다. 제거된 경우 Patch Manager가 리소스 그룹에 속하는 관리형 노드를 확인하지 못할 수 있습니다.
1. (옵션) 이 패치 작업에서 로그를 생성하고 저장하려면 [**패치 로그 스토리지(Patching log storage)**]에서 로그를 저장할 S3 버킷을 선택합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아니라 인스턴스에 할당된 인스턴스 프로파일(EC2 인스턴스용) 또는 IAM 서비스 역할(하이브리드 정품 인증 시스템)의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md) 또는 [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. (옵션) 패치 작업의 특정 지점 동안 SSM 문서를 수명 주기 후크로 실행하려면 다음을 수행합니다.
+ [**수명 주기 후크 사용(Use lifecycle hooks)**]을 선택합니다.
+ 사용 가능한 각 후크에 대해 작업의 지정된 지점에서 실행할 SSM 문서를 선택합니다.
+ 설치 전
+ 설치 후
+ 종료 시
+ 예약된 재부팅 후
**참고**
기본 문서인 `AWS-Noop`은 작업을 실행하지 않습니다.
1. [**지금 패치(Patch now)**]를 선택합니다.
[**연결 실행 요약(Association execution summary)**] 페이지가 열립니다. (이제 패치 작업에 AWS Systems Manager의 도구인 State Manager의 연결이 사용됩니다.) **작업 요약(Operation summary)** 영역에서 지정한 관리형 노드의 스캔 또는 패치 상태를 모니터링할 수 있습니다.
# 패치 기준 작업
AWS Systems Manager의 도구인 Patch Manager의 패치 기준은 관리형 노드에 대한 설치가 승인되는 패치를 정의합니다. 패치 승인 또는 거부는 하나씩 지정할 수 있습니다. 또한 자동 승인 규칙을 생성하여 특정 유형의 업데이트(예: 필수 업데이트)가 자동 승인되도록 지정할 수도 있습니다. 거부된 목록은 규칙 및 승인 목록을 모두 재정의합니다. 승인된 패치 목록을 사용하여 특정 패키지를 설치하려면 먼저 모든 자동 승인 규칙을 제거하십시오. 임의 패치를 명시적으로 거부로 구분하면 해당 패치는 자동 승인 규칙의 모든 기준을 만족하더라도 승인 또는 설치되지 않습니다. 또한 패치가 해당 관리형 노드에 대해 승인되었더라도 노드의 소프트웨어에 적용되는 경우에만 패치가 관리형 노드에 설치됩니다.
**Topics**
+ [AWS가 미리 정의한 패치 기준 보기](patch-manager-view-predefined-patch-baselines.md)
+ [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md)
+ [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md)
**추가 정보**
+ [패치 기준](patch-manager-patch-baselines.md)
# AWS가 미리 정의한 패치 기준 보기
AWS Systems Manager의 도구인 Patch Manager에는 Patch Manager가 지원하는 각 운영 체제에 대해 미리 정의된 패치 기준이 있습니다. 이 패치 기준선을 사용하거나(기본 패치 기준선은 사용자 지정할 수 없음), 혹은 자체 기준선을 생성할 수도 있습니다. 다음 절차에서는 미리 정의된 패치 기준이 해당 요건을 충족하는지 확인하는 방법을 설명합니다. 패치 기준선에 대한 자세한 내용은 [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md) 섹션을 참조하세요.
**AWS가 미리 정의한 패치 기준을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. 패치 기준 목록에서 미리 정의된 패치 기준 중 하나의 기준 ID를 선택하십시오.
-또는-
현재 AWS 리전에서 Patch Manager에 처음으로 액세스하는 경우 **개요로 시작**을 선택하고, **패치 기준선**을 선택한 다음에 사전 정의된 패치 기준선 중 하나의 기준선 ID를 선택합니다.
**참고**
Windows Server에는 3개의 미리 정의된 패치 기준이 제공됩니다. 패치 기준 `AWS-DefaultPatchBaseline` 및 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows 운영 체제 자체에서 운영 체제 업데이트만 지원합니다. `AWS-DefaultPatchBaseline`은 다른 패치 기준을 지정하지 않는 한 Windows Server 관리형 노드의 기본 패치 기준으로 사용됩니다. 이러한 두 패치 기준의 구성 설정은 동일합니다. 둘 중 더 새로운 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows Server에 대해 미리 정의된 세 번째 패치 기준과 구별하기 위해 생성되었습니다. 해당 패치 기준인 `AWS-WindowsPredefinedPatchBaseline-OS-Applications`는 Windows Server 운영 체제 및 Microsoft에서 릴리스한 지원되는 애플리케이션을 패치하는 데 사용될 수 있습니다.
자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **승인 규칙** 섹션에서 패치 기준선 구성을 검토합니다.
1. 구성이 관리형 노드에 적합한 경우 [패치 그룹 생성 및 관리](patch-manager-tag-a-patch-group.md) 절차로 건너뛸 수 있습니다.
-또는-
자체적으로 기본 패치 기준선을 생성하려면 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 주제를 계속 진행합니다.
# 사용자 정의 패치 기준 작업
AWS Systems Manager의 도구인 Patch Manager에는 Patch Manager가 지원하는 각 운영 체제에 대해 미리 정의된 패치 기준이 있습니다. 이 패치 기준선을 사용하거나(기본 패치 기준선은 사용자 지정할 수 없음), 혹은 자체 기준선을 생성할 수도 있습니다.
다음 절차에서는 사용자 정의 패치 기준을 직접 생성, 업데이트 및 삭제하는 방법을 설명합니다. 패치 기준선에 대한 자세한 내용은 [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md) 섹션을 참조하세요.
**Topics**
+ [Linux를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-linux.md)
+ [macOS를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Windows Server를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-windows.md)
+ [사용자 지정 패치 기준선 업데이트 또는 삭제](patch-manager-update-or-delete-a-patch-baseline.md)
# Linux를 위한 사용자 지정 패치 기준 생성
AWS Systems Manager의 도구인 Patch Manager에서 Linux 관리형 노드에 대한 사용자 정의 패치 기준을 생성하려면 다음 절차를 따릅니다.
macOS 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [macOS를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-macos.md) 섹션을 참조하세요. Windows 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [Windows Server를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-windows.md) 섹션을 참조하세요.
**Linux 관리형 노드의 사용자 정의 패치 기준 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준선** 탭을 선택한 다음 **패치 기준선 생성**을 선택합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **패치 기준선** 탭을 선택한 다음, **패치 기준선 생성**을 선택합니다.
1. **Name(이름)** 필드에 새로운 패치 기준 이름(예: `MyRHELPatchBaseline`)을 입력합니다.
1. (선택 사항) **설명**에 이 패치 기준에 대한 설명을 입력합니다.
1. **Operating system**에서 운영 체제(예: `Red Hat Enterprise Linux`)를 선택합니다.
1. 이 패치 기준을 생성하는 즉시 선택한 운영 체제의 기본값으로 사용하려면 **Set this patch baseline as the default patch baseline for *operating system name* instances(이 패치 기준을 operating system name 인스턴스의 기본 패치 기준으로 설정)** 옆에 있는 확인란을 선택합니다.
**참고**
이 옵션은 2022년 12월 22일에 [패치 정책](patch-manager-policies.md)이 릴리스되기 전에 Patch Manager에 처음 액세스한 경우에만 사용할 수 있습니다.
기존 패치 기준을 기본값으로 설정하는 방법에 대한 자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **Approval rules for operating systems(운영 체제에 대한 승인 규칙)** 섹션에서 필드를 사용하여 자동 승인 규칙을 한 개 이상 생성합니다.
+ **제품**: 승인 규칙이 적용되는 운영 체제 버전입니다(예: `RedhatEnterpriseLinux7.4`). 기본 선택은 `All`입니다.
+ **Classification(분류)**: 승인 규칙이 적용되는 패치 유형입니다(예: `Security` 또는 `Enhancement`). 기본 선택은 `All`입니다.
**작은 정보**
패치 기준을 구성하여 RHEL 7.8과 같이 Linux용 부 버전 업그레이드의 설치 여부를 제어할 수 있습니다. 해당 리포지토리에서 업데이트할 수 있는 경우 Patch Manager를 통해 부 버전 업그레이드를 자동 설치할 수 있습니다.
Linux 운영 체제의 경우 부 버전 업그레이드는 일관되게 분류되지 않습니다. 동일한 커널 버전 내에서도 버그 수정 또는 보안 업데이트로 분류되거나 분류되지 않을 수 있습니다. 다음은 패치 기준으로 패치 설치 여부를 제어하는 몇 가지 옵션입니다.
**옵션 1**: 마이너 버전 업그레이드가 가능한 경우 설치되도록 하기 위한 가장 광범위한 승인 규칙은 **Classification(분류)**을 `All`(\$1)로 지정하고 **Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하는 것입니다.
**옵션 2**: 운영 체제 버전에 대한 패치가 설치되도록 하려면 와일드카드(\$1) 를 사용하여 기준의 **Patch exceptions(패치 예외)** 섹션에서 커널 형식을 지정할 수 있습니다. 예를 들어 RHEL 7.\$1의 커널 형식은 `kernel-3.10.0-*.el7.x86_64`입니다.
부 버전 업그레이드를 포함한 모든 패치가 RHEL 7.\$1 관리형 노드에 적용되도록 하려면 패치 기준의 **Approved patches(승인된 패치)** 목록에 `kernel-3.10.0-*.el7.x86_64`를 입력합니다. (부 버전 패치의 정확한 패키지 이름을 알고 있다면 대신 입력할 수 있음)
**옵션 3**: `AWS-RunPatchBaseline` 문서에서 [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) 파라미터를 사용하여 부 버전 업그레이드 등, 관리형 노드에 적용할 패치를 가장 많이 제어할 수 있습니다. 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
+ **Severity**: 규칙이 적용될 패치의 심각도 값입니다(예: `Critical`). 기본 선택은 `All`입니다.
+ **Auto-approval**: 자동 승인을 위해 패치를 선택하는 방법입니다.
**참고**
Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
+ **Approve patches after a specified number of days**(지정된 일 수 후 패치 승인): 패치가 릴리스 또는 마지막으로 업데이트된 후 자동으로 승인되기까지 Patch Manager가 대기하는 일 수입니다. 0\$1360의 정수를 입력할 수 있습니다. 대부분의 시나리오에서 100일 이상 기다리지 않는 것이 좋습니다.
+ **Approve patches released up to a specific date**(특정 날짜까지 릴리스된 패치 승인): Patch Manager가 해당 날짜 또는 그 이전에 릴리스 또는 업데이트된 모든 패치를 자동으로 적용하는 패치 릴리스 날짜입니다. 예를 들어 2023년 7월 7일을 지정하면 2023년 7월 8일 또는 그 이후에 릴리스되거나 마지막으로 업데이트된 패치가 자동으로 설치되지 않습니다.
+ (선택 사항) **규정 준수 보고**: 기준선에 따라 승인된 패치에 할당하려는 심각도 수준입니다(예: `Critical` 또는 `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
+ **Include non-security updates(비보안 업데이트 포함)**: 보안 관련 패치 외에, 소스 리포지토리에서 사용 가능한 비보안 Linux 운영 체제 패치도 설치하려면 확인란을 선택합니다.
사용자 지정 패치 기준의 승인 규칙 작업에 대한 자세한 내용은 [사용자 지정 기준](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) 섹션을 참조하세요.
1. 승인 규칙을 준수하는 패치 이외에 모든 패치를 명시적으로 승인하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Approved patches(승인된 패치)**에 승인할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ (선택 사항) **Approved patches compliance level(승인된 패치 규정 준수 수준)**에서 규정 준수 수준을 목록의 패치에 할당합니다.
+ 지정하는 승인된 패치가 보안과 관련되지 않은 경우 Linux 운영 체제에 이러한 패치를 설치하려면 **비보안 업데이트 포함** 확인란을 선택합니다.
1. 승인 규칙을 준수하는 패치를 명시적으로 거부하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Rejected patches(거부된 패치)**에 거부할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ [**거부된 패치 작업(Rejected patches action)**]에서 Patch Manager가 [**거부된 패치(Rejected patches)**] 목록에 포함된 패치에 대해 수행할 작업을 선택합니다.
+ [**종속성으로 허용(Allow as dependency)**]: [**거부된 패치(Rejected patches)**] 목록에 있는 패키지는 다른 패키지에 종속성을 가질 때만 설치됩니다. 이 경우 패치 기준을 준수하는 것으로 간주되고 상태가 *InstalledOther*로 보고됩니다. 이는 옵션을 지정하지 않은 경우의 기본 작업입니다.
+ **차단**: **거부된 패치** 목록에 있는 패키지와 종속적으로 그것들을 포함하는 패키지는 어떠한 경우에도 Patch Manager에서 설치되지 않습니다. 패키지가 **거부된 패치** 목록에 추가되기 전에 설치되거나 이후에 Patch Manager 외부에 설치된 경우 패치 기준을 준수하지 않는 것으로 간주되고 상태가 *InstalledRejected*로 보고됩니다.
**참고**
Patch Manager는 패치 종속성을 재귀적으로 검색합니다.
1. (선택 사항) *AmazonLinux2016.03* 및 *AmazonLinux2017.09* 등의 다른 운영 체제 버전에 대해 대체 패치 리포지토리를 지정하려면 **패치 소스** 섹션에서 각 제품에 대해 다음을 수행합니다.
+ **Name**에 소스 구성을 식별하는 데 도움이 되는 이름을 입력합니다.
+ **Product**에서 패치 소스 리포지토리의 운영 체제 버전을 선택합니다(예: `RedhatEnterpriseLinux7.4`).
+ **구성**에서 사용할 yum 리포지토리 구성의 값을 적절한 형식으로 입력합니다.
------
#### [ Example for yum repositories ]
```
[main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
```
**작은 정보**
yum 리포지토리 구성에 사용할 수 있는 기타 옵션에 대한 자세한 내용은 [dnf.conf(5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html)를 참조하세요.
------
#### [ Examples for Ubuntu 서버 and Debian 서버 ]
`deb http://security.ubuntu.com/ubuntu jammy main`
`deb https://site.example.com/debian distribution component1 component2 component3`
Ubuntu Server 리포지토리에 대한 리포지토리 정보는 한 줄로 지정해야 합니다. 더 많은 예제 및 정보는 *Ubuntu Server Manuals* 웹 사이트의 [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) 및 *Debian Wiki*의 [sources.list format](https://wiki.debian.org/SourcesList#sources.list_format)을 참조하세요.
------
각 추가 운영 체제 버전(최대 20개)에 대해 소스 리포지토리를 지정하려면 **Add another source(다른 소스 추가)**를 선택합니다.
대체 소스 패치 리포지토리에 대한 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
1. (선택 사항) **Manage tags(태그 관리)**의 경우, 하나 이상의 태그 키 이름/값 페어를 패치 기준에 적용합니다.
태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 예를 들어, 패치 기준에 태그를 지정하여 패치의 심각도 수준, 해당 패치가 적용되는 운영 체제 제품군 및 환경 유형을 식별할 수 있습니다. 이 경우 다음 키 이름/값 페어와 비슷한 태그를 지정할 수 있습니다.
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. **패치 기준 생성**을 선택합니다.
# macOS를 위한 사용자 지정 패치 기준 생성
AWS Systems Manager의 도구인 Patch Manager에서 macOS 관리형 노드에 대한 사용자 정의 패치 기준을 생성하려면 다음 절차를 따릅니다.
Windows Server 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [Windows Server를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-windows.md) 섹션을 참조하세요. Linux 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [Linux를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-linux.md) 섹션을 참조하세요.
**참고**
일부 AWS 리전에서는 macOS가 지원되지 않습니다. macOS용 Amazon EC2 지원에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 Mac 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)를 참조하세요.
**macOS 관리형 노드의 사용자 정의 패치 기준 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준선** 탭을 선택한 다음 **패치 기준선 생성**을 선택합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **패치 기준선** 탭을 선택한 다음, **패치 기준선 생성**을 선택합니다.
1. **Name(이름)** 필드에 새로운 패치 기준 이름(예: `MymacOSPatchBaseline`)을 입력합니다.
1. (선택 사항) **설명**에 이 패치 기준에 대한 설명을 입력합니다.
1. **운영 체제**에서 macOS를 선택합니다.
1. 이 패치 기준을 생성하는 즉시 macOS의 기본값으로 사용하려면 [**이 패치 기준을 macOS 인스턴스의 기본 패치 기준으로 설정(Set this patch baseline as the default patch baseline for macOS instances)**] 옆에 있는 확인란을 선택합니다.
**참고**
이 옵션은 2022년 12월 22일에 [패치 정책](patch-manager-policies.md)이 릴리스되기 전에 Patch Manager에 처음 액세스한 경우에만 사용할 수 있습니다.
기존 패치 기준을 기본값으로 설정하는 방법에 대한 자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **Approval rules for operating systems(운영 체제에 대한 승인 규칙)** 섹션에서 필드를 사용하여 자동 승인 규칙을 한 개 이상 생성합니다.
+ **제품**: 승인 규칙이 적용되는 운영 체제 버전입니다(예: `BigSur11.3.1` 또는 `Ventura13.7`). 기본 선택은 `All`입니다.
+ **분류**: 패치 작업 중 패키지를 적용하려는 하나 이상의 패키지 관리자입니다. 사용자는 다음 중에서 선택할 수 있습니다.
+ softwareupdate
+ 설치 관리자
+ brew
+ brew cask
기본 선택은 `All`입니다.
+ (선택 사항) **규정 준수 보고**: 기준선에 따라 승인된 패치에 할당하려는 심각도 수준입니다(예: `Critical` 또는 `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
사용자 지정 패치 기준의 승인 규칙 작업에 대한 자세한 내용은 [사용자 지정 기준](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) 섹션을 참조하세요.
1. 승인 규칙을 준수하는 패치 이외에 모든 패치를 명시적으로 승인하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Approved patches(승인된 패치)**에 승인할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ (선택 사항) **Approved patches compliance level(승인된 패치 규정 준수 수준)**에서 규정 준수 수준을 목록의 패치에 할당합니다.
1. 승인 규칙을 준수하는 패치를 명시적으로 거부하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Rejected patches(거부된 패치)**에 거부할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ [**거부된 패치 작업(Rejected patches action)**]에서 Patch Manager가 [**거부된 패치(Rejected patches)**] 목록에 포함된 패치에 대해 수행할 작업을 선택합니다.
+ [**종속성으로 허용(Allow as dependency)**]: [**거부된 패치(Rejected patches)**] 목록에 있는 패키지는 다른 패키지에 종속성을 가질 때만 설치됩니다. 이 경우 패치 기준을 준수하는 것으로 간주되고 상태가 *InstalledOther*로 보고됩니다. 이는 옵션을 지정하지 않은 경우의 기본 작업입니다.
+ **차단**: **거부된 패치** 목록에 있는 패키지와 종속적으로 그것들을 포함하는 패키지는 어떠한 경우에도 Patch Manager에서 설치되지 않습니다. 패키지가 **거부된 패치** 목록에 추가되기 전에 설치되거나 이후에 Patch Manager 외부에 설치된 경우 패치 기준을 준수하지 않는 것으로 간주되고 상태가 *InstalledRejected*로 보고됩니다.
1. (선택 사항) **Manage tags(태그 관리)**의 경우, 하나 이상의 태그 키 이름/값 페어를 패치 기준에 적용합니다.
태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 예를 들어 패치 기준에 태그를 지정하여 지정한 패치의 심각도 수준, 적용되는 패키지 관리자 및 환경 유형을 식별할 수 있습니다. 이 경우 다음 키 이름/값 페어와 비슷한 태그를 지정할 수 있습니다.
+ `Key=PatchSeverity,Value=Critical`
+ `Key=PackageManager,Value=softwareupdate`
+ `Key=Environment,Value=Production`
1. **패치 기준 생성**을 선택합니다.
# Windows Server를 위한 사용자 지정 패치 기준 생성
AWS Systems Manager의 도구인 Patch Manager에서 Windows 관리형 노드에 대한 사용자 정의 패치 기준을 생성하려면 다음 절차를 따릅니다.
Linux 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [Linux를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-linux.md) 섹션을 참조하세요. macOS 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [macOS를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-macos.md) 섹션을 참조하세요.
Windows 서비스 팩 설치에만 제한되는 패치 기준 생성의 예는 [자습서: 콘솔을 사용한 Windows 서비스 팩 설치를 위한 패치 기준 생성](patch-manager-windows-service-pack-patch-baseline-tutorial.md) 섹션을 참조하세요.
**사용자 지정 패치 기준을 생성하려면(Windows)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준선** 탭을 선택한 다음 **패치 기준선 생성**을 선택합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **패치 기준선** 탭을 선택한 다음, **패치 기준선 생성**을 선택합니다.
1. **Name(이름)** 필드에 새로운 패치 기준 이름(예: `MyWindowsPatchBaseline`)을 입력합니다.
1. (선택 사항) **설명**에 이 패치 기준에 대한 설명을 입력합니다.
1. **운영 체제**에서 `Windows`를 선택합니다.
1. **사용 가능한 보안 업데이트 규정 준수 상태**에서 사용 가능하지만 패치 기준에 지정된 설치 기준을 충족하지 않기 때문에 승인되지 않은 보안 패치에 할당하려는 상태(**Non-Compliant** 또는 **Compliant**)를 선택합니다.
예제 시나리오: 설치 전에 패치가 릴리스된 후 장기간 대기하도록 지정한 경우 설치하려는 보안 패치를 건너뛸 수 있습니다. 지정된 대기 기간 동안 패치 업데이트가 릴리스되면 패치 설치 대기 기간이 다시 시작됩니다. 대기 기간이 너무 길면 여러 버전의 패치가 릴리스될 수 있지만 설치되지는 않습니다.
1. 이 패치 기준을 생성하는 즉시 Windows의 기본값으로 사용하려면 **Set this patch baseline as the default patch baseline for Windows Server instances(이 패치 기준을 Windows Server 인스턴스의 기본 패치 기준으로 설정)**를 선택하십시오.
**참고**
이 옵션은 2022년 12월 22일에 [패치 정책](patch-manager-policies.md)이 릴리스되기 전에 Patch Manager에 처음 액세스한 경우에만 사용할 수 있습니다.
기존 패치 기준을 기본값으로 설정하는 방법에 대한 자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **Approval rules for operating systems(운영 체제에 대한 승인 규칙)** 섹션에서 필드를 사용하여 자동 승인 규칙을 한 개 이상 생성합니다.
+ **제품**: 승인 규칙이 적용되는 운영 체제 버전입니다(예: `WindowsServer2012`). 기본 선택은 `All`입니다.
+ **Classification(분류)**: 승인 규칙이 적용되는 패치 유형입니다(예: `CriticalUpdates`, `Drivers` 및 `Tools`). 기본 선택은 `All`입니다.
**작은 정보**
`ServicePacks`를 포함하거나 [**분류(Classification)**] 목록에서 `All`을 선택하여 Windows 서비스 팩 설치를 승인 규칙에 포함할 수 있습니다. 문제 해결 예는 [자습서: 콘솔을 사용한 Windows 서비스 팩 설치를 위한 패치 기준 생성](patch-manager-windows-service-pack-patch-baseline-tutorial.md)을(를) 참조하세요.
+ **Severity**: 규칙이 적용될 패치의 심각도 값입니다(예: `Critical`). 기본 선택은 `All`입니다.
+ **Auto-approval**: 자동 승인을 위해 패치를 선택하는 방법입니다.
+ **Approve patches after a specified number of days**(지정된 일 수 후 패치 승인): 패치가 릴리스 또는 업데이트된 후 자동으로 승인되기까지 Patch Manager가 대기하는 일 수입니다. 0\$1360의 정수를 입력할 수 있습니다. 대부분의 시나리오에서 100일 이상 기다리지 않는 것이 좋습니다.
+ **Approve patches released up to a specific date**(특정 날짜까지 릴리스된 패치 승인): Patch Manager가 해당 날짜 또는 그 이전에 릴리스 또는 업데이트된 모든 패치를 자동으로 적용하는 패치 릴리스 날짜입니다. 예를 들어 2023년 7월 7일을 지정하면 2023년 7월 8일 또는 그 이후에 릴리스되거나 마지막으로 업데이트된 패치가 자동으로 설치되지 않습니다.
+ (선택 사항) **Compliance reporting(규정 준수 보고)**: 기준에서 승인된 패치에 할당할 심각도 수준입니다(예: `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
1. (옵션) [**애플리케이션에 대한 승인 규칙(Approval rules for applications)**] 섹션에서 필드를 사용하여 자동 승인 규칙을 1개 이상 생성합니다.
**참고**
승인 규칙을 지정하는 대신 승인된 패치 및 거부된 패치 목록을 패치 예외로 지정할 수 있습니다. 10단계와 11단계를 참조하세요.
+ **Product family**: 규칙을 지정하려는 일반 Microsoft 제품군입니다(예: `Office` 또는 `Exchange Server`).
+ **제품**: 승인 규칙이 적용되는 애플리케이션 버전입니다(예: `Office 2016` 또는 `Active Directory Rights Management Services Client 2.0 2016`). 기본 선택은 `All`입니다.
+ **Classification**: 승인 규칙이 적용되는 패치 유형입니다(예: `CriticalUpdates`). 기본 선택은 `All`입니다.
+ **Severity**: 규칙이 적용되는 패치의 심각도 값입니다(예: `Critical`). 기본 선택은 `All`입니다.
+ **Auto-approval**: 자동 승인을 위해 패치를 선택하는 방법입니다.
+ **Approve patches after a specified number of days**(지정된 일 수 후 패치 승인): 패치가 릴리스 또는 업데이트된 후 자동으로 승인되기까지 Patch Manager가 대기하는 일 수입니다. 0\$1360의 정수를 입력할 수 있습니다. 대부분의 시나리오에서 100일 이상 기다리지 않는 것이 좋습니다.
+ **Approve patches released up to a specific date**(특정 날짜까지 릴리스된 패치 승인): Patch Manager가 해당 날짜 또는 그 이전에 릴리스 또는 업데이트된 모든 패치를 자동으로 적용하는 패치 릴리스 날짜입니다. 예를 들어 2023년 7월 7일을 지정하면 2023년 7월 8일 또는 그 이후에 릴리스되거나 마지막으로 업데이트된 패치가 자동으로 설치되지 않습니다.
+ (선택 사항) **규정 준수 보고**: 기준선에 따라 승인된 패치에 할당하려는 심각도 수준입니다(예: `Critical` 또는 `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
1. (옵션) 승인 규칙에 따라 패치를 선택하는 대신 패치를 명시적으로 승인하려면 [**패치 예외(Patch exceptions)**] 섹션에서 다음을 수행합니다.
+ **Approved patches(승인된 패치)**에 승인할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ (선택 사항) **Approved patches compliance level(승인된 패치 규정 준수 수준)**에서 규정 준수 수준을 목록의 패치에 할당합니다.
1. 승인 규칙을 준수하는 패치를 명시적으로 거부하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Rejected patches(거부된 패치)**에 거부할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ [**거부된 패치 작업(Rejected patches action)**]에서 Patch Manager가 [**거부된 패치(Rejected patches)**] 목록에 포함된 패치에 대해 수행할 작업을 선택합니다.
+ **종속성으로 허용**: Windows Server에서는 패키지 종속성 개념을 지원하지 않습니다. **거부된 패치** 목록에 있는 패키지가 노드에 이미 설치되어 있는 경우 해당 상태가 `INSTALLED_OTHER`로 보고됩니다. 노드에 아직 설치되지 않은 패키지는 모두 건너뜁니다.
+ **차단**: **거부된 패치** 목록에 있는 패키지는 어떤 경우에도 Patch Manager에서 설치하지 않습니다. 패키지가 **거부된 패치** 목록에 추가되기 전에 설치되거나 이후에 Patch Manager 외부에 설치된 경우 패치 기준을 준수하지 않는 것으로 간주되고 상태가 `INSTALLED_REJECTED`로 보고됩니다.
거부된 패치 작업에 대한 자세한 내용은 [사용자 지정 패치 기준의 거부된 패치 목록 옵션](patch-manager-windows-and-linux-differences.md#rejected-patches-diff)을 참조하세요.
1. (선택 사항) **Manage tags(태그 관리)**의 경우, 하나 이상의 태그 키 이름/값 페어를 패치 기준에 적용합니다.
태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 예를 들어, 패치 기준에 태그를 지정하여 패치의 심각도 수준, 해당 패치가 적용되는 운영 체제 제품군 및 환경 유형을 식별할 수 있습니다. 이 경우 다음 키 이름/값 페어와 비슷한 태그를 지정할 수 있습니다.
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. **패치 기준 생성**을 선택합니다.
# 사용자 지정 패치 기준선 업데이트 또는 삭제
AWS Systems Manager의 도구인 Patch Manager에서 생성한 사용자 지정 패치 기준을 업데이트하거나 삭제할 수 있습니다. 패치 기준선을 업데이트할 때 이름 또는 설명, 승인 규칙 및 승인된 패치와 거부된 패치 예외를 변경할 수 있습니다. 패치 기준선에 적용된 태그를 업데이트할 수도 있습니다. 패치 기준선이 생성된 운영 체제 유형은 변경할 수 없으며 AWS에서 제공한 미리 정의된 패치 기준은 변경할 수 없습니다.
## 패치 기준선 업데이트 또는 삭제
다음 단계에 따라 패치 기준선을 업데이트하거나 삭제하십시오.
**중요**
Quick Setup의 패치 정책 구성에 사용될 수 있는 사용자 지정 패치 기준선을 삭제할 때는 주의해야 합니다.
Quick Setup에서 [패치 정책 구성](patch-manager-policies.md)을 사용하는 경우 사용자 지정 패치 기준선에 대한 업데이트는 한 시간에 한 번씩 Quick Setup과 동기화됩니다.
패치 정책에서 참조된 사용자 지정 패치 기준선이 삭제되면 해당 패치 정책의 Quick Setup **Configuration details**(구성 세부 정보) 페이지에 배너가 표시됩니다. 배너는 패치 정책에서 더 이상 존재하지 않는 패치 기준선을 참조하고 있으며 후속 패치 작업이 실패할 것임을 알려줍니다. 이 경우 Quick Setup **Configurations**(구성) 페이지로 돌아가서 Patch Manager 구성을 선택하고 **Actions**(작업), **Edit configuration**(구성 편집)을 선택합니다. 삭제된 패치 기준선 이름이 강조 표시되며, 영향을 받는 운영 체제의 새 패치 기준선을 선택해야 합니다.
**패치 기준선을 업데이트 또는 삭제하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. 업데이트 또는 삭제할 패치 기준선을 선택하고 다음 중 하나를 수행합니다.
+ AWS 계정에서 패치 기준선을 제거하려면 [**삭제(Delete)**]를 선택합니다. 시스템에 작업을 확인하라는 메시지가 표시됩니다.
+ 패치 기준선 이름 또는 설명, 승인 규칙 또는 패치 예외를 변경하려면 **편집**을 선택하십시오. **패치 기준선 편집** 페이지에서 원하는 값과 옵션을 변경한 다음 **변경 사항 저장**을 선택하십시오.
+ 패치 기준선에 적용된 태그를 추가, 변경 또는 삭제하려면 **태그** 탭을 선택한 다음 **태그 편집**을 선택하십시오. **Edit patch baseline tags(패치 기준선 태그 편집)** 페이지에서 패치 기준 태그를 업데이트한 다음 **변경 사항 저장**을 선택합니다.
선택 가능한 구성에 대한 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
# 기존 패치 기준을 기본값으로 설정
**중요**
여기서 선택한 기본 패치 기준선은 패치 정책을 기반으로 하는 패치 작업에 적용되지 않습니다. 패치 정책에서는 고유한 패치 기준선 사양을 사용합니다. 패치 정책에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
AWS Systems Manager의 도구인 Patch Manager에 사용자 정의 패치 기준을 생성할 때, 기준을 생성하는 즉시 연결된 운영 체제 유형의 기본값으로 설정할 수 있습니다. 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
기존 패치 기준을 운영 체제 유형의 기본값으로 설정할 수도 있습니다.
**참고**
2022년 12월 22일의 패치 정책 릴리스 이전 또는 이후에 처음 Patch Manager에 액세스했는지에 따라 사용자가 따르는 단계가 달라집니다. 해당 날짜 이전에 Patch Manager를 사용했다면 콘솔 절차를 사용할 수 있습니다. 그렇지 않으면 AWS CLI 절차를 사용합니다. 콘솔 절차에서 참조되는 **작업** 메뉴는 패치 정책 릴리스 이전에 Patch Manager가 사용되지 않은 리전에는 표시되지 않습니다.
**패치 기준을 기본값으로 설정하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. [**패치 기준(Patch baselines)**] 탭을 선택합니다.
1. 패치 기준 목록에서 현재 운영 체제 유형의 기본값으로 설정되지 않은 패치 기준의 버튼을 선택합니다.
**Default baseline(기본 기준)** 열은 현재 어떤 기준이 기본값으로 설정되어 있는지 나타냅니다.
1. **작업** 메뉴에서 **Set default patch baseline(기본 패치 기준 설정)**을 선택하십시오.
**중요**
2022년 12월 22일 이전에 현재 AWS 계정 및 리전에서 Patch Manager로 작업하지 않은 경우 **작업** 메뉴를 사용할 수 없습니다. 자세한 내용은 이 주제 앞부분의 **참고**를 참조하세요.
1. 확인 대화 상자가 나타나면 **Set default(기본값으로 설정)**를 선택합니다.
**패치 기준선을 기본값으로 설정하는 방법(AWS CLI)**
1. 사용 가능한 패치 기준선과 해당 ID, Amazon 리소스 이름(ARN) 목록을 보려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html) 명령을 실행합니다.
```
aws ssm describe-patch-baselines
```
1. 기준선을 연결된 운영 체제의 기본값으로 설정하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) 명령을 실행합니다. *baseline-id-or-ARN*을 사용할 사용자 지정 패치 기준선 또는 사전 정의된 기준선의 ID로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--baseline-id baseline-id-or-ARN
```
다음은 사용자 지정 기준선을 기본값으로 설정하는 예제입니다.
```
aws ssm register-default-patch-baseline \
--baseline-id pb-abc123cf9bEXAMPLE
```
다음은 AWS에서 관리하는 사전 정의된 기준선을 기본값으로 설정하는 예제입니다.
```
aws ssm register-default-patch-baseline \
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--baseline-id baseline-id-or-ARN
```
다음은 사용자 지정 기준선을 기본값으로 설정하는 예제입니다.
```
aws ssm register-default-patch-baseline ^
--baseline-id pb-abc123cf9bEXAMPLE
```
다음은 AWS에서 관리하는 사전 정의된 기준선을 기본값으로 설정하는 예제입니다.
```
aws ssm register-default-patch-baseline ^
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
```
------
# 사용 가능한 패치 보기
AWS Systems Manager의 도구인 Patch Manager로 지정된 운영 체제 및 특정 운영 체제 버전(옵션)에 대해 사용 가능한 패치를 모두 볼 수 있습니다.
**작은 정보**
사용 가능한 패치 목록을 생성하여 파일에 저장하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 명령을 사용하고 기본 설정 [출력](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html)을 지정합니다.
**사용 가능한 패치를 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. [**패치(Patches)**] 탭을 클릭합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **패치** 탭을 선택합니다.
**참고**
Windows Server의 경우 Windows Server 업데이트 서비스(WSUS)에서 사용할 수 있는 업데이트가 **패치** 탭에 표시됩니다.
1. [**운영 체제(Operating system)**]에서 사용 가능한 패치를 보려는 운영 체제(예: `Windows` 또는 `Amazon Linux`)를 선택합니다.
1. (옵션) [**제품(Product)**]에서 OS 버전(예 :`WindowsServer2019` 또는 `AmazonLinux2018.03`)을 선택합니다.
1. (옵션) 결과에 대한 정보 열을 추가하거나 제거하려면 [**패치(Patches)**] 목록 오른쪽 위에 있는 구성 버튼(![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/configure-button.png))을 선택합니다. (기본적으로 [**패치(Patches)**] 탭에는 사용 가능한 패치 메타데이터 중 일부에 대한 열만 표시됩니다.)
뷰에 추가할 수 있는 메타데이터 유형에 대한 자세한 내용은 *AWS Systems Manager API Reference*의 [Patch](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html)를 참조하세요.
# 패치 그룹 생성 및 관리
작업에서 패치 정책을 사용하지 **않는 경우 태그를 사용하여 패치 그룹에 관리형 노드를 추가하면 패치 적용 작업을 구성할 수 있습니다.
**참고**
패치 그룹은 *패치 정책*을 기반으로 하는 패치 적용 작업에 사용되지 않습니다. 패치 정책 작업에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
2022년 12월 22일에 패치 정책 지원이 릴리스될 당시에 패치 그룹을 사용하고 있지 않았던 계정-리전 페어에 대해서는 콘솔에서 패치 그룹 기능이 지원되지 않습니다. 이 날짜 이전에 패치 그룹을 사용하기 시작한 계정-리전 페어에서는 패치 그룹 기능을 계속 사용할 수 있습니다.
패치 적용 작업에 태그를 사용하려면 태그 키 `Patch Group` 또는 `PatchGroup`을 관리형 노드에 적용해야 합니다. 패치 그룹에 태그 값으로 제공할 이름도 지정해야 합니다. 값을 지정하는 데는 제한이 없지만 태그 키는 `Patch Group` 또는 `PatchGroup`이어야 합니다.
[EC2 인스턴스 메타데이터에서 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(스페이스 사용 안 함)이 필요합니다.
태그를 사용하여 관리형 노드를 그룹화한 후에 패치 기준에 패치 그룹 값을 추가해야 합니다. 패치 그룹을 패치 기준선에 등록하여 패치 적용 작업 중 올바른 패치가 설치되는지 확인할 수 있습니다. 패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
이 주제의 작업을 완료하여 태그를 노드 및 패치 기준선과 함께 사용하여 패치를 적용할 관리형 노드를 준비합니다. 작업 1은 Amazon EC2 인스턴스에 패치를 적용하는 경우에만 필요합니다. 작업 2는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 비 EC2 인스턴스에 패치를 적용하는 경우에만 필요합니다. 작업 3은 모든 관리형 노드에 필요합니다.
**작은 정보**
AWS CLI 명령 `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` 또는 Systems Manager API 작업 ssm-agent-minimum-s3-permissions-required`[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)`를 사용하여 관리형 노드에 태그를 추가할 수도 있습니다.
**Topics**
+ [태스크 1: 태그를 사용하여 패치 그룹에 EC2 인스턴스 추가](#sysman-patch-group-tagging-ec2)
+ [태스크 2: 태그를 사용하여 패치 그룹에 관리형 인스턴스 추가](#sysman-patch-group-tagging-managed)
+ [작업 3: 패치 기준에 패치 그룹 추가](#sysman-patch-group-patchbaseline)
## 태스크 1: 태그를 사용하여 패치 그룹에 EC2 인스턴스 추가
Systems Manager 콘솔 또는 Amazon EC2 콘솔을 사용하여 EC2 인스턴스에 태그를 추가할 수 있습니다. 이 작업은 Amazon EC2 인스턴스에 패치를 적용하는 경우에만 필요합니다.
**중요**
**Allow tags in instance metadata**(인스턴스 메타데이터의 태그 허용) 옵션이 인스턴스에서 활성화된 경우 `Patch Group` 태그(공백 포함)를 Amazon EC2 인스턴스에 적용할 수 없습니다. 인스턴스 메타데이터에서 태그를 허용하면 태그 키 이름에 공백이 포함되지 않습니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 태그 키 `PatchGroup`(공백 없음)을 사용해야 합니다.
**옵션 1: 패치 그룹에 EC2 인스턴스를 추가하는 방법(Systems Manager 콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **관리형 인스턴스** 목록에서 패치 적용을 위해 구성하려는 관리형 EC2 인스턴스의 ID를 선택합니다. EC2 인스턴스의 노드 ID는 `i-`으로 시작합니다.
**참고**
Amazon EC2 콘솔과 AWS CLI를 사용하는 경우 Systems Manager에 사용하도록 아직 구성되지 않은 인스턴스에 `Key = Patch Group` 또는 `Key = PatchGroup` 태그를 적용할 수 있습니다.
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **태그** 탭을 선택한 다음에 **편집**을 선택합니다.
1. 왼쪽 열에 **Patch Group** 또는 **PatchGroup**을 입력합니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(공백 없음)을 사용해야 합니다.
1. 오른쪽 열에서 패치 그룹의 이름으로 사용할 태그 값을 입력합니다.
1. **저장**을 선택합니다.
1. 이 절차를 반복하여 동일한 패치 그룹에 다른 EC2 인스턴스를 추가합니다.
**옵션 2: 패치 그룹에 EC2 인스턴스를 추가하는 방법(Amazon EC2 콘솔)**
1. [Amazon EC2 콘솔](https://console.aws.amazon.com/ec2/)을 열고 탐색 창에서 [**인스턴스(Instances)**]를 선택합니다.
1. 인스턴스 목록에서 패치로 구성할 인스턴스를 선택합니다.
1. **작업** 메뉴에서 **인스턴스 설정**, **태그 관리**를 선택합니다.
1. **새로운 태그 추가**를 선택합니다.
1. **Key**(키)에 **Patch Group** 또는 **PatchGroup**을 입력합니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(공백 없음)을 사용해야 합니다.
1. **값**의 경우 패치 그룹의 이름으로 사용할 값을 입력합니다.
1. **저장**을 선택합니다.
1. 이 절차를 반복하여 동일한 패치 그룹에 다른 인스턴스를 추가합니다.
## 태스크 2: 태그를 사용하여 패치 그룹에 관리형 인스턴스 추가
이 주제의 단계에 따라 AWS IoT Greengrass 코어 디바이스와 비 EC2 하이브리드 정품 인증 관리형 노드에 태그를 추가합니다(mi-\$1). 이 작업은 하이브리드 및 멀티클라우드 환경에서 비 EC2 인스턴스에 패치를 적용하는 경우에만 필요합니다.
**참고**
Amazon EC2 콘솔을 사용하여 비 EC2 관리형 노드의 태그를 추가할 수 없습니다.
**패치 그룹에 비 EC2 관리형 노드를 추가하는 방법(Systems Manager 콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **관리형 노드** 목록에서 패치로 구성할 관리형 노드의 이름을 선택합니다.
**참고**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **태그** 탭을 선택한 다음에 **편집**을 선택합니다.
1. 왼쪽 열에 **Patch Group** 또는 **PatchGroup**을 입력합니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(공백 없음)을 사용해야 합니다.
1. 오른쪽 열에서 패치 그룹의 이름으로 사용할 태그 값을 입력합니다.
1. **저장**을 선택합니다.
1. 이 절차를 반복하여 동일한 패치 그룹에 다른 관리형 노드를 추가합니다.
## 작업 3: 패치 기준에 패치 그룹 추가
특정 패치 기준을 관리형 노드와 연결하려면 패치 기준에 패치 그룹 값을 추가해야 합니다. 패치 그룹을 패치 기준선에 등록하여 패치 적용 작업 중 올바른 패치가 설치되는지 확인할 수 있습니다. 이 작업 EC2 인스턴스, 비 EC2 관리형 노드 또는 둘 다에 패치를 적용하든 상관없이 필요합니다.
패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
**참고**
2022년 12월 22일의 [패치 정책](patch-manager-policies.md) 릴리스 이전 또는 이후에 처음 Patch Manager에 액세스했는지에 따라 사용자가 따르는 단계가 달라집니다.
**패치 기준선에 패치 그룹을 추가하는 방법(Systems Manager 콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. 현재 AWS 리전에서 처음으로 Patch Manager에 액세스하고 Patch Manager 시작 페이지가 열리면 **개요로 시작**을 선택합니다.
1. **패치 기준선** 탭을 선택한 다음에 **패치 기준선** 목록에서 패치 그룹에 대해 구성하려는 패치 기준선의 이름을 선택합니다.
패치 정책 릴리스 이후까지 처음 Patch Manager에 액세스하지 않았다면 직접 생성한 사용자 지정 기준선을 선택해야 합니다.
1. **기준선 ID** 세부 정보 페이지에 **작업** 메뉴가 포함되어 있으면 다음을 수행합니다.
+ **작업**, **Modify patch groups(패치 그룹 수정)**을 선택합니다.
+ [태스크 2: 태그를 사용하여 패치 그룹에 관리형 인스턴스 추가](#sysman-patch-group-tagging-managed)에서 관리형 노드에 추가한 태그 값**을 입력한 다음에 **추가**를 선택합니다.
**기준선 ID** 세부 정보 페이지에 **작업** 메뉴가 포함되어 있지 **않으면 콘솔에서 패치 그룹을 구성할 수 없습니다. 그 대신에 다음 중 하나를 수행할 수 있습니다.
+ (권장) AWS Systems Manager의 도구인 Quick Setup에서 패치 정책을 설정하여 패치 기준을 하나 이상의 EC2 인스턴스에 매핑합니다.
자세한 내용은 [Quick Setup 패치 정책 사용](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) 및 [Quick Setup 패치 정책을 사용하여 조직 전반의 패치 적용 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)를 참조하세요.
+ AWS Command Line Interface(AWS CLI) 의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html)명령을 사용하여 패치 그룹을 구성합니다.
# Patch Manager와 AWS Security Hub CSPM 통합
[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)는 AWS 내의 보안 상태에 대한 포괄적인 뷰를 제공합니다. Security Hub CSPM은 AWS 계정, AWS 서비스 및 지원되는 서드 파티 파트너 제품에서 보안 데이터를 수집합니다. Security Hub CSPM을 사용하면 환경에서 보안 업계 표준 및 모범 사례를 준수하는지 확인할 수 있습니다. Security Hub CSPM은 보안 추세를 분석하고 우선순위가 가장 높은 보안 문제를 식별하는 데 도움이 됩니다.
AWS Systems Manager의 도구인 Patch Manager와 Security Hub CSPM 간 통합을 사용하여 Patch Manager에서 Security Hub CSPM으로 규정 미준수 노드에 관한 조사 결과를 보낼 수 있습니다. 결과는 보안 점검 또는 보안 관련 감지의 관찰 가능한 기록입니다. 그러면 Security Hub CSPM은 보안 태세 분석에 이러한 패치 관련 결과를 포함할 수 있습니다.
다음 항목의 정보는 패치 작업에 사용하는 구성 방법 또는 유형에 관계없이 적용됩니다.
+ Quick Setup에서 구성된 패치 정책
+ Quick Setup에서 구성된 호스트 관리 옵션
+ 패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
+ 온디맨드 **Patch now**(지금 패치) 작업
**Contents**
+ [Patch Manager에서 Security Hub CSPM으로 조사 결과를 전송하는 방법](#securityhub-integration-sending-findings)
+ [Patch Manager이(가) 보내는 결과의 유형](#securityhub-integration-finding-types)
+ [조사 결과 전송 지연 시간](#securityhub-integration-finding-latency)
+ [Security Hub CSPM을 사용할 수 없을 때 다시 시도](#securityhub-integration-retry-send)
+ [Security Hub CSPM에서 조사 결과 보기](#securityhub-integration-view-findings)
+ [Patch Manager의 일반적 조사 결과](#securityhub-integration-finding-example)
+ [통합 설정 및 구성](#securityhub-integration-enable)
+ [결과 전송을 중지하는 방법](#securityhub-integration-disable)
## Patch Manager에서 Security Hub CSPM으로 조사 결과를 전송하는 방법
Security Hub CSPM에서는 보안 문제를 조사 결과와 같이 추적합니다. 일부 결과는 다른 AWS 서비스 또는 서드 파티에서 감지한 문제에서 비롯됩니다. Security Hub CSPM에는 보안 문제를 감지하고 조사 결과를 생성하는 데 사용하는 규칙 집합도 있습니다.
Patch Manager는 결과를 Security Hub CSPM으로 보내는 Systems Manager 도구 중 하나입니다. SSM 문서(`AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` 또는 `AWS-RunPatchBaselineWithHooks`)를 실행하여 패치 작업을 수행하면 패치 정보가 AWS Systems Manager의 도구인 Inventory나 Compliance 또는 둘 다로 전송됩니다. Inventory나 Compliance 또는 둘 다 데이터를 수신한 후 Patch Manager가 알림을 수신합니다. 그런 다음 Patch Manager가 데이터의 정확성, 형식 및 규정 준수 여부를 평가합니다. 모든 조건이 충족되면 Patch Manager는 데이터를 Security Hub CSPM으로 전달합니다.
Security Hub CSPM은 이러한 모든 출처를 총망라하여 조사 결과를 관리할 도구를 제공합니다. 사용자는 조사 결과 목록을 조회하고 필터링할 수 있으며 주어진 조사 결과의 세부 정보를 조회할 수도 있습니다. 자세한 내용은 *AWS Security Hub User Guide*의 [Viewing findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html)를 참조하세요. 또한 주어진 조사 결과에 대한 조사 상태를 추적할 수도 있습니다. 자세한 내용은 *AWS Security Hub User Guide*의 [Taking action on findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html)를 참조하세요.
Security Hub CSPM의 모든 조사 결과는 표준 JSON 형식을 사용합니다. 이를 AWS Security Finding Format(ASFF)이라고 합니다. ASFF에는 문제의 출처, 영향을 받은 리소스와 결과의 현재 상태 등에 관한 세부 정보가 포함됩니다. 자세한 내용은 *AWS Security Hub User Guide*의 [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm)을 참조하세요.
### Patch Manager이(가) 보내는 결과의 유형
Patch Manager는 [AWS Security Finding Format(ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html)을 사용하여 결과를 Security Hub CSPM으로 보냅니다. ASFF의 경우, `Types` 필드가 조사 결과 유형을 제공합니다. Patch Manager의 결과는 `Types`의 값이 다음과 같습니다.
+ 소프트웨어 및 구성 확인/패치 관리
Patch Manager는 규정을 준수하지 않는 관리형 노드당 하나의 조사 결과를 보냅니다. 조사 결과는 리소스 유형 [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance)로 보고되므로 조사 결과는 `AwsEc2Instance` 리소스 유형을 보고하는 다른 Security Hub CSPM 통합과 상호 연관될 수 있습니다. Patch Manager는 작업에서 관리형 노드가 비준수임을 발견한 경우에만 조사 결과를 Security Hub CSPM으로 전달합니다. 조사 결과에는 패치 요약 결과가 포함됩니다.
**참고**
규정 미준수 노드를 Security Hub CSPM에 보고한 후에 노드가 규정을 준수하면 Patch Manager는 Security Hub CSPM에 업데이트를 보내지 않습니다. 필요한 패치를 관리형 노드에 적용한 후 Security Hub CSPM에서 조사 결과를 수동으로 확인할 수 있습니다.
규정 준수 정의에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요. `PatchSummary`에 대한 자세한 내용은 *AWS Security Hub API Reference*의 [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)를 참조하세요.
### 조사 결과 전송 지연 시간
Patch Manager가 새로운 조사 결과를 생성하면 일반적으로 몇 초에서 2시간 이내에 Security Hub CSPM으로 결과가 전송됩니다. 속도는 해당 시간에 처리 중인 AWS 리전의 트래픽에 따라 달라집니다.
### Security Hub CSPM을 사용할 수 없을 때 다시 시도
서비스 중단이 발생하면 AWS Lambda 기능이 실행되어 서비스가 다시 실행된 후 메시지를 기본 대기열에 다시 넣습니다. 메시지가 기본 대기열에 있으면 다시 시도는 자동으로 수행됩니다.
Security Hub CSPM을 사용할 수 없는 경우 Patch Manager는 결과가 수신될 때까지 결과 전송을 재시도합니다.
### Security Hub CSPM에서 조사 결과 보기
이 절차에서는 패치 규정을 준수하지 않는 플릿의 관리형 노드에 대한 Security Hub CSPM의 조사 결과를 보는 방법을 설명합니다.
**패치 규정 준수에 대한 Security Hub CSPM 조사 결과를 검토하는 방법**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/)에서 AWS Security Hub CSPM 콘솔을 엽니다.
1. 탐색 창에서 **조사 결과**를 선택합니다.
1. **필터 추가**(![\[The Search icon\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/search-icon.png)) 상자를 선택합니다.
1. 메뉴의 **필터**에서 **제품 이름**을 선택합니다.
1. 이때 열리는 대화 상자의 첫 번째 필드에서 **is**를 선택한 다음에 두 번째 필드에서 **Systems Manager Patch Manager**를 입력합니다.
1. **Apply(적용)**를 선택합니다.
1. 결과 범위를 좁히는 데 도움이 되도록 원하는 추가 필터를 추가합니다.
1. 자세한 내용을 알아보려는 조사 결과의 제목을 결과 목록에서 선택합니다.
화면 오른쪽에 리소스, 발견된 문제 및 권장 문제 해결에 대한 자세한 정보가 포함된 창이 열립니다.
**중요**
현재 Security Hub CSPM에서는 모든 관리형 노드의 리소스 유형을 `EC2 Instance`로 보고합니다. 여기에는 Systems Manager에서 사용하려고 등록한 온프레미스 서버와 가상 머신이 포함됩니다.
**심각도 분류**
**Systems Manager Patch Manager**의 결과 목록에는 조사 결과의 심각도에 대한 보고서가 포함됩니다. **심각도** 수준에는 최저부터 최고까지 다음이 포함됩니다.
+ **INFORMATIONAL ** – 찾은 문제가 없습니다.
+ **LOW** – 문제 해결이 필요하지 않습니다.
+ **MEDIUM** – 문제를 해결해야 하지만 긴급하지는 않습니다.
+ **HIGH** – 우선적으로 해결해야 할 문제입니다.
+ **CRITICAL** – 문제가 에스컬레이션되지 않도록 즉시 해결해야 합니다.
심각도는 인스턴스의 가장 심각한 규정 미준수 패키지에 의해 결정됩니다. 심각도 수준 여러 개인 패치 기준선이 여러 개 있을 수 있으므로 모든 규정 미준수 패키지 중에서 최고 심각도가 보고됩니다. 예를 들면, 패키지 A의 심각도는 "심각"이고 패키지 B의 심각도는 "낮음"인 2개의 규정 미준수 패키지가 있을 수 있습니다. "심각"이 심각도로 보고됩니다.
심각도 필드는 Patch Manager `Compliance` 필드와 직접적으로 연관됩니다. 이 필드는 규칙과 일치하는 개별 패치에 할당되도록 설정하는 필드입니다. 이 `Compliance` 필드는 개별 패치에 할당되므로 패치 요약 수준에서는 반영되지 않습니다.
**관련 콘텐츠**
+ **AWS Security Hub 사용 설명서의 [조사 결과](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html)
+ **AWS 관리 및 거버넌스 블로그의 [Patch Manager 및 Security Hub로 다중 계정 패치 규정 준수](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/)
## Patch Manager의 일반적 조사 결과
Patch Manager는 [AWS Security Finding Format(ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html)을 사용하여 조사 결과를 Security Hub CSPM으로 보냅니다.
다음은 Patch Manager의 일반적인 조사 결과를 예시로 나타낸 것입니다.
```
{
"SchemaVersion": "2018-10-08",
"Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
"GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"AwsAccountId": "111122223333",
"Types": [
"Software & Configuration Checks/Patch Management/Compliance"
],
"CreatedAt": "2021-11-11T22:05:25Z",
"UpdatedAt": "2021-11-11T22:05:25Z",
"Severity": {
"Label": "INFORMATIONAL",
"Normalized": 0
},
"Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
"Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
"Remediation": {
"Recommendation": {
"Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
"Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
}
},
"SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
"ProductFields": {
"aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"aws/securityhub/ProductName": "Systems Manager Patch Manager",
"aws/securityhub/CompanyName": "AWS"
},
"Resources": [
{
"Type": "AwsEc2Instance",
"Id": "i-02573cafcfEXAMPLE",
"Partition": "aws",
"Region": "us-east-2"
}
],
"WorkflowState": "NEW",
"Workflow": {
"Status": "NEW"
},
"RecordState": "ACTIVE",
"PatchSummary": {
"Id": "pb-0c10e65780EXAMPLE",
"InstalledCount": 45,
"MissingCount": 2,
"FailedCount": 0,
"InstalledOtherCount": 396,
"InstalledRejectedCount": 0,
"InstalledPendingReboot": 0,
"OperationStartTime": "2021-11-11T22:05:06Z",
"OperationEndTime": "2021-11-11T22:05:25Z",
"RebootOption": "NoReboot",
"Operation": "SCAN"
}
}
```
## 통합 설정 및 구성
Patch Manager와 Security Hub CSPM 통합을 사용하려면 Security Hub CSPM을 설정해야 합니다. Security Hub CSPM을 설정하는 방법에 대한 자세한 내용은 *AWS Security Hub 사용 설명서*의 [Security Hub CSPM 설정](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html)을 참조하세요.
다음 절차에서는 Security Hub CSPM이 이미 활성화되어 있지만 Patch Manager 통합이 해제된 경우 Patch Manager와 Security Hub CSPM을 통합하는 방법을 설명합니다. 통합이 수동으로 해제된 경우에만 이 절차를 수행합니다.
**Security Hub CSPM 통합에 Patch Manager를 추가하려면**
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **설정** 탭을 선택합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **설정** 탭을 선택합니다.
1. **Security Hub CSPM으로 내보내기** 섹션 아래의 **패치 규정 준수 결과가 Security Hub로 내보내지지 않음** 오른쪽에서 **사용**을 선택합니다.
## 결과 전송을 중지하는 방법
Security Hub CSPM으로 조사 결과를 전송하는 작업을 중지하려면 Security Hub CSPM 콘솔 또는 API를 사용하면 됩니다.
자세한 내용은 AWS Security Hub 사용 설명서**에서 다음 주제를 참조하세요.
+ [통합에서 결과의 흐름 사용 중지 및 사용 설정(콘솔)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [통합에서 결과의 흐름 사용 중지(Security Hub CSPM API, AWS CLI)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)
# AWS CLI를 사용하여 Patch Manager 리소스 작업
이 섹션에는 AWS Systems Manager의 도구인 Patch Manager에 대한 구성 태스크를 수행하는 데 사용할 수 있는 AWS Command Line Interface(AWS CLI) 명령의 예시가 포함되어 있습니다.
AWS CLI를 사용하여 사용자 맞춤 패치 기준선에 따라 서버 환경을 패치하는 방법은 [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md) 섹션을 참조하세요.
AWS Systems Manager 태스크에 AWS CLI 사용에 대한 자세한 내용은 [AWS CLI Command Reference의 AWS Systems Manager 섹션](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html)을 참조하세요.
**Topics**
+ [패치 기준을 위한 AWS CLI 명령](#patch-baseline-cli-commands)
+ [패치 그룹을 위한 AWS CLI 명령](#patch-group-cli-commands)
+ [패치 요약 및 세부 정보 보기를 위한 AWS CLI 명령](#patch-details-cli-commands)
+ [관리형 노드 스캔 및 패치를 위한 AWS CLI 명령](#patch-operations-cli-commands)
## 패치 기준을 위한 AWS CLI 명령
**Topics**
+ [패치 기준선 생성](#patch-manager-cli-commands-create-patch-baseline)
+ [다른 OS 버전에 대한 사용자 지정 리포지토리가 있는 패치 기준 생성](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [패치 기준선 업데이트](#patch-manager-cli-commands-update-patch-baseline)
+ [패치 기준선 이름 변경](#patch-manager-cli-commands-rename-patch-baseline)
+ [패치 기준선 삭제](#patch-manager-cli-commands-delete-patch-baseline)
+ [모든 패치 기준선 나열](#patch-manager-cli-commands-describe-patch-baselines)
+ [AWS가 제공하는 모든 패치 기준 나열](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [사용자의 패치 기준선 나열](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [패치 기준선 표시](#patch-manager-cli-commands-get-patch-baseline)
+ [기본 패치 기준선 받기](#patch-manager-cli-commands-get-default-patch-baseline)
+ [사용자 지정 패치 기준을 기본값으로 설정](#patch-manager-cli-commands-register-default-patch-baseline)
+ [AWS 패치 기준을 기본값으로 재설정](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [패치 기준선 태그 지정](#patch-manager-cli-commands-add-tags-to-resource)
+ [패치 기준선에 대한 태그 나열](#patch-manager-cli-commands-list-tags-for-resource)
+ [패치 기준선에서 태그 삭제](#patch-manager-cli-commands-remove-tags-from-resource)
### 패치 기준선 생성
다음 명령은 릴리스되고 5일 후 Windows Server 2012 R2에 대한 필수 및 중요 보안 업데이트를 모두 승인하는 패치 기준선을 생성합니다. 또한 승인된 패치 및 거부된 패치 목록에도 패치가 지정되었습니다. 또한 패치 기준에는 프로덕션 환경용임을 나타내는 태그가 지정되어 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Windows-Server-2012R2" \
--tags "Key=Environment,Value=Production" \
--description "Windows Server 2012 R2, Important and Critical security updates" \
--approved-patches "KB2032276,MS10-048" \
--rejected-patches "KB2124261" \
--rejected-patches-action "ALLOW_AS_DEPENDENCY" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Windows-Server-2012R2" ^
--tags "Key=Environment,Value=Production" ^
--description "Windows Server 2012 R2, Important and Critical security updates" ^
--approved-patches "KB2032276,MS10-048" ^
--rejected-patches "KB2124261" ^
--rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 다른 OS 버전에 대한 사용자 지정 리포지토리가 있는 패치 기준 생성
Linux 관리형 노드에만 적용됩니다. 다음 명령은 Amazon Linux 운영 체제의 특정 버전에 사용할 패치 리포지토리를 지정하는 방법을 보여줍니다. 이 샘플에서는 Amazon Linux 2017.09에서 기본적으로 활성화되어 있는 소스 리포지토리를 사용하지만, 관리형 노드에 대해 구성한 다른 소스 리포지토리에도 적용할 수 있습니다.
**참고**
이 복잡한 명령을 보다 잘 설명하기 위해 여기서는 `--cli-input-json` 옵션과 외부 JSON 파일에 저장된 추가 옵션을 사용합니다.
1. `my-patch-repository.json`과 같은 이름의 JSON 파일을 만든 후 다음 내용을 파일에 추가합니다.
```
{
"Description": "My patch repository for Amazon Linux 2",
"Name": "Amazon-Linux-2",
"OperatingSystem": "AMAZON_LINUX_2",
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 7,
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": [
"Important",
"Critical"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"Security",
"Bugfix"
]
},
{
"Key": "PRODUCT",
"Values": [
"AmazonLinux2"
]
}
]
}
}
]
},
"Sources": [
{
"Name": "My-AL2",
"Products": [
"AmazonLinux2"
],
"Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
}
]
}
```
1. 파일을 저장한 디렉터리에서 다음 명령을 실행합니다.
```
aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### 패치 기준선 업데이트
다음 명령은 두 개의 패치를 거부된 것으로 추가하고 하나의 패치를 기존 패치 기준선에 승인된 대로 추가합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--rejected-patches "KB2032276" "MS10-048" \
--approved-patches "KB2124261"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--rejected-patches "KB2032276" "MS10-048" ^
--approved-patches "KB2124261"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001494.035,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 패치 기준선 이름 변경
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001795.287,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 패치 기준선 삭제
```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 모든 패치 기준선 나열
```
aws ssm describe-patch-baselines
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
다음은 AWS 리전의 모든 패치 기준을 나열하는 또 다른 명령입니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[All]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[All]"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### AWS가 제공하는 모든 패치 기준 나열
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[AWS]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[AWS]"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
]
}
```
### 사용자의 패치 기준선 나열
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[Self]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[Self]"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineIdentities":[
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### 패치 기준선 표시
```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```
**참고**
사용자 정의 패치 기준의 경우 패치 기준 ID 또는 전체 Amazon 리소스 이름(ARN)을 지정할 수 있습니다. AWS에서 제공한 패치 기준의 경우 전체 ARN을 지정해야 합니다. 예를 들어 `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`입니다.
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"PatchGroups":[
"Web Servers"
],
"RejectedPatches":[
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1480997823.81,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 기본 패치 기준선 받기
```
aws ssm get-default-patch-baseline --region us-east-2
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### 사용자 지정 패치 기준을 기본값으로 설정
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### AWS 패치 기준을 기본값으로 재설정
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 패치 기준선 태그 지정
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tags "Key=Project,Value=Testing"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tags "Key=Project,Value=Testing"
```
------
### 패치 기준선에 대한 태그 나열
------
#### [ Linux & macOS ]
```
aws ssm list-tags-for-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm list-tags-for-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE"
```
------
### 패치 기준선에서 태그 삭제
------
#### [ Linux & macOS ]
```
aws ssm remove-tags-from-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tag-keys "Project"
```
------
#### [ Windows Server ]
```
aws ssm remove-tags-from-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tag-keys "Project"
```
------
## 패치 그룹을 위한 AWS CLI 명령
**Topics**
+ [패치 그룹 생성](#patch-manager-cli-commands-create-patch-group)
+ [패치 그룹 ‘웹 서버’를 패치 기준선에 등록](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [패치 그룹 'Backend'를 AWS가 제공하는 패치 기준에 등록](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [패치 그룹 등록 표시](#patch-manager-cli-commands-describe-patch-groups)
+ [패치 기준선에서 패치 그룹 등록 취소](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)
### 패치 그룹 생성
**참고**
패치 그룹은 *패치 정책*을 기반으로 하는 패치 적용 작업에 사용되지 않습니다. 패치 정책 작업에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
패치 작업을 쉽게 구성하려면 태그를 사용하여 관리형 노드를 패치 그룹에 추가하는 것이 좋습니다. 패치 그룹은 태그 키 `Patch Group` 또는 `PatchGroup`을 사용해야 합니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(공백 없음)을 사용해야 합니다. 값을 지정하는 데는 제한이 없지만 태그 키는 `Patch Group` 또는 `PatchGroup`이어야 합니다. 패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
태그를 사용하여 관리형 노드를 그룹화한 후에 패치 기준에 패치 그룹 값을 추가해야 합니다. 패치 그룹을 패치 기준선에 등록하여 패치 적용 작업 중 올바른 패치가 설치되는지 확인할 수 있습니다.
#### 태스크 1: 태그를 사용하여 패치 그룹에 EC2 인스턴스 추가
**참고**
Amazon Elastic Compute Cloud(Amazon EC2) 콘솔과 AWS CLI를 사용하는 경우 Systems Manager에 사용하도록 아직 구성되지 않은 인스턴스에 `Key = Patch Group` 또는 `Key = PatchGroup` 태그를 적용할 수 있습니다. `Patch Group` 또는 `Key = PatchGroup` 태그 적용 후 Patch Manager에서 예상되는 EC2 인스턴스가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 확인하세요.
다음 명령을 실행해 EC2 인스턴스에 `PatchGroup` 태그를 추가합니다.
```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```
#### 태스크 2: 태그를 사용하여 패치 그룹에 관리형 인스턴스 추가
다음 명령을 실행해 관리형 노드에 `PatchGroup` 태그를 추가합니다.
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "ManagedInstance" \
--resource-id "mi-0123456789abcdefg" \
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "ManagedInstance" ^
--resource-id "mi-0123456789abcdefg" ^
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### 작업 3: 패치 기준에 패치 그룹 추가
다음 명령을 실행하여 `PatchGroup` 태그 값을 지정된 패치 기준에 연결하십시오.
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Development"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Development"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup": "Development",
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### 패치 그룹 ‘웹 서버’를 패치 기준선에 등록
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Web Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Web Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Web Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 패치 그룹 'Backend'를 AWS가 제공하는 패치 기준에 등록
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
--patch-group "Backend"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
--patch-group "Backend"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Backend",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### 패치 그룹 등록 표시
```
aws ssm describe-patch-groups --region us-east-2
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroupPatchBaselineMappings":[
{
"PatchGroup":"Backend",
"BaselineIdentity":{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":false,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
},
{
"PatchGroup":"Web Servers",
"BaselineIdentity":{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":true,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
}
]
}
```
### 패치 기준선에서 패치 그룹 등록 취소
------
#### [ Linux & macOS ]
```
aws ssm deregister-patch-baseline-for-patch-group \
--region us-east-2 \
--patch-group "Production" \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm deregister-patch-baseline-for-patch-group ^
--region us-east-2 ^
--patch-group "Production" ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Production",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
## 패치 요약 및 세부 정보 보기를 위한 AWS CLI 명령
**Topics**
+ [패치 기준선이 정의한 모든 패치 받기](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [분류 `SECURITY` 및 심각도 `Critical`의 AmazonLinux2018.03에 대한 모든 패치 가져오기](#patch-manager-cli-commands-describe-available-patches-linux)
+ [MSRC 심각도가 `Critical`인 Windows Server 2012에 대한 모든 패치 가져오기](#patch-manager-cli-commands-describe-available-patches)
+ [사용 가능한 모든 패치 받기](#patch-manager-cli-commands-describe-available-patches)
+ [관리형 노드별 패치 요약 상태 받기](#patch-manager-cli-commands-describe-instance-patch-states)
+ [관리형 노드에 대한 패치 규정 준수 세부 정보 받기](#patch-manager-cli-commands-describe-instance-patches)
+ [패치 규정 준수 결과 보기(AWS CLI)](#viewing-patch-compliance-results-cli)
### 패치 기준선이 정의한 모든 패치 받기
**참고**
이 명령은 Windows Server 패치 기준에만 지원됩니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-effective-patches-for-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm describe-effective-patches-for-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"NextToken":"--token string truncated--",
"EffectivePatches":[
{
"PatchStatus":{
"ApprovalDate":1384711200.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system
by installing this update from Microsoft. For a complete listing of the
issues that are included in this update, see the associated Microsoft
Knowledge Base article. After you install this update, you may have to
restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
"ReleaseDate":1384279200.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2876331",
"MsrcNumber":"MS13-089",
"Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
}
},
{
"PatchStatus":{
"ApprovalDate":1428858000.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"Windows Server 2012 R2 Update is a cumulative
set of security updates, critical updates and updates. You
must install Windows Server 2012 R2 Update to ensure that
your computer can continue to receive future Windows Updates,
including security updates. For a complete listing of the
issues that are included in this update, see the associated
Microsoft Knowledge Base article for more information. After
you install this item, you may have to restart your computer.",
"Classification":"SecurityUpdates",
"Title":"Windows Server 2012 R2 Update (KB2919355)",
"ReleaseDate":1428426000.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2919355",
"MsrcNumber":"MS14-018",
"Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
}
}
---output truncated---
```
### 분류 `SECURITY` 및 심각도 `Critical`의 AmazonLinux2018.03에 대한 모든 패치 가져오기
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Patches": [
{
"AdvisoryIds": ["ALAS-2011-1"],
"BugzillaIds": [ "1234567" ],
"Classification": "SECURITY",
"CVEIds": [ "CVE-2011-3192"],
"Name": "zziplib",
"Epoch": "0",
"Version": "2.71",
"Release": "1.3.amzn1",
"Arch": "i686",
"Product": "AmazonLinux2018.03",
"ReleaseDate": 1590519815,
"Severity": "CRITICAL"
}
]
}
---output truncated---
```
### MSRC 심각도가 `Critical`인 Windows Server 2012에 대한 모든 패치 가져오기
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Patches":[
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 (KB2727528)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2727528",
"MsrcNumber":"MS12-072",
"Id":"1eb507be-2040-4eeb-803d-abc55700b715"
},
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Microsoft .NET Framework 3.5 on
Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2729462",
"MsrcNumber":"MS12-074",
"Id":"af873760-c97c-4088-ab7e-5219e120eab4"
}
---output truncated---
```
### 사용 가능한 모든 패치 받기
```
aws ssm describe-available-patches --region us-east-2
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues
that are included in this update, see the associated Microsoft Knowledge Base
article. After you install this update, you may have to restart your system.",
"Id": "11adea10-0701-430e-954f-9471595ae246",
"KbNumber": "KB4074588",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518548400,
"Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based
Systems (KB4074588)",
"Vendor": "Microsoft"
},
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
"Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
"KbNumber": "KB4074590",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518544805,
"Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based
Systems (KB4074590)",
"Vendor": "Microsoft"
}
---output truncated---
```
### 관리형 노드별 패치 요약 상태 받기
관리형 노드별 요약은 패치 그룹에 대해 다음 'NotApplicable', 'Missing', 'Failed', 'InstalledOther', 'Installed' 상태에 있는 패치의 수를 알려 줍니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states \
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states ^
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"InstancePatchStates":[
{
"InstanceId": "i-08ee91c0b17045407",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
"InstalledCount": 50,
"InstalledOtherCount": 353,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 0,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 671,
"OperationStartTime": "2020-01-24T12:37:56-08:00",
"OperationEndTime": "2020-01-24T12:37:59-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
},
{
"InstanceId": "i-09a618aec652973a9",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
"InstalledCount": 36,
"InstalledOtherCount": 396,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 3,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 420,
"OperationStartTime": "2020-01-24T12:37:34-08:00",
"OperationEndTime": "2020-01-24T12:37:37-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
}
---output truncated---
```
### 관리형 노드에 대한 패치 규정 준수 세부 정보 받기
```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-libs.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:24-07:00"
},
{
"Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-utils.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:32-07:00"
},
{
"Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
"KBId": "dhclient.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:31-07:00"
},
---output truncated---
```
### 패치 규정 준수 결과 보기(AWS CLI)
**단일 관리형 노드에 대한 패치 규정 준수 결과 확인**
단일 관리형 노드에 대한 패치 규정 준수 결과를 보려면 AWS Command Line Interface(AWS CLI)에서 다음 명령을 실행합니다.
```
aws ssm describe-instance-patch-states --instance-id instance-id
```
*instance-id*를 `i-02573cafcfEXAMPLE` 또는 `mi-0282f7c436EXAMPLE` 형식으로 결과를 보려는 관리형 노드의 ID로 바꿉니다.
시스템은 다음과 같은 정보를 반환합니다.
```
{
"InstancePatchStates": [
{
"InstanceId": "i-02573cafcfEXAMPLE",
"PatchGroup": "mypatchgroup",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
"CriticalNonCompliantCount": 2,
"SecurityNonCompliantCount": 2,
"OtherNonCompliantCount": 1,
"InstalledCount": 123,
"InstalledOtherCount": 334,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 1,
"FailedCount": 2,
"UnreportedNotApplicableCount": 11,
"NotApplicableCount": 2063,
"OperationStartTime": "2021-05-03T11:00:56-07:00",
"OperationEndTime": "2021-05-03T11:01:09-07:00",
"Operation": "Scan",
"LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
"RebootOption": "RebootIfNeeded"
}
]
}
```
**리전의 모든 EC2 인스턴스에 대한 패치 수 요약 확인**
`describe-instance-patch-states`는 한 번에 하나의 관리형 인스턴스에 대한 결과 검색만 지원합니다. 그러나 `describe-instance-patch-states` 명령에 사용자 정의 스크립트를 사용하면 보다 세부적인 보고서를 생성할 수 있습니다.
예를 들어 [jq 필터 도구](https://stedolan.github.io/jq/download/)가 로컬 시스템에 설치된 경우 다음 명령을 실행하여 특정 AWS 리전의 어느 EC2 인스턴스가 `InstalledPendingReboot` 상태인지 식별할 수 있습니다.
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
*리전*은 미국 동부(오하이오) 리전의 `us-east-2` 같이 AWS Systems Manager이 지원하는 AWS 리전의 식별자를 나타냅니다. 지원되는 *리전* 값 목록은 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 있는 **리전** 열을 참조하세요.
예제:
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
시스템은 다음과 같은 정보를 반환합니다.
```
1 i-02573cafcfEXAMPLE
0 i-0471e04240EXAMPLE
3 i-07782c72faEXAMPLE
6 i-083b678d37EXAMPLE
0 i-03a530a2d4EXAMPLE
1 i-01f68df0d0EXAMPLE
0 i-0a39c0f214EXAMPLE
7 i-0903a5101eEXAMPLE
7 i-03823c2fedEXAMPLE
```
`InstalledPendingRebootCount` 외에도 검색할 수 있는 카운트 유형 목록은 다음과 같습니다.
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`
## 관리형 노드 스캔 및 패치를 위한 AWS CLI 명령
다음 명령을 실행하여 패치 규정 준수 여부를 검사하거나 패치를 설치한 후 [패치 요약 및 세부 정보 보기를 위한 AWS CLI 명령](#patch-details-cli-commands) 섹션의 명령을 사용하여 패치 상태 및 규정 준수에 대한 정보를 볼 수 있습니다.
**Topics**
+ [패치 규정 준수를 위해 관리형 노드 스캔(AWS CLI)](#patch-operations-scan)
+ [관리형 노드에 패치 설치(AWS CLI)](#patch-operations-install-cli)
### 패치 규정 준수를 위해 관리형 노드 스캔(AWS CLI)
**패치 규정 준수를 위해 특정 관리형 노드 스캔**
다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Command": {
"CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974475.267,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621952275.267,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**패치 그룹 태그로 관리형 노드에서 패치 규정 준수 여부 스캔**
다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Command": {
"CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974983.128,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621952783.128,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
### 관리형 노드에 패치 설치(AWS CLI)
**특정 관리형 노드에 패치 설치**
다음 명령을 실행합니다.
**참고**
패치 설치를 완료하기 위해 필요에 따라 대상 관리형 노드가 재부팅됩니다. 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Command": {
"CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975301.791,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621953101.791,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**특정 패치 그룹의 관리형 노드에 패치 설치**
다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
-parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Command": {
"CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975407.865,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621953207.865,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
# AWS Systems Manager Patch Manager 자습서
이 섹션의 자습서에서는 여러 패치 적용 시나리오에 AWS Systems Manager의 도구인 Patch Manager를 사용하는 방법을 보여줍니다.
**Topics**
+ [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md)
+ [자습서: 콘솔을 사용한 Windows 서비스 팩 설치를 위한 패치 기준 생성](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [자습서: 콘솔을 사용한 애플리케이션 종속성 업데이트, 관리형 노드 패치, 애플리케이션별 상태 확인 수행](aws-runpatchbaselinewithhooks-tutorial.md)
+ [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md)
# 자습서: IPv6 전용 환경에서 서버 패치 적용
Patch Manager는 IPv6만 있는 환경에서 노드의 패치 적용을 지원합니다. SSM Agent 구성을 업데이트하면 IPv6 서비스 엔드포인트만 직접적으로 호출하도록 패치 작업을 구성할 수 있습니다.
**IPv6 전용 환경에서 서버를 패치하려면**
1. SSM Agent 3.3270.0 이상이 관리형 노드에 설치되어 있는지 확인합니다.
1. 관리형 노드에서 SSM Agent 구성 파일로 이동합니다. 다음 디렉터리에서 `amazon-ssm-agent.json` 파일을 찾을 수 있습니다.
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
`amazon-ssm-agent.json`이 아직 존재하지 않는 경우 동일한 디렉터리에 있는 `amazon-ssm-agent.json.template`의 콘텐츠를 `amazon-ssm-agent.json`에 복사합니다.
1. 다음 항목을 업데이트하여 올바른 리전을 설정하고 `UseDualStackEndpoint`를 `true`로 설정합니다.
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. 운영 체제에 맞는 명령을 사용하여 SSM Agent 서비스를 다시 시작합니다.
+ Linux: `sudo systemctl restart amazon-ssm-agent`
+ Snap 사용 시 Ubuntu Server: `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` 다음에 `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` 다음에 `Start-Service AmazonSSMAgent`
운영 체제별 전체 명령 목록은 [SSM Agent 상태 확인 및 에이전트 시작](ssm-agent-status-and-restart.md) 섹션을 참조하세요.
1. 패치 작업을 실행하여 IPv6 전용 환경에서 패치 작업이 성공했는지 확인합니다. 패치되는 노드가 패치 소스에 연결되어 있는지 확인합니다. 패치 실행의 Run Command 출력을 확인하여 액세스할 수 없는 리포지토리에 대한 경고를 확인할 수 있습니다. IPv6 전용 환경에서 실행 중인 노드에 패치를 적용할 때는 노드가 패치 소스에 연결되어 있는지 확인합니다. 패치 실행의 Run Command 출력을 확인하여 액세스할 수 없는 리포지토리에 대한 경고를 확인할 수 있습니다. DNF 기반 운영 체제의 경우 `/etc/dnf/dnf.conf`에서 `skip_if_unavailable` 옵션이 `True`로 설정되면 패치 적용 중에 사용할 수 없는 리포지토리를 건너뛰도록 구성할 수 있습니다. DNF 기반 운영 체제에는 Amazon Linux 2023, Red Hat Enterprise Linux 8 이상 버전, Oracle Linux 8 이상 버전, Rocky Linux, AlmaLinux 및 CentOS 8 이상 버전이 포함됩니다. Amazon Linux 2023에서는 `skip_if_unavailable` 옵션이 기본적으로 `True`로 설정됩니다.
**참고**
설치 재정의 목록 또는 기준 재정의 기능을 사용하는 경우 제공된 URL에 노드에서 연결할 수 있는지 확인합니다. SSM Agent 구성 옵션 `UseDualStackEndpoint`가 `true`로 설정된 경우 S3 URL이 제공될 때 듀얼 스택 S3 클라이언트가 사용됩니다.
# 자습서: 콘솔을 사용한 Windows 서비스 팩 설치를 위한 패치 기준 생성
사용자 정의 패치 기준을 만들 때 지원되는 모든 패치 또는 일부 또는 한 가지 유형의 패치만 설치하도록 지정할 수 있습니다.
Windows의 패치 기준에서 패치 업데이트를 서비스 팩으로만 제한하기 위해 `ServicePacks`를 유일한 **분류** 옵션으로만 선택할 수 있습니다. Windows Update 또는 WSUS(Windows Server Update Services)에서 업데이트를 사용할 수 있는 경우 AWS Systems Manager의 도구인 Patch Manager로 서비스 팩을 자동 설치할 수 있습니다.
모든 Windows 버전에 대한 서비스 팩의 설치 여부를 제어하거나 Windows 7 또는 Windows Server 2016과 같은 특정 버전에 대한 서비스 팩만 설치할지 여부를 제어하도록 패치 기준을 구성할 수 있습니다.
Windows 관리형 노드에 모든 서비스 팩을 설치하는 데만 사용할 사용자 정의 패치 기준을 만들려면 다음 절차를 따르세요.
**Windows 서비스 팩 설치를 위한 패치 기준선을 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준선** 탭을 선택한 다음 **패치 기준선 생성**을 선택합니다.
1. **Name(이름)** 필드에 새로운 패치 기준 이름(예: `MyWindowsServicePackPatchBaseline`)을 입력합니다.
1. (선택 사항) **설명**에 이 패치 기준에 대한 설명을 입력합니다.
1. **운영 체제**에서 `Windows`를 선택합니다.
1. 이 패치 기준을 생성하는 즉시 Windows의 기본값으로 사용하려면 **Set this patch baseline as the default patch baseline for Windows Server instances(이 패치 기준을 Windows Server 인스턴스의 기본 패치 기준으로 설정)**를 선택하십시오.
**참고**
이 옵션은 2022년 12월 22일에 [패치 정책](patch-manager-policies.md)이 릴리스되기 전에 Patch Manager에 처음 액세스한 경우에만 사용할 수 있습니다.
기존 패치 기준을 기본값으로 설정하는 방법에 대한 자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **Approval rules for operating systems(운영 체제에 대한 승인 규칙)** 섹션에서 필드를 사용하여 자동 승인 규칙을 한 개 이상 생성합니다.
+ **제품**: 승인 규칙이 적용되는 운영 체제 버전입니다(예: `WindowsServer2012`). 지원되는 Windows 버전을 하나 또는 둘 이상 또는 모두 선택할 수 있습니다. 기본 선택은 `All`입니다.
+ **Classification(분류)**: `ServicePacks`를 선택합니다.
+ **Severity(심각도)**: 규칙이 적용될 패치의 심각도 값입니다. 모든 서비스 팩이 규칙에 포함되도록 하려면 `All`을 선택합니다.
+ **Auto-approval**: 자동 승인을 위해 패치를 선택하는 방법입니다.
+ **Approve patches after a specified number of days**(지정된 일 수 후 패치 승인): 패치가 릴리스 또는 업데이트된 후 자동으로 승인되기까지 Patch Manager가 대기하는 일 수입니다. 0\$1360의 정수를 입력할 수 있습니다. 대부분의 시나리오에서 100일 이상 기다리지 않는 것이 좋습니다.
+ **Approve patches released up to a specific date**(특정 날짜까지 릴리스된 패치 승인): Patch Manager가 해당 날짜 또는 그 이전에 릴리스 또는 업데이트된 모든 패치를 자동으로 적용하는 패치 릴리스 날짜입니다. 예를 들어 2023년 7월 7일을 지정하면 2023년 7월 8일 또는 그 이후에 릴리스되거나 마지막으로 업데이트된 패치가 자동으로 설치되지 않습니다.
+ (선택 사항) **Compliance reporting(규정 준수 보고)**: 기준에서 승인된 서비스 팩에 할당할 심각도 수준입니다(예: `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 서비스 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
1. (선택 사항) **Manage tags(태그 관리)**의 경우, 하나 이상의 태그 키 이름/값 페어를 패치 기준에 적용합니다.
태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 서비스 팩 업데이트 전용인 이 패치 기준의 경우 다음과 같은 키-값 쌍을 지정할 수 있습니다.
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. **패치 기준 생성**을 선택합니다.
# 자습서: 콘솔을 사용한 애플리케이션 종속성 업데이트, 관리형 노드 패치, 애플리케이션별 상태 확인 수행
대부분의 경우 관리형 노드는 최신 소프트웨어 업데이트로 패치된 후 재부팅해야 합니다. 그러나 안전 장치 없이 프로덕션 환경에서 노드를 재부팅하면 경보 호출, 잘못된 지표 데이터 기록, 데이터 동기화 중단과 같은 여러 문제가 발생할 수 있습니다.
이 자습서에서는 AWS Systems Manager 문서(SSM 문서) `AWS-RunPatchBaselineWithHooks`를 사용하여 다음을 수행하는 복잡한 다단계 패치 작업을 수행하여 이러한 문제를 피하는 방법을 보여줍니다.
1. 애플리케이션에 새로 연결 방지
1. 운영 체제 업데이트 설치
1. 애플리케이션의 패키지 종속성 업데이트
1. 시스템 다시 시작
1. 애플리케이션별 상태 확인 수행
이 예에서는 인프라를 다음과 같이 설정했습니다.
+ 대상 가상 머신은 Systems Manager에 관리형 노드로 등록됩니다.
+ `Iptables`는 로컬 방화벽으로 사용됩니다.
+ 관리형 노드에서 호스팅되는 애플리케이션이 포트 443에서 실행되고 있습니다.
+ 관리형 노드에서 호스팅되는 애플리케이션이 `nodeJS` 애플리케이션입니다.
+ 관리형 노드에서 호스팅되는 애플리케이션이 pm2 프로세스 관리자에 의해 관리됩니다.
+ 애플리케이션에 이미 지정된 상태 확인 엔드포인트가 있습니다.
+ 애플리케이션의 상태 확인 엔드포인트에 최종 사용자 인증이 필요하지 않습니다. 엔드포인트를 사용하면 조직의 가용성 설정 요구 사항을 충족하는 상태 확인을 수행할 수 있습니다. (사용자 환경에서는 `nodeJS` 애플리케이션이 실행 중이고 요청을 수신할 수 있는지 확인하는 것으로 충분할 수 있습니다. 다른 경우에는 캐싱 계층 또는 데이터베이스 계층에 대한 연결이 이미 설정되었는지도 확인해야 할 수 있습니다.)
이 자습서의 예제는 데모용으로만 제공되며 프로덕션 환경에 있는 그대로 구현되지 않습니다. 또한 `AWS-RunPatchBaselineWithHooks` 문서와 함께 Systems Manager의 도구인 Patch Manager의 수명 주기 후크 기능은 다양한 다른 시나리오를 지원할 수 있습니다. 다음은 몇 가지 예제입니다.
+ 지표 보고 에이전트를 패치 전에 중지하고 관리형 노드 재부팅 후 다시 시작합니다.
+ 관리형 노드를 패치 전에 CRM 또는 PCS 클러스터에서 분리하고 재부팅한 후 다시 연결합니다.
+ 운영 체제(OS) 업데이트가 적용된 후 관리형 노드가 재부팅되기 전에 Windows Server 시스템에서 서드 파티 소프트웨어(예: Java, Tomcat, Adobe 애플리케이션 등)를 업데이트합니다.
**애플리케이션 종속성 업데이트, 관리형 노드 패치 및 애플리케이션별 상태 확인 수행**
1. 다음 내용으로 사전 설치 스크립트에 대한 SSM 문서를 생성하고 이름을 `NodeJSAppPrePatch`로 지정합니다. *your\$1application*을 애플리케이션 이름으로 바꿉니다.
이 스크립트는 새로운 수신 요청을 즉시 차단하고 패치 작업을 시작하기 전에 이미 활성화된 요청이 완료될 때까지 5초간 기다립니다. `sleep` 옵션에 대해 수신 요청을 완료하는 데 일반적으로 걸리는 시간보다 긴 시간(초)을 지정합니다.
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
SSM 문서 생성에 대한 자세한 내용은 [SSM 문서 콘텐츠 생성](documents-creating-content.md) 섹션을 참조하세요.
1. 설치 후 스크립트에 대해 다음 내용으로 다른 SSM 문서를 생성하여 애플리케이션 종속성을 업데이트하고 이름을 `NodeJSAppPostPatch`로 지정합니다. */your/application/path*를 애플리케이션의 경로로 바꿉니다.
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. `onExit` 스크립트에 대한 다음 내용으로 다른 SSM 문서를 생성하여 애플리케이션을 다시 불러오고 상태 확인을 수행합니다. 이 SSM 문서의 이름을 `NodeJSAppOnExitPatch`로 지정합니다. *your\$1application*을 애플리케이션 이름으로 바꿉니다.
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. 다음 단계에 따라 AWS Systems Manager의 도구인 State Manager에 연결을 생성하여 작업을 실행합니다.
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택한 후 **연결 생성**을 선택합니다.
1. [**이름(Name)**]에 연결의 목적을 식별하는 데 도움이 되는 이름을 입력합니다.
1. [**문서(Document)**] 목록에서 `AWS-RunPatchBaselineWithHooks`를 선택합니다.
1. [**작업(Operation)**]에서 [**설치(Install)**]를 선택합니다.
1. (옵션) [**스냅샷 ID(Snapshot Id)**]에 작업 속도를 높이고 일관성을 보장하기 위해 생성하는 GUID를 제공합니다. `00000000-0000-0000-0000-111122223333`과 같이 단순한 GUID 값을 사용할 수 있습니다.
1. [**설치 전 후크 문서 이름(Pre Install Hook Doc Name)**]에 `NodeJSAppPrePatch`를 입력합니다.
1. [**설치 후 후크 문서 이름(Post Install Hook Doc Name)**]에 `NodeJSAppPostPatch`를 입력합니다.
1. [**종료 시 후크 문서 이름(On ExitHook Doc Name)**]에 `NodeJSAppOnExitPatch`를 입력합니다.
1. **대상(Targets)**에서, 태그를 지정하거나, 노드를 수동으로 선택하거나, 리소스 그룹을 선택하거나, 모든 관리형 노드를 선택하여 관리형 노드를 식별할 수 있습니다.
1. [**일정 지정(Specify schedule)**]에서 연결을 실행할 빈도를 지정합니다. 예를 들어 관리형 노드 패치의 경우 일주일에 한 번이 일반적입니다.
1. **속도 제어(Rate control)** 섹션에서 여러 관리형 노드에서 연결을 실행하는 방법을 제어하는 옵션을 선택합니다. 한 번에 관리형 노드의 일부만 업데이트되는지 확인합니다. 그렇지 않으면 전체 또는 대부분의 플릿이 한 번에 오프라인 상태가 될 수 있습니다. 속도 제어 사용에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
1. (선택 사항) **출력 옵션**에서 명령 출력을 파일에 저장하려면 **S3 버킷에 쓰기 활성화** 옆의 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아닌 관리형 노드에 할당된 인스턴스 프로파일의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **연결 생성**을 선택합니다.
# 자습서: AWS CLI를 사용한 서버 환경에 패치 적용
다음 절차는 사용자 지정 패치 기준, 패치 그룹 및 유지 관리 기간을 사용하여 서버 환경에 패치를 적용하는 방법에 대해 설명합니다.
**시작하기 전 준비 사항**
+ 관리형 노드에서 SSM Agent 설치 또는 업데이트 Linux 관리형 노드에 패치를 실행하려면 노드가 SSM Agent 버전 2.0.834.0 이상을 실행 중이어야 합니다. 자세한 내용은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 섹션을 참조하세요.
+ AWS Systems Manager의 도구인 Maintenance Windows에 대한 역할 및 권한을 구성합니다. 자세한 내용은 [Maintenance Windows 설정](setting-up-maintenance-windows.md) 섹션을 참조하세요.
+ 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**Patch Manager 및 패치 관리형 노드 구성(명령줄)**
1. 다음 명령을 실행하여 이름이 `Production-Baseline`인 Windows 패치 기준을 생성합니다. 이 패치 기준선은 프로덕션 환경의 패치가 릴리스되거나 마지막으로 업데이트되고 7일 후에 승인합니다. 패치 기준에는 프로덕션 환경용임을 나타내는 태그가 지정되어 있습니다.
**참고**
`OperatingSystem` 파라미터 및 `PatchFilters`는 패치 기준이 적용되는 대상 관리형 노드의 운영 체제에 따라 달라집니다. 자세한 내용은 [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) 및 [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)를 참조하십시오.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 다음 명령을 실행하여 두 패치 그룹에 대해 "Production-Baseline" 패치 기준을 등록합니다. 그룹의 이름은 "Database Servers" 및 "Front-End Servers"로 지정됩니다.
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 다음 명령을 실행하여 프로덕션 서버에 대한 두 개의 유지 관리 기간을 생성합니다. 첫 번째 기간은 매주 화요일 오후 10시에 실행합니다. 두 번째 Window는 매주 토요일 오후 10시에 실행합니다. 또한 유지 관리 기간에는 프로덕션 환경용임을 나타내는 태그가 지정되어 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. 다음 명령을 실행하여 `Database` 및 `Front-End` 서버 패치 그룹을 해당 유지 관리 기간에 등록합니다.
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. 다음 명령을 실행하여 각 유지 관리 기간 동안 `Database` 및 `Front-End` 서버에 누락된 업데이트를 설치하는 패치 작업을 등록합니다.
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. 다음 명령을 실행하여 패치 그룹에 대한 높은 수준의 패치 규정 준수 요약을 확인합니다. 상위 수준의 패치 규정 준수 요약에는 각 패치 상태의 패치가 있는 관리형 노드 수가 포함됩니다.
**참고**
첫 번째 유지 관리 기간 동안 패치 태스크가 실행될 때까지 요약에는 관리형 노드 수가 0으로 표시됩니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. 다음 명령을 실행하여 패치 그룹에 대한 관리형 노드별 패치 요약 상태를 확인합니다. 관리형 노드별 요약에는 패치 그룹에 대한 관리형 노드당 각 패치 상태의 여러 패치가 포함됩니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
Patch Manager 구성 태스크에 사용할 수 있는 다른 AWS CLI 명령의 예를 보려면 [AWS CLI를 사용하여 Patch Manager 리소스 작업](patch-manager-cli-commands.md) 섹션을 참조하세요.
# Patch Manager 문제 해결
다음 정보를 사용하면 AWS Systems Manager의 도구인 Patch Manager 관련 문제를 해결하는 데 도움이 됩니다.
**Topics**
+ [문제: `baseline_overrides.json`에 대한 "Invoke-PatchBaselineOperation: 액세스 거부됨" 오류 또는 "S3에서 파일을 다운로드할 수 없음" 오류](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [문제: 명백한 원인 또는 오류 메시지 없이 패치 적용 실패](#race-condition-conflict)
+ [문제: 예기치 않은 패치 규정 준수 결과](#patch-manager-troubleshooting-compliance)
+ [Linux에서 `AWS-RunPatchBaseline` 실행 시 오류](#patch-manager-troubleshooting-linux)
+ [Windows Server에서 `AWS-RunPatchBaseline` 실행 시 오류](#patch-manager-troubleshooting-windows)
+ [macOS에서 `AWS-RunPatchBaseline` 실행 시 오류](#patch-manager-troubleshooting-macos)
+ [AWS Support Automation 런북 사용](#patch-manager-troubleshooting-using-support-runbooks)
+ [AWS Support 문의](#patch-manager-troubleshooting-contact-support)
## 문제: `baseline_overrides.json`에 대한 "Invoke-PatchBaselineOperation: 액세스 거부됨" 오류 또는 "S3에서 파일을 다운로드할 수 없음" 오류
**문제**: 패치 정책에 따라 지정된 패치 적용 작업을 실행하면 다음 예제와 비슷한 오류가 표시됩니다.
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**원인**: Quick Setup에서 패치 정책을 생성했으며, 연결된 인스턴스 프로파일(EC2 인스턴스의 경우) 또는 연결된 서비스 역할(비 EC2 시스템의 경우)이 이미 일부 관리형 노드에 있었습니다.
그러나 다음 이미지와 같이 **인스턴스에 연결된 기존 인스턴스 프로파일에 필수 IAM 정책 추가** 확인란을 선택하지 않았습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
패치 정책을 생성하면 정책의 구성 `baseline_overrides.json` 파일을 저장하는 Amazon S3 버킷도 생성됩니다. 정책을 생성할 때 **인스턴스에 연결된 기존 인스턴스 프로파일에 필수 IAM 정책 추가** 확인란을 선택하지 않으면 S3 버킷의 `baseline_overrides.json`에 액세스하는 데 필요한 IAM 정책 및 리소스 태그가 기존 IAM 인스턴스 프로파일 및 서비스 역할에 자동으로 추가되지 않습니다.
**솔루션 1**: 기존 패치 정책 구성을 삭제한 다음에 대체 패치 정책 구성을 생성하고, **인스턴스에 연결된 기존 인스턴스 프로파일에 필수 IAM 정책 추가** 확인란을 반드시 선택합니다. 이렇게 선택하면 연결된 인스턴스 프로파일 또는 서비스 역할이 이미 있는 노드에 이 Quick Setup 구성을 통해 생성된 IAM 정책이 적용됩니다. (기본적으로 Quick Setup에서는 인스턴스 프로파일 또는 서비스 역할이 아직 **없는 인스턴스와 노드에 필수 정책을 추가합니다.) 자세한 내용은 [Quick Setup 패치 정책을 사용하여 조직 전반의 패치 적용 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)를 참조하세요.
**솔루션 2**: Quick Setup에서 사용하는 각 IAM 인스턴스 프로파일 및 IAM 서비스 역할에 필수 권한과 태그를 수동으로 추가합니다. 지침은 [패치 정책 S3 버킷에 대한 권한](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions) 섹션을 참조하세요.
## 문제: 명백한 원인 또는 오류 메시지 없이 패치 적용 실패
**문제**: 오류 메시지가 반환되지 않고 패치 적용 작업이 실패합니다.
**가능한 원인**: 관리형 노드에 패치를 적용할 때 패치가 성공적으로 설치되었더라도 문서 실행이 중단되고 실패로 표시될 수 있습니다. 이는 패치 작업 중에 시스템이 예기치 않은 재부팅을 시작하는 경우(예: 펌웨어 또는 SecureBoot와 같은 기능에 업데이트를 적용하기 위해) 발생할 수 있습니다. SSM 에이전트는 외부 재부팅에서 문서 실행 상태를 유지하고 재개할 수 없으므로 실행이 실패한 것으로 보고됩니다.
**솔루션**: 실행 실패 후 패치 설치 상태를 확인하려면 `Scan` 패치 작업을 실행한 다음 패치 관리자의 패치 규정 준수 데이터를 확인하여 현재 규정 준수 상태를 평가합니다.
이 시나리오에서 외부 재부팅이 실패의 원인이 아니었다고 판단되면 [AWS Support](#patch-manager-troubleshooting-contact-support)에 문의하는 것이 좋습니다.
## 문제: 예기치 않은 패치 규정 준수 결과
**문제**: `Scan` 작업 후에 생성된 패치 규정 준수 세부 정보를 검토할 때, 결과에 패치 기준선에 설정된 규칙에 부합하지 않는 정보가 포함되어 있습니다. 패치 기준선의 **Rejected patches**(거부된 패치) 목록에 추가한 예외가 `Missing`으로 표시되는 경우를 예로 들 수 있습니다. 또는 패치 기준선에서 `Critical` 패치만 지정했는데도 `Important`로 분류된 패치가 누락된 것으로 표시됩니다.
**원인**: Patch Manager는 현재 다양한 `Scan` 작업 실행 방법을 지원합니다.
+ Quick Setup에서 구성된 패치 정책
+ Quick Setup에서 구성된 호스트 관리 옵션
+ 패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
+ 온디맨드 **Patch now**(지금 패치) 작업
`Scan` 작업이 실행되면 가장 최근 검사의 규정 준수 세부 정보를 덮어씁니다. `Scan` 작업을 실행하도록 설정된 방법이 2가지 이상이고, 해당 방법에서 서로 다른 규칙의 서로 다른 패치 기준선을 사용하는 경우 패치 규정 준수 결과가 달라집니다.
**해결 방법**: 예기치 않은 패치 규정 준수 결과를 방지하려면 Patch Manager `Scan` 작업을 실행할 때 한 번에 한 가지 방법만 사용하는 것이 좋습니다. 자세한 내용은 [패치 규정 준수 데이터를 생성한 실행 식별](patch-manager-compliance-data-overwrites.md) 섹션을 참조하세요.
## Linux에서 `AWS-RunPatchBaseline` 실행 시 오류
**Topics**
+ [문제: '해당 파일 또는 디렉터리가 없음(No such file or directory)' 오류](#patch-manager-troubleshooting-linux-1)
+ [문제: '다른 프로세스가 yum 잠금을 획득함(another process has acquired yum lock)' 오류](#patch-manager-troubleshooting-linux-2)
+ [문제: '권한 거부됨/명령 실행 실패(Permission denied / failed to run commands)'오류](#patch-manager-troubleshooting-linux-3)
+ [문제: '페이로드를 다운로드할 수 없음(Unable to download payload)' 오류](#patch-manager-troubleshooting-linux-4)
+ [문제: '지원되지 않는 패키지 관리자 및 python 버전 조합(unsupported package manager and python version combination)' 오류](#patch-manager-troubleshooting-linux-5)
+ [문제: Patch Manager가 특정 패키지를 제외하도록 지정된 규칙을 적용하지 않음](#patch-manager-troubleshooting-linux-6)
+ [문제: 패치가 실패하고 Patch Manager가 TLS에 대한 서버 이름 표시 확장을 사용할 수 없다고 보고함](#patch-manager-troubleshooting-linux-7)
+ [문제: Patch Manager가 '시도할 미러가 더 이상 없음(No more mirrors to try)' 보고](#patch-manager-troubleshooting-linux-8)
+ [문제: 'curl에서 반환된 오류 코드는 23'이라는 메시지와 함께 패치 적용 실패](#patch-manager-troubleshooting-linux-9)
+ [문제: 'rpm 패키지 압축 해제 오류…’라는 메시지와 함께 패치 적용 실패](#error-unpacking-rpm)
+ [문제: 'Encounter service side error when uploading the inventory' 오류 메시지와 함께 패치 적용 실패](#inventory-upload-error)
+ [문제: '패키지를 다운로드하는 동안 오류가 발생했습니다'라는 메시지와 함께 패치 적용 실패](#errors-while-downloading)
+ [문제: 메모리 부족(OOM) 오류와 함께 패치 적용 실패](#patch-manager-troubleshooting-linux-oom)
+ [문제: '퍼블릭 키를 사용할 수 없어 다음 서명을 확인할 수 없습니다'라는 메시지와 함께 패치 적용 실패](#public-key-unavailable)
+ [문제: 'NoMoreMirrorsRepoError' 메시지와 함께 패치 적용 실패](#no-more-mirrors-repo-error)
+ [문제: '페이로드를 다운로드할 수 없음' 메시지와 함께 패치 적용 실패](#payload-download-error)
+ [문제: '설치 오류: dpkg: 오류: dpkg 프런트엔드가 다른 프로세스에 의해 잠겼습니다'라는 메시지와 함께 패치 적용 실패](#dpkg-frontend-locked)
+ [문제: 'dpkg가 중단되었습니다' 오류로 Ubuntu Server의 패치 적용 실패](#dpkg-interrupted)
+ [문제: 패키지 관리자 유틸리티를 통해 패키지 종속성을 해결할 수 없음](#unresolved-dependency)
+ [문제: SLES 관리형 노드에서 Zypper 패키지 잠금 종속성 실패](#patch-manager-troubleshooting-linux-zypper-locks)
+ [문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.](#patch-manager-troubleshooting-linux-concurrent-lock)
### 문제: '해당 파일 또는 디렉터리가 없음(No such file or directory)' 오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류 중 하나와 함께 패치가 실패합니다.
```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```
```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```
```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```
**원인 1**: `AWS-RunPatchBaseline`을 실행하는 2개의 명령이 동일한 관리형 노드에서 동시에 실행되었습니다. 이로 인해 임시 `file patch-baseline-operations*`가 제대로 생성 또는 액세스되지 않는 경쟁 조건이 발생합니다.
**원인 2**: `/var` 디렉터리의 저장 공간이 부족합니다.
**해결 방법 1**: 유지 관리 기간에 동일한 우선순위 수준으로 `AWS-RunPatchBaseline`을 실행하고 동일한 대상 ID에서 실행되는 둘 이상의 Run Command 태스크가 없는지 확인합니다. 이 경우 우선순위를 다시 지정합니다. Run Command는 AWS Systems Manager의 도구입니다.
**해결 방법 2**: 한 번에 하나의 유지 관리 기간만 동일한 대상 및 동일한 일정에서 `AWS-RunPatchBaseline`을 사용하는 Run Command 태스크를 실행하고 있는지 확인합니다. 이 경우 일정을 변경합니다.
**해결 방법 3**: 하나의 State Manager 연결만 동일한 일정으로 `AWS-RunPatchBaseline`을 실행하고 동일한 관리형 노드를 대상으로 하는지 확인합니다. State Manager는 AWS Systems Manager의 도구입니다.
**해결 방법 4**: 업데이트 패키지를 위해 `/var` 디렉터리에 충분한 저장 공간을 확보합니다.
### 문제: '다른 프로세스가 yum 잠금을 획득함(another process has acquired yum lock)' 오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류와 함께 패치가 실패합니다.
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**원인**: `AWS-RunPatchBaseline` 문서가 이미 다른 작업에서 실행 중이고 패키지 관리자 `yum` 프로세스를 획득한 관리형 노드에서 실행을 시작했습니다.
**해결 방법**: 일정에 따라 `AWS-RunPatchBaseline`을 실행하는 State Manager 연결, 유지 관리 기간 태스크 또는 기타 구성이 거의 같은 시간에 동일한 관리형 노드를 대상으로 하지 않도록 합니다.
### 문제: '권한 거부됨/명령 실행 실패(Permission denied / failed to run commands)'오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류와 함께 패치가 실패합니다.
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**원인**: `/var/lib/amazon/`이 `noexec` 권한으로 탑재되었을 수 있습니다. 이것은 SSM Agent가 `/var/lib/amazon/ssm`에 페이로드 스크립트를 다운로드하고 해당 위치에서 실행하기 때문에 문제입니다.
**해결 방법**: `/var/log/amazon` 및 `/var/lib/amazon`에 대한 배타적 파티션을 구성하고 `exec` 권한으로 탑재했는지 확인합니다.
### 문제: '페이로드를 다운로드할 수 없음(Unable to download payload)' 오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류와 함께 패치가 실패합니다.
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**원인**: 지정된 Amazon Simple Storage Service(Amazon S3) 버킷에 액세스하는 데 필요한 권한이 관리형 노드에 없습니다.
**해결 방법**: S3 엔드포인트에 연결할 수 있도록 네트워크 구성을 업데이트합니다. 자세한 내용은 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)의 Patch Manager에 대한 S3 버킷에 대한 필수 액세스에 대한 정보를 참조하세요.
### 문제: '지원되지 않는 패키지 관리자 및 python 버전 조합(unsupported package manager and python version combination)' 오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류와 함께 패치가 실패합니다.
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**원인**: Debian Server 또는 Ubuntu Server 인스턴스에 지원되는 python3 버전이 설치되어 있지 않습니다.
**솔루션**: Debian Server 및 Ubuntu Server 관리형 노드에 필요한 지원되는 python3 버전(3.0\$13.12)을 서버에 설치합니다.
### 문제: Patch Manager가 특정 패키지를 제외하도록 지정된 규칙을 적용하지 않음
**문제**: `/etc/yum.conf` 파일에 `exclude=package-name` 형식으로 지정하여 특정 패키지를 제외하려고 했지만 Patch Manager `Install` 작업 중에 제외되지 않았습니다.
**원인**: Patch Manager는 `/etc/yum.conf` 파일에 지정된 제외를 포함하지 않습니다.
**해결 방법**: 특정 패키지를 제외하려면 사용자 정의 패치 기준을 생성하고 설치하지 않으려는 패키지를 제외하는 규칙을 생성합니다.
### 문제: 패치가 실패하고 Patch Manager가 TLS에 대한 서버 이름 표시 확장을 사용할 수 없다고 보고함
**문제**: 패치 작업이 다음 메시지를 표시합니다.
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**원인**: 이 메시지는 오류를 나타내지 않습니다. 대신 운영 체제와 함께 배포된 이전 버전의 Python이 TLS 서버 이름 표시를 지원하지 않는다는 경고입니다. Systems Manager 패치 페이로드 스크립트는 SNI를 지원하는 AWS API에 연결할 때 이 경고를 표시합니다.
**해결 방법**: 이 메시지가 보고될 때 패치 실패 문제를 해결하려면 `stdout` 및 `stderr` 파일의 내용을 검토합니다. 이러한 파일을 S3 버킷 또는 Amazon CloudWatch Logs 저장하도록 패치 기준선을 구성하지 않은 경우 Linux 관리형 노드의 다음 위치에서 파일을 찾을 수 있습니다.
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### 문제: Patch Manager가 '시도할 미러가 더 이상 없음(No more mirrors to try)' 보고
**문제**: 패치 작업이 다음 메시지를 표시합니다.
```
[Errno 256] No more mirrors to try.
```
**원인**: 관리형 노드에 구성된 리포지토리가 제대로 작동하지 않습니다. 이에 대한 가능한 원인은 다음과 같습니다.
+ `yum` 캐시가 손상되었습니다.
+ 네트워크 관련 문제로 인해 리포지토리 URL에 연결할 수 없습니다.
**해결 방법**: Patch Manager는 관리형 노드의 기본 패키지 관리자를 사용하여 패치 작업을 수행합니다. 리포지토리가 제대로 구성되고 작동하는지 다시 확인합니다.
### 문제: 'curl에서 반환된 오류 코드는 23'이라는 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류로 `AWS-RunPatchBaseline`을 사용하는 패치 적용 작업이 실패합니다.
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**원인**: 파일 시스템에 쓰는 데 필요한 권한이 시스템에서 사용 중인 curl 도구에 없습니다. 이는 패키지 관리자의 기본 curl 도구가 다른 버전(예: snap으로 설치된 도구)으로 대체된 경우에 발생할 수 있습니다.
**솔루션**: 다른 버전이 설치되었을 때 패키지 관리자가 제공한 curl 버전이 제거되었다면 다시 설치합니다.
여러 curl 버전을 설치된 상태로 유지해야 하는 경우 패키지 관리자와 연결된 버전이 `PATH` 변수에 나열된 첫 번째 디렉터리에 있는지 확인합니다. `echo $PATH` 명령을 실행하여 시스템에서 실행 파일을 검사한 디렉터리의 현재 순서를 참조하면 이를 확인할 수 있습니다.
### 문제: 'rpm 패키지 압축 해제 오류…’라는 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류로 패치 적용 작업이 실패합니다.
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**원인 1**: 특정 패키지가 여러 패키지 설치 관리자에 있으면(예: `pip` 및 `yum` 둘 다 또는 `dnf`) 기본 패키지 관리자를 사용할 때 충돌이 발생할 수 있습니다.
`pip`, `yum` 및 `dnf`에서 찾을 수 있는 일반적인 예가 `urllib3` 패키지에서 발생합니다.
**원인 2**: `python-urllib3` 패키지가 손상되었습니다. `rpm`이 이전에 `yum` 또는 `dnf`를 통해 설치된 패키지였던 이후에 `pip`을 통해 패키지 파일이 설치되거나 업데이트되었으면 이 문제가 발생할 수 있습니다.
**솔루션**: 기본 패키지 관리자(`yum` 또는 `dnf`)에서만 패키지가 유지되도록 `sudo pip uninstall urllib3` 명령을 실행하여 pip에서 `python-urllib3` 패키지를 제거합니다.
### 문제: 'Encounter service side error when uploading the inventory' 오류 메시지와 함께 패치 적용 실패
**문제**: `AWS-RunPatchBaseline` 문서를 실행할 때 다음 오류 메시지가 표시됩니다.
```
Encounter service side error when uploading the inventory
```
**원인**: `AWS-RunPatchBaseline`을 실행하는 2개의 명령이 동일한 관리형 노드에서 동시에 실행되었습니다. 이로 인해 패치 적용 작업 중에 boto3 클라이언트를 초기화할 때 경합 조건이 생성됩니다.
**해결 방법**: 일정에 따라 `AWS-RunPatchBaseline`을 실행하는 State Manager 연결, 유지 관리 기간 태스크 또는 기타 구성이 거의 같은 시간에 동일한 관리형 노드를 대상으로 하지 않도록 합니다.
### 문제: '패키지를 다운로드하는 동안 오류가 발생했습니다'라는 메시지와 함께 패치 적용 실패
**문제**: 패치를 적용하는 동안 다음과 비슷한 오류가 표시됩니다.
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**원인**: 이 오류는 관리형 노드에 사용할 수 있는 메모리가 부족할 때 발생할 수 있습니다.
**솔루션**: 스왑 메모리를 구성하거나 인스턴스를 다른 유형으로 업그레이드하여 메모리 지원을 늘립니다. 그런 다음에 새 패치 적용 작업을 시작합니다.
### 문제: 메모리 부족(OOM) 오류와 함께 패치 적용 실패
**문제**: `AWS-RunPatchBaseline`을 실행하면 관리형 노드의 메모리 부족으로 인해 패치 작업이 실패합니다. `Cannot allocate memory`, `Killed`(Linux OOM Killer에서 발생)와 같은 오류가 발생하거나 작업이 예기치 않게 실패할 수 있습니다. 이 오류는 RAM이 1GB 미만인 인스턴스에서 발생할 가능성이 높지만, 사용할 수 있는 업데이트가 많은 경우 메모리가 더 많은 인스턴스에도 영향을 줄 수 있습니다.
**원인**: Patch Manager는 관리형 노드의 네이티브 패키지 관리자를 사용하여 패치 작업을 실행합니다. 패치 작업 중에 필요한 메모리는 다음과 같은 여러 요인에 따라 달라집니다.
+ 관리형 노드에 설치된 패키지 수 및 사용 가능한 업데이트 수.
+ 사용 중인 패키지 관리자 및 해당 메모리 특성.
+ 패치 작업 시 관리형 노드에서 실행 중인 기타 프로세스.
설치된 패키지가 많거나 사용 가능한 업데이트가 많은 관리형 노드는 패치 작업 중에 더 많은 메모리가 필요합니다. 사용 가능한 메모리가 충분하지 않으면 패치 적용 프로세스가 실패하고 오류와 함께 종료됩니다. 운영 체제가 패치 프로세스를 종료할 수도 있습니다.
**해결 방법**: 다음 방법 중 하나 이상을 시도해 보세요.
+ 유지 관리 기간을 사용하는 등 관리형 노드에서 워크로드 활동이 적은 시간대에 패치 적용 작업을 예약합니다.
+ 인스턴스를 메모리가 더 많은 유형으로 업그레이드합니다.
+ 관리형 노드에서 스왑 메모리를 구성합니다. EBS 처리량이 제한된 인스턴스에서는 스왑 사용량이 많으면 성능이 저하될 수 있습니다.
+ 패치 작업 중에 관리형 노드에서 실행 중인 프로세스 수를 검토하고 줄입니다.
### 문제: '퍼블릭 키를 사용할 수 없어 다음 서명을 확인할 수 없습니다'라는 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류로 Ubuntu Server에서 패치 적용에 실패합니다.
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**원인**: GPG(GNU Privacy Guard) 키가 만료되었거나 누락되었습니다.
**솔루션**: GPG 키를 새로 고치거나 키를 다시 추가합니다.
예를 들어 이전에 표시된 오류를 사용하면 `467B942D3A79BD29` 키가 누락되었으며 추가해야 한다는 것을 알 수 있습니다. 이렇게 하려면 다음과 같은 명령 중 하나를 실행합니다.
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
또는 모든 키를 새로 고치려면 다음 명령을 실행합니다.
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
이후에도 오류가 다시 발생하면 리포지토리를 유지 관리하는 조직에 문제를 보고하는 것이 좋습니다. 수정이 가능할 때까지 패치 적용 프로세스 중에 `/etc/apt/sources.list` 파일을 편집하여 리포지토리를 생략할 수 있습니다.
이렇게 하려면 편집할 `sources.list` 파일을 열고, 리포지토리의 줄을 찾고, 줄 시작 부분에 `#` 문자를 삽입하여 주석을 추가합니다. 그런 다음에 파일을 저장하고 닫습니다.
### 문제: 'NoMoreMirrorsRepoError' 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류가 표시됩니다.
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**원인**: 소스 리포지토리에 오류가 있습니다.
**솔루션**: 리포지토리를 유지 관리하는 조직에 문제를 보고하는 것이 좋습니다. 오류가 수정될 때까지 운영 체제 수준에서 리포지토리를 비활성화할 수 있습니다. 이렇게 하려면 다음 명령을 실행하여 *repo-name*의 값을 리포지토리 이름으로 바꿉니다.
```
yum-config-manager --disable repo-name
```
다음은 한 예입니다.
```
yum-config-manager --disable pgdg94
```
이 명령을 실행한 후 다른 패치 적용 작업을 실행합니다.
### 문제: '페이로드를 다운로드할 수 없음' 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류가 표시됩니다.
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**원인**: 관리형 노드 구성에 오류가 있거나 불완전합니다.
**솔루션**: 관리형 노드에 다음이 구성되었는지 확인합니다.
+ 보안 그룹의 아웃바운드 TCP 443 규칙.
+ NACL의 송신 TCP 443 규칙.
+ NACL의 수신 TCP 1024-65535 규칙.
+ S3 엔드포인트에 대한 연결을 제공하는 라우팅 테이블의 NAT/IGW 인스턴스에 인터넷 액세스 권한이 없으면 S3 엔드포인트와 연결을 제공합니다. 이렇게 하려면 S3 게이트웨이 엔드포인트를 VPC에서 추가하고 관리형 노드의 라우팅 테이블과 통합합니다.
### 문제: '설치 오류: dpkg: 오류: dpkg 프런트엔드가 다른 프로세스에 의해 잠겼습니다'라는 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류로 패치 적용에 실패합니다.
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**원인**: 운영 체제 수준에서 관리형 노드의 다른 프로세스가 이미 패키지 관리자에서 실행되고 있습니다. 다른 프로세스를 완료하는 데 시간이 오래 걸리는 경우 Patch Manager 패치 적용 작업이 시간 초과로 실패할 수 있습니다.
**솔루션**: 패키지 관리자를 사용 중인 다른 프로세스가 완료된 후 새 패치 적용 작업을 실행합니다.
### 문제: 'dpkg가 중단되었습니다' 오류로 Ubuntu Server의 패치 적용 실패
**문제**: Ubuntu Server에서 다음과 비슷한 오류로 패치 적용에 실패합니다.
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**원인**: 하나 이상의 패키지가 잘못 구성되었습니다.
**해결 방법**: 다음 단계를 수행합니다.
1. 다음과 같은 명령을 한 번에 하나씩 실행하여 영향을 받는 패키지와 각 패키지의 문제를 확인합니다.
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. 다음 명령을 실행하여 문제가 있는 패키지를 수정합니다.
```
sudo dpkg --configure -a
```
1. 이전 명령으로 문제가 완전히 해결되지 않으면 다음 명령을 실행합니다.
```
sudo apt --fix-broken install
```
### 문제: 패키지 관리자 유틸리티를 통해 패키지 종속성을 해결할 수 없음
**문제**: 관리형 노드의 네이티브 패키지 관리자를 통해 패키지 종속성을 해결할 수 없어 패치 적용에 실패합니다. 다음 오류 메시지 예제는 `yum`을 패키지 관리자로 사용하는 운영 체제의 이 오류 유형을 나타냅니다.
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**원인**: Linux 운영 체제의 Patch Manager에서는 시스템의 네이티브 패키지 관리자를 사용하여 패치 적용 작업을 실행합니다(예: `yum`, `dnf`, `apt` 및 `zypper`). 애플리케이션에서는 필요에 따라 종속 패키지를 자동으로 감지, 설치, 업데이트 또는 제거합니다. 그러나 다음과 같은 일부 조건에서는 패키지 관리자가 종속성 작업을 완료하지 못할 수 있습니다.
+ 충돌하는 리포지토리가 운영 체제에 여러 개 구성되어 있습니다.
+ 네트워크 관련 문제로 인해 원격 리포지토리 URL에 액세스할 수 없습니다.
+ 리포지토리에서 잘못된 아키텍처에 대한 패키지를 찾았습니다.
**솔루션**: 아주 다양한 사유의 종속성 문제 때문에 패치 적용에 실패할 수 있습니다. 따라서 AWS Support에 문의하여 문제 해결 도움을 받는 것이 좋습니다.
### 문제: SLES 관리형 노드에서 Zypper 패키지 잠금 종속성 실패
**문제**: SUSE Linux Enterprise Server 인스턴스에서 `Install` 작업을 사용하여 `AWS-RunPatchBaseline`을 실행하면 패키지 잠금과 관련된 종속성 검사 오류와 함께 패치 적용이 실패합니다. 다음과 비슷한 오류 메시지가 나타날 수 있습니다.
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
이 예제에서는 패키지 `mock-pkg-standalone`이 잠기므로 `sudo zypper locks`를 실행하고 출력에서 이 패키지 이름을 찾아 확인할 수 있습니다.
또는 종속성 검사 실패를 나타내는 로그 항목이 표시될 수 있습니다.
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**참고**
이 문제는 `Install` 작업 중에만 발생합니다. `Scan` 작업은 패키지 잠금을 적용하지 않으며 기존 잠금의 영향을 받지 않습니다.
**원인**: 이 오류는 zypper 패키지 잠금으로 인해 종속성 충돌 때문에 패키지 설치 또는 업데이트가 불가능한 경우에 발생합니다. 패키지 잠금은 다음과 같은 여러 가지 이유로 존재할 수 있습니다.
+ **고객 적용 잠금**: 사용자 또는 시스템 관리자가 `zypper addlock`과 같은 zypper 명령을 사용하여 패키지를 수동으로 잠갔습니다.
+ **Patch Manager 거부 패치**: 패치 기준의 **거부된 패치** 목록에 패키지를 지정하면 Patch Manager가 자동으로 패키지 잠금을 적용하여 설치를 방지합니다.
+ **중단된 작업으로 인한 잔존 잠금**: 드문 경우지만 Patch Manager가 임시 잠금을 정리하기 전에 패치 작업이 중단된 경우(예: 시스템 재부팅) 잔존 패키지 잠금이 관리형 노드에 남아 있을 수 있습니다.
**솔루션**: zypper 패키지 잠금 문제를 해결하려면 원인에 따라 다음 단계를 따르세요.
**1단계: 잠긴 패키지 식별**
SLES 관리형 노드에 연결하고 다음 명령을 실행하여 현재 잠긴 패키지를 모두 나열합니다.
```
sudo zypper locks
```
**2단계: 잠금 소스 확인**
+ 잠긴 패키지가 시스템 안정성을 위해 의도적으로 잠긴 패키지인 경우 잠금 상태로 유지해야 하는지 아니면 패치 적용을 위해 일시적으로 잠금 해제할 수 있는지 고려합니다.
+ 잠긴 패키지가 패치 기준의 **거부된 패치** 목록의 항목과 일치하는 경우 이는 중단된 패치 작업으로 인한 잔존 잠금일 수 있습니다. 정상 작업 중에 Patch Manager는 이러한 잠금을 일시적으로 적용하고 작업이 완료되면 자동으로 제거합니다. 거부된 패치 목록에서 패키지를 제거하거나 패치 기준 규칙을 수정할 수 있습니다.
+ 잠긴 패키지를 인식할 수 없고 해당 패키지가 의도적으로 잠기지 않았다면 이전에 중단된 패치 작업의 잔존 잠금일 수 있습니다.
**3단계: 필요에 따라 잠금 제거**
특정 패키지 잠금을 제거하려면 다음 명령을 사용합니다.
```
sudo zypper removelock package-name
```
모든 패키지 잠금을 제거하려면(주의 필요) 다음 명령을 실행합니다.
```
sudo zypper cleanlocks
```
**4단계: 패치 기준 업데이트(해당하는 경우)**
패치 기준에서 거부된 패치로 인해 잠금이 발생한 경우:
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준** 탭을 선택한 다음 사용자 지정 패치 기준을 선택합니다.
1. **작업**, **패치 기준 수정**을 선택합니다.
1. **거부된 패치** 섹션에서 나열된 패키지를 검토하고 설치를 허용해야 하는 패키지를 모두 제거합니다.
1. **변경 사항 저장**을 선택합니다.
**5단계: 패치 작업 재시도**
문제가 있는 잠금을 제거하고 필요한 경우 패치 기준을 업데이트한 후 `AWS-RunPatchBaseline` 문서를 다시 실행합니다.
**참고**
Patch Manager는 `Install` 작업 중에 거부된 패치에 대한 잠금을 적용하면 패치 작업이 완료된 후 이러한 잠금을 자동으로 정리하도록 설계되었습니다. `sudo zypper locks`를 실행할 때 이러한 잠금이 표시되면 정리가 발생하기 전에 이전 패치 작업이 중단되었음을 나타냅니다. 그러나 패치 작업이 중단되면 이 절차에 설명된 대로 수동 정리가 필요할 수 있습니다.
**방지**: 향후 zypper 잠금 충돌을 방지하려면
+ 패치 기준의 거부된 패치 목록을 주의 깊게 검토하여 실제로 제외하려는 패키지만 포함되어 있는지 확인합니다.
+ 보안 업데이트에 대한 종속성으로 필요할 수 있는 패키지를 수동으로 잠그지 마세요.
+ 패키지를 수동으로 잠가야 하는 경우 이유를 문서화하고 잠금을 주기적으로 검토합니다.
+ 패치 작업이 성공적으로 완료되고 시스템 재부팅 또는 기타 요인으로 인해 중단되지 않는지 확인합니다.
+ 패치 작업이 완료될 때까지 모니터링하고 시스템 재부팅 또는 적절한 임시 잠금 정리를 방해할 수 있는 기타 작업으로 패치 작업이 중단되지 않도록 합니다.
### 문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.
**문제**: `AWS-RunPatchBaseline` 실행 시, 오류 코드 4와 다음 오류 메시지와 함께 패치가 실패합니다.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**원인**: 이 오류는 여러 패치 적용 작업이 동일한 관리형 노드에서 동시에 실행을 시도할 때 발생합니다. 잠금 파일은 동시 패치 작업을 방지하여 충돌을 방지하고 시스템 안정성을 보장합니다.
**해결 방법**: 패치 작업이 동일한 관리형 노드에서 동시에 실행되도록 예약되지 않았는지 확인합니다. 다음 구성을 검토하여 일정 충돌을 식별하고 해결합니다.
+ **패치 정책**: 빠른 설정 패치 정책 구성을 확인하여 다른 패치 적용 일정과 겹치지 않도록 합니다.
+ **유지 관리 기간**: 유지 관리 기간 연결을 검토하여 겹치는 시간대에 여러 기간이 동일한 관리형 노드를 대상으로 패치 작업을 수행하지 않는지 확인합니다.
+ **수동 즉시 패치 작업**: 예약된 패치 적용이 진행되는 동안 수동 **즉시 패치 작업**을 시작하지 마세요.
## Windows Server에서 `AWS-RunPatchBaseline` 실행 시 오류
**Topics**
+ [문제: 일치하지 않는 제품군/제품 페어](#patch-manager-troubleshooting-product-family-mismatch)
+ [문제: `AWS-RunPatchBaseline` 출력에서 `HRESULT`(Windows Server) 반환](#patch-manager-troubleshooting-hresult)
+ [문제: 관리형 노드에 Windows 업데이트 카탈로그 또는 WSUS에 대한 액세스 권한이 없습니다.](#patch-manager-troubleshooting-instance-access)
+ [문제: PatchBaselineOperations PowerShell 모듈을 다운로드할 수 없음](#patch-manager-troubleshooting-module-not-downloadable)
+ [문제: 패치 누락](#patch-manager-troubleshooting-missing-patches)
+ [문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.](#patch-manager-troubleshooting-windows-concurrent-lock)
### 문제: 일치하지 않는 제품군/제품 페어
**문제**: Systems Manager 콘솔에서 패치 기준을 생성할 때 제품군 및 제품을 지정합니다. 예를 들면 다음을 선택할 수 있습니다.
+ **제품군**: `Office`
**제품**: `Office 2016`
**원인**: 일치하지 않는 제품군/제품 페어로 패치 기준을 만들려고 하면 오류 메시지가 표시됩니다. 가능한 이유는 다음과 같습니다.
+ 유효한 제품군 및 제품 페어를 선택했지만 제품군 선택을 제거했습니다.
+ [**사용 가능 및 일치하는 옵션(Available and matching options)**] 하위 목록 대신 [**폐기되었거나 일치하지 않는 옵션(Obsolete or mismatched options)**] 하위 목록에서 제품을 선택했습니다.
실수로 제품 [**사용되지 않거나 일치하지 않는 옵션(Obsolete or mismatched options)**] 하위 목록의 항목이 SDK 또는 AWS Command Line Interface(AWS CLI) `create-patch-baseline` 명령을 통해 입력되었을 수 있습니다. 오타가 있거나 제품이 잘못된 제품군에 할당되었다는 뜻일 수 있습니다. 이전 패치 기준에 지정되었지만 Microsoft에서 제공하는 패치가 없는 경우에도 [**사용되지 않거나 일치하지 않는 옵션(Obsolete or mismatched options)**] 하위 목록에 제품이 포함됩니다.
**해결 방법**: 콘솔에서 이 문제를 방지하려면 항상 [**현재 사용 가능한 옵션(Currently available options)**] 하위 목록에서 옵션을 선택합니다.
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)` 명령을 사용하거나 `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` 명령을 사용하여 사용 가능한 패치가 있는 제품을 볼 수도 있습니다.
### 문제: `AWS-RunPatchBaseline` 출력에서 `HRESULT`(Windows Server) 반환
**문제**: 다음과 같은 오류가 표시됩니다.
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**원인**: 이 출력은 기본 Windows Update API가 패치 작업을 실행할 수 없음을 나타냅니다.
**해결 방법**: 다음 microsoft.com 항목에서 `HResult` 코드를 확인하여 오류 해결을 위한 문제 해결 단계를 식별합니다.
+ [구성 요소별 Windows 업데이트 오류 코드](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Windows 업데이트의 일반적인 오류 및 해결 방법](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### 문제: 관리형 노드에 Windows 업데이트 카탈로그 또는 WSUS에 대한 액세스 권한이 없습니다.
**문제**: 다음과 같은 오류가 표시됩니다.
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**원인**: 이 오류는 Windows Update 구성 요소, Windows Update 카탈로그 또는 Windows Server Update Services(WSUS)에 대한 연결 부족과 관련이 있을 수 있습니다.
**해결 방법**: 관리형 노드가 인터넷 게이트웨이, NAT 게이트웨이 또는 NAT 인스턴스를 통해 [Microsoft Update 카탈로그](https://www.catalog.update.microsoft.com/home.aspx)에 연결되어 있는지 확인합니다. WSUS를 사용하는 경우 관리형 노드가 환경의 WSUS 서버에 연결되어 있는지 확인합니다. 의도한 대상에 연결할 수 있는 경우 Microsoft 설명서에서 `HResult 0x80072EE2`의 다른 잠재적 원인을 확인합니다. 이는 운영 체제 수준 문제를 나타낼 수 있습니다.
### 문제: PatchBaselineOperations PowerShell 모듈을 다운로드할 수 없음
**문제**: 다음과 같은 오류가 표시됩니다.
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**해결 방법**: Amazon Simple Storage Service(Amazon S3)에 대한 관리형 노드 연결 및 권한을 확인합니다. 관리형 노드의 AWS Identity and Access Management(IAM) 역할이 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)에 언급된 최소 권한을 사용해야 합니다. 노드는 Amazon S3 게이트웨이 엔드포인트, NAT 게이트웨이 또는 인터넷 게이트웨이를 통해 Amazon S3 엔드포인트와 통신해야 합니다. AWS Systems ManagerSSM Agent (SSM Agent)에 대한 VPC 엔드포인트 요구 사항에 대한 자세한 내용은 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md) 섹션을 참조하세요.
### 문제: 패치 누락
**문제**: `AWS-RunPatchbaseline`이 성공적으로 완료되었지만 일부 누락된 패치가 있습니다.
다음은 몇 가지 일반적인 원인과 해결 방법입니다.
**원인 1**: 기준이 유효하지 않습니다.
**해결 방법 1**: 이것이 원인인지 확인하려면 다음 절차를 따릅니다.
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. [**명령 기록(Command history)**] 탭을 선택하고 기준을 확인할 명령을 선택합니다.
1. 패치가 누락된 관리형 노드를 선택합니다.
1. [**1단계 - 출력(Step 1 - Output)**]을 선택하고 `BaselineId` 값을 찾습니다.
1. 할당된 [패치 기준 구성](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom), 즉 운영 체제, 제품 이름, 분류 및 패치 기준의 심각도를 확인합니다.
1. [Microsoft Update 카탈로그](https://www.catalog.update.microsoft.com/home.aspx)로 이동합니다.
1. Microsoft 기술 자료(KB) 문서 ID(예: KB3216916)를 검색합니다.
1. **제품(Product)** 아래의 값이 관리형 노드의 값과 일치하는지 확인하고 해당 **제목(Title)**을 선택합니다. 새로운 **Update Details(세부 정보 업데이트)** 창이 열립니다.
1. [**개요(Overview)**] 탭의 [**분류(classification)**] 및 [**MSRC 심각도(MSRC severity)**]가 이전에 찾은 패치 기준 구성과 일치해야 합니다.
**원인 2**: 패치가 교체되었습니다.
**해결 방법 2**: 이것이 맞는지 확인하려면 다음 절차를 따릅니다.
1. [Microsoft Update 카탈로그](https://www.catalog.update.microsoft.com/home.aspx)로 이동합니다.
1. Microsoft 기술 자료(KB) 문서 ID(예: KB3216916)를 검색합니다.
1. **제품(Product)** 아래의 값이 관리형 노드의 값과 일치하는지 확인하고 해당 **제목(Title)**을 선택합니다. 새로운 **Update Details(세부 정보 업데이트)** 창이 열립니다.
1. [**패키지 세부 정보(Package Details)**] 탭으로 이동합니다. [**이 업데이트는 다음 업데이트로 대체되었습니다.(This update has been replaced by the following updates:)**] 헤더 아래에서 항목을 찾습니다.
**원인 3**: WSUS 및 Window 온라인 업데이트는 Microsoft에서 독립적인 릴리스 채널로 처리하기 때문에 동일한 패치의 KB 번호가 다를 수 있습니다.
**해결 방법 3**: 패치 적격성을 확인합니다. WSUS에서 패키지를 사용할 수 없는 경우 [OS 빌드 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57)를 설치합니다. 모든 운영 체제 빌드에 패키지를 사용할 수 있는 경우 [OS 빌드 18362.1256 및 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9)을 설치합니다.
### 문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.
**문제**: `AWS-RunPatchBaseline` 실행 시, 오류 코드 4와 다음 오류 메시지와 함께 패치가 실패합니다.
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**원인**: 이 오류는 여러 패치 적용 작업이 동일한 관리형 노드에서 동시에 실행을 시도할 때 발생합니다. 잠금 파일은 동시 패치 작업을 방지하여 충돌을 방지하고 시스템 안정성을 보장합니다.
**해결 방법**: 패치 작업이 동일한 관리형 노드에서 동시에 실행되도록 예약되지 않았는지 확인합니다. 다음 구성을 검토하여 일정 충돌을 식별하고 해결합니다.
+ **패치 정책**: 빠른 설정 패치 정책 구성을 확인하여 다른 패치 적용 일정과 겹치지 않도록 합니다.
+ **유지 관리 기간**: 유지 관리 기간 연결을 검토하여 겹치는 시간대에 여러 기간이 동일한 관리형 노드를 대상으로 패치 작업을 수행하지 않는지 확인합니다.
+ **수동 즉시 패치 작업**: 예약된 패치 적용이 진행되는 동안 수동 **즉시 패치 작업**을 시작하지 마세요.
## macOS에서 `AWS-RunPatchBaseline` 실행 시 오류
**Topics**
+ [문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.](#patch-manager-troubleshooting-macos-concurrent-lock)
### 문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.
**문제**: `AWS-RunPatchBaseline` 실행 시, 오류 코드 4와 다음 오류 메시지와 함께 패치가 실패합니다.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**원인**: 이 오류는 여러 패치 적용 작업이 동일한 관리형 노드에서 동시에 실행을 시도할 때 발생합니다. 잠금 파일은 동시 패치 작업을 방지하여 충돌을 방지하고 시스템 안정성을 보장합니다.
**해결 방법**: 패치 작업이 동일한 관리형 노드에서 동시에 실행되도록 예약되지 않았는지 확인합니다. 다음 구성을 검토하여 일정 충돌을 식별하고 해결합니다.
+ **패치 정책**: 빠른 설정 패치 정책 구성을 확인하여 다른 패치 적용 일정과 겹치지 않도록 합니다.
+ **유지 관리 기간**: 유지 관리 기간 연결을 검토하여 겹치는 시간대에 여러 기간이 동일한 관리형 노드를 대상으로 패치 작업을 수행하지 않는지 확인합니다.
+ **수동 즉시 패치 작업**: 예약된 패치 적용이 진행되는 동안 수동 **즉시 패치 작업**을 시작하지 마세요.
## AWS Support Automation 런북 사용
AWS Support는 패치 적용과 관련된 특정 문제를 해결하는 데 사용할 수 있도록 두 개의 Automation 런북을 제공합니다.
+ `AWSSupport-TroubleshootWindowsUpdate` - [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) 런북은 Amazon Elastic Compute Cloud(Amazon EC2) Windows Server 인스턴스에 대한 Windows Server 업데이트가 실패할 수 있는 문제를 식별하는 데 사용됩니다.
+ `AWSSupport-TroubleshootPatchManagerLinux` - [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) 런북은 Patch Manager를 사용하는 Linux 기반 관리형 노드에서 패치 적용 실패의 원인이 될 수 있는 일반적인 문제를 해결합니다. 이 런북의 주요 목표는 패치 명령 실패의 근본 원인을 식별하고 문제 해결 계획을 제안하는 것입니다.
**참고**
Automation 런북을 실행하려면 요금이 부과됩니다. 자세한 내용은 [AWS Systems Manager Automation 요금](https://aws.amazon.com/systems-manager/pricing/#Automation)을 참조하세요.
## AWS Support 문의
이 섹션이나 [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager)의 Systems Manager 개발자 포럼에서 문제 해결 방법을 찾을 수 없고 [Developer, Business 또는 Enterprise 지원 플랜](https://aws.amazon.com/premiumsupport/plans)이 있는 경우 [AWS Support](https://aws.amazon.com/premiumsupport/)에서 기술 지원 사례를 생성할 수 있습니다.
지원에 연락하기 전에 다음 항목을 수집합니다.
+ [SSM Agent 로그](ssm-agent-logs.md)
+ Run Command 명령 ID, 유지 관리 기간 ID 또는 Automation 실행 ID
+ Windows Server 관리형 노드를 위해서는 다음 항목도 수집합니다.
+ [패치 설치 방법](patch-manager-installing-patches.md)의 **Windows** 탭에 설명된 `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`
+ Windows 업데이트 로그: Windows Server 2012 R2 이상의 경우 `%windir%/WindowsUpdate.log`를 사용합니다. Windows Server 2016 이상에서는 `%windir%/WindowsUpdate.log`를 사용하기 전에 먼저 PowerShell 명령 [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)를 실행합니다.
+ Linux 관리형 노드를 위해서는 다음 항목도 수집합니다.
+ 디렉터리 `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`의 내용