Compartir por

Seguridad de servicios

La seguridad de un servicio de Windows Communication Foundation (WCF) consta de dos requisitos principales: seguridad y autorización de transferencia. (Un tercer requisito, la auditoría de eventos de seguridad, se describe en Auditoría). En resumen, la seguridad de transferencia incluye autenticación (comprobando la identidad del servicio y el cliente), confidencialidad (cifrado de mensajes) e integridad (firma digital para detectar alteraciones). La autorización es el control del acceso a los recursos, por ejemplo, lo que permite que solo los usuarios con privilegios lean un archivo. Con las características de WCF, los dos requisitos principales se implementan fácilmente.

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

Conceptos básicos de seguridad

La seguridad se basa en las credenciales. Una credencial demuestra que una entidad es quién dice ser. (Una entidad puede ser una persona, un proceso de software, una empresa o cualquier cosa que se pueda autorizar). 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. En primer lugar, un servicio realiza una notificación de su identidad y lo demuestra al cliente con una credencial. Por el contrario, el cliente realiza una notificación de identidad y presenta una credencial al servicio. Si ambas partes confían en las credenciales del otro, se puede establecer un contexto seguro en el que se intercambian todos los mensajes de confidencialidad y se firman todos los mensajes para proteger su integridad. Una vez que el servicio establece la identidad del cliente, puede hacer coincidir las afirmaciones de la credencial con un rol o pertenencia a 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 en función del rol o los privilegios de grupo.

Mecanismos de seguridad de Windows

Si el cliente y el equipo de servicio están en un dominio de Windows que requiere que ambos inicien sesión en la red, la infraestructura de Windows proporciona las credenciales. En ese caso, las credenciales se establecen cuando un usuario del equipo inicia sesión en la red. Todos los usuarios y todos los equipos de la red deben validarse como pertenecientes al conjunto de usuarios y equipos de confianza. 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 Kerberos, el controlador Kerberos utiliza un esquema basado en la concesión de tickets a cada entidad de seguridad. Los vales que concede el controlador son de confianza para otros receptores de vales en el sistema. Cada vez que una entidad intenta realizar alguna operación o acceder a un recurso (por ejemplo, un archivo o directorio en un equipo), se examina el ticket para verificar su validez y, si pasa, se le concede al principal otro ticket para la operación. 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 más antiguo y menos seguro que se usa en dominios de Windows es NT LAN Manager (NTLM). En los casos en los que No se puede usar Kerberos (normalmente fuera de un dominio de Windows, como en un grupo de trabajo), NTLM se puede usar como alternativa. NTLM también está disponible como opción de seguridad para IIS.

En un sistema Windows, la autorización funciona asignando cada equipo y usuario a un conjunto de roles y grupos. Por ejemplo, todos los equipos Windows deben configurarse y controlarse mediante una persona (o grupo de personas) en el rol del administrador. Otro rol es el del usuario, que tiene un conjunto de permisos mucho más restringido. Además del rol, los usuarios se asignan a grupos. Un grupo permite que varios usuarios realicen el mismo rol. En la práctica, por lo tanto, se administra una máquina Windows mediante la asignación de usuarios a grupos. Por ejemplo, se pueden asignar varios usuarios al grupo de usuarios de un equipo y se puede asignar un conjunto de usuarios mucho más restringido al grupo de administradores. En un equipo local, un administrador también puede crear nuevos grupos y asignar otros usuarios (o incluso otros grupos) al grupo.

En un equipo que ejecuta Windows, todas las carpetas de un directorio se pueden proteger. Es decir, puede seleccionar una carpeta y controlar quién puede acceder a los archivos, y si pueden copiar el archivo o (en el caso con más privilegios) cambiar un archivo, eliminar un archivo o agregar archivos a la carpeta. Esto se conoce como control de acceso y el mecanismo para él se conoce como la lista de control de acceso (ACL). Al crear la ACL, puede asignar privilegios de acceso a cualquier grupo o grupo, así como a miembros individuales de un dominio.

La infraestructura de WCF está diseñada para usar estos mecanismos de seguridad de Windows. Por lo tanto, si va a crear un servicio que se implementa en una intranet y cuyos clientes están restringidos a los miembros del dominio de Windows, la seguridad se implementa fácilmente. Solo los usuarios válidos pueden iniciar sesión en el dominio. Una vez que los usuarios inician sesión, el controlador Kerberos permite a cada usuario establecer contextos seguros con cualquier otro equipo o aplicación. En un equipo local, los grupos se pueden crear fácilmente y, al proteger carpetas específicas, esos grupos se pueden usar para asignar privilegios de acceso en el equipo.

Implementación de la seguridad de Windows en los servicios de 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 acceder 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 la integridad. Para obtener más información sobre cómo crear un servicio que use la seguridad de Windows, vea Cómo: Proteger un servicio con credenciales de Windows.

Autorización mediante la clase PrincipalPermissionAttribute

