Mac patch management: The realities of macOS patching

기업 환경에서의 Mac 도입이 가속화되고 있지만, IT 관리 도구, 특히 의 패치 관리 기능은 이에 항상 발맞추지 못하고 있다. 그룹 정책, WSUS, System Center Configuration Manager(SCCM) 등을 포함하여 Windows에서 작동하는 워크플로는 macOS에 그대로 적용되지 않습니다. 도구 관련 전제가 단순히 다를 뿐입니다.
애플의 업데이트 아키텍처는 다른 전제를 바탕으로 작동합니다. macOS에서는 MDM을 통해 배포된 구성 프로파일이 업데이트 강제 적용 및 연기 정책을 처리합니다. 업데이트 배포는 Apple의 소프트웨어 업데이트 서비스가 직접 담당합니다. WSUS의 ‘승인 및 스테이징’ 워크플로우와 동등한 기본 기능은 없기 때문에, 바로 그 이유로 타사 도구가 종종 그 공백을 메우고 있습니다. 또한 ‘Rapid Security Response’와 같은 메커니즘은 Windows 관리자들이 이전에 접해 보지 못했을 수도 있는 패치 적용 주기를 도입합니다.

이 가이드에서는 macOS가 업데이트를 제공하는 방식, 가시성 격차가 발생하는 지점, Apple 취약점을 Windows CVE와 함께 우선순위를 정하는 방법, 그리고 Mac 패치 적용을 통합된 크로스 플랫폼 프로그램에 통합하기 위해 필요한 사항을 다룹니다.

macOS의 업데이트 제공 방식

Mac 패치 관리란 Mac 기기 및 macOS 엔드포인트에 대한 운영 체제 및 애플리케이션 업데이트를 식별하고, 테스트하며, 배포하는 과정을 말합니다. 그룹 정책(Group Policy)과 WSUS를 통해 중앙 집중식 제어가 이루어지는 Windows 환경과 달리, macOS는 Apple의 소프트웨어 업데이트 프레임워크와 MDM 솔루션을 활용합니다.

애플은 ‘소프트웨어 업데이트’ 서비스를 통해 macOS 업데이트를 배포합니다. 엔드포인트는 자동으로 또는 사용자가 지정한 일정에 따라 확인됩니다. 기업 환경에서 MDM 솔루션은 등록된 Mac에 구성 프로파일과 업데이트 명령을 전송합니다.

[전체 엔드포인트 환경을 위한 반복 가능하고 확장 가능한 패치 프로그램을 구축하세요]

이러한 업데이트는 주요 운영 체제 릴리스부터 버그 수정, 성능 개선, 보안 패치를 포함하는 사소한 점 업데이트에 이르기까지 다양하며, 각각 기업 팀이 고려해야 할 긴급도 수준과 배포 사항이 다릅니다.

바로 이 부분에서 이 아키텍처는 Windows와 차이가 있습니다:

• 그룹 정책에 상응하는 기능이 없음: macOS는 MDM을 통해 제공되는 구성 프로파일을 사용하여 업데이트 동작, 연기 기간 및 설치 시점을 제어합니다. 최신 macOS 버전은 또한 애플이 XML 구성 프로파일의 후속 기술로 도입한 JSON 기반의 선언적 기기 관리(DDM)를 지원하며, 이를 통해 관리 대상 기기에 대한 안정성과 상태 보고 기능이 향상되었습니다.
• Apple Business Manager(ABM) 연동: ABM은 단순한 기기 등록 포털이 아닌, 기업용 Mac 관리의 중추적인 역할을 합니다. 또한 이는 애플 라이선스를 받은 앱 배포, 관리형 애플 ID, 연합 신원 인증을 위한 신뢰할 수 있는 정보의 원천이기도 합니다. ABM을 통해 등록된 관리 대상 기기는 자동 업데이트 및 원격 데이터 삭제 등 가장 광범위한 MDM 명령을 지원합니다. ABM 설정을 선택 사항으로 여기는 조직들은 대개 첫 번째 강제 OS 업데이트 배포 과정에서 ABM이 설정되지 않았다는 사실을 깨닫게 됩니다.
• 사용자 주도 업데이트 대 MDM을 통한 강제 업데이트: 관리되지 않는 Mac의 경우, 시스템 알림이나 ‘소프트웨어 업데이트’ 창을 통해 최종 사용자에게 업데이트 설치를 요청할 수 있습니다. 관리 대상 Mac은 MDM 명령을 통해 사용자 개입 없이도 자동 설치 또는 예약 배포를 수행할 수 있지만, 실제 동작은 칩 아키텍처와 macOS 버전에 따라 달라질 수 있습니다.

SCCM이나 Intune을 통해 세분화된 대상 지정 및 연기 정책을 적용하여 Windows 업데이트를 배포하는 데 익숙한 사용자라면, macOS 업데이트 관리가 기기의 감독 상태와 MDM 기능에 더 크게 좌우된다는 점을 알게 될 것입니다.

애플이 표준 업데이트를 제공하는 방식을 이해하는 것은 패치 방식을 완전히 바꿔놓을, 더 새롭고 빠른 메커니즘을 도입하기 위한 토대를 마련해 줍니다.

애플 신속 보안 대응(Apple Rapid Security Response)에 대해 알아보기

애플은 기존 업데이트 주기보다 더 빠르게 심각한 취약점을 해결하기 위해 macOS 벤츄라에 ‘신속 보안 대응(Rapid Security Responses)’ 기능을 도입했습니다. 이 패치들은 용량이 작고 설치가 빠르며, 대개 시스템을 완전히 재부팅할 필요도 없습니다.

