Guías de decisión

Qué auditoría ejecutar

El Engine ofrece la auditoría completa, una en seco, pasos sueltos y una verificación de acceso. Elegir bien ahorra tiempo de los equipos y evita leer resultados viejos como si fueran nuevos.

Cómo acotar

• Usa scope=site o site_type para auditorías rutinarias de una región o un arquetipo; devices para una lista concreta.
• Los filtros filter_roles, filter_platforms y lifecycle recortan dentro del alcance. lifecycle=active excluye equipos en preparación o en baja.
• max_workers alto acelera, pero cada worker es una sesión SSH simultánea: empieza en 3 o 4 en redes con enlaces lentos.
• completed_with_errors es terminal: revisa el estado por equipo del job para ver qué equipos fallaron y por qué, y vuelve a lanzar sólo esos.

Cómo modelar la intención

La intención es el estándar de la red escrito de forma que una máquina lo compare con la realidad. La regla de diseño de la plataforma es intención primero: el Configurador define el estado deseado; el discovery observa y sugiere, no decide.

1. Empieza por lo que ya es estándar. DNS, NTP, syslog, SNMP, SSH, VTY, banners, reloj. Son los servicios que casi todos los equipos comparten; van en defaults y producen cumplimiento visible desde la primera auditoría.
2. Declara en el alcance más amplio que sea cierto. Si todos los switches de acceso llevan el mismo blindaje de puertos, va en by_role.lan_switch, no en cada equipo. Ver Cuándo usar cada alcance.
3. Usa los servicios del catálogo, no líneas sueltas. Un servicio trae plantilla por plataforma, formulario y checks. Una línea suelta en una regla manual no genera configuración ni se adapta al fabricante.
4. Parte del respaldo cuando no sepas el valor. La plataforma propone un bloque services desde el running. Revísalo y promueve lo que sea estándar; lo que sea excepción, déjalo como excepción consciente.
5. Cierra con las reglas de estado. Cuando la configuración ya cumple, declara los vecinos BGP y OSPF esperados, las VLAN del trunk y la raíz STP: así compliance detecta fallas de operación y no sólo de configuración.
6. Habilita y deshabilita por catálogo. Un servicio deshabilitado en el catálogo del tenant apaga sus checks en cascada. Es la forma correcta de «todavía no auditamos esto».

Dos trampas documentadas: los carriles de API (FortiGate, Junos, Meraki, SD-WAN) en modo estricto consideran drift lo que sobra, así que una intención parcial produce fallos esperables; y el targets vacío de una regla ya no significa «todos los equipos», hay que marcar apply_to_all.

Cuándo usar defaults, by_site, by_role, by_platform o by_device

Los alcances se fusionan en este orden y el último gana: defaults → by_site → by_site_type → by_role → by_platform → by_model → by_tag → by_filter → by_device. La fusión es recursiva para diccionarios; las listas se reemplazan completas.

Regla práctica

Pregunta «¿qué tendría que cambiar para que este valor cambie?». Si la respuesta es «la organización», va en defaults; «el sitio», en by_site; «el tipo de sitio», en by_site_type; «la función del equipo», en by_role; «el sistema operativo», en by_platform; «este equipo en particular», en by_device. La herramienta de estandarización del Configurador factoriza automáticamente los servicios idénticos de varios equipos al alcance más amplio que los contiene, sólo si todos coinciden.

Cómo clasificar campos

Antes de agregar un dato a la plataforma conviene decidir de qué naturaleza es. Cada naturaleza tiene su archivo, su dueño y su forma de cambiar.

Casos que confunden

• La IP de gestión es identidad (hostname del inventario base) aunque también aparezca observada (ip_address). La declarada manda para conectarse; la observada sirve para detectar que alguien la cambió.
• La comunidad SNMP es intención (se configura en el equipo) y secreto (Telegraf la usa para leer). Va en la intención como servicio y en la bóveda como credencial snmp; los reportes la redactan.
• El ASN y los vecinos BGP son intención por equipo (by_device), pero la plataforma también los observa. La regla state_bgp_neighbors compara ambos.
• La versión de software es observada, pero la versión mínima es intención: el servicio software_version y la norma de versión en Cumplimiento → Software.
• Las etiquetas son clasificación cuando una persona las pone (device_tags.json) y derivadas cuando salen de una regla (interface_tags.json con prefix o contains).

Cómo migrar desde CSV y YAML hacia la fuente de verdad

