Udostępnij za pośrednictwem

  • Artykuł

Extending Database Impersonation by Using EXECUTE AS

SQL Server obsługuje możliwość podszycia się pod innego podmiotu za jawnie za pomocą instrukcja wykonać jako autonomiczny lub niejawnie przy użyciu wykonać AS klauzula dla modułów.Autonomiczny instrukcja wykonać AS można personifikować głównych poziom serwera lub logowania, przy użyciu instrukcja wykonać AS LOGIN.Autonomiczny instrukcja wykonać AS można również personifikację poziom głównych obiektów bazy danych lub użytkowników, przy użyciu instrukcja wykonać AS USER.

Niejawna impersonations są wykonać za pośrednictwem wykonać AS klauzula na moduły podszycia się pod określonego użytkownika lub logowania poziom bazy danych lub serwera.To personifikacji zależy od tego, czy moduł jest moduł poziom bazy danych, takie jak procedura przechowywana lub funkcja modułu poziomie serwera, takiego jak wyzwalacz poziomie serwera.

Opis zakres personifikacji

Podczas personifikacji obiektem przy użyciu instrukcja wykonać AS LOGIN lub modułu o zakresie serwera za pomocą wykonać AS klauzula zakres personifikację jest całego serwera.Oznacza to, że po przełączniku kontekstu wszystkich zasób na serwerze, który personifikowanego logowanie ma uprawnienia do możliwy jest dostęp.

Jednak podczas personifikacji obiektem przy użyciu instrukcja wykonać AS USER lub modułu bazy danych o zakresie przy użyciu wykonać AS klauzula zakres personifikacji jest ograniczona do bazy danych domyślnie.Oznacza to, że odwołania do obiektów poza zakres bazy danych będzie zwracać błąd.Aby poznać przyczynę to zachowanie domyślne, należy rozważyć następujący scenariusz.

Istnieje możliwość, że właściciel bazy danych, podczas mają pełne uprawnienia w tej bazie danych nie ma żadnych uprawnień poza zakres bazy danych.Dlatego też SQL Server nie zezwala na właściciel bazy danych do podszycia się pod lub udzielić osobie możliwość podszycia się pod, inny użytkownik mógł uzyskać dostęp do zasobów poza zakres bieżące uprawnienia właściciela bazy danych.

Na przykład, należy rozważyć dwie bazy danych w środowisku hostingu i każdej bazy danych należy do odrębną jednostkę na stronie.Database1 is owned by Bob and Database2 is owned by Fred.Robert ani Fred chce drugiej do uzyskania dostępu do zasobów w 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 ze względu na ograniczenia zabezpieczeń narzucone przez SQL ServerRobert nie można uzyskać dostępu do bazy danych przez Fred w kontekście personifikowanego. Bez te domyślne ograniczenia w miejscu Robert, będzie mogła uzyskać dostęp do danych firmy Fred bez jego wiedza.Jest to dlaczego 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 bazy danych.Na przykład czy to przypadek aplikacji, która korzysta z dwóch baz danych i wymaga dostępu do baz danych z innej bazy danych.

Należy wziąć pod uwagę wielkości liter w marketingu aplikacji, która wywołuje procedura przechowywana, o nazwie GetSalesProjections in the Obrót bazy danych i procedura przechowywana ma przełącznik kontekst wykonywania zdefiniowana w nim.Wywołuje procedura przechowywana Sprzedaż bazy danych do pobierania informacji o sprzedaży z SalesStats tabela.Domyślnie w tym scenariuszu nie będzie działać, ponieważ kontekst wykonanie ustanowiony wewnątrz jednej bazy danych jest nieprawidłowa poza bazą danych.Jednak deweloperzy aplikacji obrotu nie powinien użytkowników aplikacji marketingu bezpośredniego dostępu do Sprzedaż bazy danych lub mieć uprawnienia na wszystkich obiektach.Idealnym rozwiązaniem byłoby użyć wykonać AS klauzula w przechowywanej procedurze podszycia się pod użytkownika ma wymagane uprawnienia Sprzedaż bazy danych.Jednak ograniczenia domyślne znajdujące się w miejscu temu zapobiec.Pytanie jest tak, jak deweloperzy mogą rozwiązać ten problem.

