Seguridad de acceso del código de integración CLR

Artículo
05/08/2013

Common Language Runtime (CLR) admite un modelo de seguridad denominado seguridad de acceso del código para el código administrado. En este modelo, se conceden permisos a los ensamblados basados en la identidad del código. Para obtener más información, vea la sección sobre seguridad de acceso del código en el kit de desarrollo de software de .NET Framework.

La directiva de seguridad que determina los permisos que se conceden a los ensamblados se define en tres sitios distintos:

Directiva de equipo: es la directiva activa para todo el código administrado que se ejecuta en el equipo donde está instalado SQL Server.
Directiva de usuario: es la directiva activa para el código administrado que se hospeda en un proceso. Para SQL Server, la directiva de usuario es específica de la cuenta de Windows en la que se ejecuta el servicio SQL Server.
Directiva de host: es la directiva configurada por el host de CLR (en este caso, SQL Server) que está activa para el código administrado que se ejecuta en ese host.

El mecanismo de seguridad de acceso del código admitido por CLR se basa en el supuesto de que el tiempo de ejecución puede hospedar código de plena confianza y código de confianza parcial. Los recursos protegidos por la seguridad de acceso del código de CLR suelen empaquetarse mediante interfaces de programación de aplicaciones que requieren el permiso correspondiente antes de permitir el acceso al recurso. La solicitud de permiso solamente se satisface si todos los autores de llamadas (en el nivel de ensamblado) de la pila de llamadas tienen el permiso correspondiente para el recurso.

El conjunto de permisos de seguridad de acceso del código que se conceden al código administrado cuando se ejecuta en SQL Server es la combinación del conjunto de permisos que conceden los tres niveles de directiva mencionados anteriormente. Aunque SQL Server conceda un conjunto de permisos a un ensamblado cargado en SQL Server, las directivas de nivel de usuario y de equipo pueden restringir aún más el posible conjunto de permisos que se concede al código de usuario.

Conjuntos de permisos de nivel de directiva de host de SQL Server

El conjunto de permisos de seguridad de acceso del código que se concede a los ensamblados mediante el nivel de directiva de host de SQL Server viene determinado por el conjunto de permisos especificado al crear el ensamblado. Existen tres conjuntos de permisos: SAFE, EXTERNAL_ACCESS y UNSAFE (que se especifica con la opción PERMISSION_SET de CREATE ASSEMBLY (Transact-SQL)).

SQL Server proporciona un nivel de directiva de seguridad de nivel de host a CLR mientras lo hospeda; esta directiva es un nivel de directiva adicional por debajo de los dos niveles de directiva que siempre están activos. Esta directiva se establece para cada dominio de aplicación creado por SQL Server. Esta directiva no está pensada para el dominio de aplicación predeterminado que estaría activo cuando SQL Server crea una instancia de CLR.

La directiva de nivel de host de SQL Server es una combinación de la directiva fija de SQL Server para ensamblados del sistema y la directiva especificada por el usuario para ensamblados de usuario.

La directiva fija para ensamblados CLR y ensamblados del sistema de SQL Server les concede plena confianza.

La parte especificada por el usuario de la directiva de host de SQL Server depende de que el propietario de los ensamblados especifique uno de los tres depósitos de permisos para cada ensamblado. Para obtener más información acerca de los permisos de seguridad que se muestran a continuación, vea el SDK de .NET Framework.

SAFE

Solo se permiten el cálculo interno y el acceso a datos local. SAFE es el conjunto de permisos más restrictivo. El código que ejecuta un ensamblado con permisos SAFE no puede tener acceso a recursos externos del sistema, como archivos, la red, variables de entorno o el Registro.

Los ensamblados SAFE tienen los siguientes permisos y valores:

Permiso	Valor(es)/descripción
SecurityPermission	Execution: permiso para ejecutar el código administrado.
SqlClientPermission	Context connection = true, context connection = yes: solo puede usarse la conexión de contexto (context-connection) y la cadena de conexión solo puede especificar un valor "context connection=true" o "context connection=yes". AllowBlankPassword = false: no se permiten contraseñas en blanco.

SecurityPermission

Execution: permiso para ejecutar el código administrado.

SqlClientPermission

Context connection = true, context connection = yes: solo puede usarse la conexión de contexto (context-connection) y la cadena de conexión solo puede especificar un valor "context connection=true" o "context connection=yes".

AllowBlankPassword = false: no se permiten contraseñas en blanco.

EXTERNAL_ACCESS

Los ensamblados EXTERNAL_ACCESS tienen los mismos permisos que los ensamblados SAFE , con la capacidad adicional de obtener acceso a recursos externos del sistema, como archivos, redes, variables de entorno y el Registro.

Los ensamblados EXTERNAL_ACCESS también tienen los siguientes permisos y valores:

Permiso	Valor(es)/descripción
DistributedTransactionPermission	Unrestricted: se admiten transacciones distribuidas.
DNSPermission	Unrestricted: permiso para solicitar información a los servidores de nombres de dominio (DNS).
EnvironmentPermission	Unrestricted: se permite un acceso total a las variables de entorno del sistema y del usuario.
EventLogPermission	Administer: se permiten las acciones siguientes: crear un origen de eventos, leer los registros existentes, eliminar orígenes o registros de eventos, responder a entradas, borrar un registro de eventos, escuchar eventos y obtener acceso a una colección de todos los registros de eventos.
FileIOPermission	Unrestricted: se permite un acceso total a los archivos y carpetas.
KeyContainerPermission	Unrestricted: se permite un acceso total a los contenedores de claves.
NetworkInformationPermission	Access: se permite hacer ping.
RegistryPermission	Permite derechos de lectura de HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CURRENT_CONFIG y HKEY_USERS.
SecurityPermission	Assertion: posibilidad de afirmar que todos los autores de llamadas de este código tienen el permiso necesario para la operación. ControlPrincipal: posibilidad de manipular el objeto principal. Execution: permiso para ejecutar el código administrado. SerializationFormatter: posibilidad de ofrecer servicios de serialización.
SmtpPermission	Access: se permiten conexiones salientes al puerto 25 del host SMTP.
SocketPermission	Connect: se permiten conexiones salientes (todos los puertos, todos los protocolos) en una dirección de transporte.
SqlClientPermission	Unrestricted: se permite un acceso total al origen de datos.
StorePermission	Unrestricted: se permite un acceso total a los almacenes de certificados X.509.
WebPermission	Connect: se permiten conexiones salientes a recursos web.

