SQL 2017 wprowadził pewną zmianę w zakresie CLR.
Otóż od tej pory bardzo wiele zależy od opcji 'clr strict security’ (konfigurowana przez sp_configure).
Jeżeli jej wartość to „0” (NIEZALECANE), to wszystko działa po staremu, tzn.:
- każdy assembly posiada swój permission set, który może być równy:
- SAFE – nie wychodzimy poza „proces” – jakieś dane dostaliśmy na wejściu i je przetwarzamy
- EXTERNAL ACCESS – możliwe jest korzystanie z zasobów zewnętrznych, jak np. sieć lub system plików
- UNSAFE – można wywołać kod niezarządzany
- żeby zaimportować moduł SAFE właściwie nie trzeba wykonywać żadnej specjalnej konfiguracji,
- ale dla EXTERNAL ACCESS lub UNSAFE należy:
- podpisywać assembly certyfikatem lub kluczem asymetrycznym (ZALECANE)
- lub ustawiać parametr TRUSTWORTHY dla bazy na ON a właścicielem bazy powinien być login z uprawnieniem UNSAFE ASSEMBLY (NIEZALECANE)
Jeżeli wartość parametru to 1 (ZALECANE), to permission set nadal należy określać, ale… nie służy on już do niczego. Każdy assembly będzie traktowany i tak jako UNSAFE, a do uruchomienia kodu musisz podpisać kod (ZALECANE) lub zmienić TRUSTWORTHY na ON (NIEZALECANE).
Ponieważ TRUSTWORTHY ustawione na on może naruszać bezpieczeństwo systemu, oczywiście zaleca się stosowanie podpisywania kodu.
Komentarze:
[…] W tym artykule pokażę jak od A do Z zaimplementować w .NET dwie metody służące do listowania plików i katalogów i zaimportować te funkcje do SQL 2017 z uwzględnieniem aktualnych best practice (z opcją ‚clr strict security’). Czym jest ta opcja i jakie ma działanie zobacz w https://www.mobilo24.eu/sql-clr-w-wersji-2017opcja-clr-strict-security/ […]