Para ver el artículo en inglés, active la casilla Inglés. También puede ver el texto en inglés en una ventana emergente si pasa el puntero del mouse por el texto.
Traducción
Inglés
Información
El tema que ha solicitado se muestra abajo. Sin embargo, este tema no se encuentra en la biblioteca.

Security-Transparent Code

.NET Framework (current version)
 

System_CAPS_cautionPrecaución

Seguridad de acceso del código y código de confianza parcial

.NET Framework proporciona seguridad de acceso del código (CAS), que es un mecanismo para el cumplimiento de los distintos niveles de confianza en diferentes códigos que se ejecutan en la misma aplicación.  La seguridad de acceso de código de .NET Framework no debería usarse como mecanismo para reforzar los límites de seguridad basados en el origen del código u otros aspectos de identidad. Estamos actualizando las guías para reflejar que la seguridad de acceso de código y el código transparente de seguridad no se podrán usar como límites de seguridad con código de confianza parcial, especialmente en código con orígenes desconocidos. Le aconsejamos que no cargue ni ejecute código de orígenes desconocidos sin contar con medidas de seguridad alternativas.

Esta directiva se aplica a todas las versiones de .NET Framework, pero no se aplica a la versión de .NET Framework incluida en Silverlight.

En la seguridad participan tres partes interrelacionadas: espacio aislado, permisos y cumplimiento. Espacio aislado se refiere a la práctica de crear dominios aislados, donde una parte del código se trata como un código de plena confianza y la otra se restringe al conjunto de permisos concedidos al espacio aislado. El código de aplicación que se ejecuta en el conjunto de permisos del espacio aislado se considera transparente, es decir, no puede realizar operaciones que puedan afectar a la seguridad. El conjunto de permisos del espacio aislado se determina mediante evidencia (clase Evidence). La evidencia identifica los permisos específicos que los espacios aislados requieren y los tipos de espacios aislados que se pueden crear. El cumplimiento se refiere a permitir que el código transparente tan solo se ejecute dentro su conjunto de permisos.

System_CAPS_importantImportante

La directiva de seguridad era un elemento clave en las versiones anteriores de .NET Framework, pero tras la versión .NET Framework 4 se ha quedado obsoleta. La eliminación de la directiva de seguridad es independiente de la transparencia de seguridad. Para obtener información sobre los efectos de este cambio, vea Code Access Security Policy Compatibility and Migration.

En este tema se describe el modelo de transparencia con más detalle. Contiene las siguientes secciones:

La transparencia es un mecanismo de cumplimiento que separa el código que se ejecuta como parte de la aplicación del código que se ejecuta como parte de la infraestructura. La transparencia dibuja una barrera entre el código que puede realizar acciones con privilegios (código crítico), como llamar a código nativo, y el código sin esa capacidad (código transparente). El código transparente puede ejecutar comandos dentro de los límites del conjunto de permisos en el que opera, pero no puede ejecutar ni contener código crítico, ni tampoco derivar de él.

El objetivo principal del cumplimiento de la transparencia es proporcionar un mecanismo sencillo y eficaz para aislar grupos diferentes de código en función de los privilegios. En el contexto del modelo de espacio aislado, estos grupos de privilegios son de plena confianza (es decir, no restringidos) o de confianza parcial (es decir, restringidos al conjunto de permisos concedido al espacio aislado).

System_CAPS_importantImportante

El modelo de transparencia trasciende a la seguridad de acceso del código. El compilador Just-In-Time hace cumplir la transparencia, la cual permanece en vigor independientemente del conjunto de permisos concedidos a un ensamblado, incluida la plena confianza.

La transparencia se introdujo en .NET Framework 2.0 para simplificar el modelo de seguridad y para facilitar la escritura e implementación de aplicaciones y bibliotecas seguras. El código transparente también se usa en Microsoft Silverlight a fin de simplificar el desarrollo de aplicaciones de confianza parcial.

System_CAPS_noteNota

Al desarrollar una aplicación de confianza parcial, hay que tener en cuenta los requisitos de permisos para los hosts de destino. Si se desarrolla una aplicación que usa recursos no permitidos por algunos hosts, la aplicación se compilará sin problemas, pero producirá error cuando se cargue en el entorno hospedado. Si ha desarrollado su aplicación con Visual Studio, puede habilitar la depuración en confianza parcial o en un conjunto de permisos restringidos desde el entorno de desarrollo. Para obtener más información, consulta Cómo: Depurar una aplicación ClickOnce con permisos restringidos. La característica Calcular permisos proporcionada para aplicaciones ClickOnce también está disponible para cualquier aplicación de confianza parcial.

Volver al principio

El atributo SecurityRulesAttribute de nivel de ensamblado selecciona de forma explícita las reglas SecurityRuleSet que seguirá el ensamblado. Las reglas se organizan en un sistema de niveles numéricos en el que los niveles superiores implican un cumplimiento más estricto de reglas de seguridad.

