Server patch management 101: Strategies for secure infrastructure

서버는 노트북처럼 패치를 적용할 수 없습니다. 직원의 워크스테이션에서 업데이트가 실패하면 한 사람에게 불편을 초래합니다. 데이터베이스 서버에서 업데이트가 실패하면 사업부 전체의 트랜잭션이 중단되거나 일시적으로 멈출 수 있으므로, 롤백 계획 수립이 필수적입니다.

엔드포인트를 위해 고안된 표준 장치 관리 관행은 서버 환경에는 그대로 적용될 수 없습니다. 운영상의 중요성, 의존성 체인, 가동 시간 요구 사항은 근본적으로 다릅니다.

폭발 반경의 차이는 패치 계획 수립, 단계별 준비 및 실행 방식의 모든 측면을 바꿔 놓습니다. 서버 패치 관리에는 가동 시간 요구 사항, 애플리케이션 종속성, 변경 관리 워크플로우를 고려한 조정이 수반되는데, 이는 엔드포인트 패치 작업에서는 일반적으로 필요하지 않은 사항들입니다.

이 가이드에서는 자산 목록 및 종속성 매핑부터 위험 기반 우선순위 지정, 링 기반 배포, 팀 간 협업, 배포 후 검증에 이르기까지, 서버 패치 적용을 다른 작업과 차별화하는 운영상의 제약 사항들을 다룹니다.

서버 패치 작업에 왜 다른 운영 방식이 필요한가

데이터베이스 서버에서 업데이트가 한 번만 실패해도 사업부 전체의 업무가 마비될 수 있습니다. 그렇기 때문에 서버 패치 관리는 단순히 의 패치 관리 를 대규모로 확장한 것이 아니라, 근본적으로 다른 운영 분야입니다.

의 일반적인 패치 관리 프로세스 는 누락된 업데이트를 스캔하고, 스테이징 환경에서 패치를 테스트하며, 유지보수 시간대에 패치를 배포하고, 그 결과를 보고하는 과정을 포함합니다. 의 모범 사례로는 반복적인 작업을 자동화하고, Windows 환경의 경우 마이크로소프트의 ‘패치 화요일(Patch Tuesday)’과 같은 정기적인 패치 일정을 따르며, Linux 및 기타 플랫폼의 경우 공급업체별 릴리스 주기를 준수하고, 업데이트를 적용하기 전에 백업이나 스냅샷을 생성하는 것 등이 있습니다.

하지만 그것이 표준적인 틀입니다. 서버를 관리하는 기업 팀의 현실은 훨씬 더 복잡합니다.

서버는 대개 24/7 개의 워크로드를 처리하며, 유지보수 시간은 몇 주 전에 미리 협의된 좁은 시간대에 이루어집니다. 그 시기를 놓치면, 패치가 이미 승인되고 배포 준비가 완료된 상태라 하더라도 노출 기간이 몇 주나 더 길어집니다. 표준 엔드포인트 관리를 사용하면, 점심 시간 동안에도 업무에 미치는 영향을 최소화하면서 장치를 재부팅할 수 있습니다. 서버에는 그런 유연성이 없습니다.

그리고 의존성 문제도 있습니다. 서버가 단독으로 작동하는 경우는 거의 없습니다. 한 서버에 적용된 패치가 다른 서버가 의존하고 있는 API를 오작동하게 만들 수 있으며, 이는 결과적으로 하류에 위치한 제3의 시스템에도 영향을 미칠 수 있습니다. 이러한 서비스와 종속성 간의 상호 연결된 구조 때문에 서버 패치 작업은 엔드포인트 패치 작업보다 근본적으로 더 복잡하며, 변경 사항을 일괄적으로 배포하기보다는 신중하게 순서를 정해 적용해야 하는 이유이기도 합니다.

서버 패치 적용에 따른 제약 사항이 있다고 해서 작업을 할 수 없는 것은 아닙니다. 이를 통해 운영상 차별화를 꾀합니다. 다음 섹션에서는 새로운 운영상의 문제를 야기하지 않으면서 위험을 줄일 수 있는 방식으로 각 제약 사항을 해결하는 방법을 단계별로 설명합니다.

서버 인벤토리 및 종속성 매핑