Si necesita restringir el acceso de los recursos en un equipo, la manera más fácil es usar la PrincipalPermissionAttribute clase . Este atributo permite restringir la invocación de operaciones de servicio exigiendo que el usuario esté en un grupo o rol de Windows especificado, o que sea un usuario específico. Para obtener más información, vea Cómo: Restringir el acceso con la clase PrincipalPermissionAttribute.

Suplantación

La suplantación es otro mecanismo que puede usar para controlar el acceso a los recursos. De forma predeterminada, un servicio hospedado por IIS se ejecutará en la identidad de la cuenta de ASPNET. La cuenta de ASPNET solo puede acceder a los recursos para los que tiene permiso. Sin embargo, es posible establecer la ACL de una carpeta para excluir la cuenta de servicio ASPNET, pero permitir que ciertas identidades accedan a la carpeta. A continuación, la pregunta se convierte en cómo permitir que esos usuarios accedan a la carpeta si no se permite que la cuenta de ASPNET lo haga. La respuesta es usar la suplantación, en la que el servicio puede usar las credenciales del cliente para acceder a un recurso determinado. Otro ejemplo es cuando se accede a una base de datos de SQL Server a la que solo determinados usuarios tienen permiso. Para obtener 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 consta de los mismos requisitos que la seguridad en una intranet. Un servicio debe presentar sus credenciales para demostrar su autenticidad y los clientes deben demostrar su identidad al servicio. Una vez probada la identidad de un cliente, el servicio puede controlar cuánto acceso tiene el cliente a los recursos. Sin embargo, debido a la naturaleza heterogénea de Internet, las credenciales presentadas difieren de las usadas en un dominio de Windows. Mientras que un controlador Kerberos controla la autenticación de los usuarios en un dominio con vales para credenciales, en Internet, los servicios y los clientes dependen de cualquiera de las distintas maneras de presentar credenciales. Sin embargo, el objetivo de este tema es presentar un enfoque común que le permite crear un servicio WCF accesible en Internet.

Uso de IIS y ASP.NET

Los requisitos de seguridad de Internet y los mecanismos para resolver esos problemas no son nuevos. IIS es el servidor web de Microsoft para Internet y tiene muchas características de seguridad que abordan esos problemas; además, ASP.NET incluye características de seguridad que los servicios WCF pueden usar. Para aprovechar estas características de seguridad, hospede un servicio WCF en IIS.

Uso de proveedores de membresía y roles en ASP.NET

ASP.NET incluye un sistema de membresía y un proveedor de funciones. El proveedor es una base de datos de pares de nombre de usuario y contraseña para autenticar a los autores de llamadas que también le permiten especificar los privilegios de acceso de cada llamador. Con WCF, puede usar fácilmente un proveedor de membresía y roles preexistente a través de la configuración. Para obtener una aplicación de ejemplo que muestre esto, consulte el ejemplo Proveedor de membresía y roles.

Credenciales usadas por IIS

A diferencia de un dominio de Windows respaldado por un controlador Kerberos, Internet es un entorno sin un único controlador para administrar los millones de usuarios que inician sesión en cualquier momento. En su lugar, las credenciales en Internet suelen tener la forma de certificados X.509 (también conocidos como Protocolo de capa de conexión segura o certificados SSL, por sus siglas en inglés). Estos certificados suelen ser emitidos por una entidad de certificación, que puede ser una empresa de terceros que vude la autenticidad del certificado y la persona a la que se ha emitido. Para exponer su servicio en Internet, también debe proporcionar un certificado confiable para autenticar su servicio.

La pregunta surge en este momento, ¿cómo se obtiene este certificado? Un enfoque consiste en ir a una entidad de certificación de terceros, como Authenticode o VeriSign, cuando esté listo para implementar el servicio y comprar un certificado para su servicio. Sin embargo, si está en la fase de desarrollo con WCF y aún no está listo para confirmar la compra de un certificado, existen herramientas y técnicas para crear certificados X.509 que puede usar para simular una implementación de producción. Para obtener más información, vea Trabajar con certificados.

Modos de seguridad

La programación de la seguridad de WCF implica algunos puntos de decisión críticos. Uno de los aspectos más básicos 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 ambos modos principales, es el transporte con el modo de credenciales de mensaje.

El modo de seguridad determina cómo se protegen los mensajes y cada opción tiene ventajas y desventajas, como se explica a continuación. Para obtener más información sobre cómo establecer el modo de seguridad, vea Cómo: Establecer el modo de seguridad.

Modo de transporte

Hay varias capas entre la red y la aplicación. Una de estas es la capa de transporte *,* que administra la transferencia de mensajes entre puntos de conexión. Para el presente propósito, solo es necesario que comprenda que WCF usa varios protocolos de transporte, cada uno de los cuales puede proteger la transferencia de mensajes. (Para obtener más información sobre los transportes, vea Transportes).

