Jaki jest cel „właściciela” bazy danych?

Dzisiaj podczas rozwiązywania problemu z brokerem usług odkryłem, że właścicielem bazy danych był login Windows pracownika, który odszedł z firmy. Jego login został usunięty, dlatego powiadomienia o zapytaniach nie powiodły się.

Podobno najlepszą praktyką do radzenia sobie z tym jest utworzenie „sa” właścicielem bazy danych. Zmieniliśmy to i to wyczyściło kolejkę.

Moje (bardzo elementarne) pytanie: kto jest właścicielem bazy danych i jaki jest jej cel?

Istnieje pewne zamieszanie między koncepcjami bazy danych „dbo” (użytkownik) i „db_owner” (stała rola) z jednej strony a koncepcją instancji „właściciela bazy danych” z drugiej strony. „Dbo” i „db_owner” są często nazywane „właścicielem bazy danych”. W pytaniu mówisz o właścicielu bazy danych jako głównym serwerze, który jest właścicielem bazy danych.

Teoria wygląda następująco: wszystko, co może uzyskać uprawnienia, jest „zabezpieczalne” . Wszystkie papiery wartościowe mają właściciela. Właściciel papierów wartościowych ma absolutną kontrolę nad papierami wartościowymi i nie można odmówić im żadnych przywilejów. Zabezpieczenia na poziomie instancji są własnością podmiotów głównych serwera (loginów). Zabezpieczenia na poziomie bazy danych są własnością podmiotów baz danych (użytkowników). Główny ma dwa rodzaje smaków: pierwotny (tożsamość) i wtórny (członkostwo). Zabezpieczenia na poziomie serwera są domyślnie własnością aktualnie zalogowanego głównego serwera głównego. Zabezpieczenia na poziomie bazy danych są domyślnie własnością bieżącego podmiotu bazy danych, z wyjątkiem obiektów powiązanych ze schematem, które domyślnie są własnością właściciela schematu. Wszystkie papiery wartościowe obsługują klauzulę AUTORYZACJA w czasie tworzenia, aby wymusić innego właściciela.ALTER AUTHORIZATION może być później wykorzystany do zmiany właściciela dowolnego zabezpieczenia.

Ponieważ baza danych jest zabezpieczana na poziomie serwera, domyślnie jest własnością głównego podmiotu, który wydał instrukcję CREATE DATABASE. To znaczy. login NT zmarłego pracownika.

Więc twoje pytanie brzmi: „ Dlaczego papiery wartościowe potrzebują właściciela? ”. Ponieważ właściciel jest źródłem zaufania. To właściciel udziela, odmawia i cofa uprawnienie do obiektu. Czy można zaprojektować system bezpieczeństwa bez właścicieli papierów wartościowych? Prawdopodobnie tak, ale musiałby istnieć jakiś mechanizm zastępujący rolę, jaką odgrywają właściciele w obecnym modelu. Weźmy na przykład pod uwagę, że tata zabezpieczenia nie mają właściciela (np. Zamiast posiadania zabezpieczenia, oryginalny twórca otrzymuje po prostu KONTROLĘ nad nim), byłoby możliwe utworzenie zabezpieczenia i odwołanie dostępu dla wszystkich , w tym dla niego samego. Wymóg właściciela pozwala obejść ten problem, ponieważ właściciel nie może się zablokować.

Mało znany efekt uboczny CREATE DATABASE polegający na utworzeniu zabezpieczonej (bazy danych) posiadanej przez oryginalny login NT już wiele razy płonął. Zasady są takie same dla każdego zabezpieczanego, ale niektóre czynniki pogarszają problemy właściciela bazy danych:

• inne zabezpieczenia na poziomie serwera (punkt końcowy, rola serwera, login) są bardzo rzadko używane, przenoszone itp.
• zabezpieczenia na poziomie bazy danych zwykle kończą się tym, że są własnością dbo(podmiotu bazy danych) lub jakiegoś innego podmiotu bazy danych, a zatem właściciel jest zawarty w bazie danych
• Ustawienie domyślnej własności bazy danych na NT jako główny podmiot powoduje powstanie problemu związanego z przechowywaniem (właścicielem jest NT SID zarządzany przez AD i nie podróżuje z plikami bazy danych, konto NT może być wyróżnione itp. Itp.)
• najważniejsze: właściciel bazy danych ma ważne skutki uboczne, w szczególności EXECUTE AS context. Ten późniejszy problem spala większość użytkowników. Ponieważ Service Broker w szerokim zakresie korzysta z EXECUTE AS (dostarczanie wiadomości ma niejawny kontekst EXECUTE AS, a także jawną aktywację kolejki), zwykle użytkownicy Service Broker odkrywają ten problem jako pierwszy.

BTW, Kudos za zbadanie i naprawienie oryginalnego problemu :)

Baza danych ownerjest trochę cofnięta do czasów, zanim (właściwy) schemat został wprowadzony w SQL Sever 2005.

Zasadniczo właścicielem bazy danych jest domyślny dbo(właściciel bazy danych) bazy danych, a sama baza danych jest obiektem bazy danych .

Z dokumentów SQL Server 2000 ...

dboJest łatwy do zrozumienia, że ma uprawnienia do wykonywania wszelkich czynności w bazie danych.

We wcześniejszych wersjach programu SQL Server, gdy schemat nie mógł „posiadać” obiektu ( a raczej należy stwierdzić, że wszystkie obiekty, tabele, widoki itp. Były własnością dboi nie było innych schematów ), konieczne było „użytkownik”, który jest właścicielem ... powinno być oczywiste, dlaczego coś musi być właścicielem bazy danych (w przeciwnym razie uprawnienia byłyby raczej trudne).

Tak więc technicznie w starszych wersjach programu SQL Server (lub uaktualnionych bazach danych) nie była to tabela „Foo”, ale była to tabela „dbo.Foo”… z tym, dboże jest właścicielem.

Wraz z nadejściem SQL Server 2005 mogłeś mieć obiekty bazy danych będące własnością schematu, takie jak powiedzmy, że masz schemat o nazwie „bar” i tabela o nazwie „Foo” ... to staje się bar.Foojak w ...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

Problem polega na tym, że użytkownik tworzący bazę danych jest automatycznie ustawiany jako właściciel, co prowadzi do problemów z rotacją pracowników itp.

Dlatego najlepszą praktyką jest zmiana tego na sakonto, a może (z mojego doświadczenia) na konto domeny, którym może zarządzać zespół operacyjny / IT organizacji.

W tym artykule przedstawiono różnicę między starszym sposobem robienia rzeczy przez „właściciela” a nowszym systemem własności opartym na schemacie.

Aby zrozumieć różnicę między właścicielami a schematem, poświęćmy trochę czasu na sprawdzenie własności obiektu. Gdy obiekt jest tworzony w SQL Server 2000 lub wcześniejszym, obiekt musi mieć właściciela. Przez większość czasu właścicielem jest „dbo”, znany również jako właściciel bazy danych.