Vínculos en el ámbito de seguridad de la integración CLR

En esta sección se describe cómo los fragmentos de código de usuario se pueden llamar entre sí en SQL Server, ya sea en Transact-SQL o en uno de los lenguajes administrados. Estas relaciones entre objetos reciben el nombre de vínculos.

Los vínculos de invocación corresponden a una invocación de código, ya sea desde un usuario que llama a un objeto (como un lote de Transact-SQL que llama a un procedimiento almacenado) o a un procedimiento almacenado o una función de Common Language Runtime (CLR). Los vínculos de invocación hacen que se compruebe un permiso EXECUTE en el destinatario.

Los vínculos de acceso a tablas corresponden a valores de recuperación o modificación de una tabla, vista o función con valores de tabla. Son similares a los vínculos de invocación, pero tienen un control de acceso más exhaustivo en lo que se refiere a los permisos SELECT, INSERT, UPDATE y DELETE .

Los vínculos canalizados implican que, durante la ejecución, los permisos no se comprueban a través de la relación de objetos una vez que se ha establecido. Cuando hay un vínculo canalizado entre dos objetos (por ejemplo, un objeto x y un objeto y), los permisos en el objeto y y otros objetos a los que se obtiene acceso desde el objeto y solamente se comprueban en el momento de creación del objeto x. En el momento de creación del objeto x, REFERENCE el permiso se comprueba en y con el propietario de x. En tiempo de ejecución (por ejemplo, cuando alguien llama al objeto x), no hay ningún permiso comprobado en y ni en otros objetos a los que hace referencia de forma estática. En tiempo de ejecución, un permiso adecuado se comprobará en el propio objeto x .

Los vínculos canalizados siempre se usan junto con una dependencia de metadatos entre dos objetos. Esta dependencia de metadatos es una relación establecida en SQL Server catálogos que impide que un objeto se quite mientras otro objeto dependa de él.

Los vínculos canalizados son muy útiles cuando resulta adecuado o sencillo conceder permisos a muchos objetos dependientes. Los vínculos limitados se introducen entre objetos que definen puntos de entrada de Transact-SQL en ensamblados CLR (por ejemplo, procedimientos CLR, desencadenadores, funciones, tipos y agregados) y los ensamblados desde los que se definen. La seguridad controlada contra estos objetos implica que para invocar un punto de entrada de Transact-SQL definido en un ensamblado CLR, el autor de la llamada solo necesita un permiso adecuado en ese punto de entrada de Transact-SQL. No es necesario que el autor de las llamadas tenga permisos en ese ensamblado o en cualquier otro ensamblado al que haga referencia de forma estática. Los permisos del ensamblado se comprueban en el momento de creación del punto de entrada de Transact-SQL.

Seguridad basada en autorizaciones de SQL Server

A continuación se muestran las reglas básicas detrás de las comprobaciones de seguridad de SQL Server para las invocaciones de y entre objetos de base de datos basados en CLR; las tres primeras reglas definen qué permisos se comprueban y con qué objeto; la cuarta regla define el contexto de ejecución con el que se comprueba el permiso.

  1. Todas las invocaciones requieren el permiso EXECUTE, a menos que tengan lugar dentro del mismo objeto; esto significa que las llamadas dentro del mismo ensamblado no requieren comprobaciones de permisos. Los permisos se comprueban en tiempo de ejecución.

  2. Los vínculos canalizados requieren el permiso REFERENCE en el destinatario cuando se crea el objeto de llamada. El permiso se comprueba para el propietario del objeto de llamada cuando se crea el objeto.

  3. Los vínculos de acceso a tablas requieren el permiso SELECT, INSERT, UPDATE o DELETE correspondiente en la tabla o vista a la que se obtiene acceso.

  4. El permiso se comprueba en el contexto de ejecución actual. Pueden crearse procedimientos y funciones con un contexto de ejecución diferente al del autor de las llamadas. Los ensamblados siempre se crean con el contexto de ejecución del procedimiento, función o desencadenador que se define en el mismo.

Consulte también

Seguridad de la integración CLR