Conceptos de seguridad en los servicios WEB

Se ofrece un repaso de las principales iniciativas, en forma de consorcios u organizaciones, que están implicadas en los servicios Web en general y en el aspecto de su seguridad en particular.

Consorcio World Wide Web (W3C)

La W3C nace con un objetivo claro, ser un foro de discusión abierto y fomentar la interoperabilidad en la evolución técnica que se produce en el mundo Web. En un periodo de tiempo menor a diez años, se han generado más de cincuenta especificaciones técnicas que están orientadas a la estandarización de la infraestructura Web.

Se definen como objetivos a largo plazo en W3C:

• Acceso Universal. Permitir que el acceso a la web sea para todos. Realizando un esfuerzo por las tecnologías que consideran las diferentes lenguas, culturas, capacidades, educación, recursos disponibles o las disminuciones físicas o psíquicas de cada uno.
• Web Semántica. Ofrecer y desarrollar avances en el mundo WEB que permitan a los usuarios disfrutar del mejor uso posible de los recursos disponibles en la web, adaptándolo a las necesidades de cada usuario.
• Web de Confianza. Crear un desarrollo web, que permita realizar desarrollo manteniendo unos criterios comerciales y sociales adecuados.

OASIS (Organization for the Advancement of Structured Information Standards)

OASIS, es un organismo global muy centrado en temas de comercio electrónico. Es un organismo sin ánimo de lucro. Oasis trata de establecer estándares de forma abierta y mediante procesos ligeros aplicados por sus miembros, tratando temas referentes a la seguridad, servicios Web, edición digital, tratamiento de XML, etc.

IBM/Microsoft/Verisign/RSA Security

Mediante un proceso de colaboración entre las principales compañías dentro del ámbito IT, siendo encabezadas por Microsoft e IBM, se han propuesto una serie de especificaciones acerca de como afrontar la seguridad en los servicios Web. Dentro de este conjunto de especificaciones se encuentra la especificación WS-Security estandarizada por OASIS.

WS-Security

La especificación WS-Security, describe la forma de asegurar los servicios Web en el nivel de los mensajes, en lugar de en el nivel del protocolo de transferencia o en el de la conexión. Para ello, tiene como objetivo principal describir la forma de firmar y de encriptar mensajes de tipo SOAP. Las soluciones en el nivel de transporte actuales, como SSL/TLS, proporcionan un sólido cifrado y autenticación de datos punto a punto, aunque presentan limitaciones cuando un servicio intermedio debe procesar o examinar un mensaje. Por ejemplo, un gran número de organizaciones implementan un corta fuegos (firewall) que realiza un filtrado en el nivel de la aplicación para examinar el tráfico antes de pasarlo a una red interna.

Si un mensaje debe pasar a través de varios puntos para llegar a su destino, cada punto intermedio debe reenviarlo a través de una nueva conexión SSL. En este modelo, el mensaje original del cliente no está protegido mediante cifrado puesto que atraviesa servidores intermedios y para cada nueva conexión SSL que se establece se realizan operaciones de cifrado adicionales que requieren una gran cantidad de programación

El estándar WS-Security se basa en estándares y certificaciones digitales para dotar a los mensajes SOAP de los criterios de seguridad necesarios. Se definen cabeceras y usa XML Signature para el manejo de firmas en el mensaje. La encriptación de la información la realiza mediante XML Encryption. Hace uso del intercambio de credenciales de los clientes.

WS-Addressing, desempeña un papel fundamental en la seguridad en el nivel de los mensajes puesto que proporciona los mecanismos para enviar los mensajes de un modo independiente del transporte. Esto permite enviar un mensaje seguro a través de cualquier transporte y enrutarlo con facilidad. La protección del mensaje en lugar del uso del protocolo de transporte ofrece varias ventajas:

• En primer lugar, resulta más flexible puesto que se pueden firmar o cifrar partes del mensaje en lugar del mensaje completo. De este modo, los intermediarios pueden ver las partes del mensaje destinadas a ellos. Un ejemplo de esto sería un servicio Web que enruta mensajes SOAP y puede inspeccionar las partes no cifradas de los mismos para determinar a dónde enviarlos, mientras que otras partes permanecen cifradas.
• En segundo lugar, los intermediarios pueden agregar sus propios encabezados al mensaje y firmarlos para llevar a cabo el registro de auditorías. Por último, esto implica que el mensaje protegido se puede enviar a través de diferentes protocolos, como SMTP, FTP y TCP, sin necesidad de basarse en el protocolo para la seguridad

Como funciona WS-Security

WS-Security define la forma de conseguir integridad, confidencialidad y autenticación en los mensajes SOAP. Se realiza de la siguiente manera:

• La autenticación se ocupa de identificar al llamador.
• WS-Security utiliza tokens de seguridad para mantener esta información mediante un encabezado de seguridad del mensaje SOAP.
• La integridad del mensaje se consigue mediante firmas digitales XML, que permiten garantizar que no se han alterado partes del mensaje desde que lo firmó el originador.
• La confidencialidad del mensaje se basa en la especificación XML Encryption y garantiza que sólo el destinatario o los destinatarios a quien va destinado el mensaje podrán comprender las partes correspondientes.
• Se apoya en WS-Adressing para asegurar el no repudio.

WS-Policy