무엇이든 배포하기 전에, 어떤 부분에 패치를 적용하는지, 그리고 그 부분에 의존하는 요소가 무엇인지 파악해야 합니다. 서버 목록이 불완전하면 배포가 시작되기도 전에 패치 작업에 차질이 생길 수 있습니다.

패치 적용을 위한 서버 인벤토리 작업은 단순한 자산 파악을 넘어서는 것입니다. 여기에는 운영 체제 버전, 설치된 애플리케이션, 패치 수준, 그리고 각 서버가 지원하는 비즈니스 기능이 포함됩니다. 이러한 정보가 없으면, 팀들은 특정 서버가 테스트 워크로드를 실행 중인지, 아니면 운영용 데이터베이스를 실행 중인지 알 수 없는 상태에서 무작정 패치를 적용하게 됩니다.

[실시간 IT 자산 현황 파악을 통해 보안 침해로 이어지기 전에 위험을 관리하는 역량을 어떻게 혁신할 수 있는지 알아보세요]

의존성 매핑은 또 다른 계층을 추가합니다. 서버는 종종 다른 시스템이 호출하는 서비스를 호스팅합니다. 미들웨어 서버에서 재부팅이 필요한 패치를 적용하면 다운스트림 애플리케이션과의 연결이 일시적으로 중단될 수 있습니다. 의 클라우드 및 컨테이너 중심 환경에서는 패치 적용이, 장기적으로 운영되는 인스턴스를 그대로 업데이트하는 대신 골든 이미지를 재구축하고 워크로드를 재배포하는 것(불변 인프라)을 의미할 수도 있습니다.

각 서버가 어떤 요소와 연동되는지, 그리고 어떤 요소가 해당 서버와 연동되는지를 파악하면, 팀은 패치를 올바른 순서대로 적용하고 영향을 받는 이해관계자들에게 알릴 수 있습니다.

수동 재고 관리 프로세스는 서버의 무분별한 증설 속도를 따라잡기 힘들다. 클라우드 환경에서는 서버가 가동 및 중지되며, 온프레미스 인프라도 폐기, 재구성, 새로운 배포 등을 통해 마찬가지로 빈번하게 변화하지만, 이러한 변경 사항이 항상 기록되지는 않습니다. 구성 편차는 시간이 지남에 따라 누적됩니다. 분기별 감사에만 의존하는 팀들은 패치가 실패하거나 감사 과정에서 누락된 부분이 지적된 후에야 비로소 문제점을 발견하는 경우가 많습니다.

의 실시간 자산 가시성 기능은 서버 상태를 지속적으로 모니터링함으로써 이 문제를 해결할 수 있습니다. 새로운 서버가 가동되거나 기존 서버의 구성이 변경되면, 구성 및 연결 상태에 따라 인벤토리가 자동으로 업데이트될 수 있습니다.

현대적인 패치 관리 소프트웨어는 이러한 실시간 자산 현황 파악 기능을 패치 적용 워크플로우에 직접 통합하여, 팀에게 오래된 스냅샷이 아닌 최신 현황을 제공해야 하며, 기존 방식의 속도를 저하시키는 수동 대조 작업을 없애야 합니다.

완벽한 인벤토리 및 종속성 맵이 마련된 상황에서, 다음으로 제기되는 질문은 ‘어떤 서버에 먼저 패치를 적용해야 하는가?’입니다.

EPSS, CISA KEV 및 자산 중요도를 활용하여 서버 패치의 우선순위를 정하는 방법

모든 취약점이 동일한 위험을 수반하는 것은 아닙니다. 네트워크에 노출되지 않은 테스트 서버에서 CVSS(공통 취약점 평가 시스템) 점수가 9,8 인 경우, 고객 거래를 처리하는 운영 서버에서 CVSS 점수가 7,5 인 경우보다 시급성이 낮습니다. 효과적인 우선순위 설정은 취약점의 심각도와 비즈니스 상황을 종합적으로 고려합니다. 이는 에서 제시하는 성숙한 취약점 관리 프로그램 의 초석으로, 단순히 문제를 스캔하는 것을 넘어 악용될 수 있는 노출 위험을 적극적으로 줄이는 것을 목표로 합니다.

