Cloudflare Tunnel의 장점과 놓치기 쉬운 보안 주의점

“포트를 열지 않고 서버를 연결한다”는 설명을 들으면 대개 두 가지가 동시에 궁금해집니다. 정말 인바운드 포트를 하나도 열지 않아도 되는가, 그리고 그렇게 연결하면 그것으로 안전이 끝나는가입니다. 앞 질문의 답은 대체로 “그렇다”에 가깝지만, 뒤 질문의 답은 “아니다”에 가깝습니다.

Cloudflare Tunnel은 인바운드 포트를 없애 주는 도구이지 접근을 통제해 주는 도구가 아닙니다. 포트를 닫아서 얻은 안전은, 무엇을 노출했고 그 앞에 어떤 정책을 붙였는지에 다시 묶입니다. 이 글은 Tunnel이 어떻게 포트 없이 연결되는지부터 시작해, 도입한 뒤 새로 지켜야 할 것들 — 노출 범위, 앞단 인증, 토큰과 자격증명 취급 — 을 정리하고, 마지막으로 Tunnel이 맞는 상황과 그렇지 않은 상황을 나눕니다.

Cloudflare Tunnel은 무엇인가

Cloudflare Tunnel은 서버 안에 설치한 작은 프로그램이 Cloudflare 네트워크로 스스로 연결을 맺어, 외부의 요청을 그 연결을 통해 서버까지 전달하는 방식입니다. 이 프로그램을 cloudflared라고 부르며, 서버 쪽에서 상주하며 Cloudflare와의 통로를 유지하는 역할을 합니다.

기존 방식과 견주면 차이가 분명해집니다. 웹 서버를 외부에 공개하려면 보통 공개 IP를 두고 방화벽에서 특정 포트를 열어, 바깥에서 그 포트로 들어오는 요청을 받습니다. Tunnel은 이 방향을 뒤집습니다. 바깥에서 서버로 들어오는 포트를 여는 대신, 서버 쪽 cloudflared가 Cloudflare로 나가는 연결을 먼저 맺어 두고, 외부 요청은 그 이미 맺어진 연결을 타고 서버에 도달합니다.

그래서 서버 입장에서는 인터넷을 향해 열어 둔 문이 없는 상태로도 외부 접근을 받을 수 있습니다. 문을 여는 대신, 안에서 밖으로 통로를 하나 뽑아 두는 구성이라고 이해하시면 됩니다.

왜 인바운드 포트를 안 열어도 되는가

핵심은 방화벽이 들어오는 트래픽과 나가는 트래픽을 다르게 다룬다는 데 있습니다. 대부분의 방화벽은 바깥에서 안으로 들어오는 연결은 기본적으로 막고, 안에서 밖으로 나가는 연결은 기본적으로 허용합니다. Cloudflare 문서도 cloudflared가 “방화벽을 통해 오리진에서 Cloudflare 글로벌 네트워크로 나가는 연결을 시작”하며, “대부분의 방화벽이 아웃바운드 트래픽을 기본 허용한다”는 점을 이용한다고 설명합니다.

Tunnel은 바로 이 기본 정책을 활용합니다. 새로 인바운드 규칙을 추가하지 않아도, 서버가 원래부터 할 수 있는 아웃바운드 연결만으로 통로가 만들어집니다. 그 결과 방화벽에서는 인바운드를 전부 막아 둔 채, 필요한 아웃바운드 연결만 허용하는 구성이 가능해집니다.

여기서 오해하기 쉬운 지점을 짚어 두겠습니다. 인바운드 포트를 열지 않는다는 것은 네트워크 계층에서 새 공격면을 만들지 않는다는 뜻이지, 그 뒤에 붙는 애플리케이션까지 안전해진다는 뜻은 아닙니다. 통로 자체는 닫힌 방화벽 위에서도 열리지만, 그 통로가 무엇으로 이어지는지는 별개의 문제입니다.

무엇이 좋아지는가

인바운드 포트를 없애는 구성이 실제로 줄여 주는 위험은 대체로 다음 세 가지입니다.

