uso usan una tipos son qué que procedimientos procedimiento objetivo los ejemplo ejecutar desventajas declaran datos cuál como aporta almacenados almacenado sql sql-server security stored-procedures

sql - usan - ¿Qué beneficios de seguridad se proporcionan mediante el uso de procedimientos almacenados para acceder a los datos?



qué desventajas aporta el uso de procedimientos almacenados en una base de datos (9)

He visto una guía que recomienda que proteja una base de datos al acodar todo el acceso a los datos a través de procedimientos almacenados.

Sé que para SQL Server, puede asegurar tablas e incluso columnas contra operaciones CRUD.

Por ejemplo:

--// Logged in as ''sa'' USE AdventureWorks; GRANT SELECT ON Person.Address(AddressID, AddressLine1) to Matt; GRANT UPDATE ON Person.Address(AddressLine1) to Matt; --// Logged in as ''Matt'' SELECT * from Person.Address; --// Fail SELECT AddressID, AddressLine1 from Person.Address; --// Succeed UPDATE Person.Address SET AddressLine1 = ''#____ 2700 Production Way'' WHERE AddressID = 497; --// Succeed

Dado que puede proteger tablas e incluso columnas contra operaciones CRUD, ¿cómo proporciona un uso de un procedimiento almacenado seguridad adicional o administración de seguridad?

El procedimiento almacenado es mejor porque la seguridad en el procedimiento almacenado (IIRC) prevalecerá sobre la seguridad en las tablas / columnas.

Para acceso a una sola tabla, eso no es gran cosa. Sin embargo, si tiene una operación que involucra múltiples columnas en varias tablas, tener un indicador de acceso / denegación para una tabla / columna podría no funcionar para todas las situaciones.

Sin embargo, un procedimiento almacenado puede realizar la operación compuesta y puede establecer la seguridad apropiadamente en eso.

En la mayoría (¿todos?) RDBMS''s se puede ''otorgar'' acceso en tablas específicas a usuarios específicos. Un procedimiento almacenado puede ejecutarse como un usuario diferente, uno con mayor acceso. Pero el procedimiento almacenado no es lo mismo que dar acceso a toda la tabla, sino que primero podría verificar algunas cosas y solo devolver las filas que coincidan con sus preocupaciones particulares de seguridad.

Es posible que pueda hacer comprobaciones similares con una vista, pero los procedimientos almacenados suelen ser mucho más flexibles, ya que pueden ejecutar casi cualquier SQL: compare los resultados y decida qué filas devolver.

Es posible que no desee darle a Matt una tarjeta blanca para actualizar ciertas tablas o columnas directamente. ¿Qué pasa si Matt decide hacer esto?

UPDATE Person.Address SET AddressLine1 = NULL

Whoops. Matt olvidó la cláusula WHERE y simplemente limpió su base de datos. O tal vez Matt simplemente se enojó con su jefe y ha decidido renunciar al final del día. O tal vez la contraseña de Matt no es tan segura como debería y ahora lo tiene un hacker.

Este es solo un simple ejemplo. El control sobre las tablas y columnas podría volverse mucho más complejo y podría ser insostenible a través de otros procedimientos que no sean los almacenados.

Los procedimientos almacenados proporcionan seguridad adicional al permitir a los usuarios realizar operaciones CRUD (insertar, actualizar, eliminar) pero solo de forma limitada. Por ejemplo, permite al usuario Matt actualizar la dirección de algunas filas pero no de otras.

Le permite agregar verificaciones de datos para asegurarse de que los datos insertados sean datos válidos, no basura aleatoria. Para la mayoría de las cosas, puede usar restricciones o desencadenantes para hacer parte de este trabajo, pero existen limitaciones. Los procedimientos almacenados mejoran la seguridad al garantizar que el usuario permita las operaciones que se realizan.

Es más fácil hacer un seguimiento de los cambios en la base de datos a través de un único punto de acceso, controlado por sus aplicaciones, en lugar de a través de cualquier cantidad de interfaces. Y el procedimiento puede actualizar un registro de auditoría.

El primer beneficio, discutido extensamente aquí, es un mejor control de los permisos: los usuarios pueden limitarse a filas específicas, no solo por columna (lo que por cierto es bueno administrar en un sistema grande); Los SP pueden hacer cumplir la lógica de negocios y la lógica transaccional; los datos solo pueden recuperarse dependiendo de otros datos (por ejemplo, unir); las actualizaciones pueden estar limitadas a filas individuales a la vez; etc.

