「ノー・ルート」企業コンプライアンスの視点：2026年の開発者トンネルの安全性確保

開発者トンネルはもともと便利さから生まれました：Webhookプロバイダーやチームメイト、クライアントがアクセスできるようにローカルの開発サーバーを公開インターネットに一時的に置くための手段です。2026年にはセキュリティチームの監視範囲内に入り、ゼロトラストプログラムやより厳格なDevSecOpsパイプラインの導入により、 workstationへの公開経路を作るものには「誰が承認したのか」「何に触れることができるのか」といった質問が必ず投げかけられます。

一般的な回答は「root権限なしで実行する」です。これは良い直感ですが、物語の半分にすぎません。トンネルエージェントを普通のユーザーとして実行することで、侵害された場合の被害を実質的に縮小できます。ただし、それだけではトンネルのコンプライアンスは保証されず、以下に示すように、これらのツールが攻撃者にとって魅力的になる性質もあります。本ガイドでは、rootlessトンネルの実態、サポートしているツール、そして堅牢な企業プログラムの構築例を解説します。

セキュリティチームが開発者トンネルを厳しく監視する理由

トンネルが怪しいのは、その仕組みが特殊だからではありません。むしろ、普通で正当なものでありながら暗号化されている点にこそ、疑念が生じるのです。

• MITRE ATT&CKは Protocol Tunneling (T1572) を、トラフィックを別のプロトコルに包むことで隠す手法として分類しています。また、ngrok は、攻撃者が複数のキャンペーンで lateral movement やデータ抽出に利用したソフトウェアとしてリストアップされています。
• Cloudflareの無料TryCloudflare機能は、悪用のターゲットになりやすいです。2024年のProofpointの報告によると、2023年以降、犯罪者によるマルウェア配信に利用されるケースが増加しています。Securonixは2025年のキャンペーンで、trycloudflare.comサブドメインにペイロードをホストした事例を記録しています。Cofenseは2026年3月に、Cloudflare TunnelsとWorkersを悪用したインシデントが2025年にピークを迎えたと報告しています。
• 2026年8月には、SpearTipのインシデント対応者がQuick Tunnelサブドメインを使ったマルウェアホスティングやペイロードステージング、ポスト侵害活動を観測しています。彼らのアドバイスは、DNS、プロキシ、ファイアウォール、EDRのテレメトリを通じて*.trycloudflare.comへのアウトバウンド通信を監視することです。
• 攻撃者は、侵害されたマシン上でcloudflaredをトークンだけで実行し、検知ツールがルールを提供しています（ElasticのPotential Protocol Tunneling via Cloudflared ルールなど）。

防御側のポイント：開発者のトンネルと攻撃者のトンネルは、通信の見た目が同じになることがあります。ポリシーは「誰が承認したか」「どこに接続しているか」で区別すべきであり、その挙動だけでは判断できません。

同じ問題に対するCISO側の見解については、以前の解説Why CISOs Are Blocking ngrokも参照してください。

「ノー・ルート」が実際に提供するもの

リバーストンネルは、プライベートマシンが外向きに開く接続です。これにより、プライベートマシンはインバウンド接続を受け付けず、家庭用ルーターや企業のファイアウォール、キャリアグレードNAT（CGNAT）を通じてポートを開けずに動作します。

このアウトバウンド専用設計のため、多くのトンネルクライアントは特別な権限を必要としません：

• ngrokエージェントは ポート443 でアウトバウンドTLS接続を行います。これは普通のHTTPSと同じポートです。
• localhost.runやPinggyのSSHサービスは、既存のSSHクライアントを利用しており、新たなインストールや昇格は不要です。
• boreのサーバは、ドキュメント に従い、1024以上のポートのみ受け付けます。
• Tailscaleのtsnetは、自己完結型のノードをユーザースペース内で動かし、root権限不要です。

本当に権限昇格が必要となるのは、エッジ部分です。エージェントをシステムサービスとしてインストールしたり（例：Packetriotのdaemonドキュメント）、公開アプリケーションを特権ポートにバインドしたりする場合です。

