Existen una serie de necesidades y requerimientos que son específicos para una arquitectura IoT. Los dispositivos del internet de las cosas tienen sus propias características. Permiten tener nuevas funcionalidades, pero también son dispositivos con una potencia muy limitada y con diferentes capacidades físicas. Todo ello, hace que tengamos que tener en cuenta una serie de cuestiones a las que no prestaríamos atención en otro tipo de arquitectura.
En este artículo veremos esos requerimientos y encontraremos varias buenas prácticas para la conectividad que debemos de tener en cuenta.
Conectividad y comunicación
HTTP es un protocolo muy común y útil para muchos dispositivos. HTTP puede ofrecer una conectividad unificada y uniforme incluso en controladores de 8-bits para crear solicitudes de GET y POST. Pero la sobrecarga de este y otros protocolos tradicionales pueden ser un problema por dos razones principales.
“Los protocolos tradicionales, como HTTP, pueden suponer un problema para los dispositivos IoT”
En primer lugar, el tamaño de la memoria del programa, puede suponer un inconveniente en dispositivos pequeños. De cualquier forma, el problema más conflictivo viene en segundo lugar: HTTP tiene altos requerimientos de energía. Para solventar esta problemática necesitaremos un protocolo binario pequeño y simple con habilidad para superar firewalls.
Otra cosa que debemos de tener en cuenta, es que existen dispositivos que se conectan directamente a la red y otros que lo hacen a través de gateways. No nos podemos olvidar, que estos últimos, requieren dos protocolos: uno para conectarse al gateway y otro para conectarse del gateway a la nube.
Para que nuestros dispositivos IoT tengan la mejor comodidad, deberemos crear un puente entre transporte y protocolo. Por ejemplo, podríamos querer ofrecer un protocolo binario al dispositivo, pero contar con un API basado en HTTP para el control del dispositivo que exponemos a terceros.
Gestión de dispositivos
Actualmente, muchos de los dispositivos IoT no están controlados ni gestionados activamente. Esto puede ser un error. Cada vez son más los dispositivos que controlamos de manera activa (como ordenadores o móviles) y lo más probable, y adecuado, es que los instrumentos IoT también sigan esta tendencia. Pero, ¿cuáles son los requerimientos para la gestión de este tipo de dispositivos? En la siguiente lista repasaremos algunos ejemplos de qué nos permitiría un dispositivo gestionado remotamente:
- La posibilidad de desconectar un dispositivo robado
- La habilidad de actualizar el software de un dispositivo
- La actualización de credenciales de seguridad
- Autorizar o denegar algunas capacidades del hardware remotamente
- Localizar dispositivos perdidos
- Limpiar información confidencial de un dispositivo robado
- Reconfigurar parámetros de Wi-Fi, GPRS u otras redes remotamente.
Todas estas funcionalidades no son necesarias en todas las arquitecturas. Habrá casos en que muchas no tengan ninguna utilidad para nosotros, y habr
Recolección, análisis y actuación de los datos
Ciertos dispositivos tienen algún tipo de interfaz de usuario (UI), pero en general los dispositivos IoT están centrados en ofrecer sensores, actuadores o una combinación de ambos. El requerimiento principal del sistema es que podamos recolectar datos e información desde una multitud de dispositivos y poder almacenarla, analizarla y actuar sobre esta información.
“El requerimiento principal del sistema es que podamos recolectar y gestionar datos”
Una buena arquitectura debe de estar diseñada para que podamos gestionar o manejar un número amplio de dispositivos. Si estos dispositivos emiten información de forma constante, estaremos generando una gran cantidad de datos. A la hora de pensar en una arquitectura, deberemos de pensar en un sistema de almacenamiento escalable, capaz de gestionar datos con un gran volumen y de diversos tipos.
Además, en muchas ocasiones, es posible que queramos acceder y manejar los datos casi en tiempo real. Por otra parte, el dispositivo necesita ser capaz de analizar y actuar sobre la información que recolecta. En algunos casos, bastará con una lógica integrada para cumplir este propósito. En los dispositivos más potentes podremos utilizar motores más eficaces para procesar eventos y acciones.
Escalabilidad
Idealmente, una arquitectura en el servidor debería de ser altamente escalable y capaz de soportar millones de dispositivos que envían, reciben y actúan sobre datos constantemente. De cualquier forma, muchas arquitecturas altamente escalables también tienen altos costes, tanto en su complejidad, como en el coste de su software y hardware.
Un requerimiento importante para una arquitectura es que pueda ser escalada y que pueda ir de soportar una integración pequeña a soportar un gran número de dispositivos. Es esencial contar con una escalabilidad elástica y la habilidad de desarrollar en una infraestructura Cloud. También es un requisito el poder escalar el servidor en servidores económicos para poder conseguir una arquitectura asumible.
Seguridad
La seguridad es el aspecto más importante del IoT. En muchas ocasiones los dispositivos IoT recolectan un gran número de información personal. Por su función de llevar el mundo real a internet (y viceversa), hace que nos encontremos con tres categorías de riesgo:
- Riesgos inherentes de cualquier sistema de internet pero que los diseñadores IoT o de producto no tengan consciencia de ellos.
- Riesgos específicos de los dispositivos IoT
- Seguridad para cerciorarnos de que no se causan daños por, por ejemplo, por el mal uso de los actuadores.
La primera categoría incluye cosas simples como el bloque de los puertos abiertos de los dispositivos. Como por ejemplo, un congelador conectado a la red que tiene un SMTP inseguro y estaba siendo usado para mandar spam.
La segunda categoría incluye cuestiones relacionadas específicamente con el hardware IoT. Por ejemplo, muchos dispositivos IoT son demasiado pequeños para soportar una encriptación asimétrica. Otro ejemplo específico es la habilidad que pudiera tener alguien para atacar un hardware para entender su seguridad.
“La gestión de identidades y accesos es una cuestión primordial para la seguridad. Pero encontramos muchas malas prácticas.”
Dos cuestiones específicas muy importantes de la seguridad IoT son las preocupaciones sobre la gestión de identidades y de accesos. La identidad es una cuestión sobre la que habitualmente encontramos implementaciones con malas prácticas. Por ejemplo, el uso de contraseñas codificadas con texto/Base64 con dispositivos y M2M es un error común. Lo ideal, sería remplazarlas con tokens gestionados, como los que provee OAuth/OAuth2.
Otro problema común es el hacer una gestión de accesos con hardcode en el lado de los servicios o en el del cliente. Un enfoque mucho más flexible y potente es el de usar modelos, como un control de acceso basado en atributos o un control de acceso basado en políticas. De estos enfoques, los más conocidos son los estándares de XACL[1]. Estos enfoques eliminan las decisiones del control de acceso de la lógica hardcode y externalizarlos en políticas que posibilitan lo siguiente:
- Más decisiones potentes y apropiadas;
- Pueden estar basados en algún contexto como por ejemplo la localización, la red que se está utilizando o la hora del día,
- El control de acceso puede ser analizado y auditado; y
- Las políticas pueden ser actualizadas y cambiadas, incluso dinámicamente sin codificar ni modificar dispositivos.
Nuestros requerimientos de seguridad entonces deben de soportar;
- Encriptación en aquellos dispositivos que son lo suficiente potentes.
- Un modelo de identidades basado en tokens moderno y no una contraseña/usuario
- Una gestión de tokens y accesos lo más remota y fácil posible; y
- Control de accesos basados en políticas y con gestión de usuarios para sistemas basados en XACML.
Como hemos visto, trabajar con dispositivos IoT puede significar que tengamos que incluir requerimientos extra en el servidor. Con esto concluimos el conjunto de requerimientos que hemos identificado para una arquitectura de referencia. Obviamente, a cualquier arquitectura se le pueden añadir más requerimientos. Algunos de estos requerimientos es posible que pueda que no sean necesarios en nuestro caso, mientras que en otros casos necesitaremos añadir más componentes.
[1] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
