• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.
# 콘솔을 사용하여 Patch Manager 리소스 및 규정 준수 작업
AWS Systems Manager의 도구인 Patch Manager를 사용하려면 다음 태스크를 완료합니다. 이러한 작업은 이 단원에서 더 자세히 설명합니다.
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)