Compartir vía

CREATE ASSEMBLY (Transact-SQL)

  • Artículo

Se aplica a: SQL Server Azure SQL Managed Instance

Crea un módulo de aplicación administrada que contiene metadatos de clase y código administrado como un objeto en una instancia de SQL Server. Mediante este módulo, puede crear en la base de datos funciones CLR (Common Language Runtime), procedimientos almacenados, desencadenadores, funciones de agregado definidas por el usuario y tipos definidos por el usuario.

Convenciones de sintaxis de Transact-SQL

Sintaxis

CREATE ASSEMBLY assembly_name
[ AUTHORIZATION owner_name ]
FROM { <client_assembly_specifier> | <assembly_bits> [ , ...n ] }
[ WITH PERMISSION_SET = { SAFE | EXTERNAL_ACCESS | UNSAFE } ]
[ ; ]
<client_assembly_specifier> ::=
    '[ \\computer_name\ ] share_name\ [ path\ ] manifest_file_name'
    | '[ local_path\ ] manifest_file_name'

<assembly_bits> ::=
{ varbinary_literal | varbinary_expression }

Argumentos

assembly_name

Nombre del ensamblado. El nombre debe ser único en la base de datos y un identificador válido.

AUTHORIZATION owner_name

Especifica el nombre de un usuario o rol como propietario del ensamblado. owner_name debe ser el nombre de un rol del que el usuario actual es miembro o el usuario actual debe tener IMPERSONATE permiso para owner_name. Si no se especifica, la propiedad se otorga al usuario actual.

<client_assembly_specifier>

Especifica la ruta de acceso local o ubicación de red en la que se encuentra el ensamblado que se carga y, además, el nombre de archivo de manifiesto que se corresponde con el ensamblado. <client_assembly_specifier> se puede expresar como una cadena fija o una expresión que se evalúe como una cadena fija, con variables. CREATE ASSEMBLY no admite la carga de ensamblados multimódulo. SQL Server también busca cualquier ensamblado dependiente de este ensamblado en la misma ubicación y lo carga con el mismo propietario que el ensamblado de nivel raíz. Si no se encuentran estos ensamblados dependientes y aún no se cargan en la base de datos actual, CREATE ASSEMBLY se produce un error. Si los ensamblados dependientes ya están cargados en la base de datos actual, el propietario de los mismos deberá ser el mismo que el del ensamblado nuevo que se crea.

Importante

Azure SQL Database y Azure SQL Instancia administrada no admiten la creación de un ensamblado a partir de un archivo.

<client_assembly_specifier> no se puede especificar si el usuario que ha iniciado sesión se está suplantando.

<assembly_bits>

Lista de valores binarios que componen el ensamblado y sus ensamblados dependientes. El primer valor de esta lista se considera el ensamblado raíz. Los valores correspondientes a los ensamblados dependientes pueden suministrarse en cualquier orden. Los valores que no corresponden a las dependencias del ensamblado raíz se omiten.

Nota:

Esta opción no está disponible en las bases de datos independientes.

varbinary_literal

Literal varbinary .

expresión_varbinary

Expresión de tipo varbinary.

PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }

Especifica un conjunto de permisos de acceso de código que se conceden al ensamblado cuando SQL Server tiene acceso a él. Si no se especifica, SAFE se aplica como valor predeterminado.

La PERMISSION_SET opción se ve afectada por la configuración del servidor: clr strict security option. Cuando clr strict security está habilitada, todos los ensamblados se tratan como UNSAFE.

Recomendamos utilizar SAFE. SAFE es el conjunto de permisos más restrictivo. El código ejecutado por un ensamblado con SAFE permisos no puede acceder a recursos externos del sistema, como archivos, la red, las variables de entorno o el registro.

EXTERNAL_ACCESS permite que los ensamblados accedan a determinados recursos del sistema externo, como archivos, redes, variables de entorno y el Registro.

UNSAFE habilita el acceso sin restricciones a los ensamblados a los recursos, tanto dentro como fuera de una instancia de SQL Server. El código que se ejecuta desde un UNSAFE ensamblado puede llamar a código no administrado.

SAFE es la configuración de permisos recomendada para los ensamblados que realizan tareas de cálculo y administración de datos sin tener acceso a recursos fuera de una instancia de SQL Server.

Nota:

Las EXTERNAL_ACCESS opciones y UNSAFE no están disponibles en una base de datos independiente.

