Compartir a través de

Diseño de ensamblados

  • Artículo

Se aplica a: SQL Server

En este artículo 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

Ensamblados de paquetes

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 métodos de tareas menos relacionadas.

Al empaquetar código en ensamblado, tenga 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, es mejor separar el código en el que se basan 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 del ensamblado

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_ACCESSo UNSAFE.

Permiso SAFE

SAFE es el conjunto de permisos predeterminado y es el 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. SAFE el código 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.

permiso de 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 EXTERNAL ACCESS permisos pueden crear EXTERNAL_ACCESS ensamblados.

SAFE y EXTERNAL_ACCESS los ensamblados 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.

Permiso 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 UNSAFE ensamblado 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. UNSAFE Los ensamblados también pueden subvertir el sistema de seguridad de SQL Server o 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 UNSAFE ensamblados.

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 ciertas operaciones que pueden poner en peligro la solidez del servidor no están permitidas en SAFE y EXTERNAL_ACCESS ensamblados.

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, SAFE los EXTERNAL_ACCESS ensamblados 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 ninguna API de Microsoft .NET Framework anotada con uno de los no permitidos HostProtectionAttributes desde SAFE ensamblados y EXTERNAL_ACCESS .

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

Contenido relacionado