패치 관리
더 많은 작업
- Patch Management; 패치 관리, 패치관리, 보안 패치 관리
- 조직 전체의 소프트웨어·펌웨어에 대한 패치·업데이트·업그레이드를 식별하고, 우선순위를 정하고, 확보·설치하고, 설치 여부를 검증하는 과정
NIST SP 800-40 Rev. 4(2022년 4월, "기업 패치 관리 계획 지침: 기술의 예방 정비")는 기업 패치 관리를 "조직 전체에서 패치, 업데이트, 업그레이드를 식별하고 우선순위를 정하고 확보하고 설치하고 설치를 검증하는 과정"으로 정의한다. 이 지침의 핵심 메시지는 패치를 보안팀의 일회성 대응이 아니라 예방 정비(preventive maintenance), 즉 기술을 쓰는 데 드는 당연한 사업 비용으로 보라는 것이다. 업무 부서는 서비스 중단을 이유로 패치를 미루고 보안 부서는 빨리 하라고 재촉하는 갈등이 흔한데, 이를 계획과 사전 합의로 풀어야 한다는 뜻이다.
취약점 관리가 "어떤 취약점을 어떤 순서로 없앨지"를 정하는 상위 프로세스라면, 패치 관리는 그 결정의 가장 흔한 실행 수단이다. CISSP 7.8(패치와 취약점 관리)이 두 주제를 함께 다루며, 국내 ISMS-P 인증기준 2.10.8(패치관리)도 자산별 특성과 중요도에 따른 패치 정책·절차를 세워 최신 패치를 적용하고, 서비스 영향 때문에 적용이 어려우면 별도의 보완대책을 마련하도록 요구한다.
| 단계 | 주요 활동 | 주의점 |
|---|---|---|
| 1. 자산 식별 | 하드웨어·운영체제·애플리케이션·펌웨어·클라우드 이미지·컨테이너 이미지 목록과 버전, 소유자, 중요도 정리 | 목록에 없는 자산은 패치되지 않는다. 소프트웨어 구성 목록(SBOM)이 도움이 된다 |
| 2. 패치 정보 수집 | 제조사 권고문, 보안 공지, CISA KEV, 국내 보안 공지(KISA 보호나라) 모니터링 | 정기 배포일과 긴급 배포를 모두 추적한다 |
| 3. 평가·우선순위 | 해당 자산 여부 확인, 취약점 심각도·악용 여부·자산 중요도로 우선순위와 적용 기한 결정 | 취약점 관리의 위험 기반 우선순위와 같은 기준을 쓴다 |
| 4. 테스트 | 시험 환경이나 대표 시스템 일부에 먼저 적용해 호환성·안정성·성능 확인 | 시험 환경이 운영과 다르면 결과를 믿기 어렵다 |
| 5. 승인(변경 관리) | 변경 요청 등록, 영향·복구 계획 검토, 변경 관리 위원회(CAB) 또는 위임된 승인권자의 승인 | 정기 패치는 사전 승인된 표준 변경으로 처리할 수 있다. 변경 관리 참고 |
| 6. 배포 | 단계적 배포(파일럿 → 일부 → 전체), 유지보수 시간대 활용, 재부팅 일정 조율 | 실패 시 되돌리기(롤백) 계획을 준비한다 |
| 7. 검증 | 설치 여부와 버전 확인, 재스캔으로 취약점 해소 확인, 서비스 정상 동작 확인 | "배포 명령 성공"과 "취약점 해소"는 다르다 |
| 8. 보고 | 적용률, 기한 준수율, 예외 현황을 자산 소유자와 경영진에 보고 | 미적용 자산은 예외 절차로 넘긴다 |
NIST SP 800-40 Rev. 4는 조직이 미리 준비해야 할 위험 대응 시나리오의 예로 다음 네 가지를 든다. 각 자산을 비슷한 특성의 유지보수 그룹(maintenance group)으로 묶고, 그룹마다 시나리오별 유지보수 계획(시작·종료 기한 포함)을 미리 정해 두라고 권고한다.
| 시나리오 | 상황 | 대응 |
|---|---|---|
| 정기 패치(routine patching) | 정기 배포 주기의 일반 패치. 대부분이 여기에 속한다 | 계획된 일정과 절차로 적용. 미루면 공격 기회가 늘고, 나중에 긴급 패치가 더 어려워진다(선행 패치부터 깔아야 하므로) |
| 긴급 패치(emergency patching) | 심각한 취약점이나 실제 악용 중인 취약점 | 정기 패치와 같은 방식을 크게 앞당긴 일정으로 수행. 이미 침해된 자산이 있으면 침해사고 대응의 일부가 된다 |
| 긴급 완화(emergency mitigation) | 패치가 아직 없거나 패치에 문제가 있는 위기 상황 | 기능 비활성화, 접근 차단 같은 임시 완화. 나중에 되돌릴 수도 있다 |
| 패치 불가 자산(unpatchable assets) | 제조사가 패치를 주지 않거나(지원 종료) 장기간 중단 없이 돌아가야 하는 핵심 시스템 | 격리 등 다른 방법으로 위험 완화 |
같은 지침은 위험 대응을 수용(기존 통제를 믿거나 영향이 작아 추가 조치 없음), 완화(패치·기능 비활성화·업그레이드 또는 방화벽·분리 같은 추가 통제), 전가(사이버 보험, 패치를 공급자가 맡는 SaaS로 전환), 회피(취약한 소프트웨어 제거, 자산 폐기)의 네 가지로 정리한다. 패치는 이 가운데 완화의 한 방법일 뿐이다.
| 보완 통제 | 내용 | 한계 |
|---|---|---|
| 가상 패치(virtual patching) | 웹 방화벽이나 침입방지시스템에 해당 취약점 공격 패턴을 막는 규칙을 넣어 네트워크 단에서 차단 | 취약점 자체는 남는다. 우회 공격이나 내부 경로는 못 막을 수 있다 |
| 격리·분리 | 취약 자산을 별도 네트워크 구간에 두고 필요한 통신만 허용(네트워크 분할, 망분리) | 운영 편의가 떨어진다 |
| 기능 비활성화 | 취약한 서비스·모듈·프로토콜을 끈다 | 해당 기능을 쓰는 업무가 영향을 받는다 |
| 접근 제한·강화된 인증 | 관리 인터페이스 접근을 특정 위치·계정으로 제한, 다중 인증 적용 | 원격 공격 경로가 남을 수 있다 |
| 모니터링 강화 | 해당 취약점 악용 시도를 잡는 탐지 규칙과 경보 추가 | 예방이 아니라 탐지이다 |
보완 통제를 쓰는 경우에도 위험 수용 승인, 기한, 재평가를 포함한 예외 처리를 거친다(취약점 관리의 예외 처리 참고). 산업제어시스템(SCADA, 산업제어시스템)이나 의료기기처럼 제조사 인증 때문에 마음대로 패치할 수 없는 환경에서는 격리와 모니터링이 주된 대책이 된다.
| 분류 | 예 | 역할 |
|---|---|---|
| 운영체제 업데이트 관리 | Windows Server Update Services(WSUS), Microsoft Intune, 리눅스 배포판 저장소와 패키지 관리자 | 패치 승인·배포·보고 |
| 엔드포인트·서버 관리 | 통합 엔드포인트 관리(UEM) 도구, 구성 관리 도구(Ansible 등) | 여러 플랫폼과 서드파티 애플리케이션 패치 배포 |
| 취약점 관리 연동 | 취약점 스캐너, 자산 관리 시스템 | 미적용 패치 탐지, 적용 후 검증 |
| 불변 인프라 | 컨테이너 이미지·가상머신 이미지 재빌드, 코드형 인프라 | 실행 중인 서버를 고치지 않고 새 이미지로 교체 |
NIST SP 800-40 Rev. 4는 자산·소프트웨어·취약점·패치 정보를 관리하고 긴급 상황에 빠르게 대응하려면 자동화가 필요하다고 강조한다. 다만 자동 배포도 테스트·승인·검증 단계를 건너뛰어서는 안 된다.
NIST SP 800-40 Rev. 4는 "전체 취약점 중 몇 퍼센트를 패치했다" 같은 지나치게 단순한 지표는 조치로 이어지지 않는다고 지적하고, 자산 중요도(낮음·중간·높음)와 취약점 중요도(낮음~치명)를 교차한 표의 각 칸에 다음 값을 두는 예를 보여 준다.
- 유지보수 계획 기한 안에 패치된 자산 비율
- 평균 패치 적용 시간(mean)
- 중앙값 패치 적용 시간(median)
이렇게 나누면 "중요한 자산의 치명적 취약점은 빨리 처리되는데 중간 중요도 자산이 뒤처진다" 같은 개선 지점이 보인다. 플랫폼, 사업부, 유지보수 그룹별로 나누어 볼 수도 있다. 자세한 내용은 보안 지표 문서를 본다.
- 패치는 운영 환경에 바로 넣지 않는다. 테스트 → 변경 관리 승인 → 배포 → 검증 순서를 지킨다. "가장 먼저"를 묻으면 자산 목록 확인이나 테스트가 답인 경우가 많다.
- 긴급 패치도 변경 관리를 생략하지 않는다. 긴급 변경 절차로 빠르게 승인하고 사후에 기록·검토한다.
- 패치할 수 없으면 보완 통제(가상 패치, 격리)를 적용하고 위험 수용 승인을 받는다.
- 패치 적용 여부는 재스캔으로 검증한다. 배포 도구의 성공 보고만 믿지 않는다.
- 지원 종료 제품은 패치가 나오지 않으므로 교체 계획이 근본 대책이다(제품 지원 종료).