ドメイン信頼なしで Excel から取引先の SQL Server へ

他の組織の SQL Server 上でテーブルを開く Excel ブックには、ふつう一つとして語られる三つのものが必要です。サーバーが受け入れる ID、クライアントが検証する転送、双方が許可するネットワーク経路です。ドメイン信頼は最初のものを満たす一つの方法で、最も広いものです。TLS は二つ目を満たし、一つ目については何も言いません。経路は三つ目を満たし、それ自体では何も守りません。

三つを切り分ければ、表計算は管理上の関係ではなく、小さく確認できる依頼になります。

問いが隠している三つの決定

ID とは、データベースがあなたを誰とみなすかです。信頼されたドメインの Windows アカウント、独自のパスワードを持つ SQL ログイン、証明書ベースの ID のいずれかです。転送とは、セッションが暗号化されているか、クライアントがサーバーの証明書チェーンを確認するかです。経路とは、パケットがリスナーにどう届くかで、VPN、プライベートリンク、ファイアウォール規則付きの公開エンドポイントなどがあります。それぞれ別の場所にあり、それぞれ単独で失敗し得ます。

フォレスト信頼は最初のものに広く答えるもので、一つのブックの設定ではなく組織間の関係です。また何も暗号化しないので、信頼がセキュリティ管理だと想定していた人は驚きます。

フォレスト信頼なしの ID

対象環境で意図的に用意したアカウントは、クライアントの作業手順がそれを使えるなら、信頼なしでもより狭い要件を満たせます。ポリシーが許す場合のもう一つの定番が SQL 認証です。ログインは独自の資格情報のライフサイクルを持ち、ドメインに参加せず、Windows 統合認証も生成しません。証明書やトークンに基づく ID は、新しい基盤での第三の選択肢です。どれを選ぶにせよ、ブックが実際に必要とするデータベース権限だけを付与してください。

誰かの個人ログインより専用アカウントを選んでください。表計算の中で共有された資格情報は、いずれ起きるサポート問題です。名前付きアカウントなら、プロジェクト終了時に取り消せます。

暗号化はするが、証明書は信頼するのか

ODBC Driver 18 では、Encrypt=Yes;TrustServerCertificate=No は証明書が実際に確認される暗号化セッションを要求します。その場合、接続文字列は証明書が対象とするサーバーを指定する必要があり、クライアントはそのチェーンを信頼しなければなりません。Driver 18 は以前のバージョンと違い既定で暗号化するため、古い接続文字列がそれを告げずに TLS を交渉することがあります。明示的な設定は意図したポリシーをすべてのマシンで見えるようにし、複数の人が同じブックを保守するときに重要です。

TrustServerCertificate=Yes は暗号化しつつ検証を飛ばしますが、これは名前の不一致や信頼されないチェーンに対する等価な修復ではありません。クライアントが誤ったエンドポイントに達したことを伝えるはずの信号を消してしまうので、代わりに証明書か名前を直してください。

サーバー側の強制は別の管理です。暗号化をすべてのクライアントに適用すべきなら、サーバーの強制暗号化設定を構成して確認してください。協力的な接続文字列が一つあっても何も強制できません。

ネットワーク経路は保護ではない

VPN 経由で到達するプライベートリスナーは露出を減らしますが、それが機能するには VPN が正しい宛先と戻りの経路を運ぶ必要があります。動くトンネルは認証の必要性や証明書の検証をなくしませんし、TLS はどの遠隔システムが接続を試せるかを制限しません。これは三つの別個の観察です。TLS ハンドシェイク、VPN ログイン、承認されたクエリ。三つ目だけが、ブックが読むことを許されたデータを読んだことを証明します。

ですから、信頼の問いにデータベースをインターネットへ公開して答える近道は避けてください。狭い答えは通常、専用アカウント、検証済みの暗号化、承認された一つの経路であり、この順序です。

通常の Excel の作業手順で確認してください。受け入れられた ID、有効な権限、交渉された暗号化を、それぞれサーバー自身のセッションビューで確かめます。