Erweitern des Identitätswechsels bei Datenbanken durch Verwenden von EXECUTE AS

Artikel
12/15/2008

SQL Server 2005 unterstützt die Möglichkeit, die Identität eines anderen Prinzipals anzunehmen, und zwar entweder explizit mithilfe der eigenständigen EXECUTE AS-Anweisung oder implizit mithilfe der EXECUTE AS-Klausel für Module. Die eigenständige EXECUTE AS-Anweisung kann verwendet werden, um mithilfe der EXECUTE AS LOGIN-Anweisung die Identität von Prinzipalen auf der Serverebene oder Anmeldenamen anzunehmen. Die eigenständige EXECUTE AS-Anweisung kann außerdem zum Identitätswechsel von Prinzipalen auf Datenbankebene (d. h. Benutzern) verwendet werden, indem die EXECUTE AS USER-Anweisung ausgeführt wird.

Implizite Identitätswechsel, die mithilfe der EXECUTE AS-Klausel für Module durchgeführt werden, bewirken einen Identitätswechsel des angegebenen Benutzers oder Anmeldenamens auf der Datenbank- oder Serverebene. Dieser Identitätswechsel richtet sich danach, ob es sich bei dem Modul um ein Modul auf der Datenbankebene (z. B. eine gespeicherte Prozedur oder Funktion) oder um ein Modul auf der Serverebene (z. B. um einen Trigger auf der Serverebene) handelt.

Grundlegendes zum Geltungsbereich des Identitätswechsels

Beim Identitätswechsel eines Prinzipals durch Ausführen der EXECUTE AS LOGIN-Anweisung oder in einem Modul des Serverbereichs durch Verwenden der EXECUTE AS-Klausel gilt der Identitätswechsel für den gesamten Server. Das bedeutet, dass nach dem Kontextwechsel der Zugriff auf alle Ressourcen innerhalb des Servers möglich ist, für die der Anmeldename Berechtigungen besitzt, für den der Identitätswechsel erfolgt ist.

Beim Identitätswechsel eines Prinzipals durch Ausführen der EXECUTE AS USER-Anweisung oder in einem Modul des Serverbereichs durch Verwenden der EXECUTE AS-Klausel gilt der Identitätswechsel jedoch standardmäßig nur für die Datenbank. Das bedeutet, dass Verweise auf Objekte außerhalb des Datenbankbereichs zur Rückgabe eines Fehlers führen. Um den Grund für dieses Standardverhalten zu verstehen, nehmen wir das folgende Szenario als Beispiel.

Es ist möglich, dass der Besitzer einer Datenbank zwar innerhalb der Datenbank über alle Berechtigungen verfügt, außerhalb des Datenbankbereichs jedoch über keinerlei Berechtigungen verfügt. Deshalb gestattet SQL Server dem Datenbankbesitzer keinen Identitätswechsel zu einem anderen Benutzer (und gestattet auch keiner anderen Person den Identitätswechsel zu einem anderen Benutzer), um den Zugriff auf Ressourcen zu ermöglichen, die außerhalb des Geltungsbereichs der Berechtigungen liegen, über die der Datenbankbesitzer aktuell verfügt.

Betrachten Sie z. B. zwei Datenbank in einer Hostingumgebung, wobei jede Datenbank zu einer separaten Besitzerentität gehört. Der Besitzer von Database1 ist Bob, während der Besitzer von Database2 Fred ist. Weder Bob noch Fred möchten dem jeweils anderen Besitzer den Zugriff auf Ressourcen in ihrer jeweiligen Datenbank ermöglichen. Als Besitzer von Database1 kann Bob einen Benutzer für Fred in seiner Datenbank erstellen. Und da er innerhalb der Database 1 über die vollständigen Berechtigungen verfügt, kann Bob auch zur Identität des Benutzers Fred wechseln. Aufgrund der von SQL Server auferlegten Sicherheitseinschränkungen kann Bob im Kontext nach dem Identitätswechsel jedoch nicht auf die Datenbank von Fred zugreifen. Ohne diese Standardeinschränkungen wäre Bob in der Lage, ohne Freds Wissen auf dessen Daten zuzugreifen. Deshalb ist der Geltungsbereich der Identitätswechsel auf Datenbankebene standardmäßig auf die Datenbank beschränkt.

Allerdings kann es in bestimmten Szenarien nützlich sein, den Geltungsbereich des Identitätswechsels selektiv über die Datenbank hinaus erweitern zu können. Das wäre z. B. der Fall, wenn eine Anwendung, die zwei Datenbanken verwendet, den Zugriff auf die eine Datenbank von der anderen Datenbank aus erfordert.

Betrachten Sie z. B. eine Marketinganwendung, die eine gespeicherte Prozedur namens GetSalesProjections in der Marketing-Datenbank aufruft, und die gespeicherte Prozedur enthält in ihrer Definition einen Wechsel des Ausführungskontexts. Die gespeicherte Prozedur führt einen Aufruf in der Sales-Datenbank durch, um Verkaufszahlen aus der SalesStats-Tabelle abzurufen. Standardmäßig würde dieses Szenario nicht funktionieren, weil ein Ausführungskontext, der innerhalb einer Datenbank eingerichtet wurde, nicht außerhalb dieser Datenbank gilt. Allerdings möchten die Entwickler der Marketinganwendung nicht, dass Benutzer der Marketinganwendung direkten Zugriff auf die Sales-Datenbank oder Berechtigungen für irgendwelche Objekte innerhalb dieser Datenbank haben. Die ideale Lösung wäre das Verwenden der EXECUTE AS-Klausel in der gespeicherten Prozedur, um einem Benutzer mit den erforderlichen Berechtigungen einen Identitätswechsel zum Zugriff auf die Sales-Datenbank zu gestatten. Dies wird jedoch durch die aktuell geltenden Standardeinschränkungen verhindert. Die Frage ist also, wie die Entwickler dieses Problem lösen können.

In SQL Server 2005 können Sie selektiv den Geltungsbereich des innerhalb einer Datenbank eingerichteten Identitätswechsels erweitern, indem ein Vertrauensmodell zwischen den beiden Datenbanken eingerichtet wird. Bevor wir jedoch zur Beschreibung dieses Vertrauensmodells und der selektiven Erweiterung des Geltungsbereichs des Identitätswechsels kommen, müssen Sie mit der Authentifizierung und der Rolle der Authentifikatoren in SQL Server vertraut sein.

Grundlegendes zu Authentifikatoren

Die Authentifizierung ist der Prozess, mit dem ein bestimmter Prinzipal seine Identität gegenüber einem System einrichtet und nachweist. Ein Authentifikator ist eine Entität, welche die Echtheit (d. h. Authentizität) eines bestimmten Prinzipals sicherstellt, den Prinzipal also authentifiziert. Wenn z. B. eine Verbindung mit SQL Server hergestellt wird, wird der Anmeldename, der für diese Verbindung angegeben wird, durch die Instanz von SQL Server authentifiziert.

Betrachten Sie den Fall, wenn ein Benutzer durch Ausführung der EXECUTE AS LOGIN-Anweisung explizit einen Kontextwechsel auf der Serverebene durchführt. Dazu sind Identitätswechselberechtigungen auf der Serverebene erforderlich. Diese Berechtigungen ermöglichen es dem Berechtigten, also dem Aufrufer der EXECUTE AS LOGIN-Anweisung, einen Identitätswechsel für den angegebenen Anmeldenamen überall innerhalb der Instanz von SQL Server durchzuführen. Die Anweisung ermöglicht dem Aufrufer praktisch das Anmelden mit dem Anmeldenamen, dessen Identität der Aufrufer angenommen hat. Der Besitzer der Berechtigungen im Serverebenenbereich ist der sysadmin, der auch der Besitzer der Instanz von SQL Server ist. In diesem Fall des Identitätswechsels auf Serverebene ist der Authentifikator der sysadmin oder die Instanz von SQL Server selbst.

