Saltar al contenido

Control de accesos · acre security · Access Control y Feenics

acre no es una plataforma. Es una cartera.

Detrás del nombre hay varias plataformas de control de accesos compradas en momentos distintos, y Feenics es la de nube. Cuál de ellas te ofrecen importa mucho más que el nombre del grupo, y es la primera pregunta que hay que hacer.

Qué es acre, y qué es Feenics.

Lo primero que hay que entender de esta marca es que no es un producto: es un grupo que ha ido comprando productos.

acre security se ha formado comprando casas de control de accesos. Eso quiere decir que bajo el mismo nombre hay varias plataformas con historias, arquitecturas y herramientas distintas. Cuando alguien dice «vamos con acre» todavía no ha dicho nada: hay que preguntar con cuál de ellas, y por escrito en la oferta.

Feenics es la línea de nube, y es la que hace interesante al grupo en esta conversación. Resuelve un problema muy concreto: quien quiere quitarse el servidor de accesos de encima pero no quiere atarse a la electrónica de un solo fabricante. Las demás líneas son de servidor propio y juegan donde juegan las plataformas enterprise clásicas.

Aparece en sedes corporativas repartidas, en educación, en sanidad y, sobre todo, en clientes que ya tienen una plataforma con servidor y han decidido salir de él sin tirar lo que hay en los armarios.

Cómo está construido, y por qué importa.

Feenics es nube sobre controladoras de la familia Mercury, de HID. Eso no es un detalle: es la diferencia entre una nube y otra. La cabeza está fuera, la decisión sigue dentro del edificio en un panel de mercado, y el panel no es cautivo de nadie.

La consecuencia práctica es que esta arquitectura se puede deshacer. Si dentro de tres años el cliente cambia de criterio, de proveedor o de plataforma, el cable, los lectores y el panel se quedan. En una nube con hardware propio eso no pasa, y es justo la decisión que se paga tarde.

Lo que hay que mirar con lupa es lo otro: cuando una plataforma entra en una cartera, conviene preguntar cuál es su hoja de ruta, qué línea recibe desarrollo y qué pasa con las versiones antiguas. No es mala fe, es lo que ocurre con las carteras de producto; y se nota tres años después, cuando toca subir versión y resulta que la línea que te vendieron ya no es la que reciben los recursos.

Cuatro preguntas de ficha técnica.

  • Qué línea exactamente, con su nombre de producto en la oferta. De eso depende todo lo demás, incluida la herramienta con la que se configura.
  • Qué controladoras Mercury están instaladas ya, con su modelo y su firmware. Es lo que decide si la migración es de cabeza o es de obra.
  • Cómo se junta con el vídeo y con la intrusión: por API o por integración hecha, y hasta dónde llega cada una. Se prueba en maqueta antes de prometerlo.
  • A nombre de quién queda el inquilino de nube. Esto parece administrativo y es el nudo donde se quedan atrapados muchos clientes: si lo creó el integrador con su cuenta, cambiar de integrador se complica.

La nube, la línea y el RGPD.

De las cuatro plataformas de nube de este grupo, ésta es la que aguanta mejor un corte. Y por una razón de arquitectura, no de marketing.

El panel de puerta tiene su propia base de datos de personas, permisos y horarios, y es el mismo tipo de panel que usan las plataformas enterprise de servidor. Así que sin línea la instalación no se queda en mínimos: sigue aplicando su lógica, guarda los eventos y los sube cuando vuelve la conexión.

Lo que se pierde es lo mismo que en cualquier nube, y hay que decirlo: no se propaga un cambio mientras no hay línea, no se abre en remoto y no se ve en directo. Si se da de baja a alguien justo en ese rato, su credencial sigue abriendo hasta que el panel se entere.

Y los datos. El servicio se aloja en infraestructura de nube pública, así que hay que pedir por escrito en qué región, el contrato de encargado de tratamiento con su lista de subencargados y el mecanismo que ampara las transferencias fuera de la Unión Europea. Más una pregunta que casi nadie hace y que es la que más duele: en qué formato se entregan los datos si algún día se quiere salir.

