Compartir a través de


Vínculos en CLR Integration Security

En esta sección se describe cómo los fragmentos de código de usuario pueden llamarse entre sí en SQL Server, ya sea en Transact-SQL o en uno de los lenguajes administrados. Estas relaciones entre objetos se conocen como 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 (por ejemplo, un lote de Transact-SQL que llama a un procedimiento almacenado) o a una función o procedimiento almacenado de Common Language Runtime (CLR). Los vínculos de invocación hacen que se compruebe un EXECUTE permiso en el destinatario.

Los vínculos de acceso a tablas corresponden a la recuperación o modificación de valores en una tabla, vista o función con valores de tabla. Son similares a los vínculos de invocación, salvo que tienen un control de acceso más específico en términos de permisos SELECT, INSERT, UPDATE y DELETE.

Los vínculos cerrados significan que durante la ejecución, los permisos no se comprueban en la relación de objeto una vez establecida. Cuando hay un vínculo cerrado entre dos objetos (por ejemplo, object x e y), los permisos de object y y otros objetos a los que se accede desde el objeto y solo 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 permisos comprobados en y u otros objetos a los que hace referencia estáticamente. En tiempo de ejecución, se comprobará un permiso adecuado con el objeto x .

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

Los vínculos cerrados son útiles cuando no es adecuado o administrable conceder permisos a muchos objetos dependientes. Los vínculos cerrados se introducen entre objetos que definen Transact-SQL puntos de entrada 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 Transact-SQL definido en un ensamblado CLR, el autor de la llamada solo necesita un permiso adecuado para ese punto de entrada Transact-SQL. No es necesario que el autor de la llamada tenga permisos en ese ensamblado ni en ningún otro ensamblado al que hace referencia estáticamente. Los permisos del ensamblado se comprueban en el momento de creación del punto de entrada de Transact-SQL.

Seguridad de SQL Server Authorization-Based

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 los 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 en qué contexto de ejecución se comprueba el permiso.

  1. Todas las invocaciones requieren EXECUTE permiso a menos que las invocaciones se produzcan dentro del mismo objeto; esto significa que las llamadas dentro del mismo ensamblado no requieren ninguna comprobación de permisos. El permiso se comprueba en tiempo de ejecución.

  2. Los vínculos cerrados requieren REFERENCE permiso para el destinatario cuando se crea el objeto que realiza la llamada. El permiso se comprueba para el propietario del objeto que realiza la llamada cuando se crea el objeto.

  3. Los vínculos de acceso a tablas requieren el permiso , INSERT, UPDATEo DELETE correspondiente SELECTa la tabla o vista a la que se accede.

  4. El permiso se comprueba con el contexto de ejecución actual. Los procedimientos y funciones se pueden crear con un contexto de ejecución diferente del autor de la llamada. Los ensamblados siempre se crean con el contexto de ejecución del procedimiento, la función o el desencadenador que se define en él.

Véase también

Seguridad de la integración CLR