CLR строга сигурност на SQL Server 2017

Как може един CLR монтаж, създаден с PERMISSION_SET =SAFE, да има достъп до външни системни ресурси, да извиква неуправляван код и да придобива привилегии на системния администратор?

Това се дължи на промените в сигурността, направени в .NET Framework, започвайки от версия 4.5 (вярвам).

Документацията на MSDN за Основи на сигурността на кодовия достъп гласи:

.NET Framework предоставя механизъм за налагане на различни нива на доверие върху различен код, изпълняван в едно и също приложение, наречена Code Access Security (CAS). Защитата на кодовия достъп в .NET Framework не трябва да се използва като механизъм за налагане на граници на сигурността въз основа на произхода на кода или други аспекти на идентичността. Актуализираме нашите насоки, за да отразим, че сигурността за достъп до код и прозрачният код за сигурност няма да се поддържат като граница на сигурността с частично доверен код, особено код с неизвестен произход. Съветваме ви да не зареждате и изпълнявате код с неизвестен произход, без да въвеждате алтернативни мерки за сигурност.

И след това сочи към страницата за промени в сигурността в .NET Framework, която гласи:

Най-важната промяна в сигурността в .NET Framework 4.5 е силното именуване.

Което след това сочи към документацията за Enhanced Strong Naming, която гласи:

Силните ключове за имена се състоят от ключ за подпис и ключ за самоличност. Монтажът е подписан с ключа за подпис и се идентифицира с ключа за самоличност. Преди .NET Framework 4.5 тези два ключа бяха идентични. Започвайки с .NET Framework 4.5, ключът за самоличност остава същият като в по-ранните версии на .NET Framework, но ключът за подпис е подобрен с по-силен хеш алгоритъм. В допълнение, ключът за подпис е подписан с ключа за самоличност, за да се създаде контра-подпис.

СЪЩО, документацията за Указанията за безопасно кодиране гласи:

Сигурност за достъп до код и Прозрачен код за сигурност няма да се поддържат като граница на сигурността с частично доверен код. Съветваме ви да не зареждате и изпълнявате код с неизвестен произход, без да въвеждате алтернативни мерки за сигурност...

И така, моделът за сигурност за .NET се промени преди години, но на SQL Server (до SQL Server 2017) беше разрешено да продължи да използва стария модел на сигурност. Изглежда, че започвайки със SQL Server 2017, беше взето решение да не се поддържа старият модел на сигурност.

Подозирам, че разрешаването на стария модел за сигурност беше:

предотвратяване на SQL Server (поне свързаната с CLR функционалност/компоненти) да се базира на по-новите версии на .NET Framework и
отговорен за рязкото премахване на SQLCLR като поддържана функция от Azure SQL база данни (поддръжката беше добавена в края на 2014 г. с пускането на v12, но след това премахната изцяло към 15 април 2016 г.).

Така че, да, това е гадно. Това, което означава (поне за момента) е, че човек трябва да първи създайте сертификат или асиметричен ключ (който е бил използван за подписване на асемблите, които трябва да бъдат заредени) в [master] за да създадете вход от и след това да предоставите UNSAFE ASSEMBLY към това Вход. Това е същата последователност от събития, която човек трябва да направи при зареждане на EXTERNAL_ACCESS и UNSAFE Сглобки, но сега, за съжаление, трябва да се направи дори за SAFE Асамблеи.

Понастоящем няма механизъм за справяне с това по напълно преносим начин (т.е. да не се разчита на външни файлове) и не може да се обработва от Visual Studio / SSDT без ръчна намеса. Това вече беше така, но поне беше възможно да се създаде настройка, която да обработва това по напълно преносим начин (т.е. изцяло съдържаща се в .sql скрипт):моля, вижте Stairway to SQLCLR Ниво 7:Разработка и сигурност за подробности (това е статия, която написах).

Възможно е да се създаде сертификат от шестнадесетични байтове (т.е. FROM BINARY = 0x... ), но това не работи с Visual Studio (което разчита на MSBuild) / SSDT, тъй като използването на сертификата изисква използване на signtool и MSBuild използва sn .

За да може това да стане работещо, така че процесът на публикуване на Visual Studio / MSBuild / SSDT да работи (което от своя страна би означавало, че всеки ще може да създаде напълно самостоятелен .sql скрипт, способен да създаде асиметричния ключ, без да разчита на външен файл), CREATE ASYMMETRIC KEY командата трябва да бъде подобрена, за да позволи създаването от двоичен низ. Направих това предложение в Microsoft Connect – Разрешете създаването на асиметричен ключ от низ с двоичен шестнадесетичен байт, точно като CREATE CERTIFICATE – така че, моля, подкрепете го :-).

Като алтернатива (за момента, докато MS се надяваме да създаде по-добър метод, като моите предложения за асиметрични ключове), можете да опитате някоя от двете техники, които описвам в следните публикации в блога (и двете работят напълно с SSDT):

SQLCLR срещу SQL Server 2017, част 2:„Строгота CLR сигурност“ – Решение 1
SQLCLR срещу SQL Server 2017, част 3:„Строгота CLR сигурност“ – Решение 2

Като последен курорт, можете да разгледате следния подход:

ВРЕМЕННО задайте [master] База данни за TRUSTWORTHY ON

За следващата стъпка (т.е. CREATE ASSEMBLY ), за да се изпълни успешно, входът, който е собственикът на базата данни (т.е. същият SID, използван от [dbo] Потребител на [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:„Надеждени асемли“ – Разочарованието.