AI 샌드박스의 egress 방화벽: IP 대신 TLS SNI 호스트명 필터링

AI가 생성한 코드를 샌드박스에서 실행할 때 아웃바운드 네트워크를 제어하는 기존 IP 기반 방화벽은 수천 개 도메인이 CDN IP를 공유하는 현대 인터넷에서 무력하다. Vercel Sandbox는 TLS 핸드셰이크의 SNI(Server Name Indication) 필드를 검사해 데이터 전송 전에 대상 호스트명 기반으로 연결을 차단하는 egress 필터링을 지원한다. HTTP 프록시 없이 TLS 레이어에서 동작하므로 Redis, Postgres 등 모든 TLS 기반 프로토콜을 커버하며, 실행 중인 샌드박스에서 재시작 없이 정책을 동적으로 변경할 수 있다.

핵심 포인트

IP 기반 방화벽 한계: 수천 개 도메인이 CDN IP를 공유해 IP 차단으로는 도메인 단위 제어가 불가능하다
SNI 필터링: TLS ClientHello의 SNI 필드를 검사해 대상 호스트명을 추출 — 데이터 전송 이전에 핸드셰이크 단계에서 차단
프로토콜 무관: TLS 레이어에서 동작하므로 HTTP뿐 아니라 Redis, Postgres, gRPC 등 TLS 기반 모든 프로토콜 지원
CIDR 블록도 병행: IP 범위 기반 필터링과 도메인 기반 SNI 필터링을 함께 사용 가능
동적 정책 변경: 실행 중 샌드박스에서 재시작 없이 egress 정책 실시간 업데이트
단계별 접근 제어: 의존성 설치 → 코드 실행 → 결과 전송 → 완전 차단의 단계적 네트워크 정책 가능

상세 정리

보안 위협 배경: AI 에이전트가 생성한 코드나 신뢰할 수 없는 코드를 샌드박스에서 실행할 때, 손상된 코드가 데이터를 외부로 유출하거나 의도치 않은 API를 호출할 수 있다.
IP 기반 방화벽의 실패 이유: Cloudflare, Akamai 같은 CDN 때문에 수천 개 도메인이 소수 IP를 공유한다. 특정 IP를 허용하면 원하지 않는 다른 도메인들도 함께 허용된다.
SNI 필터링 원리: TLS 핸드셰이크의 ClientHello 메시지에는 클라이언트가 접속하려는 호스트명이 SNI 필드에 평문으로 포함된다. 방화벽이 이 초기 바이트를 검사해 허용 도메인 목록과 대조한다.
차단 시점: TLS 핸드셰이크 단계에서 승인되지 않은 목적지를 차단한다. 데이터가 전혀 전송되기 전에 연결이 거부되므로 데이터 누출 위험이 없다.
프로토콜 무관성: HTTP 프록시 방식이 아니라 네트워크 레이어에서 TLS를 검사한다. Redis(TLS), Postgres(TLS/SSL), gRPC 등 HTTP가 아닌 프로토콜에도 동일하게 적용된다.
와일드카드 지원: *.github.com처럼 와일드카드 도메인 패턴으로 CDN 뒤의 서비스 전체를 허용하거나 차단할 수 있다.
동적 정책 업데이트: 실행 중인 샌드박스에서 프로세스 재시작 없이 네트워크 정책을 변경한다. 단계별로 의존성 설치 단계에선 패키지 저장소 허용, 코드 실행 단계에선 필요한 외부 API만 허용, 완료 후엔 전체 차단하는 순차적 정책이 가능하다.
기본값: 기본은 무제한 인터넷 접근. 신뢰할 수 없는 코드를 실행할 때만 정책을 추가하는 선택적 보안 레이어다.

왜 읽나AI 에이전트 코드 실행 환경, 서드파티 코드 샌드박싱, 또는 제로트러스트 egress 보안을 설계하는 보안/인프라 엔지니어에게 TLS SNI 필터링이 IP 기반 방화벽의 한계를 어떻게 극복하는지 실용적인 관점에서 설명한다.

Vercel Blog 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

AI 샌드박스의 egress 방화벽: IP 대신 TLS SNI 호스트명 필터링

이 글과 비슷한

사이트 소유자를 위한 새 AI 트래픽 제어 옵션

Cloudflare 앱 생태계 OAuth 전면 개방 — Hydra 마이그레이션 내막

양자 내성 암호화 행정명령(EO 14409) — 2030 전환 기한과 조직 대응 방안