Es la especificación encargada de delimitar las diferentes políticas aplicables a los servicios Web. Es de vital importancia a la hora de integrar los servicios Web, ya que si presentan cierta complejidad, es muy necesario conocer los detalles del XML que lo define, además de otros requisitos o capacidades adicionales.

Si se produce un intento de integrar un servicio sin conocer los detalles de su implementación probablemente se este evocando al fracaso. Por lo tanto es muy necesario realizar un estándar que defina las diferentes políticas a acordar. Sin él, los desarrolladores quedarían expuestos a realizar desarrollos sin integración y difícilmente escalables

Un marco de trabajo de políticas permitiría a los desarrolladores expresar las políticas de los servicios de una forma procesable por las computadoras. La infraestructura de los servicios Web puede verse ser mejorada para entender ciertas políticas y forzar su uso en tiempo de ejecución.

WS-Trust

La especificación WS-Trust permite definir extensiones al estándar WS-Security con el objetivo claro de dotar a este de nuevos mecanismos de seguridad. En esta especificación se incluye el proceso de solicitud, emisión y control sobre tokens de seguridad y se permite la gestión de las relaciones de confianza entre los servicios

WS-Security, realiza una definición amplia de los mecanismos básicos para proporcionar un entorno de trabajo seguro en el intercambio de mensajes. Esta especificación, partiendo de los mecanismos básicos, va añadiendo primitivas adicionales junto con extensiones para estandarizar el intercambio de tokens de seguridad. Con ello se busca optimizar la emisión y propagación de las credenciales de los servicios dentro de diferentes dominios de confianza.

Como funciona WS-Trust

Esta especificación da soporte a un modelo de confianza destinado a los servicios Web, se le denomina Web Services Trust Model. Para ello, define un proceso a través del cual, un servicio, puede solicitar que cualquier petición que le llegue cumpla con una serie de reclamaciones. En la situación, que un solicitante no disponga de todos los requerimientos necesarios, los solicita al Servicio de tokens de seguridad (STS). Existe una relación de confianza entre el STS y el servicio

La especificación define varios mecanismos para verificar relaciones de confianza entre dos partes. Sin embargo, no se restringe solo a ellos, pudiendo un servicio verificar la relación de confianza con la otra parte como considere necesario. Los métodos que definen son los siguientes:

• Fixed Trust Roots: El más simple. El servicio mantiene un conjunto fijo de relaciones de confianza
• Trust hierarchies: El servicio confiara en los tokens siempre que vengan de una jerarquía de confianza que lleve a un trust root.
• Authentication Service: Es un servicio con el cual el servicio mantiene una relación de confianza. Cuando llega un security token, el servicio lo envía al Authentication Service el cuál enviará probablemente otro token que aprobará o no la autenticación

WS-Federation

Con frecuencia se produce la situación de que participantes en el consumo y la prestación de un servicio pueden utilizar diferentes tecnologías de seguridad, por ejemplo, una de las partes podrá utilizar Kerberos y otro Certificados X.509, podría necesitarse una traducción de los datos que afectan a la seguridad entre las partes afectadas.

Una federación es una colección dominios de seguridad que han establecido relaciones en virtud del cual un proveedor de uno de los dominios puede proporcionar acceso autorizado a los recursos que gestiona sobre la base de la información de los participantes (como puede ser su identidad) la cual debe ser afirmada por un proveedor de identidad (Security Token Service).

WS-Federation es la especificación que describe la forma de llevar a cabo la intermediación entre los participantes. Esta especificación tiene como objetivo principal ayudar a la definición de los mecanismos de federación de dominios de seguridad, ya sean distintos o similares. Para ello, define , categoriza y intermedia con los niveles de confianza de las identidades, atributos, y autenticación de los servicios Web de todos los colaboradores.

En la especificación WS-Federation se definen perfiles asociados a las entidades que servirán para clasificar los solicitantes que pueden adaptarse al modelo. Es por tanto un objetivo prioritario de esta especificación habilitar la federación de la información de las identidades, atributos, autenticación y autorización.

WS-Addressing

WS-Addressing ofrece seguridad de extremo a extremo a la mensajería SOAP . Independientemente de los tipos de intermediarios como puertos, workstations, cortafuegos, etc. que sean atravesados por un bloque en el camino al receptor, todo aquel que se encuentre por el camino sabrá:

• De dónde viene
• (Dirección postal) La dirección a donde se supone que va
• (Att) La persona o servicio específico en esa dirección que se supone va a recibirlo
• Dónde debería ir si no puede ser remitido como estaba previsto
• Todo esto lo incluye en la cabecera del mensaje SOAP ()

WS-Addressing convierte a los mensaje en unidades autónomas de comunicación. La especificación WS-Addressing define dos tipos de elementos que se incorporan en el mensajes SOAP:

• Endpoint References (EPR), referencias de invocación, que identifican al punto donde deben ser dirigidas las peticiones.
• Message Information Headers, son cabeceras específicas que contienen información relacionada con la identificación que caracteriza al mensaje.

Endpoint References (EPR)

Un identificador de punto de acceso al servicio web puede contener las siguientes propiedades:

• [wsa:Address], una URI que identifica al punto de acceso. Este elemento es obligatorio
• [wsa:ReferenceProperties], propiedades individuales necesarias para identificar la entidad o recurso transportado. Las provee el creador del punto de acceso al servicio web.
• [wsa:ReferenceParameters], parámetros que faciliten interacciones fruto del camino que recorre el mensaje. Las provee el punto de acceso al servicio web.
• [wsa:PortType]
• [wsa:ServiceName]
• [wsp:Policy], políticas WS-Policy aplicables

