La seguridad implica tres piezas que interactúan: sandboxing, permisos y enforcement. El sandboxing se refiere a la práctica de crear dominios aislados en los que parte del código es tratado como de plena confianza y otro código está restringido a los permisos del conjunto de concesiones para el sandbox. El código de la aplicación que se ejecuta dentro del conjunto de concesiones del sandbox se considera transparente; es decir, no puede realizar ninguna operación que pueda afectar a la seguridad. El conjunto de concesiones para la caja de arena está determinado por la evidencia (clase Evidence). Las evidencias identifican qué permisos específicos requieren las cajas de arena, y qué tipos de cajas de arena pueden crearse. Enforcement se refiere a permitir que el código transparente se ejecute sólo dentro de su conjunto de concesión.

Propósito del modelo de transparencia

La transparencia es un mecanismo de aplicación 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 traza una barrera entre el código que puede hacer cosas privilegiadas (código crítico), como llamar a código nativo, y el código que no puede (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, derivar o contener código crítico.

El objetivo principal de la aplicación de la transparencia es proporcionar un mecanismo simple y eficaz para aislar diferentes grupos de código basado en el privilegio. Dentro del contexto del modelo de caja de arena, estos grupos de privilegios son de plena confianza (es decir, no restringidos) o de confianza parcial (es decir, restringidos al conjunto de permisos concedidos a la caja de arena).

La transparencia fue introducida en la versión 2.0 de .NET Framework para simplificar el modelo de seguridad, y para hacer más fácil escribir y desplegar bibliotecas y aplicaciones seguras. El código transparente también se utiliza en Microsoft Silverlight, para simplificar el desarrollo de aplicaciones de confianza parcial.

Especificación del nivel de transparencia

El atributo SecurityRulesAttribute a nivel de ensamblaje selecciona explícitamente las reglas SecurityRuleSet que seguirá el ensamblaje. Las reglas están organizadas bajo un sistema de niveles numéricos, donde los niveles más altos significan una aplicación más estricta de las 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 principal diferencia entre los dos niveles de transparencia es que el nivel 1 no aplica las reglas de transparencia para las llamadas desde fuera del ensamblado y está pensado sólo para la compatibilidad.

Transparencia de nivel 2

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

• El código transparente, independientemente de los permisos que se le concedan (incluida la confianza total), sólo puede llamar a otro código transparente o al código crítico para la seguridad. Si el código es parcialmente confiable, sólo puede realizar acciones que son permitidas por el conjunto de permisos del dominio. El código transparente no puede hacer lo siguiente:

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

  • Contiene código inseguro o no verificable.

  • Llamar directamente a código crítico.

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

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

  • Heredar de tipos críticos.

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

• El código crítico a prueba de seguridad es de plena confianza pero es llamable por código transparente. Expone una superficie limitada de código de plena confianza. La corrección y las verificaciones de seguridad ocurren en el código safe-critical.

• El código security-critical puede llamar a cualquier código y es totalmente confiable, pero no puede ser llamado por código transparente.

Transparencia de nivel 1

El modelo de transparencia de nivel 1 fue introducido en la versión 2.0 de .NET Framework 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 estaba disponible públicamente en la versión 2.0, se utilizaba principalmente sólo dentro de Microsoft para fines de auditoría de seguridad. Mediante anotaciones, los desarrolladores pueden declarar qué tipos y miembros pueden realizar elevaciones de seguridad y otras acciones de confianza (security-critical) y cuáles no (security-transparent). El código que se identifica como transparente no requiere un alto grado de auditoría de seguridad. El nivel 1 de transparencia establece que la aplicación de la transparencia se limita al interior del conjunto. En otras palabras, cualquier tipo o miembro público que se identifique como crítico para la seguridad es crítico para la seguridad sólo dentro del conjunto. Si quieres hacer cumplir la seguridad de esos tipos y miembros cuando son llamados desde fuera del ensamblaje, debes usar demandas de enlace para la confianza total. Si no lo hace, los tipos y miembros críticos para la seguridad visibles públicamente son tratados como críticos para la seguridad y pueden ser llamados por código parcialmente confiable fuera del ensamblaje.

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 el código transparente para la seguridad.

• Las anotaciones de transparencia se aplican sólo dentro de un ensamblaje.

• Los tipos y miembros críticos para la seguridad deben utilizar demandas de enlace para reforzar la seguridad de las llamadas desde fuera del ensamblaje.

• Las reglas de herencia no se aplican.

• Existe la posibilidad de que el código transparente haga cosas perjudiciales cuando se ejecuta con plena confianza.

Aplicación de la transparencia

Las reglas de transparencia no se aplican hasta que se calcula la transparencia. En ese momento, se lanza una InvalidOperationException si se viola una regla de transparencia. El momento en que se calcula la transparencia depende de múltiples factores y no se puede predecir. Se calcula lo más tarde posible. En .NET Framework 4, el cálculo de la transparencia a nivel de ensamblado se produce antes que en .NET Framework 2.0. La única garantía es que el cálculo de la transparencia se producirá en el momento en que se necesite. Esto es similar a la forma en que el compilador justo a tiempo (JIT) puede cambiar el momento en que se compila un método y se detecta cualquier error en ese método. El cálculo de transparencia es invisible si su código no tiene ningún error de transparencia.

Ver también

• Código transparente de seguridad, nivel 1
• Código transparente de seguridad, nivel 2