Un protocolo usado habitualmente es HTTP; otro es TCP. Cada uno de estos protocolos puede proteger la transferencia de mensajes mediante un mecanismo (o mecanismos) concretos para el 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 WSHttpBinding clase y establece su modo de seguridad en Transporte, selecciona SSL a través de HTTP (HTTPS) como mecanismo de seguridad. La ventaja del modo de transporte es que es más eficaz que el modo de mensaje porque la seguridad se integra en un nivel comparativamente bajo. Al usar el modo de transporte, el mecanismo de seguridad debe implementarse según la especificación del transporte y, por tanto, los mensajes solo pueden fluir de forma segura desde un punto a otro a través del transporte.

Modo de mensaje

En cambio, el modo de mensaje proporciona seguridad al incluir los datos de seguridad como parte de cada mensaje. Con encabezados de seguridad XML y SOAP, las credenciales y otros datos necesarios para garantizar la integridad y confidencialidad del mensaje se incluyen con cada mensaje. Cada mensaje incluye datos de seguridad, por lo que da como resultado un peaje en el rendimiento, ya que cada mensaje debe procesarse individualmente. (En modo de transporte, una vez protegida la capa de transporte, todos los mensajes fluyen libremente). Sin embargo, la seguridad del mensaje tiene una ventaja sobre la seguridad de transporte: es más flexible. Es decir, el transporte no determina los requisitos de seguridad. Puede usar cualquier tipo de credencial de cliente para proteger el mensaje. (En el modo de transporte, el protocolo de transporte determina el tipo de credencial de cliente que puede usar).

Transporte con credenciales de mensaje

El tercer modo combina lo mejor tanto de transporte como de seguridad de mensajes. En este modo, la seguridad de transporte se usa para garantizar eficazmente la confidencialidad y la integridad de todos los mensajes. Al mismo tiempo, cada mensaje incluye sus datos de credenciales, lo que permite autenticar el mensaje. Con la autenticación, también se puede implementar la autorización. Al autenticar un remitente, se puede conceder acceso a los recursos (o denegar) según la identidad del remitente.

Especificar el tipo de credencial de cliente y el valor de credencial

Después de seleccionar un modo de seguridad, también puede especificar un tipo de credencial de cliente. El tipo de credencial de cliente especifica qué tipo debe usar un cliente para autenticarse en el servidor.

Sin embargo, no todos los escenarios requieren un tipo de credencial de cliente. Mediante SSL a través de HTTP (HTTPS), un servicio se autentica en el cliente. Como parte de esta autenticación, el certificado del servicio se envía al cliente en un proceso denominado negociación. El transporte protegido por SSL garantiza que todos los mensajes sean confidenciales.

Si va a crear un servicio que requiera que el cliente se autentique, la elección de un tipo de credencial de cliente depende del transporte y el modo seleccionado. Por ejemplo, el uso del transporte HTTP y la elección del modo de transporte proporciona varias opciones, como Basic, Digest y otros. (Para obtener más información sobre estos tipos de credenciales, vea Descripción de la autenticación HTTP).

Si va a crear un servicio en un dominio de Windows que solo estará disponible para otros usuarios de la red, lo más fácil de usar es el tipo de credencial de cliente de Windows. Sin embargo, es posible que también necesite proporcionar un servicio con certificado. Esto se muestra en Cómo: Especificar valores de credenciales de cliente.

Valores de credencial

Un valor de credencial es la credencial real que usa el servicio. Una vez que haya especificado un tipo de credencial, es posible que también tenga que configurar el servicio con las credenciales reales. Si ha seleccionado Windows (y el servicio se ejecutará en un dominio de Windows), no especifique un valor de credencial real.

identidad

En WCF, el término identidad tiene significados diferentes para el servidor y el cliente. En resumen, cuando se ejecuta 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, vea Cómo: Examinar el contexto de seguridad.

En cambio, en el cliente, se usa la identidad para validar el servicio. En tiempo de diseño, un desarrollador cliente puede establecer el <elemento de identidad> en un valor obtenido del servicio. En tiempo de ejecución, el cliente comprueba el valor del elemento en 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 de usuario (UPN) si el servicio se ejecuta bajo la identidad de un usuario determinado o un nombre principal del servicio (SPN) si el servicio se ejecuta en una cuenta de equipo. Para más información, consulte Identidad de servicio y autenticación. La credencial también puede ser un certificado o un campo que se encuentra en un certificado que identifica el certificado.

Niveles de protección

La propiedad ProtectionLevel se produce 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 elementos de mensaje) que admiten un servicio están firmados, firmados y cifrados, o se envían sin firmas ni cifrado. Para obtener más información sobre la propiedad , vea Descripción del nivel de protección y para obtener ejemplos de programación, vea How to: Set the ProtectionLevel Property. Para obtener más información sobre cómo diseñar un contrato de servicio con ProtectionLevel en contexto, consulte Diseño de contratos de servicio.

Consulte también

  • Last updated on