Saltar a contenido

Seguridad del parque — nota de arquitectura

Traducción automática del original francés.

Lo que esta página dice y lo que deliberadamente oculta

Describe los sistemas de seguridad, sus conexiones y sus flujos. No proporciona ningún dirección IP, nombre de host, nombre de cuenta, ni FQDN de servicio. Los hosts se identifican por su función.

Esta elección no es una cuestión de estética: una página de documentación, incluso tras la autenticación, eventualmente se copia en un ticket, una captura de pantalla o en el portapapeles. Una arquitectura sigue siendo una arquitectura sin sus coordenadas; una lista de FQDN públicos, en cambio, es un mapa de ataque listo para usar.

Las coordenadas se encuentran en el cofre privado y en el cofre. Ver Leer un secreto del cofre.

La misma regla se aplica a las subpáginas de esta sección, con una cláusula adicional: ninguna vulnerabilidad aún abierta se menciona. Estas describen la arquitectura, los principios y la forma de verificarlo; el estado actual — lo que está en curso, lo que falla — se encuentra en el cofre privado y en la tabla de cumplimiento.

El principio rector

El parque no tiene un perímetro único que defender. Tiene capas que fallan por separado: un atacante que supera una debe superar la siguiente, y cada superación deja una huella en un sistema que la capa anterior no controla.

Cuatro reglas rigen todo:

  1. Una única autoridad de identidad. Ningún servicio gestiona sus propias cuentas si puede delegar. Una salida, una contraseña comprometida, un segundo factor: un único punto de contacto.
  2. Lo que detecta no es lo que ejecuta. Los registros de un host están en otro lugar. Un host comprometido puede mentir sobre sí mismo, pero no puede eliminar lo que ya ha salido.
  3. El silencio es un estado sospechoso. Un sensor que no dice nada y un sensor muerto producen la misma ausencia. Por lo tanto, cada cadena de detección tiene un elemento funcional: no un contador que diga "estoy activo", sino un caso conocido, introducido expresamente, que debe ser detectado en cada paso.
  4. Probar, no declarar. Cada control se mide con un sensor que se ha visto fallar al menos una vez; su veredicto entra en un registro que no se puede reescribir sin que se note, y el estado "cumplimiento" se calcula a partir de las pruebas: nunca se basa en la mera declaración. Ver Cumplimiento y pruebas.

La sección en un vistazo

La defensa del parque se organiza en cuatro funciones, y una quinta que las verifica todas:

flowchart LR
    classDef p fill:#0f766e,stroke:#0f766e,color:#fff
    classDef d fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef r fill:#9a3412,stroke:#9a3412,color:#fff
    classDef c fill:#1e40af,stroke:#1e40af,color:#fff
    classDef g fill:#3f3f46,stroke:#3f3f46,color:#fff

    prev["PRÉVENIR<br/>périmètre · identité · secrets<br/>chaîne d'approvisionnement · correctifs"]:::p
    det["DÉTECTER<br/>SIEM · exécution · réseau<br/>fichiers · vulnérabilités"]:::d
    rep["RÉPONDRE<br/>notification unique · réponse automatique<br/>investigation · registre d'incidents"]:::r
    cont["SURVIVRE<br/>sauvegardes immuables · restauration chronométrée<br/>clé maîtresse hors ligne"]:::c
    prouv["PROUVER<br/>catalogue de contrôles · sondes<br/>registre chaîné · ancre git"]:::g

    prev --> det --> rep --> cont
    prouv -.->|"mesure"| prev
    prouv -.->|"mesure"| det
    prouv -.->|"mesure"| rep
    prouv -.->|"mesure"| cont
Página Lo que se encuentra
Esta página La arquitectura: capas, sus conexiones, sus flujos — y la prevención
Detección Una pregunta, un motor: SIEM, ejecución, red, archivos, vulnerabilidades — y sus elementos funcionales
Respuesta Notificación, respuesta automática limitada, investigación en caliente, registro de incidentes
Continuidad Niveles de respaldo, inmutabilidad, ejercicio de restauración, clave maestra
Cumplimiento y pruebas NIS2 y SOC 2 como marco, controles, sensores, registro en cadena, auditoría
Glosario Cada término, y lo que designa en este parque

