So verweigern Sie den Zugriff auf SQL Server für bestimmte Anmeldungen über SSMS, lassen ihn jedoch über .NET SqlClient Data Provider zu

Wir haben eine Situation, in der Entwickler keine UPDATEBerechtigungen haben, ABER sie arbeiten mit Anwendungen und sehen Verbindungszeichenfolgen -> sie kennen Kennwörter von einigen SQL-Konten (Beispiel SQLLogin1), die UPDATE-Berechtigungen haben. Unsere Abläufe sind derzeit nicht perfekt, und manchmal müssen Produktionsdaten geändert werden (noch keine grafische Benutzeroberfläche).

Anstatt sich an DBA zu wenden und ihn zu bitten, die Daten zu ändern, würde der Entwickler (zu Unrecht) ein SQL-Konto SQLLogin1(das die Berechtigung zum Ändern der Daten hat) verwenden und eine Verbindung über SQL Server Management Studio herstellen, um die Daten selbst zu ändern.

Der DBA kann das Kennwort nicht ändern, SQLLogin1ohne dass der Entwickler die neue Verbindungszeichenfolge und das neue Kennwort sieht, da die verwendete Anwendungsverbindungszeichenfolge SQLLogin1vom Entwickler verwaltet wird.

Frage:

Gibt es eine Möglichkeit, den Zugriff auf die SQLLogin1SQL-Anmeldung zu verweigern , jedoch nur, wenn eine Verbindung über SSMS hergestellt wird?

Zur gleichen Zeit, wenn SQLLogin1eine Verbindung über .Net SqlClient Data Provider( program_namein sys.dm_exec_sessions) hergestellt wird, muss die Anmeldung gestattet sein.

Auf diese Weise möchten wir nicht, dass Entwickler über SSMS eine Verbindung herstellen SQLLogin1, während die verwendete Anwendung SQLLogin1weiterhin eine Verbindung herstellen kann.

Sie können einen Server-Anmeldetrigger verwenden , um benutzerdefinierte Anmeldeüberprüfungen durchzuführen und diese abzulehnen, wann immer Sie dies für richtig halten. Sie sehen diesen Trigger unter "Serverobjekte" und in "Trigger", wenn Sie SSMS verwenden.

Beispielsweise:

CREATE TRIGGER strRejectSSMSConnectionForSQLLogin1
ON ALL SERVER FOR LOGON
AS
BEGIN

    IF ORIGINAL_LOGIN() = N'SQLLogin1' AND PROGRAM_NAME() LIKE N'Microsoft SQL Server Management Studio%'
    BEGIN
        RAISERROR('Direct connection by SSMS refused.', 16, 1)
        ROLLBACK
    END

END

Das ROLLBACKInnere des Triggers lehnt die Verbindung ab (es gibt eine implizite Transaktion, die den Aufruf des Triggers für das Anmeldeereignis umschließt).

Seien Sie vorsichtig, wenn Sie Anmeldetrigger implementieren. Wenn Sie nicht richtig codiert sind, lehnen Sie Anmeldungen ab, die sich anmelden können sollten (einschließlich Ihrer eigenen!). Stellen Sie sicher, dass Sie zuerst in Test- / Entwicklungsumgebungen testen.

Beachten Sie, dass dieser Code vor dem Erstellen der Sitzung ausgeführt wird , sodass Systemansichten, die auf der Sitzungs-ID (SPID) basieren, die aktuell überprüfte Anmeldung erst enthalten, wenn die Trigger ohne Rollback oder ausreichend hohen Fehler beendet werden.

Ich denke, es gibt keine zuverlässige Lösung für Ihr Problem, da Application Namees modifizierbar ist, parameterdass die Kamera von jedem Benutzer geändert wird.

So ändern Sie es innerhalb SSMS:

Connect to Database ObjectWählen Sie im Dialogfeld Optionen, öffnen Sie Additional Connection Parametersund wählen Sie einen beliebigen Namen für Application NameFolgendes:

Jetzt zeigen sys.dm_exec_sessionsDMV und Program_name () an, was Sie in Ihrer Verbindungszeichenfolge im Application NameParameter übergeben haben:

Sie können einen bestimmten Client nicht abschneiden, wie bereits in den anderen Antworten beschrieben.