Message Information Headers

Provee información que caracteriza al mensaje y que no se puede modificar a lo largo del transporte del mismo. Puede contener las siguientes propiedades:

• [destination, wsa:To], una URI identificando el destino del mensaje.
• [source endpoint, wsa:From], un EndpointReference del punto de acceso del emisor del mensaje.
• [reply endpoint, wsa:ReplyTo], un EndpointReference que contenga el punto de acceso al que dirigir una respuesta. Si se espera respuesta del punto de acceso de destino del mensaje es obligatoria la presencia de esta propiedad.
• [fault endpoint, wsa:FaultTo], un EndpointReference que contenga el punto de acceso al que dirigir los fallos provocados por el mensaje.
• [action, wsa:Action], una URI que identifique el mensaje como un mensaje de entrada, salida o error en la WSDL del servicio web de destino.
• [message id, wsa:MessageID], una URI que identifique unívocamente el mensaje. Si se espera una respuesta, esta propiedad es obligatoria.
• [relationship, wsa:RelatesTo]

La Seguridad en la Arquitectura de Referencia de los Servicios Web

Siguiendo el modelo W3C, vamos a realizar un pequeño estudio sobre los requisitos de seguridad que se encuentran enumerados dentro de la arquitectura de referencia de los servicios web y señalando las diferentes tentativas de ataque que también aparecen dentro de la especificación. Se ofrecerán soluciones para las mismas.

Servicios de seguridad básicos

La seguridad es un concepto considerado clave dentro de los que comprenden el aseguramiento de calidad dentro del servicio Web. Si se realiza una catalogación básica de los servicios de seguridad son la confidencialidad, integridad, autenticidad de origen, no repudio y control de acceso. A continuación se explica brevemente cada uno de ellos:

• Autenticación de los participantes. Los servicios Web por definición tienen mucha heterogeneidad, lo que provoca que los sistema de autenticación tengan que ser flexibles. Si imaginamos un servicio Web que necesita comunicarse con otro servicio, este podría solicitar al demandante credenciales junto a una demostración de que es el propietario de las mismas. Resulta necesario conseguir un estandarización de los protocolos y en los formatos a utilizar. Otro problema remanente es definir un modelo de autenticación Single Sign-On de forma que un servicio que necesita comunicarse con otros servicios Web,no tenga la necesidad de estar continuamente autenticándose y logre completar el proceso de negocio en un tiempo de respuesta aceptable.
• Autorización. Con frecuencia , es necesario aplicar unos criterios que permitan controlar el acceso a los diferentes recursos. Es necesario definir los usuarios que pueden realizar diversas acciones sobre los diferentes recursos. En combinación con la autenticación, permite a las identidades conocidas realizar las acciones para las que tienen permisos. Con frecuencia se definen políticas de acceso en base a jerarquías.
• Confidencialidad. Es necesario asegurar que el contenido incluido en los mensajes que se intercambian se mantiene como información confidencial. Es muy habitual emplear técnicas de cifrado, ya muy extendidas. Obviamente, la confidencialidad del mensaje va más allá que el canal por el que es transmitido.
• Integridad. Esta propiedad garantiza que la información que se ha recibido , es exactamente la misma que se envió desde el cliente.
• No repudio. En una comunicación que se realizan transacciones, es necesario registrar que las mismas se han producido y registrar el autor que lo ejecutó. En el caso de los servicios Web, trasladamos esta política la uso del servicio. Se comprueba que cierto cliente hizo uso de un servicio a pesar de que éste lo niegue (no repudio del solicitante) así como probar la ejecución se llevó a cabo (no repudio del receptor).
• Disponibilidad. Uno de los ataques mas frecuentes a las aplicaciones se basa en la denegación de servicios. Se lanzan múltiples solicitudes falsas para inundar el servicio y provocar su caída. Es necesario contemplar la disponibilidad, como punto muy importante en el diseño de servicio web, ya que permiten cierta redundancia de los sistemas.
• Auditabilidad. El registro de las acciones en los servicios Web permite mantener una traza de las mismas de manera que se puedan realizar análisis posteriores de los datos.
• Seguridad extremo-a-extremo. Cuando se ejecuta un servicio es necesario garantizar la seguridad durante todo el recorrido que efectúan los mensajes. Dado que normalmente existen routers como intermediarios de la comunicación, esto provoca un aumento de la política de seguridad que garantice que se realiza el transporte de forma segura y confirme la seguridad de los intermediarios. Es importante disponer de un contexto de seguridad único y que incluya el canal de comunicación. Para conseguirlo, es necesario aplicar diversas operaciones de carácter criptográfico sobre la información en el origen. De esta manera se evita una dependencia con la seguridad que se configure por debajo de la capa de aplicación y se garantiza los servicios de seguridad

Requisitos de Seguridad

Si realizamos una abstracción sobre la problemática, el objetivo principal es conseguir un entorno para las transacciones y los procesos que sea seguro para todo el canal de comunicación. Obviamente, es necesario garantizar la seguridad durante el tránsito de la comunicación, ya sea con intermediarios o sin ellos durante la misma. Pro otra parte, se necesita asegurar la seguridad de la información en los procesos de almacenamiento: A continuación se ofrece una revisión breve de los principales requisitos para asegurar la seguridad en la comunicación.

