¿Qué procesos o herramientas permiten la segregación de tareas cuando los ingenieros implementan y ejecutan código?

En entornos altamente regulados, como el sector de servicios financieros, la segregación de funciones es un mecanismo esencial para evitar colisiones entre personas con responsabilidades de desarrollo y privilegios de producción.

Tradicionalmente, esto ha significado que los Desarrolladores desarrollen código y luego lo entreguen a Operaciones; sin embargo, en muchos Modelos Operativos de DevOps, la segregación entre Desarrollo y Operaciones es, como mínimo, borrosa:

• En la práctica de Ingeniería de confiabilidad del sitio de Google , o SRE, hay una función SRE separada dentro de Google, sin embargo, los desarrolladores son contratados para respaldar los SRE en tiempos de alta carga operativa.

• En el modelo "You Build It, You Run It" no hay una función de operaciones separada.

Después de pasar meses profundizando en las causas profundas de un mecanismo de segregación de funciones, parece que existe principalmente para satisfacer a Sarbanes Oxley Sección 404 : Evaluación de la gestión de los controles internos:

(a) Reglas requeridas. La Comisión prescribirá reglas que requieren que cada informe anual requerido por la sección 13 (a) o 15 (d) de la Ley de Bolsa de Valores de 1934 contenga un informe de control interno, que deberá:

(1) declarar la responsabilidad de la administración para establecer y mantener una estructura de control interno y procedimientos adecuados para la información financiera; y

(2) contienen una evaluación, al final del año fiscal más reciente del emisor, de la efectividad de la estructura de control interno y los procedimientos del emisor para la información financiera.

(b) Evaluación e informes de control interno. En la evaluación de control interno requerida por el inciso (a), cada firma de contaduría pública registrada que prepare o emita el informe de auditoría para el emisor deberá dar fe e informar sobre la evaluación realizada por la administración del emisor. Una certificación realizada en virtud de este inciso se realizará de conformidad con las normas para trabajos de certificación emitidos o adoptados por la Junta. Cualquier certificación de este tipo no será objeto de un compromiso por separado.

Con base en los comentarios, es importante mencionar algunas suposiciones que estoy haciendo:

• Principalmente estoy considerando los servicios financieros del mercado masivo, es decir, los volúmenes de transacciones son de valor alto pero relativamente bajo. Esto sería opuesto a los servicios financieros comerciales que tienen un perfil de valor de transacción diferente.
• La oferta en línea de una institución financiera estará compuesta por muchos componentes que tienen diferentes consideraciones de riesgo:
  • Mover dinero : mover dinero entre cuentas o transferencias entre cuentas de diferentes propietarios. Una operación que debe considerar los países contra el lavado de dinero, la protección contra el fraude y el embargo, por nombrar algunos.
  • Adquisición de clientes : menos "arriesgado", ya que tiene bajos volúmenes de transacciones en comparación con Move Money, pero aún necesita consideración.
  • Banca por Internet : cubre una amplia gama de servicios con diferentes niveles de riesgo, Move Money se consideraría parte de esto.
• Posiblemente se podría adoptar un enfoque diferente para cada uno según el riesgo, sin embargo, en aras de simplificarlo, estoy trabajando para encontrar una solución que se aplique a algunas de las operaciones más riesgosas.

TL; DR : Es responsabilidad de la gerencia garantizar que existan controles internos adecuados que cumplan con las regulaciones de la Comisión de Bolsa y Valores .

Sarbanes Oxley 404 normalmente se satisface con la realización de una evaluación de riesgos de arriba hacia abajo, parte de la cual evaluará el riesgo de colusión y presentará estrategias de mitigación.

Dentro de una empresa que emplea la práctica y la cultura de DevOps, donde los Desarrolladores tienen acceso de forma rutinaria tanto al control de origen como a la producción, ¿cómo se puede lograr la Segregación de los Deberes, o más en general, cómo se puede mitigar el riesgo de colusión?

