manejo de contraseñas en sql server

10/12/2004 - 21:28 por Juan Carlos | Informe spam
Hola:

Tengo una duda de como diseñar la parte de seguridad para una aplicación que
usa SQL Server.

Para un sistema que estamos construyendo es parte de los requerimientos de
alguna forma manejar usuarios y contraseñas de acceso al programa, donde
además los usuarios y contraseñas tienen que caducar cada cierto tiempo
configurable, y que cuando las contraseñas hayan caducado, el sistema le
pueda ofrecer al usuario cambiar la contraseña.

Este sistema hace uso de SQL Server 2000 para almacenar/recuperar los datos.
Los datos van a ser principalmente un registro (una especie de "log" ) de
operaciones llevadas a cabo por los usuarios. La aplicación va a correr en
un conjunto chico de PCs dedicados que usan un SQL server para acceder a los
datos.
Para todos los registros de la base de datos se tiene que tener el usuario
que ejecuto la operacion (el registro "registra" esa operación).
Como dije, los PCs son dedicados y no existe un servidor de dominio en la
red. Todas las máquinas tendrían Windows XP.

La duda me surge es cuál es la mejor forma de hacer este manejo de
usuarios/contraseñas tanto para el acceso al sistema como para la base de
datos. No tengo mucha experiencia en estas cosas, asì que agradezco su
ayuda.

Se me ocurren por ejemplo:
1) Que la autenticación al sistema sea a través del sistema operativo, que
el acceso a la base de datos sea un acceso "integrado" y que el manejo de la
caducidad de usuarios y contraseñas se haga en el servidor (Windows XP).
2) Que la autenticación al sistema se haga contra el SQL Server, que en SQL
Server se haga todo el manejo de usuarios/contraseñas. El tema de la
caducidad no sé como sería (no sé si se puede hacer ese control en SQL
Server).
3) Que todo el tema de usuarios/permisos/caducidad sea manejado por la
aplicación (lo que no implica que no sea almacenado en la base de datos) y
el acceso a la base de datos sea con un usuario y contraseña "hardcodeados"
(fijos para la aplicación).

Saludos,
Juan Carlos

Preguntas similare

Leer las respuestas

#6 MAXI
10/12/2004 - 23:44 | Informe spam
Hola, pues mira has pensado hacerlo en c# en lugar de c++?




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"Juan Carlos" escribió en el mensaje
news:
Gracias a ambos por sus respuestas.

Usaré triggers entonces.

Para la parte de de seguridad de la aplicación, es una aplicación Win32
hecha en Visual C++ .NET , por lo que supongo que no me sirve el
"application block".
Todavía no sé como crear usuarios de Windows desde Visual C++ pero lo
averiguaré por otro lado.

Muchas gracias,
Juan Carlos


"MAXI" escribió en el mensaje
news:
Hola para tu primer pregunta te envio un articulo que escribi sobre dicho
tema, leelo que seguro te ayuda mucho ;)

Para la segunda pregunta te comento:

