Besitzketten
Wenn mehrere Datenbankobjekte aufeinander sequenziell zugreifen, wird diese Sequenz als Kette bezeichnet. Obwohl solche Ketten nicht unabhängig voneinander vorhanden sind, werden in SQL Server beim Traversieren der Verknüpfungen in einer Kette durch SQL Server die Berechtigungen für die einzelnen Objekte anders ausgewertet als beim getrennten Zugriff auf die Objekte. Diese Unterschiede haben nachhaltige Auswirkungen auf die Sicherheitsverwaltung.
Besitzketten ermöglichen die Verwaltung des Zugriffs auf mehrere Objekte, z. B. mehrere Tabellen, indem Berechtigungen für ein Objekt, z. B. eine Sicht, festgelegt werden. Besitzketten bieten auch einen Leistungsvorteil in Situationen, in denen Berechtigungsprüfungen ausgelassen werden können.
Prüfen von Berechtigungen in einer Kette
Wenn auf ein Objekt über eine Kette zugegriffen wird, wird von SQL Server zunächst der Besitzer des Objekts mit dem Besitzer des aufrufenden Objekts verglichen. Dabei handelt es sich um die vorherige Verknüpfung in der Kette. Wenn beide Objekte denselben Besitzer aufweisen, werden die Berechtigungen für das Objekt, auf das verwiesen wird, nicht ausgewertet.
Beispiel einer Besitzverkettung
In der folgenden Abbildung ist Mary die Besitzerin der Sicht July2003. Sie hat Alex Berechtigungen für die Sicht erteilt. Er hat in dieser Instanz keine weiteren Berechtigungen für die Datenbankobjekte. Was geschieht, wenn Alex die Sicht auswählt?
Alex führt für die Sicht July2003 SELECT * aus. Die Berechtigungen für die Sicht werden von SQL Server geprüft, und es wird bestätigt, dass Alex über Berechtigungen für ihre Auswahl verfügt.
Die Sicht July2003 benötigt Informationen von der Sicht SalesXZ. Der Besitz der Sicht SalesXZ wird von SQL Server geprüft. Da diese Sicht denselben Besitzer (Mary) wie die Sicht hat, von der sie aufgerufen wird, werden die Berechtigungen für SalesXZ nicht geprüft. Die erforderlichen Informationen werden zurückgegeben.
Die Sicht SalesXZ benötigt Informationen von der Sicht InvoicesXZ. Der Besitz der Sicht InvoicesXZ wird von SQL Server geprüft. Da diese Sicht denselben Besitzer aufweist wie das vorherige Objekt, werden die Berechtigungen für InvoicesXZ nicht geprüft. Die erforderlichen Informationen werden zurückgegeben. Bis zu diesem Punkt hatten alle Elemente der Sequenz einen Besitzer (nämlich Mary). Dies wird als fortlaufende Besitzkette bezeichnet.
Die Sicht InvoicesXZ benötigt Informationen von der Sicht AcctAgeXZ. Der Besitz der Sicht AcctAgeXZ wird von SQL Server geprüft. Da sich der Besitzer dieser Sicht vom Besitzer des vorherigen Objekts unterscheidet (Sam, nicht Mary), werden die vollständigen Informationen über die Berechtigungen für diese Sicht abgerufen. Wenn die Sicht AcctAgeXZ Berechtigungen aufweist, die einen Zugriff von Alex ermöglichen, werden die Informationen zurückgegeben.
Die Sicht AcctAgeXZ benötigt Informationen aus der Tabelle ExpenseXZ. Der Besitz der Tabelle ExpenseXZ wird von SQL Server geprüft. Da sich der Besitzer dieser Tabelle vom Besitzer des vorherigen Objekts unterscheidet (Joe, nicht Sam), werden die vollständigen Informationen über die Berechtigungen für diese Tabelle abgerufen. Wenn die Tabelle ExpenseXZ Berechtigungen aufweist, die einen Zugriff von Alex ermöglichen, werden die Informationen zurückgegeben.
Wenn die Sicht July2003 versucht, Informationen aus der Tabelle ProjectionsXZ abzurufen, wird vom Server zunächst geprüft, ob die datenbankübergreifende Verkettung zwischen Datenbank 1 und Datenbank 2 aktiviert ist. Falls die datenbankübergreifende Verkettung aktiviert ist, prüft der Server den Besitz der Tabelle ProjectionsXZ. Da diese Tabelle denselben Besitzer hat wie die aufrufende Sicht (nämlich Mary), werden die Berechtigungen für diese Tabelle nicht geprüft. Die angeforderten Informationen werden zurückgegeben.
Datenbankübergreifende Besitzverkettung
SQL Server kann so konfiguriert werden, dass eine Besitzverkettung zwischen bestimmten Datenbanken oder über alle Datenbanken hinweg innerhalb einer einzelnen Instanz von SQL Server möglich ist. Die datenbankübergreifende Besitzverkettung ist standardmäßig deaktiviert und sollte auch nur aktiviert werden, wenn dies dringend erforderlich ist.
Mögliche Bedrohungen
Die Besitzverkettung ist besonders nützlich für die Verwaltung von Datenbankberechtigungen, es wird jedoch vorausgesetzt, dass sich die Objektbesitzer der vollen Konsequenzen jeder Entscheidung bewusst sind, eine Berechtigung für ein sicherungsfähiges Element zu erteilen. In der vorherigen Abbildung besitzt Mary die meisten zugrunde liegenden Objekte der Sicht July 2003. Mary verfügt über das Recht, den Zugriff auf Objekte, deren Besitzer sie ist, für jeden anderen Benutzer zu erteilen. Daher verhält sich SQL Server so, als ob Mary beim Erteilen des Zugriffs auf die erste Sicht in einer Kette eine bewusste Entscheidung getroffen hätte, die Sichten und die Tabelle freizugeben, auf die verwiesen wird. Diese Annahme ist jedoch möglicherweise nicht zutreffend. Produktionsdatenbanken sind weitaus komplexer als die in der Abbildung, und die Berechtigungen, die den Zugriff darauf steuern, passen selten zu den Verwaltungsstrukturen der Organisationen, in denen sie verwendet werden.
Ihnen sollte klar sein, dass die Mitglieder von Datenbankrollen mit sehr hohen Berechtigungen die datenbankübergreifende Besitzverkettung für den Zugriff auf Objekte in Datenbanken außerhalb ihrer eigenen verwenden können. Wenn z. B. die datenbankübergreifende Verkettung zwischen Datenbank A und Datenbank B aktiviert ist, kann sich ein Mitglied der festen Datenbankrolle db_owner einer der Datenbanken unzulässigerweise seinen Weg in die jeweils andere Datenbank bahnen. Der Prozess ist einfach: Diane (ein Element von db_owner in Datenbank A) erstellt in Datenbank A den Benutzer Stuart. Der Benutzer Stuart ist jedoch bereits als Benutzer in Datenbank B vorhanden. Diane erstellt dann in Datenbank A ein Objekt (mit dem Besitzer Stuart), das ein Objekt aufruft, das im Besitz von Stuart in Datenbank B ist. Da das aufrufende und das aufgerufene Objekt über einen gemeinsamen Besitzer verfügen, werden Berechtigungen für das Objekt in Datenbank B nicht überprüft, wenn Diane darauf über das von ihr erstellte Objekt zugreift.