Microsoftのセキュリティベストプラクティス。Data.SqlClient

ADO.NET のダウンロード

接続層、アイデンティティ層、クエリ層、デプロイメント層でデータベースアプリケーションを保護します。 認証が成功したからといって、接続がトランスポート層セキュリティ(TLS)を使ってサーバーを検証していることや、そのIDがアプリケーションに必要な権限のみを持っていることを証明するものではありません。

セキュリティ チェックリスト

Area Action
ネットワーク暗号化。 互換性のあるエンドポイントで Encrypt=true または Encrypt=Strict を使用し、リモートの本番環境接続には TrustServerCertificate=false を残してください。
認証。 ターゲットとホストがサポートしている場合は、Windows統合認証、管理型アイデンティティ、またはワークロードアイデンティティを優先してください。
承認。 必要なデータベース権限のみを付与してください。 スキーマ展開とアプリケーションリクエストには別々の識別子を使いましょう。
クエリの構築。 データ値をパラメータ化します。 アプリケーション制御の許可リストからパラメータにできない識別子を選択します。
接続設定。 SqlConnectionStringBuilderと信頼できるエンドポイントの設定を使いましょう。 ユーザー制御の接続文字列断片を連結しないでください。
秘密。 保護された秘密ストアやホストIDを使いましょう。 パスワード、秘密鍵、ベアラートークンは絶対にコミットしないでください。
プール。 特にトークンコールバックの際は、プールキーとアイデンティティの選択を一貫させてください。
エラーと診断。 安全なアプリケーションエラーを返し、認証情報やトークンなしで制限された診断情報を保持します。
メンテナンス。 アップデートはドライバーおよびアイデンティティライブラリ依存関係をサポートし、アップグレード後に接続および認証の動作を行います。

証明書エラーに応じて設定を変更する前に、 暗号化と証明書検証 を参照してください。 TrustServerCertificate=true 本人確認を除去します。証明書の展開を解決するものではありません。

一般的な脅威

信頼できない入力がデータベースのコマンドや接続設定にどのように届くか、どのアイデンティティが各操作を実行しているか、そしてどの診断情報がサービスを離れるかを確認しましょう。

SQL インジェクション

SQLインジェクションは、アプリケーションが信頼できない入力をデータではなく実行可能な Transact-SQL(T-SQL)として扱うときに発生します。 値にはコマンドパラメータを使用し、明示的な型と適切なサイズを付けます。 ビジネスルールの入力も検証してください。

ストアドプロシージャは、信頼できない入力を動的SQLに連結していても注入を防げません。 適切な場合は、sp_executesql を使用して動的なステートメントをパラメーター化してください。 テーブル名、列名、ソート方向を変えなければならない場合は、アプリケーション制御の許可リストから選択してください。通常の値パラメータではSQL識別子や構文の代わりにはなりません。

任意の生SQLを安全にするために、クォートエスケープや接続文字列ビルダー、オブジェクトリレーショナルマッパーだけに頼らないでください。 コマンド とパラメータ 、 そして安全な動的SQLを書くことを参照してください。

権限の昇格

アプリケーションリクエストは、最も権限の低いデータベースIDで実行します。 アプリケーションエラーを消すためにサーバー管理者やデータベース所有者に権限を与えないでください。

スキーマの移行認証はランタイム認証と別々に行う。 必要なテーブルやプロシージャに適したロールを通じてアクセス権を付与します。 証明書署名や慎重に範囲を定めたなりすましは、操作が発信者以外の許可を必要とする場合にのみ使用し、その境界は別途確認してください。

認証はアプリケーションの承認ではありません。 サービスが複数のユーザーに対して一つのデータベースIDとして接続されている場合、各ユーザーがアクセスできるレコードや操作を強制しなければなりません。

プロービングとインテリジェントな観測

生のデータベース例外情報、接続文字列、スタックトレースを信頼できないクライアントに返さないでください。 適切な場合はアプリケーションレベルのエラーと相関識別子を返します。

診断記録は制限付きログシステムに保管してください。 操作、SqlClientエラー番号、再試行、相関識別子などの情報を記録します。 クエリテキスト、パラメータ値、エンドポイント、個人データの例外テキストやトレーシング設定を収集またはエクスポートする前に確認してください。

