Cada vez más nodos comentan el
problema que se presenta debido a la dualidad de protocolos en uso, http y
https. La verdad es que ha llegado el momento de recomendar que todos los
servicios estén preparados para responder según ambos protocolos, aunque usar el
http seguro (https) no represente muchas ventajas prácticas para los geoservicios.
Es un protocolo seguro pensado fundamentalmente para entornos bancarios, de e-administración y casos muy especiales, en los que es importante que no sea posible suplantar la identidad de nadie. Ofrece la ventaja adicional de encriptar los datos que se transfieren para impedir que nadie pueda interceptarlos y utilizarlos. Eso puede ser relevante en procedimientos administrativos que deben ser realizados por una persona bien identificada y autenticada, en los que además intervenga una cartografía, como trámites relacionados con el catastro, el registro de la propiedad, solicitudes acompañadas de un plano…
En cualquier caso, cada vez más organizaciones adoptan ese protocolo por defecto como política general de actuación, por ser más seguro, y debemos estar preparados para dar respuesta. Implementar https sobre la infraestructura propia de un nodo no es difícil, pero puede suponer una importante sobrecarga. Para solucionarlo hay varios servicios de Content Delivery Network (Red de entrega de contenidos) que ofrecen como servicio el facilitar que un nodo de respuesta a ambos tipos de petición.
Las Content Delivery Networks (CDN) sirven para prestar el servicio de publicar contenidos con alto rendimiento y disponibilidad, ahora mismo nos proporcionan una buena parte de la información que nos llega por Internet (textos, gráficos, scripts, aplicaciones, documentos, streaming…) y aunque hay intentos de CDN P2P, la mayoría de los proveedores son de pago. Creo que cualquiera de ellos puede solucionar el problema de que nuestro nodo responda a los dos protocolos.
Otro aspecto de la cuestión es el que nos ha contado nuestro compañero de IDERioja, Gonzalo López. En este caso es el propio Gobierno de La Rioja quien ha decidido adoptar la política de utilizar el protocolo https, como tantas organizaciones por motivos de seguridad. En consecuencia, sus propias páginas no admitían componentes no seguros y se han visto obligadas a publicar servicios https y en principio, no admitían peticiones http.
Han tenido que redireccionar las peticiones http que les llegaban y entonces han comprobado que algunos visualizadores ligeros y pesados no admitían la respuesta https, por lo que han tenido que arbitrar la solución de desdoblar los servicios atendiendo tanto peticiones http como https por canales diferentes. No ha sido técnicamente excesivamente complicado y lo han hecho ellos mismos, sin contar con una CDN.
En resumen, que es fácil de solucionar, de un modo u otro, muy pocos nodos de la IDEE lo han tenido en cuenta hasta ahora (solo he encontrado tres nodos nacionales y autonómicos de una muestra de veintidós que respondan correctamente a una petición https) y creo que es el momento de mirar el asunto.
Salud e interoperabilidad.
Es un protocolo seguro pensado fundamentalmente para entornos bancarios, de e-administración y casos muy especiales, en los que es importante que no sea posible suplantar la identidad de nadie. Ofrece la ventaja adicional de encriptar los datos que se transfieren para impedir que nadie pueda interceptarlos y utilizarlos. Eso puede ser relevante en procedimientos administrativos que deben ser realizados por una persona bien identificada y autenticada, en los que además intervenga una cartografía, como trámites relacionados con el catastro, el registro de la propiedad, solicitudes acompañadas de un plano…
En cualquier caso, cada vez más organizaciones adoptan ese protocolo por defecto como política general de actuación, por ser más seguro, y debemos estar preparados para dar respuesta. Implementar https sobre la infraestructura propia de un nodo no es difícil, pero puede suponer una importante sobrecarga. Para solucionarlo hay varios servicios de Content Delivery Network (Red de entrega de contenidos) que ofrecen como servicio el facilitar que un nodo de respuesta a ambos tipos de petición.
Las Content Delivery Networks (CDN) sirven para prestar el servicio de publicar contenidos con alto rendimiento y disponibilidad, ahora mismo nos proporcionan una buena parte de la información que nos llega por Internet (textos, gráficos, scripts, aplicaciones, documentos, streaming…) y aunque hay intentos de CDN P2P, la mayoría de los proveedores son de pago. Creo que cualquiera de ellos puede solucionar el problema de que nuestro nodo responda a los dos protocolos.
Otro aspecto de la cuestión es el que nos ha contado nuestro compañero de IDERioja, Gonzalo López. En este caso es el propio Gobierno de La Rioja quien ha decidido adoptar la política de utilizar el protocolo https, como tantas organizaciones por motivos de seguridad. En consecuencia, sus propias páginas no admitían componentes no seguros y se han visto obligadas a publicar servicios https y en principio, no admitían peticiones http.
Han tenido que redireccionar las peticiones http que les llegaban y entonces han comprobado que algunos visualizadores ligeros y pesados no admitían la respuesta https, por lo que han tenido que arbitrar la solución de desdoblar los servicios atendiendo tanto peticiones http como https por canales diferentes. No ha sido técnicamente excesivamente complicado y lo han hecho ellos mismos, sin contar con una CDN.
En resumen, que es fácil de solucionar, de un modo u otro, muy pocos nodos de la IDEE lo han tenido en cuenta hasta ahora (solo he encontrado tres nodos nacionales y autonómicos de una muestra de veintidós que respondan correctamente a una petición https) y creo que es el momento de mirar el asunto.
Salud e interoperabilidad.
Publicado por Antonio F. Rodríguez.
No hay comentarios:
Publicar un comentario