Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La transparencia ayuda a los desarrolladores a escribir bibliotecas de .NET Framework más seguras que exponen la funcionalidad a código de confianza parcial. La transparencia de nivel 1 se introdujo en la versión 2.0 de .NET Framework y se utilizó principalmente dentro de Microsoft. A partir de .NET Framework versión 4, puede utilizar la transparencia de nivel 2. Sin embargo, se ha mantenido la transparencia de nivel 1 para que pueda identificar código heredado que se debe ejecutar con las reglas de seguridad anteriores.
.gif "Nota importante") Importante |
|---|
Solo debería especificar el nivel 1 de transparencia por cuestiones de compatibilidad; es decir, especifique nivel 1 únicamente para el código que se desarrolló con .NET Framework 3.5 o anterior que utilice AllowPartiallyTrustedCallersAttribute o no utilice el modelo de la 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 el nivel 2 de transparencia. |
Este tema contiene las siguientes secciones:
El modelo de transparencia de nivel 1
Atributos de transparencia
Ejemplos de transparencia en seguridad
El modelo de transparencia de nivel 1
Cuando se usa la transparencia de nivel 1, se utiliza un modelo de seguridad que separa el código en métodos transparentes en seguridad, métodos críticos para la seguridad y disponibles desde código transparente, y métodos críticos para la seguridad.
Puede marcar como transparente en seguridad un ensamblado entero, algunas clases de un ensamblado o algunos métodos de una clase. El código transparente en seguridad no puede elevar los privilegios. Esta restricción tiene tres consecuencias:
El código transparente en seguridad no puede realizar acciones Assert.
Cualquier petición de vínculo a la que podría responder el código transparente en seguridad se convierte en una demanda completa.
Cualquier código no seguro (no comprobable) que deba ejecutarse en código transparente en seguridad da lugar a una demanda completa del permiso de seguridad UnmanagedCode.
Common Language Runtime (CLR) exige estas reglas durante la ejecución. El código transparente en seguridad cumple todos los requisitos de seguridad del código que devuelve a sus llamadores. Las demandas que pasan por el código transparente en seguridad no pueden elevar los privilegios. Si una aplicación de nivel de confianza bajo llama al código transparente en seguridad y crea una demanda de privilegios altos, la demanda volverá al código de nivel de confianza bajo y se producirá un error. El código transparente en seguridad no puede detener la demanda porque no puede realizar acciones de aserción. Si se llama al mismo código transparente en seguridad desde código de plena confianza, el resultado será una demanda correcta.
El término código crítico para la seguridad es lo opuesto al término código transparente en seguridad. El código crítico para la seguridad se ejecuta con plena confianza y puede realizar todas las operaciones para las que tiene privilegios. El código crítico para la seguridad y disponible desde código transparente es código con privilegios que se ha sometido a una exhaustiva auditoría de seguridad a fin de confirmar que no permite a los llamadores de confianza parcial usar los recursos para los que no tienen permiso de acceso.
Es necesario aplicar la transparencia de forma explícita. Normalmente, la mayor parte del código que administra la lógica y la manipulación de datos se puede marcar como transparente en seguridad, mientras que una pequeña parte del código que realiza elevaciones de los privilegios se marca como crítica para la seguridad y disponible desde código transparente.
| Importante |
|---|
La transparencia de nivel 1 se limita al ámbito de los ensamblados; no se aplica entre los ensamblados.Esta transparencia se usaba fundamentalmente en Microsoft para las auditorías de seguridad.A los miembros y tipos críticos para la seguridad de un ensamblado de nivel 1 puede obtener acceso el código transparente en seguridad de otros ensamblados.Es importante que se realicen peticiones de vínculo de plena confianza en todos los tipos y miembros críticos para la seguridad del nivel 1.Los tipos y miembros críticos para la seguridad y disponibles desde código transparente también deben confirmar que los llamadores tienen permisos para los recursos protegidos a los que obtienen acceso. |
A efectos de compatibilidad con versiones anteriores de .NET Framework, se considera que todos los miembros no marcados con atributos de transparencia son críticos para la seguridad y disponibles desde código transparente. Todos los tipos no marcados se consideran transparentes. No existen reglas de análisis estático para validar la transparencia. Por consiguiente, es posible que tenga que depurar los errores de transparencia en tiempo de ejecución.
Atributos de transparencia
La tabla siguiente describe los tres atributos que se utilizan para anotar la transparencia del código.
Atributo |
Descripción |
|---|---|
Sólo se permite en el nivel de ensamblado. Identifica todos los tipos y miembros del ensamblado como transparentes en seguridad. El ensamblado no puede contener ningún código crítico para la seguridad. |
|
Cuando se usa en el nivel de ensamblado sin la propiedad Scope, identifica todo el código del ensamblado como transparente en seguridad de forma predeterminada, pero indica que el ensamblado puede contener código crítico para la seguridad. Cuando se usa en el nivel de clase, identifica la clase o el método como críticos para la seguridad, pero no los miembros de la clase. Para que todos los miembros sean críticos para la seguridad, establezca la propiedad Scope en Everything. Cuando se usa en el nivel de miembro, el atributo se aplica únicamente a ese miembro. La clase o el miembro identificados como críticos para la seguridad puede elevar los privilegios. Importante
En la transparencia de nivel 1, los tipos y miembros críticos para la seguridad se consideran críticos para la seguridad y disponibles desde código transparente cuando se invocan desde fuera del ensamblado.Los tipos y miembros críticos para la seguridad deben protegerse con una petición de vínculo de plena confianza para evitar que los privilegios se eleven de forma no autorizada.
|
|
Identifica el código crítico para la seguridad al que puede tener acceso el código transparente en seguridad del ensamblado. De otro modo, el código transparente en seguridad no puede tener acceso a los miembros críticos para la seguridad privados o internos del mismo ensamblado. Esto influiría en el código crítico para la seguridad y haría posible elevaciones de privilegios imprevistas. El código crítico para la seguridad y disponible desde código transparente debe someterse a una rigurosa auditoría de seguridad. .gif "Nota") Nota
Los tipos y miembros críticos para la seguridad y disponibles desde código transparente deben validar los permisos de los llamadores para determinar si estos están autorizados para obtener acceso a los recursos protegidos.
|
El atributo SecuritySafeCriticalAttribute permite al código transparente en seguridad tener acceso a los miembros críticos para la seguridad del mismo ensamblado. Considere el código transparente en seguridad y crítico para la seguridad de su ensamblado como si estuviera separado en dos ensamblados. El código transparente en seguridad no podría ver los miembros privados o internos del código crítico para la seguridad. Además, el código crítico para la seguridad se audita por lo general en previsión de acceso a la interfaz pública. No es de esperar que un estado privado o interno sea accesible fuera del ensamblado; lo lógico sería mantener el estado aislado. El atributo SecuritySafeCriticalAttribute mantiene el aislamiento del estado entre el código transparente en seguridad y el código crítico para la seguridad y, al mismo tiempo, permite invalidar el aislamiento si es necesario. El código transparente en seguridad no puede obtener acceso al código crítico para la seguridad privado o interno, a menos que los miembros hayan sido marcados con SecuritySafeCriticalAttribute. Antes de aplicar SecuritySafeCriticalAttribute, audite ese miembro como si estuviera expuesto públicamente.
Anotación en el nivel de ensamblado
En la siguiente tabla se describen los efectos de usar los atributos de seguridad en el nivel del ensamblado.
Atributo de ensamblado |
Estado del ensamblado |
|---|---|
Ningún atributo en un ensamblado de confianza parcial |
Todos los tipos y miembros son transparentes. |
Ningún atributo en un ensamblado de plena confianza (de la memoria caché global de ensamblados o identificado como de plena confianza en AppDomain) |
Todos los tipos son transparentes y todos los miembros son críticos para la seguridad y disponibles desde código transparente. |
SecurityTransparent |
Todos los tipos y miembros son transparentes. |
SecurityCritical(SecurityCriticalScope.Everything) |
Todos los tipos y miembros son críticos para la seguridad. |
SecurityCritical |
Todos los valores predeterminados de código son transparentes. No obstante, cada tipo o miembro puede tener otros atributos. |
Ejemplos de transparencia en seguridad
Para utilizar las reglas de transparencia de .NET Framework 2.0 (el nivel 1 de transparencia), utilice el siguiente marcado de ensamblado:
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Si desea que un ensamblado entero sea transparente para indicar que no contiene ningún código crítico y que no eleva los privilegios de ninguna manera, puede agregar explícitamente la transparencia al ensamblado con el atributo siguiente:
[assembly: SecurityTransparent]
Si desea combinar código crítico y código transparente en el mismo ensamblado, comience marcando el ensamblado con el atributo SecurityCriticalAttribute para indicar que puede contener código crítico, de la siguiente manera:
[assembly: SecurityCritical]
Si desea realizar las acciones críticas para la seguridad, debe marcar explícitamente el código que realizará la acción crítica con otro atributo SecurityCriticalAttribute, como se muestra en el ejemplo de código siguiente:
[assembly: SecurityCritical]
Public class A
{
[SecurityCritical]
private void Critical()
{
// critical
}
public int SomeProperty
{
get {/* transparent */ }
set {/* transparent */ }
}
}
public class B
{
internal string SomeOtherProperty
{
get { /* transparent */ }
set { /* transparent */ }
}
}
El código anterior es transparente, salvo para el método Critical, que se marca explícitamente como crítico para la seguridad. La transparencia es la configuración predeterminada, incluso con el atributo SecurityCriticalAttribute en el nivel de ensamblado.