대체 패치 소스 리포지토리를 지정하는 방법(Linux)
패치 작업에 대해 관리형 노드에 구성된 기본 리포지토리를 사용하는 경우 AWS Systems Manager의 기능인 Patch Manager는 보안 관련 패치를 찾거나 설치합니다. 이는 Patch Manager의 기본 동작입니다. Patch Manager가 보안 패치를 선택 및 설치하는 방법에 대한 모든 정보는 보안 패치 선택 방법 섹션을 참조하세요.
그러나 Linux 시스템에서는 Patch Manager를 사용하여 보안과 관련되지 않은 패치 또는 관리형 노드에 구성된 기본 소스 리포지토리가 아닌 다른 소스 리포지토리에 있는 패치를 설치할 수도 있습니다. 사용자 지정 패치 기준을 만들 때 대체 패치 소스 리포지토리를 지정할 수 있습니다. 각 사용자 지정 패치 기준에서 지원되는 최대 20개의 Linux 운영 체제 버전에 대해 패치 소스 구성을 지정할 수 있습니다.
예를 들어, Ubuntu Server 플릿에 Ubuntu Server 14.04 및 Ubuntu Server 16.04 관리형 노두가 모두 포함된다고 가정해 보겠습니다. 이 경우, 동일한 사용자 지정 패치 기준으로 각 버전에 대체 리포지토리를 지정할 수 있습니다. 각 버전에 대해 이름을 입력하고, 운영 체제 버전 유형(제품)을 지정하고, 리포지토리 구성을 제공합니다. 또한 지원되는 모든 운영 체제 버전에 적용되는 단일의 대체 소스 리포지토리를 지정할 수도 있습니다.
참고
관리형 노드에 대한 대체 패치 리포지토리를 지정하는 사용자 정의 패치 기준을 실행해도 해당 리포지토리가 운영체제의 새 기본 리포지토리로 지정되지 않습니다. 패치 작업이 완료된 후 이전에 노드의 운영체제에서 기본값으로 구성된 리포지토리는 기본값으로 유지됩니다.
이 옵션 사용에 대한 예제 시나리오 목록은 이 주제 후반부의 대체 패치 소스 리포지토리의 사용 샘플 섹션을 참조하세요.
기본 및 사용자 지정 패치 기준에 대한 자세한 내용은 미리 정의된 패치 및 사용자 지정 패치 기준 정보 섹션을 참조하세요.
예: 콘솔 사용
Systems Manager 콘솔에서 작업 중인 경우 대체 패치 소스 리포지토리를 지정하려면 패치 기준 생성(Create patch baseline) 페이지의 패치 소스(Patch sources) 섹션을 사용합니다. 패치 소스(Patch sources) 옵션 사용에 대한 자세한 내용은 사용자 정의 패치 기준 생성(Linux) 섹션을 참조하세요.
예: AWS CLI 사용
AWS Command Line Interface(AWS CLI)와 함께 --sources 옵션을 사용하는 예는 다른 OS 버전에 대한 사용자 지정 리포지토리가 있는 패치 기준 생성 섹션을 참조하세요.
대체 리포지토리에 대한 중요 고려 사항
대체 패치 리포지토리를 사용하여 대치 전략을 계획할 경우 다음 사항에 유의하십시오.
지정된 리포지토리만 패치를 적용하는 데 사용됩니다.
대체 리포지토리를 지정하는 것이 추가 리포지토리를 지정하는 것을 의미하지는 않습니다. 관리형 노드에 대해 기본으로 구성되지 않은 리포지토리를 지정할 수 있습니다. 하지만 업데이트를 적용하려면 기본 리포지토리도 대체 패치 소스 구성의 일부로 지정해야 합니다.
예를 들어 Amazon Linux 2 관리형 노드의 기본 리포지토리는 amzn2-core 및 amzn2extra-docker입니다. 패치 적용 작업에 EPEL(Extra Packages for Enterprise Linux) 리포지토리를 포함하려면 세 리포지토리를 모두 대체 리포지토리로 지정해야 합니다.
참고
관리형 노드에 대한 대체 패치 리포지토리를 지정하는 사용자 정의 패치 기준을 실행해도 해당 리포지토리가 운영체제의 새 기본 리포지토리로 지정되지 않습니다. 패치 작업이 완료된 후 이전에 노드의 운영체제에서 기본값으로 구성된 리포지토리는 기본값으로 유지됩니다.
YUM 기반 배포에 대한 패치 동작은 updateinfo.xml 매니페스트에 따라 다릅니다.
YUM 기반 배포(예: Amazon Linux 1 또는 Amazon Linux 2, Red Hat Enterprise Linux 또는 CentOS)에 대해 대체 패치 리포지토리를 지정할 경우 패치 동작은 완전하고 올바른 형식의 updateinfo.xml 파일 형태의 업데이트 매니페스트가 리포지토리에 포함되는지 여부에 따라 달라집니다. 이 파일은 다양한 패키지의 릴리스 날짜, 분류 및 심각도를 지정합니다. 패치 동작에 영향을 주는 항목은 다음과 같습니다.
-
분류(Classification)와 심각도(Severity)를 기준으로 필터링하지만
updateinfo.xml에 지정되어 있지 않은 경우 해당 패키지는 필터에 포함되지 않습니다. 즉,updateinfo.xml파일이 없는 패키지는 패치에 포함되지 않습니다. -
ApprovalAfterDays를 기준으로 필터링하지만 패키지 릴리스 날짜가 Unix Epoch 형식이 아니거나 릴리스 날짜가 지정되지 않은 경우 해당 패키지는 필터에 포함되지 않습니다.
-
패치 기준선 생성 페이지에서 비보안 업데이트 포함 확인란을 선택한 경우는 예외입니다. 이 경우
updateinfo.xml파일이 없거나 적절하게 서식 지정된 분류(Classification), 보안(Severity) 및 날짜(Date) 값이 없는 이 파일을 포함하는 패키지는 사전 필터링된 패치 목록에 포함됩니다. 이 경우에도 설치를 위한 다른 패치 기준 규칙 요건을 충족해야 합니다.
대체 패치 소스 리포지토리의 사용 샘플
예제 1 - Ubuntu Server에 대한 비보안 업데이트
이미 Patch Manager를 사용하여 AWS에서 제공하는 미리 정의된 패치 기준인 AWS-UbuntuDefaultPatchBaseline을 사용하는 Ubuntu Server 관리형 노드의 플릿에 보안 패치를 설치했습니다. 이 기본 패치 기준을 기반으로 하는 새 패치 기준을 생성하되, 승인 규칙에서 기본 배포의 일부인 비보안 관련 업데이트도 설치하도록 지정할 수 있습니다. 이 패치 기준이 노드에 대해 실행될 때 보안 및 비보안 문제에 대한 패치가 적용됩니다. 또한 기준에 대해 지정하는 패치 예외의 비보안 패치를 승인할 수도 있습니다.
예제 2 - Ubuntu Server의 PPA(Personal Package Archives)
Ubuntu Server 관리형 노드가 Ubuntu의 PPA(Personal Package Archives)
예제 3 - Amazon Linux의 사내 애플리케이션
Amazon Linux 관리형 노드에서 산업 규정 준수에 필요한 애플리케이션을 실행해야 합니다. 노드에 이러한 애플리케이션의 리포지토리를 구성하거나, YUM을 사용하여 애플리케이션을 처음 설치한 후 업데이트하거나, 이 새로운 기업 리포지토리를 포함하도록 새 패치 기준을 생성할 수 있습니다. 그런 다음 Run Command를 사용하여 Scan 옵션으로 AWS-RunPatchBaseline 문서를 실행하여 기업 패키지가 설치된 패키지로 나열되고 관리형 노드에서 최신 상태인지 확인할 수 있습니다. 최신이 아닌 경우 애플리케이션을 업데이트하도록 Install 옵션을 사용하여 문서를 다시 실행하면 됩니다.