다음 세 가지 지표는 단순한 CVSS 점수만으로는 파악하기 어려운 우선순위 설정을 더욱 정교하게 하는 데 도움이 됩니다:

1. 취약점 악용 예측 점수 체계(EPSS): EPSS는 향후 30 일 이내에 특정 취약점이 실제 환경에서 악용될 확률을 추정합니다. CVSS 점수는 높지만 EPSS 점수는 낮은 취약점은, CVSS 점수가 보통이고 EPSS 점수가 높은 취약점보다 시급성이 낮을 수 있습니다.
2. CISA의 KEV 목록: CISA KEV 목록에 취약점이 등재되면, 공격자들은 이미 이를 악용하고 있는 것입니다. 이 목록에 포함된 취약점은 다른 점수와 관계없이 우선 처리 대상 순서의 맨 앞으로 이동합니다. 이는 특히 Windows Server와 널리 사용되는 리눅스 배포판을 비롯한 광범위하게 배포된 서버 플랫폼에 해당되는데, 이러한 플랫폼들은 기업 환경 및 인터넷에 노출된 환경에서 널리 사용되기 때문에 KEV 목록에 자주 등장합니다.
3. 자산 중요도: 서버가 비즈니스 운영에서 수행하는 역할에 따라 패치 적용의 시급성이 결정됩니다. 수익 창출 애플리케이션, 규제 대상 데이터 또는 고객 대상 서비스를 지원하는 서버의 경우 일반적으로 더 신속한 문제 해결이 필요합니다. 또한 이들은 협상력을 극대화하기 위해 고가치의 시스템을 의도적으로 노리는 랜섬웨어 운영자들에게 가장 매력적인 표적이기도 합니다.

KEV에 등재된 취약점의 경우, 일반적인 패치 주기를 변경해야 하는 경우가 많습니다. 성숙한 패치 관리 프로그램은 KEV에 등재되었거나 노출 위험이 매우 높은 취약점에 대해, 비록 정기적인 유지보수 일정에 차질이 생기더라도 아웃오브밴드 대응을 지원합니다.

신호를 결합하면 우선순위 매트릭스가 생성됩니다. EPSS 점수가 높고, CISA KEV에 등재되어 있으며, Tier 1 운영 서버에 존재하는 취약점은 즉각적인 주의를 요합니다. EPSS 점수가 낮고, KEV 목록에 등재되지 않았으며, 개발 서버에 존재하는 취약점은 다음 정기 유지보수 시간까지 기다릴 수 있습니다. 목표는 모든 것을 한꺼번에 수정하는 것이 아닙니다. 이는 악용될 가능성이 가장 높은 취약점을 우선적으로 해결함으로써 공격 표면을 체계적으로 축소하기 위함입니다.

위험 기반의 우선순위 지정은 팀이 위험 노출을 가장 크게 줄일 수 있는 부분에 노력을 집중할 수 있도록 돕습니다. 우선순위가 정해지면, 다음 과제는 운영에 차질을 주지 않으면서 패치를 적용하는 것입니다.

Tanium Comply를 통한 보다 스마트한 취약점 우선순위 지정

취약점 누적 건수는 더 열심히 일한다고 줄어드는 것이 아니라, 더 현명하게 일해야 줄어듭니다. 이번 Tanium Tech Talks 에피소드에서는 Tanium Comply가 CVSS 점수 위에 ‘ ’의 취약점 공격 정보, 엔드포인트 중요도 및 탐지된 제품 데이터를 어떻게 중첩하여 적용하는지 살펴보며, 이를 통해 팀이 무엇을 먼저 수정해야 할지 더 정확하고 타당한 근거를 바탕으로 결정할 수 있는 방법을 제시합니다.

서버 패치 워크플로우를 여전히 스프레드시트와 직감에 의존해 시작하고 계신다면, 이 영상을 꼭 시청해 보시기 바랍니다.

링 기반 배포 방식을 활용한 서버 패치 배포 체계 구축

모든 서버에 패치를 동시에 적용하는 것은 대규모 서비스 중단을 초래할 수 있습니다. 링 기반 배포 방식은 패치를 점차 더 큰 그룹 단위로 단계적으로 적용함으로써, 문제가 운영에 필수적인 시스템에 영향을 미치기 전에 조기에 파악할 수 있게 합니다.

