패치 유형: 보안 및 데브옵스 팀을 위한 상세 설명

주요 내용

• 패치 방식에는 전통적 패치, 가상 패치, 펌웨어 패치, 라이브 패치, 클라우드/컨테이너 패치 등 다섯 가지 유형이 있으며, 각각 고유한 가동 중단 시간, 위험 요소 및 규정 준수 특성을 가지고 있습니다.
• 대부분의 팀은 여전히 패치를 적용하고 시스템을 재부팅하는 방식을 고수하고 있는데, 이로 인해 변경 작업이 대기열에 쌓이는 동안 시스템이 며칠에서 몇 주 동안 취약한 상태에 놓이게 됩니다.
• 라이브 패칭은 재부팅 없이 실행 중인 시스템에 커널 및 라이브러리 수정 사항을 적용하여, 문제 해결 시간을 몇 주에서 몇 시간으로 단축합니다.
• 올바른 패치 전략은 가동 시간 요구 사항, 규제 관련 SLA, 그리고 실제로 관리하고 있는 스택의 계층에 따라 달라집니다.

일요일 밤 11시입니다. 팀원 중 한 명이 유지보수 시간을 지키고 있습니다. 운영 중인 서버 세 대에 커널 CVE 패치가 필요하고, 2014년 운영 매뉴얼에 따르면 이를 적용하는 유일한 안전한 방법은 재부팅뿐이기 때문입니다. 패치 파일 자체는 2메가바이트입니다. 다운타임은 호스트당 40분이 소요됩니다. 수백 대에 달하는 서버 전체에 이를 적용하면, 이 '빠른 보안 수정' 작업은 되돌릴 수 없는 15분의 손실로 이어집니다.

이것이 바로 어떤 패치 방식을 선택하느냐가 실제로 중요한 이유입니다. 올바른 접근 방식을 취하면 유지보수 시간을 몇 시간에서 몇 초로 단축하거나 아예 없앨 수도 있습니다. 반면 잘못된 방식을 선택하면 재부팅 승인을 받지 못해 몇 주 동안 알려진 CVE 취약점에 노출된 상태로 남게 됩니다.

일부 소위 “패치”라고 불리는 방법들은 사실 패치라고 할 수조차 없습니다. 이 글은 시중에 나와 있는 다양한 패치 관련 서비스를 제대로 파악할 수 있도록 도와주는 종합 가이드입니다.

소프트웨어 패치란 무엇인가요?

소프트웨어 패치 적용은 IT 프로세스이자 기본적인 보안 관행입니다. 일반적으로 이는 기존 구성 요소를 업데이트된 버전으로 추가하거나 교체하여 특정 시스템의 문제를 해결하거나 기능을 추가하는 과정으로 설명됩니다. 이는 하위 시스템, 종속성 또는 핵심 기능 수준에서 코드를 업데이트하는 등 다양한 단계에서 수행될 수 있습니다. 마찬가지로 특정 애플리케이션, 운영 체제, 드라이버 또는 기타 구성 요소에 패치를 적용할 수 있습니다.

패치의 목표는 항상 해당 대상에 적용되는 최신 버전을 확보하는 것이지만, 이를 달성하는 방식에 따라 다양한 패치 접근 방식 간의 차이가 발생합니다. 그리고 이러한 접근 방식들을 하나의 범주로 묶어 다루는 것이야말로, 팀들이 결국 수개월 동안 패치되지 않은 취약점을 운영 환경에 방치하게 되는 원인이 됩니다.

디버깅과 같은 다른 IT 용어들과 마찬가지로, 패칭(patching)이라는 용어도 물리적 과정에서 유래했습니다. 이는 펀치 카드의 구멍을 실제로 덮는 작업을 의미했으며, 즉 코드의 특정 부분을 “패치”하는 것을 뜻했습니다. 이 용어는 이제 거의 쓰이지 않는 듯하니, 대신 좀 더 현대적인 접근 방식들을 다루도록 하겠습니다.

패치, 업데이트, 정식 릴리스의 차이점

