Protegiendo la Base de Datos mediante procedimientos almacenados

Y es que íºltimamente le doy muchas vueltas a la protección del modelo de datos. Me quedan aíºn en la manga almenos un par de artí­culos más al respecto, siendo este uno de ellos.
Hoy hablaremos un poco de cómo proteger la base de datos mediante un método que me parece bastante curioso, y un poco peñazo sobre todo. Este método lo utilizan sobre todo empresas que dan acceso a una de sus bases de datos a un equipo de trabajo externo, ajeno a la empresa.
Resumiendo la historia un poco, la “técnica” se basa en que todo acceso a la base de datos (SELECT, INSERT, UPDATE, DELETE) se lleve a cabo mediante un procedimiento o función almacenada. Desde una SELECT algo pesada, a cualquier inserción modificación y borrado simple de un registro. ¿Y por qué trabajar de esta manera? Pues es para asegurarse de que sólo se va a acceder a la base de datos a través de dichos procedimientos almacenados. Se crea un usuario de base de datos que tenga permiso de ejecución sobre dichos procedimientos, y sólo para dichos procedimientos, y ese usuario se le da a la empresa externa para que haga login contra la base de datos mediante ese usuario.
Este sistema, a parte de la protección tiene alguna cosa más buena, y es que todos los procedimientos de acceso a datos están centralizados en un íºnico punto… y que además, los procedimientos que sean pesados, al llevarse a cabo directamente sobre la base de datos, se ejecutan mucho más rápido que si se estuvieran lanzando sobre el cliente.
¿Cosas malas? Pues como siempre alguna hay. Por ejemplo, si trabajáis con SQL Server, los procedimientos almacenados no pueden agruparse en Paquetes (así­ como sí­ puedes hacerlo en ORACLE), por lo que si tienes un níºmero grande de procedimientos almacenados, al final tienes una lista interminable que cuelga de una rama y que es un rollo de gestionar. Otra cosa mala, que parecerá una chorrada pero a mi me molesta especialmente es que para hacer una select simple que devuelve un registro o un grupo de registros o incluso un valor… tener que crear un procedimiento almacenado la verdad es que me parece un verdadero engorro. Además, tened en cuenta una cosa, a la hora de actualizar cualquier procedimiento almacenado vais a tener que generar un script de actualización y otro con las contramedidas, para luego desplegarlo en el servidor de pruebas… preproducción, producción… (vale, en otro caso tendrí­ais que actualizar aplicación, pero bueno, que está claro que lleva trabajo).
¿Y qué os parece el utilizar una mezcla entre ambos extremos, es decir, parte del acceso a datos definido en el cliente y parte en procedimientos almacenados? Pues… una vez leyendo un informe de una persona Certificada por Sun lei que no era una forma adecuada el tener parte del acceso a datos definido en la base de datos y parte en la aplicación, porque a la hora de desarrollar no sabes muy bien por donde buscar, al tener repartido los accesos en diferentes componentes de la aplicación… ¿tení­a razón esta persona? Pues la verdad es que aíºn le sigo dando vueltas…
Saludos.
Miguel.

Leave a Reply

Your email address will not be published. Required fields are marked *