¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Exportar (0) Imprimir
Expandir todo
Este artículo proviene de un motor de traducción automática. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original

Conceptos básicos sobre la seguridad de acceso del código

Todas las aplicaciones que tengan como destino Common Language Runtime (es decir, todas las aplicaciones administradas) deben interactuar con el sistema de seguridad de Common Language Runtime. Cuando se carga una aplicación administrada, su host le concede automáticamente un conjunto de permisos. Estos permisos los determina la configuración de seguridad local del host o el espacio aislado en que está la aplicación. En función de estos permisos, la aplicación se ejecuta correctamente o genera una excepción de seguridad.

El host predeterminado para las aplicaciones de escritorio permite la ejecución del código en plena confianza. Por consiguiente, si una aplicación tiene como destino el escritorio, dispone de un conjunto de permisos no restringidos. Otros hosts o espacios aislados proporcionan un conjunto de permisos limitados para las aplicaciones. Dado que el conjunto de permisos puede cambiar de un host a otro, una aplicación se debe diseñar para que se usen solamente los permisos que el host de destino permite.

Se debe estar familiarizado con los siguientes conceptos de seguridad de acceso del código para escribir aplicaciones eficaces que tengan como destino Common Language Runtime:

  • Código seguro de tipos: el código seguro de tipos es código que sólo obtiene acceso a tipos siguiendo métodos permitidos y perfectamente definidos. Por ejemplo, dada una referencia a objeto válida, el código seguro de tipos puede obtener acceso a la memoria en desplazamientos fijos que se correspondan con miembros de campo reales. Si el código obtiene acceso a la memoria en desplazamientos arbitrarios que se encuentran fuera del intervalo de memoria que pertenece a los campos públicamente expuestos de ese objeto, no tiene seguridad de tipos. Para que el código pueda beneficiarse de la seguridad de acceso del código, es preciso usar un compilador que genere código con seguridad de tipos comprobable. Para obtener más información, vea la sección Escribir código seguro de tipos comprobable más adelante en este tema.

  • Sintaxis imperativa y declarativa: el código que tiene como destino Common Language Runtime puede interactuar con el sistema de seguridad al solicitar permisos, exigir que los llamadores tengan los permisos especificados y reemplazar determinados valores de seguridad (si dispone de privilegios suficientes). Para interactuar mediante programación con el sistema de seguridad de .NET Framework, se usan dos formas de sintaxis: la sintaxis declarativa y la sintaxis imperativa. Las llamadas declarativas se realizan mediante atributos, mientras que las llamadas imperativas se realizan con nuevas instancias de clases del código. Unas llamadas pueden realizarse solamente de forma imperativa, mientras que otras pueden realizarse solamente de forma declarativa, y algunas pueden realizarse de ambas maneras. Para obtener más información, vea Seguridad declarativa y Seguridad imperativa.

  • Biblioteca de clases segura: una biblioteca de clases segura es una biblioteca que usa peticiones de seguridad para garantizar que los llamadores de la biblioteca tienen permiso para obtener acceso a los recursos que ésta expone. Por ejemplo, una biblioteca de clases segura podría tener un método para crear archivos que requiera que los llamadores tengan permisos para crear archivos. .NET Framework incorpora bibliotecas de clases seguras. Debe conocer los permisos necesarios para obtener acceso a cualquier biblioteca que el código utilice. Para obtener más información, vea la sección Usar bibliotecas de clases seguras más adelante en este tema.

  • Código transparente: a partir de .NET Framework 4, además de identificar los permisos específicos, también debe determinar si el código se debe ejecutar como transparente en seguridad. El código transparente en seguridad no puede llamar a tipos o miembros identificados como críticos para la seguridad. Esta regla se aplica a las aplicaciones de plena confianza así como a las aplicaciones de confianza parcial. Para obtener más información, vea Código transparente en seguridad.

La compilación Just-In-Time (JIT) ejecuta un proceso de comprobación que examina el código e intenta determinar si tiene seguridad de tipos. Si se demuestra durante la comprobación que el código tiene seguridad de tipos, se denominará código seguro de tipos comprobable. El código puede tener seguridad de tipos pero, aún así, no ser comprobable debido a las limitaciones del proceso de comprobación o del compilador. No todos los lenguajes tienen seguridad de tipos y algunos compiladores de lenguaje, como Microsoft Visual C++, no pueden generar código administrado seguro de tipos comprobable. Para determinar si el compilador de lenguaje que utiliza genera código seguro de tipos comprobable, consulte la documentación del compilador. Si usa un compilador de lenguaje que genera código con seguridad de tipos comprobable solo cuando se evitan determinadas construcciones del lenguaje, podrá usar la herramienta PEVerify para determinar si el código tiene seguridad de tipos comprobable.

El código que no tiene seguridad de tipos comprobable puede intentar ejecutarse si la directiva de seguridad permite que el código evite la comprobación. Sin embargo, dado que la seguridad de tipos es una parte esencial del mecanismo del motor en tiempo de ejecución para aislar los ensamblados, la seguridad no se puede imponer de manera confiable si el código infringe las reglas de la seguridad de tipos. De manera predeterminada, el código que no tiene seguridad de tipos se puede ejecutar únicamente si procede del equipo local. Por tanto, el código móvil debe tener seguridad de tipos.

Si su código solicita los permisos requeridos por la biblioteca de clases y se conceden, podrá obtener acceso a la biblioteca y los recursos que expone la biblioteca estarán protegidas de acceso no autorizado. Si el código no tiene los permisos necesarios, no podrá tener acceso a la biblioteca de clases, y el código malintencionado no podrá usar el código para obtener acceso indirectamente a los recursos protegidos. Otro código que llama a su código debe tener permiso para obtener acceso a la biblioteca. De no ser así, el código se limitará también en su ejecución.

La seguridad de acceso del código no elimina la posibilidad de errores humanos al escribir código. Sin embargo, si la aplicación usa las bibliotecas de clases seguras para obtener acceso a recursos protegidos, el riesgo para la seguridad del código de la aplicación se reduce, porque las bibliotecas de clases se revisan meticulosamente en busca de posibles problemas de seguridad.

Adiciones de comunidad

AGREGAR
Mostrar:
© 2015 Microsoft