CLR Strict Security w SQL Server 2017

W jaki sposób zestaw CLR utworzony z PERMISSION_SET =SAFE może mieć dostęp do zewnętrznych zasobów systemowych, wywoływać kod niezarządzany i uzyskiwać uprawnienia administratora systemu?

Wynika to ze zmian bezpieczeństwa wprowadzonych w .NET Framework, począwszy od wersji 4.5 (wierzę).

Dokumentacja MSDN dotycząca podstaw zabezpieczeń dostępu do kodu stwierdza:

.NET Framework udostępnia mechanizm wymuszania różnych poziomów zaufania w różnych kodach uruchomionych w tej samej aplikacji o nazwie Code Access Security (CAS). Zabezpieczenia dostępu do kodu w .NET Framework nie powinny być używane jako mechanizm wymuszania granic zabezpieczeń na podstawie pochodzenia kodu lub innych aspektów tożsamości. Aktualizujemy nasze wskazówki, aby odzwierciedlić, że zabezpieczenia dostępu do kodu i kod przezroczysty pod względem bezpieczeństwa nie będą obsługiwane jako granica bezpieczeństwa z częściowo zaufanym kodem, zwłaszcza kodem nieznanego pochodzenia. Odradzamy ładowanie i wykonywanie kodu nieznanego pochodzenia bez stosowania alternatywnych środków bezpieczeństwa.

A następnie wskazuje stronę ze zmianami zabezpieczeń w .NET Framework, która stwierdza:

Najważniejszą zmianą w bezpieczeństwie w .NET Framework 4.5 jest silne nazewnictwo.

Co następnie wskazuje na dokumentację Ulepszonego silnego nazewnictwa, która stwierdza:

Klucze silnej nazwy składają się z klucza podpisu i klucza tożsamości. Zespół jest podpisany kluczem podpisu i jest identyfikowany przez klucz tożsamości. Przed .NET Framework 4.5 te dwa klucze były identyczne. Począwszy od .NET Framework 4,5, klucz tożsamości pozostaje taki sam jak we wcześniejszych wersjach .NET Framework, ale klucz podpisu jest ulepszony za pomocą silniejszego algorytmu skrótu. Ponadto klucz podpisu jest podpisany kluczem tożsamości, aby utworzyć kontrasygnatę.

RÓWNIEŻ dokumentacja wytycznych dotyczących bezpiecznego kodowania stwierdza:

Bezpieczeństwo dostępu do kodu i kod przezroczysty pod względem bezpieczeństwa nie będą obsługiwane jako granica bezpieczeństwa z częściowo zaufanym kodem. Odradzamy ładowanie i wykonywanie kodu nieznanego pochodzenia bez stosowania alternatywnych środków bezpieczeństwa...

Tak więc model bezpieczeństwa dla platformy .NET zmienił się lata temu, ale SQL Server (do SQL Server 2017) mógł nadal korzystać ze starego modelu bezpieczeństwa. Wygląda na to, że począwszy od SQL Server 2017 podjęto decyzję o zaprzestaniu obsługi starego modelu bezpieczeństwa.

Podejrzewam, że zezwolenie na stary model zabezpieczeń było:

zapobieganie bazowaniu SQL Server (przynajmniej funkcji/składników związanych z CLR) na nowszych wersjach .NET Framework oraz
odpowiedzialny za nagłe usunięcie SQLCLR jako obsługiwanej funkcji z Azure SQL Database (obsługa została dodana pod koniec 2014 r. wraz z uruchomieniem wersji 12, ale następnie całkowicie usunięta 15 kwietnia 2016 r.).

Więc tak, to jest do bani. Oznacza to (przynajmniej na razie) to, że trzeba najpierw utwórz certyfikat lub klucz asymetryczny (który został użyty do podpisania dowolnych zestawów do załadowania) w [master] aby następnie utworzyć login z, a następnie przyznać UNSAFE ASSEMBLY do tego logowania. Jest to ta sama sekwencja zdarzeń, którą należy wykonać podczas ładowania EXTERNAL_ACCESS i UNSAFE Złożenia, ale teraz niestety trzeba to zrobić nawet dla SAFE Zespoły.

