Integración de IoT y Cerraduras Inteligentes

Un operador de instalaciones gestionaba el acceso físico de decenas de edificios con una mezcla de cerraduras inteligentes, controladores de pasarela y paneles de acceso de varios fabricantes. Cada familia de dispositivos tenía su propio esquema de credenciales, su propio formato de registro y ninguna noción compartida de quién era realmente una persona. Cuando ocurría un incidente, reconstruir “quién abrió esa puerta y si estaba autorizado” exigía cruzar exportaciones de tres sistemas desconectados.

El operador necesitaba una sola malla gobernada por identidad donde cada cerradura, cada pasarela y cada actor humano se autenticara contra el mismo plano de control.

El desafío

El parque de hardware era heterogéneo y no se podía reemplazar de golpe. Las cerraduras hablaban con pasarelas locales; las pasarelas llamaban a servicios en la nube; los servicios en la nube confiaban en cualquier token que recibieran. No había forma consistente de vincular un evento de puerta a una identidad verificada, y el tráfico máquina a máquina entre pasarelas y backend usaba secretos compartidos de larga duración que nadie rotaba.

Los auditores querían atribución para cada apertura, y seguridad quería revocar a una persona o a un dispositivo comprometido al instante, en todas partes, sin recorrer el edificio.

Qué desplegó Veripass

Veripass se convirtió en la capa de identidad y autorización frente a la flota de dispositivos. Cada edificio se modeló como un tenant, aislando sus miembros, dispositivos, políticas e historial de auditoría. Los actores humanos se autenticaban a través del directorio de su organización, federado vía OIDC, y recibían sesiones acotadas a los edificios y puertas que su perfil de acceso permitía.

Las pasarelas y controladores se trataron como identidades de máquina de primera clase. Cada pasarela se autenticaba con una API key acotada en lugar de un secreto compartido, de modo que un controlador comprometido podía revocarse individualmente sin volver a generar claves para todo el sitio. Cada solicitud de apertura se evaluaba contra una política sensible al contexto — actor, rol, edificio, ventana horaria — antes de ordenar la apertura de una cerradura, y cada decisión se escribía en un registro de auditoría inmutable.

• Modelo multi-tenant que aísla cada edificio y su parque de dispositivos
• Federación OIDC para actores humanos vía el directorio de la organización
• API keys por pasarela para tráfico máquina a máquina, revocables de forma individual
• RBAC compuesto por claims, capabilities, roles y perfiles de acceso
• Evaluación basada en políticas y sensible al contexto por puerta y ventana horaria
• MFA adaptativo y escalonado por TOTP de teléfono para zonas de alta seguridad
• Registro de auditoría inmutable que vincula cada apertura a una identidad verificada

Para zonas sensibles — salas de servidores, áreas de manejo de efectivo — la política exigía un escalonamiento: MFA adaptativo por TOTP de teléfono antes de liberar la puerta, incluso para un titular ya autorizado. La elevación de la sesión se registraba junto a la apertura, de modo que la traza mostraba no solo que una puerta se abrió, sino que el actor se identificó primero.

Resultado

El operador colapsó tres registros de acceso específicos de cada fabricante en una sola traza consolidada e inmutable donde cada evento de puerta nombraba a una persona verificada o a un dispositivo conocido. Revocar el acceso se volvió atómico: deshabilitar a una persona en el directorio o revocar la API key de una pasarela surtía efecto en todo el parque de inmediato, sin visitas al sitio.

Lo más importante: el acceso físico dejó de ser una caja negra. Cada apertura respondía ahora quién abrió la puerta, en qué edificio, bajo qué política y si tuvo que escalonar para hacerlo — sin reemplazar una sola cerradura.