it-swarm.com.de

Datenbankübergreifende Ansicht - Im aktuellen Sicherheitskontext kann nicht auf die Datenbank zugegriffen werden

Wir haben zwei Datenbanken, Adb und Bdb. In Bdb erstellen wir eine Ansicht, die auf eine andere Ansicht in Adb verweist, wie folgt: CREATE VIEW Bdb.dbo.Bview AS SELECT * FROM Adb.dbo.Aview.

Wir haben ein SQL-authentifiziertes Blogin, das Buser zugeordnet ist, sowohl auf Adb als auch Bdb, mit mindestens dem db_datareader Rolle auf beiden.

Folgendes funktioniert nicht:

USE Bdb;
EXECUTE AS USER = 'Buser';
SELECT * FROM Bdb.dbo.Bview;
SELECT * FROM Adb.dbo.Aview;

Der folgende Fehler wird für beide Auswahlen ausgegeben:

Msg 916, Level 14, State 1, Line 4
The server principal "Buser" is not able to access the database "Adb" under the current security context.

Dies funktioniert jedoch:

USE Adb;
EXECUTE AS USER = 'Buser';
SELECT * FROM Adb.dbo.Aview;
SELECT * FROM Bdb.dbo.Bview;

Ich habe das bemerkt, als ich zum ersten Mal USE Bdb und wechseln Sie zu Buser, ich kann keine anderen Datenbanken sehen:

USE Bdb;
EXECUTE AS USER = 'Buser';
SELECT * FROM sys.databases; -- only master, tempdb and Bdb is shown

Aber wenn ich USE Adb Zuerst sehe ich alle, auch diejenigen, die nicht über Buser verfügen und auf die nicht zugegriffen werden kann:

USE Adb;
EXECUTE AS USER = 'Buser';
SELECT * FROM sys.databases; -- all DBs on the server are shown

Was könnte dieses Problem verursachen? Was soll ich überprüfen?

3
ROAL

Das Wichtigste zuerst: VERTRAUEN SIE NICHT VERTRAUENSWERT !! Es gibt absolut keinen Grund, eine so große Sicherheitslücke zu öffnen. (Hinweis: msdb hat TRUSTWORTHY aktiviert und das ist in Ordnung, da es sich um eine von Microsoft bereitgestellte Datenbank handelt. Vom Benutzer erstellte DBs werden nie benötigtTRUSTWORTHY aktiviert)

Wenn dies nun funktioniert, wenn Sie sich als Benutzer anstatt als Login ausgeben, liegt dies daran, dass Ihre [Adb] - Datenbank bereits als TRUSTWORTHY ON Aktiviert ist. Dadurch wird die Standardquarantäne entfernt, die bei Verwendung des Identitätswechsels auf Datenbankebene vorhanden ist . Sie können dies sehen, indem Sie Folgendes ausführen:

SELECT db.is_trustworthy_on, *
FROM   sys.databases db
WHERE  db.[name] IN (N'Adb', N'Bdb');

Unter der Annahme, dass Adb für TRUSTWORTHY aktiviert ist und Bdb nicht, aktivieren Sie bitte TRUSTWORTHY für Bdb nicht ]. Es ist am besten, deaktivierenTRUSTWORTHY für Adb und Module Signing zu verwenden, um dies zu erreichen:

ALTER DATABASE [Adb] SET TRUSTWORTHY OFF;

Ein Beispiel für diesen datenbankübergreifenden Zugriff über die Modulsignatur finden Sie in der folgenden Antwort von mir (hier auf DBA.SE):

Zugriffsansicht basierend auf Tabelle in einer anderen Datenbank ohne Konto in dieser anderen Datenbank

Weitere Informationen darüber, warum Sie Module Signing anstelle von TRUSTWORTHY (oder sogar datenbankübergreifende Verkettung) verwenden sollten, finden Sie in meinem folgenden Beitrag:

BITTE, bitte, bitte hören Sie auf, Identitätswechsel, VERTRAUENSWERT und DB-übergreifende Eigentumsverkettung zu verwenden

Weitere Informationen zur Modulsignierung im Allgemeinen finden Sie unter:

https://ModuleSigning.info/


Wie @Nic in einem Kommentar zu der Frage erwähnt hat, ist es am besten, beim Testen EXECUTE AS LOGIN Anstelle von EXECUTE AS USER Zu verwenden. Anmeldungen erfolgen auf Serverebene und haben Zugriff auf Datenbanken, in denen ein Benutzer für diese Anmeldung erstellt wurde. Dies entspricht der Anmeldung bei SQL Server als diesem Konto.

Der Grund für den Unterschied ist auf der Microsoft-Dokumentationsseite für Erweitern des Datenbankidentitätswechsels mithilfe von EXECUTE AS angegeben

Identitätswechsel verstehen

...

Wenn Sie sich jedoch als Principal ausgeben, indem Sie die EXECUTE AS USER-Anweisung verwenden, oder innerhalb eines Moduls mit Datenbankbereich, indem Sie die EXECUTE AS-Klausel verwenden, ist der Umfang des Identitätswechsels standardmäßig auf die Datenbank beschränkt. Dies bedeutet, dass Verweise auf Objekte außerhalb des Bereichs der Datenbank einen Fehler zurückgeben.

Außerdem gibt es viele gute Informationen auf der MSDN-Seite "Erweitern des Datenbankidentitätswechsels mithilfe von EXECUTE AS" (oben verlinkt), auf der Authentifikatoren und die Gründe für diese Regeln erläutert werden.

Da diese beiden Datenbanken vom Hersteller bereitgestellt werden (Informationen wurden hinzugefügt, nachdem ich diese Antwort gesendet habe), ist es wahrscheinlich am besten, einfach auf EXECUTE AS LOGIN Zu wechseln und nicht Änderungen an der vorzunehmen Datenbanken (zur Modulsignatur).

6
Solomon Rutzky

Ist Bdb eine vertrauenswürdige Datenbank?

SELECT name, is_trustworthy_on FROM sys.databases 

Um EXECUTE AS für eine andere Datenbank zu verwenden, müssen Sie eine Vertrauensstellung zwischen den Datenbanken einrichten:

ALTER DATABASE Bdb SET TRUSTWORTHY ON;
GO

Dies ist jedoch mit vielen Sicherheitsbedenken verbunden. Tun Sie dies nur, wenn Sie die Risiken tatsächlich verstehen.

Weitere Informationen finden Sie hier: https://technet.Microsoft.com/en-us/library/ms188304 (v = sql.105) .aspxhttps://support.Microsoft .com/de-de/help/2183687/Richtlinien für die Verwendung der vertrauenswürdigen Datenbankeinstellung in SQL Server

0
JasonBluefire