Seguridad de acceso del código de integración CLR
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: esta es la directiva en vigor para todo el código administrado que se ejecuta en el equipo en el que se instala SQL Server.
Directiva de usuario: es la directiva activa para el código administrado que se hospeda en un proceso. Para SQL Server servicio se está ejecutando.
Directiva de host: esta es la directiva configurada por el host de CLR (en este caso, SQL Server) que está en vigor 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 al código CLR normalmente se encapsulan mediante interfaces de programación de aplicaciones administradas que requieren el permiso correspondiente antes de permitir el acceso al recurso. La demanda del permiso solo se satisface si todos los llamadores (en el nivel de ensamblado) de la pila de llamadas tienen el permiso de recurso correspondiente.
El conjunto de permisos de seguridad de acceso de código que se conceden al código administrado cuando se ejecuta dentro de SQL Server concede un conjunto de permisos a un ensamblado cargado en SQL Server, el conjunto final de permisos concedidos al código de usuario puede restringirse aún más por las directivas de nivel de usuario y equipo.
Conjuntos de permisos de nivel de directiva de host de SQL Server
El conjunto de permisos de seguridad de acceso de código concedidos a los ensamblados por el nivel de directiva de host SQL Server viene determinado por el conjunto de permisos especificado al crear el ensamblado. Hay tres conjuntos de permisos: SAFE
y UNSAFE
EXTERNAL_ACCESS
(especificados mediante la opción PERMISSION_SETde CREATE ASSEMBLY (Transact-SQL)).
SQL Server. No está destinada al dominio de aplicación predeterminado que estaría activo si SQL Server creara una instancia de CLR.
La directiva fija SQL Server para los ensamblados del sistema y la directiva especificada por el usuario para los 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 se basa en el propietario del ensamblado que especifica 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. |
EXTERNAL_ACCESS
EXTERNAL_ACCESS ensamblados tienen los mismos permisos que SAFE
los ensamblados, con la capacidad adicional de acceder a recursos del sistema externo, 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 permiten transacciones distribuidas. |
DNSPermission |
Unrestricted: Permiso para solicitar información de los servidores de nombres de dominio. |
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 que los ensamblados tengan acceso sin restricciones a los recursos, 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
.
Importante
SAFE
es la configuración de permisos recomendada para los ensamblados que realizan tareas de cálculo y administración de datos sin tener acceso a recursos fuera de SQL Server. EXTERNAL_ACCESS
Los ensamblados se ejecutan de forma predeterminada como la cuenta de servicio de SQL Server, solo se debe conceder permiso para ejecutarse EXTERNAL_ACCESS
a los inicios de sesión de confianza para ejecutarse como la cuenta de servicio. Desde el punto de vista de la seguridad, los ensamblados EXTERNAL_ACCESS
y UNSAFE
son idénticos. Sin embargo, los ensamblados EXTERNAL_ACCESS
proporcionan diferentes protecciones de confiabilidad y solidez que no se incluyen en los ensamblados UNSAFE
. Especificar UNSAFE
permite que el código del ensamblado realice operaciones no válidas en el SQL Server. Para obtener más información sobre cómo crear ensamblados CLR en SQL Server, consulte Administración de ensamblados de integración de 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 especifican los EXTERNAL_ACCESS
conjuntos de permisos o UNSAFE
y el código administrado intenta acceder a los 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 tiene 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í |
Consulte también
Seguridad de la integración CLR
Atributos de protección del host y programación de la integración CLR
Restricciones del modelo de programación de la integración CLR
Entorno hospedado CLR