Zugriffssicherheit SQL Server

[mogano]

Hallo,

ich entwickle eine WinForm-Applikation (c#.NET 2.0), die den SQL Server 2005 Express als Backend verwendet. Die Applikation soll beim Kunden innerhalb der Domain auf einzelnen Client-Rechnern laufen - die Datenbank auf einem zentralen Server. Der Kunde möchte Windows-Authentifizierung verwenden.
Die Zugriffsrechte der einzelnen Applikations-User auf die Daten ist in der Geschäftslogik der Applikation hinterlegt.

Wenn ich das richtig verstanden habe, muß bei der Windows-Authentifizierung jeder Windows-User, der die Applikation nutzen soll, als Datenbank-User angelegt werden.

Problem ist nun, daß der User z.B. mit dem SQL Server Management Studio Express ebenfalls auf die Datenbank zugreifen und somit die Rechteverwaltung der Applikation aushebeln könnten.

Habe ich da was falsch verstanden oder ist das tatsächlich so, bzw. wie kann man das verhindern (DB-Admin, ActiveDirectory etc.) ?

Da ich mich im Admin-Bereich leider nicht besonders gut auskenne, bin ich für jeden Hinweis dankbar.

[Bernhard Geyer]

> Problem ist nun, daß der User z.B. mit dem SQL Server Management Studio Express ebenfalls auf die Datenbank zugreifen und somit die Rechteverwaltung der Applikation aushebeln könnten.

Wenn die User keine Entsprechenden Adminrechte auf der Datenbank haben können die dort gar nichts machen "verpfuschen". "Einfach" nur Lese/Schreibrechte auf die eine Datenbank geben und gut ist. Dann können Sie sich nicht mal mit dem SQL Server Managemnt Studio Express anmelden.

[mogano]

hm, verstehe ich nicht ganz. Wie kann die Datenbank denn unterscheiden, ob der Zugriff (schreiben / lesen) von der Applikation oder vom SQL Server Management Studio Express kommt?

[Andreas Kosch]

Hallo,

..und somit die Rechteverwaltung der Applikation aushebeln könnten.

für jedes SQL Server-Login und für jeden Datenbank-Benutzer können die Rechte sehr feingliedrig unterteilt werden. Der SQL Server 2005 Express stellt in Gestalt der so genannten Fixed Server Roles vordefinierte Berechtigungsmengen zur Verfügung, die eine Art SQL Server-Gruppen bilden. Zum Beispiel ist die feste Server-Rolle sysadmin die Rolle mit der umfangreichsten Berechtigungsmenge. Wenn ein neues SQL Server Login uneingeschränkte Administrator-Rechte für die SQL Server-Instanz erhalten soll, kann dieses Login über die Systemprozedur sp_addsrvrolemember als Mitglied der Gruppe der festen Server-Rolle sysadmin zugeordnet werden.

Wenn der Benutzer der festen Rolle db_securityadmin zugeordnet wird, darf er die Berechtigungen ändern. Wenn die Benutzer jedoch nur den Rollen db_datawriter und db_datareader zugeordnet werden, können sie nur die Tabellen und die Daten lesen und ändern:
[highlight=SQL]
USE MeineDatenbank
GO
EXEC sp_addrolemember N'db_datawriter', N'DomainName\BenutzerName'
EXEC sp_addrolemember N'db_datareader', N'DomainName\BenutzerName'
GO
[/highlight]
Wenn der Benutzer nur bestimmte Tabelle lesen oder beschreiben darf, wird dies über einzelne GRANT-Aufrufe festgelegt. Die Datenbank kann dem Benutzer auch alle Rechte an den Basistabellen entziehen und über GRANT EXECUTE nur das Ausführen von gespeicherten Prozeduren der Datenbank zulassen. In diesem Fall kann der Anwender auch im SQL Server Management Studio Express die Tabellen der Datenbank nicht einsehen, aber trotzdem mit dem Programm arbeiten, wenn das Programm die gespeicherten Prozeduren für den Datenbankzugriff nutzt.

Wie kann die Datenbank denn unterscheiden, ob der Zugriff (schreiben / lesen) von der Applikation oder vom SQL Server Management Studio Express kommt?

Der Zugriffsweg spielt keine Rolle. Für den SQL Server entscheidend ist bei der integrierten Windows-Authentifizierung allein das Benutzerkonto, mit dem sich der Anwender bei Windows angemeldet hat. Dieses Benutzerkonto wird vom SQL Server genutzt, um die zugeordneten Server-Rollen und somit auch die Berechtigungen dieses Benutzers zu bestimmen.

Wenn sich der Benutzer mit einem Konto anmeldet, das zur Gruppe der lokalen Administratoren bzw. der Domänen-Administratoren gehört, hat er implizit volle Rechte (SQL Server-Rolle sysadmin) am SQL Server. Jede in der SQL Server-Datenbank vorgenommene Einschränkung wird in diesem Fall wirkungslos, da der Administrator immer einen uneingeschränkten Zugriff erhält.

[mogano]

Erstmal danke für die ausführliche Antwort.

Ein Grant für Schreib-/Leserechte auf einzelne Tabellen für bestimmte Benutzer bzw. Rollen reicht in meinem Fall leider nicht aus, da die Granularität teilweise bis auf einzelne Datensätze herunter geht.

Die Kapselung der Datenbank-Tabellen in StoredProcs wäre eine Möglichkeit, wobei dann die komplette Berechtigungslogik von der Applikation in die Datenbank verlegt werden müßte, da der User ansonsten die Rechteverwaltung der Applikation eben über die StoredProcs aushebeln könnte, auf die er ja nach wie vor mit dem SQL Server Management Studio Express zugreifen kann.

Der Weg erscheint mir zwar gangbar, aber recht aufwendig. Außerdem wollte ich eigentlich vermeiden, Applikationslogik in die Datenbank zu verlegen, da bei einem evtl. Datenbankwechsel zusätzlicher Aufwand entsteht.

Habe ich da noch einen Denkfehler drin oder ist das tatsächlich die einzige Möglichkeit das Problem "administrativ" in den Griff zu bekommen?

[Bernhard Geyer]

Wie wäre es mit einer 3-Tier Architektur? Dann könnte die Sicherheitsüberprüfung im App-Server erfolgen und du könntest die DB primär für die Speicherung einsetzen.

[Andreas Kosch]

Hallo,

...da die Granularität teilweise bis auf einzelne Datensätze herunter geht.

Diese Anforderungen lassen sich mit Zugriffsrechte auf einen VIEW (Sichttabelle) oder über die bereits genannten EXECUTE-Rechte auf eine Stored Procedure (SP) erfüllen. Sowohl der VIEW oder die SP kann über die Selektion und Projektion jedem Benutzer eine eigene Sichtweise auf die Daten einräumen. Das EXECUTE-Rechte an eine SP bedeutet nicht, dass der Anwender die Implementierung der SP ändern kann.

Außerdem wollte ich eigentlich vermeiden, Applikationslogik in die Datenbank zu verlegen, da bei einem evtl. Datenbankwechsel zusätzlicher Aufwand entsteht.

Tja - in diesem Fall muss sich die Anwendung dem Prinzip des kleinsten gemeinsamen Nenners (ANSI-SQL) unterwerfen, wobei dann auch die gespeicherten Prozeduren entfallen.

...oder ist das tatsächlich die einzige Möglichkeit ..

Beim MS SQL Server könnte man auf eine Application Role zurückgreifen.
Eine über CREATE APPLICATION ROLE angelegte Application Role ist ein Hybrid zwischen einem SQL Server-Login und einer Datenbank-Rolle. Der Application Role können Berechtigungen auf dem gleichen Weg zugewiesen werden wie bei den anderen benutzerdefinierten Rollen. Allerdings unterscheiden sich die Anwendungs-Rollen gegenüber den Datenbank- oder Server-Rollen darin, dass keine Mitglieder zugeordnet werden können. Statt dessen wird ein Passwort in der Funktion einer Parole zugeordnet, das vom Programm erst nach dem Login an der Datenbank über die Systemprozedur sp_setapprole verdeckt gesendet wird. Da der Anwender diese "Parole" nicht kennt, kann er über sein Benutzerkonto nicht direkt auf die Datenbank zugreifen, wenn die Zugriffsrechte an den Datenbankobjekten nur der Application Role, aber nicht dem Benutzerkonto erteilt werden.

Allerdings steht die Application Role nicht zur Verfügung, wenn die Anwendung mit beliebigen SQL-Datenbanken zusammenarbeiten soll. Statt dessen wäre eine Three-Tier-Anwendung in der Tat am besten geeignet, um alle Anforderungen unter einen Hut zu bringen.

[mogano]

Danke nochmals für die Antworten.

Werde meinem Kunden erstmal die verschiedenen Möglichkeiten vorstellen und dann weitersehen.