사례1건

1건 중 1~1번째

1. IL-0092 ingress-nginx 를 1.12.0 에서 1.14.3 으로 올리자 새 ModSecurity 와 OWASP Core Rule Set 이 정상 요청을 오탐으로 막아 HMPPS 사용자가 인증하지 못했다.

   UK Ministry of Justice2026

   증상

   2026년 3월 30일 08:56 에 Cloud Platform 팀은 #hmpps-auth-audit-registers 슬랙 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤다. 같은 날 07:11 에 운영 인그레스 세 개에 새 ingress-nginx 를 배포하기 시작한 뒤였다.

   오류율 상승서비스 중단

   촉발

   Cloud Platform 팀이 ingress-nginx 1.14.3 을 운영 인그레스 세 개에 배포했다. 이 버전에는 새 ModSecurity WAF 와 새 OWASP Core Rule Set 이 들어 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러웹 애플리케이션 방화벽 규칙

   기여 요인

   스테이징 불일치

   감지

   Cloud Platform 팀은 HMPPS Auth 팀 슬랙 채널의 메시지로 장애를 알았다. 팀은 08:56 에 #hmpps-auth-audit-registers 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤고, 09:14 에 장애를 선언했다.

   조치

   • 09:14 에 ingress-nginx 롤백을 시작해 09:43 에 마쳤다.
   • HMPPS 개발자들이 HMPPS Auth 로 가는 트래픽을 막는 규칙을 자기 ModSecurity 설정에서 예외 처리했다.
   • Cloud Platform 팀이 posthog 쿠키가 걸리는 규칙을 플랫폼의 모든 서비스에서 임시로 예외 처리했다.
   • 두 예외를 둔 상태로 새 ingress-nginx 를 다시 배포해 14:00 에 마쳤다.

   후속 조치

   • posthog 쿠키의 범위를 줄여 모든 *.justice.gov.uk 서비스로 가는 요청에 실리지 않게 했다. 다만 이 변경과 CRS 규칙 배포 사이가 짧아 사용자 브라우저의 쿠키가 만료되거나 바뀔 시간이 모자랐다.
   • posthog 쿠키가 충분히 많은 사용자 브라우저에서 만료되면 플랫폼 전체에 넣은 임시 예외를 없앤다.
   • 서비스 팀들에게 개발과 테스트 워크로드에 비운영 인그레스 컨트롤러를 쓰라고 다시 강조해, 이후 ModSecurity 와 CRS 업데이트에서 생길 문제를 미리 찾게 한다.
   • Cloud Platform 3.0 에서는 운영과 비운영 워크로드를 다른 클러스터로 나눠 비운영 워크로드가 반드시 비운영 인그레스를 거치게 한다.

   교훈

   WAF 규칙 세트 업데이트는 보안을 높이려는 변경이어도 정상 트래픽을 막을 수 있다. 베타 인그레스와 비운영 배포로 시험 기회를 줬어도 서비스 팀들이 개발과 테스트에 비운영 인그레스를 실제로 쓰지 않으면 Expect 헤더 같은 오탐은 운영에서야 드러난다. 시험에서 찾은 문제라도 쿠키처럼 사용자 브라우저에 남는 값이면 대응이 효과를 내기까지 시간이 걸린다. 팀은 롤백으로 먼저 영향을 끊고 예외를 준비한 뒤 다시 배포해 같은 날 업그레이드를 마쳤다.

   사례 보기

원인별1