실제로 애플은 RSR을 주로 WebKit과 Safari의 취약점을 패치하는 데 활용해 왔는데, 이는 신속한 대응이 가장 중요한 브라우저의 공격 표면이기 때문이다.

macOS 26,1 및 이후 버전에 대한 참고 사항: Apple은 macOS 26,1, iOS 26,1, iPadOS 26,1부터 이 메커니즘을 ‘배경 보안 개선(Background Security Improvements)’이라는 새로운 이름으로 발전시키고 있습니다.
근본적인 목적은 동일합니다. 즉, 정식 릴리스 사이에서 Safari, WebKit 및 기타 시스템 라이브러리와 같은 구성 요소에 초점을 맞춘, 가볍고 표적화된 보안 패치를 효율적으로 제공하는 것입니다.
애플은 ‘ ’ 애플 보안 릴리스 페이지에서 표준 업데이트와 ‘배경 보안 개선(Background Security Improvements)’에 대한 최신 목록을 공개하고 있습니다. 사용 중인 기기 군이 macOS 26,1을 실행 중이거나 해당 버전으로 업그레이드할 계획이라면, 에서 Apple의 보안 아키텍처 문서( )를 검토하여 배포 메커니즘의 작동 방식에 대한 최신 지침을 확인하시기 바랍니다.

현재 macOS 버전을 사용하는 기업용 Mac 기기를 관리하는 IT 관리자에게 RSR은 기회와 복잡성을 동시에 안겨줍니다:

• 더 빠른 보호: 애플이 실제로 악용되고 있는 제로데이 취약점을 식별하면, RSR을 통해 다음 예정된 macOS 점 릴리스 이전에 수정 사항을 제공할 수 있습니다.
• 변경 관리에 미치는 영향: RSR 패치가 일반적인 유지보수 시간대 외에 배포될 수 있습니다. 변경 자문 위원회 절차에 RSR 업데이트를 위한 신속 처리 절차를 도입하면 도움이 될 수 있습니다. RSR 패치는 일반적으로 시스템을 완전히 재부팅하지 않고도 설치되므로, 기존의 누적 업데이트에 비해 가동 중단 시간과 업무 차질을 최소화해 주며, 이로 인해 신속한 승인 절차를 정당화하기가 더 수월해집니다.
• MDM 정책 상호작용: MDM 구성 프로필을 통해 RSR을 연기할 수 있지만, 이렇게 하면 노출 기간이 연장됩니다. macOS 26,1 및 이후 버전에서 ‘백그라운드 보안 개선’에 대한 MDM 유예 동작이 다를 수 있으므로, 업그레이드 시 해당 MDM 공급업체의 최신 문서를 확인하시기 바랍니다.
• 롤백 기능: 누적 macOS 업데이트와 달리, RSR 패치는 호환성 문제를 일으키는 경우 제거할 수 있습니다. 롤백의 안정성은 MDM 플랫폼과 macOS 버전에 따라 다릅니다. MDM이 RSR 제거를 지원하는지 확인한 후에야 이를 확실한 복구 옵션으로 간주하십시오.

RSR은 애플이 기존의 업데이트 주기로는 현대적인 악용 시나리오의 속도를 따라잡기 어려울 수 있다는 점을 인식하고 있음을 반영합니다. 적절한 프로세스 조정을 통해, 거버넌스 통제 체계를 유지하면서도 이러한 가속화된 주기를 처리할 수 있도록 패치 프로그램을 구성할 수 있습니다.

업데이트 방식에 대해 살펴보았으니, 다음 과제는 패치가 필요한 모든 Mac을 실제로 파악할 수 있도록 하는 것입니다.

MDM 등록 누락 및 관리되지 않는 엔드포인트

귀사의 MDM 솔루션은 시스템에 등록된 기기에 대해서만 패치 상태를 보고합니다. BYOD(개인 기기 사용) 정책, 인수 통합, 또는 등록 실패 등으로 인해 등록되지 않은 모든 Mac은 패치 준수 데이터에서 사각지대를 형성합니다.

의 구버전 소프트웨어 가 설치된 관리되지 않는 Mac 한 대만으로도, 공격자가 초기 침투 경로를 확보할 경우 횡방향 이동의 진입점이 될 수 있습니다.

패치가 적용되지 않은 엔드포인트는 이미 잘 알려진 공격 경로이며, 어떤 기기가 최신 상태인지 파악할 수 없다면 보이지 않는 문제를 해결할 수 없습니다.

등록 격차는 단순히 관리상의 불편함 그 이상입니다. 이는 엔드포인트 보안에 있어 명백한 취약점입니다. 관리가 이루어지지 않는 모든 Mac은 패치 상태가 불분명하고, 취약점이 추적되지 않으며, 악용 위험에 대한 노출이 모니터링되지 않는 기기입니다.

또한 감사관이 패치 준수 여부에 대한 증빙 자료를 요청할 때, MDM 관리 대상 외의 기기는 보고서에 표시되지 않습니다.

등록 공백이 발생하는 일반적인 원인으로는 다음이 있습니다:

• BYOD 및 계약자 기기: 업무용으로 사용되는 개인용 Mac은 Apple의 사용자 등록(User Enrollment) 절차를 통해 등록할 수 있지만, 이는 자동 기기 등록(ADE)을 통해 등록된 기업 소유 기기와는 근본적으로 다른 관리 상태입니다. 두 가지 중 하나에서 얻을 수 있는 패치 가시성은 서로 다릅니다.

ADE와 사용자 등록 은 서로 다른 개념입니다. 애플은 개인이 직접 등록한 기기에서 MDM이 확인할 수 있는 내용과 수행할 수 있는 작업을 의도적으로 제한합니다. 관리 대상 앱은 컨테이너화되어 있으며, 기기 수준의 쿼리는 제한되고, 많은 MDM 명령은 아예 적용되지 않습니다. 이는 설계상 개인 정보 보호를 위한 구획입니다.

