「ノー・ルート」企業コンプライアンスの視点：2026年の開発者トンネルのセキュリティ

開発者トンネルは便利さから始まりました：1つのコマンドで、localhost上で動作しているサービスに対してWebhookのテストや同僚へのプレビュー表示用の公開HTTPS URLを取得できます。ゼロトラスト環境では、その同じ便利さはラップトップからパブリックインターネットへの未管理の経路となり、セキュリティチームの注目を集めています。

この記事では、「rootless」が実際に何をもたらすのか、何をもたらさないのか、どのツールが本当に昇格権限なしで動作するのか、そして開発者が従うトンネルポリシーの展開方法について解説します。

なぜ脅威モデルが重要なのか（そして一般的な誤解）

リバーストンネルは、プライベートマシンが外向きに開く接続です。公開サーバーはその接続を通じてインバウンドトラフィックを中継します。プライベートマシンはインバウンドを受け付けないため、自宅ルーターや企業のファイアウォール、キャリアグレードNATの背後からでも動作します。

このアウトバウンド専用の設計が、トンネルの採用を容易にし、ガバナンス上の問題となる理由です。インバウンドアクセスを止めるファイアウォールルールはこれらを認識しません。

権限が関係するのはどこか？2つのポイントです：

• エージェント自体。 ほとんどのトンネルクライアントはアウトバウンド接続とローカルポートへの通信だけで済み、特別な権限は不要です。昇格権限が必要になるのは、エージェントを永続的なシステムサービスとしてインストールする場合や、ネットワークスタックを操作するモードを使用する場合です。例えば、zrokのVPNバックエンドモードはsudoでドキュメント化されていますが、通常のプロキシ共有はそうではありません。
• 公開されているアプリケーション。 これが見落とされがちなポイントです。攻撃者があなたのトンネルURLを見つけて、その背後のアプリのバグを悪用した場合、得られるのは*そのアプリのプロセスの権限*です。管理者として動作する開発サーバーや、Dockerソケットやクラウド資格情報にアクセスできる状態のサーバーは、実際のリスクの範囲です。トンネルクライアントを非特権で動かすのは良い習慣ですが、公開されているアプリも同様に非特権で動かすことが重要です。

Linuxでは、1024未満のポートにバインドするには伝統的に昇格した権限が必要であり、そのため自己ホスト型のトンネルサーバーは高いポートで待ち受けるか、リバースプロキシの背後に置かれることが多いです。例えばboreは、デフォルトで1024以上のポートを受け付ける設定になっています。

Rootlessは必要条件であり、十分条件ではない

rootを放棄すればトンネルがコンプライアンスに適合する、あるいはエンドポイント検知から見えなくなると考えるのは誤りです。どちらも正しくありませんし、後者はそもそもコンプライアンスプログラムの目的ではありません。

トンネルユーティリティは、MITRE ATT&CKのProtocol Tunneling（T1572）として記録されている攻撃手法です。具体的なデータポイントは以下の通りです：

• CISAのAkiraランサムウェアグループに関する共同アドバイザリーでは、ngrokなどのトンネルユーティリティを使って暗号化されたコマンド＆コントロールセッションを確立し、境界監視を回避していると記載されています。また、Cloudflare TunnelもC2に使用されているとリストアップされています。
• Cofenseの2026年3月の分析では、攻撃者がCloudflare Tunnels、特に無料のTryCloudflare機能を悪用して、一時的で難読化された接続を設定し、自身のインフラを隠している事例を報告しています。
• SecuronixのSERPENTINE#CLOUD調査は、trycloudflare.comのサブドメインにペイロードをホストしたキャンペーンを記述しています。
• GuidePointのインシデント対応チームは、2023年頃からcloudflaredが侵入に使われている事例を記録し、正当なツールでも検知の可能性が低くなると指摘しています。

防御側は、権限に基づく検知ではなく、挙動に基づく検知を採用しています。Splunkの「Windows Potential Cloudflared Network Connection」解析（2026年5月更新）は、EDRのテレメトリに基づいています：プロセス名、親プロセス、コマンドライン全体です。Elasticは、「Potential Protocol Tunneling via Cloudflared」という事前定義ルールを提供しています。

コンプライアンスプログラムのポイント：承認されたrootlessで*インベントリ化された*トンネルとログ記録があれば十分に防御可能です。未承認のトンネルは、rootで動作しているかどうかに関わらず、ネットワークから見れば攻撃者のトンネルと区別がつきません。「検知回避」を反意とし、承認されたトンネルを容易に識別・ホワイトリスト化できるようにすることが目的です。

Rootlessツールボックス

SSHベースのツール：インストール不要

