투명 프록시 환경에서의 사용자 자율 정책 예외 시스템 설계 = A User-Autonomous Policy Exception System in Transparent Proxy Environments

국문 초록 (Abstract)

MITM（Man-in-the-Middle） 방식의 투명 프록시 기반 웹 접근 제어는 기업, 학교 등 대규모 조직 환경에서 보안 위협 차단, 내부 정책 준수, 생산성 관리 등의 목적으로 사용된다. TLS 인터셉션이 가능한 Secure Web Gateway（SWG） 제품은 HTTPS 트래픽을 복호화한 후 URL 분류, 악성코드 탐지, DLP, 애플리케이션 제어 등의 정책 검사를 수행하며, 정책 위반 또는 위험 요청으로 판단한 경우 사용자에게 차단 응답을 반환한다.
상용 SWG 및 MITM 프록시 제품의 차단 응답은 정적 차단 응답, 요청 단위 정책 예외 적용, 정책 수정형 예외 처리로 구분할 수 있다. 정적 차단 응답은 접근 거부 사실과 정책 사유를 전달하는 데 목적이 있다. 따라서 차단 시점의 일시적 예외 필요성에 대응하지 못하여 사용자의 업무 중단을 유발할 수 있으며, 사용자 업무 맥락도 수집하지 못한다. 요청 단위 정책 예외 적용 방식은 차단 또는 경고 페이지에서의 사용자 상호작용을 통해 일시적 예외를 제공할 수는 있으나, 예외 요청 사유, 업무 맥락, 사용자별 요청 빈도, 예외 지속 시간, URL 카테고리 등을 체계적으로 수집·관리하는 데 한계가 있다. 또한 요청 대상의 위험 수준에 따라 예외 허용 여부, 사용자 마찰 수준, 예외 지속 시간을 차등 적용하기 어렵다. 정책 수정형 예외 처리 방식은 반복적인 예외 요청이나 URL 오분류에 대응하는 데 유용하지만, 관리자 주도의 정적 정책 변경에 의존하므로 차단 시점의 사용자 업무 맥락을 반영하기 어렵다. 또한 특정 제품의 정책 모델, 관리자 콘솔, URL 분류 체계, 인증 방식과 밀접하게 결합되어 있어 프록시 제품으로부터 독립적인 예외 관리 구조로 확장하기 어렵다.
이러한 문제를 해결하기 위해 본 논문은 TLS 인터셉션이 가능한 MITM 프록시 환경에서 특정 프록시 제품 구현에 종속되지 않는 사용자 자율 정책 예외 시스템을 제안한다. 제안 시스템은 기존 웹 접근 제어 제품의 프록시 계층과 예외 관리 계층을 분리한다. 프록시 계층은 기존과 같이 정책 평가와 차단 집행을 수행하면서 활성 임시 예외 조회 및 차단 컨텍스트 등록을 통해 예외 관리 계층과 연동한다. 예외 관리 계층은 정적 차단 응답과 예외 요청 웹 애플리케이션 제공, 서버 측 예외 검증, 토큰 무결성 및 재사용 방지, 임시 예외 부여 및 저장, 임시 예외 사용 및 재접속 처리, 구조화된 감사 로그 기록을 수행한다. 이를 통해 사용자의 업무상 필요를 예외 요청 과정에서 구조화하여 수집하고, 위험 등급에 따라 서로 다른 수준의 마찰과 제한 조건을 적용하며, 모든 예외 처리 과정을 감사 가능한 형태로 기록할 수 있다.
본 논문에서는 제안 시스템의 동작 가능성을 검증하기 위해 프록시 계층과 예외 관리 계층의 연동 인터페이스, 차단 컨텍스트 관리 모듈, 예외 요청 웹 애플리케이션, 예외 관리 서비스, 단기 상태 저장소, 감사 로그 수집기로 구성된 Docker 기반 프로토타입을 구현하였다. 구현 결과, 프록시가 차단 컨텍스트를 등록하고 사용자가 예외 요청 웹 애플리케이션에 접근한 뒤, 위험 등급에 따른 상호작용과 서버 측 검증을 거쳐 제한된 시간 동안 임시 예외가 적용되는 전체 흐름이 정상적으로 수행됨을 확인하였다. 또한 예외 요청, 검증, 승인 또는 거부, 임시 예외 사용 및 만료 과정이 구조화된 감사 로그로 기록됨을 확인하였다. 평가 지표와 유스케이스 분석 결과, 제안 시스템은 기존 차단 응답을 사용자 업무 맥락과 위험 수준을 반영한 통제 가능한 정책 예외 요청 절차로 확장할 수 있음을 보였다.

