Seguridad de servicios

Artículo
10/07/2008

La seguridad de un servicio Windows Communication Foundation (WCF) se basa en dos requisitos primarios: la seguridad de la transferencia y la autorización. (Un tercer requisito, la auditoría de los eventos de seguridad, se describe en Auditoría de eventos de seguridad.) Resumiendo, la seguridad de la transferencia incluye la autenticación (comprobar la identidad del servicio y del cliente), la confidencialidad (cifrado de mensajes) y la integridad (firma digital para detectar la modificación). La autorización es el control del acceso a los recursos, por ejemplo, permitiendo la lectura de un archivo sólo a usuarios privilegiados. Con las características de WCF, se implementan fácilmente los dos requisitos primarios.

Excepto la clase BasicHttpBinding (o el elemento <basicHttpBinding> en configuración), la seguridad de la transferencia está habilitada de forma predeterminada para todos los enlaces predefinidos. Los temas de esta sección tratan dos escenarios básicos: la implementación de la seguridad de la transferencia y la autorización en un servicio de la intranet que se hospeda en IIS (Internet Information Services), y la implementación de la seguridad de la transferencia y la autorización en un servicio hospedado en IIS.

Nota

Windows XP Home no admite la autenticación de Windows. Por lo tanto, no debería ejecutar un servicio en ese sistema.

Fundamentos de seguridad

La seguridad se basa en las credenciales. Una credencial demuestra que una entidad es quién notifica ser. (Una entidad puede ser una persona, un proceso de software, una compañía, o cualquier cosa que esté autorizada.) Por ejemplo, un cliente de un servicio realiza una notificación de identidad, y la credencial demuestra esa notificación de alguna manera. En un escenario típico, se produce un intercambio de credenciales. Primero, un servicio realiza una notificación de su identidad y lo prueba ante el cliente con una credencial. A la inversa, el cliente realiza una notificación de identidad y presenta una credencial al servicio. Si ambas partes confían en las respectivas credenciales, a continuación, se puede establecer un contexto seguro en el que todos los mensajes se intercambian de manera confidencial, y todos los mensajes están firmados para proteger su integridad. Una vez que el servicio establece la identidad del cliente, puede hacer coincidir las notificaciones de la credencial con una función o la pertenencia de un grupo. En cualquier caso, mediante la función o el grupo al que pertenece el cliente, el servicio autoriza al cliente a realizar un conjunto limitado de operaciones basado en los privilegios de la función o el grupo.

Mecanismos de seguridad de Windows

Si tanto el cliente como el equipo de servicio pertenecen a un dominio de Windows que exige a ambos el inicio de una sesión en la red, la infraestructura de Windows proporcionará las credenciales. En ese caso, las credenciales se establecen cuando un usuario del equipo inicia sesión en la red. Cada usuario y cada equipo de la red deben validarse como pertenecientes al conjunto seguro de usuarios y equipos. En un sistema de Windows, cada uno de estos usuarios y equipos se conoce también como una entidad de seguridad.

En un dominio de Windows respaldado por un controlador de Kerberos, éste utiliza un esquema basado en otorgar los vales a cada entidad de seguridad. Los vales que otorga el controlador son de confianza para otros emisores de vales del sistema. Siempre que una entidad intenta realizar alguna operación o tener acceso a un recurso (como un archivo o directorio en un equipo), se examina la validez del vale y, si se aprueba, se otorga otro vale para la operación a la entidad de seguridad. Este método de otorgar vales es más eficaz que la alternativa de intentar validar la entidad de seguridad en cada operación.

Un mecanismo anterior y menos seguro que se utiliza en dominios de Windows es NT LAN Manager (NTLM). En casos donde no se puede utilizar Kerberos (normalmente fuera de un dominio de Windows, como en un grupo de trabajo), se puede utilizar NTLM como alternativa. NTLM también está disponible como opción de seguridad para IIS.

En un sistema de Windows, la autorización funciona asignando cada equipo y usuario a un conjunto de funciones y grupos. Por ejemplo, cada equipo de Windows debe estar configurado y controlado por una persona (o grupo de personas) con la función de administrador. Otra función es la del usuario, que tiene un conjunto mucho más restringido de permisos. Además de a la función, los usuarios están asignados a grupos. Un grupo permite a varios usuarios actuar en la misma función. Por lo tanto, en la práctica, un equipo de Windows se administra asignando usuarios a los grupos. Por ejemplo, se pueden asignar varios usuarios al grupo de usuarios de un equipo, y asignar un conjunto mucho más restringido de usuarios al grupo de administradores. En un equipo local, un administrador también puede crear grupos nuevos y asignarle otros usuarios (o incluso otros grupos).

