最近、SQL Server 2017 Expressとlocaldb(一般的な可用性)をインストールしました。 tSQLtフレームワークをインストールしようとしたときに、SQL Server 2017に実装された新しいセキュリティ機能である「clr strict security」オプションを発見しました。この新しいセキュリティ機能は、tSQLtCLRアセンブリの作成を妨げているようです。
SQLエラーメッセージは次のように述べています。
Sp_configureの 'clr strict security'オプションが1に設定されているため、SAFEまたはEXTERNAL_ACCESSオプションを使用してアセンブリ 'tSQLtCLR'のアセンブリを作成または変更できませんでした。対応するログインを持つ証明書または非対称キーでアセンブリに署名することをお勧めしますUNSAFEアセンブリ許可。または、sp_add_trusted_Assemblyを使用してアセンブリを信頼できます。
Sp_add_trusted_Assemblyプロシージャに関連するMicrosoftの技術ドキュメントを読みましたが、アセンブリを正常に作成できたと思われます。そもそもtSQLtCLRアセンブリを「信頼できる」としてリストするようにコーディングするには、それを最初から作成できないのでしょうか。
SQL Server 2017では、「CLR strict security」という名前の新しいサーバーレベルの構成オプションが導入され、デフォルトで有効になっています。このオプションでは、[〜#〜] all [〜#〜]アセンブリであっても、SAFE
のものであっても、証明書または厳密な名前の鍵で署名されていること、および証明書または非対称鍵であることが必要です。署名を行うために使用され、[master]
に読み込まれ、そこからログインが作成され、そのログインにUNSAFE Assembly
権限が付与されています。
SAFE
アセンブリに署名ベースのログインを設定する必要があるためbeforeがCREATE Assembly
を介して読み込まれるため、空の署名済みアセンブリを使用できなくなりました。 [master]
経由でCREATE Assembly ... FROM 0x... WITH PERMISSION_SET = SAFE;
に読み込まれます。
現在、SQLCLRセキュリティをVARBINARY
リテラルまたは変数から設定するために使用できるオブジェクトを作成する方法は2つしかありません(つまり、外部ファイルからnot)。
CREATE Assembly ... FROM 0x...;
CREATE CERTIFICATE ... FROM BINARY = 0x...;
オプション#1は、少なくともそれ自体では、もはやオプションではありません。オプション2は問題ありませんが、証明書がVisual Studio/MSBuildビルドプロセスに完全に統合されていないため、推奨されませんでした。
幸い、次の2つのブログ投稿で説明されているように、これを修正する方法は2つあります。
現在の状況に「なぜ」いるのかという質問に答えるだけです。その状況を修正するには、tSQLtビルドプロセスを更新して証明書を含めない可能性が高いと想定して、簡単な方法で一度限りの修正:
ALTER DATABASE [master] SET TRUSTWORTHY ON;
EXEC tSQLt.InstallExternalAccessKey;
EXEC master.sys.sp_executesql N'GRANT UNSAFE Assembly TO [tSQLtExternalAccessKey];';
ALTER DATABASE [master] SET TRUSTWORTHY OFF;
GRANT UNSAFE Assembly
が存在するのは、tSQLt.InstallExternalAccessKey
ストアドプロシージャがEXTERNAL ACCESS Assembly
をログインに許可するだけなので、以前は問題ありませんでしたが、今では十分ではありません。
もちろん、これらの4つのステップが完了するまでtSQLtアセンブリをロードすることはできません。そのため、プロセスが最初にすべてをロードし、それが失敗する場合は、以下を実行する必要があります。
EXEC sp_configure 'clr strict security', 0; RECONFIGURE;
-- Install tSQLt ...
EXEC tSQLt.InstallExternalAccessKey;
EXEC master.sys.sp_executesql N'GRANT UNSAFE Assembly TO [tSQLtExternalAccessKey];';
EXEC sp_configure 'clr strict security', 1; RECONFIGURE;
理想的な修正をソースファイルに組み込むために必要な手順を使用して、tSQLt GitHubリポジトリに問題を作成しました: https://github.com/tSQLt-org/tSQLt/issues/25
これらの可能な解決策のいずれにも、新しい「信頼されたアセンブリ」機能の使用は含まれていません。その機能は、決して(絶対的な好奇心とテスト以外の目的で)誰によっても使用されるべきではありません。それを回避する理由は、以下で始まるいくつかのブログ投稿(現在は3つ以上)で詳しく説明されています。
TSQLtアセンブリは既に署名されています。ここでは、マスターでアセンブリを作成し、そこから証明書を作成して、アセンブリを再度ドロップし、その証明書を使用して必要な手順を実行します。
2017にtSQLtをインストールするために必要な手順を自動化する作業をしています。