방화벽 정책 설계: 기본 거부·상태 추적·규칙 정리 방법

1장 개념과 보호 목표#

방화벽은 정해진 정책에 따라 네트워크 연결이나 요청을 허용·차단하는 통제입니다. 주소와 포트 기반 필터링, 연결 상태 추적, 애플리케이션 식별 등 기능 범위가 다르므로 배치 위치와 허용해야 할 업무 흐름을 먼저 정해야 합니다.

2장 원리와 구분#

기본 거부 정책에서는 필요한 통신만 명시적으로 허용합니다. 규칙 순서, 넓은 주소 범위, 중복 예외 때문에 의도와 실제 결과가 달라질 수 있습니다. 내부망이라는 이유만으로 모든 연결을 허용하면 침입 후 확산을 제한하기 어렵습니다. WAF는 웹 요청을 다루는 통제이며 서버의 안전한 입력 처리와 인가를 대신하지 않습니다.

경계 방화벽뿐 아니라 서버 간 동서 트래픽과 외부로 나가는 통신을 점검해야 합니다. 외부 연결의 목적을 제한하면 침해 후 제어 서버 통신이나 데이터 반출을 줄이는 데 도움이 됩니다. TLS 검사 기능을 사용할 경우 인증서 배포, 민감정보 취급과 검사 예외의 영향을 함께 검토합니다.

3장 비교와 판단 기준#

검토 항목	허용 기준	점검 증거
출발지·목적지	필요한 시스템 범위	규칙·실제 연결
서비스	필요한 포트·프로토콜	업무 요구·트래픽
예외	승인된 기간·사유	담당자·만료일
로그	조사와 정책 검증	차단·허용·변경 기록

4장 패킷을 허용하는 것과 요청을 신뢰하는 것#

방화벽은 필요한 연결이나 요청의 범위를 제한합니다. 허용된 주소·포트로 들어온 요청도 애플리케이션에서는 악성 입력일 수 있습니다. 네트워크 필터링과 서비스의 인증·인가·입력 처리를 같은 기능으로 취급하지 않습니다. 배치 위치와 실제로 볼 수 있는 정보를 먼저 확인합니다.

패킷 필터는 주소·프로토콜·포트 등을, 상태 추적은 연결의 상태를, 응용 기능은 지원되는 애플리케이션 문맥을 봅니다. 제품이 암호화된 내용을 실제로 검사하는지와 예외·우회 경로도 점검합니다.

5장 기본 거부 정책을 업무 흐름으로 바꾸기#

필요한 시스템 간 흐름을 적고 그 흐름만 명시적으로 허용합니다. API 서버가 DB에 접근해야 한다면 출발지 서버 그룹·목적지 DB·필요 포트로 범위를 좁힙니다. 내부 전체에서 DB의 모든 서비스를 허용하면 침입 이후 확산 경로가 커집니다.

flowchart LR
 U["외부 사용자"] --> W["웹·API 진입점"]
 W --> A["허용된 애플리케이션 그룹"]
 A -->|"필요한 DB 서비스만"| D["DB 그룹"]
 M["관리 경로"] -->|"승인된 관리 연결"| A

6장 규칙 순서와 가림 현상#

넓은 허용 규칙이 먼저 적용되면 아래의 좁은 차단 규칙이 기대대로 작동하지 않을 수 있습니다. 장비의 평가 순서·구역·기본 동작을 확인해야 합니다. 같은 화면에 두 규칙이 있다는 사실만으로 차단이 수행된다고 판단하지 않습니다.

중복·충돌·가려진 규칙을 조사하고 실제 허용·차단 패킷으로 대조합니다. 로그가 해당 규칙을 보여 주는지와 변경 후 캐시·기존 연결에 어떤 영향이 있는지도 확인합니다.

7장 NAT·주소 그룹·IPv6의 경계#

주소 변환 전후 어느 주소가 정책에 사용되는지 장비와 경로에 맞춰 확인합니다. 주소 그룹이 바뀌었는데 규칙 소유자가 모르면 새로운 자산이 예상치 않게 허용될 수 있습니다. IPv4만 점검하고 IPv6 연결이 그대로 남는 상황도 조사합니다.

원래 출발지·목적지
주소 변환의 위치
정책이 판단하는 주소와 구역
실제 전달되는 경로
허용·차단의 관측 결과

8장 상태 추적과 비대칭 라우팅#

상태 추적은 연결의 흐름을 보고 후속 패킷을 판단할 수 있습니다. 왕복 경로가 다른 장비로 지나가거나 장애 전환에서 상태가 이어지지 않으면 정상 연결에 영향을 줄 수 있습니다. 이중화·라우팅 변경을 실제 조건으로 시험해야 합니다.

정상 세션의 유지와 보안 정책을 함께 확인합니다. 장애 때 보호를 무제한 우회하는 정책이 있는지, 세션 상태·로그가 어떻게 남는지도 기록합니다.

9장 외부로 나가는 연결도 제한한다#

서버가 임의 외부 주소·프로토콜로 나갈 수 있으면 침해 후 제어 서버 통신이나 데이터 반출의 경로가 넓어질 수 있습니다. 업데이트·외부 API·메일 등의 필요한 연결을 구분합니다. 내부 동서 트래픽도 필요한 자산 간 흐름으로 제한합니다.

