Was ist der Zweck des Datenbankbesitzers?

Bei der Behebung eines Service Broker-Problems stellte ich heute fest, dass der Datenbankeigentümer die Windows-Anmeldung eines Mitarbeiters war, der das Unternehmen verlassen hatte. Sein Login wurde entfernt und die Abfragebenachrichtigungen schlugen fehl.

Angeblich besteht die beste Vorgehensweise darin, "sa" zum Datenbankeigentümer zu machen. Wir haben es geändert und das hat die Warteschlange ausgeräumt.

Meine (sehr elementare) Frage: Was ist der Datenbankbesitzer und wozu dient er?

Es gibt einige Verwechslungen zwischen den Datenbankkonzepten 'dbo' (ein Benutzer) und 'db_owner' (eine feste Rolle) auf der einen Seite und dem Instanzkonzept 'Datenbankeigentümer' auf der anderen Seite. 'Dbo' und 'db_owner' werden häufig als 'Datenbankbesitzer' bezeichnet. In Ihrer Frage geht es um den Datenbankeigentümer als Serverprinzipal, dem die Datenbank gehört.

Die Theorie lautet wie folgt : Alles, wofür Berechtigungen erteilt werden können, ist "sicherbar" . Alle Sicherheiten haben einen Besitzer. Der Eigentümer eines Sicherungsgegenstands hat die absolute Kontrolle über den Sicherungsgegenstand und kann kein Privileg verweigern. Sicherheitselemente auf Instanzebene gehören Server- Principals (Logins). Sicherungen auf Datenbankebene gehören Datenbank-Principals (Benutzern). Prinzipal gibt es in zwei Varianten: primär (Identität) und sekundär (Mitgliedschaft). Secureables auf Serverebene gehören standardmäßig dem derzeit protokollierten primären Serverprinzipal. Sicherungen auf Datenbankebene gehören standardmäßig dem aktuellen Datenbankprinzipal, mit Ausnahme von schemagebundenen Objekten, die standardmäßig dem Schemabesitzer gehören. Alle Sicherheitselemente unterstützen die AUTHORIZATION-Klausel zum Zeitpunkt der Erstellung, um einen anderen Eigentümer zu erzwingen.ALTER AUTHORIZATION kann später verwendet werden, um den Eigentümer eines zu sichernden Objekts zu ändern.

Da die Datenbank auf Serverebene sicherbar ist, gehört sie standardmäßig dem primären Prinzipal, der die Anweisung CREATE DATABASE ausgegeben hat. Dh das NT-Login des verstorbenen Mitarbeiters.

Ihre Frage lautet also wirklich " Warum brauchen Wertpapierbesitzer einen Besitzer? ". Weil der Eigentümer die Wurzel des Vertrauens ist. Der Eigentümer erteilt, verweigert und widerruft die Berechtigung für das Objekt. Kann ein Sicherheitssystem ohne Eigentümer von Wertsachen entworfen werden? Wahrscheinlich ja, aber es müsste einen Mechanismus geben, der die Rolle der Eigentümer im aktuellen Modell ersetzt. Stellen Sie sich zum Beispiel vor, dass Papas Sicherheitselemente keinen Eigentümer haben (statt eines Sicherheitselements hat der ursprüngliche Ersteller lediglich die KONTROLLE darüber), wäre es möglich, ein Sicherheitselement zu erstellen und allen , einschließlich sich selbst, den Zugriff darauf zu entziehen . Die Anforderung eines Eigentümers umgeht dieses Problem, da sich ein Eigentümer nicht selbst aussperren kann.

Der wenig bekannte Nebeneffekt von CREATE DATABASE, eine sichere Datenbank zu erstellen, die dem ursprünglichen NT-Login gehört, hat schon viele Male zuvor gebrannt. Die Regeln sind für alle zu sichernden Elemente gleich, aber einige Faktoren erschweren die Probleme des Besitzers von DATABASE:

• Die anderen Sicherheitselemente auf Serverebene (Endpunkt, Serverrolle, Anmeldung) werden weitestgehend selten verwendet, verschoben usw.
• Sicherungen auf Datenbankebene gehören in der Regel dbo(dem Datenbankprinzipal) oder einem anderen Datenbankprinzipal, und daher ist der Eigentümer in der Datenbank enthalten
• Wenn der NT-Primärprinzipal als Datenbankeigentümer voreingestellt ist, entsteht ein Eindämmungsproblem (der Eigentümer ist eine von AD verwaltete NT-SID und wandert nicht mit den Datenbankdateien, das NT-Konto kann über einen Thumbstone usw. usw. usw. weitergeleitet werden).
• Das Wichtigste: Der Datenbankbesitzer hat wichtige Nebenwirkungen, insbesondere die EXECUTE AS context. Dieses spätere Problem brennt die meisten Benutzer. Da Service Broker EXECUTE AS in großem Umfang nutzt (die Nachrichtenübermittlung hat einen impliziten EXECUTE AS-Kontext sowie eine explizite Warteschlangenaktivierung), stellen Service Broker-Benutzer dieses Problem in der Regel zuerst fest.

Übrigens, ein dickes Lob für die Untersuchung und Behebung Ihres ursprünglichen Problems :)

Die Datenbank ownerist ein kleiner Rückblick auf eine Zeit, bevor (richtige) Schemas in SQL Server 2005 eingeführt wurden.

Im Grunde eine Datenbank Eigentümer ist die Standardeinstellung dbo(Datenbank - Besitzer) der Datenbank, mit der Datenbank selbst eine Wesen Objektdatenbank .

In den SQL Server 2000- Dokumenten ...

Dies dboist ein Benutzer, der Berechtigungen zum Ausführen aller Aktivitäten in der Datenbank impliziert hat.

Wenn ein Schema in früheren Versionen von SQL Server kein Objekt "besitzen" konnte ( oder es sollte angegeben werden, dass alle Objekte, Tabellen, Ansichten usw. Eigentum von waren dbound es keine anderen Schemata gab ), war dies für a erforderlich "user", um es zu besitzen ... es sollte selbstverständlich sein, warum etwas die Datenbank besitzen muss (andernfalls wären Berechtigungen im Allgemeinen ziemlich schwierig.)

Technisch gesehen war es in älteren Versionen von SQL Server (oder aktualisierten Datenbanken) nicht die "Foo" -Tabelle, sondern die "dbo.Foo" -Tabelle ... mit dbodem Eigentümer.

Mit dem Aufkommen von SQL Server 2005 konnten Sie Datenbankobjekte im Schemabesitz haben, beispielsweise ein Schema mit dem Namen "bar" und eine Tabelle mit dem Namen "Foo" ... dies wird bar.Foowie in ...

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

Das Knifflige dabei ist, dass der Benutzer , der die Datenbank erstellt, automatisch als Eigentümer festgelegt wird, was zu Problemen mit der Mitarbeiterumsetzung usw. führt.

Daher ist es empfehlenswert, dies entweder in das saKonto oder (meiner Erfahrung nach) in ein Domänenkonto zu ändern, das vom Operations- / IT-Team einer Organisation verwaltet werden kann.

In diesem Artikel wird der Unterschied zwischen der älteren "Eigentümer" -Methode und dem neueren "Schema" -basierten Eigentümersystem erläutert.

Um den Unterschied zwischen Eigentümern und Schema zu verstehen, nehmen wir uns etwas Zeit, um die Eigentümerschaft des Objekts zu überprüfen. Wenn ein Objekt in SQL Server 2000 oder früher erstellt wird, muss das Objekt einen Besitzer haben. Meistens ist der Eigentümer "dbo", auch als Datenbankeigentümer bekannt.