패치 설치 방법 - AWS Systems Manager

패치 설치 방법

AWS Systems Manager의 기능인 Patch Manager는 운영 체제 유형에 적합한 내장 메커니즘을 사용하여 관리형 노드에 업데이트를 설치합니다. 예를 들어 Windows Server의 경우 Windows Update API가 사용되며 Amazon Linux 2의 경우에는 yum 패키지 관리자가 사용됩니다.

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 관리형 노드의 패치 설치 워크플로는 다음과 같습니다.

  1. AWS-RunPatchBaseline 또는 AWS-RunPatchBaselineAssociation 문서에 대해 InstallOverrideList 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2~7단계를 건너뜁니다.

  2. 패치 기준에 지정된 대로 GlobalFilters를 적용하여 자격을 갖춘 패키지만 향후 프로세스에 사용되도록 유지됩니다.

  3. 패치 기준에 지정된 대로 ApprovalRules를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.

    그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 비보안 업데이트 포함(Include nonsecurity updates) 확인란을 선택했는지 여부에 따라 달라집니다.

    비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.

    비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.

  4. 패치 기준에 지정된 대로 ApprovedPatches를 적용합니다. 승인된 패치는 GlobalFilters를 통해 폐기되었거나 ApprovalRules에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.

  5. 패치 기준에 지정된 대로 RejectedPatches를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.

  6. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.

  7. YUM 업데이트 API(Amazon Linux 1, Amazon Linux 2) 또는 DNF 업데이트 API(Amazon Linux 2022, Amazon Linux 2023)는 다음과 같이 승인된 패치에 적용됩니다.

    • AWS에서 제공하는 미리 정의된 기본 패치 기준선의 경우 updateinfo.xml에 지정된 패치만 적용됩니다(보안 업데이트만 해당). 비보안 업데이트 포함 확인란이 선택되지 않았기 때문입니다. 미리 정의된 기준선은 다음과 같은 사용자 지정 기준선과 동일합니다.

      • 비보안 업데이트 포함 확인란은 선택되지 않음

      • [Critical, Important]의 심각도 목록

      • [Security, Bugfix]의 분류 목록

      Amazon Linux 1 및 Amazon Linux 2의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      Amazon Linux 2022 및 Amazon Linux 2023의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.

      sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

      비보안 업데이트 포함 확인란이 선택된 경우 updateinfo.xml에 포함된 패치 및 updateinfo.xml에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).

      Amazon Linux 1 및 Amazon Linux 2의 경우 비보안 업데이트 포함이 선택된 기준선에 [Critical, Important]의 심각도 목록 및 [Security, Bugfix]의 분류 목록이 포함된 경우 이와 동등한 yum 명령은 다음과 같습니다.

      sudo yum update --security --sec-severity=Critical,Important --bugfix -y

      Amazon Linux 2022 및 Amazon Linux 2023의 경우 이와 동등한 dnf 명령은 다음과 같습니다.

      sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
      참고

      Amazon Linux 2022 및 Amazon Linux 2023의 경우 Medium의 패치 심각도 수준은 일부 외부 리포지토리에 정의될 수 있는 Moderate의 심각도와 동일합니다. 패치 기준에 Medium 심각도 패치를 포함하면 외부 패치의 Moderate 심각도 패치도 인스턴스에 설치됩니다.

      API 작업 DescribeInstancePatches를 사용하여 규정 준수 데이터를 쿼리하는 경우 심각도 수준 Medium을 필터링하면 심각도 수준이 Medium 및 Moderate인 패치가 모두 보고됩니다.

      Amazon Linux 2022 및 Amazon Linux 2023은 DNF 패키지 관리자가 인식하는 패치 심각도 수준 None도 지원합니다.

  8. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

CentOS and CentOS Stream

