Despliegue en el borde e ingesta en el perímetro

La plataforma traslada todas las conexiones de red externas al perímetro más externo del sistema antes de que cualquier dato llegue a los anillos de procesamiento central, siguiendo la arquitectura de tres anillos. Esta arquitectura impide que los ataques de red habituales alcancen los registros financieros y los datos estructurados almacenados en el Anillo 2, que son protegidos por el registro WORM.

Puntos clave

• Todo el tráfico de internet entrante se procesa exclusivamente en el Anillo 1 — la capa de perímetro. Ningún payload externo llega al Anillo 2 sin antes haber sido saneado, validado y despojado de metadatos de transporte por el servicio de ingesta del Anillo 1 correspondiente. El internet público nunca está en contacto directo con el Anillo 2 ni con el Anillo 3.
• El Anillo 1 se implementa como un conjunto de servicios de ingesta por canal (correo electrónico, sistema de archivos, registros de personas, input externo). Tres de los cuatro — correo, sistema de archivos, registros de personas — exponen su interfaz de registros saneados como servidor MCP; el canal de input externo expone el mismo límite mediante HTTP simple. Cada uno acepta, sanea y entrega únicamente registros limpios y estructurados hacia el interior — un canal de ingesta comprometido no puede escalar al nivel del libro mayor.
• El registro de auditoría del Anillo 2 registra lo que el sistema procesó, no lo que llegó al perímetro de red. Esta separación es una condición previa del diseño del registro WORM: eventos limpios y validados — no tráfico en bruto — son lo que se escribe en el registro inmutable.
• El Anillo 2 no tiene ruta de salida a internet salvo a través de Servicio de egreso. El perímetro se aplica en ambas direcciones: entrada a través de la ingesta del Anillo 1, salida a través del servicio de egreso.

El problema de la ingesta profunda

Las configuraciones de servidor estándar procesan el tráfico de internet entrante dentro del mismo entorno de ejecución que contiene los datos centrales. Una vulnerabilidad en cualquier ruta de ingesta otorga acceso al mismo espacio de memoria que los registros principales. El aislamiento no puede añadirse retroactivamente una vez que un proceso comparte memoria con otro.

Posicionamiento en el perímetro

La plataforma sitúa todos los procesos de ingesta en el borde físico y lógico del sistema. Ningún payload de internet entrante cruza hacia el Anillo 2 sin antes pasar por la capa de perímetro del Anillo 1. El Anillo 1 se implementa como un conjunto de servicios de ingesta, uno por canal (correo electrónico, sistema de archivos, registros de personas, input externo). Correo, sistema de archivos y registros de personas exponen este límite como servidor MCP (Model Context Protocol); el canal de input externo lo expone mediante HTTP simple.

Cada proceso del Anillo 1 acepta el payload, lo desinfecta —elimina metadatos de transporte, valida la estructura y descarta entradas malformadas— y luego entrega únicamente el registro limpio y estructurado al Anillo 2. El internet público nunca está en contacto directo con el Anillo 2 ni con el Anillo 3.

Efecto sobre la integridad de la auditoría

Dado que los payloads en bruto se sanean en el perímetro y son los registros limpios los que procesa el Anillo 2, el registro de auditoría refleja sobre qué actuó el sistema, no lo que llegó a nivel de red. Esta separación es una condición previa del diseño del registro WORM.

Véase también

• Arquitectura de tres anillos — la arquitectura de tres anillos que define los límites del Anillo 1 y el Anillo 2
• Substrato WORM — arquitectura del ledger inmutable de cuatro capas y dos sobres de arranque — el registro WORM que almacena los datos saneados
• Ingesta de correo — ingesta del Anillo 1 para correo electrónico
• Sustrato compuesto — la arquitectura de tres anillos en contexto
• Cómo autoalojar un despliegue — guía paso a paso: desplegar la plataforma en infraestructura propia con ingesta del Anillo 1 configurada