none
Logon Trigger wg. SSMS Zugriff? RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich verwende derzeit einen Logon Trigger um die Verbindung von Benutzern über das Management Studio mit bestimmten SQL Servern zu verhindern.

    Über Berechtigungen kann ich die Benutzer leider nicht einschränken, da diese über eine Anwendung bzw. Excel dbo-Zugriffe auf die Datenbanken benötigen. Fehler by Design, ich weiß...

    Gibt es vielleicht noch eine andere Möglichkeit die Benutzung des SSMS für bestimmte Benutzer zu unterbinden - außer die Installation auf den Rechnern nicht zuzulassen :-)

    Es kommen leider derzeit nach und nach einzelne Benutzer dazu die das SSMS doch benutzen sollen und die müssen alle im Trigger eine Ausnahme bekommen, so wie unten zu sehen - AD Gruppen funktionieren dort nicht:

    create TRIGGER [disallow_trigger]
    ON ALL SERVER
    FOR LOGON
    AS
    BEGIN
    IF (not exists(select * from fn_my_permissions(null,'SERVER') where permission_name='CONTROL SERVER') and ORIGINAL_LOGIN() not in ('ranger\Volker1','ranger\Volker2'))
      AND
      exists(select *
             from sys.dm_exec_sessions 
             where 
               original_login_name = ORIGINAL_LOGIN() and 
               program_name like '%Management Studio%' ) 
                    BEGIN
          ROLLBACK;
        END
    END;

    Danke für Eure Hinweise.

    Viele Grüße,

    Volker

    Donnerstag, 11. September 2014 14:51
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Volker,

    ich sehe hier 2 Schwachpunkte, über die Du Dir hoffentlich im Klaren bist:

    • zum einen die Verwendung von dbo/db_owner für die Verbindung - damit kann jeder allen Unfug mit der DB anstellen, der nur denkbar ist, inkl. den Server mit Backups vollmüllen oder u.U. auch den Server übernehmen.
    • Zum anderen sind Logon-Trigger mit App_name keine wirkliche Sicherheit, denn der Applikationsname lässt sich ohne komplizierte Eingriffe ganz bequem in den Verbindungseinstellungen ändern.

    Ich würde nahelegen, mit 2 verschiedenen Anwenderguppen (Windows-Gruppen) zu arbeiten, also integrierte Sicherheit zu hinterlegen, und je nach eingeloggtem User/Gruppe dann verschiedene Berechtigungen zuzuweisen. - Wenn das irgendwie noch umsetzbar ist.

    Die Anwendung einzuschränken ist reine Makulatur, die nur "zufällig Verirrte" abhalten wird. (Dafür ist das auch Legitim, nur mehr sollte man sich nicht erhoffen.)

     

    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Donnerstag, 11. September 2014 15:15
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Volker,

    ich sehe hier 2 Schwachpunkte, über die Du Dir hoffentlich im Klaren bist:

    • zum einen die Verwendung von dbo/db_owner für die Verbindung - damit kann jeder allen Unfug mit der DB anstellen, der nur denkbar ist, inkl. den Server mit Backups vollmüllen oder u.U. auch den Server übernehmen.
    • Zum anderen sind Logon-Trigger mit App_name keine wirkliche Sicherheit, denn der Applikationsname lässt sich ohne komplizierte Eingriffe ganz bequem in den Verbindungseinstellungen ändern.

    Ich würde nahelegen, mit 2 verschiedenen Anwenderguppen (Windows-Gruppen) zu arbeiten, also integrierte Sicherheit zu hinterlegen, und je nach eingeloggtem User/Gruppe dann verschiedene Berechtigungen zuzuweisen. - Wenn das irgendwie noch umsetzbar ist.

    Die Anwendung einzuschränken ist reine Makulatur, die nur "zufällig Verirrte" abhalten wird. (Dafür ist das auch Legitim, nur mehr sollte man sich nicht erhoffen.)

     

    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Donnerstag, 11. September 2014 15:15
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Volker,

    wo seht ihr den qualitativen zwischen MS Excel/Query und SSMS? Auch aus MS Excel kann ich z.B. DML Statements absetzen.

    Ein Logon-Trigger ist wohl die einzige Möglichkeit die Nutzung zu unterbinden, wenn auch keine zuverlässliche. Für die Ausnahmen an Usern könntest Du eine Tabelle anlegen, in denen die User gepflegt werden. Du musst dann nur alle User Leserechte auf die Tabelle geben; auch nicht so optimal.

    Und mit Logon Trigger sollte man vorsichtig sein, ein Bug und niemand kann sich mehr anmelden. Dann kann nur ein SysAdmin via DAC darauf zugreifen und den Trigger droppen.

    Zum Schluß noch die schlechte Nachricht bezüglich "nicht zuverlässlich": Der Application Name ist keine zugesicherte Eigenschaft, da kann alles & jeder übergeben, was er will und so auch in SSMS unter "Zusätzliche Verbindungsparameter":

    Den Trigger kann man also ganz leicht austricksen.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 11. September 2014 15:23
    |
  • Question
    Anmelden
    0
    Anmelden

    Und wenn ich jetzt mit MS-Access oder einem anderen ODBC-Client komme?

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 12. September 2014 06:20
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Andreas, 

    ich sehe die Berechtigungsstruktur - wenn man denn überhaupt davon reden kann - auch nicht als besonders glücklich an, habe aber dazu schon einige Kämpfe ausgefochten die jedes Mal mit "Umbau zu teuer" für die Anwendung abgewiesen wurden. 

    Neben den Anwendungsberechtigungen über ein SQL Login gibt es dann noch die AD Berechtigungen - vielleicht muss ich da nochmal differenzierter drauf schauen um damit die User einzuschränken, wie von Dir vorgeschlagen.

    Dass man den APP_Name auch im Management Studio so leicht ändern kann war mir nicht klar.

    Da wir für die Installation der Anwendungen auf den Rechnern verantwortlich sind und die Benutzer auch keine ausführbaren Programme runterladen dürfen, haben wir von der Seite aus ein wenig Sicherheit, ich sehe aber ein dass es sich auch um eine trügerische Sicherheit handel könnte. 

    Danke für die Hinweise.

    Viele Grüße,

    Volker


    Freitag, 12. September 2014 07:00
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    die Unterschiede sehen wir darin, dass man mit dem Management Studio per Se mehr anrichten kann (Backup, Restore, Datenbank trennen usw.). Ich weiß das vieles auch über Skripte aus Excel o.ä. heraus ausführbar wäre.

    Da sind wir dann schnell wieder bei den Berechtigungen der Benutzer auf dem Server was auch Andreas schon angesprochen hat. Da muss ich wohl nochmal dran. :-)

    Wie ich auch Andreas schon geschrieben habe, war mir nicht klar, dass man den Anwendungsnamen des SSMS so einfach ändern kann.

    Danke Dir auch für die Hinweise.

    Viele Grüße,

    Volker

    Freitag, 12. September 2014 07:10
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Christoph,

    dann erwische ich Dich nicht. :-)

    An die Berechtigungen der einzelnen Benutzer bzw. Gruppen auf dem Server - neben den Anwendungsberechtigungen - muss ich dann wohl nochmal ran...

    Danke und Gruß,

    Volker


    Freitag, 12. September 2014 07:19
    |
  • Question
    Anmelden
    0
    Anmelden

    die Unterschiede sehen wir darin, dass man mit dem Management Studio per Se mehr anrichten kann (Backup, Restore, Datenbank trennen usw.).

    Hallo Volker,

    Nein, kann man nicht, es geht nur in SSMS bequemer per Klickie-Buntie und selbst Rookies können es damit. Aber SSMS macht auch nichts anderes als T-SQL Statements an den SQL Server um Aktionen wie Backup/Detach etc. auszuführen und die Statements kann man auch aus MS Excel absetzten; man muss nur das Statement kennen.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 12. September 2014 07:35
    |