Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La capacidad de cargar y ejecutar código administrado en un host de SQL Server requiere cumplir los requisitos del host tanto para la seguridad de acceso de código como para la protección de recursos de host. Los requisitos de seguridad de acceso de código se especifican mediante uno de los tres conjuntos de permisos de SQL Server: SAFE, EXTERNAL-ACCESS o UNSAFE. El código que se ejecuta en los conjuntos de permisos SAFE o EXTERNAL-ACCESS debe evitar determinados tipos o miembros que tengan aplicado el HostProtectionAttribute atributo . El HostProtectionAttribute no es tanto un permiso de seguridad como una garantía de fiabilidad al identificar construcciones específicas de código, ya sean tipos o métodos, que el anfitrión pueda no permitir. El uso del HostProtectionAttribute aplica un modelo de programación que ayuda a proteger la estabilidad del host.
Nota:
La seguridad de acceso al código (CAS) está en desuso en todas las versiones de .NET Framework y .NET. Las versiones recientes de .NET no respetan las anotaciones CAS y producen errores si se utilizan las APIs relacionadas con CAS. Los desarrolladores deben buscar medios alternativos para realizar tareas de seguridad.
Atributos de protección del host
Los atributos de protección de host identifican tipos o miembros que no se ajustan al modelo de programación de host y representan los siguientes niveles crecientes de amenaza de confiabilidad:
Por lo demás, son benignos.
Podrían provocar la desestabilización del código de usuario administrado por servidor.
Podría provocar la desestabilización del propio proceso de servidor.
SQL Server no permite el uso de un tipo o miembro que tiene un HostProtectionAttribute que especifica un HostProtectionResource valor de SharedState, Synchronization, MayLeakOnAbort o ExternalProcessMgmt. Esto impide que los ensamblados llamen a los miembros que habilitan el estado compartido, realizan una sincronización, podrían provocar una pérdida de recursos al finalizar o afectan a la integridad del proceso de SQL Server.
Tipos y miembros no permitidos
En la tabla siguiente se identifican los tipos y miembros cuyos HostProtectionResource valores no están permitidos por SQL Server.
Conjuntos de permisos de SQL Server
SQL Server permite a los usuarios especificar los requisitos de confiabilidad para el código implementado en una base de datos. Cuando los ensamblados se cargan en la base de datos, el autor del ensamblado puede especificar uno de los tres conjuntos de permisos para ese ensamblado: SAFE, EXTERNAL-ACCESS o UNSAFE.
| Conjunto de permisos | SEGURO | EXTERNAL-ACCESS | INSEGURO |
|---|---|---|---|
| Seguridad de acceso al código | Solo ejecución | Ejecución + acceso a recursos externos | Sin restricciones |
| Restricciones del modelo de programación | Sí | Sí | Sin restricciones |
| Requisito de capacidad de comprobación | Sí | Sí | No |
| Capacidad de llamar a código nativo | No | No | Sí |
SAFE es el modo más confiable y seguro, con restricciones asociadas relativas al modelo de programación permitido. El código SAFE tiene características de alta confiabilidad y seguridad. Los ensamblados SAFE tienen permisos suficientes para la ejecución, realización de cálculos y obtención de acceso a la base de datos local. Los ensamblados SAFE deben tener capacidad para comprobar la seguridad de los tipos y no pueden llamar a código no administrado.
EXTERNAL-ACCESS proporciona una opción de seguridad intermedia, lo que permite que el código acceda a los recursos externos a la base de datos, pero sigue teniendo la confiabilidad y seguridad de SAFE.
UNSAFE está pensado para el código de alta confianza que solo pueden crear los administradores de bases de datos. Este código de confianza no tiene ninguna restricción de acceso y puede llamar a un código no administrado (nativo).
SQL Server utiliza la capa de directiva de seguridad de acceso de código a nivel de host para configurar una política de host que otorga uno de tres conjuntos de permisos según el conjunto de permisos almacenado en los catálogos de SQL Server. El código administrado que se ejecuta dentro de la base de datos siempre obtiene uno de estos conjuntos de permisos de acceso a código.
Restricciones del modelo de programación
El modelo de programación para código administrado en SQL Server requiere funciones, procedimientos y tipos que no requieren el uso del estado mantenido en varias invocaciones o el uso compartido de estado en varias sesiones de usuario. Además, como se explicó antes, la presencia de estado compartido puede producir excepciones críticas que tienen un impacto en la escalabilidad y la confiabilidad de la aplicación.
Dadas estas consideraciones, SQL Server no permite el uso de variables estáticas y miembros de datos estáticos. En el caso de los ensamblados SAFE y EXTERNAL-ACCESS, SQL Server examina los metadatos del ensamblado en tiempo CREATE ASSEMBLY y produce un error en la creación de dichos ensamblados si encuentra el uso de miembros y variables de datos estáticos.