Cómo importar envíos de formularios públicos a una red privada

Un formulario público que nunca habla con la red privada igualmente produce datos que la red privada debe juzgar. El túnel solo cambia quién llama a quién. Todo lo que ocurre después de la descarga es una decisión de importación y pertenece al lado privado. Este recorrido sigue un envío desde el navegador hasta un registro interno consolidado.

Empiece donde aterriza el envío

El navegador publica en un punto de conexión público, que escribe una fila en un almacén de entrada controlado y no devuelve más que un acuse de recibo. Ese almacén es el punto de entrega y debería ser lo único en lo que la capa pública puede escribir. Mantenga allí la carga original sin cambios, junto con la hora de llegada y un identificador de registro estable.

Después, un trabajador privado extrae las filas pendientes por el túnel y decide qué hacer con cada una. Se ejecuta bajo su propia identidad, que es el tema de la sección siguiente.

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

Dé al importador solo la autoridad que necesita

El proceso web público y la identidad que escribe en la aplicación interna deberían ser dos sujetos distintos. Un servidor público no necesita administración interna solo porque tenga que entregar datos de formulario, y una única cuenta compartida para ambos lados convierte cualquier fallo web en una escritura interna. Emita para el trabajador su propia credencial, limítela a la única operación de importación y registre qué sujeto realizó cada importación. Esa separación es lo que hace que la frontera del túnel sea significativa y no decorativa.

Limite también de qué fuente puede leer el trabajador. Si la implementación usa una cola o un servicio de transferencia, ese servicio conserva su propia autenticación y política de acceso, porque la VPN no autentica nada dentro de la carga.

Una función de corta duración no está exenta de la misma revisión. Mientras se ejecuta, su posición de red y sus credenciales siguen otorgando autoridad, y una vida más corta solo estrecha la ventana. La duración no sustituye la decisión sobre qué operaciones puede realizar la identidad.

Valide antes de que cambie algo interno

Los campos de los formularios públicos son texto controlado por el atacante hasta que se demuestre lo contrario, y las directrices de validación de entrada de OWASP incluyen los flujos del backend entre las fuentes no fiables exactamente por ese motivo. Un transporte cifrado dice que los bytes llegaron intactos, no que describan una petición permitida. Analice y valide antes de cualquier paso privilegiado, para que una fila defectuosa nunca llegue a una ruta de código que pueda actuar.

Defina los campos permitidos, sus formatos, sus tamaños y las reglas de negocio que deben cumplirse. Una fecha puede estar bien formada y aun así ser incorrecta para la operación solicitada, y una carga que nombre una cuenta interna o un estado de aprobación no debe poder concederse ninguno de los dos.

Envíe las filas rechazadas a un resultado de revisión en lugar de adivinar una corrección o reenviarlas a un intérprete de órdenes o a una interfaz directa de base de datos. Registre el identificador del registro y la regla que falló, no todos los campos que escribió el solicitante.

Cree un punto de reintento en una sola operación

Si el registro submission-1042 se extrae dos veces porque se perdió el primer acuse, el trabajador necesita una forma duradera de reconocer el registro de origen y su resultado consolidado. Una programación que ejecuta la tarea una vez no demuestra que cada fila se haya aplicado una vez. La entrega duplicada es normal, así que el diseño debe absorberla.

Utilice el mecanismo propio de transacciones y de gestión de duplicados de la aplicación interna, y mantenga el identificador de origen, el resultado y el acuse en una secuencia coherente. Confirme solo después de que la operación prevista esté consolidada o asignada de forma duradera, y nunca elimine la fila de entrada solo porque se hayan descargado los bytes.

Luego demuéstrelo con tres archivos de prueba: una fila válida, una fila mal formada y el mismo identificador de origen controlado entregado dos veces. Cada uno pasa por el mismo punto de conexión que usa el trabajador.

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

Las dos primeras filas deben terminar en estados internos distintos, y la tercera debe devolver el identificador ya consolidado para ese registro de origen en lugar de crear uno segundo. Cualquier otra cosa significa que la importación todavía no es repetible.