플랫폼 독립 방화벽 정책 표현
본 논문은 다양한 방화벽 벤더의 고유 문법과 의미 차이를 추상화하여, 하나의 플랫폼‑독립 정책 언어와 모델을 정의한다. 정의된 모델을 구체적인 방화벽 구성으로 자동 컴파일하고, 검증·최적화 기법을 제시한다.
저자: ** Vadim Zaliva (lord@crocodile.org) **
본 논문은 다중 벤더 방화벽 환경에서 관리자가 겪는 복잡성 문제를 해결하고자, 추상 방화벽 모델과 플랫폼‑독립 정책 정의 언어를 제안한다. 서론에서는 각 벤더가 제공하는 고유 문법과 정책 의미 차이로 인해 관리자가 여러 개의 어셈블리 언어를 학습해야 하는 현실을 지적하고, 이를 하나의 고수준 언어로 통합함으로써 인적 오류와 관리 비용을 감소시킬 수 있음을 강조한다.
2장에서는 제안된 추상 방화벽 모델의 구조를 상세히 설명한다. 데이터 모델은 객체‑지향 방식으로, 기본 네트워킹 객체(IPv4 주소, 서비스, 물리 주소 등), 호스트·방화벽·정책 객체, 그리고 유틸리티 객체(주소 범위, 그룹 등)로 구분된다. 각 객체는 고유 ID 로 식별되며, XML 기반 DTD 로 정의돼 파일(.fwb) 형태로 저장된다. 예시 XML 코드를 통해 네트워크 객체, UDP 서비스, 방화벽 인터페이스, 정책 규칙 등이 어떻게 기술되는지 보여준다.
2.2절에서는 정책 문법을 XML(DTD) 로 정의하고, 객체 참조 방식(내부 삽입 vs ObjectRef) 을 설명한다. 2.3절은 처리 모델을 제시한다. 패킷은 먼저 NAT 규칙 집합을 통과하고, 그 다음 방화벽 정책 규칙을 평가한다. 매칭 필드는 소스, 목적지, 서비스, 인터페이스, 방향, 시간이며, ‘Any’ 와 ‘Negation’ 옵션을 통해 복합 조건을 표현한다. 매칭된 규칙의 동작은 Accept, Drop, Reject, Count 로 구분되며, 기본 정책은 Drop 으로 설정한다.
2.4절에서는 정책 검증과 최적화 방안을 논의한다. 구문 검증은 DTD 로 수행되지만 의미적 오류(규칙 그림자, 중복, 충돌 등)는 별도 분석이 필요하다. 저자는 규칙 그림자를 탐지하는 알고리즘을 제시하고, 향후 최적화 기법(규칙 병합, 범위 축소 등)을 적용할 계획임을 밝힌다.
3장에서는 실제 벤더별 차이점을 사례로 제시한다. 암시적·명시적 인터페이스 지정, 기본 정책 차이, 규칙 매칭 순서(first‑match vs last‑match), NAT와 방화벽 규칙 적용 순서, 부정(Negation) 지원 여부, 주소 범위 에뮬레이션, 동적 인터페이스 처리 등 7가지 주요 이슈를 다룬다. 각 이슈마다 추상 모델에서 어떻게 통합하고, 구체적인 벤더 구현에 매핑할지를 설명한다.
4장에서는 추상 정책을 구체적인 방화벽 구문으로 변환하는 컴파일 기술을 소개한다. 정책 컴파일러는 추상 규칙을 벤더‑특정 명령어 집합으로 변환하고, 필요 시 주소 범위 확장, 서비스 매핑, 인터페이스 이름 변환 등을 수행한다.
5장은 관련 연구를 검토하고, 6장은 결론 및 향후 연구 방향을 제시한다. 향후 연구는 정책 최적화 알고리즘 고도화, 정형 검증 기법 도입, 다중 방화벽 정책 동기화, 클라우드·SDN 환경에 대한 확장 등을 포함한다.
전체적으로 논문은 “Firewall Builder” 프로젝트에 구현된 사례를 통해, 추상 방화벽 모델이 실제 다중 벤더 환경에서 어떻게 적용될 수 있는지를 입증한다. 제안된 모델은 정책의 이식성, 자동화, 검증 가능성을 크게 향상시키며, 향후 보안 정책 관리 자동화 연구에 중요한 기반을 제공한다.
원본 논문
고화질 논문을 불러오는 중입니다...
댓글 및 학술 토론
Loading comments...
의견 남기기