最近、MicrosoftはSQL Server用の2つの新しいドライバー、メジャーアップグレードをリリースしました：
SQLServer用のODBC18ドライバー
SQLServer用のOLEDB19ドライバー
それは良い知らせだ！ただし、注意が必要な大きな重大な変更があります。具体的には、暗号化のデフォルト設定の動作方法を変更しました。以前のすべてのバージョンのドライバーでは、デフォルトでは暗号化は必要ありませんでした。サーバー側から暗号化を強制するか、クライアント側の接続文字列内で暗号化を要求するかを選択できました。明らかに、サーバー管理者にとっては、通常、サーバーから暗号化を強制する方が望ましいので、古いアプリケーションがそれを要求しなくても問題はありませんが、サーバーとの通信を暗号化することが保証されます。
2つの接続文字列キーワードと、ドライバーの動作に影響を与えるサーバー設定があります。
クライアント側からの接続文字列内：
暗号化：通信を暗号化する必要があるかどうかを示します。-
TrustServerCertificate：クライアントが証明書の信頼性を確認せずにサーバーの証明書を信頼する必要があるかどうかを示します。
サーバー側からの設定内：
強制暗号化：クライアントの接続文字列に関係なく、サーバーに接続するすべてのクライアントが通信を暗号化することを義務付けます。
3つのプロパティの組み合わせは、接続方法に影響を与えます。それらを列挙した便利なチャートがあり、ここにあります。
ただし、最も一般的なシナリオは、サーバーからの暗号化を強制し、接続文字列に他に何も指定しないことです。以前のバージョンと新しいバージョンの動作の両方から抽出されたバージョンは次のとおりです。
バージョン | 暗号化 | 結果 |
|---|---|---|
| ODBC17以前 OLEDB18以前 | サーバー証明書はチェックされません。 クライアントとサーバー間で送信されるデータは暗号化されています。 | |
| ODBC 18 OLEDB 19 | サーバー証明書がチェックされます。 クライアントとサーバー間で送信されるデータは暗号化されています。 |
これは、特にAzure SQLデータベースが一般的になるにつれて、一般的には良いことだと思いますが、SQL Server証明書のチェックを変更すると、特に証明書が設定されていないサーバーでは、変更が導入されます。デフォルトでは、自己署名証明書が使用されますが、これは信頼できる証明書ほど安全ではありません。インターネットを介して接続が確立されているサーバーの場合、特別な予防策を講じる価値があります。
以前のバージョンと現在のバージョンの間で変更されたSQLServerを使用したMicrosoftAccessのODBC接続文字列の比較は次のとおりです。
ODBC17とODBC18
17： <サーバー名> DRIVER =ODBC Driver 17 for SQL Server; SERVER = <データベース名> ; DATABASE = ; Encrypt =yes;
18： <サーバー名> DRIVER =ODBC Driver 18 for SQL Server; SERVER = <データベース名> ; DATABASE = ;
SQLServerを使用したMicrosoftAccessのOLEDB18とOLEDB19の接続文字列
18： MSOLEDBSQL Provider = ;データソース= ;初期カタログ= ; Encrypt =yes;
19： MSOLEDBSQL19 Provider = ;データソース= ;初期カタログ=
以前のバージョンでは、 Encrypt =yesを指定する必要があったことに注意してください ただし、これは現在のバージョンでは暗黙的です。
わかりました。オンプレミスサーバーを使用していますが、新しいドライバーでは機能しませんか？
設定が変更されたため、次のエラーが表示される場合があります：
シナリオと要件に応じて、考えられる解決策は次のとおりです。
- サーバーに信頼できる証明書をインストールして構成します。
- アプリケーションの接続文字列を変更して、
TrustServerCertificate =Yesを含めます 。 注意して使用 - アプリケーションの接続文字列を変更して、
Encrypt =Noを含めますForce Encryptionを無効にします サーバー上。 推奨されません - ドライバーを更新しないでください。
問題を解決する手順については、対応するセクションで詳しく説明しています。
解決策
サーバーに信頼できる証明書をインストールして構成する
有効なSSL証明書が設定され、アクティブに使用されているサーバーがあるからといって、SQLServerが同じ証明書を使用しているとは限らないことに注意することが非常に重要です。さらに、SQLServer構成マネージャーは証明書の処理に恐ろしいことがわかりました。使用する証明書がリストされていない場合があります：
短いバージョンでは、SQL Server Configuration Managerは、一覧表示する証明書を過度に制限しています。これは、特にこれがUIの問題であり、SQL Server自体による真の要件ではないため、非常にイライラする可能性があります。幸い、レジストリを直接編集することで、このばかげたUIの制限を回避できます。これはレジストリキーに対応します：
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server\<インスタンスの名前>\MSSQLServer \ SuperSocketNetLib
そのキー内には、値 Certificate があります 証明書の拇印が必要です。
使用するSSL証明書の拇印を手動で貼り付けることもできますが、サーバーアカウントに証明書へのアクセス許可があることを確認する必要があるため、スクリプトを使用してこれを行うことをお勧めします。このブログ記事を、PowerShellスクリプトを設定して証明書を選択し、SQLServerのレジストリキーに読み込んでサービスを再起動するためのガイドとして使用しました。 SSL証明書とワークフローを提供するユーザーによっては、これを他のスケジュールされたタスクに統合して、SSL証明書が更新されたときに、それに応じてレジストリキーとアクセス許可が更新されるようにすることができます。
すべてが正しく設定されていれば、サーバーはアプリケーションの接続文字列を変更せずに新しいドライバを使用できるはずです。追加の検証として、SQL Serverのエラーログを確認し、次のような行を探すことができます。
拇印が使用したい拇印と一致する場合は、拇印が正しくロードされていることがわかり、信頼の鎖が確立されます。
アプリケーションの接続文字列を変更して、 TrustServerCertificate =Yesを含めます
ただし、サーバーがインターネットに接続されておらず、SSL証明書を設定するのが面倒な場合は、 TrustServerCertificateをオンにしてもかまいません。 。これには、アプリケーションの接続文字列を変更する必要があります。これにより、アプリケーションはサーバーの証明書を確認せずにサーバーに接続できるようになります。アプリケーションがネットワークの外に出ないように自信を持って制御できる場合は、これで問題ありません。誰かがネットワーク内でサーバーの名前またはIPを偽装できる場合、クライアントアプリケーションは盲目的にそのコンピューターに接続することに注意してください。そのため、接続にインターネットが関与している場合、これをお勧めすることはできません。リスクを冒したくないのです。
アプリケーションの接続文字列を変更して、 Encrypt =Noを含めます Force Encryptionを無効にします サーバー上。
これは、巨大なネオンサイン「STEAL MY DATA！ HIJACK ME NOW！」そこにいるすべての悪い俳優に。これはerm、「オプション」です。このオプションについて私が言える唯一のことは、それが非常に悪いということです。とても悪いので、これを行う方法を忘れました。あなたは一人でいる、相棒。
ドライバーを更新しないでください。
以前と比較してわずかに優れた代替策は、ODBC17およびOLEDB18ドライバーを更新せずにそのまま使用することです。ただし、これはせいぜい一時的な対策です。この解決にはアプリケーションの変更は必要ありませんが、これは避けられない変更を遅らせるだけです。時間を利用して、最新バージョンに到達し、データを適切に保護するためのパスを探索できます。
お役に立てば幸いです。