ClickCease 재부팅할 것인가, 재부팅하지 않을 것인가? 많은 시스템 관리자가 궁금해하는 질문 - TuxCare

인기 뉴스레터 구독하기

4,500명 이상의 Linux 및 오픈소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.

재부팅할 것인가, 재부팅하지 않을 것인가? 많은 시스템 관리자가 궁금해하는 질문입니다.

2020년 11월 12일 TuxCare 홍보팀

재부팅할 것인가, 재부팅하지 않을 것인가? 많은 시스템 관리자가 궁금해하는 질문입니다.서버 재부팅 주기는 조직에서 여러 대의 서버를 재부팅하는 프로세스를 통칭하는 이름입니다. 이는 여러 가지 요인으로 인해 발생할 수 있지만, 패치와 업데이트가 운영 체제의 중요한 구성 요소를 대상으로 하거나 여러 구성 요소나 프로그램에서 사용하는 공유 라이브러리를 대상으로 하는 경우 재부팅이 필요한 경우가 많습니다. 재부팅할 서버의 수는 작업 기간과 관련 위험에 직접적인 영향을 미칩니다. 업데이트해야 하는 서버가 많을수록 계획 및 실행 프로세스가 더 어려워집니다.

이러한 보안 업데이트를 재부팅 없이 처리할 수 있는 방법을 기업에 제공하기 위해 라이브 패치가 만들어졌습니다. 이 방법의 가장 큰 장점은 재부팅이 필요하지 않으므로 일반적인 패치 주기 작업을 60%까지 줄일 수 있다는 것입니다. 그럼에도 불구하고 많은 기업이 라이브 패치 방식이 아닌 재부팅 주기로 작업하고 있습니다. 그 이유가 있을까요? 여기서는 그 문제를 살펴보겠습니다.

콘텐츠:

  1. 업데이트에 따른 위험. 업데이트하지 않을 경우의 위험:
    Equifax: 주의 사례
    라이브 패치로 시스템 속도가 느려지나요?
  2. 재부팅 대 재부팅 없음
  3. 승자: 재부팅 없이 경로 설정
  4. 결론

 

업데이트 시 위험. 업데이트하지 않을 경우의 위험.

업데이트 시 위험. 업데이트하지 않을 경우의 위험.

Kernel을 업데이트할 때는 항상 새로운 잠재적 위험 새로운 잠재적 위험이 수반되기 때문에 아직 라이브 패치 업데이트를 수용하지 않는 곳도 있습니다. 서버가 이미 안정적이고 속도가 적당하며 새로운 기능이 필요하지 않은 경우 패치를 적용하는 데 필요한 서버 다운타임의 위험을 감수하고 싶지 않을 수 있습니다. 이러한 이유로 패치를 적용하지 않는 것이 지극히 합리적인 것처럼 보일 수 있지만, 이러한 이유가 하나 이상 있더라도 반드시 패치를 적용해야 하는 한 가지 이유가 있습니다: 바로 보안입니다.

새로운 Kernel 패치가 발표되자마자 해커들은 패치되는 취약점을 악용할 방법을 찾기 시작합니다. 해당 패치를 업데이트하지 않으면 해커가 시스템에 침입할 수 있는 백도어를 항상 열어두게 됩니다. 이것이 바로 하트블리드 취약점을 악용하는 해커가 여전히 발견되는 하트블리드 취약점을 악용하는 해커들이 2014년에 이 취약점을 수정하는 패치가 출시되었음에도 불구하고 오늘날에도 여전히 해커들이 이 취약점을 악용하고 있습니다. 하트블리드는 가장 치명적인 취약점 중 하나이지만, 일부 시스템에는 아직 패치가 적용되지 않아 해커로부터 이 백도어를 제거하지 못하고 있습니다.

 

Equifax: 주의해야 할 이야기

Equifax: 주의해야 할 이야기

포네몬의 설문조사에 따르면 응답자의 60%는 작년에 조직에서 경험한 침해 중 하나 이상이 패치를 통해 해결할 수 있는 알려진 취약점 때문이었지만 패치를 적용하지 않았다고 답했습니다. 약 88%는 패치를 적용하기 전에 조직 내 다른 부서와 조율해야 하며, 이로 인해 패치 적용이 최대 12일까지 지연될 수 있다고 답했습니다. 지연 시간이 길어질수록 해커가 시스템에 침투할 수 있는 백도어를 찾을 수 있는 시간이 늘어납니다.

Equifax 2017 침해 사고는 패치가 적용되지 않은 취약점의 대표적인 예입니다. 에퀴팩스는 apache 스트럿츠(CVE-2017-5638) 취약점을 알고 있었지만 시스템에 패치를 적용하지 않았습니다. 당시 에퀴팩스의 CEO는 시스템 검사에서 취약점을 발견하지 못했기 때문에 패치가 제대로 적용되지 않았다고 말했습니다. 패치가 적용되지 않았기 때문에 1억 4,550만 명의 미국인이 정보를 도난당했습니다. 실시간 패치 시스템을 사용했다면 이러한 데이터 유출을 피할 수 있었을 것입니다.

 