전형적인 링 구조는 다음과 같습니다:

링 0: 카나리아

비중요 서버로 구성된 소규모 그룹이 가장 먼저 패치를 적용받습니다. 캐너리 서버는 프로덕션 환경을 그대로 반영하지만, 프로덕션 워크로드는 처리하지 않습니다. 패치로 인해 문제가 발생하더라도 피해는 제한적입니다.

링 1: 파일럿

카나리아 서버가 정해진 기간 동안 안정적으로 운영된 후, 패치는 파일럿 그룹으로 이동합니다. 시범 운영 그룹에는 더 다양한 유형의 서버가 포함되어 있으며, 일부 하위 등급의 운영 시스템도 포함될 수 있습니다. 이 단계에서는 모니터링이 강화됩니다.

Ring 2: 광범위한 출시

카나리아 및 파일럿 단계가 완료됨에 따라, 패치가 대부분의 서버에 배포됩니다. 이 단계는 대개 예정된 유지보수 시간대에 진행되며, 배포 전후의 자동 상태 점검을 포함합니다. 초기 테스트 단계에서 얻은 데이터를 바탕으로, 팀은 본격적인 확대 적용에 앞서 시기, 배치 규모 및 순서를 세밀하게 조정할 수 있습니다.

링 3: 운영에 필수적인

가장 민감한 서버의 경우, 악용의 심각성이나 노출 정도가 신속한 대응을 필요로 하지 않는 한, 일반적으로 이전 단계에서 검증이 완료된 후에 패치를 적용받습니다. 이 시점에서 해당 패치는 수백, 수천 대의 다른 서버에서 안정적으로 작동하는 것으로 입증되었습니다.

자동 피드백 게이트가 링 간의 이동을 제어합니다. 한 링에서 오류율이 급증하거나 상태 확인에 실패하면, 배포는 다음 단계로 진행되기 전에 일시 중지됩니다. 이를 통해 문제가 있는 패치가 함대 전체로 연쇄적으로 확산되는 것을 방지할 수 있습니다.

링 기반 배포는 변경 관리 프로세스와 통합될 때 가장 효과적입니다. 그 조율이 바로 퍼즐의 다음 조각입니다.

IT 운영, 보안 및 변경 관리 부서 전반에 걸친 서버 패치 적용 조정

서버 패치 작업은 한 팀만의 전유물이 되는 경우가 거의 없습니다. 복잡한 IT 환경에서 보안 팀은 취약점을 파악하고 수정 일정을 수립하는 반면, IT 운영 팀은 서버를 관리하고 배포를 수행하며, 변경 관리 팀은 변경 사항이 언제, 어떻게 이루어질지를 규정합니다. 이러한 기능 간에 명확한 조율이 이루어지지 않으면, 패치가 승인 대기열에서 정체되거나 적절한 감독 없이 배포되곤 합니다.

역할을 명확히 하는 것이 도움이 됩니다. 일반적인 모델에서는 책임을 다음과 같이 할당합니다:

• 보안: 취약점을 파악하고, 우선순위 기준을 설정하며, 수정 조치에 대한 SLA를 정의합니다.
• IT 운영: 서버 목록을 관리하고, 패치 배포를 수행하며, 배포 후 상태를 모니터링합니다.
• 변경 관리: 변경 사항을 승인하고, 유지보수 시간을 일정으로 잡으며, 예외 사항을 문서화합니다.

변경 자문 위원회(CAB)의 승인은 특히 운영 환경의 경우 서버 패치 적용에 있어 종종 필수적인 절차로 작용합니다. 패치 적용 워크플로를 ServiceNow와 같은 IT 서비스 관리(ITSM) 플랫폼과 통합하면 이 프로세스를 효율화할 수 있습니다. 패치 요청은 표준 변경 티켓을 통해 처리되며, 승인은 서버 계층에 따라 자동으로 진행되고, 배포 상태는 티켓에 실시간으로 반영됩니다.

내부적으로든 관리형 서비스 제공업체를 통해서든 패치 적용이 IT 서비스 형태로 제공되는 조직의 경우, 이러한 워크플로 통합을 통해 대규모로 일관되고 감사 가능한 실행이 가능해집니다. 특히 관리형 서비스 제공업체(MSP)는 이러한 통합을 통해 각 고객 환경에 맞춰 별도의 워크플로를 구축하지 않고도 여러 고객 환경에 걸쳐 일관된 패치 적용 기준을 적용할 수 있어 큰 이점을 얻습니다.