Berücksichtigen Sie jedoch den Fall, in dem aufgrund einer EXECUTE AS USER-Anweisung oder einer EXECUTE AS-Klausel für ein Modul des Serverbereichs ein Kontext eingerichtet wurde. In diesen Fällen werden die Berechtigungen zum Identitätswechsel innerhalb des Datenbankbereichs überprüft. Der Standardwert für den Geltungsbereich der IMPERSONATE-Berechtigungen für Benutzer ist die Datenbank selbst, deren Besitzer der dbo ist. Außerdem ist der Authentifikator dieser Identitätswechsel der Datenbankbesitzer. Darüber hinaus ist es der Datenbankbesitzer, der praktisch die Identität des Benutzers nach dem Identitätswechsel einrichtet und dessen Authentizität sicherstellt. Weil der Datenbankbesitzer die komplette Datenbank besitzt, wird der beim Identitätswechsel angenommene Kontext überall innerhalb dieser speziellen Datenbank als authentisch betrachtet. Außerhalb dieser Datenbank ist der beim Identitätswechsel angenommene Kontext jedoch nicht gültig.

Verwenden von Authentifikatoren

Authentifikatoren werden verwendet, um zu ermitteln, ob ein eingerichteter Kontext innerhalb eines bestimmten Bereichs gültig ist. Häufig ist der Authentifikator entweder der Systemadministrator (SA) oder die Instanz von SQL Server oder bei Datenbanken der dbo. Der Authentifikator ist praktisch der Besitzer des Bereichs, in dem der Kontext für einen bestimmten Benutzer oder Anmeldenamen eingerichtet wird. Diese Authentifikatorinformationen sind in den Tokeninformationen enthalten, die für den Anmeldenamen und Benutzer gespeichert sind, und sind über die sys.user_token- und sys.login_token-Sichten sichtbar. Weitere Informationen finden Sie unter Grundlegendes zum Ausführungskontext.

Hinweis:
Wenn in der Tokensicht keine Authentifikatorinformationen zurückgegeben werden, ist die Instanz von SQL Server der Authentifikator. Das gilt, wenn es keinen Kontextwechsel gibt oder wenn der Identitätswechsel auf der Serverebene erfolgt.

Ein Ausführungskontext, dessen Authentifikator der Besitzer eines Bereichs ist, ist über diesen gesamten Bereich gültig. Das liegt daran, dass der Besitzer eines Bereichs, z. B. einer Datenbank, implizit von allen Entitäten innerhalb des Bereichs als vertrauenswürdig angesehen wird. Der Kontext ist auch über andere Bereiche gültig, z. B. in anderen Datenbanken oder in der Instanz von SQL Server selbst, in denen der Authentifikator vertrauenswürdig ist. Daher hängt die Gültigkeit des per Identitätswechsel angenommenen Benutzerkontexts außerhalb des Bereichs der Datenbank davon ab, ob der Authentifikator für den Kontext innerhalb des Zielbereichs vertrauenswürdig ist. Dieses Vertrauen wird eingerichtet, indem der Authentifikator die AUTHENTICATE-Berechtigung erhält, wenn der Zielbereich eine andere Datenbank ist, oder die AUTHENTICATE SERVER-Berechtigung erhält, wenn der Zielbereich eine Instanz von SQL Server ist.

Erweitern des Geltungsbereichs des Identitätswechsels

Um den Geltungsbereich eines Identitätswechsels aus einer Datenbank auf einen Zielbereich, wie z. B. auf eine andere Datenbank oder auf die Instanz von SQL Server, erweitern zu können, müssen die folgenden Bedingungen erfüllt sein.

