DevOps vs DevSecOps : à quoi cela ressemblait dans une banque

La banque sous-traite ses projets à de nombreux entrepreneurs. Les « externes » écrivent du code, puis transmettent les résultats sous une forme peu pratique. Concrètement, le processus ressemblait à ceci : ils ont remis un projet qui a passé avec eux des tests fonctionnels, puis a été testé à l'intérieur du périmètre bancaire pour l'intégration, la charge, etc. On découvrait souvent que les tests échouaient. Ensuite, tout est retourné au développeur externe. Comme vous pouvez le deviner, cela signifiait de longs délais pour la correction des bugs.

La banque a décidé qu'il était possible et nécessaire de traîner l'ensemble du pipeline sous son aile, depuis les engagements jusqu'à la libération. Pour que tout soit uniforme et sous le contrôle des équipes responsables du produit dans la banque. C'est comme si l'entrepreneur externe travaillait simplement quelque part dans la pièce voisine du bureau. Sur la pile d'entreprise. Il s'agit d'un développeur ordinaire.

D’où vient Sec ? La sécurité de la banque impose des exigences élevées quant à la manière dont un sous-traitant externe peut travailler dans le segment réseau, quel accès dispose d'une personne, comment et qui utilise le code. C’est juste qu’IB ne savait pas encore que lorsque les entrepreneurs travaillent à l’extérieur, peu de normes bancaires sont respectées. Et puis, dans quelques jours, tout le monde devra commencer à les observer.

La simple révélation que l’entrepreneur avait un accès complet au code du produit avait déjà bouleversé leur monde.

C’est à ce moment-là qu’a commencé l’histoire de DevSecOps, dont je veux vous parler.

Quelles conclusions pratiques la banque a-t-elle tiré de cette situation ?