Su pregunta no parece suponer nada sobre la plataforma / sistema operativo del que se trata. Es por eso que puede tener sentido agregar una respuesta sobre cómo esto se hace / aborda típicamente en un entorno mainframe, donde los "ingenieros" (como en el título de su pregunta) son en realidad grupos de personas que eran docenas (posiblemente cientos) de personas. involucrado. Mi respuesta se basa en el uso del producto SCM con el que estoy más familiarizado (no estoy seguro de si es necesario revelar el nombre del producto).

1. Arquitectura

Estos son los aspectos más destacados de cómo respondería a su pregunta:

• Todo el código (y artefactos relacionados como ejecutables, etc.) se almacena en archivos que, en conjunto, es lo que llamamos la estructura de la biblioteca .
• Para cada entorno en cada sistema de destino (posiblemente remoto), hay un servidor (una "tarea iniciada" en el lenguaje principal), que se encarga de TODAS (repita: TODAS) las actualizaciones de cualquier cosa en la estructura de la biblioteca. Hay algunas excepciones (como personal de seguridad o equipo de administración de espacio), pero aparte de eso, nadie (repita: nadie) tiene autorización para aplicar actualizaciones a cualquier archivo dentro de esa estructura de biblioteca. En otras palabras: el servidor obtiene autorización de actualización exclusiva para toda la estructura de la biblioteca . Atención: las personas de OPS se volverán locas si entras para limitar su acceso (al principio van a resistir ...), así que asegúrate de estar cubierto por la alta gerencia (CxO) para imponer esas reglas de acceso ...
• El software real cambia mi consiste en un solo componente (una pequeña corrección de código en medio de la noche ...), o también puede ser cientos o miles de fuentes, ejecutables o cualquier otro artefacto (durante un fin de semana de lanzamiento). Para que sean manejables, las cosas que se deben mover (más o menos) juntas, al mismo tiempo, se agrupan en lo que se llama un paquete de cambio de software .

Con lo anterior en su lugar, cualquier tipo de actualización que aplique el servidor a la estructura de la biblioteca, solo será posible a través de un flujo de trabajo bien definido, que llamamos el ciclo de vida de un paquete de cambio de software (SDLC si lo prefiere). Para ejecutar realmente los diversos pasos en ese flujo de trabajo, esto es lo que se necesita para que esto suceda:

• Solo el servidor ejecutará los pasos necesarios (y preconfigurados).
• El servidor solo realizará un paso específico (= actualizar algo en algún lugar de la estructura de la biblioteca), después de que se hayan reunido las aprobaciones requeridas (de los seres humanos) para realizar dicho paso.
• Las aprobaciones solo pueden ser otorgadas por usuarios que tengan un rol que les permita (= permiso) emitir dichas aprobaciones.

2. Roles y permisos

Paso 1: configurar los permisos (en el sistema de seguridad)

• Defina entidades de seguridad en su sistema de seguridad, con nombres bien definidos para esas entidades. Algunas muestras (agregue tantas similares para satisfacer sus propias necesidades):

  • PrmUnit, Que se utiliza para obtener el permiso para solicitar una Promover decir Unidad -testing.
  • PrmQA, Que se utiliza para obtener el permiso para solicitar una Promover decir Qa -testing (vamos a suponer que este es el nivel más alto de la prueba).
  • PrdEnduser, utilizado por usuarios finales involucrados en algún nivel de prueba, para indicar que están satisfechos con los resultados producidos por algún tipo de prueba. Y debido a eso, esos usuarios finales están de acuerdo con el cambio que avanza en la estructura de la biblioteca.
  • PrdRelmgnt, utilizado por los administradores de versiones para autorizar una Activación en producción (= el último / más alto nivel en la estructura de la biblioteca).

