보안 패치 선택 방법 - AWS Systems Manager

보안 패치 선택 방법

AWS Systems Manager의 기능인 Patch Manager의 주 업무는 관리형 노드에 운영 체제 보안 관련 업데이트를 설치하는 것입니다. 기본적으로 Patch Manager는 사용 가능한 모든 패치를 설치하기 보다는 보안에 관련된 소규모의 패치만 설치합니다.

패치의 심각도 수준을 보고하는 Linux 기반 운영 체제 유형의 경우 Patch Manager는 업데이트 알림 또는 개별 패치에 대해 소프트웨어 게시자가 보고한 심각도 수준을 사용합니다. Patch Manager는 CVSS(Common Vulnerability Scoring System)와 같은 서드 파티 소스 또는 NVD(National Vulnerability Database)에서 발표한 지표에서 심각도 수준을 도출하지 않습니다.

참고

Patch Manager에서 지원하는 모든 Linux 기반 시스템에서 관리형 노드에 대해 구성된 다른 소스 리포지토리를 선택하여 비보안 업데이트를 설치할 수도 있습니다. 자세한 내용은 대체 패치 소스 리포지토리를 지정하는 방법(Linux)을 참조하세요.

Patch Manager가 운영 체제에 맞는 보안 패치를 선택하는 방법을 알아보려면 다음 탭에서 선택합니다.

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

사전 구성된 리포지토리는 Amazon Linux 1 및 Amazon Linux 2에서 Amazon Linux 2022 및 Amazon Linux 2023과 다르게 처리됩니다.

Amazon Linux 1 및 Amazon Linux 2의 경우 Systems Manager 패치 기준 서비스는 관리형 노드의 사전 구성된 리포지토리를 사용합니다. 하나의 노드에는 보통 다음과 같은 두 개의 사전 구성된 리포지토리가 있습니다.

Amazon Linux 1

  • 리포지토리 ID: amzn-main/latest

    리포지토리 이름: amzn-main-Base

  • 리포지토리 ID: amzn-updates/latest

    리포지토리 이름: amzn-updates-Base

Amazon Linux 2

  • 리포지토리 ID: amzn2-core/2/architecture

    리포지토리 이름: Amazon Linux 2 core repository

  • 리포지토리 ID: amzn2extra-docker/2/architecture

    리포지토리 이름: Amazon Extras repo for docker

참고

아키텍처는 x86_64 또는 arch64일 수 있습니다.

처음에는 Amazon Linux 2023(AL2023) 인스턴스에 AL2023 버전 및 선택한 AMI에서 사용할 수 있었던 업데이트가 포함됩니다. 기본적으로 AL2023 인스턴스에는 시작 시 심각하고 중요한 추가 보안 업데이트가 자동으로 수신되지 않습니다. 그 대신에 기본적으로 켜져 있는 AL2023의 버전 지정 리포지토리 특성을 통한 결정적 업그레이드를 통해 특정한 필요성을 충족하는 업데이트를 일정에 따라 적용할 수 있습니다. 자세한 내용은 Amazon Linux 2023 사용 설명서의 버전 지정 리포지토리를 통한 결정적 업그레이드를 참조하세요.

Amazon Linux 2022에서는 사전 구성된 리포지토리가 패키지 업데이트의 잠긴 버전에 연결됩니다. 새로운 Amazon Linux 2022용 Amazon Machine Images(AMIs)가 릴리스될 때 특정 버전으로 잠겨 있습니다. 패치 업데이트의 경우 Patch Manager는 패치 업데이트 리포지토리의 최신 잠긴 버전을 검색한 다음 잠긴 버전의 콘텐츠를 기반으로 관리 노드의 패키지를 업데이트합니다.

AL2023의 사전 구성된 리포지토리는 다음과 같습니다.

  • 리포지토리 ID: amazonlinux

    리포지토리 이름: Amazon Linux 2023 리포지토리

Amazon Linux 2022(평가판 릴리스)의 사전 구성된 리포지토리는 패키지 업데이트의 잠긴 버전에 연결됩니다. 새로운 Amazon Linux 2022용 Amazon Machine Images(AMIs)가 릴리스될 때 특정 버전으로 잠겨 있습니다. 패치 업데이트의 경우 Patch Manager는 패치 업데이트 리포지토리의 최신 잠긴 버전을 검색한 다음 잠긴 버전의 콘텐츠를 기반으로 관리 노드의 패키지를 업데이트합니다.

