• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.

# Linux를 위한 사용자 지정 패치 기준 생성
<a name="patch-manager-create-a-patch-baseline-for-linux"></a>

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. **패치 기준 생성**을 선택합니다.