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

18

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.

sre financial-services operating-model Richard Slater
la source
L'idée principale derrière une organisation devops étant de mettre tout le monde dans l'équipe responsable de ce qui se passe dans la production, il ne peut y avoir de séparation des tâches. Cela signifie principalement que ce type d'organisation ne peut pas être vraiment utilisé lorsqu'il existe des besoins réglementaires pour cette séparation.
Tensibai
@Tensbai Je suis fondamentalement en désaccord avec l'affirmation selon laquelle DevOps est incompatible avec la séparation des tâches. Les lois ne sont pas normatives quant à la manière des contrôles, pas plus que les régulateurs n'imposent un processus prédéfini aux banques et aux services financiers. C'est en grande partie à l'organisation d'identifier ce qui est approprié et d'être totalement transparent avec les régulateurs et leurs auditeurs désignés. À titre d'exemple, ING et Barclays ont adopté des pratiques DevOps pour leur permettre d'accélérer leur capacité à offrir de la valeur à leurs clients.
Richard Slater
Oui, dévops sur des sujets non liés à une séparation réglementaire, et ils ont profité de l'automatisation sur une organisation traditionnelle en silo pour des sujets restreints (qui sont en fait très peu nombreux). Ils ont juste deux types d'organisations en fonction du type d'opérations que le logiciel effectuera
Tensibai
Il n'y a rien de tel que la «séparation réglementaire», les lois / lois et les organismes de réglementation n'imposent pas de séparation aux institutions financières, ils imposent une responsabilité de gestion d'avoir des «contrôles appropriés» pour gérer le risque financier. De la même manière qu'Agile a fait passer le développement logiciel de cycles longs à de petits cycles, DevOps prend les opérations en petits cycles, DevOps in Financial Services doit trouver un moyen de prendre la séparation des tâches en petits cycles, en créant par exemple un pipeline de CD qui applique des «contrôles appropriés» tels que l'examen par les pairs et la promotion basée sur l'approbation.
Richard Slater
1
@ Pierre.Vriens oui la grande question est dans le titre, j'ai essayé de l'étendre en faisant quelques hypothèses. Les rôles sont susceptibles de faire partie de la solution, tout comme le bris de glace et la gestion des comptes privilégiés. Les rôles et responsabilités sont un concept intéressant dans DevOps / Agile, car il était une fois un développeur Java, un développeur F / E, un concepteur, un PM, un ingénieur de construction, un gestionnaire de versions et un ingénieur des opérations - vous avez maintenant un groupe de personnes qui peuvent porter des chapeaux multiples - des équipes interfonctionnelles composées d '"ingénieurs" qui peuvent se spécialiser mais en fin de compte partager les responsabilités.
Richard Slater

Réponses:

8

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.

Pierre.Vriens
la source
Cela ressemble à une implémentation de base de l'évaluation des risques descendante, je ne comprends pas comment cela répond à la question de savoir comment cela pourrait être implémenté de manière devops où les développeurs auraient le droit de déclencher le commutateur «déployer». L'idée est que vous ne pouvez pas le faire dans une organisation Devops?
Tensibai
@Tensibai "si" les développeurs auraient l'auth (rôle) d'approbation finale (par exemple) pour prod (qu'ils n'ont généralement PAS dans de telles organisations), alors ce serveur (tâche démarrée) commencerait le déploiement. Et selon le titre de la question, je pense que c'est "une" réponse possible. On pourrait cependant se demander si c'est ce que nous appellerions une organisation DevOps, mais je sais que les auditeurs aiment vraiment ce type de séparation des tâches "configurable" (par exemple: les quatre yeux et leurs variantes). Peut-être que Richard peut nous aider avec son point de vue à ce sujet?
Pierre.Vriens
1
Je suis d'accord que les auditeurs l'apprécient absolument, j'ai juste raté la façon dont cela est lié à «l'explosion» de l'accès, ce que l'auditeur n'aime généralement pas lorsque la liste contient plus de 6 à 7 personnes. Dire que cela ne correspond pas est une réponse absolument valable à mon humble avis.
Tensibai
1
Merci d'avoir consacré autant de temps à une réponse. Je pense en fait à implémenter une règle à 3 personnes, en ce sens qu'un développeur écrit le code, un développeur différent examine le code et une troisième personne appuie sur le bouton de libération pour déployer le code. L'autre considération est parce que cela fait partie d'une adoption Agile / DevOps à l'échelle de l'entreprise, les équipes de développement sont assez petites, avec l'effet net de petits groupes de personnes ayant accès à la production sur une fine tranche de production, cela semble être favorable du point de vue du risque. .
Richard Slater
1
@ Pierre.Vriens Impossible de voter deux fois, super extension :)
Tensibai
5

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 .

Tensibai
la source
Réponse intéressante et très pertinente car de nombreuses banques européennes opèrent en effet en France. Y a-t-il une chance que vous puissiez développer ce que signifie «Emettre de l'argent», c'est-à-dire simplement retirer de l'argent d'un GAB ou cela inclut-il des transferts de solde? Dans ce cas, un lien avec les statuts serait utile car il donne un pointeur sur les lois pertinentes, quelle que soit la langue dans laquelle elles se trouvent.
Richard Slater
@RichardSlater En bref, toute entreprise travaillant avec de l'argent pourrait être une société d'investissement uniquement ainsi que des courtiers en prêts le long des banques traditionnelles. Surtout tout ce qui a un impact financier quelque part est concerné (à quelques exceptions près que l'autorité peut donner dans les circonstances). La «liste» légale en français est là mais même en français elle n'est pas toujours évidente.
Tensibai
Je fais l'hypothèse que le lien avec la norme ISO devrait en fait être ISO27001: 2013
Richard Slater
@Richard semble en effet que le lien du français vers l'anglais n'a pas été mis à jour sur Wikipédia. Je mettrai à jour plus tard (ou si vous le souhaitez, n'hésitez pas à modifier)
Tensibai
connexes: Comment puis-je persuader les développeurs de mon équipe d'adopter «vous le construisez, vous l'exécutez»?
Dan Cornilescu
0

À 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!

fgeorgatos
la source
1
Assurément, ce même contrôle pourrait être obtenu grâce à des demandes d'extraction et à des accrochages post-validation qui garantissaient que les développeurs pouvaient s'engager librement, cependant, les validations de fusion ne pouvaient être effectuées que par un groupe de personnes approuvé. De même, ce même hook post-commit pourrait garantir que les auteurs des commits qui ont constitué la demande de pull n'incluent pas la personne qui a fait la demande de pull.
Richard Slater
@RichardSlater: la raison pour laquelle vous souhaiteriez peut-être avoir deux référentiels distincts est que vous avez à la fois besoin de permettre aux développeurs de fusionner - lorsqu'ils échangent librement du code en mode développeur - ainsi que d' empêcher la plupart des développeurs de fusionner du code lorsqu'il est pour aller vers la production (modulo SysOps, c'est-à-dire le soi-disant "groupe de personnes agréé").
fgeorgatos
Encore une fois, vous pouvez y parvenir avec des hooks post-commit et des requêtes pull, sans oublier que GitHub Enterprise autorise les branches protégées.
Richard Slater
0

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.

fgeorgatos
la source