• Artykuł

Rozszerzanie bazy danych personifikacji przy użyciu jako EXECUTE

SQL Serverobsługuje możliwość personifikować innego podmiotu jawnie, używając instrukcja EXECUTE jako autonomiczny albo niejawnie na podstawie wykonywanie jako klauzula na moduły.Instrukcja EXECUTE jako autonomiczny można personifikować podmiotów poziom serwera lub logowania, przy użyciu instrukcji EXECUTE logowania jako.Instrukcja EXECUTE jako autonomiczny można również personifikować podmiotów poziom bazy danych lub użytkowników, przy użyciu instrukcji EXECUTE jako użytkownik.

Niejawna impersonations wykonywanych przez wykonanie jako klauzula na moduły personifikować określonego użytkownika lub logowania poziom bazy danych lub serwera.Personifikacja ten zależy od tego, czy moduł jest moduł poziom bazy danych, takich jak procedura składowana lub funkcja modułu poziom serwera, takiego jak wyzwalacz poziom serwera.

Opis zakresu personifikacji

Gdy uosabia zleceniodawca przy użyciu instrukcja EXECUTE logowania jako lub modułu zakres serwera za pomocą klauzula zakres personifikacji jest serwer WWW EXECUTE.Oznacza to, że po przełączanie kontekstu, dowolnego zasób w obrębie serwera logowania personifikowanym uprawnieniami na możliwy.

Jednakże gdy uosabia zleceniodawca przy użyciu instrukcja EXECUTE użytkownika jako lub modułu zakres bazy danych za pomocą klauzula zakres personifikacji jest ograniczony do bazy danych domyślnie EXECUTE.Oznacza to, że odwołania do obiektów poza zakres bazy danych zwróci błąd.Aby poznać przyczynę to zachowanie domyślne, należy rozważyć następujący scenariusz.

Jest możliwe, że właściciel bazy danych, mając pełne uprawnienia w tej bazie danych nie ma żadnych uprawnień poza zakres bazy danych.Dlatego SQL Server nie umożliwia personifikację, właściciel bazy danych lub przydzielić innemu użytkownikowi możliwość personifikować inny użytkownik mógł uzyskać dostęp do zasobów poza zakres uprawnień bieżącego właściciela bazy danych.

Na przykład, rozważmy dwie bazy danych w środowisku obsługującym i każdej bazy danych należy do oddzielnego obiekt będącego właścicielem.Database1 is owned by Bob and Database2 is owned by Fred.Robert ani Fred chce inne dostęp do zasobów w ramach ich odpowiednich bazach danych.As the owner of Database1, Bob can create a user for Fred in his database and because he has full permissions within Database 1, Bob can also impersonate user Fred.Jednakże z powodu ograniczeń zabezpieczeń nałożonych przez SQL Server, Robert nie może uzyskać dostępu do bazy danych przez Fred w kontekście personifikowanym.Bez te domyślne ograniczenia w miejscu Robert będzie mogła uzyskać dostęp do danych Fred użytkownika bez jego wiedza.Dlatego właśnie zakres impersonations poziom bazy danych jest ograniczone przez bazę danych domyślnie.

Jednak w pewnych sytuacjach może być przydatne selektywnie rozszerzenie zakres personifikacji poza bazą danych.Na przykład byłoby to przypadek aplikacji, która używa dwóch baz danych i wymaga dostępu do baz danych z bazy danych.

Należy rozważyć przypadek gospodarczego aplikacji, która wywołuje procedura składowana GetSalesProjections w gospodarczego bazy danych i procedura składowana jest wykonanie przełączanie kontekstu określonych w nim.Wywołuje procedura składowana sprzedaży bazy danych do pobierania informacji o sprzedaży z SalesStats tabela.Domyślnie w tym scenariuszu nie będą działać, ponieważ kontekst wykonywania ustanowiony wewnątrz jednej bazy danych jest nieprawidłowa poza bazą danych.Jednak deweloperzy aplikacji gospodarczego nie ma użytkowników aplikacji marketing bezpośredni dostęp do Sprzedaż bazy danych lub mieć uprawnienia na wszystkich obiektach.Idealnym rozwiązaniem byłoby użyć jako wykonywanie w klauzula procedura składowana personifikować użytkownika, który ma wymagane uprawnienia w Sprzedaż bazy danych.Jednakże ograniczenia domyślnego aktualnie temu zapobiec.Pytanie jest tak, jak deweloperzy rozwiązać ten problem.

