¿Cuáles son las posibles implementaciones (o ejemplos) del principio de los cuatro ojos?

Michael Grünewald recientemente publicó este comentario :

Un método muy importante que no menciona es el "principio de cuatro ojos" que se utiliza en las finanzas, ya sea como una obligación regulatoria o como una salvaguardia. En la industria del software, se implementa de varias maneras, como por ejemplo, revisiones de código, pero también se puede usar para validar comandos que afectan a los sistemas en vivo.

Corríjame si me equivoco, pero me enseñaron que el "principio de los cuatro ojos" se trata de algo que está "aprobado para suceder", después de que al menos 2 seres humanos (y / o procesos automatizados) dieron su bendición previa. O para usar la redacción (ligeramente corregida) sobre la "regla del hombre dos (wo)" de Wikipedia :

La regla de los dos hombres es un mecanismo de control diseñado para lograr un alto nivel de seguridad para materiales u operaciones especialmente críticos. Bajo esta regla, todo acceso y acciones requieren la presencia de dos personas autorizadas en todo momento.

Las obligaciones regulatorias están, bastante seguro, fuera de tema aquí, pero en el contexto de la "protección", ¿cuáles son las posibles implementaciones conceptuales de este principio de cuatro ojos, que probablemente podrían aplicarse a cualquier plataforma / SO / hardware que se utilice?

Una de las implementaciones en el código es el modelo de solicitud de extracción (PR) popularizado por GitHub.

El principal razonamiento detrás es que solo un pequeño conjunto de mantenedores del producto podrá fusionar código en la rama de lanzamiento. Cada nueva característica / corrección de errores sucederá en una nueva rama y una vez hecho esto se definirá como una solicitud de extracción.

Esto permite probar en la fusión del código de lanzamiento real (maestro) con el código en el PR de forma automática (Travis es el más popular para proyectos públicos en realidad) y dar una primera retroalimentación sobre la calidad del código. Travis CI (por ejemplo) puede ejecutarse en el resultado del maestro real con el código de la solicitud de extracción fusionada, por lo que fallará si la fusión es imposible o si los comandos definidos en travisci.yml devuelven una salida distinta de cero código

Una vez que las pruebas automáticas han pasado, para el principio de 4 ojos, todavía se requiere un número configurable de personas para revisar y aprobar el cambio antes de que se fusione, obviamente, al menos 1 persona (que no es el autor de relaciones públicas) para exigir que 4 ojos revisen cambios

Hay una amplia gama de opciones para fusionar automáticamente una vez que se cumpla el quórum de revisores o para que un mantenedor aún necesite una fusión manual.

Los permisos para revisar y fusionar se pueden separar, lo que ayuda a otorgar a más personas el derecho de "votar" sobre el estado de la fusión, al tiempo que mantiene la posibilidad de restringir quién puede realmente hacer la fusión.

Revisiones de código

Se trata de que al menos otra persona vea el código escrito por alguien, por ejemplo, para evaluar si cumple con algunos criterios predefinidos como:

• Normas de codificación (hendiduras, etc.).
• Documentación en línea.
• Mantenibilidad del código.
• Manejo de errores.
• Integridad (por ejemplo, if/then/elseo las case/whenconstrucciones cubren todos los casos posibles).

Aprobaciones para actualizar algunos entornos objetivo

Se trata de tener al menos 2 confirmaciones de alguna persona y / o sistema automatizado antes de que se le permita actualizar algún entorno de destino (que puede estar en vivo, o puede ser algo así como un archivo maestro / biblioteca de línea de base). Algunos ejemplos son:

• Solo se permite un conjunto limitado de advertencias al transformar (construir) componentes de origen en componentes ejecutables.
• Algún conjunto de pruebas automatizadas debe haberse completado sin ninguna sonda.
• Algunos seres humanos deben haber indicado su aprobación previa (y sin eso, cualquier intento de actualizar los entornos objetivo fallará automáticamente).

Estas son estrategias / patrones en los que puedo pensar:

Separación del deber

DevOps, al menos en mi opinión, no significa encarnar tanto a los desarrolladores como a las operaciones en una sola persona. Por lo tanto, todavía es posible separar el deber de manera que el que escribe el código (dev) no sea el que lo ejecuta (ops).

Por ejemplo, si se va a ejecutar una instrucción SQL en el entorno en vivo, uno escribe el SQL y otro lo ejecuta. Lo que esto presupone es que el que ejecuta también debe tener una comprensión del SQL y no solo ejecutar.

Implementar disparador

Si bien hay méritos para implementar continuamente. El equipo en una industria más regulada puede designar a otra parte (separada) para activar el despliegue en lugar de desplegarse automáticamente. Lista de verificación, pruebas automatizadas, sumas de verificación son posibles verificaciones antes de iniciar la implementación.

Una vez activada, la automatización puede seguir adelante para ejecutar la implementación.

Programación en pareja

Personalmente, no he citado esta técnica como un método para el auditor para satisfacer el principio de verificación y equilibrio. Pero potencialmente creo que puede ser una estrategia.

AMF

Puede que me estire un poco con este, pero es posible que por alguna razón que no desee una entrada unilateral en un sistema, alguien pueda tener la contraseña y otra persona tenga el token o dispositivo por un código de tiempo. Para que 2 personas deben estar presentes para evaluar el sistema.