Coś mi brakuje podczas próby użycia procedury składowanej EXECUTE AS. Procedura składowana odczytuje dane source_db, agreguje je i przechowuje wynik target_db.
Sam SP jest w target_db. Mam dedykowany logowanie i mapować je do użytkowników w obu source_dbi target_dbdla właściciela SP jest (więc jest łatwy app_agentw source_dba target_dbdo logowania app_agent).
Jeśli zaloguję się jako app_agenti wykonam
EXEC target_db.app_agent_schema.import_datawszystko dziala. Ale jeśli się zmienię
ALTER PROCEDURE app_agent_schema.import_data WITH EXECUTE AS OWNER` (or `AS SELF`) i spróbuj go wykonać, rzuca
Główny serwer „app_agent” nie może uzyskać dostępu do bazy danych „source_db” w obecnym kontekście bezpieczeństwa.
Używam SQL Server 2008.
Czy ktoś mógłby wskazać mój błąd?
Dzięki
Aktualizacja
Po przeprowadzeniu badań odkryłem, że ALTER DATABASE target_db SET TRUSTWORTHY ONrozwiązuje problem, ale nie wydaje mi się to właściwym rozwiązaniem ...
źródło
Odpowiedzi:
Jest to wyjaśnione w temacie Rozszerzanie personifikacji bazy danych za pomocą EXECUTE AS . Kontekst EXECUTE AS jest zaufany tylko w bieżącej bazie danych, a przeniesienie go do innych baz danych stanowi eskalację wektora ataku uprzywilejowanego.
Istnieją dwa rozwiązania opisane w powyższym artykule:
łatwe jeden jest, aby zaznaczyć godny zaufania bazy danych:
ALTER DATABASE [source_db] SET TRUSTWORTHY ON;. Chociaż łatwo jest również niebezpieczne, ponieważ sprawia, żedbostanowisource_dbde factosysadmin.bezpiecznym jest użycie podpisu kodu, patrz przykład Wywołanie procedury w innej bazie danych . Jest to bardziej złożone, ale zapewnia 100% bezpieczeństwo buletproff.
źródło
Który użytkownik uruchamia polecenie ALTER PROCEDURE? Może ustawić poziom dostępu właściciela (własny) na tego użytkownika, a nie na zamierzony.
źródło
app_agent). Jeśli mam procedurę utworzoną przezapp_agentbezexecute as owner/self, zaloguj się jakoapp_agentSP wykonuje się poprawnie. Jeśli dodamEXECUTE AS SELF(ponownie tego samego użytkownika) iapp_agent...is not able to access the database...