W SQL Server, można wybiórczo rozszerzyć zakres personifikacji bazy danych, ustalone w bazie danych, ustanawiając modelu zaufania między dwiema bazami danych. Jednak przed opisujących ten model zaufania i w jaki sposób zakres personifikację może być selektywnie rozszerzony, należy wiedzieć uwierzytelnianie i roli uwierzytelnienia w SQL Server.

Opis uwierzytelnienia

Uwierzytelnianie to proces, za pomocą których określonego główny ustanawia oraz udowadnia swoją tożsamość system.wystawca uwierzytelnienia jest jednostką, który uwierzytelnia lub ręczy za autentyczność określonego obiekt.Na przykład, po nawiązaniu połączenia z SQL Server, identyfikator logowania, które są ustanowione dla tego połączenia jest uwierzytelniany przez wystąpienie SQL Server.

Należy wziąć pod uwagę przypadek, w którym użytkownik jawnie przełącza kontekst na poziom serwera za pomocą instrukcja wykonać AS LOGIN.Wymaga to uprawnień personifikację poziom serwera.Te uprawnienia pozwalają grantee uprawnień, wywołujący instrukcja wykonać AS LOGIN, możliwość podszycia się pod określonym logowania wszędzie w obrębie wystąpienie SQL Server. W efekcie instrukcja umożliwia wywołującego przeprowadzić symulację działania rejestrowania w jak tego personifikowanego logowania.Właściciel zakres serwera poziom uprawnień jest sysadmin właścicielem wystąpienie SQL Server. W takim przypadek personifikacji poziom serwera, wystawca uwierzytelnienia jest sysadmin lub wystąpienie SQL Server sam.

Jednakże należy wziąć pod uwagę przypadek, w którego kontekście jest ustanowiona, z powodu instrukcja wykonać AS USER lub wykonać AS klauzula na module bazy danych o zakresie.W takich wypadkach uprawnienia personifikacji w zakres bazy danych są sprawdzane.Wartość domyślna dla zakres PERSONIFIKACJI uprawnień użytkowników jest samej bazy danych, których właścicielem jest dbo.Ponadto wystawca uwierzytelnienia te impersonations jest właścicielem bazy danych.Ponadto jest właścicielem bazy danych, które w rzeczywistości ustanawia tożsamości personifikowanego użytkownika i ręczy za jego autentyczności.Ponieważ właścicielem bazy danych jest właścicielem pełną bazy danych, kontekście personifikowanego jest uważane za autentyczne wszędzie w ramach określonej bazy danych.Jednak poza tą bazą danych kontekście personifikowanego jest nieprawidłowa.

W jaki sposób są używane uwierzytelnienia

Uwierzytelnienia są używane do ustalenia, czy ustalonych kontekstu jest prawidłowy wewnątrz określonego zakres.Często wystawca uwierzytelnienia jest administrator systemu (SA, Security ASSOCIATION) lub wystąpienie programu SQL Server, lub z bazami danych, dbo.wystawca uwierzytelnienia jest faktycznie właściciela zakres, w którym ma siedzibę kontekst dla określonego użytkownika lub logowania.Informacje wystawca uwierzytelnienia są przechwytywane w obrębie informacji o tokenie utrzymywane dla użytkowników i identyfikator logowania i są widoczne przez sys.user_token and sys.login_token widoki.Aby uzyskać więcej informacji zobaczUnderstanding Execution Context.

Uwaga

Brak informacji o wystawca uwierzytelnienia jest zwracany w widoku token, wystawca uwierzytelnienia jest wystąpienie SQL Server. Jest to PRAWDA, jeśli brak jest kontekstu przełączanie lub jest personifikację poziom serwera.

