Zagrożenia bezpieczeństwa lub wydajności związane z SQL CLR [zamknięte]

Czy są jakieś szczególne zagrożenia bezpieczeństwa lub wydajności podczas korzystania z CLR w SQL Server?

Pytanie, jak zauważył Remus, jest zbyt ogólne, aby uzyskać odpowiedź, ponieważ odpowiedź zależy od kontekstu, jaka funkcjonalność ma zostać użyta i jak zostanie wykorzystana.

W odniesieniu do „bezpieczeństwa”:

Jeśli pytasz o cokolwiek, co można zrobić w zestawie oznaczonym PERMISSION_SET = SAFE, oznacza to, że nie ma żadnych problemów, które kiedykolwiek mogłem znaleźć. A SQLCLR jest „bezpieczniejszy” niż używanie xp_cmdshelllub wspaniałe (to był sarkazm) sp_OA*procy (lub nawet Rozszerzone Procedury Przechowywane, ale mam nadzieję, że nikt już ich nie tworzy).

Jeśli chcesz dowiedzieć się, co oznacza „SAFE” w praktyce, zapoznaj się z tym artykułem: Schody do SQLCLR Poziom 3: Bezpieczeństwo (zespoły ogólne i SAFE) (wymagana bezpłatna rejestracja).

Jeśli pytasz o cokolwiek, co można zrobić w zestawie oznaczonym PERMISSION_SET = EXTERNAL_ACCESS, to z pewnością istnieje ryzyko, ponownie, w zależności od używanej funkcjonalności. Jeśli piszesz procedurę czytania katalogów i nazw plików (tj. Tylko do odczytu), to tylko kwestia tego, co powinno być widoczne, a czego nie. Jeśli piszesz kod, który pozwala na usunięcie pliku, ryzyko wzrasta. Ale to, co można zrobić z tymi zasobami zewnętrznymi, jest kontrolowane przez:

• niezależnie od tego, czy używasz Podszywania się:
  • brak personifikacji oznacza, że ​​dostęp do zasobów zewnętrznych odbywa się za pośrednictwem konta „Zaloguj się jako” usługi SQL Server. Bez względu na to, do czego konto ma dostęp, funkcja SQLCLR będzie w stanie to zrobić.
  • użycie Personifikacji oznacza, że ​​Logowanie w SQL Server, który uruchamia tę funkcję, jeśli to logowanie odpowiada loginowi Windows, może robić wszystko, co jest dozwolone. Jeśli login w SQL Server to login SQL Server, wówczas próba użycia personifikacji spowoduje błąd.
• Jakie uprawnienia są skonfigurowane dla zasobu zewnętrznego. W przypadku dostępu do systemu plików jest to kontrolowane przez listy ACL na dyskach NTFS.

Jeśli pytasz o cokolwiek, co można zrobić w zestawie oznaczonym PERMISSION_SET = UNSAFE, to jest dość otwarte. Wiele funkcji uważa się za użyteczne tylko w zespołach UNSAFE, ponieważ są to kwestie stabilności i / lub spójnego zachowania bardziej niż bezpieczeństwo lub wydajność. Na przykład w zespole UNSAFE można mieć zapisywalną zmienną statyczną. Zazwyczaj nie jest to dobre, ponieważ klasy SQLCLR są wspólne dla wszystkich sesji. Jeśli masz zamiar udostępniać dane w pamięci we wszystkich sesjach i zaplanowałeś warunki wyścigu (i wykonałeś wiele testów), powinieneś być w porządku, ponieważ spodziewasz się takiego zachowania. Ale jeśli po prostu chciałeś, aby zapisywalna zmienna statyczna buforowała wartość dla konkretnej sesji, aby nie musieć jej ponownie sprawdzać ani obliczać, i nie byłaś świadoma tego, że inne sesje odczytują tę wartość i prawdopodobnie ją nadpisują, cóż, to byłby problem.

Ale jeśli martwisz się o kogoś, kto pisze do Rejestru, ale nie masz żadnego kodu, który faktycznie zapisuje w Rejestrze, prawdopodobnie nie musisz się tym martwić ;-).

Jeśli chcesz zapoznać się z praktycznym działaniem EXTERNAL_ACCESS i UNSAFE oraz różnicą między ustawieniem TRUSTWORTHY ON(nie preferowanym) a użyciem Asymetrycznego logowania opartego na kluczu lub certyfikacie, zapoznaj się z tym artykułem: Schody do SQLCLR poziom 4: Bezpieczeństwo (zespoły ZEWNĘTRZNE i NIEBEZPIECZNE) (wymagana bezpłatna rejestracja).

W odniesieniu do „wydajności”:

