Acepta lo inevitable: los datos locales persistentes en el borde de la red son una realidad

Es indiscutible que la inteligencia en el borde seguirá creciendo, ya sea en forma de aplicaciones móviles que se ejecutan en teléfonos inteligentes, aplicaciones de IoT que se ejecutan en coches inteligentes (o en los sensores subyacentes), centros de entretenimiento, sistemas de navegación, etc. Habrá innumerables escenarios móviles y de IoT —considerados en su conjunto, escenarios de borde— en los que una aplicación nativa será un enfoque mejor que una aplicación basada en web, o en los que resultaría ineficiente o potencialmente menos seguro enviar datos sin procesar desde los puntos de recopilación de IoT, en lugar de procesar los datos y almacenarlos o borrarlos localmente.

La complejidad de los procesos y los flujos de trabajo en el borde de la red, la capacidad de realizar análisis en el punto de acción y la necesidad de trabajar en modos sin conexión o con conexiones intermitentes son ejemplos de por qué necesitarás un almacenamiento de datos local y, por lo tanto, una base de datos local. Es evidente que los datos asociados a estas aplicaciones se multiplicarán.

Por desgracia, lo que resulta igualmente inevitable es que las vulnerabilidades de seguridad y los ataques oportunistas que se aprovechan de estas debilidades aumenten en el futuro inmediato. En los últimos años se han llevado a cabo varios estudios y encuestas que muestran claramente que existe un número mucho mayor de vulnerabilidades de seguridad en el software basado en el IoT y en los dispositivos móviles que en las plataformas de ordenadores de sobremesa o portátiles, más maduras, por no hablar del software que se ejecuta en los servidores de los centros de datos. No olvidemos que hace 10 años, cada brecha de seguridad en la nube generaba pánico y tal vez ralentizaba la adopción de los servicios en la nube. Es muy posible que esta sea la situación en la que nos encontramos ahora con la gestión de datos localizada e integrada para dispositivos periféricos.

Un ejemplo claro: este fin de semana se descubrió una vulnerabilidad de seguridad muy grave en SQLite y en la versión de SQLite integrada en Chromium (el núcleo de código abierto de Google Chrome). Aunque este no es el primer ni el mayor punto de vulnerabilidad potencial encontrado en la gestión de datos de código abierto —al fin y al cabo, el virus Heartbleed de 2014, que se aprovechó de OpenSSL, probablemente ostenta ambos récords—, dado que esta vulnerabilidad está asociada a SQLite, una base de datos casi omnipresente en aplicaciones nativas para móviles y basadas en la web, y a sus API, debemos prepararnos para la reacción instintiva: quizás los datos no deberían almacenarse localmente en dispositivos periféricos y todo debería hacerse en la nube, donde se supone que es más seguro (vaya, cómo han cambiado los tiempos).

Una reducción del personal sería una reacción exagerada

En primer lugar, SQLite es mucho mejor que una combinación de asignación de memoria temporal y sistemas de archivos planos, un enfoque que nunca recomendaría a nadie a quien considere un amigo. ¿Por qué? A diferencia de la asignación de memoria y el uso de archivos planos, que ofrecen poca estandarización, indexación integrada u otras funciones reales de manipulación de datos, SQLite proporciona una base de soporte de bases de datos para la inteligencia en el borde.

SQLite puede ejecutarse en un dispositivo para permitir un uso totalmente optimizado de los recursos informáticos locales, lo que permite a una aplicación gestionar los datos de forma local, al tiempo que ofrece el mismo conjunto de llamadas a la API para una versión web de esa misma aplicación, o incluso funciona tanto en los componentes nativos como en los web de una aplicación más compleja. Admite la mayoría de las llamadas a la API de SQL, por lo que también es estándar.

Llegar a un acuerdo sería una opción igualmente mala

Sin embargo, SQLite presenta muchos inconvenientes en comparación con una base de datos integrada comercial de nivel empresarial. En particular, no cuenta con cifrado integrado para los datos en reposo o en tránsito, y mucho menos con un nivel de 128 bits o superior. Además, solo se puede integrar en una única aplicación y en una única instancia, por lo que no se puede ampliar para dar soporte a múltiples usuarios que necesiten enviar o recibir datos desde esa imagen de SQLite.