Visión general

flowchart TB
    classDef edge fill:#0f766e,stroke:#0f766e,color:#fff
    classDef det fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef id fill:#1e40af,stroke:#1e40af,color:#fff
    classDef data fill:#3f3f46,stroke:#3f3f46,color:#fff

    client["Client Internet"]

    subgraph perimetre["1 · Périmètre"]
        dns["DNS public<br/>zone déléguée au registrar"]
        nat["Routeur — NAT entrant<br/>un seul port ouvert"]
        edge["Proxy de bordure<br/>terminaison TLS · sur le NAS"]:::edge
        proxy["Proxy interne<br/>routage · en-têtes · journalisation"]:::edge
        ips["CrowdSec<br/>analyse des journaux → 403"]:::edge
    end

    subgraph identite["2 · Identité"]
        idp["Fournisseur d'identité<br/>OIDC · SAML · MFA"]:::id
        fa["forward_auth<br/>mur, sans identité applicative"]:::id
    end

    subgraph prive["3 · Réseau privé"]
        cp["Plan de contrôle VPN<br/>auto-hébergé sur le VPS"]:::edge
        mesh["Maillage WireGuard<br/>chiffré de bout en bout"]:::edge
        dnsf["Filtrage DNS<br/>listes + horizon dédoublé"]:::edge
    end

    subgraph contenu["4 · Contenu"]
        av["Moteur antivirus central<br/>un seul daemon, protocole INSTREAM"]:::det
        yara["Analyse statique profonde<br/>dépliage récursif · YARA"]:::det
        quar["Quarantaine partagée<br/>sur le NAS"]:::data
    end

    subgraph detection["5 · Détection et réponse"]
        siem["SIEM / XDR<br/>intégrité fichiers · CVE · MITRE"]:::det
        fleet["Collecte journaux + métriques"]:::det
        rt["Détection à l'exécution<br/>appels système · eBPF"]:::det
        ids["IDS réseau<br/>signatures sur le trafic"]:::det
        ar["Réponse automatique<br/>blocage à durée limitée"]:::det
        hub["Répartiteur d'alertes"]:::det
        chat["Messagerie d'équipe<br/>deux destinations"]:::det
        dfir["Investigation à chaud<br/>client sur chaque machine"]:::det
    end

    subgraph socle["6 · Socle"]
        coffre["Coffre de secrets"]:::data
        sops["Secrets chiffrés au repos<br/>dans le dépôt"]:::data
        backup["Dépôts de sauvegarde chiffrés<br/>ajout seul · copies hors site"]:::data
        smart["Santé des disques"]:::data
        preuve["Registre de preuves<br/>chaîné · ancré dans git"]:::data
    end

    client --> dns --> nat --> edge --> proxy
    proxy --> ips
    ips -->|"IP décidée"| proxy
    proxy --> idp
    proxy -.->|"dernier recours"| fa
    idp --> proxy

    mesh --- cp
    mesh --- dnsf

    av --> quar
    yara --> quar

    proxy --> siem
    av --> siem
    yara --> siem
    fleet --> siem
    siem --> hub --> chat
    smart --> hub
    rt -.->|"après mesure du bruit"| hub
    ids -.->|"après mesure du bruit"| hub
    siem -->|"identifiant de règle"| ar
    chat -.->|"enquête"| dfir

    coffre -.-> sops
    backup -.-> quar
    siem -.->|"sondes"| preuve
    backup -.->|"sondes"| preuve

El esquema se lee de arriba hacia abajo, en el orden en que una solicitud maliciosa encuentra las defensas. Las capas 5 y 6 tienen cada una su propia página: Detección, Respuesta, Continuidad y Cumplimiento y pruebas.

1 · Alcance y exposición

La cadena de entrada

Una solicitud proveniente de Internet atraviesa cuatro dispositivos antes de llegar a un contenedor: el servidor DNS público, el router que realiza NAT, un proxy de borde alojado en el NAS, y luego un proxy interno en el host Docker principal.

