none
Zugriff auf Tabellen verhindern abhängig von Clientanwendung? RRS feed

  • Frage

  • Hallo zusammen,

    ich hab da ein Problem:
    Benutzer greifen auf eine SQL-Datenbank über einen NAV-Client zu.
    Für eine wichtige Auswertung wird aber Excel (mit JetReports) verwendet.

    Leider kann ich über SQL-Rechte manche Tabellen nicht sperren, da diese in NAV gebraucht werden.
    (Der direkte lesende Zugriff ist für die Benutzer nicht möglich da NAV das in der eigenen Anwendung verhindert)

    Ich muss aber verhindern das Benutzer über Excel auf diese bestimmten Tabellen lesend zugreift.
    Zuerst dachte ich mir: Dafür gibt es Anwendungsrollen. Aber ich sehe keine Möglichkeit in Excel bzw. JetReports sp_setapprole etc. aufzurufen.

    Kann ich irgendwie anders einen lesenden Zugriff auf bestimmte Tabellen, über eine andere Anwendung als NAV, sperren?
    Trigger?

    Danke schonmal für jede Idee.

    Grüße,

    Coyote

    Freitag, 21. Dezember 2012 10:20

Antworten

  • Hallo Coyote,

    die von Dir genannten Anforderungen können in SQL Server nicht implementiert werden, da es auf Ebene des Servers nur DDL/LOGON-Trigger und auf Ebene der Datenbanken nur DDL-Trigger gibt. Soll heißen, dass Du auf Ebene der Datenbank eigentlich DML-Trigger implementieren müßtes. So etwas ist aber in SQL Server nicht vorgesehen:

    http://msdn.microsoft.com/de-de/library/bb522542.aspx

    Selbst die Möglichkeit, mit EXTENDED EVENTS zu arbeiten, ist nicht möglich, da hier nur Aufzeichnungen geführt werden. Sie können aber während des Ausführens selbst nicht analysiert werden. Mein Vorschlag wäre, die Datenbank mittels Transaction-Replikation in eine dedizierte Datenbank zu transferrieren. In dieser Datenbank kann dann der User mit EXCEL spielen, bis die Spalten schmelzen.

    In Deiner eigentichen Datenbank erstellst Du einen LOGON-Trigger, der die Application überprüft und bei Application = 'EXCEL' ein Reject ausführt.

    CREATE TRIGGER trg_Select_Permissions
    ON ALL SERVER
    FOR LOGON
    AS
    	SET NOCOUNT ON
    
    	IF EXISTS (SELECT PROGRAM_NAME FROM sys.sysprocesses WHERE program_name LIKE '%Office%' AND db_name(dbid) = 'DeineDatenbank')
    	BEGIN
    		RAISERROR ('Auf diese Datenbank ist nur ein Zugriff mittels NAV möglich!', 16, 1) WITH NOWAIT
    		ROLLBACK
    	END
    	SET NOCOUNT OFF
    GO

    Hierzu noch ein paar Tipps:

    1. Ich würde eine Referenztabelle mit Programm-Namen anlegen. Welche Programme auf das System zugreifen kannst Du mittels:

    SELECT DISTINCT program_name FROM sys.sysprocesses

    analysieren. Dann sollte die Abfrage im Trigger auf die Referenztabelle, in der Du die "bad apps" hinterlegst, zugreifen.

    Eine andere Möglichkeit fällt mir hierzu auch nicht ein!


    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)


    Freitag, 21. Dezember 2012 13:02

