Microsoft.Data.SqlClient の接続文字列

Microsoftです。Data.SqlClient 接続文字列は、ドライバーにどのSQL Server互換エンドポイントやデータベースを使うか、認証方法、接続の設定方法を教えます。 SqlConnectionかSqlConnectionStringBuilderに渡してください。

まずは4つの決断から始めましょう。

1. アプリケーションはどのサーバーとデータベースを使っていますか?
2. アプリケーションはどのアイデンティティで動作しますか?
3. クライアントはどのようにしてサーバー証明書を検証するのでしょうか?
4. ワークロードに必要な接続動作は何でしょうか?

選択した認証方法がその設計をサポートしている場合、認証情報やアクセストークンは接続文字列から除外してください。

認証パターンを選択する

展開に合った最も狭いパターンを使いましょう。

Microsoft。Data.SqlClient 7.0以降のバージョンでは、ドライバーが提供するMicrosoft Entra ID認証モードのためにバージョンマッチドのMicrosoft.Data.SqlClient.Extensions.Azureパッケージが必要です。 アプリケーションコードがアクセストークンやアクセストークンコールバックを提供する場合は、その拡張機能は必要ありません。

認証にはデータベース側のユーザー、権限、ID設定も必要です。 選択行列とセットアップの詳細については、Microsoft Entra ID認証およびSQL Server認証を参照してください。

サーバーとデータベースを指定する

標準的なキーワード名として Server と Database を使いましょう。 ドライバーはServerにはData Source、DatabaseにはInitial Catalogなどの別名も受け入れています。

一般的なサーバー形式には以下があります:

Server=server-name
Server=server-name\instance-name
Server=tcp:server-name,1433
Server=(localdb)\MSSQLLocalDB

本番TCP接続では、明示的なプロトコル、ホスト名、ポートを好みます。 IPアドレスではなく、サーバー証明書と一致する安定したDNS名を使いましょう。

可用性グループリスナー、フェイルオーバーグループ、Azure SQLエンドポイント、またはその他のマルチアドレスTCPエンドポイントについては、接続オプションでMultiSubnetFailoverを確認してください。

暗号化と証明書検証の設定

Microsoft.Data.SqlClient 4.0 以降のバージョンでは、既定でtrueがEncryptになります。 Microsoft.Data.SqlClient 5.0 以降のバージョンでは、TDS 8.0 をネゴシエートするサーバーに対しても Encrypt=Strict をサポートしています。

以下を使用してください。

• Encrypt=Strict サーバーがTDS 8.0をサポートし、証明書を持っている場合、クライアントは検証可能です。
• Encrypt=true 他の対応サーバーとの暗号化接続のために。
• TrustServerCertificate=false、は本番証明書検証のデフォルトです。

TrustServerCertificate=trueを一般的な接続修正として使わないでください。 チャネルは暗号化されますが、サーバーのアイデンティティ検証はスキップされます。 信頼できる証明書が存在しない管理された開発環境に限定してください。

サーバーの要件、バージョンの挙動、証明書オプションについては「 暗号化および証明書検証」を参照してください。

接続文字列 構文を理解する

接続文字列とは、キーワードと値の組み合わせをセミコロンで区切ったリストです。

Server=tcp:sql.example.com,1433;Database=Orders;Integrated Security=true;Encrypt=true

次の規則に従います。

• キーワード名は大文字を区別しません。
• 値では、大文字と小文字が区別される場合があります。
• 最後のセミコロンは任意です。
• セミコロンや前後の空白を含む値に、シングルまたはダブルクォートマークで引用してください。
• 価値を2倍にすることで、その見積もりから逃れましょう。
• 重複キーワードは使わないでください。 パーサは最後の値を使うため、効果的な構成の確認が難しくなります。

受け入れられたキーワードとエイリアスの集合は提供者に属します。 Microsoft.Data.SqlClientが受け入れた接続文字列がSystem.Data.SqlClientや他のデータプロバイダーでは機能しない場合があります。

接続ストリングを安全に作る

コードが値を追加、検証、または置き換えする必要がある場合には SqlConnectionStringBuilder を使います。 信頼できない値を接続文字列に連結しないでください。

string baseConnectionString =
    configuration.GetConnectionString("Orders")
    ?? throw new InvalidOperationException(
        "Connection string 'Orders' wasn't configured.");

var builder = new SqlConnectionStringBuilder(baseConnectionString)
{
    ApplicationName = "Orders.Api",
    ConnectTimeout = 30,
};

string connectionString = builder.ConnectionString;

建築業者:

• サポートされていないキーワードや無効な値は却下します。
• エイリアスを標準的な性質にマッピングします。
• 必要に応じて見積もりを記載してください。
• 値が別のキーワードを注入するのを防ぎます。

ビルダーはプロセスメモリに入ったパスワードやトークンを保護しません。 また、サーバー、アイデンティティ、証明書の設定が安全かどうかも決定しません。

コード外での接続情報の保存

アプリケーションで使用される構成システムから接続文字列を読み込みます。 現在の.NETアプリケーションでは、環境変数、ローカル開発用のユーザーシークレット、Azure App Configuration、Azure Key Vaultによる構成が一般的に使用されています。

以下のルールを守ってください:

• パスワード、クライアントシークレット、アクセストークン、本番接続文字列はコミットしないでください。
• 接続文字列にパスワードを入力しないIDベースの認証方法を好みます。
• 設定ソースへのアクセスを制限してください。
• 保存されたシークレットをローテーションし、それらをキャッシュするアプリケーションを再起動または更新します。
• ログ、例外、トレース、テレメトリに接続文字列を書かないでください。
• デフォルトPersist Security Info=falseのままにしておき、開いた接続が接続文字列を通じてセキュリティに敏感な値を露出させないようにしましょう。

.NET 設定プロバイダーについては、「.NET 内の構成」を参照してください。 追加の管理については 、「接続情報の保護」をご覧ください。

プールの鍵を安定させておきましょう

接続プーリングでは、完全に一致する接続構成がプールキーの一部として使用されます。 同等の文字列は、テキストが異なる場合、例えばキーワードの順序が異なる場合など、別々のプールを作成することがあります。

アプリケーション起動時に1つの標準的な接続文字列を作成し、それを再利用します。 リクエストIDやユーザー名、アクセストークン、その他のリクエストごとの値を文字列に追加しないでください。 主要なルールの詳細については、SQL Server接続プーリングを参照してください。

接続設定とコマンド設定を別々に

接続文字列は接続の確立とセッションの動作を制御します。 コマンドは1つのSQL操作を制御します。

長いタイムアウトをリトライの論理と考えないでください。 タイムアウトは待機時間の制限です。 リトライでは再度試行を開始するため、回数や条件が適切に制限されており、安全に繰り返せる必要があります。

バージョン依存の挙動をレビュー

サポートされている安定版ドライバーを使用し、アップデート前にリリースノートを読みましょう。 現在のバージョンについては、 SqlClientドライバーのサポートライフサイクルを参照してください。

関連するコンテンツ

• .NET アプリで Microsoft.Data.SqlClient を使用する
• 接続オプション。
• データ ソースへの接続
• Microsoft Entra ID 認証
• 暗号化と証明書の検証
• Microsoft.Data.SqlClient API リファレンス