외부 연결 제한은 다른 목적지로 우회하거나 프록시를 사용하는 경로까지 봅니다. 업무 변경 때 필요한 새 연결을 승인하고 기록하는 절차가 있어야 정상 서비스가 암묵적으로 예외를 누적하지 않습니다.

10장 WAF가 담당하는 경계#

WAF는 웹 요청의 위험을 탐지·제한하는 데 활용됩니다. DB 질의를 바인딩하거나 객체 인가를 수행하는 서버 코드와는 다릅니다. 알려진 패턴 차단이 성공했다고 실제 결함을 남겨 두지 않습니다. 오탐 예외도 기능·범위·기한을 명확히 둡니다.

TLS 검사에는 인증서 배포·민감정보·우회·호환성의 조건이 있습니다. 검사하지 않는 경로와 실제 가시성을 제품 설명이 아닌 배포 설정에서 확인합니다.

11장 임시 규칙의 종료 조건#

규칙 속성	필요한 기록
목적	어떤 업무·장애 점검인가?
대상	최소 출발지·목적지·서비스
책임	소유자·승인자·변경자
수명	만료·재검토·제거 조건
검증	정상 성공과 비허용 실패

사용 횟수 0은 불필요함의 단독 근거가 아닙니다. 집계 기간·로그·비정기 백업·월말·재해복구를 확인합니다. 제거도 변경과 복구 계획에 따라 수행합니다.

12장 변경 검증과 롤백#

변경 전 예상한 허용·차단을 적고 적용 후 실제 연결과 업무 성공률을 대조합니다. 차단 증가가 공격인지 새 배포의 정상 연결인지 조사합니다. 필요하면 정해진 이전 정책으로 되돌리되 긴급 예외는 사후 검토합니다.

flowchart TB
 R["업무 흐름과 위험 정의"] --> P["최소 규칙과 승인"]
 P --> T["변경 적용"]
 T --> V["허용·거부·업무 영향 검증"]
 V --> O["로그 관찰과 예외 정리"]
 O --> E["정기 검토·만료 제거"]

13장 적용 사례와 운영 방법#

API 서버에서 데이터베이스로 가는 통신은 실제 서버 그룹·포트로 제한하고 임시 점검 규칙에는 만료일을 둡니다. 규칙 변경 전후에 허용 대상과 차단 대상을 함께 테스트하고, 차단량 증가가 공격인지 정상 서비스 변경인지 로그로 구분합니다.

14장 규칙은 업무 흐름의 가장 작은 단위로 만든다#

좋은 규칙에는 출발지·목적지·서비스·목적·소유자·검토일이 있습니다. API 서버에서 DB로 필요한 포트만 허용하는 규칙과 내부 전체에서 DB 전체 포트를 허용하는 규칙은 운영 편의가 비슷해 보여도 확산 범위가 다릅니다. 서비스 그룹과 자산 목록을 연결해 장비 교체 후 규칙이 실제 대상을 가리키는지도 확인합니다.

규칙의 평가 순서는 장비별로 확인해야 합니다. 넓은 허용 규칙이 좁은 차단 규칙을 가리는지, NAT 전후 주소를 어느 단계에서 판단하는지, IPv6 경로가 별도로 열려 있는지 시험합니다. 설정 문서의 정책과 실제 패킷의 결과를 대응시켜야 합니다.

15장 임시 점검 예외가 영구 통로로 남지 않게 한다#

장애 점검을 위해 추가한 원격 접속 규칙에는 목적·승인자·만료 시간을 붙입니다. 만료 후 자동 제거하거나 재승인을 받도록 하고, 긴급 변경도 사후 검증 기록을 남깁니다. 사용되지 않는 규칙을 지우기 전에는 드물게 수행되는 백업·재해복구·월말 업무의 흐름도 확인합니다.

변경 검증은 정상 연결의 성공과 허용하지 않은 연결의 실패를 함께 측정합니다. 비대칭 라우팅이나 고가용성 전환에서 상태 추적이 깨지는지와 실패 시 우회·차단 정책도 시험하면 정책 강화가 예기치 않은 중단으로 이어지는 일을 줄일 수 있습니다.

16장 적용 전 확인할 사항#

각 규칙에 업무 목적·소유자·검토일을 기록한다
출발지·목적지·서비스 범위를 최소화한다
변경 검증과 만료된 예외 정리를 수행한다

17장 자주 묻는 질문#

방화벽을 통과한 트래픽은 신뢰해도 되나요?#

허용된 연결 안에도 악성 요청이 들어올 수 있습니다. 애플리케이션 인증·인가와 탐지를 계속 적용해야 합니다.

사용 횟수가 0인 규칙은 바로 삭제해도 되나요?#

집계 기간과 로그 설정을 확인해야 합니다. 비정기 업무의 필요성을 소유자와 검토하고 변경·복구 절차에 따라 정리합니다.

포트를 바꾸면 관리자 서비스가 안전해지나요?#

노출 감소에 일부 도움이 될 수 있지만 인증·접근 범위·패치·기록을 대신하지 않습니다. 필요한 관리 경로만 제한적으로 허용해야 합니다.