Der Authentifikator muss im Zielbereich vertrauenswürdig sein.
Die Quelldatenbank muss als vertrauenswürdig gekennzeichnet sein.

Herstellen der Vertrauenswürdigkeit des Authentifikators

Basierend auf dem obigen Beispiel mit den Datenbanken Sales und Marketing zeigt das folgende Beispiel, wie die gespeicherte Prozedur GetSalesProjections in der Marketing-Datenbank auf Daten in der SalesStats-Tabelle der Sales-Datenbank zugreift. Die gespeicherte Prozedur enthält die Klausel EXECUTE AS USER MarketingExec. Der Besitzer der Sales-Datenbank ist SalesDBO, und der Besitzer der Marketing-Datenbank ist MarketingDBO.

EXECUTE AS wechselt den Ausführungskontext eines Moduls

Wenn die gespeicherte Prozedur GetSalesProjections durch einen Benutzer aufgerufen wird, bewirkt die EXECUTE AS-Klausel einen impliziten Wechsel des Ausführungskontexts der gespeicherten Prozedur, und zwar vom aufrufenden Benutzer zum MarketingExec-Benutzer. Der Authentifikator dieses Kontexts ist MarketingDBO, der Besitzer der Marketing-Datenbank. Standardmäßig kann diese Prozedur auf alle Ressourcen innerhalb der Marketing-Datenbank zugreifen, für die der MarketingExec-Benutzer zugriffsberechtigt ist. Um jedoch auf eine Tabelle in der Sales-Datenbank zuzugreifen, muss die Sales-Datenbank den Authentifikator MarketingDBO als vertrauenswürdig einstufen.

Das erfolgt, indem Sie in der Sales-Datenbank einen Benutzer namens MarketingDBO erstellen, der dem MarketingDBO-Anmeldenamen zugeordnet ist, und anschließend diesem Benutzer die AUTHENTICATE-Berechtigung für die Sales-Datenbank erteilen. Dadurch wird jeder Ausführungskontext, dessen Authentifikator der Inhaber dieser Berechtigung ist, innerhalb der Datenbank gültig. Da der Authentifikator MarketingDBO über die AUTHENTICATE-Berechtigung in der Sales-Datenbank verfügt, gilt der Kontext, der für den Benutzer MarketingExec durch die EXECUTE AS-Klausel der in der Marketing-Datenbank gespeicherten Prozedur GetSalesProjections erstellt wird, in der Sales-Datenbank als vertrauenswürdig.

Während dieses Beispiel das Erweitern des Geltungsbereichs des Identitätswechsels beschreibt, um den Zugriff auf ein Objekt in einer externen Datenbank zu ermöglichen, ist es auch möglich, den Geltungsbereich des Identitätswechsels auf die Instanz von SQL Server zu erweitern. Wenn z. B. die Prozedur zum Erstellen eines Anmeldenamens führen würde, wobei es sich um eine Aktion auf Serverebene handelt, die eine serverweite Berechtigung erfordert, müsste dem Authentifikator des Kontexts die AUTHENTICATE SERVER-Berechtigung erteilt werden. Semantisch bedeutet das, dass jeder Kontext, dessen Authentifikator der Inhaber der AUTHENTICATE SERVER-Berechtigung ist, in der gesamten Instanz von SQL Server als vertrauenswürdig gilt, als würde sich der Kontext direkt an der Instanz von SQL Server anmelden.

Herstellen der Vertrauenswürdigkeit der Datenbank

In SQL Server 2005 geht das Vertrauensmodell einen Schritt weiter, um zusätzliche Sicherheit und eine erhöhte Granularität im Zusammenhang mit dem Erweitern des Geltungsbereichs des Identitätswechsels auf Datenbankebene bereitzustellen. Sie können einerseits die AUTHENTICATE-Berechtigung verwenden, um den Authentifikator eines Kontexts im Zielbereich als vertrauenswürdig anzuerkennen, Sie können aber auch bestimmen, dass die Instanz von SQL Server die Quelldatenbank und die darin enthaltenen Inhalte als vertrauenswürdig gelten.