rootlessエージェントの利点。 もし公開されたアプリが侵害された場合、攻撃者は標準ユーザーの権限を継承します。管理者権限のエージェントを動かす必要はほとんどありません。ポリシーとして禁止すれば、開発者の負担は少なくて済みます。

ただし、これだけでは十分ではありません。 トンネルの承認や通信先、トラフィックの流れはわかりません。rootlessの特徴（インストール不要、管理者権限不要、アウトバウンドのみ）は、攻撃者にとっても魅力的です。「管理者権限なしで動かす」ことは必要条件ですが、十分条件ではありません。実際のコンプライアンスには、承認済みのプロバイダー、認証されたアクセス、中央管理のインベントリ、出口監視が必要です。

2026年のrootlessオプション

SSHベースのサービス

SSHリモートフォワーディングは、最も古典的なリバーストンネルです。リモートのSSHサーバにポートをリッスンさせ、そのセッションを通じてローカルポートにトラフィックを送ります。標準のSSHクライアントを使うため、追加のバイナリや昇格は不要です。

• localhost.runは最速のスタートを提供します。コマンド一つで、インストールや登録不要です：

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

無料ドメインは常に無料ですが、無料プランは速度制限とローテーションがあり、Webhookの安定したURLには向きません。安定したlhr.rocksや独自ドメインは$9/月（年払い）です。

• PinggyもSSHのみの選択肢で、バイナリ不要です：

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

Pinggyのヘルプページによると、無料プランは60分のトンネルタイムアウトがあり、新しいトンネルごとにURLが変わります。永続的なURLや独自ドメインは有料プラン（例：月$2.50からの有料プラン）で利用可能です。TCP/TLSトンネルも無料です。重要な点：Pinggyはトラフィックを読み取るためのWeb Debugger機能も持っています。

• セキュリティチームへの注意喚起。 これらのサービスはポート443や22を使います。特にPinggyは443を明示しています。これによりファイアウォールに優しいですが、ポートベースの出口ルールだけでは区別できません。ドメインやSNIレベルの制御が現実的です。

自ホスティング＆オープンソースツール

外部にトラフィックを送らず、自ホスティングを選ぶと、データパスからリレーを排除できます。

• frp (Fast Reverse Proxy)は最も有名な自ホスティングツールです。TCP、UDP、HTTP、HTTPSのフォワーディングに対応し、P2Pモードもサポート。クライアントとサーバはTCP、QUIC、KCP、WebSocket上で通信可能です。最近のリリースではOIDCクライアントやPrometheusの詳細メトリクスも追加されています。サポートポリシーはv0.69.0以降は、9つの新しいマイナーリリースまでサポートされるため、定期的なアップデートが必要です。

• boreはシンプルな選択肢です。READMEによると約400行の安全な非同期Rustコードで構成され、クライアントとサーバの両方に単一バイナリとして配布されます。TCPのみ対応し、共有シークレットとHMACチャレンジレスポンスによる認証も可能です：

bore server --secret my_secret_string
bore local 8000 --to your-bore-host.example.com --secret my_secret_string

bore.pubの公開インスタンスはデモには便利ですが、コンプライアンス重視の場合は自ホスティングを推奨します。TLSは自己管理してください。

• zrokはOpenZitiのオーバーレイネットワーク上に構築され、NetFoundryによって開発されたオープンソースの自己ホスティングツールです。無料のホステッドインスタンスもzrok.ioで提供。公開シェア（HTTPS URL）とプライベートシェア（トークンベースの非公開接続）をサポートします。ホステッドインスタンスではトラフィック監視が可能なため、プライバシーのモデルは異なります。2026年3月にリリースされたバージョン2.0では、旧来の予約・解放ワークフローを名前空間と名前に置き換え、CLIもzrok2に改名されました。

マネージドエッジサービス

• Cloudflare Tunnel. 簡易テスト用にcloudflaredはアカウント不要で公開HTTPS URLを作成します：

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

ただし、詳細に注意してください。Cloudflareのドキュメントによると、これらのクイックトンネルはテスト専用で、同時200リクエスト制限やSSE非対応です。長期運用や共有には、アカウントが必要な名前付きトンネルを使うべきです。クイックトンネルは上述の悪用例と同じ機能であり、多くのセキュリティチームが監視対象としています。

