Diseño de ensamblados

En este tema se describen los siguientes factores que debe tener en cuenta al diseñar ensamblados:

• Empaquetado de ensamblados

• Administración de la seguridad del ensamblado

• Restricciones en los ensamblados

Empaquetado de ensamblados

Un ensamblado puede contener funcionalidad para más de una rutina o tipo de SQL Server en sus clases y métodos. En la mayoría de los casos, resulta conveniente empaquetar la funcionalidad de rutinas que ejecutan funciones relacionadas dentro del mismo ensamblado, especialmente si estas rutinas comparten clases cuyos métodos se llaman unos a otros. Por ejemplo, las clases que efectúan tareas de administración de entradas de datos para desencadenadores de Common Language Runtime (CLR) y procedimientos almacenados de CLR se pueden empaquetar en el mismo ensamblado. Esto se debe a que los métodos de estas clases tienen más probabilidades de llamarse entre sí que los de tareas menos relacionadas.

Al empaquetar código en ensamblado, debe tener en cuenta lo siguiente:

• Los índices y tipos definidos por el usuario CLR que dependan de funciones definidas por el usuario CLR pueden provocar que haya datos almacenados en la base de datos que dependan del ensamblado. La modificación del código de un ensamblado suele ser más compleja cuando hay datos persistentes que dependen del ensamblado de la base de datos. Por lo tanto, generalmente es mejor separar el código en el que dependen las dependencias de datos persistentes (como los tipos e índices definidos por el usuario mediante funciones definidas por el usuario) del código que no tiene estas dependencias de datos persistentes. Para obtener más información, vea Implementación de ensamblados y ALTER ASSEMBLY (Transact-SQL).

• Si un fragmento de código administrado requiere un permiso mayor, es mejor separar ese código en un ensamblado independiente del código que no requiere un permiso mayor.

Administración de la seguridad de ensamblados

Es posible controlar el grado de acceso de un ensamblado a los recursos protegidos mediante la seguridad de acceso del código de .NET mientras ejecuta código administrado. Para ello, especifique uno de los tres conjuntos de permisos al crear o modificar un ensamblado: SAFE, EXTERNAL_ACCESS o UNSAFE.

SEGURO

SAFE es el conjunto de permisos predeterminado y es el más restrictivo. El código ejecutado por un ensamblado con permisos SAFE no puede acceder a recursos externos del sistema, como archivos, la red, las variables de entorno o el registro. El código SAFE puede acceder a los datos de las bases de datos locales de SQL Server o realizar cálculos y lógica de negocios que no impliquen el acceso a recursos fuera de las bases de datos locales.

La mayoría de los ensamblados realizan tareas de cálculo y administración de datos sin tener que acceder a recursos fuera de SQL Server. Por lo tanto, se recomienda SAFE como conjunto de permisos de ensamblado.

EXTERNAL_ACCESS

EXTERNAL_ACCESS permite que los ensamblados accedan a determinados recursos del sistema externo, como archivos, redes, servicios web, variables de entorno y el registro. Solo los inicios de sesión de SQL Server con permisos EXTERNAL ACCESS pueden crear ensamblados EXTERNAL_ACCESS.

Los ensamblados SAFE y EXTERNAL_ACCESS solo pueden contener código que sea seguro para tipos verificables. Esto significa que dichos ensamblados solo tienen acceso a clases a través de puntos de entrada bien definidos que son válidos para la definición de tipos. Por lo tanto, no pueden acceder arbitrariamente a los búferes de memoria que no pertenecen al código. Además, no pueden realizar operaciones que puedan tener un efecto adverso en la solidez del proceso de SQL Server.

INSEGURO

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

Además, especificar UNSAFE permite que el código del ensamblado realice operaciones que el comprobador CLR considera no segura para tipos. Estas operaciones pueden tener acceso a los búferes de memoria en el espacio de procesos de SQL Server de forma no controlada. Los ensamblados UNSAFE también pueden subvertir el sistema de seguridad de SQL Server o Common Language Runtime. Los permisos UNSAFE solo deben concederse a ensamblados de alta confianza por parte de desarrolladores o administradores experimentados. Solo los miembros del rol fijo de servidor sysadmin pueden crear ensamblados UNSAFE.

Restricciones en ensamblados

SQL Server pone ciertas restricciones en el código administrado en ensamblados para asegurarse de que se pueden ejecutar de forma confiable y escalable. Esto significa que ciertas operaciones que pueden poner en peligro la solidez del servidor no se permiten en los ensamblados SAFE y EXTERNAL_ACCESS.

Atributos personalizados no permitidos

Los ensamblados no se pueden anotar con los siguientes atributos personalizados:

System.ContextStaticAttribute  
System.MTAThreadAttribute  
System.Runtime.CompilerServices.MethodImplAttribute  
System.Runtime.CompilerServices.CompilationRelaxationsAttribute  
System.Runtime.Remoting.Contexts.ContextAttribute  
System.Runtime.Remoting.Contexts.SynchronizationAttribute  
System.Runtime.InteropServices.DllImportAttribute   
System.Security.Permissions.CodeAccessSecurityAttribute  
System.STAThreadAttribute  
System.ThreadStaticAttribute  

Además, los ensamblados SAFE y EXTERNAL_ACCESS no se pueden anotar con los siguientes atributos personalizados:

System.Security.SuppressUnmanagedCodeSecurityAttribute  
System.Security.UnverifiableCodeAttribute  

API de .NET Framework no permitidas

No se puede llamar a cualquier API de Microsoft .NET Framework anotada con uno de los hostProtectionAttributes no permitidos desde safe y EXTERNAL_ACCESS ensamblados.

eSelfAffectingProcessMgmt  
eSelfAffectingThreading  
eSynchronization  
eSharedState   
eExternalProcessMgmt  
eExternalThreading  
eSecurityInfrastructure  
eMayLeakOnAbort  
eUI  

Ensamblados de .NET Framework admitidos

Cualquier ensamblado al que haga referencia el ensamblado personalizado debe cargarse en SQL Server mediante CREATE ASSEMBLY. Los ensamblados de .NET Framework siguientes ya se cargan en SQL Server y, por lo tanto, se puede hacer referencia a los ensamblados personalizados sin tener que usar CREATE ASSEMBLY.

custommarshallers.dll  
Microsoft.visualbasic.dll  
Microsoft.visualc.dll  
mscorlib.dll  
system.data.dll  
System.Data.SqlXml.dll  
system.dll  
system.security.dll  
system.web.services.dll  
system.xml.dll  
System.Transactions  
System.Data.OracleClient  
System.Configuration  

Véase también

Ensamblados (motor de base de datos)
Seguridad de la integración CLR