사용자가 직접 등록한 MacBook은 MDM 콘솔에 ‘등록됨’ 상태로 표시될 수 있지만, 패치 준수 여부 확인 목적상 사실상 인식되지 않을 수 있습니다. 등록이 곧 가시성을 의미한다는 가정이 아니라, 그러한 현실을 바탕으로 BYOD 정책을 수립하십시오.[/callOut]

• M&A 전환 과정: 인수된 기업들은 종종 서로 다른 관리 도구를 사용하거나 아예 관리 체계가 없는 자체 기기들을 보유하고 있는 경우가 많습니다.
• 등록 실패: 설정 과정에서 자동 등록에 실패한 기기가 IT 부서의 인지 없이 간과될 수 있습니다.
• 섀도우 IT: 일부 부서는 등록 절차를 완전히 생략하고 표준 절차를 거치지 않은 채 Mac을 구입하기도 합니다.

등록 격차를 해소하려면 MDM과 독립적으로 작동하는 탐색 기능을 갖춘 엔드포인트 관리 솔루션 이 필요합니다. 네트워크 스캔, 에이전트 기반 탐지 또는 ID 제공자와의 연동을 통해 관리 플랫폼에 상태를 보고하지 않는 Mac을 식별할 수 있습니다.

관리 대상이 아닌 장치를 파악한 후에는, 해당 문제를 해결하는 방법은 조직의 정책에 따라 달라집니다.

일부 팀은 네트워크 접속의 조건으로 등록을 의무화하고 있습니다. 다른 업체들은 완전한 MDM 등록 없이도 패치 상태를 파악할 수 있는 경량형 에이전트를 사용합니다.

가시성은의 토대입니다. 이것이 없다면, 패치 준수 지표는 실제 위험 노출 상황을 부분적으로만 반영하게 됩니다.

어떤 기기들이 있는지 아는 것은 한 가지 문제일 뿐입니다. 이러한 기기들 중에서 어떤 패치를 우선적으로 적용할지 결정하는 것은 또 다른 난제입니다.

CVE 위험 신호를 기반으로 macOS 패치 우선순위 지정

애플의 보안 릴리스 노트에는 각 업데이트에서 해결된 취약점이 나열되어 있지만, 출시 초기에는 항상 중요한 CVSS 점수나 악용 가능성 데이터가 포함되는 것은 아닙니다.
실제로 “항상 즉시 공개되는 것은 아니다”라는 말은 출시 후 며칠 또는 심지어 몇 주를 기다려야 한다는 것을 의미하며, 경우에 따라서는 NVD가 자체 분석 결과를 발표하기 전까지는 CVSS 점수가 공개되지 않기도 합니다.

애플의 보안 공지에서는 KEV 수준의 악용 사실을 즉시 확인하지는 않더라도 “애플은 이 문제가 적극적으로 악용되었을 수 있다는 보고를 인지하고 있다”와 같은 표현을 사용할 수도 있습니다. 실시간 리스크 관리 프로그램을 운영하는 팀들에게 있어 이러한 지연은 사소한 불편함이 아니라 운영상의 문제입니다.

패치가 적용되지 않은 macOS의 취약점은 시스템을 무단 접근에 노출시킬 수 있으며, 일단 침투 경로가 확보되면 횡방향으로 확산되는 악성코드, 랜섬웨어 및 기타 위협의 침투 경로가 될 수 있습니다.

애플의 실적 정보를 일반적인 위험 신호와 연결하는 방법은 다음과 같습니다.

• Apple CVE를 NVD에 매핑하기: Apple은 대부분의 취약점에 CVE 식별자를 할당합니다. 해당 식별자를 NVD 항목과 대조하여 CVSS 점수와 기술적 세부 정보를 확인하십시오.
• CISA의 KEV 카탈로그를 확인하세요: KEV에 macOS CVE가 등재되어 있다면, 이는 실제 환경에서 악용된 사례이므로 CVSS 점수와 관계없이 즉각적인 조치가 필요합니다.
• EPSS(Exploit Prediction Scoring System) 데이터를 적용하세요: EPSS는 향후 30 일 이내에 악용될 확률 점수를 제공합니다. 대략 10%를 초과하는 점수는 일반적으로 각별한 주의를 요하지만, 기준치는 해당 환경에 맞춰 조정해야 합니다. EPSS 점수가 높으면, CVSS 점수만으로는 심각도가 ‘중간’으로 나타날지라도 긴급한 대응이 필요함을 시사합니다.
• 자산의 중요도를 고려하십시오: 민감한 데이터에 접근할 수 있는 경영진의 맥북에 존재하는 취약점은, 회의실 공용 기기에서 발견된 동일한 결함과 비교할 때 다른 수준의 위험을 초래합니다.

애플의 릴리스 노트를 출발점으로 삼지 말고, NVD와 CISA KEV를 주요 신호로 삼아 워크플로를 구축하십시오. 의 취약점 관리 워크플로우( )에 이미 Windows용 CVSS, KEV 및 EPSS가 통합되어 있는 경우, 해당 프레임워크를 macOS로 확장하면 일관성을 확보할 수 있을 뿐만 아니라 중요한 Apple 취약점을 간과할 가능성을 줄일 수 있습니다.

OS 수준의 취약점에 대한 우선순위를 정하는 방법을 아는 것만으로는 문제의 절반밖에 해결되지 않습니다. Mac에서 실행되는 애플리케이션들은 완전히 다른 패치 관리 체계를 따릅니다.

타사 macOS 앱 패치

