1433番ポートの転送を避けるべき理由
社内にSQL Serverがあります。そのネットワークの外にいる誰か——リモートのアナリスト、クラウドのレポートツール、チームが作りたいアプリ——がそれを読む必要があります。誰もが最初に提案する手っ取り早い方法は、ルーターでTCP 1433番をDBサーバーに転送し、ファイアウォールで許可することです。
動きますし、手軽です。ただ、ほとんどのセキュリティ担当者が「やめておくべき」と言う方法でもあります。
- ログイン画面が公開される。 インターネット上のあらゆるものがSQL Serverに到達し、認証を試せます。自動スキャナーは一日中、開いている1433番を探し、
saなどのアカウントにパスワードリストを試しています。 - データベースが境界線になる。 適用していないパッチも弱いSQLログインも、外部から到達可能になります。
- IP制限は役立つが、もろい。 1433番をベンダーのIPに限定すれば露出は減りますが、IPは変わり、誰かがリストを管理し続ける必要があります。
本当に必要なのは、受信ポートなしで外部からそのデータベースを読めるようにすることです。方法は4つあります。
選択肢1：VPN
VPNは外部の相手を社内ネットワークの「内側」に入れます。クライアントVPNは個人のPCを接続し、サイト間VPNは2つのネットワークを常時つなぎます。
人向け。 SQL Server Management Studioを使うリモートの経理担当者は、まさにVPNが想定するケースです。
SaaSツールには不向き。 多くのクラウドサービスは社内のVPNに参加できません。またVPNゲートウェイ自体が通常は受信ポートで待ち受けるため、公開されたDBを、（はるかに堅牢とはいえ）公開されたVPN端点に置き換えることになります。
選択肢2：踏み台サーバー経由のSSHトンネル
多くのクラウドツールが「SSHトンネル経由で接続」に対応しています。ツールがSSHで入れる小さなLinuxマシン（踏み台）を用意し、SQL Serverへの通信をそのセッション経由で流します。
対応ツールが多く、鍵認証のSSHはよく知られ検証された仕組みです。
注意点： 受信ポート（通常22番）をインターネットかベンダーのIPに開ける必要があり、そのマシンのパッチ適用と監視も必要です。公開アドレスのないオフィスには不向きです。踏み台サーバーは外部から到達できる必要があるためです。
選択肢3：外向きトンネル（Cloudflare Tunnel、ngrok、Tailscale）
外向きトンネルは向きを逆にします。社内の内側にある小さなプロセスが外へ接続し、通信はその外向き接続を通って戻ってきます。
- Cloudflare Tunnel は社内で
cloudflaredを動かし、Cloudflareへの外向き接続だけを張ります。誰が入れるかはアクセスポリシーで制御します。 - ngrok は外向き接続を開き、ローカルのサービスに転送する公開エンドポイントを発行します。テストには便利ですが、アクセス制御を付けなければそのエンドポイントはインターネットから到達できます。
- Tailscale は登録した端末同士でWireGuardのプライベートネットワークを作ります。ネットワークのメンバーだけがSQL Serverに届きます。
受信ルールも公開IPも不要。 どちらもないオフィスでも動作します。
ただし、DBではなくネットワークへのアクセスです。 トンネルに届いたものは、そのログインの権限でSQL Serverと話せます。ポリシー、ログイン、監視は引き続き自社の責任です。そして相手側のSaaSツールがトンネルを使えなければなりませんが、使えないものも多くあります。
選択肢4：外へ接続するベンダーのエージェント
この用途のために専用エージェントを提供する製品もあります。DBが見えるマシンにインストールすると、ベンダーのクラウドへ外向きに接続し、製品はその接続を通してクエリを送ります。
- Microsoftのオンプレミスデータゲートウェイ が最も有名です。Windowsで動作し、Azureへ外向きに接続して、Power BI、Power Apps、Power Automate、Logic Appsに対応します。チームがMicrosoft製品中心なら、まずこれが候補です。（詳しくはオンプレミスデータゲートウェイの代替ガイドで比較しています。）
- AgentUIコネクタ はAgentUIのアプリとダッシュボード向けに同じことを行い、意図的に範囲を絞っています。
すっきりしている理由： 受信ポートも公開アドレスも不要で、エージェントはそのベンダーの製品にしか使われないため、汎用のネットワーク経路を気にする必要がありません。
トレードオフ： それぞれ自社ベンダーの製品にしか使えず、ベンダーのエージェントを信頼することになります。インストール前に、できることとできないことを確認してください。
比較表
| 方法 | 受信ポートを開ける？ | 公開IPなしで動く？ | DBに届くのは | 向いている用途 |
|---|---|---|---|---|
| 1433番の転送 | はい（1433） | いいえ | ポートに届く誰でも | 長期利用には不向き |
| VPN | 通常はゲートウェイで | 構成による | VPN上の誰でも | ネットワーク全体へのアクセスが必要な人 |
| 踏み台経由のSSHトンネル | はい（踏み台の22） | いいえ | 踏み台の鍵を持つ人 | SSHトンネル対応のクラウドツール |
| 外向きトンネル（Cloudflare Tunnel、Tailscale） | いいえ | はい | ポリシーで許可された相手 | アクセスポリシーを管理できるチーム |
| ベンダーのエージェント（ゲートウェイ、AgentUIコネクタ） | いいえ | はい | そのベンダーの製品だけ | 1つのベンダーのツールでデータを使う |
目的がそのデータを使ったアプリやダッシュボードなら
本当に欲しいのが社内DBの上に作る業務ツール、レポート、ダッシュボードなら、トンネルよりコネクタの選び方が重要です。そのために作ったのがAgentUIのオンプレミスSQL Serverコネクタです。
- 外向きのみ。 ポート443のHTTPSで外へ接続。受信ルールもファイアウォール変更も公開アドレスも不要です。
- 読み取り専用。 実行できるのは
SELECTとWITHだけで、各クエリは実行後にロールバックされます。 - パスワードは動かない。 そのサーバーにだけ保存（Windowsでは暗号化）。AgentUIが持つのはコネクタキーのフィンガープリントだけです。
- 取り消し可能。 2クリックで取り消し、キーは25秒以内に無効になります。
- 制限。 対応はMicrosoft SQL Serverのみ。クエリは必要なときに実行され、1回あたり最大1,000行・30秒。DBのコピーや同期はしません。
Windows・macOS・Linuxにサービスとしてインストールできます。典型的なのはWindowsサーバーでのSAP Business Oneです。この観点でアプリ構築ツールを比較しているなら、RetoolがオンプレミスのSQL Serverにどう接続するかも解説しています。
どれを選ぶべきか
- 人が自宅からフルアクセスしたい： VPN。
- クラウドツールがSSHトンネルにしか対応していない： ベンダーのIPに限定した踏み台。保守すべきサーバーが1台増えると考えてください。
- アクセスポリシーを自社で管理でき、汎用の経路が欲しい： Cloudflare TunnelやTailscaleのような外向きトンネル。
- 1つの製品にだけデータを読ませたい： その製品の外向きエージェント。Power PlatformならMicrosoftのゲートウェイ、AgentUIのアプリならAgentUIコネクタ。
最後のケースに当てはまるなら、AgentUIコネクタでSQL Serverをつなぎましょう。読み取り専用で、2クリックで取り消せます。