Hyperledger Fabric es la tecnología de referencia en todos los proyectos que realizamos en Kolokium desde principios del 2017, tiempo en el que entramos en el programa de partners de IBM. En todo este tiempo hemos ayudado a muchos clientes a entender y explorar el potencial de Hyperledger Fabric como tecnología para desplegar procesos distribuidos.
Por nuestra experiencia durante todos estos años desplegando soluciones Blockchain, nos hemos enfrentado con una gran cantidad de entornos y casos de uso diferentes, desde certificación de procesos industriales, despliegue de blockchain para la gestión de identidad de redes IoT o implementación del ciclo de vida de documentación certificada. Aunque cada caso de uso tiene sus peculiaridades, las cuales dependen directamente del vertical en el que se desarrolla. Esta dependencia está directamente ligada a los modelos de gobernanza de los datos asociados a los procesos que se pretenden desplegar.
Salvando las diferencias propias de cada proyecto o cliente, en los que hemos trabajado, podemos enumerar un conjunto de buenas prácticas, las cuales solemos transmitir a los clientes, con el propósito de que interioricen el potencial de la tecnología y el impacto positivo que dicho potencial tendrá en sus organizaciones.
1. Estás construyendo un sistema distribuido
Después de tantos años desplegando soluciones Blockchain y ayudando a compañías a implementar procesos con tecnología Blockchain, el principal consejo que solemos dar y que puede parecer de sentido común, es que debes cambiar tu forma de pensar cuando construyes soluciones. Hyperledger Fabric es una tecnología que te permite construir soluciones distribuidas y consorciadas. Lo que significa que varias compañías podrían desplegar procesos para la gestión de datos, en un entorno distribuido desde el punto de vista IT, es decir, los componentes, encargados de ejecutar el código de los procesos y de mantener la persistencia de los datos, pueden estar repartidos entre la infraestructura de las distintas compañías que participan en el consorcio.
El número de casuísticas que se pueden llegar a dar es enorme, lo que complica el diseño y la planificación del desarrollo y el mantenimiento de la solución. Y aunque puede parecer una tarea titánica, establecer los posibles escenarios para construir los planes de desarrollo o contingencia. La estrategia más acertada pasa por plantear un escenario de arranque inicial y diseñar los procesos de onboarding de nuevos participantes, así como establecer los modelos de gobernanza del dato y la infraestructura, con el propósito de que todos los participantes en el arranque, tengan claras las reglas del juego y la forma en la que la solución puede evolucionar con el tiempo.
Pensar de manera distribuida, nos permite concentrarnos en aspectos como la seguridad o la escalabilidad, ya que estas características deben estar definidas desde el inicio, por la naturaleza distribuida de la solución. Ya no basta con implementar un modelo de bastionado de la solución, como haríamos en una plataforma tradicional. En las soluciones implementadas con Hyperledger Fabric, el dato está distribuido, por lo que tenemos que concentrarnos en proteger el dato en primera instancia, independientemente del nodo en el que se encuentre almacenado dentro de la red.
2. Sin modelo de datos, el fracaso está asegurado
Aunque puede parecer una obviedad, en muchos casos, cuando las compañías inician una aproximación a la tecnología Blockchain, la realizan desde un ángulo incorrecto: utilizar Blockchain para guardar datos. Definir un modelo de datos que esté alineado, no solo con lo que se pretende hacer, sino con la naturaleza de la tecnología que estamos desplegando. Y esto es importante, ya que debemos tener presente de manera continua, que vamos a desplegar datos sobre una tecnología distribuida y las reglas de acceso o distribución de los datos, son muy diferentes, si construimos soluciones sobre tecnología distribuida o no distribuida.
Por tanto, para que los modelos de datos funcionen sobre tecnologías como Hyperledger Fabric, se debe tener en cuenta, no solo los modelos relacionales de los distintos componentes funcionales, sino como dichos componentes pueden evolucionar de manera distribuida a lo largo del tiempo.
Otro error común, que afecta directamente a los modelos de datos sobre tecnologías Blockchain, es asimilar que el ledger es una base de datos, con el concepto actual que tenemos de base de datos. Y no sólo como repositorio de datos que garantizan la persistencia, que en este caso la Blockchain también lo hace, sino como herramienta para la gestión de consultas y modificaciones de los datos. Durante estos años nos hemos encontrado casos en los que se pretendía utilizar la Blockchain como un sustituto seguro de una base de datos. Este planteamiento que no tiene mucho recorrido, ya que a pesar de las carencias que la tecnología Blockchain puede tener para constituir una alternativa a cualquier sistema de bases de datos actuales, el enfoque de Kolokium siempre ha sido intentar integrar soluciones que funcionen, llevando al cliente hacia el modelo que utilice lo que le funcione y aplique Blockchain allí donde le puede ayudar. Por ejemplo, para gestionar el ciclo de vida de ciertos datos, aunque estos datos tengan un persistencia fuera de la blockchain.
A modo de resumen, solemos compartir con los clientes, las siguientes ideas en cuanto al ciclo de vida del dato:
- Blockchain no es mejor que un sistema de Bases de Datos tradicional, para los usos que el cliente está acostumbrado a hacer de ellos
- Utiliza la capa de persistencia de la Blockchain para gestionar aquellos datos, de los que sería útil disponer de una trazabilidad para certificar ciertas cualidades del dato, origen, caducidad, etc.
- Construye cachés para incrementar el rendimiento de las operaciones de consulta sobre datos e históricos de la Blockchain. El usuario siempre podrá verificar la fuente de la caché que has construido.
- Intenta construir un modelo de seguridad y gobernanza, no de la solución, sino del dato. El objetivo es que el dato esté protegido por sí mismo, independientemente de dónde termine almacenado.
- Cuidado con la concurrencia sobre los datos, estás trabajando sobre un entorno distribuido, en el que no tienes control sobre qué partes de la red pueden recibir una transacción que afecte a un dato en concreto.
3. Construye un modelo de identidad digital para los componentes y participantes
La base de cualquier solución Blockchain, es que todas las operaciones que se realizan están firmadas digitalmente por un emisor. Sobre esta premisa, se pueden construir soluciones que cumplan con las necesidades de certificación y trazabilidad de los datos, que los participantes hayan establecido. Por tanto, es necesario construir un modelo de identidad digital que permita construir soluciones robustas, en las que se puedan establecer relaciones de confianza entre los componentes y participantes.
En muchas ocasiones nos hemos encontrado que los clientes no han dado importancia al modelo de identidad digital de la solución, generando un enorme problema, no solo de seguridad del dato, sino de confianza de toda la solución.
Hyperledger Fabric es una tecnología Blockchain de tipo permisionada, eso quiere decir que todas las identidades digitales deben ser aprobadas por un participante que tenga esta competencia. Por tanto, el modelo de identidad digital que se establezca debe cumplir con un modelo permisionado, en el que uno o varios participantes tendrán la responsabilidad de permitir el acceso a nuevas identidades digitales. Este modelo permisionado está soportado por un conjunto de reglas y métodos, que permiten a la infraestructura Hyperledger Fabric validar las identidades digitales que participan en dicha infraestructura.
Algunas buenas prácticas, que cualquier organización que quiera desplegar una solución sobre Hyperledger Fabric, debería tener en cuenta:
- El esquema de identidad digital se basa en poseer un par de claves, pública y privada, junto al certificado x.509 asociado a la clave pública y emitido por una CA de la infraestructura. Por lo tanto hay que construir el modelo utilizando estos elementos.
- Todos los componentes, ya sean aplicaciones, peers o usuarios, deben disponer de una identidad digital autorizada en la infraestructura.
- El modelo de permisionado se basa en la gestión de certificados x.509 estándar, hay que tener cuidado con los datos que se eligen incluir en este tipo de certificados, ya que esta información es accesible por los distintos elementos de la infraestructura.
- Un usuario podría disponer de varias identidades digitales, asegurando el control sobre las mismas. Un modelo permisionado garantiza que una parte de la infraestructura conocerá la identidad del usuario, aunque quede oculta para el resto.
- Es crucial que el modelo de identidad digital implemente, no solo el proceso de onboarding al modelo, también el proceso de revocación de la capacidad para actuar en la solución a una identidad digital.
- Recuerda que estás en un entorno distribuido, en el que no existe un modelo centralizado de autorización, sino de consorcio de organizaciones, las cuales deben consensuar un modelo de identidad digital común.
4. Establece un modelo de gobernanza de la infraestructura
A diferencia de una infraestructura IT tradicional, en la que un equipo más o menos organizado de la compañía, se encarga de gestionar todo el ciclo de vida de la infraestructura, en las soluciones basadas en tecnología Blockchain, la infraestructura está gestionada por equipos de distintas organizaciones, lo que incrementa la complejidad.
El modelo de gobernanza de la infraestructura permite poner de acuerdo a varios equipos IT, en distintas organizaciones. Este modelo es necesario para que la solución pueda evolucionar al ritmo de las necesidades de las áreas de negocio. Recordemos que estas áreas de negocio, ya no quedan supeditadas a una sola compañía, son áreas con intereses comunes, pero que pertenecen a distintas organizaciones.
Las plataformas que implementan procesos distribuidos, como es el caso de Hyperledger Fabric, necesitan de un conjunto de reglas que definan el modelo de gobernanza. Estas reglas de gobierno, permiten a los administradores IT de las diferentes compañías, aprobar cambios en la infraestructura, como por ejemplo:
- Añadir nuevos participantes, por ejemplo, nuevas organizaciones que quieran participar en el proceso desplegado sobre la infraestructura Hyperledger Fabric.
- Generar nuevos canales (ledgers) y definir los participantes.
- Desplegar y actualizar smart contracts.
Si el modelo de gobernanza de la infraestructura no está bien diseñado, se podrían generar ciertos problemas en un futuro, relacionados por ejemplo con la disponibilidad de la propia plataforma. Un ejemplo típico de problema con el modelo de gobernanza, es que en una infraestructura se defina una política que necesite la aprobación de las tres organizaciones que participan, en el caso de que una de las organizaciones decida dejar de participar, inhabilitaría a las otras dos para poder continuar utilizando la plataforma.
Aunque el ejemplo anterior, sólo pretende ilustrar un caso en particular, puede servir para mostrar el daño, que un modelo de gobernanza equivocado, provocará en la solución.
Para construir un modelo de gobernanza de la infraestructura, debemos trabajar en dos niveles:
- Nivel consorcio, con el objetivo de establecer esas reglas que permitan a la plataforma estar operativa el mayor tiempo posible. En este nivel, se tienen que definir cómo la plataforma podrá evolucionar en el futuro y cuáles serán las reglas de convivencia de las distintas organizaciones.
- Nivel organización, es bastante frecuente, que cuando las compañías afrontan el despliegue o la incorporación a una plataforma basada en tecnología Blockchain, su aproximación sea la de tratar los componentes de la infraestructura IT, como elemento estáticos y externos a su core, aunque esta infraestructura gestione datos core para el negocio. Por tanto, es importante que las áreas de IT de la compañía sean capaces de incorporar a los componentes de la infraestructura Blockchain dentro de los procesos propios de la organización.
Los modelos de gobernanza de la infraestructura Blockchain deben estar orientados a:
- Cubrir todo el ciclo de vida de la infraestructura Blockchain.
- Automatizar todos los procesos de despliegue y configuración de componentes, desde nodos a smart contracts.
- Cubrir las necesidades de escalabilidad de los distintos servicios desplegados en la red Blockchain. Lo que hoy puede funcionar, quizás mañana no. Hay que analizar cómo la plataforma puede crecer y qué elementos son los que deberían estar monitorizados para poder absorber la carga que se demande.
- Construir estrategias para simplificar los procesos de onboarding a la plataforma. Debemos tener en cuenta, que cualquier elemento que vaya a participar de manera activa en la red Hyperledger Fabric, necesita de un permiso en formato certificado x.509. Por tanto, los procesos para la solicitud y generación de dichos certificados, deben estar lo suficientemente automatizados, para que los participantes puedan gestionarlos de manera sencilla y rápida.
- Desplegar infraestructura distribuida. No podemos olvidar nunca, la naturaleza distribuida de la tecnología que estamos utilizando, ya que esto nos ayudará a enfocar de manera correcta el modelo de gobernanza.
5. La seguridad se debe construir y mantener
Durante estos años, hemos tenido la oportunidad de participar en un buen número de proyectos diferentes, tanto en el tamaño como en la naturaleza del proyecto, distintos verticales con distintos enfoques. Pero todos o casi todos han tenido algo en común, la idea errónea de que por utilizar la tecnología Blockchain la solución es de por sí más segura que con tecnología tradicional.
La seguridad en las soluciones Blockchain es un tema que levanta cierta controversia, sobre todo cuando se tienen ciertas ideas preconcebidas en las que mezclamos conceptos como criptografía e inmutabilidad de la blockchain, lo que debe significar que la solución es segura. Las soluciones basadas en tecnología Blockchain necesitan ser construidas, con unos principios de diseño que permita cumplir con los requerimientos de seguridad que se esperan. Por sí sola la tecnología blockchain no es más segura que lo que podríamos hacer con tecnología tradicional. Es decir, la seguridad debemos construirla.
La tecnología Blockchain pone a disposición un conjunto de herramientas, que nos ayudan a construir soluciones seguras, pero insisto, la seguridad de la solución está directamente relacionado con el diseño que hayamos realizado de la misma. Las herramientas con las que contamos son:
- La firma digital de todas las operaciones.
- Todos los componentes deben disponer de un par de claves de curva elíptica, una clave privada y su clave pública.
- La trazabilidad de las operaciones que se realizan sobre la solución y que quedan registradas en la blockchain.
Esta es la base que utilizan la mayoría de las tecnologías Blockchain. Con esta herramientas y otras que debemos incorporar a las soluciones, podremos crear esquemas de seguridad robustos y confiables. Hyperledger Fabric dispone de unas cuantas funcionalidades que son especialmente interesantes para construir estos esquemas de seguridad.
- Multiledger, esto significa que en una misma infraestructura Hyperledger Fabric pueden estar conviviendo varios blockchains a la vez. ¿Por qué esta funcionalidad es interesante? Porque nos puede ayudar a organizar la información en distintos ledgers, permitiendo tener un control sobre en qué nodos de la infraestructura está almacenado un dato o las identidades que tienen acceso al dato. En Hyperldger Fabric se denomina canal a cada uno de estos ledgers independientes.
- A diferencia de otras tecnologías Blockchain, en Hyperledger Fabric, los smart contracts no se ejecutan en todos los nodos. Esto permite controlar qué nodos de la red pueden ejecutar los smart contracts para manipular los datos. Si los usuarios pueden decidir dónde ejecutar los Smart Contracts, podemos implementar funcionalidades de encriptado/desencriptado de datos dentro de los propios Smart Contracts. Esta característica permite a Hyperledger Fabric garantizar el control de acceso a los datos encriptados.
- Dentro de un canal todos los nodos tienen una copia entera del ledger. Pero existe una funcionalidad de Hyperldger Fabric que nos permite definir un dato como privado a una organización, lo que garantiza que ese dato solo estará almacenado en nodos de esa organización.
- Canal de transient, no es un canal como los que hemos comentado anteriormente, sino que se trata de una forma de pasar datos a un Smart Contracts de forma que dichos datos no formarán parte de la transacción que se almacenará en la blockchain. Esto nos permite hacer cosas como por ejemplo, enviar claves de encriptación/desencriptación por este canal de comunicación, para que el smart contract pueda acceder a los datos encriptados.
Algunos consejo generales para implementar buenas prácticas en nuestras soluciones Hyperledger Fabric:
- Diseñar un proceso confiable para la generación y custodia de las claves de curva elípticas que los usuarios, aplicaciones y componentes de la red blockchain deben poseer para poder operar con la solución.
- Utilizar claves simétricas para encriptar los datos, son más rápidas que los métodos asimétricos.
- Implementa permisos sobre los datos, construye ACLs (Access Control Lists) para gestionar los permisos de acceso de las identidades digitales, sobre datos y smart contracts.
- No trabajes con un solo ledger, construye arquitecturas que te permitan tener la información distribuida en distintos ledger, sobre los que poder aplicar políticas de acceso.
- No todo el mundo tiene que tener acceso a todo, ese modelo funciona para las criptos.
- Implementa métodos para validar las identidades en los smart contracts, te ayudará a evitar problemas de acceso.
- Trabaja siempre con datos encriptados, puede que esos datos que ahora solo ves tú, puedan terminar accesibles a terceros, sin que tenga control sobre ello.
- Implementa procesos para auditar las transacciones que reciben ciertos smart contracts. Esta monitorización te puede ayudar a descubrir comportamientos extraños.
- Cuidado con la caducidad de los certificados x.509 y los datos que metes en estos certificados.
- Utiliza componentes que te permita firmar sin la necesidad de acceder a la clave privada. Los HSM (Hardware Security Modules) son buenos aliados para gestionar credenciales críticas de la plataforma.
Conclusión
Con este post he pretendido describir las 5 principales recomendaciones que hacemos a los clientes cuando abordamos un proyecto de despliegue de una solución basada en Hyperledger Fabric. Los proyectos Blockchain en entornos permisionados son especialmente complejos, por una sola razón, hay que orquestar muchos componentes distintos, de distinta naturaleza, en distintas infraestructuras, pertenecientes a distintas organizaciones. Pero esta complejidad se reduce si partimos de una base clara y es que estamos construyendo sobre entornos distribuidos. Otra de las bondades de Hyperldger Fabric es su escalabilidad, no solo de carga, sino funcional, ya que podemos empezar con esquemas de arquitectura sencillos, en los que implementar los distintos modelos. Y poco a poco hacer crecer la infraestructura.
Siempre que hayamos entendido el propósito y los requerimientos de la solución, Hyperledger Fabric nos puede ayudar a implementar de manera gradual la plataforma. Por alguna razón es la tecnología Blockchain que más está creciendo dentro del entorno corporativo e institucional.
José Juan Mora Pérez
CTO & Founder
