Mejores Prácticas para servicios web, Parte 11: Seguridad de servicios web, Parte 1

Mecánica de la Seguridad de SW

Hacer negocios en el mundo actual normalmente requiere que una compañía utilice Internet tanto para negocios como para interacciones de negocio-a-cliente y de negocio-a-negocio. Con frecuencia, la información intercambiada en transacciones de negocios es crítica de misión, valorada en el mercado o confidencial, por lo tanto, mientras transita por Internet debe ser protegida de accesos accidentales o de control y uso no autorizados. Entender la mecánica sobre cómo funciona la Seguridad de SW y las opciones que permite en una arquitectura orientada al servicio puede permitirle hacer la mejor selección de tecnología de seguridad para responder a sus necesidades de autenticaciones, integridad de datos y confidencialidad.

Holt Adams, Executive IT Architect, IBM

Holt Adams es Arquitecto Ejecutivo de TI del grupo de Tecnología Emergente de software IBM, donde actualmente apoya el programa jStart de IBM y el Equipo de Innovación del Cliente. Sus habilidades le permiten jugar roles tanto de arquitecto de solución como de gestor de vinculación, para ser un catalizador efectivo en la adopción de los clientes de tecnologías de Internet emergentes. Tiene experiencia como profesional en los aspectos técnico y de negocios de las vinculaciones de clientes, a partir de actividades que incluyen la generación de oportunidades, la calificación de negocios, la administración de requerimientos, la arquitectura de solución el diseño de solución y las negociaciones contractuales. Como Arquitecto de IT, Holt refina las necesidades de negocios de los clientes que se pueden solucionar con las capacidades de TI de las tecnologías emergentes en la creación de soluciones de última generación. Durante su paso por el Programa jStart y en otros trabajos relacionados con servicios, su portfolio de tecnologías incluyó computación wireless/ubicua, infraestructura de Intrenet, Java/J2EE, XML, servicios web/SOA, fuente abierta, Web 2.0, redes sociales y tecnologías de mashup corporativo.



06-01-2012

El tema de este artículo está dividido en dos partes. La primera parte cubre los recursos de Seguridad de SW, la relación entre los participantes de negocios y la mecánica de cómo se implementan las capacidades de Seguridad de SW. La segunda parte describirá el soporte del IBM® WebSphere® Application Server de la Seguridad de SW, los requerimientos de negocios de los clientes y cómo ellos han utilizado la Seguridad de SW y otras tecnologías de seguridad en sus soluciones operacionales.

Introducción

Implicaciones del uso de la seguridad

Las opciones de diseño y las implementaciones que responden a necesidades de seguridad a menudo tienen un impacto adverso en el desempeño de una solución. Esto no implica que todas las tecnologías de seguridad utilizadas en las soluciones den como resultado un bajo desempeño. En lugar de ello, usted debe saber que las soluciones de servicios web que requieren autenticación de los participantes de negocios, firma digital del contenido del mensaje y cifrado de datos XML pueden tener características de desempeño bastante diferentes basadas en la tecnología o método utilizado para asegurar las funciones y datos de negocios expuestos de una solución.

La trinidad de la seguridad que se cubre en este artículo comprende: (a) autenticación, (b) integridad de datos, y(c) confidencialidad de datos. Si usted no es un experto en los mecanismos para resolver a estos requerimientos de seguridad, mostraré brevemente una visión general de las capacidades a continuación, antes de profundizar en los detalles sobre cómo puede implementarlas.

La trinidad de la seguridad

La Autenticación es utilizada para asegurar que las partes dentro de una transacción de negocios realmente son quienes dicen ser; por ello se requiere una prueba de identidad. Esta prueba de identidad pude realizarse de varias formas. Un ejemplo simple es presentar una ID de usuario junto con una contraseña secreta. Un ejemplo más complejo es el uso de un certificado X.509 expedido por una Autoridad Certificadora confiable (como Verisign). El certificado contiene credenciales de identidad y tiene un par de claves públicas y privadas asociadas a él. La prueba de identidad presentada por una parte incluye el certificado en sí y una porción separada de información que es firmada digitalmente usando la clave privada del certificado. Al validar la información firmada usando la clave pública asociada con el certificado de la parte, quien recibe puede autenticar que quien la envía es el propietario del certificado, validando así su identidad. Cuando ambas partes se validan entre sí, esto se llama autenticación mutua y esto se hace a menudo entre el consumidor de servicios web y el proveedor de servicios web.