W SQL Server, można wybiórczo rozszerzenie zakres personifikacji bazy danych, ustanowiona w bazie danych przez ustanowienie model zaufania między dwoma baz danych.Jednak przed opisującego ten model zaufania i jak zakres personifikację można selektywnie rozszerzony, należy przeanalizować uwierzytelnianie i roli wystawców uwierzytelnienia w SQL Server.

Opis wystawców uwierzytelnienia

Uwierzytelnianie jest procesem, w którym określonego główne ustanawia i udowadnia swoją tożsamość system.wystawca uwierzytelnienia jest obiekt, który uwierzytelnia lub zakwaterowaniu, autentyczność określonego głównego zobowiązanego.Na przykład, po nawiązaniu połączenia do SQL Server, logowanie jest ustalona dla tego połączenia jest uwierzytelniany przez wystąpienie SQL Server.

Należy rozważyć przypadek, w którym użytkownik jawnie przełącza kontekst na poziom serwera za pomocą instrukcja EXECUTE logowania jako.Wymaga to uprawnień personifikację poziom serwera.Te uprawnienia pozwalają grantee uprawnienie wywołującego instrukcja EXECUTE logowania jako możliwość podszycia się pod określony login wszędzie w wystąpienie z SQL Server.W efekcie instrukcja zezwala rozmówcy do symulowania działania rejestrowania w, jako że personifikowanym logowanie.Właściciel zakres serwera poziom uprawnień jest sysadmin , jest właścicielem wystąpienie SQL Server.W tym przypadek personifikacji poziom serwera, wystawca uwierzytelnienia jest sysadmin lub wystąpienie SQL Server sobie.

Jednak rozważyć przypadek, w którego kontekście jest ustanowiona, z powodu instrukcja EXECUTE użytkownika jako lub EXECUTE AS klauzula modułu zakresu bazy danych.W takich wypadkach uprawnienia personifikacji w zakres bazy danych są sprawdzane.Domyślnie dla zakres uprawnień PERSONIFIKOWANIE użytkowników jest samej bazy danych, którego właścicielem jest dbo.Wystawca uwierzytelnienia te impersonations jest również właścicielem bazy danych.Ponadto jest właścicielem bazy danych, która w efekcie tożsamości personifikowanego użytkownika i zakwaterowaniu jego autentyczności.Ponieważ właściciel bazy danych jest właścicielem bazy danych pełną, personifikowanym kontekstu jest uważane za autentyczne wszędzie w określonej bazie danych.Jednakże poza tej bazy danych, personifikowanym kontekstu jest nieprawidłowy.

Sposób użycia wystawców uwierzytelnienia

Wystawców uwierzytelnienia są używane do określenia, czy ustalonych kontekstu jest prawidłowy wewnątrz określonego zakres.Często, wystawca uwierzytelnienia jest administrator systemu (SA) lub wystąpienie SQL Server, lub z bazami danych, dbo.Wystawca uwierzytelnienia jest skutecznie właściciela zakres, w którym ustanowiona jest kontekst dla określonego użytkownika lub logowania.Informacje wystawca uwierzytelnienia przechwycone w obrębie informacji o tokenie utrzymywane dla użytkowników i logowania i są widoczne przez sys.user_token i sys.login_token widoki.Aby uzyskać więcej informacji, zobacz Opis kontekstu wykonania.

Ostrzeżenie

Jeśli żadne informacje o wystawcy uwierzytelnienia jest zwracany w widoku token, wystawca uwierzytelnienia jest wystąpienie SQL Server.Jest to wartość true, jeśli brak jest kontekstu przełączania lub jeśli personifikację poziom serwera.

