Sistemas air-gapped: software crítico sin conexión a internet

Hay sistemas que nunca deben hablar con internet: el control de una emisión en directo, la red de un hospital, una línea de producción, un laboratorio con datos sujetos a control de exportación. Durante años eso significaba renunciar a las herramientas modernas. Ya no. Kubernetes, GitOps, imágenes firmadas y una monitorización seria funcionan dentro de un enclave sin ninguna salida, siempre que trates la frontera como un proceso y no solo como un cable que falta. Así es como los construyo y los opero.

Dominik Heinrich

7 de noviembre de 202610 min de lectura

1. Qué es de verdad un air gap

La palabra se usa para tres cosas muy distintas, y la diferencia importa. Un air gap físico significa que no hay ningún camino de red: los datos solo viajan en soportes que alguien lleva de un lado a otro. Una pasarela unidireccional, a menudo llamada diodo de datos, impone la dirección por hardware: los datos entran en el enclave, o salen para monitorización, pero nunca vuelven. Una separación lógica es un firewall que debería bloquearlo todo, es decir, segmentación, no aislamiento: basta una regla equivocada para que el hueco desaparezca. NIST SP 800-82, la guía estadounidense de seguridad para tecnología operativa, trata la segmentación y las pasarelas unidireccionales como herramientas distintas precisamente por eso. Antes de diseñar nada, anota cuál de las tres tienes de verdad, porque el proceso de actualización, la monitorización y el modelo de amenazas dependen de ello.

Consejo práctico

Dibuja en una página los flujos de datos reales, incluidos los USB, los portátiles de los técnicos de servicio y las herramientas de soporte remoto. Esa página suele mostrar el hueco que no sabías que tenías.

2. Cuándo lo necesitas y cuándo no

Un air gap tiene sentido donde un incidente sería catastrófico o donde la normativa lo exige: redes clasificadas y de defensa, sistemas de control industrial en energía y fabricación, producción de televisión en directo donde un ataque te saca del aire, dispositivos médicos, núcleos de pagos y trading, y datos de investigación con control de exportación. Cuesta algo real: las actualizaciones llegan por lotes en lugar de forma continua, cada herramienta nueva necesita una solución sin conexión y en la frontera hace falta disciplina. Por eso decido por sistema, no por empresa. Normalmente solo las joyas de la corona quedan detrás del aislamiento y todo lo demás sigue conectado y bien segmentado. Los controles de NIST SP 800-53 sobre protección de fronteras y flujos de información son una buena lista para defender esa decisión ante los auditores.

3. La arquitectura: tres zonas y una sola dirección

Cada entorno que construyo tiene las mismas tres zonas. La zona conectada trae lo que necesitas del exterior: imágenes de contenedores, charts de Helm, actualizaciones del sistema operativo, repositorios Git. La zona de transferencia es un área pequeña y bastionada donde todo se analiza en busca de vulnerabilidades, se describe en una lista de materiales de software (SBOM) y se firma antes de empaquetarlo con un manifiesto de checksums. El enclave solo recibe ese paquete, lo verifica de nuevo y lo sirve desde su propio registro y su propio Git. Herramientas como Zarf resumen bien la idea con su lema, desarrollar conectado y desplegar desconectado, y empaquetan justo este flujo. Uses una herramienta así o unos cuantos scripts, la regla es la misma: nada dentro del enclave sale nunca, todo entra por una única puerta controlada.

Kubernetes air-gapped: una zona conectada con registros de fabricantes, Git y actualizaciones; una zona de transferencia que analiza, genera la SBOM y firma; una transferencia unidireccional a un enclave con registro privado, Git interno con GitOps, un clúster de Kubernetes con pods Linux y máquinas virtuales Windows en KubeVirt, monitorización interna, fuente de tiempo local y acceso de emergencia, sin ninguna ruta a internet. — Cómo llega el software a un enclave de Kubernetes air-gapped: analizado y firmado fuera, movido en una sola dirección y verificado de nuevo dentro. Haz clic para verlo a tamaño completo.

4. Imágenes, charts y SBOM, fijados y firmados

