Quels processus ou outils permettent la séparation des tâches lorsque les ingénieurs déploient et exécutent du code?

Dans des environnements hautement réglementés, tels que le secteur des services financiers, la séparation des tâches est un mécanisme essentiel pour éviter les collisions entre les individus ayant des responsabilités de développement et des privilèges de production.

Traditionnellement, cela signifie que les développeurs développent du code puis le remettent aux opérations, mais dans de nombreux modèles d'exploitation DevOps, la ségrégation entre développement et opérations est, au minimum, floue:

• Dans Google Site Reliability Engineering , ou SRE, la pratique est qu'il existe une fonction SRE distincte au sein de Google, cependant, les développeurs sont amenés à soutenir les SRE en cas de charge opérationnelle élevée.

• Dans le modèle "You Build It, You Run It" , il n'y a pas de fonction d'opérations distincte.

Après avoir passé des mois à explorer les causes profondes d'un mécanisme de séparation des tâches, il semble qu'il existe principalement pour satisfaire la section 404 de Sarbanes Oxley : Évaluation de la gestion des contrôles internes:

(a) Règles requises. La Commission doit prescrire des règles exigeant que chaque rapport annuel exigé par l'article 13 (a) ou 15 (d) de la Securities Exchange Act de 1934 contienne un rapport de contrôle interne, qui doit--

(1) indiquer la responsabilité de la direction d'établir et de maintenir une structure de contrôle interne et des procédures adéquates pour la communication de l'information financière; et

(2) contiennent une évaluation, à la fin du dernier exercice de l'émetteur, de l'efficacité de la structure de contrôle interne et des procédures de l'émetteur en matière d'information financière.

(b) Évaluation et rapports du contrôle interne. Lors de l'évaluation du contrôle interne exigée par le paragraphe (a), chaque cabinet d'expertise comptable agréé qui prépare ou émet le rapport d'audit pour l'émetteur atteste et rend compte de l'évaluation effectuée par la direction de l'émetteur. Une attestation faite en vertu du présent paragraphe doit être faite conformément aux normes pour les missions d'attestation émises ou adoptées par le Conseil. Une telle attestation ne fera pas l'objet d'un engagement distinct.

Sur la base des commentaires, il est important de rappeler quelques hypothèses que je fais:

• Je pense principalement aux services financiers grand public, c'est-à-dire que les volumes de transactions sont élevés mais de valeur relativement faible. Ce serait par opposition aux services financiers commerciaux qui ont un profil de valeur transactionnelle différent.
• L'offre en ligne d'une institution financière sera composée de nombreux éléments ayant des considérations de risque différentes:
  • Déplacer de l'argent - Déplacer de l'argent entre des comptes ou des transferts entre des comptes de différents propriétaires. Une opération qui doit prendre en compte la lutte contre le blanchiment d'argent, la protection contre la fraude et les pays sous embargo pour n'en nommer que quelques-uns.
  • Acquisition de clients - Moins "risqué" car il a de faibles volumes de transactions par rapport à Move Money mais doit encore être pris en considération.
  • Services bancaires par Internet - Couvre une large gamme de services avec différents niveaux de risque, Move Money serait considéré comme faisant partie de cela.
• En théorie, une approche différente pourrait être adoptée pour chacun en fonction du risque. Cependant, dans un souci de simplicité, je travaille à une solution qui s'appliquerait à certaines des opérations les plus risquées.

TL; DR : Il est de la responsabilité de la gestion de veiller à ce que des contrôles internes adéquats soient en place conformes à la de Securities and Exchange Commission des règlements .

Sarbanes Oxley 404 est normalement satisfait par l'achèvement d'une évaluation des risques descendante, dont une partie évaluera le risque de collusion et proposera des stratégies d'atténuation.

Au sein d'une entreprise qui utilise la pratique et la culture DevOps, où les développeurs ont régulièrement accès au contrôle des sources et à la production, comment la séparation des tâches peut-elle être réalisée, ou plus généralement comment atténuer le risque de collusion.