Kontekst wykonania jest właściciel zakres jako jej wystawca uwierzytelnienia jest prawidłowa dla tego zakres.Dzieje się tak, ponieważ właściciel zakres, na przykład bazy danych, domyślnie jest zaufany dla wszystkich obiektów w zakresie.Kontekście obowiązuje także w innych zakresach, na przykład innych baz danych lub wystąpienie programu SQL Server w którym wystawca uwierzytelnienia się zaufany.W związku z tym, ważności kontekście personifikowanego użytkownika poza zakres bazy danych zależy od tego, czy wystawca uwierzytelnienia kontekstu jest zaufane w miejsce docelowe zakresu.Tego zaufania jest ustanowiona przez przyznawania uprawnień AUTHENTICATE wystawca uwierzytelnienia, jeśli zakres miejsce docelowe jest innej bazy danych lub serwera AUTHENTICATE uprawnień, jeśli zakres miejsce docelowe jest wystąpienie SQL Server.

Rozszerzenie zakres personifikacji

W celu rozszerzenia zakres personifikacji w z wewnątrz bazy danych miejsce docelowe zakres, takie jak innej bazy danych lub wystąpienie programu SQL Server, muszą być spełnione następujące warunki.

  • Uwierzytelniającym musi być zaufany w zakresie docelowym.

  • Źródłowa baza danych ma być oznaczone jako zaufane.

Ufanie wystawca uwierzytelnienia

Przy użyciu poprzedniego Sprzedaż and Obrót przykład baz danych, na poniższej ilustracji przedstawiono procedura przechowywana GetSalesProjections in the Obrót bazy danych, uzyskiwanie dostępu do danych w SalesStats tabelaSprzedaż bazy danych.Przechowywana procedura zawiera klauzulę wykonać AS USER MarketingExec.Właściciel Sprzedaż jest baza danych SalesDBO a właścicielaObrót jest baza danych MarketingDBO.

EXECUTE AS switches execution context of a module

Gdy GetSalesProjections przechowywane procedury jest wywoływany przez użytkownika, the wykonać AS klauzula niejawnie przełącza kontekst wykonać procedura przechowywana przez użytkownika wywołującego MarketingExec użytkownika.Wystawca uwierzytelnienia dla tego kontekstu jest MarketingDBO, właściciel Obrót bazy danych.Domyślnie, procedurę tę mogą uzyskać dostęp wszystkie zasoby w obrębie Obrót bazy danych, które MarketingExec użytkownik może uzyskać dostęp.Jednak 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 mapowanyMarketingDBO logowania i, a następnie nadając temu użytkownikowi uprawnienie AUTHENTICATE Sprzedaż bazy danych.W wyniku dowolnym kontekście wykonanie zawierający grantee o uprawnienie, to jako jego wystawca uwierzytelnienia jest prawidłowy w bazie danych.Ponieważ wystawca uwierzytelnienia MarketingDBO udzielono uprawnienia AUTHENTICATE w Sprzedaż bazy danych, kontekst użytkownika MarketingExec ustanowionych przez wykonać AS klauzula w GetSalesProjections procedura przechowywana w Obrót zaufanej w bazy danychSprzedaż bazy danych.

W czasie, gdy w przykładzie pokazano rozszerzająca zakres personifikacji, aby zezwolić na dostęp do obiektu w zewnętrznej bazie danych, możliwe jest także rozszerzenie zakresu personifikacji do wystąpienie SQL Server. Na przykład gdyby procedury do utworzenia identyfikatora logowania akcja poziomie serwera, która wymaga uprawnień dla całego serwera uprawnienie AUTHENTICATE SERVER musi być przyznane wystawca uwierzytelnienia od kontekstu.Jest to semantyki zaufanej dowolnym kontekście, zawierający grantee uprawnień AUTHENTICATE serwera jako jego wystawca uwierzytelnienia w całości wystąpienie SQL Server**,** tak, jakby były logowania kontekście do wystąpienia SQL Server bezpośrednio.

Ufanie bazy danych

