패치 관리 모범 사례

솔루션 아키텍트로서 저는 종종 패치 관리를 위한 Red Hat의 모범 사례에 대한 질문을 받습니다. 이 글에서는 적절한 경우 관련 작업과 자료를 연결하여 정확한 모범 사례와 패치 관리 툴킷의 일부로 활용할 수 있는 툴을 중심으로 핵심 내용을 안내합니다.

이 문서를 읽고 나면 조직에 패치를 제공하기 위해 활용할 수 있는 툴 및 접근 방식과 해당 프로세스 정의와 관련된 모범 사례에 대해 더 명확하게 이해할 수 있습니다.

"모범 사례"라는 말은 조금 주관적입니다. 모든 조직에 적합한 것은 아닐 수 있으니까요. 따라서 하나의 방식을 "최적"이라고 부르기보다는 위험 수준별로 가장 적절하다는 의미에서 프로세스를 논의하는 것이 좋습니다. 패치 관리는 궁극적으로 위험 관리 또는 변경 관리에 관한 것입니다.

모든 조직에는 위험 해결 방식이 필요합니다. 그러나 이를 정의하는 방식, 중점을 두는 분야, 다양한 비즈니스 제약 조건, 영향 또는 결과를 평가하는 방식은 조직별로 달라야 합니다.

그런 면에서 "우수 사례"가 더 나은 표현일 듯 합니다. 예를 들어, 자동화 사례 커뮤니티는 현장에서 고객을 지원하면서 얻은 인사이트를 기반으로 자동화 우수 사례 문서를 게시합니다.

패치 관리 툴킷 및 접근 방식으로 활용할 수 있는 것은 무엇인가요?

인프라에서 패치를 관리하는 방법을 정의하는 툴과 방법론이 있습니다.

1. 정오표 정의

Red Hat은 코드 또는 콘텐츠 변경 사항(정오표)을 세 가지 범주로 분류합니다. 카테고리마다 목적과 변화 속도가 다릅니다. 조직의 목표와 변화 허용 범위에 따라 목표와 변화 속도에 더 적합한 옵션이 있을 수 있습니다.

• Red Hat Security Advisory(RHSA): 시스템을 보호하기 위해 긴급히 변경됨
• Red Hat Bug Advisory(RHBA): 사용자에게 영향을 미치거나 미치지 않을 수도 있는 버그 수정
• RHEA(Red Hat Enhancement Advisory): 새로운 기능이 추가됨

자세한 내용은 Red Hat의 보안 백포팅 사례와 백포팅의 정의, RHEL 및 기타 Red Hat 제품에 저굥되는 방식을 확인하세요.

이 원칙을 사용하면 유형 및 위험에 따라 정오표를 분리한 다음 필수 패치와 선택 사항으로 간주하는 패치를 선택할 수 있습니다. 

예를 들어, 인터넷에 연결된 인프라 또는 보안 프로파일이 높은 DMZ(완충 영역)가 있는 경우 해당 환경에서 릴리스될 때마다 Red Hat Security Advisory 정오표만 적용하도록 선택할 수 있습니다. 이렇게 하면 변경 사항을 작고 사용하기 쉬운 배치로 분할하는 동시에 고위험 인프라의 요구 사항을 해결할 수 있습니다. 

다음 링크는 패치 프로세스에서 보안 정오표만 적용하는 방법의 예입니다.

• 보안 업데이트만 나열하거나 설치하도록 yum을 제한할 수 있습니까?
• Red Hat Satellite에서 보안 정오표를 적용하는 방법

추가로 고려해야 할 접근 방식은 패키지의 하위 집합에 패치를 적용하여 변경 위험을 더욱 줄이는 것입니다. 또한 패치가 예기치 않게 시스템과 상호 작용하는 경우 롤백의 유연성을 허용합니다. 모든 접근 방식과 마찬가지로, 장단점에 유의해서 관리해야 합니다. 일부 사용자에게는 프로세스가 너무 세분화되어 있을 수 있지만, 변경 허용 범위에 더 적합하다고 보는 사용자도 있을 수 있습니다.

2. 표준 운영 환경(SOE)을 구축하기 위한 10단계

이 문서는 Red Hat Satellite 를 사용하여 표준 운영 환경을 활성화하고 관리하는 방법을 자세히 설명합니다. 모든 주제를 매우 자세히 다루며 모범 사례에 대한 가장 일반적인 질문의 답을 참고하기에 좋습니다. 이 내용은 몇 년 전 Red Hat Satellite 6가 처음 소개되었을 때 작성되었지만 기본 개념은 지금도 동일합니다.

콘텐츠 관리와 콘텐츠 스테이징은 패치 프로세스에서 가장 중요합니다. 이는 패치 콘텐츠가 인프라에 제공되는 방식의 기반을 마련하며, 위험 관리 및 위험 감소를 위한 패치 프로세스에서 중요한 역할을 합니다.

특히 Satellite의 라이프사이클 환경 및 콘텐츠 뷰에 중점을 둡니다. 이는 콘텐츠 스테이징과 인프라로의 승격(또는 롤백)에 중요한 개념입니다.

둘째, 인프라 및 인벤토리를 분류하기 위해 조직, 위치 및 호스트 그룹에 중점을 둡니다. 라이프사이클 환경 또는 콘텐츠 뷰를 지나치게 세분화하여 지리적 위치, 클라우드 환경, 유사한 인프라 또는 조직 내 여러 팀을 분류하는 문제 등을 해결하기 위해 이러한 구조를 사용하는 경우가 많습니다.