Votre question ne semble faire aucune hypothèse sur la plate-forme / le système d'exploitation dont il s'agit. C'est pourquoi il peut être judicieux d'ajouter une réponse sur la façon dont cela est généralement fait / traité dans un environnement mainframe, où les «ingénieurs» (comme dans le titre de votre question) sont en fait des groupes de personnes étaient des dizaines (peut-être des centaines) de personnes impliqué. Ma réponse est basée sur l'utilisation du produit SCM où je suis le plus familier (je ne sais pas s'il est nécessaire de divulguer le nom du produit).

---

1. Architecture

---

Voici les points saillants de la façon dont je répondrais à votre question:

• Tout le code (et les artefacts connexes comme les exécutables, etc.) est stocké dans des fichiers qui, ensemble, sont ce que nous appelons la structure de la bibliothèque .
• Pour chaque environnement sur chaque système cible (éventuellement distant), il y a un serveur (une "tâche démarrée" dans le mainframe), qui s'occupe de TOUTES (répétez: TOUTES) mises à jour de tout dans la structure de la bibliothèque. Il y a quelques exceptions (comme les responsables de la sécurité ou l'équipe de gestion de l'espace), mais à part cela, personne (répétez: personne) n'a l'autorisation d'appliquer des mises à jour à n'importe quel fichier de cette structure de bibliothèque. En d'autres termes: le serveur obtient une autorisation de mise à jour exclusive sur toute la structure de la bibliothèque . Attention: les gens d'OPS iront bonkers si vous entrez pour limiter leur accès (au début, ils vont résister ...), alors assurez-vous d'être couvert par la haute direction (CxO) pour imposer ces règles d'accès ...
• Le logiciel réel change mon composé d'un seul composant (un minuscule correctif de code au milieu de la nuit ...), ou il peut également s'agir de centaines ou de milliers de sources, d'exécutables ou de tout autre artefact (pendant un week-end de sortie). Pour les rendre gérables, les choses qui devraient être déplacées (plus ou moins) ensemble, en même temps, sont regroupées dans ce qu'on appelle un package de modifications logicielles .

Avec ce qui précède en place, tout type de mise à jour à appliquer par le serveur à la structure de la bibliothèque ne sera possible que via un flux de travail bien défini, que nous appelons le cycle de vie d'un package de modifications logicielles (SDLC si vous préférez). Pour réellement exécuter les différentes étapes de ce flux de travail, voici ce qu'il faut pour y arriver:

• Seul le serveur exécutera les étapes requises (et préconfigurées).
• Le serveur ne fera qu'une étape spécifique (= mettre à jour quelque chose quelque part dans la structure de la bibliothèque), après que les approbations requises (des êtres humains) aient été rassemblées pour effectuer une telle étape.
• Les approbations ne peuvent être accordées que par des utilisateurs qui ont un rôle qui leur permet (= autorisation) d'émettre de telles approbations.

---

2. Rôles et autorisations

---

Le serveur s'assurera que l'utilisateur essayant de faire quelque chose (comme «approuver quelque chose») ne pourra le faire que si les autorisations de l'utilisateur sont appropriées. Cette partie est facile. Mais vous ne voulez pas utiliser le système SCM pour administrer toutes ces autorisations pour tous les utilisateurs impliqués, c'est ce qui appartient à votre système de sécurité (pas le système SCM!), Afin que vous puissiez adapter votre flux de travail (dans votre système SCM) pour aller vérifier ces autorisations chaque fois que cela est approprié. Les étapes ci-dessous fournissent plus de détails à ce sujet.

Étape 1: configurer les autorisations (dans le système de sécurité)

• Définissez des entités de sécurité dans votre système de sécurité, avec des noms bien définis pour ces entités. Quelques échantillons (ajoutez autant d'échantillons similaires pour répondre à vos propres besoins):

  • PrmUnit, utilisé pour obtenir la permission de demander une promotion pour dire test d' unité .
  • PrmQA, Utilisé pour obtenir l' autorisation de demander un Promouvoir dire Qa -Test (supposons que c'est le niveau de test le plus élevé).
  • PrdEnduser, utilisé par les utilisateurs finaux impliqués dans un certain niveau de test, pour indiquer qu'ils sont satisfaits des résultats produits par une sorte de test. Et à cause de cela, ces utilisateurs finaux sont d'accord avec le changement progressif dans la structure de la bibliothèque.
  • PrdRelmgnt, utilisé par les gestionnaires de versions pour autoriser une activation en production (= le dernier / plus haut niveau dans la structure de la bibliothèque).

