Ollama や LM Studio を自宅サーバで動かし、外出先のスマホからアクセスしたい——そんな需要に Cloudflare Tunnel + Access という構成が注目されている。設定手順は GIGAZINEの記事 が詳しいが、ここではネットワーク構成のセキュリティ的な意味と落とし穴をハッカー視点で整理する。
Tunnel だけでは「認証なし公開」と同じ #
cloudflared デーモンがアウトバウンドで Cloudflare エッジに接続し、外部からのトラフィックを折り返す——これが Tunnel の本質だ。ルーターのポート開放が不要なためポートスキャンには映らず、侵入経路の「見える化」防止という点では有効だ。
ただし Cloudflare Access を設定しなければ、公開 URL を知っている人間は世界中からアクセスできる。Ollama のデフォルトは認証なし REST API を露出するため、Tunnel だけの状態 = 無制限アクセスと同義だ。実際、Shodan を使った調査では認証なしで公開されている Ollama エンドポイントが世界で数千件単位で見つかっており、モデルへの無制限クエリや /api/pull でのモデル引き込みが可能な状態になっていた事例も報告されている。
Access を追加すれば Google / GitHub / メール OTP などの IdP 認証がエッジで挟まり、未認証リクエストは弾かれる。数分の設定コストでネットワーク層の保護が完成する。
Cloudflare 自体を「信頼する」という前提を見落とすな #
ここで立ち止まりたいのが「ゼロトラスト」の定義だ。Cloudflare はエッジで HTTPS を終端する——つまりユーザーとサーバーの間に Cloudflare という中間者が存在し、全トラフィックを平文で読める状態にある。無料プランでも有料プランでもこの構造は変わらない。
個人の趣味用モデルなら許容範囲かもしれないが、業務上の機密情報を含むプロンプトや出力を扱う場合は別の話だ。「ゼロトラスト = ベンダーも信頼しない」が原則のはずだが、Cloudflare Tunnel はそのベンダーを信頼基盤に置く設計であると明確に認識しておく必要がある。
認証後のアプリ層リスク: プロンプトインジェクション #
Access で正当に認証されたユーザーが「悪意あるプロンプト」を送り込む攻撃は、ネットワーク層では防げない。複数人が同じエンドポイントを使う環境では、プロンプトインジェクション経由でシステムプロンプトを引き出したり、モデルの挙動を書き換えたりする手法が有効になりうる。
Cloudflare Tunnel + Access はネットワーク層の保護として優秀な選択肢だ。しかし「設定したから安全」で思考を止めると、アプリケーション層の信頼モデルという別次元のリスクを見落とす。セキュリティは層を重ねて初めて成り立つ——Tunnel と Access はその最初の 1〜2 枚目にすぎない。
COMMENTS 0
No comments yet — be the first to leave one.