Tabellenzugriff einschränken

[MrFreez]

Hallo zusammen,

gibt es eine einfache Möglichkeit einem bestimmten User den Zugriff auf den Inhalt einer DB-Tabelle einzuschränken? Folgendes Szenario:

Zur Weiterverarbeitung von Datensätzen aus einer DB soll ein neuer User angelegt werden, der dann mittels ODBC vom Client aus auf einen MS SQL Server zugreifen kann, um von dort Datensätze aus einer oder mehreren Tabellen auszulesen. Bei einer normalen Einrichtung erhält der neu angelegte User volles Leserecht auf sämtlichen Inhalt der Tabelle, was aber vom Autraggeber so nicht gewünscht wird!

Stattdessen soll der Lesezugriff nur auf einen bestimmten Umfang der Tabellen (nur bestimmte Kostenarten und Kostenstellen) begrenzt werden!

Gibt es hierfür Möglichkeiten, dem User über den Enterprise Manager oder anderen Standardtools so zu beschneiden oder muss man hierfür ein Script im Vorfeld erstellen, welches dann genau die Datensätze bei einem Lesevorgang eleminiert, die für den User tabu sind?

Habt ihr für ein solches Problem schon einmal eine Lösung geschaffen? Welche Lösungsansätze habt ihr verwendet?

Ist eine der gegebenen Möglichkeiten vielleicht das ganze mittels Views abzubilden? In der View werden die Parameter als SQL-Statements hinterlegt, die für den Anwender nicht ersichtlich sein sollen!

Gruß

Mr. Freez

Bearbeitet 23. September 2009 von MrFreez

[flashpixx]

Ich kann jetzt nur von Postgres und mySQL sprechen, aber ich gehe davon aus, dass dies auch unter MS SQL möglich ist (Google Such findet entsprechendes)

Stattdessen soll der Lesezugriff nur auf einen bestimmten Umfang der Tabellen (nur bestimmte Kostenarten und Kostenstellen) begrenzt werden!

Sprechen wir hier von Spalten oder von Datensätzen? Das DBMS beschränkt die Berechtigung auf Feldebene meist nicht auf Inhalt

Ist eine der gegebenen Möglichkeiten vielleicht das ganze mittels Views abzubilden? In der View werden die Parameter als SQL-Statements hinterlegt, die für den Anwender nicht ersichtlich sein sollen!

Das kommt darauf an, was Du beschränken willst. Der User authentifiziert sich ja am DBMS und arbeitet damit als dieser User. Du kannst Tabellen / Schreib- / Leseberechtigungen / Feldberechtigungen entsprechend setzen. wenn Du Datensätze filtern willst muss ja die Kondition des Statements verändert werden

[.NETter]

Hallo,

wenn sich die Beschränkung auf bestimmte Inhalte bezieht wie z.B.:

- Bestimmte User sollen nur Datensätze der Kostenstelle 123 sehen können

Würde ich eine View erstellen welche diese Daten filtert und dem eingeschränkten Benutzer zur Verfügung stellt.

Am besten wäre es allerdings garkeinem User irgendwelche Berechtigungen an Tabellen oder Views zu geben!!!

Gespeicherte Prozeduren und Funktionen bieten hier eine viel höhere Sicherheit und auch Performance.

Schreibe eine Prozedur oder Funktion die entsprechende Daten zurück gibt und nutze diese in der Anzeige. (Und natürlich auch zum Ändern und Anfügen.)

Die Benutzer erhalten nur das Recht "Execute" und gut :-)

Ein versierter User weiß sehr wohl mit Access oder Excel umzugehen und kann sich so mit einem anderen Programm Zugang zu Daten verschaffen (ODBC-Verbindung)... Man glaubt nicht wie erfinderisch selbst eine Sekretärin sein kann, um dann doch anders als gewollt mit den Daten zu arbeiten (Selbst erlebt)

Gruß,

Thomas

[dr.dimitri]

Gespeicherte Prozeduren und Funktionen bieten hier eine viel höhere Sicherheit und auch Performance.

Sicherheit vielleicht - Performance - wieso?