Il y a eu beaucoup de controverses sur le fait que tout était mal fait. Les développeurs ont déclaré que la sécurité ne faisait qu'essayer d'interférer avec le développement et qu'ils, comme des gardiens, essayaient d'interdire sans réfléchir. De leur côté, les spécialistes de la sécurité hésitaient entre choisir entre les points de vue : « les développeurs créent des vulnérabilités dans notre circuit » et « les développeurs ne créent pas de vulnérabilités, mais le sont eux-mêmes ». Le conflit aurait duré longtemps sans les nouvelles exigences du marché et l’émergence du paradigme DevSecOps. Il a été possible d'expliquer que cette automatisation même des processus prenant en compte les exigences de sécurité de l'information « prête à l'emploi » aidera tout le monde à rester heureux. Dans le sens où les règles sont écrites immédiatement et ne changent pas pendant le jeu (la sécurité de l'information n'interdit pas quelque chose de manière inattendue), et les développeurs tiennent la sécurité de l'information informée de tout ce qui se passe (la sécurité de l'information ne rencontre pas quelque chose soudainement) . Chaque équipe est également responsable de la sécurité ultime, et non de quelques frères aînés abstraits.

1. Étant donné que les employés externes ont déjà accès au code et à un certain nombre de systèmes internes, il est probablement possible de supprimer des documents l'exigence « le développement doit être effectué entièrement sur l'infrastructure de la banque ».
2. D’un autre côté, nous devons renforcer le contrôle sur ce qui se passe.
3. Le compromis a été la création d'équipes interfonctionnelles, où les employés travaillent en étroite collaboration avec des personnes externes. Dans ce cas, vous devez vous assurer que l’équipe travaille sur des outils présents sur les serveurs de la banque. Du début jusqu'à la fin.

Autrement dit, les entrepreneurs peuvent être autorisés à entrer, mais ils doivent se voir attribuer des segments séparés. Afin qu’ils n’introduisent pas une sorte d’infection de l’extérieur dans l’infrastructure de la banque et qu’ils ne voient pas plus que ce qui est nécessaire. Eh bien, pour que leurs actions soient enregistrées. DLP pour la protection contre les fuites, tout cela était inclus.

En principe, toutes les banques y arrivent tôt ou tard. Ici, nous sommes sortis des sentiers battus et nous sommes mis d'accord sur les exigences relatives aux environnements dans lesquels travaillent des « externes ». Il est apparu une gamme maximale d'outils de contrôle d'accès, d'outils de vérification des vulnérabilités, d'analyse antivirus sur les circuits, les assemblages et les tests. C'est ce qu'on appelle DevSecOps.

Soudain, il est devenu clair que si avant DevSecOps, la sécurité bancaire n'avait aucun contrôle sur ce qui se passe du côté du développeur, alors dans le nouveau paradigme, la sécurité est contrôlée de la même manière que les événements ordinaires sur l'infrastructure. Ce n'est que maintenant qu'il existe des alertes sur les assemblys, le contrôle des bibliothèques, etc.

Il ne reste plus qu'à transférer les équipes vers le nouveau modèle. Eh bien, créez l’infrastructure. Mais ce sont des bagatelles, c'est comme dessiner un hibou. En fait, nous avons contribué à l'infrastructure et, à cette époque, les processus de développement étaient en train de changer.

Qu'est ce qui a changé

Nous avons décidé de le mettre en œuvre par petites étapes, car nous comprenions que de nombreux processus s'effondreraient et que de nombreux « externes » pourraient ne pas être en mesure de supporter les nouvelles conditions de travail sous la supervision de tous.

Dans un premier temps, nous avons créé des équipes interfonctionnelles et appris à organiser des projets en tenant compte des nouvelles exigences. Dans le sens organisationnel, nous avons discuté de quels processus. Le résultat a été un schéma du pipeline d'assemblage avec tous les responsables.

• CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• Tester: Sonarqube, SoapUI, jMeter, Sélénium : MF Fortify, Performance Center, MF UFT, Ataccama.
• Présentation (reporting, communication) : Grafana, Kibana, Jira, Confluence, RocketChat.
• Opérations (maintenance, gestion) : Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Pile sélectionnée :

• Base de connaissances - Atlassian Confluence ;
• Suivi des tâches - Atlassian Jira ;
• Dépôt d'artefacts - « Nexus » ;
• Système d'intégration continue - « Gitlab CI » ;
• Système d'analyse continue - « SonarQube » ;
• Système d'analyse de la sécurité des applications - « Micro Focus Fortify » ;
• Système de communication - « GitLab Mattermost » ;
• Système de gestion de configuration - « Ansible » ;
• Système de surveillance - «ELK», «TICK Stack» («InfluxData»).

Ils ont commencé à créer une équipe prête à recruter des entrepreneurs. On se rend compte qu’il y a plusieurs choses importantes :

• Tout doit être unifié, au moins lors de la transmission du code. Parce qu’il y avait autant d’entrepreneurs que de processus de développement différents avec leurs propres particularités. Il était nécessaire de regrouper tout le monde dans un seul groupe, mais avec des options.
• Il existe de nombreux sous-traitants et la création manuelle d’infrastructures n’est pas adaptée. Toute nouvelle tâche doit démarrer très rapidement, c'est-à-dire que l'instance doit être déployée presque instantanément afin que les développeurs disposent d'un ensemble de solutions pour gérer leur pipeline.

Pour faire le premier pas, il fallait comprendre ce qui se faisait. Et nous avons dû déterminer comment y arriver. Nous avons commencé par aider à dessiner l'architecture de la solution cible tant en infrastructure qu'en automatisation CI/CD. Ensuite, nous avons commencé à assembler ce convoyeur. Il nous fallait une infrastructure unique, la même pour tout le monde, où fonctionneraient les mêmes convoyeurs. Nous avons proposé des options avec calculs, a pensé la banque, puis nous avons décidé de ce qui serait construit et avec quels fonds.

Vient ensuite la création du circuit - installation du logiciel, configuration. Développement de scripts pour le déploiement et la gestion des infrastructures. Vient ensuite la transition vers le support du convoyeur.

Nous avons décidé de tout tester sur le pilote. Fait intéressant, lors du pilotage, une certaine pile est apparue pour la première fois dans la banque. Entre autres choses, un fournisseur national de l'une des solutions a été proposé pour un lancement rapide dans le cadre du projet pilote. La sécurité l'a connu pendant qu'il pilotait, et cela a laissé une impression inoubliable. Lorsque nous avons décidé de changer, heureusement, la couche infrastructure a été remplacée par une solution Nutanix, qui était déjà en banque auparavant. D’ailleurs, avant c’était pour le VDI, mais nous l’avons réutilisé pour les services d’infrastructure. À petits volumes, il ne s'intégrait pas à l'économie, mais à gros volumes, il devenait un excellent environnement pour le développement et les tests.

Le reste de la pile est plus ou moins familier à tout le monde. Des outils d'automatisation dans Ansible ont été utilisés et des spécialistes de la sécurité ont travaillé en étroite collaboration avec eux. La pile Atlassin était utilisée par la banque avant le projet. Outils de sécurité Fortinet - ils ont été proposés par les responsables de la sécurité eux-mêmes. Le cadre de test a été créé par la banque, sans poser de questions. Le système de référentiel posait des questions, j'ai dû m'y habituer.

Les entrepreneurs ont reçu une nouvelle pile. Ils nous ont donné le temps de le réécrire pour GitlabCI, et de migrer Jira vers le segment bancaire, etc.

Pas à pas

Étape 1. Tout d’abord, nous avons utilisé une solution d’un fournisseur national, le produit était connecté à un nouveau segment de réseau DSO créé. La plateforme a été choisie pour son délai de livraison, sa flexibilité d'évolutivité et sa possibilité d'automatisation complète. Tests effectués :

• Possibilité de gestion flexible et entièrement automatisée de l'infrastructure de la plateforme de virtualisation (réseau, sous-système disques, sous-système ressources informatiques).
• Automatisation de la gestion du cycle de vie des machines virtuelles (modèles, instantanés, sauvegardes).

Après l'installation et la configuration de base de la plate-forme, elle a été utilisée comme point de placement des sous-systèmes de la deuxième étape (outils DSO, schémas de développement des systèmes de vente au détail). Les ensembles de pipelines nécessaires ont été créés - création, suppression, modification, sauvegarde de machines virtuelles. Ces pipelines ont été utilisés comme première étape du processus de déploiement.

Le résultat est que l’équipement fourni ne répond pas aux exigences de performance et de tolérance aux pannes de la banque. La DIT de la banque a décidé de créer un complexe basé sur le progiciel Nutanix.

Étape 2. Nous avons pris la pile définie et écrit des scripts d'installation et de post-configuration automatisés pour tous les sous-systèmes afin que tout soit transféré du circuit pilote au circuit cible le plus rapidement possible. Tous les systèmes ont été déployés dans une configuration tolérante aux pannes (où cette capacité n'est pas limitée par les politiques de licence du fournisseur) et connectés à des sous-systèmes de collecte de métriques et d'événements. IB a analysé le respect de ses exigences et a donné son feu vert.

