Come negare l'accesso a SQL Server per un determinato accesso tramite SSMS, ma consentire tramite .Net SqlClient Data Provider

Abbiamo una situazione in cui gli sviluppatori non dispongono di UPDATEautorizzazioni, MA lavorano con le applicazioni e vedono le stringhe di connessione -> conoscono le password di alcuni account SQL (esempio SQLLogin1) che dispongono di autorizzazioni UPDATE. Le nostre operazioni al momento non sono perfette e, a volte, i dati di produzione devono essere modificati (non è ancora disponibile una GUI).

Invece di contattare DBA e chiedergli di modificare i dati, lo sviluppatore dovrebbe (impropriamente) utilizzare l'account SQL SQLLogin1(che dispone dell'autorizzazione per modificare i dati) e connettersi tramite SQL Server Management Studio per modificare i dati.

DBA non può modificare la password SQLLogin1senza che Developer visualizzi la nuova stringa di connessione e la nuova password, poiché la stringa di connessione dell'applicazione che utilizza SQLLogin1viene gestita da Developer.

Domanda:

C'è un modo per negare l'accesso al SQLLogin1login SQL, ma solo se si sta connettendo tramite SSMS?

Allo stesso tempo, se si SQLLogin1sta connettendo tramite .Net SqlClient Data Provider( program_namein sys.dm_exec_sessions), deve essere consentito il login.

In questo modo non vogliamo consentire allo sviluppatore di connettersi tramite SSMS utilizzando SQLLogin1, mentre l'applicazione che sta utilizzando SQLLogin1, sarebbe comunque in grado di connettersi.

È possibile utilizzare un trigger di accesso al server per effettuare convalide di accesso personalizzate e rifiutarle ogni volta che lo ritengono opportuno. Vedrai questo trigger elencato sotto "Oggetti server" e dentro "Trigger" se stai usando SSMS.

Per esempio:

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

L' ROLLBACKinterno del trigger rifiuta la connessione (esiste una transazione implicita che avvolge la chiamata al trigger sull'evento di accesso).

Prestare attenzione durante l'implementazione dei trigger di accesso, se non codificato correttamente si rifiuteranno accessi che dovrebbero essere in grado di accedere (incluso il proprio!). Assicurati di testare prima su ambienti test / dev.

Tenere presente che questo codice viene eseguito prima della creazione della sessione , quindi le viste di sistema che si basano sull'ID sessione (SPID) non conterranno l'accesso attualmente verificato fino a quando i trigger non terminano senza rollback o errori sufficientemente elevati.

Penso che non ci sia una soluzione affidabile per il tuo problema poiché Application Nameè modificabile parameterche la cam possa essere cambiata da qualsiasi utente.

Ecco come modificarlo in SSMS:

Nella Connect to Database Objectfinestra di dialogo scegli Opzioni, apri Additional Connection Parameterse scegli un nome qualsiasi Application Namecome questo:

Ora sys.dm_exec_sessionsDMV e Program_name () ti mostreranno cosa hai passato nella stringa di connessione nel Application Nameparametro:

Non è possibile tagliare un cliente specifico, come già dettagliato nelle altre risposte.

La soluzione è rimuovere i privilegi di accesso ai sistemi di produzione dagli account dello sviluppatore.

Qualsiasi modifica deve essere eseguita tramite script e un dba eseguirà lo script.

La distribuzione viene eseguita da un amministratore di sistema; Gli sviluppatori producono un pacchetto che danno a qualcuno con i privilegi adeguati e gli sviluppatori non vedono mai le configurazioni utilizzate nei sistemi di produzione.

Il debug è organizzato caso per caso con una copia dei dati di produzione in un ambiente di gestione temporanea come soluzione preferita o un account temporaneo con privilegi limitati, se necessario.

1. Nel senso ideale, questo è un problema di processo / politica / gestione. Anche se qualcuno conosce la password, se è contro la politica aziendale per chiunque tranne un DBA connettersi alla produzione (beh, potresti avere un team di Release Engineering e / o amministratori di sistema, ecc.) E ci sono penalità per infrangere le regole, allora ciò dovrebbe essere sufficiente (supponendo che tali regole vengano applicate).

2. Cercare di impedire la connessione di una particolare applicazione è impossibile. Come dimostrato da sepupic , è abbastanza facile cambiare il "nome del programma". Ma anche se lo sviluppatore non riesce a capirlo, ci sono molti altri programmi che possono connettersi a SQL Server. Molte persone avranno accesso a SQLCMD.exe e persino a OSQL.exe deprecato . Lo sviluppatore può connettersi da Visual Studio e può persino creare la propria app per connettersi tramite ".Net SqlClient Data Provider". Oh, e ora abbiamo anche Azure Data Studio. Sono troppi.

3. Tuttavia, ciò potrebbe essere ancora possibile se ci avviciniamo dall'altra direzione: invece di impedire la connessione dell'applicazione X, che ne dici di consentire solo all'applicazione Y di connettersi? Certo, entriamo di nuovo nel "nome del programma" e persino "nome host" può essere falsificato, MA sono abbastanza sicuro che l'indirizzo IP del client non possa essere falsificato (almeno non tramite le parole chiave della stringa di connessione). Conosci l'indirizzo IP dei server delle app o puoi trovarlo facilmente dal sys.dm_exec_connectionsDMV (nel client_net_addresscampo).

   A partire dal trigger di accesso suggerito da EzLo , possiamo modificare la logica che determina se la connessione è valida o meno:

   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;

   L'unico modo per ora sarebbe accedere alla macchina di produzione o fare in modo che la propria workstation falsifichi l'IP del server delle app. Speriamo che gli sviluppatori non abbiano alcun accesso per accedere a Production. E lo spoofing di un IP esistente su una rete causa problemi che potrebbero influenzare negativamente la produzione, quindi non ci proveranno, giusto? Giusto?

In precedenza ho lavorato per un'azienda che aveva questo problema con uno sviluppatore. È stato licenziato, ma abbiamo anche implementato una tabella con LoginName e AllowMachine (Application Server) tramite un trigger di accesso. Questo ha risolto i nostri problemi. O forse era dovuto al fuoco.