패치 유형에 대해 살펴보기 전에, 실무에서 상당한 혼란을 야기하는 용어 문제를 먼저 명확히 해둘 필요가 있습니다. ‘패치’, ‘업데이트’, ‘전체 릴리스’라는 용어들은 종종 혼용되어 사용되는데(때로는 같은 사람이 같은 대화 속에서 혼용하기도 합니다), 특히 작업 범위를 정하거나 규정 준수 감사관과 논의할 때 이 용어들은 의미상 상당히 다른 개념을 지칭합니다.

다음은 대략적인 기준입니다. 변경 사항을 한 문장으로 설명할 수 있다면 패치입니다. 릴리스 노트가 한 단락보다 길다면 업데이트입니다. 마이그레이션 가이드가 함께 제공된다면 정식 릴리스입니다.

이 표에서 파악할 수 없는 한 가지 사실은, 공급업체들이 때때로 변경 사항이 덜 파격적으로 들리도록 라벨을 잘못 붙인다는 점입니다. 내부 데이터베이스 드라이버를 조용히 교체하는 “소규모 업데이트”는 기능적으로 보면 정식 릴리스에 더 가깝습니다. 라벨을 그대로 믿기 전에 변경 내역을 꼼꼼히 확인하세요.

패치 유형의 주요 분류: 종합 분석

아래에 나열된 유형들은 대부분의 보안 및 데브옵스 팀이 접하게 될 사례의 대부분을 포괄합니다. 일부는 중복되는 부분도 있습니다. 예를 들어 펌웨어 패치는 보안 패치이기도 하며, 라이브 패칭은 기존 리눅스 서버와 컨테이너화된 워크로드 모두에 적용됩니다. 이러한 범주들은 서로 배타적이지는 않지만, 각각 고유한 운영 특성을 지닌 별개의 배포 메커니즘을 설명합니다.

전통적인 패치 적용

이것이 대부분의 사람들이 패치로 인식하는 것입니다. 특정 소프트웨어의 업데이트된 버전을 다운로드한 다음 디스크의 해당 파일을 새 버전으로 교체하는 작업으로 구성됩니다.

구현이 비교적 간단하고 이해하기도 쉽습니다. 기존 소프트웨어의 구버전이 전체 또는 부분적으로 새 버전으로 대체되는 방식입니다. 새 버전을 적용하려면 애플리케이션을 다시 시작하거나 시스템을 재부팅해야 하지만, 그 외에는 별다른 과정이 필요하지 않습니다. 물론, 바로 여기에 가장 큰 단점이 있습니다. 애플리케이션을 다시 시작하거나 시스템 전체를 재부팅하는 것은 시간이 오래 걸리는 작업으로, 실행 중인 모든 워크로드에 상당한 지장을 초래합니다. 이 때문에 즉흥적으로 수행할 수 있는 작업이 아니므로, 일반적으로 '유지보수 시간대'라고 불리는 기간에 이루어집니다. 이는 시스템 가용성이나 성능 문제가 발생할 것으로 예상되는, 사전에 승인된 시간대를 말합니다.

이 방식은 설정하는 데 시간이 오래 걸리며, 문제가 발생할 경우 예상 소요 시간을 초과하기 쉽습니다. TuxCare가 후원한 Ponemon Institute 보고서에 따르면, 조직의 56%는 중대하거나 우선순위가 높은 취약점을 해결하는 데 5주에서 1년까지 걸리며, 55% 이상은 이미 패치가 출시되었음에도 적용되지 않아 발생한 사이버 보안 사고를 경험했다고 보고했습니다. 이러한 지연은 설치 과정 자체가 아니라 변경 작업 시간대(change-window) 일정 조정에 기인하는 경우가 압도적으로 많습니다.

다음과 같은 경우에 사용하십시오. 유지보수 시간이 어느 정도 확보되어 있고, 안정적인 테스트 환경이 마련되어 있으며, 신속한 문제 해결을 요구하는 규정 준수 제약이 없는 경우에 사용하십시오. 정기적인 재부팅이 불가능한 시스템을 운영 중이라면, 이 방법을 유일한 전략으로 삼지 마십시오.