• Defina grupos de usuarios en su sistema de seguridad. Algunas muestras (agregue tantas similares para satisfacer sus propias necesidades):

  • GrpDevs, que (por ejemplo) corresponde a sus desarrolladores (probablemente más que solo 1).
  • GrpEnduser, que (por ejemplo) corresponde a sus usuarios finales (al menos 1, preferiblemente con usuarios más similares).
  • GrpRelMgnt, que (por ejemplo) corresponde a sus administradores de versiones (al menos 1, preferiblemente algunos usuarios más).

• Otorgue permisos , también utilizando su sistema de seguridad, para permitir el acceso a " entidades de seguridad " seleccionadas para " grupos de usuarios " seleccionados. Para continuar con el ejemplo anterior, esto es lo que parece apropiado (adaptar para satisfacer sus propias necesidades):

  • El grupo GrpDevsobtiene acceso a (¡solo!) Entidad de seguridad PrmUnit.
  • El grupo GrpEnduserobtiene acceso a (¡solo!) Entidad de seguridad PrdEnduser.
  • El grupo GrpRelMgntobtiene acceso a (¡ambas!) Entidad de seguridad PrmQAy PrdRelmgnt.

Paso 2: configurar el flujo de trabajo (en el sistema SCM)

Después de configurar los permisos en su sistema de seguridad (como en el Paso 1), todo lo que queda por hacer en su sistema SCM es configurar cómo los diversos pasos en el ciclo de vida coinciden con las entidades de seguridad relacionadas en su sistema de seguridad. Es decir, solo aquellos usuarios que tienen el acceso apropiado a la entidad de seguridad requerida, pueden solicitar al servidor que realice el paso correspondiente en el flujo de trabajo.

Aquí hay algunos ejemplos de cómo configuraría su sistema SCM para que suceda algo de magia:

• Si un usuario tiene acceso a PrmUnit, y luego se le permite a dicho usuario para solicitar una Promover a Unidad -testing. Obviamente, los usuarios en grupo GrpDevsson los usuarios autorizados para esto (nota: no, por ejemplo, los usuarios en grupo GrpRelMgnt).
• Si un usuario tiene acceso a PrmQA, y luego se le permite a dicho usuario para solicitar una Promover a QA -testing. Obviamente, los usuarios en grupo GrpRelMgntson los usuarios autorizados para esto (nota: no, por ejemplo, los usuarios en grupo GrpDevso en grupo GrpEnduser).
• Si un usuario tiene acceso PrdEnduser, entonces dicho usuario puede autorizar el cambio en la estructura de la biblioteca (que generalmente es un requisito previo para que los usuarios del grupo GrpRelMgntpuedan incluso revisar un cambio). Obviamente, los usuarios del grupo GrpEnduserson los (únicos) usuarios autorizados para esto.
• Si un usuario tiene acceso PrdRelmgnt, entonces dicho usuario puede autorizar una Activación en producción (= el último / más alto nivel en la estructura de la biblioteca).

3. Espera lo inesperado y prepárate para ello.

Lo anterior es solo un plano, que con suerte ayuda a comprender cómo al final es el servidor el que se encarga de la segregación de funciones ... siempre que tenga la cobertura de CxO para imponer algunas reglas de acceso que no todos querrán.

Para completar la imagen como se explicó anteriormente, el servidor crea un seguimiento de auditoría (registro) de todo lo que sucede en el sistema. Para que en cualquier momento, siempre sea posible responder preguntas como

¿Qué sucedió cuándo y por qué, y qué usuario autorizado realmente lo aprobó ... por adelantado?

Pero, probablemente la parte más difícil es tener disponibles herramientas de informes adecuadas (y saber cómo usarlas). Al menos para satisfacer (fácilmente) las solicitudes de los auditores de TI (sus preguntas pueden ser muy difíciles). Pero también para señalar los registros de registro relevantes en su sistema SCM para responder a todo tipo de preguntas de "Lo que sucedió" en situaciones de crisis donde (parte de) la producción está baja.