El borde WAN no es el host Docker

Este es el punto más contraintuitivo de la arquitectura, y el que requiere más tiempo cuando se olvida. Dos consecuencias:

  • Todo filtrado L3 realizado en el host Docker no bloquea nada proveniente de Internet: la dirección de origen que ve es la del proxy de borde, nunca la del cliente.
  • Consultar un servicio por su nombre desde la red local no prueba el camino WAN. La resolución se duplica: el mismo nombre apunta a otra dirección según de dónde se solicite. Probar el WAN implica forzar la resolución hacia la dirección pública.

Detalle del camino completo: Cadena de proxy inverso y DNS y resolución.

Certificados

Los certificados son emitidos por ACME mediante el desafío DNS-01, a través de la API del registrador. Esta elección tiene una consecuencia de seguridad directa: no es necesario ningún registro A público para emitir un certificado. Por lo tanto, un servicio puede ser servido en TLS en la red local sin que su nombre se publique nunca en una zona DNS pública: la transparencia de los certificados sigue siendo pública.

Detección y remediación de aplicaciones

CrowdSec lee los registros de acceso del proxy interno, decide y aplica su decisión mediante un módulo integrado en el proxy, que responde con 403. También utiliza una lista de bloqueo compartida.

Se implementó después de una auditoría superficial que reveló 74 nombres expuestos y la ausencia de cualquier sistema de detección de intrusiones. Es la única capa que actúa sobre el contenido de una solicitud HTTP; en la parte anterior, el NAT no tiene conocimiento del HTTP.

Lo que CrowdSec no puede ver

El proxy interno solo ve la dirección real del cliente si el proxy de borde la transmite en un encabezado, y si el proxy interno confía en ese encabezado. Un error de configuración en este punto no causa ningún fallo; simplemente bloquea al proxy de borde, o bloquea a nadie. El síntoma es un sistema que parece funcionar.

2 · Identidad y acceso

Un proveedor de identidad único (Authentik) gestiona las cuentas, los grupos, el segundo factor y las sesiones. Coexisten dos modos de conexión, y el orden de preferencia es una regla, no un gusto:

Modo Lo que el servicio aprende Cuándo utilizarlo
OIDC / SAML nativo Identidad, grupos, roles, desconexión propia Por defecto, siempre que el servicio lo soporte
forward_auth Nada. Una barrera frente a la aplicación Último recurso, para un servicio sin concepto de cuenta

Nunca combinar dos servicios

El proxy de autenticación intercepta las URL de retorno de OAuth antes de que lleguen a la aplicación. El resultado es un ciclo de conexión provocado por tres componentes que parecen estar funcionando correctamente; cada uno realiza su tarea. Este es un fallo que no se refleja en ningún registro de errores.

El inicio de sesión local de un servicio solo se cierra después de una primera conexión federada exitosa. El orden inverso lo cierra.

3 · Red privada

Los hosts no se conectan utilizando sus direcciones de red local cuando salen de la red. Un enlace WireGuard los conecta, con un plan de control auto-alojado ubicado en el VPS público, por lo que no hay dependencia de un servicio de terceros para la pertenencia a la red.

Esto conlleva dos propiedades:

  • Un host fuera de la red local se comunica con el SIEM utilizando la dirección del enlace, nunca con una dirección local que no existe para él. Esto es una fuente común de error durante la incorporación de un agente.
  • El nombre del plan de control y el sufijo de las máquinas deben ser dos dominios distintos. Un cliente controla la resolución del sufijo: un plan de control que viva debajo se volvería inaccesible desde un nodo conectado. El servidor, además, no arranca en esta configuración.

Un filtrado DNS (listas de bloqueo, reescrituras internas) sirve para la red local y duplica la resolución: el mismo nombre hace que la dirección interna sea accesible desde dentro, y la dirección pública desde fuera.

Un dispositivo en la subred anunciada

Activar la aceptación de rutas en una máquina ya ubicada en la subred que el enlace anuncia hace que pierda el acceso a la red. El síntoma se asemeja a un fallo de Internet; la causa es una ruta aprendida que cubre la ruta local.

