Seguridad en un sistema de interacción remota
En general, las cuestiones relacionadas con la seguridad de las aplicaciones que utilizan .NET Framework Remoting son más complejas que las de las aplicaciones locales.
La protección de las aplicaciones distribuidas plantea un problema difícil de resolver sin recurrir a medidas que disminuyen el rendimiento. Si un extremo de la comunicación está a la escucha de una invocación, cualquier cliente no autorizado que conozca el extremo de escucha puede intentar pasar información serializada, para se deserialice e invoque en el otro extremo. La autenticación mutua y el posterior cifrado del contenido es la única forma que permite estar razonablemente seguro de que la comunicación se produce entre componentes de confianza. Como consecuencia, se debe evaluar en primer lugar los requisitos de seguridad de la aplicación de interacción remota y después los requisitos de rendimiento. Debe exponer los datos y extremos sin autenticación y cifrado en la medida en que requiera integridad de los datos para la aplicación.
Los delegados de interacción remota ilustran el problema. Dado que los delegados pueden contener la información de tipos de los métodos estáticos, que jamás se ejecutan de manera remota, las aplicaciones del servidor deben declarar siempre un tipo de delegado personalizado que adopte parámetros personalizados que, conjuntamente, jamás coincidan con un método estático al que se puede llamar desde el equipo del servidor. No permita nunca que un cliente defina y pase a su aplicación ningún tipo que su servidor pueda deserializar.
Una parte muy importante del diseño de aplicaciones distribuidas que utilicen la infraestructura de .NET Framework Remoting es estar seguro del nivel de seguridad que desea tener y en dónde. En esta sección se describen varios enfoques de seguridad basados en ciertas decisiones de diseño. No se abordan todos los escenarios, pero estos temas constituyen un buen punto de partida a la hora de tomar decisiones.
Seguridad de acceso a código
La seguridad de acceso a código controla el acceso que tiene el código ejecutable a los recursos y operaciones, en función de la directiva de seguridad establecida por el administrador del equipo. Sin embargo, como la seguridad de acceso a código no recorre la pila en una conexión remota, los programadores de aplicaciones de interacción remota deben comprender que la infraestructura de interacción remota requiere total confianza para ejecutarse en el cliente o el servidor. Cualquier uso no autorizado de una aplicación remota proporciona acceso no autorizado a permisos FullTrust.
 Precaución |
|---|
| No intente nunca crear un contenedor utilizable de forma remota para un objeto AppDomain. En caso contrario, es posible que publique de manera remota una referencia a dicho objeto AppDomain, lo que expone el método AppDomain.CreateInstance (u otros métodos) de manera remota y destruye cualquier seguridad de acceso a código para ese objeto AppDomain. Los clientes no autorizados que se conecten al objeto AppDomain que se utiliza de forma remota podrán obtener acceso a todos los recursos a los que puede obtener acceso el objeto AppDomain. De hecho, no debe crear un contenedor utilizable de forma remota para ningún tipo que extienda MarshalByRefObject e implemente métodos que podrían usar clientes no autorizados para evitar el sistema de seguridad. |
 Nota |
|---|
| En términos más generales, varios tipos de sistema extienden MarshalByRefObject pero también realizan comprobaciones de seguridad en tiempo de ejecución para evitar que nada fuera del dominio de aplicación pueda realmente invocar de manera remota un objeto de dicho tipo MarshalByRefObject. AppDomain y System.Windows.Forms.Form son dos ejemplos de dichos tipos de sistema. Sería fácil pensar que se puede extender MarshalByRefObject y obtener una referencia de manera remota, pero éste no es el caso con estos tipos especiales. Puede que desee envolver la referencia en proceso con otro tipo utilizable de forma remota, pero con ello se burla de manera no intencionada el sistema de seguridad de acceso a código, lo que no debe hacerse jamás. |
Consideraciones de seguridad referentes a las aplicaciones remotas
Normalmente hay dos áreas de seguridad que puede ser necesario resolver en una aplicación distribuida, que dependen de su escenario particular. Puede que desee proteger el canal de comunicación y el mensaje propiamente dicho, o bien proteger la aplicación frente a un uso incorrecto. También es posible que desee resolver ambos en cierta medida.
Para proteger el canal de comunicación suele ser necesario cifrar el canal propiamente dicho, cifrar el contenido del mensaje en un extremo de la secuencia y descifrarlo en el otro, o ambas cosas. Puede que el contenido del mensaje requiera una comprobación de integridad para determinar si alguien lo ha manipulado. Asimismo, puede ser necesario confirmar la identidad del cliente o del servidor (o de ambos).
En primer lugar, siempre debe autenticar los clientes para confirmar que disponen de permisos para utilizar el recurso. En segundo lugar, debe cifrar todas las conversaciones para proteger los datos durante la transmisión. Estos dos pasos son totalmente compatibles con HttpChannel y TcpChannel. (Como el canal IPC sólo funciona en un mismo equipo, no admite cifrado, pero sí autenticación de Windows.)
Algunos escenarios son excepciones a las dos reglas anteriores. Podría eliminarse el cifrado si los requisitos de rendimiento son los suficientemente altos y el valor de los datos lo suficientemente bajo como para que la observación o manipulación de los datos tenga relativamente poca importancia. También puede deshabilitarse el cifrado cuando la comunicación se produce en una red cifrada, como una red protegida mediante IPsec.
Para contribuir a proteger la aplicación contra el uso no autorizado, puede registrar el comportamiento del usuario para posteriormente reconstruir los patrones de uso.
| Precaución |
|---|
| .NET Framework Remoting no realiza autenticación ni cifrado de manera predeterminada. Por lo tanto, se recomienda que siga todos los procedimientos necesarios para asegurarse de la identidad de los clientes o servidores antes de interactuar con ellos de manera remota. Como las aplicaciones de .NET Framework Remoting requieren permisos FullTrust para ejecutarse, si se ha concedido acceso al servidor a un cliente no autorizado, éste podrá ejecutar código como si fuera de total confianza. Autentique siempre los extremos y cifre las secuencias de comunicación. Para ello, puede alojar los tipos utilizados de forma remota en Servicios de Internet Information Server (IIS) o generar un par de receptores de canales personalizados para que se hagan cargo de este trabajo. En la versión 2.0 de .NET Framework no es necesario generar un receptor personalizado para proteger la comunicación. Las características Autenticación y Cifrado (que se habilitan al establecer secure = true para el canal TCP) habilitan la comunicación segura. Ahora el canal TCP permite autenticar al usuario que se conecta, cifrar los datos en la conexión y determinar la identidad y la dirección IP del cliente que se conecta. |