To wszystko zależy od tego, co próbujesz zrobić i jak to zrobić. Istnieją pewne rzeczy, które są znacznie szybsze w SQLCLR, a niektóre rzeczy, które są wolniejsze. Ale podobnie jak w przypadku T-SQL, możliwe jest podjęcie nieco prostego i / lub wydajnego zadania oraz uczynienie go skomplikowanym i / lub nieefektywnym poprzez nieprawidłowe działanie. Ale korzystanie z SQL CLR nie jest z natury z natury wolniejsze.

Zespoły SQLCLR mogą być instalowane z trzema poziomami dostępu Bezpieczeństwo: SAFE | EXTERNAL_ACCESS | UNSAFE. Jest to obszernie udokumentowane, patrz CREATE ASSEMBLYi Projektowanie zespołów :

Zarządzanie bezpieczeństwem zespołu
Możesz kontrolować, ile zespołu może uzyskać dostęp do zasobów chronionych przez .NET Code Access Security, gdy uruchamia kod zarządzany. Można to zrobić, określając jeden z trzech zestawów uprawnień podczas tworzenia lub modyfikowania zestawu: SAFE, EXTERNAL_ACCESS lub UNSAFE.

SAFE
BEZPIECZNY jest domyślnym zestawem uprawnień i jest najbardziej restrykcyjny. Kod uruchamiany przez zestaw z uprawnieniami SAFE nie może uzyskać dostępu do zewnętrznych zasobów systemu, takich jak pliki, sieć, zmienne środowiskowe lub rejestr. Kod SAFE może uzyskiwać dostęp do danych z lokalnych baz danych SQL Server lub wykonywać obliczenia i logikę biznesową, które nie wymagają dostępu do zasobów poza lokalnymi bazami danych.
Większość zestawów wykonuje zadania obliczeniowe i zarządzania danymi bez konieczności uzyskiwania dostępu do zasobów poza SQL Server. Dlatego zalecamy BEZPIECZNY jako zestaw uprawnień do montażu.

EXTERNAL_ACCESS
EXTERNAL_ACCESS pozwala zespołom na dostęp do niektórych zewnętrznych zasobów systemowych, takich jak pliki, sieci, usługi sieciowe, zmienne środowiskowe i rejestr. Tylko loginy SQL Server z uprawnieniami DO ZEWNĘTRZNEGO DOSTĘPU mogą tworzyć zespoły EXTERNAL_ACCESS. Zespoły SAFE i EXTERNAL_ACCESS mogą zawierać tylko kod, który można zweryfikować pod względem typu. Oznacza to, że te zespoły mogą uzyskiwać dostęp do klas tylko poprzez dobrze zdefiniowane punkty wejścia, które są poprawne dla definicji typu. Dlatego nie mogą one arbitralnie uzyskiwać dostępu do buforów pamięci niebędących własnością kodu. Ponadto nie mogą wykonywać operacji, które mogą mieć negatywny wpływ na niezawodność procesu SQL Server.

UNSAFE
UNSAFE zapewnia zespołom nieograniczony dostęp do zasobów, zarówno w SQL Server, jak i poza nim. Kod uruchamiany z zestawu UNSAFE może wywoływać kod niezarządzany. Ponadto określenie UNSAFE pozwala kodowi w zestawie wykonywać operacje, które weryfikator CLR uważa za niebezpieczne. Te operacje mogą potencjalnie uzyskiwać dostęp do buforów pamięci w przestrzeni procesu SQL Server w niekontrolowany sposób. Zespoły UNSAFE mogą również potencjalnie obalić system bezpieczeństwa programu SQL Server lub środowiska uruchomieniowego wspólnego języka. Uprawnienia UNSAFE powinny być przyznawane tylko przez wysoce zaufane zespoły przez doświadczonych programistów lub administratorów. Tylko członkowie sysadmin o stałej roli serwera mogą tworzyć zespoły UNSAFE.

Istnieją dalsze ograniczenia dotyczące dozwolonych atrybutów CLR i obsługiwany jest tylko podzbiór .NET Framework Asemblies. Ponownie zapoznaj się z dołączoną dokumentacją.

Jeśli chodzi o wydajność, najważniejsze jest, aby pamiętać, że SQL Server to współpracujące środowisko wielozadaniowe, podczas gdy CLR nie. Kod SQLCLR musi wywoływać za Thread.BeginThreadAffinity()każdym razem, gdy zajmie CPU na dowolny czas (w tym blokowanie). Adam Machanic ma doskonałą prezentację na ten temat, obejrzyj dane, szybciej: Microsoft SQL Server Performance Techniques with SQLCLR .

Temat jest obszerny, a pytanie niejasne. SQLCLR może wykonywać niektóre unikalne zadania, których żadna inna funkcja nie może dopasować. A SQLCLR to kolejna broń w arsenale SQL Server, z którą możesz strzelać sobie w stopę, osiągami lub bezpieczeństwem. Przeczytaj dokumentację.