많은 MSP 업체들이 원격 모니터링 및 관리(RMM) 플랫폼을 통해 패치 적용 서비스를 제공하며, 이러한 플랫폼은 클라이언트 환경 전반에 걸쳐 중앙 집중식 가시성과 제어 기능을 제공합니다. 다만, 복잡한 서버 종속성과 링 기반 배포 로직을 처리하는 능력은 플랫폼마다 차이가 있습니다.

예외 처리에도 협력이 필요합니다. 일부 서버는 업무상의 제약, 공급업체에 대한 의존성 또는 기술적 한계로 인해 예정된 일정에 따라 패치를 적용할 수 없는 경우가 있습니다. 예외 사항을 기록하고 이에 대한 보완 통제 조치를 함께 마련하면 감사 추적을 명확하게 유지할 수 있으며, 보안 팀이 잔여 위험을 정확히 파악할 수 있도록 보장합니다.

에 대한 패치가 적용되지 않아 높은 위험에 노출된 서버( )의 경우, 보안 정보 및 이벤트 관리(SIEM) 플랫폼에 경보를 통합하면, 문제가 해결될 때까지 악용 시도를 탐지하는 데 필요한 지속적인 모니터링을 제공할 수 있습니다.

패치를 적용하고 변경 내역을 업데이트한 후, 마지막 단계는 모든 것이 정상적으로 작동하는지 확인하는 것입니다.

서버 군 전체에서 패치 배포 성공 여부 확인

패치를 배포하는 것과 패치를 성공적으로 설치하는 것은 같은 것이 아닙니다. 패치 설치가 실패하는 데는 여러 가지 이유가 있습니다. 디스크 공간 부족, 소프트웨어 충돌, 네트워크 중단, 또는 재부팅이 제대로 완료되지 않은 경우 등이 있습니다.

검증이 이루어지지 않으면 팀은 사실보다는 가정에만 의존하여 업무를 수행하게 됩니다. 바로 그 차이가 성숙한 패치 프로세스와 허위의 안전감을 주는 프로세스를 구분 짓는 요소입니다.

전체 차량 군을 대상으로 한 실시간 쿼리 기능이야말로 폐쇄형 검증 방식을 대규모로 실용화할 수 있게 해주는 핵심 요소입니다. 팀은 표본을 무작위로 점검한 뒤 나머지는 추측에 의존하는 대신, 배포 후 몇 분 만에 관리 대상 모든 서버의 패치 상태를 확인할 수 있으며, 설치에 실패한 항목은 자동으로 표시되어 조치를 취할 수 있습니다.

배포 후 검증은 다음 세 가지 질문에 대한 답을 제공합니다:

• 패치가 설치되었나요? 업데이트가 OS/패키지 관리자에 정상적으로 기록되었는지, 그리고 예상된 패키지, KB, 빌드 또는 버전 상태가 반영되었는지 확인하십시오.
• 패치가 적용되었나요? 필요한 재부팅 또는 서비스 재시작이 완료되었는지 확인하고, 실행 중인 커널/서비스 버전이 수정된 상태를 반영하는지 확인하십시오.
• 패치로 인해 문제가 발생했나요? 건강 상태 점검 및 서비스 수준 지표(로그, 오류율, 지연 시간)를 검증하고, 문제가 발생할 경우 롤백/페일오버 경로를 확인합니다.

자동화된 검증 프로세스를 통해 대규모 차량 함대 전반에 걸쳐 이 과정을 확장할 수 있습니다. 팀은 서버 샘플을 무작위로 점검하는 대신, 모든 서버에 대해 실시간으로 쿼리를 실행하여 패치 상태를 확인할 수 있습니다. 설치에 실패한 서버는 수정 조치가 필요하다는 표시가 붙습니다. 설치가 성공적으로 완료된 서버는 구성 관리 데이터베이스(CMDB)에 해당 레코드를 업데이트합니다.

검증을 통해 전체 과정이 완성됩니다. 이를 통해 패치 적용을 단순한 배포 활동에서 측정 가능한 성과를 내는 위험 완화 활동으로 전환합니다.