Um dies zu veranschaulichen, nehmen wir an, dass der Prinzipal MarketingDBO Besitzer einer weiteren Datenbank namens Conference ist. Außerdem nehmen wir an, dass der MarketingDBO möchte, dass die Ausführungskontexte, die innerhalb der Marketing-Datenbank angegeben sind, Zugriff auf die Ressourcen in der Sales-Datenbank hat. Allerdings soll keiner der Kontexte, die in der Conference-Datenbank eingerichtet sind, Zugriff auf die Sales-Datenbank erhalten.

Um diese Anforderung zu erfüllen, muss die Datenbank, die das Modul enthält, in dem ein Identitätswechselkontext zum Zugriff auf Ressourcen außerhalb der Datenbank verwendet wird, als vertrauenswürdig gekennzeichnet sein. Die TRUSTWORTHY-Eigenschaft gibt an, ob die Instanz von SQL Server die Datenbank und die darin enthaltenen Inhalte als vertrauenswürdig einstuft. Die TRUSTWORTHY-Eigenschaft hat zwei Aufgaben:

Sie verringert das Risiko im Zusammenhang mit Datenbanken, die an die Instanz von SQL Server angefügt sind und möglicherweise böswillige Module enthalten, die so definiert wurden, dass sie im Kontext eines Benutzers mit einer höhere Privilegstufe ausgeführt werden.
Das wird erreicht, indem sichergestellt wird, dass angefügte Datenbanken nicht standardmäßig als vertrauenswürdig gekennzeichnet werden. Es wird auch erreicht, indem sichergestellt wird, dass der Zugriff auf Ressourcen außerhalb der Datenbank durch potenziell bösartige Module voraussetzt, dass die Datenbank als vertrauenswürdig gekennzeichnet ist. Das Festlegen der TRUSTWORTHY-Eigenschaft einer Datenbank ist auf Mitglieder der festen Serverrolle sysadmin beschränkt.
Damit kann der Administrator der Instanz von SQL Server unterscheiden zwischen Datenbanken, denen der Zugriff auf externe Ressourcen gestattet werden soll, und solchen Datenbanken, die diesen Zugriff nicht erhalten sollen, wenn die Datenbanken denselben Besitzer haben und dieser Besitzer als Authentifikator in einem gewissen Bereich vertrauenswürdig ist.

Dieses Verhalten kann durch Verwenden der TRUSTWORTHY-Eigenschaft gesteuert werden. Nehmen wir beispielsweise an, dass durch Identitätswechsel angenommene Kontexte aus einer Datenbank (Database 1) als vertrauenswürdig gelten sollen, während die Kontexte aus einer anderen Datenbank (Database 2) nicht als vertrauenswürdig gelten sollen, und beide Datenbanken denselben Besitzer haben, der als Authentifikator im Zielbereich vertrauenswürdig ist. Die TRUSTWORTHY-Eigenschaft kann für Database 1 auf ON und für Database 2 auf OFF gesetzt werden, um sicherzustellen, dass Module in Database 2 keinen Zugriff auf Ressourcen außerhalb dieser Datenbank erhalten.

Das folgende Beispiel veranschaulicht die Verwendung der TRUSTWORTHY-Datenbankeigenschaft zum Steuern des Zugriffs auf Ressourcen außerhalb des Bereichs der Quelldatenbank. MarketingDBO erhält AUTHENTICATE-Berechtigungen in der Sales-Datenbank und ist der Besitzer der beiden Datenbanken Marketing und Conference. Die in der Marketing-Datenbank gespeicherte Prozedur GetSalesProjections kann erfolgreich auf die Sales-Datenbank zugreifen, weil sie die beiden Sicherheitsanforderungen erfüllt: Der Authentifikator (MarketingDBO) ist im Zielbereich vertrauenswürdig, und die Quelldatenbank (Marketing) ist ebenfalls vertrauenswürdig. Versuche zum Zugriff auf die Sales-Datenbank von der Conference-Datenbank aus werden zurückgewiesen, weil nur eine Anforderung erfüllt ist: Der Authentifikator (MarketingDBO) ist im Zielbereich vertrauenswürdig.