• ngrok. ngrokは定番のリファレンスです。無料プランは最大3エンドポイントまで対応。従量課金プランは月$20の基本料金に、$20の利用分が含まれます。エンタープライズ向けには料金ページで、SAMLやOpenID Connect、SCIM、RBAC、監査ログ、自己ホスティングオプションが掲載されています。

• Microsoft Dev Tunnels. Microsoft向けの選択肢で、管理者コントロールが充実しています。デフォルトでは、トンネルのホスティングや接続には認証が必要です。匿名アクセスは明示的に有効化しなければなりません。管理者はグループポリシーを設定し、匿名アクセスを無効化したり、Dev Tunnels自体を無効化したり、Microsoft EntraテナントIDのホワイトリスト制限をかけたりできます。これらのポリシーはVisual StudioやVS Codeのポートフォワーディング、Remote - Tunnels拡張、devtunnel CLIに適用されます。Microsoftは*.devtunnels.msなどのドメインも公開しており、ネットワークレベルでのアクセス制御も可能です。

Packetriot Spokes：チーム向け管理サーバ

個人開発者はSSHトリックやシングルバイナリツールで十分ですが、チームや大規模展開には自管理のサーバが必要です。例としてSpokesがあります。Packetriotのサーバです。

Packetriotによると、SpokesはPacketriot.comのトンネルサーバのプライベートインスタンスで、大規模なチームやデバイス群向けにHTTP/SとTCPトンネルを管理・提供します。1インスタンスあたり数千のトンネルに対応し、標準のPacketriotクライアントと互換性があります。重要なポイント：

• アクセスモデル。 管理者はユーザとトークンを管理し、Packetriotのアカウントシステムに依存しません。Spokesは組み込みのSOCKSv5プロキシとアップストリーム監視を搭載しています（Spokesドキュメント参照）。また、OpenID Connectもサポート。
• エンドポイントポリシー。 ローカルポリシーにより、IT管理者はトンネルの宛先やポートを制限可能。クライアントCLIから管理し、サーバからのリモートルール上書きはできません。
• 展開方法。 Docker、Kubernetes、RPM/DEBパッケージに対応。デフォルトはSQLiteで、大規模展開向けにMariaDBやPostgresも選択可能です。
• ライセンス。 年間契約で最大トンネル数に応じて価格設定：$1,000（100トンネル）、$2,000（250トンネル）、$3,500（500トンネル）など。30日間の試用ライセンスもあります。
• 由来と歴史。 SpokesはPacketriotの旧サーバHubsから派生し、2023年にネットワーク移行済みです（移行記事）。

Packetriotはオンプレミスの選択肢を、HIPAAやGDPR、SOX、PCIといった規制準拠のための既存のコンプライアンスプロセスの再利用と位置付けています。これは妥当なアーキテクチャの主張ですが、ホスティング自体がコンプライアンスを保証するわけではありません。

一覧表

ツール	モデル	権限範囲	注意点
localhost.run	SSHでリレー公開	標準SSHクライアント	無料ドメインはローテーションと速度制限
Pinggy	SSHでリレー公開	標準SSHクライアント	無料トンネルは60分、トラフィックを読む
Cloudflare quick tunnel	ホスティング型、cloudflared	ユーザーレベルバイナリ	テスト専用、200リクエスト制限、SSE非対応
ngrok	ホスティング型（エンタープライズは自己ホスティングも）	outbound TLS 443	無料は3エンドポイントまで
Microsoft Dev Tunnels	ホスティング型、テナント管理	devtunnel CLIまたはIDE	管理者コントロールが最良、Microsoftエコシステム向け
frp	自ホスティング	クライアント＆サーババイナリ	パッチ適用は自己責任、頻繁なリリース
bore	自ホスティング	単一バイナリ	TCPのみ、TLSは自己管理
zrok	ホスティングまたは自ホスティング	ユーザーレベルクライアント	v2 CLIはzrok2にリネーム済、公開とプライベートでプライバシー異なる
Packetriot Spokes	自ホスティングまたはベンダー管理	標準クライアント	ライセンスはトンネル数、販売はベンダー経由

