커널케어 온보딩 시 예상되는 사항

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

커널케어는 재부팅이나 서비스 중단 없이 실행 중인 커널에 보안 패치를 적용합니다.
커널케어 라이브 패칭을 도입하는 과정은 단일 명령어로 수행되는 간단한 설치 절차로 이루어집니다.
커널케어는 모든 주요 리눅스 배포판에 라이브 패치의 자동 배포를 가능하게 합니다.

대부분 리눅스 커널 보안 업데이트 시스템 재부팅이 필요합니다. 서비스 중단을 방지하기 위해 IT 팀은 이러한 재부팅을 유지보수 시간대에 계획하며, 사용자 영향 최소화를 위해 주로 심야나 주말에 진행합니다.

팀이 예정된 작업 시간을 기다리는 동안 시스템은 노출된 상태로 남아 있습니다. 알려진 취약점은 패치되지 않은 채로 남아 있어, 패치가 제공된 시점과 적용되는 시점 사이에 간극이 발생합니다. 보안 팀은 즉시 패치를 적용하고자 합니다. 운영 팀은 가동 시간을 보호해야 합니다. 이러한 긴장 관계는 대응 속도를 늦추고 위험을 증가시킵니다.

라이브 패칭 이 문제를 해결합니다. 시스템을 중지하거나 서비스를 재시작하지 않고도 실행 중인 리눅스 커널에 보안 패치를 적용합니다.

본 문서는 KernelCare의 온보딩이 실제로 어떻게 진행되는지, 그리고 TuxCare를 활용한 재부팅 없는 패치 적용 시 조직이 기대할 수 있는 사항을 설명합니다.

재부팅 없는 패치 적용 전 일반적인 우려 사항

팀들은 재부팅 없는 패치의 가치를 이해하지만, 운영상의 위험 때문에 종종 주저합니다.

커널 안정성

일부 관리자는 실행 중인 커널에 변경 사항을 적용하면 충돌이나 정의되지 않은 동작이 발생할 수 있다고 우려합니다. 기존 커널 업데이트는 재부팅을 필요로 합니다. 이 단계를 제거하는 것은 표준 유지보수에 익숙한 사람들에게는 안전하지 않게 느껴질 수 있습니다.

제어 및 타이밍

보안 팀은 신속한 패치 적용을 원하지만, 운영 팀은 예측 가능한 변경 관리가 필요합니다. 자동화된 업데이트는 검토 없이 또는 승인된 시간대를 벗어나 변경이 발생할 수 있다는 우려를 불러일으킬 수 있습니다.

롤백 기능

패치가 문제를 일으킬 경우 팀은 이를 즉시 되돌릴 수 있는 방법이 필요합니다. 명확한 롤백 경로가 없다면, 라이브 패칭은 기존의 재부팅 기반 프로세스보다 더 위험하게 느껴집니다.

복잡한 환경

기업 환경에서는 종종 실질적인 제약이 존재합니다. 에어갭 네트워크, 엄격한 규정 준수 규칙, 단계적 배포 정책으로 인해 팀들은 재부팅 없는 패치가 기존 워크플로우에 적합한지 의문을 제기합니다.

커널케어(KernelCare)를 도입할 때 실제로 배포하는 것

커널케어 온보딩은 실행 중인 서비스를 중단시키지 않고 실시간 패치를 제공하기 위해 함께 작동하는 소수의 구성 요소를 도입합니다.

클라이언트 애플리케이션

각 컴퓨터에 경량 클라이언트 애플리케이션을 설치합니다. 이 애플리케이션은 4시간마다 새로운 패치를 확인하고 검증한 후, 사용 가능한 패치를 실행 중인 커널에 적용합니다. 이 프로세스는 재부팅이나 서비스 재시작이 필요하지 않으며 백그라운드에서 조용히 실행됩니다.

다음 명령어를 사용하여 수동으로 업데이트를 실행할 수도 있습니다:

# kcarectl --update

kcarectl 유틸리티를 사용하면 관리자가 패치 정보를 확인하고, 패치를 다운로드 및 적용하며, 적용된 패치를 열거할 수 있습니다.

사용 가능한 모든 사용 가능한 명령줄 옵션은 문서에서 확인할 수 있습니다.

패치 소스

커널케어 에이전트는 업데이트를 찾고 다운로드할 소스가 필요합니다. 두 가지 옵션이 있습니다:

TuxCare 포털: TuxCare에서 호스팅하는 클라우드 기반 저장소입니다. 대부분의 사용자에게 기본 선택 사항입니다.

ePortal: 인터넷에 연결되지 않은 서버에 패치를 배포할 수 있도록 지원하는 KernelCare용 웹 관리 콘솔입니다.