가상 패치 적용

이 기술은 이름에 ‘패치( patching)’라는 단어가 포함되어 있고, 겉보기에는 패치 결과를 제공하는 것처럼 보이지만, 실제로는 완전히 다른 방식으로 작동합니다. 가상 패칭(virtual patching)에서는 실제 코드 교체나 수정이 이루어지지 않습니다. 이는 방화벽 수준에서 위협 탐지 기능을 구현하여 알려진 공격 패턴을 차단하는 방식으로 이루어집니다. 공격자의 관점에서 보면 공격이 실패하므로, 공격자는 시스템이 패치된 것으로 오해할 수 있지만, 실제로는 그렇지 않습니다.

이러한 “패치” 방식에는 몇 가지 단점이 있습니다. 첫째, 시스템에 실제로 수정된 코드가 반영되지 않습니다. 둘째, 이 보호 기능은 알려진 공격 패턴에만 적용되므로 로컬 전용 취약점은 즉시 제외됩니다. 셋째, 특정 위협에 대응하여 네트워크 트래픽이 변조될 경우 이 방식이 우회될 수 있습니다.

이러한 단점들만으로는 이 접근 방식을 즉시 배제할 수 없다면, 장점으로는 시스템 내부에서 실제로 어떤 작업도 수행되지 않기 때문에 운영에 차질이 없다는 점, 단 한 번의 배포로 여러 시스템을 포괄할 수 있다는 점, 그리고 새로운 원격 전용 위협이 등장하는 즉시 이에 대한 보호를 받을 수 있다는 점이 있습니다.

가상 패치 적용을 최종 해결책이 아닌 임시 조치로 간주하십시오. 중대한 취약점이 공개되었을 때, 팀이 실제 수정 패치를 배포하는 데 몇 주가 아닌 며칠이 필요한 경우, 가상 패치는 귀중한 시간을 벌어줍니다. 하지만 취약점 공개 후 6개월이 지나도 여전히 가상 패치가 적용된 상태라면, 이는 패치 작업을 중단하고 도박을 시작한 것과 다름없습니다.

다음과 같은 경우에 사용하십시오. 실제 수정 프로그램을 적용하기 전에 CVE를 더 빠르게 완화해야 할 때, 또는 더 이상 공급업체 패치를 받지 못하는 지원 종료 소프트웨어를 실행 중인 경우에 사용하십시오.

펌웨어 패치 적용

펌웨어 업데이트는 기존의 패치 작업의 특수한 사례로, 일반적으로 업데이트하기 어려운 저장 매체에 포함된 코드를 EPROM(지우기 가능한 프로그래머블 읽기 전용 메모리) 칩에 직접 패치한다는 점이 추가적인 특징입니다. 이는 초기 스마트 기기와 1세대 IoT 기기에서 흔히 볼 수 있던 방식이었습니다. 소프트웨어는 제조 단계에서 미리 탑재되었으며, 업데이트가 이루어지는 경우는 거의 없었습니다. 이는 부분적으로는 오늘날처럼 업데이트와 보안이 주요 관심사가 아니었기 때문이기도 하지만, 소프트웨어가 저장된 방식 자체가 업데이트를 어렵게 만들었기 때문이기도 합니다. 최근의 기기들은 코드를 전부 또는 일부 SSD, SD 카드 또는 이와 유사한 표준 저장 매체에 기록하고 있으며, 이러한 매체는 수정하기가 훨씬 쉽습니다.

특정 소프트웨어와 전용 케이블이 필요한 특수 기록 하드웨어에 연결해야만 칩에서 코드를 실행할 수 있었던 시절에는, 이로 인해 복잡성이 한층 더해져 대부분의 IT 팀에게 전체 프로세스가 매우 부담스럽게 느껴졌습니다. 그 결과, 이러한 장치들은 수명 주기 내내 단 한 번도 업데이트되지 않는 경우가 많았습니다. 안타깝게도 이러한 방식의 장치는 여전히 많이 남아 있는데, 프린트 서버, IP 카메라, 데이터 센터 센서 등이 대표적인 예입니다.