Replica solo lo que ejecutas, nunca un registro público entero. Fija cada imagen por digest y cada chart por versión, porque las etiquetas cambian y luego no hay forma de comprobar qué significaba una etiqueta el día que la copiaste. kubeadm lista exactamente las imágenes que necesita una versión concreta de Kubernetes y Helm descarga un chart como archivo. Genera una SBOM en formato SPDX o CycloneDX para todo el paquete; la CISA describe la SBOM como la lista de ingredientes que te permite responder en minutos si te afecta la próxima gran vulnerabilidad. Después, firma. En la zona conectada funciona bien un par de claves con cosign: la clave privada se queda fuera, idealmente en un token hardware, y solo la clave pública entra en el enclave.

bash

# Connected zone: build one transfer bundle, pinned and signed
set -euo pipefail
mkdir -p bundle/images bundle/charts

kubeadm config images list --kubernetes-version "$K8S_VERSION" > bundle/k8s-images.txt
while read -r img; do
  skopeo copy --all "docker://$img" "oci-archive:bundle/images/$(echo "$img" | tr '/:' '__').tar"
done < bundle/k8s-images.txt

helm pull ingress-nginx/ingress-nginx --version "$CHART_VERSION" -d bundle/charts
syft dir:bundle -o spdx-json > bundle/sbom.spdx.json      # what is inside

(cd bundle && find . -type f ! -name SHA256SUMS -exec sha256sum {} + > SHA256SUMS)
cosign sign-blob --key cosign.key --bundle bundle/SHA256SUMS.bundle bundle/SHA256SUMS

Consejo práctico

Analiza en la zona de transferencia y rechaza el paquete si un hallazgo crítico no tiene una decisión documentada. Corregirlo después dentro del enclave cuesta diez veces más.

5. Cruzar el hueco: una dirección, verificado dos veces

El paquete cruza por un diodo de datos o en soportes extraíbles firmados, transportados con la regla de las cuatro manos. Del lado del enclave llega primero a cuarentena. Allí un host separado verifica la firma con la clave pública, compara cada archivo con el manifiesto de checksums y solo entonces importa las imágenes al registro privado y los charts y manifiestos al Git interno. Como el enclave no puede llegar a un registro público de transparencia, la verificación se hace solo con la clave, algo que cosign admite de forma explícita. Cada transferencia deja un registro: quién, cuándo, qué, qué checksums, qué aprobación. Acordad un ritmo fijo, por ejemplo un paquete por semana, y un camino de emergencia documentado para parches críticos, para que nadie caiga en la tentación de enchufar un cable «solo esta vez».

bash

# Enclave side, quarantine host: verify before anything is imported
set -euo pipefail
cd /quarantine/bundle

# Signature against the public key only (no public transparency log reachable)
cosign verify-blob --key /etc/airgap/cosign.pub \
  --bundle SHA256SUMS.bundle --insecure-ignore-tlog=true SHA256SUMS

sha256sum -c SHA256SUMS            # every file, byte for byte