Kontekst wykonywania, zawierający właściciela zakres jako jego wystawca uwierzytelnienia jest prawidłowa dla tego zakres.Jest tak, ponieważ właściciel zakres, na przykład bazy danych, jest niejawnie zaufany przez wszystkie podmioty w zakresie.Kontekście obowiązuje także w innych zakresach, na przykład innych baz danych lub wystąpienie SQL Server siebie, w którym wystawca uwierzytelnienia jest zaufanych.Dlatego ważności kontekście personifikowanym użytkownikiem poza zakres bazy danych zależy czy wystawca uwierzytelnienia kontekstu jest zaufany w miejsce docelowe zakres.To zaufanie jest ustanowiona przez przyznawania uprawnień UWIERZYTELNIJ wystawca uwierzytelnienia, jeśli zakres miejsce docelowe jest inna baza danych lub uprawnienia do uwierzytelniania serwera, jeśli zakres miejsce docelowe jest wystąpienie SQL Server.

Rozszerzanie zakresu personifikacji

Aby rozszerzyć zakres personifikacji od wewnątrz bazy danych w miejsce docelowe zakresu, takie jak innej bazy danych lub wystąpienie SQL Server, następujące warunki muszą być frędzlami

  • Wystawca uwierzytelnienia musi zaufane w miejsce docelowe zakres.

  • źródłowa baza danych Musi zostać oznaczone jako zaufane.

Ufanie wystawcy uwierzytelnienia

Przy użyciu poprzedniego sprzedaży i gospodarczego bazy danych przykład na poniższej ilustracji przedstawiono procedura składowana GetSalesProjections w gospodarczego dostęp do danych w bazie danych SalesStats tabela w Sprzedaż bazy danych.Procedura składowana zawiera klauzula wykonanie użytkownika jako MarketingExec.Właściciel Sprzedaż baza danych jest SalesDBO , a właściciel gospodarczego baza danych jest MarketingDBO.

Polecenie EXECUTE AS przełącza kontekst wykonywania modułu

Gdy GetSalesProjections procedura składowana jest wywoływany przez użytkownika, WYKONAJ W klauzula niejawnie przełącza kontekst wykonanie procedura składowana użytkownika wywołującego MarketingExec użytkownika.Wystawca uwierzytelnienia dla tego kontekstu MarketingDBO, właściciel gospodarczego bazy danych.Domyślnie ta procedura dostęp do wszelkich zasobów w gospodarczego bazy danych, który MarketingExec użytkownik może uzyskać dostęp.Jednakże w celu uzyskania dostępu do tabela w Sprzedaż bazy danych, Sprzedaż bazy danych musi ufać wystawca uwierzytelnienia MarketingDBO.

Można to zrobić, tworząc użytkownika w Sprzedaż bazy danych o nazwie MarketingDBO mapuje do MarketingDBO logowania i następnie przyznawania uprawnień do uwierzytelniania użytkownika w Sprzedaż bazy danych.W wyniku dowolnym kontekście wykonanie, zawierający grantee to uprawnienie jako jego wystawca uwierzytelnienia jest prawidłowy wewnątrz bazy danych.Ponieważ serwer uwierzytelniający MarketingDBO udzielono uprawnienia do uwierzytelniania w sprzedaży bazy danych, w kontekście użytkownika MarketingExec ustanowionych przez co wykonanie w klauzula GetSalesProjections procedura składowana w gospodarczego bazy danych jest zaufane w sprzedaży bazy danych.

Podczas gdy ten przykład demonstruje rozszerzająca zakres personifikacji, aby umożliwić dostęp do obiektu w zewnętrznej bazie danych, jest również możliwe rozszerzenie zakresu personifikacji do wystąpienie SQL Server.Na przykład, gdyby procedury logowania, który jest akcja poziom serwera, która wymaga uprawnień całego serwera, utworzyć uprawnienia serwera uwierzytelniania musiałaby przyznawana wystawca uwierzytelnienia kontekstu.Jest to semantyczna zaufanej dowolnym kontekście, który ma grantee uprawnienia uwierzytelniania serwera jako jego wystawca uwierzytelnienia przez całe wystąpienie SQL Server**,** jak w przypadku wystąpienia zostały rejestrowanie kontekście SQL Server bezpośrednio.

Ufanie bazy danych