애플의 macOS 업데이트는 운영 체제와 사파리 같은 기본 제공 앱을 포함합니다. Chrome이나 Firefox와 같은 브라우저, Zoom이나 Slack과 같은 업무용 도구, 개발자용 유틸리티를 포함한 그 밖의 모든 항목은 별도의 패치 적용 절차가 필요합니다.

macOS는 설계상 개방형 플랫폼입니다. 애플리케이션은 App Store를 통하지 않고, 공급업체 웹사이트, 기업용 배포 도구 또는 사용자 지정 패키지를 통해 배포 및 업데이트될 수 있습니다.

이러한 개방성은 개발자와 숙련된 사용자에게 유용한 기능입니다. IT 측면에서 보면, 전체 애플리케이션 카탈로그를 아우르는 단일 업데이트 메커니즘이 없다는 뜻입니다.

이는 다음과 같은 의미입니다:

• 중앙 집중식 업데이트 메커니즘 없음: 각 애플리케이션마다 앱 내 알림, 백그라운드 자동 업데이트, 수동 다운로드 등 고유한 업데이트 프로세스를 가질 수 있습니다.
• 버전 산재 현상: 강제 조치가 없다면, 사용자들은 업데이트를 무기한 미룰 수 있으며, 이로 인해 전체 시스템에 취약한 버전이 계속 실행되면서 중앙 집중식 가시성 없이는 정량화하기 어려운 복합적인 보안 위험이 발생하게 됩니다.
• 가시성 문제: 사용 중인 MDM이 App Store 외 애플리케이션의 설치 버전을 보고하지 않을 수 있어, 노출 위험을 파악하기 어려울 수 있습니다.

기업 팀은 일반적으로 다음 세 가지 방법 중 하나를 통해 타사 macOS 패치 문제를 해결합니다:

1. MDM을 통한 앱 배포: 일부 MDM 솔루션은 사용자 지정 패키지나 공급업체 업데이트 피드와의 연동을 통해 타사 앱을 배포하고 업데이트할 수 있도록 지원합니다.
2. 전용 패치 관리 소프트웨어: 전용 패치 관리 플랫폼을 사용하면 설치된 애플리케이션을 파악하고, 구버전을 식별하며, Mac 전체에 업데이트를 배포할 수 있습니다. 이는 흔히 일반적인 타사 앱을 위한 미리 구축된 카탈로그를 활용함으로써, 배포 패키지를 수동으로 생성하고 관리할 필요가 없도록 해줍니다.
3. 벤더별 관리: 일부 애플리케이션(Adobe Creative Cloud, Microsoft 365)에는 자체적인 기업용 업데이트 관리 기능이 포함되어 있습니다.

타사 macOS 패치 적용은 Windows의 경우보다 수동 설정 작업이 더 많이 필요한 경우가 많습니다. WSUS와 SCCM은 타사 패치 카탈로그를 위한 성숙한 생태계를 갖추고 있습니다. macOS 관련 도구들도 점차 따라잡고 있지만, 타사 패치 적용 워크플로를 구축하고 유지 관리하는 데 더 많은 노력을 기울여야 할 가능성이 높습니다.

[서버 패치 관리에 표준 엔드포인트 패치 적용을 넘어선 실시간 인벤토리, 위험 기반 우선순위 지정, 단계적 배포가 필요한 이유를 알아보세요]

적절한 도구가 없다면 이 과정은 시간이 많이 소요될 수 있으며, IT 팀은 공급업체의 릴리스 주기를 수동으로 추적하고, 맞춤형 패키지를 구축하며, 다양한 애플리케이션 카탈로그 전반에 걸쳐 배포를 검증해야 합니다.

OS와 애플리케이션 패치 문제를 모두 해결했으므로, 다음 단계는 macOS를 기업의 전반적인 패치 관리 프로그램에 통합하는 것입니다.

크로스 플랫폼 프로그램에 Mac 패치 기능 통합하기

대부분의 기업 환경에서는 Windows, macOS, Linux 엔드포인트와 함께 클라우드 워크로드를 함께 실행하고 있습니다. 각 플랫폼을 별개의 패치 관리 영역으로 취급하면 비효율이 발생하고, 적용 범위가 일관되지 않을 위험이 커집니다.

이러한 과제는 특히 여러 고객 환경에 걸쳐 Mac 기기를 관리하는 관리형 서비스 제공업체(MSP)의 경우 더욱 두드러지는데, 일관성 없는 도구 사용과 분산된 보고 체계로 인해 대규모 환경에서 일관된 패치 적용률을 유지하기가 어렵기 때문입니다.

통합이란 macOS 패치 데이터를 다른 플랫폼에 대해 사용하는 것과 동일한 워크플로우, 대시보드 및 보고 체계에 통합하는 것을 의미합니다:

• 통합 취약점 대시보드: 보안 팀은 Windows와 Mac의 패치 상태를 확인하기 위해 별도의 콘솔을 일일이 확인할 필요가 없습니다. macOS 취약점 및 패치 데이터를 기존 SIEM 또는 취약점 관리 플랫폼에 연동하십시오.
• 일관된 SLA: 의 패치 정책 에 따라 Windows의 중요 업데이트를 72 시간 이내에 적용해야 하는 경우, macOS에도 동일한 기준을 적용하십시오. 일정 차이가 혼란을 야기하고 감사 위험을 초래합니다.
• 공동 변경 관리: macOS 패치 배포를 Windows 업데이트와 동일한 변경 관리 승인 절차를 통해 진행합니다. 이를 통해 별도의 거버넌스 구조를 만들지 않으면서도 적절한 검토가 이루어지도록 보장합니다.
• 크로스 플랫폼 보고: 경영진이 패치 준수 여부에 대해 문의할 때, 그 답변은 도구가 가장 잘 갖춰진 플랫폼뿐만 아니라 전체 엔드포인트 환경을 반영합니다.

