패치를 관리하는 올바른 방법

제가 "시스템 관리 101" 기사 시리즈를 다시 계속하기로 그렇게 빨리 결정한 이유는 일부 Linux 시스템 관리자가 패치 관리에 있어서 Windows 시스템 관리자와 다르지 않다는 것을 깨달았기 때문입니다. 솔직히 말하면 일부 영역에서는 더 나쁩니다(특히 실행 시간에 자부심을 갖고 있음). 따라서 이 문서에서는 올바른 패치 관리의 모습, 사용할 수 있는 일부 관련 도구, 전체 패치 설치 프로세스가 수행되는 방법을 포함하여 Linux에서 패치 관리의 기본 개념을 다룰 것입니다.

패치 관리란 소프트웨어를 최신의 가장 뛰어난 버전으로 업데이트하는 것이 아니라 서버의 소프트웨어를 업그레이드하기 위해 배포하는 시스템을 의미합니다. "안정성"을 위해 특정 버전의 소프트웨어를 유지 관리하는 데비안과 같은 보수적인 배포판조차도 버그와 보안 허점을 수정하기 위해 수시로 업그레이드 패치를 출시합니다.

물론, 개발자가 가장 뛰어난 최신 버전이 필요하고 소프트웨어 소스 코드를 파생하여 수정해야 하거나 스스로 추가 작업을 수행하기를 원하기 때문에 조직에서 특정 소프트웨어의 자체 버전을 유지하기로 결정한 경우 그러면 문제에 봉착하게 됩니다. 이상적으로는 다른 소프트웨어에서 사용하는 것과 동일한 지속적인 통합 시스템을 사용하여 소프트웨어의 사용자 정의 버전을 자동으로 구축하고 패키징하도록 시스템을 구성해야 합니다. 그러나 많은 시스템 관리자는 위키의 (최신 버전이기를 바랍니다) 문서에 따라 로컬 호스트에서 소프트웨어를 패키징하는 오래된 방법을 여전히 사용하고 있습니다. 어떤 방법을 사용하든 사용 중인 버전에 보안 결함이 있는지 확인해야 하며, 그렇다면 사용자 정의된 소프트웨어 버전에 새 패치가 설치되어 있는지 확인해야 합니다.

패치 관리에서 가장 먼저 해야 할 일은 소프트웨어 업그레이드를 확인하는 것입니다. 우선 핵심 소프트웨어에 대해서는 해당 리눅스 배포판의 보안 메일링 리스트를 구독해야 해당 소프트웨어의 보안 업그레이드에 대해 최대한 빨리 알아볼 수 있다. 배포 저장소에서 제공되지 않은 소프트웨어를 사용하는 경우 해당 소프트웨어에 대한 보안 업데이트도 추적해야 합니다. 새 보안 알림을 받으면 알림 세부 정보를 검토하여 보안 취약성의 심각도를 확인하고 시스템이 영향을 받는지 여부와 보안 패치의 긴급성을 확인해야 합니다.

일부 조직에서는 여전히 수동 방법을 사용하여 패치를 관리합니다. 이렇듯 보안 패치가 나오면 시스템 관리자는 메모리에 의존해 각 서버에 로그인해 이를 확인해야 한다. 업그레이드해야 할 서버를 결정한 후 서버에 내장된 패키지 관리 도구를 사용하여 릴리스 저장소에서 해당 소프트웨어를 업그레이드하십시오. 마지막으로 나머지 서버도 모두 동일한 방식으로 업그레이드합니다.

패치를 수동으로 관리하는 방식에는 문제가 많습니다. 첫째, 그렇게 하면 패치를 더 많이 설치할수록 더 많은 인건비가 필요하고 시스템 관리자가 패치를 미루거나 아예 무시할 가능성도 커집니다. 둘째, 수동 관리는 시스템 관리자의 메모리에 의존하여 자신이 담당하는 서버의 업그레이드를 추적합니다. 이로 인해 일부 서버가 누락되거나 제때에 업그레이드되지 않을 수 있습니다.

패치 관리가 빠르고 쉬울수록 잘 할 확률이 높아집니다. 특정 소프트웨어를 실행하는 서버와 해당 소프트웨어의 버전 번호를 신속하게 쿼리할 수 있는 시스템을 구축해야 하며 이상적으로는 다양한 업그레이드 패치를 푸시할 수 있습니다. 개인적으로 저는 이 작업을 완료하기 위해 MCollective와 같은 오케스트레이션 도구를 사용하는 경향이 있지만 Red Hat에서 제공하는 Satellite와 Canonical에서 제공하는 Landscape를 사용하면 서버의 소프트웨어 버전 정보를 확인하고 통합 관리 인터페이스에 패치를 설치할 수 있습니다.