Mecanismos de autenticación

La autenticación es obligatoria para mantener control y verificar la identidad de solicitantes y proveedores. En algunas ocasiones, resultará necesario realizar una autenticación tanto del solicitante como del proveedor, ya que puede producirse que los participantes no estén en conexión directa. Pueden existir intermediarios que retransmitan la comunicación

En función de la política de seguridad que se adopte, será necesario autenticar tanto al proveedor como al solicitante o simplemente a alguno de ellos. Se pueden emplear métodos basados en contraseñas, certificados , etc.. para formalizar la autenticación. Si se basan en contraseñas, es necesario aplicar una política que aporte robustez a las mismas.

• Se pueden emplear mecanismos basados en protocolos de transporte como el Http Autentication y SSL/TLS X509 Certificate. Estos mecanismos sólo son válidos cuando existe una conexión directa entre el consumidor y el proveedor de servicio, ya que si un mensaje SOAP viaja entre varios endpoints antes de llegar a su destino, las credenciales del consumidor original se pierden en el primer endpoint.

• También se pueden emplear mecanismos basados en tokens que se incluye dentro del mensaje. El estándar WS-Security incorpora un gran número de tokens que pueden ser empleados en este caso; Username Token, X509 Certificate, SAML assertions, etc. Este mecanismo de autenticación no tiene los problemas de los mecanismos basados en el transporte, ya que las credenciales pueden viajar entre los distintos endpoints hasta llegar a su destino. Si usamos este mecanismo, es necesario que estos sean transmitidos de forma segura para evitar ataques de replay. Esto puede se consigue mediante la firma del token dentro del mensaje SOAP, junto a un TimeStamp o IDMessage, por lo que se recomienda incluir en la firma la cabecera de WS-Addressing. En entornos cerrados también se puede emplear SSL para transmitir los mensajes con Tokens de forma segura, aunque esta aproximación es menos segura que la anterior.

Autorización

La autorización resulta necesaria para efectuar un control sobre el acceso a los recursos. Una vez se ha realizado la autenticación sobre el participante y se conoce su identidad, se utilizarán los mecanismos de autorización para realizar las comprobaciones pertinentes y asegurar el acceso adecuado al recurso por parte del participante.

Se crean políticas que determinan los privilegios de los participantes. Mediante la gestión de la confianza, se permite la interacción entre un solicitante y un proveedor sin referencias previas pero que atendiendo a las credenciales que se intercambian determinen un nivel de confianza asumible por ambos. De esta manera se permite un proceso de autenticación sin que haya existido la necesidad de desvelar las identidades de los participantes en el proceso

Integridad y confidencialidad de los datos

El proceso que mantiene la integridad de los datos, garantiza que la información que se ha enviada no ha sufrido ninguna transformación sin que se haya detectado. La confidencialidad, asegura los principios de intimidad de la información. Es decir solo se permite el acceso a la información a aquellos participantes con permisos para hacerlo. Con frecuencia, se usan técnicas de cifrado para conceptos de confidencialidad y la firma digital para temas de integridad.

No repudio

El objeto de las técnicas de no repudio ya se han comentado anteriormente, es registrar la participación y el grado de la misma de los diferentes interlocutores en una transacción para protegerlo de una posible denegación, posiblemente por parte de algún interlocutor de la misma, negando de que la transacción ocurrió o de su participación en la misma.

Las técnicas de no repudio permiten proporcionar evidencias sobre lo sucedido en la transacción, de manera que una tercera parte resuelve el desacuerdo producido.

Para garantizar el no repudio dentro de las comunicaciones por Servicios Webs, los mensajes SOAPs intercambiados deberán ser identificados de forma única mediante el uso de la especificación WS-Addressing. Los mensajes SOAP junto a sus cabeceras "relevantes", deberán ser firmadas según los procedimientos recogidos en la especificación WS-Security. Por último, los mensajes deberán ser almacenados en ficheros de logs, para su posterior consulta.

Rastreabilidad

Es necesario ajustar trazas que aseguren poder conocer información del acceso una vez se haya producido este, y comprobar el comportamiento que ha tenido el usuario que ha realizado el acceso. Son de especial importancia para verificar la integridad del sistema. Normalmente las trazas las generen los determinados "agentes de auditoria" que pueden realizar monitoreo, observar recursos y el comportamiento de otros agentes, y validar el cumplimiento de las políticas establecidas. Con frecuencia , no es posible prevenir la violación de las diferentes obligaciones pero si un agente de auditoria detecta una brecha podría activar un plan de repulsa o determinar otro tipo de actividades.

Aplicación distribuida de las políticas de seguridad

Si se han definido arquitecturas que están basadas en Servicios Web, están deben permitir la definición de políticas de seguridad y comprobar su cumplimiento en las diversas plataformas y con las diversas variaciones de acceso al servicio.

Uso de políticas

Los mensajes que se envían en la comunicación de los servicios Web atraviesan los cortafuegos y pueden ser modificados a través de los diferentes puertos y protocolos existentes. Es necesario, para asegurar la calidad de seguridad en los servicios Web, crear políticas corporativas para integrarse con las diversas políticas de los proveedores y con la gestión de la confianza planificada.

Políticas distribuidas

