Laguna de Duero, una visión práctica de la Administración Electrónica

Laguna de Duero es una población ubicada en los alrededores de Valladolid que cuenta con más de 20.000 vecinos. Su ubicación la convierte en un núcleo de población joven con una elevada demanda servicios electrónicos.

El equipo del Ayuntamiento, consciente de esta realidad, lleva trabajando desde al año 2001 en la prestación de servicios electrónicos a través de su plataforma GeXtion@, que ha sido desarrollada a medida en función de las necesidades de las diferentes áreas de trabajo.

El diseño de la plataforma, en contraposición al enfoque de homogeneización y simplificación de procedimientos, apostó por centrarse en la gestión del documento electrónico, delegando en los empleados públicos de cada departamento la responsabilidad de ejecutar el procedimiento administrativo adecuado a cada solicitud. De esta manera, tras diez años de uso diario por parte de los empleados públicos, el Ayuntamiento dispone de un catálogo detallado de todas las gestiones que llevan a cabo. Por lo que se encuentran en el momento adecuado para aplicar procesos de simplificación y racionalización a su gestión administrativa.

El uso de la plataforma por parte del ciudadano ha demostrado ser eficaz y amigable, ya que no debe enfrentarse a extensos formularios con campos de difícil compresión. Asimismo, la reutilización de la información en poder del Ayuntamiento ha evitado la duplicación de la información y ha agilizado el tiempo de resolución de los trámites.

Las principales características de GeXtion@ son:

  • Registro de Entrada y Salida Único (presencial y electrónico)
  • Catálogo de Procedimientos basado en plantillas de Documentos Electrónicos
  • Firma electrónica de documentos acorde al ENI
  • Carpeta Ciudadana web
  • Repositorio único de información y servicios a través de modelo de agregación
    • Notificaciones Telemáticas Seguras (SNTS)
    • Envío de mensajes SMS
    • Digitalización de documentos
    • Integración con Catastro y TGSS

Actualmente el Ayuntamiento ha comenzado los trámites para la cesión gratuita de la plataforma a otros municipios a través de la Red de Municipios Digitales de Castilla y León y a través de la forja del CTT.

En mi opinión esta iniciativa supone para la administración local una oportunidad excelente para subirse al carro de la Administración Electrónica en un tiempo récord y con un presupuesto asequible. Quizá sea hora de volver a confiar en que los propios empleados públicos sean los que definan su manera de trabajar, en vez de imponerles rígidas estructuras diseñadas para encorsetar la agilidad de resolución de trámites.

ENI – Transmisión de ficheros en el esquema del Documento Electrónico

El Esquema Nacional de Interoperabilidad define en la Norma Técnica de Interoperabilidad de Documento Electrónico las especificaciones XSD para el intercambio de Documentos Electrónicos Interoperables:

Tanto en la Guía de Aplicación de la NTI Documento Electrónico como en el Manual de usuario para los esquemas XML de intercambio de documentos electrónicos y expedientes electrónicos se trata el bloque de Contenido de un documento electrónico. El fichero se puede incluir en el esquema de diferentes formas:

  • En formato XML
  • Binario codificado en base 64
  • Como referencia interna a otro punto interno de la estructura XML

La mayoría de los documentos generados en las Sedes Electrónicas son archivos PDF (binarios), por lo que la forma recomendada debería ser un binario codificado en base 64. En ambos documentos parece insinuarse que la manera de transmitir el fichero es incrustándolo en el XML SOAP codificado en base 64.

El envío del contenido de ficheros a través de servicios web empleando esta técnica presenta una serie de inconvenientes que conviene recordar:

  • El cliente debe codificar en base64 el contenido del fichero
  • El cliente debe construir en memoria una estructura XML que contiene los datos de la petición y el contenido completo del fichero
  • La petición del cliente viaja completa hasta el servidor
  • El servidor debe construir en memoria la misma estructura XML (con los datos de la petición y el contenido completo del fichero)
  • El servidor debe decodificar de base64 el contenido del fichero

Resulta evidente que este mecanismo limita el tamaño de los ficheros que pueden ser enviados a la capacidad de memoria de las máquinas y que sobrecarga el proceso al incluir la codificación y decodificación en base64.

Cómo implementar el envío de una manera eficiente

MTOM es un estándar que permite la transmisión de ficheros en tecnologías de servicios web de una manera eficiente y que está soportado tanto por WS-i como por múltiples fabricantes (Axis 2, Apache CXF, Microsoft WCF…). La utilización de este mecanismo permite enviar el contenido de los ficheros en formato binario y hacerlo en modo streaming. Gracias a estas características tanto servidor como cliente ahorran mucho tiempo de proceso (al evitar el formato base64 y la manipulación en memoria de XML) y se elimina la limitación para el tamaño del fichero que se intercambia.

Comparativa entre el envío XML base64 y el uso de MTOM

Comparativa entre el envío XML base64 y el uso de MTOM

