Ensamblados: diseño

  • Artículo

Se aplica a:SQL Server

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

  • Empaquetado de ensamblados

  • Administración de la seguridad del ensamblado

  • Restricciones en los ensamblados

Empaquetar ensamblados

Un ensamblado puede contener funcionalidad para más de un SQL Server rutina o tipo 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 correspondientes a estas clases tienen más probabilidad de llamarse unos a otros que los de tareas menos relacionadas.

Cuando empaquete código en un 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. Normalmente, modificar el código de un ensamblado resulta más complejo cuando hay datos almacenados que dependen del ensamblado de la base de datos. Por lo tanto, en general es mejor separar el código en el que se basan las dependencias de datos almacenados (como los tipos y los índices definidos por el usuario que utilizan funciones definidas por el usuario) del código que no tiene tales dependencias de datos almacenados. Para obtener más información, vea Implementación de ensamblados y ALTER ASSEMBLY (Transact-SQL) .

  • Si parte del código administrado requiere un permiso de mayor nivel, es mejor separar ese código en un ensamblado diferente del correspondiente al código que no requiere ese nivel de permiso.

Administrar la seguridad de los 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, tiene que especificar uno de estos tres conjuntos de permisos al crear o modificar un ensamblado: SAFE, EXTERNAL_ACCESS o UNSAFE.

SAFE

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

EXTERNAL_ACCESS

EXTERNAL_ACCESS permite a los ensamblados obtener acceso a ciertos recursos externos del sistema, como los archivos, las redes, los servicios web, las variables de entorno y el registro. Solo SQL Server inicios de sesión con permisos EXTERNAL ACCESS pueden crear ensamblados EXTERNAL_ACCESS.

Los ensamblados con SAFE y EXTERNAL_ACCESS pueden incluir código con seguridad de tipos comprobable. 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 tener acceso arbitrariamente a búferes de memoria que no pertenezcan al código. Además, no pueden realizar operaciones que puedan tener un efecto adverso en la solidez del proceso de SQL Server.

UNSAFE

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 con UNSAFE puede llamar a código no administrado.

Además, si se especifica UNSAFE, el código incluido en el ensamblado puede realizar operaciones que la comprobación de CLR considera sin seguridad de tipos. Estas operaciones pueden acceder potencialmente a los búferes de memoria en el espacio de proceso SQL Server de forma no controlada. Los ensamblados UNSAFE también pueden trastornar potencialmente el sistema de seguridad de SQL Server o de Common Language Runtime. Los permisos UNSAFE solo deben concederlos programadores o administradores experimentados a ensamblados de mucha confianza. Solo los miembros del rol fijo de servidor sysadmin pueden crear ensamblados UNSAFE.

Restricciones en los 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, en los ensamblados con SAFE y EXTERNAL_ACCESS, no se permiten ciertas operaciones que pueden comprometer la estabilidad del servidor.

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 con 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.

CustomMarshalers.dll  
Microsoft.VisualBasic.dll  
Microsoft.VisualC.dll  
mscorlib.dll  
System.dll  
System.Configuration.dll  
System.Core.dll  
System.Data.dll  
System.Data.OracleClient.dll  
System.Data.SqlXml.dll  
System.Deployment.dll  
System.Security.dll  
System.Transactions.dll  
System.Web.Services.dll  
system.Xml.dll  
System.Xml.Linq.dll

Consulte también

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