Resumen de los cambios en la seguridad de acceso del código
En .NET Framework versión 4, la seguridad de acceso del código (CAS) ha experimentado cambios importantes con el fin de simplificar el sistema de seguridad. En versiones anteriores de .NET Framework, los derechos de una aplicación administrada se determinaban mediante reglas de directiva de seguridad, que eran válidas para todo el equipo para establecer la configuración en tiempo de ejecución. A partir de .NET Framework 4:
La directiva de seguridad ya no está en vigor. Los permisos se siguen usando; solo se ha eliminado el sistema de directivas.
Los derechos de acceso para las aplicaciones están determinados por dos factores: sus permisos (el conjunto de permisos concedidos establecido por el dominio de aplicación) y la transparencia. Todas las aplicaciones de confianza parcial están clasificadas como transparentes. Las aplicaciones transparentes no tienen por qué preocuparse de la seguridad. La transparencia se usó por primera vez en Microsoft Silverlight y ahora se ha extendido en todos los entornos hospedados.
A las aplicaciones de escritorio y de intranet local se les concede plena confianza.
.gif "Nota importante") Importante |
|---|
El cambio principal en CAS es la eliminación de la directiva de seguridad.CAS no se ha eliminado; solo se ha quitado el uso de la directiva (y algunas solicitudes de permisos). |
En este tema se proporciona información general breve sobre los cambios de CAS en .NET Framework 4. Para obtener más información, vea Cambios de seguridad en .NET Framework 4.
Espacio aislado y el modelo de permisos
En la lista siguiente se describe el modelo de confianza para las aplicaciones de escritorio y hospedadas en .NET Framework 4. Para obtener más información, vea Cambios de seguridad en .NET Framework 4.
Aplicaciones de escritorio. Como en versiones anteriores de .NET Framework, a las aplicaciones administradas que residen en el escritorio (a menos que se hayan descargado del web) se les concede plena confianza. A las aplicaciones que residen en recursos compartidos de la intranet local también se les concede plena confianza. Ya no puede usar la directiva para restringir los permisos para una aplicación basándose en su carpeta del disco duro local.
Aplicaciones hospedadas. A las aplicaciones que se ejecutan en un espacio aislado (por ejemplo, las aplicaciones basadas en Silverlight) se les concede un conjunto limitado de permisos que determinan a qué recursos del equipo pueden tener acceso (por ejemplo, qué archivos pueden usar). Las espacios aislados ofrecen la posibilidad de identificar algunos ensamblados dentro del espacio aislado como de confianza parcial y otros como de plena confianza. A los ensamblados de confianza parcial se es concede un conjunto específico de permisos, según determine el dominio de aplicación (System.AppDomain) que creó el espacio aislado. El código de confianza parcial puede llamar a parte del código de plena confianza de las bibliotecas de plena confianza. Ese código de confianza puede realizar llamadas a recursos protegidos del equipo. Sin embargo, los tipos de plena confianza públicamente accesibles y los miembros que pueden llamar a recursos protegidos deben haber superado una auditoría de seguridad. Esos miembros se clasifican como críticos para la seguridad, como se describe en la próxima sección. Pueden ser llamados por código de confianza parcial (transparente) y, a su vez, pueden llamar a código crítico.
Transparencia en seguridad
La transparencia en seguridad separa el código que afecta a la seguridad del código que no afecta a la seguridad. Se introdujo en .NET Framework versión 2.0 para simplificar las auditorías de seguridad anotando como crítico para la seguridad el código que tenía que realizar acciones que afectaban a la seguridad. Esto significaba que el código que no era crítico para la seguridad (es decir, código transparente) no necesitaba una revisión exhaustiva. Sin embargo, en estas versiones anteriores de .NET Framework, la transparencia solo se usó en código de Microsoft.
En .NET Framework 4, este modelo se ha ampliado y las reglas se han hecho más estrictas para activar la transparencia en seguridad en un modelo de cumplimiento. En este modelo mejorado, el código que afecta a la seguridad e invocable por parte de aplicaciones de confianza parcial se puede identificar más fácilmente. Esto reduce aún más la superficie expuesta que hay que auditar.
En la tabla siguiente se muestran las categorías de transparencia y los atributos asociados para anotar código.
Categoría de seguridad |
Atributo |
Descripción |
|---|---|---|
Transparente |
Código que no hace nada que afecte a la seguridad inherentemente. |
|
Crítica |
Código puede no hacer nada, pero al que no pueden llamar las aplicaciones de confianza parcial. |
|
Crítico para la seguridad |
Código que puede no hacer nada, pero al que pueden llamar las aplicaciones de confianza parcial. Este es el nivel de negociación seguro; su finalidad es realizar comprobaciones y validaciones de seguridad adecuadas antes de llamar a código crítico. |
El código transparente no puede hacer lo siguiente, independientemente de los permisos que tenga concedidos:
Contener código que no se pueda comprobar.
Usar invocación de plataforma.
Realizar operaciones de Assert.
Llamar a código crítico.
Derive de código crítico.
Llamar a código protegido mediante LinkDemand (es decir, código que se considera crítico).
Si el código intenta infringir estas reglas, se producen excepciones (incluso si el código tiene plena confianza). Para obtener más información, vea Cambios de seguridad en .NET Framework 4.
Observe que el carácter de seguridad se define en Common Language Runtime (CLR) como acciones prohibidas para código transparente. El modelo de transparencia no protege contra las infracciones de seguridad específicas del escenario, como almacenar contraseñas en campos.
Cómo funciona el modelo de seguridad
Cada AppDomain tiene asociado un conjunto de permisos, definido por el host en un escenario hospedado. (El conjunto de permisos es de plena confianza para el código que no está hospedado.)
El código de confianza parcial siempre es transparente; por tanto, no puede realizar acciones prohibidas para el código transparente (vea transparencia).
De forma predeterminada, el código de plena confianza es crítico a menos que se haya marcado como transparente. Si una aplicación de escritorio se marca como transparente, no puede llamar a código crítico aunque tenga plena confianza.
Tanto el host como .NET Framework pueden exponer bibliotecas a código de confianza parcial. Estas bibliotecas contienen una mezcla de código transparente, crítico y crítico para la seguridad.
El código crítico para la seguridad debe exigir los permisos adecuados antes de usar funcionalidad crítica. Por ejemplo, el método File.Open exige FileIOPermission antes de abrir un archivo.
El código crítico para la seguridad también debe realizar cualquier otra comprobación y validación antes y después de las llamadas a funcionalidad crítica. Por ejemplo, puede que haya que filtrar las excepciones y los mensajes antes de pasarlos a código de confianza parcial.
El código crítico tiene que validar los permisos que necesita cuando es invocado por código de confianza parcial, ya que el código crítico podría hacer algo que el código de confianza parcial no le permite.