4 · Contenido: antivirus y análisis de archivos

Un único motor, por una razón que no es la economía

El parque utiliza un único daemon antivirus. Las demás máquinas no instalan ningún binario ni ninguna base de firmas: envían el contenido a través de un canal dedicado (protocolo INSTREAM) y reciben una decisión.

¿Por qué solo uno, y por qué un espejo privado?

El parque tiene una única dirección IP pública. Varios clientes de actualización que consultan la red de distribución de firmas desde esta dirección terminan sufriendo una limitación de velocidad, y luego aparecen en una lista negra.

El síntoma no es un error: es una base de firmas que envejece silenciosamente. Un antivirus cuya base tiene tres meses funciona, responde rápidamente y da respuestas falsas.

Por lo tanto, un único proceso del parque se conecta a Internet para obtener las firmas, dos veces al día, y las distribuye a todos desde un espejo interno. Las otras máquinas tienen el acceso a Internet bloqueado por configuración.

El cliente registra, no el servidor

En INSTREAM, el daemon solo recibe un flujo de bytes: su propio registro indica que se ha encontrado una firma en "un flujo", sin ruta ni máquina. La única parte que posee la información completa es el cliente. Por lo tanto, es él quien escribe en el registro del sistema, en el formato exacto que espera el decodificador del SIEM.

Consecuencias para el perímetro

Un motor central es un servicio de red: solo ve lo que se le envía. Un host sin cliente no está "protegido" — está fuera del perímetro. Por lo tanto, la cobertura se lee en la lista de clientes y sus zonas monitoreadas, nunca en el estado del daemon.

Detección: cuarentena, no eliminación

Un archivo detectado se mueve a una cuarentena en un espacio compartido del NAS, con acceso restringido y retención. La eliminación existe, pero no es el problema, por dos razones que se han observado en este entorno:

  • Ya se han detectado falsos positivos en archivos sanos (un libro electrónico, archivos de una aplicación); una eliminación habría sido inútil;
  • Algunas zonas monitorizadas están sincronizadas con otros dispositivos: eliminar un archivo de la zona propaga su desaparición en todas partes. Esto se ha diseñado para una verdadera amenaza, pero es perjudicial para un falso positivo.

Análisis estático profundo

Mientras que un antivirus emite un veredicto sobre un archivo, un segundo motor de análisis estático realiza lo que el antivirus no hace: desempaqueta recursivamente (archivos dentro de archivos, documentos, objetos incrustados, macros, ejecutables) y pasa decenas de escáneres sobre cada objeto extraído, incluyendo un motor de reglas YARA con miles de reglas. No se ejecuta ningún código: es un análisis estático, no un entorno de pruebas.

Un conjunto de reglas que no carga dice nada

El motor compila su conjunto de reglas en un solo bloque. Una sola regla inválida invalida todo el conjunto. El contenedor permanece aparentemente en buen estado y no detecta nada — fallo perfectamente silencioso.

Un contador de reglas cargadas no es suficiente para detectarlo: indica cuántas reglas están en memoria, pero no si todavía reconocen algo. El testigo es una regla canaria, colocada entre otras, cuya activación se exige cada vez que se pasa por delante — es ella la que distingue "nada que señalar" de "nada que funcione". Ver Detección.

5 · El escritorio de macOS

La estación macOS se trata como un dispositivo del parque, no como una excepción.

Capa Rol
Agente SIEM Integridad de los archivos, comprobaciones de configuración, notificación al responsable
Cliente antivirus Envío del contenido de las zonas de riesgo al motor central, según programación
Firewall por proceso Little Snitch — cada binario solicita permiso para salir
Enumerador de persistencia KnockKnock, conectado al motor antivirus del parque

KnockKnock conectado al motor central

KnockKnock enumera todo lo que se inicia automáticamente en un Mac: agentes y demonios de inicio, extensiones del núcleo, complementos de autorización, elementos de conexión, extensiones de navegador, tareas programadas. Se trata de la pregunta "¿qué se está ejecutando sin que yo lo solicite", que es exactamente la pregunta que se hace después de una vulneración.