서버 패치 규정 준수를 위한 감사 대비 태세 유지

PCI DSS, HIPAA, DORA(EU 디지털 운영 복원력 법) 등 규정 준수 프레임워크는 조직이 패치 및 취약점 관리 관행을 문서화하고 입증할 것을 요구합니다.

감사관들은 단순히 패치가 적용되었는지 여부만 알고 싶어 하는 것이 아닙니다. 그들은 증거를 원합니다: 배포 로그, 커버리지 보고서, 예외 사항 문서, 그리고 문제 해결 일정 등입니다. 에 명시된 패치 관리 정책은 역할, 일정, 예외 처리 절차 및 에스컬레이션 경로를 정의하는 것으로, 감사관이 가장 먼저 요청하는 문서가 되는 경우가 많으며, 이 문서가 누락된 것은 규정 준수 검토 시 흔히 발견되는 문제점입니다.

감사 대비는 일관된 기록 관리에서 시작됩니다. 패치를 배포할 때마다 다음과 같은 질문에 대한 답변이 담긴 기록이 생성됩니다:

• 어떤 서버들이 공격 대상이 되었나요?
• 어떤 패치가 배포되었나요?
• 배치는 언제 이루어졌나요?
• 성공률은 얼마였나요?
• 어떤 서버에 장애가 발생했으며, 어떤 조치들이 취해졌습니까?
• 어떤 서버들이 예외로 처리되었으며, 어떤 보완 통제 수단이 마련되어 있습니까?

패치 도구를 CMDB 및 ITSM 플랫폼과 통합하면 이러한 증거를 중앙 집중화할 수 있습니다. 감사인이 PCI 적용 대상 서버에 대한 패치 적용 현황을 요청할 때, 그 답변은 수동으로 스프레드시트를 대조하는 방식이 아니라 쿼리를 통해 제공됩니다.

예외 관련 문서에는 각별한 주의를 기울여야 합니다. 감사관들은 모든 서버에 즉시 패치를 적용할 수는 없다는 점을 이해하고 있습니다. 그들이 확인하고자 하는 것은 예외 사항이 추적되고, 위험 평가가 이루어지며, 이를 보완하는 통제 수단이 마련되어 있다는 증거입니다.

공급업체의 제약으로 인해 패치를 적용할 수 없는 서버의 경우, 이를 보완하기 위한 통제 수단으로 네트워크 분할이나 강화된 모니터링을 적용할 수 있습니다.

Tanium이 서버 패치 관리를 지원하는 방법

타늄(Tanium)의 자율 IT 플랫폼 ‘ ’은 서버 패치 관리를 지속적이고 데이터 기반의 프로세스로 접근합니다. 데이터베이스 스냅샷이나 예약된 스캔 주기에 의존하지 않고 엔드포인트에 직접 쿼리를 보내므로, 의사 결정은 마지막 스캔 당시의 상황이 아니라 현재의 실제 상황을 바탕으로 이루어집니다.

IT 운영 및 보안 팀은 단일 콘솔을 통해 Windows, Linux, macOS 전반에 걸쳐 어떤 서버에 패치가 누락되었는지, 어떤 서버가 패치 적용 준비가 되었는지, 그리고 어떤 서버의 패치 적용을 연기해야 하는지 등에 대한 최신 현황을 파악할 수 있습니다.