W SQL Server, model zaufania przejście jeden krok w celu zapewnienia dodatkowych zabezpieczeń i ziarnistość do działania rozszerzenia zakres bazy danych poziom personifikacji. Można użyć uprawnień AUTHENTICATE jako sposób, w jaki zakres miejsce docelowe zaufać wystawca uwierzytelnienia kontekstu, ale można także określić, czy wystąpienie SQL Server relacje zaufania źródłowa baza danych i jego zawartość.

Aby to zilustrować, założono, że MarketingDBO podmiot jest właścicielem innej bazy danych o nazwie Konferencja.Również założono, że MarketingDBO chce kontekstów wykonania, które są określone w ramach Obrót bazy danych, aby mieć dostęp do zasobów w Sprzedaż bazy danych.Jednak nie chce wszystkich kontekstów, które są ustalone w Konferencja bazy danych, aby korzystać z dowolnej Sprzedaż bazy danych.

Aby osiągnąć ten wymóg, 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 relacje zaufania z bazą danych i zawartość w nim. Właściwość ZAUFANEGO służy dwóch celach:

  1. Zmniejsza ona zagrożenie, pochodzących z baz danych, które są dołączone do wystąpienie SQL Server i mogą zawierać potencjalnie szkodliwe modułów określonych do wykonać w kontekście użytkownika wysokie uprawnienia.

    Można to osiągnąć, należy upewnić się, że dołączonych baz danych nie są oznaczane zaufanego domyślnie.Jest również możliwe należy upewnić się, że dostęp do zasobów poza bazą danych przez moduły potencjalnie złośliwe wymaga, bazy danych były oznaczane godne zaufania.Ustawienie właściwość godne zaufania z bazą danych są ograniczone do członków sysadmin ustalić roli serwera.

  2. Administrator programu SQL Server do odróżnienia bazy danych, które należy zezwolić na dostęp do zasobów zewnętrznych i tych, które powinny nie wtedy, gdy baz danych mają taki sam właściciel lub właściciel tego jest zaufany jako wystawca uwierzytelnienia w niektórych zakres.

Takie zachowanie może być kontrolowane za pomocą Właściwość godny zaufania.Na przykład załóżmy, że sytuacja, w którym personifikowanego kontekstów z jednej bazy danych, 1 bazy danych, powinny być zaufanych kontekstów z innej bazy danych, 2 bazy danych, nie powinny być zaufane i mają tego samego właściciela, który jest zaufany jako wystawca uwierzytelnienia w zakresie docelowym.Godne zaufania właściwość może być ustawiona na ON dla database1 i ustawić na OFF dla database2 Aby upewnić się, że, modułówBazy danych 2 nie można uzyskać dostępu do zasobów poza bazą danych.

Na poniższej ilustracji pokazano sposób użycia właściwość ZAUFANEGO bazy danych do kontrolowania dostępu do reurządzenie źródłowes poza zakresem urządzenie źródłowe bazy danych.MarketingDBO udzielane są uprawnienia AUTHENTICATE w Sprzedaż bazy danych i jest właścicielem Obrót and Konferencja baz danych.The GetSalesProjections procedura przechowywana in the Marketing database can successfully access the Sales database, because it meets the two security requirements: wystawca uwierzytelnienia MarketingDBO, jest zaufany w zakresie docelowym oraz urządzenie źródłowe bazy danych, Obrót, jest godna zaufania.Próbuje uzyskać dostęp do Sprzedaż bazę danychKonferencja bazy danych są odrzucane, ponieważ tylko jedno wymaganie jest spełnione: wystawca uwierzytelnienia MarketingDBO, jest zaufany w miejsce docelowe zakresu.

Controlling database access to external resources

Za każdym razem, gdy przeprowadzana jest próba dostępu do zasób poza zakres bazy danych przy użyciu kontekście personifikowanego, wystąpienie SQL Server sprawdza, czy bazy danych, z którego pochodzi żądanie jest godny zaufania i czy wystawca uwierzytelnienia jest zaufany.

Certyfikaty i klucze asymetrycznego jako uwierzytelnienia