Muchas instalaciones empiezan con el inventario en archivos del Engine (el CSV de equipos y el inventario interno) y credenciales en archivos locales o variables de entorno. El destino es el inventario por tenant en la UI y la bóveda. Se puede hacer sin perder historial.

1. Congela el punto de partida. Corre una auditoría completa y guarda un snapshot del Gemelo con una nota («antes de migrar»). Es la referencia para comparar después.
2. Crea la organización en la UI y asigna a los usuarios. Si vienes de una instalación de un solo tenant, el slug default ya existe.
3. Da de alta los catálogos en Provisioning: tipos de sitio, roles y sitios con los mismos códigos que usa el CSV. Un rol que no exista en el catálogo hará que la importación rechace el equipo.
4. Importa el CSV en Inventario → Importar, en modo fusión. Revisa devices_without_management_ip y corrige los equipos cuyo hostname era un FQDN que la UI no pudo convertir en IP.
5. Migra las credenciales con el comando de importación a la bóveda de la UI, primero en modo de prueba (--dry-run), revisa el resumen y repite en firme. Comprueba en Integraciones → Credenciales que el alcance de cada una sea el que esperas (global, sitio o equipo).
6. Sincroniza el inventario con «Sincronizar inventario»: el Engine genera el inventario de la organización desde la fuente de verdad. A partir de aquí, el inventario de la UI manda y los archivos del Engine dejan de afectar las auditorías.
7. Mueve la intención. Si tenías service_vars.json en el Engine, impórtalo en el Configurador (JSON o CSV). Si tenías reglas de estado en intended.json, impórtalas en Cumplimiento → Reglas en CSV. Las reglas de configuración se regeneran al guardar los servicios.
8. Audita de nuevo y compara con el snapshot del paso 1. Las diferencias deberían ser cero o explicables (por ejemplo, un equipo que quedó sin IP de gestión).
9. Cierra la puerta trasera. Activa en el Engine el modo «sólo bóveda», que rechaza credenciales de archivos o variables, y borra los archivos locales y las variables legadas que las contenían.

Para instalaciones con varios tenants, el paquete de tenant (ZIP con vista previa) mueve una organización completa entre instalaciones sin repetir los pasos.

Cómo preparar evidencia para compliance

Un auditor externo quiere tres cosas: cuál era el estándar, qué se midió contra él y cuándo. Oktavia produce las tres como artefactos; el trabajo es elegirlos y conservarlos.

Qué conservar de cada corte

Procedimiento recomendado

1. Programa la auditoría del corte con el scheduler y output_path hacia un directorio de evidencia: el Engine copia inventario, resumen, resultados y configuraciones en un directorio por job.
2. Agrega al mismo job los pasos export_compliance_csv, export_device_summary_csv y export_site_summary_csv.
3. Congela un snapshot del Gemelo con el job_id del corte y la nota del periodo. Queda inmutable y sirve para el diff del siguiente corte.
4. Exporta la intención vigente ese día; sin ella los resultados no se pueden reproducir.
5. Conserva el job_id: enlaza inventario, reglas, resultados y configuraciones del mismo instante.

Cómo presentarlo

• site_summary.csv abre la conversación: puntaje por sitio con total, pasados y fallados.
• compliance_tests.csv responde el detalle: cada prueba con equipo, regla, severidad, resultado, tipo de remediación, ticket y fecha de ejecución.
• Separa las tres clases de no cumplimiento: compliance_failure es hallazgo; data_missing y pipeline_inconsistency son limitaciones de medición y se explican aparte.
• Los artefactos ya vienen redactados (sin contraseñas ni comunidades). No compartas los snapshots crudos del discovery.
• Para un hallazgo corregido, la cadena completa es: prueba fallida en el corte N, cambio CHG-… aprobado con ticket, prueba pasada en el corte N+1.
• El veredicto del ciclo cerrado ya trae la comparación antes y después por equipo (corregidas, regresiones, fallas nuevas, siguen fallando): adjúntalo al cambio.

Reporte de red PCI DSS

Para un auditor de PCI, Oktavia genera el reporte de red de PCI DSS v4.0.1 por sitio, sobre los requisitos 1, 2, 6.3.3, 7, 8 y 10. El alcance del entorno de datos de tarjetahabientes son los sitios de punto de venta. Cada requisito sale como cumple, no cumple o no evaluado; sólo cuenta si la familia de fabricante del equipo tiene una verificación para él, así que un «no evaluado» es una limitación de medición, no un hallazgo, y se explica aparte. Trae evidencia por equipo y se imprime en PDF. Apoya al QSA; no lo sustituye.