CentOS 및 CentOS Stream 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.

  1. AWS-RunPatchBaseline 또는 AWS-RunPatchBaselineAssociation 문서에 대해 InstallOverrideList 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2~7단계를 건너뜁니다.

    패치 기준에 지정된 대로 GlobalFilters를 적용하여 자격을 갖춘 패키지만 향후 프로세스에 사용되도록 유지됩니다.

  2. 패치 기준에 지정된 대로 ApprovalRules를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.

    그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 비보안 업데이트 포함(Include nonsecurity updates) 확인란을 선택했는지 여부에 따라 달라집니다.

    비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.

    비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.

  3. 패치 기준에 지정된 대로 ApprovedPatches를 적용합니다. 승인된 패치는 GlobalFilters를 통해 폐기되었거나 ApprovalRules에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.

  4. 패치 기준에 지정된 대로 RejectedPatches를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.

  5. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.

  6. YUM 업데이트 API(CentOS 6.x 및 7.x 버전) 또는 DNF 업데이트(CentOS 8 및 CentOS Stream)는 승인된 패치에 적용됩니다.

  7. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

Debian 서버 and Raspberry Pi OS

Debian Server 및 Raspberry Pi OS(구 Raspbian) 인스턴스에서 패치 설치 워크플로는 다음과 같습니다.

  1. AWS-RunPatchBaseline 또는 AWS-RunPatchBaselineAssociation 문서에 대해 InstallOverrideList 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2~7단계를 건너뜁니다.

  2. python3-apt(libapt에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. ([비보안 업데이트 포함(Include nonsecurity updates)] 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)

    중요

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

    1. 관리형 노드에서 jessie-backports 리포지토리에 대한 참조는 소스 위치 목록(/etc/apt/sources.list.d/jessie-backports)에서 코멘트 아웃 처리됩니다. 따라서 해당 위치에서 패치를 다운로드하려고 시도하지 않습니다.

    2. Stretch 보안 업데이트 서명 키를 가져옵니다. 이 키는 Debian Server 8.* 배포의 업데이트 및 설치 작업에 필요한 권한을 제공합니다.

    3. 이 시점에서 패치 프로세스가 시작되기 전에 python3-apt의 최신 버전이 설치되도록 apt-get 작업이 실행됩니다.

    4. 설치 프로세스가 완료되면 jessie-backports 리포지토리에 대한 참조가 복원되고 서명 키가 apt 소스 키 링에서 제거됩니다. 이 작업은 패치 적용 작업 이전의 시스템 구성을 그대로 두기 위해 수행됩니다.

    다음에 Patch Manager가 시스템을 업데이트하면 동일한 프로세스가 반복됩니다.

  3. 패치 기준에 지정된 대로 GlobalFilters를 적용하여 자격을 갖춘 패키지만 향후 프로세스에 사용되도록 유지됩니다.

  4. 패치 기준에 지정된 대로 ApprovalRules를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.

    참고

    Debian Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.

    그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 비보안 업데이트 포함(Include nonsecurity updates) 확인란을 선택했는지 여부에 따라 달라집니다.

    비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.

    비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.

    참고

    Debian Server 및 Raspberry Pi OS의 경우 패치 후보 버전은 debian-security에 포함된 패치로 제한됩니다.

  5. 패치 기준에 지정된 대로 ApprovedPatches를 적용합니다. 승인된 패치는 GlobalFilters를 통해 폐기되었거나 ApprovalRules에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.

  6. 패치 기준에 지정된 대로 RejectedPatches를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.

  7. APT 라이브러리가 사용되어 패키지가 업그레이드됩니다.

    참고

    Patch Manager에서는 APT Pin-Priority 옵션을 사용하여 패키지에 우선순위를 지정하는 기능을 지원하지 않습니다. Patch Manager에서는 활성화된 모든 리포지토리에서 사용 가능한 업데이트를 집계하고 설치된 각 패키지의 기준과 일치하는 최신 업데이트를 선택합니다.

  8. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

macOS

macOS 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.

  1. /Library/Receipts/InstallHistory.plist 속성 목록은 softwareupdate 및 installer 패키지 관리자를 사용하여 설치 및 업그레이드된 소프트웨어의 레코드입니다. pkgutil 명령줄 도구(installer용)와 softwareupdate 패키지 관리자를 사용하여 CLI 명령을 실행하여 이 목록을 구문 분석합니다.

    installer의 경우 CLI 명령에 대한 응답에 package name, version, volume, location 및 install-time 세부 정보가 포함되지만 Patch Manager는 package name과 version만 사용합니다.

    softwareupdate의 경우 CLI 명령에 대한 응답에 패키지 이름(display name), version 및 date가 포함되지만 패치 관리자는 패키지 이름과 버전만 사용합니다.

    Brew 및 Brew Cask의 경우 Homebrew는 루트 사용자로 실행되는 명령을 지원하지 않습니다. 결과적으로 Patch Manager는 Homebrew 디렉터리의 소유자 또는 Homebrew 디렉터리의 소유자 그룹에 속하는 유효한 사용자로 Homebrew 명령을 쿼리하고 실행합니다. 명령은 softwareupdate 및 installer와 유사하며 Python 하위 프로세스를 통해 실행되어 패키지 데이터를 수집하고 출력을 구문 분석하여 패키지 이름 및 버전을 식별합니다.

  2. 패치 기준에 지정된 대로 GlobalFilters를 적용하여 자격을 갖춘 패키지만 향후 프로세스에 사용되도록 유지됩니다.

  3. 패치 기준에 지정된 대로 ApprovalRules를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.

  4. 패치 기준에 지정된 대로 ApprovedPatches를 적용합니다. 승인된 패치는 GlobalFilters를 통해 폐기되었거나 ApprovalRules에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.

  5. 패치 기준에 지정된 대로 RejectedPatches를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.

  6. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.

  7. 관리형 노드에서 적절한 패키지 CLI를 호출하여 다음과 같이 승인된 패치를 처리합니다.

    참고

    installer에는 업데이트를 확인하고 설치하는 기능이 없습니다. 따라서 installer의 경우 Patch Manager는 설치된 패키지만 보고합니다. 그 결과 installer 패키지는 Missing으로 보고되지 않습니다.

    • AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 비보안 업데이트 포함 확인란이 선택되지 않은 사용자 지정 패치 기준선의 경우 보안 업데이트만 적용됩니다.

    • 비보안 업데이트 포함 확인란이 선택된 사용자 지정 패치 기준선의 경우 보안 및 비보안 업데이트가 모두 적용됩니다.

  8. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

Oracle Linux

Oracle Linux 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.

  1. AWS-RunPatchBaseline 또는 AWS-RunPatchBaselineAssociation 문서에 대해 InstallOverrideList 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2~7단계를 건너뜁니다.

  2. 패치 기준에 지정된 대로 GlobalFilters를 적용하여 자격을 갖춘 패키지만 향후 프로세스에 사용되도록 유지됩니다.

  3. 패치 기준에 지정된 대로 ApprovalRules를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.

    그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 비보안 업데이트 포함(Include nonsecurity updates) 확인란을 선택했는지 여부에 따라 달라집니다.

    비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.

    비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.

  4. 패치 기준에 지정된 대로 ApprovedPatches를 적용합니다. 승인된 패치는 GlobalFilters를 통해 폐기되었거나 ApprovalRules에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.

  5. 패치 기준에 지정된 대로 RejectedPatches를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.

  6. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.

  7. 버전 7 관리형 노드에서 다음과 같이 YUM 업데이트 API가 승인된 패치에 적용됩니다.

    • AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 비보안 업데이트 포함 확인란이 선택되지 않은 사용자 지정 패치 기준선의 경우 updateinfo.xml에 지정한 패치만 적용됩니다(보안 업데이트만 해당).

      이 워크플로와 동등한 YUM 명령은 다음과 같습니다.

      sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y

    • 비보안 업데이트 포함 확인란을 선택한 사용자 지정 패치 기준선의 경우 updateinfo.xml에 포함된 패치 및 updateinfo.xml에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).

      이 워크플로와 동등한 YUM 명령은 다음과 같습니다.

      sudo yum update --security --bugfix -y

      버전 8 및 9 관리형 노드에서 다음과 같이 DNF 업데이트 API가 승인된 패치에 적용됩니다.

      • AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 비보안 업데이트 포함 확인란이 선택되지 않은 사용자 지정 패치 기준선의 경우 updateinfo.xml에 지정한 패치만 적용됩니다(보안 업데이트만 해당).

        이 워크플로와 동등한 YUM 명령은 다음과 같습니다.

        sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important

      • 비보안 업데이트 포함 확인란을 선택한 사용자 지정 패치 기준선의 경우 updateinfo.xml에 포함된 패치 및 updateinfo.xml에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).

        이 워크플로와 동등한 YUM 명령은 다음과 같습니다.

        sudo dnf upgrade --security --bugfix

  8. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

