모든 조직은 패치를 적용합니다. 이를 꾸준히 실천하는 사람은 거의 없다. 이 두 현실 사이의 괴리에서 보안 침해가 발생하고, 감사가 실패하며, IT 팀은 이미 알려진 취약점이 왜 수개월 동안 방치되었는지 설명하느라 허둥지둥하게 됩니다.
패치 관리 정책이란, 조직이 보안 취약점을 줄이고, 규정 준수 노력을 지원하며, 시스템 중단을 방지하기 위해 소프트웨어 업데이트를 식별, 우선순위 지정, 테스트 및 배포하는 방법을 정의한 문서화된 체계입니다. 효과적인 정책은 현재의 위협에 대처할 뿐만 아니라, IT 환경이 점점 더 복잡해짐에 따라 조직이 이에 유연하게 적응할 수 있도록 준비시켜 줍니다.
이것이 없다면, 패치 작업은 사후 대응에 급급한 상황이 되어 팀마다 일관성이 떨어지고, 감사가 어려우며, 중대한 취약점이 발견되었을 때 대응이 더뎌지게 됩니다. 패치 관리 정책은 조직이 제대로 관리되고 있기를 바라는 것과 실제로 그렇다는 것을 확실히 아는 것의 차이입니다.
이 가이드에서는 정책을 수립하기 위한 5단계 절차, 문서 자체에 포함해야 할 내용, 그리고 ISO 27001 및 NIST와 같은 규정 준수 프레임워크에 따라 접근 방식을 조정하는 방법을 단계별로 안내합니다.
패치 관리 정책이란 무엇인가요?
패치 관리 정책이란, 조직이 IT 환경 전반에 걸쳐 소프트웨어 업데이트를 식별, 확보, 테스트 및 배포하는 방법을 정의한 문서화된 지침 및 절차의 집합을 말합니다. 의 패치 관리( )는 업데이트를 적용하는 실무적인 과정을 의미하는 반면, 정책( )은 의 패치 관리 프로세스( )가 어떻게 운영될지를 규정하는 거버넌스 프레임워크입니다.
이렇게 생각해 보세요. 패치 관리는 바로 여러분의 팀이 담당하는 업무입니다. ‘ ’ 정책( )은 해당 업무를 일관성 있게, 책임감 있게, 그리고 귀사의 위험 허용 범위와 부합하도록 수행할 수 있도록 보장하는 지침서입니다.
포괄적인 정책은 일반적으로 온프레미스, 클라우드 및 하이브리드 환경에 걸쳐 운영 체제, 앱, 펌웨어 및 연결된 기기를 모두 포함합니다. 또한 식별 단계부터 검증 단계에 이르기까지 패치 수명 주기의 각 단계에 대한 책임 주체를 명시하고 있습니다.
이 정책 자체만으로는 사용자의 패치 적용 도구나 워크플로를 대체하지는 않습니다. 이를 통해 대규모 환경에서 패치 적용을 효과적으로 수행할 수 있는 체계와 책임 체계를 마련해 줍니다.
많은 조직에서 패치 관리 정책은 보다 광범위한 위험 관리 및 보안 정책 프레임워크에 공식적으로 통합되어, 패치 적용 의무가 접근 제어, 사고 대응, 데이터 보호 요구 사항과 동등한 조직적 중요성을 부여받도록 보장하고 있습니다.
이 정의는 해당 정책이 무엇인지 명시하고 있습니다. 다음 내용에서는 이것이 왜 중요한지 설명합니다.
조직에 패치 관리 정책이 필요한 이유
효과적인 패치 관리 정책은 현대 사이버 보안 및 IT 운영의 초석입니다. 공식적인 정책이 없으면, IT 환경 전반에 걸친 패치 작업은 일관성이 떨어지는 경향이 있습니다. 어떤 팀은 신속하게 패치를 적용하지만, 다른 팀은 그렇지 않습니다. 어떤 시스템은 주목을 받지만, 다른 시스템은 소외되곤 합니다. 그 결과 보안 태세가 고르지 않게 되고, 조만간 규정 준수 문제가 발생할 우려가 커집니다.
문서화된 정책은 체계, 책임 소재, 그리고 명확한 기대치를 제시함으로써 일관성 부족 문제를 해결합니다:
- 보안 위험 감소: 패치가 적용되지 않은 시스템은 알려진 패치되지 않은 취약점을 표적으로 삼는 랜섬웨어 공격을 비롯한 사이버 공격의 가장 흔한 침투 경로 중 하나로 남아 있습니다. 정책은 조직이 취약점을 일관되고 신속하게 해결하도록 지원하여 보안 침해 위험을 줄여줍니다.
- 규정 준수 요건: GDPR, HIPAA, PCI-DSS와 같은 규정은 조직이 안전한 시스템을 유지하도록 요구하며, 여기에는 적시에 패치를 적용하는 것도 포함됩니다. 정책은 감사인이 기대하는 관련 문서를 제공합니다.
- 운영 일관성: 패치 적용 방식과 시기를 표준화하면 예기치 않은 가동 중단을 초래할 수 있는 즉흥적인 업데이트를 방지할 수 있습니다.
- 책임 소재: 이 정책은 패치 라이프사이클의 각 단계에 대한 책임 소재를 명확히 함으로써 혼란을 줄이고, 팀이 절차를 누락하는 것을 방지하도록 돕습니다.
만드는 방법은 다음과 같습니다.
5 단계로 알아보는 패치 관리 정책 수립 방법
패치 관리 정책을 수립한다는 것은 보안 모범 사례를 문서화되고 실행 가능한 체계로 전환하는 것을 의미합니다. 다음의 5단계는 귀사의 특정 환경에 맞는 정책을 수립하는 과정을 안내해 드립니다.
[패치 관리 모범 사례를 준수하면 조직의 보안 태세를 강화하는 데 어떻게 도움이 되는지 알아보세요]
1. 정책의 범위와 목표를 정의한다
먼저 해당 정책이 어떤 자산을 보장하는지 명확히 정의하십시오. 온프레미스, 클라우드, 하이브리드 등 모든 환경에 걸쳐 있는 모든 시스템, 애플리케이션, 운영 체제 및 장치 유형을 포함합니다. 용 타사 소프트웨어를 놓치지 마세요. 이는 취약점이 발생하는 흔한 원인 중 하나입니다.
목표는 구체적이고 측정 가능할 때 가장 효과적이다. 예를 들어, “패치 출시 후 48 시간 이내에 중대한 취약점에 대한 노출을 줄인다” 또는 “SLA 기간 내에 모든 운영 시스템에서 95 %의 패치 적용률을 달성한다”와 같은 경우입니다.
2. 역할과 책임 정립
패치 관리 라이프사이클의 각 단계에 대한 책임 주체를 명확히 파악해야 하며, 여기에는 기술 팀은 물론, 자신의 시스템에 영향을 미치는 배포를 승인해야 할 수도 있는 비즈니스 이해관계자들도 포함됩니다. 명확한 책임 소재가 없으면 패치 작업이 지체됩니다. 누군가는 항상 다른 누군가가 그 일을 처리하고 있을 거라고 가정하곤 한다.
| 역할 | 책임 |
|---|---|
| IT 운영 | 패치 배포 및 검증 |
| 보안팀 | 취약점 식별 및 우선순위 지정 |
| 애플리케이션 소유자 | 시스템에 대한 시험 및 승인 |
| 최고 후원자 | 감독, 자원 배분 및 상급 기관 보고 |
이러한 역할을 명확히 정의함으로써, 모든 계층의 IT 담당자가 패치 적용 라이프사이클 내에서 자신의 책임을 이해하고, 시의적절한 배포가 필요한 상황에서 임시방편적인 지시를 기다리지 않고도 즉각적으로 대응할 수 있게 됩니다.
3. 위험 기반의 패치 적용 일정 및 SLA 설정
패치를 심각도와 비즈니스 영향도에 따라 분류한 다음, 목표 수정 일정을 수립하십시오. 일반적인 접근 방식:
| 패치 심각도 | 트리거 예시 | 일반적인 SLA |
|---|---|---|
| 중요 | 실제 환경에서 활동 중인 익스플로잇 | 24-48 시간 |
| 높음 | 알려진 취약점이지만, 현재 악용 사례는 없음 | 7 일 |
| 중간 | 중간 수준의 위험, 제한된 노출 | 14-30 일 |
| 낮음 | 사소한 버그 수정 | 다음 유지보수 기간 |
SLA는 절대적인 기준이 아니라 가이드라인의 역할을 합니다. 효과적인 정책은 실제 위험이 변화할 때, 특히 악용 활동이 증가하거나 시스템의 노출 범위가 예기치 않게 확대된 고위험 취약점의 경우, 상황에 따라 유연하게 조정될 수 있도록 합니다.
4. 문서 테스트 및 배포 절차
모든 패치는 운영 시스템에 적용되기 전에 전용 테스트 환경에서 테스트를 거쳐야 합니다. 이러한 패치 테스트는 기존 소프트웨어 구성과의 호환성을 평가하는 데 도움이 되며, 패치로 인해 운영 중단이 발생하거나 종속 시스템과 예기치 못한 충돌이 일어날 위험을 줄여줍니다.
배포를 시작하기 전에 필수 백업 절차를 포함하고, 예기치 않은 시스템 불안정성을 초래하는 패치가 발생할 경우 최소한의 중단으로 신속하게 원상복구할 수 있도록 명확한 롤백 절차를 문서화해야 합니다. 패치를 먼저 소수의 시스템에 적용한 다음 점진적으로 확대해 나가는, 단계별 또는 링 기반 배포 절차를 문서화하십시오.
의 링 기반 배포 방식은 문제가 광범위한 문제로 번지기 전에 이를 파악하는 데 도움이 될 수 있습니다. 또한 이 정책에는 예정된 패치 배포에 앞서 영향을 받는 팀과 최종 사용자에게 언제, 어떤 방식으로 알릴 것인지 명시하는 통지 요건이 포함되어야 합니다.
5. 예외 처리 및 검토 절차 수립
모든 시스템에 즉시 패치를 적용할 수 있는 것은 아닙니다. 구형 소프트웨어, 운영상의 제약이 있는 중요 시스템, 또는 복잡한 애플리케이션 상호 의존성으로 인해 때로는 즉각적인 패치 적용이 현실적으로 어려울 수 있습니다.
이 정책에는 예외 사항의 요청, 승인 및 추적을 위한 공식적인 절차가 포함되어 있습니다. 패치 적용이 연기된 모든 시스템에 대해서는 보완 통제 조치(예: 네트워크 분할 또는 모니터링 강화 등)가 문서화되어 있습니다. 마지막으로, 해당 정책 자체는 그 적절성을 유지하기 위해 정기적으로, 대개 매년 또는 중대한 보안 사고가 발생한 후에 검토됩니다.
범위 정의, 역할 배정, 일정 수립, 절차 문서화, 예외 사항 관리라는 5단계 프로세스를 따름으로써, 귀사는 사후 대응적이고 일관성 없는 접근 방식에서 선제적이고 체계적인 접근 방식으로 전환할 수 있습니다. 다음 과제는 그 구조를 팀원들이 실제로 활용할 수 있는 정책 문서에 반영하는 것입니다.
패치 관리 정책 문서에 포함되어야 할 내용
체계적으로 잘 구성된 정책 문서는 거버넌스 체계이자 운영 지침의 역할을 동시에 수행합니다. 다음은 포함해야 할 항목들입니다:
- 범위 및 적용 대상: 이 정책이 적용되는 자산, 환경, 운영 체제 및 팀.
- 역할 및 책임: 패치의 모니터링, 테스트, 승인, 배포 및 검증에 대한 명확한 책임 소재.
- 패치 분류 기준: 위험 수준 및 비즈니스 영향도에 따라 패치를 분류하는 공식 시스템입니다.
- 테스트 및 검증 요구 사항: 운영 환경 배포를 위한 비운영 환경 테스트 의무 사항 및 성공 기준.
- 배포 일정 및 유지보수 시간대: 프로덕션 배포에 대한 승인된 기간, 커뮤니케이션 요건, 그리고 시스템 재시작이나 일시적인 서비스 중단으로 인해 영향을 받을 수 있는 최종 사용자에 대한 사전 통지 사항.
- 변경 관리 조정: 운영 시스템에 영향을 미치는 패치 배포는 변경 사항이 적용되기 전에 적절한 승인, 문서화 및 이해관계자 알림이 이루어지도록 조직의 변경 관리 프로세스를 통해 조정되어야 합니다.
- 긴급 패치 적용 절차: 의 제로데이 취약점 또는 진행 중인 악용 사례를 해결하기 위한 중요 패치에 대한 신속 처리 절차입니다.
- 예외 및 유예 절차: 보완 통제를 포함하여 예외를 요청, 승인 및 추적하기 위한 공식 절차.
- 보고 및 규정 준수 문서: 패치 상태 보고서 및 예외 로그를 포함하여 감사 추적을 위해 필요한 기록은 무엇입니까?
- 정책 검토 주기: 정책이 얼마나 자주 검토 및 업데이트될지.
각 섹션은 구체적인 조치를 안내할 만큼 상세하면서도, 여러분의 환경적 현실을 반영할 수 있을 만큼 유연합니다. 처음부터 시스템을 구축하는 조직의 경우, 이러한 섹션이 미리 구성되어 있는 패치 관리 정책 템플릿을 바탕으로 시작하고, 이후 조직의 구체적인 자산 현황, 위험 허용 범위 및 규정 준수 의무를 반영하도록 이를 맞춤 설정하는 것이 도움이 될 수 있습니다.
문서 그 자체 외에도, 정책이 실제로 효과적으로 작동하도록 돕는 몇 가지 운영 관행이 있습니다.
소프트웨어 패치 정책에 대한 모범 사례
잘 작성된 정책은 성공적으로 이행될 때만 효과를 발휘한다. 다음과 같은 관행들은 정책과 실행 간의 격차를 해소하는 데 도움이 됩니다.
패치 탐지 및 배포 자동화
자동화 는 수작업 부담을 줄이고, 인적 오류를 최소화하며, 일관된 정책 적용을 보장합니다. 최신 패치 관리 도구는 누락된 패치를 자동으로 검색하고, 정책에 따라 우선순위를 지정하며, 수동 개입 없이 일관된 패치 적용 일정을 준수하도록 할 수 있습니다.
패치 관리를 취약점 관리와 통합
패치 적용은 포괄적인 취약점 관리 프로그램 내에서 핵심적인 시정 조치입니다. 패치 관리 정책은 취약점 우선순위 지정 워크플로우와 긴밀하게 연계되어야 합니다. 통합을 통해 취약점이 조직에 미치는 실제 위험도를 기준으로 패치를 적용할 수 있으며, 단순히 공급업체가 제시한 일반적인 심각도 점수만 따르지 않게 됩니다.
단계적 도입을 통해 위험을 줄이세요
전체 기업에 패치를 한꺼번에 배포하는 것은 위험합니다. 더 나은 접근 방식: 단계별 또는 단계적 배포. 먼저 규모가 작고 시스템에 미치는 영향이 적은 시스템 그룹부터 시작하여 문제를 모니터링한 뒤, 점차 확대해 나가십시오. 단계적 도입을 통해 잠재적인 문제가 광범위한 서비스 중단을 초래하기 전에 미리 파악할 수 있습니다.
정확한 자산 목록을 관리한다
자신이 가지고 있다는 사실조차 모르는 문제는 해결할 수 없다. 완벽하고 지속적으로 업데이트되는 자산 목록( )은 효과적인 패치 관리 프로그램의 토대가 됩니다. 귀사의 정책은 적용 범위를 정의하고 규정 준수 여부를 확인하기 위해 정확한 재고 현황에 의존합니다.
정기적인 감사를 실시한다
시스템을 정기적으로 점검하여 패치가 올바르게 적용되었는지, 그리고 모든 엔드포인트가 정책을 준수하고 있는지 확인하십시오. 감사는 프로세스의 미비점, 간과되어 패치가 적용되지 않은 시스템, 그리고 시정 조치가 필요한 실패한 배포 사례를 파악하는 데 도움이 됩니다.
많은 조직에서 패치 관리는 단순한 보안 모범 사례를 넘어서는 의미를 지닙니다. 이는 규정 준수 요건으로, 문서화되고, 이행되며, 감사 가능해야 합니다.
정책을 규정 준수 체계에 부합하도록 조정하기
여러 규제 체계와 업계 표준에서는 공식적인 패치 관리 관행을 의무화하거나 적극 권장하고 있습니다.
ISO 27001 패치 관리 정책 요구사항
정보 보안 관리에 관한 ISO 27001 표준은 조직이 기술적 취약점 관리를 위한 통제 조치를 마련할 것을 요구하고 있다. 문서화되고 엄격히 시행되는 패치 관리 정책은 ISO 27001 요건 준수를 뒷받침하는 핵심 요소이며, 인증을 추진하는 모든 조직에 필수적입니다.
NIST 패치 관리 지침
미국 국립표준기술연구소(NIST)는 특별 간행물 800-40호인 ‘ : 기업 패치 관리 가이드( Guide to Enterprise Patch Management)’()를 통해 포괄적인 지침을 제공하고 있습니다. 정책을 ‘ ’ NIST 지침( )에 부합하도록 조정하는 것은 연방 기관과 민간 부문 조직 모두에게 널리 인정받는 모범 사례입니다.
PCI DSS, HIPAA 및 GDPR 패치 적용 시 고려 사항
PCI DSS, HIPAA, GDPR과 같은 규제 체계는 모두 조직이 알려진 보안 취약점을 해결함으로써 민감한 데이터를 보호할 것을 요구합니다. 예를 들어, PCI DSS는 중요한 보안 패치 가 출시된 지 한 달 이내에 설치되어야 한다고 명시하고 있습니다. 공식적인 패치 관리 정책과 이를 통해 생성된 문서는 감사 시 규정 준수 노력을 뒷받침할 수 있습니다.
| 프레임워크 | 패치 요구 사항 |
|---|---|
| ISO 27001 | 기술적 취약점 관리 통제 조치 |
| NIST SP 800-40 | 패치 수명 주기 모범 사례 |
| PCI DSS | 30 일 이내에 적용해야 할 중요 패치 |
| HIPAA | 시스템 취약점에 대한 신속한 조치 |
| GDPR | 패치 적용을 포함한 적절한 보안 통제 조치 |
문서상으로는 규정 준수 요건을 충족하는 정책이라도 실제로는 이를 이행해야 하며, 바로 그 지점에서 도구의 활용이 결정적인 요소가 됩니다.
정책 이행을 위한 도구 및 자동화
패치 관리 정책은 이를 제대로 이행할 수 있는 능력에 따라 그 효과가 결정됩니다. 기업 규모에서는 정책 적용을 위해, 엔드포인트 상태를 지속적으로 파악할 수 있고 위험 및 환경 변화에 따라 일관된 정책 적용을 지원하는 패치 관리 소프트웨어가 필요합니다.
패치 관리 플랫폼의 기능
효과적인 플랫폼은 환경 전반에 걸친 패치 상태를 실시간으로 파악할 수 있게 해주며, 정책 기반의 자동화를 지원하여 통제되고 반복 가능한 방식으로 위험을 해소합니다. 이 도구는 Microsoft Windows, Mac, Linux 등 사용자의 환경에 있는 주요 운영 체제를 지원해야 하며, 자동화된 정책 적용의 일환으로 Microsoft의 ‘패치 화요일(Patch Tuesday)’ 릴리스와 같은 벤더 업데이트 피드를 처리할 수 있어야 합니다.
엔드포인트 및 취약점 관리와의 통합
가장 효과적인 패치 관리 도구는 고립된 방식으로 작동하지 않습니다. 이 솔루션들은 귀사의 광범위한 ‘ ’ 엔드포인트 관리 및 취약점 관리 솔루션과 연동되어, 단일 콘솔에서 위험 식별, 패치 배포, 수정 조치 확인에 이르는 워크플로를 간소화함으로써, 대규모 환경에서 수정 조치를 지연시키는 수동적인 업무 이관을 없애줍니다.
보고 및 감사 추적 요건
선택하신 도구는 정책의 SLA 준수 여부를 추적하는 데 도움이 되는 상세한 보고서를 생성합니다. 이 기능은 어떤 패치가 적용되었는지, 언제 적용되었는지, 그리고 어떤 시스템이 여전히 규정 미준수 상태인지에 대한 완전한 감사 추적을 제공하며, 여기에 문서화된 예외 사항도 포함됩니다.
타늄(Tanium)의 자율 IT 플랫폼은 이러한 정책 적용 요구 사항을 충족하도록 설계되었습니다.
Tanium이 패치 관리 정책 적용을 지원하는 방법
의 Tanium Autonomous IT 플랫폼( )은 실시간 엔드포인트 인텔리전스와 통제된 자동화 기능을 결합하여 정책 중심의 패치 관리 방식을 구현합니다. 이를 통해 IT 및 보안 팀은 분산된 도구들 간에 조율할 필요 없이, 현재의 위험 상황과 엔드포인트 상태를 기반으로 패치 정책을 적용할 수 있는 공통의 기반을 확보할 수 있습니다.
팀은 단일 콘솔을 통해 온프레미스, 원격 및 클라우드 기반 장치 전반의 현재 패치 상태를 실시간으로 확인하고, 취약점 및 노출 데이터를 바탕으로 패치의 우선순위를 정하며, 비즈니스 중단을 최소화하는 링 기반 배포 방식을 통해 패치 적용을 자동화할 수 있습니다. 정책에 정의된 SLA 및 예외 처리 절차는 수동으로 상호 참조할 필요 없이, 실제 엔드포인트 데이터에 대해 직접 적용할 수 있습니다.
[클라우드 환경이 패치 관리 방식을 어떻게 변화시키는지, 그리고 끊임없이 변화하는 워크로드 전반에 걸쳐 가시성과 규정 준수를 유지하기 위해 무엇이 필요한지 알아보세요]
Tanium은 엔드포인트 관리 및 보안 운영을 하나의 플랫폼에 통합하여, 정책 정의와 정책 실행 간의 격차를 해소합니다. 패치 배포는 승인 워크플로우와 유지보수 기간을 거쳐 진행됩니다. 준수 증빙 자료는 감사 시점에 일괄적으로 수집되는 것이 아니라 지속적으로 생성됩니다.
그 결과, 자체 규칙에 따라 일관되고, 검증 가능하며, 대규모로 작동하는 패치 프로그램이 탄생했습니다.
패치 관리 정책에 관한 자주 묻는 질문
패치 관리 정책을 수립하고 유지하는 과정에서는, 특히 규정 준수 요건을 충족해야 하거나 복잡한 IT 환경을 운영하는 조직의 경우 실질적인 문제들이 제기됩니다. 다음은 자주 묻는 질문에 대한 답변입니다.
패치 관리 정책은 얼마나 자주 검토해야 합니까?
대부분의 조직은 매년 또는 중대한 보안 사고, 대규모 인프라 변경, 새로운 규정 준수 요건의 도입과 같은 중대한 사건이 발생한 후에 패치 관리 정책을 검토합니다.
패치 관리 정책과 패치 관리 계획의 차이점은 무엇인가요?
정책이란 규칙, 역할 및 요구 사항을 정의하는 상위 수준의 거버넌스 문서입니다. 계획이란 정책을 실행하는 데 사용되는 구체적인 절차, 일정 및 도구를 명시한 상세한 운영 문서입니다.
원격 팀 전반에 걸쳐 패치 관리 정책을 어떻게 시행할 수 있을까요?
분산된 인력에 대한 정책 적용을 위해서는 물리적 위치나 네트워크 연결 상태와 관계없이 모든 기기에 대한 실시간 가시성과 제어 기능을 제공하는 중앙 집중식 엔드포인트 관리 도구가 필요합니다.
패치 관리 정책의 효과를 측정하는 KPI는 무엇인가요?
추적해야 할 주요 지표로는 중대한 취약점에 대한 평균 패치 소요 시간(MTTP), 정책 SLA를 준수하는 엔드포인트의 비율, 그리고 미해결 패치 예외 사항의 수와 경과 기간 등이 있습니다.
패치를 적용할 수 없는 레거시 시스템에 대해서는 정책이 어떻게 다루고 있나요?
이 정책에 따르면, 패치 적용이 불가능한 시스템은 예외 처리 절차에 따라 문서화되어야 하며, 네트워크 분할, 보다 엄격한 접근 제어, 보안 문제에 대한 강화된 모니터링과 같은 보완적 통제 수단을 통해 보호되어야 합니다.
[기존 패치 및 취약점 관리 도구에서 최신 솔루션으로 전환할 때 얻을 수 있는 5가지 주요 이점을 살펴보세요]
잘 마련된 정책은 문서상으로는 올바른 패치 적용이 어떤 모습이어야 하는지를 명확히 규정합니다. 해당 문서와 수천 개의 엔드포인트에서 실제로 발생하는 상황 간의 격차를 해소하는 것이 바로 대부분의 조직이 어려움을 겪는 부분이며, 이때 정책 자체만큼이나 정책 이면을 뒷받침하는 도구의 중요성이 부각됩니다.
Tanium의 자율 IT 플랫폼은 성숙한 패치 정책이 대규모로 작동하는 데 필요한 실시간 엔드포인트 가시성과 통제된 링 기반 배포를 기반으로 구축되었습니다.
자사 환경에서 이 솔루션이 실제로 어떻게 작동하는지 확인해 보시려면, 를 방문하여 맞춤형 Tanium 데모를 예약해 주십시오.