Ein versierter User weiß sehr wohl mit Access oder Excel umzugehen

Zum Glück weiß der versierte Datenbankentwickler auch, dass man für Applikationen niemals die User verwendet denen die Tabellen gehören, sondern speziell für den Zugriff angelegte User verwendet.

Diesen Usern kannst Du dann Select Rechte auf die Views geben, die ihnen das zeigen was sie sehen sollen.

Würde ich eine View erstellen welche diese Daten filtert und dem eingeschränkten Benutzer zur Verfügung stellt.

Dito. Eigentlich sollte aber der Zugriff auf eine Datenbank immer nur über die entsprechende Applikation erfolgen und nicht mittels SQLs die man Ad Hoc abschickt.

Dann kann man sich auch die Views sparen (vor allem bei umfangreicheren Datenmodellen sehr aufwändig) und statt dessen sein eigenes, auf die Bedürfnisse zugeschnittenes Berechtigungssystem implementieren. Dann sind wir auch bei den von dir schon erwähnten SPs wieder einer Meinung (bis auf die Performance vielleicht)

Dim

[.NETter]

Hallo,

Zitat:

Gespeicherte Prozeduren und Funktionen bieten hier eine viel höhere Sicherheit und auch Performance.

Sicherheit vielleicht - Performance - wieso?

Sicherheit sogar ganz Sicher! Und Performance sowieso weil:

Der SQL Server legt für jede Stored Procedure einen Ausführungsplan an, was bedeutet er muss kein SQL Statement prüfen ob es syntaktisch richtig ist und ob angegebene Tabellen und Felder überhaupt vorhanden sind.

Zitat:

Ein versierter User weiß sehr wohl mit Access oder Excel umzugehen

Zum Glück weiß der versierte Datenbankentwickler auch, dass man für Applikationen niemals die User verwendet denen die Tabellen gehören, sondern speziell für den Zugriff angelegte User verwendet.

Diesen Usern kannst Du dann Select Rechte auf die Views geben, die ihnen das zeigen was sie sehen sollen.

Speziell angelegte User? Für den Datenbankzugriff? Wo hinterlegst Du dann die Anmeldedaten? Im Quellcode? Ressourcendatei?

Windows integrierte Sicherheit ist hier die bessere Lösung bzw. sollte im Internet dem ASP-User ein entsprechendes Recht eingeräumt werden.

Das hinterlegen von Anmeldeinformation auf irgendeine Art sollte absolute Ausnahmen bleiben auch wenn sie verschlüsselt hinterlegt sind.

Dito. Eigentlich sollte aber der Zugriff auf eine Datenbank immer nur über die entsprechende Applikation erfolgen und nicht mittels SQLs die man Ad Hoc abschickt.

Dann kann man sich auch die Views sparen (vor allem bei umfangreicheren Datenmodellen sehr aufwändig) und statt dessen sein eigenes, auf die Bedürfnisse zugeschnittenes Berechtigungssystem implementieren. Dann sind wir auch bei den von dir schon erwähnten SPs wieder einer Meinung (bis auf die Performance vielleicht)

Natürlich kommen Anforderungen an den SQL Server rein aus der Anwendung, aber gerade hier ist der Einsatz von Stored Procedures absolut ratsam.

Sie werden auch API der Datenbank genannt und so sollte man es auch halten.

Änderungen können so rein am SQL Server vorgenommen werden ohne die Anwendung anfassen zu müssen (vorausgesetzt die Signatur der SP bleibt die selbe).

So hat man den Grundstein für Mehrschichtige Anwendungen.

Die View erledigt sich mit einer SP natürlich, da sie selbst Daten zurück gibt. Das Berechtigungssystem ist im SQL Server doch schon vorhanden... Schemata, Rollen. Berechtigungen setzen und gut...

Gruß,

Thomas

[dr.dimitri]

Sicherheit sogar ganz Sicher! Und Performance sowieso

Ich kann auch eine SP schreiben, die als Argument einen String erwartet und denn dann als dynam. SQL ausführt. Sprich ich kann auch mit SP unsicheren Code schreiben genauso wie ich auch mit SQL und PreparedStatements sicheren Code schreiben kann.