Respuesta basada en mi conocimiento de la regulación francesa de "Controles internos", algo equivalente a las regulaciones de la SEC a las que usted señala, supongo que vincular aquí a un texto legal francés no sería realmente útil y no conozco una buena traducción del mismo.

En un modelo ideal de "lo construyes, lo ejecutas", todos en el equipo serán responsables del cambio. La evaluación de riesgos no se puede hacer cumplir mediante una separación de funciones y la única forma en que sé seguir cumpliendo con la regulación es mediante una auditoría periódica de transacciones de ciclo corto junto con un seguimiento de acciones inalterable para volver a la persona que realizó la liberación. .
Esto significa que todos los registros de transacciones y acciones se envían a un área restringida a la que el equipo no tiene acceso, un cambio en lo que se registra "debería" detectarse mediante pruebas funcionales a las que el equipo no tiene acceso y, en el peor de los casos, se detectará por la auditoría y rastreado a su autor.

Esto no es aplicable a todos los productos, al momento de escribir en Francia cualquier compañía autorizada a emitir dinero (principalmente bancos), debe asegurarse de que cada transacción se registre y, por lo tanto, no puede correr el riesgo de perder una transacción.
Por otro lado, no tienen la obligación legal de rastrear ninguna oferta comercial o evaluación de riesgos cuando alguien solicita un préstamo, y por lo tanto, los productos que manejan esta selección de clientes y calculan las tarifas que estarán en la oferta son más fáciles de encajar en una publicación modelo de auditoría de lanzamiento.

La idea principal es que el modelo de lanzamiento debe modificarse de acuerdo con las obligaciones de evaluación de riesgos.

Un recurso relacionado es la norma ISO27001 .

En mi humilde opinión, los desarrolladores y las operaciones podrían estar representados por nada más que dos repositorios git para la misma base de código , con distintos modelos de permisos cada uno, para que los equipos no interfieran en el trabajo de los demás.

Llamémoslos Dev.mygithub.co y ops.mygithub.co , solo como ejemplo.

La idea es que los Desarrolladores sean libres de crear / ramificar / fusionar el contenido de su corazón -git está proporcionando una trazabilidad completa y eso es lo que importa aquí- mientras tanto, en el momento en que el marco regulatorio implica un esfuerzo de revisión, se puede plantear una Solicitud de extracción, para la fusión suceda de manera controlada.

Llevando ese concepto a su próximo nivel, una rama de desarrollo puede propagarse hacia la producción remota de Ops a través de otro acto de solicitud de extracción. Esa última parte tiene que pasar por las manos y los ojos de las operaciones, ya que tienen la responsabilidad de examinarla en producción y eligen el nivel de revisión.

¡Este esquema permite una flexibilidad infinita, una trazabilidad completa, la capacidad de detectar problemas desde el principio a través de una variedad de procesos, la separación de preocupaciones y una experiencia de usuario muy razonable en el proceso !

Nota: ¡El modelo descrito anteriormente puede seguirse incluso si Ops y Dev se superponen totalmente!

más alto es más caro:

• Distintos sitios y métodos de desarrollo y operaciones para llevar el trabajo de uno a otro
• Distintos sistemas y métodos de desarrollo y operación como los anteriores
• distintos repositorios de desarrollo y operaciones git / vcs y métodos relacionados
• distintas ramas de desarrollo y operaciones git / vcs (protegidas) y métodos relacionados

Dependiendo de lo que haga, algunas soluciones son mejores que otras, por ejemplo, si tiene la necesidad de servir a dos equipos con roles distintos dentro de ellos y cada uno de los cuales tiene la propiedad y proporciona una trazabilidad completa, se encuentra sobre los primeros tres.

En resumen, cualquier cosa que imponga que un chico o una chica no puede tomar la pelota solo y correr con ella, y cruza un límite explícito distintivo entre los desarrolladores y las operaciones. Ahora, dependiendo del nivel de riesgo, ese límite puede hacerse cumplir o no.