Usuarios IoT: gestionar la identidad de los miles de millones de objetos conectados
Durante décadas, la gestión de las identidades digitales en las empresas se refirió principalmente a las personas. Un empleado recibe una cuenta cuando se incorpora a la organización, obtiene accesos correspondientes a su rol, ve evolucionar sus permisos cuando cambia de función y normalmente pierde sus accesos cuando deja la empresa. Esta gestión del ciclo de vida constituye hoy uno de los fundamentos de la ciberseguridad.
El Internet de las cosas cambia considerablemente la escala del problema. Sensores, cámaras, vehículos, máquinas industriales, equipos médicos, sistemas energéticos y otros dispositivos conectados deben ahora ser reconocidos por las infraestructuras con las que se comunican. Deben poder demostrar su identidad, acceder a los recursos necesarios para su función y ser impedidos de utilizar aquellos que no les están destinados. Sus permisos también deben poder evolucionar o ser revocados durante toda su vida útil.
A esta población de equipos se suman las aplicaciones, las API, los servicios automatizados y ahora los agentes de inteligencia artificial. Una empresa digital puede, por lo tanto, administrar progresivamente muchas más identidades no humanas que identidades humanas.
Este cambio puede parecer esencialmente técnico. Sin embargo, es fundamental. Cuando una máquina posee una identidad, permisos y una capacidad de actuar, se convierte en un participante de la infraestructura digital. La gestión de las identidades ya no puede, por lo tanto, organizarse principalmente en torno a una sola pregunta: “¿Quién es este usuario?”
Ahora debe responder continuamente a una pregunta mucho más amplia: ¿qué es lo que intenta acceder a nuestros sistemas y qué estamos dispuestos a permitirle hacer?
Un dispositivo conectado encuentra un problema comparable al de un usuario humano cuando desea acceder a un recurso. Cuando un sensor transmite datos a una plataforma, esta debe poder determinar que se trata realmente del dispositivo esperado. Cuando una máquina solicita una configuración o un vehículo se comunica con un servicio remoto, la infraestructura debe ser capaz de establecer la legitimidad de esa comunicación.
Una simple dirección de red no constituye una identidad suficientemente confiable. Puede cambiar, ser imitada o aportar únicamente una información muy limitada sobre el equipo que se comunica. Distintos mecanismos permiten, por lo tanto, asociar más sólidamente una identidad digital al dispositivo: certificados, claves criptográficas, módulos seguros, mecanismos de aprovisionamiento o identidades asociadas a ciertas infraestructuras de conectividad.
Esta identidad constituye, no obstante, el comienzo de la relación de confianza y no su culminación.
Un sistema puede establecer con un alto nivel de confianza que un dispositivo posee efectivamente la identidad que dice tener, sin tener que aceptar automáticamente todas sus acciones. Un dispositivo legítimo puede ser comprometido. Su software puede contener una vulnerabilidad, una clave puede haber quedado expuesta o su comportamiento puede volverse de repente incompatible con su función habitual.
Esta distinción entre autenticación y autorización se vuelve fundamental. La identidad permite determinar quién o qué solicita un acceso. Las políticas de seguridad determinan luego lo que esa identidad puede realmente realizar en un contexto preciso.
Un sensor encargado de transmitir una temperatura no tiene ninguna razón para acceder al conjunto de la red de la empresa. Una cámara puede tener que transmitir imágenes hacia un servicio determinado sin poder consultar otros sistemas. Un equipo industrial puede recibir ciertas órdenes operativas y permanecer al mismo tiempo aislado de las funciones administrativas a las que no tiene ninguna razón de acceder.
La identidad se convierte así en el punto de partida del mínimo privilegio. El reto adquiere, sin embargo, una dimensión completamente diferente cuando el número de dispositivos aumenta. Una empresa de algunos miles de empleados puede dedicar ya recursos considerables a la gestión de sus cuentas, roles y permisos. Una organización que opera decenas o centenas de miles de dispositivos debe gestionar una población digital de una magnitud muy distinta.
Cada dispositivo puede poseer una identidad distinta, una versión de software particular, autorizaciones precisas y una relación específica con diferentes sistemas. Algunos dispositivos se añaden, otros se reemplazan. Pueden cambiar de ubicación, de propietario o de función. Algunos se averían, son comprometidos o deben ser desactivados.
Una gestión esencialmente manual se vuelve rápidamente imposible. La identidad de máquina debe, por lo tanto, diseñarse desde el principio para funcionar a gran escala. El aprovisionamiento, la renovación de los secretos, la modificación de los permisos y la revocación deben poder automatizarse conservando al mismo tiempo suficiente control y trazabilidad para comprender con precisión lo que ocurre. Una arquitectura capaz de administrar cien dispositivos no se convierte automáticamente en una arquitectura capaz de administrar cien mil.
Esta escala obliga también a pensar la identidad como un ciclo de vida. Una identidad digital nunca debería considerarse permanente simplemente porque pertenece a una máquina. Cuando se fabrica un dispositivo, debe crearse o establecerse una identidad inicial. En el momento del despliegue, debe asociarse a un entorno, un cliente, una organización o una función. Sus permisos pueden luego evolucionar durante varios años.
El dispositivo puede cambiar de propietario o de sitio. Puede asignársele una nueva función. Sus claves criptográficas deberán eventualmente renovarse y sus certificados expirarán. Una vulnerabilidad o un incidente de seguridad puede exigir la revocación inmediata de ciertos accesos. Y llegará finalmente el momento en que el equipo sea retirado del servicio.
La manera en que su identidad desaparece se vuelve entonces tan importante como aquella en que fue creada. Un dispositivo desechado que conserva credenciales válidas puede convertirse en una puerta de entrada hacia sistemas que siguen considerándolo legítimo.
Esta cuestión se vuelve particularmente compleja cuando los dispositivos poseen una vida útil de diez o quince años. Las tecnologías de identidad y de criptografía utilizadas en el momento de su fabricación pueden tener que evolucionar varias veces durante su explotación. Una arquitectura robusta debe, por lo tanto, prever desde su diseño la posibilidad de renovar las credenciales, modificar los permisos y reemplazar ciertos mecanismos criptográficos.
El aprovisionamiento inicial constituye también una etapa crítica. Un dispositivo puede fabricarse varios meses antes de su instalación, pasar por distintos intermediarios y ser finalmente desplegado en un entorno desconocido para el fabricante en el momento de su producción. Inscribir de forma duradera credenciales sensibles en el software o utilizar secretos estáticos crea entonces riesgos importantes.
El uso compartido de un mismo secreto entre varios equipos puede ampliar considerablemente las consecuencias de un compromiso. El uso de un secreto diferente para cada dispositivo mejora la separación, pero impone luego la capacidad de gestionar potencialmente millones de credenciales durante varios años.
Enfoques más dinámicos permiten utilizar la identidad inicial del equipo para establecer una primera relación de confianza y obtener después las credenciales y permisos realmente necesarios para su entorno operativo. El dispositivo no necesita así conservar de forma permanente todas las claves que dan acceso directo a cada plataforma que podría utilizar.
La identidad se convierte entonces menos en una caja fuerte que contiene todas las claves que en un mecanismo que permite obtener la autorización apropiada cuando es necesaria. Este diseño conecta directamente con el principio del Continuous Trust. En una infraestructura distribuida, la identidad permite iniciar la relación, pero la confianza debe poder evolucionar con el contexto. Un dispositivo correctamente autenticado ayer puede haber cambiado de estado hoy. Su configuración, su ubicación, su comportamiento, su versión de software o su nivel de riesgo pueden justificar una decisión diferente.
La confianza se vuelve, por lo tanto, continuamente verificada y reevaluada en lugar de definitivamente adquirida. Esta capacidad posee también una dimensión de soberanía digital. ¿Quién controla la identidad de un dispositivo? ¿Quién puede modificarla o revocarla? ¿Está íntimamente ligada a un proveedor particular? ¿Puede seguir funcionando si la organización cambia de red, de plataforma o de proveedor de nube?
Estas preguntas adquieren una importancia considerable cuando los dispositivos permanecen en servicio durante una década o más. Una empresa puede cambiar varias veces de estrategia tecnológica durante ese periodo. Puede migrar hacia otra infraestructura de nube, modificar sus sistemas de gestión, cambiar de operador o tener que satisfacer nuevas exigencias regulatorias.
Si la identidad de toda una flota depende profundamente de una infraestructura prácticamente imposible de reemplazar, los dispositivos mismos se convierten en una fuente de dependencia tecnológica. Preservar la capacidad de hacer evolucionar las identidades, los permisos y las relaciones de confianza contribuye, por lo tanto, directamente a preservar la capacidad de elegir.
Los dispositivos IoT representan, sin embargo, solo una parte de esta transformación. Las organizaciones poseen ya numerosas identidades técnicas asociadas a las aplicaciones, a los servicios, a las API y a las automatizaciones. La llegada de los agentes de IA amplía aún más esta población porque estos sistemas pueden consultar varias fuentes de información, utilizar aplicaciones y desencadenar acciones en nombre de un proceso o de un equipo.
Un agente puede tener que consultar un CRM, acceder a una base documental, preparar una transacción o desencadenar una operación en otro sistema. Necesita, por lo tanto, una identidad y permisos claramente definidos.
Esta situación plantea una pregunta importante: ¿debe el agente utilizar la identidad del empleado que lo lanzó o poseer su propia identidad? Una identidad distinta permite generalmente una gobernanza mucho más precisa. La organización puede definir exactamente lo que el agente está autorizado a hacer, seguir sus acciones y revocar sus permisos independientemente de los del usuario humano.
Esta separación se vuelve particularmente importante cuando varios agentes colaboran entre sí o empiezan a interactuar con dispositivos IoT.
Imaginemos una infraestructura industrial en la que un sensor detecta una situación. Los datos se transmiten a una plataforma donde un agente de IA los analiza, consulta el historial de la máquina y determina que es necesaria una intervención. Una instrucción se transmite luego a un sistema de control que modifica ciertos parámetros de funcionamiento.
Varias identidades participan entonces en una sola cadena de acción: el sensor que produjo la información, la plataforma que la recibió, el agente que la interpretó, el sistema que solicitó la intervención, el equipo que la ejecutó y eventualmente el empleado que supervisaba el proceso.
La organización debe poder reconstruir esa cadena. Debe saber qué identidad produjo la información, cuál tomó o recomendó una decisión, cuál solicitó la acción y qué sistema la ejecutó finalmente. A medida que los sistemas se vuelven autónomos, saber quién — o qué — hizo qué se convierte en una propiedad esencial de la seguridad, de la gobernanza y de la responsabilidad.
Esta multiplicación de las identidades no humanas aumenta inevitablemente el número de objetivos potenciales. Una arquitectura resiliente no puede, por lo tanto, basarse en la hipótesis de que ninguna identidad será jamás comprometida. Debe limitar las consecuencias cuando un compromiso ocurre.
Si un sensor es comprometido, su identidad solo debería permitir acceder a los recursos necesarios para su función. Si un agente de IA es desviado de su propósito, sus permisos deberían impedirle actuar más allá de su mandato. Si una clave queda expuesta, debe poder ser revocada y reemplazada rápidamente.
Es aquí donde se encuentran el IAM, el mínimo privilegio, la segmentación, el Zero Trust y el Continuous Trust. El objetivo consiste en evitar que una identidad legítima pueda convertirse en una llave maestra que permita desplazarse libremente por el entorno digital.
Esta transformación conlleva también una necesidad mucho más fundamental: las organizaciones deberán saber qué identidades existen.
El inventario de los dispositivos ya no basta. ¿Cuántas identidades de máquina están activas? ¿A qué sistemas dan acceso? ¿Quién es responsable de ellas? ¿Cuándo fueron creadas? ¿Qué certificados y mecanismos criptográficos utilizan? ¿Cuándo deben renovarse? ¿Corresponden algunas identidades a equipos que ya no están en servicio?
Estas preguntas resultan particularmente importantes desde una perspectiva de transición criptográfica. Una organización que debe reemplazar un mecanismo de cifrado o de firma debe conocer los dispositivos, certificados, aplicaciones y sistemas que dependen de él. La identidad de máquina se conecta así directamente con la criptoagilidad y la preparación poscuántica.
Una empresa que ignora dónde se encuentran sus identidades y sus dependencias criptográficas encontrará inevitablemente más dificultades cuando deba hacerlas evolucionar.
Esta evolución nos lleva finalmente a reconsiderar el papel mismo de la identidad en la arquitectura informática. A medida que los sistemas se vuelven distribuidos, la red física pierde una parte de su papel histórico como frontera de confianza. Un dispositivo puede estar conectado por red celular, satélite, Wi-Fi o Ethernet. Un agente puede funcionar en una nube pública, una infraestructura privada o directamente en el Edge.
La ubicación ya no basta para establecer la confianza. La identidad se convierte entonces en uno de los mecanismos que permiten mantener una política coherente a través de esos entornos. Un sistema puede reconocer a un ser humano, un dispositivo, una aplicación o un agente, verificar su contexto y aplicarle los permisos apropiados independientemente del lugar donde se encuentre.
La identidad se convierte progresivamente en una infraestructura en sí misma.
Ya no es simplemente el mecanismo que permite a un empleado iniciar sesión por la mañana. Se convierte en uno de los cimientos que permiten a personas, máquinas, aplicaciones e inteligencias artificiales trabajar juntas conservando exactamente el nivel de autoridad necesario para su rol.
Las organizaciones entran en un periodo en el que las identidades digitales ya no representarán principalmente a personas. Representarán también sensores, máquinas, vehículos, aplicaciones, API, servicios automatizados y agentes de inteligencia artificial. En ciertas organizaciones, esta población no humana podría superar rápidamente y con amplitud el número de empleados.
La gestión de estas identidades se convierte, por lo tanto, en una disciplina estratégica. Cada dispositivo y cada agente debe poder ser reconocido, autenticado, limitado a su rol, supervisado durante toda su vida útil y revocado cuando ya no deba acceder a los sistemas. Esta gobernanza deberá funcionar a muy gran escala conservando al mismo tiempo suficiente precisión para determinar qué identidad realizó qué acción.
Esta evolución constituye igualmente uno de los fundamentos de la Hiperseguridad. Cuando las infraestructuras se vuelven distribuidas e inteligentes, la confianza ya no puede depender principalmente de la ubicación en la red. Debe basarse en identidades conocidas, permisos controlados, un contexto evaluado continuamente, interacciones trazables y una capacidad de contener rápidamente las consecuencias de un compromiso.
En Quantum Beyond, esta transformación conecta directamente con nuestros trabajos en arquitectura de seguridad, IAM, Zero Trust, Continuous Trust, Q-Carbon Security Systems, infraestructuras Edge, gobernanza de los agentes de IA y preparación criptográfica. Nuestros expertos trabajan junto a los equipos de tecnología y de ciberseguridad con el fin de reforzar las arquitecturas existentes, estructurar las relaciones de confianza y preparar a las organizaciones para gestionar entornos donde las identidades humanas pronto representarán solo una parte del ecosistema digital.
Durante mucho tiempo, la ciberseguridad buscó principalmente responder a una pregunta: “¿Es realmente la persona correcta?”
En una infraestructura donde trabajan juntos seres humanos, objetos, aplicaciones y agentes inteligentes, la pregunta se vuelve más exigente: “¿Es realmente la persona correcta, la máquina correcta o el agente correcto, en el contexto correcto, y posee exactamente el nivel de autoridad necesario para realizar esta acción?”