Por ejemplo, si se instalara SQLite en una pasarela y luego varios dispositivos IoT conectados intentaran escribir datos en esa instancia de SQLite, no habría forma de gestionar que más de un cliente (dispositivo IoT conectado) escribiera en la base de datos SQLite al mismo tiempo —un requisito imprescindible en un entorno de IoT, donde a menudo hay decenas, cientos o incluso miles de dispositivos conectados—. Sin embargo, las bases de datos cliente-servidor son capaces de gestionar cientos o miles de clientes activos; por lo tanto, los usuarios de archivos planos y SQLite deben combinar siempre sus aplicaciones que envían o reciben datos con MS SQL, mySQL, Oracle o alguna otra base de datos cliente-servidor. Esta combinación garantiza que el reformateo de datos o el proceso ETL (Extract, Transform, Load) sea un mal necesario.

Hay tres inconvenientes principales del ETL con los que, según hemos observado, se enfrentan la mayoría de los arquitectos y desarrolladores de datos: el coste de la integración, el rendimiento y la seguridad de los datos. Dejaré el tema del coste y las pérdidas de rendimiento para otra entrada del blog, pero merece la pena abordar aquí la seguridad de los datos. A falta de una arquitectura única que abarque la gestión de bases de datos tanto en el lado del cliente como en el del servidor, incluso si contases con cifrado integrado, no tendrías más remedio que descifrar y volver a cifrar para poder realizar las funciones de ETL, aunque no tuvieras que realizar ninguna otra manipulación de datos. La necesidad de descifrar implica que tus cargas de datos quedan expuestas —aunque sea temporalmente— a los piratas informáticos.

Una forma óptima de gestionar los datos de forma segura en el perímetro

La familia de bases de datos Actian Zen se basa en una arquitectura única, escalable y segura que permite a Zen ejecutarse en máquinas virtuales en la nube y en prácticamente cualquier entorno operativo, desde Windows, Linux y Mac OS —como una base de datos cliente-servidor completa— hasta Windows IoT Core, distribuciones de Raspbian Linux, Android e iOS —como una plataforma de gestión de datos en el borde, reducida a 2 MB y exclusivamente para clientes—. Dado que Actian Zen se ejecuta en prácticamente cualquier entorno con API totalmente transferibles (se puede utilizar SQL directamente o API NoSQL/SQL mediante programación desde los lenguajes de programación más populares), motor y almacenamiento de archivos subyacente, no requiere ETL. Además, cuenta con cifrado de 192 bits tanto en reposo como en tránsito, lo que elimina los costes de integración y las vulnerabilidades de seguridad de los datos, al tiempo que mejora el rendimiento.

Resumen

En lo que respecta a SQLite y a las recientes vulnerabilidades de seguridad descubiertas, la respuesta debe consistir en subsanar dichas vulnerabilidades y reducir el riesgo, ya sea corrigiendo SQLite o adoptando una solución de clase empresarial superior, como Actian Zen. La solución no pasa por evitar o limitar drásticamente el almacenamiento de datos en dispositivos locales. Estas restricciones frenarán la innovación y la mejora de los resultados que, sin duda, se derivarán de la inteligencia integrada en el punto de acción. La seguridad en la nube ha experimentado notables mejoras porque los proveedores, los clientes del sector y los organismos de normalización, así como el gobierno (especificaciones del NIST, FEDRamp, etc.), han asumido el reto, en lugar de volver a los entornos heredados. Siempre habrá riesgo, pero la clave está en gestionar ese riesgo pasando de comprobaciones de seguridad estáticas, reactivas y periódicas a un enfoque de diagnóstico y supervisión continuos y basados en el riesgo. No espere menos con el tiempo en lo que respecta a la seguridad de los datos móviles y del IoT, ya que los proveedores —como Actian— colaboran para ayudar a los clientes a mantener la tranquilidad y a proteger sus datos en el perímetro.

Si está listo para reconsiderar SQLite, obtenga más información sobre Actian Zen. También puede probar Zen Core, que está libre de derechos de autor para el desarrollo y la distribución.