Die Lösung besteht darin, die Zugriffsrechte auf die Produktionssysteme aus den Konten des Entwicklers zu entfernen.

Jede Änderung muss per Skript ausgeführt werden, und eine Datenbank führt das Skript aus.

Die Bereitstellung wird von einem Systemadministrator durchgeführt. Entwickler erstellen ein Paket, das sie jemandem mit den richtigen Berechtigungen geben, und Entwickler sehen niemals die auf Produktionssystemen verwendeten Konfigurationen.

Das Debuggen wird von Fall zu Fall mit einer Kopie der Produktionsdaten in einer Staging-Umgebung als bevorzugte Lösung oder einem temporären Konto mit eingeschränkten Berechtigungen bei Bedarf arrangiert.

1. Im Idealfall handelt es sich hierbei um ein Prozess- / Richtlinien- / Managementproblem. Selbst wenn jemand das Kennwort kennt, wenn es gegen die Unternehmensrichtlinien verstößt, dass nur ein DBA eine Verbindung zur Produktion herstellt (möglicherweise haben Sie ein Release Engineering-Team und / oder Systemadministratoren usw.), und es gibt Strafen für Verstöße gegen die Regeln. dann sollte das ausreichen (vorausgesetzt, dass solche Regeln durchgesetzt werden).

2. Der Versuch, die Verbindung einer bestimmten Anwendung zu verhindern, ist nicht möglich. Wie Sepupic gezeigt hat , ist es ziemlich einfach, den "Programmnamen" zu ändern. Aber selbst wenn der Entwickler das nicht herausfinden kann, gibt es viele andere Programme, die eine Verbindung zu SQL Server herstellen können. Die meisten Benutzer haben Zugriff auf SQLCMD.exe und sogar auf die veraltete OSQL.exe . Der Entwickler kann von Visual Studio aus eine Verbindung herstellen und sogar eine eigene App erstellen, um über ".Net SqlClient Data Provider" eine Verbindung herzustellen. Oh, und jetzt haben wir sogar Azure Data Studio. Es sind einfach zu viele.

3. Dies könnte jedoch immer noch möglich sein, wenn wir uns der anderen Richtung nähern: Anstatt zu verhindern, dass Anwendung X eine Verbindung herstellt, können Sie nur zulassen, dass Anwendung Y eine Verbindung herstellt. Sicher, wir kommen wieder zum "Programmnamen" und sogar "Hostname" kann gefälscht werden, ABER ich bin mir ziemlich sicher, dass die IP-Adresse des Clients nicht gefälscht werden kann (zumindest nicht über die Schlüsselwörter der Verbindungszeichenfolge). Sie kennen die IP-Adresse des / der App-Server (s) oder können sie leicht über die sys.dm_exec_connectionsDMV (im client_net_addressFeld) finden.

   Beginnend mit dem von EzLo vorgeschlagenen Anmeldetrigger können wir die Logik ändern, die bestimmt, ob die Verbindung gültig ist oder nicht:

   IF (ORIGINAL_LOGIN() = N'SQLLogin1'
       AND (
                CONVERT(VARCHAR(10), CONNECTIONPROPERTY('net_transport')) <> 'TCP'
             OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address')) <> '10.10.10.10'
    -- uncomment below (and comment-out line above) if app uses multiple IP addresses
    --       OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address'))
    --                   NOT IN ( '10.10.10.10', '10.10.10.11', ...)
           ))
   BEGIN
       RAISERROR('Non-application connection refused.', 16, 1);
       ROLLBACK;
   END;
   

   Die einzige Möglichkeit besteht jetzt darin, sich entweder am Produktionscomputer anzumelden oder die IP-Adresse des App-Servers von der Workstation fälschen zu lassen. Hoffentlich haben Entwickler keinen Zugriff, um sich bei Production anzumelden. Und das Spoofing einer vorhandenen IP in einem Netzwerk verursacht Probleme, die sich nachteilig auf die Produktion auswirken können. Sie werden das also nicht versuchen, oder? Richtig?

Ich habe zuvor für eine Firma gearbeitet, die dieses Problem mit einem Entwickler hatte. Er wurde gefeuert, aber wir haben auch eine Tabelle implementiert, die den LoginName und AllowedMachine (Application Server) über einen Login-Trigger hatte. Dies löste unsere Probleme. Oder vielleicht lag es am Feuer.