Se recomienda usar EXTERNAL_ACCESS para ensamblados que accedan a recursos fuera de una instancia de SQL Server. EXTERNAL_ACCESS Los ensamblados incluyen las protecciones de confiabilidad y escalabilidad de SAFE los ensamblados, pero desde una perspectiva de seguridad, son similares a UNSAFE los ensamblados. El código de los ensamblados se ejecuta de forma predeterminada en EXTERNAL_ACCESS la cuenta de servicio de SQL Server y accede a los recursos externos de esa cuenta, a menos que el código suplanta explícitamente al autor de la llamada. Por lo tanto, solo se debe conceder permiso para crear EXTERNAL_ACCESS ensamblados a los inicios de sesión que son de confianza para ejecutar código en la cuenta de servicio de SQL Server. Para obtener más información sobre la suplantación, vea Seguridad de la integración CLR.

Especificar UNSAFE permite que el código del ensamblado tenga libertad completa para realizar operaciones en el espacio de procesos de SQL Server que pueda poner en peligro la solidez de SQL Server. UNSAFE Los ensamblados también pueden subvertir el sistema de seguridad de SQL Server o Common Language Runtime. UNSAFE Solo se deben conceder permisos a ensamblados de alta confianza. Solo los miembros del rol fijo de servidor sysadmin pueden crear y modificar UNSAFE ensamblados.

Para obtener más información sobre los conjuntos de permisos de ensamblado, vea Diseño de ensamblados.

Ya no se admite la seguridad de acceso al código

CLR usa la seguridad de acceso del código (CAS) de .NET Framework, que ya no se admite como un límite de seguridad. Un ensamblado CLR creado con PERMISSION_SET = SAFE podría tener acceso a recursos externos del sistema, llamar al código no administrado y adquirir privilegios sysadmin. En SQL Server 2017 (14.x) y versiones posteriores, la sp_configure opción clr strict security mejora la seguridad de los ensamblados CLR. La opción clr strict security está habilitada de forma predeterminada y trata los ensamblados SAFE y EXTERNAL_ACCESS como si estuvieran marcados con UNSAFE. La clr strict security opción se puede deshabilitar para la compatibilidad con versiones anteriores, pero no se recomienda.

Se recomienda firmar todos los ensamblados mediante un certificado o una clave asimétrica, con un inicio de sesión correspondiente al que se ha concedido UNSAFE ASSEMBLY permiso en la master base de datos. Los administradores de SQL Server también pueden agregar ensamblados a una lista de los ensamblados en los que el motor de base de datos debe confiar. Para más información, vea sys.sp_add_trusted_assembly.

Comentarios

CREATE ASSEMBLY carga un ensamblado que se compiló anteriormente como un archivo .dll desde código administrado para su uso dentro de una instancia de SQL Server.

Cuando se habilita, la opción PERMISSION_SET en las instrucciones CREATE ASSEMBLY y ALTER ASSEMBLY se omite en tiempo de ejecución, pero las opciones PERMISSION_SET se conservan en los metadatos. Omitir la opción minimiza la interrupción de las instrucciones de código existentes.

SQL Server no permite registrar versiones diferentes de un ensamblado con el mismo nombre, referencia cultural y clave pública.

Al intentar acceder al ensamblado especificado en <client_assembly_specifier>, SQL Server suplanta el contexto de seguridad del inicio de sesión de Windows actual. Si <client_assembly_specifier> especifica una ubicación de red (ruta de acceso UNC), la suplantación del inicio de sesión actual no se lleva a cabo en la ubicación de red debido a las limitaciones de delegación. En este caso, el acceso se realiza mediante el contexto de seguridad de la cuenta del servicio SQL Server. Para más información, vea Credenciales (motor de base de datos).

Además del ensamblado raíz especificado por assembly_name, SQL Server intenta cargar cualquier ensamblado al que haga referencia el ensamblado raíz que se carga. Si ya se ha cargado un ensamblado al que se hace referencia en la base de datos debido a una instrucción anterior CREATE ASSEMBLY , este ensamblado no se carga, pero está disponible para el ensamblado raíz. Si no se cargó previamente un ensamblado dependiente, pero SQL Server no puede encontrar su archivo de manifiesto en el directorio de origen, CREATE ASSEMBLY devuelve un error.

Si los ensamblados dependientes a los que hace referencia el ensamblado raíz aún no están en la base de datos y se cargan implícitamente junto con el ensamblado raíz, tienen el mismo conjunto de permisos que el ensamblado de nivel raíz. Si se deben crear ensamblados dependientes mediante el uso de permisos diferentes de los del ensamblado raíz, estos deben cargarse explícitamente antes del ensamblado raíz con los permisos apropiados establecidos.

Validación del ensamblado