Étape 3. Migration de tous les sous-systèmes et de leurs paramètres vers le nouveau PAC. Les scripts d'automatisation de l'infrastructure ont été réécrits et la migration des sous-systèmes DSO a été réalisée de manière entièrement automatisée. Les contours du développement IP ont été recréés par les pipelines des équipes de développement.

Étape 4. Automatisation de l'installation des logiciels d'application. Ces tâches ont été définies par les chefs d'équipe des nouvelles équipes.

Étape 5. Exploitation.

Accès à distance

Les équipes de développement ont demandé une flexibilité maximale dans le travail avec le circuit, et l'exigence d'un accès à distance depuis des ordinateurs portables personnels a été soulevée dès le début du projet. La banque disposait déjà d'un accès à distance, mais cela ne convenait pas aux développeurs. Le fait est que le système utilisait la connexion de l’utilisateur à un VDI protégé. Cela convenait à ceux qui n'avaient besoin que de courrier et d'un package bureautique sur leur lieu de travail. Les développeurs auraient besoin de clients lourds, performants, avec beaucoup de ressources. Et bien sûr, ils devaient être statiques, car la perte de session utilisateur pour ceux qui travaillent avec VStudio (par exemple) ou autre SDK est inacceptable. L'organisation d'un grand nombre de VDI statiques épais pour toutes les équipes de développement a considérablement augmenté le coût de la solution VDI existante.

Nous avons décidé de travailler sur l'accès à distance directement aux ressources du segment de développement. Jira, Wiki, Gitlab, Nexus, bancs de build et de test, infrastructure virtuelle. Les agents de sécurité ont exigé que l'accès ne puisse être accordé que sous réserve des conditions suivantes :

1. Utiliser les technologies déjà disponibles dans la banque.
2. L'infrastructure ne doit pas utiliser de contrôleurs de domaine existants qui stockent les enregistrements d'objets de compte productifs.
3. L'accès doit être limité aux seules ressources requises par une équipe spécifique (afin qu'une équipe produit ne puisse pas accéder aux ressources d'une autre équipe).
4. Contrôle maximal sur RBAC dans les systèmes.