アプリケーションにトンネルを埋め込む

別のアプローチとして、トンネルのバイナリ数を減らすために、アプリケーションに直接トンネリングを組み込む方法があります。現在、いくつかの実例とドキュメント化された選択肢があります：

• ngrok Agent SDKs. Agent SDKsはGo、JavaScript、Python、Rust向けに公開されており、自前のコードからエンドポイントを作成可能です。受信接続はローカルのソケットを開いたかのように扱います。管理プロセスやソフトウェアバンドルを避けたい場合に推奨されます。Go SDKはバージョン2に到達しています。
• Tailscale tsnet. Go言語で、tsnetはTailscaleのノードを完全に埋め込み、root権限不要です。ListenFunnelを使えば、アプリを公開インターネットに公開可能（TCP 443, 8443, 10000対応）。HTTPS有効化が必要です。
• zrokとOpenZiti SDKs. zrokのドキュメントは、Go SDKを通じて共有をアプリに直接組み込む方法を解説しています。これにより、アプリがoverlayにサービスをバインド可能です。

命名について：ツールの一覧で「TunnelAPI 2.0」と記載されることがありますが、これは一つのベンダーのホスティングトンネルとAPIゲートウェイ製品であり、業界標準ではありません。埋め込み用の標準規格ではないため、コンプライアンスの基準として扱わないでください。

セキュリティの正直な見解。 埋め込みは別途インストールされたバイナリを排除し、トンネルのライフサイクルをアプリに紐付けます。これにより、インベントリ管理やクリーンアップが容易になります。ただし、検知の場所も変わります。アプリ内で作成されたトンネルは、「ngrok」や「cloudflared」として認識されません。プロセス名ルールは効きません。ネットワーク層（DNS、プロキシログ、宛先許可リスト）が信頼できる制御手段です。認証（Mutual TLSなど）の適用は、選択した製品と設定次第です。

コンプライアンス対応のトンネルプログラム構築

アドホックなトンネルから管理されたモデルへの移行は、段階的に進めるのが効果的です。開発者は何もない状態を回避できません。

1. 既存の状況を把握。 EDR、DNS、プロキシのテレメトリを使い、トンネルエージェントとドメインを洗い出します。よく知られた宛先（*.trycloudflare.com、ngrokドメイン、*.devtunnels.ms）や既存の検知ルールを確認し、権限昇格しているものはフラグ付けします。
2. 適切な利用規範を策定。 権限昇格不要、認証必須、匿名・永続的な公開トンネルは禁止します。トンネルURLだけではアクセス制御にならないことを理解し、エッジで認証を追加します。
3. 認められた代替手段を提供。 ツールとニーズに合わせて選択。Microsoft環境ではDev Tunnelsとグループポリシーで制限。チームはPacketriot Spokesやfrp、zrokの自己ホスティング、またはエンタープライズプランを選択。WebhookテストにはSSHベースのサービスの許可・不許可を決めます。
4. ネットワーク層での制御。 これらのサービスは共通ポートを意図的に使うため、ドメインやSNIに基づく出口制御とアラートを設定します。承認済みの宛先だけ許可リストに登録します。
5. アイデンティティと連携。 承認されたインフラとアイデンティティプロバイダを連携させ、誰がトンネルを作ったか追跡できるようにします。SpokesのトークンやDev TunnelsのEntra制限、ngrokのエンタープライズSSOなどが該当します。
6. 内部ツールの標準化。 プラットフォームチームがトンネルをスキャフォールディングやCLIに組み込む場合、承認済みSDK（ngrok SDK、tsnet、zrok/OpenZiti SDK）を利用し、最も簡単な経路を確保します。

まとめ

「ノー・ルート」は、すべてのトンネルクライアントのデフォルトとして適切であり、開発者の負担もほとんどありません。ただし、「ノー・ルート」が会話の出発点であり終点ではありません。低摩擦の特性は、攻撃者にとっても魅力的です。成熟したプログラムは、最小権限の実行と承認済みプロバイダー、認証アクセス、中央管理のインベントリ、出口監視を組み合わせる必要があります。誰がいつどこにトンネルを開いたのか証明できるツールを選びましょう。それが監査に求められることです。

