1. Pregunta y contexto
Un equipo de plataforma necesita cambiar reglas de firewall, límites de pago o enrutamiento de servicios. El solicitante no puede aprobar su propio cambio, la aprobación debe apuntar a una versión exacta y una ejecución fallida no debe dejar una actualización parcial. El objetivo es un flujo de trabajo verificable, auditable y recuperable.
2. Qué está evaluando el entrevistador
- Si separa los estados de propuesta, aprobación, ejecución y reversión.
- Si los aprobadores son independientes y el contenido aprobado no se puede reemplazar silenciosamente.
- Si maneja aprobaciones concurrentes, solicitudes duplicadas, tiempos de espera, revocaciones y cambios de permisos.
- Si proporciona un despliegue de alcance reducido y una recuperación estable mientras controla el riesgo.
NIST SP 800-128 exige que los cambios de configuración sean revisados por una persona autorizada e independiente del solicitante. Google SRE enfatiza la revisión de código para las versiones de configuración y continuar sirviendo la configuración anterior cuando una nueva falla las comprobaciones. Traslade esos principios a los datos y a las transiciones de estado.
3. Preguntas aclaratorias antes de responder
- ¿Qué recursos y campos son de alto riesgo, y difieren según el entorno o el inquilino?
- ¿La aprobación es de una sola persona, cualquiera de varias, o un umbral entre roles y personas?
- ¿La ejecución es un cambio total, un despliegue por lotes o una confirmación por instancia de destino?
- ¿La reversión es a la última versión correcta conocida o a una versión elegida por el solicitante?
4. Estructura de respuesta en 30 segundos
Utilice propuesta inmutable, coincidencia de políticas, aislamiento de aprobaciones, ejecutor, reversión y auditoría.
Congelo cada cambio como una versión inmutable y una política selecciona aprobadores independientes a partir del recurso, el riesgo y el entorno. La aprobación registra el resumen criptográfico de la versión y la versión de la política, y el solicitante no puede cumplir el umbral de aprobación. Un ejecutor idempotente aplica el cambio en lotes con comprobaciones de salud. Cualquier falla detiene el despliegue posterior y restaura la última versión verificada, mientras que cada estado y decisión se envía a un almacenamiento de auditoría de solo anexión.
5. Análisis detallado paso a paso
Paso 1: Definir las entidades y la máquina de estados
Una propuesta contiene recursos, diff, autor, resumen criptográfico de la versión, entorno de destino y expiración. Una aprobación contiene aprobador, rol, decisión, hora, versión de la política y resumen criptográfico de la propuesta. Un registro de ejecución contiene lote, destino, resultado y versión de reversión. Los estados pueden ser DRAFT, PENDING_APPROVAL, APPROVED, EXECUTING, SUCCEEDED, FAILED, REVOKED o EXPIRED; solo las reglas del lado del servidor pueden realizar la transición entre ellos.
Paso 2: Hacer que la aprobación sea independiente y esté vinculada a la versión
El servicio de políticas calcula los roles requeridos, las personas, la prohibición de autoaprobación y el tiempo de vida de la aprobación. El diff mostrado a un aprobador debe coincidir en su hash con la versión de ejecución; cualquier edición de la propuesta invalida la aprobación e inicia una nueva revisión. Vuelva a verificar los permisos en el momento de la aprobación y de la ejecución para que no se pueda eludir una revocación posterior de roles.
Paso 3: Controlar la publicación con un ejecutor idempotente
Genere una clave de idempotencia para cada propuesta y destino, y registre los acuses de recibo externos. Aplique lotes pequeños después de comprobaciones de sintaxis, dependencias y seguridad, y luego observe las señales de salud. Reintente únicamente resultados desconocidos; nunca repita ciegamente una operación no idempotente. Una cola o motor de flujo de trabajo gestiona tiempos de espera, reintentos y límites de concurrencia.
Paso 4: Revertir de forma segura y auditar
Guarde la última versión verificada antes del lanzamiento. En caso de falla, detenga los lotes posteriores y restaure esa versión. Registre el operador y el motivo de la reversión; una reversión de emergencia de alto riesgo puede requerir su propia aprobación. Audite al menos el resumen criptográfico de la propuesta, la cadena de aprobación, los lotes de ejecución, las versiones de configuración, el motivo del fallo y el resultado de la reversión, con eliminación y mutación restringidas.
6. Ejemplo de respuesta de alta calidad
Dividiría el sistema en una API de propuestas, un servicio de políticas, un servicio de aprobaciones, una cola de ejecución, adaptadores de configuración y almacenamiento de auditoría. La propuesta es inmutable y contiene el diff del recurso, el entorno, el autor y la expiración. El servicio de políticas calcula los roles requeridos y el recuento de aprobadores según el riesgo, excluyendo al autor.
>
Los aprobadores ven el resumen criptográfico de la versión y el diff, y la aprobación se vincula al hash de la propuesta y a la versión de la política. Cualquier edición devuelve la propuesta al estado de aprobación pendiente. Una vez que se alcanza el umbral, el ejecutor crea una clave de idempotencia a partir del ID de propuesta y el ID de destino, ejecuta comprobaciones estáticas y luego aplica lotes pequeños mientras lee las señales de salud. Una solicitud duplicada devuelve el resultado de ejecución existente; un resultado desconocido pasa a revisión.
>
Cada propuesta conserva la última versión verificada. Si un lote falla, los lotes posteriores se detienen, se restaura la versión anterior y se registra el motivo; una reversión de emergencia de alto riesgo aún necesita aprobación independiente. Los eventos de auditoría son de solo anexión y registran quién aprobó qué resumen criptográfico, cuándo, qué destinos se ejecutaron y si ocurrió una reversión. Esto hace cumplir la separación de funciones y evita que una configuración aprobada sea reemplazada silenciosamente.
7. Modos de falla comunes
- Vincular la aprobación solo a un ID de recurso en lugar del diff exacto y el resumen criptográfico de la versión.
- Permitir que el autor se autoapruebe a través de un segundo rol.
- Escribir la aprobación directamente en el almacén de configuración sin estado de ejecución ni acuses de recibo.
- Expandir el despliegue tras un fallo o reintentar operaciones no idempotentes indefinidamente.
- Revertir sin registrar la versión, la autorización y la evidencia de auditoría.
8. Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Qué sucede si el autor deja la empresa tras la aprobación?
La decisión está vinculada a una propuesta inmutable y no requiere que el autor esté en línea. La ejecución utiliza la cuenta de servicio y la política actual; revocar al autor no borra la cadena de auditoría válida.
Pregunta de seguimiento 2: ¿Cómo evita que dos flujos de aprobación ejecuten el mismo recurso?
Utilice un bloqueo o arrendamiento de recurso y entorno, y luego vuelva a verificar la versión actual de la configuración antes de la ejecución. En caso de conflicto, la propuesta más reciente recalcula su diff y su aprobación.
Pregunta de seguimiento 3: ¿Puede un cambio de emergencia eludir la aprobación?
Defina una ruta de acceso de emergencia restringida (break-glass) con autorización de dos personas, privilegio mínimo, vida útil corta, revisión posterior al cambio y auditoría completa. No debe convertirse en el atajo habitual.