macOS를 통합 패치 프로그램에 포함시키는 것은 단순히 적용 범위를 넓히는 데 그치지 않습니다. 이를 통해 IT 팀은 도구 과다 현상을 줄이고, 단일 신뢰할 수 있는 정보원을 바탕으로 모든 플랫폼에 걸친 규정 준수 현황을 보고할 수 있습니다.

기술적인 과제는 정규화입니다. Windows 패치는 마이크로소프트에서 KB 번호와 함께 제공됩니다. macOS 업데이트에는 빌드 번호와 버전 문자열이 있습니다. 리눅스 배포판들은 각자 고유한 버전 관리 체계를 사용합니다. 귀사의 툴링은 패치 데이터를 비교 및 보고를 위한 공통 프레임워크로 변환합니다.

[Windows를 넘어 패치 프로그램을 확장하시겠습니까? [리눅스 패치 관리에 필요한 사항을 확인해 보세요]

다양한 운영 체제에 걸쳐 실시간 엔드포인트 데이터를 제공하는 플랫폼은 이러한 통합 과정을 간소화합니다.

단일 콘솔에서 Windows, macOS, Linux의 패치 상태를 조회할 수 있다면, 크로스 플랫폼 거버넌스는 더 이상 막연한 목표가 아니라 현실적인 일이 됩니다.

통합 가시성은 운영 체제와 관계없이 모든 엔드포인트에 점점 더 많이 적용되고 있는 규정 준수 요건도 지원합니다.

규제 대상 환경에서의 macOS 패치 준수 현황

HIPAA, PCI DSS, NIST SP 800-40 과 같은 규제 프레임워크는 운영 체제를 구분하지 않습니다. 준수 범위에서 엔드포인트를 포함한다면, 여기에는 Mac도 포함됩니다.

규제 대상 환경에서 macOS에 대한 효과적인 패치 관리는 단순히 업데이트를 제때 배포하는 것 이상의 의미를 지닙니다. 이를 위해서는 문서화된 정책, 감사 가능한 증거, 그리고 전체 Mac 기기군에 걸쳐 규정 준수를 입증할 수 있는 도구가 필요합니다.

이로 인해 macOS 패치 관리에 있어 다음과 같은 구체적인 의무가 발생합니다:

• 문서화된 패치 정책: 감사관은 패치 일정, 테스트 절차 및 예외 처리를 명시한 서면 정책을 요구합니다. 패치 정책은 Windows와 마찬가지로 macOS에도 적용됩니다.
• 패치 상태 관련 증거: 어떤 Mac에 어떤 패치가 설치되어 있는지, 패치가 언제 적용되었는지, 그리고 어떤 기기에 미해결 취약점이 있는지 보여주는 보고서를 생성하게 됩니다.
• macOS에 대한 인터넷 보안 센터(CIS) 벤치마크: 인터넷 보안 센터(CIS)는 패치 관련 통제 사항을 포함하는 macOS용 보안 강화 벤치마크를 발표합니다. 많은 규정 준수 프로그램이 CIS를 기준점으로 삼고 있습니다.

준수 프로그램에 반영할 가치가 있는 운영상의 세부 사항 하나: CIS는 주요 OS가 출시될 때마다 새로운 macOS 벤치마크를 발표하며, 버전 번호는 중요한 의미를 지닙니다.
조직의 기기 대부분이 이미 macOS 15 로 전환된 상태에서 CIS macOS 13 벤치마크를 기준으로 평가를 수행하는 준수 프로그램의 경우, 릴리스 간에 일부 통제 수단이 변경되고 매 릴리스마다 새로운 공격 표면이 도입됨에 따라 평가 범위에 공백이 발생할 수 있습니다.
평가 도구가 환경에서 실제로 실행 중인 OS 버전에 해당하는 최신 벤치마크 버전을 기반으로 데이터를 가져오고 있는지 확인하십시오.

• 적시 수정: 예를 들어, PCI DSS는 중요한 패치를 30 일 이내에 적용할 것을 요구합니다. macOS 패치 주기는 보다 광범위한 규정 준수 프로그램의 일환으로 PCI DSS 패치 일정 요건을 충족할 수 있도록 구성할 수 있습니다.

macOS 감사에서 직면하는 어려움은 대개 도구 문제에서 비롯됩니다. 사용 중인 패치 관리 플랫폼이 Mac에 대해 Windows와 동일한 수준의 상세한 보고 기능을 제공하지 않는다면, 증거 자료를 수동으로 수집하는 데 더 많은 시간을 소비하게 될 것입니다.

규정 준수는 단순히 패치를 설치하는 것만을 의미하는 것이 아닙니다. 이는 패치가 설치되어 있는지, 언제 적용되었는지, 그리고 의 패치 적용 프로세스 가 재현 가능하고 체계적으로 문서화되어 있음을 입증하는 것입니다.

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

Tanium의 자율 IT 플랫폼은 단일 콘솔을 통해 macOS, Windows, Linux 전반에 걸쳐 실시간 가시성과 엔드포인트 관리 기능을 제공함으로써, 각 운영 체제별로 별도의 워크플로우를 구축해야 하는 부담을 줄여줍니다.

Tanium은 패치 관리를 탐지, 우선순위 지정, 승인, 배포 및 검증에 이르는 전체 라이프사이클로 접근합니다. macOS의 경우, Tanium은 Apple의 공식 시스템 업데이트 카탈로그에서 직접 정보를 가져와 사용 가능한 macOS 패치를 표시합니다. 기기 표시 여부는 ‘기기 관리(Device Management)’ 에서 ‘ ’ 등록 여부에 따라 달라지며, 이는 Apple Business Manager 또는 Apple School Manager를 통한 자동 등록이나 수동 프로필 설치를 통해 이루어집니다. 이를 바탕으로 조직은 실시간 취약점 데이터를 활용하여 가장 중요한 취약점에 대한 대응 조치를 우선적으로 수행할 수 있습니다.

macOS용 소프트웨어 업데이트 관리

Tanium은 MDM 기반의 ‘소프트웨어 업데이트 설정’ 및 ‘소프트웨어 업데이트 강제 적용’ 구성을 활용하는 기기 관리 기능을 통해 macOS 소프트웨어 업데이트를 관리합니다. 팀은 업데이트 유예 기간을 정의하고, 대상 빌드 버전을 지정하며, 적용 기한을 설정한 다음, 컬렉션을 통해 해당 설정을 여러 기기 그룹에 일괄 적용할 수 있습니다.

의 ‘기기 관리 개요’ 대시보드( )는 ‘버전별 Mac 기기’, ‘비활성 기기’, ‘일별 반납 기기’ 등 여러 패널을 통해 팀이 Mac 기기 현황을 파악할 수 있도록 지원합니다. 이 모든 요소를 종합하면, 목표 버전에 도달하지 않은 엔드포인트를 파악하고, 더 이상 적용 설정을 수신하지 못할 가능성이 있는 기기를 식별하는 데 도움이 됩니다.

운영상 고려해야 할 중요한 사항 하나: 강제 적용 설정이 대상 기기와 호환되지 않는 경우(예: 해당 기기의 하드웨어에서 지원되지 않는 OS 버전 등), 기기에서 오류가 발생하거나, 기기에 알림이 표시되지 않은 채로 강제 적용을 묵인할 수 있습니다. 이는 애플이 의도한 동작이며, 이는 버전 보고가 적용 구성의 필수적인 보완 수단이지, 이를 대체하는 것이 아님을 의미합니다.
바로 이 때문에 Tanium의 ‘버전별 Mac 기기’ 보고서가 중요한 것입니다. 이 보고서는 차량 배치 현황을 파악하는 데 그치지 않습니다. 또한 감지되지 않은 오류를 찾아내는 데도 도움이 됩니다.
강제 적용이 성공적으로 수행되면 버전 분포가 변화합니다. 만약 하드웨어 비호환성이나 등록 누락 등의 이유로 등록되지 않았다면, 해당 기기들은 이전 버전을 계속 사용하게 되며 보고서에 표시됩니다. 그게 바로 조사해야 한다는 신호입니다.

대규모 제3자 소프트웨어 업데이트

macOS의 기본 업데이트 기능은 타사 애플리케이션을 지원하지 않습니다. Tanium Deploy 는 타사 소프트웨어를 가져오고 배포하기 위한 템플릿을 제공함으로써 이 문제를 직접 해결하므로, 팀은 공급업체의 릴리스 주기를 모니터링하거나 배포 패키지를 수동으로 구축할 필요가 없습니다.

Tanium Deploy의 사전 정의된 패키지 갤러리 에는 브라우저, 생산성 도구, 커뮤니케이션 앱, 개발자 유틸리티 등 일반적인 기업용 소프트웨어를 포함한 macOS 애플리케이션용 사전 패키지화된 템플릿이 포함되어 있습니다.

패키지는 설치, 업데이트 및 제거 작업을 지원하며, Tanium에서 새 버전을 출시할 때마다 이를 가져오도록 구성할 수 있습니다. 또한 Tanium Deploy는 를 통해 macOS 버전 업그레이드를 직접 관리할 수 있으며, 2단계 사전 캐싱 및 업그레이드 프로세스를 활용하여 대규모 배포 환경에서 대역폭에 미치는 영향을 최소화합니다.

규정 준수 평가 및 취약점 가시성

Tanium Comply 는 운영 체제, 애플리케이션 및 보안 구성을 대상으로 취약점 및 규정 준수 평가를 수행하며, 매일 업데이트되는 콘텐츠 라이브러리를 통해 SCAP(Security Content Automation Protocol) 및 OVAL(Open Vulnerability and Assessment Language) 기반 콘텐츠를 지원합니다. 이는 인텔 기반 Mac과 Apple 실리콘(M1 이상)을 탑재한 Mac 모두에서 macOS 엔드포인트 를 지원합니다.

Comply의 분석 결과는 배포 및 문제 해결에 사용되는 동일한 플랫폼에 반영될 수 있어, 콘솔을 전환하거나 티켓을 별도의 팀으로 전달해야 하는 번거로움을 줄일 수 있습니다.

소프트웨어 워크플로우를 위한 자동화 및 오케스트레이션

Tanium Automate 는 플레이북을 사용하여 자동 또는 수동으로 실행되는 순차적 단계를 수행하고, macOS 엔드포인트를 포함한 Tanium 솔루션 전반에 걸쳐 소프트웨어 배포 작업을 조정합니다. 각 단계는 특정 엔드포인트 그룹을 대상으로 할 수 있으며, 운영자는 플레이북을 구성하여 각 단계에서 자동으로 진행되도록 하거나 수동 승인을 요구하도록 설정할 수 있습니다.

Tanium 패치 관리의 실제 적용 사례 살펴보기

베테랑 IT 분석가인 데니스는 ‘제로 터치(Zero Touch) 배포’를 다룬 단 한 편의 ‘테크 토크(Tech Talks)’ 에피소드가 어떻게 자신의 패치 관리 방식을 전면적으로 개편하게 했는지, 그 결과 규정 준수율을 45%에서 97%로 끌어올릴 수 있었는지 설명합니다. 변경된 사항은 다음과 같습니다.

실제 결과

시노프시스(Synopsys)는 타늄(Tanium)을 통해 미주 지역 전역에 걸쳐 Windows PC와 Mac이 혼합된 23.000 대의 엔드포인트를 관리하고 있습니다.

IT 팀은 Tanium을 활용하여 브라우저를 최신 상태로 유지하고 자주 사용되는 엔드포인트 애플리케이션에 패치를 적용하며, 이전에는 답변하는 데 최대 일주일이 걸리던 엔드포인트 상태에 대한 문의 사항을 실시간으로 처리하고 있습니다.

[사례 연구 읽어보기]

”우리는 항상 적은 자원으로 더 많은 성과를 내야 한다는 압박을 받고 있습니다. “Tanium 덕분에 우리 팀이 그렇게 할 수 있었습니다.”

시노프시스(Synopsys) IT 담당 이사 앤드류 월

Mac 패치 관리 자주 묻는 질문

Mac 패치 적용은 기업 팀, 특히 기존 Windows 중심 프로그램을 확장하고 있는 팀들에게 일관된 일련의 의문점을 제기합니다. 아래 답변들은 팀들이 가장 흔히 겪는 운영 및 아키텍처상의 문제점들을 다루고 있습니다.

MDM에 등록되지 않은 Mac에는 어떻게 패치를 적용하나요?

첫 번째 단계는 현재 어떤 상황에 직면해 있는지 파악하는 것입니다. 대부분의 환경에서 등록되지 않은 Mac은 몇 가지 범주로 나뉩니다. 표준 프로비저닝 워크플로를 거치지 않은 기기, 관리 범위 밖에 있는 계약자용 기기나 BYOD 기기, 그리고 등록을 거부한 사용자의 기기 등이 이에 해당합니다. 올바른 접근 방식은 해결하려는 문제가 무엇인지에 따라 달라집니다.

관리자 권한이 있는 등록되지 않은 Mac의 경우, 에서 softwareupdate 명령줄 도구를 사용하여 MDM 없이 패치를 적용할 수 있습니다. 이 작업은 수동으로 실행하거나, 스크립트를 통해 실행하거나, 에이전트를 통해 트리거할 수 있습니다. 에이전트 기반 엔드포인트 관리 도구 역시 MDM 등록 여부와 관계없이 패치 상태를 평가하고 문제를 해결할 수 있지만, 에이전트를 배포하려면 여전히 기기에 대한 일정한 접근 경로가 필요합니다.

프로그래밍 방식으로 접근할 수 없는 기기의 경우, 에 설명된 대로 사용자가 직접 실행하는 업데이트 정책과 준수 기한을 설정하는 것이, 특히 계약업체 기기나 BYOD 기기의 경우 실용적인 대안입니다. 이 접근 방식은 직접적인 문제 해결보다는 적용 및 보고에 의존하므로, 업데이트가 실제로 적용되었는지 확인해 주는 가시성 도구와 함께 사용할 때 가장 효과적입니다.

MDM이 없다면, 관리 대상이 아닌 기기에서 패치 적용 현황을 확인하고 적용을 강제하는 일은 항상 더 어려울 수밖에 없습니다. 어떤 도구나 워크플로를 사용하든 간에, 이것이 근본적인 제약 조건입니다.

Apple Rapid Security Responses를 연기할 수 있나요?

네, 다만 유예를 통제 수단으로 활용하기 전에 알아두어야 할 몇 가지 사항이 있습니다.

MDM 구성 프로파일을 사용하면 ‘Rapid Security Responses’가 자동으로 설치되는 것을 방지하거나, 일단 설치된 후 사용자가 이를 제거하지 못하도록 차단할 수 있습니다. 이는 표준 OS 업데이트 연기 설정과는 별도로 관리되므로, RSR에 표준 OS 업데이트 연기 설정을 적용하는 것은 흔한 설정 오류이므로 올바른 구성 방법을 확인하려면 MDM 공급업체의 설명서를 참조하십시오.

이연 계획에 영향을 미치는 한 가지 행동상의 세부 사항: RSR은 최신 마이너 OS 버전에만 적용됩니다. 사용자 환경에서 해당 사소한 OS 업데이트 자체가 연기되고 있다면, 그 결과 RSR도 사실상 지연되는 셈입니다.

기본적으로 사용자는 ‘소프트웨어 업데이트’를 통해 설치된 RSR을 직접 제거할 수 있습니다. MDM을 통해 이를 제한할 수 있지만, 이를 위해서는 별도의 설정이 필요합니다. 지연 기능은 어떤 내용이 푸시되는지를 제어할 뿐, 사용자가 RSR을 개별적으로 롤백하는 것을 자동으로 막지는 않습니다.

RSR은 전체 OS가 아닌 좁은 범위(Safari, WebKit 및 일부 시스템 구성 요소)를 대상으로 합니다. 이러한 업데이트는 과거에 적극적으로 악용되었던 취약점을 해결해 왔기 때문에, 이를 연기할 경우의 위험은 일반적인 보안 업데이트를 연기할 때보다 일반적으로 더 높습니다.

Apple 취약점에 대한 CVSS 점수는 어떻게 확인할 수 있나요?

애플의 보안 릴리스 노트 에는 CVE 식별자가 포함되어 있지만, CVSS 점수는 직접 공개하지 않습니다. 점수를 확인하려면 해당 CVE ID를 국가 취약점 데이터베이스(National Vulnerability Database)와 대조해 보십시오.

실무에서 이 워크플로우에는 두 가지 제약 사항이 있습니다:

1. 애플은 해당 NVD 항목이 등록되기 전이나 분석이 완료되기 전에 보안 업데이트를 자주 배포하기 때문에, 점수가 ‘보류 중’으로 표시되거나 아예 없는 경우라도 이는 귀하의 프로세스에 오류가 있는 것은 아닙니다.
2. NVD 역시 분석 지연 문제를 겪고 있어, 일부 CVE는 공개된 후 며칠 또는 몇 주 동안 평가 점수가 매겨지지 않은 채 방치될 수 있습니다.

시급한 패치 결정의 경우, NVD, MITRE의 CVE 데이터베이스, 애플의 보안 공지 페이지 등 여러 출처를 교차 참조하면 단일 출처만 참고할 때보다 더 포괄적인 정보를 얻을 수 있습니다.

CVE 상호 연관성을 자동화하는 취약점 관리 플랫폼은 상류 데이터의 최신 상태를 그대로 반영할 뿐이므로, 애플이 업데이트를 발표하고 NVD가 이를 완전히 분석하기까지의 기간 동안 동일한 정보 격차가 발생하기 마련입니다.

감독형 Mac과 비감독형 Mac의 차이점은 무엇인가요?

‘감독(Supervision)’은 등록 시 설정되는 기기 상태로, MDM이 해당 기기를 어느 정도까지 제어할 수 있는지를 결정합니다. 이는 등록 과정에서 설정되며, 기기를 초기화하고 다시 등록하지 않는 한 소급 적용할 수 없습니다.

관리 대상 Mac 은 강제 제한, 커널 확장 관리, 콘텐츠 필터링, 무통증 앱 설치, 업데이트 관리 등 훨씬 더 광범위한 MDM 기능을 지원합니다.

비감독형 Mac 은 주로 프로필 배포 및 기본적인 자산 관리 기능으로 제한됩니다. 규정 준수 프레임워크에서 요구하는 많은 ‘ ’ 보안 통제 사항 은 감독을 받지 않는 기기에서는 단순히 시행할 수 없습니다.

재택 근무자의 macOS 업데이트는 어떻게 관리해야 할까요?

MDM은 VPN 없이도 인터넷을 통해 OS 및 보안 업데이트를 제공하므로, 원격으로 연결된 Mac에서도 기본적인 배포 방식이 작동합니다. 더 어려운 문제는 집행과 규정 준수 현황 파악입니다.

사용자 연체는 주요 운영 위험 요소입니다. MDM에서 연기 기한을 강제하지 않는 한, 원격 근무자는 주요 OS 업데이트를 반복적으로 연기할 수 있습니다. 애플은 MDM이 업데이트를 얼마나 적극적으로 강제할 수 있는지에 제한을 두고 있으므로, 아무리 엄격한 정책이라도 예외의 여지가 남게 됩니다. 해당 제약 조건을 고려하여 패치 주기를 수립하십시오.

패치 상태 보고의 신뢰성은 MDM 체크인 빈도에 따라 달라집니다. 최근에 상태를 보고하지 않은 Mac의 경우 오래된 규정 준수 데이터가 표시되므로, 패치 적용률 수치를 해석할 때 이 점을 고려해야 합니다.

Mac의 패치 관리가 Windows의 패치 적용과 어떻게 다른가요?

Mac 패치 관리는 Windows 패치 적용 방식 과는 업데이트 배포, 타사 애플리케이션 지원 범위, 도구 사용이라는 세 가지 측면에서 차이가 있습니다.

애플은 업데이트 배포 프로세스 전반을 관리합니다. WSUS에 상응하는 온프레미스 배포 지점은 없습니다. OS 및 보안 업데이트는 ‘소프트웨어 업데이트’ 또는 MDM 명령을 통해 애플의 자체 인프라를 경유하여 제공됩니다. 이는 패치 배포가 단순히 운영 차원을 넘어 아키텍처 수준에서도 다르게 이루어진다는 것을 의미합니다.

의 타사 앱 패치 문제는 별개의 문제입니다. macOS는 Mac App Store 외부에서 설치된 애플리케이션의 업데이트를 관리하기 위한 중앙 집중식 OS 수준 메커니즘을 제공하지 않습니다. 그 결과, Chrome, Zoom, Slack과 같은 일반적인 도구들은 자체 업데이트 프레임워크에 의존하거나, 스크립트, 타사 도구, 또는 MDM과 연계된 워크플로를 통해 패치를 적용해야 합니다.

공구 격차는 이 두 가지 문제를 더욱 악화시킵니다. Windows 중심의 패치 관리 플랫폼은 macOS를 지원하지 않거나, 애플의 업데이트 모델이 어떻게 작동하는지 고려하지 않은 제한적인 지원만 제공합니다. 적절한 도구를 사용하더라도 패치 상태 보고는 장치 등록 및 에이전트 상태에 따라 달라집니다.

보다 효과적인 패치 관리를 위한 향후 방향은 플랫폼 간의 차이점을 이해하고, 필요한 경우 macOS 전용 워크플로를 구축하며, Mac 패치 관리를 통합된 크로스 플랫폼 프로그램으로 통합하는 것입니다. 운영 체제에 관계없이 모든 엔드포인트에 대한 실시간 가시성을 제공하므로, 이 통합 기능은 필수적입니다.

Tanium의 선형 체인 아키텍처는 캐시된 데이터에 의존하기보다는 엔드포인트를 실시간으로 직접 조회하도록 설계되었습니다. 즉, 패치 상태는 캐시된 스캔 데이터가 아닌 엔드포인트에 대한 직접 쿼리를 기반으로 하므로, 팀은 자사 인프라 전반에 설치된 소프트웨어에 대한 보다 최신 정보를 확인할 수 있습니다.
Tanium의 패치 관리 기능을 확인해 보시려면 데모를 예약하세요..