En segundo lugar, esto puede proporcionar una capa adicional de protección contra la Inyección SQL (aunque no es completa y automática). Si bien esto se puede romper sea SQL dinámico dentro del SP, o por llamadas de concatenación incorrectas, el SP hace cumplir tipos de parámetros y otras cosas, separando el código de los datos.

En tercer lugar, todo se reduce al control, en la fase de desarrollo: normalmente habría DBA entrenados escribiendo los SP, a diferencia de los programadores (que están entrenados en el código ...)

Esto sin mencionar los beneficios no relacionados con la seguridad, como un mejor rendimiento.

En pocas palabras, le permite definir la seguridad funcionalmente en lugar de estructuralmente. En otras palabras, restringe lo que un usuario puede hacer (con un mayor grado de granularidad) en lugar de a qué objetos de la base de datos se puede acceder (con una granularidad muy gruesa).

Tenga en cuenta que estamos hablando de "seguridad controlada por el DBA", en lugar de hacerlo por el administrador del sitio o del sistema o el módulo de software, todos los cuales son útiles y forman parte de la infraestructura de seguridad general.

En SQL Server no tiene que otorgar ningún acceso directo a las tablas si usa adecuadamente los procesos almacenados (eso significa que no hay SQl dinámico). Esto significa que tus usuarios solo pueden hacer esas cosas definidas por los procesos. Si tiene datos financieros en su base de datos o datos de naturaleza confidencial, solo el menor número posible de personas (generalmente solo dbas) debe tener acceso directo a las tablas. Esto reduce seriamente el riesgo de fraude o empleados descontentos que destruyen los datos críticos de su empresa o que los empleados roban información personal para cometer un robo de identidad. En términos contables, este es un control interno necesario y la conveniencia del desarrollador o los deseos personales de hacer todo dinámicamente desde la interfaz del usuario deberían ser superados por la inseguridad de los datos. Desafortunadamente en muy pocas compañías, no lo es. La mayoría de los desarrolladores parece que solo se preocupan por las amenazas externas a sus datos, pero los internos a menudo son mucho más críticos.

Si restringe al usuario a nivel de tabla y luego el usuario desactiva una consulta para hacer una inserción de legititmate, no sucederá. Si les otorga los derechos para hacer inserciones, entonces pueden hacer cualquier inserción adhoc que deseen y no están limitadas a las que provienen de la interfaz de usuario. Con los procesos almacenados, solo pueden hacer las cosas específicamente definidas por el proceso.

En los procedimientos almacenados, puede agregar controles lógicos. Puede devolver un código de error si algo no está bien en lugar de actualizar los datos de la tabla directamente.

Por ejemplo, tienes un sistema de retroalimentación. Los comentarios solo se pueden enviar después de que la administración haya comenzado la campaña de comentarios. Simplemente está actualizando una bandera en alguna tabla. Luego, cuando el usuario envía comentarios, SP puede verificar si la bandera está configurada.

Select @IsFeedbackDefined = IsFeedbackDefined From sometable where ID = @ID IF @IsFeedbackDefined is Null or @IsFeedbackDefined = false Begin Return -2 --can not submit feedback End

Porque al limitar todo el acceso a esos procesos almacenados ha establecido una interfaz definida para la base de datos, a través de la cual debe tener lugar todo el acceso ... Dado que tendrá operaciones de selección, inserción, actualización y eliminación DENY''d Direct en las tablas y vistas , nadie puede escribir directamente sql de su propio diseño que haga lo que quiera ... Si quiere limitar las inserciones en la tabla de empleados donde el empleado está asignado a más de tres proyectos solo a aquellos empleados que tienen un puntaje mayor que 85 en una prueba de competencia, entonces puede escribir esa restricción en el sproc SaveEmployee, y hacer que arroje una excepción a cualquier código de cliente que intente hacer eso ...

Seguro que PODRÍA hacer lo mismo usando el código del lado del cliente, pero usar sProcs hace que el proceso sea más fácil de diseñar y administrar, porque todo está en un solo lugar, y TODAS las aplicaciones que intentan acceder a este sistema de base de datos TIENEN que ajustarse a las limitaciones y / o las disposiciones de seguridad que defina en los SProcs ... Ningún desarrollador deshonesto que escriba una nueva aplicación de cliente separada que acceda a la base de datos puede ignorar o solucionar una restricción o provisión de seguridad en SProc si ese SProc es la ÚNICA FORMA de insertar o actualizar un grabar...