none
capturar usuario RRS feed

  • Pregunta

  • tenemos un aplicativo tipo web realizado en C#. el cual se conecta a la db con un usuario  que tiene las mismas caracteristicas del usuario 'sa' (los datos de conexion los saca de un archivo xml). Despues de conectado valida el usuario y la clave  en la tabla  usuarios.

    pregunta:

    Esta bien ese metodo de conexion a la base de datos?

    Si yo quisiera realizar un trigger para auditar los cambios que se realicen a  'X' tabla. como puedo capturar el usuario que realizo dicho cambio? y no el  superusuario.

    Si quiero ver los  usuarios conectados y que actualmente presentan un bloqueo en el sistema, cual seria el metodo para identificarlos


    lunes, 10 de octubre de 2016 14:22

Respuestas

  • Esta bien ese metodo de conexion a la base de datos?

    No es buena idea desde el punto de vista de la seguridad. Utiliza un usuario con los mínimos privilegios posibles (si solo es para validar usuarios, bastaría con que tenga acceso en solo-lectura a la tabla de usuarios).

    Si yo quisiera realizar un trigger para auditar los cambios que se realicen a  'X' tabla. como puedo capturar el usuario que realizo dicho cambio? y no el  superusuario.

    Hay varias opciones. La primera es que todos los usuarios estén en la tabla de usuarios del SQL y se conecten con sus propias credenciales (en lugar de usar un usuario fijo en la cadena de conexión para todos ellos). De esta manera, el servidor sabe quién es el usuario y puedes capturarlo dentro de un trigger con el User_name() o sus variantes, o puedes ahorrarte el trigger y activar el SQL Audit, que también conocerá el usuario.

    Eso tiene el inconveniente de que hay que asignar permisos a todos los usuarios que se conectan. Se puede evitar usando los roles de aplicación. Nada más abrir la conexión se hace un sp_setapprole, y se activa un rol que es el que tiene los permisos. Y al usuario no se le dan directamente permisos sobre las tablas, lo cual es más seguro, pero el sistema sigue sabiendo quién es el usuario para poderlo auditar.

    Finalmente, si no se puede hacer que cada usuario haga login con sus credenciales en SQL Server, otra opción es gestionar la auditoría desde el código cliente. Si es una aplicación en varias capas, se hace la auditoría desde la capa de datos. Y si son varias aplicaciones, se hace una arquitectura SOA y todas las aplicaciones pasan por un webservice para acceder a datos, y ahí se hace la auditoría.

    Si quiero ver los  usuarios conectados y que actualmente presentan un bloqueo en el sistema, cual seria el metodo para identificarlos

    Posiblemente lo más directo sea un select sobre sys.dm_tran_locks.
    lunes, 10 de octubre de 2016 17:26
  • le puedes dar permisos de ejecución a un rol.

    Puedes crear un rol especifico, con los permisos que necesites, y añadir en tu bbdd los usuarios a ese rol.

    Desde ese punto de vista podrías hacer lo siguiente.

    1. En tu app web tienes un formulario que te pide usuario y contraseña. Con estas credenciales, sin almacenar en ningún sitio simplemente se las pasas a sql como usuario y password. Así por ejemplo podrás entrar con el  superusuario que has creado.

    2.- En el lugar donde añades usuarios (los metes en tu tabla xxx), simplemente ejecutas el comando créate login correspondiente y el créate user, además puedes añadir ese usuario a un rol creado para la base de datos

    3.- Ese rol es el que tiene que tener los permisos, dale los mínimos, y conforme veas que te falla ve añadiéndole. Por ejemplo, lectura en los objetos que sepas sguro que se lean y ejecución en los procedimientos que ejecutes. Si no lees nunca con un SELECT solo necesitaras dar permisos de ejcución a los procedimientos.

    Con esta aproximación realmente tus aplicación no tiene que guardar una tabla con el user (ni con el password), simplemente tiene que conectarse con las credenciales que te pasen y el alta de usuarios, crea todo, con lo que no tiene que ser más trabajo de administración.


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    lunes, 10 de octubre de 2016 20:10
    Moderador