단계별: 온보딩 프로세스의 모습

1단계: 커널케어 설치

커널케어 설치에는 루트 권한으로 단일 명령어만 필요합니다. TuxCare 서버에서 설치 프로그램을 가져오려면 curl 또는 wget을 사용할 수 있습니다.

# curl -s -L https://kernelcare.com/installer | bash

스크립트는 에이전트를 설치하고 장치를 등록합니다. 이 과정은 몇 분 정도 소요됩니다.

2단계: 제품 활성화

커널케어(KernelCare)를 활성화하려면 라이선스가 필요합니다. 라이선스에는 IP 기반과 키 기반 두 가지 유형이 있습니다.

IP 기반 라이선스는 특정 IP 주소에 연결되어 있으며, 해당 주소가 일치할 경우 자동으로 실행됩니다.
키 기반 라이선스는 활성화 키를 사용한 등록이 필요합니다. 키를 등록하려면 아래 명령어를 사용하십시오.

# kcarectl --register <KEY>

Replace <KEY> with the registration code you receive when you sign up for a trial or purchase KernelCare.

무료 체험 받기

무료 체험판 활성화 키를 요청할 수 있습니다. 무료 체험 활성화 키를 요청하실 수 있습니다. 이 키는 14일간 유효합니다. 이 기간 동안 귀사의 시스템에서 KernelCare 라이브 패칭의 모든 기능을 시험해 보실 수 있습니다.

3단계: 패치 탐지 및 적용

활성화되면 KernelCare는 자동으로 업데이트를 확인합니다. 일치하는 패치가 있을 경우 다운로드, 검증 후 실행 중인 커널에 적용됩니다. 취약점이 해결되는 동안 시스템은 온라인 상태를 유지하며 정상적으로 작동합니다.

4단계: 검증 및 출시 관리

패치 상태는 명령줄 또는 ePortal 대시보드를 통해 확인할 수 있습니다. ePortal을 사용하는 경우 패치 정책에 따라 패치를 점진적으로 배포할 수 있습니다.

새로운 커널 CVE가 공개되면 어떤 일이 발생하나요?

새로운 커널 CVE 이 공개되면 시간이 주요 위험 요소가 됩니다. 시스템이 패치되지 않은 상태로 오래 유지될수록 노출 기간이 길어집니다. 보안 취약점이 공개되는 순간 패치 작업이 시작됩니다. TuxCare는 공개부터 배포까지 엄격한 워크플로를 따릅니다.

모니터링 및 분석

TuxCare 보안 팀은 커널 권고사항과 공급업체 업데이트를 지속적으로 모니터링합니다. 새로운 CVE가 등장하면 엔지니어들이 공식 수정 사항을 분석합니다. 이후 영향을 받는 커널 버전을 위한 라이브 패치를 생성합니다. 이 패치는 특정 취약점에만 한정됩니다. 기능 업데이트나 관련 없는 변경 사항은 포함되지 않습니다.

테스트 계층

커널케어는 세 가지 계층을 통해 패치를 제공합니다:

내부 계층: 엔지니어들은 안정성을 보장하기 위해 내부 서버에서 패치를 테스트합니다.
TuxCare 포털: 패치가 일반 사용을 위해 공개 저장소로 이동합니다.
ePortal: 패치는 ePortal에 가장 늦게 적용됩니다. 기업 고객은 선택 시 점진적 배포 정책을 따를 수 있습니다.

이 과정 전반에 걸쳐 패치 상태는 내부적으로 모니터링됩니다. 문제가 발생할 경우, 패치 배포는 ePortal 서버에 도달하기 전에 중단될 수 있습니다.

응답 시간 기대치

TuxCare는 공개된 지 10일 이내에 벤더가 수정된 커널 취약점에 대한 실시간 패치를 제공하는 것을 목표로 합니다. 이 접근 방식은 노출 시간을 줄이면서 운영 환경에서의 제어권과 안정성을 유지합니다.

커널을 넘어: LibCare로 커버리지 확장하기

커널 취약점 시스템에 대한 위협은 커널 취약점만이 아닙니다. 보안 결함은 애플리케이션이 매일 사용하는 공유 라이브러리에서도 자주 발견됩니다. 기존 방식에서는 이러한 라이브러리를 패치하려면 해당 라이브러리에 의존하는 모든 애플리케이션을 재시작해야 했습니다.

공유 라이브러리를 위한 라이브 패칭

LibCare KernelCare의 선택적 추가 기능으로, 이러한 중요한 공유 라이브러리에 대한 실시간 패치 기능을 확장합니다.