펌웨어 패치 작업은 운영상 가장 위험도가 높은 유형이기도 합니다. BIOS 플래시 작업이 잘못되면 기기가 완전히 고장 나게 되며, 이 경우 대부분 “복구가 불가능하다”는 답변을 듣게 됩니다. 제조사마다 펌웨어 업데이트를 배포하는 빈도나 테스트의 신뢰성 측면에서 일관성이 없습니다. 서버 제조사들은 대체로 신뢰할 수 있지만, IoT 및 소비자용 하드웨어의 경우 사정이 다릅니다.

리눅스를 실행하는 IoT 및 임베디드 기기의 경우, 주목할 만한 대안이 있습니다. TuxCare의 KernelCare IoT는 ARM64 기기를 위한 재부팅 없는 커널 패치 기능을 제공하며, Arm Neoverse, NXP, AWS Graviton 등 다양한 칩셋을 탑재한 라즈베리 파이(Raspberry Pi), 우분투(Ubuntu), 요크토(Yocto) 기반 배포판을 지원합니다. 또한 Microsoft Azure IoT Hub와의 연동을 통해 기기 군 관리 기능을 제공함으로써, 커널 계층에서 발생하는 기존의 펌웨어 업데이트 문제를 완전히 해결합니다.

다음과 같은 경우에 사용하십시오 정해진 주기에 따라 – 대부분의 차량군에 있어 분기별이 적당합니다 – 항상 대표적인 하드웨어에서 테스트한 후 적용하고, 펌웨어 업데이트 후 검증 단계를 절대 생략하지 마십시오.

라이브 패치

라이브 패칭이란 실행 중인 코드를 수정하고, 버그가 있는 것으로 확인된 코드 구역이나 함수를 해당 구역의 수정된 버전으로 교체하는 과정을 말합니다. 이 작업은 전적으로 메모리 내에서 이루어지므로, 변경 사항을 반영하기 위해 애플리케이션을 다시 시작할 필요가 없습니다. 한 순간만 해도 소프트웨어의 함수에 버그가 있었더라도, 다음 순간에는 그 함수의 수정된 버전이 대신 사용됩니다.

시스템을 다시 시작하거나 재부팅할 필요가 없으며, 서비스 중단도 발생하지 않습니다. 덕분에 패치를 즉시 배포할 수 있어 별도의 유지보수 시간이 필요하지 않으며, 새롭게 등장하는 위협에 더 신속하게 대응할 수 있습니다. 기존의 패치 적용 방식처럼 패치가 배포되기를 몇 주 또는 몇 달씩 기다릴 필요 없이, 이제 패치가 출시된 지 몇 시간 또는 심지어 몇 분 만에 적용할 수 있습니다.

라이브 패칭의 복잡성은 패치 생성 단계에서 발생합니다. 패치는 원본 코드와 동일한 변수 크기와 정렬 방식을 사용하여 올바른 메모리 공간에 로드될 수 있도록 만들어야 합니다. 이러한 복잡성은 라이브 패칭 솔루션의 사용자에게는 드러나지 않으며, 오직 라이브 패치 제공자에게만 드러납니다.

라이브 패치 서브시스템은 지난 10년 넘게 리눅스 커널 내부에 패치를 적용해 왔으며, 이에 대한 다양한 솔루션이 개발되었습니다. TuxCare의 KernelCare는 이러한 솔루션 중 하나로, 모든 주요 배포판에서 리눅스 커널의 라이브 패치 기능을 지원합니다. LibCare는 이를 서비스 재시작 없이 OpenSSL 및 glibc를 포함한 중요한 사용자 공간 라이브러리로 확장합니다. 이 라이브러리들은 사실상 모든 리눅스 워크로드에서 암호화 및 핵심 시스템 호출의 기반이 됩니다. 이 두 솔루션은 유지보수 시간을 할애하지 않고도 리눅스 서버에서 가장 위험이 높은 공격 표면을 포괄적으로 보호합니다.