SSHリモートフォワーディングは、最も古典的なリバーストンネルであり、Windows、macOS、ほぼすべてのLinuxディストリビューションに標準搭載されているOpenSSHクライアントを使用します。新たなバイナリの検証は不要です。

localhost.runは、コマンド一つでサインアップ不要です：

ssh -R 80:localhost:8080 nokey@localhost.run

無料ドメインは引き続き無料ですが、FAQによると無料トンネルは数時間後にドメイン名が変わるため、Webhook登録の安定したURLには適しません。SSHキーを使い、nokeyの代わりにキー認証を行えば、ドメインは接続間で維持され、lhr.rocksやカスタムドメイン（$9/月、年払い）も利用可能です。

Pinggyも同じアプローチを採用しています：

ssh -p 443 -R0:localhost:3000 free.pinggy.io

Pinggyのヘルプページによると、無料プランは60分のトンネルタイムアウトがあり、新たにトンネルを開始すると新しいURLが発行されます。永続的なURLやカスタムドメインはProプランが必要です。TCPとTLSトンネルは無料で利用可能です。セキュリティ面で注意すべき点は、Pinggyがトンルトラフィックを読み取ってWeb Debugger機能を動かしている点と、「ゼロトラスト」モードではデータを読めないTLSトンネルを推奨している点です。ポート443で動作しているため、通常のHTTPSの出口と見なされ、開発者にとって便利であり、承認リストに載せるべき理由です。

セルフホスト型バイナリ：第三者をデータ経路に入れない

frp (Fast Reverse Proxy)は、自己ホスティングの標準です。frpsを管理下のVPSに、frpcを開発者のマシンに配置し、TCP、UDP、HTTP、HTTPSのフォワーディングを行います。現在も活発に開発されており、リリースページにはv0.70系が掲載されています。コンプライアンスに関係するポイントは以下の通りです：

• v0.50.0以降、クライアントとサーバ間のTLSがデフォルトで有効になっています。
• transport.tls.force = trueをサーバ側に設定すれば、非TLSクライアントを拒否できます。
• v0.69.0以降、サポート期間のドキュメントもあり、各マイナーリリースは次の9つのマイナーリリースまでサポートされ、クライアントとサーバの互換性も保証されます。

boreは最小限の選択肢です。READMEによると、約400行の安全な非同期Rustコードで、クライアントとサーバのバイナリ一つだけで構成され、設定ファイルは不要です：

bore local 8000 --to bore.pub

TCPのみ対応で、セキュリティ上の注意点も明示されています。--secretは初期ハンドシェイク時のHMACチャレンジに使われますが、READMEではデフォルトではトラフィックは暗号化されません。機密情報はTLSを自己用に用意すべきです。サーバはコントロールポート（7835）を使用し、デフォルトでは1024以上のポートのみを割り当てます。これは理解しやすいですが、既に管理しているサーバ向けのツールです。

zrok（OpenZitiベース）は、異なる考え方を採用しています：プライベートシェアです。プライベートシェアはOpenZitiネットワーク内に限定され、zrok accessを通じてアクセスされます。HTTP/HTTPSのパブリックシェアやWebDAVを使ったファイル共有の「ドライブ」モードもあります。なお、zrok 2.0（2026年初頭リリース）は、バイナリ名をzrok2に変更し、環境ディレクトリを~/.zrok2に移し、予約済みシェアを名前空間と予約名に置き換えています。古いチュートリアルのzrok reserveは最新リリースと一致しません。

エッジネットワークとID認証対応オプション

Cloudflare Tunnel（cloudflared）は、Cloudflareのエッジに対してアウトバウンド接続を行います。クイックトンネルはアカウント不要です：

cloudflared tunnel --url http://localhost:8080

Cloudflareの公式ドキュメントでは、クイックトンネルはテスト用と明示されており、同時リクエスト数は200に制限され、Server-Sent Eventsはサポートされません。本番運用には、Cloudflareアカウントとドメインが必要な名前付きトンネルを使います。これにより、安定したホスト名とアクセス制御ポリシーを設定できます。Threatレポートで頻繁に登場するTryCloudflareは、多くのセキュリティチームが*.trycloudflare.comをブロックし、企業アカウントに紐づく名前付きトンネルのみ許可しています。

Microsoft Dev Tunnelsは、管理された環境向けの選択肢です。トンネルのホスティングにはMicrosoft Entra ID、MicrosoftまたはGitHubアカウントでのサインインが必要です。匿名ユーザはトンネルを作成できません。デフォルトでは、作成者のみがホストまたは接続可能です（--allow-anonymousで明示的に許可可能）。Microsoftのドキュメントでは、トンネルIDを推測されると誰でもローカルサーバにアクセスできると警告しています。アクセスは、--tenantやGitHub組織に拡張可能です。管理者向けには、グループポリシーで匿名アクセスを完全に無効化したり、EntraテナントIDのホワイトリスト制限も可能です。Microsoftは、*.devtunnels.msなどのアウトバウンドドメインも公開しており、ネットワークレベルで許可・拒否できます。