Los niveles son los siguientes:

  • Nivel 2 (Level2): las reglas de transparencia de .NET Framework 4.

  • Nivel 1 (Level1): las reglas de transparencia de .NET Framework 2.0.

La diferencia principal entre los dos niveles de transparencia es que el nivel 1 no exige el cumplimiento de las reglas de transparencia en las llamadas hechas desde fuera del ensamblado y se usa únicamente por razones de compatibilidad.

System_CAPS_importantImportante

Debe especificar la transparencia de nivel 1 solo para la compatibilidad; es decir, especifique el nivel 1 únicamente para el código que se desarrolló con .NET Framework 3.5 o versiones anteriores que usa el atributo AllowPartiallyTrustedCallersAttribute o que no usa el modelo de transparencia. Por ejemplo, use la transparencia de nivel 1 para ensamblados de .NET Framework 2.0 que permiten llamadas de llamadores de confianza parcial (APTCA). Con código que se desarrolló para .NET Framework 4, use siempre la transparencia de nivel 2.

La transparencia de nivel 2 se introdujo en .NET Framework 4. Los tres principios de este modelo son código transparente, código crítico para la seguridad y disponible desde código transparente, y código crítico para la seguridad.

  • El código transparente, independientemente de los permisos que se le conceden (incluida la plena confianza), solo puede llamar a otro código transparente o a código crítico para la seguridad y disponible desde código transparente. Si el código es de confianza parcial, solo puede realizar acciones permitidas por el conjunto de permisos del dominio. El código transparente no puede hacer lo siguiente:

    • Realizar una operación Assert o una elevación de privilegios.

    • Contener código no seguro o no comprobable.

    • Llamar directamente a código crítico.

    • Llamar a código nativo o a código que tiene el atributo SuppressUnmanagedCodeSecurityAttribute.

    • Llamar a un miembro que está protegido por LinkDemand.

    • Heredar de tipos críticos.

    Además, los métodos transparentes no pueden invalidar métodos virtuales críticos o implementar métodos de interfaz críticos.

  • El código crítico para la seguridad y disponible desde código transparente es de plena confianza, pero puede llamarlo el código transparente y exhibe un área expuesta limitada de código de plena confianza. Las comprobaciones de corrección y seguridad se producen en código crítico para la seguridad.

  • El código crítico para la seguridad puede llamar a cualquier código y es de plena confianza, pero no se puede llamar mediante código transparente.

El modelo de transparencia de nivel 1 se introdujo en .NET Framework 2.0 para permitir a los desarrolladores reducir la cantidad de código que está sujeto a una auditoría de seguridad. Aunque la transparencia de nivel 1 se puso a disposición del público en la versión 2.0, se usaba fundamentalmente de forma interna en Microsoft con fines de auditoría de seguridad. Mediante las anotaciones, los desarrolladores pueden declarar qué tipos y miembros pueden realizar elevaciones de seguridad y otras acciones de confianza (críticos para la seguridad) y cuáles no (transparentes en seguridad). El código que se identifica como transparente no requiere un alto grado de auditoría de seguridad. La transparencia de nivel 1 indica que el cumplimiento de la transparencia se limita a dentro del ensamblado. En otras palabras, los tipos o miembros públicos que se identifican como críticos para la seguridad lo son únicamente dentro del ensamblado. Si desea exigir el cumplimiento de la seguridad en estos tipos y miembros cuando se les llama desde fuera del ensamblado, use peticiones de vínculo de plena confianza. Si no lo hace, los miembros y los tipos críticos para la seguridad y públicamente visibles se tratarán como críticos para la seguridad y disponibles desde código transparente, y podrán ser llamados por código de confianza parcial desde fuera del ensamblado.

El modelo de transparencia de nivel 1 tiene las siguientes limitaciones:

  • Los tipos y miembros críticos para la seguridad que son públicos son accesibles desde código transparente en seguridad.

  • Las anotaciones de transparencia se aplican solo dentro de un ensamblado.

  • Los tipos y miembros críticos para la seguridad deben usar peticiones de vínculo para exigir el cumplimiento de la seguridad en las llamadas desde fuera del ensamblado.

  • No se aplican las reglas de herencia.

  • Existe la posibilidad de que el código transparente sea perjudicial si se ejecuta con plena confianza.

Volver al principio

Las reglas de transparencia no se aplican hasta que se calcula la transparencia. En ese momento, se genera una InvalidOperationException si se infringe una regla de transparencia. El momento en que se calcula la transparencia depende de varios factores y no se puede predecir. Se calcula lo más tarde posible. En .NET Framework 4, el cálculo de transparencia de nivel de ensamblado se produce antes de que en .NET Framework 2.0. La única garantía es que el cálculo de transparencia se producirá cuando sea necesario. Esto es similar a cómo el compilador Just-In-Time (JIT) puede cambiar el punto cuando se compila un método y se detectan errores en ese método. El cálculo de transparencia es invisible si el código no tiene errores de transparencia.

Mostrar: