El control de acceso basado en roles (RBAC) es una forma de gestionar permisos en la que los derechos se conceden a roles, como «instalador» u «observador», y después se asigna a las personas a esos roles, en lugar de conceder cada derecho a cada persona uno por uno. Cuando alguien cambia de puesto, se le cambia el rol y los permisos lo siguen automáticamente.

Parece un detalle técnico de informática hasta que el sistema en cuestión controla equipos físicos. En un edificio o una planta conectados, el inicio de sesión que abre un gráfico de temperatura también podría permitir editar una automatización, borrar un dispositivo o enviar un comando a una válvula. Quién tiene cuál de esos derechos es una decisión de seguridad física tanto como de ciberseguridad, y se complica con cada compañero, contratista y cliente al que invita.

Lo esencial

  • El RBAC agrupa los permisos en roles y asigna a las personas a roles, de modo que el acceso siga siendo manejable a medida que crece un equipo.
  • El mínimo privilegio significa que cada persona y cada integración reciben solo los derechos que necesita su trabajo, empezando desde cero.
  • En los sistemas conectados, los permisos de riesgo son los que cambian cosas: automatizaciones, ajustes de dispositivos y comandos.
  • Una plataforma multiinquilino añade un límite exterior que impide que cada cliente vea los datos de los demás.

Ejemplos de control de acceso basado en roles

El modelo se ve mejor en una instalación de aspecto realista. Tomemos una empresa de servicios que supervisa 40 edificios de oficinas con sensores de temperatura, de fugas y de puertas. Cinco tipos de personas necesitan acceso, y cada uno necesita algo distinto. Escrito en forma de roles, podría quedar así:

Rol Dispositivos Paneles Automatizaciones y alarmas Comandos de dispositivos Usuarios y facturación
Instalador Editar Ver Ninguno Enviar Ninguno
Responsable de instalaciones Ver Editar Editar Enviar Ninguno
Contacto del inquilino Ninguno Ver, solo su propio edificio Ninguno Ninguno Ninguno
Ingeniero de soporte Editar Editar Editar Enviar Ninguno
Titular de la cuenta Editar Editar Editar Enviar Editar

Esa tabla es toda la idea del RBAC. En lugar de mantener decenas de listas de permisos individuales, se mantienen cinco filas. Un nuevo instalador recibe el rol de Instalador el primer día y puede registrar hardware sin tocar la facturación. Cuando el instalador se marcha, retirar ese único rol lo retira todo a la vez, lo que evita un problema conocido: cuentas que sobreviven al trabajo para el que se crearon.

El enfoque tiene una historia documentada. David Ferraiolo y Richard Kuhn, del Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST), describieron el control de acceso basado en roles en 1992, y un modelo unificado del NIST se convirtió más tarde en la norma ANSI INCITS 359-2004. El NIST describe el RBAC como el modelo predominante de control de acceso avanzado, y muchas implementaciones añaden jerarquías de roles, en las que un rol superior hereda todo lo que puede hacer un rol inferior.

Pero fíjese otra vez en la fila Contacto del inquilino. «Solo su propio edificio» no encaja bien en un rol. Con 40 edificios, el RBAC puro le empuja hacia 40 roles: Contacto del inquilino del edificio 1, Contacto del inquilino del edificio 2, y así sucesivamente. Los administradores llaman a esto explosión de roles, y es la razón principal por la que los modelos de acceso han ido más allá de los roles por sí solos, como explica la comparación más abajo.

¿Qué es el principio de mínimo privilegio?

El principio de mínimo privilegio dice que cada usuario y cada programa deben funcionar con el conjunto de permisos más pequeño que les permita hacer su trabajo. Jerome Saltzer y Michael Schroeder lo formularon en esos términos en su artículo de 1975 sobre la protección de la información en los sistemas informáticos, y desde entonces es un principio de diseño.

Los roles organizan los permisos, y el mínimo privilegio decide qué tamaño debe tener cada rol. Un rol de «Operador» que además incluye borrar dispositivos sigue el modelo RBAC, pero concede más de lo que requiere el trabajo de un operador.

El principio importa más de lo habitual en los equipos conectados porque los permisos tienen tres intensidades distintas. Leer datos es la más suave. Cambiar la configuración, como un umbral o una automatización, es más fuerte, porque un cambio erróneo puede ocultar un problema real. Enviar comandos es la más fuerte, porque mueve algo en el mundo físico. Un buen diseño de roles mantiene separadas estas tres, de modo que la mayoría de las personas lean, menos personas configuren y solo quienes necesitan actuar puedan enviar comandos.

El mínimo privilegio también se aplica a las máquinas. Piense en un script de informes que copia cada mañana en una hoja de cálculo las lecturas de sensores del día anterior. Si se ejecuta con las credenciales de un administrador y ese token acaba filtrado en un repositorio de código compartido, quien lo encuentre puede cambiar automatizaciones y enviar comandos. Si se ejecuta con una clave de solo lectura limitada a las lecturas, la misma filtración expone datos, pero no puede tocar los equipos.