W SQL Server, model zaufania przechodzi jeden krok w celu zapewnienia dodatkowych zabezpieczeń i ziarnistość akt rozszerzająca zakres bazy danych poziom personifikacji.Można używać uprawnień UWIERZYTELNIJ jako sposób zakres miejsce docelowe ufa wystawca uwierzytelnienia kontekstu, ale można także określić, czy wystąpienie SQL Server zaufania źródłowa baza danych i zawartość w ramach go

Aby to zilustrować, zakładać, że MarketingDBO główny zobowiązany jest właścicielem innej bazy danych o nazwie konferencji.Również zakładać, że MarketingDBO chce kontekstów wykonanie, które są określone w gospodarczego bazy danych, aby mieć dostęp do zasobów w Sprzedaż bazy danych.Jednak nie chce konteksty są ustanawiane w konferencji bazy danych do dowolnego dostępu do Sprzedaż bazy danych.

Aby osiągnąć tego wymogu, bazy danych, która zawiera moduł, w którym używany jest kontekst personifikacji dostęp do zasobów poza bazą danych muszą być oznaczone jako zaufane.Właściwość godne zaufania wskazuje, czy wystąpienie SQL Server ufa bazy danych i zawartość w typie.właściwość ZAUFANEGO służy dwóm celom:

  1. To zmniejsza zagrożenie pochodzące z baz danych, które są dołączone do wystąpienie SQL Server i potencjalnie może zawierać złośliwy modułów zdefiniowanych wykonać w kontekście wysokie uprawnienia użytkownika.

    Można to osiągnąć, należy upewnić się, że dołączonych baz danych nie oznaczone jako zaufanego domyślnie.Również jest realizowane należy upewnić się, że dostęp do zasobów poza bazą danych przez moduły potencjalnie niebezpiecznego wymaga, bazy danych oznaczone godne zaufania.Ustawienie właściwość ZAUFANEGO bazy danych jest ograniczona do członków sysadmin stała rola serwera.

  2. Dzięki niej administrator wystąpienie SQL Server do odróżnienia baz danych, które powinny mieć możliwość dostępu do zasobów zewnętrznych i tych, które powinny, kiedy baz danych ma takie same właściciel lub właściciel tego jest zaufany jako wystawca uwierzytelnienia w niektórych zakres.

To zachowanie można kontrolować za pomocą właściwość ZAUFANEGO.Załóżmy na przykład, mają sytuacji gdzie personifikowanym kontekstów z jednej bazy danych, 1 bazy danych należy do zaufanych podczas kontekstów z innej bazy danych, 2 bazy danych nie należy do zaufanych i mają tego samego właściciela, który jest zaufany jako wystawca uwierzytelnienia w miejsce docelowe zakres.WIARYGODNY właściwość zestaw na dla database1 i ustawić na OFF dla database2 czy moduły w 2 bazy danych nie może uzyskać dostępu do zasobów poza bazą danych.

Na następującej ilustracji pokazano użycie właściwość ZAUFANEGO bazy danych do kontrolowania dostępu do zasobów poza zakresem źródłowa baza danych.MarketingDBO udzielane są uprawnienia do uwierzytelniania w Sprzedaż bazy danych i jest jego właścicielem gospodarczego i konferencji baz danych.GetSalesProjections procedura składowana w gospodarczego bazy danych można uzyskać dostęp do Sprzedaż bazy danych, ponieważ spełnia on wymagania zabezpieczeń dwa: wystawca uwierzytelnienia, MarketingDBO, jest zaufana w miejsce docelowe zakres i źródłowej bazy danych gospodarczego, jest godna zaufania.Próbuje uzyskać dostęp do Sprzedaż bazy danych z konferencji bazy danych są odrzucane, ponieważ tylko jeden wymóg jest spełniony: Wystawca uwierzytelnienia, MarketingDBO, jest zaufana w miejsce docelowe zakres.

Kontrolowanie dostępu bazy danych do zasobów zewnętrznych

Zawsze, gdy podjęta próba uzyskania dostępu do zasób poza zakres bazy danych przy użyciu kontekstu personifikowanym, wystąpienie SQL Server weryfikuje, że bazy danych, z którego pochodzi żądanie jest godna zaufania i że wystawca uwierzytelnienia jest zaufany.

