ClickCease 클라우드 서버도 업데이트가 필요합니다 - TuxCare

인기 뉴스레터 구독하기

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

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

클라우드 서버도 업데이트 필요

2020년 12월 7일 TuxCare 홍보팀

클라우드 서버도 업데이트 필요

클라우드 프로비저닝은 로컬 호스팅 서버를 꾸준히 대체해 왔습니다. 워크로드를 처리하고 수요에 따라 확장하기 위해 클라우드에서 호스팅되는 Linux VM을 실행하는 것이 훨씬 빠르고 저렴합니다.

서비스형 인프라(IaaS) 시장이 빠르게 성장하고 있는 것은 당연합니다, Gartner에 따르면 2019년에만 IaaS 청구액이 37.3% 증가했습니다.. 하지만 이러한 사용 편의성은 클라우드 호스팅 Linux 서버를 운영하는 기업을 사이버 공격의 엄청난 위험에 노출시킬 수 있습니다.

이 도움말에서는 클라우드 호스팅 Linux 서버가 고유한 보안 위험을 초래하는 이유와 이것이 회사의 유지 보수 책임 측면에서 무엇을 의미하는지 설명하고, 클라우드 Linux 서버를 항상 최신 상태로 유지하기 위해 회사가 할 수 있는 일을 간략하게 설명합니다.

 

콘텐츠:

  1. 클라우드 내 가상 머신(IaaS)이란 무엇인가요?
  2. 위험에 처한 클라우드 서비스, 그리고 IaaS
  3. 주요 사례: SACK 패닉
  4. 새로운 시스템을 가동하는 것은 쉽지만 유지 보수 및 보안은 사용자가 책임집니다.
  5. Kernel 패치의 문제점
  6. KernelCare의 지원 방법
  7. 결론

 

클라우드 내 가상 머신(IaaS)이란 무엇인가요?

클라우드 내 가상 머신(IaaS)이란 무엇인가요?

서비스형 인프라 (IaaS)는 "인터넷을 통해 프로비저닝 및 관리되는 인스턴트 컴퓨팅 인프라"로 정의할 수 있습니다. IaaS의 핵심 구성 요소는 서버와 같은 하드웨어 리소스의 사용을 구매하고 이러한 리소스를 회사 또는 고객의 애플리케이션 요구 사항을 충족하도록 신속하게 배포할 수 있는 기능입니다.

서버를 임대한다는 것은 물리적 서버 전체를 임대하는 것을 의미할 수도 있지만, 더 일반적으로는 특정 양의 처리 능력과 스토리지에 대한 액세스 권한을 부여하는 가상화된 하드웨어 인프라를 임대하는 경우가 많습니다. 이는 최첨단 가상화 기술을 사용하여 물리적 하드웨어를 유연하게 관리하는 공급자인 IaaS 벤더가 제공합니다.

클라우드 서버 패키지의 일부로, 공급업체는 일반적으로 사전 패키징된 Linux 배포를 설치하는 편리한 경로를 제공합니다. 설치도 간단합니다. 클릭 한 번으로 설치를 트리거하면 Linux 워크로드 실행을 시작할 수 있습니다.

그러나 설치는 놀라울 정도로 간단할 수 있으며, Linux 서버를 간단히 설정하고 잊어버릴 수 있다고 생각하기 쉽습니다. 하지만 이는 상당한 위험을 감수하는 것입니다.

 

 

위험에 처한 클라우드 서비스, 그리고 IaaS

위험에 처한 클라우드 서비스, 그리고 IaaS

최근 Sophos 클라우드 보안 현황 조사 는 클라우드 보안을 당연시하는 것이 얼마나 쉬운 일인지, 그리고 그 대가가 얼마나 큰지를 보여줍니다. Sophos 설문조사에 따르면, 98%의 기업이 계정에서 가장 기본적인 보안 단계인 멀티팩터(MFA) 인증을 활성화하지 않았습니다.

설문조사에 참여한 3,200명의 IT 관리자 중 70%가 해킹을 당했거나 계정에서 데이터가 유출된 경험이 있다고 답한 것은 놀라운 일이 아닙니다.

클라우드 보안 침해는 계속해서 빈번하게 발생하고 있습니다. 한 가지 예를 들어보면 올해 초, 정교한 그룹이 아마존 웹 서비스(AWS)를 해킹하여를 해킹하여 해커가 AWS 서버를 원격으로 제어할 수 있는 루트킷을 설치했습니다.

물론 AWS뿐만이 아닙니다. 2019년에는 WhatsApp을 해킹하는 데 사용된 페가수스 멀웨어를 개발한 이스라엘 기업 NSO Group, 모든 주요 기술 기업의 클라우드 서비스를 침해할 수 있었다고 밝혔습니다.. 본질적으로 이 회사는 자사의 소프트웨어가 법 집행 기관의 범죄 수사를 가능하게 하도록 설계되었다고 주장했습니다.

어느 쪽이든 클라우드 서버가 취약하다는 것은 분명한 사실입니다. 그리고 취약성의 핵심 지점 중 하나는 Linux Kernel입니다.

 

 

대표적인 사례: SACK 패닉

2019년에도 미디어 대기업 넷플릭스는 Linux Kernel에서 여러 가지 중요한 네트워킹 취약점을 발견했습니다.. 이 익스플로잇을 통해 공격자는 실행 중인 서비스와 관계없이 서버에 대한 TCP 연결만 열 수 있다면 공격을 진행할 수 있었습니다. 가장 심각한 취약점 중 하나는 넷플릭스에 의해 "SACK 패닉"으로 명명되었습니다.

