Control d'accessos · acre security · Access Control i Feenics
acre no és una plataforma. És una cartera.
Darrere del nom hi ha diverses plataformes de control d'accessos comprades en moments diferents, i Feenics és la del núvol. Quina d'elles t'ofereixen importa molt més que el nom del grup, i és la primera pregunta que cal fer.
Què és acre, i què és Feenics.
El primer que cal entendre d'aquesta marca és que no és un producte: és un grup que ha anat comprant productes.
acre security s'ha format comprant cases de control d'accessos. Això vol dir que sota el mateix nom hi ha diverses plataformes amb històries, arquitectures i eines diferents. Quan algú diu «anem amb acre» encara no ha dit res: cal preguntar amb quina d'elles, i per escrit a l'oferta.
Feenics és la línia de núvol, i és la que fa interessant el grup en aquesta conversa. Resol un problema molt concret: qui vol treure's el servidor d'accessos de sobre però no vol lligar-se a l'electrònica d'un sol fabricant. Les altres línies són de servidor propi i juguen on juguen les plataformes enterprise clàssiques.
Apareix en seus corporatives repartides, en educació, en sanitat i, sobretot, en clients que ja tenen una plataforma amb servidor i han decidit sortir-ne sense llençar el que hi ha als armaris.
Com està construït, i per què importa.
Feenics és núvol sobre controladores de la família Mercury, de HID. Això no és un detall: és la diferència entre un núvol i un altre. El cap és fora, la decisió continua dins de l'edifici en un panell de mercat, i el panell no és captiu de ningú.
La conseqüència pràctica és que aquesta arquitectura es pot desfer. Si d'aquí a tres anys el client canvia de criteri, de proveïdor o de plataforma, el cable, els lectors i el panell es queden. En un núvol amb maquinari propi això no passa, i és justament la decisió que es paga tard.
El que cal mirar amb lupa és l'altra cosa: quan una plataforma entra en una cartera, convé preguntar quin és el seu full de ruta, quina línia rep desenvolupament i què passa amb les versions antigues. No és mala fe, és el que passa amb les carteres de producte; i es nota tres anys després, quan toca pujar de versió i resulta que la línia que et van vendre ja no és la que rep els recursos.
Quatre preguntes de fitxa tècnica.
- Quina línia exactament, amb el seu nom de producte a l'oferta. D'això depèn tota la resta, inclosa l'eina amb què es configura.
- Quines controladores Mercury hi ha instal·lades ja, amb el seu model i el seu firmware. És el que decideix si la migració és de cap o és d'obra.
- Com s'ajunta amb el vídeo i amb la intrusió: per API o per integració feta, i fins on arriba cadascuna. Es prova en maqueta abans de prometre-ho.
- A nom de qui queda l'inquilí de núvol. Això sembla administratiu i és el nus on es queden atrapats molts clients: si el va crear l'integrador amb el seu compte, canviar d'integrador es complica.
El núvol, la línia i el RGPD.
De les quatre plataformes de núvol d'aquest grup, aquesta és la que aguanta millor un tall. I per una raó d'arquitectura, no de màrqueting.
El panell de porta té la seva pròpia base de dades de persones, permisos i horaris, i és el mateix tipus de panell que fan servir les plataformes enterprise de servidor. Així que sense línia la instal·lació no es queda en mínims: continua aplicant la seva lògica, guarda els esdeveniments i els puja quan torna la connexió.
El que es perd és el mateix que en qualsevol núvol, i cal dir-ho: no es propaga un canvi mentre no hi ha línia, no s'obre en remot i no es veu en directe. Si es dóna de baixa algú justament en aquella estona, la seva credencial continua obrint fins que el panell se n'assabenti.
I les dades. El servei s'allotja en infraestructura de núvol pública, així que cal demanar per escrit en quina regió, el contracte d'encarregat de tractament amb la seva llista de subencarregats i el mecanisme que empara les transferències fora de la Unió Europea. Més una pregunta que gairebé ningú no fa i que és la que més fa mal: en quin format es lliuren les dades si algun dia se'n vol sortir.
Per a qui encaixa, i per a qui no.
Encaixa especialment en un cas: ja hi ha una plataforma enterprise muntada sobre controladores Mercury, el servidor envelleix, ningú no el vol mantenir i es vol conservar la inversió dels armaris. Aquí aquesta arquitectura és la resposta natural i gairebé no hi ha obra.
També encaixa en seus repartides que necessiten més lògica de la que dóna un núvol senzill: zones, antipassback, horaris complicats, administració delegada per seu.
No encaixa si es busca el que busquen els clients de núvol pur: una sola casa, un sol número de telèfon i zero decisions tècniques. Aquí hi ha més peces i per tant més projecte. I no encaixa si el que hi ha instal·lat no és Mercury, perquè llavors es perd l'avantatge principal i la comparació amb els altres núvols torna a començar de zero.
Què hi fem nosaltres amb ella.
- L'inventari del que hi ha als armaris abans d'oferir res: model i firmware de cada controladora, estat del cablejat de lector i quins lectors són. Sense això, un pressupost de migració és una aposta.
- El projecte porta per porta: credencial, comportament quan marxa la llum, lectura de sortida, càmera que la mira i coordinació amb la detecció d'incendis.
- La instal·lació i la substitució del que toqui: alimentació i reserva, lectors a OSDP on es pugui, panys i ferramentes, i la xarxa per on surt el sistema.
- La posada en marxa: estructura de zones i horaris del projecte, càrrega de persones des de la font bona, integracions comprovades i prova escrita porta per porta amb acta.
- El manteniment i la propietat: reserva i bateries, firmware, revisió del llistat de credencials contra personal, i l'inquilí i les claus a nom del client. Això últim ho demanem nosaltres encara que no ho demani ell.
Qui la configura quan marxem.
El dia a dia, el client. La capa de sota, no — i aquí la frontera està més marcada que en un núvol senzill.
Les altes i les baixes de persones, els horaris, els permisos per zona i les credencials temporals els porta el client des del navegador, amb rols que separen la gestió de persones de la configuració del sistema. Això ho pot portar l'equip de seguretat o el d'informàtica, i quan existeixen tots dos el millor és repartir i escriure qui fa què.
El que no toca el client és el que viu al panell: afegir una controladora, canviar el mode d'una porta, tocar excluses o antipassback, pujar firmware, refer l'arbre de zones. Aquí això importa més perquè hi ha de debò dues capes, la de núvol i la de panell, i un canvi mal fet a la de sota pot deixar una porta actuant diferent de com diu la pantalla de dalt.
El que es lliura perquè puguin: formació per papers, el mapa de portes amb el seu comportament, l'arbre de zones i horaris tal com va quedar, l'inventari de panells amb firmware, qui té cada rol i un full amb els cinc problemes probables. I el recordatori que un sistema que només sap manejar una persona es trenca quan aquella persona se'n va de vacances.
Venir d'una altra cosa.
El cas bo ja està dit: si el que hi ha instal·lat és Mercury, es conserva el panell, el cable i els lectors, i el que canvia és el cap. Cal revisar firmware i refer la configuració, i això és feina, però no s'obren parets ni es reemeten targetes si les actuals es llegeixen.
El que no viatja és l'historial: s'exporta i s'arxiva a part abans d'apagar el sistema vell. Tampoc no viatgen les particularitats configurades a mà durant anys a la plataforma anterior — aquells pedaços que ningú no va documentar i que algú trobarà a faltar. S'aixequen un a un abans de migrar, preguntant, perquè al manual no hi són.
I si el que hi ha instal·lat no és Mercury, la migració és la normal: es conserva canalització, alimentació i ferramentes, es comproven lectors i targetes, i l'electrònica es canvia.
Les altres sis d'aquest grup.
Tres més viuen al núvol, amb arquitectures que no són aquesta. Tres no. I la recomanació depèn del que hi hagi als armaris.
Començar
Què hi ha avui als teus armaris?
Amb el model de les controladores instal·lades, el nombre de portes i qui portarà les altes i les baixes, et podem dir si aquesta arquitectura t'estalvia l'obra o si el que tens demana una altra cosa. I si demana una altra cosa, ho diem abans de pressupostar.