SQL Server examina los archivos binarios de ensamblado cargados por la CREATE ASSEMBLY instrucción para garantizar las siguientes comprobaciones:

  • El binario del ensamblado está formado por metadatos y segmentos de código válidos; los segmentos de código tienen instrucciones MSIL (Lenguaje intermedio de Microsoft) válidas.

  • El conjunto de ensamblados del sistema al que hace referencia es uno de los siguientes ensamblados admitidos en SQL Server: Microsoft.VisualBasic.dll, mscorlib.dll, System.Data.dllSystem.dll, , System.Web.Services.dllCustomMarshallers.dllSystem.Xml.dllSystem.Security.dllSystem.Data.SqlXml.dllMicrosoft.VisualC.dll, System.Core.dll, y .System.Xml.Linq.dll Se puede hacer referencia a otros ensamblados del sistema, pero deben estar registrados de forma explícita en la base de datos.

  • Para los ensamblados creados mediante SAFE o EXTERNAL ACCESS conjuntos de permisos:

    • El código del ensamblado debe tener seguridad de tipos. La seguridad de tipos se establece ejecutando el comprobador de Common Language Runtime en el ensamblado.

    • El ensamblado no debe contener ningún miembro de datos estáticos en sus clases a menos que estén marcados como de solo lectura.

    • Las clases del ensamblado no pueden contener métodos de finalizador.

    • Las clases o métodos del ensamblado deben anotarse solamente con atributos de código permitidos. Para obtener más información, consulte Integración de CLR: atributos personalizados para rutinas CLR.

Además de las comprobaciones anteriores que se realizan cuando CREATE ASSEMBLY se ejecuta, hay comprobaciones adicionales que se realizan en tiempo de ejecución del código en el ensamblado:

  • Si se llama a determinadas API de .NET Framework que requieren un permiso de acceso de código específico, puede producirse un error si el conjunto de permisos del ensamblado no incluye ese permiso.

  • Para SAFE los ensamblados y EXTERNAL_ACCESS , se produce un error en cualquier intento de llamar a las API de .NET Framework anotadas con determinados HostProtectionAttributes.

Para obtener más información, consulte Diseño de ensamblados.

Permisos

Requiere el permiso CREATE ASSEMBLY.

Si PERMISSION_SET = EXTERNAL_ACCESS se especifica, requiere EXTERNAL ACCESS ASSEMBLY permiso en el servidor. Si PERMISSION_SET = UNSAFE se especifica, requiere UNSAFE ASSEMBLY permiso en el servidor.

El usuario debe ser el propietario de cualquier ensamblado al que el ensamblado que se va a cargar haga referencia (si los ensamblados ya existen en la base de datos). Para cargar un ensamblado mediante una ruta de acceso de archivo, el usuario actual debe ser miembro del inicio de sesión autenticado de Windows o del rol fijo de servidor sysadmin. El inicio de sesión de Windows del usuario que ejecuta CREATE ASSEMBLY debe tener permiso de lectura en el recurso compartido y los archivos que se cargan en la instrucción .

Permisos con seguridad estricta de CLR

Los siguientes permisos son necesarios para crear un ensamblado CLR cuando la opción CLR strict security está habilitada:

  • El usuario debe tener el permiso CREATE ASSEMBLY.
  • Además, se debe dar una de las siguientes condiciones:
    • El ensamblado debe estar firmado con un certificado o clave asimétrica que tenga el inicio de sesión correspondiente con el permiso UNSAFE ASSEMBLY en el servidor. Se recomienda firmar el ensamblado.
    • La base de datos tiene la propiedad TRUSTWORTHY establecida en ON y pertenece a un inicio de sesión que tiene el permiso UNSAFE ASSEMBLY en el servidor. No se recomienda esta opción.

Para obtener más información sobre los conjuntos de permisos de ensamblado, vea Diseño de ensamblados.

Ejemplos

A Creación de un ensamblado a partir de un archivo DLL

En el ejemplo siguiente se supone que los ejemplos de Motor de base de datos de SQL Server se instalan en la ubicación predeterminada del equipo local y se compila la HelloWorld.csproj aplicación de ejemplo. Para más información, vea Ejemplo de Hola a todos.

CREATE ASSEMBLY HelloWorld
FROM '<system_drive>:\Program Files\Microsoft SQL Server\100\Samples\HelloWorld\CS\HelloWorld\bin\debug\HelloWorld.dll'
WITH PERMISSION_SET = SAFE;

Importante

Azure SQL Database no admite la creación de un ensamblado a partir de un archivo.

B. Creación de un ensamblado a partir de bits de ensamblado

Reemplace los bits de ejemplo (que no están completos o válidos) por los bits de ensamblado.

CREATE ASSEMBLY HelloWorld
    FROM 0x4D5A900000000000
WITH PERMISSION_SET = SAFE;

Contenido relacionado