22. 방화벽 정책을 리뉴얼할 때 실무에서 꼭 거치는 세 단계

방화벽 정책을 다시 손보자, 튜닝하자는 말이 나오면
대부분 이미 룰이 수백 개는 쌓여 있고,
“누가 왜 열었는지” 기억나지 않는 포트가 섞여 있습니다.

실무에서 몇 번 방화벽 리뉴얼을 겪어 보면서 느낀 건
기술보다 순서가 중요하다는 점이었습니다.
보통은 아래 세 단계를 반복하면서 정리했습니다.

1. 구간(Zone) 재정의: “비즈니스 관점에서 경계를 다시 그리기”

우선 장비나 인터페이스가 아니라
업무 단위로 네트워크 구간을 다시 나누는 것부터 시작합니다.

• 사용자망 (사무실 PC, 노트북, 재택 VPN 등)
• 서버망 (업무 서버, DB, 내부 API 등)
• DMZ/대외 서비스망 (웹·앱, 파트너용 API 등)
• 관리망/백오피스, 모니터링망, 보안장비망 등

이렇게 구간을 그려놓고 구간별로

• 기본 정책: 기본 차단(deny) 후 허용인지,
• 예외 정책: 어떤 경우에만 열어 줄 것인지

를 문장으로 적어둡니다.

이 과정을 거치면
“장비 기준 방화벽”이 아니라
“업무 흐름 기준 방화벽”으로 사고가 전환돼서
정책을 설명하기도 훨씬 수월했습니다.

2. 서비스 흐름 기준 정책 설계: “포트가 아니라 업무 이름으로 관리하기”

그다음 단계는 구체적인 서비스 흐름 단위 설계입니다.

예를 들어,

• 외부 사용자 → 웹/WAF → 애플리케이션 서버 → DB
• 내부 사용자 → 백오피스 → API 게이트웨이 → 내부 시스템
• 관제센터 → 보안장비/로그 서버

이 흐름을 그림으로 그리고
각 단계에 필요한 통신을 정의합니다.

이때 룰 이름을

• TCP 443 허용처럼 기술 위주로 짓기보다
• 서비스명_모듈명_용도 형태로
  예: WebPortal_FW_WAF_to_WAS_HTTPS

로 관리하면
나중에 정책 검토·장애 분석·감사 대응 시
“어느 서비스 때문에 열어둔 것인지”를 바로 파악할 수 있습니다.

실무에서는 룰 자체보다 설명 가능한 룰 이름과 주석이
훨씬 큰 자산이었습니다.

3. 레거시 룰 정리: “쓰지 않는 통로를 닫는 것도 보안”

마지막 단계가 가장 힘들지만,
가장 효과가 컸던 작업입니다.

1. 주인 없는 룰 식별
   • 요청자/담당 시스템을 알 수 없는 룰에 “후보” 태그를 달고
   • 관련 부서에 일괄 리스트를 공유해 확인 요청
2. 사용 여부 확인
   • 일정 기간(예: 1~3개월) 동안 로그를 분석해
     실제 트래픽이 있는지 확인
   • 트래픽이 있다면 어느 시스템/계정에서 발생하는지 추적
3. 단계적 폐기
   • 바로 삭제하기 부담스럽다면
     우선 로그만 남기는 “모니터링 모드”로 전환
   • 이상 없으면 실제 통신 차단 후 일정 기간 모니터링
   • 문제없을 때 최종 삭제

이 과정을 프로젝트 형식으로 한 번만 돌려도
“누구도 건드리지 못하는 룰 덩어리”가 크게 줄어듭니다.

특히, 퇴사자·중단된 시스템 관련 룰이
적지 않은 비율을 차지하는 것을 여러 번 경험했습니다.
**“사용하지 않는 통로를 닫는 것만으로 보안 수준이 올라간다”**는 말이
과장이 아니라는 걸 체감했습니다.

4. 덤: 방화벽 정책 리뉴얼 시 꼭 챙겼던 것들

프로세스 외에
늘 체크리스트에 넣어두었던 항목들도 있습니다.

• 정책 변경 전·후 룰셋 백업 및 버전 관리
• 변경 요청·승인 기록 (Change Management)
• 룰 변경 시 영향도 검토와 롤백 시나리오
• 주요 정책(예: 전사 공통 차단 룰)에 대한 별도 문서화

방화벽은 “설치 후 잊어버리는 장비”가 아니라
조직의 네트워크 철학이 드러나는 장비라서,
한 번 리뉴얼할 때 조금 시간을 더 들여
이 관점까지 정리해 두면
이후 운영이 훨씬 편했습니다.