Para quién encaja, y para quién no.

Encaja especialmente en un caso: ya hay una plataforma enterprise montada sobre controladoras Mercury, el servidor envejece, nadie quiere mantenerlo y se quiere conservar la inversión de los armarios. Ahí esta arquitectura es la respuesta natural y casi no hay obra.

También encaja en sedes repartidas que necesitan más lógica de la que da una nube sencilla: zonas, antipassback, horarios complicados, administración delegada por sede.

No encaja si se busca lo que buscan los clientes de nube pura: una sola casa, un solo número de teléfono y cero decisiones técnicas. Aquí hay más piezas y por tanto más proyecto. Y no encaja si lo que hay instalado no es Mercury, porque entonces se pierde la ventaja principal y la comparación con las otras nubes vuelve a empezar de cero.

Qué hacemos nosotros con ella.

  • El inventario de lo que hay en los armarios antes de ofrecer nada: modelo y firmware de cada controladora, estado del cableado de lector y qué lectores son. Sin eso, un presupuesto de migración es una apuesta.
  • El proyecto puerta por puerta: credencial, comportamiento al irse la luz, lectura de salida, cámara que la mira y coordinación con la detección de incendios.
  • La instalación y la sustitución de lo que toque: alimentación y respaldo, lectores a OSDP donde se pueda, cerraduras y herrajes, y la red por la que sale el sistema.
  • La puesta en marcha: estructura de zonas y horarios del proyecto, carga de personas desde la fuente buena, integraciones comprobadas y prueba escrita puerta por puerta con acta.
  • El mantenimiento y la propiedad: respaldo y baterías, firmware, revisión del listado de credenciales contra personal, y el inquilino y las claves a nombre del cliente. Eso último lo pedimos nosotros aunque no lo pida él.

Quién la configura cuando nos vamos.

El día a día, el cliente. La capa de abajo, no — y aquí la frontera está más marcada que en una nube sencilla.

Las altas y las bajas de personas, los horarios, los permisos por zona y las credenciales temporales los lleva el cliente desde el navegador, con roles que separan la gestión de personas de la configuración del sistema. Eso lo puede llevar el equipo de seguridad o el de informática, y cuando existen los dos lo mejor es repartir y escribir quién hace qué.

Lo que no toca el cliente es lo que vive en el panel: añadir una controladora, cambiar el modo de una puerta, tocar esclusas o antipassback, subir firmware, rehacer el árbol de zonas. Aquí eso importa más porque hay de verdad dos capas, la de nube y la de panel, y un cambio mal hecho en la de abajo puede dejar una puerta actuando distinto de como dice la pantalla de arriba.

Lo que se entrega para que puedan: formación por papeles, el mapa de puertas con su comportamiento, el árbol de zonas y horarios tal como quedó, el inventario de paneles con firmware, quién tiene cada rol y un folio con los cinco problemas probables. Y el recordatorio de que un sistema que sólo sabe manejar una persona se rompe cuando esa persona se va de vacaciones.

Venir de otra cosa.

El caso bueno ya está dicho: si lo instalado es Mercury, se conserva el panel, el cable y los lectores, y lo que cambia es la cabeza. Hay que revisar firmware y rehacer la configuración, y eso es trabajo, pero no se abren paredes ni se reemiten tarjetas si las actuales se leen.

Lo que no viaja es el historial: se exporta y se archiva aparte antes de apagar el sistema viejo. Tampoco viajan las particularidades configuradas a mano durante años en la plataforma anterior — esos apaños que nadie documentó y que alguien echará de menos. Se levantan uno a uno antes de migrar, preguntando, porque en el manual no están.

Y si lo instalado no es Mercury, la migración es la normal: se conserva canalización, alimentación y herrajes, se comprueban lectores y tarjetas, y la electrónica se cambia.

Empezar

¿Qué hay hoy en tus armarios?

Con el modelo de las controladoras instaladas, el número de puertas y quién va a llevar las altas y las bajas, podemos decirte si esta arquitectura te ahorra la obra o si lo que tienes pide otra cosa. Y si pide otra cosa, lo decimos antes de presupuestar.