SQL Server EJECUTAR COMO problema

13

Me falta algo al intentar utilizar mi procedimiento almacenado EXECUTE AS. El procedimiento almacenado lee datos source_db, los agrega y almacena los resultados target_db.

El sp en sí está adentro target_db. Tengo un inicio de sesión dedicado y lo asigno a los usuarios en ambos source_dby target_dbpara el propietario de sp (por lo que hay un usuario app_agenten source_dby target_dbpara iniciar sesión app_agent).

Si inicio sesión como app_agenty ejecuto

EXEC target_db.app_agent_schema.import_data

Todo funciona bien. Pero si cambio

ALTER PROCEDURE app_agent_schema.import_data WITH EXECUTE AS OWNER` (or `AS SELF`)

e intenta ejecutarlo, arroja

El servidor principal "app_agent" no puede acceder a la base de datos "source_db" en el contexto de seguridad actual.

Estoy usando SQL Server 2008.

¿Alguien podría señalar mi error?

Gracias

Actualización Después de investigar un poco, descubrí que ALTER DATABASE target_db SET TRUSTWORTHY ONresuelve el problema, pero eso no me parece la solución correcta ...

sql-server-2008 security a1ex07
fuente
1
Creo que la respuesta está utilizando la base de datos de -level cadena de propiedad entre bases de datos opción. Pude reproducir el error en su escenario, pero no hay suficientes detalles para saber si lo reproduje exactamente ... la opción CDOC no funcionó para mí, pero pruébelo y vea si eso lo hace.
Jon Seigel

Respuestas:

24

Esto se explica en Ampliación de la suplantación de bases de datos mediante EXECUTE AS . El contexto EJECUTAR COMO solo se confía en la base de datos actual y permitir que se extienda a otras bases de datos es una escalada del vector de ataque de privilegios.

Hay dos soluciones, ambas descritas en el artículo vinculado anteriormente:

  • la fácil es para marcar el CONFIABLE base de datos: ALTER DATABASE [source_db] SET TRUSTWORTHY ON;. Aunque es fácil, también es peligroso, ya que hace que la dbode source_dbun de-facto sysadmin.

  • el seguro es usar la firma de código, consulte Llamar a un procedimiento en otra base de datos para ver un ejemplo. Esto es más complejo, pero es 100% seguro de seguridad.

Remus Rusanu
fuente
0

¿Qué usuario ejecuta el comando ALTER PROCEDURE? Es posible que haya establecido el nivel de acceso Propietario (propio) para ese usuario, no el que usted pretendía.

Cielo
fuente
El mismo usuario que creó el procedimiento ( app_agent). Si tengo un procedimiento creado por app_agentsin execute as owner/self, inicie sesión como app_agent, SP se ejecuta correctamente. Si agrego EXECUTE AS SELF(de nuevo, el mismo usuario) e inicio sesión incluso como app_agent, obtengo...is not able to access the database...
a1ex07