Alle Antworten

  • Geht zwar, aber einfacher ist normalerweise ein separater Benutzer, welcher entsprechend berechtigt wird. Z.B. über Sichten in einem eigenen Schema.
    Freitag, 21. Dezember 2012 10:24
  • Danke für die schnelle Antwort.

    Daran hab ich auch schon gedacht, aber die Benutzer können die Verbindungseinstellungen wieder auf "Windows Authentifizierung" umstellen.
    Ich muss dazu sagen, das die Benutzer teilweise Entwickler sind und weitestgehende Rechte im Entwicklungssystem haben/brauchen. Dennoch sollen
    bestimmte Tabellen auch für diese Benutzer gesperrt sein.
    Es ist auch nicht machbar das die Benutzer sich mit einem anderen Login an Windows anmelden um diese Reports zu starten oder entwickeln zu können.

    Ich sehe tatsächlich nur die Möglichkeit das am SQL-Server zu regeln, am besten abhängig von der verbundenen Anwendung.... ich weiß nur nicht wie :(

    viele Grüße,

    Coyote

    Freitag, 21. Dezember 2012 10:31
  • Die Berechtigungen im Entwicklungssystem sind egal, da es ja vom Produktivsystem entkoppelt sein muss. Außerdem, wenn einem Benutzer, auch wenn er Entwickler ist, bestimmte Berechtigungen zu entziehen sind, beeinflussen sich die Rollen ja nicht, da nur ein Administrator in der Lage sein sollte, sich fehlende Berechtigungen zu verschaffen.
    Freitag, 21. Dezember 2012 10:59
  • Schon, aber in diesem Fall reicht diese Entkopplung Produktiv und Entwicklungssystem nicht. Außerdem kann ich dem Benutzer ja nicht grundsätzlich das lese-Recht entziehen:

    Fakt ist: Ich kann dem Benutzer nicht das lesende Recht in NAV entziehen da es für interne Berechnungen gebraucht wird.
    Der Benutzer sieht innerhalb von NAV die Daten nicht, da durch die Anwendung keine Anzeige vorhanden ist.

    Greift der Benutzer aber über Excel auf die Datenbank, greifen die Mechanismen von NAV nicht. Er kann also die Tabellen lesen.
    Bei Excel mit JetReports kann ein und soll ein versierter Benutzer eigene Reports erstellen können. Er bekommt
    eine Auflistung aller vorhandener Tabellen und könnte auch die "verbotenene" Tabellen auswählen. Und das gilt es zu verhindern.

    Und es müssen natürlich beide Anwendungen (Excel JetReports und NAV) für einen Benutzer funktionieren. Natürlich auch im Produktivsystem.

    Ich sehe keine Möglichkeit in Excel einen Benutzer daran zu hindern, anstatt einem Datenbankuser mit eingeschränkten Rechten, die Datenverbindung auf "Windows" umzustellen, und spätestens jetzt hat wieder Zugriff auf die verbotenen Tabellen, da er diese ja in NAV lesend braucht.

    Aber ich befürchte dafür gibt es keine geeignete Lösung da sich die Anforderungen in teilen wiedersprechen.

    Freitag, 21. Dezember 2012 11:11
  • Dann gibt es grundsätzlich keine Möglichkeit außer NAV anzupassen. Nur wenn hier mit einer Application Role gearbeitet werden kann o.ä. dann läßt sich dein Wunsch umsetzten. Ansonsten nicht. Da ein versierter Nutzer immer mit der NAV-Ameldung "alles" darf.

    Du kannst natürlich immer noch einen zweiten SQL Server aufsetzten, dort mittels linked server und Sichten nur die gewünschten Tabellen bereitstellen. Dann kannst du wenigstens einiges verstecken...

    Freitag, 21. Dezember 2012 12:39
  • Hallo Coyote,

    die von Dir genannten Anforderungen können in SQL Server nicht implementiert werden, da es auf Ebene des Servers nur DDL/LOGON-Trigger und auf Ebene der Datenbanken nur DDL-Trigger gibt. Soll heißen, dass Du auf Ebene der Datenbank eigentlich DML-Trigger implementieren müßtes. So etwas ist aber in SQL Server nicht vorgesehen:

    http://msdn.microsoft.com/de-de/library/bb522542.aspx

    Selbst die Möglichkeit, mit EXTENDED EVENTS zu arbeiten, ist nicht möglich, da hier nur Aufzeichnungen geführt werden. Sie können aber während des Ausführens selbst nicht analysiert werden. Mein Vorschlag wäre, die Datenbank mittels Transaction-Replikation in eine dedizierte Datenbank zu transferrieren. In dieser Datenbank kann dann der User mit EXCEL spielen, bis die Spalten schmelzen.

    In Deiner eigentichen Datenbank erstellst Du einen LOGON-Trigger, der die Application überprüft und bei Application = 'EXCEL' ein Reject ausführt.

    CREATE TRIGGER trg_Select_Permissions
    ON ALL SERVER
    FOR LOGON
    AS
    	SET NOCOUNT ON
    
    	IF EXISTS (SELECT PROGRAM_NAME FROM sys.sysprocesses WHERE program_name LIKE '%Office%' AND db_name(dbid) = 'DeineDatenbank')
    	BEGIN
    		RAISERROR ('Auf diese Datenbank ist nur ein Zugriff mittels NAV möglich!', 16, 1) WITH NOWAIT
    		ROLLBACK
    	END
    	SET NOCOUNT OFF
    GO

    Hierzu noch ein paar Tipps:

    1. Ich würde eine Referenztabelle mit Programm-Namen anlegen. Welche Programme auf das System zugreifen kannst Du mittels:

    SELECT DISTINCT program_name FROM sys.sysprocesses

    analysieren. Dann sollte die Abfrage im Trigger auf die Referenztabelle, in der Du die "bad apps" hinterlegst, zugreifen.

    Eine andere Möglichkeit fällt mir hierzu auch nicht ein!


    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)


    Freitag, 21. Dezember 2012 13:02
  • Laut seiner Beschreibung haben die Benutzer einen mehr als weitrechenden Zugriff per Domänenauthentifizierung.. und der er ja versierte Nutzer hat, ist ein Blocken mittels program_name mehr als löchrig..
    Freitag, 21. Dezember 2012 13:47
  • Vielen Dank für eure Unterstützung.
    Ich hab schon befürchtet das es sehr problematisch wird.

    Das mit dem Sperren mittels Programmnamen ist natürlich nicht sicher, verhindert aber einen "versehentlichen" Zugriff.

    Vermutlich werde ich euren Vorschlag mit der replizierten DB implementieren und mit dem LOGON-Trigger den versehentlichen Zugriff auf die Live-DB zumindest erschweren.

    Danke an euch Beide.

    Viele Grüße,

    Coyote



    Freitag, 21. Dezember 2012 13:56
  • Laut seiner Beschreibung haben die Benutzer einen mehr als weitrechenden Zugriff per Domänenauthentifizierung.. und der er ja versierte Nutzer hat, ist ein Blocken mittels program_name mehr als löchrig..

    Hallo Stefan,

    in diesem Fall sehe ich das anders. Die Anforderung lautet:

    "Ich muss aber verhindern das Benutzer über Excel auf diese bestimmten Tabellen lesend zugreift."

    Dann bleibt nur die Möglichkeit, generell den Zugriff auf die Datenbank mit "Office-Komponenten" zu untersagen.
    Eine andere Möglichkeit besteht - wie ich schon ausgeführt habe - nicht!


    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    SQL Server Blog (german only)

    Freitag, 21. Dezember 2012 14:01