이 익스플로잇을 사용하면 공격자가 특정 목적을 위해 특별히 제작된 트래픽을 사용하여 Linux 시스템을 강제로 다운시킬 수 있습니다. 이로 인해 Ubuntu와 Red Hat을 포함한 많은 주요 배포판에서 SACK 패닉 Kernel 익스플로잇에 대한 경고를 발표했습니다.

넷플릭스의 발견은 Linux Kernel이 얼마나 취약한지 잘 보여줍니다. 예, 취약점이 발견되면 Kernel 패치를 통해 해당 취약점을 효과적으로 패치할 수 있지만, 패치에는 Linux 시스템 운영자가 패치를 적용하지 않으면 완벽하게 효과적인 패치가 작동하지 않는다는 중요한 약점이 있습니다.

 

 

새로운 시스템을 가동하는 것은 쉽지만 유지 보수 및 보안은 사용자가 책임집니다.

새로운 시스템을 가동하는 것은 쉽지만 유지 보수 및 보안은 사용자가 책임집니다.

클라우드 서비스를 보호하는 데 필요한 보안 조치(예: MFA)의 포괄적인 목록은 이 문서의 범위를 벗어나지만 여기서는 한 가지 중요한 사항을 다루겠습니다: Linux Kernel 패치입니다. 위의 예에서 볼 수 있듯이 Kernel 패치는 클라우드 서버 보안에서 명백하지만 종종 무시되는 측면입니다.

기업은 클라우드에 Linux 서버를 배포할 때 IaaS 제공업체가 제공하는 신속하고 간단하며 확장 가능한 롤아웃 프로세스에 의존합니다. 여기에는 최신 중요 패치가 포함되지 않은 표준 배포판을 롤아웃하는 것이 포함되는데, 이 배포판은 약간 오래된 경우가 많습니다.

더 심각한 문제는 클라우드 서버 운영자가 Kernel 라이브 패치를 IaaS 제공업체가 담당한다고 생각하지만 실제로는 재부팅 시에만 패치를 적용하는 경우가 있다는 것입니다. SACK 패닉에서 알 수 있듯이 패치가 적용되지 않은 Kernel은 엄청난 비용이 드는 사이버 침해로 이어질 수 있습니다. Linux 가상 서버를 운영하는 기업이라면 Kernel 라이브 패치를 무시할 수 없습니다.

안타깝게도 Kernel을 지속적으로 패치하는 것은 말처럼 쉬운 일이 아닙니다.

 

 

Kernel 패치의 문제점

Kernel 패치의 문제점

먼저 서버에서 Kernel을 패치하려면 일반적으로 재부팅이 필요합니다. 재부팅하는 동안 서버는 오프라인 상태가 되며, 해당 서버가 지원하는 서비스도 오프라인 상태가 됩니다. 이는 정기적이고 빈번한 패치 적용에 큰 장애가 됩니다. 기업들은 보안 패치가 절대적으로 중요한 경우가 아니라면 보안 패치를 적용하기 위해 서비스를 중단하고 싶지 않을 것입니다.

다음으로 패치는 노동 집약적인 프로세스입니다. 패치를 적용하는 것뿐만 아니라 재시작 시 서버 성능을 모니터링하고 패치가 중요한 서비스를 중단시키지 않는지 확인해야 합니다. 패치로 인한 다운타임과 이에 수반되는 노력 때문에 정기적인 패치가 뒷전으로 밀려나 사이버 보안에 심각한 위험을 초래하는 것은 당연한 일입니다.

하지만 서버 재시작 및 수동 패치를 대체할 수 있는 방법이 있습니다.

 

 

KernelCare의 지원 방법

KernelCare의 지원 방법

Kernel 패치를 자동화하여 일관되고 수고 없이 Kernel을 패치할 수 있도록 하는 것이 첫 번째 단계이며, 이것이 바로 KernelCare가 하는 일의 핵심입니다. KernelCare는 새로 릴리스된 패치를 지속적으로 모니터링하고 패치가 식별되면 자동으로 업데이트 프로세스를 트리거합니다.

이러한 자동화는 수작업으로 인한 문제를 없애줍니다. 패치 배포 횟수에 상관없이 클라우드 Linux 서버는 항상 패치가 적용되고 보안이 유지됩니다. 하지만 KernelCare는 한 단계 더 나아갑니다.

다른 많은 자동화된 패치 솔루션과 달리, KernelCare는 라이브 패치를 수행할 수 있습니다.. 자동 패치를 위해 KernelCare를 사용하는 기업은 Linux 서버를 완전히 재부팅할 필요 없이 Kernel 패치를 적용할 수 있기 때문에 다운타임을 최소화할 수 있습니다.

그 결과, KernelCare는 Linux 서버에 항상 패치가 적용되도록 보장하며, 패치 작업이나 IaaS 제공업체의 (부재할 가능성이 있는) 지원에 의존할 필요가 없습니다.

 

결론

실시간 패치가 핵심 단계이지만, 이 글의 전반적인 메시지는 IaaS Linux 서버 인스턴스를 능동적으로 관리해야 한다는 것입니다. 서버 유지 보수 및 보안을 인프라를 제공하는 공급업체에 맡기는 것은 다시 한 번 생각해 보세요. 그렇게 하면 비용이 많이 들지만 완전히 방지할 수 있는 보안 취약성에 노출될 수 있습니다.

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

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

TuxCare 게스트 작가 되기

시작하기

메일

가입

4,500

Linux & 오픈 소스
전문가!


뉴스레터 구독하기