Red Hat Security 2026: 패치, 규정 준수 및 모범 사례

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

주요 내용

RHEL의 보안 기능은 레드햇 보안의 탄탄한 기반이 되지만, 적극적인 패치 적용, 정기적인 감사, 그리고 엄격한 라이프사이클 관리가 뒷받침되지 않는다면 그 어떤 것도 제대로 작동하지 않습니다.
확장 지원 플랜 없이 RHEL 7 또는 지원 종료(EOL) 버전을 운영할 경우, 감사 위험에 노출되고 규정 준수 위반이 발생할 수 있습니다.
라이브 패칭을 사용하면 시스템을 재부팅하지 않고도 실행 중인 시스템에 커널 CVE 수정 사항을 적용할 수 있습니다. TuxCare의 KernelCare는 모든 주요 RHEL 버전에서 이 기능을 지원합니다.

레드햇 엔터프라이즈 리눅스를 사용하는 대부분의 팀은 레드햇이 확고한 명성을 쌓아왔기 때문에 자사의 보안 태세가 탄탄하다고 여깁니다. 이 플랫폼은 SELinux 강제 적용 기능, 서명된 패키지, 그리고 성숙한 취약점 공개 절차를 기본으로 제공합니다. 이러한 명성은 결코 우연히 얻은 것이 아닙니다.

하지만 이는 레드햇 보안에서 특정한 문제점으로 이어집니다. 즉, 취약점 패치, 라이프사이클 계획, 감사 관리와 같은 실질적인 업무는 플랫폼을 운영하는 팀의 몫임에도 불구하고, 플랫폼이 그 역할을 대신하고 있다고 가정하는 것입니다.

실제로는 다음과 같은 상황이 벌어집니다. 화요일에 리눅스 커널의 CVE가 공개됩니다. 금요일이면 패치가 제공됩니다. 다음 유지보수 일정은 18일 뒤입니다. 해당 CVE를 알고 있는 공격자는 이제 18일 동안 여러분의 시스템을 노릴 수 있는 기회를 얻게 됩니다. 이는 가상의 시나리오가 아닙니다. 바로 기업용 리눅스 보안의 일상적인 현실이며, 패치 제공 시기와 마찬가지로 패치 적용 주기가 중요한 이유이기도 합니다.

레드햇 보안의 실제 모습

RHEL의 보안 아키텍처는 계층적으로 구성되어 있으며, 이는 이 아키텍처의 강점이자, 이를 유지 관리하는 데 있어 수동적인 신뢰보다는 적극적인 노력이 필요한 이유이기도 합니다.

커널 수준에서, SELinux 강제 접근 제어를 적용하므로, 해킹당한 프로세스조차 자신에게 적용된 정책의 범위를 벗어날 수 없습니다. 이는 올바르게 구성되었을 때 효과적인 보호 수단이 되지만, 누군가가 setenforce 0 사건 발생 시 이를 되돌리지 않습니다. 또한, 역할 기반 접근 제어(RBAC)는 신원 및 권한 경계를 관리합니다. 게다가 레드햇의 서명된 업데이트 인프라와 그 리눅스 취약점 트래킹 피드는 신뢰할 수 있는 CVE 파이프라인과 출처를 확실히 알 수 있는 패치를 제공합니다.

문제는 이러한 상태들이 스스로 유지되지 않는다는 점입니다. RHEL은 초기에는 안전합니다. 하지만 그 상태가 지속될지는 전적으로 이후 팀의 관리 여부에 달려 있습니다. 2020년에 적절히 보강되었으나 2024년 중반 이후로 패치를 적용하지 않은 RHEL 7 시스템에는 수년간 패치되지 않은 커널 및 사용자 공간 CVE가 누적되어 있습니다. 초기 설계는 마지막 패치 적용 이후에 공개된 취약점으로부터 시스템을 보호하지 못합니다.

2024년 6월 지원 종료(EOL) 시점을 넘겨 여전히 RHEL 7을 사용 중인 팀의 경우, TuxCare의 ‘Endless Lifecycle Support’는 아직 운영상 실현 가능하지 않을 수 있는 강제 마이그레이션을 피하면서도 CVE 패치를 지속적으로 받을 수 있는 거의 유일한 방법 중 하나입니다.

레드햇 보안이 중요한 이유

RHEL은 지루하지만 매우 중요한 인프라를 운영하는 데 주로 사용됩니다. 은행들은 거래 정산을 위해 RHEL을 사용하며, 통신사들은 라우팅에 활용하고, 병원들은 이 플랫폼에서 EHR 시스템을 운영합니다. 주요 항공사나 금융 기관이 자사의 기술 스택을 열거할 때, RHEL은 대개 그 중심에서 핵심적인 역할을 담당하고 있습니다. 이는 공격 표면이 넓고, 보안 침해 시 파급 효과가 크다는 것을 의미합니다.