3. 실시간 커널 패치 적용

실시간 커널 패치 는 몇 년 전부터 제공되어 왔으며 여러 메이저 RHEL 릴리스에 포함되어 있습니다.   매우 신속하게 취약점을 해결하기 위해 재부팅 없이 커널에 실시간 패치를 적용할 수 있습니다. 이를 통해 관리자는 위험을 즉시 해결할 수 있으며 재부팅이 가능한 경우 더 적절한 유지 관리 일정을 예약할 수 있습니다. 

Red Hat Satellite를 통해 오케스트레이션할 수도 있습니다.

4. 업데이트 후 시스템 재부팅이 필요한 패키지 식별

업데이트 및 정오표 콘텐츠에 따라 패치 후 재부팅할 이유가 없을 수도 있습니다. 업데이트된 바이너리를 사용하기 위해 업데이트 후 서비스를 다시 시작하는 것만으로도 충분할 수 있습니다. 

RHEL 7부터 yum-utils에는 needs-restarting이라는 플러그인이 포함되어 있습니다. 이 유틸리티는 패치를 적용한 후 재부팅이 필요한지 여부를 보고합니다. 이를 통해 시스템 변경의 필요성을 이해하고 패치 적용 시 재부팅할 필요성을 줄일 수 있습니다.

Satellite에는 Tracer라는 기능도 있습니. Tracer는 Satellite 관점에서 동일한 작업을 수행하므로 시스템 패치 적용 후 관리자가 다시 시작해야 하는 애플리케이션을 식별할 수 있습니다.

5. 사전 예방적인 Red Hat 케이스 열기

특정 유지 관리 활동에 대한 고급 지식과 사전에 정보와 데이터를 수집할 수 있는 기회가 있으면 다운타임을 줄이고 패치 적용과 관련된 일부 위험을 줄일 수 있습니다.

사전 예방적 지원 케이스 열기로 서비스 복구에 필요한 문제 해결 시간을 크게 단축할 수 있을 뿐만 아니라 절차나 접근 방식을 미리 검토할 수도 있습니다. 이는 운영 중단 및 MTTR(평균 복구 시간) 메트릭을 줄이는 데 어느 정도 영향을 미칠 수 있습니다.

6. 자동화

수동 단계 를 자동화된 접근 방식으로 대체하면 인적 오류를 줄이고, 신뢰성을 높이며, 패치 프로세스 속도를 높일 수 있습니다. 자동화는 조직에 적합한 모범 사례를 도입하기 위한 핵심 차별화 요소입니다.

Red Hat Satellite에는 Ansible과 함께 원격 실행을 사용할 수 있는 기능이 있습니다. RHEL 인벤토리에서 Red Hat Satellite는 Ansible Playbook 및 Ansible Role을 실행할 수 있으며 패치 작업을 손쉽게 자동화하고 예약할 수 있습니다.

실제로 Red Hat Ansible Automation Platform에서 제공되는 공식 redhat.satellite Ansible 컬렉션을 사용하면 스테이징된 이후 패치 콘텐츠를 적용하는 것 외에도 Satellite의 전체 콘텐츠 관리 측면을 자동화하고 오케스트레이션할 수 있습니다.

뿐만 아니라 패치를 적용한 후 웹 서비스 기능 테스트 또는 서비스 검증에 대한 기능 테스트를 수행하는 데 사용할 수 있는 Ansible 모듈도 있습니다.

요약

Red Hat은 조직의 취약점 관리 방식에 대한 간결하면서도 포괄적인 방법론인 취약점 관리에 대한 개방형 접근 방식을 게시했습니다. 위험 관리는 비즈니스 제약 조건, 영향, 결과를  고려하고 평가한 후 결정해야 합니다.

문제는 모든 취약점이 정말로 중요한가입니다. 이 글에서는 제약 조건, 영향 및 결과의 평가와 관련된 몇 가지 실태와 장단점을 중점적으로 살펴봅니다. 이는 원하는 결과와 이를 달성하는 데 따른 비용 및 편익을 비교하는 좋은 예입니다. 모든 위험을 고려해야 하지만 모두 동일하게 평가할 수는 없으며, 각각의 위험을 모두 해결할 수 있는 무제한 리소스를 가진 사람도 없습니다. 이 예를 통해 중요도에 따른 우선순위를 정하고 완화하는 것이 좋은 위험과 부담 없이 감수할 수 있는 위험을 분류하는 전략을 수립하는 방법을 알 수 있습니다.

즉, 반복과 책임감이 필요합니다. 이 글에서 제시한 어떤 예도 전략을 한 번만 시도한 것은 아닙니다. Red Hat에 적합한 위험 관리 균형을 찾을 때까지 각각 수없이 검토하고 개선했습니다. 그리고 위의 방법은 새로운 내용을 배우고 업계 환경이 변화함에 따라 계속 개선되고 있습니다. 처음부터 접근 방식을 정의하는 것만큼 위험 허용 범위와 상태를 지속적으로 평가하는 것도 중요합니다. 지속적인 맞춤화와 개선을 통해 '최적의 상태'를 '모범 사례'에 적용할 수 있습니다.