라이브 패칭에는 임시적 접근 방식과 영구적 접근 방식을 포함하여 다양한 형태가 존재하며, 이는 라이브 패칭 프로세스가 임시 방편으로 구현되는지, 아니면 기존 패칭 방식을 대체할 보다 영구적인 대안으로 구현되는지에 따라 달라집니다.

다음과 같은 경우에 사용하십시오. 상당한 규모로 Linux를 운영하거나, 엄격한 복구 SLA가 적용되는 규제 대상 워크로드를 실행하거나, 계획되지 않은 재부팅을 중대한 사고로 간주하는 이해관계자가 있는 경우

클라우드 및 컨테이너 패치 적용

클라우드 및 컨테이너 워크로드는 기존 서버에 적용되던 가정들이 그대로 통용되지 않기 때문에, 그 변화 양상을 명확히 이해할 필요가 있습니다.

컨테이너는 일반적으로 이미지를 재빌드하고 새로운 배포를 적용하는 방식으로 패치됩니다. 즉, 기존 컨테이너가 수정 사항이 반영된 새로운 컨테이너로 대체되는 방식입니다. 대부분의 워크플로에서는 실행 중인 컨테이너를 그 자리에서 수정하지 않도록 의도적으로 설계되어 있습니다. 불변성(immutability)은 설계 원칙이며, 이는 타당한 원칙입니다. 하지만 이는 재빌드 프로세스가 제대로 관리되지 않을 경우, 취약점이 있는 기본 이미지가 수많은 실행 중인 컨테이너에 은밀하게 지속될 수 있음을 의미합니다.

클라우드 환경은 공동 책임 모델에 따라 책임을 분담합니다. IaaS의 경우, 공급자는 하이퍼바이저와 물리적 호스트에 대한 패치를 적용하며, 사용자는 게스트 OS, 런타임 및 애플리케이션 계층을 관리합니다. PaaS의 경우, 공급자가 스택의 더 많은 부분을 처리합니다. SaaS의 경우, 사용자는 주로 에이전트와 통합 기능에 주의를 기울이면 됩니다. 자신이 어떤 계층을 관리해야 하는지 정확히 파악하는 것이 성공의 절반입니다. 공급자가 명시적으로 다루지 않는 부분에 대해 "클라우드가 처리해 줄 것"이라고 가정했다가 큰 타격을 입은 팀들이 많기 때문입니다.

컨테이너 모델이 바꾸지 못하는 점은, 컨테이너 런타임의 기반이 되는 리눅스 커널에는 여전히 패치가 필요하다는 사실입니다. 이는 실제 커널을 실행하며 실제 CVE 취약점을 지닌 실제 시스템들이며, 라이브 패치는 다른 리눅스 호스트와 마찬가지로 이 시스템들에도 적용됩니다.

다음과 같은 경우에 사용하세요 Kubernetes, ECS 또는 기타 컨테이너 오케스트레이션 플랫폼을 운영할 때 사용하세요. 이미지 재빌드를 라이브 패치 또는 기본 호스트 OS에 대한 기존 패치와 함께 사용하십시오. 컨테이너 추상화만으로는 그 아래에 있는 커널이 마법처럼 안전해지는 것은 아닙니다.

올바른 패치 전략을 선택하는 방법

패치 적용에는 다양한 방법이 있으며, 모든 상황에 적용할 수 있는 단일한 방법은 없습니다. 올바른 선택은 기술적 요인과 조직적 요인이 복합적으로 작용하여 특정 접근 방식을 선택하게 만드는 여러 요소의 조합에 달려 있습니다.

가장 중요한 몇 가지 변수:

가동 시간 요구 사항: 5분간의 재부팅이 별다른 문제가 되지 않는다면, 기존의 패치 적용 방식으로도 대부분의 경우를 처리할 수 있습니다. 그러나 예기치 않은 가동 중단이 심각한 사고로 간주된다면, 라이브 패치 적용은 상황을 완전히 바꿔놓습니다.