목차 (Table of Contents)

• 제1장 서론 1
• 제2장 배경 및 관련 연구 5
• 2.1 기술적 배경 5
• 2.1.1 투명 프록시와 TLS 인터셉션 5
• 2.1.2 상용 SWG의 웹 접근 제어 기능 및 차단 응답 8
• 2.2 사용자 중심 보안 통제와 보안 의사결정 관련 연구 13
• 2.2.1 사용 가능한 보안 15
• 2.2.2 보안 경고 16
• 2.2.3 보안 강화 마찰과 넛지 17
• 2.2.4 그림자 보안 18
• 2.3 사용자 자율 정책 예외 시스템의 필요성 20
• 제3장 설계 목표와 요구사항 21
• 3.1 설계 목표21 3.1.1 사용자 자율 정책 예외 요청 22
• 3.1.2 감사 가능한 로그 수집 22
• 3.1.3 위험 등급 기반 차등적 처리 23
• 3.1.4 프록시 계층과 예외 관리 계층의 분리 24
• 3.2 위험 등급 분류 기준 25
• 3.2.1 등급 1: 절대 금지 26
• 3.2.2 등급 2: 조건부 허용 26
• 3.2.3 등급 3: 미분류 27
• 3.3 설계 요구사항 28
• 3.3.1 정적 차단 응답과 정책 예외 요청 인터페이스의 분리 29
• 3.3.2 예외 요청 사유 및 업무 맥락의 구조화된 수집 29
• 3.3.3 임시 예외 제한 30
• 3.3.4 구조화된 감사 로그 수집 31
• 3.3.5 위험 등급 기반 서버 예외 검증 32
• 3.3.6 불투명 식별자 기반 차단 컨텍스트 연결 ·33
• 3.3.7 예외 요청 토큰의 무결성 보장 및 재사용 방지 34
• 3.3.8 프록시 계층과 예외 관리 계층의 연동 인터페이스 분리 35
• 제4장 정책 예외 시스템 설계 37
• 4.1 정책 예외 시스템 개요 38
• 4.1.1 구성요소 41
• 4.2 활성 임시 예외 조회 42
• 4.3 차단 컨텍스트 등록 및 불투명 식별자 발급 43
• 4.4 정적 차단 응답 제공 44
• 4.5 예외 요청 웹 애플리케이션 구성 45
• 4.6 예외 요청 검증 47
• 4.7 토큰 무결성 및 재사용 방지 48
• 4.8 임시 예외 부여 및 저장 48
• 4.9 임시 예외 사용 및 재접속 처리 50
• 4.10 감사 로그 및 보안 운영 연계 51
• 제5장 정책 예외 시스템 구현 53
• 5.1 구현 환경 53
• 5.2 프록시 연동 인터페이스 구현 55
• 5.3 예외 관리 서비스 구현 56
• 5.3.1 차단 컨텍스트 등록 57
• 5.3.2 토큰 발행 57
• 5.3.3 예외 요청 검증 및 승인 58
• 5.4 단기 상태 저장 및 임시 예외 관리 59
• 5.4.1 차단 컨텍스트 저장 59
• 5.4.2 재사용 방지 60
• 5.4.3 임시 예외 저장 60
• 5.5 예외 요청 웹 애플리케이션 구현 61
• 5.6 감사 로그 수집 구현 61
• 5.7 Docker 기반 실행 환경 62
• 제6장 유스케이스 분석 및 연구 비교 63
• 6.1 평가 지표63 6.1.1 정책 예외 처리 시간 63
• 6.1.2 사용자 숙고 지표 64
• 6.1.3 예외 남용 탐지 지표 65
• 6.1.4 감사 가능성 지표 66
• 6.2 유스케이스 기반 분석 67
• 6.2.1 유스케이스 1: 업무 목적에 따른 조건부 예외 요청 67
• 6.2.2 유스케이스 2: 고위험 사이트 접근 시도 69
• 6.2.3 유스케이스 3: 반복 예외 요청을 통한 정책 우회 시도 70
• 6.2.4 유스케이스 4: 신규 또는 미분류 도메인 접근 71
• 6.2.5 유스케이스 5: 오분류 신고와 임시 예외 요청의 분리 73
• 6.2.6 유스케이스 6: 토큰 재사용 및 만료된 예외 사용 시도 74
• 6.3 기존 방식 및 관련 연구와의 비교 75
• 제7장 결론 및 향후 연구 방향 78
• 참고문헌 85
• ABSTRACT 88