Steuern von Datenbankzugriff auf externe Ressourcen

Immer wenn versucht wird, durch Verwenden eines durch Identitätswechsel übernommenen Kontexts auf eine Ressource außerhalb des Bereichs der Datenbank zuzugreifen, überprüft die Instanz von SQL Server, ob die Datenbank, aus der die Anforderung stammt, vertrauenswürdig ist und ob der Authentifikator vertrauenswürdig ist.

Zertifikate und asymmetrische Schlüssel als Authentifikatoren

Ein innerhalb einer Datenbank eingerichteter Identitätswechselkontext kann für den Zugriff auf Ressourcen außerhalb des Bereichs der Datenbank erweitert werden, indem der Datenbankbesitzer als Authentifikator verwendet wird. Das setzt voraus, dass der Datenbankbesitzer von der externen Ressource als vertrauenswürdig eingestuft wird und dass die Datenbank selbst ebenfalls vertrauenswürdig ist. Allerdings impliziert dieses Konzept, dass in dem Fall, dass ein vertrauenswürdiger Datenbankbesitzer die AUTHENTICATE- oder AUTHENTICATE SERVER-Berechtigungen im Zielbereich besitzt und die aufrufende Datenbank vertrauenswürdig ist, alle in dieser Datenbank eingerichteten Identitätswechselkontexte im gesamten Zielbereich gültig sind, in dem der Datenbankbesitzer als vertrauenswürdig gilt.

Daher kann eine genauere Granularität der Vertrauenswürdigkeit erforderlich sein. Angenommen, die Geschäftsanforderung gibt vor, nur einige wenige Module in der Quelldatenbank als vertrauenswürdig einzustufen, indem die EXECUTE AS-Klausel zum Zugriff auf die Zielressource verwendet wird und nicht die gesamte Quelldatenbank als vertrauenswürdig eingestuft wird. Nehmen wir z. B. an, der SalesDBO möchte sicherstellen, dass nur die gespeicherte Prozedur GetSalesProjections als der MarketingExec-Benutzer auf die SalesStats-Tabelle zugreifen darf. Er möchte jedoch nicht, dass jeder Benutzer in der Marketing-Datenbank mit Identitätswechselberechtigungen für MarketingExec in der Lage sein soll, auf die Ressourcen in der Sales-Datenbank zuzugreifen. Durch Erklärung der Vertrauenswürdigkeit von MarketingDBO und Einstufung der Marketing-Datenbank als vertrauenswürdig könnte diese Aufgabe nicht erfüllt werden. Um zur Erfüllung dieser Anforderung eine zusätzliche Granularitätsstufe bereitzustellen, ermöglicht das Vertrauensmodell die Verwendung von Zertifikaten oder asymmetrischen Schlüsseln als Authentifikatoren. Damit wird eine Technik genutzt, die als Signierung bezeichnet wird. Weitere Informationen zur Signierung finden Sie unter ADD SIGNATURE (Transact-SQL).

Verwenden von Signaturen

Durch Signaturen für ein Modul wird sichergestellt, dass Änderungen am Code innerhalb eines Moduls nur durch eine Person möglich ist, die Zugriff auf den privaten Schlüssel hat, der zum Signieren des Moduls verwendet wurde. Angesichts der Garantien des Signierungsprozesses können Sie das Zertifikat oder den asymmetrischen Schlüssel, das bzw. der in der Signatur angegeben ist, als vertrauenswürdig betrachten. Genauer gesagt betrachten Sie damit nicht den Datenbankbesitzer als vertrauenswürdig, sondern den Besitzer des Zertifikats oder des asymmetrischen Schlüssels.