En conséquence, un domaine distinct a été créé pour ce segment. Ce domaine abritait toutes les ressources du segment de développement, à la fois les informations d'identification des utilisateurs et l'infrastructure. Le cycle de vie des enregistrements de ce domaine est géré à l'aide de l'IdM existant dans la banque.

L’accès direct à distance a été organisé sur la base des équipements existants de la banque. Le contrôle d'accès était divisé en groupes AD, auxquels correspondaient des règles sur les contextes (un groupe de produits = un groupe de règles).

Gestion des modèles de VM

La rapidité de création d'une boucle d'assemblage et de test est l'un des principaux KPI fixés par le responsable de l'unité de développement, car la rapidité de préparation de l'environnement affecte directement le temps global d'exécution du pipeline. Deux options pour préparer les images de base de la VM ont été envisagées. Le premier concerne la taille minimale des images, par défaut pour tous les produits du système, le respect maximal des politiques de la banque en matière de paramètres. La seconde est l'image de base, qui contient un POPPO robuste installé, dont le temps d'installation pourrait grandement influencer la vitesse d'exécution du pipeline.

Les exigences en matière d'infrastructure et de sécurité ont également été prises en compte lors du développement - maintien des images à jour (patchs, etc.), intégration avec SIEM, paramètres de sécurité selon les normes bancaires.

En conséquence, il a été décidé d’utiliser un minimum d’images afin de minimiser le coût de leur mise à jour. Il est beaucoup plus facile de mettre à jour le système d'exploitation de base que de patcher chaque image pour les nouvelles versions de POPPO.

Sur la base des résultats, une liste a été constituée de l'ensemble minimum requis de systèmes d'exploitation, dont la mise à jour est effectuée par l'équipe des opérations, et les scripts du pipeline sont entièrement responsables de la mise à jour du logiciel et, si nécessaire, de la modification de la version. du logiciel installé - transférez simplement la balise requise vers le pipeline. Oui, cela nécessite que l'équipe produit DevOps dispose de scénarios de déploiement plus complexes, mais cela réduit considérablement le temps opérationnel requis pour prendre en charge les images de base, dont la maintenance pourrait autrement nécessiter plus d'une centaine d'images de VM de base.

Accès Internet

Une autre pierre d'achoppement en matière de sécurité bancaire était l'accès aux ressources Internet depuis l'environnement de développement. De plus, cet accès peut être divisé en deux catégories :

1. Accès aux infrastructures.
2. Accès développeur.

L'accès à l'infrastructure a été organisé en proxyant des référentiels externes avec Nexus. Autrement dit, l'accès direct depuis les machines virtuelles n'était pas fourni. Cela a permis de parvenir à un compromis avec la sécurité de l'information, qui s'opposait catégoriquement à tout accès au monde extérieur depuis le segment du développement.

Les développeurs avaient besoin d'accéder à Internet pour des raisons évidentes (stackoverflow). Et bien que toutes les commandes, comme mentionné ci-dessus, aient accès au circuit à distance, ce n'est pas toujours pratique lorsque vous ne pouvez pas faire ctrl+v depuis le lieu de travail du développeur dans la banque de l'EDI.

Un accord a été conclu avec IS selon lequel, dans un premier temps, au stade des tests, l'accès sera fourni via un proxy bancaire basé sur une liste blanche. Une fois le projet terminé, l'accès sera transféré à la liste noire. D'énormes tableaux d'accès ont été préparés, qui indiquaient les principales ressources et référentiels auxquels l'accès était requis au début du projet. La coordination de ces accès a pris beaucoup de temps, ce qui a permis d'insister sur un passage le plus rapide possible aux listes noires.

résultats

Le projet s'est terminé il y a un peu moins d'un an. Curieusement, tous les entrepreneurs sont passés à temps à la nouvelle pile et personne n'est parti à cause de la nouvelle automatisation. IB n'est pas pressé de partager des retours positifs, mais ne se plaint pas non plus, ce qui nous permet de conclure qu'ils l'aiment. Les conflits se sont apaisés parce que la sécurité de l'information semble à nouveau sous contrôle, mais n'interfère pas avec les processus de développement. Les équipes se sont vu confier davantage de responsabilités et l'attitude globale à l'égard de la sécurité de l'information s'est améliorée. La banque a compris que la transition vers DevSecOps était presque inévitable et l'a fait, à mon avis, de la manière la plus douce et la plus correcte.

Alexander Shubin, architecte système.

Source: habr.com