Cloudflare Tunnelで構築する公開不要なサーバー環境

攻撃される入口そのものを消し去る: Cloudflare TunnelとAccessによる統合アクセス設計

この記事の目次
  1. ポートを開けずに「内側から」つなぐトンネルの仕組み
  2. テスト環境や管理画面を外部パートナー以外からは見えなくする
  3. Tunnel(どうつなぐか)とAccess(誰を通すか)との役割分担
  4. 固定IPやポート開放を前提としないシンプルな運用
  5. すべてのサーバーをTunnelにする必要はない
  6. DOMOの視点
  7. まとめ
  8. 覚えておきたい用語

Webサイトや社内システムをインターネット経由で利用できるようにするためには、通常、外部からサーバーへ到達できる通信の「入口(受信用ポートや公開IPアドレス)」を用意します。一般の不特定多数に向けた公開Webサイトであれば、外部からのアクセスを受け付ける入口を設けるのは当然のことです。

しかし、社内向けの管理画面、開発中のプレビュー環境、CMSのログイン画面、テスト用サーバーまで、同じようにインターネットから丸見えの状態にしておく必要はあるでしょうか。「関係者や外部パートナーには安全に使ってもらいたいが、攻撃者や無関係な第三者には存在そのものを隠したい」。こうした要望に対して、サーバーをインターネットへ直接露出させず、Cloudflare経由で安全に接続する仕組みを提供するのが「Cloudflare Tunnel」です。

この節では、WAFやファイアウォールで「届いた攻撃をどう防ぐか」を考える前に、そもそも「直接狙われる入口を作らない」という発想で、Webセキュリティの設計そのものを変える手法について解説します。

ポートを開けずに「内側から」つなぐトンネルの仕組み

従来の構成では、外部からサーバーへアクセスさせるために、公開IPアドレスを用意し、ルーターやファイアウォールで特定の通信ポート(80番や443番など)を開放(インバウンド許可)します。

WAFやファイアウォールを適切に設定していれば危険な通信を遮断することはできますが、サーバーがインターネット上に直接露出している以上、攻撃者からIPアドレスをスキャンされたり、設定の隙を探されたりするリスクをゼロにすることはできません。

Cloudflare Tunnelでは、この通信の向きを完全に「逆転」させることで、攻撃のリスクを極小化します。これは、外部からサーバーへ向かってくる「インバウンド通信」を廃止し、サーバー側からCloudflareへ向かって安全な暗号化パスを伸ばす「アウトバウンド通信」のみに転換するものです。

サーバーや社内ネットワーク側に軽量の専用エージェント「cloudflared」を配置し、内側からCloudflareのエッジネットワークへ向けて保護トンネルを構築します。外部からの受信用ポート(Inbound port)を開ける必要がなく、パブリックIPアドレスを露出させることもないため、インターネット上の自動スキャンや直接攻撃の対象となるサーバーそのものの存在を、見かけ上消し去ることになります。

Cloudflare Tunnelを使えばすべての攻撃を防げるわけではありません。それでも、外部から直接狙える入口そのものを減らせるため、攻撃対象領域を小さくするという意味で大きな効果があります。

出典: Cloudflare Docs: Cloudflare Tunnel

テスト環境や管理画面を外部パートナー以外からは見えなくする

Cloudflare Tunnelのメリットが最もはっきりと発揮されるのは、マーケティングやWeb制作の現場において、公開前プレビュー環境やCMS管理画面を共有する場合です。

例えば、社内サーバーや開発環境にある制作中のキャンペーンサイトを、外部の広告代理店や制作会社に確認してもらいたいケースを考えてみましょう。従来であれば、外部アクセス用に固定IPを契約したり、ファイアウォールの設定を変更したり、わざわざ専用VPNを準備したりする必要がありました。

Cloudflare Tunnelを導入すれば、社内にあるサーバーをインターネット上に直接さらすことなく、Cloudflare経由でのみアクセスできる保護ルートを瞬時に作成できるようになります。固定IPの確保や面倒なネットワーク設定の必要はありません。

出典: Cloudflare Docs: Cloudflare Tunnel use cases

Tunnel(どうつなぐか)とAccess(誰を通すか)との役割分担

Cloudflare Tunnelを導入する際、誤解してはならないのは、「Tunnelを作っただけで、ユーザーの本人認証まで自動的に実行されるわけではない」という点です。

Tunnelはあくまで「サーバーからCloudflareへの安全な通信経路」を作る技術であり、アクセスしてきた人物が誰なのかを判定する機能は持っていません。そのため、Tunnelを作って公開用のホスト名を紐付けただけでは、URLを知っている人なら誰でもアクセスできてしまう可能性があります。

そこで不可欠となるのが、前節で解説したCloudflare Accessとの組み合わせです。サーバーを外部へ晒さずにCloudflareへの接続を可能にするCloudflare Tunnelと、アクセスしてきたユーザーの本人確認と認可をするCloudflare Accessを組み合わせるのです。

この2つをセットで運用することで、公開前のWebサイトや管理画面をインターネット上の攻撃に一切さらすことなく、必要なパートナーにだけ、安全に利用してもらう「極めて安全なアクセス環境」が完成します。