Con frecuencia, se asocian las políticas de seguridad a los proveedores o a los clientes o a un mecanismo de descubrimiento. Se utilizan para controlar y definir la metodología de acceso de las peticiones y las respuestas a las mismas, dadas por los involucrados en la comunicación. Estas políticas son validadas en ejecución dentro del contexto de la comunicación. Cada parte involucrada debe realizar la validación de sus políticas.

Políticas de confianza

Defiendo de manera simple una política de confianza como una política distribuida que asegura a dos entidades que afrontan una interacción sin conocerse previamente. Mediante el uso de credenciales, asumen el nivel de seguridad que pueden soportar. En ocasiones, la definición de estas políticas implica a terceras entidades de forma recursiva, que influyen en la decisión. Un ejemplo, "yo confió en esta entidad, si mis dos compañeros confían en ti y tu confías en mis dos compañeros"

Mecanismo de Descubrimiento Seguro

El mecanismo de descubrimiento seguro controla las publicaciones y apariciones de un servicio. Cuando aparece un servicio, es necesario realizar una evaluación de las políticas de publicación del servicio, exceptuando las situaciones que supongan un servicio de descubrimiento entre nodos. Si el descubrimiento lo realiza un cliente, puede dotar de identidad o no dársela al servicio. En esta segunda situación hablamos de un descubrimiento anónimo.

Confianza y Descubrimiento

Si imaginamos una situación donde un cliente descubre que existe un servicio Web muy necesario para él, y el proveedor del mismo, es una entidad desconocida hay que preguntarse que nivel de confianza puede otorgar el solicitante a ese servicio. Esta situación es especialmente importante en el caso que se este manejando información muy sensible, ya que se esta corrigiendo un riesgo grave.

Privacidad

La privacidad se expresa mediante las diferentes políticas definidas por los diferentes propietarios de los datos. Con frecuencia, los propietarios son los usuarios de los servicios Web. Es necesario asegurar que los privilegios y derechos de los usuarios son respetados

Fiabilidad de los servicios Web

La aparición de errores es inevitable, especialmente si consideramos que el contexto engloba a multitud de servicios interconectados por una red global que pertenecen a todo tipo de personas y entidades. La eliminación de errores no puede ser completa, así que el objetivo principal es reducir la tasa de errores que aparecen al nivel máximo posible.

Si hablamos de fiabilidad dentro de los servicios Web, podemos realizar una clasificación en función de la predecibilidad y la fiabilidad de:

• Los servicios de la infraestructura, como un mecanismo de transporte de los mensajes o un servicio de descubrimiento.
• Las interacciones entre los servicios.
• El comportamiento individual del solicitante y del proveedor.

Amenazas de seguridad

Si analizamos el concepto de amenaza de seguridad, tendemos a asumir que existirá un intento de acceso y mal uso de los servicios. Por lo tanto hay que realizar un esfuerzo para controlar los accesos no permitidos. Si realizamos una clasificación de las principales amenazas, tenemos lo siguiente:

• Acceso no permitido llevado a cabo por entidades sin identificar. Es necesario poder identificar de forma confiable la identidad de proveedores, servicios, etc...
• Alteración de la información en el canal de comunicación. Es necesario garantizar la integridad de la información que se envía.
• Debe asegurarse el acceso a la información. Solo pueden acceder las partes deseadas. Debe de mantenerse una certeza del contenido y de que la comunicación tuvo lugar.
• El acceso inapropiado a los recursos. Debería ser posible garantizar que los recursos y las acciones no son accesibles por aquellas partes que no están autorizadas. De nuevo, este hecho se podría extender al mero conocimiento de que cierto recurso existe, es decir, de alguna forma se debería poder impedir que personas no autorizadas no puedan conocer la existencia de ciertos recursos o ciertos servicios.
• Denegación de servicio. No debería ser posible que los clientes de los servicios no puedan acceder a él.

Tipos de ataques

Los tipos de ataques que se listan a continuación están extraídos de la especificación W3C.

Alteración de los mensajes

Es un tipo de ataque centrado sobre la integridad de los mensajes. Se busca modificar el contenido del mensaje (ya sea parcialmente o totalmente). En el caso que el atacante tuviera controlado un canal de comunicaciones entre servicios podría modificar los mismos, eliminarlos, capturarlos y reenviarlos.

La integridad de los mensajes se proporciona mediante la firma digital del fichero XML junto con tokens de seguridad para asegurar que el mensaje es transmitido sin modificaciones. El mecanismo de integridad está diseñado para soportar múltiples firmas por diferentes actores y se puede extender para soportar nuevos mecanismo de firma. Integrando XMLSignature, según lo establecido por la especificación WS-Security se minimiza la repercusión de estos ataques.

Ataques a la confidencialidad

Centrados en la captación de la información contenida dentro de los mensajes. En ocasiones puede existir información muy sensible (datos médicos, datos económicos, etc...)

Hombre en el medio o ‘man- in-the-middle.

Es la infiltración por parte de un atacante entre los participantes de una comunicación. Normalmente, intercepta la comunicación y suplanta a los participantes de manera que estos creen que se comunican entre si cuando lo hacen con el atacante.

La posibilidad de un ataque de intermediario sigue siendo un problema potencial de seguridad serio, incluso para muchos sistemas criptográficos basados en clave pública. Existen varios tipos de defensa contra estos ataques que emplean técnicas de autenticación basadas en:

