Principio de los cuatro ojos en el despliegue: cómo hacer cumplir las aprobaciones mediante la herramienta

Objetivo

Detectar antes de producción los errores y abusos que podría introducir una sola persona (o un único agente que actúe con sus permisos), sin basar el proceso en la confianza ni en la memoria.

Requisitos previos

Un sistema de control de versiones y de CI que admita reglas por rama y por entorno: GitHub ofrece ramas protegidas y entornos con «Required reviewers»; GitLab ofrece aprobaciones para despliegues («Deployment approvals»). Al menos dos personas con permiso de revisión. Un despliegue que se realice exclusivamente desde la CI y solo desde la rama principal.

Pasos

1. Proteger la rama principal: prohibir los push directos, exigir al menos una aprobación, invalidar las aprobaciones cuando se suban nuevos commits (GitHub: «Dismiss stale pull request approvals when new commits are pushed») y registrar como obligatorias las comprobaciones de estado de la CI.
2. Excluir la autoaprobación: quien crea la propuesta de cambio no la aprueba por sí mismo. Para rutas sensibles (scripts de despliegue, infraestructura, permisos), exigir mediante un archivo de propietarios de código la aprobación de un segundo grupo designado.
3. Crear la producción como un entorno propio con aprobación obligatoria, de modo que el job de despliegue espere hasta que una persona autorizada lo apruebe. Esta aprobación es independiente de la revisión de código, porque el momento y el contexto de la entrega requieren una decisión propia.
4. Cerrar las vías de elusión: los administradores están sujetos a las mismas reglas («Do not allow bypassing the above settings»); las credenciales de despliegue residen solo en la CI, no en los equipos de trabajo.
5. Definir una vía de emergencia que desplace el principio en lugar de romperlo: un despliegue de emergencia requiere una segunda persona por teléfono, se marca como tal y se revisa a posteriori a más tardar el siguiente día laborable.
6. Comprobar con regularidad: quién tiene permiso de revisión, qué reglas se han eludido según el registro de auditoría y qué aprobaciones se dieron tan rápido que nadie puede haber leído el cambio.

Resultado esperado

Cada cambio en producción puede atribuirse a dos personas: la autora y quien lo aprueba. Una estación de trabajo comprometida o un agente que se desvíe no pueden desplegar una versión por sí solos.

Límites y base de verificación

El principio comprueba que alguien ha mirado el cambio, no con qué rigor; las revisiones de mero trámite lo desvirtúan, y contra eso solo ayudan una cultura de revisión y los muestreos, no las herramientas. Dos personas que colaboren entre sí pueden burlarlo; contra eso ayudan los registros y la separación de roles. Las configuraciones mencionadas siguen la documentación citada de GitHub y GitLab; no se afirma nada sobre el efecto en las tasas de error.