for f in images/*.tar; do
  skopeo copy --all "oci-archive:$f" "docker://registry.enclave.local/mirror/$(basename "$f" .tar)"
done

6. Kubernetes dentro del enclave

Dentro, un registro privado como Harbor es la única fuente de imágenes, con análisis de vulnerabilidades y políticas que impiden descargar imágenes que no cumplen tus reglas. El runtime de contenedores de cada nodo lo usa como espejo, así que incluso un manifiesto que todavía dice docker.io se resuelve internamente y nunca intenta salir. Los despliegues llegan del Git interno mediante GitOps con Flux o Argo CD, con la misma revisión, historial y vuelta atrás que tendrías en la nube. En la admisión, un motor de políticas como Kyverno, que admite firmas de Sigstore cosign, rechaza cualquier imagen que no esté firmada con tu clave o que no venga del registro interno. Para los equipos resulta sorprendentemente normal: pull requests, pipelines y paneles, solo que con una cadena de suministro más lenta y mejor revisada detrás.

toml

# /etc/containerd/certs.d/docker.io/hosts.toml on every node:
# anything that asks for docker.io is served by the internal Harbor proxy project
server = "https://registry-1.docker.io"

[host."https://registry.enclave.local/v2/mirror-docker.io"]
  capabilities = ["pull", "resolve"]
  override_path = true

Consejo práctico

Ejecuta primero la política de admisión una semana en modo auditoría. Encontrarás esa imagen sidecar olvidada antes de que bloquee un despliegue en producción.

Cloud Native Deployments in Air Gapped Environments, CNCF (YouTube). Se carga desde YouTube solo cuando haces clic.

7. Windows y software heredado: máquinas virtuales en KubeVirt

Los enclaves reales casi nunca son solo contenedores. El software de control, las herramientas de fabricantes y los sistemas antiguos a menudo solo funcionan en Windows. KubeVirt los ejecuta como máquinas virtuales junto a tus pods, en los mismos nodos, con el mismo GitOps, la misma monitorización y la misma rutina de copias, así que no necesitas una segunda plataforma de virtualización con su propio problema de actualizaciones. He operado exactamente esta mezcla: Kubernetes híbrido entre bare metal y la nube para cargas de broadcast, aplicaciones Windows como máquinas virtuales en KubeVirt y las partes sensibles en air gap. Planifica pronto tres cosas: los drivers virtio que Windows necesita en KubeVirt, una forma de incluir las actualizaciones de Windows en tu paquete y una activación de licencias que funcione sin internet, por ejemplo con un servicio de activación dentro del enclave.

8. Las partes aburridas que fallan primero

En mi experiencia, las plataformas air-gapped casi nunca fallan en las partes ingeniosas. Fallan por la hora, los certificados y la visibilidad. Sin una fuente de tiempo local, los relojes derivan hasta que TLS y los tokens se rompen, así que lleva tu propia fuente NTP o PTP, por ejemplo un reloj GPS. Opera una autoridad de certificación interna y automatiza las renovaciones dentro, porque nadie puede pedir un certificado a internet. Mantén la monitorización, los logs y las alertas dentro del enclave; con una pasarela unidireccional puedes enviar métricas hacia fuera a un equipo central sin abrir nada hacia dentro. Prueba las copias restaurándolas dentro, con regularidad. Y define el acceso de emergencia antes del primer incidente: limitado en el tiempo, dos personas y todo registrado. Hasta mi pequeño robot sin conexión, un ESP32 con reconocimiento de voz y un modelo de lenguaje locales, me enseñó lo mismo: diseña desde el primer día para no tener red y lo demás se vuelve rutina.

Consejo práctico

Escribe el runbook para «la vía de transferencia está caída dos semanas» antes de necesitarlo: qué parches pueden esperar, cuáles necesitan el camino de emergencia y quién decide.

9. Una implantación realista

No empieces aislando todo. Elige un sistema que lo necesite claramente y construye para él la vía de transferencia de principio a fin: empaquetar, analizar, firmar, transportar, verificar, importar, desplegar. Repite ese ciclo unas cuantas veces con actualizaciones inocuas hasta que sea aburrido y esté documentado, y después mueve las cargas reales. Mide dos cifras desde el primer día: cuánto tarda un parche de seguridad crítico desde su publicación hasta estar funcionando dentro, y cuántas transferencias se rechazaron y por qué. La primera le dice a la dirección lo que cuesta el aislamiento en velocidad; la segunda demuestra que los controles funcionan de verdad. Tras unos meses, la mayoría de los equipos encuentra un ritmo en el que los paquetes semanales son rutina y el camino de emergencia se usa un puñado de veces al año, que es justo donde quieres estar.

Conclusión
Un air gap es tan fuerte como el proceso en su frontera: cada cruce analizado, firmado y verificado, y todo lo demás con su sitio dentro.

Proyectos reales relacionados

Kubernetes híbrido para broadcast en directo

Pruébalo tú mismo

Revisión de air gap

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos

Sistemas air-gapped: software crítico sin conexión a internet

1. Qué es de verdad un air gap

2. Cuándo lo necesitas y cuándo no

¿Tu air gap es algo más que una regla de firewall?

3. La arquitectura: tres zonas y una sola dirección

4. Imágenes, charts y SBOM, fijados y firmados

5. Cruzar el hueco: una dirección, verificado dos veces

6. Kubernetes dentro del enclave

7. Windows y software heredado: máquinas virtuales en KubeVirt

8. Las partes aburridas que fallan primero

9. Una implantación realista

Hablemos