Lista de comprobación de bastionado

El bastionado es el proceso de reducir los privilegios evitables y hacer que la recuperación sea predecible antes de un incidente. El responsable de seguridad aprueba las excepciones, el responsable de la plataforma implementa los controles de host y de red, y los responsables de los servicios demuestran que unos controles más estrictos no rompen los flujos de trabajo necesarios. Prioriza los controles por su impacto en los clientes y por el alcance de las credenciales, no por el número de elementos de la lista.

Empieza por los límites que pueden comprometer toda la instalación: el acceso al host de Opfield, las identidades de administrador, las claves de cifrado y de PKI, PostgreSQL, Redis, la identidad de Relay y el almacenamiento de las copias de seguridad. Después bastiona los roles de los nodos gestionados, las cargas de trabajo, los proveedores y la automatización.

Mantén los hosts de Opfield y de los daemons con los parches al día y dedicados a sus roles cuando sea posible.
Restringe PostgreSQL y Redis a la red privada de la aplicación.
Expón solo los puertos HTTPS y de Relay que requiera el despliegue.
Exige MFA a los administradores y reduce al mínimo el número de administradores.
Guarda las claves maestras y las copias de seguridad fuera del host de Opfield.
Usa credenciales de servicio limitadas por recurso e intervalos de rotación cortos.
Prefiere digests de imagen inmutables y Build Workers dedicados.
Deniega los bind mounts del host y el acceso privilegiado o a dispositivos salvo que un flujo de trabajo compatible y explícito los requiera.
Mantén privadas las bases de datos gestionadas y usa identidades de vinculación.
Mantén activada la verificación de certificados TLS en las conexiones a bases de datos externas, y actívala en las conexiones que muestren TLS certificate is not verified tras actualizar a la 2.11.
Supervisa la renovación automática de los certificados de Opfield, Relay y los daemons, y conserva la PKI del sistema usada para el transporte interno; consulta Nodos: renovación de certificados.
Envía los eventos de auditoría a un SIEM controlado de forma independiente cuando sea necesario.
Revisa con regularidad las integraciones de código fuente, las credenciales de registros, los clientes OAuth, los tokens y las sesiones activas.
Trata los tokens de API y las concesiones OAuth que tienen ámbitos administrativos, como admin:system, admin:users, settings:opfield:edit o nodes:manage, como credenciales de administrador: desde la 2.11 el acceso programático puede llevarlos. Asigna a cada uno un responsable, una caducidad y el alcance de recursos más reducido posible.
Elimina tras los incidentes el mantenimiento temporal, la exposición para depuración y los cambios manuales en los hosts.

No publiques capturas de pantalla, paquetes de soporte ni logs hasta haber ocultado los secretos, las direcciones internas, los nombres de clientes y las URL de repositorios.

Plano de control

Ejecuta Opfield en una VM o un host dedicado y restringe el acceso directo a la shell y a Docker.
Mantén PostgreSQL, Redis, el gRPC interno y el inference core en redes privadas.
Protege .env, las claves de cifrado, las claves de PKI, los artefactos subidos y la identidad de Relay con una propiedad restrictiva y copias de seguridad.
Usa HTTPS en la URL pública canónica y verifica el comportamiento de las cookies, los WebSockets, OAuth y el proxy.
Desactiva los métodos de autenticación y las integraciones que no uses.

Nodos gestionados

Usa una identidad de registro por cada rol de host y no copies nunca certificados de daemons entre hosts.
Restringe los destinos salientes a Opfield/Relay y a los proveedores necesarios cuando sea posible.
Protege las unidades de systemd, la configuración, los anclajes de confianza de las actualizaciones, los sockets de ejecución y el almacenamiento local.
Mantén aislados los roles Ingress, Build Worker, Storage y Relay según su riesgo.
Configura alertas por una última conexión antigua, degradación de capacidades, presión de disco e incompatibilidad de actualizaciones.

Cargas de trabajo y builds

Prefiere imágenes fijadas por digest y revisa el código fuente, los logs de build, la política de vulnerabilidades y los límites de procedencia.
Ejecuta los builds de Git solo en Build Workers dedicados.
Usa volúmenes gestionados en lugar de bind mounts del host.
No concedas modo privilegiado, dispositivos arbitrarios, red del host ni acceso al sistema de archivos del host sin un requisito explícito y compatible.
Guarda los secretos de ejecución y los Build Secrets a través de sus vías cifradas separadas.

Datos y conectividad privada

Mantén sin publicar por defecto las bases de datos gestionadas.
Usa una identidad de vinculación por cada relación de aplicación y verifica que las credenciales de propietario nunca entran en la configuración de las cargas de trabajo.
Protege las redes de enlace propiedad de Opfield y el conector de Secure Links frente a las acciones de ciclo de vida de los usuarios.
Haz copias de seguridad de los datos de las aplicaciones con los procedimientos nativos de cada motor y prueba la restauración de forma independiente de la recuperación de Opfield.
Mantén activado TLS en las conexiones directas a bases de datos salvo que esté documentada una excepción deliberada para una red privada.

Garantía operativa

Revisa con una periodicidad fija los administradores, los ámbitos de los grupos, los tokens, los clientes OAuth, las integraciones de código fuente, los conectores DNS, las credenciales SMTP, los destinos SIEM y las sesiones activas. Prueba los caminos de denegación con identidades sin privilegios de administrador.

Haz ejercicios de incidentes, restauración, actualización, conmutación por error de Relay, reinicio de nodos, recreación de cargas de trabajo y recuperación de vinculaciones de bases de datos. Elimina el acceso temporal de depuración y documenta cualquier excepción aceptada con un responsable y una caducidad.

Gestión de excepciones

Algunas cargas de trabajo pueden requerir un control que la política predeterminada evita, como la publicación directa de una base de datos, la red del host, un dispositivo o un acceso más amplio al proveedor. Trátalo como una excepción revisada, no como un interruptor oculto. Registra el requisito de negocio, los recursos afectados, la amenaza introducida, los controles compensatorios, el responsable que lo aprueba, la fecha de revisión y el desencadenante de su retirada.

No debilites un nodo o una instalación completa para dar cabida a una carga de trabajo cuando un nodo dedicado, un segmento de red o un servicio externo puedan aislar la excepción. Vuelve a validar las excepciones tras cambios en la aplicación, el entorno de ejecución, el rol del nodo o el proveedor.

Verificación y recuperación

Para cada control de bastionado, demuestra tanto la operación prevista como la denegación esperada. Verifica la recuperación de administradores tras desactivar la autenticación no usada, la recuperación de cargas de trabajo tras retirar el acceso al host, el comportamiento de los builds con restricciones de salida, la renovación de certificados con credenciales DNS restringidas y el acceso a bases de datos mediante identidades de vinculación tras reiniciar el nodo y la carga de trabajo.

Mantén un método de recuperación que no dependa del componente que se está reparando. Las claves de las copias de seguridad deben estar accesibles cuando se pierde el host de Opfield; la recuperación de administradores debe funcionar cuando OIDC o el correo no están disponibles; las copias de seguridad nativas de los motores deben poder restaurarse cuando el plano de control no está disponible. Guarda las pruebas y revísalas con una periodicidad fija.