エラーは明示的に処理しましょう。 失敗したクエリや認証試行を空のデータで成功応答に変換しないでください。 証明書の失敗、無効な認証情報、または許可の拒否は、無制限の再試行ではなく修正が必要です。

認証

アプリケーションホストに適したアイデンティティを使いましょう。 Windows 認証はSQLパスワードの保存を必要としません。 Azureホスト型ワークロードはサポートされている場合にマネージドIDを使用できます。フェデレーテッドホストはワークロードIDを使用できます。 インタラクティブ認証はユーザー向けであり、無人サービス向けではありません。

SqlConnectionStringBuilderを使って接続文字列の値を割り当てます。 値は適切に引用してエスケープしますが、送信先を認可することはありません。 サーバー、データベース、認証モード、TLSポリシーはアプリケーションまたは管理者の管理下に置いてください。

信頼できないリクエストに TrustServerCertificate、 Encrypt、 Authentication、あるいは任意のサーバーアドレスを選ばせないようにしましょう。 マルチテナントアプリケーションの場合、リクエストからの完全な接続文字列を受け入れるのではなく、認可されたテナント構成を解決してください。

SQL Server and Windows 認証 および Microsoft Entra 認証を参照してください。

パスワード

SQL認証やクライアントシークレット認証が必要な場合は、保護された設定やシークレットストアからシークレットを取得します。 読み取りアクセスを制限し、シークレットをローテーションし、デプロイ後に古い認証情報を削除してください。

環境変数はインジェクションシークレットを保持できますが、シークレットストアではなく、プロセス診断やデプロイツールによって公開されることがあります。 印刷したりクラッシュレポートに含めたりしないでください。 開発の秘密はソース管理から守りましょう。

デフォルト Persist Security Info=false残す。 この設定は、開かれた接続のconnection-stringプロパティによる露出を制限します。元の構成文字列を消去したり、ログにした秘密を保護したりはしません。

アクセストークンと接続プーリング

接続プールは認証済みの物理接続を再利用します。 各プールを意図されたセキュリティコンテキストに紐付けたままにしてください。

  • リテラル AccessToken がプール キーに含まれます。 SqlClient はそれを更新することも、そのプロパティから有効期限を推測することもできません。 トークンの寿命管理を行い、必要に応じて影響を受けたプールをクリアします。
  • AccessTokenCallback はプール キーに含まれます。 プールを共有するべき接続については、安定したデリゲートと認証インスタンスを再利用してください。
  • 同じコールバック入力に対して同じ同一性を返します。 プールの入力によってその ID が常に確実に分離される場合を除き、共有コールバック内で現在の Web ユーザーの ID を参照しないでください。
  • アクセストークン、クライアントシークレット、証明書秘密鍵、または認証情報を含む接続文字列を完全に記録してはいけません。

トークンコールバックのガイダンスを使って取得と更新を実装してください。 トークンコールバックはTLS証明書の検証をカスタマイズしません。

展開とサービス境界

サポートされているMicrosoftのリリースを使用してください。Data.SqlClientおよび認証ライブラリ。 ドライバー提供のMicrosoft Entraモードを使う際は、コアドライバーとAzure拡張機能のバージョンを揃えておきましょう。 接続文字列解析だけでなく、サーバーの証明書設定や実際の認証フローに対してアップグレードをテストします。

可能な限りデータベースは公開ネットワークから遠ざけ、アプリケーションに必要なエンドポイントへのアクセスを制限してください。 TLSは輸送中のトラフィックを保護します。データベース権限を強制したり、ディスク上のデータベースファイルを暗号化したりしません。

LocalDBはWindows開発ツールです。 ファイルを保護し、リモートTLSやMicrosoft Entraの挙動の証拠としてLocalDBのみの実行を使わないでください。

SQL Server機能を導入する前に、目的地の機能を確認してください。 Microsoft FabricのSQLデータベースはMicrosoft Entraの識別情報を必要とし、SQLログイン、アプリケーションロール、Always Encryptedテーブルをサポートしていません。 Fabric SQLデータベースの制限を参照してください。

このセクションでは

Write Secure dynamic SQL では、動的文のパラメータ化方法や実行権限のレビュー方法を説明しています。