Acceso a Datos (Mejores practicas)

On Tue, 22 May 2007 10:58:02 +0200, "Jesús López"
wrote:

No estoy de acuerdo Alberto.

Yo si :)

Sin embargo, los procedimientos almacenados siguen teniendo ventajas de
seguridad. Por ejemplo puedes crear un procedimiento para eliminar un
registro y dar permiso de ejecución de este procedimiento a los usuarios.
Así los usuarios pueden eliminar registros, pero DE UNO EN UNO. Por otra
parte si utilizas la instrucción DELETE directamente desde la aplicación
tienes que dar permiso de delete sobre la tabla a los usuarios, con lo que
un usurario PUEDE ELIMINAR TODOS LOS REGISTROS DE LA TABLA DE UNA SOLA VEZ,
usando la instrucción DELETE FROM LaTabla sin cláusula WHERE. Lo mismo
ocurre para insert y update.

La seguridad es la misma, lo único que pasa es que van a tardar un
poco más en borrar toda la tabla. El problema es que a las
aplicaciones que hagan un uso legítimo de la base de datos les va a
pasar lo mismo. Perjudicas a los usuarios que sabes que existen para
ponerles las cosas un poco más incómodas a supuestos hackers que no
sabes si existen.

Además a los hackers hasta les gusta que les pongan las cosas
difíciles :-)

Otra ventaja de los procedimientos almacenados es la encapsulación.

Pero es la forma más primitiva de encapsulación que tienen los SGBD
SQL. Es mejor encapsular con vistas siempre que se pueda.


Saludos

Excelentes opiniones...

La verdad, yo estoy de acuerdo con la encapsulación de todo en stored
procedures, sin embargo, por rapidez (y presión) en el desarrollo de
aplicaciones a veces se opta por colocar las sentencias SQL en el
codigo.

Como soy desarrollador y no me considero ni de cerca un DBA (Aunque
puedo hacer cualquier stored procedure), no entiendo el concepto de
"Planes de Ejecución de SQL Server", ni sus atributos ni propiedades.

Gracias por sus opiniones.. y ojalá existiera un consenso sobre el
tema..

Saludos

On 22 May 2007 09:06:43 -0700, wrote:

La verdad, yo estoy de acuerdo con la encapsulación de todo en stored
procedures,

¿Y que se consigue con eso además de aumentar los costes de
desarrollo?

Mayor rendimiento no. Mayor seguridad tampoco.


Saludos

Dios me libre de tener la responsabilidad de administrar una aplicación cuya
seguridad haya sido diseñada por una persona que piense que es lo mismo dar
permiso para eliminar un registro que dar permiso para eliminar todos los
registros de golpe.

No sólo es una cuestión de seguridad sino de intentar evitar que alguien
inadvertidamente elimine más registros de los que realmente quiere eliminar.
Toda precaución es poca, sobre todo con los usuario "avanzados" que son
capaces de usar el Excel para ejecutar consultas contra SQL Server y hacer
estropicios.

Hasta el momento, que yo sepa, no hay otra forma de encapsular un SGDB y que
proporcione la misma funcionalidad que los procedimientos almacenados, por
muy primitiva que te parezca.

No tengo nada en contra de las vistas y otros artefactos, pero no
proporcionan la misma funcionalidad que los procedimientos almacenados.


Saludos:


Jesús López





"Alfredo Novoa" escribió en el mensaje
news:

On Tue, 22 May 2007 10:58:02 +0200, "Jesús López"
wrote:

No estoy de acuerdo Alberto.

Yo si :)

Sin embargo, los procedimientos almacenados siguen teniendo ventajas de
seguridad. Por ejemplo puedes crear un procedimiento para eliminar un
registro y dar permiso de ejecución de este procedimiento a los usuarios.
Así los usuarios pueden eliminar registros, pero DE UNO EN UNO. Por otra
parte si utilizas la instrucción DELETE directamente desde la aplicación
tienes que dar permiso de delete sobre la tabla a los usuarios, con lo que
un usurario PUEDE ELIMINAR TODOS LOS REGISTROS DE LA TABLA DE UNA SOLA
VEZ,
usando la instrucción DELETE FROM LaTabla sin cláusula WHERE. Lo mismo
ocurre para insert y update.

La seguridad es la misma, lo único que pasa es que van a tardar un
poco más en borrar toda la tabla. El problema es que a las
aplicaciones que hagan un uso legítimo de la base de datos les va a
pasar lo mismo. Perjudicas a los usuarios que sabes que existen para
ponerles las cosas un poco más incómodas a supuestos hackers que no
sabes si existen.

Además a los hackers hasta les gusta que les pongan las cosas
difíciles :-)

Otra ventaja de los procedimientos almacenados es la encapsulación.

Pero es la forma más primitiva de encapsulación que tienen los SGBD
SQL. Es mejor encapsular con vistas siempre que se pueda.


Saludos

Mayor rendimiento sí. Mayor seguridad también.

Decir sí o no, es muy fácil. Dar argumentos es otra historia

Saludos:

Jesús López




"Alfredo Novoa" escribió en el mensaje
news:

On 22 May 2007 09:06:43 -0700, wrote:

La verdad, yo estoy de acuerdo con la encapsulación de todo en stored
procedures,

¿Y que se consigue con eso además de aumentar los costes de
desarrollo?

Mayor rendimiento no. Mayor seguridad tampoco.


Saludos