지난 몇 년간 리눅스를 표적으로 한 공격이 크게 증가했습니다. 랜섬웨어 그룹과 국가 연계 위협 행위자들은 윈도우 엔드포인트에서 실제로 고가치 워크로드가 운영되는 리눅스 서버로 관심을 돌렸습니다. 2024년 XZ Utils 백도어(CVE-2024-3094) 는 안정화 버전에 포함되었더라면 RHEL 기반 배포판의 상당 부분에 영향을 미쳤을 뻔한 아슬아슬한 사례였습니다. 다행히 이 취약점은 발견되었습니다. 하지만 다음 번에는 그렇지 않을 수도 있습니다.

규정 준수는 또 다른 차원의 시급성을 더합니다. HIPAA, PCI DSS, GDPR, SOC 2는 모두 한 가지 전제를 공유합니다. 바로 귀사가 여전히 공급업체의 보안 업데이트를 받는 소프트웨어를 운영 중이라는 점입니다. 연장 지원 계약 없이 시스템이 EOL(제품 수명 주기 종료)에 도달하는 순간, 이 전제는 무너지고 감사관들은 이를 포착합니다. “시스템이 잘 작동한다”는 말은 규정 준수 측면에서 타당한 근거가 될 수 없습니다. 이것이 운영 측면에서 어떤 의미를 갖는지 자세히 알아보려면, RHEL 7의 EOL이 귀사의 비즈니스에 미치는 영향을 확인해 보십시오.

RHEL의 일반적인 보안 위험

아래에 언급된 위험 요소들은 단순히 이론상의 극단적인 사례가 아닙니다. 이들은 사고 사후 분석 과정에서 반복적으로 나타나는 문제들이므로, 그 명칭을 확실히 알아두는 것이 좋습니다.

위험 요인 1: 패치되지 않은 커널 CVE

커널 패치를 적용하려면 재부팅이 필요하지만, 재부팅은 미뤄지기 일쑤입니다. 운영 중인 데이터베이스 클러스터, 통신사 라우팅 스택, 실시간 처리 시스템 등 모든 시스템에는 계획되지 않은 가동 중단을 피해야 할 타당한 이유가 있습니다. 그래서 패치는 그대로 방치되곤 합니다. CVE-2022-0847(Dirty Pipe) 의 경우, 취약점이 공개된 지 며칠 만에 패치가 나왔음에도 불구하고, 롤링 재시작을 진행하려는 사람이 없어 수많은 운영 시스템에서 수개월 동안 패치를 적용하지 않은 채 방치되었습니다.

CISA는 최근 2026년 5월 1일, 디스크에 접근하지 않고도 커널의 메모리 내 페이지 캐시를 KEV 카탈로그로 손상시켜 권한이 없는 로컬 사용자가 루트 권한을 획득할 수 있게 하는 권한 상승 취약점인 CVE-2026-31431(Copy Fail)을 추가했으며, 연방 기관에 2주간의 패치 기간을 부여했습니다. 대부분의 기업용 리눅스 환경은 기존의 패치 주기를 통해 이토록 신속하게 대응하기 어렵습니다. 이 취약점 자체로는 원격 접속이 필요하지 않지만, 도난당한 SSH 인증 정보나 침해된 컨테이너 프로세스와 같은 흔한 공격 수단과 연쇄적으로 결합될 경우, 시스템의 루트 권한을 완전히 탈취하는 결과로 이어집니다.

위험 #2: SELinux 비활성화 또는 잘못된 구성

프로덕션 환경에서 문제가 발생하면, setenforce 0 가장 빠른 해결책이지만 동시에 최악의 방법이기도 하다. SELinux 허용 모드에서는 정책 위반 사항을 기록할 뿐 차단은 하지 않으며, “문제 원인을 파악한 후 다시 활성화하겠다”는 말이 결국 영구적인 상태로 굳어지기 일쑤입니다. 지나치게 광범위한 정책 모듈 역시 거의 마찬가지로 문제가 됩니다. 서비스에 필요한 것보다 더 많은 권한이 부여되면, 해당 서비스가 침해당했을 때 그 영향 범위도 본래보다 훨씬 넓어지기 때문입니다.

전문가 팁: 문제 해결을 위해 SELinux를 비활성화하기 전에, setenforce 0 명령어를 사용하여 일시적으로 허용 모드로 전환한 후 확인해 보십시오. ausearch -m avc -ts recent 최근 거절 내역을 조회하기 위해. 대부분의 경우, 거절 로그를 보면 어떤 정책 규칙을 작성해야 하는지 정확히 알 수 있으며, 영구적으로 적용 모드를 종료할 필요가 전혀 없습니다.

selinux-enforcing-permissive-disabled 비교

위험 #3: 생산 환경에서 여전히 가동 중인 EOL 시스템

RHEL 7은 2024년 6월에 지원 종료(EOL) 시점을 맞이했습니다. 여전히 상당수의 조직에서 이 버전을 사용하고 있습니다. 마이그레이션은 비용이 많이 들고 업무에 차질을 빚을 뿐만 아니라, 당면한 긴급한 문제 해결보다 우선순위가 낮은 경우가 많기 때문입니다. 연장 지원 서비스가 없다면, 지원 종료일 이후에 공개되는 모든 커널 및 패키지 CVE는 영구적으로 패치되지 않은 취약점으로 남게 됩니다. 벤더의 지원이 종료되면 이를 만회할 방법은 없습니다.

위험 요소 4: 취약한 권한 경계

루트 권한으로 실행되는 서비스 계정. 모든 사용자에게 ‘NOPASSWD’ 설정이 적용된 sudoers 파일. 2019년에 설정된 후 한 번도 교체되지 않은 SSH 키. 이는 정교한 공격 경로가 아닙니다. 서비스 침해와 호스트 침해의 차이를 만드는, 기본적인 보안 결함일 뿐입니다.

위험 #5: 감사받지 않은 제3자 저장소

EPEL, 타사 RPM 저장소, 그리고 공급업체가 제공하는 패키지 미러는 종종 필수적입니다. 또한 이들은 공급망 공격 경로가 되기도 합니다. 단 하나의 패키지를 설치하기 위해 저장소를 추가하고, 그 외에 어떤 항목이 신뢰 대상에 포함되었는지 검토하지 않는 팀은 의도치 않게 공격 표면을 확대하게 됩니다.

레드햇 보안 모범 사례

위 위험 요소들에 대한 해결책은 복잡하지 않습니다. 어려운 점은 운영상의 압박 속에서 대규모 차량 대열 전체에 이를 일관되게 적용하는 것입니다.

실습 #1: 실제 일정에 맞춰 패치 적용하기

패치 출시와 실제 적용 사이에 발생하는 틈새가 바로 보안 취약점이 악용되는 시점입니다. 패키지 업데이트는 주간 주기로, 커널 업데이트는 월간 주기로 진행하는 것이 대부분의 조직에 있어 실현 가능한 최소 기준입니다. 결정의 핵심은 운영 측면에 있습니다:

예정된 재부팅이 가능하다면 – 표준 패치 적용을 통해 dnf update 게다가 윈도우를 재부팅해도 문제없습니다.
재부팅이 운영에 차질을 빚는다면, 가용성 위험을 초래하지 않으면서도 취약점 공개 속도에 발맞출 수 있는 유일한 방법은 재부팅 없이 패치를 적용하는 것입니다.

실습 #2: 커널 및 공유 라이브러리를 위한 라이브 패칭

라이브 커널 패칭은 재부팅 없이 실행 중인 커널에 CVE 수정 사항을 적용하는 기술입니다. 레드햇(Red Hat)은 일부 커널 브랜치에 대해 kpatch를 제공하지만, 지원 범위는 현재 지원 중인 버전으로 제한됩니다. TuxCare의 KernelCare는 구버전 및 EOL(지원 종료) 릴리스를 포함하여 더 광범위한 RHEL 커널 버전을 지원합니다.

접근 방식	재부팅이 필요합니다	적용 범위	최상의 대상
재부팅을 동반한 수동 패치	예	전체	개발/테스트용, 가동 시간이 짧은 시스템
Red Hat k패치	아니요	제한된 커널 브랜치	RHEL 표준 지원
TuxCare KernelCare	아니요	광범위하게, EOL 커널 포함	가동률이 높은 생산 시스템, 단종(EOL) 시스템

커널케어(KernelCare)와 kpatch의 지원 범위, 지원되는 커널, 롤백 기능에 대한 자세한 비교 내용은 ‘커널케어 엔터프라이즈와 Red Hat kpatch 비교’를 참조하십시오.

