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

18

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?

Richard Slater
fuente
La idea principal detrás de una organización devops es hacer que todos en el Equipo sean responsables de lo que sucede en la producción, no puede haber separación de tareas. Esto significa principalmente que este tipo de organización no puede usarse realmente cuando hay necesidades regulatorias para esta separación.
Tensibai
@Tensbai Estoy fundamentalmente en desacuerdo con la afirmación de que DevOps es incompatible con la segregación de deberes. Las leyes no son prescriptivas en cuanto a la forma de los controles, ni los reguladores imponen un proceso predefinido a los bancos y servicios financieros. Depende en gran medida de la organización identificar qué es apropiado y ser totalmente transparente con los reguladores y sus auditores designados. Como ejemplo, tanto ING como Barclays han adoptado prácticas de DevOps para permitirles acelerar su capacidad de entregar valor a sus clientes.
Richard Slater
Sí, devops sobre temas que no están sujetos a la separación regulatoria, y aprovecharon la automatización en una organización tradicional basada en silo para temas restringidos (que de hecho son muy pocos). Solo tienen dos tipos de organizaciones según el tipo de operaciones que realizará el software
Tensibai
No existe tal cosa como "Separación reglamentaria", los estatutos / leyes y los organismos reguladores no imponen la separación a las instituciones financieras, imponen la responsabilidad de la administración de tener "Controles apropiados" para administrar el riesgo financiero. De la misma manera que Agile llevó el desarrollo de software de ciclos largos a ciclos pequeños, DevOps está llevando las operaciones a ciclos pequeños, DevOps en Servicios Financieros necesita encontrar una manera de llevar la Segregación de Deberes a ciclos pequeños, por ejemplo, creando una tubería de CD que aplica "controles apropiados", como la revisión por pares y la promoción basada en la aprobación.
Richard Slater
1
@ Pierre.Vriens sí, la pregunta general está en el título, he tratado de ampliarla haciendo algunas suposiciones. Es probable que los roles sean parte de la solución, al igual que cosas como Break-Glass y Privileged Account Management. Los roles y las responsabilidades son un concepto interesante en DevOps / Agile, ya que alguna vez tuvo un Desarrollador Java, Desarrollador F / E, Diseñador, PM, Ingeniero de construcción, Administrador de versiones e Ingeniero de operaciones: ahora tiene un grupo de personas que pueden use múltiples sombreros: equipos multifuncionales formados por "ingenieros" que pueden especializarse pero en última instancia compartir la responsabilidad.
Richard Slater

Respuestas:

8

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


El servidor se asegurará de que el usuario que intenta hacer que algo suceda (como 'aprobar algo') solo podrá hacerlo, si los permisos del usuario son apropiados. Esa parte es fácil. Pero no desea utilizar el sistema SCM para administrar todos esos permisos para todos los usuarios involucrados, eso es lo que pertenece a su sistema de seguridad (¡no al sistema SCM!), Para que pueda adaptar su flujo de trabajo (en su sistema SCM) para verificar esos permisos siempre que sea apropiado. Los pasos a continuación proporcionan más detalles al respecto.

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.


PD: lo dejo a criterio de todos si mi respuesta es sí o no compatible con DevOps.

Pierre.Vriens
fuente
Eso suena como una implementación básica de la evaluación de riesgos de arriba hacia abajo, no entiendo cómo aborda la pregunta sobre cómo esto podría implementarse de manera devops donde los desarrolladores tendrían los derechos para activar el interruptor de 'despliegue'. ¿Es la idea de que no puedes hacerlo en una organización devops?
Tensibai
@Tensibai "si" los desarrolladores tendrían la autenticación (función) de (por ejemplo) la aprobación final de prod (que normalmente NO tienen en tales organizaciones), entonces dicho servidor (tarea iniciada) comenzaría la implementación. Y según el título de la pregunta, creo que esta es "una" posible respuesta. Sin embargo, uno podría preguntarse si esto es lo que llamaríamos una organización DevOps, pero sí sé que a los auditores realmente les gusta este tipo de separación de funciones "configurable" (por ejemplo: cuatro ojos y variaciones de eso). ¿Quizás Richard puede ayudarnos con su punto de vista sobre esto?
Pierre.Vriens
1
Estoy totalmente de acuerdo con que a los auditores les gusta absolutamente, simplemente extrañé cómo esto se relaciona / encaja con la "explosión" de acceso, que al auditor generalmente no le gusta cuando la lista contiene más de 6 a 7 personas. Decir que no encaja es una respuesta absolutamente válida en mi humilde opinión.
Tensibai
1
Gracias por dedicar tanto tiempo a responder. Realmente estoy pensando en implementar una regla de 3 personas, en la que un desarrollador escribe el código, un desarrollador diferente revisa el código y una tercera persona presiona el botón de liberación para implementar el código. La otra consideración es porque esto es parte de una adopción de Agile / DevOps en toda la compañía, los equipos de desarrollo son bastante pequeños, con el efecto neto de que pequeños grupos de personas tienen acceso de producción a una pequeña porción de producción, esto parece ser favorable desde una perspectiva de riesgo .
Richard Slater
1
@ Pierre.Vriens No puedo votar dos veces, gran extensión :)
Tensibai
5

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 .

Tensibai
fuente
Respuesta interesante y muy relevante ya que muchos bancos europeos operan en Francia. ¿Hay alguna posibilidad de que pueda ampliar lo que significa "Emitir dinero"? En este caso, el enlace a los estatutos sería valioso, ya que proporciona un puntero a las leyes relevantes, independientemente del idioma en el que se encuentren.
Richard Slater
@RichardSlater En resumen, cualquier compañía que trabaje con dinero podría ser una compañía de inversión solamente, así como también corredores de préstamos en los bancos tradicionales. Principalmente, cualquier cosa que tenga un impacto financiero en alguna parte se refiere (de las pocas excepciones que la autoridad puede dar bajo las circunstancias). La "lista" legal en francés está aquí, pero incluso en francés no siempre es obvia.
Tensibai
Estoy asumiendo que el enlace al estándar ISO debería ser ISO27001: 2013
Richard Slater
@Richard de hecho, parece que el enlace de francés a inglés no se ha actualizado en Wikipedia. Actualizaré más tarde (o si lo desea, siéntase libre de editar)
Tensibai
0

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!

fgeorgatos
fuente
1
Seguramente, este mismo control podría lograrse a través de solicitudes de extracción y ganchos posteriores a la confirmación que aseguraron que los desarrolladores pudieran comprometerse libremente, sin embargo, las confirmaciones de fusión solo pueden ser realizadas por un grupo aprobado de personas. Igualmente, ese mismo enlace posterior a la confirmación podría garantizar que los autores de las confirmaciones que conformaron la solicitud de extracción no incluyeran a la persona que realiza la solicitud de extracción.
Richard Slater
@ RichardSlater: la razón por la que es posible que desee tener dos repositorios distintos es que tiene la doble necesidad de permitir que los desarrolladores se fusionen, cuando intercambian libremente el código en modo desarrollador, así como de bloquear a la mayoría de los desarrolladores de fusionar el código cuando es para ir hacia la producción (módulo SysOps, es decir, el llamado "grupo de personas aprobado").
fgeorgatos
Nuevamente, puede lograr eso con ganchos posteriores a la confirmación y solicitudes de extracción, sin mencionar que GitHub Enterprise permite ramas protegidas.
Richard Slater
0

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.

fgeorgatos
fuente