• 오리진 주소가 드러나지 않습니다. 외부 요청이 Cloudflare를 거쳐 통로로 들어오므로, 서버의 공개 IP를 인터넷에 노출할 필요가 없습니다. 공격자가 방어를 우회해 서버로 직접 요청을 보내려면 먼저 그 주소를 알아야 하는데, 주소가 드러나지 않으면 이 우회 시도의 출발점 자체가 사라집니다. 인바운드 경로를 남겨 둔 구성에서 이 우회를 막기 위해 Authenticated Origin Pulls 같은 수단을 따로 얹는 것과 견주면, 경로 자체를 없애는 쪽이 더 근본적입니다.
• 인바운드 공격면이 줄어듭니다. 열어 둔 포트가 없으면 그 포트를 겨냥한 스캔이나 무차별 접속 시도가 애초에 향할 대상을 갖지 못합니다. 열어 둔 문이 하나도 없는 벽은 두드릴 곳이 없습니다.
• 공개 IP가 필요 없습니다. 고정 공개 IP를 확보하거나 관리할 필요 없이, 사내망이나 사설 대역에 있는 서버도 통로를 통해 외부에서 접근하게 할 수 있습니다.

이 세 가지는 인바운드를 아예 없애는 방식의 이점입니다. 기존 인바운드 경로를 유지하면서 그 경로를 지키는 방법과는 접근이 다른데, 그 비교는 AWS와 Cloudflare를 함께 쓸 때 깨지는 자리에서 오리진 보호 관점으로 더 다룹니다.

깔았다고 안전해지는 것은 아닙니다

여기가 이 글의 무게중심입니다. Tunnel을 설치하면 인바운드 포트라는 위험 하나가 사라지지만, 그 자리에 접근 통제라는 새로운 과제가 생깁니다.

Tunnel은 대상을 외부에서 도달 가능하게 연결해 주는 통로입니다. 통로가 뚫렸다는 것과, 그 통로로 누가 들어와도 되는지가 정해졌다는 것은 다른 이야기입니다. 앞단에 접근 정책을 두지 않은 공개 호스트네임으로 대상을 연결하면, 인바운드 포트를 열어 두었을 때와 마찬가지로 그 주소를 아는 사람은 접근할 수 있습니다. 포트를 닫아서 얻은 안전이, 무엇을 어떻게 노출했는지에 따라 그대로 다시 열릴 수 있다는 뜻입니다.

그래서 Tunnel 도입을 “포트를 닫았으니 끝”으로 계획하면, 가장 중요한 결정 — 무엇을 노출하고 그 앞에 무엇을 세울지 — 을 건너뛴 채 통로만 뚫게 됩니다. 실제로 지켜야 할 것은 다음 절들에서 나눕니다. 무엇을 노출 대상으로 삼을지, 그 앞에 어떤 인증을 붙일지, 그리고 통로를 인증하는 토큰과 자격증명을 어떻게 보관할지입니다.

무엇을 노출하면 안 되는가

Tunnel의 안전은 노출 범위를 얼마나 좁게 잡느냐에 크게 좌우됩니다. 원칙은 하나입니다. 필요한 대상만, 대상 단위로 노출하는 것.

• 애플리케이션 단위로 좁히십시오. 특정 웹 애플리케이션 하나를 지정해 연결하면, 외부에서 도달 가능한 것은 그 대상뿐입니다. 반대로 사내 네트워크 대역을 통째로 라우팅하는 방식으로 넓게 열면, 의도한 대상 외의 자원까지 같은 통로로 도달 가능해질 수 있습니다. 넓은 라우트는 편리하지만 노출 범위를 스스로 넓히는 선택이라는 점을 함께 보셔야 합니다.
• 관리·데이터베이스 포트를 무분별하게 열지 마십시오. 서버 관리 경로, 데이터베이스 접속 포트, 내부 대시보드처럼 권한이 큰 대상일수록 노출 범위를 최소화하고, 앞단 정책과 접속 로그를 반드시 함께 두어야 합니다. 권한이 큰 경로가 가장 넓게 열려 있는 상태가 가장 위험합니다.
• 넓게 열고 나중에 좁히는 순서를 피하십시오. 처음에 편의를 위해 넓게 열어 두면, 그것을 좁힐 계기는 좀처럼 생기지 않습니다. 필요한 것부터 좁게 열고 필요할 때 넓히는 순서가 결과적으로 더 안전합니다.

