it-swarm.com.de

Was ist der Zweck des Datenbankbesitzers?

Bei der Fehlerbehebung bei einem Service Broker-Problem stellte ich heute fest, dass der Datenbankeigentümer das Windows-Login eines Mitarbeiters war, der das Unternehmen verlassen hatte. Sein Login wurde entfernt und daher schlugen die Abfragemeldungen fehl.

Angeblich besteht die beste Vorgehensweise darin, 'sa' zum Datenbankbesitzer zu machen. Wir haben es geändert und das hat die Warteschlange geräumt.

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

53
8kb

Es gibt einige Verwechslungen zwischen den Datenbankkonzepten von 'dbo' (ein Benutzer) und 'db_owner' (eine feste Rolle) auf der einen Seite und dem Instanzkonzept von 'Datenbankbesitzer' auf der anderen Seite. Die 'dbo' und 'db_owner' werden oft als 'Datenbankbesitzer' bezeichnet. In dem, was Sie fragen, sprechen Sie über den Datenbankeigentümer als den Serverprinzipal, dem die Datenbank gehört.

Die Theorie lautet wie folgt: Alles, für das Berechtigungen erteilt werden können, ist ein 'sicherbar' . Alle Wertpapiere haben einen Eigentümer. Der Eigentümer eines Securable hat die absolute Kontrolle über das Securable und kann kein Privileg verweigern. Securables auf Instanzebene gehören dem Server Principals (Logins). Securables auf Datenbankebene gehören Datenbank-Principals (Benutzern). Principal gibt es in zwei Varianten: primär (Identität) und sekundär (Mitgliedschaft). Securables auf Serverebene gehören standardmäßig dem aktuell protokollierten primären Serverprinzipal. Securables auf Datenbankebene gehören standardmäßig dem aktuellen Datenbankprinzipal, mit Ausnahme von schemagebundenen Objekten, die standardmäßig dem Schemabesitzer gehören. Alle Securables unterstützen die AUTHORIZATION-Klausel beim Erstellen, um einen anderen Eigentümer durchzusetzen. ALTER AUTHORIZATION kann später verwendet werden, um den Besitzer eines sicheren Objekts zu ändern.

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

Ihre Frage lautet also wirklich " Warum brauchen Securables einen Eigentümer? ". Weil der Eigentümer die Wurzel des Vertrauens ist. Es ist der Eigentümer, der die Berechtigung für das Objekt erteilt, verweigert und widerruft. Kann ein Sicherheitssystem ohne Eigentümer von Sicherheiten entworfen werden? Wahrscheinlich ja, aber es müsste einen Mechanismus geben, der die Rolle der Eigentümer im aktuellen Modell ersetzt. Nehmen wir zum Beispiel an, dass Papa-Securables keinen Eigentümer haben (z. B. anstatt ein Securable zu besitzen, erhält der ursprüngliche Ersteller nur die KONTROLLE darüber), wäre es möglich, ein Securable zu erstellen und den Zugriff darauf zu widerrufen jeder , auch er selbst. Das Erfordernis eines Eigentümers umgeht dieses Problem, da sich ein Eigentümer nicht aussperren kann.

Der wenig bekannte Nebeneffekt von CREATE DATABASE beim Erstellen einer sicheren Datenbank (der Datenbank), die dem ursprünglichen NT-Login gehört, hat schon viele Male gebrannt. Die Regeln sind für alle Sicherheiten gleich, aber einige Faktoren verschlimmern die Probleme des DATABASE-Besitzers:

  • die anderen Secure-Dateien auf Serverebene (Endpunkt, Serverrolle, Anmeldung) werden weitaus selten verwendet, verschoben usw.
  • securables auf Datenbankebene gehören normalerweise dbo (dem Datenbankprinzipal) oder einem anderen Datenbankprinzipal, und daher ist der Eigentümer in der Datenbank enthalten
  • Wenn der Datenbankbesitz standardmäßig auf den primären NT-Principal festgelegt ist, entsteht ein Eindämmungsproblem (der Eigentümer ist eine von AD verwaltete NT-SID und wird nicht mit den Datenbankdateien übertragen. Das NT-Konto kann mit einem Daumen versehen werden usw. usw. usw.)
  • das Wichtigste: Der Datenbankbesitzer hat wichtige Nebenwirkungen, insbesondere das EXECUTE AS context . Dieses spätere Problem brennt die meisten Benutzer. Da Service Broker EXECUTE AS in großem Umfang verwendet (die Nachrichtenübermittlung hat einen impliziten EXECUTE AS-Kontext sowie eine explizite Warteschlangenaktivierung), sind es normalerweise Service Broker-Benutzer, die dieses Problem zuerst entdecken.

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

59
Remus Rusanu

Die Datenbank owner ist ein kleiner Rückschritt zu einer Zeit, bevor (richtige) Schemas in SQL Server 2005 eingeführt wurden.

Grundsätzlich ist ein Datenbankbesitzer der Standard dbo (Datenbankeigentümer) der Datenbank, wobei die Datenbank selbst ein Datenbankobjekt .

Aus dem SQL Server 20 docs ...

Das dbo ist ein Benutzer, der Berechtigungen zum Ausführen aller Aktivitäten in der Datenbank impliziert hat.

In früheren Versionen von SQL Server, in denen ein Schema kein Objekt "besitzen" konnte ( oder besser gesagt, es sollte angegeben werden, dass alle Objekte, Tabellen, Ansichten usw. Eigentum von dbo und dort waren waren keine anderen Schemata) es war notwendig, dass ein "Benutzer" es besaß ... es sollte selbstverständlich sein, warum etwas die Datenbank besitzen muss (oder Berechtigungen in allgemein wäre ziemlich schwierig.)

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

Mit dem Aufkommen von SQL Server 2005 könnten Sie schemaeigene Datenbankobjekte haben, z. B. ein Schema mit dem Namen "bar" und eine Tabelle mit dem Namen "Foo" ... dies wird zu bar.Foo wie in ...

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

Der schwierige Teil kommt mit der Tatsache, dass der Benutzer Erstellen die Datenbank automatisch als Eigentümer festgelegt wird, was dazu führt Probleme mit Mitarbeiterumsatz usw.

Daher ist es empfehlenswert, dies entweder in das Konto sa oder (meiner Erfahrung nach) in ein Domänenkonto zu ändern, das vom Ops/IT-Team eines Unternehmens verwaltet werden kann.

Dieser Artikel gibt einen Überblick über den Unterschied zwischen der älteren "Eigentümer" -Methode und dem neueren "Schema" -basierten Besitzersystem.

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

14
Justin Jenkins