AlmaLinux, RHEL, and Rocky Linux

Red Hat Enterprise Linux 및 Rocky Linux 관리형 노드의 패치 설치 워크플로는 다음과 같습니다.

  1. AWS-RunPatchBaseline 또는 AWS-RunPatchBaselineAssociation 문서에 대해 InstallOverrideList 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2~7단계를 건너뜁니다.

  2. 패치 기준에 지정된 대로 GlobalFilters를 적용하여 자격을 갖춘 패키지만 향후 프로세스에 사용되도록 유지됩니다.

  3. 패치 기준에 지정된 대로 ApprovalRules를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.

    그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 비보안 업데이트 포함(Include nonsecurity updates) 확인란을 선택했는지 여부에 따라 달라집니다.

    비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.

    비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.

  4. 패치 기준에 지정된 대로 ApprovedPatches를 적용합니다. 승인된 패치는 GlobalFilters를 통해 폐기되었거나 ApprovalRules에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.

  5. 패치 기준에 지정된 대로 RejectedPatches를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.

  6. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.

  7. YUM 업데이트 API(RHEL 7의 경우) 또는 DNF 업데이트 API(AlmaLinux 8 및 9, RHEL 8 및 9, Rocky Linux 8 및 9의 경우)는 다음과 같이 승인된 패치에 적용됩니다.

    • AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 비보안 업데이트 포함 확인란이 선택되지 않은 사용자 지정 패치 기준선의 경우 updateinfo.xml에 지정한 패치만 적용됩니다(보안 업데이트만 해당).

      RHEL 7의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      AlmaLinux, RHEL 8 및 Rocky Linux의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y

    • 비보안 업데이트 포함 확인란을 선택한 사용자 지정 패치 기준선의 경우 updateinfo.xml에 포함된 패치 및 updateinfo.xml에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).

      RHEL 7의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.

      sudo yum update --security --bugfix -y

      AlmaLinux 8 및 9, RHEL 8 및 9 Rocky Linux 8 및 9의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.

      sudo dnf update --security --bugfix -y

  8. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