참고:LibCare는 라이브 패치 기능을 다음과 같은 중요한 공유 라이브러리로 확장합니다. glibc 및 OpenSSL 와 같은 중요한 공유 라이브러리로 확장합니다. 이러한 구성 요소들은 기존 방식으로는 패치 시 종속 서비스를 재시작해야 합니다. 전체 시스템 재부팅까지는 아니지만, 지속적인 연결이나 세션 상태를 유지하는 모든 작업에는 여전히 방해가 될 수 있습니다. OpenSSL을 사용하는 서비스를 재시작하지 않고 실행 중인 OpenSSL에 패치를 적용하는 것은 결코 쉬운 일이 아니며, 가동 시간이 긴 환경에서는 매우 중요한 기능입니다.

실습 #3: 단순히 CVE 목록을 활용하는 것이 아니라 CVE 우선순위 지정을 활용하세요

단순한 CVE 건수만으로는 실질적인 조치를 취할 수 없습니다. 대부분의 환경에서는 언제든 수백 건의 공개된 취약점이 누적되어 있으며, 이 모든 취약점을 동일한 시급성으로 다루다 보면 보안 태세를 개선하지 못한 채 팀원들이 지쳐버리게 됩니다.

실습 #4: SELinux를 강제 모드로 유지

강제 실행 모드로 실행하십시오. 거부 오류가 발생하면 다음을 사용하여 원인을 조사하십시오. ausearch 그리고 audit2allow 정책을 비활성화하는 대신, 사용자 정의 규칙이 정말로 필요하다면 해당 서비스가 실제로 필요로 하는 범위에 맞춰 설계된 정책 모듈을 작성하십시오. 이러한 원칙을 철저히 준수하는 팀들은 다른 모니터링 시스템이 문제를 포착하기 전에, SELinux의 접근 거부 메시지가 시스템에 이상이 발생했다는 첫 신호임을 종종 확인하게 됩니다.

실천 방법 #5: 권한 경계를 정기적으로 점검하십시오

서비스 계정은 정상적인 작동에 실제로 필요한 최소한의 권한으로만 실행되어야 합니다. sudoers 항목은 포괄적인 허용이 아닌 구체적인 권한만 명시해야 합니다. SSH 키는 정해진 일정에 따라 주기적으로 교체해야 하며, 키 기반 인증만이 허용되는 유일한 방법이어야 합니다. 파이프 auditd 검토가 이루어지는 곳에 로그를 기록하고, 중요 경로에 대해 파일 무결성 모니터링을 수행하도록 AIDE를 설정합니다.

전문가 팁: 실행 sudo -l -U <serviceaccount> 특정 서비스 계정이 정확히 어떤 권한을 보유하고 있는지 확인하기 위해서입니다. 30초면 끝나는 이 확인 과정을 통해, 수년에 걸쳐 sudoers 파일을 조금씩 수정해 오면서 쌓인 NOPASSWD 항목이나 지나치게 광범위한 명령어 권한 부여 사항을 발견하는 경우가 많습니다.

실천법 #6: 임종이 닥치기 전에 미리 준비하라

레드햇은 수년 전에 제품 수명 주기 일정을 미리 공개합니다. 흔히 발생하는 실수는 마이그레이션을 당면한 긴급 상황이 될 때까지 미래의 문제로만 치부해 버리는 것입니다. RHEL 8의 유지보수 지원이 2029년 5월에 종료되므로, 다가오는 주요 일정을 파악하는 것이 매우 중요합니다. 만약 대규모 RHEL 8 환경을 운영 중이라면, 이미 카운트다운이 시작된 셈입니다.

EOL(지원 종료) 전에 RHEL 9 또는 10으로의 마이그레이션이 가능하다면 지금부터 계획을 세우십시오. “3개월 전부터 계획을 시작하라”는 말은 실제 환경 전체를 마이그레이션하기에는 준비 기간이 턱없이 부족합니다.
만약 해당 일정 내에 마이그레이션이 불가능하다면, 지원 종료 기한 전에 연장 지원 서비스를 마련해 두십시오. TuxCare의 RHEL 7용 ‘Endless Lifecycle Support’는 레드햇의 자체 연장 지원 기간을 훨씬 넘어서까지 지속적인 CVE 패치 서비스를 제공하며, 이는 이번 회계연도나 다음 회계연도에 마이그레이션을 진행하지 않는 레거시 애플리케이션 스택을 보유하고 있는 경우 특히 중요합니다.

RHEL 보안을 강화하는 4가지 도구

리눅스 보안을 강화해 준다고 주장하는 도구는 많지만, 이 네 가지는 실제 RHEL 운영 환경에서 중요한 보안 취약점을 실제로 해결해 줍니다.

TuxCare

TuxCare는 RHEL 보안 운영에서 가장 해결하기 어려운 두 가지 문제, 즉 재부팅 없이 커널 및 공유 라이브러리의 CVE에 대한 패치를 적용하는 것과, 레드햇이 해당 시스템에 대한 업데이트 제공을 중단한 후에도 계속해서 패치를 적용하는 문제를 해결합니다.