En su estado actual, la herramienta consulta un servicio público de reputación mediante la huella del archivo. El parque utiliza una versión derivada que envía el contenido al motor antivirus interno en lugar de ello:

  • ningún archivo sale de la red local, ni huella ni contenido;
  • no se necesita ninguna clave de API, por lo que no hay limitaciones de velocidad;
  • el veredicto se basa en el contenido real del archivo, no en lo que ha visto un tercero.

Un firewall por proceso hace que los fallos sean silenciosos

En esta estación, cualquier nueva herramienta de red es silenciosa hasta que no se le autorice, y el fallo se asemeja exactamente a un fallo de red: la conexión queda en espera de una decisión que se muestra en una ventana —invisible para una tarea programada o una sesión remota.

De ahí una regla de diseño: una tarea sin interfaz debe pasar por un interpretador ya autorizado, nunca por un binario recién instalado. Una aplicación interactiva, en cambio, puede abrir su propia conexión: alguien está presente para responder a la ventana.

Acceso al disco completo

La enumeración completa de los puntos de persistencia requiere la autorización "acceso al disco completo", otorgada por un binario y únicamente manualmente, en la configuración del sistema. Ningún comando puede otorgarla de forma remota: es una propiedad del sistema operativo, no una limitación de la herramienta.

Una auditoría parcial se señala como parcial

El enumerador recorre unas veinte categorías de forma secuencial. Basta con que una llamada al sistema quede bloqueada en espera continua — un estado en el que el proceso ya no responde ni a una solicitud de parada ni a un apagado forzado — para que una sola categoría absorba toda la auditoría. Una tarea programada que "mata y reinicia" acumula un proceso adicional en cada paso.

La regla adoptada: una categoría que bloquea se elimina explícitamente, las demás se ejecutan, y la lista de categorías no revisadas se incluye en el cuerpo de la notificación. Una auditoría en la que una parte no ha sido revisada no es una auditoría verde — y "nada detectado" se parece exactamente a "no revisado".

6 · Detección, correlación, alerta

El SIEM

Un gestor de SIEM/XDR recopila los agentes de todos los hosts. Esto proporciona cuatro cosas que los registros brutos no ofrecen:

  • Supervisión de integridad de los componentes críticos;
  • Verificación de la configuración frente a estándares de seguridad;
  • Detección de vulnerabilidades mediante la correlación entre los paquetes instalados y las bases de datos CVE;
  • Correlación y mapeo en una matriz de técnicas de ataque.

Una segunda cadena recopila registros y métricas hacia un motor de búsqueda distinto. Ambas responden a una pregunta diferente: una pregunta si se trata de un "ataque conocido", y la otra pregunta "¿qué ha ocurrido, minuto a minuto".

Más allá del SIEM

El SIEM tiene visibilidad del estado de los hosts. Tres motores cubren lo que no ve: Falco supervisa las llamadas al sistema de los contenedores durante su ejecución, Suricata aplica firmas al tráfico de red, y Velociraptor permite consultar toda la flota durante un incidente. Sus funciones, sus capacidades y sus limitaciones de diseño se describen en Detección y Respuesta.

El camino hacia la detección

sequenceDiagram
    autonumber
    participant Z as Zone surveillée
    participant C as Client de scan
    participant M as Moteur antivirus
    participant J as Journal système
    participant A as Agent SIEM
    participant S as Manager SIEM
    participant H as Répartiteur d'alertes
    participant D as Zulip + Telegram

    Z->>C: fichier nouveau ou modifié
    C->>M: contenu, en INSTREAM
    M-->>C: verdict + signature
    Note over C: le serveur ignore le chemin<br/>et la machine : c'est le client<br/>qui détient le contexte
    C->>Z: mise en quarantaine
    C->>J: ligne au format attendu par le décodeur
    A->>J: lecture
    A->>S: événement
    S->>S: règle → niveau de sévérité
    S->>H: intégration filtrée par identifiant de règle
    H->>D: un envoi, deux destinations

Dos trampas en esta cadena, ambas silenciosas

El filtro de integración. Se centra en un identificador de regla, nunca en un grupo. Un filtro por grupo incorpora reglas vecinas y envía duplicados a través del mismo canal.