• 실시간 엔드포인트 가시성: Windows, Linux, macOS 전반에 걸쳐 주기적인 스캔 결과가 아닌, 요청 시 확인 가능한 최신 패치 상태
• 위험 기반 우선순위 지정: 취약점 데이터를 EPSS, CISA KEV, 자산 중요도 및 신뢰도 점수와 결합하여 위험을 가장 크게 줄일 수 있는 부분에 노력을 집중합니다.
• 신뢰도 점수 (Windows): Windows 패치 배포 시, 광범위한 배포에 앞서 설치 성공률, 충돌 빈도 및 성능 지표를 기반으로 한 배포 영향에 대한 예측적 통찰력을 제공합니다. 이 점수는 참여 고객들의 익명화된 배포 텔레메트리 데이터에서 도출된 것으로, 가정이 아닌 실제 패치 동작을 반영합니다.
• 링 기반 점진적 배포: 확장하기 전에 신뢰도 기준에 따라 결과를 검증하는 단계별 배포 방식으로, 핵심 서버는 마지막에 패치를 적용하므로, 운영 환경 및 비즈니스 핵심 시스템은 해당 시스템에 적용되기 전에 이전 링에서 이루어진 검증의 이점을 누릴 수 있습니다.
• 관리형 자동화 플레이북: 운영자 승인 단계와 완전한 감사 추적이 포함된, 조건 기반의 다단계 워크플로우
• 용 타사 소프트웨어 패치: 공급업체 사이트에서 수동으로 패키지를 가져올 필요 없이 애플리케이션 패치 및 타사 업데이트를 위한 내장 템플릿 제공
• Tanium Guardian 위협 인텔리전스: Tanium VERT를 기반으로 수많은 중대한 취약점 및 제로데이 취약점에 대한 시기적절한 경고와 맞춤형 해결 지침을 제공하며, 새로운 위협을 파악하여 도구를 전환할 필요 없이 콘솔로 직접 구체적인 해결 조치를 전달합니다.
• 폐쇄형 검증: 관리 대상 엔드포인트 전반에 걸쳐 패치 상태를 배포 후 확인하고, 설치에 실패한 사례를 신속하게 파악합니다.
• 규정 준수 평가: PCI, HIPAA, SOX 및 기타 프레임워크와 관련된 기술적 통제 사항에 부합하는 SCAP 및 OVAL 기반 평가로, 콘텐츠가 매일 업데이트됩니다.
• 감사 준비를 위한 보고: 예외 사항 추적 및 규정 준수 대시보드가 포함된 조직 및 기기 수준 보고서
• ITSM 통합: ServiceNow 및 기타 ITSM 도구와 연동된 워크플로우를 통해 티켓 상태를 자동으로 업데이트합니다.
• AI 지원 운영: 엔드포인트 데이터, 조사 및 소프트웨어 관리를 위한 자연어 쿼리 . ‘휴먼-인-더-루프(human-in-the-loop)’ 방식의 승인 절차를 통해 자동화된 조치의 통제 및 감사 가능성을 보장합니다.

여기에 설명된 기능 및 결과는 Tanium 제품 설명서, 검증된 고객 사례 연구 및 실제 사용 사례를 바탕으로 합니다. 실제 결과는 배포 환경, 구성 및 조직의 성숙도에 따라 달라질 수 있습니다.

실제 결과: 서버 패치 준수 여부를 확인하는 단일 신뢰할 수 있는 정보원

Tanium을 도입하기 전, Honeywell은 팀 전반에 걸쳐 일관되게 규정 준수 여부를 측정할 수 있는 신뢰할 만한 방법이 없었습니다. 보안 팀과 IT 운영 팀은 각각 서로 다른 지표를 추적했고, 수치에 대한 의견 불일치는 빈번하게 발생했습니다.

Tanium은 양 팀 모두에게 동일한 데이터를 확인할 수 있는 기능을 제공했기 때문에, 보안 부서에서 나온 것이든 IT 운영 부서에서 나온 것이든 규정 준수 수치는 일관성을 유지했습니다. 이러한 일관성 덕분에 허니웰 IT 팀은 고위 경영진과 서비스 책임자 모두에게 정확한 수치를 보고할 수 있는 자신감을 갖게 되었습니다.

[사례 연구 읽어보기]

”Tanium을 사용하기 전에는 패치 준수율이 낮았습니다. 이제 Tanium을 도입한 덕분에, 3개월 연속으로 패치 준수율이 90%를 넘어섰습니다. 그건 중요한 점입니다.”

허니웰 IT 이사 마니쉬 초프라

서버 패치 관리 자주 묻는 질문

서버 패치 작업에는 일반적인 패치 관리 가이드에서 종종 간과하는 조정상의 어려움이 수반됩니다. 다음은 기업 팀이 서버 패치 프로그램을 구축하거나 개선할 때 자주 묻는 질문들입니다.

서버 패치와 엔드포인트 패치는 어떻게 다른가요?

