Liberar sin miedo en su propia infraestructura

Lo que la norma pide, y lo que no

Muchas instituciones mantienen sistemas y datos en infraestructura propia, por su modelo de riesgo, sus contratos o sus sistemas heredados. No son minoría: en la encuesta 2024 de la CNCF, el 59 % de los participantes usa infraestructura propia autogestionada, igual que nube pública autogestionada (750 participantes de su comunidad). Operar en casa no es excusa para liberar sin disciplina.

Una precisión que conviene tener clara frente a cualquier comité: en general, la regulación mexicana no impone que la infraestructura esté en casa. Las disposiciones de la CNBV para bancos contemplan infraestructura propia o de terceros, incluso en el extranjero, con requisitos que dependen del servicio: aviso o autorización previa, continuidad ante fallas del proveedor y acceso de la autoridad a la información. La ley de datos personales tampoco fija una ubicación obligatoria, aunque sí condiciones para el tratamiento y las transferencias. El detalle se valida para cada entidad y cada servicio.

Lo que estos marcos sí piden es demostrar control: evidencia y trazabilidad proporcionales al riesgo. Tener la infraestructura en casa no lo garantiza. Lo que cambia es la responsabilidad: en casa, todo el control y toda la mitigación son suyos. Si el camino a producción está bien hecho, ese control se demuestra con evidencia y no con promesas.

¿Su infraestructura actual le permite demostrar ese control con la misma disciplina que una nube pública? Nube e infraestructura

Lo que viene inseguro de fábrica

Un clúster que pasa las pruebas funcionales puede reprobar una auditoría de seguridad si conserva su configuración de fábrica. Según la documentación oficial de Kubernetes y la guía de endurecimiento de la NSA y la CISA, varias cosas vienen así por omisión:

• Los secretos se guardan sin cifrar en la base del clúster.
• La bitácora de auditoría está apagada.
• Los espacios de nombres no aíslan la red: sin políticas explícitas, todo habla con todo.
• En clústeres creados con kubeadm, los certificados de cliente vencen al año por omisión. Se renuevan con las actualizaciones o con un procedimiento explícito; si nadie lo hace, el clúster deja de responder un día cualquiera.

Y hay uno físico que casi nadie mide: el almacén de estado del clúster (etcd) es muy sensible a la latencia de disco. Su guía de hardware da como referencia 50 operaciones secuenciales por segundo y 500 para clústeres cargados, y recomienda disco de estado sólido. Con latencia alta o muy variable, el síntoma no es «está lento»: son tiempos de espera, elecciones de líder y caídas de disponibilidad. Se mide con pruebas de carga representativas, antes de producción.

¿Alguien en su equipo podría decir hoy, sin buscar, cuándo caducan los certificados de su clúster?

Un solo camino a producción

Del cambio del programador a producción, todo pasa por el mismo camino, y cada compuerta puede detener la liberación:

1. Pruebas que frenan. Las pruebas obligatorias bloquean la promoción; las señales no concluyentes se registran y se atienden con una política explícita. Para una emergencia hay un procedimiento de excepción, con aprobación y rastro.
2. Calidad con el motivo a la vista. La compuerta no se conforma con «terminó bien»: dice qué condición falló.
3. Escaneo por categorías: código, dependencias, secretos expuestos, imágenes y configuración, con umbrales y excepciones trazables. Y distingue «encontró algo» de «no terminó de revisar»: las dos cosas detienen la liberación.
4. Construir una vez, promover lo mismo. Lo que se probó es lo que llega a producción; no se recompila por ambiente. La configuración y los secretos de cada ambiente se controlan aparte, con versión y rastro.
5. Fallar temprano y claro. Si al servidor de construcción le falta algo, falla en el primer paso diciendo qué falta.

¿Qué revisa hoy su proceso antes de llegar a producción, y qué deja pasar sin que nadie lo note? DevSecOps

Sin internet, el escáner también envejece

En una red aislada, la parte que más se descuida es la más silenciosa: la base de vulnerabilidades del escáner. Si nadie la actualiza, el escáner sigue diciendo «sin hallazgos» porque no conoce lo nuevo. Algunas herramientas se niegan a correr con una base de más de cinco días; otras siguen en verde con la base congelada. Un camino aislado bien hecho trae su propio espejo de esas bases, con fecha visible y una alerta cuando envejece.

¿Su escáner sabe de las vulnerabilidades publicadas esta semana? DevSecOps

Tres destinos, el mismo criterio

Las compuertas y la evidencia se reutilizan entre destinos; cada destino conserva sus propios requisitos de despliegue, identidad, monitoreo y recuperación, y pasar a Kubernetes exige rediseñar varios de ellos.

¿Cuál de los tres es el suyo hoy, y cuál debería ser en dos años?

Fallas que vemos con frecuencia

• Procesos de liberación duplicados y sin gobierno. Cuando cada equipo mantiene su propia copia, las copias divergen en silencio y la evidencia deja de ser comparable. Mejor un solo molde compartido y versionado.
• Instalar a mano desde la herramienta de construcción. Mezclar «quien construye» con «quien instala» deja cambios sin rastro. Mejor separarlos y describir el ambiente como código.
• Excepciones temporales que se vuelven permanentes. Un control omitido «solo en desarrollo» es el que después falla en producción.
• Identidades sueltas. El directorio propio del orquestador, separado del de la empresa, acumula cuentas huérfanas con privilegios altos (NIST SP 800-190).

Otros controles que suelen ser relevantes —gestión de secretos, firma e inventario de lo que se libera, aprobación humana para producción, segregación de funciones, recuperación y retención— se definen según su modelo de riesgo.