시정 조치 SLA: PCI DSS 및 HIPAA와 같은 프레임워크는 중요한 패치를 적용해야 하는 시한을 명시하고 있습니다. SLA가 30일이고 변경 작업 기간이 월 1회라면, 문제가 발생할 여지가 전혀 없습니다.

스택 구성: 리눅스 기반 환경은 라이브 패치 적용을 통해 가장 큰 이점을 얻습니다. 윈도우 기반 환경은 가상 패치를 임시 방편으로 활용하며 전통적인 패치 방식을 주로 사용합니다. 임베디드 및 IoT 기기는 펌웨어 패치가 필요하지만, 대부분의 팀은 이에 대한 투자를 지속적으로 소홀히 하고 있습니다.

운영 성숙도: 자동화된 테스트 환경과 확실한 롤백 절차는 어떤 전략이 실행 가능한지를 결정합니다. 이러한 요소가 없다면, 모든 패치 유형은 본래보다 더 큰 위험을 수반하게 됩니다.

흔히 접하는 상황에 적용할 수 있는 실용적인 틀:

• 절대 타협할 수 없는 가동 시간, 리눅스 환경 → 커널 및 중요 공유 라이브러리에 대한 라이브 패치, 그 외 모든 구성 요소에 대해서는 유연한 주기로 기존 방식의 패치 적용
• 유연한 유지보수 시간대, 균일한 환경 → 강력한 자동화 기능을 갖춘 기존 패치 적용 방식이 대부분의 요구 사항을 충족합니다
• 아직 대체할 수 없는 단종(EOL) 소프트웨어에 발이 묶여 있다면 → 가상 패치와 철저한 모니터링이 유일한 합리적인 임시 대책입니다
• 인프라에는 물리적 서버, 네트워크 장비 또는 IoT가 포함됩니다 → 펌웨어 패치 작업을 OS 패치와 별도로 독립된 프로그램으로 예산 편성

시스템, 데이터 및 사용자의 보안을 조금이라도 중요하게 여기는 모든 조직에게 패치 관리는 전략적 및 운영적 차원에서 반드시 해결해야 할 핵심 과제 중 하나입니다. 각 환경마다 고유한 특성이 있으므로, 반드시 해당 상황에 맞는 적절한 프로세스를 선택해야 합니다.

아직도 패치를 위해 재부팅하고 계신가요? 더 좋은 방법이 있습니다가 있습니다

만약 현재 여러분의 업무 흐름이 “재부팅을 예약하고, 아무 문제도 생기지 않기를 바라며, 다음 달에 또 반복한다”는 식이라면, 필요 이상으로 많은 관리 부담을 안고 있을 뿐만 아니라, 감수해야 할 위험 기간도 불필요하게 길어지고 있는 셈입니다. 라이브 패칭이 존재하는 이유는 ‘재부팅이 필수’라는 모델이 물리 법칙이 아니기 때문입니다. 이는 대안이 없던 시절에서 물려받은 습관에 불과합니다.

TuxCare의 KernelCare와 LibCare는 모든 주요 배포판에서 리눅스 커널과 OpenSSL, glibc를 포함한 중요한 공유 라이브러리에 대한 라이브 패치 기능을 제공합니다. 보안 패치를 적용할 때 기존 서버를 그대로 사용하며, 재부팅이나 별도의 유지보수 시간이 필요하지 않습니다. 또한, 관리 중인 시스템에 IoT 또는 임베디드 기기가 포함되어 있다면, KernelCare IoT를 통해 라즈베리 파이(Raspberry Pi), 우분투(Ubuntu), 요크토(Yocto) 기반 배포판을 실행하는 ARM64 기기에도 동일한 재부팅 없는 패치 기능을 적용할 수 있습니다.

자주 묻는 질문

요약

기사 이름

패치 유형: 보안 및 데브옵스 팀을 위한 상세 설명

설명

보안 패치, OS 패치, 라이브 패치 등 다양한 패치 유형을 알아보세요. 각 패치를 언제 사용해야 하는지, 그리고 시스템을 안전하게 유지하는 방법을 이해하세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고