Información
El tema que ha solicitado se muestra abajo. Sin embargo, este tema no se encuentra en la biblioteca.

Security-Transparent Code, Level 1

 

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 .NET Framework versión 2.0 y se usó principalmente solo dentro de Microsoft. A partir de .NET Framework 4, puede usar la transparencia de nivel 2. Sin embargo, se ha conservado la transparencia de nivel 1 para que pueda identificar código heredado que se debe ejecutar con las reglas de seguridad anteriores.

System_CAPS_ICON_important.jpg Importante

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 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). En el caso del código que se desarrolló para .NET Framework 4, use siempre la transparencia de nivel 2.

System_CAPS_ICON_caution.jpg Precaució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 del código en .NET Framework no debe usarse como límite de seguridad para código de confianza parcial, especialmente si se trata de código de origen desconocido. 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.

Este tema contiene las siguientes secciones:

Cuando usa la transparencia de nivel 1, está empleando un modelo de seguridad que separa el código en métodos transparentes en seguridad, críticos para la seguridad y disponibles desde código transparente, y críticos para la seguridad.

Puede marcar un ensamblado entero, algunas clases de un ensamblado o algunos métodos de una clase como transparentes en seguridad. El código transparente en seguridad no puede elevar privilegios. Esta restricción tiene tres consecuencias:

  • El código transparente en seguridad no puede realizar acciones Assert.

  • Cualquier petición de vínculo que se vea satisfecha por 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 hace una demanda completa para el permiso de seguridad UnmanagedCode.

Estas reglas se aplican durante la ejecución mediante Common Language Runtime (CLR). El código transparente en seguridad pasa todos los requisitos de seguridad del código al que llama de vuelta a sus llamadores. Las demandas que fluyen a través del código transparente en seguridad no pueden elevar privilegios. Si una aplicación de nivel de confianza bajo llama a código transparente en seguridad y crea una demanda de privilegios altos, la demanda fluirá de vuelta al código de nivel de confianza bajo y producirá un error. El código transparente en seguridad no puede detener la demanda porque no puede realizar acciones Assert. El mismo código transparente en seguridad llamado desde código de plena confianza produce una demanda correcta.

Crítico para la seguridad es lo contrario de transparente en seguridad. El código crítico para la seguridad se ejecuta con plena confianza y puede realizar todas las operaciones con privilegios. El código crítico para la seguridad y disponible desde código transparente es código con privilegios que se sometió a una auditoría de seguridad exhaustiva para confirmar que no permite que llamadores de confianza parcial usen los recursos para los que no tienen permiso de acceso.

Debe aplicar la transparencia de forma explícita. La mayoría del código que administra la lógica y la manipulación de datos normalmente se puede marcar como transparente en seguridad, mientras que el menor porcentaje de código que realiza elevaciones de privilegios está marcado como crítico para la seguridad o bien crítico para la seguridad y disponible desde código transparente.

System_CAPS_ICON_important.jpg Importante

La transparencia de nivel 1 se limita al ámbito de ensamblado; no se aplica entre ensamblados. La transparencia de nivel 1 se usaba principalmente en Microsoft para realizar auditorías de seguridad. El código transparente en seguridad de otros ensamblados puede acceder a los tipos y miembros críticos para la seguridad dentro de un ensamblado de nivel 1. Es importante que se realicen peticiones de vínculo de plena confianza en todos los tipos y miembros críticos para la seguridad de nivel 1. Los tipos y miembros críticos para la seguridad y disponibles desde código transparente también deben confirmar que los llamadores tengan permisos para los recursos protegidos a los que accede el tipo o miembro.

Para mantener la compatibilidad con versiones anteriores de .NET Framework, todos los miembros no anotados con atributos de transparencia se consideran críticos para la seguridad y disponibles desde código transparente. Todos los tipos que no están anotados se consideran transparentes. No existen reglas de análisis estático para validar la transparencia. Por lo tanto, puede que necesite depurar errores de transparencia en tiempo de ejecución.

En la tabla siguiente se describen los tres atributos que se usan para anotar el código para la transparencia.

AtributoDescripción
SecurityTransparentAttributeSolo 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.
SecurityCriticalAttributeCuando 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 método como crítico 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 solo a ese miembro.

La clase o miembro identificado como crítico para la seguridad puede realizar elevaciones de privilegios. Important: En la transparencia de nivel 1, los tipos y miembros críticos para la seguridad se tratan como críticos para la seguridad y disponibles desde código transparente cuando se les llama desde fuera del ensamblado. Debe proteger los tipos y miembros críticos para la seguridad con una petición de vínculo de plena confianza para evitar la elevación de privilegios no autorizada.
SecuritySafeCriticalAttributeIdentifica el código crítico para la seguridad al que puede tener acceso el código transparente en seguridad del ensamblado. De lo contrario, el código transparente en seguridad no puede acceder a los miembros críticos para la seguridad privados o internos del mismo ensamblado. Si lo hiciera, podría influir en el código crítico para la seguridad y hacer posibles las elevaciones de privilegios imprevistas. El código crítico para la seguridad y disponible desde código transparente debe someterse a una auditoría de seguridad rigurosa. Note: 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 el llamador tiene autoridad para acceder a recursos protegidos.

El atributo SecuritySafeCriticalAttribute permite que el código transparente en seguridad acceda 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 sería capaz de ver los miembros privados o internos del código crítico para la seguridad. Además, el código crítico para la seguridad suele auditarse para tener acceso a su interfaz pública. No se espera que un estado privado o interno sea accesible fuera del ensamblado; lo mejor es mantener aislado el estado. El atributo SecuritySafeCriticalAttribute mantiene el aislamiento del estado entre el código transparente en seguridad y el código crítico para la seguridad, al mismo tiempo que ofrece la capacidad de invalidar el aislamiento si es necesario. El código transparente en seguridad no puede acceder al código crítico para la seguridad privado o interno, a menos que esos miembros se hayan marcado con SecuritySafeCriticalAttribute. Antes de aplicar SecuritySafeCriticalAttribute, audite ese miembro como si estuviera expuesto públicamente.

Anotación de todo el ensamblado

En la siguiente tabla se describen los efectos del uso de atributos de seguridad en el nivel de ensamblado.

Assembly (atributo)Estado del ensamblado
Ningún atributo en un ensamblado de confianza parcialTodos los tipos y los miembros son transparentes.
Ningún atributo en un ensamblado de plena confianza (en la 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.
SecurityTransparentTodos los tipos y los miembros son transparentes.
SecurityCritical(SecurityCriticalScope.Everything)Todos los tipos y los miembros son críticos para la seguridad.
SecurityCriticalEl valor predeterminado de todo el código es transparente. Sin embargo, los miembros y tipos individuales pueden tener otros atributos.

Para usar las reglas de transparencia de .NET Framework 2.0 (transparencia de nivel 1), use la siguiente anotación de ensamblado:

[assembly: SecurityRules(SecurityRuleSet.Level1)]  

Si desea que un ensamblado entero sea transparente para indicar que no contiene código crítico y que no eleva los privilegios de ninguna manera, puede agregar transparencia explícitamente al ensamblado con el atributo siguiente:

[assembly: SecurityTransparent]  

Si desea mezclar código transparente y crítico en el mismo ensamblado, empiece marcando el ensamblado con el atributo SecurityCriticalAttribute para indicar que el ensamblado puede contener código crítico, como se indica a continuación:

[assembly: SecurityCritical]  

Si desea realizar 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, excepto 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 de nivel de ensamblado.

Security-Transparent Code, Level 2
Cambios de seguridad

Mostrar: