대상 OS: Rocky Linux 9

패치 관리는 ‘무슨 패키지를 올리느냐’만큼이나 언제, 어떤 절차로, 누가 책임지고 올리느냐가 핵심입니다. 일정이 없으면 패치는 계속 밀리고, 결국 취약점은 “언젠가”가 아니라 “이미” 공격 표면이 됩니다.

Rocky Linux 9(dnf) 기준으로, 일정 중심의 패치 운영을 최소 단위로 정리합니다.

1) 업데이트 후보를 먼저 확인(변경량 파악)

무작정 업데이트를 걸기 전에, 변경량과 영향 범위를 먼저 봅니다. 특히 커널/openssl/glibc 같은 핵심 패키지는 재부팅/서비스 재시작이 필요할 수 있습니다.

# 업데이트 후보 확인
sudo dnf check-update


2) 유지보수 창(maintenance window)을 ‘캘린더’로 고정

가장 중요한 단계입니다. “시간이 날 때 패치”는 결국 패치가 안 됩니다. 유지보수 창은 작아도 좋으니 고정합니다.

  • 예: 매주 화/목 02:00~03:00 (서비스 이용이 낮은 시간대)
  • 업데이트 전 현 상태 스냅샷/백업 및 롤백 계획을 포함
  • 영향 큰 서비스는 사전 공지 및 책임자(승인자) 지정


3) 적용 절차(최소 표준) 만들기

절차는 길 필요가 없습니다. 대신 “항상 같은 순서”로 수행해 재현성과 감사 가능성을 확보합니다.

# (예) 패치 적용
sudo dnf -y update

업데이트 직후에는 다음을 습관화합니다: (1) 핵심 서비스 상태, (2) 주요 포트 리스닝, (3) 핵심 API 헬스체크.


4) ‘재부팅이 필요한 변경’이 있었는지 확인하기

패치 자체보다 위험한 건 “커널 업데이트를 했는데 재부팅을 안 해서, 취약한 커널이 계속 돌아가는 상태”입니다. 재부팅은 피하는 것이 아니라 일정에 포함해야 합니다.

# 최근 설치/업데이트된 패키지 확인(상위 30개)
rpm -qa --last | head -n 30

# 현재 커널 버전 확인
uname -r

커널이 업데이트되었는데 uname -r이 그대로면, “언제 재부팅할지”를 결정해야 합니다.


5) 긴급 보안 패치(CVE) 예외 프로세스 정의

정기 일정이 기본이고, 긴급 패치는 예외입니다. 예외 프로세스가 문서로 없으면, 긴급 상황에서 커뮤니케이션 비용이 폭증합니다.

  • 긴급 패치 트리거 기준: CVSS, 익스플로잇 공개 여부, 인터넷 노출 여부, 영향 범위
  • 승인/커뮤니케이션: 누가 승인하고, 누구에게 알릴지
  • 롤백/모니터링: 적용 후 무엇을 확인할지(헬스체크/지표/로그)


사례(현장에서 자주 겪는 상황)

  • “서비스가 바빠서” 패치를 계속 미룸 → 3개월치 업데이트가 쌓여 한 번에 올리기 더 어려워짐
  • 커널 업데이트 후 재부팅 회피 → 보안은 올라간 줄 알았는데 실제 런타임은 구버전 커널 유지
  • 담당자 부재 → 누가 결정/승인하는지 불명확해 일정이 계속 흔들림

트러블슈팅(증상→원인→해결)

  • 증상: 업데이트 후 특정 서비스가 기동 실패
    원인: 의존성/설정 변경, 패키지 업데이트로 동작이 바뀜
    해결: 유지보수 창에 헬스체크를 포함하고, 롤백(이전 패키지/스냅샷) 절차를 사전에 준비
  • 증상: 패치를 했는데 취약점 진단에서 여전히 취약으로 표시
    원인: 재부팅 미실시(커널/핵심 라이브러리), 또는 취약점 DB 기준 차이
    해결: 커널/핵심 라이브러리 업데이트 여부 확인 후 재부팅 일정 반영, 진단 도구 기준(패키지 릴리즈) 확인
  • 증상: 정기 패치가 계속 미뤄짐
    원인: 일정이 ‘정의’만 되고 실제 캘린더/책임자가 없음
    해결: 캘린더 고정 + 책임자 지정 + 최소 표준 절차(체크리스트)로 운영 비용을 낮춰 지속 가능하게 만들기

푸터: 패치의 핵심은 기술보다 운영입니다. “일정(캘린더) + 최소 절차 + 재부팅 정책 + 예외 프로세스”만 고정해도, 패치 품질과 보안 수준이 꾸준히 올라갑니다.