TRUSTWORTHY właściwość bazy danych (gdy ustawiona na ON ) zasadniczo deklaruje SQL Server, że kod zawarty w tej bazie danych i wykonywany w kontekście personifikowanym powinien mieć możliwość wychodzenia poza tę bazę danych przy zachowaniu tego kontekstu bezpieczeństwa personifikowanego. Pozwala także na wszystko Zestawy SQLCLR w tej bazie danych mają być ustawione na EXTERNAL_ACCESS i UNSAFE , niezależnie od tego, czy kod dociera poza serwer (w znaczeniu zewnętrznym:dostęp do sieci, dostęp do systemu plików, dostęp do rejestru, dostęp do środowiska itp.).
Jest to dość ogólny sposób pozwalający na to, ponieważ obejmuje cały kod w bazie danych. Używanie certyfikatów i/lub kluczy asymetrycznych do podpisywania modułów — procesów i/lub zestawów — pozwala na bardziej szczegółową kontrolę nad tym, jaki kod ma jakie uprawnienia.
Ustawianie bazy danych na TRUSTWORTHY umożliwia również dowolnemu procesowi rozpoczynającemu się w tej Bazie Danych osiągnięcie poziomu Serwera i/lub w poprzek innych Baz Danych. Zwykle proces jest ograniczony/poddawany kwarantannie w Bazie Danych, w której się rozpoczął. Jeśli baza danych należy do loginu „sa”, każdy proces zainicjowany w tej bazie danych i działający jako „dbo” będzie miał faktycznie uprawnienia „sa” (Ups!).
Zamiast próbować opisywać tutaj ilość szczegółów wymaganych do pełnego przekazania szczegółów dotyczących podszywania się, rozszerzania tej podszywania się, podpisywania modułów itp., zalecam zapoznanie się z następującymi zasobami na ten temat:
- PROSZĘ, proszę , przestań używać podszywania się, SOLIDNEGO ZAUFANIA i wiązania własności między bazami danych
- Wytyczne dotyczące korzystania z ustawienia bazy danych TRUSTWORTHY w SQL Server
- Rozszerzanie personifikacji bazy danych za pomocą opcji WYKONAJ JAKO
Jest to bardzo pouczający dokument, który obejmuje większość aspektów tego tematu, do którego odwołuje się również połączona strona powyżej. - Schody do SQLCLR Poziom 4:Bezpieczeństwo (zestawy ZEWNĘTRZNE i NIEBEZPIECZNE)
To jest artykuł, który napisałem jako część serii na temat SQLCLR, który zawiera przykłady ilustrujące różnice między metodą TRUSTWORTHY a metodą logowania na podstawie zestawu podpisów; Wymagana jest bezpłatna rejestracja.
Powinieneś unikać ustawiania bazy danych na TRUSTWORTHY tak dużo jak to możliwe. Jeśli naprawdę musisz mieć wywołania wielowątkowe / asynchroniczne ORAZ jeśli masz kod źródłowy i kompilujesz zestaw, to nie mogę wymyślić powodu, aby użyć SET TRUSTWORTHY ON opcja. Zamiast tego powinieneś podpisać zestaw hasłem i użyj następujących poleceń, aby skonfigurować preferowaną metodę zezwalania na EXTERNAL_ACCESS i UNSAFE zespoły:
USE [master];
CREATE ASYMMETRIC KEY [ClrPermissionsKey]
AUTHORIZATION [dbo]
FROM EXECUTABLE FILE = 'C:\path\to\my\assembly.dll';
CREATE LOGIN [ClrPermissionsLogin]
FROM ASYMMETRIC KEY [ClrPermissionsKey];
GRANT UNSAFE ASSEMBLY TO [ClrPermissionsLogin];
Gdy już to zrobisz, możesz przejść do bazy danych, w której Twój zespół został załadowany i uruchomić:
ALTER ASSEMBLY [MyAssembly] WITH PERMISSION_SET = UNSAFE;
Lub możesz dołączyć WITH PERMISSION_SET = UNSAFE na końcu CREATE ASSEMBLY polecenie.