• Définissez des groupes d'utilisateurs dans votre système de sécurité. Quelques échantillons (ajoutez autant d'échantillons similaires pour répondre à vos propres besoins):

  • GrpDevs, ce qui (par exemple) correspond à vos développeurs (probablement plus que juste 1).
  • GrpEnduser, ce qui (par exemple) correspond à vos utilisateurs finaux (au moins 1, de préférence avec des utilisateurs plus similaires).
  • GrpRelMgnt, ce qui (par exemple) correspond à vos gestionnaires de versions (au moins 1, de préférence quelques utilisateurs supplémentaires).

• Accordez des autorisations , également à l'aide de votre système de sécurité, pour autoriser l'accès à des " entités de sécurité " sélectionnées pour des " groupes d'utilisateurs " sélectionnés. Pour continuer l'exemple ci-dessus, voici ce qui semble approprié (adaptez-vous à vos propres besoins):

  • Le groupe GrpDevsa accès à (uniquement!) L'entité de sécurité PrmUnit.
  • Le groupe GrpEndusera accès à (uniquement!) L'entité de sécurité PrdEnduser.
  • Le groupe GrpRelMgnta accès à (les deux!) Entité de sécurité PrmQAet PrdRelmgnt.

Étape 2: configurer le flux de travail (dans le système SCM)