Con el fin de validar la integridad de la información de negocios intercambiada en una transacción, asegurando que el contenido del mensaje no ha sido alterado ni corrompido durante su transmisión sobre Internet, los datos pueden ser firmados digitalmente usando claves de seguridad. Este es el segundo requerimiento de la trinidad de la seguridad. Una práctica común es usar la clave privada del certificado X.509 del remitente para firmar digitalmente el cuerpo SOAP de una solicitud de servicios web. De manera similar, los bloques de un encabezado SOAP de una solicitud también pueden ser firmados para asegurar la integridad de la información intercambiada en una transacción que esté por fuera del alcance del contexto de negocios efectivo (por ejemplo, ID's de mensajes, tokens de seguridad). De forma similar, una respuesta de servicios web puede estar firmada digitalmente para asegurar la integridad de los datos.

El tercer requerimiento de la trinidad de la seguridad es la confidencialidad. La tecnología de cifrado puede usarse para hacer que la información intercambiada en las solicitudes y respuestas de servicios web sea ilegible. El propósito de esto es asegurar que cualquiera que acceda a los datos en tránsito, en memoria, o después de que hayan sido persistidos, necesitará los algoritmos apropiados y las claves de seguridad para descifrar los datos antes de poder acceder a la información real.

Actualmente usted puede implementar todas estas medidas de seguridad usando diferentes mecanismos. Con base en sus requerimientos específicos y entorno de negocios, usted podrá seleccionar aquellos que dependan del medio de transporte o aquellos que sean específicos para la mensajería SOAP.

Como este artículo es parte de la serie Mejores Prácticas para servicios web , se enfocará principalmente en las diferentes formas de aprovechar la Seguridad de SW en sus soluciones y en el impacto en el desempeño que usted puede esperar.


Modelo General de Seguridad de SW

La especificación de Seguridad de SW está en su proceso final de aprobación dentro del cuerpo de estándares OASIS, y proporciona los mecanismos para responder a todos los tres requisitos descritos como la trinidad de la seguridad entre puntos finales de aplicación. Con la Seguridad de SW usted puede implementar de forma selectiva cada uno de los requerimientos de la trinidad de la seguridad como tal, o todos pueden estar resueltos en su solución.

Una aplicación que requiere de los servicios de otra aplicación es considerada la Aplicación Consumidora para este artículo. Me referiré a la aplicación que proporciona los servicios como el Proveedor de Servicios. El siguiente diagrama ilustra esta relación y es la base de gran parte de la discusión que sigue:

Figura 1 - Entorno de sistema
Figura 1 - Entorno de sistema

Para el escenario descrito e ilustrado en las siguientes secciones, la clave pública del certificado X.509 del Proveedor de Servicios debe intercambiarse con el cliente y configurarse en el tiempo de ejecución del cliente antes de invocar los servicios del Proveedor de Servicios. Tanto para el Consumidor de Aplicaciones como para el Proveedor de Servicios el certificado raíz de la Autoridad Certificadora (como Verisign) que expidió los certificados de las partes, necesitará ser importado a los almacenes de claves locales. El almacén de claves de la Aplicación Consumidora tendrá el certificado raíz del certificado del Proveedor de Servicios. De igual manera, al almacén de claves del Proveedor de Servicios requerirá que el certificado raíz del certificado de la Aplicación Consumidora. Esto es obligatorio y permite la validación de las firmas digitales de los certificados individuales que son pasados como tokens de seguridad binarios en los mensajes SOAP.

Una implementación completa de todos los tres requisitos de seguridad incluiría:

  • Los remitentes de la solicitud o la respuesta de servicios web
    • Firmar el mensaje con la clave privada de su certificado X.509
    • Cifrar el mensaje con la clave pública del certificado X.509 del receptor para asegurar que solo estos puedan acceder al contenido del mensaje
  • Los receptores de la solicitud o respuesta de servicios web
    • Verificar la firma del mensaje usando la clave pública del remitente para autenticarlo y verificar la integridad del mensaje
    • Descifrar el mensaje con la clave privada de su certificado X.509

Detalles del cifrado XML de la Seguridad de SW

El cifrado de datos basado en la especificación de Seguridad de SW y en las especificaciones de Cifrado XML a que hace referencia incluye:

  • Un proceso de dos fases utilizando algoritmos simétricos y asimétricos.
  • Una clave compartida que se utiliza para cifrar/descifrar los datos del mensaje usando un algoritmo simétrico como Triple DES. Los algoritmos simétricos son bastante eficientes y funcionan con una sola clave tanto para cálculos de cifrado como de descifrado. Las implementaciones de Seguridad de SW utilizan una clave que se genera aleatoriamente. En cuanto los datos del mensaje son cifrados, la clave en sí es insertada al mensaje. (Note que la clave también es cifrada, como se describe a continuación).
  • Pasar la clave compartida en el mensaje SOAP con la clave cifrada/descifrada usando un algoritmo asimétrico como el RSA-V1.5. El cifrado de la clave compartida se efectúa de manera diferente a los datos de mensaje con un algoritmo que utiliza un par de claves (privada y pública). Un certificado X.509 tiene dos claves, una que es privada para el propietario del certificado y una segunda que es compartida con otros con quienes hace negocios. Los algoritmos simétricos son más eficientes que los asimétricos; no obstante, requieren del manejo de claves compartidas entre las partes y tienen riesgos de seguridad inherentes de ser expuestos a otros por fuera de su organización o de sus asociados de negocios. Por ello, al usar solo algoritmos asimétricos en la clave aleatoria, la Seguridad de SW proporciona tanto una solución relativamente eficiente como una que es fácil de manejar. En la parte dos de este artículo, explicaré por qué utilizo la palabra relativamente.

Consulte los enlaces de la sección Recursos para conocer detalles sobre el Cifrado XML.


Escenario de Seguridad de SW del mundo real

El escenario descrito a continuación es una de las muchas posibilidades que se pueden lograr con la Seguridad de SW. Este utiliza certificados X.509, una práctica común en muchas de las soluciones de clientes que describiré en la Parte Dos de este artículo.

Procesamiento de solicitud de servicios web por una Aplicación Consumidora

Normalmente la Aplicación Consumidora tendrá un Proxy de Servicio o un sub-componente JAX-RPC que ha sido generado a partir de un Entorno de Desarrollo Integrado (como el WebSphere Studio Application Developer) usando el WSDL del Proveedor de Servicios. Cuando se realiza una invocación de servicios web, el proxy o el tiempo de ejecución SOAP en el sistema cliente lleva a cabo las funciones de seguridad antes de enviar la solicitud.

Primero, el mensaje SOAP es firmado digitalmente. El tiempo de ejecución SOAP puede acceder al almacén de claves para recuperar las claves de seguridad y los certificados, según lo necesite. Dependiendo del soporte de seguridad de SW que proporcione su entorno, usted tal vez pueda firmar solo el cuerpo SOAP, o puede firmar elementos individuales dentro del cuerpo. Además, los bloques de encabezado SOAP pueden ser firmados. La firma se realiza usando la clave privada del certificado X.509 de la Aplicación Consumidora. En cuanto el mensaje ha sido firmado, el certificado X.509 en sí se incluye en el encabezado SOAP como un token de seguridad binario. El mensaje se cifra usando un algoritmo simétrico con una clave compartida. La clave usada para el cifrado de datos está cifrada ella misma usando un algoritmo asimétrico con la clave pública asociada al certificado X.509 del Proveedor de Servicio. En cuanto el mensaje y la clave asociada han sido cifrados, se incluye en el encabezado SOAP una referencia al certificado X.509 del Proveedor de Servicios al cual se está enviando la solicitud. Esto se hace porque el Proveedor de Servicios puede estar usando múltiples certificados.

Figura 2 - Procesamiento de solicitud por una Aplicación Consumidora con Seguridad de SW
Figura 2 - Procesamiento de solicitud por una Aplicación Consumidora con Seguridad de SW

Procesamiento de solicitud de servicios web por un Proveedor de Servicios

Cuando un Proveedor de servicios recibe una solicitud de servicios web, la solicitud es dirigida hacia el motor de procesamiento SOAP (tiempo de ejecución SOAP) con base en el URL de la solicitud (punto de acceso publicado para el servicio). Los datos del mensaje y la clave compartida que se pasan en la solicitud están cifrados, así que el primer paso es identificar el certificado X,509 referenciado en el encabezado SOAP y recuperar su clave privada de un almacén de claves. En cuanto se obtiene la clave privada, la clave compartida puede descifrarse usando un algoritmo asimétrico. Con la segunda clave abierta, los datos de mensaje se pueden descifrar usando un algoritmo simétrico. Con todo el mensaje abierto ahora, se puede acceder al certificado X.509 que se pasó en el encabezado SOAP para recuperar su clave pública. La firma digital del mensaje se efectúa con la clave pública de la Aplicación Consumidora. Como resultado de la validación satisfactoria de la firma, el tiempo de ejecución SOAP del Proveedor de Servicios no solo valida la integridad del mensaje, sino que también se asegura de que la Aplicación Consumidora efectivamente haya firmado el mensaje. Este proceso también autentica el origen/remitente del mensaje, porque solo el remitente que posee el certificado tiene acceso a la clave privada usada para firmar el mensaje. En cuanto el mensaje ha sido descifrado y se valida la firma, el tiempo de ejecución SOAP llama la implementación de los servicios web.

Figura 3 - Procesamiento de solicitud por el Proveedor de servicios con Seguridad de SW
Figura 3 - Procesamiento de solicitud por el Proveedor de servicios con Seguridad de SW

Procesamiento de respuesta de servicios web por el Proveedor de Servicios

En cuanto se ha ejecutado la lógica de negocios de la implementación del servicio y hay una respuesta disponible, se realizan las mismas operaciones de Seguridad de SW para el mensaje de respuesta de servicios web. No obstante, los roles de los pares de claves X.509 se invierten para firma digital y descifrado. El tiempo de ejecución SOAP del Proveedor de Servicios firma digitalmente el mensaje usando la clave privada de su propio certificado X.509. El certificado se incluye en el mensaje SOAP y el mensaje es cifrado usando una clave compartida. La clave usada para el cifrado de datos puede ser la misma clave que se pasó en la solicitud original, u otra clave generada aleatoriamente, siendo esto último lo más común. El cifrado de la clave estándar se lleva a cabo usando la clave pública del certificado que se pasó en la solicitud; así solo el remitente de la solicitud que tiene acceso a la clave privada del certificado es la única parte que puede descifrar el mensaje. En cuanto el mensaje ha sido firmado y cifrado, el tiempo de ejecución SOAP del Proveedor de Servicios envía la respuesta a la Aplicación Consumidora.

Figura 4 - Procesamiento de la respuesta por el Proveedor de Servicios con Seguridad de SW
Figura 4 - Procesamiento de la respuesta por el Proveedor de Servicios con Seguridad de SW

Procesamiento de la respuesta de servicios web por la Aplicación Consumidora

El procesamiento de la respuesta de servicios web por la Aplicación Consumidora con Seguridad de SW es bastante similar a lo que realizó el Proveedor de Servicios con la solicitud.

La Aplicación Consumidora recibe una respuesta de servicios web con la respuesta dirigida al motor de procesamiento SOAP (tiempo de ejecución SOAP) con base en la sesión HTTP original. Los datos de mensaje y la clave compartida que se pasaron en la respuesta están cifrados. Por lo tanto, el paso inicial es recuperar la clave privada del certificado asociado con la solicitud correspondiente para descifrar la clave compartida utilizando un algoritmo asimétrico. Con la segunda clave abierta, los datos de mensaje se pueden descifrar usando un algoritmo simétrico. Después de que todo el mensaje está abierto, se puede acceder al certificado X.509 que se pasó en el encabezado SOAP para recuperar su clave pública. La firma digital del mensaje se efectúa con la clave pública del Proveedor de Servicios. Después de la validación satisfactoria de la firma, el tiempo de ejecución SOAP de la Aplicación Consumidora no solo valida la integridad del mensaje, sino que también se asegura de que el Proveedor de Servicios efectivamente haya firmado el mensaje. Este proceso también autentica el origen/remitente del mensaje, porque solo el remitente que posee el certificado tiene acceso a la clave privada usada para firmar el mensaje. En cuanto el mensaje ha sido descifrado y la firma validada, el tiempo de ejecución SOAP reenvía la respuesta a la Aplicación Consumidora.

Figura 5 - Procesamiento de respuesta por Aplicación Consumidora con Seguridad de SW
Figura 5 - Procesamiento de respuesta por Aplicación Consumidora con Seguridad de SW

Resumen

Bajo la cubierta, la Seguridad de SW es bastante compleja y puede utilizarse en muchos escenarios diferentes. El ejemplo descrito arriba tiene muchos aspectos que los clientes de hoy han implementado. Parte o la totalidad del escenario ha sido implementado por clientes sobre plataformas WebSphere Application Server, dependiendo de sus políticas de seguridad existentes, de su infraestructura de seguridad, o de sus requerimientos de negocios. Esto se tratará en la Parte Dos de este artículo.

La buena noticia es que el soporte de la Seguridad de SW del WebSphere Application Server es mediante un modelo declarativo. Así, una vez que usted tenga sus implementaciones de servicios web desarrolladas y comprobadas, la activación de los recursos de Seguridad de SW se logra fácilmente durante la fase de implementación. Como resultado, la complejidad de la Firma Digital y del Cifrado XML deben ser una preocupación menor para usted como Arquitecto de TI o como Especialista de TI.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=783709
ArticleTitle=Mejores Prácticas para servicios web, Parte 11: Seguridad de servicios web, Parte 1
publish-date=01062012