En un equipo que ejecuta Windows, puede protegerse cada carpeta de un directorio. Es decir, puede seleccionar una carpeta y controlar quién tiene acceso a los archivos y si pueden o no copiarlos, o (en el caso más privilegiado) cambiar o eliminar un archivo, o agregar archivos a la carpeta. Esto se conoce como control de acceso, y su mecanismo como la lista de control de acceso (ACL). Al crear la ACL, puede asignar los privilegios de acceso a cualquier grupo o grupos, así como los miembros individuales de un dominio.

La infraestructura WCF está diseñada para utilizar estos mecanismos de seguridad de Windows. Por lo tanto, si está creando un servicio que se implementa en una intranet, y sus clientes están restringidos a los miembros del dominio de Windows, la seguridad se implementará fácilmente. Sólo los usuarios válidos pueden iniciar sesión en el dominio. Después de que los usuarios inicien la sesión, el controlador de Kerberos permite a cada uno de ellos establecer contextos seguros con cualquier otro equipo o aplicación. En un equipo local, los grupos pueden crearse fácilmente y al proteger carpetas específicas, pueden utilizarse esos grupos para asignar los privilegios de acceso al equipo.

Implementación de la seguridad de Windows en servicios de la intranet

Para proteger una aplicación que se ejecuta exclusivamente en un dominio de Windows, puede utilizar la configuración de seguridad predeterminada de WSHttpBinding, o el enlace NetTcpBinding. De forma predeterminada, cualquier usuario del mismo dominio de Windows puede tener acceso a los servicios WCF. Dado que esos usuarios han iniciado sesión en la red, son de confianza. Los mensajes entre un servicio y un cliente se cifran por motivos de confidencialidad y se firman por razones de integridad. Para obtener más información acerca de cómo crear un servicio que utiliza la seguridad de Windows, vea Cómo: Proteger un servicio con credenciales de Windows.

Autorización utilizando la clase PrincipalPermissionAttribute

Si necesita restringir el acceso de recursos de un equipo, la manera más sencilla es utilizar la clase PrincipalPermissionAttribute. Este atributo permite restringir la invocación de operaciones del servicio exigiendo que el usuario pertenezca a un grupo o función de Windows específico, o bien ser un usuario concreto. Para obtener más información, consulte Cómo restringir el acceso con la clase PrincipalPermissionAttribute.

Suplantación

La suplantación es otro mecanismo que puede utilizarse para controlar el acceso a los recursos. De forma predeterminada, un servicio hospedado por IIS se ejecutará bajo la identidad de la cuenta ASPNET. La cuenta ASPNET sólo puede tener acceso a los recursos para los que tiene permiso. Sin embargo, es posible establecer la ACL para que una carpeta excluya la cuenta de servicio ASPNET, pero permitir que otras identidades tengan acceso a la carpeta. La cuestión entonces es cómo permitir a esos usuarios tener acceso a la carpeta si la cuenta ASPNET no está autorizada a hacerlo. La respuesta es utilizar la suplantación, con lo que el servicio está autorizado a utilizar las credenciales del cliente para tener acceso a un recurso determinado. Otro ejemplo es el acceso a una base de datos de SQL Server para la que sólo ciertos usuarios tienen permiso. Para obtener más información acerca de cómo usar la suplantación, vea Cómo suplantar a un cliente en un servicio y Delegación y suplantación con WCF.

Seguridad en Internet

La seguridad en Internet se basa en los mismos requisitos que la seguridad en una intranet. Un servicio necesita presentar sus credenciales para demostrar su autenticidad, y los clientes necesitan demostrar su identidad al servicio. Una vez demostrada la identidad de un cliente, el servicio puede controlar qué tipo de acceso a los recursos posee el cliente. No obstante, debido a la naturaleza heterogénea de Internet, las credenciales presentadas difieren de las utilizadas en un dominio de Windows. Si bien un controlador de Kerberos administra la autenticación de usuarios en un dominio mediante vales para las credenciales, en Internet, los servicios y clientes confían en cualquiera de las distintas maneras de presentar credenciales. El objetivo de este tema, sin embargo, es presentar un enfoque común que le permita crear un servicio WCF accesible a través de Internet.

Utilización de IIS y ASP.NET

Los requisitos de seguridad de Internet, así como los mecanismos para resolver esos problemas, no son algo nuevo. IIS es el servidor web de Microsoft para Internet y posee muchas características de seguridad para resolver esos problemas; además, ASP.NET incluye características de seguridad que los servicios WCF pueden utilizar. Para beneficiarse de estas características de seguridad, hospede un servicio WCF en IIS.

Utilización de la pertenencia a ASP.NET y los proveedores de funciones

ASP.NET incluye una pertenencia y un proveedor de funciones. El proveedor es una base de datos de pares de nombre de usuario/contraseña para la autenticación de autores de llamadas, que también permite especificar los privilegios de acceso de cada autor de llamada. Con WCF, puede utilizar fácilmente, a través de la configuración, una pertenencia y un proveedor de funciones existente previamente. Para consultar una aplicación de ejemplo, vea Membership and Role Provider.

Credenciales utilizadas por IIS

A diferencia de un dominio de Windows respaldado por un controlador de Kerberos, Internet es un entorno sin un único controlador que administre los millones de usuarios que inician sesión al mismo tiempo. En vez de eso, las credenciales en Internet se encuentran con mayor frecuencia en forma de certificados X.509 (que también se conocen como certificados de Capa de sockets seguros, o SSL). Normalmente, estos certificados los emite una entidad de certificación, que puede ser una compañía de otro fabricante que responde de la autenticidad del certificado y la persona para la que se emitió. Para exponer su servicio en Internet, también debe proporcionar este tipo de certificado de confianza como autenticación de su servicio.

La pregunta que surge en este punto es ¿cómo obtener este tipo de certificado? Una solución es acudir a una entidad de certificación de otro fabricante, como Authenticode o VeriSign, cuando esté en disposición de implementar el servicio, y adquirir un certificado para el mismo. Sin embargo, si se encuentra en la fase de desarrollo con WCF, y aún no está listo para adquirir un certificado, existen herramientas y técnicas de creación de certificados X.509 que puede utilizar para simular una implementación de la producción. Para obtener más información, consulte Trabajar con certificados.

Modos de seguridad

La programación de la seguridad de WCF conlleva algunas decisiones críticas. Una de las más básica es la elección del modo de seguridad. Los dos modos de seguridad principales son el modo de transporte y el modo de mensaje.

Un tercer modo, que combina la semántica de los dos modos principales, es el modo de transporte con credenciales de mensaje.

El modo de seguridad determina la protección de los mensajes, y cada elección presenta ventajas y desventajas, como se indica a continuación. Para obtener más información acerca de cómo establecer el modo de seguridad, vea Cómo: Establecer el modo de seguridad.

Modo de transporte

Existen varias capas entre la red y la aplicación. Uno de ellas es la capa de transporte,que administra la transferencia de mensajes entre los puntos finales. Para el propósito que nos ocupa, sólo necesita comprender que WCF utiliza varios protocolos de transporte, cada uno de los cuales puede proteger la transferencia de mensajes. (Para obtener más información acerca de transportes, vea Transportes en Windows Communication Foundation.)

Un protocolo utilizado frecuentemente es HTTP; otro es TCP. Cada uno de estos protocolos puede proteger la transferencia del mensaje mediante un mecanismo (o mecanismos) determinado del protocolo. Por ejemplo, el protocolo HTTP se protege utilizando SSL sobre HTTP, normalmente abreviado como "HTTPS". Así, al seleccionar el modo de transporte para la seguridad, está decidiendo utilizar el mecanismo dictado por el protocolo. Por ejemplo, si selecciona la clase WSHttpBinding y establece su modo de seguridad en Transporte, está seleccionando SSL sobre HTTP (HTTPS) como mecanismo de seguridad. La ventaja del modo de transporte es que es más eficaz que el modo de mensaje ya que la seguridad se integra en un nivel comparativamente bajo. Al utilizar el modo de transporte, el mecanismo de seguridad se debe implementar según la especificación para el transporte, de este modo los mensajes pueden fluir de manera segura de un punto a otro del transporte.

Modo de mensaje

Por el contrario, el modo de mensaje proporciona seguridad incluyendo los datos de seguridad en cada mensaje. Utilizando XML y encabezados de seguridad de SOAP, las credenciales y otros datos necesarios para garantizar la integridad y confidencialidad del mensaje se incluyen en cada mensaje. Cada mensaje incluye los datos de seguridad, lo que afecta negativamente al rendimiento debido a que cada mensaje debe procesarse de manera individual. En el modo de transporte, una vez protegida la capa de transporte, todos los mensajes fluyen libremente. Sin embargo, el modo de seguridad tiene una ventaja sobre la seguridad de transporte: es más flexible. Es decir, el transporte no determina los requisitos de seguridad. Puede utilizar cualquier tipo de credencial de cliente para proteger el mensaje. En modo de transporte, el protocolo de transporte determina el tipo de credencial de cliente que puede utilizarse.

Transporte con credenciales de mensaje

El tercer modo combina lo mejor de la seguridad de transporte y de mensaje. En este modo, la seguridad de transporte se utiliza para proteger eficazmente la confidencialidad e integridad de cada mensaje. Al mismo tiempo, cada mensaje incluye sus datos de credencial, lo que permite la autenticación del mensaje. Con la autenticación, también puede implementarse la autorización. Mediante la autenticación de un remitente, el acceso a los recursos puede otorgarse (o denegarse) conforme a la identidad del remitente.

Especificación del tipo de credencial de cliente y del valor de credencial

Después de seleccionar un modo de seguridad, es posible que también desee especificar un tipo de credencial de cliente. El tipo de credencial de cliente especifica qué tipo debe utilizar un cliente para autenticarse al servidor.

No obstante, no todos los escenarios requieren un tipo de credencial de cliente. Utilizando SSL sobre HTTP (HTTPS), un servicio se autentica al cliente. Como parte de esta autenticación, se envía el certificado del servicio al cliente en un proceso denominado negociación. El transporte protegido por SSL garantiza que todos los mensajes son confidenciales.

Si está creando un servicio que requiere la autenticación del cliente, la elección de un tipo de credencial de cliente depende del transporte y el modo seleccionados. Por ejemplo, si utiliza el transporte HTTP y opta por el modo de transporte, podrá elegir entre varias opciones, como Básica, Implícita, y otras. (Para obtener más información acerca de estos tipos de credencial, vea Introducción a la autenticación HTTP.)

Si crea un servicio en un dominio de Windows que sólo estará disponible para otros usuarios de la red, el más fácil de utilizar es el tipo de credencial de cliente de Windows. Sin embargo, también puede que tenga que proporcionar un certificado al servicio. Este caso se muestra en Cómo: Especificar los valores de credenciales de cliente.

Valores de credencial

Un valor de credencial es la credencial real utilizada por el servicio. Cuando se especifica un tipo de credencial, también puede ser necesario configurar el servicio con las credenciales reales. Si se selecciona Windows (y el servicio se ejecutará en un dominio de Windows), no será necesario especificar un valor de credencial real.

Identidad

En WCF, el término identidad tiene significados diferentes para el servidor y para el cliente. Resumiendo, al ejecutar un servicio, se asigna una identidad al contexto de seguridad después de la autenticación. Para ver la identidad real, compruebe las propiedades WindowsIdentity y PrimaryIdentity de la clase ServiceSecurityContext. Para obtener más información, consulte Cómo: Examinar el contexto de seguridad.

Por el contrario, en el cliente, la identidad se utiliza para validar el servicio. Durante el diseño, un programador del cliente puede establecer el elemento <identity> en un valor obtenido del servicio. Durante la ejecución, el cliente contrasta el valor del elemento con la identidad real del servicio. Si se produce un error en la comprobación, el cliente finaliza la comunicación. El valor puede ser un nombre principal del usuario (UPN), si el servicio se ejecuta bajo la identidad de un usuario determinado, o un nombre principal de servicio (SPN) si el servicio se ejecuta bajo una cuenta de equipo. Para obtener más información, consulte Identidad del servicio y autenticación. La credencial también puede ser un certificado, o un campo de un certificado que identifica a éste último.

Niveles de protección

La propiedad ProtectionLevel se encuentra en varias clases de atributo (como las clases ServiceContractAttribute y OperationContractAttribute ). El nivel de protección es un valor que especifica si los mensajes (o partes del mensaje) compatibles con un servicio se firman, se firman y cifran, o bien se envían sin firmas ni cifrado. Para obtener más información acerca de la propiedad, vea Descripción de los niveles de protección, y para ejemplos de programación, vea Cómo: Establecer la propiedad ProtectionLevel. Para obtener más información acerca de cómo diseñar un contrato de servicio con el ProtectionLevel en contexto, vea Diseño de contratos de servicios.

Consulte también

Compartir a través de