• Claves públicas
• Autenticación mutua fuerte
• Claves secretas (secretos con alta entropía)
• Passwords (secretos con baja entropía)
• Otros criterios, como el reconocimiento de voz u otras características biométricas

La integridad de las claves públicas debe asegurarse de alguna manera, pero éstas no exigen ser secretas, mientras que los passwords y las claves de secreto compartido tienen el requerimiento adicional de la confidencialidad. Las claves públicas pueden ser verificadas por una autoridad de certificación (CA), cuya clave pública sea distribuida a través de un canal seguro (por ejemplo, integrada en el navegador web o en la instalación del sistema operativo).

Suplantación de identidad (Spoofing)

Es un ataque orientado a los niveles de confianza que se establecen en la comunicación. El atacante suplanta la identidad de uno de los participantes en una relación de confianza, usualmente trata de comprometer al destinatario de la comunicación. Es muy útil utilizar una robusta autenticación para fortalecer el servicio ante estos ataques.

Para evitar ataques de spoofing exitosos contra nuestros sistemas podemos tomar diferentes medidas preventivas; en primer lugar, parece evidente que una gran ayuda es reforzar la secuencia de predicción de números de secuencia TCP. Otra medida sencilla es eliminar las relaciones de confianza basadas en la dirección IP o el nombre de las máquinas, sustituyéndolas por relaciones basadas en claves criptográficas; el cifrado y el filtrado de las conexiones que pueden aceptar nuestras máquinas también son unas medidas de seguridad importantes de cara a evitar el spoofing.

Denegación de servicio

El objetivo es mantener un servicio activo para que los usuarios legítimos puedan acceder a él. Los ataques se centran en destruir la disponibilidad de un servicio. Su objetivo es interrumpir las operaciones de un servicio dejándolo desconectado.

Es necesario adaptar la configuración del servidor a las necesidades de autenticación, seguir recomendaciones con respecto al tamaño de mensajes aceptadas, controlar la distribución de mensajes para minimizar este tipo de ataques.

Ataque de repetición

En este caso un atacante es capaz de interceptar un mensaje válido pudiendo reenviarlo más tarde todas las veces que quiera al servicio para el que era destinatario. Para poder solventar este problema se deben utilizar técnicas de autenticación apropiadas conjuntamente con técnicas de sellado de tiempos y números de secuencia.

Estándares y frameworks actuales que abordan la seguridad en servicios web

El esquema del que parte la estructura de los servicios Web, tiene unas características propias de acceso a la información, sobre el intercambio de la misma, sobre la autonomía de la información que difieren de lo establecido en los modelos de seguridad tradicionales. De hecho, esto provoca la necesidad y el desafío de modificar mecanismos que afectan a la integridad y confidencialidad de la información que es enviada por el canal del servicio Web. Si analizamos la estructura de los sistemas de seguridad perimetrales (cortafuegos , sistemas anti-intrusos) no están preparados para asegurar arquitecturas SOA. Estas arquitecturas son eminentemente dinámicas y son transmitidas a través de protocolos no asegurados como HTTP. Si aplicamos criterios que controlan la comunicación punto a punto (TLS,SSL), no son validos para porque no aseguran la aplicación completa.

El procesamiento de SOA se basa en comunicaciones basadas en mensajes SOAP y documentos XML. Es necesario asegurar transmisiones a través de una infraestructura de conectividad. Los estándares que se están desarrollando por W3C y otras organismos, basados en XML, tratan de asegurar la confidencialidad, integridad y disponibilidad de los Servicios Web. Estas especificaciones dotan de mecanismos para cifrar, firmar digitalmente, autenticar y certificar documentos XML. A continuación vamos a ofrecer una breve descripción de los mas significativos:

XML Digital Signature

Establecido por W3C, tiene como objetivo crear una serie de mecanismos que permitan la creación y manejo de firmas digitales basadas en el lenguaje XML. XML Signature, es el estándar de firmado desarrollado para establecer un esquema que permite interpretar el resultado obtenido de las firmas digitales y aplicarlas sobre los datos. Dentro del esquema se contempla la integridad de los datos, el no repudio de las transacciones y criterios de autenticación sobre la transmisión

XML Signature permite firmar parcialmente el código XML y no obliga a que la firma se aplique a la totalidad de un documento, además permite firmar diferentes tipos de recursos dentro de estos fragmentos de código, como datos XHTML, datos en formatos binarios y datos en formatos en XML nativo. La validación de la firma requiere que el objeto que fue firmado sea accesible. La firma XML indica la localización del objeto original firmado, estas localizaciones pueden ser referenciadas por una URI con la firma XML.

XML Encryption

Presenta un framework para cifrar documentos XML. En el siguiente ejemplo se muestra cómo usar este estándar con llaves simétricas. Un ejemplo de código sin firmar sería:

<?Xml version=’1.0’?>
<Metodopago xmlns=’http://madeja/ejemplo”>
  <Nombre>Desarrollador</Nombre>
    <CreditCard Limite=’10000’ Moneda=’EU’>
      <Numero>222 111 333 444</Numero>
      <Issuer>BanJuntaAndalucia</Issuer>
    <Caducidad>10/10</Caducidad>
  </CreditCard>
</Metodopago>

XML Key Management

