같은 워커 연결이어도 제공 시점과 역할은 다르다
클라우드플레어는 10월 15일 보안 웹 게이트웨이와 자사 엣지 실행 환경 Workers를 연결하는 기능을 발표했다. Forward는 모든 Zero Trust 플랜에서 공개 베타로 제공된다. 허용된 HTTP 트래픽을 워커로 보내 요청과 응답을 가공하는 동작이다. 패턴 탐지 결과를 추가 확인하는 DLP 맞춤 검증 함수도 제공을 시작했다고 밝혔다.
반면 Gateway 정책 조건에서 값으로 쓰는 Custom Functions는 연말 이전 제공 계획이다. 이 기능은 워커가 문자열·숫자·불리언을 반환해 네트워크나 HTTP 규칙의 선택 조건을 확장하는 방식이다. DLP 검증과 이름이 비슷하지만 별개의 진입점이며, 세 기능을 모두 정식 출시된 하나의 기능으로 볼 수는 없다.
Forward는 원래 목적지로 이어지는 처리 경로다
공식 가이드는 HTTP 요청 정책이 허용한 트래픽에서 우선순위상 처음 맞는 Forward 규칙의 워커를 호출한다고 설명한다. 요청 정책의 Block은 워커 호출을 막으며, 맞는 Forward 규칙이 없으면 워커 없이 기존 경로로 진행한다. 워커는 헤더·쿠키·본문 등을 바꾸거나 자체 응답을 반환할 수 있다.
원래 목적지로 요청을 이어 보내는 next()는 호출당 최대 한 번 쓸 수 있다. 목적지 URL과 호스트를 바꾸거나 상위 요청을 재시도하고 여러 목적지로 보내는 용도가 아니다. 일반 fetch()는 독립적인 하위 요청이므로 사용자의 Gateway 정책이나 외부 연결 IP를 그대로 따른다고 가정해서도 안 된다.
본문 검사 경계가 가공 코드의 책임을 정한다
Gateway는 원래 요청 본문을 검사한 뒤 워커에 전달하고, 워커가 만든 최종 응답도 검사한다. 그러나 워커가 바꾼 요청 바이트를 목적지에 보내기 전에 다시 검사하지는 않는다. 따라서 요청을 지우거나 가리는 코드로 최초 DLP 검사를 건너뛸 수 없고, 허용된 요청에 새로 붙인 데이터에는 두 번째 요청 측 검사가 보장되지 않는다.
현재 Forward 가이드는 워커 선택 조건을 요청 메타데이터·사용자 신원·장치 상태로 한정하며 DLP 일치 결과나 응답 선택자로 워커를 고를 수 없다고 명시한다. 도입팀은 발표의 활용 예시만으로 규칙을 만들기보다 현재 지원되는 조건과 검사 경계를 기준으로 설계해야 한다. 민감한 데이터를 추가하는 변환이라면 코드 자체의 검토도 필요하다.
DLP 검증은 패턴 일치의 신뢰도를 조정한다
DLP 맞춤 검증 워커는 사용자 정의 패턴이 맞았을 때 조직별 추가 검사를 수행한다. 입력에는 탐지 항목 ID와 일치 위치, 요청 메서드·URL 등이 들어가며 일치 내용과 주변 문맥은 base64로 인코딩된 excerpt에 담긴다. 사용자 ID는 선택 항목이다. 워커는 신뢰도를 높이거나 낮추고, 해당 일치를 거부할 수 있다.
공식 계약은 -1부터 1까지의 점수를 허용한다. 양수는 신뢰도를 높이고 음수는 낮추며 0은 그대로 유지한다. veto는 일치를 거부하는 별도 결과다. 편집 화면에서 오류나 시간 초과의 기본 동작을 정하고, 해당 탐지 항목을 사용자 정의 DLP 프로필에 넣어야 스캔에 사용된다. 단순히 워커를 배포한 것만으로 모든 DLP 규칙이 바뀌는 구조는 아니다.
HTTPS·프로토콜·실패 조건을 먼저 확인한다
Forward로 HTTPS를 처리하려면 TLS 복호화를 켜고 테스트 장치가 신뢰하는 루트 인증서를 설치해야 한다. Do Not Inspect에 해당하는 트래픽에는 워커를 호출하지 않는다. WebSocket과 HTTP CONNECT 터널도 선택된 워커를 우회하므로 일반 HTTP 변환을 모든 통신에 적용할 수는 없다.
워커 오류나 Gateway와의 통신 실패는 원래 요청을 그냥 통과시키지 않고 차단하는 방향으로 동작한다. 연결된 워커를 삭제해도 Forward 규칙이 자동 해제되지 않아 해당 요청은 HTTP 500으로 실패한다. 변경 관리에는 코드 배포뿐 아니라 참조 규칙 교체와 실패 대응이 들어가야 한다. 보안 프록시 서버 운영을 덜어도 정책 코드 운영까지 사라지는 것은 아니다.
네트워크 우회 감소가 무제한 성능을 뜻하지 않는다
회사는 Gateway와 Workers가 같은 장비에서 동작해 워커 호출 자체에 추가 네트워크 홉이 없다고 설명한다. 하지만 워커 코드의 실행 시간과 외부 서비스 호출의 영향까지 없어지는 것은 아니다. 기능을 쓰는 요청은 일반 Workers 요청으로 과금되고 기존 실행·요청 제한도 적용된다. 발표는 특정 고객 환경의 지연 개선 수치를 제시하지 않았다.
실무 도입은 특정 테스트 호스트와 사용자 집단으로 범위를 좁히고 단순 통과 동작부터 검증하는 편이 적절하다. Gateway의 가이드는 응답 헤더로 호출 여부를 확인하는 절차를 제시한다. 특히 알림 같은 후속 작업은 응답 뒤 실행할 수 있어도 내구성 있는 작업 큐와 같지 않다. 보안 판단·트래픽 가공·후속 기록의 실패를 나눠 확인해야 이 확장의 운영상 이점을 평가할 수 있다.
출처
Cloudflare Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
A fully programmable secure web gateway (새 창)