빌드업웍스의 운영 경험에서는, Tunnel 구성에서 사고로 이어질 소지가 가장 큰 지점이 기능의 부족이 아니라 노출 범위를 필요 이상으로 넓게 잡는 초기 설정이었습니다. 무엇을 열지 목록으로 먼저 정하고, 그 목록에 없는 것은 열지 않는 편이 뒤에 붙이는 어떤 방어보다 앞섭니다.

앞에 인증을 붙인다는 것

Tunnel과 접근 정책은 같은 층이 아닙니다. Tunnel은 연결을 담당하고, 접근 정책은 허가를 담당합니다. 통로를 뚫는 일과 그 통로로 누구를 들여보낼지 정하는 일은 나뉘어 있습니다.

접근 정책은 대상 앞에 두어 “이 사람이 이 대상에 접근해도 되는가”를 요청마다 검증하는 계층입니다. 회사 계정을 한 곳에서 관리하는 신원 공급자와 연동해, 통과한 요청만 뒤의 Tunnel로 넘기고 그렇지 않은 요청은 대상에 닿기 전에 막습니다. 이렇게 두 층을 겹쳐 두면, 설령 통로의 주소가 알려지더라도 정책을 통과하지 못한 접근은 대상까지 도달하지 못합니다.

순서로 보면 이렇습니다. 먼저 무엇을 노출할지 대상 단위로 정하고, 그 대상 앞에 인증 정책을 세운 다음, 그 뒤로 Tunnel이 대상까지 연결합니다. 통로를 먼저 뚫고 정책은 나중에 얹는 순서로 가면, 정책이 붙기 전까지의 공백 동안 대상이 그대로 노출됩니다. 이 두 층의 관계 — 위치를 신뢰하는 방식과 요청마다 검증하는 방식의 차이 — 는 Zero Trust와 VPN의 차이에서 원칙 수준으로 정리했으니 함께 보시면 맥락이 잡힙니다.

토큰과 자격증명을 다루는 법

Tunnel을 실행하려면 그 Tunnel이 정당한 것임을 증명하는 비밀이 필요합니다. 대시보드나 API로 관리하는 방식에서는 이 비밀이 토큰 형태로, 서버에서 직접 관리하는 방식에서는 자격증명 파일 형태로 존재합니다. 이름과 형태는 달라도 성격은 같습니다 — 그 값을 쥔 쪽이 해당 Tunnel을 실행할 수 있습니다.

여기서 나오는 주의점은 API 토큰 같은 다른 비밀을 다루는 원칙과 다르지 않습니다. Cloudflare 문서도 API 토큰을 생성 시점에 한 번 보여 주는 비밀로 취급하며 안전하게 보관할 것을 전제합니다. Tunnel의 토큰과 자격증명도 같은 무게로 다뤄야 합니다.

• 평문으로 흘리지 마십시오. 토큰이나 자격증명 파일을 소스 코드 저장소에 커밋하거나, 채팅·이메일로 그대로 주고받거나, 로그에 남기면 그 순간 통로 하나가 통제 밖으로 새어 나갑니다. 배포 도구의 비밀 저장소나 서버의 보호된 위치에 두고, 접근 권한을 가진 사람을 최소화하십시오.
• 어디에 배포됐는지 목록을 유지하십시오. 어떤 토큰이 어느 서버에 있는지가 정리돼 있어야, 유출이 의심될 때 무엇을 회수해야 하는지 즉시 판단할 수 있습니다. 목록이 없으면 회수 자체가 하나의 조사가 됩니다.
• 유출이 의심되면 즉시 무효화하고 재발급하십시오. 유출된 토큰은 그 Tunnel이 도달하도록 설정된 자원으로 향하는 경로입니다. 앞단 접근 정책이 한 겹 더 막아 준다 해도, 토큰 유출 자체를 안전하다고 볼 수는 없습니다. 해당 Tunnel의 토큰을 무효화하고 새로 발급하거나 Tunnel을 재생성해, 유출된 값으로는 더 이상 통로가 열리지 않게 하는 것이 원칙입니다.