Todas las respuestas

  • Esta bien ese metodo de conexion a la base de datos?

    No es buena idea desde el punto de vista de la seguridad. Utiliza un usuario con los mínimos privilegios posibles (si solo es para validar usuarios, bastaría con que tenga acceso en solo-lectura a la tabla de usuarios).

    Si yo quisiera realizar un trigger para auditar los cambios que se realicen a  'X' tabla. como puedo capturar el usuario que realizo dicho cambio? y no el  superusuario.

    Hay varias opciones. La primera es que todos los usuarios estén en la tabla de usuarios del SQL y se conecten con sus propias credenciales (en lugar de usar un usuario fijo en la cadena de conexión para todos ellos). De esta manera, el servidor sabe quién es el usuario y puedes capturarlo dentro de un trigger con el User_name() o sus variantes, o puedes ahorrarte el trigger y activar el SQL Audit, que también conocerá el usuario.

    Eso tiene el inconveniente de que hay que asignar permisos a todos los usuarios que se conectan. Se puede evitar usando los roles de aplicación. Nada más abrir la conexión se hace un sp_setapprole, y se activa un rol que es el que tiene los permisos. Y al usuario no se le dan directamente permisos sobre las tablas, lo cual es más seguro, pero el sistema sigue sabiendo quién es el usuario para poderlo auditar.

    Finalmente, si no se puede hacer que cada usuario haga login con sus credenciales en SQL Server, otra opción es gestionar la auditoría desde el código cliente. Si es una aplicación en varias capas, se hace la auditoría desde la capa de datos. Y si son varias aplicaciones, se hace una arquitectura SOA y todas las aplicaciones pasan por un webservice para acceder a datos, y ahí se hace la auditoría.

    Si quiero ver los  usuarios conectados y que actualmente presentan un bloqueo en el sistema, cual seria el metodo para identificarlos

    Posiblemente lo más directo sea un select sobre sys.dm_tran_locks.
    lunes, 10 de octubre de 2016 17:26
  • El programa realizado en ambiente web; la mayor parte llama o  ejecuta procedimientos.

    en el primer punto..., si fuese de solo lectura (para verificar el usuario). Como se haria para que  a la hora de llamar o ejecutar un procedimiento(el cual toca la db). No  le afecte el tipo de permiso inicial(solo lectura).

    lunes, 10 de octubre de 2016 19:35
  • le puedes dar permisos de ejecución a un rol.

    Puedes crear un rol especifico, con los permisos que necesites, y añadir en tu bbdd los usuarios a ese rol.

    Desde ese punto de vista podrías hacer lo siguiente.

    1. En tu app web tienes un formulario que te pide usuario y contraseña. Con estas credenciales, sin almacenar en ningún sitio simplemente se las pasas a sql como usuario y password. Así por ejemplo podrás entrar con el  superusuario que has creado.

    2.- En el lugar donde añades usuarios (los metes en tu tabla xxx), simplemente ejecutas el comando créate login correspondiente y el créate user, además puedes añadir ese usuario a un rol creado para la base de datos

    3.- Ese rol es el que tiene que tener los permisos, dale los mínimos, y conforme veas que te falla ve añadiéndole. Por ejemplo, lectura en los objetos que sepas sguro que se lean y ejecución en los procedimientos que ejecutes. Si no lees nunca con un SELECT solo necesitaras dar permisos de ejcución a los procedimientos.

    Con esta aproximación realmente tus aplicación no tiene que guardar una tabla con el user (ni con el password), simplemente tiene que conectarse con las credenciales que te pasen y el alta de usuarios, crea todo, con lo que no tiene que ser más trabajo de administración.


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    lunes, 10 de octubre de 2016 20:10
    Moderador