SLES

:SUSE Linux Enterprise Server(SLES) 관리형 노드, 패치 설치 워크플로는 다음과 같습니다.

  1. AWS-RunPatchBaseline 또는 AWS-RunPatchBaselineAssociation 문서에 대해 InstallOverrideList 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2~7단계를 건너뜁니다.

  2. 패치 기준에 지정된 대로 GlobalFilters를 적용하여 자격을 갖춘 패키지만 향후 프로세스에 사용되도록 유지됩니다.

  3. 패치 기준에 지정된 대로 ApprovalRules를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.

    그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 비보안 업데이트 포함(Include nonsecurity updates) 확인란을 선택했는지 여부에 따라 달라집니다.

    비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.

    비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.

  4. 패치 기준에 지정된 대로 ApprovedPatches를 적용합니다. 승인된 패치는 GlobalFilters를 통해 폐기되었거나 ApprovalRules에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.

  5. 패치 기준에 지정된 대로 RejectedPatches를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.

  6. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.

  7. Zypper 업데이트 API가 승인된 패치에 적용됩니다.

  8. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

Ubuntu 서버

Ubuntu Server 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.

  1. AWS-RunPatchBaseline 또는 AWS-RunPatchBaselineAssociation 문서에 대해 InstallOverrideList 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2~7단계를 건너뜁니다.

  2. python3-apt(libapt에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. ([비보안 업데이트 포함(Include nonsecurity updates)] 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)

  3. 패치 기준에 지정된 대로 GlobalFilters를 적용하여 자격을 갖춘 패키지만 향후 프로세스에 사용되도록 유지됩니다.

  4. 패치 기준에 지정된 대로 ApprovalRules를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.

    참고

    Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.

    그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 비보안 업데이트 포함(Include nonsecurity updates) 확인란을 선택했는지 여부에 따라 달라집니다.

    비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.

    비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.

    그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 [비보안 업데이트 포함(Include nonsecurity updates)] 확인란을 선택했는지 여부에 따라 달라집니다.

    참고

    Ubuntu Server의 각 버전에서 패치 후보 버전은 다음과 같이 해당 버전의 관련 리포지토리에 속하는 패치로 제한됩니다.

    • 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-lobster

  5. 패치 기준에 지정된 대로 ApprovedPatches를 적용합니다. 승인된 패치는 GlobalFilters를 통해 폐기되었거나 ApprovalRules에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.

  6. 패치 기준에 지정된 대로 RejectedPatches를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.

  7. APT 라이브러리가 사용되어 패키지가 업그레이드됩니다.

    참고

    Patch Manager에서는 APT Pin-Priority 옵션을 사용하여 패키지에 우선순위를 지정하는 기능을 지원하지 않습니다. Patch Manager에서는 활성화된 모든 리포지토리에서 사용 가능한 업데이트를 집계하고 설치된 각 패키지의 기준과 일치하는 최신 업데이트를 선택합니다.

  8. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

Windows Server

Windows Server 관리형 노드에서 패치 작업이 수행되는 경우 노드가 Systems Manager에서 해당되는 패치 기준 스냅샷을 요청합니다. 이 스냅샷에는 배포하도록 승인된 패치 기준에 있는 사용 가능한 모든 업데이트 목록이 들어 있습니다. 이 업데이트 목록이 Windows 업데이트 API로 전송되며, 여기서 관리형 노드에 적용 가능한 업데이트를 결정하고 필요 시 이를 설치합니다. Windows에서는 사용 가능한 최신 KB 버전만 설치할 수 있습니다. Patch Manager는 KB의 최신 버전 또는 KB의 이전 버전이 적용된 패치 기준과 일치하는 경우 KB의 최신 버전을 설치합니다. 업데이트가 설치되면, 필요한 모든 패치 적용 작업을 완료하기 위해 필요한 만큼 관리형 노드가 재부팅됩니다. (예외: AWS-RunPatchBaseline 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.) 패치 적용 작업에 대한 정보는 Run Command 요청의 결과에 요약되어 표시됩니다. 추가 로그는 %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs 폴더의 관리형 노드에서 찾을 수 있습니다.

KB를 다운로드하고 설치하는 데 Windows Update API가 사용되므로 Windows Update에 대한 모든 그룹 정책 설정이 유지됩니다. Patch Manager를 사용하는 데는 그룹 정책 설정이 필요하지 않지만, 관리형 노드가 Windows Server Update Services(WSUS) 서버로 향하도록 하는 것과 같은 정의된 설정은 적용됩니다.

참고

Patch Manager는 Windows Update API를 사용하여 KB의 다운로드 및 설치를 진행하므로 기본적으로 Windows는 Microsoft의 Windows Update 사이트로부터 모든 KB를 다운로드합니다. 따라서 관리형 노드에서 Microsoft Windows Update 사이트에 연결할 수 있어야 하며, 그렇지 않으면 패치가 적용되지 않습니다. 또는 WSUS 서버가 KB 리포지토리 역할을 수행하도록 구성하고, 관리형 노드가 그룹 정책을 사용하는 해당 WSUS 서버를 대상으로 지정하도록 구성할 수 있습니다.