Una opcion puede ser la que indicas y la otra que levantes el usuario de
windows y uses ese para definirle los permisos. La recomendacion de Gux
es
adecuada si usas :NET, de todas formas miralo antes de implementar porque
ese AP tiene algunos detalles :(

http://www.microsoft.com/spanish/ms...art168.asp

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"Juan Carlos" escribió en el mensaje
news:
> Bueno, muchas gracias por la respuesta.
>
> ¿Para la parte de registrar quien hizo cada cambio que seria mejor?
> ¿Uso triggers que setean automáticamente para cada registro quién fue
> el
> usuario que lo originó (a nivel de base de datos) o lo inserto desde la
> aplicación (por ejemplo obteniendo el usuario desde la variable de


entorno
> "USERNAME")?
>
> La parte de autenticacion "en la aplicación" con seguridad integrada


sería
> definiendo grupos a nivel del sistema operativo y obteniendo el grupo
> desde
> el sistema operativo?
>
> Gracias,
> Juan Carlos.
>
>
> "Maxi" escribió en el mensaje
> news:u1$h$
>> Hola, mira lo mejor seria usar seguridad integrada y darle al SO el
>> manejo
>> que estas comentando. Esto es valido si todas las estaciones de
>> trabajo
> son
>> clientes Windows, de lo contrario no podras aprovechar esta ventaja :(
>>
>> Otro tema es la autentificacion a la aplicacion ( o sea, que cosas


puede
>> o
>> no hacer dicho usuario dentro de esta ), esto tambien lo podrias hacer
>> con
>> seguridad integrada o bien guardar los registros en una tabla y ahi
>> establecer los permisos.
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Juan Carlos" escribió en el mensaje
>> news:
>> > Hola:
>> >
>> > Tengo una duda de como diseñar la parte de seguridad para una
>> > aplicación
>> > que
>> > usa SQL Server.
>> >
>> > Para un sistema que estamos construyendo es parte de los


requerimientos
> de
>> > alguna forma manejar usuarios y contraseñas de acceso al programa,
>> > donde
>> > además los usuarios y contraseñas tienen que caducar cada cierto


tiempo
>> > configurable, y que cuando las contraseñas hayan caducado, el
>> > sistema
>> > le
>> > pueda ofrecer al usuario cambiar la contraseña.
>> >
>> > Este sistema hace uso de SQL Server 2000 para almacenar/recuperar
>> > los
>> > datos.
>> > Los datos van a ser principalmente un registro (una especie de


"log" )
> de
>> > operaciones llevadas a cabo por los usuarios. La aplicación va a


correr
> en
>> > un conjunto chico de PCs dedicados que usan un SQL server para


acceder
>> > a
>> > los
>> > datos.
>> > Para todos los registros de la base de datos se tiene que tener el
> usuario
>> > que ejecuto la operacion (el registro "registra" esa operación).
>> > Como dije, los PCs son dedicados y no existe un servidor de dominio


en
> la
>> > red. Todas las máquinas tendrían Windows XP.
>> >
>> > La duda me surge es cuál es la mejor forma de hacer este manejo de
>> > usuarios/contraseñas tanto para el acceso al sistema como para la


base
> de
>> > datos. No tengo mucha experiencia en estas cosas, asì que agradezco


su
>> > ayuda.
>> >
>> > Se me ocurren por ejemplo:
>> > 1) Que la autenticación al sistema sea a través del sistema


operativo,
> que
>> > el acceso a la base de datos sea un acceso "integrado" y que el


manejo
> de
>> > la
>> > caducidad de usuarios y contraseñas se haga en el servidor (Windows
>> > XP).
>> > 2) Que la autenticación al sistema se haga contra el SQL Server, que


en
>> > SQL
>> > Server se haga todo el manejo de usuarios/contraseñas. El tema de la
>> > caducidad no sé como sería (no sé si se puede hacer ese control en


SQL
>> > Server).
>> > 3) Que todo el tema de usuarios/permisos/caducidad sea manejado por


la
>> > aplicación (lo que no implica que no sea almacenado en la base de
>> > datos)
> y
>> > el acceso a la base de datos sea con un usuario y contraseña
>> > "hardcodeados"
>> > (fijos para la aplicación).
>> >
>> > Saludos,
>> > Juan Carlos
>> >
>> >
>>
>>
>
>






Respuesta Responder a este mensaje
#7 Juan Carlos
11/12/2004 - 00:35 | Informe spam
El tema es que la aplicación ya está hecha.
Se está adaptando para cumplir con los requerimientos del "Part11" del FDA
(del que nunca habrán visto ni oído).
Y bueno, no está en los planes "rehacerla".

Saludos,
Juan Carlos

"MAXI" escribió en el mensaje
news:
Hola, pues mira has pensado hacerlo en c# en lugar de c++?




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"Juan Carlos" escribió en el mensaje
news:
> Gracias a ambos por sus respuestas.
>
> Usaré triggers entonces.
>
> Para la parte de de seguridad de la aplicación, es una aplicación Win32
> hecha en Visual C++ .NET , por lo que supongo que no me sirve el
> "application block".
> Todavía no sé como crear usuarios de Windows desde Visual C++ pero lo
> averiguaré por otro lado.
>
> Muchas gracias,
> Juan Carlos
>
>
> "MAXI" escribió en el mensaje
> news:
>> Hola para tu primer pregunta te envio un articulo que escribi sobre


dicho
>> tema, leelo que seguro te ayuda mucho ;)
>>
>> Para la segunda pregunta te comento:
>>
>> Una opcion puede ser la que indicas y la otra que levantes el usuario


de
>> windows y uses ese para definirle los permisos. La recomendacion de Gux
>> es
>> adecuada si usas :NET, de todas formas miralo antes de implementar


