Seguridad de los servicios

  • Artículo

La seguridad de un servicio de Windows Communication Foundation (WCF) se basa en dos requisitos principales: la seguridad de la transferencia y la autorización. (Hay un tercer requisito, la auditoría de los eventos de seguridad, que se describe en Auditorías.) 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 alteraciones). La autorización es el control del acceso a los recursos, por ejemplo, permitiendo la lectura de un archivo solo a usuarios privilegiados. Con las características de WCF se implementan fácilmente los dos requisitos principales.

Con la excepción de la clase BasicHttpBinding (o del elemento <basicHttpBinding> en la configuración), la seguridad de la transferencia está habilitada de manera 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.

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 empresa o cualquier cosa que pueda autorizarse). Por ejemplo, un cliente de un servicio realiza una notificación de identidad y la credencial demuestra la veracidad de 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 un rol o con la pertenencia de un grupo. En cualquier caso, mediante el rol o el grupo al que pertenece el cliente, el servicio autoriza al cliente a realizar un conjunto limitado de operaciones basado en los privilegios del rol o del 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 roles y grupos. Por ejemplo, cada equipo de Windows debe estar configurado y controlado por una persona (o grupo de personas) con el rol de administrador. Otro rol es el del usuario, que tiene un conjunto mucho más restringido de permisos. Además del rol, los usuarios están asignados a grupos. Un grupo permite a varios usuarios actuar en la misma rol. 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 de 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. Solo 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 manera 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 para la confidencialidad y se firman para integridad. Para más información sobre cómo crear un servicio que use la seguridad de Windows, consulte Cómo garantizar la seguridad de 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 rol de Windows específico, o bien ser un usuario concreto. Para 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 solo 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 solo ciertos usuarios tienen permiso. Para más información sobre el uso de la suplantación, consulte Cómo suplantar a un cliente en un servicio y Delegación y suplantación.

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 de 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 tiene 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 sacar provecho de estas características de seguridad, hospede un servicio WCF en IIS.

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

ASP.NET incluye una pertenencia y un proveedor de roles. 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 roles que ya existan previamente. Para obtener una aplicación de ejemplo que muestre esto, consulte la muestra que hay en Pertenencia y proveedor de roles.

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 confirmar la adquisición de un certificado, hay herramientas y técnicas de creación de certificados X.509 que puede utilizar para simular una implementación de producción. Para 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ásicas 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 más información sobre cómo establecer el modo de seguridad, consulte Cómo establecer el modo de seguridad.

modo de transporte

Existen varias capas entre la red y la aplicación. Una de ellas es la capa de transporte, que administra la transferencia de mensajes entre los puntos de conexión. Para el propósito que nos ocupa, solo necesita comprender que WCF utiliza varios protocolos de transporte y que cada uno de ellos puede proteger la transferencia de mensajes. (Para más información acerca de los transportes, consulte Transportes.)

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 mediante SSL a través de HTTP, normalmente abreviado como "HTTPS". Por lo tanto, al seleccionar el modo de transporte para la seguridad, se elige usar el mecanismo según lo dicta 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, la seguridad de los mensajes tiene una ventaja sobre la seguridad del 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 más información sobre estos tipos de credenciales, consulte Descripción de la autenticación HTTP).

Si crea un servicio en un dominio de Windows que solo 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. Esto se muestra en How to: Specify Client Credential Values.

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 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 tiempo de diseño, un desarrollador del cliente puede establecer el elemento <identidad> 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 de entidad de seguridad de servicio (SPN) si el servicio se ejecuta bajo una cuenta de equipo. Para más información, consulte Identidad y autenticación de servicio. 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 atributos (como las clases ServiceContractAttribute y OperationContractAttribute ). El nivel de protección es un valor que especifica si los mensajes (o partes del mensaje) que soportan un servicio están firmados, firmados y cifrados, o si se envían sin firmar o cifrar. Para más información sobre la propiedad, consulte Descripción del nivel de protección, y para obtener ejemplos de programación, consulte Cómo establecer la propiedad ProtectionLevel. Para más información sobre el diseño de contratos de servicio con la propiedad ProtectionLevel en contexto, consulte Diseño de contratos de servicio.

Consulte también