Zum thema Performance: Ich kann jetzt nur für oracle sprechen, aber ich denke der SQLServer hat ähnliche Mechanismen. In oracle wird das gepartse Statement ebenfalls abgelegt und kann dann wiederverwendet werden.

Speziell angelegte User? Für den Datenbankzugriff?

Natürlich. erlauben, dass der Owner der Objekte in der Applikation als User verwendet wird hat zur folge, dass man als DBA deutlich weniger Kontrolle über die augeführten Tätigkeiten besitzt. Das kann ein Programmfehler sein der Tabelle löscht weil der Testquellcode nicht entfernt wurde, oder auch eine Sicherheitslücke in der App die dann kompletten Zugriff auf alle Objekte bietet.

Wo hinterlegst Du dann die Anmeldedaten? Im Quellcode? Ressourcendatei?

Ob Du mit dem Owner der Tabellen drauf gehst oder mit einem speziellen anonymen oder personalisierten user - Irgendwie muss er sich anmelden.

Sie werden auch API der Datenbank genannt und so sollte man es auch halten.

Eingebaute Systemfunktionen mag man API nennen. Aber sich selbst eine Zugriffsschicht a la getXY und setXY zu schreiben ist für größere Anwendungen utopisch (wenn ich mir vorstelle, dass unsere ca. 1500 SQL Statements alle in SPs abgelegt wären anstatt in einer Tabelle würd mir Angst und Bange werden).

Versteh mich nicht falsch. Ich bin ein großer Fan von SPs und der Meinung das man nur mit ihnen die DB wirklich auch ausnutzen kann, aber nur wenn es darum geht Daten zu verarbeiten nicht um sie einfach als Kapselung für einen mehr oder weniger einfachen Select zu verwenden.

Dim

[.NETter]

Hallo Dim,

natürlich kann man eine SP schreiben die einfach ein SQL-Statement entgegen nimmt und dieses dann ausführt. "Works as designed" würde ich sagen. Aber das wäre ja der Missbrauch einer SP.

Natürlich cached der SQL Server auch bereits eingegangene SQL´s. Aber auch nur solange wie eine Verbindung von der Anwendung aufrecht erhalten wird. Wird die Anwendung geschlossen und neu gestartet so werden die gleichen SQL-Statements erneut ausgeführt nur in einem neuen Kontext, was zur folge hat, dass der SQL Server diese erneut prüfen muss. Ein Ausführungsplan ist ein Fixum.

Ob Du mit dem Owner der Tabellen drauf gehst oder mit einem speziellen anonymen oder personalisierten user - Irgendwie muss er sich anmelden.

Da gebe ich Dir völlig Recht! Der Benutzer muss sich am Server und dann an der Datenbank anmelden. Klar, anders geht´s ja nicht. Wie gesagt sollte man von der integrierten Sicherheit nur im absoluten Ausnahmefall abweichen.

Es gab in meinen bisherigen Projekten immer die Vorgabe keinem Benutzer Rechte an Tabellen zu geben.

Eingebaute Systemfunktionen mag man API nennen. Aber sich selbst eine Zugriffsschicht a la getXY und setXY zu schreiben ist für größere Anwendungen utopisch

Hmm, wo ist der Unterschied im Arbeitsaufwand? Ob ich das SQL nun in der Anwendung hinterlege oder in einer SP... Schreiben muss ich so oder so.

Ich habe vor einem halben Jahr eine Anwendung von Sybase zu SQL Server migriert. 2200 Stored Procedures! Ich war sehr dankbar über Stored Procedures, sonst hätte ich in einer Anwendung Dinge ändern müssen die ich nicht geschrieben habe.

Also irgendwo muss ich diese Datenschicht eh erzeugen. Und zusätzlich eine Schicht in der Anwendung die mir als Object-Relation-Mapper (z.B. Entity Framework) dient.

Es ist absolut gang und gäbe eine solche Schicht mit SP´s zu erzeugen.

Daher auch "API der Datenbank".