ngrokは、最もよく知られた商用オプションです。エージェントはポート443でアウトバウンドTLS接続を開き、無料プランには1つのエージェント、静的ドメイン、トラフィック検査・リプレイ、HTTP/HTTPS/TCPエンドポイントが含まれます。OAuthやBasic認証はTraffic Policyを通じて適用されます。エージェントはroot専用ツールではありませんが、CISAのアドバイザリにCloudflare Tunnelとともに名前が挙がっているため、インベントリに登録しておくべきです。

企業管理：Packetriot Spokes

中央管理が必要なチーム向けに、PacketriotはSpokesを提供しています。これはエッジサーバのセルフホスティング（またはベンダー管理）版です。ドキュメントによると、標準のPacketriotクライアントはSpokesに対しても同じように動作し、管理者がクライアント登録と認証トークンを管理します。

ベンダーの企業向けページの内容は以下の通りです：

• Spokesは、HTTP/SとTCPトンネルをチームやデバイス群に提供し、トラフィック、セキュリティ、監査の制御を強化します。1インスタンスで数千のトンネルにスケール可能です。
• 配布は公式Dockerコンテナ、Kubernetes、RPMやDEBパッケージ経由。デフォルトのデータストアはSQLiteで、大規模展開にはMariaDBやPostgresも選択可能。
• ライセンスは年間契約で、トンネル数に応じて料金設定：100トンネルまで$1,000、250トンネルで$2,000、500トンネルで$3,500、さらに多い場合はカスタム見積もり。30日間の試用ライセンスも提供。
• ベンダーは、オンプレミスホスティングによりHIPAA、GDPR、SOX、PCIなどの規制に既存のコントロールを再利用できると主張。ただし、これはベンダーの立場であり、認証ではありません。Spokesを自環境で動かす場合、ログ記録やアクセス制御の検証は自社の監査要件に従う必要があります。

クライアント側の設定は、開発者用の一時的な設定と、常時稼働のシステム全体用の設定に分かれます。ポリシーとしては、開発者のラップトップには前者を、管理されたデバイスには後者を適用します。

この層の正当な代替案は、自己ホスティングのfrp展開や、SAMLや監査機能付きのCloudflareやngrokの有料プランです。どちらを選ぶかは、データ経路と監査ログの保存場所次第です。

組み込みトンネル：真のトレンドと検知のトレードオフ

一部のチームは、スタンドアロンのトンネルバイナリから、アプリケーション内で作成されるトンネルへと移行しています。これは実在し、ベンダーもサポートしています：

• ngrok Agent SDKs（Go、JavaScript、Python、Rust）は、アプリがプログラム的にエンドポイントを作成できるもので、ngrokのドキュメントでは、クラウドからのトラフィックはアプリがリスニングソケットを開いたかのように扱われると記載されています。エージェント管理を避けたい場合に推奨されます。
• OpenZitiとzrokは、ゼロトラスト接続をアプリに直接埋め込むSDKを提供しています。
• Pinggyは、プログラム的にトンネルを作成できるPython SDKを提供しています。

セキュリティの向上は確かです：トンネルはアプリのユーザ、リソース制限、ネットワークポリシーを継承し、プロセス終了とともに消えるため、長期的なバックグラウンドサービスを忘れる心配がありません。

一方、可視性の問題もあります。アプリ内で作成されたトンネルは、ngrokやcloudflaredのプロセスとして認識されず、プロセス名やコマンドラインに基づく検知は失敗します。埋め込みトンネルの検知は、DNS、プロキシ、ファイアウォールのテレメトリに移行する必要があります：どのホストがビルドエージェントや開発マシンと通信しているか、そしてそれらのトンネル提供ドメインが承認リストにあるかどうかです。

「TunnelAPI 2.0」についての注意。 これはアプリランタイムにトンネルを埋め込むための標準とされることがありますが、実際にはそうではありません。TunnelAPIは、docs.tunnelapi.inに記載された単一ベンダーのホステッドプラットフォームで、HTTPSトンネルとAPIゲートウェイ、Kubernetes ingressコントローラー、SAML/OAuth/OIDC認証を組み合わせたものです。コミュニティの「awesome-tunneling」ディレクトリに、以前の1.0ツールとともにリストされています。評価は可能ですが、ベンダーニュートラルな「TunnelAPI 2.0準拠ライブラリ」の仕様は存在しません。埋め込みトンネルについては、上記のSDKを検討してください。

実際に開発者が従う展開計画