서버는 일반적으로 유지보수 시간이 매우 제한적인 24/7 개의 워크로드를 처리하는 반면, 엔드포인트는 사용자의 업무 중단 시간 동안 재부팅할 수 있습니다. 또한 서버 간에는 더 복잡한 상호 의존성이 존재하기 때문에, 한 서버에 적용된 패치가 다른 서버에서 실행 중인 애플리케이션에 영향을 미칠 수 있습니다.

서버 패치 실패로 인한 영향 범위는 대개 엔드포인트 패치 실패보다 넓기 때문에, 팀들이 테스트, 스테이징 및 롤백 계획을 수립하는 방식에도 변화가 생깁니다.

서버는 패치를 적용하지 않은 상태로 얼마나 오랫동안 안전하게 가동될 수 있나요?

정답은 하나만 있는 게 아닙니다. CISA KEV 목록에 포함된 중대한 취약점은 공격자들이 이를 적극적으로 악용하고 있으므로 즉각적인 조치가 필요합니다. 그 외의 취약점의 경우, 대응 일정은 서버의 노출 정도, 보완 통제 조치, 비즈니스상의 제약 조건 등의 요인에 따라 달라집니다.

규정 준수 요건은 프레임워크 와 위험 상황에 따라 다릅니다. PCI DSS의 경우, 조직은 일반적으로 위험도에 기반하여 패치 SLA를 운영에 반영하며(대개 고위험 취약점의 경우 약 30 일을 목표로 하고, 저위험 문제의 경우 더 긴 기간을 설정함), 이에 더해 문서화된 예외 사항 및 보완 통제 조치를 함께 적용합니다.

설정 기간을 초과하는 팀은 보안 위험과 감사 지적 사항을 모두 초래합니다.

서버에 예정된 일정에 따라 패치를 적용할 수 없는 경우에는 어떻게 되나요?

예외 사항을 기록하고, 잔여 위험을 평가하며, 보완 통제를 시행하십시오. 보완 조치로는 노출을 제한하기 위한 네트워크 분할, 악용 시도를 탐지하기 위한 모니터링 강화, 또는 취약점으로 인한 영향을 완화하는 애플리케이션 수준 제어 등이 포함될 수 있습니다. 감사관들은 이러한 문서와 더불어 향후 시정 조치를 위한 계획도 제출되기를 기대하고 있습니다.

상시 가동되는 서버에서 재부팅이 필요한 패치는 팀에서 어떻게 처리하나요?

선택 사항으로는 라이브 패치 기술(특정 배포판 및 지원 계약에 따라 일부 리눅스 커널 업데이트 에서 이용 가능), 재부팅 시간대 동안 중복 서버로의 페일오버, 또는 트래픽이 적은 시간대에 재부팅을 예약하고 관련 당사자에게 알리는 방법 등이 있습니다.

올바른 접근 방식은 서버의 역할, 조직의 가동 중단 허용 범위, 그리고 중복 구성이 마련되어 있는지 여부에 따라 달라집니다. 일부 보안 업데이트는 적용을 위해 단순히 재부팅이나 서비스 재시작만 필요로 하며, 이러한 현실에 대비하는 것은 서버 패치 관리의 일환으로 간주됩니다.

설치만 되고 적용되지 않은 패치는 여전히 취약점을 노출시킨다. 실제로, 특히 클러스터 시스템이나 비즈니스에 필수적인 서비스의 경우, 패치 배포 자체가 아니라 재부팅 조율이 종종 진정한 병목 현상이 됩니다.

프로덕션 서비스의 경우, 패치 계획에는 롤백 기준과 복구 경로(예: 적절한 경우 스냅샷, 또는 클러스터 및 고가용성(HA) 환경에서의 장애 조치)도 포함되어야 합니다.

기업 규모에서 서버 패치 작업을 수행하려면 단순한 체크리스트만으로는 부족합니다. 이를 위해서는 실시간 가시성, 위험 기반 우선순위 지정, 단계적 배포, 그리고 패치가 실제로 취약점을 줄였는지 확인하는 과정이 필요합니다.
Tanium은 이러한 기능을 단일 플랫폼에 통합하여, IT 및 보안 팀이 추측에 의존하지 않고 확신을 가지고 서버에 패치를 적용할 수 있도록 지원합니다. 에서 무료 데모를 예약하고 오늘 바로 Tanium의 실제 작동 모습을 확인해 보세요.