Übrigens auch für Oracle. Für eine öffentliche Verwaltung habe ich eine Anwendung auf Oracle-Datenbasis schreiben müssen und auch diese nur in SP´s abgelegt. Alle schön als Package, da auch hier die Vorgabe war keinem Benutzer irgendwelche Berechtigungen an Tabellen zu erteilen.

Die Wartbarkeit ist somit auch viel einfacher, weil ich hier nur am SQL- oder Oracle-Server eingreifen muss. Im schlimmsten Fall habe ich eine Formsanwendung und entdecke nach dem Rollout doch noch einen Fehler oder irgendeine Änderung muss noch implementiert werden. Dann muss ich vielleicht für mehrere tausend Benutzer ein Update oder sogar eine neue Version der Software bereitstellen um ein fehlerhaftes SQL-Statement abzuändern. So gehe ich kurz zum Datenbankserver, ändere die SP und gut.

Gruß,

Thomas

[dr.dimitri]

Wird die Anwendung geschlossen und neu gestartet so werden die gleichen SQL-Statements erneut ausgeführt nur in einem neuen Kontext

Ok da ist Oracle etwas weiter. Zum einen werden Statements geparst und der Plan erstellt (Hardparse) und im Shared Pool abgelegt. Beim erneuten Zugriff wird nur geprüft, ob der User auch noch Berechtigungen hat die Objekte zu sehen (Softparse). das ist unabhängig davon ob die ursprüngliche Sesseion noch aktiv ist oder nicht.

Des weiteren speichert Oracle die ausgeführten Plane auch noch als Session Cached Cursor hier ist dann auch kein Softparse mehr nötig, aber sie verschwinden wenn die Session beendet wird.

Ein Ausführungsplan ist ein Fixum.

Nicht in Oracle. Auch in PL/SQL wird ein Ausführungsplan nicht zwangsläufig sofort erzeugt. Mal folgendes Beispiel:

function f1 (p_var varchar2) return number is

  l_result number;

begin

  Select count(*) into l_result from T where WERT=p_var

  return result;

end;

Es gibt 100000 Einträge mit der Ausprägung A in der Spalte WERT und weiteren 100000 distincte Einträge mit anderen Ausprägungen. Des weiteren ist WERT indiziert und es gibt aktuelle Statistiken inklusive Histogramm.

Beim ersten Zugriff auf dieses Statement wird der Ausführungsplan erstellt (validiert wurde das Statement schon während des Compiles) und der Optimizer schaut sich für die Berechnung u.a. auch den an die Bindvariable gebundenen Wert an (Bind Peeking seit, implementiert seit 9i) und bezieht diesen Wert in seine Berechnungen an.

Wird hier jetzt der Wert A übergeben, dann errechnet der CBO einen Full Table Scan, würde ein anderer Wert übergeben werden, würde der CBO einen Indexzugriff bevorzugen.

Dieser Plan wäre dann für alle weiteren Aufrufe relevant bis er irgendwann invalidiert oder aus dem Shared Pool gelöscht würde.

In Oracle 11g geht das noch einen Schritt weiter. Hier merkt Oracle, wenn der Plan für unterschiedliche Werte der Bindvariablen extrem unterschiedliche Laufzeiten zur Folge hat und berechnet für ein und das selbe Statement unterschiedlcieh Ausführungspläne (adaptive Cursor Sharing).

Eine Ausführungsplan ist also auch in einer SP alles andere als ein Fixum - zumindest unter Oracle und das ist auch gut so.

Dim

[.NETter]

Hallo,

leider erst eine späte Antwort da ich ein paar Tage nicht da war...

Meine Bezeichnung "Fixum" für den Ausführungsplan war ungünstig gewählt!

Der SQL Server hält den Ausführungsplan vor, kann aber auch (wie du über den Oracle 11g gesagt hast...) den Ausführungsplan sagen wir mal "neu überdenken". Hier werden auch die unterschiedlichen Ausführungszeiten für eine Neuerstellung herangezogen (auch mehrfache Pläne sind möglich).

Aber ich denke es ist auch völlig Sinnfrei hier den alten

Krieg MS SQL Server gegen Oracle loszutreten, da ich denke, dass beide durchaus ihre Daseinsberechtigung besitzen.

Gruß,

Thomas