Obecnie nie ma mechanizmu do obsługi tego w sposób całkowicie przenośny (tj. Nie polegaj na plikach zewnętrznych) i nie może być obsługiwany przez Visual Studio / SSDT bez ręcznej interwencji. W pewnym sensie już tak było, ale przynajmniej udało się stworzyć zestaw do obsługi tego w sposób całkowicie przenośny (tj. całkowicie zawarty w skrypcie .sql):zobacz Stairway to SQLCLR Level 7:Development and Security, aby uzyskać szczegółowe informacje (to jest artykuł, który napisałem).

Możliwe jest utworzenie Certyfikatu z bajtów szesnastkowych (np. FROM BINARY = 0x... ), ale to nie działa z programem Visual Studio (który opiera się na MSBuild) / SSDT, ponieważ użycie certyfikatu wymaga użycia narzędzia signtool a MSBuild używa sn .

Aby było to wykonalne, tak aby proces publikowania Visual Studio / MSBuild / SSDT działał (co z kolei oznaczałoby, że każdy byłby w stanie utworzyć całkowicie samodzielny skrypt .sql zdolny do tworzenia klucza asymetrycznego bez polegania na pliku zewnętrznego), CREATE ASYMMETRIC KEY polecenie musi zostać ulepszone, aby umożliwić tworzenie z ciągu binarnego. Zrobiłem tę sugestię w Microsoft Connect – Zezwól na tworzenie klucza asymetrycznego z binarnego ciągu bajtów szesnastkowych, tak jak CREATE CERTIFICATE – więc proszę o wsparcie :-).

Alternatywnie (w tej chwili, dopóki MS, miejmy nadzieję, nie stworzy lepszej metody, takiej jak moje sugestie dotyczące klucza asymetrycznego), możesz wypróbować jedną z dwóch technik, które opisuję w następujących wpisach na blogu (obie działają w pełni z SSDT):

SQLCLR kontra SQL Server 2017, część 2:„Ścisłe zabezpieczenia CLR” — rozwiązanie 1
SQLCLR kontra SQL Server 2017, część 3:„Ścisłe zabezpieczenia CLR” — rozwiązanie 2

Jako ostatni ośrodek, możesz rozważyć następujące podejście:

CZASOWE ustaw [master] Baza danych do TRUSTWORTHY ON

W następnym kroku (tj. CREATE ASSEMBLY ), aby pomyślnie wykonać, Login będący właścicielem bazy danych (tj. ten sam identyfikator SID używany przez [dbo] Użytkownik [master] ) musi mieć UNSAFE ASSEMBLY pozwolenie. Jeśli [master] należy do sa lub jakikolwiek inny administrator, to ma wszystkie uprawnienia i ten wymóg został spełniony. Ale jeśli [master] jest własnością loginu o niskich uprawnieniach ("najlepsza praktyka"), musisz wykonać następującą instrukcję, aby CREATE ASSEMBLY do pracy, gdy TRUSTWORTHY jest ON :
```
EXEC (N'USE [master]; GRANT UNSAFE ASSEMBLY TO [{DB_Owner_Login}];');
```
Utwórz zespół w [master]
Utwórz klucz asymetryczny z zestawu
Upuść zespół
ustaw [master] Baza danych do TRUSTWORTHY OFF
Utwórz login z klucza asymetrycznego
Przyznaj UNSAFE ASSEMBLY do tego loginu (zastępuje to potrzebę ustawienia bazy danych, w której ładowany jest zestaw, na TRUSTWORTHY ON i dla jego właściciela Zaloguj się, aby mieć UNSAFE ASSEMBLY pozwolenie).

Pamiętaj, że nie dołącz nową funkcję „Zaufany zespół” jako opcję tutaj. Powodem, dla którego nie wspomniano o tym, jest to, że ma o wiele więcej wad niż korzyści, nie wspominając o tym, że jest całkowicie niepotrzebny, biorąc pod uwagę, że istniejąca funkcjonalność już obsługiwała sytuację, którą miały rozwiązać „Zaufane zespoły”. Aby uzyskać szczegółowe informacje na ten temat oraz demonstrację prawidłowego sposobu obsługi istniejących, niepodpisanych zestawów, zobacz:SQLCLR vs. SQL Server 2017, Część 4:„Zaufane zestawy” — Rozczarowanie.