VPN 経由の SQL：直接クライアントか社内ワークステーションか

チームはノート PC で SSMS を使いたがり、手早い解決策は SQL ポートを VPN プールに公開することです。より慎重な答えは、直接アクセスと社内ワークステーションで送信元アドレス、エンドポイントの信頼、そしてデータ経路が異なるため、クライアントプロセスをどこで動かすかを問います。どちらも自動的に安全ではなく、VPN のメンバーシップだけでは何も決まりません。許可ルールができる前に設計を比べてください。

二つの経路、二つの送信元アドレス

直接アクセスでは、ノート PC がクライアント設定を保持し、データベース接続を自分で開きます。リモートワークステーションでは、ノート PC がデスクトップセッションを開き、ワークステーションが自分のアドレスから SQL 接続を行います。そのためデータベースは、前者では VPN プールまたは変換されたゲートウェイを、後者ではワークステーションのアドレスを見ます。この違いが、どのファイアウォールルールとどの SQL 権限が実際に適用されるかを決めます。

ノート PC は依然としてリモートセッションを制御するので、ワークステーションはユーザー認証やセッションポリシーの代わりにはなりません。

データベースが実際に何を見ているかを確認する

送信元アドレスは図から推測するものではなく、測定するものです。稼働中の接続のサーバー側で読み取ります。

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

接続テストはリスナーがそのネットワークから TCP を受け入れることを示し、クエリはセッションがどのログインとデータベースに到達したかを示します。サーバーが記録したアドレスを見るには、現在のセッションについて sys.dm_exec_connections を照会すると、変換後のクライアントアドレスが返ります。その値がノート PC ではなくゲートウェイなら、ユーザーごとのホストルールはデータベースのマシンでは機能しません。観測した値は再接続やプールの変化で動くため、選んだ設計の横に書いてください。

リスナーだけを開き、余計なものは開かない

デプロイに必要なサービスだけを開きます。よく知られた 1433 は既定インスタンスのポートであり、普遍的な定数ではありません。

Get-NetTCPConnection -State Listen -LocalPort 1433

名前付きインスタンスは動的ポートで待ち受けることが多く、SQL Server Browser が UDP 1434 で検出に応答するため、この依存は別途正当化すべき露出です。インスタンスに固定ポートを割り当てれば Browser の必要がなくなり、ファイアウォールルールも安定します。テストを通すためにクライアントの暗号化と証明書の確認を無効にせず、そのまま残してください。そのうえで、VPN グループ全体をサーバーロールに追加するのではなく、ワークロードにデータベースロールを付与します。

許可された経路と拒否された経路を証明する

通常の承認済みユーザーとして新しいセッションを開き、サーバーの識別情報、データベース、必要な操作を確認します。次に、ポリシー外の送信元やアカウントが同じテストで失敗することを確認します。ワークステーション設計では、ノート PC がデータベースに直接到達して境界を迂回できないことを確認します。直接アクセスでは、再接続後も経路と送信元ルールが有効であることを確認します。

クライアントがどこで動いたか、データベースがどの送信元を見たか、どのルールがそれを許可したかを記録します。それが次のレビューで求められる証拠です。