Esta orientado a la obtención de información acerca de claves y certificados. Permite manejar los procesos de registro y revocación del servicio. Mediante el uso de este protocolo se puede intercambiar y registrar claves públicas. Esta compuesto de dos elementos importantes: la información (X-KISS) y el registro (X-RKSS) de la clave pública. Se definen los dos estándares como:

• XML Key Information Service Specification (X-KISS). Tiene como objetivo crear protocolos para el procesamiento de la información asociada a las claves de una firma XML y el contenido de las claves , ya sean públicas o privadas, de los datos.
• XML Key Registration Service Specification (X-KRSS). Esta especificación esta dirigida a registrar un conjunto de claves que permiten realizar gestiones sobre la arquitectura pública y privada. Su objetivo primordial, es ofrecer una gestión global de los procesos de intercambio de claves.

OASIS Security Service TC-SAML (Security Authorization Markup Language)

SAML es un derivado de XML que está diseñado para el intercambio de autenticación y autorización de datos. Este framework facilita infraestructuras de llave pública, que permiten realizar intercambios de autenticaciones y autorizaciones. Tiene como objetivo principal crear un conjunto de procesos que permitan realizar ,de forma segura , un canje de los datos relacionados con la identidad y privilegios de los usuarios. Esta información de seguridad se materializa en forma de afirmaciones hechas por una autoridad SAML sobre un sujeto. El sujeto de una afirmación es aquella entidad objeto de las afirmaciones realizadas por la autoridad SAML.

Las afirmaciones, contienen varios tipos de información. Pueden informar acerca de la autenticación, sobre atributo, o sobre decisiones de autorización. Analizando el tipo de declaraciones que pueden emitirse, pueden definirse tres tipos de autoridades como son: Autoridad de Autenticación, Autoridad de Atributos y Puntos de Decisión de Políticas.

Afirmaciones SAML

Las afirmaciones SAML suelen ser transferidas por los proveedores de identidad a los proveedores de servicios. Las afirmaciones contienen declaraciones que los proveedores de servicios utilizan para tomar decisiones de control de acceso. Tres tipos de declaraciones son proporcionados por SAML:

• Las declaraciones de autenticación de afirmar que el proveedor de servicios que efectivamente se autenticó con el proveedor de identidad en un momento dado con un método de autenticación.
• Una declaración de atributo afirma que un sujeto se asocia con ciertos atributos. Un atributo es simplemente un par nombre-valor. Partes que confían en utilizar los atributos para tomar decisiones de control de acceso.
• Una la declaración de decisión de autorizar afirma que un sujeto se le permite realizar una acción en un recurso presentado pruebas para ello. La expresividad de los estados decisión de autorización en SAML se limita deliberadamente.

Una afirmación esta compuesta de una o varias declaraciones. A continuación se debe definir la información que contiene las declaraciones mediante uno o varios de entre los siguientes elementos:

• Statement: una declaración realizada mediante una extensión al esquema.
• SubjectStatement: una declaración del sujeto de la afirmación realizada mediante una extensión del esquema.
• AuthenticationStatement: una afirmación de autenticación.
• AuthorizationDecisionStatement: una afirmación que contiene la información relacionada con la decisión resultado de una evaluación de autorización.
• AttributeStatement: una afirmación que contiene información de los atributos del sujeto en favor del cual se está emitiendo la aseveración.

XML Advanced Electronic Signatures (XAdES)

Es un estándar del W3C y propuesto por el ETSI europeo. XADES define un estándar de firma de documentos basado en XML con:

• Soporte a múltiples CA's
• Soporte a múltiples documentos
• Soporte a documentos complejos
• Soporte a múltiples formatos de documentos
• Soporte a múltiples firmas en tiempos distintos.
• Soporte a time-stamping en tiempos distintos

XAdES define seis perfiles (formas) según el nivel de protección ofrecido. Cada perfil incluye y extiende al previo:

• XAdES-BES, forma básica que simplemente cumple los requisitos legales de la Directiva para firma electrónica avanzada,
• XAdES-EPES, forma básica a la que se la ha añadido información sobre la política de firma,
• XAdES-T (timestamp), añade un campo de sellado de tiempo para proteger contra el repudio,
• XAdES-C (complete), añade referencias a datos de verificación (certificados y listas de revocación) a los documentos firmados para permitir verificación y validación off-line en el futuro (pero no almacena los datos en sí mismos),
• XAdES-X (extended), añade sellos de tiempo a las referencias introducidas por XAdES-C para evitar que pueda verse comprometida en el futuro una cadena de certificados,
• XAdES-X-L (extended long-term), añade los propios certificados y listas de revocación a los documentos firmados para permitir la verificación en el futuro incluso si las fuentes originales (de consulta de certificados o de las listas de revocación) no estuvieran ya disponibles,
• XAdES-A (archivado), añade la posibilidad de timestamping periódico (por ej. cada año) de documentos archivados para prevenir que puedan ser comprometidos debido a la debilidad de la firma durante un periodo largo de almacenamiento.

Platform for Privacy Preferences (P3P)

Es una especificación propuesta por el consorcio de W3C con el objetivo claro de indicar la política de privacidad de los participantes de manera estandarizada. En esta especificación se ha definido una forma de interpretar la información referente a la privacidad. En el si incluye una recomendación para la creación de un conjunto de ficheros destinados al manejo de políticas.

Ventajas de P3P