Certyfikaty i klucze asymetryczne jako wystawców uwierzytelnienia

Kontekst personifikacji siedzibę bazy danych można rozszerzyć dostęp do zasobów poza zakres bazy danych przy użyciu właściciel bazy danych jako wystawca uwierzytelnienia.Wymaga to zaufane właściciel bazy danych przez zewnętrznych zasób i samej bazy danych jest także godna zaufania.Jednakże podejście to wynika, że gdy zaufanych właociciela udzielane są uprawnienia do uwierzytelniania lub uwierzytelnianie serwera w miejsce docelowe zakres i wywołania bazy danych jest wiarygodny, dowolnym kontekście personifikowanym ustanowiony w bazie danych jest ważna przez miejsce docelowe zakres ufa właściciel bazy danych.

Szczegółowo poziom zaufania mogą być wymagane.Załóżmy, że wymagania biznesowe wskazuje ufania kilku modułów w źródłowej bazie danych jako wykonywanie klauzula dostępu do miejsce docelowe zasobów, ale nie ufania całego źródłowej bazy danych.Załóżmy na przykład, SalesDBO chce upewnić się to tylko GetSalesProjections procedura składowana można uzyskać dostępu do SalesStats tabela jako MarketingExec użytkownika, ale nie wszyscy gospodarczego bazy danych z personifikować uprawnienia na MarketingExec mogli uzyskać dostęp do zasobów sprzedaży bazy danych.Ufanie MarketingDBO i gospodarczego bazy danych do zaufanego nie będzie wykonywać zadania.Zapewnia dodatkowy poziom ziarnistość do wykonania tego wymogu, model zaufania pozwala na Certyfikaty lub klucze asymetryczne do użycia jako wystawców uwierzytelnienia.To wykorzystuje technikę zwane podpisywania.Aby uzyskać informacje dotyczące podpisywania, zobacz Dodaj podpis (Transact-SQL).

Za pomocą podpisów

Podpisy na module Zweryfikuj, że kod w module mogą być modyfikowane tylko przez osoby z dostępem do klucz prywatny, który jest używany do podpisywania modułu.Uwzględniając gwarancje proces podpisywania można zaufania certyfikat lub klucz asymetrycznego, określony w podpisie.Dokładniej można ufać właściciela certyfikat lub klucz asymetrycznego, zamiast tylko właściciel bazy danych.

Ufania podpisanym moduł jest realizowane poprzez przyznawanie uprawnień uwierzytelniania lub uwierzytelnianie serwera do użytkownika w zakres miejsce docelowe, który jest mapowany do certyfikat lub klucz asymetrycznego.

W związku z tym kontekście wykonywania ustanowione w module, który jest podpisany przy użyciu zaufanego certyfikatu jest prawidłowy w zakres miejsce docelowe, w którym certyfikat jest zaufany.

Załóżmy, że procedura GetSalesProjections jest podpisany przy użyciu certyfikat o nazwie C1.Certyfikat C1 musi znajdować się w Sprzedaż bazy danych i użytkownika, na przykład CertUser1, musi być mapowany do świadectwa C1.CertUser1 następnie udzielane są uprawnienia do uwierzytelniania w Sprzedaż bazy danych.

Po wywołaniu procedury jego podpis zostanie zweryfikowany, aby upewnić się, że go nie została zmieniona po jego podpisaniu.Jeżeli podpis zostanie zweryfikowany, kontekście ustanowionych przez wykonanie klauzula w module ma certyfikat C1 jako jego wystawca uwierzytelnienia.Podpis nie został zweryfikowany, wystawca uwierzytelnienia nie jest dodawany do tokenu, a nie powiedzie się próba dostępu do zasób zewnętrznych.

Na następującej ilustracji pokazano użycie podpisane moduł do kontrolowania dostępu do zasobów poza zakresem źródłowa baza danych.Procedura GetSalesProjections w gospodarczego bazy danych jest podpisany przy użyciu certyfikat o nazwie C1.Certyfikat C1 w Sprzedaż bazy danych i użytkownika CertUser mapowanego na certyfikat.CertUser1 udzielane są uprawnienia do uwierzytelniania w Sprzedaż bazy danych.