出典: Cloudflare Docs: Secure origin connections with Tunnel and Access

固定IPやポート開放を前提としないシンプルな運用

従来、社内サーバーや検証環境を外部から利用できるようにするためには、以下のようなインフラ構成やコストが必要でした。

  • 固定IPアドレスの月額契約(コスト)
  • ルーターやファイアウォールでのポート開放設定(セキュリティリスク)
  • VPN機器の設置や保守メンテナンス(運用負荷)

Cloudflare Tunnelでは、サーバー側からCloudflareのエッジへ向けて通信を確立するため、受信用ポートの開放も固定IPアドレスの契約も不要です。IPアドレスが動的に変化するIP環境や社内LAN環境、プライベートクラウド上のサーバーであっても、cloudflaredを実行するだけでCloudflareネットワークへ安全に接続できます。

「外部公開のためだけにかける設備コストや保守の手間」を大幅に削減し、インフラ構成を格段にシンプルに整理できる点が、Cloudflare Tunnelの大きな魅力です。

すべてのサーバーをTunnelにする必要はない

Cloudflare Tunnelは非常に強力な仕組みですが、すべてのWebサーバーに適用すべきというわけではありません。

一般ユーザーへ広くアクセスしてもらうことが目的の本番コーポレートサイトや大型ECサイトであれば、通常のCloudflareプロキシ(DNSのプロキシモード)を通す標準構成で十分に保護、高速化が可能です。

Tunnelの導入を検討すべきなのは、以下のような、利用者を限定したい領域です。

  • CMS(WordPress等)の管理画面、ログイン環境
  • 公開前のプレビューサイト、検証用サーバー
  • 社内限定の業務ツール・ダッシュボード
  • 開発、テスト用のAPI環境

「そこにTunnelがあるからTunnelを通す」のではなく、「そのサーバーは一般公開する必要があるのか?」を問い直すことがスタート地点です。一般公開が不要な資産であれば、Tunnelを使って「存在ごと隠す」アプローチが最適な選択肢となるでしょう。

DOMOの視点

防御を追加する前に、「公開しない」という選択肢を考える

DOMOとしてセキュリティ基盤について検討する際、最初から「WAFのルールを増やしましょう」、「認証を厳しくしましょう」といったように、防御を足し算する方向で考えることはありません。まず確認させていただくのは、「そもそも、このサーバーをインターネットから直接見える状態にしておく必要がありますか?」という根本的な問いです。

制作会社とのプレビュー環境やCMS管理画面において、とりあえずBasic認証をかけて直接公開したり、IP制限をかけたりしているケースは多く存在します。

しかし、公開する必要のないサーバーをわざわざインターネット上にさらし、後から何層もの防御壁を重ねるよりも、最初からCloudflare Tunnelを使って外部から直接到達できない状態(非公開)にしてしまう方が、構成として圧倒的にスマートで安全です。

以下の手順のようなアプローチを取ります。

  1. 公開範囲を分類する: 一般公開サイトか、限定利用のツール・検証環境かを仕分ける
  2. 公開不要なものはTunnelで隠す: 外部からの直接攻撃トラフィックを物理的にゼロにする
  3. Accessで認証されたメンバーだけを通す: ワンタイムPINや既存IdPで厳格にアクセスを制御する

守る壁を厚くする前に、攻撃される入口(隙)そのものを減らす。この発想の転換こそが、DOMOが提唱するCloudflare Tunnelを活用したセキュリティ設計の真髄です。

まとめ

Cloudflare Tunnelは、サーバー側からCloudflareへ安全な通信を作成し、受信用ポートや公開IPなしで接続を提供する仕組みです。

  • ポート開放不要のアウトバウンド接続: 外部からの直接アクセスを受け付ける入口を作らず、サーバーの露出(攻撃対象領域)を最小化
  • Accessとの組み合わせで完成: Tunnelでサーバーを隠し、Accessで「誰を通すか」を認証することで、安全な協業環境を構築
  • 限定環境(プレビュー・管理画面等)から適用: すべてのサイトをTunnelにする必要はなく、一般公開不要な資産から選択的に導入

自社のサーバーや管理画面で、不要にインターネットへ露出している場所がないか。まずは「公開不要な入口」の整理から始めるべきでしょう。

覚えておきたい用語

  • Cloudflare Tunnel: サーバー側からCloudflareへ接続し、外部公開用IPや受信用ポートを用意せずにサービスを提供する仕組み
  • cloudflared: サーバーや社内ネットワークからCloudflare Tunnelを作るためのソフトウェア
  • 固定IP: 接続するたびに変わらず、同じ値を使い続けるIPアドレス
  • ポート: サーバーがどの種類の通信を受け付けるかを識別するための入口
  • ファイアウォール: 通信を確認し、許可するものと遮断するものを制御する仕組み
  • Cloudflare Access: ユーザーを認証し、許可された人だけを指定したアプリへアクセスさせる仕組み
  • オリジンサーバー: Webサイトやアプリ本体が置かれている元のサーバー

この章のほかの記事