Cambio de contexto de ejecución en el interior de disparo de inicio de sesión

Question

Tengo una base de datos llamada MyDB en un caso expreso de Microsoft SQL Server 2008 mediante la autenticación de modo mixto. La aplicación que utiliza la base de datos actualmente MyDB se conecta utilizando la autenticación de Windows, usando las credenciales de Windows del usuario actual. Este inicio de sesión es un miembro de la función de servidor 'público', y tiene un usuario asignado a él en la base de datos MyDB. Este usuario base de datos es un miembro de las funciones de base de datos db_datareader y db_datawriter.

Lo que me gustaría es que cuando se conecta la aplicación, que tiene permisos para leer y escribir en MyDB. Pero cuando otra aplicación se conecta utilizando el mismo nombre de usuario, que sólo debe ser permitido leer.

Mi pensamiento era que me gustaría crear un disparador de inicio de sesión, lo que marque la parte del nombre de la aplicación de la cadena de conexión, y en base a que decida si el contexto de ejecución debe ser cambiado. (Para el registro, sé que no es en absoluto seguro que confiar en el nombre de la aplicación de la cadena de conexión, y que es muy fácil de burlar. El objetivo aquí no es para asegurar la base de datos, sino para ayudar a los usuarios evitar el cambio de los datos cuando se conectan mediante otra aplicación, como Microsoft Excel)

He creado un nuevo inicio de sesión llamada 'myapp_reader' asignada a un usuario en la base de datos MyDB, que es miembro de db_datareader.

Entonces intentado crear un disparador de inicio de sesión con la siguiente TSQL:

CREATE TRIGGER CheckUser
ON ALL SERVER
AFTER LOGON AS
BEGIN
IF APP_NAME() <> 'My Application Name'
    BEGIN
        EXECUTE AS LOGIN = 'myapp_reader' WITH NO REVERT
    END
END

Pero, por desgracia, no funciona. Cuando intento conectar me sale el siguiente error:

  

Conexión anómala de inicio de sesión 'Mi PC \ MyWindowsUsername' debido a la ejecución de disparo.
  contexto de la base cambiada a 'maestro'.
  configuración de idioma cambiado a us_english. (Microsoft SQL Server, error: 17892)

Y cuando miro en el registro de errores que dice:

  

Error: 15590, gravedad: 16, estado: 1.
  Sólo se puede utilizar el 'No Revert' o las opciones de 'cookie' con el "Ejecutar Como la declaración a nivel adhoc.
  Error: 17892, gravedad: 20, estado: 1.
  Conexión anómala de inicio de sesión 'Mi PC \ MyWindowsUsername' debido a la ejecución de disparo. [CLIENTE: xxx.xxx.xxx.xxx]

¿Significa este error no puedo cambiar permanentemente el contexto de ejecución en el gatillo de inicio de sesión?

Answer 1

No creo que su posible cambiar el contexto de ejecución durante toda la sesión. Se puede crear un desencadenador DML para INSERT, UPDATE y DELETE para cada tabla / vista en su base de datos que hace un retroceso para un determinado nombre_apl (). Se puede escribir un procedimiento para automatizar la creación de todos estos gatillo.

Por otra parte, si tuviera la opción de tener aplicaciones como Excel conectan a través de un servidor vinculado entonces se podría cambiar el contexto de ejecución en este punto. Y crear un disparador de inicio de sesión que deshace la conexión si los usuarios intentan conectarse a través de Excel u otras aplicaciones directamente en el servidor.

Answer 2

Si se asume que usted tiene el control de la aplicación y puede modificarlo, entonces las funciones de aplicación van a hacer exactamente lo que quiere. Ver sp_setapprole en los libros en pantalla para empezar.

Answer 3

No se puede hacer esto de la manera que desee.

• Una conexión de usuario tiene las mismas credenciales en todo excepto para algunos alcances específicos utilizando EXECUTE AS.
• Se han dado cuenta que no se puede confiar en APP_NAME () o HOST_NAME () para detectar cuando alguien se conecta de forma diferente, lo que significa un disparador de reversión por mesa no puede confiar en que hay
• Su aplicación se basa en el acceso directo de escritura tabla

Algunas opciones que se me ocurre ...

• Sus usos de aplicaciones almacena procs, los usuarios tienen acceso de lectura sólo a las tablas
• Utilice SET CONTEXT_INFO en su aplicación establezca una llave "secreta" para la restitución disparadores
• Cambiar la aplicación para utilizar una cuenta de servicio / es un servicio de Windows / etc y delegación en el nombre de usuario (como una página web haría)
• ... o algunas permutaciones therof

Answer 4

que realmente necesita para tomar una decisión sobre la forma de organizar y gestionar las credenciales en primer lugar.

Si utiliza sp_setapprole que eludir la autenticación de Windows y permitir el acceso a través de esa aplicación para cualquier usuario. Si eso es lo que realmente quiere hacer a continuación si la aplicación es crear un servidor de cuenta de usuario para esa aplicación y ejecutar el programa bajo las credenciales de ese usuario.

Si se trata de una aplicación de cliente a continuación, hacer un servicio web que sólo leer y enviar datos particulares que las necesidades de aplicación y ejecutar ese servicio web bajo nueva cuenta. Luego, en IIS7 se puede poner una ACL en la misma así que el servicio web que aún está protegida.

Además, si esa aplicación no es de confianza para ser limpio y saber lo que está haciendo y luego solicitar que tiene que ser revisado código antes de que se les permite tocar servidor SQL. Si es su propia aplicación a continuación, empezar a confiar en sí mismo: -)