Die Vertrauenswürdigkeit des signierten Moduls wird erreicht, indem der Benutzer im Zielbereich, der dem Zertifikat oder dem asymmetrischen Schlüssel zugeordnet ist, die AUTHENTICATE- oder AUTHENTICATE SERVER-Berechtigung erhält.

Mit diesem Konzept wird ein Ausführungskontext, der innerhalb eines Moduls eingerichtet wird, das durch Verwenden eines vertrauenswürdigen Zertifikats signiert wird, im Zielbereich gültig, in dem das Zertifikat als vertrauenswürdig gilt.

Nehmen wir z. B. an, dass die Prozedur GetSalesProjections durch Verwenden eines Zertifikats namens C1 signiert wurde. Zertifikat C1 muss in der Sales-Datenbank vorhanden sein, und ein Benutzer, z. B. CertUser1, muss dem Zertifikat C1 zugeordnet sein. CertUser1 erhält dann AUTHENTICATE-Berechtigungen in der Sales-Datenbank.

Wird die Prozedur aufgerufen, erfolgt eine Prüfung ihrer Signatur, um sicherzustellen, dass bei der Signierung keine Manipulation erfolgte. Wenn die Signatur bestätigt wird, hat der durch die EXECUTE AS-Klausel im Modul eingerichtete Kontext das Zertifikat C1 als seinen Authentifikator. Wenn die Signatur nicht bestätigt wird, wird der Authentifikator nicht zum Token hinzugefügt, und der Versuch zum Zugriff auf die externe Ressource erzeugt einen Fehler.

Das folgende Beispiel veranschaulicht die Verwendung eines signierten Moduls zum Steuern des Zugriffs auf Ressourcen außerhalb des Bereichs der Quelldatenbank. Die Prozedur GetSalesProjections in der Marketing-Datenbank ist durch Verwendung eines Zertifikats namens C1 signiert. Zertifikat C1 ist in der Sales-Datenbank vorhanden, und Benutzer CertUser ist dem Zertifikat zugeordnet. CertUser1 erhält AUTHENTICATE-Berechtigungen in der Sales-Datenbank.

Zertifikat zum Einschränken des Datenbankzugriffs

Die Vertrauenswürdigkeit dieses Authentifikators wird in gleicher Weise überprüft, als wäre der Datenbankbesitzer der Authentifikator. Das heißt, die Überprüfung erfolgt durch Prüfung der AUTHENTICATE SERVER- oder AUTHENTICATE-Berechtigung. Da jedoch die Vertrauenswürdigkeit auf einer genaueren Granularitätsstufe eingerichtet wurde und Änderungen des Moduls nicht ohne Änderungen der Signatur vorgenommen werden können, besteht keine Notwendigkeit, die TRUSTWORTHY-Eigenschaft der Datenbank zu prüfen.

Damit wird das Risiko verringert, das sich aus angefügten Datenbanken ergibt, die potenziell böswilligen Code enthalten. Der Angreifer müsste das Modul mit dem privaten Schlüssel signieren, der dem bereits als vertrauenswürdig eingestuften Zertifikat entspricht. Der Angreifer hat jedoch keinen Zugriff auf diesen Schlüssel. Bei Änderungen an einem vorhandenen vertrauenswürdigen Modul oder beim Erstellen eines neuen Moduls wäre dann außerdem keine gültige vertrauenswürdige Signatur vorhanden.

Weitere Informationen finden Sie unter Modulsignierung.

Regeln für das Erweitern des Geltungsbereichs für Datenbankidentitätswechsel

