게이트웨이를 관리형 서비스로 제공한다
클라우드플레어는 10월 2일 OHTTP Gateway의 비공개 베타를 발표했다. 고객의 존에 유료 부가 기능으로 활성화하는 관리형 게이트웨이를 준비하며 대기 목록 신청을 받고 있다. 기존 Privacy Gateway는 역할을 분명히 하기 위해 Cloudflare OHTTP Relay로 이름을 바꾼다. 모든 고객에게 일반 제공이 완료된 서비스라는 발표와는 구분된다.
OHTTP는 IETF의 RFC 9458에 정의된 프로토콜이다. 요청은 중계자와 게이트웨이를 거친다. 중계자는 사용자 IP 등 연결 정보를 보지만 암호화된 요청 내용을 읽지 못하고, 게이트웨이는 내용을 복호화하지만 사용자의 원래 IP를 직접 받지 않는다. 한 사업자가 사용자 식별 정보와 요청 내용을 동시에 결합하지 않도록 역할과 신뢰를 나누는 방식이다.
앱 서버의 위치에 따라 두 가지 구성을 고른다
회사는 클라우드플레어 밖에 앱 서버를 두고 자체 게이트웨이를 운영할 수 있다면 Cloudflare OHTTP Relay를 쓰는 구성을 제시했다. 반대로 앱 서버가 클라우드플레어 CDN 뒤에 있거나 Workers로 동작하면 새 Gateway와 제3자 중계자를 결합하는 방식이 적합하다고 설명했다. 양쪽 역할을 같은 사업자에 맡기면 신뢰 분리의 목적을 잃을 수 있기 때문이다.
새 서비스는 이런 잘못된 구성을 줄이기 위해 Workers나 클라우드플레어 프록시 호스트에서 보낸 요청의 복호화를 거부한다고 회사는 밝혔다. 외부 클라이언트와 중계자가 이미 존재하는 서비스에서 OHTTP 요청을 받는 경우도 사용 예로 제시했다. 단순히 게이트웨이 기능을 켜는 것 외에 클라이언트 구현과 독립적으로 운영되는 중계자가 필요하다.
키와 요청 처리를 관리하되 기존 HTTP도 받는다
클라이언트는 존의 /.well-known/ohttp-gateway 엔드포인트로 형식에 맞는 요청을 보낸다. 서비스는 복호화한 요청을 앱 서버에 전달하고 응답을 다시 암호화해 돌려준다. 일반 HTTP 요청은 게이트웨이를 호출하지 않고 기존 경로로 처리할 수 있다. 클라우드플레어는 공개 키 관리도 맡고 같은 엔드포인트의 GET 요청으로 키 구성을 제공한다고 설명했다.
중계자 인증에는 복호화 전 단계의 Cloudflare Access 정책을 사용할 수 있으며 상호 TLS나 서비스 자격 증명 등이 제시됐다. 게이트웨이는 존과 연결돼 임의의 외부 도메인으로 요청을 보내는 우회 경로로 쓰이지 않도록 한다. 회사는 글로벌 네트워크 배치가 운영 부담과 지연을 줄일 수 있다고 설명했지만, 이번 발표에 모든 사용 환경의 지연 개선 수치를 제공하지는 않았다.
네트워크 보호와 요청 본문의 식별 정보는 별개다
ARCH.B가 보는 핵심 조건은 앱이 직접 보내는 정보다. 사용자 IP를 숨겨도 요청 본문에 이메일이나 계정 이름을 넣으면 서버는 그 정보로 사용자를 알아볼 수 있다. 클라우드플레어도 OHTTP가 내부 요청 본문을 바꾸지 않는다고 명시한다. RFC는 쿠키와 후속 요청에 반영되는 응답 내용 역시 요청 사이의 연결 단서가 될 수 있다고 설명한다.
따라서 프라이버시를 목표로 도입하는 팀은 전송 경로뿐 아니라 입력 스키마와 로그를 함께 살펴야 한다. 기능에 꼭 필요한 정보만 남겼는지, 같은 사용자를 장기간 연결하는 값이 있는지 확인하는 식이다. 게이트웨이 설정은 이 검토를 대신하지 않는다. 무엇을 숨기고 어떤 정보는 앱에 전달하는지 사용자에게 설명할 때도 네트워크 계층의 보호 범위를 정확히 구분해야 한다.
추가 경로의 비용과 독립 운영을 함께 검토한다
OHTTP는 일반 직접 요청보다 암호화 처리와 중계 경로를 더한다. RFC도 추가 지연과 처리 부담이 있음을 다룬다. 관리형 게이트웨이는 키 관리와 확장 같은 운영 작업을 덜어 줄 수 있지만 클라이언트와 중계자의 구성, 장애 처리와 신뢰 관계는 여전히 설계에 남는다. 베타를 시험할 때는 실제 요청 크기와 지역별 지연을 확인하는 편이 유용하다.
또한 제3자 중계자를 쓴다는 이름만으로 독립성이 완성되는 것은 아니다. 누가 각 구간의 로그를 볼 수 있고 두 역할의 정보를 결합할 수 있는지 판단해야 한다. 새 제품이 제공하는 선택지는 클라우드플레어 뒤에 앱을 운영하면서 중계자를 따로 둘 수 있다는 점이다. 프라이버시 성과는 이 배치와 앱의 데이터 처리 원칙이 함께 유지될 때 평가할 수 있다.
출처
Cloudflare Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure (새 창)