정리하면, 토큰 하나가 유출되면 그것은 곧 안으로 들어오는 경로 하나가 남의 손에 들어간 것입니다. 포트를 닫아 인바운드 위험을 없앴더라도, 그 통로를 여는 열쇠를 허술하게 두면 없앴던 위험이 다른 형태로 돌아옵니다.

Tunnel이 맞을 때와 아닐 때

Tunnel은 만능 연결 수단이 아니라, 잘 맞는 자리가 정해져 있는 도구입니다. 아래로 나누면 판단이 쉬워집니다.

잘 맞는 경우

• 외부에서 접근해야 하는 대상이 웹으로 열리는 애플리케이션·관리 화면·비공개 API이고, 그 대상을 대상 단위로 지정할 수 있을 때.
• 공개 IP를 두거나 인바운드 포트를 여는 것이 부담스럽고, 오리진 주소를 드러내지 않고 싶을 때.
• 앞단에 붙일 인증 정책이 정해져 있거나 함께 세울 준비가 돼 있을 때.

별도 판단이 필요한 경우

• 네트워크 자체를 넓게 이어야 할 때. 특정 애플리케이션이 아니라 사내 대역 전반에 도달해야 하거나, 본사와 지사·사무실과 데이터센터처럼 거점 대 거점을 상시로 연결해야 하는 구간은 사람의 접근을 통제하는 문제와 성격이 다릅니다. 이런 대상까지 Tunnel로 넓게 라우팅하면 노출 범위가 커지므로, 별도의 네트워크 연결 방식을 함께 검토하는 편이 맞습니다.
• 웹이 아닌 프로토콜이 중심일 때. 데이터베이스 클라이언트, 원격 접속, 오래된 장비의 전용 프로토콜처럼 웹이 아닌 트래픽이 주가 되면, 대상 단위로 좁히고 앞단 정책과 로그를 함께 두는 설계가 웹 애플리케이션을 노출하는 것보다 손이 많이 갑니다. 다룰 수 없다는 뜻이 아니라, 더 신중한 설계가 필요하다는 뜻입니다.
• 규정이나 계약이 특정 연결 방식을 지정할 때. 발주처나 규제 요건이 전용 회선이나 지정된 접속 방식을 명시하는 경우, 기술적 우열과 무관하게 그 방식을 유지해야 합니다.

이 갈림의 바탕에는 앞서 다룬 원칙이 그대로 놓여 있습니다. Tunnel이 잘 맞는 자리는 노출 대상을 좁게 지정할 수 있고 그 앞에 정책을 세울 수 있는 곳이고, 그렇지 않은 자리 — 넓은 네트워크 연결이나 웹 아닌 프로토콜 — 는 다른 도구와 함께 봐야 합니다. VPN을 유지해야 하는 상황과의 구분은 Zero Trust와 VPN의 차이에서, AWS 자원을 함께 연결할 때의 인프라 관점은 AWS 인프라 설계·구축 범위에서 이어 보실 수 있습니다.

다음 단계

Tunnel을 검토하고 계시다면, 먼저 확인할 것은 통로 자체가 아니라 그 앞뒤입니다. 노출할 대상을 대상 단위로 좁힐 수 있는지, 그 앞에 세울 인증 정책이 정해져 있는지, 토큰과 자격증명을 안전하게 둘 자리가 있는지입니다. 보안 진단에는 네트워크 노출과 접근 통제를 묻는 항목이 포함돼 있어, 이 글에서 다룬 기준을 자신의 환경에 대입해 보실 수 있습니다. 연락처를 남기지 않아도 결과는 바로 확인하실 수 있습니다.

접근 정책과 경계를 어디까지 저희가 맡고 어디부터 별도인지 먼저 확인하고 싶으시면 통합 보안 서비스 범위를 보십시오. 지금 구조에서 무엇을 어떻게 노출하는 것이 맞을지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• Cloudflare 문서 — Cloudflare Tunnel
• Cloudflare 문서 — Cloudflare Tunnel 시작하기
• Cloudflare One 문서 — 개요
• Cloudflare 문서 — Authenticated Origin Pulls
• Cloudflare 문서 — API 토큰 생성