---

ファクトチェック・チェンジログ（公開前に削除）

2026年9月29日時点のベンダードキュメントや一次資料に基づき、最も重要な変更点は以下の通りです：

1. 「TunnelAPI 2.0」の標準化は削除・置換。 もともと記載されていた「TunnelAPI 2.0」規格は存在しません。これは一つのベンダーのホスティングトンネルとAI/APIゲートウェイの製品名です。埋め込みライブラリやmTLS、「ポートをリッスンしない」主張も根拠なしでした。実在する埋め込み例（ngrok Agent SDKs、Tailscale tsnet、zrok/OpenZiti SDKs）に書き換え、名称もTunnelAPIの説明を一行追加しています。

2. EDRの記述を逆に修正。 以前の記述では、CrowdStrikeやSentinelOne、DefenderなどのEDRプラットフォームが「トンネルエージェントを殺す」としていましたが、根拠がなく、証拠は逆を示しています。MITRE、Proofpoint、Securonix、Cofense、SpearTip、GuidePointは、ユーザーレベルのトンネル（トークンやSSHだけで動作）を攻撃者が利用していると示しています。記事は、「rootlessは必要だが十分ではない」とし、Elasticの検知ルール例を引用しています。

3. root権限必要なツールの記述を削除。 「1024未満のポートにバインド」「HTTPSの中間証明書をインストール」「サービス登録」などの記述は根拠がなく、逆に、逆トンネルクライアントはアウトバウンド接続であり、権限不要です。必要な場合のみ、システムサービスや特権ポートに関する記述に修正しました。

4. Packetriot Spokesの詳細。 展開方法（Docker、Kubernetes、RPM/DEB）、デフォルトのデータストア（SQLite）、HTTP/SとTCP対応、「数千のトンネル」対応、規制リストは公式ページに沿っています。市場シェアの断定や「監査ログ」の表現も緩和し、規制リスク低減はベンダーの主張と位置付けました。価格帯、30日試用、ローカルポリシー、トークン管理、SOCKS5プロキシ、OIDC対応、HubsからSpokesへの移行歴も追加。

5. bore。 「1,000行未満」から「約400行」に修正。TCPのみ、単一バイナリ、HMACシークレット、1024ポートのデフォルト最小値、公開サーバの注意点も追記。

6. zrok。 「デフォルトはプライベート共有」から、「公開とプライベートの選択制」に修正。プライベート共有の動作や、2026年3月のzrok2へのリネームも追加。

7. Cloudflare Tunnel。 クイックトンネルコマンドを確認。制限（テスト用、200リクエスト、SSE非対応）を追記。自己管理TLSは自己責任と明記。

8. Pinggy。 コマンドとTCP/TLS対応を確認。60分無料タイムアウトとトラフィック読み取りの情報を追加。料金もPinggyのブログから引用。

9. localhost.run。 コマンドと無料ドメインの制限、$9/月のカスタムドメインを追記。

10. frp。 プロトコルリストとトランスポートオプション、OIDCやメトリクスの改善、v0.69.0以降のサポート方針も記載。

11. セキュリティチームのブラックリスト化。 監視推奨（SpearTip）やMicrosoftの管理者コントロールを引用し、未検証の workstation隔離リスクは削除。

12. 新規セクション追加。 MITRE ATT&CKや悪用キャンペーンの背景、Microsoft Dev Tunnelsのグループポリシー、ngrokのプランとエンタープライズ詳細、比較表、「コンプライアンス対応プログラム構築」のステップも見直し。

意図的に省略・未確認の内容: - ngrokの無料プランの詳細（2時間セッション、ランダムURL）については、ngrok公式サイトと矛盾するため記載しません。必要ならngrokの最新の料金・制限ページを参照してください。 - sudoを必要とするcloudflared service installの詳細は未確認のため、一般的なシステムサービスインストールの記述にとどめています。 - PinggyのUDPサポートについては、第三者比較や過去記事で触れられていますが、公式ページで再確認していません。記載しません。