Cloudflare Access, 포트 80 사설 HTTP 앱 로그인 흐름을 브라우저 기반으로 변경
Cloudflare는 Access에서 포트 80으로 제공되는 평문 HTTP 사설 애플리케이션의 인증 방식을 바꿨다. 이제 사용자가 해당 앱에 접속하면 Cloudflare One Client 알림을 거치는 대신 브라우저에서 바로 Access 로그인 페이지를 보게 되며, 인증 성공 시 표준 Access 애플리케이션 토큰을 받는다.
무엇이 바뀌었나
기존에는 평문 HTTP 사설 앱이 SSH, RDP 등 비HTTP 프로토콜과 같은 세션 흐름으로 처리됐다. 사용자는 Cloudflare One Client의 인증 필요 팝업을 확인한 뒤, 알림을 눌러 브라우저 로그인으로 이동해야 했다.
이번 변경으로 포트 80의 HTTP 사설 앱은 브라우저에서 직접 로그인 페이지를 표시하는 표준 흐름을 사용한다. 사용자 입장에서는 HTTPS 사설 앱에 접속할 때와 더 비슷한 경험으로 바뀐 셈이다.
운영자가 확인할 영향 범위
이번 변경은 인증 UX와 세션 처리 주체에 영향을 준다. Cloudflare One Client는 여전히 사설 네트워크로 트래픽을 라우팅하는 데 필요하지만, HTTP 앱의 Access 세션 관리는 더 이상 클라이언트가 담당하지 않는다.
사내 관리용 웹 도구, 레거시 운영 포털, 내부 API 프런트엔드처럼 아직 HTTP로 남아 있는 서비스가 있다면, 사용자 문의 유형이 바뀔 수 있다. 기존에는 클라이언트 알림 승인 절차 안내가 중요했다면, 이제는 브라우저 로그인 페이지 노출과 토큰 기반 세션 동작을 기준으로 안내 문구와 접속 가이드를 정리하는 편이 적절하다.
한국·일본 IDC 및 호스팅 운영 관점
IDC나 코로케이션 환경에서 운영되는 내부 웹 관리 도구 중 일부는 폐쇄망 또는 사설 경로를 이유로 포트 80 HTTP를 유지하는 경우가 있다. 이런 서비스에 Cloudflare Access를 적용했다면, 원격 운영자나 고객사의 접속 절차가 단순해질 수 있다.
다만 이번 발표는 HTTP 앱의 로그인 흐름 변경에 관한 내용이지, HTTP 자체의 보안성 향상을 의미하지는 않는다. 운영자는 인증 UX 개선과 별개로 해당 관리 페이지를 계속 평문 HTTP로 둘지, HTTPS 전환이 가능한지, 접속 경로 문서와 헬프데스크 안내가 현재 흐름과 맞는지를 구분해 점검할 필요가 있다.
점검 포인트
포트 80의 사설 HTTP 애플리케이션에 대해 Access를 적용 중인지 먼저 식별한다. 사용자 가이드, 운영 문서, 사내 FAQ에 Cloudflare One Client 알림 팝업을 전제로 한 설명이 남아 있다면 브라우저 로그인 기준으로 수정하는 것이 좋다.
비HTTP 프로토콜은 이번 변경 대상이 아니다. SSH, RDP, 임의의 TCP/UDP 접근 절차는 계속 기존 클라이언트 알림 흐름을 사용하므로, 운영 문서에서 HTTP 앱과 비HTTP 앱의 인증 절차를 분리해 안내해야 혼선을 줄일 수 있다.
핵심 포인트
- 포트 80의 평문 HTTP 사설 앱이 브라우저 기반 Access 로그인 흐름으로 변경됐다.
- 설정 변경은 필요하지 않다.
- Cloudflare One Client는 여전히 사설 네트워크 라우팅에 필요하다.
- HTTP 앱의 Access 세션 관리는 더 이상 Cloudflare One Client가 담당하지 않는다.
- SSH, RDP, TCP/UDP 등 비HTTP 프로토콜은 기존 알림 기반 인증 흐름을 유지한다.