UNSAFE

UNSAFE permite a los ensamblados un acceso sin límites a los recursos situados tanto dentro como fuera de SQL Server. El código que se ejecuta desde un ensamblado UNSAFE también puede llamar a código no administrado.

A los ensamblados UNSAFE se les concede FullTrust.

Nota de seguridad
SAFE es la configuración de permiso recomendada para los ensamblados que realizan tareas de administración de datos y cálculos sin tener acceso a los recursos fuera de SQL Server. Se recomienda el uso de EXTERNAL_ACCESS para los ensamblados que necesitan obtener acceso a recursos ajenos a SQL Server. De forma predeterminada, los ensamblados EXTERNAL_ACCESS se ejecutan como la cuenta de servicio de SQL Server. Es posible que el código EXTERNAL_ACCESS represente de forma explícita el contexto de seguridad de la autenticación de Windows. Dado que la acción predeterminada es ejecutarse como la cuenta de servicio de SQL Server, solo debería concederse permiso para ejecutar EXTERNAL_ACCESS a los inicios de sesión en los que se confía para que se ejecuten como la cuenta de servicio. Desde el punto de vista de la seguridad, los ensamblados UNSAFE y EXTERNAL_ACCESS son idénticos. Sin embargo, los ensamblados EXTERNAL_ACCESS proporcionan diferentes protecciones de confiabilidad y solidez que no se incluyen en los ensamblados UNSAFE. Al especificar UNSAFE se permite al código del ensamblado realizar operaciones ilegales en el espacio del proceso de SQL Server, lo que podría comprometer la solidez y la escalabilidad de SQL Server. Para obtener más información acerca de la forma de crear ensamblados CLR en SQL Server, vea Administrar ensamblados de integración CLR.

SAFE es la configuración de permiso recomendada para los ensamblados que realizan tareas de administración de datos y cálculos sin tener acceso a los recursos fuera de SQL Server. Se recomienda el uso de EXTERNAL_ACCESS para los ensamblados que necesitan obtener acceso a recursos ajenos a SQL Server. De forma predeterminada, los ensamblados EXTERNAL_ACCESS se ejecutan como la cuenta de servicio de SQL Server. Es posible que el código EXTERNAL_ACCESS represente de forma explícita el contexto de seguridad de la autenticación de Windows. Dado que la acción predeterminada es ejecutarse como la cuenta de servicio de SQL Server, solo debería concederse permiso para ejecutar EXTERNAL_ACCESS a los inicios de sesión en los que se confía para que se ejecuten como la cuenta de servicio. Desde el punto de vista de la seguridad, los ensamblados UNSAFE y EXTERNAL_ACCESS son idénticos. Sin embargo, los ensamblados EXTERNAL_ACCESS proporcionan diferentes protecciones de confiabilidad y solidez que no se incluyen en los ensamblados UNSAFE. Al especificar UNSAFE se permite al código del ensamblado realizar operaciones ilegales en el espacio del proceso de SQL Server, lo que podría comprometer la solidez y la escalabilidad de SQL Server. Para obtener más información acerca de la forma de crear ensamblados CLR en SQL Server, vea Administrar ensamblados de integración CLR.

Obtener acceso a recursos externos

Si un tipo definido por el usuario (UDT), un procedimiento almacenado u otro tipo de ensamblado de construcción se registra con el conjunto de permisos SAFE, el código administrado que se ejecuta en la construcción no puede obtener acceso a los recursos externos. Sin embargo, si se especifica cualquiera de los conjuntos de permisos EXTERNAL_ACCESS o UNSAFE y el código administrado intenta obtener acceso a recursos externos, SQL Server aplica las reglas siguientes:

Si	Entonces
El contexto de ejecución corresponde a un inicio de sesión de SQL Server.	Se deniegan los intentos de acceso a recursos externos y se inicia una excepción de seguridad.
El contexto de ejecución corresponde a un inicio de sesión de Windows y el contexto de ejecución es el autor de la llamada original.	Se obtiene acceso al recurso externo en el contexto de seguridad de la cuenta de servicio de SQL Server.
El autor de llamada no es el autor de llamada original.	Se deniega el acceso y se inicia una excepción de seguridad.
El contexto de ejecución corresponde a un inicio de sesión de Windows y el contexto de ejecución es el autor de llamada original, y el autor de llamada ha sido suplantado.	El acceso usa el contexto de seguridad del autor de llamada, no la cuenta de servicio.

Resumen del conjunto de permisos

En el gráfico siguiente se resumen las restricciones y los permisos concedidos a los conjuntos de permisos SAFE, EXTERNAL_ACCESS y UNSAFE.

	SAFE	EXTERNAL_ACCESS	UNSAFE
Code Access Security Permissions	Solo ejecución	Ejecución + acceso a recursos externos	Sin restringir (se incluye P/Invoke)
Programming model restrictions	Sí	Sí	Sin restricciones
Verifiability requirement	Sí	Sí	No
Local data access	Sí	Sí	Sí
Ability to call native code	No	No	Sí