El nivel de severidad. Decide qué se envía. Un nivel demasiado alto hace que se envíe dos veces a través de dos caminos diferentes; un nivel demasiado bajo silencia la detección. Este ajuste se verifica provocando intencionadamente una detección con un archivo de prueba inofensivo, no leyendo la configuración.

La notificación

Todas las alertas convergen hacia un único distribuidor: un emisor envía una vez, y el distribuidor duplica hacia los destinos. Cuando un destino cambia, solo la configuración de los canales se modifica — ningún emisor necesita ser actualizado. El detalle — y lo que el parque hace automáticamente cuando una regla lo requiere — se encuentra en Respuesta.

Una alerta que se repite no dice nada

Cualquier notificación recurrente se basa en una hiistencia y la duración de la serie. Una alerta que se envía cada hora durante tres semanas ya no es una alerta: es ruido que el sistema filtra, y oculta la verdadera.

7 · Secretos

Dónde Qué Propiedad
Cofre auto-alojado Contraseñas, tokens, claves, notas Fuente de verdad, desbloqueado por un servicio dedicado
Archivos cifrados en el repositorio Variables de entorno de los stacks Cifrados en reposo, versionados, descifrados al desplegar
Análisis antes de commit y antes de enviar Múltiples detectores de secretos apilados en cada diff, y luego todo el historial en integración continua Bloquea antes de que el secreto entre en el historial
Escaneo de hosts Secretos que permanecen en texto plano en los discos Severidad basada en los permisos del archivo

Tres reglas que no se pueden negociar:

  1. Los archivos de entorno no se leen ni versionan en texto plano.
  2. Un secreto nunca pasa por una URL. El registro de errores de un motor de flujo de trabajo registra la URL resuelta, incluyendo los tokens — y esta información persiste después de la rotación del secreto.
  3. Un valor leído desde el cofre pasa por un "tuber", nunca por la línea de comandos: no atraviesa la tabla de procesos, ni el historial del shell, ni la transcripción de una sesión asistida.

Procedimiento: Leer un secreto del cofre.

8 · Cadena de suministro

Esta es la superficie de ataque que ha cambiado más en los últimos años, y que ningún firewall cubre.

Cuarentena de versiones. No se instalan versiones publicadas hace menos de siete días. Esta es la única defensa que habría detenido la difusión masiva de paquetes maliciosos de los últimos meses: todas fueron detectadas y retiradas en cuestión de horas o días. El retraso convierte una carrera en un asunto trivial.

La cuarentena se aplica en tres lugares diferentes

Los tres gestores de paquetes del ecosistema aplican esta regla, pero con tres unidades y tres ubicaciones: una en días, otra en minutos, y la tercera en segundos; una a nivel de máquina, y otra solo por repositorio.

Consecuencia práctica: un repositorio puede no tener ninguna cuarentena, y nadie lo detecta. Por lo tanto, el archivo de configuración que la define forma parte del esqueleto de un nuevo proyecto, al igual que el archivo de exclusión de versiones.

Imágenes fijadas por huella. Las imágenes de contenedores se identifican por su condensado, no por una etiqueta. Una etiqueta es un puntero mutable: stable de hoy no es stable de mañana, y nada en el archivo de composición lo indica.

Registro interno. Las imágenes creadas internamente viven en un registro privado, y un espejo de registro absorbe las imágenes públicas — lo que elimina así tantas dependencias directas a un servicio de terceros al inicio.

Vulnerabilidades conocidas e inventario. Las imágenes en funcionamiento y los repositorios se escanean diariamente, y cada hallazgo se clasifica según tres ejes: gravedad, explotación constatada y exposición, en lugar de basarse únicamente en su nota. Cada imagen en funcionamiento tiene su SBOM. Detalle: Detección.

9 · Parches y exposición de hardware

Parches. Los servidores siguen un esquema de actualizaciones no supervisadas, extendido durante la noche con un retraso aleatorio por servidor. Los componentes cuya actualización reinicia un servicio crítico se excluyen intencionalmente y se gestionan manualmente.