Amazon Linux 2022에서 사전 구성된 리포지토리는 다음과 같습니다.

  • 리포지토리 ID: amazonlinux

    리포지토리 이름: Amazon Linux 2022 리포지토리

참고

모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.

Amazon Linux 1 및 Amazon Linux 2 관리형 노드에서는 Yum을 패키지 관리자로 사용합니다. Amazon Linux 2022 및 Amazon Linux 2023에서는 DNF를 패키지 관리자로 사용합니다.

두 패키지 관리자 모두 업데이트 알림 개념을 updateinfo.xml이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. Patch Manager는 업데이트 알림에 있는 모든 패키지를 보안으로 간주합니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당합니다.

참고

패치 기준선 생성 페이지에서 비보안 업데이트 포함 확인란을 선택하면 updateinfo.xml 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.

CentOS and CentOS Stream

CentOS 및 CentOS Stream의 경우 Systems Manager 패치 기준선 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 다음 목록에는 가상의 CentOS 8.2 Amazon Machine Image(AMI)에 대한 예가 나와 있습니다.

  • 리포지토리 ID: example-centos-8.2-base

    리포지토리 이름: Example CentOS-8.2 - Base

  • 리포지토리 ID: example-centos-8.2-extras

    리포지토리 이름: Example CentOS-8.2 - Extras

  • 리포지토리 ID: example-centos-8.2-updates

    리포지토리 이름: Example CentOS-8.2 - Updates

  • 리포지토리 ID: example-centos-8.x-examplerepo

    리포지토리 이름: Example CentOS-8.x – Example Repo Packages

참고

모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.

CentOS 6 및 7 관리형 노드는 Yum을 패키지 관리자로 사용합니다. CentOS 8 및 CentOS Stream 노드는 DNF를 패키지 관리자로 사용합니다. 두 패키지 관리자 모두 업데이트 알림 개념을 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다.

하지만 CentOS 및 CentOS Stream 기본 리포지토리는 업데이트 알림으로 구성되지 않습니다. 따라서 Patch Manager는 기본 CentOS 및 CentOS Stream 리포지토리의 패키지를 감지하지 못합니다. Patch Manager가 업데이트 알림에 포함되지 않은 패키지를 처리하게 하려면 패치 기준 규칙에서 EnableNonSecurity 플래그를 설정해야 합니다.

참고

CentOS 및 CentOS Stream 업데이트 알림은 지원되지 않습니다. 업데이트 알림을 포함하는 리포지토리는 시작 후 다운로드할 수 있습니다.

Debian 서버 and Raspberry Pi OS

Debian Server 및 Raspberry Pi OS(구 Raspbian)에서 Systems Manager 패치 기준 서비스는 인스턴스에 있는 사전 구성된 리포지토리를 사용합니다. 사용 가능한 패키지 업그레이드의 업데이트된 목록을 가져오기 위해 3개의 사전 구성된 리포지토리가 사용됩니다. 이를 위해, Systems Manager는 sudo apt-get update 명령과 동등한 명령을 수행합니다.

그런 다음 패키지는 debian-security codename 리포지토리에서 필터링됩니다. 즉, 각 Debian Server 버전에서 Patch Manager는 다음과 같이 해당 버전의 관련 리포지토리에 속하는 업그레이드만 식별합니다.

  • Debian Server 8: debian-security jessie

  • Debian Server 9: debian-security stretch

  • Debian Server 10: debian-security buster

  • Debian Server 11: debian-security bullseye

  • Debian Server 12: debian-security bookworm

참고

Debian Server 8에만 해당: 일부 Debian Server 8.* 관리형 노드는 더 이상 사용하지 않는 패키지 리포지토리(jessie-backports)를 참조하기 때문에 Patch Manager는 패치 작업이 성공할 수 있도록 추가 단계를 수행해야 합니다. 자세한 내용은 패치 설치 방법 단원을 참조하십시오.

Oracle Linux

Oracle Linux에서, Systems Manager 패치 기준 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 하나의 노드에는 보통 다음과 같은 두 개의 사전 구성된 리포지토리가 있습니다.

Oracle Linux 7:

  • 리포지토리 ID: ol7_UEKR5/x86_64

    리포지토리 이름: Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)

  • 리포지토리 ID: ol7_latest/x86_64

    리포지토리 이름: Oracle Linux 7Server Latest (x86_64)