• P3P sirve para desarrollar herramientas y servicios que ofrezcan a los usuarios un mayor control sobre la información personal que se maneja en Internet y, al mismo tiempo, aumentar la confianza entre los servicios Web y los usuarios.
• P3P mejora el control del usuario al colocar políticas de privacidad donde los usuarios pueden encontrarlas, en un formato en el que los usuarios pueden entender y, lo más importante, con la posibilidad de que el usuario actúe sobre lo que ven.
• En conclusión, P3P proporciona a los usuarios Web facilidad y regularidad a la hora de decidir si quieren o no, y bajo qué circunstancia, revelar información personal.

Como funciona P3P

P3P permite a los sitios Web trasladar sus prácticas de privacidad a un formato estandarizado y procesable por dispositivos (basado en XML) que puede ser recuperado de forma automática y que además puede ser interpretado fácilmente por los navegadores de los usuarios.

Una vez completada una simple configuración del servidor, el sitio Web informará automáticamente a los visitantes de la página que ese sitio Web es compatible con P3P. En el lado del usuario, P3P automáticamente busca y lee las políticas de privacidad del sitio Web. Un navegador equipado para utilizar P3P puede comprobar una política de privacidad de un sitio Web e informar al usuario sobre las prácticas de información de ese sitio. El navegador puede entonces comparar automáticamente la declaración con las preferencias de privacidad del usuario, pautas reguladoras u otra variedad de estándares legales desde todo el mundo

XACML (eXtensible Authorization Markup Language)

Se define XACML como un estándar basado en la especificación XML, que tiene como objetivo principal la definición de un lenguaje que facilite la definición de la autorización. Es decir, un lenguaje que pueda realizar especificaciones y definiciones sobre políticas de acceso. XACML, es el encargado de crear un modelo para el intercambio de información de autorización, así como de almacenar y estructurar el citado almacenamiento de dicha información. A partir del citado modelo se estandariza una base de comportamiento, pero se le dota de la flexibilidad necesaria para permitir a los diferentes sistemas que manifiesten sus políticas de autorización. Así, por ejemplo, algunos sistemas basaran sus políticas en usuarios, perfiles y páginas permitidas, mientras que otros los basaran en terminales, transacciones y tipos de producto XACML presenta dos esquemas:

• Un esquema para los mensajes de autorización:Este esquema define la estructura del mensaje XML para un pedido de autorización (request), así como la estructura del mensaje de respuesta (response), el cual indica si la autorización se concede o no.
• Un esquema para expresar las políticas de acceso: definiendo la estructura XML de las políticas de acceso. Las políticas son la unidad básica que expresa quién puede hacer qué y bajo qué circunstancias o contexto.

Ventajas del uso de XACML

• Un lenguaje unificado puede reemplazar varios lenguajes propietarios, simplificando la administración de políticas y control de acceso.
  • No es necesario capacitarse en distintas herramientas o lenguajes.
  • Se reduce el impacto de volver a escribir las políticas de acceso al reemplazar un sistema (por ejemplo, si un conjunto de aplicaciones se migran a un nuevo servidor Web, y tanto el servidor anterior como el nuevo basan su estructura de control de acceso en XACML, el esfuerzo de reescritura de las políticas será considerablemente menor al necesario si ambos sistemas utilizaran estructuras incompatibles).
  • Cuando se implementa un nuevo sistema de autorización, los diseñadores no necesitarán pensar desde cero un lenguaje nuevo e implementar herramientas de configuración: pueden reutilizar código existente.
• Será posible desarrollar herramientas amigables para escribir y administrar las diferentes políticas XACML.Dado que XACML define un lenguaje común basado en XML, el desarrollo de herramientas que trabajen con este lenguaje será mucho más atractivo, ya que las mismas podrán utilizarse en cualquier contexto donde exista uno o más sistemas que trabajen con políticas XACML.
• La existencia de este lenguaje común también introduce oportunidades para desarrollar adaptadores y traductores. Por ejemplo, una herramienta que permita exportar una base de datos con información de roles y usuarios en estructuras XML compatibles con XACML, las cuáles podrán luego ser consumidas por cualquier implementación XACML.
• XACML es lo suficientemente flexible para resolver las necesidades más comunes de información de autorización.
• Los mecanismos de extensibilidad de XACML permiten acomodar nuevas necesidades a medida que sean necesarias, con impacto mínimo en los sistemas ya implementados.
• XACML permite utilizar escenarios centralizados o descentralizados.
  • En un escenario centralizado, un conjunto de políticas único se utiliza para referirse al control de acceso sobre distintos tipos de recursos.
  • En un escenario descentralizado, distintos puntos de control utilizan distintas políticas y repositorios XACML. La utilización de XACML permite que algunas políticas «apunten» a otras. Por ejemplo, una política aplicada a un dominio de baja jerarquía puede combinarse con otra de mayor jerarquía. Un caso típico es cómo una política departamental hereda lo definido en una política organizacional.

Aspectos no cubiertos

XACML es un lenguaje muy centrado en la autorización, por tanto, deja aspectos sin considerar que deben tenerse en cuenta cuando se realiza la implementación de los aspectos relacionados con la autorización. Por ejemplo:

• Almacenamiento de las políticas de autorización: Definir donde se almacenan las diferentes políticas de autorización.
• Mantenimiento: Definir como y quien podrá actualizar sus políticas de acceso.
• Requerimientos de disponibilidad, tolerancia a fallos y escalabilidad.