web-dev-qa-db-ja.com

SQL Server 2017でtSQLtCLRアセンブリを作成できません

最近、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アセンブリを「信頼できる」としてリストするようにコーディングするには、それを最初から作成できないのでしょうか。

9
Brent

SQL Server 2017では、「CLR strict security」という名前の新しいサーバーレベルの構成オプションが導入され、デフォルトで有効になっています。このオプションでは、[〜#〜] all [〜#〜]アセンブリであっても、SAFEのものであっても、証明書または厳密な名前の鍵で署名されていること、および証明書または非対称鍵であることが必要です。署名を行うために使用され、[master]に読み込まれ、そこからログインが作成され、そのログインにUNSAFE Assembly権限が付与されています。

SAFEアセンブリに署名ベースのログインを設定する必要があるためbeforeCREATE Assemblyを介して読み込まれるため、空の署名済みアセンブリを使用できなくなりました。 [master]経由でCREATE Assembly ... FROM 0x... WITH PERMISSION_SET = SAFE;に読み込まれます。

現在、SQLCLRセキュリティをVARBINARYリテラルまたは変数から設定するために使用できるオブジェクトを作成する方法は2つしかありません(つまり、外部ファイルからnot)。

  1. CREATE Assembly ... FROM 0x...;
  2. CREATE CERTIFICATE ... FROM BINARY = 0x...;

オプション#1は、少なくともそれ自体では、もはやオプションではありません。オプション2は問題ありませんが、証明書がVisual Studio/MSBuildビルドプロセスに完全に統合されていないため、推奨されませんでした。

幸い、次の2つのブログ投稿で説明されているように、これを修正する方法は2つあります。

  1. SQLCLRとSQL Server 2017、パート2:「CLR厳格なセキュリティ」–ソリューション1 —パート3、ソリューション2(下記)よりも多くのステップですが、ほとんど必要がないため、既存のプロジェクトに適しています既存のソリューションまたは展開プロセスへの変更(実際、これは実際に私が SQL# プロジェクトのために行ったルートです)、インストールスクリプトの先頭に3つの簡単な手順を追加するだけでした。 )
  2. SQLCLRとSQL Server 2017、パート3:「CLR厳格なセキュリティ」–ソリューション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つ以上)で詳しく説明されています。

SQLCLRとSQL Server 2017、パート4:「信頼できるアセンブリ」–失望

15
Solomon Rutzky

TSQLtアセンブリは既に署名されています。ここでは、マスターでアセンブリを作成し、そこから証明書を作成して、アセンブリを再度ドロップし、その証明書を使用して必要な手順を実行します。

2017にtSQLtをインストールするために必要な手順を自動化する作業をしています。

2
Sebastian Meine