Oracle Linux 8:

  • 리포지토리 ID: ol8_baseos_latest

    리포지토리 이름: Oracle Linux 8 BaseOS Latest (x86_64)

  • 리포지토리 ID: ol8_appstream

    리포지토리 이름: Oracle Linux 8 Application Stream (x86_64)

  • 리포지토리 ID: ol8_UEKR6

    리포지토리 이름: Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)

Oracle Linux 9:

  • 리포지토리 ID: ol9_baseos_latest

    리포지토리 이름: Oracle Linux 9 BaseOS Latest (x86_64)

  • 리포지토리 ID: ol9_appstream

    리포지토리 이름: Oracle Linux 9 Application Stream Packages(x86_64)

  • 리포지토리 ID: ol9_UEKR7

    리포지토리 이름: Oracle Linux UEK Release 7 (x86_64)

참고

모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.

Oracle Linux 관리형 노드는 Yum을 패키지 관리자로 사용하며, Yum은 업데이트 알림의 개념을 updateinfo.xml이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당하고 패치 기준에 지정된 분류 필터를 기반으로 패키지를 설치합니다.

참고

패치 기준선 생성 페이지에서 비보안 업데이트 포함 확인란을 선택하면 updateinfo.xml 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.

AlmaLinux, RHEL, and Rocky Linux

AlmaLinux, Red Hat Enterprise Linux 및 Rocky Linux의 Systems Manager 패치 기준선 서비스에서는 관리형 노드의 사전 구성된 리포지토리(repos)를 사용합니다. 하나의 노드에는 보통 다음과 같은 세 개의 사전 구성된 리포지토리가 있습니다.

모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.

참고

패치 기준선 생성 페이지에서 비보안 업데이트 포함 확인란을 선택하면 updateinfo.xml 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.

Red Hat Enterprise Linux 7 관리형 노드에서는 Yum을 패키지 관리자로 사용합니다. AlmaLinux, Red Hat Enterprise Linux 8 및 Rocky Linux 관리형 노드에서는 DNF를 패키지 관리자로 사용합니다. 두 패키지 관리자 모두 업데이트 알림 개념을 updateinfo.xml이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당하고 패치 기준에 지정된 분류 필터를 기반으로 패키지를 설치합니다.

RHEL 7
참고

다음 리포지토리 ID는 RHUI 2와 연결되어 있습니다. RHUI 3는 2019년 12월에 출시되었으며 Yum 리포지토리 ID에 대한 다른 이름 지정 체계를 도입했습니다. 관리형 노드를 생성하는 RHEL-7 AMI에 따라 명령을 업데이트해야 할 수도 있습니다. 자세한 내용은 Red Hat Customer Portal의 Repository IDs for RHEL 7 in AWS Have Changed를 참조하세요.

  • 리포지토리 ID: rhui-REGION-client-config-server-7/x86_64

    리포지토리 이름: Red Hat Update Infrastructure 2.0 Client Configuration Server 7

  • 리포지토리 ID: rhui-REGION-rhel-server-releases/7Server/x86_64

    리포지토리 이름: Red Hat Enterprise Linux Server 7 (RPMs)

  • 리포지토리 ID: rhui-REGION-rhel-server-rh-common/7Server/x86_64

    리포지토리 이름: Red Hat Enterprise Linux Server 7 RH Common (RPMs)

AlmaLinux, 8 RHEL 8 및 Rocky Linux 8

  • 리포지토리 ID: rhel-8-appstream-rhui-rpms

    리포지토리 이름: Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)

  • 리포지토리 ID: rhel-8-baseos-rhui-rpms

    리포지토리 이름: Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)

  • 리포지토리 ID: rhui-client-config-server-8

    리포지토리 이름: Red Hat Update Infrastructure 3 Client Configuration Server 8

AlmaLinux 9, RHEL 9 및 Rocky Linux 9

  • 리포지토리 ID: rhel-9-appstream-rhui-rpms

    리포지토리 이름: Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)

  • 리포지토리 ID: rhel-9-baseos-rhui-rpms

    리포지토리 이름: Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)

  • 리포지토리 ID: rhui-client-config-server-9

    리포지토리 이름: Red Hat Enterprise Linux 9 Client Configuration

SLES