glibc: 대부분의 리눅스 애플리케이션에서 사용하는 표준 C 라이브러리

OpenSSL: 암호화 및 보안 통신을 처리하는 라이브러리.

LibCare가 없다면 glibc 업데이트 시 시스템 전체 재부팅이 필요합니다. OpenSSL 업데이트 시에는 웹 서버, 데이터베이스, 메일 서비스를 재시작해야 합니다. LibCare는 이러한 요구 사항을 제거합니다. 애플리케이션은 보안 업데이트를 받는 동안에도 계속 실행됩니다. 이를 통해 보안 취약점을 보완하는 동안에도 사용자에게 서비스를 계속 제공할 수 있습니다.

지원 환경 및 실제 호환성

커널케어는 다양한 리눅스 배포판과 커널 버전에서 작동하도록 설계되었습니다.

광범위한 유통 지원

커널케어는 RHEL, CentOS 등 인기 있는 엔터프라이즈 플랫폼을 포함하여 수십 개의 리눅스 배포판을 지원합니다. CentOS, AlmaLinux, Rocky Linux, Ubuntu, Debian, Oracle Linux, Amazon Linux 및 CloudLinux. 이러한 광범위한 지원 범위는 팀이 혼합 환경 전반에 걸쳐 단일 라이브 패칭 접근 방식을 사용할 수 있도록 합니다.

하드웨어 및 아키텍처

커널케어는 가장 일반적인 두 가지 서버 아키텍처와 호환됩니다:

x86-64: 대부분의 데이터 센터에서 발견되는 표준 인텔 및 AMD 프로세서.
ARM64: 현대 클라우드 환경과 에너지 효율적인 워크로드에서 점차 보편화되고 있습니다.

커스텀 커널 및 강화 커널

일부 조직은 특수 하드웨어나 성능 요구사항을 지원하기 위해 맞춤형 또는 강화된 커널을 사용합니다. TuxCare는 기존 구성과 일치하는 커널 전용 패치를 개발 및 유지보수함으로써 이러한 특수 환경에도 라이브 패칭을 확장할 수 있습니다.

자세히 알아보기 커스텀 커널 엔지니어링.

온보딩 후 운영 영향: 어떤 변화가 발생하나요?

커널케어(KernelCare)를 활성화하면 패치 작업이 사후 대응적 작업에서 자동화된 프로세스로 전환됩니다. 이러한 변화를 이해하면 팀이 업무 흐름을 조정하는 데 도움이 됩니다.

유지보수 시간대: 커널 CVE마다 다운타임을 예약할 필요가 없습니다. 라이브 패칭을 통해 즉시 재부팅 없이 보안 수정 사항을 적용할 수 있습니다. 유지보수 시간은 보안 패치 적용이 아닌 커널 업그레이드나 하드웨어 변경을 위한 계획적 선택이 됩니다.

작업 부하 분산: 시스템 관리자는 수동 패치 작업에 소요되는 시간을 줄입니다. 팀은 야간 재부팅 작업에서 벗어나 정상 업무 시간 동안 계획된 작업에 할애할 시간을 확보합니다.

취약점 노출: KernelCare는 지속적으로 업데이트를 확인하고 사용 가능한 패치를 자동으로 적용합니다. 이는 커널 취약점이 공개된 후 시스템이 노출된 상태로 남아 있는 시간을 줄여줍니다.

실제 환경에서 재부팅 없이 패치하는 것이 가치가 있을까?

재부팅 없는 패치로의 전환은 보안과 가동 시간 사이의 마찰을 제거합니다. 커널케어 도입 절차는 단일 명령어만으로 간단합니다. 라이브 패칭이 적용되면 운영상의 이점이 명확해집니다. 시스템은 서비스 중단 없이 보안 업데이트를 수신하며, 취약점 노출 위험이 크게 감소합니다.

서버를 다수 운영하는 모든 조직에게 수동 재부팅에서 자동화된 라이브 패칭으로의 전환은 운영 안정성을 근본적으로 개선하는 조치입니다.

TuxCare의 KernelCare 또한 조직이 PCI DSS와 같은 표준에서 정의한 패치 요구 사항을 충족하도록 지원함으로써 규정 준수 노력을 지원합니다. PCI DSS 및 HIPAA. 커널 업그레이드나 하드웨어 변경 시에는 여전히 재부팅이 필요하지만, 적용되는 모든 보안 패치마다 재부팅이 발생하지는 않습니다.

커널케어의 실제 작동 모습을 확인해 보시겠습니까? 무료 체험판 신청 을 신청하여 리눅스 시스템에서 자동화된 재부팅 없는 패치 적용을 경험해 보세요.

요약