기술 지원
문서
로그인
문의하기
TuxCare 블로그
엔터프라이즈 환경에서 일하는 시스템 관리자는 패치가 사실상 풀타임 업무라는 것을 알고 있습니다. 시스템 관리자는 패치가 사용 가능한지 확인하고, 다운타임이나 중단을 계획하고, 패치를 다운로드하고, 시스템에 패치를 배포하고, 시스템이 이전 상태로 복구되는지 확인해야 하는 등 시스템 하나만 패치하는 데 드는 노력을 생각해보십시오.
이는 한 대의 머신을 대상으로 하는 상당한 프로세스입니다. 엔터프라이즈 환경에서는 관리해야 할 서버가 수백 대에 달하므로 패치 작업은 하루 종일 책임져야 하는 일이 됩니다. 또한 패치를 설치한 후 재부팅에 실패할 위험도 상당합니다.
그렇기 때문에 시스템 관리자는 패치 관리 관점에서 패치를 생각해야 합니다. Linux 패치 관리에 대한 최종 가이드에서는 시스템 관리자가 자동화 도구를 사용하여 시간을 절약하고 패치를 구성하는 방법과 패치와 관련된 위험을 더 잘 관리하기 위해 시스템 관리 자가 할 수 있는 일을 설명합니다, 그리고 라이브 패치가 엔터프라이즈 패치의 판도를 바꾸는 도구인 이유를 설명합니다..
패치 관리가 패치 적용과 다른 점은 무엇인가요?
관리자는 시스템에서 시스템으로 또는 노드에서 노드로 이동하여 패치를 적용하는 등 Linux 시스템을 수동으로 간단히 패치할 수 있습니다. 그러나 인적 오류의 위험이 있으며 문제가 발생하면 패치를 롤백하기가 어려울 수 있습니다.
패치가 잘못되면 가동 중단 시간이 길어질 수 있으며 수동으로 패치를 적용하는 데도 많은 시간이 소요될 수 있습니다.
패치 관리는 전체 프로세스를 자동화하여 관리자에게 도움이 됩니다. 패치 관리 시스템을 워크플로에 통합하면 업데이트를 자동으로 감지하고 다운로드한 다음 모든 서버에 배포할 수 있습니다.
시스템 관리자는 라이브 패치를 배포하여 자동화를 한 단계 더 발전시킬 수 있으며, 이를 통해 일반적으로 Linux 업데이트 후 필요한 재부팅 프로세스를 없앨 수 있습니다. 이 섹션에서는 라이브 패치에 대해 설명합니다.
패치 관리가 중요한 이유는 무엇인가요?
패치가 적용되지 않은 공용 웹 서버는 사이버 보안에 있어 중요한 문제이지만, 사이버 보안만이 Linux를 패치해야 하는 유일한 이유는 아닙니다. 패치는 버그를 수정하고 새로운 기능을 추가하는 역할도 합니다. 대규모 업데이트는 운영 체제에 중요한 기능을 추가할 수 있으며 장기적으로 애플리케이션 호환성을 유지하기 위해 필요할 수 있습니다.
패치가 적용되지 않으면 패치가 쌓이게 됩니다. 관리자가 시스템 패치를 기다리는 시간이 길어질수록 시스템을 최신 상태로 유지하기 위해 더 많은 패치 작업이 필요합니다. 이는 Linux 서버를 완전히 패치하는 데 걸리는 시간을 늘리고 문제가 발생할 위험을 가중시킵니다.
공급업체와 배포판 개발자가 제공하는 핫픽스는 가장 중요한 패치가므로 즉시 적용해야 합니다. 핫픽스는 운영 체제 내의 중요한 문제를 해결하므로 우선순위가 정해져 있습니다.
패치 관리는 얼마나 자주 수행해야 하나요?
패치 관리는 가끔 하는 작업이 아닙니다. 패치 관리는 1년 중 거의 매일 시스템 관리자가 쉬지 않고 지속적으로 활동해야 합니다. 그럼에도 불구하고 일부 패치는 즉시 적용해야 하는 반면, 다른 패치는 패치를 배포하기 전에 보다 광범위한 테스트 프로세스를 거쳐야 할 수 있습니다.
중요한 보안 패치가 릴리스되면 관리자는 가능한 한 빨리 패치를 테스트하고 배포하는 것이 중요합니다.
제로데이 취약점은 조직과 디지털 자산에 대한 실질적인 위협입니다. 제로데이 취약점이 발표되면 위협 행위자는 패치되지 않은 시스템을 악용하기 위해 신속하게 익스플로잇을 만듭니다. 패치되지 않은 취약점은 공격자가 기업 시스템에 침입할 방법을 찾는 일반적인 방법이며 랜섬웨어 그룹이 사용하는 가장 일반적인 공격 벡터입니다..
데이터 유출 위험을 낮추려면 조직은 보안 패치가 출시되는 즉시 신속하게 배포해야 합니다.
기능 업데이트 및 덜 중요한 보안 수정의 경우 스테이징 환경에서 철저한 테스트를 거친 후 패치를 적용해야 합니다. 스테이징 환경은 프로덕션 환경의 복제본으로 테스트 중에 1:1로 일치하는지 확인해야 하며, 그렇지 않으면 오류로 인해 프로덕션에서 다운타임이 발생할 수 있습니다. 테스트도 중요하지만, 공급업체가 패치를 제공한 후 30일 이내에 패치를 적용하는 것이 좋은 경험 법칙입니다.
대규모 엔터프라이즈 환경에서는 매일 새로운 업데이트가 출시되는 경우가 많기 때문에 지속적인 테스트와 배포가 필요합니다. 매일 새로운 패치를 수동으로 확인하는 것은 지루한 일이므로 패치 관리 자동화가 필요합니다.
패치할 때 발생할 수 있는 일반적인 문제
패치는 중요한 활동이지만 몇 가지 함정이 있습니다. Linux 패치 관리 전략을 수립할 때 몇 가지 일반적인 패치 관리 함정을 염두에 두는 것이 좋습니다(다음 섹션에서 설명할 예정임):
재부팅으로 인한 운영 중단라이브 패치를 사용하지 않는 경우 재부팅이 운영에 미치는 영향에 대해 알고 있어야 합니다. 즉, 유지 보수 기간을 예약하거나 고가용성의 경우 고가용성 시스템이 이미 과도하게 확장되지 않은 사용량이 적은 시간대에만 패치를 수행해야 합니다.
패치된 머신은 이전 상태로 돌아가지 않습니다.: 마찬가지로 시스템을 재부팅하면 단순히 시작만 하고 중단된 부분부터 계속 진행되지 않을 위험이 있으므로 이전 상태로 다시 간호할 준비가 필요합니다. 이러한 위험을 완화하는 한 가지 방법은 취약점을 최소화하고 패치 전후의 안정성을 보장하도록 시스템을 구성하는 Linux 강화입니다. 관리자는 보안 모범 사례와 시스템 최적화를 구현함으로써 업데이트 후 예기치 않은 장애가 발생할 가능성을 줄일 수 있습니다.
직원 리소스 부족최선의 계획을 세워도 엄청난 양의 업데이트와 패치가 부담스러울 수 있습니다. 가능한 한 자동화를 우선순위에 두고 활용하는 것이 핵심입니다.
소프트웨어의 큰 변경 사항기존 기능을 중단시킬 수 있는 대규모 업데이트에 유의하세요. 업데이트가 철저한 테스트를 거쳤다고 하더라도 업데이트 규모가 클수록 기업 전체에 업데이트를 배포할 때 더 많은 주의와 관심을 기울여야 합니다.
업데이트에 버그가 있을 수 있습니다.중요한 보안 패치를 제외하고는 배포하기 전에 항상 업데이트를 테스트해야 하지만, 엄격한 테스트를 거친 후에도 장기적으로 업데이트에 버그가 있을 수 있는 위험이 있습니다.
패치가 리소스 사용에 미치는 영향패치로 인해 새로운 기능이 너무 많이 추가되고 시스템 작동 방식이 변경되어 일상적인 작업에 훨씬 더 많은 리소스가 소모되는 경우가 있습니다. 이는 테스트 중에 드러나지 않아 작업 속도가 느려질 수 있습니다.
패치 적용 시 발생할 수 있는 몇 가지 일반적인 문제를 방지하려면 Linux 패치 관리 전략을 수립하고 패치 관리 모범 사례를 따라야 합니다.
Linux 패치 관리 전략이란 무엇인가요?
패치 자동화는 핵심 도구이지만 패치를 시작하기 전에 패치 관리 전략에 대해 이야기할 필요가 있습니다.
Windows와 같은 폐쇄형 소스 운영체제와 달리 Linux는 패치가 예측하기 어렵고 복잡할 수 있습니다. 오픈 소스에는 장점이 있지만 다양한 기여자에 의해 변경이 이루어지는 운영 체제를 운영한다는 단점이 있습니다. 호환되지 않는 변경 사항 하나만 있어도 조직 전체에 영향을 미칠 수 있습니다.
패치 관리가 제대로 이루어지지 않을 때 발생하는 번거로움과 오버헤드를 줄이기 위해 절차에 적용할 수 있는 몇 가지 전략과 모범 사례를 소개합니다:
패치 관리 정책 만들기: 이 정책에는 품질 보증(QA) 테스트, 패치 적용 빈도, 롤백 절차, 운영 체제 변경에 대한 결재권자 등 모든 단계가 포함되어야 합니다.
스캐닝 도구를 사용하여 취약점 찾기: 공용 서버든 기업 애플리케이션을 실행하는 내부 호스트든 취약점 스캔은 패치되지 않은 시스템을 찾아 일반적인 익스플로잇을 방지하는 데 도움이 됩니다.
리포팅을 사용하여 패치 실패 식별: 패치가 성공적으로 설치되었는지 어떻게 알 수 있나요? 좋은 패치 관리 솔루션은 패치 설치 성공 및 실패에 대한 보고서를 표시하는 중앙 대시보드를 제공하여 관리자가 패치를 검토하고 필요한 경우 수동으로 적용할 수 있도록 합니다.
테스트가 완료되는 즉시 패치 배포: 배포 전 테스트도 중요하지만, 테스트에서 배포에 대한 청신호가 켜지면 전체 환경에 패치를 설치해야 합니다.
환경 변경 사항 문서화: 일반적으로 문서화는 권한이 있는 직원이 환경 업데이트에 대해 서명하는 변경 제어의 형태로 이루어집니다. 이 단계는 다운타임을 검토하고 근본 원인 분석을 수행할 때 중요합니다. 감사 및 규정 준수 측면에서도 중요합니다.
위의 목록은 패치 관리 전략의 출발점이 될 것입니다. 이러한 전략을 적용할 때 Linux 환경 전반에 걸쳐 포괄적인 보호를 보장하기 위해 패치 및 취약성 관리 모범 사례도 고려해야 합니다.
패치 적용 모범 사례
SANS(시스템 관리자, 감사, 네트워크 및 보안) 조직은 다음을 위한 좋은 출처입니다. 모범 사례 의 좋은 소스입니다. SANS 모범 사례 가이드라인은 관리자에게 조직 전반의 위험을 문서화, 감사 및 평가하여 패치를 배포해야 하는 시기와 방법을 결정하는 기업 정책을 구현하는 방법에 대한 로드맵을 제공합니다. 8가지 SANS 모범 사례 권장 사항은 다음과 같습니다:
환경 인벤토리 관리: 포괄적으로 패치를 적용하려면 어떤 패치가 필요한지 알아야 하므로 네트워크의 모든 Linux 시스템에 대한 감사 목록을 작성해야 합니다.
각 서버에 위험 수준 할당: 위험 수준은 관리자에게 가장 중요하고 우선순위를 정해야 하는 서버를 알려줍니다. 모든 시스템을 패치해야 하지만 가장 중요한 서버를 대상으로 하면 테스트 및 기타 패치 작업이 진행되는 동안 서버가 손상될 위험을 줄일 수 있습니다.
하나의 솔루션으로 패치 관리 소프트웨어 통합: 자동화 도구는 유용하지만 환경을 변경하는 도구가 너무 많으면 오류가 발생하고 경쟁 상황이 발생할 수 있습니다.
공급업체 패치 발표 검토 정기적으로: 자동화 도구는 자동으로 업데이트를 다운로드하지만 관리자는 새로운 패치, 특히 중요한 패치가 언제 제공되는지 파악하기 위해 계속 주의를 기울여야 합니다.
패치 실패 위험 완화: 예외 문제로 인해 관리자가 업데이트를 중단하는 경우가 종종 있습니다. 이런 일이 발생하면 가능한 경우 서버를 잠가 악용 가능성을 제한해야 합니다.
항상 스테이징 단계에서 패치를 먼저 테스트하세요.: 스테이징 환경은 프로덕션을 복제하여 패치를 테스트하고 다운타임의 위험을 낮출 수 있도록 해야 합니다.
가능한 한 신속하게 시스템 패치: 서버가 패치되지 않은 상태로 오래 유지될수록 알려진 취약점으로 인한 침해 위험이 커집니다.
자동화 도구 사용: 자동화 도구는 관리자의 수고를 덜어주고 패치를 사용할 수 있을 때 자동으로 배포합니다.
관련 읽기: 더 빠른 패치 관리로 규정 준수 지원
자동화된 Linux 패치 관리 소프트웨어는 어떻게 작동하나요?
자동화된 패치 관리는 여러 계층에서 작동하며, 취약성 스캔은 그 중 하나입니다. 뉴스에 나올 만한 데이터 유출 사고가 발생하지 않으려면 조직은 모든 디바이스에서 취약성 검사를 수행해야 합니다.
취약점 스캔은 패치가 누락되었는지 확인하여 관리자가 가능한 한 빨리 패치를 배포할 수 있도록 합니다. 이 첫 단계를 훨씬 더 효율적이고 편리하게 수행할 수 있는 몇 가지 좋은 취약성 스캐너가 있습니다. 이러한 스캐너는 다음과 같습니다:
스캔이 완료되면 이제 패치 관리 도구가 그 역할을 대신할 차례입니다. 시중에 나와 있는 여러 도구를 사용하면 관리자가 훨씬 더 편리하게 패치를 적용할 수 있습니다.
더 나은 도구는 성공 및 실패한 패치를 보고하여 관리자가 수동 업데이트가 필요한 시기를 알 수 있도록 합니다. 따라서 패치 관리 도구는 기업 환경의 현재 사이버 보안 상태에 대한 포괄적인 업데이트를 제공합니다. 패치를 관리하는 데 사용할 수 있는 몇 가지 도구는 다음과 같습니다:
위 도구의 주요 장점은 업데이트를 다운로드한 다음 관리자에게 결과를 보고하기 때문에 정리가 간편하다는 점입니다. 이 과정에서 올바른 도구를 사용하면 대규모 환경에서 패치 관리를 처리할 때 발생할 수 있는 혼란을 최소화할 수 있습니다.
또한 관리자는 패치를 예약하고, 자체 배포 정책을 선택하고, 테스트한 다음 배포 전에 업데이트를 승인할 수 있습니다.
라이브 패치는 패치 관리 프레임워크에 어떻게 적용되나요?
패치 관리 도구는 관리자에게 향상된 관리 기능을 제공하지만 재부팅은 여전히 주요 문제입니다. 중요한 Linux 서버를 재부팅한다는 것은 조직의 시스템 다운타임을 의미하며, 이러한 다운타임을 어떻게든 처리해야 합니다.
여기에는 고가용성(패치는 여전히 성능에 영향을 미치지만) 또는 유지 보수 기간을 예약하고 사용량이 적은 시간대에 패치를 예약하는 방법이 포함될 수 있습니다. 즉, 패치를 편리한 시간까지 연기할 수 있으므로 패치가 적용되지 않은 서버는 더 오랫동안 취약한 상태로 남게 됩니다. 실시간 패치는 재부팅 프로세스를 제거하여 전체 프로세스를 개선합니다.
재부팅을 없애면 재부팅에 내재된 위험을 줄이는 등 몇 가지 다른 측면에서도 도움이 됩니다. 시스템이 재시작되지 않으면 어떻게 하나요? 패치를 적용하고 동시에 재부팅해야 하는 중요한 서버가 여러 대 있다면 어떻게 해야 할까요?
시스템 관리자는 전체 조직을 지원하는 여러 중요 서버에 취약점에 대한 긴급 패치가 필요할 수 있으며, 여러 중요 서버가 원활하게 재시작되지 않을 위험이 있습니다. 실시간 패치를 사용하면 이러한 위험이 제거됩니다.
KernelCare는 패치 관리 도구와 함께 작동하나요?
KernelCare는 기존 패치 관리 솔루션에 통합되는 Linux 라이브 패치 도구입니다. 패치는 여전히 패치 관리 도구에서 예약, 테스트, 다운로드 및 배포됩니다. 하지만 KernelCare는 라이브 패치 기능을 추가하고 재부팅 요구 사항을 제거합니다.
KernelCare 라이브 패치는 간단한 4단계로 작동합니다:
- Kernel 메모리를 할당하고 새 보안 코드를 메모리에 로드합니다.
- 안전 모드에서 모든 프로세스를 일시적으로 정지합니다.
- 기능을 수정하고 새로운 보안 코드로 이동하여 취약점을 차단합니다.
- 프로세스 고정을 해제하고 활동을 재개합니다.
패치를 적용하기 위해 패치 대상 컴퓨터를 재시작할 필요가 없다는 점이 가장 큰 장점입니다. KernelCare 라이브 패칭을 사용하면 시스템 관리자의 개입 없이도 중단 없이 업데이트된 코드가 원활하게 적용됩니다.
앞서 언급한 패치 도구(예: Ansible, Puppet, Chef, SaltStack)를 사용하는 경우 동일한 도구를 사용하여 KernelCare를 배포할 수 있으므로 각 서버에 KernelCare를 수동으로 설치할 필요가 없습니다. 관리자는 이러한 도구를 사용하면 다음과 같이 할 수 있습니다:
- KernelCare 에이전트 패키지 배포(서버가 인터넷에 액세스할 수 없는 경우에만 필요)
- KernelCare 에이전트 구성 파일 /etc/sysconfig/kcare/kcare.conf를 배포합니다.
- 환경 변수 설정
- 로컬 또는 원격 다운로드 서버에서 KernelCare 에이전트를 설치합니다.
- 키 기반 또는 IP 기반 라이선스로 KernelCare 등록하기
현재 패치 배포 애플리케이션에 쉽게 배포 및 통합할 수 있을 뿐만 아니라, KernelCare는 서버의 취약점을 조사하는 취약성 스캐너에 "안전한 Kernel" 보고서를 전송합니다.
KernelCare를 사용하면 재부팅할 필요 없이 Linux 서버에 자동으로 패치가 적용되며, 취약성 스캐너가 서버가 업데이트되어 취약성 패치가 최신 상태임을 알려줍니다.
Linux 시스템을 수동으로 패치하는 방법?
패치 자동화와 실시간 패치가 적용되어 있더라도 수동 업데이트가 필요한 경우가 있습니다. 예를 들어 업데이트에 실패한 후 관리자가 시스템을 수동으로 패치해야 할 수 있습니다. 테스트 환경에서도 수동 업데이트가 필요할 수 있습니다. Linux를 업데이트하는 명령은 배포판에 따라 다르지만 다음은 몇 가지 일반적인 배포판에 대한 명령입니다.
데비안 기반 배포판(예: 데비안, Ubuntu, 민트)의 경우 다음 명령은 사용 가능한 패치와 업데이트 패키지 및 운영 체제를 표시합니다:
sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade
Red Hat Linux 배포판(예: RedHat, CentOS, Oracle)의 경우 다음 명령으로 업데이트를 확인하고 시스템을 패치할 수 있습니다:
yum 확인 업데이트 yum 업데이트
SUSE 기반 Linux(예: Suse Linux Enterprise, OpenSuse)의 경우 다음 명령으로 업데이트를 확인하고 시스템을 패치할 수 있습니다:
zypper 점검 업데이트 자이퍼 업데이트
수명이 다한 Linux 처리
일부 서버룸에는 코끼리가 있습니다. 지원되지 않거나 Lifecycle이 다한 운영 체제라고 불리는 이 코끼리는 아무리 좋은 패치 관리 전략도 순식간에 무너뜨릴 수 있는 존재입니다.
지원되지 않는 운영체제는 새로 발견된 보안 취약점에 대한 패치를 더 이상 제공받지 못합니다. 패치가 없으면 자동 패치가 적용되어 있는 경우에도 중요한 취약점으로부터 시스템을 보호할 방법이 없습니다. 사용자 지정 패치를 개발하는 것은 어렵고 비용이 많이 드는 솔루션입니다.
기업에서 Lifecycle이 다한 운영 체제를 운영하는 이유는 무엇일까요? 지원되는 버전으로 업그레이드하는 데 필요한 조치를 취하지 않은 시스템 관리팀의 부주의로 인한 것일 수도 있습니다. 그러나 대부분의 경우 최신 OS에서 작동하지 않는 특정 소프트웨어가 있거나 시스템 관리자 팀에 심각한 압박이 가해져 업그레이드를 수행할 수 없는 등 실용적인 문제인 경우가 많습니다.
다행히도 수명이 다한 운영 체제에도 패치 관리 전략을 적용할 수 있는 방법이 있습니다. Linux 공급업체의 연장 지원 플랜에 가입할 수도 있지만, 비용이 많이 들고 불필요한 기능이 포함될 수 있습니다.
TuxCare의 다양한 수명 주기 연장 지원 서비스 는 더 이상 공식적으로 지원되지 않는 Linux 배포판에 대한 보다 합리적인 대안입니다. 지원되지 않는 여러 Linux 배포판에 대한 최대 4년의 보안 업데이트는 물론 PHP 및 Python과 같은 코딩 언어도 제공합니다.
결론
일관된 패치는 매우 중요하지만 제대로 적용하기는 어렵습니다. 재부팅이 방해가 되고 제한된 리소스로 인해 패치 작업이 중단될 수 있습니다. 그럼에도 불구하고 Linux 패치 관리는 엔터프라이즈 컴퓨팅 환경을 안전하게 유지하는 데 핵심적인 역할을 합니다.
패치 관리를 제대로 하려면 패치 관리 모범 사례를 따르는 전략적 접근 방식이 필요하며, 동시에 최고의 도구를 사용하여 작업을 수행해야 합니다.
KernelCare를 패치 관리에 통합하면 위험을 줄이고 Linux 서버의 보안을 개선하며 관리자에게 편리함을 제공합니다. 또한 KernelCare는 현재 패치 프로세스와 원활하게 작동하여 재부팅 없이 업데이트를 도입할 수 있습니다.
6년 이상 재부팅하지 않은 서버를 보유한 고객도 있습니다. 전 세계 주요 데이터센터에 있는 30만 대 이상의 지원 서버가 KernelCare 덕분에 실시간 패치 프레임워크를 통해 SOC 2 규정 준수 상태를 유지하고 있습니다.
시도 KernelCare 를 지금 사용해 보세요. Linux 패치 관리 전략을 유지하고 관리자의 많은 오버헤드와 시간 소모적인 프로세스를 줄일 수 있습니다.
