El proceso de instalación difiere ligeramente según el modelo de lector que tengamos y el sistema operativo donde queramos instalarlo. Por ello, abarcar todas las posibles combinaciones de lector y sistema operativo en un único post se antoja complicado.

Una vez dispongamos del lector la cosa no está ni mucho menos solucionada. Todavía queda instalar los controladores del lector y los controladores del propio DNIe. Es probable que podamos librarnos del paso de instalar controladores para nuestro lector si éste viene soportado por defecto en el sistema operativo, pero de instalar los drivers del DNI electrónico, a día de hoy, no hay quien nos salve.

De momento, los usuarios que más dolor nos han proyectado son los Mac-eros. Y es que la instalación en Mac OS X es un poco “tricky”. Para arrojar un poco de luz a este tema he confiscado un Mac con OS X y he realizado todo el proceso necesario para tener el DNI electrónico funcionando. Por suerte, es un proceso que la gente del DNI electrónico ha documentado bastante bien, así que seguiremos sus indicaciones para intentar llegar a buen puerto.

Descripción del entorno de trabajo

• Sistema Operativo: Mac OS X 10.5 o OS X10.4.x.
• Lector probado: LTC31 (USB) de C3PO (el que regalamos en Tractis).
• Nivel de dolor: Medio.
• Tiempo de instalación: unos 30 minutos.

Paso 1: Consigue un lector de tarjetas

El primer gran problema es hacerse con un lector de tarjetas inteligentes (o “chipetera”) donde poder utilizar el DNI electrónico. Afortunadamente, este problema cada vez lo es menos. Poco a poco, van apareciendo más lectores en el mercado y a un precio cada vez más competitivo.

Si aún no tienes un lector, mírate nuestras recomendaciones sobre donde conseguirlos.

Paso 2: Instala las librerías de OpenSC y los drivers del DNIe

Este proceso está basado en lo descrito en la documentación de instalación disponible en el portal del DNI electrónico, concretamente en el punto 3 “Instalación y configuración de sistemas Mac OS X“.

El proceso es simple, debemos bajar las librerías de OpenSC y los drivers de DNI electrónico e instalarlos en ese orden:

1. OpenSC es un conjunto de librerías para el uso de tarjetas inteligentes en ordenadores. Mac OS X ya lleva por defecto un OpenSC, pero éste no funciona demasiado bien con los drivers del DNI electrónico, así que deberemos actualizarlo. Para instalarlo debemos bajar OpenSC para OS X 10.5 o OpenSC para OS X 10.4. Esta librería se instala del mismo modo que una aplicación normal. Ejecutaremos el instalador y seguiremos los pasos que nos vaya planteando hasta que se nos informe de que la librería se ha instalado correctamente.
2. Drivers DNIe: El siguiente paso es instalar los controladores del DNI electrónico. Para ello, debemos bajarlos de aquí y también instalarlos del mismo modo que OpenSC. Cuando la instalación acabe nos pedirá reiniciar la máquina, así que le seguimos el rollo y reiniciamos.

Paso 3: Comprueba que todo está en orden

Hasta aquí está todo sacado casi de manera literal del manual del DNI electrónico. Ahora viene la parte de comprobar que todo está funcionando correctamente. Un diagnóstico rápido pero no muy fiable, son las luces del lector. Con todo instalado y la tarjeta introducida, la luz del lector LTC31 debería ser verde. Si tu luz es roja o si tu lector solo tiene una luz, conviene realizar un diagnostico mas fiable. Para ello, debes ejecutar desde la consola el comando:

/Library/OpenSC/bin/pkcs15-tool -D

pkcs15-tool es una herramienta que proporciona OpenSC y que permite, entre otras cosas, mostrar el estado de los lectores y de las tarjetas inteligentes conectadas en el sistema. La opción -D insta a esta utilidad a volcar toda la información de los dispositivos conectados. Antes de ejecutar el comando asegúrate de que el lector esta conectado, que la tarjeta está insertada y que has instalado las librerías OpenSC y Drivers DNIe que tocan para tu sistema operativo.

El resultado de ejecutar este comando nos dará pistas sobre si todo funciona o hay algún tipo de problema con la instalación. Si todo va bien el resultado debería ser algo parecido a esto:

my-mac:bin user$ ./pkcs15-tool -D
PKCS#15 Card [DNI electrónico]:
Version        : 1
Serial number  : 063AA3BA682276
Manufacturer ID: DGP-FNMT
Flags          : Login required, PRN generation

PIN [PIN1]
Com. Flags: 0x3
ID        : 01
Flags     : [0x211], case-sensitive, initialized, integrity-protected
Length    : min_len:4, max_len:16, stored_len:16
Pad char  : 0x00
Reference : 1
Type      : ascii-numeric
Path      : 3f00