1. インベントリの作成。 EDR、DNS、プロキシのテレメトリを使って、既に使われているトンネルエージェントやドメインを特定します（長期的なアウトバウンドSSHセッションや-Rフラグも含む）。昇格権限やシステムサービスとしての実行もフラグ付けします。
2. 許容利用標準の策定。 トンネルは標準ユーザとして動作させ、意図的なポートだけを公開し、デモ以外は認証を設定し、管理者や本番資格情報を含むアプリには絶対に前面に出さないことを求めます。
3. 承認された経路の提供。 制限なしのブロックは、開発者を個人アカウントや消費者ツールに誘導します。承認済みの選択肢を1つか2つ用意します：例として、ポリシーで匿名アクセスを無効化し、テナント制限を設けたDev Tunnelsと、長期的な共有のための自己ホスティングfrpやPacketriot Spokesを併用します。
4. ネットワーク層での強制。 承認済みプロバイダのドメインを許可リストに登録し、それ以外をブロックまたはアラートします。trycloudflare.comも含め、クイックトンネルを使わない場合はブロックします。SSHやポート443のトンネルは通常の出口に溶け込むため、DNSやプロキシのログが主な管理ポイントです。
5. 検知の追加。 ベンダーのルール（SplunkやElasticのcloudflaredルールなど）を使い、承認済み展開の例外リストを設定して、アラートの有効性を保ちます。
6. 埋め込みトンネルの意図的な管理。 内部フレームワークが起動時にトンネルを作成する場合は、そのエンドポイントを登録し、認証と有効期限を設定します。
7. 定期的な見直し。 無料プランの条件や製品の挙動は頻繁に変わるため、定期的にベンダードキュメントと照合し、承認リストを更新します。

まとめ

rootなしでトンネルクライアントを動かすのは、合理的な最低ラインです。これにより、侵害されたエージェントの行動範囲を縮小し、常時稼働の特権層からトンネルを排除します。ただし、それだけではトンネルの安全性や見えなさを保証しません。より強力なコンプライアンスの立場は、承認済みで認証され、ログが記録されたトンネルのリストと、ネットワークポリシーの強制、そしてスタンドアロンと埋め込みの両方のトンネルを理解した検知です。

---

出典

• Packetriot for Enterprise: https://packetriot.com/enterprise
• Packetriot Spokesドキュメント: https://docs.packetriot.com/spokes/
• Packetriotクイックスタート: https://docs.packetriot.com/quickstart/
• Pinggyヘルプ: https://pinggy.io/help/
• localhost.run FAQ: https://localhost.run/docs/faq/
• localhost.run ホーム / 料金: https://localhost.run/
• frpリポジトリ: https://github.com/fatedier/frp
• frpリリース情報: https://github.com/fatedier/frp/releases
• boreリポジトリ: https://github.com/ekzhang/bore
• zrokリリース情報: https://github.com/openziti/zrok/releases
• zrok v2.0紹介: https://blog.openziti.io/introducing-zrok-v2-0
• zrok公開共有ドキュメント: https://docs.zrok.io/docs/concepts/sharing-public
• Cloudflare Tunnel設定（クイックトンネル制限）: https://developers.cloudflare.com/tunnel/get-started/
• Microsoft Dev Tunnelsのセキュリティ: https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/security
• Microsoft Dev Tunnelsのグループポリシー: https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/policies
• Microsoft Dev Tunnels CLIリファレンス: https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/cli-commands
• ngrok Agent SDKs: https://ngrok.com/docs/agent-sdks
• ngrokのローカルホスト共有概要: https://ngrok.com/use-cases/share-localhost
• CISA #StopRansomware: Akira: https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-109a
• Cofense、Cloudflareサービスの悪用例: https://cofense.com/blog/how-cloudflare-services-are-abused-for-credential-theft-and-malware-distribution
• Securonix、SERPENTINE#CLOUD調査: https://www.securonix.com/blog/analyzing_serpentinecloud-threat-actors-abuse-cloudflare-tunnels-threat-research/
• GuidePoint、Cloudflaredの悪用事例: https://www.guidepointsecurity.com/blog/tunnel-vision-cloudflared-abused-in-the-wild/
• Splunk、「Windows Potential Cloudflared Network Connection」解析: https://research.splunk.com/endpoint/29798d45-c9c7-4240-a5ef-d7648c016024/
• Elastic、「Potential Protocol Tunneling via Cloudflared」ルール: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/windows/command_and_control_tunnel_cloudflared
• MITRE ATT&CK T1572、Protocol Tunneling: https://attack.mitre.org/techniques/T1572/
• TunnelAPIドキュメント: https://docs.tunnelapi.in/
• awesome-tunnelingディレクトリ: https://github.com/anderspitman/awesome-tunneling