SQLServer2017でのCLRの厳格なセキュリティ

PERMISSION_SET =SAFEで作成されたCLRアセンブリは、どのようにして外部システムリソースにアクセスし、アンマネージコードを呼び出し、sysadmin特権を取得できるのでしょうか。

これは、バージョン4.5以降の.NET Frameworkで行われたセキュリティの変更によるものです（私は信じています）。

Code AccessSecurityBasicsのMSDNドキュメントには次のように記載されています。

.NET Frameworkは、Code Access Security（CAS）と呼ばれる同じアプリケーションで実行されているさまざまなコードにさまざまなレベルの信頼を適用するためのメカニズムを提供します。 .NET Frameworkのコードアクセスセキュリティは、コードの発信やその他のIDの側面に基づいてセキュリティ境界を適用するためのメカニズムとして使用しないでください。コードアクセスのセキュリティとセキュリティ透過コードは、部分的に信頼できるコード、特に出所不明のコードとのセキュリティ境界としてサポートされないことを反映するように、ガイダンスを更新しています。代替のセキュリティ対策を講じずに、出所不明のコードをロードして実行しないことをお勧めします。

次に、.NETFrameworkのセキュリティの変更に関するページをポイントします。

.NET Framework 4.5のセキュリティに対する最も重要な変更は、厳密な命名です。

次に、次のように記述された拡張ストロングネーミングのドキュメントを指します。

厳密な名前キーは、署名キーとIDキーで構成されます。アセンブリは署名キーで署名され、IDキーによって識別されます。 .NET Framework 4.5より前は、これら2つのキーは同一でした。 .NET Framework 4.5以降、IDキーは以前の.NET Frameworkバージョンと同じままですが、署名キーはより強力なハッシュアルゴリズムで拡張されています。さらに、署名キーはIDキーで署名され、カウンター署名が作成されます。

また、セキュアコーディングガイドラインのドキュメントには次のように記載されています。

コードアクセスのセキュリティとセキュリティ-透過的なコードは、部分的に信頼されたコードとのセキュリティ境界としてサポートされません。代替のセキュリティ対策を講じずに、出所不明のコードをロードして実行しないことをお勧めします...

そのため、.NETのセキュリティモデルは数年前に変更されましたが、SQL Server（SQL Server 2017まで）は古いセキュリティモデルの使用を継続することが許可されています。 SQL Server 2017以降、古いセキュリティモデルをサポートしないことが決定されたようです。

古いセキュリティモデルを許可することは次のとおりだったと思います：

SQL Server（少なくともCLR関連の機能/コンポーネント）が新しい.NETFrameworkバージョンに基づいていないこと。
Azure SQL Databaseからサポートされている機能としてSQLCLRを突然削除する責任があります（サポートはv12のリリースで2014年後半に追加されましたが、2016年4月15日から完全に削除されました）。

だから、はい、これはちょっとひどいです。それが意味することは（少なくとも今のところ）、最初にする必要があるということです [master]に証明書または非対称キー（ロードするアセンブリに署名するために使用されたもの）を作成します次に、からログインを作成し、UNSAFE ASSEMBLYを付与します。そのログインに。これは、EXTERNAL_ACCESSをロードするときに実行する必要がある一連のイベントと同じです。およびUNSAFE アセンブリですが、残念ながら、SAFEでも実行する必要があります。アセンブリ。

現在、これを完全に移植可能な方法で処理するメカニズムはなく（つまり、外部ファイルに依存しない）、手動の介入なしにVisual Studio/SSDTで処理することはできません。これはすでに事実でしたが、少なくともこれを完全に移植可能な方法で処理するためのセットアップを作成することは可能でした（つまり、完全に.sqlスクリプト内に含まれています）。詳細については、SQLCLRレベル7への階段：開発とセキュリティを参照してください。（これは私が書いた記事です。）

16進バイトから証明書を作成することができます（つまり、FROM BINARY = 0x... ）ただし、証明書を使用するにはsigntoolを使用する必要があるため、Visual Studio（MSBuildに依存）/SSDTでは機能しません。 MSBuildはsnを使用します。

Visual Studio / MSBuild / SSDT公開プロセスが機能するようにこれを実行可能にするために（つまり、誰もが依存せずに非対称キーを作成できる完全に自己完結型の.sqlスクリプトを作成できるようになります）外部ファイル）、CREATE ASYMMETRIC KEY バイナリ文字列から作成できるように、コマンドを拡張する必要があります。私はMicrosoftConnectでこの提案をしました– CREATE CERTIFICATEのようにバイナリの16進バイト文字列から非対称キーを作成できるようにします–それをサポートしてください:-)

または（現時点では、MSが非対称鍵の提案など、より良い方法を作成するまで）、次のブログ投稿で説明する2つの手法のいずれかを試すことができます（どちらもSSDTで完全に機能します）：

SQLCLRとSQLServer2017、パート2：「CLRの厳密なセキュリティ」–ソリューション1
SQLCLRとSQLServer2017、パート3：「CLRの厳密なセキュリティ」–ソリューション2

最後としてリゾートでは、次のアプローチを検討できます。

一時的に [master]を設定します TRUSTWORTHY ONへのデータベース

次のステップ（つまり、CREATE ASSEMBLY ）正常に実行するには、データベース所有者であるログイン（つまり、[dbo]で使用されるのと同じSID） [master]のユーザー）UNSAFE ASSEMBLYが必要です許可。 [master]の場合 saが所有していますまたは他のシステム管理者の場合、すべての権限があり、この要件が満たされています。ただし、[master] が低特権ログイン（「ベストプラクティス」）によって所有されている場合、CREATE ASSEMBLYを実行するには、次のステートメントを実行する必要があります。 TRUSTWORTHYのときに機能する ONです：
```
EXEC (N'USE [master]; GRANT UNSAFE ASSEMBLY TO [{DB_Owner_Login}];');
```
[master]でアセンブリを作成します
アセンブリから非対称鍵を作成する
アセンブリをドロップします
[master]を設定します TRUSTWORTHY OFFへのデータベース
非対称キーからログインを作成する
UNSAFE ASSEMBLYを付与するそのログインに（これにより、アセンブリがロードされるDBをTRUSTWORTHY ONに設定する必要がなくなります。 および 所有者がログインしてUNSAFE ASSEMBLYを取得する許可）。

私はしなかったことに注意してくださいここにオプションとして新しい「信頼できるアセンブリ」機能を含めます。言及されなかった理由は、既存の機能が「信頼できるアセンブリ」が対処することを意図した状況をすでに処理していることを考えると、そもそも完全に不要であることは言うまでもなく、利点よりも多くの欠陥があるためです。その詳細と、既存の署名されていないアセンブリを処理する適切な方法のデモについては、SQLCLRとSQL Server 2017、パート4：「信頼できるアセンブリ」–失望を参照してください。