• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요. # 패치 기준 이 섹션의 주제에서는 관리형 노드에서 `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)에서 문제 해결을 위한 도움말을 찾아보세요.