Una actualización importante desactiva los repositorios de terceros

Esto ocurrió en este parque: una actualización del sistema dejó de funcionar los repositorios de terceros, dejando tres meses sin actualizaciones de seguridad en los componentes afectados, sin errores visibles. Después de cualquier actualización importante, la presencia de los repositorios se verifica explícitamente.

Discos. El estado SMART de todos los discos físicos se registra y se alerta antes de la falla. Un punto de atención: los indicadores de los fabricantes no hablan el mismo idioma, y un estado "fallido" puede ser simplemente una tabla de correspondencia malinterpretada. Un reemplazo se decide basándose en una tendencia, nunca en una única lectura.

Copias de seguridad. Cada servidor envía un repositorio cifrado al NAS, con retención, verificación de integridad y restauración mediante navegación. El cifrado se realiza por el cliente, antes del envío: el servidor del repositorio no posee las claves. El repositorio rechaza cualquier eliminación proveniente de los servidores, existen copias fuera del sitio, y una restauración real se cronometra regularmente: ver Continuidad.

10 · Los flujos, sin direcciones

De A Canal Objeto
Cliente de Internet Proxy de borde HTTPS Cualquier solicitud pública
Proxy de borde Proxy interno HTTPS Enrutamiento de aplicaciones
Proxy interno Proveedor de identidad HTTP interno Autenticación
Proxy interno CrowdSec API local Decisión de bloqueo
Clientes de escaneo Motor antivirus TCP dedicado, IN STREAM Contenido a analizar
Proceso de actualización Distribución de firmas HTTPS saliente Solo salida de Internet de la cadena antivirus
Agentes Manager SIEM Canal cifrado del agente Eventos, integridad, inventario
Agentes fuera de la red local Manager SIEM Idem, a través del enrutamiento Idem
Manager SIEM Distribuidor de alertas HTTP interno Alertas filtradas por identificador de regla
Distribuidor Mensajería de equipo HTTPS saliente Notificación, dos destinos
Servidores Servidor de respaldo HTTPS interno Datos ya cifrados
Servidores Cofre de secretos HTTPS interno Lectura de un secreto, a través de un túnel
Detección en tiempo de ejecución Archivo local, luego distribuidor Local, luego HTTP interno Eventos de llamadas al sistema, notificados después de medir el ruido
Punto de convergencia del tráfico IDS de red Escucha pasiva Firmas aplicadas en tránsito
Clientes de investigación Servidor de investigación Canal cifrado, a través del enrutamiento fuera de la red local Solicitudes y resultados de investigación
Lanzador de sondas Registro de pruebas API autentificada Sentencias fechadas
Registro de pruebas Dos repositorios Git remotos HTTPS saliente Anclaje diario

Lo que esta arquitectura no cubre

Una nota de arquitectura que solo enumera sus fortalezas es una simple descripción. Las limitaciones estructurales — aquellas que dependen de las elecciones de arquitectura, y no del estado del entorno — se exponen claramente:

  • El NAS es tanto el borde de la red WAN, como el almacenamiento principal y el depósito de respaldo. Es un único punto de fallo, y también la máquina más expuesta. Por eso, el depósito de respaldo no permite ninguna eliminación proveniente de los hosts, y por eso existen copias fuera del sitio.
  • Una única dirección IP pública. Toda la cadena de actualización de firmas depende de ello, y un bloqueo por parte del proveedor perjudica la detección sin errores visibles.
  • No hay un entorno de pruebas dinámico. El análisis de archivos es estático. Un binario que solo revela su comportamiento durante la ejecución pasa por ambos motores.
  • La protección antivirus es una lista de zonas, no una propiedad del host. Un directorio recién creado no es monitoreado hasta que alguien lo haya añadido.
  • El sistema macOS depende de permisos otorgados manualmente (acceso completo al disco, reglas de firewall saliente). Una reinstalación las elimina todas, silenciosamente.
  • CrowdSec actúa sobre HTTP. Un servicio expuesto en otro protocolo solo está cubierto por el filtrado de red.

Leer después

Dernière vérification de cette page : 2026-09-11