Cómo denegar el acceso a SQL Server a cierto inicio de sesión a través de SSMS, pero permitir a través de .Net SqlClient Data Provider

Tenemos una situación en la que los Desarrolladores no tienen ningún UPDATEpermiso, PERO trabajan con aplicaciones y ven cadenas de conexión -> conocen las contraseñas de algunas cuentas SQL (ejemplo SQLLogin1) que tienen permisos de ACTUALIZACIÓN. Nuestras operaciones actualmente no son perfectas y, a veces, es necesario modificar los datos de producción (todavía no hay GUI para eso).

En lugar de contactar a DBA y pedirle que modifique los datos, el Desarrollador usaría (incorrectamente) una cuenta SQL SQLLogin1(que tiene permiso para modificar los datos) y se conectaría a través de SQL Server Management Studio para modificar los datos él mismo.

DBA no puede cambiar la contraseña SQLLogin1sin que el Desarrollador vea la nueva cadena de conexión y la nueva contraseña, ya que la cadena de conexión de la aplicación que utiliza SQLLogin1es mantenida por el Desarrollador.

Pregunta:

¿Hay alguna forma de denegar el acceso al SQLLogin1inicio de sesión de SQL, pero solo si se conecta a través de SSMS?

Al mismo tiempo, si se SQLLogin1está conectando .Net SqlClient Data Provider( program_nameen el sys.dm_exec_sessions), se debe permitir iniciar sesión.

De esta manera, no queremos permitir que Developer se conecte a través de SSMS usando SQLLogin1, mientras que la aplicación que está usando SQLLogin1, todavía podría conectarse.

Puede usar un disparador de inicio de sesión del servidor para realizar validaciones de inicio de sesión personalizadas y rechazarlas cuando lo considere oportuno. Verá este activador debajo de "Objetos de servidor" y dentro de "Activadores" si está utilizando SSMS.

Por ejemplo:

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

El ROLLBACKinterior del activador rechazará la conexión (hay una transacción implícita que envuelve la llamada al activador en el evento de inicio de sesión).

Tenga cuidado al implementar disparadores de inicio de sesión, si no está codificado correctamente, rechazará los inicios de sesión que deberían poder iniciar sesión (¡incluido el suyo!). Asegúrese de probar primero en entornos de prueba / desarrollo.

Tenga en cuenta que este código se ejecuta antes de que se cree la sesión , por lo que las vistas del sistema que dependen del ID de sesión (SPID) no contendrán el inicio de sesión actualmente verificado hasta que los desencadenadores finalicen sin una reversión o una falla lo suficientemente alta.

Creo que no hay una solución confiable para su problema, ya que Application Namees modificable parameterque cualquier usuario pueda cambiar la cámara.

Aquí está cómo cambiarlo dentro de SSMS:

En el Connect to Database Objectcuadro de diálogo, elija Opciones, abra Additional Connection Parametersy elija cualquier nombre para Application Nameesto:

Ahora sys.dm_exec_sessionsDMV y Program_name () le mostrarán lo que pasó en su cadena de conexión en el Application Nameparámetro:

No puede cortar un cliente específico, como ya se detalla en las otras respuestas.

La solución es eliminar los privilegios de acceso a los sistemas de producción de las cuentas del desarrollador.

Cualquier cambio debe ser programado y un dba ejecutará el script.

La implementación la realiza un administrador del sistema; los desarrolladores producen un paquete que le dan a alguien con los privilegios adecuados y los desarrolladores nunca ven las configuraciones utilizadas en los sistemas de producción.

La depuración se organiza caso por caso con una copia de los datos de producción en un entorno provisional como una solución preferida o una cuenta temporal con privilegios limitados si es necesario.

1. En el sentido ideal, este es un problema de proceso / política / gestión. Incluso si alguien conoce la contraseña, si va en contra de la política de la compañía que alguien que no sea un DBA se conecte a Producción (bueno, es posible que tenga un equipo de Release Engineering y / o administradores de sistemas, etc.), y existen sanciones por infringir las reglas, entonces eso debería ser suficiente (suponiendo que se apliquen tales reglas).

2. Intentar evitar que una aplicación en particular se conecte es imposible. Como demostró Sepupic , es bastante fácil cambiar el "nombre del programa". Pero incluso si el desarrollador no puede resolver eso, hay muchos otros programas que pueden conectarse a SQL Server. La mayoría de las personas tendrán acceso a SQLCMD.exe e incluso al obsoleto OSQL.exe . El desarrollador puede conectarse desde Visual Studio, e incluso puede crear su propia aplicación para conectarse a través de ".Net SqlClient Data Provider". Ah, y ahora incluso tenemos Azure Data Studio. Son demasiados

3. Aún así, esto podría ser posible si lo enfocamos desde la otra dirección: en lugar de evitar que la aplicación X se conecte, ¿qué tal si solo permitimos que la aplicación Y se conecte? Claro, nuevamente ingresamos al "nombre del programa", e incluso el "nombre de host" puede ser falsificado, PERO, estoy bastante seguro de que la dirección IP del cliente no puede ser falsificada (al menos no a través de las palabras clave de la cadena de conexión). Conoce la dirección IP de los servidores de aplicaciones o puede encontrarla fácilmente desde el sys.dm_exec_connectionsDMV (en el client_net_addresscampo).

   Comenzando con el Logon Trigger sugerido por EzLo , podemos modificar la lógica que determina si la conexión es válida o no es la siguiente:

   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;
   

   Las únicas formas en este momento serían iniciar sesión en la máquina de producción o hacer que su estación de trabajo falsifique la IP del servidor de aplicaciones. Esperemos que los desarrolladores no tengan acceso para iniciar sesión en Producción. Y falsificar una IP existente en una red causa problemas que podrían afectar negativamente a la producción, por lo que no lo intentarán, ¿verdad? ¿Derecho?

Anteriormente trabajé para una empresa que tenía este problema con un desarrollador. Fue despedido, pero también implementamos una tabla que tenía LoginName y AllowMachine (Application Server) a través de un desencadenador de inicio de sesión. Esto resolvió nuestros problemas. O tal vez se debió a los disparos.