Une fois les autorisations configurées dans votre système de sécurité (comme à l'étape 1), tout ce qui reste à faire dans votre système SCM est de configurer la façon dont les différentes étapes du style de vie correspondent aux entités de sécurité associées dans votre système de sécurité. Autrement dit, seuls les utilisateurs qui ont l'accès approprié à l'entité de sécurité requise sont autorisés à demander au serveur d'effectuer l'étape correspondante dans le flux de travail.

Voici quelques exemples de la façon dont vous configureriez votre système SCM pour que la magie se produise:

• Si un utilisateur y a accès PrmUnit, cet utilisateur est autorisé à demander un test de promotion en unité . Évidemment, les utilisateurs du groupe GrpDevssont les utilisateurs autorisés pour cela (remarque: pas, par exemple, les utilisateurs du groupe GrpRelMgnt).
• Si un utilisateur y a accès PrmQA, cet utilisateur est autorisé à demander un test de promotion au contrôle qualité. Évidemment, les utilisateurs du groupe GrpRelMgntsont les utilisateurs autorisés pour cela (remarque: pas, par exemple, les utilisateurs du groupe GrpDevsou du groupe GrpEnduser).
• Si un utilisateur y a accès PrdEnduser, cet utilisateur est autorisé à autoriser la modification à aller de l'avant dans la structure de la bibliothèque (ce qui est généralement une condition préalable pour que les utilisateurs du groupe GrpRelMgntpuissent même réviser une modification). De toute évidence, les utilisateurs du groupe GrpEndusersont les (seuls) utilisateurs autorisés pour cela.
• Si un utilisateur y a accès PrdRelmgnt, cet utilisateur est autorisé à autoriser une activation en production (= le dernier / plus haut niveau dans la structure de la bibliothèque).

---

3. Attendez-vous à l'inattendu et soyez prêt

---

Ce qui précède n'est qu'un schéma directeur, qui, espérons-le, aidera à comprendre comment, en fin de compte, c'est le serveur qui s'occupe de la séparation des tâches ... à condition que vous ayez la couverture CxO pour vous imposer des règles d'accès qui ne plairont pas à tout le monde.

Pour compléter l'image comme expliqué ci-dessus, le serveur crée une piste d'audit (journalisation) de tout ce qui se passe dans le système. Pour qu'à tout moment, il soit toujours possible de répondre à des questions comme

Que s'est-il passé quand et pourquoi, et quel utilisateur autorisé l'a effectivement approuvé ... dès le départ?

Mais le plus difficile est probablement de disposer d'outils de reporting adéquats (et de savoir comment les utiliser). Au moins pour (facilement) satisfaire les demandes des auditeurs informatiques (leurs questions peuvent être très difficiles). Mais aussi pour pointer vers les enregistrements de journaux pertinents dans votre système SCM pour répondre à toutes sortes de questions «Que s'est-il passé» dans les situations de crise où (une partie de) la production est en baisse.

---

PS: Je laisse le jugement de chacun si ma réponse est oui ou non conforme à DevOps.

Réponse basée sur ma connaissance de la réglementation française "Contrôles internes", sorte d'équivalent à la réglementation SEC dont vous parlez, je suppose que le lien ici vers un texte juridique français ne serait pas vraiment utile et je ne connais aucune bonne traduction de celui-ci.

Dans un modèle idéal «vous le construisez, vous l'exécutez», tout le monde dans l'équipe sera responsable du changement. L'évaluation des risques ne peut pas être imposée par une séparation des tâches et la seule façon que je sache de me conformer à la réglementation est d'avoir un audit périodique court des transactions avec un suivi des actions inaltérable pour revenir à la personne qui a fait la libération .
Cela signifie que tous les journaux des transactions et des actions sont poussés vers une zone restreinte à laquelle l'équipe n'a pas accès, un changement dans ce qui est consigné "devrait" être détecté par des tests fonctionnels auxquels l'équipe n'a pas accès et au pire le sera. par l'audit et suivi à son auteur.

Cela ne s'applique pas à tous les produits, au moment de la rédaction en France, toute entreprise autorisée à émettre de l'argent (principalement des banques), doit s'assurer que chaque transaction sera enregistrée et ne peut donc pas prendre le risque de manquer une transaction.
En revanche, ils n'ont aucune obligation légale de suivre toute offre commerciale ou évaluation des risques lorsque quelqu'un demande un prêt, et donc les produits gérant cette sélection de clients et calculant les frais qui seront dans l'offre sont plus faciles à intégrer dans un poste -démarrer le modèle d'audit.

L'idée principale est que le modèle de publication doit être modifié en fonction des obligations d'évaluation des risques.

Une ressource connexe est la norme ISO27001 .

À mon humble avis, les développeurs et les opérations pourraient être représentés par rien de plus que deux référentiels git pour la même base de code , avec chacun un modèle d'autorisations distinct, afin que les équipes n'interfèrent pas du tout dans le travail les unes des autres.

Appelons-les Dev.mygithub.co & ops.mygithub.co , juste à titre d'exemple.

L'idée est que les développeurs sont libres de créer / créer des succursales / fusionner au contenu de leur cœur - git fournit une traçabilité complète et c'est ce qui importe ici - pendant ce temps, au moment où le cadre réglementaire implique un effort de révision, une demande de pull peut être soulevée, pour la fusion doit se faire de manière contrôlée.

Amenant ce concept à un niveau supérieur, une branche de développement peut être propagée vers la production des opérations distantes via un autre acte Pull Request . Cette dernière partie doit se produire par les mains et les yeux des opérations, car ils ont la responsabilité de la mettre en production et de choisir le niveau d'examen.

Un tel schéma permet une flexibilité infinie, une traçabilité complète, la capacité de détecter les problèmes dès le début via une variété de processus, la séparation des préoccupations et une expérience utilisateur très raisonnable dans le processus !

NB Le modèle décrit ci-dessus peut être suivi même si Ops & Dev se chevauchent totalement!

plus est plus cher:

• sites et méthodes distincts de développement et d'opérations pour transférer le travail de l'un à l'autre
• systèmes et méthodes de développement et d'exploitation distincts comme ci-dessus
• référentiels git / vcs distincts pour dev et ops et méthodes connexes
• branches distinctes dev et ops git / vcs (protégées) et méthodes connexes

Selon ce que vous faites, certaines solutions sont meilleures que d'autres.Par exemple, si vous avez besoin de servir deux équipes avec des rôles distincts en leur sein et chacune ayant la propriété et offrant une traçabilité complète, vous survolez les trois premières.

En bref, tout ce qui oblige un gars ou une fille ne peut pas prendre le ballon tout seul et courir avec, et il franchit une frontière explicite distincte entre les développeurs et les opérateurs. Maintenant, selon le niveau de risque, cette limite peut être appliquée ou non.