Private RSA Key [KprivAutenticacion]
Com. Flags  : 3
Usage       : [0xC], sign, signRecover
Access Flags: [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength   : 2048
Key ref     : 1
Native      : yes
Path        : 3f003f110101
Auth ID     : 01
ID          : 4130363341413342413638323237363230303830323131313531303536

(...)

Hemos cortado el mensaje porque es muy largo. Puedes ver el mensaje completo aquí. Verás que una serie de mensajes de error avisando de un Security status not satisfied aparecen numerosas veces. No hay de que preocuparse, éstos mensajes son “normales”. Si tu resultado no se parece al mensaje anterior y/o  tienes algún mensaje de error tipo : No Readers found o No cards found entonces es que hay algo que no termina de ir bien en la instalación.

Si todo ha salido según lo descrito en el apartado anterior, ya puedes utilizar  tu DNI electrónico en Tractis. Podrás autenticarte en la plataforma usando un mecanismo mucho más robusto que el usuario/contraseña y firmar contratos con las máximas garantías de validez legal. Además, el DNIe te abre la puerta a un número creciente de aplicaciones que hacen uso de él, como banca segura en línea y trámites con la administración (consulta de datos fiscales, vida laboral, puntos del carnet de conducir, padrón, declaración de la renta, etc).

One more thing… Instalando los certificados en Firefox

Firefox tiene su propio sistema de gestión de certificados, completamente independiente del que dispone el sistema operativo. Por esta razón, una vez que tu sistema esté preparado para utilizar tu DNI electrónico, también deberás decirle a Firefox que puede hacer uso del DNIe.

Los drivers del DNI electrónico incluyen una página html que “mágicamente” (utilizando javascript) añaden los certificados de tu DNIe al repositorio de Firefox. Para acceder a esta página solo tienes que abrir desde tu navegador la ruta local

/Library/OpenSC/Share/web/instala_modulo.htm

…y seguir los pasos que te indiquen hasta recibir la confirmación de que los certificados se añadieron de manera satisfactoria.

Este último paso NO es necesario para utilizar tu DNIe en Tractis pero sí que es recomendable para aquellos usuarios que quieran utilizar Firefox y su DNIe en otros portales.

Conclusiones

A día de hoy, instalar un DNI electrónico en Mac OS X no es todo lo fácil que cabría esperar de un dispositivo destinado a ser de uso universal. Aún estamos ante una tecnología nueva (fuera de los cículos más tecnológicos)  y es normal que ciertos pasos aún no sean todo lo fáciles e intuitivos que nos gustaría. Por suerte, la gente del DNI electrónico proporciona buenas guías que arrojan mucha luz en el proceso de instalación.

Este post es nuestro granito de arena para favorecer el uso de esta tecnología tan potente entre los usuarios de Mac. Esperamos que os sea útil.

Hoy sin embargo me gustaría centrarme en una herramienta muy presente en mi día a día y que me esta haciendo la vida bastante mas fácil: maven.

No daré ningún tutorial de como funciona la cosa, porque para eso ya hay muchísima documentación que lo explica bastante mejor de lo que yo lo haría. Explicaré como nos ayuda maven en la gestión de la configuración en nuestros proyectos.

Un poco de introducción

El principal problema con el que me encontraba a la hora de gestionar el gran numero de pequeños subsistemas Java que tenemos en el backend de Tractis es que gestionar el ciclo de vida de éstos requiere de muchas tareas repetitivas que pueden ser automatizadas y la inclusión de muchas librerías de terceros.

Para esta automatización usábamos Ant de Apache que nos ayudaba a la gestión de tareas repetitivas durante el desarrollo de nuestros proyectos.

Ant es muy bueno para automatizar tareas repetitivas pero la gestión de librerías externas no es todo lo potente que podría ser. La manera común de usar una librería en uno de nuestros proyectos era bajar la versión adecuada, ponerla en un directorio del proyecto e incluirla mediante el classpath en nuestra aplicación.

Esta manera de gestionar las librerías puede funcionar cuando tienes pocos proyectos o los proyectos tienen muy pocas librerías en común. Por el contrario, si cuando buscas una librería en todos tus proyectos obtienes 10 resultados: tienes un problema con la gestión de librerías; y más aun si te paras a ver las distintas versiones de la librería en cada uno de los proyectos.

Es por esto que Ant, pese a que puede ser una alternativa razonable si tienes pocos proyectos, se queda corto conforme vamos teniendo un número considerable de proyectos para gestionar.

Maven al rescate

Maven es una tecnología más que asentada y que se usa en la mayoría de proyectos Open Source Java, pero nunca esta de mas reconocer las enormes ventajas que su aplicación nos aporta.

Esta tecnología ayuda a gestionar el ciclo de vida de los proyectos.Para ello se definen las fases del proyecto (compilación, test, empaquetado, despliegue) en un fichero de meta-información llamado POM donde se recogen detalles de las tareas a realizar en cada fase. También se recogen detalles de la naturaleza del proyecto como por ejemplo sus dependencias respecto a librerías de terceros.

Maven permite la gestión automatizada de estas dependencias de librerías de un modo mas que notable. Simplemente es necesario incluir la referencia a la librería dentro del fichero POM así como la versión requerida y maven la bajará del repositorio por defecto (o de otro que se encuentre configurado dentro del POM) y la incluirá en el repositorio local.

Esto facilita la gestión de la configuración muchísimo ya que los proyectos no van engordando con librerías que se encuentran duplicadas a lo largo de nuestro sistema de control de versiones.

Además la gran mayoría de los proyectos Open Source o bien tienen sus librerías dentro del repositorio por defecto de maven o disponen de un repositorio propio.

En resumen

Yo en un principio pensaba que con mi ant ya me iba bien pero despues de probar maven te quedas con la misma sensación que tienes con gem en ruby o apt-get en debian o ubuntu…¿Como he vivido tanto tiempo sin esto?!

Ya puedes firmar en Tractis con cualquier tarjeta bancaria Advantis Crypto que incluya uno de los certificados electrónicos admitidos en Tractis.

¿Qué es Advantis Crypto?

“Advantis Crypto” es un sistema operativo de tarjetas inteligentes multiprocesador desarrollado por Sermepa y que cada vez está y estará más y más presente en bancos e instituciones.

Como recordareis de un post anterior, la SEPA obliga a los bancos y cajas a migrar todo su parque de tarjetas bancarias de banda magnética a tarjetas inteligentes EMV con chip antes de 2010. La SEPA tiene enormes repercusiones tecnológicas para los bancos, que necesitan tarjetas inteligentes con sistemas operativos capaces de ejecutar múltiples aplicaciones. Las tarjetas Advantis Crypto permiten precisamente esto: ser usadas como tarjeta EMV o como un Dispositivo Seguro de Creación de Firma (DSCF) donde los bancos pueden incluir sus propios certificados, entre otras aplicaciones.

¿Quién es Sermepa?

A aquellos que viven en España puede que Sermepa no les suene mucho pero seguro que conocen ServiRed, el principal sistemas medios de pago español con 40 millones de tarjetas y más de 30.000 cajeros. Pues bien, Sermepa es el brazo tecnológico de ServiRed y ofrece sus servicios (soluciones tecnológicas, comunicaciones e I+D) a las cien entidades financieras que forman parte de ServiRed.

¿Por qué debería importarme?

Muchos bancos están aprovechando la migración de la SEPA para incluir certificados electrónicos en sus tarjetas con chip y, como anunciaba Julián Inza hace algún tiempo, dar así a sus clientes la posibilidad de firmar electrónicamente con sus tarjetas de crédito y débito. En Tractis hemos querido prepararnos desde el principio para este nuevo “ecosistema”. Durante las últimas semanas hemos trabajado hombro con hombro con Sermepa para asegurar que, desde hoy, puedas utilizar tu tarjeta Advantis Crypto para firmar en Tractis.

Para terminar, me gustaría apuntar que este movimiento se encuadra dentro de la estrategia de Tractis de convertirse en una plataforma abierta, neutral y universal. Un lugar donde puedas utilizar para firmar electrónicamente todos los sistemas operativos, todos los navegadores, todos los certificados electrónicos cualificados y todos los Dispositivos Seguros de Creación de Firma (tarjetas, USBs, etc) existentes. En definitiva, un lugar donde no tengas que preocuparte si tú, o la otra parte, vais a tener problemas para firmar.

Seguridad física

Disponemos de un cluster de servidores redundante alojado por Acens en su datacenter de Barcelona (España). Acens es uno de los proveedores españoles líderes en housing y nos proporciona una infraestructura con los máximos niveles de disponibilidad y seguridad, así como acceso a una red troncal propia, multioperador y con presencia en los puntos de acceso neutro (NAP) de Espanix y Catnix.

Las medidas de seguridad y control de acceso físico incluyen detectores de presencia, proximidad y circuito cerrado de televisión. Los medios físicos de seguridad incluyen sistemas tele-gestionados de protección contra incendios, detección de fugas de agua y combustible.

Gracias a que el servicio corre en nuestros servidores, tenemos control total sobre el código que se ejecuta en la solución final.

Seguridad de infraestructuras

Nuestras máquinas esta conectadas entre sí mediante una red privada de alta velocidad administrada únicamente por personal de Tractis y aislada de forma física, no solo del exterior, sino del resto de sistemas del datacenter.

La conexión desde exterior para la provisión de servicio se realiza a través de sistemas de firewall a nivel de red. Además, cada nodo front-end dispone de firewall lógico corriendo dentro del sistema operativo.

Seguridad en la administración

El acceso a nuestros sistema con propósito de administración se realiza mediante comunicaciones seguras basadas en SSH sobre TLS. Para ello nuestros administradores disponen de tokens de autenticación basados en certificados X509 protegidos a su vez por contraseña. Las ventajas de este sistema de acceso son:

1. Acceso mucho mas seguro que la autenticación basada en usuario y contraseña.
2. Acceso que permite la distinción y vinculación de los individuos y sus actividades en el sistema.

Seguridad de datos

Los sistemas de Tractis estan organizados mediante jerarquías donde los sistemas de proceso de transacciones forman clusters separados de los sistemas encargados de la gestión de nuestras bases de datos.

La comunicación entre las máquinas que sirven contenidos y estos sistemas de gestión de datos se realiza en un entorno seguro donde el canal se asegura mediante el uso de una red privada a nivel físico y encriptación de los canales de comunicación y autenticación de servidores mediante SSL/TLS .

Nuestras bases de datos corren sobre sistemas replicados y cada uno de ellos dispone de raids de discos , ofreciendo así mayor capacidad de servicio y mayor robustez en el manejo de datos ante posibles desastres físicos o lógicos.

Para garantizar la recuperación frente a desastres hacemos back-up de los datos cada noche y mantenemos copias encriptadas de estos back-up en distintas máquinas.

Seguridad de la Autoridad de Sello de Tiempo (TSA)

Tractis requiere aplicar “sellos de tiempo” en una variedad de situaciones (p.ej: en el instante de validación de la firma de un contrato con el fin de establecer una cota superior del instante de creación de la firma) y para ello dispone de su propia “Autoridad de Sellado de Tiempo” (“Time Stamping Authority” o “TSA”). Para la provisión segura y a prueba de fallos de dicho servicio, Tractis dispone de:

1. Hardware Security Modules: Tractis utiliza dispositivos HSM (o “Hardware Security Module“) con un doble fin, tanto como dispositivos de firma segura como con fines de aceleración criptográfica en la generación de firmas electrónicas. En concreto utilizamos Luna SA de Safenet que cumplen EAL 4 + CWA 14169 y que por tanto ofrecen las máximas garantías en la generación de sellos de tiempo:
   • Para la administración de estos dispositivos HSM requerimos autenticación de doble factor (token + pin code) y, por tanto, presencia física en el datacenter.
   • Aún contando con presencia física es imposible extraer la clave con la que realizamos la firma dado que se encuentra almacenada en la memoria interna “tamper proof” del propio dispositivo. En otras palabras, la clave no puede ser exportada para su uso fraudulento en otros sistemas.
   • Finalmente, para poder controlar el acceso al HSM empleamos el concepto “trusted path“, con lo que sólo las máquinas que han sido dadas de alta mediante procesos de administración presenciales pueden hacer uso del dispositivo.
2. Fuente segura de tiempo: Para la obtención del tiempo utilizado en la confección de los sellos de tiempo empleamos fuentes fiables de tiempo. Tractis dispone de un servidor de tiempo NTP (o Network Time Protocol) de primer nivel (o stratum 1) que obtiene su referencia a partir de un receptor GPS (o Global Positioning System). El sistema utiliza un reloj hardware que permite conocer el tiempo UTC (o Coordinated Universal Time) con una precisión dentro del microsegundo. Este reloj se mantiene sincronizado cada segundo con las señales de referencia procedentes de varios satélites de la constelación Navstar, que constituye el alma del sistema GPS, y que son visibles desde la ubicación geográfica del servidor.

Con esto termina la serie de dos posts dedicada a la “Seguridad en Tractis”. Esperamos que esta información haya resuelto muchas dudas. Si nos hemos dejado algo en el tintero o hay algún tema que te interesa pero no hemos tocado, no dudes en dejarnos un comentario o enviarnos un email.

Hoy comenzamos una serie de dos posts dedicada a explicar, con total transparencia, las medidas de seguridad que empleamos actualmente en Tractis.

Nuestros clientes utilizan Tractis para implementar procesos de contratación extremadamente sensibles que suponen el manejo de información confidencial como la identidad de las partes, el contenido de lo acordado y la firma del contrato. En Tractis somos conscientes de semejante responsabilidad y aspiramos continuamente a ofrecer la máxima seguridad posible, tanto en las transacciones llevadas a cabo como en los sistemas sobre los que se corren dichas transacciones.

Este primer post de la serie se centra en la “Seguridad en Procesos”, mientras que el próximo (y último) post de la serie, se centra en la “Seguridad en Sistemas”.

Los procesos de contratación permiten que las partes lleguen a un acuerdo, materializado en el contenido de un contrato y formalizado con la firma del mismo.

Para llevar a cabo estos procesos de contratación ofrecemos un sistema transaccional al que los clientes pueden conectarse mediante su navegador y que les brinda las funcionalidades de creación, negociación y firma de contratos. Los peligros y amenazas sobre dichos procesos son de naturaleza diversa, al igual que las medidas de seguridad utilizadas para contrarrestarlos.

Seguridad en la creación de contratos

Los contratos confeccionados entre las partes deben reflejar los acuerdos a las que éstas llegan de una manera exacta y fidedigna. Sin embargo, en los documentos digitales es relativamente fácil aplicar transformaciones sobre el contenido que hagan que ciertos datos no sean visibles al firmante. Por poner un ejemplo, podrían añadirse transformaciones que hicieran que ciertas cláusulas de un contrato no fuesen mostradas cuando se leyera pero que si estuvieran presentes dentro del contenido para el que se solicita la firma.

Tractis trabaja con XHTML y utiliza un editor de contratos especialmente diseñado para evitar el peligro arriba mencionado. Todos los textos cortados y pegados en nuestro editor así como las importaciones de documentos (desde Word, OpenOffice, etc.) son sometidos a un proceso de “sanitización” previo al guardado de cada versión del contrato. Este sanitizado elimina todos los elementos susceptibles (estilos, fuentes, etc) que puedan afectar a la representación visual del contrato.

Seguridad en las transacciones

Tractis ofrece medidas de seguridad en las transacciones que hacen uso de algoritmos criptográficos que hacen que sea imposible, sin antes romper dichos algoritmos, que terceros maliciosos puedan usurpar la identidad de las partes o interceptar los datos que estas intercambian:

1. Todas las transacciones (no solo el proceso de inicio de sesión sino todas las transacciones) realizadas en Tractis emplean el protocolo HTTPS sobre un canal seguro. De esta forma, los datos intercambiados entre el navegador del cliente no pueden ser interceptadas por terceras partes mediante técnicas de “snifado” de red.
2. Tractis permite diferentes métodos de autenticación. Los usuarios pueden autenticarse mediante el uso del tradicional usuario y contraseña o, en caso requerir un nivel de seguridad mayor, mediante mecanismos mas robustos como autenticación de doble factor con certificados electrónicos almacenados en tarjetas inteligentes (p.ej: DNIe). El administrador de cada cuenta business puede decidir que mecanismos de autenticación están disponibles para los usuarios de su cuenta y cuales no.

Seguridad en la firma de contratos

Firmas en cliente

Todas las firmas generadas en Tractis y basadas en dispositivos de creación de firma segura, se realizan en el cliente. Es decir, la aplicación Java de firma debe de interactuar con la tarjeta del cliente y por lo tanto con sus claves. Como esta tarjeta se trata de un dispositivo de creación seguro de firma las claves nunca salen de la misma y no viajan al servidor con lo cual la aplicación de firma es ejecutada siempre en el sistema del cliente.

Con objeto de garantizar que el componente de firma es íntegro y no ha sido alterado por terceros, se realiza la firma del código de dicho componente. De esta forma, el navegador del cliente, antes de emplear el componente de firma, comprueba que este no ha sido alterado. Para ello verifica que el componente está firmado y que la firma es válida. Esta medida garantiza que el código que corre en el cliente es íntegro y confiable y evita alteraciones que pudieran realizar accesos maliciosos a las claves tales como la realización automatizada firmas fuera del control del usuario.

Firmas electrónicas cualificadas

En Europa, la Directiva 1999/93/CE del Parlamento europeo y del Consejo, de 13 de Diciembre de 1999, establece el marco comunitario para firmas electrónicas. La Directiva define firma electrónica como datos en forma electrónica a los cuales se adjunta o se asocia de forma lógica otros datos electrónicos que pueden ser utilizados para identificar al firmante. La directiva distingue entre dos tipos de firmas:

• Firma electrónica avanzada: aquella que (a) está enlazada de forma única al firmante, (b) es capaz de identificar al firmante, (c) es creada utilizando medios que el firmante puede mantener bajo su control, y (d) está enlazada a los datos de tal forma que cualquier cambio subsiguiente a los datos es detectable.
• Firma electrónica cualificada: aquella “firma electrónica avanzada” que está basada en un certificado cualificado que ha sido creado por un dispositivo-seguro-de-creación-de-firma tal como define la directiva.

Todas las firmas utilizadas en Tractis para la firma de contratos con “Tractis Score 5″ (el nivel de firma más alto que reconocemos) tienen la consideración de firma electrónica cualificadas (o “Reconocidas”) y, por tanto, son equivalentes a firma manuscrita.

Validación de firmas (SVA)

Tractis valida las firmas una vez entran en el sistema y sólo las acepta si éstas son consideradas válidas, tanto por la ley (validez jurídica) como por el cliente (validez semántica). De esta tarea se encarga la “Autoridad de Validación Semántica” (“Semantic Validation Authority” o “SVA”) de Tractis. Este componente garantiza que si el certificado, las claves o la firma generada no son válidas no serán añadidas al contrato. Para ello el sistema valida las firmas teniendo en cuenta los criterios y algoritmos definidos en normativas internacionales al respecto de firmas avanzadas y certificados. En concreto, Tractis realiza todas las comprobaciones detalladas en los procesos de validación de firma descritos en DSS, XMLDSig, XAdES y se adhiere a todos los criterios definidos en los RFCs de Certificate Path Building y Certificate Path Validation, para validación del certificado con el que se realiza la firma.

Con carácter previo a cualquier nueva subida de código al entorno de producción, Tractis realiza baterías de tests para asegurar que cubre la multitud de situaciones descritas y casos particulares que se pueden producir en la validación de certificados. Una de estas baterías, la que la mayoría de los expertos consideran “la batería de tests definitiva en validación de certificados” por su excelente calidad, es la llamada PKITS que pone a disposición pública el NIST. El NIST o “National Institute of Standards and Technology” es la agencia del gobierno estadounidense dedicada a garantizar el cumplimiento de estándares y favorecer la interoperabilidad entre distintos fabricantes. Las pruebas PKITS diseñadas por la “ NIST – Computer Security Division ” y la NSA (Agencia de Seguridad Nacional) son utilizadas por las distintas administraciones del gobierno federal estadounidense como un método fiable para medir la calidad de los distintos despliegues PKI del gobierno. Dentro del PKITS, el caso que nos compete es la parte referente a “Path Validation Testing Program” diseñada para garantizar un cumplimiento exquisito de las especificaciones X.509 y RFC3280. Tractis supera satisfactoriamente el 100% de tests que “PKITS – Path Validation Testing Programs” establece.

Para una explicación en profundidad del proceso de validación de firmas en Tractis, de la conveniencia de validar certificados en el momento de la firma aún cuando la ley no lo exige y de las capacidades de validación semántica de nuestra SVA, recomendamos la lectura de los siguientes posts:

1. Validación de firmas en Tractis (1): Validación de certificados.
2. Validación de firmas en Tractis (2): Validación de firmas.
3. Validación de firams en Tractis (3): Validación a prueba de fallos.

Gestión de evidencias generadas por la validación de firmas

Todo el proceso de validación de firmas descrito en el punto anterior genera una serie de evidencias derivadas de los elementos empleados a la hora de aceptar o no una firma como válida (por ejemplo, certificados o información de revocación -CRL u OCSP-). Dichas evidencias son almacenadas y preservadas en el “Gestor de Evidencias” de Tractis. Este sistema garantiza el almacenamiento y preservación de la integridad en el tiempo de las evidencias generadas, de forma que puedan ser recuperables mediante procesos fuera de línea para su uso en caso de que surjan procesos periciales o disputas.

Seguridad en la preservación de contratos (LTA)

Una vez finalizado el proceso de contratación, Tractis se encarga de conservar los datos críticos generados en la plataforma (contratos, firmas, evidencias) y garantizar su integridad a través del tiempo mediante nuestro “Archivo de Larga Duración” (“Long Term Archive” o “LTA”).

Este sistema de almacenamiento de contenidos se diferencia de otros sistemas de almacenamiento disponibles en varios aspectos. El principal aspecto diferencial es que en un “Archivo de Larga Duración” la integridad de los datos no depende de auditorias que demuestren la imposibilidad de alterar el sistema sino que cada elemento almacenado en el sistema es capaz de demostrar su integridad de manera independiente. Cada uno de los registros del Archivo de Larga Duración se halla protegido mediante una cadena de sellos de tiempo que garantiza que dicho elemento no ha sido alterado desde su introducción en el Archivo.

–

Próximo (y último) post de la serie: Seguridad en Tractis (2): Seguridad en Sistemas

En posts anteriores hemos desgranado parte de los procesos que llevamos a cabo para poder validar las firmas electrónicas que se generan dentro de Tractis.

En este último post de la serie voy a concentrarme en los riesgos derivados de equivocarse en dicha validación, la importancia de las baterías de tests, para acabar centrándome en una de ellas: la batería de tests PKITS del NITS para validación de certificados.

Validar firmas electrónicas no es tarea para pusilánimes

Nuestro trabajo de desarrollo goza de una criticidad especial ya que se trata de implementar procesos donde se busca la preservación de datos e identidad de partes en procesos de firma.

Están en juego relaciones contractuales de compraventa, reclutamiento, control de calidad, operaciones financieras, suministro, inversión, partnerships o prestación de servicios, por poner unos pocos ejemplos. Contratos de los que dependen la operativa, reputación, estrategia, supervivencia financiera y, por qué negarlo, los “sueños” de las partes. Cada firma esconde muchas horas de trabajo y negociaciones previas y desencadena consecuencias a posteriori con un impacto real y visible en la vida de personas y empresas.

Semejante responsabilidad es una carga enorme. Hay que ser especialmente rigurosos para poder asegurar que todo funciona como debería hacerlo y solo hay una manera de conseguirlo:

Tests, tests y más tests

Testear es un proceso clave en el desarrollo de software de calidad. El realizar un testeo riguroso y de calidad puede marcar la diferencia entre un producto excelente y otro mediocre y mal acabado.

El software que compone una infraestructura de firma digital no solo no escapa a estas apreciaciones sino que, dada su complejidad y criticidad, debe hacer especial énfasis en procesos de testeo.

Testear de principio a fín una infraestructura como la de Tractis es una tarea en estado de perfeccionamiento y mejora contínuos. Cada elemento de la infraestructura (Autoridad de Atributos -AA-, Autoridad de Sellado de Tiempo -TSA-, Archivo de Larga Duración -LTA-, etc) requiere distintos enfoques de testeo. Solo la Autoridad de Validación Semántica -SVA- incluye múltiples componentes: unos validan firmas criptográficamente, otros miran la adecuación de la firma del punto de vista sintáctico comprobando que la información contenida en la misma es suficiente y correcta … y, como no, componentes que validan el certificado o certificados que intervienen en la misma. Una infraestructura con múltiples elementos, cada elemento con varios componentes, cada componente con sus propia batería de tests.

Para ejemplificar uno de los procedimientos que hemos seguido a la hora de comprobar que nuestra infraestructura funciona de manera correcta, ilustraremos el testeo del componente de validación de certificados.

Validando al validador: Los tests PKITS del NIST

Implementar un validador de certificados no es tarea fácil. Por un lado tenemos una serie de excelentes documentos RFC que nos explicitan el comportamiento esperado exacto de este tipo de componentes. Por otro lado, no son documentos triviales de implementar y su análisis requiere una atención máxima al detalle.

Una vez desarrollado el software que plasma en código los algoritmos definidos en el RFC 3280, surge la pregunta interesante: ¿Lo hemos hecho bien?.

Hay multitud de situaciones descritas y casos particulares que una buena batería de tests de validación de certificados debería tener en cuenta para poder dar garantías suficientes de que el componente es robusto y consistente con la especificación del RFC. El construir esta batería requiere de un análisis minucioso de la especificación y de encontrar ejemplos y contraejemplos que validen que el software responde de manera coherente a todos los diferentes casos derivados de la casuística de las entradas. Afortunadamente existen baterías de este tipo ya diseñadas y disponibles de manera pública.

Una de estas baterías, la que la mayoría de los expertos consideran “la batería de tests definitiva en validación de certificados” por su excelente calidad, es la llamada PKITS que pone a disposición pública el NIST. El NIST o “National Institute of Standards and Technology” es la agencia del gobierno estadounidense dedicada a garantizar el cumplimiento de estándares y favorecer la interoperabilidad entre distintos fabricantes. Las pruebas PKITS diseñadas por la “NIST – Computer Security Division” y la NSA (Agencia de Seguridad Nacional) son utilizadas por las distintas administraciones del gobierno federal estadounidense como un método fiable para medir la calidad de los distintos despliegues PKI del gobierno. Dentro del PKITS, el caso que nos compete es la parte referente a “Path Validation Testing Program” diseñada para garantizar un cumplimiento exquisito de las especificaciones X.509 y RFC3280.

Nosotros llevamos a cabo este testeo como parte de las baterías de pruebas de nuestro backend de validación de firma y estamos orgulloso de anunciar que, desde la semana pasada:

Tractis supera satisfactoriamente la totalidad de tests que “PKITS – Path Validation Testing Programs” establece.

Esto no es sencillo. De hecho, no hay muchas implementaciones de validadores de certificados que pasen la totalidad de la casuística definida en PKITS. La superación de estos tests es el resultado de un trabajo duro durante los últimos dos años y nos otorga confianza de que estamos actuando diligentemente cuando prestamos servicios de firma digital a nuestros clientes.

Finalmente, quiero aprovechar para agradecer a David Cooper, Computer Scientist del NIST, por su valiosa ayuda a la hora de pulir las últimas aristas necesarias para superar el 100% de los tests y reiterar que PKITS es solo una pequeña parte (adecuación al RFC 3280) de una estrategia global de tests que incluye la validación de la adecuación a XAdES, DSS, RFC 3161 (cada uno merecedor de su propia serie de posts) y demás estándares empleados en la construcción del backend de Tractis.

Con este post termina la serie “Validación de firmas en Tractis”. Esperamos que haya sido de vuestro interés.

En el primer post de esta serie dedicada a la “Validación de firmas en Tractis”, comentamos que el proceso de validar una firma es bastante complejo porque requiere la validación de numerosos elementos. Nos concentramos en explicar el más importante de ellos (pero no el único): la “validación del certificado con el que se realiza la firma”.

Explicamos:

1. Por qué debe validarse el certificado en el momento de la firma (si no validas el certificado utilizado para firmar, no te enterarás de si ha sido revocado, robado o falsificado).
2. Los principales fases para validar un certificado correctamente (1. construcción del path del certificado y 2. validación del path).
3. Los principales recursos que describen cuales son las comprobaciones y como deben realizarse (RFC3280).

Ahora que hemos descrito con cierto grado de detalle las operaciones a realizar para poder validar un certificado, en este segundo post, iremos un paso más allá. Describiremos en qué consiste “validar una firma”, los desafíos que supone y como una “Autoridad de Validación Semántica” responde a estos desafíos.

Validación de Firmas: La importancia del Sello de Tiempo

Para poder validar una firma electrónica necesitamos la firma en si, el documento firmado (en caso de que éste no este contenido como parte de ésta) y el momento del tiempo en el cual fue realizada la firma.

A vista de pájaro, una validación básica de firma require:

1. Validación criptográfica: validar la no alteración del contenido mediante algoritmos criptográficos de verificación de firma digital,
2. Validación de certificado: verificar el estado del certificado del firmante en el momento de la firma, y
3. Determinación del tiempo de la firma: conocer con el mayor grado de exactitud y certeza el tiempo en el cual fue realizada la firma.

No vamos a hablar del primer punto de validación criptográfica ya que intervienen algoritmos complejos que no aportan demasiado a un discurso de alto nivel como el que nos ocupa. Solo indicar que se persigue garantizar que el contenido no ha sido alterado. Asimismo, el proceso de validación de certificados ya lo describimos con un detalle razonable en el post anterior.

Vamos a centrarnos en el proceso de determinación del tiempo de firma, algo que puede llevarse a cabo de diferentes maneras pero en el que todas esas maneras tienen algo en común: alguien debe decirnos cuando ocurrió la firma. En nuestro caso, el tiempo de firma viene acotado por un “sello de tiempo” sobre la firma.

El sello de tiempo no es más que una firma (otra más) que protege el contenido sobre el que se aplica (en nuestro caso, la firma del contrato) y que además contiene un instante de tiempo. La conjunción de ambas cosas nos permite conocer de manera fidedigna cuando fué realizada la firma. Tractis realiza una validación de la firma justo después de firmar y añade un sello de tiempo para preservar ese instante.

Aunque quizás pueda parecer que no aporta demasiado al proceso de validación, esta coordenada temporal es clave. Nos permite averiguar si el certificado utilizado para firmar era válido en el momento de realización de la firma, independientemente del estado actual del certificado. En otras palabras, aunque nuestro certificado haya caducado o sido revocado hoy, las firmas realizadas con él hasta hoy (en que cambia de estado), deben ser consideradas válidas.

Dado que el sello de tiempo es una firma en sí misma, también debe ser validado aplicando los mismos criterios que aplicamos a cualquier otra firma.

En Infraestructura de Clave Pública (PKI), el ente encargado de realizar todas estas comprobaciones se denomina “Autoridad de Validación”. Todas las comprobaciones que hemos mencionado (validaciones criptográficas, de certificado y de sellos de tiempo) dan una idea de la complejidad de su tarea.

Desafíos: ¿Esta firma es válida?

Uno podría pensar que la pregunta de si una firma es válida o no se responde siempre con una afirmación absoluta. Decidir si la firma ha sido criptográficamente alterada se hace con un cálculo matemático que solo tiene dos posibles resultados: el contenido ha sido alterado o no ha sido alterado. ¿No es cierto?. Pues no, no es tan sencillo.

La respuesta sobre si una firma es válida o no puede variar según quien realice la comprobación.

Esto puede sonar chocante y sin sentido… ¿como puede una firma ser válida para mi pero invalida para el vecino si es la misma cosa y seguimos los mismos criterios y algoritmos de validación?. Pues puede y, de hecho, tiene todo el sentido ya que no todo el mundo tiene el mismo concepto de lo que es válido o no lo es.

Veamos un ejemplo: Imaginad que tenemos una misma Autoridad de Validación que da servicios a varias instituciones. En este escenario cualquier conjunto de firmas será válido o invalido para todos los usuarios. Imaginad ahora que uno de los clientes que consume los servicios de esa Autoridad de Validación solamente quiere aceptar una serie de certificados concretos (p.ej: solo certificados de Autoridades de Certificación alemanas) o solo una série de algoritmos (p.ej: claves más fuertes que supongan mayores garantías de integridad). Más aún, sigamos imaginando ahora que uno de los clientes de esa Autoridad de Validación requiere de certificados y algoritmos diferentes en función del proceso de contratación o la cuantía involucrada. Tiene sentido: un acuerdo por la compra de un CD no requiere las mismas garantías que un acuerdo por la compra de una empresa.

Aunque la Autoridad de Validación diga que la firma es válida desde el punto de vista técnico, no lo es desde el punto de vista del conjunto de reglas que el cliente ha definido. Estamos pasando de la “simple” firma de un mensaje criptográfico a “algo más” donde la validez depende de la naturaleza del contenido firmado.

Estamos añadiendo “semántica” a la validación.

Bienvenidos a Tractis: Validación Semántica de Firmas

Cuando decimos que una Autoridad de Validación es semántica, queremos decir que permite a sus usuarios crear diferentes tipos de reglas de validación para validar distintos tipos de documentos firmados, independientemente de la configuración por defecto de la que disponga el servicio en si.

Normalmente la validación suele darse mediante unos mecanismos técnicos estándares que suelen dar un resultado concreto para una solicitud de validación determinada. Es decir, muchas Autoridades de Validación actuales no pueden observar casos particulares dependiendo de quien solicite la validación.

Tractis da respuesta a los desafíos mencionados a través de nuestra “Autoridad de Validación Semántica” o “SVA”, uno de los componentes de la infraestructura back-end de Tractis. La SVA de Tractis se encarga tanto la validación técnica como de la validación semántica de cada firma. El que Tractis soporte certificados de diferentes Autoridades de Certificación de diversos paises no significa que nuestros clientes deban aceptarlas todas como válidas. Nosotros realizamos recomendaciones sobre los distintos grados de seguridad y garantía de cada método de firma pero nuestros usuarios conservan la libertad (y el poder) para decidir que consideran válido y que no para cada tipo de contrato.

Actualmente, el componente semántico de la Autoridad de Validación de Tractis está solo disponible para grandes cuentas pero, siguiendo la filosofía de Tractis de “todos disfrutan del mismo nivel de seguridad y funcionalidad”, pronto lo pondremos a disposición de todos los usuarios, particulares y pymes.

Como podeis imaginar, añadir semántica a la validación incorpora un nivel de complejidad (y utilidad) sin precedentes. Gestionar dicho servicio y garantizar su correcto funcionamiento se convierte en el auténtico desafío. Como lo conseguimos en Tractis es el tema del próximo, y último, post de esta serie.

–

Próximo post: Validación de firmas en Tractis (3): Validación a prueba de fallos.

Hoy Lunes 28 de Abril de 2008 marca un hito importante en el roadmap de Tractis. Tenemos el placer de anunciar oficialmente que Tractis supera la totalidad de tests PKITS del NIST.

El NIST o “National Institute of Standards and Technology” es la agencia del gobierno estadounidense dedicada a garantizar el cumplimiento de estándares y favorecer la interoperabilidad entre distintos fabricantes. Las pruebas diseñadas por la “NIST – Computer Security Division” y la NSA (Agencia de Seguridad Nacional) son utilizadas por las distintas administraciones del gobierno federal estadounidense como un método fiable para medir la calidad de los distintos despliegues PKI del gobierno. La semana pasada Tractis superó con éxito el 100% de la batería de tests PKITS del NIST, diseñados para garantizar un cumplimiento exquisito de las especificaciones X.509 y RFC3280.

Para celebrarlo, vamos a dedicar esta semana a una serie de tres posts cuyo objetivo es explicar (1) conceptos básicos de validación de certificados, (2) el desafío que supone la validación de firmas electrónicas y (3) algunas de las técnicas que utilizamos en Tractis para garantizar una validación perfecta y a prueba de fallos.

Introducción

En Tractis ofrecemos un servicio web que permite a particulares y empresas firmar contratos 100% online y con la misma eficacia jurídica que la firma manuscrita. Para ello empleamos tecnologías de firma digital que garantizan la integridad del documento, la identidad de las partes y la no repudiación futura de los compromisos adquiridos por los firmantes.

Nuestra plataforma no sólo permite un firmado de contratos sin más, sino que antes de añadir cualquier firma al contrato la validamos para evitar cualquier tipo de irregularidad en el proceso de firma. El responsable de realizar este proceso en nuestro back-end es un elemento al que denominamos “Autoridad de Validación Semántica” (SVA o Semantic Validation Authority). La SVA de Tractis valida desde aspectos criptográficos a temporales y, por supuesto, valida que el certificado empleado para realizar la firma es apto para ello.

Como el proceso completo de validación de la firma es demasiado complejo para explicar en un solo post (personalmente diría incluso que es demasiado complejo, a secas), en este primer post nos centraremos en el proceso de validar el certificado con el cual se ha realizado la firma.

Validación de certificados

Para que exista “firma electrónica reconocida” (equivalente a firma manuscrita), la legislación europea no requiere que se valide el certificado electrónico con el que se realiza la firma en el mismo momento de la firma. Sin embargo, en Tractis siempre lo hacemos. No es ninguna tontería. Imaginad una empresa que entrega un certificado electrónico a un empleado para que firme contratos electrónicos en representación de la compañía. Ahora imaginad que esa empresa despide al empleado y revoca su certificado. Si se utilizasen herramientas de contratación online que no validan online el estado del certificado, el ex-empleado podría engañar a terceros y utilizar el certificado para firmar en nombre de la empresa ¡incluso a pesar de estar despedido!. Las pérdidas podrían ser cuantiosas. No en Tractis. En Tractis no se realiza ninguna firma electrónica reconocida sin antes validar online en tiempo real el estado del certificado. Esto es así para todos los certificados que admitimos, sean del país que sean. Y, ni siquiera haciendo esto, hemos terminado nuestro trabajo.

Mucha gente piensa que validar un certificado consiste simplemente en lo que hemos comentado: consultar, en el momento de la firma, el estado del certificado a la Autoridad de Certificación que lo emitió y averiguar si el certificado es válido y no ha sido revocado. Nada más lejos de la realidad. Validar un certificado de una manera ortodoxa no es algo sencillo. Validar que el certificado no este “expirado” o mirando una CRL o consultando un OCSP para ver si está “revocado” es sólo una pequeña parte del trabajo.

El proceso de validar un certificado con garantías suficientes es bastante mas complejo, ya que hay que tener en cuenta la validación de todos los elementos relacionados con el certificado como certificados de Autoridades de Certificación, listas de revocación (CRL) o mensajes OCSP que deben ser a su vez validados de manera análoga.

El porque de tener que validar todos estos componentes deriva de que el encargado de validar el certificado no suele ser el mismo que el emisor de dicho certificado. Nos encontramos entonces con que el validador debe confiar en la información emitida por un tercero para poder emitir un veredicto respecto al certificado a validar. No obstante, antes de poder utilizar esta información para poder emitir un veredicto, ésta debe ser validada. Debemos comprobar que nos hayamos ante información confiable: que no ha sido alterada y que es adecuada para efectuar la validación del certificado en el instante de tiempo en el cual éste debe ser validado. Y es que el momento en el cual se valida el certificado es un punto clave a la hora de efectuar todo este proceso ya que el componente temporal afecta enormemente al proceso de validación. No es lo mismo validar un certificado en el momento actual, que hace 5 años o que de aquí a 5 años.

Por ello, y por poner un ejemplo sencillo, en el caso de una firma no podemos simplemente validar el certificado en la actualidad sino que debemos determinar de manera fidedigna cuando fue realizada la firma y validar el certificado en ese momento. Veamos un ejemplo: si firmé mi hipoteca y al año siguiente me robaron mi e-ID (sea el que sea: DNIe español, beID belga, Cartão de Cidadão portugués, Carta d’dentitá elettronica italiana, Bürgerkarte austriaco, FINEID finlandés, ID-Card estonio…) y lo anulé, no me gustaria que todas las firmas que hice antes de ese momento (incluyendo mi hipoteca) sean consideradas a partir de ese momento como invalidas, ¿no?.

Aparte de las consideraciones ya comentadas hay además multitud de detalles críticos como la comprobación de longitud de paths, espacios de nombres admitidos, extensiones críticas aceptadas o no, firmas de la información de revocación, etc… que deben ser tenidos en cuenta.

Para simplificar, abstrayéndonos un poco de toda esta ingente cantidad de procesos que deben llevarse a cabo, el proceso de validación de un certificado se divide en dos grandes partes: (1) la construcción del path de certificación y (2) la validación del mismo.

La necesidad de construir un path… y validarlo

Para validar un certificado, ya sea como parte una validación de firma o validándolo de manera aislada (por ejemplo para logearse en un portal mediante el uso de TLS), es necesario contruir todo su “certification path“ y validarlo.

El concepto de “path” viene determinado por el como las Autoridades de Certificación emiten sus certificados. Cada certificado de entidad final (el que emiten a personas o entidades ) contiene una serie de atributos tales como “nombre”, “organización”… que hacen referencia al sujeto que es objeto de la emisión del mismo. Además, cada certificado incluye una clave pública que será empleada en el proceso de validación criptográfica de toda firma realizada con la clave privada asociada a ese certificado.

Este certificado es una representación off-line de estos datos en la que un tercero (tu banco, tu gobierno…) nos garantiza la veracidad de estos atributos para este individuo. Por ejemplo con la emisión de un certificado donde figure mi nombre, apellidos, empresa y DNI, la autoridad que emite el certificado garantiza que esos atributos son constituyentes de mi identidad y además los asocia a una clave pública.

Como hemos comentado un certificado no es más que un mensaje codificado según una serie de reglas establecidas, pero como es un método de transmisión de información off-line debe haber alguna manera de garantizar la autenticidad de los datos que figuran en el mismo. De esta necesidad de preservar la integridad de los datos viene el requerimiento de que todo certificado debe estar firmado por la autoridad de certificación que lo emite. Así, deberemos validar criptograficamente el certificado de entidad final para garantizar su autenticidad y no alteración, utilizando para ello la clave pública del certificado de la Autoridad de Certificación (CA) emisora.

Este certificado de CA emisora puede estar emitido a su vez por una CA de grado superior y esta por otra hasta llegar hasta la llamada “CA raíz”, un certificado de CA que esta emitido por el mismo y como tal esta firmado con su propia clave privada.

Para que todo el proceso sea consistente estos “certificados raíz” deben ser conocidos por el validador por medios fuera de banda. ¿Os suena el repositorio de certificados que Windows lleva para que os podáis conectar a servidores vía https sin que salgan advertencias de seguridad?, pues es algo así.

Más aún, una vez construido el path, este debe ser validado teniendo en cuenta un gran número de consideraciones relativas a restricciones sobre el mismo o validar el estado del certificado de entidad final así como de las CAs involucradas (sin contar la raíz) contra CRLs, OCSPs u otros métodos de comprobación del estado de la revocación.

Y aún hay más, CRLs y OCSPs son objetos firmados con lo cual para poder emplearlos y ser confiables deben ser validados criptográfica y sintácticamente así como validar el certificado con el cual han sido firmados de manera similar a la comentada para los de entidad final: construyendo su path y validándolo.

Como veis, en la validación de un certificado intervienen una serie de actores adicionales como CAs e información de revocación que debe ser tenida en cuenta, procesada y validada haciendo que la complejidad y el coste de validar un certificado explote.

Afortunadamente las normas RFC 3280 especifican de manera detallada como debe llevarse a cabo el proceso de validación del path de certificados. Así, este procedimiento queda detallado en un documento y todos los validadores que, como Tractis, dispongan de una implementación que respete RFC3280 validarán siguiendo el mismo conjunto de reglas.

Conclusiones

El proceso de validar una firma electrónica es un proceso complejo que se puede dividir en diferentes procesos complementarios que validan las diferentes partes de la firma: la criptográfica, la relativa al tiempo de firma … y, como una de las destacadas, la relativa a la validación del certificado con el que se realiza la firma.

Hemos descrito este proceso a vista de pájaro y de forma resumida pero con el suficiente grado de detalle como para demostrar que conocer el estado de un certificado de manera diligente es mucho más complicado que consultar a un servicio OCSP de estado de certificados o bien mirar las entradas de una CRL.

También hemos visto que, por suerte para los que construimos infraestructuras de este tipo, existen especificaciones de lo que debe y no debe hacerse en dicho procesos. Estas especificaciones hacen posible que dispongamos de implementaciones de validación coherentes, respetuosas con estándares abiertos e interoperables entre los diferentes fabricantes.

–

Próximo post: Validación de firmas en Tractis (2): Validación de firmas

En las empresas constantemente se tiene que decidir entre diversas opciones para poder minimizar costes y maximizar beneficios. Así debemos elegir entre alquilar oficinas o comprarlas, externalizar o no ciertas actividades de nuestro negocio: con outsourcing, offshoring y demás estrategias que, al fin y al cabo, lo que hacen es ayudar a desarrollar la actividad de la empresa sin que ésta deba someterse a aumentos y descensos en el volumen de plantilla o inmuebles para dar respuesta a la demanda del mercado.

En el campo de la informática suele ocurrir el encontrarnos con este tipo de decisiones en procesos de desarrollo de software: el típico ¿lo hacemos en la casa o lo contratamos fuera?. Pero una vez termina éste ciclo no es común llevar emplear estrategias similares para el resto de los campos de la actividad informática.

En el terreno de las infraestructuras donde corren los servicios de una compañía no suelen darse este tipo de pensamientos, ya que la criticidad de los mismos lleva a pensar que no es una buena idea delegar estos, ni tan siquiera una parte de ellos, en un tercero porque tenemos la percepción de que perdemos el “control total”.

Actualmente, cada vez más, y sobretodo en el sector de las empresas de internet, se va percibiendo que no es nfecesario disponer de unas infraestructuras propias que tengan todo lo que necesitamos para correr nuestras aplicaciones. De hecho, que incluso no necesitemos ni de una infraestructura propia para poder desarrollar nuestra actividad.

Realmente si transportamos el problema a un equivalente mas cotidiano cuando le damos al botón para encender la luz queremos que se ilumine la bombilla y nos da igual donde se produjo la electricidad, simplemente queremos que la cosa funcione. No necesitamos tener una central nuclear en casa para poder encender una bombilla, pero si tenemos una empresa y la electricidad es clave para desarrollar nuestra actividad, seguramente queramos mantener la disponibilidad de éste recursos a prueba de fallos. En estos casos sería más práctico en pensar en tener varios puntos de fallo con diversos proveedores más que en ser nuestro propio proveedor.

Utility computing: Informática como el agua o la electridad

Este pensamiento lleva años siendo plasmado por los grandes del mercado que quieren hacer que la informática se convierta en una comodity más para las empresas, como pueden ser la luz, el gas o el agua.

Actualmente ciertos componentes como la computación o el almacenamiento se están comoditizando con un grado de madurez suficiente para que puedan ser empleados por las empresas en entornos de producción, cosa que es una gran noticia ya que permite aplicar economías de escala a las empresas que los prestan y dar un mejor servicio a un mejor precio.

Así podemos tener nuestra aplicación corriendo en servidores virtuales en los que paguemos según el consumo que tengamos en mismos, nuestros backups o contenidos a servir pueden estar en servidores de storage remoto, con lo cual evitamos gastos en dispositivos de copia de seguridad o almacenamiento (el coste de un buen sistema de copias de seguridad puede llegar a ser realmente elevado). Podemos servir ciertos contenidos empleando redes de distribución de contenidos (dando la imagen de tener un data center próximo al cliente) y así poco a poco externalizar ciertos servicios infrastructurales en proveedores especializados reduciendo costes y mejorando la calidad de nuestro servicio.

Incluso podemos ir más allá del planteamiento de sólo usar a terceros en servicios sobre los que corre nuestra plataforma, podríamos adaptar ciertos componentes de ésta para que sean prestados por terceros proveedores especializados. Así evitaríamos el coste de su desarrollo, mantenimiento y explotación, que en ciertos casos puede ser una parte importante del presupuesto de la aplicación, optimizable y externalizable si no es un valor añadido de nuestras aplicaciones.

Firma electrónica bajo demanda

Dentro de éste tipo de componentes susceptibles de ser prestados por terceros especializados podemos encontrar los enmarcados dentro de la categoría de infrastructuras de clave pública y firma digital, cada vez más vitales en las aplicaciones y sobretodo en las del mundo internet pero que disponen de la bastante complejidad para que su desarollo no sea un tema trivial.

En este campo la tendencia suele ser o hacerse el software ad-hoc a partir de librerías ya existentes, o instalar productos ya desarrollados, sean soluciones open source o comerciales de terceros pero explotados en nuestros sistemas. El problema es que estos desarrollos, instalaciones y mantenimientos de éste tipo de soluciones no suelen ser muy asequibles.

Están solo al alcance de empresas que disponen de enormes partidas de presupuestos para estos fines e, incluso en estos casos, carecen del know-how o no presupuestan el mantenimiento y mejora continua de la nueva infraestructura. El resultado son despliegues que no representan el coste total de propiedad (CTO), que pronto quedan obsoletos, que se implantan de forma defectuosa o, pero aún, que nunca llegan a ser implantados.

El campo de las infraestructuras de clave pública fue el primero de los dos en mover ficha y hoy en día ciertas actividades relativas a las mismas, como por ejemplo el rol de emitir certificados, ha quedado limitado a un pequeño conjunto de proveedores especializados dado que es una actividad que requiere de un elevado desembolso y esfuerzo para ser llevada a cabo.

Las infraestructuras de firma digital van un poco más rezagadas a la hora de hacer visible su complejidad y así como casi nadie hoy en día se plantea construir su propia autoridad de certificación, si es común en cambio el plantearse el crear una autoridad de firma digital (ya sea para la creación, validación, sellado o almacenado).

Una buena idea en éste aspecto es aplicar un criterio similar al tomado con las autoridades de certificación y delegar los servicios de firma digital en un tercero pudiéndonos centrar así nosotros en desarrollar nuestra actividad de negocio.

De hecho cada vez son más las instituciones públicas y empresas privadas en nuestro país que ponen a disposición terceros plataformas que ofrecen servicios de infraestructura de clave pública y de firma digital abriendo un nuevo mercado de la actividad informática y reforzando la idea de que éste tipo de trabajos críticos debe estar centralizado en proveedores especializados que aprovechando economías de escala puedan ayudar a optimizar costes y maximizar la calidad del producto final.

Nosotros creemos que ésto es una gran idea ya que el mundo de la infraestructura de clave pública y la firma digital debería ser algo que las empresas pudieran integrar en sus aplicaciones sin necesidad de grandes desembolsos y esfuerzos como ha pasado hasta ahora. Somos conscientes de lo complicado que puede llegar a ser solucionar éste problema, porque nosotros también hemos estado ahí y por eso el que nos decidieramos a abrir nuestros servicios de firma digital y ofrecerlos como servicios a terceros, porque en internet la seguridad debería ser una comodity, no un lujo.

En su día ya comentamos nuestra decisión de usar Ruby on Rails para desarrollar Tractis y lo que nos alegrábamos de haber escogido Rails en lugar de Java. También mencionamos que, debido a las carencias de Ruby, habíamos optado por emplear servicios web en Java para el backend de firma digital.

Entonces nos alegrábamos mucho sobre la decisión que habíamos tomado al escoger Rails, y todavía lo hacemos. El framework nos ha dado muchísima agilidad y trabajar con él es divertido. Quién sigue el blog ha visto que incluso participamos en los eventos que podemos sobre Rails, con lo que resulta bastante evidente nuestra satisfacción con la herramienta.

Ahora bien ¿qué ha sido del desarrollo que hemos hecho en Java?

Releyendo aquel post parece que estamos desarrollando en Java porque no hay más remedio. Que si hubiésemos tenido las librerías necesarias en Ruby ahora no tendríamos código Java y seríamos aun más felices. Con la aparición de JRuby hay quien nos pregunta si no preferiríamos tener la aplicación en JRuby on Rails y tener así acceso a las librerías que necesitamos de Java, eliminando nuestra necesidad de los servicios web.

Sin embargo, aquella decisión que tomamos no fue solo sobre frameworks, sino que también consistió en una decisión sobre el diseño de la aplicación.

La elección de diseño: arquitectura de servicios web

Como decíamos, cuando escogimos framework, también escogimos arquitectura. Decidíamos que preferíamos desarrollar varias aplicaciones específicas que una que lo englobase todo, al más puro estilo UNIX.

La verdad es que, volviendo la mirada atrás, nos alegramos mucho de haber optado por Rails para el frontend, pero nos alegramos mucho más de haber optado por una arquitectura de servicios web. Así que, igual que entonces os contamos las ventajas que habíamos tenido al escoger Rails, ahora queremos compartir con vosotros las ventajas de esta decisión de diseño.

Otra buzzword

Este tipo de arquitecturas está de moda y tienen buzzword propia: SOA (Service Oriented Architeqture). Así ya podrás tener tu aplicación SOA, hecha en Rails y con mucho AJAX.

Si por el contraro, eres como nosotros y prefieres motivos de verdad. Sigue leyendo

Calidad

Enlazando con lo que comentamos antes, la idea de diseñar aplicaciones más pequeñas y específicas que conformen un todo sigue la línea de la filosofía UNIX.

Si nos paramos a pensarlo, es esa filosofía la que hace que UNIX sea tan potente y nos guste tanto. Tienes un montón de programas específicos: ls, grep, sed, awk… Esos programas hacen cosas muy específicas, pero las hacen muy bien.

Al trabajar con aplicaciones específicas que tienen que resolver un problema concreto podemos centrarnos mucho mejor en el problema en cuestión. Podríamos pensar que para esta labor de aislamiento de tareas basta con desarrollar librerías en lugar de aplicaciones, y estaríamos en lo cierto. No obstante, el desarrollar aplicaciones distintas conectadas por servicios web nos permite tener una arquitectura totalmente agnóstica sobre lenguajes, frameworks y pilas de despliegue. Si más adelante resulta que con C++ o .NET tenemos mejores herramientas para la validación de firmas podemos migrar únicamente esa aplicación sin que el resto de nuestro sistema lo perciba. Desarrollando aplicaciones específicas podemos emplear las mejores herramientas en cada caso

Además de la calidad en la implementación, nosotros encontramos una mejora en la calidad a la hora de dar servicio, por un lado por motivos de escalabilidad que comentaremos en el punto siguiente, y por otro ante la posibilidad de redesplegar o desactivar un servicio en concreto sin que esto implique parar el resto de los servicios.

Escalabilidad

Cuando nos referimos a escalabilidad hablamos tanto de escalabilidad de recursos técnicos como humanos.

Por parte de los recursos técnicos es muy simple. En un principio puedes empezar con todos los servicios en una misma máquina, si alguno te supone un cuello de botella, pues le pones una máquina dedicada. Es más, si el servicio es un share-nothing, puedes poner tantas máquinas como necesites para dar un buen servicio. Los que trabajéis en Rails esto lo tendréis claro

Entrando en el terreno humano, una arquitectura de servicios nos da más fórmulas para escalar nuestro desarrollo, permitiendo desde la gestión de un único equipo, hasta la asignación de un equipo por servicio. De este modo, cuando nuestro proyecto crece y requiere de más desarrolladores no es necesario que tengamos un equipo cada vez más grande, sino que podemos mantener varios equipos más pequeños y ágiles que se encarguen de uno o más servicios.

En futuros posts

En futuros posts esperamos comentaros más detalles sobre la arquitectura que tenemos, qué servicios la componen y para qué sirven.

Un saludo!