Programación en SQL Server y atributos de protección de host
La capacidad de cargar y ejecutar código administrado en un host SQL Server requiere cumplir los requisitos del host tanto en lo relativo a seguridad de acceso a código como a protección de recursos del host. Los requisitos de seguridad de acceso a código se especifican a través de uno de los tres conjuntos de permisos de SQL Server: SAFE, EXTERNAL-ACCESS o UNSAFE. El código que ejecutado dentro de los conjuntos de permisos SAFE o EXTERNAL-ACCESS deben evitar ciertos tipos o miembros que tienen aplicado el atributo HostProtectionAttribute. El atributo HostProtectionAttribute no es tanto un permiso de seguridad como una garantía de fiabilidad en cuanto a que identifica construcciones de código específicas, bien sean tipos o métodos, que pueden no estar permitidos por el host. El uso del atributo HostProtectionAttribute fuerza un modelo de programación que ayuda a proteger la estabilidad del host.
Atributos de protección del host
Los atributos de protección del host identifican los tipos o miembros que no se ajustan al modelo de programación del host y representan los siguientes niveles crecientes de amenaza de confiabilidad:
En caso contrario 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 tenga un HostProtectionAttribute que especifique un valor de HostProtectionResource de SharedState, Synchronization, MayLeakOnAbort o ExternalProcessMgmt. De esta forma, se evita que los ensamblados llamen a miembros que habiliten el estado compartido, ejecuten la sincronización, puedan causar una pérdida de recursos al terminar o afecten la integridad de los procesos de SQL Server.
Tipos y miembros denegados
La tabla siguiente identifica los tipos y miembros cuyos valores de HostProtectionResource 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 se cargan los ensamblados en la base de datos, el autor del ensamblado puede especificar uno de los tres conjuntos de permisos para dicho ensamblado: SAFE, EXTERNAL-ACCESS o UNSAFE.
Conjunto de permisos |
SAFE |
EXTERNAL-ACCESS (Acceso externo) |
UNSAFE |
---|---|---|---|
Seguridad de acceso a código |
Sólo ejecución |
Ejecución + acceso a los recursos externos |
Sin restricciones |
Restricciones del modelo de programación |
Sí |
Sí |
Ninguna restricción |
Requisito de verificabilidad |
Sí |
Sí |
No |
Capacidad para 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 confiabilidad alta y características de seguridad. Los ensamblados SAFE tienen permisos suficientes para la ejecución, realizar cálculos y tener acceso a la base de datos local. Los ensamblados SAFE deben tener verificabilidad de la seguridad de los tipos y no pueden llamar a código no administrado.
EXTERNAL-ACCESS proporciona una opción de seguridad intermedia, permitiendo al código tener acceso a los recursos externos a la base de datos pero teniendo todavía la confiabilidad y seguridad de SAFE.
UNSAFE está pensado para el código de alta confianza que sólo pueden crear los administradores de bases de datos. Este código de confianza no tiene ninguna restricción de acceso a código y puede llamar al código no administrado (nativo).
SQL Server utiliza la capa de directiva de seguridad de acceso a código de nivel de host para configurar una directiva de host que concede uno de los tres conjuntos de permisos basados en 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 el código administrado en SQL Server requiere funciones, procedimientos y tipos que no necesitan utilizar el estado mantenido a lo largo de varias invocaciones o compartir el estado entre 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.
A la vista de estas consideraciones, SQL Server deniega el uso de variables estáticas y miembros de datos estáticos. En el caso de ensamblados SAFE y EXTERNAL-ACCESS, SQL Server examina los metadatos del ensamblado en tiempo de creación de ensamblado (CREATE ASSEMBLY) no puede crear dichos ensamblados si encuentra el uso de variables y miembros de datos estáticos.