Código transparente en seguridad
La seguridad implica tres partes interrelacionadas: espacio aislado, permisos y cumplimiento. El espacio aislado hace referencia a la práctica de crear dominios aislados en los que determinado código se trata como de plena confianza y otro código está restringido a los permisos del conjunto de permisos concedido al espacio aislado. Se considera que el código de aplicación que se ejecuta dentro del conjunto de permisos concedido del espacio aislado es transparente; es decir, no puede realizar ninguna operación que pueda afectar a la seguridad. El conjunto de permisos concedido al espacio aislado está determinado por la evidencia. La evidencia identifica qué permisos concretos requieren los espacios aislados y qué tipos de espacios aislados se pueden crear. El cumplimiento hace referencia al hecho de permitir que el código transparente solo se ejecute dentro de su conjunto de permisos concedido.
.gif "Nota importante") Importante |
|---|
La directiva de seguridad era un elemento clave en versiones anteriores de .NET Framework.A partir de .NET Framework versión 4, la directiva de seguridad está 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 y recomendaciones sobre la mitigación, vea Compatibilidad con la directiva de seguridad de acceso del código y migración. |
En este tema se describe el modelo de transparencia de forma más detallada. Contiene las siguientes secciones:
Propósito del modelo de transparencia
Especificar el nivel de transparencia
Cumplimiento de la transparencia
Propósito del modelo de transparencia
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 levanta una barrera entre código que puede realizar acciones con privilegios (código crítico), como llamar a código nativo, y código que no puede realizar dichas acciones (código transparente). El código transparente puede ejecutar comandos dentro de los límites del conjunto de permisos en el que está funcionando, pero no puede ejecutar, derivar ni contener código crítico.
El objetivo principal de la exigencia de transparencia es proporcionar un mecanismo sencillo y eficaz para aislar grupos diferentes de código según los privilegios. Dentro del 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).
| Importante |
|---|
El modelo de transparencia transciende la seguridad de acceso del código.El compilador Just-In-Time (JIT) exige el cumplimiento de la transparencia y sigue en vigor sea cual sea el conjunto de permisos concedido a un ensamblado, incluida la plena confianza. |
La transparencia se introdujo en la versión 2.0 de .NET Framework para simplificar el modelo de seguridad y facilitar la escritura e implementación de bibliotecas y aplicaciones seguras. El código transparente también se utiliza en Microsoft Silverlight para simplificar el desarrollo de aplicaciones de confianza parcial.
.gif "Nota") Nota |
|---|
Al desarrollar una aplicación de confianza parcial, debe tener en cuenta los requisitos de permisos para los hosts de destino.Puede desarrollar una aplicación que utiliza recursos que algunos hosts no permiten.Esta aplicación se compilará sin errores, pero presentará un error al cargarla en el entorno hospedado.Si ha desarrollado la aplicación mediante Visual Studio, puede habilitar la depuración en confianza parcial o en un conjunto de permisos restringido del entorno de desarrollo.Para obtener más información, vea 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
Especificar el nivel de transparencia
El atributo SecurityRulesAttribute de nivel de ensamblado selecciona explícitamente las reglas SecurityRuleSet que seguirá el ensamblado. Las reglas están organizadas en un sistema de niveles numéricos, donde los niveles más altos suponen un cumplimiento más estricto de las reglas de seguridad.
Los niveles son los siguientes:
Nivel 2 (Level2): reglas de transparencia de .NET Framework 4.
Nivel 1 (Level1): reglas de transparencia de .NET Framework 2.0.
La principal diferencia entre los dos niveles de transparencia es que el nivel 1 no exige el cumplimiento de las reglas de transparencia para llamadas de fuera del ensamblado y está previsto solo para compatibilidad.
| Importante |
|---|
Solo debe especificar el nivel 1 de transparencia para cuestiones de compatibilidad; es decir, especifique el nivel 1 únicamente para código desarrollado con .NET Framework 3.5 o versiones anteriores, que utilice el atributo AllowPartiallyTrustedCallersAttribute o que no utilice el modelo de transparencia.Por ejemplo, utilice transparencia de nivel 1 para ensamblados de .NET Framework 2.0 que permiten llamadas de llamadores de confianza parcial (APTCA).Con el código que se desarrolla para .NET Framework 4, utilice siempre la transparencia de nivel 2. |
Transparencia de nivel 2
La transparencia de nivel 2 se introdujo en .NET Framework versión 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, sean cuales sean los permisos concedidos (incluso 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 las acciones 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 privilegios.
Contener código no seguro o no comprobable.
Llamar directamente a código crítico.
Llamar a código nativo o código que tenga 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 los métodos virtuales críticos ni 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 es invocable por código transparente. Expone 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 y disponible desde código transparente.
El código crítico para la seguridad puede llamar a cualquier código y es de plena confianza, pero no puede ser llamado por código transparente.
Transparencia de nivel 1
El modelo de transparencia de nivel 1 se introdujo en la versión 2.0 de .NET Framework para permitir a los desarrolladores reducir la cantidad de código que está sujeta a una auditoría de seguridad. Aunque la transparencia de nivel 1 estaba públicamente disponible en la versión 2.0, se utilizó principalmente solo 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 (críticas para la seguridad) y cuáles no (transparentes en seguridad). El código que se identifica como transparente no requiere ningún grado elevado de auditoría de seguridad. La transparencia de nivel 1 indica que el cumplimiento de la transparencia se limita al interior del ensamblado. En otras palabras, cualquier tipo o miembro público que se identifica como crítico para la seguridad solo lo es dentro del ensamblado. Si desea exigir el cumplimiento de la seguridad para estos tipos y miembros cuando se les llama desde fuera del ensamblado, debe utilizar peticiones de vínculo para plena confianza. Si no lo hace, los tipos y miembros críticos para la seguridad públicamente visibles se tratan como críticos para la seguridad y disponibles desde código transparente y pueden ser llamados por código de confianza parcial 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.
Se exige el cumplimiento de las anotaciones de transparencia solo dentro de un ensamblado.
Los tipos y miembros críticos para la seguridad deben utilizar peticiones de vínculo para exigir el cumplimiento de la seguridad para llamadas de fuera del ensamblado.
No se exige el cumplimiento de reglas de herencia.
El código transparente tiene el potencial para realizar acciones dañinas cuando se ejecuta en plena confianza.
Volver al principio
Cumplimiento de la transparencia
No se exige el cumplimiento de reglas de transparencia hasta que ésta se haya calculado. En ese momento, se produce InvalidOperationException si se infringe una regla de transparencia. El tiempo que se tarda en calcular 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 del nivel de ensamblado se produce antes que en .NET Framework 2.0. La única garantía es que el cálculo de transparencia se producirá en el momento en que sea necesario. Esto es similar al modo en que el compilador Just-In-Time (JIT) puede cambiar el punto cuando se compila un método y se detecta en éste cualquier error. El cálculo de la transparencia no es visible si su código no tiene ningún error de transparencia.
Volver al principio