Kontekst personifikacji ustalone w bazie danych mogą być rozszerzane do uzyskania dostępu do zasobów poza zakres bazy danych przy użyciu właścicielem bazy danych jako wystawca uwierzytelnienia.Wymaga to zaufanie właścicielem bazy danych przez zasób zewnętrznych i bazy danych jest również godne zaufania.Jednak to podejście oznacza, że gdy zaufanych właociciela ma udzielone uprawnienia AUTHENTICATE lub AUTHENTICATE SERVER w zakresie docelowym i wywołania bazy danych jest godny zaufania, dowolnym kontekście personifikowanego w tej bazie danych jest ważne na zakres miejsce docelowe, któremu ufa właścicielem bazy danych.

Bardziej szczegółowe poziom zaufania może być wymagane.Załóżmy, że wymagań biznesowych wskazuje zaufanie tylko kilka modułów w źródłowej bazie danych przy użyciu wykonać AS klauzula dostęp do miejsce docelowe zasób, ale nie zaufanie całego źródłowa baza danych.Załóżmy na przykład, SalesDBO chce upewnić się, że tylko GetSalesProjections przechowywane procedury można uzyskać dostępu do SalesStats Tabela MarketingExec użytkownika, ale nie chce, aby wszyscy użytkownicy w Obrót bazę danych z personifikować uprawnienia MarketingExec , aby można było uzyskać dostęp do zasobów w Sprzedaż Baza danych.Ufanie MarketingDBO a ustawienieObrót bazy danych do zaufanego nie będzie wykonywać to zadanie.Aby zapewnić dodatkowy poziom rozdrobnienia, aby wykonać ten wymóg, model zaufania pozwala na certyfikaty or klucze asymetryczne mają być używane jako uwierzytelnienia.To wykorzystuje stosowana jest metoda zwana podpisywania.Aby uzyskać więcej informacji na temat rejestrowania Zobacz Dodawanie podpisu (języka Transact-SQL).

Za pomocą podpisów

Podpisy w module upewnij się, że kod w module mogą być modyfikowane tylko przez osobę mającą dostęp do klucz prywatnego, który jest używany do podpisywania modułu.Biorąc pod uwagę gwarancji proces podpisywania zaufania certyfikat lub klucz asymetrycznego, określone w podpisie.Dokładniej można ufać właściciela certyfikat lub klucz asymetrycznego, zamiast po prostu właścicielem bazy danych.

Ufania podpisanym moduł jest możliwe, udzielając uprawnień AUTHENTICATE lub AUTHENTICATE SERVER użytkownikowi w miejsce docelowe zakres, który jest mapowany do certyfikat lub klucz asymetrycznego.

Z tego podejścia kontekst wykonywania ustalone w module, który jest podpisany przy użyciu zaufanego certyfikatu jest prawidłowy w zakresie docelowym, w którym certyfikat jest zaufany.

Na przykład, załóżmy, że procedura GetSalesProjections podpisany za pomocą certyfikat o nazwie C1.Certyfikat C1 musi znajdować się w Sprzedaż bazy danych i użytkownika, na przykład, CertUser1, musi być mapowany do certyfikatu C1.CertUser1 następnie udzielane są uprawnienia AUTHENTICATE w Sprzedaż bazy danych.

Kiedy procedura zostanie wywołana, jego podpis zostanie zweryfikowany, aby upewnić się, że nie został zmodyfikowany po jego podpisaniu.Jeśli podpis został zweryfikowany, kontekście ustanowionych przez wykonać AS klauzula w module ma certyfikat C1 jako jej 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 poniższej ilustracji pokazano sposób użycia podpisanych modułu do kontrolowania dostępu do reurządzenie źródłowes poza zakresem urządzenie źródłowe bazy danych.Procedura GetSalesProjections in the Obrót podpisany za pomocą certyfikat o nazwie bazy danychC1.Certyfikat C1 jest obecny w Sprzedaż bazy danych i użytkownik CertUser jest mapowany do certyfikatu.CertUser1 udzielane są uprawnienia AUTHENTICATE w Sprzedaż bazy danych.

Certificate used to restrict database access

Zaufanie w tej wystawca uwierzytelnienia jest weryfikowana w taki sam sposób jak zaufania są weryfikowane, gdy właściciel bazy danych jest serwerem uwierzytelniającym.Oznacza to są weryfikowane przez sprawdzenie uprawnień AUTHENTICATE SERVER lub AUTHENTICATE.Jednak ponieważ zaufania jest ustanowiona poziom szczegółowości poziomie i w module nie mogą być zmieniane bez modyfikowania podpis, ma potrzeby ZAUFANEGO właściwość bazy danych do weryfikacji.

Ogranicza to zagrożenie, pochodzące z dołączonych baz danych przy użyciu złośliwego kodu w nich.Osoba atakująca musi zarejestrować się w module przy użyciu klucz prywatnego odpowiadającego certyfikat, który jest już zaufany.Osoba atakująca nie ma dostępu do tego klucz.Ponadto jeśli modyfikowany jest istniejący moduł zaufany lub jest tworzony nowy, moduł nie będzie miał zaufanego podpisu.

Aby uzyskać więcej informacji zobaczModule Signing (Database Engine).

Zasady rozszerzenie zakres personifikacji bazy danych

Podsumowując, można rozszerzyć zakres personifikacji kontekstu ustalone w bazie danych na inne zakresy wtedy i tylko wtedy, gdy są spełnione następujące warunki:

  • wystawca uwierzytelnienia, właściciel bazy danych lub certyfikat albo klucz asymetrycznego użyty do podpisania modułu, musi być zaufany w zakres miejsce docelowe.Można to zrobić, przyznając uprawnienia AUTHENTICATE lub AUTHENTICATE serwera głównego, który jest mapowany do właściciela certyfikat i klucz asymetrycznego.

  • wystawca uwierzytelnienia jest właścicielem bazy danych, źródłowa baza danych musi być oznaczony jako godne zaufania.Można to zrobić przez ustawienie właściwość ZAUFANEGO ON dla bazy danych.

Wybieranie zaufania mechanizm Twoje potrzeby

Brak zalety i wady podejście właściciel bazy danych i podejście podpisu.Najlepsze mechanizmu do własnych potrzeb zależy od wymagań biznesowych oraz do środowiska firmy.

Hasło właściciela bazy danych

Metoda właściciel bazy danych przy ustanawianiu zaufania ma następujące zalety i wady:

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

  • Jako rozwiązanie oparte na podpis nie zapewnia największą ziarnistość.

  • Dołączanie do wystąpienie bazy danych SQL Server Ustawia właściwość ZAUFANEGO bazy danych, aby OFF. Moduły ufa właścicielem bazy danych nie będzie obowiązywać, dopóki administrator systemu jawnie ustawia właściwość ZAUFANEGO on.Oznacza to, że jest potencjalnie niektóre interwencji, które są wymagane przez administrator systemu, zanim dołączonego bazy danych może działać jako ma i uzyskać dostęp do innych baz danych.

Podejście podpisu

Metoda podpisu przy ustanawianiu zaufania ma następujące zalety i wady:

  • Może zapewnić poziomu szczegółowości poziom zaufania, lecz ma zastosowanie wyłącznie w kontekście przełączników, które są wykonywane wewnątrz podpisanych modułów.

  • Podpis nie można zastosować do kontekstu przełączników, które są ustanawiane przez autonomiczny instrukcji wykonać AS USER i wykonać AS LOGIN.Instrukcje te wymagają podejścia opartego na właściciela bazy danych rozszerzenie zakres zaufania.

  • Jest możliwe dla dostawcy aplikacji lub Projektant może zarejestrować modułu przy użyciu klucza prywatnego, ale Usuń klucz prywatny przed dostarczeniem modułów lub bazy danych.Ten sposób jest skuteczny, ponieważ klucze prywatne są używane tylko do podpisywania modułów.Dla celów weryfikacji podpisu kluczy publicznych, związane z modułem, są wystarczające.

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