Orden de puesta en marcha
No hay atajos: primero se levanta el inventario de puertas, lectores y cámaras que cubren las salas de servidores, y en paralelo se traza qué flujos de red atraviesan la infraestructura. Solo después tiene sentido hablar de correlación. Si se invierte el orden, el panel conjunto acumula ruido en lugar de incidentes útiles.
Antes de decidir qué se captura, conviene saber qué hay. Qué puertas dan a la sala de servidores, qué lector tiene cada una, qué cámara cubre el pasillo y qué flujos de red cruzan los switches de agregación. Un inventario incompleto obliga a rehacer la fase siguiente.
Con el mapa claro se decide qué se registra: huella, rostro o iris para el acceso físico, y metadatos de conexión para la capa lógica. La elección depende de condiciones reales del sitio, no de catálogo. Una cámara frente a una puerta con carros y movimiento no rinde igual que en un pasillo limpio.
Videovigilancia, control de acceso y cortafuegos no comparten formato. Cada sistema trae sus marcas de tiempo y sus identificadores. Normalizar significa acordar un esquema común antes de conectar nada al panel, y decidir qué campos son obligatorios y cuáles opcionales.
La correlación exige relojes alineados y una tabla que relacione identificadores de persona con cuentas de usuario. Ese encaje rara vez es directo: una misma persona puede tener un badge, un usuario de dominio y una cuenta de operador de red. Sin ese mapa, las coincidencias temporales no significan nada.
Cuando cámaras, lectores o sensores de red los gestiona un tercero, hay que prever quién puede consultar qué y cómo se reconstruye una secuencia. La trazabilidad no se improvisa al final: se define al contratar el acceso a los datos.
Solo con lo anterior en pie se activan reglas que cruzan capas. Un acceso fuera de horario y un escaneo de puertos en la misma franja pueden ser el mismo incidente visto desde dos sitios. El ajuste de esas reglas es trabajo continuo, no una puesta en marcha cerrada.
Poner en marcha un esquema híbrido de seguridad en un centro de datos que sirve a una plataforma de intercambio genera dudas razonables. Estas son las que aparecen casi siempre en la primera reunión técnica, con la respuesta tal como la daríamos en una conversación, no en un folleto.
No. CustodiaDC es un proyecto editorial. Aquí no se vende licencia, no hay prueba gratuita ni despliegue gestionado. Lo que encontrarás son descripciones operativas, criterios de diseño y escenarios ilustrativos para que un equipo interno pueda decidir qué necesita antes de hablar con proveedores.
Son ejemplos construidos para explicar una secuencia o un problema concreto: cómo se inventaría un acceso, cómo se normaliza un evento, cómo se sincronizan relojes. No representan instalaciones verificadas ni resultados medidos en un cliente. Si un texto necesita una cifra para entenderse, se marca como referencia de orden de magnitud, no como dato propio.
Porque invertirlo sale caro. Si se conecta primero el panel conjunto y se deja la normalización para después, el sistema acumula ruido: eventos duplicados, marcas de tiempo que no cuadran, identificadores de persona que no se corresponden con cuentas de usuario. Corregir eso a posteriori obliga a rehacer la lógica de correlación casi desde cero.
No se comparan aquí los IDS por firmas con los modelos neuronales, ni se detallan umbrales de falso positivo y falso negativo, ni se entra en los límites legales de almacenar plantillas biométricas en la Unión Europea. Son temas con entidad propia y se tratan en sus propios artículos, no como apéndice de una guía de arranque.
Es lo habitual. La secuencia describe un orden lógico, no un manual cerrado. Un centro con videovigilancia ya desplegada empezará por la capa de red; otro con control de acceso reciente puede permitirse normalizar antes. Lo importante es no saltarse la etapa de inventario, porque todo lo que viene después depende de saber qué puertas, lectores, cámaras y flujos existen realmente.