El OWASP Top 10, la clasificación más conocida de riesgos de seguridad de las aplicaciones web, situó la pérdida de control de acceso (broken access control) en primer lugar en su edición de 2021 y lo mantuvo ahí en la edición de 2025. Las plataformas IoT son aplicaciones web, así que la lección se traslada directamente.

Para aplicar el mínimo privilegio a una instalación que ya existe, puede seguir este orden:

  1. Haga una lista de todas las cuentas de personas y todas las credenciales de integraciones, incluidas las que nadie recuerda haber creado.
  2. Escriba una frase que describa para qué sirve cada una.
  3. Retire todos los permisos que esa frase no requiera.
  4. Separe los derechos de lectura, configuración y comandos siempre que el software lo permita.
  5. Ponga fecha de caducidad a las cuentas de contratistas y a las claves de integración.
  6. Repita la revisión con una periodicidad fija, por ejemplo cada trimestre, y siempre que termine un proyecto o un contrato.

Control de acceso basado en roles frente a basado en atributos

El control de acceso basado en atributos (ABAC) toma cada decisión a partir de atributos del usuario, del recurso, de la acción y, a veces, del entorno, en lugar de solo a partir de un rol. La guía del NIST sobre ABAC, la Special Publication 800-162, se publicó en 2014. Una política ABAC típica se lee como una frase: «un contacto del inquilino puede ver los paneles del edificio que figura en su perfil». Una sola política sustituye a los 40 roles de inquilino del ejemplo anterior.

La contrapartida es la visibilidad. Con RBAC, la pregunta de auditoría «¿quién puede enviar comandos?» tiene una respuesta sencilla: todos los que tienen los roles que incluyen ese derecho. Con ABAC, la respuesta depende de combinar políticas y atributos, así que conviene contar con buenas herramientas. Por otro lado, ABAC se adapta mucho mejor a las formas que adoptan las organizaciones reales: muchos emplazamientos, muchos clientes, personas que son dueñas de algunos recursos y solo observan otros.

En la práctica, la mayoría de los sistemas modernos mezclan los dos. Los roles se mantienen como etiquetas legibles, mientras que atributos como la organización, la propiedad y el emplazamiento deciden el alcance exacto. Si está eligiendo un modelo para una instalación que crece, la pregunta útil es si el sistema le permite acotar el acceso por emplazamiento o por cliente sin inventar un rol nuevo cada vez.

¿Qué es el control de acceso en IoT?

Control de acceso IoT es una expresión con dos significados, así que conviene separarlos. En el sector de la seguridad de edificios, significa control de acceso físico: lectores de tarjetas, controladores de puertas y los sistemas que deciden quién puede entrar en una sala. Este artículo usa el otro significado: controlar quién y qué puede llegar a los dispositivos conectados, a sus datos y a sus controles.

Ese segundo tipo de control de acceso tiene más capas que una aplicación de oficina. Cada dispositivo necesita su propia identidad y sus propias claves, para que una clave robada no abra toda la flota. Si 200 sensores comparten una clave y alguien arranca una sola unidad de la pared y lee su memoria, quedan expuestos los 200; con una clave por dispositivo, el daño se queda en esa unidad. La red decide qué sistemas pueden siquiera comunicarse con los dispositivos. La plataforma decide qué personas pueden ver lecturas, editar automatizaciones o enviar comandos. Las integraciones y los scripts necesitan sus propias credenciales con alcance limitado. Y, cada vez más, los agentes de IA consultan dispositivos y envían comandos en nombre de una persona, algo que solo sigue siendo seguro cuando el agente queda sujeto a los permisos de esa persona en lugar de recibir una llave maestra.

El control de acceso es también la principal herramienta de trabajo para la privacidad de los datos IoT. Las lecturas de sensores parecen inofensivas, pero describen comportamientos. Los datos de ocupación y de puertas muestran cuándo está vacía una oficina. El historial de un localizador GPS muestra dónde pasa la noche aparcado un vehículo, lo que a menudo significa dónde vive su conductor. El Reglamento General de Protección de Datos (RGPD) de la UE exige en su artículo 25 la protección de datos por defecto, incluido que los datos personales no sean accesibles, sin la intervención de la persona, a un número indeterminado de personas. En una instalación conectada, eso se traduce directamente en quién puede abrir qué panel y qué historial.

¿Qué es una plataforma IoT multiinquilino?

Una plataforma IoT multiinquilino atiende a varios clientes independientes, o inquilinos, desde una sola instalación, y mantiene separados los dispositivos, los datos y los usuarios de cada inquilino. El límite del inquilino queda fuera de cualquier rol: un responsable de instalaciones de un inquilino no debería tener ninguna forma de descubrir siquiera que existe otro inquilino.

Antes de confiar en el límite entre inquilinos de cualquier plataforma, pruébelo usted mismo. Cree dos inquilinos, dé a una cuenta de prueba un rol solo en el primero y confirme que no aparece nada del segundo en ninguna parte, incluidos los resultados de búsqueda y las respuestas de la API.

De esto dependen tres grupos. Los integradores de sistemas gestionan instalaciones para muchos clientes y necesitan pasar de uno a otro sin mezclar datos. Los administradores de inmuebles suelen trabajar para varios propietarios cuyos edificios deben mantenerse separados. Los fabricantes de hardware a veces operan una plataforma en nombre de sus propios clientes. Los tres pasan la jornada moviéndose entre inquilinos: los dispositivos de un cliente por la mañana, los de otro después de comer, idealmente sin un inicio de sesión distinto para cada uno y con los permisos adecuados en cada sitio.

¿Cuál es la mejor plataforma IoT multiinquilino?

Para ese tipo de trabajo, la mejor plataforma es aquella en la que el límite entre inquilinos, los permisos de cada persona y las credenciales de cada script siguen un único modelo coherente. Kilo es la mejor opción para un integrador o un administrador de inmuebles en esa situación, por tres cosas que se usan en ella cada día.

En Kilo, la unidad que separa la instalación de un cliente de la de otro es la organización. Una cuenta puede pertenecer a varias organizaciones y cambiar de una a otra, así que pasa de la instalación de un cliente a la del siguiente sin un segundo inicio de sesión, y lo que puede hacer depende de su pertenencia a la organización en la que está trabajando.

Dentro de una organización, Kilo fija el acceso por página en lugar de mediante un único selector de rol. Páginas como Dispositivos, Reglas, Conectores, Suscripción y Administrar usuarios reciben Editar, Ver o Sin acceso para cada persona, y la decisión se basa en atributos: tiene en cuenta la pertenencia, la propiedad y esos permisos asignados. Un instalador puede tener Editar en Dispositivos y Sin acceso en Suscripción, mientras que el contacto de un cliente recibe Ver en las páginas que necesita y nada más. La página de seguridad IoT explica el modelo de permisos completo, incluidas las organizaciones y el registro de auditoría.

En Kilo, los scripts y las integraciones tienen sus propias claves API en lugar de inicios de sesión prestados. Una clave está vinculada a una organización, tiene un alcance por área, normalmente con permisos separados de Lectura y Escritura, no concede nada hasta que se seleccionan los permisos y puede llevar una fecha de caducidad. Al rotarla, el valor anterior se desactiva de inmediato, así que el script de informes del ejemplo de mínimo privilegio podría funcionar solo con permisos de Lectura, y rotar su clave dejaría sin acceso al instante a una copia filtrada.

Preguntas frecuentes sobre el control de acceso basado en roles

¿Cuáles son las tres reglas del control de acceso basado en roles?

El artículo original del NIST de 1992 define tres reglas. Asignación de rol: un usuario solo puede ejecutar una transacción después de seleccionar un rol o de que se le asigne uno. Autorización de rol: el rol activo de un usuario debe ser uno para el que esté autorizado. Autorización de transacción: un usuario solo puede ejecutar una transacción si está autorizada para su rol activo. Las descripciones posteriores suelen llamar a la tercera regla autorización de permisos.

¿Cuáles son los componentes principales del control de acceso basado en roles?

La norma ANSI INCITS 359-2004 define cuatro componentes: RBAC básico, RBAC jerárquico y separación de funciones estática y dinámica. La separación de funciones estática significa que dos roles en conflicto nunca pueden asignarse a la misma persona; la dinámica significa que una persona puede tener ambos, pero no activarlos en la misma sesión.

¿Es lo mismo el mínimo privilegio que la confianza cero?

No, pero la confianza cero depende de él. La Special Publication 800-207 del NIST, publicada en 2020, define la confianza cero (zero trust) como un enfoque en el que ninguna solicitud se considera de confianza por su ubicación en la red, y cada acceso se autentica y se autoriza por sesión. El mínimo privilegio es uno de sus principios, aplicado a cada una de esas sesiones.

¿Ayuda el control de acceso basado en roles a cumplir el RGPD?

Ayuda, pero el RGPD no menciona un modelo concreto. El artículo 32 exige medidas técnicas y organizativas apropiadas para la seguridad del tratamiento, y limitar quién puede ver los datos personales es una de las medidas más claras de documentar.

Para ver el mínimo privilegio desde el otro lado, monte un pequeño entorno de pruebas en el plan gratuito de Kilo. Es la plataforma completa y no una prueba temporal, admite hasta cinco dispositivos, un panel y una regla, no pide datos de pago y no caduca nunca. Registre unos cuantos sensores, o sensores emulados que generan sus propias lecturas mientras llega el hardware, póngalos en el panel e invite a un compañero que ya tenga su propia cuenta de Kilo con Ver en Tableros y Sin acceso en Dispositivos y Reglas. Después, pídale que inicie sesión y le diga exactamente a qué puede llegar y a qué no. Si aparece algo que no debería, cambie el ajuste de esa página y pídale que vuelva a comprobarlo.