porque
>> ese AP tiene algunos detalles :(
>>
>>


http://www.microsoft.com/spanish/ms...art168.asp
>>
>> Un abrazo
>>
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>> Mail: Maxi_accotto[arroba]speedy.com.ar
>>
>> Msn Messenger:
>>
>> "Juan Carlos" escribió en el mensaje
>> news:
>> > Bueno, muchas gracias por la respuesta.
>> >
>> > ¿Para la parte de registrar quien hizo cada cambio que seria mejor?
>> > ¿Uso triggers que setean automáticamente para cada registro quién fue
>> > el
>> > usuario que lo originó (a nivel de base de datos) o lo inserto desde


la
>> > aplicación (por ejemplo obteniendo el usuario desde la variable de
> entorno
>> > "USERNAME")?
>> >
>> > La parte de autenticacion "en la aplicación" con seguridad integrada
> sería
>> > definiendo grupos a nivel del sistema operativo y obteniendo el grupo
>> > desde
>> > el sistema operativo?
>> >
>> > Gracias,
>> > Juan Carlos.
>> >
>> >
>> > "Maxi" escribió en el mensaje
>> > news:u1$h$
>> >> Hola, mira lo mejor seria usar seguridad integrada y darle al SO el
>> >> manejo
>> >> que estas comentando. Esto es valido si todas las estaciones de
>> >> trabajo
>> > son
>> >> clientes Windows, de lo contrario no podras aprovechar esta ventaja


:(
>> >>
>> >> Otro tema es la autentificacion a la aplicacion ( o sea, que cosas
> puede
>> >> o
>> >> no hacer dicho usuario dentro de esta ), esto tambien lo podrias


hacer
>> >> con
>> >> seguridad integrada o bien guardar los registros en una tabla y ahi
>> >> establecer los permisos.
>> >>
>> >>
>> >> Salu2
>> >> Maxi
>> >>
>> >>
>> >> "Juan Carlos" escribió en el mensaje
>> >> news:
>> >> > Hola:
>> >> >
>> >> > Tengo una duda de como diseñar la parte de seguridad para una
>> >> > aplicación
>> >> > que
>> >> > usa SQL Server.
>> >> >
>> >> > Para un sistema que estamos construyendo es parte de los
> requerimientos
>> > de
>> >> > alguna forma manejar usuarios y contraseñas de acceso al programa,
>> >> > donde
>> >> > además los usuarios y contraseñas tienen que caducar cada cierto
> tiempo
>> >> > configurable, y que cuando las contraseñas hayan caducado, el
>> >> > sistema
>> >> > le
>> >> > pueda ofrecer al usuario cambiar la contraseña.
>> >> >
>> >> > Este sistema hace uso de SQL Server 2000 para almacenar/recuperar
>> >> > los
>> >> > datos.
>> >> > Los datos van a ser principalmente un registro (una especie de
> "log" )
>> > de
>> >> > operaciones llevadas a cabo por los usuarios. La aplicación va a
> correr
>> > en
>> >> > un conjunto chico de PCs dedicados que usan un SQL server para
> acceder
>> >> > a
>> >> > los
>> >> > datos.
>> >> > Para todos los registros de la base de datos se tiene que tener el
>> > usuario
>> >> > que ejecuto la operacion (el registro "registra" esa operación).
>> >> > Como dije, los PCs son dedicados y no existe un servidor de


dominio
> en
>> > la
>> >> > red. Todas las máquinas tendrían Windows XP.
>> >> >
>> >> > La duda me surge es cuál es la mejor forma de hacer este manejo de
>> >> > usuarios/contraseñas tanto para el acceso al sistema como para la
> base
>> > de
>> >> > datos. No tengo mucha experiencia en estas cosas, asì que


agradezco
> su
>> >> > ayuda.
>> >> >
>> >> > Se me ocurren por ejemplo:
>> >> > 1) Que la autenticación al sistema sea a través del sistema
> operativo,
>> > que
>> >> > el acceso a la base de datos sea un acceso "integrado" y que el
> manejo
>> > de
>> >> > la
>> >> > caducidad de usuarios y contraseñas se haga en el servidor


(Windows
>> >> > XP).
>> >> > 2) Que la autenticación al sistema se haga contra el SQL Server,


que
> en
>> >> > SQL
>> >> > Server se haga todo el manejo de usuarios/contraseñas. El tema de


la
>> >> > caducidad no sé como sería (no sé si se puede hacer ese control en
> SQL
>> >> > Server).
>> >> > 3) Que todo el tema de usuarios/permisos/caducidad sea manejado


por
> la
>> >> > aplicación (lo que no implica que no sea almacenado en la base de
>> >> > datos)
>> > y
>> >> > el acceso a la base de datos sea con un usuario y contraseña
>> >> > "hardcodeados"
>> >> > (fijos para la aplicación).
>> >> >
>> >> > Saludos,
>> >> > Juan Carlos
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>


email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida