Permisos al usar "Ejecutar sp_Executesql"

Tengo una base de datos donde todo el acceso se controla mediante procedimientos almacenados. Al DBA le gustaría evitar que los usuarios tengan acceso directo de lectura/escritura a las tablas subyacentes, lo que puedo entender. Por lo tanto, todas las actualizaciones y selecciones de datos se realizan a través de procedimientos almacenados. Básicamente, ha creado un rol que tiene permisos de EJECUTAR para todos los procedimientos almacenados en la base de datos y le otorga a los usuarios ese rol.Permisos al usar "Ejecutar sp_Executesql"

El problema es que uno de los procedimientos almacenados crea dinámicamente una consulta SQl y la ejecuta mediante "Execute sp_Executesql". Sin entrar en gran detalle, la consulta se genera dinámicamente porque cambia significativamente dependiendo de muchos parámetros de entrada del usuario. El procedimiento almacenado en cuestión es solo una instrucción SELECT sql; sin embargo, estoy descubriendo que simplemente dar al procedimiento almacenado el permiso EXECUTE no es suficiente. Las tablas subyacentes a las que se hace referencia dentro del procedimiento almacenado que utilizan "Execute sp_Executesql" deben tener acceso de "lector de datos" o el procedimiento almacenado falla.

¿Alguna idea sobre cómo corregir esto? Realmente quería restringir el acceso a las tablas solo a los procedimientos almacenados, pero necesito encontrar una forma de evitar los procedimientos almacenados que hacen uso de "Execute sp_Executesq" l. Gracias.

Fuente

2010-09-28 webworm

se puede lograr mejores serverfault avdice. Mi consejo: habla con el dba y explica la situación. Trabaja con ellos para obtener los permisos correctos. –

-3

El problema real es que sp_Executesql está en la base de datos master, no necesariamente en la base de datos en la que está trabajando. Su DBA debe otorgar permiso de ejecución sp_Executesql al procedimiento de llamada. Que cualquiera que tenga permiso para llamar a ese procedimiento podrá ejecutar el sp_Executesql.

Fuente

2010-09-28 19:58:02 MAW74656

-1 sp_Executesql ya tiene ejecución pública. "Requiere membresía en el rol público". http://msdn.microsoft.com/en-us/library/ms188001.aspx El verdadero problema es la propiedad de encadenar saltos cuando usa sp_executesql. Consulte este http://stackoverflow.com/questions/3815411 – gbn

Si ha endurecido su base de datos para bloquear el rol público, entonces @ MAW74656 es correcto; por ejemplo, ha creado una función personalizada para reemplazar la función pública y ha eliminado todos los privilegios de la función pública. Sí, esto va en contra de los requisitos documentados, pero los sistemas de escaneo de bases de datos como AppDetective (a través de SQL Server STIG) presentan el rol público y su acceso abierto predeterminado como un riesgo importante. – Draghon

... además, citando el mismo artículo de MSDN, "Las instrucciones de ejecución de Transact-SQL compiladas en el tiempo pueden exponer las aplicaciones a ataques maliciosos". Esto se muestra de manera más prominente que la declaración "Requiere membresía en el rol público". – Draghon

En el proc envoltorio puede utilizar EXECUTE AS OWNER o EXECUTE AS SomeuserWithNoLogin

Esto cambiará el contexto de inicio de sesión para la duración del procedimiento almacenado que incluye sp_executesql.

Si utiliza PROPIETARIO, funcionará porque ya está utilizando el encadenamiento de propiedad.
Si su DBA (¡buen hombre!) No quiere que se ejecute como dbo, configure un usuario que tenga una lectura completa pero sin derechos. EXECUTE AS <user> requiere una entrada es sys.database_principals

De esta manera:

CREATE USER SomeuserWithNoLogin WITH WITHOUT LOGIN 
EXEC sp_addrolemember 'db_datareader', 'SomeuserWithNoLogin'

Para obtener más información, consulte EXECUTE AS Clause on MSDN y CREATE PROCEDURE

Fuente

2010-09-28 19:59:06 gbn

Permisos al usar "Ejecutar sp_Executesql"

Respuesta

Cuestiones relacionadas