KernelCare는 구버전 및 EOL(지원 종료) 릴리스를 포함한 광범위한 RHEL 버전의 실행 중인 시스템에 커널 CVE 수정 사항을 적용합니다. LibCare는 이를 glibc 및 OpenSSL과 같은 공유 라이브러리로 확장하며, 이러한 라이브러리의 경우 기존 방식으로는 패치 적용 시 서비스 재시작이 필요합니다. 이 두 기술은 결합되어 대부분의 기업용 리눅스 패치 프로그램에서 골칫거리였던 재부팅 지연 문제를 해결합니다.

‘무한 라이프사이클 지원(ELS)’ 프로그램은 특히 RHEL 7을 사용하는 조직에 적합합니다. 레드햇(Red Hat)이 제공하는 자체 연장 지원은 2024년 6월 제품 수명 주기 종료(EOL) 이후 제한된 기간 동안만 적용됩니다. 반면 TuxCare의 서비스는 조직이 필요로 하는 기간 동안 CVE 패치 지원을 그 이후로도 계속 제공합니다. 이는 마이그레이션 일정이 분기 단위가 아닌 수년 단위로 계획될 때 특히 중요한 요소입니다.

OpenSCAP

OpenSCAP은 RHEL에 기본으로 포함된 규정 준수 스캐너입니다. 이 도구는 SCAP 형식의 보안 정책(CIS 벤치마크, DISA STIG, PCI DSS 프로필 등)을 기준으로 시스템을 검사하여, 시스템이 규정을 준수하지 않는 부분을 상세히 기록한 보고서를 생성합니다. 보고서를 해석하는 데 약간의 노력이 필요하고 도구 자체는 화려하지 않지만, 이미 지불하고 있는 비용 외에 추가 비용을 들이지 않고도 RHEL 환경의 실제 규정 준수 기준을 파악할 수 있는 가장 직접적인 방법입니다.

레드햇 인사이트

Insights는 레드햇(Red Hat)의 내장형 예측 분석 서비스입니다. 이 서비스는 등록된 시스템에서 수집한 텔레메트리 데이터를 분석하여 알려진 취약점, 구성 변경 사항 및 성능 문제를 파악해 줍니다. 대부분의 유효한 RHEL 구독에 포함되어 있으므로, 이를 활용하지 않는 팀은 이미 비용을 지불한 기능을 방치하고 있는 셈입니다. 다만, 시스템을 등록하고 대시보드를 직접 확인해야 한다는 점이 문제입니다. Insights는 분석 결과를 검토하는 사람이 없다면 별다른 효과를 발휘하지 못하기 때문입니다.

Wazuh

Wazuh는 RHEL에서 원활하게 구동되는 오픈소스 SIEM 및 호스트 침입 탐지 플랫폼입니다. 이 플랫폼은 파일 무결성 모니터링, 로그 분석, 취약점 탐지, 규정 준수 보고 기능을 하나의 통합 시스템에서 처리합니다. Splunk나 IBM QRadar를 운영하고 싶지 않은 팀에게 Wazuh는 신뢰할 만한 대안이 될 수 있습니다. 다만, SIEM의 운영 및 유지보수 책임을 직접 져야 한다는 점이 단점입니다.

TuxCare로 레드햇 보안 강화하기

레드햇은 견고한 보안 기반을 제공합니다. 문제는 플랫폼이 초기 단계에서 제공하는 기능과, 운영상의 압박 속에서 시간이 지남에 따라 실제 환경 전반에 걸쳐 이러한 보안 상태를 유지하는 데 필요한 조치 사이의 격차에 있습니다.

레드햇 보안 분야에서 이러한 격차가 가장 자주 나타나는 두 가지 영역은 패치 적용 주기(특히 커널 및 공유 라이브러리 CVE에 대한 재부팅 연기 문제)와 라이프사이클 계획(특히 마이그레이션 경로가 마련되지 않은 상태에서 EOL에 도달했거나 이에 근접한 시스템의 처리 방안)입니다.

팀에서 미뤄둔 커널 재부팅 작업이 쌓여 있거나, 지원 계약 없이 RHEL 7을 운영 중이거나, 기존 패치 일정이 취약점 공개 속도를 따라잡을 수 없을 정도로 대규모 시스템을 관리하고 있다면, TuxCare가 이 세 가지 문제를 모두 해결해 드립니다. KernelCare와 LibCare는 재부팅 공백을 메워줍니다. Endless Lifecycle Support는 EOL 이후에도 CVE 지원 범위를 확장해 드립니다.

요약