Zusammenfassend gilt: Der Geltungsbereich für Identitätswechsel eines innerhalb einer Datenbank eingerichteten Kontexts kann nur dann auf andere Bereiche erweitert werden, wenn folgende Aussagen zutreffen:

Der Authentifikator (entweder der Datenbankbesitzer oder ein zur Signierung des Moduls verwendetes Zertifikat oder asymmetrischer Schlüssel) muss im Zielbereich als vertrauenswürdig gelten. Das erreichen Sie, indem Sie dem Prinzipal, der dem Datenbankbesitzer, dem Zertifikat oder dem asymmetrischen Schlüssel zugeordnet ist, die AUTHENTICATE- oder AUTHENTICATE SERVER-Berechtigung erteilen.
Wenn der Authentifikator der Datenbankbesitzer ist, muss die Quelldatenbank als vertrauenswürdig gekennzeichnet sein. Das erreichen Sie, indem Sie die TRUSTWORTHY-Eigenschaft der Datenbank auf ON setzen.

Auswählen des geeigneten Mechanismus zur Herstellung der Vertrauenswürdigkeit

Sowohl das Konzept mit Verwendung des Datenbankbesitzers als auch das Konzept mit Verwendung der Signatur weisen Vor- und Nachteile auf. Welcher der beiden Mechanismen für Ihren Bedarf geeignet ist, richtet sich nach Ihren Geschäftsanforderungen und nach Ihrer Geschäftsumgebung.

Datenbankbesitzerkonzept

Das Konzept mithilfe des Datenbankbesitzers zur Herstellung der Vertrauenswürdigkeit weist die folgenden Vor- und Nachteile auf:

Es setzt keinerlei Vorkenntnisse von Verschlüsselungskonzepten wie Zertifikaten oder Signaturen voraus.
Es bietet nicht dasselbe Ausmaß an Granularität wie das Signaturkonzept.
Beim Anfügen einer Datenbank an eine Instanz von SQL Server wird die TRUSTWORTHY-Eigenschaft der Datenbank auf OFF gesetzt. Die vom Datenbankbesitzer als vertrauenswürdig eingestuften Module werden erst dann gültig, wenn der Systemadministrator die TRUSTWORTHY-Eigenschaft explizit auf ON setzt. Das bedeutet, dass möglicherweise erst ein Eingreifen durch den Systemadministrator erforderlich ist, bevor die angefügte Datenbank wie gewünscht funktioniert und auf andere Datenbanken zugreifen kann.

Signaturkonzept

Das Konzept mithilfe der Signatur zur Herstellung der Vertrauenswürdigkeit weist die folgenden Vor- und Nachteile auf:

Sie ermöglicht eine feinere Granularitätsstufe in Bezug auf die Herstellung der Vertrauenswürdigkeit, gilt jedoch nur für Kontextwechsel, die innerhalb von signierten Modulen durchgeführt werden.
Die Signatur kann nicht für Kontextwechsel verwendet werden, die durch die eigenständigen Anweisungen EXECUTE AS USER und EXECUTE AS LOGIN erzielt werden. Bei diesen Anweisungen kann die Vertrauenswürdigkeit nur durch Verwendung des Datenbankbesitzerkonzepts erweitert werden.
Es ist dem Hersteller oder Entwickler der Anwendung möglich, das Modul zwar mit einem privaten Schlüssel zu signieren, diesen privaten Schlüssel jedoch vor der Auslieferung der Module oder der Datenbank zu entfernen. Das ist möglich, weil die privaten Schlüssel lediglich zum Signieren der Module verwendet werden. Zu Zwecken der Signaturprüfung sind die öffentlichen Schlüssel ausreichend, die dem Modul zugewiesen sind.
Das Anfügen einer Datenbank hat keinerlei Auswirkungen auf Module, die aufgrund ihrer Signaturen als vertrauenswürdig gelten. Sie funktionieren, ohne dass dazu weitere Schritte unternommen werden müssen.

Siehe auch

Freigeben über