SUSE Linux Enterprise Server(SLES) 관리형 노드에 있는 ZYPP 라이브러리는 다음 위치에서 사용 가능한 패치 목록(패키지 모음)을 가져옵니다.

  • 리포지토리 목록: etc/zypp/repos.d/*

  • 패키지 정보: /var/cache/zypp/raw/*

SLES 관리형 노드는 Zypper를 패키지 관리자로 사용하며, Zypper는 패치 개념을 사용합니다. 패치는 단순히 특정 문제를 수정하는 패키지 모음입니다. Patch Manager는 패치에서 참조하는 모든 패키지를 보안 관련으로 처리합니다. 개별 패키지에는 분류 또는 심각도가 지정되지 않았기 때문에 Patch Manager는 해당 패키지를 이들이 속한 패치의 속성에 할당합니다.

Ubuntu 서버

Ubuntu Server에서, Systems Manager 패치 기준 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 사용 가능한 패키지 업그레이드의 업데이트된 목록을 가져오기 위해 3개의 사전 구성된 리포지토리가 사용됩니다. 이를 위해, Systems Manager는 sudo apt-get update 명령과 동등한 명령을 수행합니다.

그런 다음 codename-security 리포지토리에서 패키지가 필터링됩니다. 여기서 코드명은 Ubuntu Server 14의 경우 trusty와 같이 릴리스 버전마다 고유합니다. Patch Manager는 이러한 리포지토리의 일부인 업그레이드만 식별합니다.

  • Ubuntu Server 14.04 LTS: trusty-security

  • Ubuntu Server 16.04 LTS: xenial-security

  • Ubuntu Server 18.04 LTS: bionic-security

  • Ubuntu Server 20.04 LTS: focal-security

  • Ubuntu Server 20.10 STR: groovy-security

  • Ubuntu Server 22.04 LTS(jammy-security)

  • Ubuntu Server 23.04(lunar-security)

Windows Server

Microsoft Windows 운영 체제에서 Patch Manager는 Microsoft가 Microsoft Update에 게시하고 WSUS(Windows Server Update Services)에서 자동으로 사용할 수 있는 사용 가능한 업데이트 목록을 검색합니다.

참고

Patch Manager는 Patch Manager에 지원되는 Windows Server 운영 체제 버전에 대해서만 패치를 제공합니다. 예를 들어 Patch Manager는 Windows RT 패치에 사용할 수 없습니다.

Patch Manager는 모든 AWS 리전에서 새로운 업데이트를 지속적으로 모니터링합니다. 사용 가능한 업데이트 목록은 최소한 하루에 한 번씩 리전별로 갱신됩니다. Microsoft의 패치 정보가 처리되면 Patch Manager는 해당 패치 목록에서 최신 업데이트로 대체된 업데이트를 제거합니다. 그러므로 최신 업데이트만 표시되며 설치 시 사용 가능한 상태가 됩니다. 예를 들어 KB4012214가 KB3135456을 대체하는 경우 KB4012214만 Patch Manager에서 업데이트로 사용됩니다.

마찬가지로 Patch Manager는 패치 작업 중에 관리형 노드에서 사용할 수 있는 패치만 설치할 수 있습니다. 기본적으로 Windows Server 2019 및 Windows Server 2022는 이후 업데이트로 대체되는 업데이트를 제거합니다. 따라서 Windows Server 패치 기준의 ApproveUntilDate 파라미터를 사용하지만 ApproveUntilDate 파라미터에서 선택한 날짜가 최신 패치 날짜 이전인 경우 다음과 같은 시나리오가 발생합니다.

  • 대체된 패치는 노드에서 제거되므로 Patch Manager를 사용하여 설치할 수 없습니다.

  • 최신 대체 패치가 노드에 있지만 ApproveUntilDate 파라미터의 지정된 날짜에 따라 아직 설치가 승인되지 않았습니다.

즉, 관리형 노드는 이전 달의 중요한 패치가 설치되지 않았더라도 Systems Manager 운영 측면에서 규정을 준수합니다. ApproveAfterDays 파라미터를 사용할 때도 이와 동일한 시나리오가 발생할 수 있습니다. Microsoft의 대체 패치 동작으로 인해 Microsoft에서 제공하는 최신 패치가 ApproveAfterDays의 일수가 경과하기 전에 릴리스되는 경우 Windows Server에 대한 패치가 설치되지 않도록 숫자(일반적으로 30일 이상)를 설정할 수 있습니다. 관리형 노드에서 대체된 패치를 사용할 수 있도록 Windows 그룹 정책 개체(GPO) 설정을 수정한 경우에는 이 시스템 동작이 적용되지 않습니다.

참고

경우에 따라 Microsoft는 업데이트된 날짜와 시간을 지정하지 않는 애플리케이션에 대한 패치를 릴리스합니다. 이 경우 업데이트된 01/01/1970의 날짜 및 시간은 기본적으로 제공됩니다.