Certyfikat służący do ograniczania dostępu do bazy danych

Zaufanie w tym wystawca uwierzytelnienia jest weryfikowana w taki sam sposób jak zaufanie jest weryfikowane, gdy właściciel bazy danych jest urządzeniem uwierzytelniającym.Oznacza to, że jest weryfikowana poprzez sprawdzenie uprawnień uwierzytelniania serwera lub uwierzytelniania.Jednak ponieważ zaufania jest ustanowiona poziom szczegółowości i moduł nie mogą być zmieniane bez modyfikowania podpis, jest niepotrzebna ZAUFANEGO właściwość bazy danych do weryfikacji.

Zmniejsza to zagrożenie, które pochodzą z dołączonych baz danych przy użyciu złośliwego kodu w nich.Osoba atakująca musiałaby zarejestrować moduł z prywatnego klucz , który odpowiada certyfikat, który jest zaufany.Jednak osoba atakująca nie ma dostępu do tego klucz.Ponadto jeśli utworzono nowy lub zmodyfikowany istniejący moduł zaufanej, moduł nie będzie zaufanego podpisu.

Aby uzyskać więcej informacji, zobacz Moduł podpisywania (aparat bazy danych).

Zasady rozszerzania zakresu personifikacji bazy danych

Podsumowując, zakres personifikacji kontekstu siedzibę bazy danych może zostać rozszerzona na inne zakresy tylko wtedy, gdy są spełnione następujące warunki:

  • wystawca uwierzytelnienia, właściciel bazy danych lub certyfikat lub klucz asymetrycznego, używany do podpisywania moduł, należy zaufane w miejsce docelowe zakres.Można to zrobić przez udzielanie uprawnień do uwierzytelniania serwera lub uwierzytelniania podmiotu, który mapuje właociciela certyfikat i klucz asymetrycznego.

  • wystawca uwierzytelnienia jest właścicielem bazy danych źródłowa baza danych muszą być oznaczone jako zaufane.Można to zrobić przez ustawienie właściwość ZAUFANEGO na bazę danych.

Wybierając mechanizm zaufania dla potrzeb

Istnieją zalety i wady podejście właściciel bazy danych i podejście podpisu.Najlepszym mechanizmem potrzeb zależy od wymagań biznesowych i środowiska biznesowego.

Podejście właściciel bazy danych

Podejście właściciel bazy danych do ustanowienia zaufania ma następujące zalety i wady:

  • Nie wymaga żadnych Zrozumienie pojęć kryptografii, takich jak certyfikaty lub podpisów.

  • Nie zapewnia największą ziarnistość jako podejścia opartego na podpis.

  • Dołączania bazy danych do wystąpienie SQL Server ustawia właściwość ZAUFANEGO bazy danych, aby występujeModuły zaufanej przez właściciela bazy danych nie będzie obowiązywać aż administrator systemu jawnie ustawia właściwość ZAUFANEGO na.Oznacza to, że jest potencjalnie niektóre interwencji, które są wymagane przez administrator systemu przed dołączanej bazy danych można funkcja a dostęp do innych baz danych.

Podejście podpisu

Podejście podpisu przy ustanawianiu zaufania ma następujące zalety i wady:

  • Można udostępniać granulowany poziom zaufania, ale dotyczy tylko przełączeń kontekstu, wykonywanych w ramach podpisanej modułów.

  • Nie można zastosować podpis do przełączeń kontekstu, ustanowione przez autonomiczny instrukcji EXECUTE użytkownika jako i wykonać logowanie jako.Instrukcje te wymagają podejścia opartego na właściciela bazy danych, aby rozszerzyć zakres zaufania.

  • Istnieje możliwość dostawcę lub dewelopera zarejestrować moduł z kluczem prywatnym, ale usunąć klucz prywatny przed dostarczeniem modułów lub bazy danych.Dzieje się tak, ponieważ klucze prywatne są używane tylko do podpisywania modułów.Do celów weryfikacji podpisu klucze publiczne związane z modułem są wystarczające.

  • Dołączania bazy danych nie ma wpływu na moduły, które są zaufane, ze względu na swoje podpisy.Będą one działać bez dodatkowych wymagań.