Unidad
6 Servicios WEB
6.1
Conceptos generales
Un servicio web (en inglés,
Web services) es una tecnología que utiliza un conjunto de protocolos y
estándares que sirven para intercambiar datos entre
aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de computadoras como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y
reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I,
encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Es una máquina que atiende las peticiones de los clientes web y les envía los recursos solicitados.
aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de computadoras como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y
reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I,
encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Es una máquina que atiende las peticiones de los clientes web y les envía los recursos solicitados.
Ventajas de los servicios web
Aportan interoperabilidad
entre aplicaciones de software independientemente de sus propiedades o de las
plataformas sobre las que se instalen.
Los servicios Web fomentan los
estándares y protocolos basados en texto, que hacen más fácil acceder a su
contenido y entender su funcionamiento.
Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.
Inconvenientes de los servicios Web
Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.
Inconvenientes de los servicios Web
Para realizar transacciones no
pueden compararse en su grado de desarrollo con los estándares abiertos de
computación distribuida como CORBA (Common Object Request Broker Architecture).
Su rendimiento es bajo si se compara con otros modelos de computación
distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM
(Distributed Component Object Model). Es uno de los inconvenientes derivados de
adoptar un formato basado en texto. Y es que entre los objetivos de XML no se
encuentra la concisión ni la eficacia de procesamiento. Al apoyarse en HTTP, pueden
esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de
bloquear o auditar la comunicación entre programas a ambos lados de la barrera.
Razones para crear servicios
Web
La principal razón para usar
servicios Web es que se pueden utilizar con HTTP sobre TC (Transmission Control
Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes
mediante firewalls -que filtran y bloquean gran parte del tráfico de Internet-,
cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que
usan los navegadores. Los servicios Web utilizan este puerto, por la simple
razón de que no resultan bloqueados. Es importante señalar que los servicios
web se pueden utilizar sobre cualquier protocolo, sin embargo, TCP es el más
común.
Otra razón es que, antes de
que existiera SOAP, no había buenas interfaces para acceder a las
funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco
conocidas, tales como EDI (Electronic Data Interchange), RPC (Remote Procedure
Call), u otras APIs.
Una tercera razón por la que
los servicios Web son muy prácticos es que pueden aportar gran independencia
entre la aplicación que usa el servicio Web y el propio servicio. De esta
forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta
flexibilidad será cada vez más importante, dado que la tendencia a construir
grandes aplicaciones a partir de componentes distribuidos más pequeños es cada
día más utilizada. Se espera que para los próximos años mejoren la calidad y
cantidad de servicios ofrecidos basados en los nuevos estándares.
Plataformas
Servidores de aplicaciones para servicios Web:
Plataformas
Servidores de aplicaciones para servicios Web:
• Oracle Fusion Middleware
• Axis y el servidor Jakarta Tomcat (de Apache)
• ColdFusion MX de [[Macromedia]httpd ]
• Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat)
• JOnAS (parte de ObjectWeb una iniciativa de código abierto)
• Microsoft .NET
• Novell exteNd (basado en la plataforma J2EE)
• WebLogic
• WebSphere
• JAX-WS con GlassFish
• Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el lenguaje de programación Python
• VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host IBM y VT
• PHP
• Axis y el servidor Jakarta Tomcat (de Apache)
• ColdFusion MX de [[Macromedia]httpd ]
• Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat)
• JOnAS (parte de ObjectWeb una iniciativa de código abierto)
• Microsoft .NET
• Novell exteNd (basado en la plataforma J2EE)
• WebLogic
• WebSphere
• JAX-WS con GlassFish
• Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el lenguaje de programación Python
• VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host IBM y VT
• PHP
6.2
Estandares
Estándares de servicio Web
Uno de los atributos clave de
estándares de Internet es que se centran en protocolos y no en
implementaciones. Internet se compone de tecnologías heterogéneas que operan
conjuntamente de modo satisfactorio mediante protocolos compartidos. Esto
impide que los proveedores individuales impongan un estándar en Internet. El
desarrollo del software de código fuente abierto desempeña un rol fundamental
para proteger la interoperatividad de implementaciones de estándares del
proveedor.
Los estándares siguientes desempeñan roles clave en servicios Web: UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language), WSIL (Web Services Inspection Language), SOAP y WS-I (Web Services Interoperability). La relación entre estos estándares se describe en la Figura 2. La especificación UDDI define estándares abiertos independientes de la plataforma que permiten a las empresas compartir información en un registro de empresa global, encontrar servicios en el registro y definir cómo actúan conjuntamente en Internet.
WSIL es una especificación abierta basada en XML que define un método de descubrimiento de servicios distribuidos que suministra referencias a descripciones de servicio en el punto de ofertas del proveedor de servicios, especificando cómo comprobar si hay servicios Web disponibles en un sitio Web. Un documento WSIL define las ubicaciones en un sitio Web donde se pueden buscar descripciones del servicio Web. Dado que WSIL se centra en el descubrimiento de servicios distribuidos, la especificación WSIL complementa UDDI facilitando el descubrimiento de servicios que están disponibles en sitios Web que quizá no se enumeren aún en un registro UDDI. En un tema aparte de esta documentación se describe la Relación entre UDDI y WSIL.
WSDL es una especificación abierta basada en XML que describe las interfaces y las instancias de servicios Web en la red. Es ampliable, de modo que se pueden describir los puntos finales independientemente de los formatos de mensaje o de los protocolos de red que se utilicen para comunicarse. Las empresas pueden poner a disposición de sus servicios Web los documentos WSDL mediante UDDI, WSIL o divulgando los URL a su WSDL mediante correo electrónico o sitios Web. WSDL se describe en un tema aparte de esta documentación.
SOAP es un estándar basado en XML para la transmisión de mensajes en HTTP y otros protocolos de Internet. Es un protocolo ligero para el intercambio de información en un entorno descentralizado y distribuido. Se basa en XML y consta de tres partes:
Los estándares siguientes desempeñan roles clave en servicios Web: UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language), WSIL (Web Services Inspection Language), SOAP y WS-I (Web Services Interoperability). La relación entre estos estándares se describe en la Figura 2. La especificación UDDI define estándares abiertos independientes de la plataforma que permiten a las empresas compartir información en un registro de empresa global, encontrar servicios en el registro y definir cómo actúan conjuntamente en Internet.
WSIL es una especificación abierta basada en XML que define un método de descubrimiento de servicios distribuidos que suministra referencias a descripciones de servicio en el punto de ofertas del proveedor de servicios, especificando cómo comprobar si hay servicios Web disponibles en un sitio Web. Un documento WSIL define las ubicaciones en un sitio Web donde se pueden buscar descripciones del servicio Web. Dado que WSIL se centra en el descubrimiento de servicios distribuidos, la especificación WSIL complementa UDDI facilitando el descubrimiento de servicios que están disponibles en sitios Web que quizá no se enumeren aún en un registro UDDI. En un tema aparte de esta documentación se describe la Relación entre UDDI y WSIL.
WSDL es una especificación abierta basada en XML que describe las interfaces y las instancias de servicios Web en la red. Es ampliable, de modo que se pueden describir los puntos finales independientemente de los formatos de mensaje o de los protocolos de red que se utilicen para comunicarse. Las empresas pueden poner a disposición de sus servicios Web los documentos WSDL mediante UDDI, WSIL o divulgando los URL a su WSDL mediante correo electrónico o sitios Web. WSDL se describe en un tema aparte de esta documentación.
SOAP es un estándar basado en XML para la transmisión de mensajes en HTTP y otros protocolos de Internet. Es un protocolo ligero para el intercambio de información en un entorno descentralizado y distribuido. Se basa en XML y consta de tres partes:
- Un sobre que define una infraestructura
para describir el contenido del mensaje y cómo procesarlo.
- Un conjunto de normas de codificación para
expresar instancias de tipos de datos definidos por la aplicación.
- Una convención para representar llamadas y
respuestas a procedimiento remoto.
SOAP permite el enlace y la
utilización de servicios Web encontrados definiendo una ruta de mensaje para el
direccionamiento de mensajes. Se puede utilizar SOAP para consultar UDDI para
servicios Web.
Figura 2. Relaciones entre
SOAP, UDDI, WSIL y WSDL.
Un proveedor de servicios
aloja un servicio Web y lo hace accesible con protocolos como SOAP/HTTP o
SOAP/JMS. El servicio Web se describe mediante un documento WSDL que se
almacena en el servidor del proveedor o en un depósito especial. UDDI Business
Registry y sus documentos WSDL pueden hacer referencia al documento WSDL. Estos
contienen punteros a los archivos WSDL del servicio Web.
Los perfiles WS-I Simple SOAP
Binding Profile y WS-I Attachments Profile son esquemas de requisitos que el
tráfico de WSDL y de protocolo de servicio Web (SOAP/HTTP) deben cumplir para
afirmar la conformidad WS-I. Las herramientas de validación WS-I de servicios
Web admiten actualmente WS-I Simple SOAP Binding Profile 1.0 y Attachment
Profile 1.0.
Productos de Rational Developer también admiten varios estándares nuevos de servicios Web. Éstas son:
Productos de Rational Developer también admiten varios estándares nuevos de servicios Web. Éstas son:
JAX-RPC
JAX-RPC son las siglas de Java
API for XML-based RPC (API de Java para RPC basado en XML), también conocido
como JSR 101. Es una especificación que describe las interfaces de programación
de aplicaciones (API) de Java y las convenciones para crear servicios Web y
clientes de servicio Web que utilizan RPC (llamadas a procedimiento remoto) y
XML. Estandariza las correlaciones de Java con WSDL y de WSDL con Java,
asimismo proporciona las API principales para el desarrollo de servicios Web y
clientes de servicio Web en la plataforma Java.
JSR-109 y JSR-921
JSR-109 y JSR-921
(implementación de Enterprise Web Services) definen el modelo de programación y
la arquitectura de ejecución para desplegar y buscar servicios Web en el
entorno J2EE; más específicamente, en los contenedores Web, EJB y de
aplicaciones cliente. Uno de los objetivos principales es asegurar que las
implementaciones operen conjuntamente.
WS-S
Estas herramientas admiten el
estándar OASIS Web Services Security 1.0.
Las herramientas de servicios
Web admiten las siguientes especificaciones:
- WSDL (Web Services Description Language)
WSDL (Web Services Description Language) es una especificación estándar para describir servicios basados en XML de red. Proporciona a los proveedores de servicios un modo sencillo de describir el formato básico de las peticiones a sus sistemas independientemente de la implementación del motor de ejecución subyacente. - SOAP
SOAP (anteriormente conocido como Simple Object Access Protocol) es un protocolo ligero para el intercambio de información en entornos descentralizados y distribuidos. Los mensajes SOAP son las transmisiones de información de remitentes a destinatarios. Los mensajes SOAP se pueden combinar para crear patrones de petición/respuesta. - UDDI (Universal Description, Discovery,
and Integration)
- WSIL (Web Services Inspection Language)
WSIL (Web Services Inspection Language) es un mecanismo de descubrimiento de servicios que es una alternativa a UDDI además de ser complementario a UDDI. Cuando encuentra servicios Web con UDDI, se dirige a un registro centralizado. WSIL es un método alternativo al descubrimiento de servicios Web. WSIL le permite dirigirse directamente al proveedor de servicios y solicitar los servicios que proporciona. - JAX-RPC
JAX-RPC son las siglas de Java API for XML-based RPC (API de Java para RPC basado en XML), también conocido como JSR 101. Es una especificación que describe las interfaces de programación de aplicaciones (API) de Java y las convenciones para crear servicios Web y clientes de servicio Web que utilizan RPC (llamadas a procedimiento remoto) y XML. Estandariza las correlaciones de Java con WSDL y de WSDL con Java, asimismo proporciona las API principales para el desarrollo de servicios Web y clientes de servicio Web en la plataforma Java. El mecanismo de RPC, a menudo utilizado en modelos de cliente/servidor distribuido, permite que los clientes ejecuten procedimientos en otros sistemas. - JSR 109 y JSR 921: implementación de
servicios Web de empresa
JSR 109 y JSR 921 (implementación de servicios Web de empresa) definen el modelo de programación y la arquitectura de ejecución para desplegar y buscar servicios Web en el entorno J2EE; más específicamente, en los contenedores Web, EJB y de aplicaciones cliente. Uno de los objetivos principales es asegurar que las implementaciones operen conjuntamente.
6.3
Seguridad e interoperabilidad
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.
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
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.
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:
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.
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:
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.
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.
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.
Interoperabilidad
La interoperabilidad entre los
servicio web de ASP.NET y los servicio web de Windows Communication Foundation
(WCF) se puede lograr asegurando que los servicios implementados usen ambas
tecnologías de acuerdo con la especificación WS-I Basic Profile 1.1. Los
servicio web de ASP.NET que cumplen con WS-I Basic Profile 1.1 son
interoperables con clientes de WCF mediante el uso de enlace proporcionado por
el sistema de WCF, BasicHttpBinding.
Utilice la opción de ASP.NET 2.0 de agregar los atributos WebService y WebMethodAttribute a una interfaz en lugar de a una clase y escribir una clase para implementar la interfaz, como se muestra en el siguiente código de ejemplo.
Utilice la opción de ASP.NET 2.0 de agregar los atributos WebService y WebMethodAttribute a una interfaz en lugar de a una clase y escribir una clase para implementar la interfaz, como se muestra en el siguiente código de ejemplo.
[WebService]
public interface IEcho
{
[WebMethod]
string Echo(string input);
}
public class Service : IEcho
{
public string Echo(string input)
{
return input;
}
}
El uso de esta opción es
preferible, porque la interfaz con el atributo WebService constituye un
contrato para las operaciones realizadas por el servicio, que puede
reutilizarse con diferentes clases que podrían implementar ese mismo contrato
de distintas maneras.
Evite usar el atributo SoapDocumentServiceAttribute para que los mensajes se enruten a métodos en función del nombre completo del elemento de cuerpo del mensaje SOAP en lugar del encabezado HTTP SOAPAction.WCF usa el encabezado HTTP SOAPAction para enrutar mensajes.
El XML en el que XmlSerializer serializa de forma predeterminada un tipo es semánticamente idéntico al XML en el que DataContractSerializer serializa un tipo, dando por hecho que el espacio de nombres para el XML se define explícitamente.Cuando defina un tipo de datos para su uso con los servicios web de ASP.NETy en previsión de que se adoptará WCF, haga lo siguiente:
Evite usar el atributo SoapDocumentServiceAttribute para que los mensajes se enruten a métodos en función del nombre completo del elemento de cuerpo del mensaje SOAP en lugar del encabezado HTTP SOAPAction.WCF usa el encabezado HTTP SOAPAction para enrutar mensajes.
El XML en el que XmlSerializer serializa de forma predeterminada un tipo es semánticamente idéntico al XML en el que DataContractSerializer serializa un tipo, dando por hecho que el espacio de nombres para el XML se define explícitamente.Cuando defina un tipo de datos para su uso con los servicios web de ASP.NETy en previsión de que se adoptará WCF, haga lo siguiente:
- Defina el tipo mediante las clases de .NET
Framework en lugar de mediante el Esquema XML.
- Agregue solo SerializableAttribute y
XmlRootAttribute a la clase, utilizando el último para definir
explícitamente el espacio de nombres del tipo.No agregue atributos
adicionales del espacio de nombres System.Xml.Serialization para controlar
cómo se traducirá la clase de .NET Framework a XML.
- Mediante el uso de este enfoque, debería
ser capaz de convertir más adelante las clases .NET en contratos de datos
agregando DataContractAttribute y DataMemberAttribute sin modificar
significativamente el XML en el que las clases se serializan para la
transmisión.Los tipos utilizados en los mensajes por los servicios web de
ASP.NET se pueden procesar como contratos de datos a través de
aplicaciones WCF, lo que produce, entre otras ventajas, un mejor
rendimiento en las aplicaciones WCF.
Evite usar las opciones de
autenticación proporcionadas por Internet Information Services (IIS).Los clientes
de WCF no las admiten.Si es necesario proteger un servicio, utilice las
opciones proporcionadas por WCF, porque estas opciones son robustas y se basan
en protocolos estándar.
Repercusión en el rendimiento
de la carga de ServiceModel HttpModule
En .NET Framework 3.0, se
instaló el HttpModule de WCF en el archivo raíz Web.config, de modo
que cada aplicación ASP.NET sea compatible con WCF. Esto puede afectar al
rendimiento, por lo que es posible quitar ServiceModel del archivo
Web.config, como se muestra en el siguiente ejemplo.
<httpModules>
<remove name=”ServiceModel” />
<httpModules/>