Existen diferentes técnicas para implementar clientes y servidores que gestionen servicios web que usen MTOM, pero la única manera de garantizar la interoperabilidad entre diferentes plataformas (Java, .NET, PHP…) es utilizando el estándar WS-Policy, que permite indicar la serialización de contenidos de una manera interoperable. Dado que es posible declarar el uso de este mecanismo en el bloque de binding del WSDL, los esquemas XSD del Documento Electrónico pueden ser respetados.

Conclusiones

Las administraciones públicas deben prestar especial atención a cómo se aborda este punto por parte de su personal técnico o de las empresas de tecnología contratadas, ya que un enfoque propietario (como el basado en el “xmime:contentype” de Java) puede generar problemas de interoperabilidad entre organismos y una implementación que no soporte MTOM podría generar graves limitaciones en el intercambio de información.

Tampoco estaría de más que en la documentación suministrada por el Ministerio en relación al ENI y sus NTI, se tratase esta cuestión de una manera más profunda y detallada.

Referencias

Microsoft CodePlex – Software para asegurar compatibilidad de WCF con IBM WebSphere, Oracle WebLogic, Java Metro y Apache (Axis 2 y CXF).

Web Service Attachments Support Matrix – Estudio, aunque desactualizado, del soporte de los diferentes frameworks de servicios web para MTOM y otros mecanismos de envío de ficheros

La eficacia del hardware criptográfico para las firmas AdES-XL

La adopción de firmas AdES-XL por parte de la Administración Pública en España para sus servicios electrónicos en los diferentes formatos de firma (XAdES, CAdES y PAdES) ha sido promovida tanto por la normativa, a través del Esquema Nacional de Interoperabilidad (ENI) y del Esquema Nacional de Seguridad (ENS), como por los integradores del sector tecnológico.

Por otro lado, uno de los requisitos fundamentales para la creación de este tipo de firmas de manera reconocida es la utilización de dispositivos criptográficos hardware (HSM o hardware security module). Para ello se han puesto a disposición de los ciudadanos mecanismos como el DNI electrónico (que incluye una tarjeta de firma inteligente) y se ha dotado a los organismos públicos de módulos de firma en servidor basados en tarjetas PCI o en appliances de red.

Parece evidente constatar que la seguridad del proceso ha sido cubierta por este despliegue, ya que las claves privadas de ciudadanos y organismos públicos están bien custodiadas por los dispositivos criptográficos referidos en el párrafo anterior.

Sin embargo, he escuchado en más de una ocasión asegurar que los dispositivos criptográficos hardware para firma en servidor permiten incrementar el rendimiento del sistema de un modo drástico. Una revisión al proceso de construcción de una firma XAdES-XL quizá ayude a identificar el nivel de mejora que puede ser alcanzado con la incorporación de este tipo de soluciones hardware.

  1. La operación criptográfica de generación de la firma (RSA, por ejemplo) puede realizarse a través de dos métodos:
    1. HSM (HW). Es necesario enviar el documento al HSM, que realiza la operación criptográfica y devuelve el resultado de la firma
    2. SW. Se realiza la operación criptográfica de firma utilizando software propietario de alto rendimiento
  2. Para la construcción de la firma EPES, formato básico establecido por el ENI, es necesario descargar la política de firma de una URL externa y calcular su HASH para incorporarlo a la firma
  3. Para la construcción de la firma T es necesario solicitar a una TSA externa un sello de tiempo
  4. Para la construcción de la firma C es necesario solicitar a una CA externa la validación del certificado utilizado para la firma, por ejemplo a través de una invocación OCSP. En caso de que se quiera almacenar toda la cadena de confianza es posible que esta invocación debe realizarse más de una vez para asegurar la validez de las diferentes SubCAs.
  5. Para la construcción de la firma X es necesario solicitar un nuevo sello de tiempo a una TSA externa
  6. Finalmente, para la construcción de la firma XL es necesario realizar al menos una invocación OCSP que permita almacenar las evidencias requeridas

En cada uno de los puntos anteriores es necesario consultar con servicios externos para garantizar que la firma resultante es reconocida, ya que solo pueden ser utilizados los servicios de los prestadores de servicios de certificación reconocidos en el ámbito español.

En resumen, la creación de una firma XAdES-XL conlleva al menos la descarga de un documento externo y cuatro invocaciones a sistemas externos para recuperar sellos de tiempo y evidencias de validación. Y el tiempo de estas conexiones externas sobre el global de la operación de firma es muy superior al proceso atómico por el que un dispositivo hardware o software construye una firma básica.

Reflexión final

Si bien es cierto que los dispositivos criptográficos hardware suponen un elemento indispensable para garantizar la seguridad en el uso de un sistema, el incremento de la eficacia de dicho sistema se basa más en la optimización de la capacidad de conexiones a Autoridades de Confianza externas que en la potencia del propio HSM utilizado.