패치 설치도 내결함성이 있어야 합니다. 서비스를 오프라인으로 전환하지 않고도 서비스를 패치할 수 있어야 합니다. 시스템 재부팅이 필요한 커널 패치에도 동일하게 적용됩니다. 제가 채택한 방법은 서버를 서로 다른 고가용성 그룹으로 나누는 것입니다. 즉, 한 그룹에는 lb1, app1, Rabbitmq1 및 db1이 있고 다른 그룹에는 lb2, app2, Rabbitmq2 및 db2가 있습니다. 이렇게 하면 서비스를 오프라인으로 전환하지 않고도 한 번에 한 그룹씩 업그레이드할 수 있습니다.

그럼 빠르다는 건 얼마나 빠른 걸까요? 서비스와 함께 제공되지 않는 일부 소프트웨어의 경우 시스템에 몇 분에서 최대 한 시간 내에 패치를 설치할 수 있어야 합니다(예: bash의 ShellShock 취약점). 서비스를 다시 시작해야 하는 OpenSSL과 같은 소프트웨어의 경우 패치를 설치하고 내결함성 방식으로 서비스를 다시 시작하는 프로세스는 시간이 조금 더 걸릴 수 있지만 이때 오케스트레이션 도구가 유용합니다. MCollective에 대한 최근 기사(2016년 12월 및 2017년 1월 티켓 참조)에서 패치 관리를 위해 MCollective를 사용하는 몇 가지 예를 제시했습니다. 내결함성, 자동화된 방식으로 패치 설치 및 서비스 재시작을 단순화하는 시스템을 배포하는 것이 가장 좋습니다.

패치에 커널 패치처럼 시스템 재부팅이 필요한 경우 시간이 더 걸립니다. 다시 말하지만, 자동화 및 조정 도구는 이 프로세스를 생각보다 빠르게 만들 수 있습니다. 한두 시간 내에 프로덕션 서버를 내결함성으로 업그레이드하고 다시 시작할 수 있었으며, 다시 시작하는 사이에 클러스터 동기화 백업을 기다릴 필요가 없었기 때문에 프로세스가 훨씬 더 빨라졌습니다.

불행히도 많은 시스템 관리자는 긴급 커널 패치가 1년에 한 번 발생한다는 점을 감안할 때 여전히 가동 시간을 자부심의 상징으로 보는 구식 견해를 고수하고 있습니다. 나에게 이는 단지 시스템 보안을 심각하게 생각하지 않는다는 의미일 뿐입니다!

많은 조직에서는 여전히 일시적으로 오프라인 상태로 전환할 수 없는 단일 실패 지점인 서버를 사용하고 있으며 이러한 이유로 업그레이드하거나 다시 시작할 수 없습니다. 시스템의 보안을 강화하려면 오래된 수하물을 제거하고 최소한 심야 유지 관리 기간 동안 다시 시작할 수 있는 시스템을 구축해야 합니다.

기본적으로 빠르고 편리한 패치 관리는 성숙하고 전문적인 시스템 관리팀의 상징이기도 합니다. 소프트웨어 업그레이드는 모든 시스템 관리자에게 필요한 작업 중 하나입니다. 이 프로세스를 간단하고 빠르게 만드는 데 시간을 투자하면 시스템 보안 이상의 이점을 얻을 수 있습니다. 예를 들어 건축 설계에서 단일 실패 지점을 찾는 데 도움이 될 수 있습니다. 또한 환경에서 오래된 시스템을 식별하는 데 도움이 되며 이러한 부품을 교체할 인센티브를 제공합니다. 궁극적으로 패치 관리가 충분히 이루어지면 시스템 관리자의 시간이 확보되어 실제로 전문 지식이 필요한 영역에 집중할 수 있습니다.

Kyle Rankin은 수석 보안 및 인프라 설계자로서 적대적인 네트워크의 Linux 강화, DevOps 문제 해결 및 공식 Ubuntu 서버 책을 포함하고 있습니다. 그는 또한 Linux Journal의 칼럼니스트이기도 합니다.

위 내용은 패치를 관리하는 올바른 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!