라이브 패치를 적용하면 시스템 속도가 느려지나요?

라이브 패치를 적용하면 시스템 속도가 느려지나요?

라이브 패치로 전환하지 않는 이유는 라이브 업데이트가 시스템 속도를 늦출 것이라고 생각하기 때문일 수 있습니다. 시스템 속도가 느려지고하지만 시스템 속도가 조금만 느려져도 조직에 문제가 발생할 수 있습니다. 취약성 자체, 지속적 패치가 아닌 임시 패치 사용 등 시스템 속도를 늦출 수 있는 요소는 여러 가지가 있습니다.

임시 패치를 사용하면 업데이트가 서버에 적용되지만 패치를 완전히 적용하려면 서버를 재부팅해야 합니다. 또한 패치가 서로 겹쳐서 적용되기 때문에 시스템 속도가 저절로 느려질 수 있습니다. 지속적 라이브 패치를 사용하면 재부팅하거나 시스템 속도를 늦출 필요 없이 모든 작업이 완료됩니다.

 

재부팅 대 재부팅 없음

재부팅 대 재부팅 없음

실시간 패치와 재부팅을 통한 정기 패치를 비교하려면 시스템 유형에 따라 비교 방법이 달라지므로 몇 가지 측면을 고려해야 합니다.

물리적 서버: 물리적 서버의 경우 하드웨어 구성 요소를 확인하기 위해 수행되는 전원 켜기 자체 테스트(POST) 작업으로 인해 재부팅 작업에는 항상 최소 몇 분이 걸립니다. 이 경우 라이브 패치를 수행하는 것이 시간이 덜 걸리고 서비스 가용성이 높기 때문에 항상 더 빠르고 효율적입니다. 모든 면에서 KernelCare Enterprise를 사용한 라이브 패치가 항상 더 나은 대표적인 사례입니다.

두꺼운 가상화서버: 두꺼운 가상화 서버의 경우 재부팅 시간이 덜 중요하지만 정기적인 패치 및 재부팅을 수행할 때 약간의 다운타임이 발생합니다. 이는 다른 시스템에 파급 효과가 있고, 제공되는 서비스의 이중화에 영향을 미치며, 유지 보수 기간이 필요하고, 라이브 패치보다 더 많은 영향을 미칩니다.

씬 가상화 서버: 씬 가상화 시스템에서는 컨테이너를 재부팅하는 것이 컨테이너를 파괴했다가 다시 생성하는 것과 같기 때문에 컨테이너의 최적 사용 사례입니다. 그러나 컨테이너는 실행 중인 호스트와 Kernel을 공유하므로 KernelCare Enterprise로 호스트의 Kernel을 라이브 패치하면 컨테이너에도 자동으로 패치가 적용됩니다. 이렇게 하면 컨테이너를 중단하고 다시 생성할 필요가 없으므로 속도가 얼마나 빠르든 느리든 상관없습니다.

서버 비교 표

여러 서버에서 이 작업을 수행할 때는 서비스 가용성을 유지하기 위해 이 작업을 수행해야 하며, 서버가 많으면 이 작업을 수행하기가 더 쉽습니다. 즉, 대규모 조직은 더 많은 중복 서버를 보유하고 있기 때문에 소규모 조직보다 이 작업을 더 효율적으로 수행할 수 있습니다. 하지만 완전히 컨테이너화된 서비스를 사용하는 최상의 경우에도 호스트 서버에서 실시간 패치를 수행하는 것이 업데이트된 버전으로 컨테이너를 다시 생성하는 것보다 영향이 적습니다.

 

승자: 재부팅 없이 패치 적용

승자: 재부팅 없이 패치 적용

에퀴팩스 유출 사고와 6년 후에도 계속되는 하트블리드 취약점 악용 사례에서 보았듯이, 보안 침해를 방지하는 유일한 방법은 패치를 신속하게 적용하는 것입니다. 그러나 시스템을 재부팅하는 데 필요한 다운타임은 잠재적으로 시스템을 취약하게 만들 수 있습니다. 유일한 해결책은 재부팅이 필요 없는 라이브 패치 시스템입니다.

 

결론

시스템에 1,000대 이상의 서버가 있는 경우, 특히 부서 간 다운타임을 조정해야 하는 경우 모든 서버를 자체적으로 최신 상태로 유지하는 것이 어려울 수 있습니다. KernelCare Enterprise는 재부팅 없이 실시간 패치를 제공하므로 다운타임이 발생하지 않으며 시스템이 패치되지 않은 취약점에 노출되지 않습니다. KernelCare Enterprise로 엔터프라이즈 서버를 항상 최신 상태로 유지하고 데이터 침해로부터 보호하세요.

7일 지원되는 KernelCare 무료 체험판 받기 

 

 

Kernel 재부팅, 시스템 다운타임 또는 예정된 유지 보수 기간 없이 취약성 패치를 자동화하고 싶으신가요?

TuxCare로 라이브 패치에 대해 알아보기

TuxCare 게스트 작가 되기

시작하기

메일

가입

4,500

Linux & 오픈 소스
전문가!


뉴스레터 구독하기