Actuellement, dans le cadre de la mise en œuvre de la nouvelle stratégie de développement et de transformation numérique, VTB met activement en œuvre DevOps, intégrant la pratique du développement de logiciels sécurisés dans le processus d'ingénierie, augmentant le niveau d'automatisation et optimisant les processus de production de routine. Le but de ces changements peut être formulé en trois points clés: rapidité, fiabilité et efficacité. Naturellement, lors de ces transformations mondiales, il devient important de tenir des réunions informelles ouvertes, au cours desquelles vous pourrez partager votre propre expérience, discuter des différents carrefours et des nuances de l'introduction de diverses pratiques de production. Les Mitapas sont un excellent format pour accroître l'engagement global, la sensibilisation et l'échange d'expérience à la fois avec des collègues de la banque et avec des partenaires d'autres entreprises.
Under the cut - le plus intéressant de la première réunion VTB «DevSecOps: réponses pratiques à des questions non triviales», qui s'est tenue en novembre sur le site WeWork. La réunion a réuni plus de 200 spécialistes.
Comment tout a commencé
Comme vous le savez, VTB est la deuxième banque en Russie en termes de nombre de clients, d'actifs et d'indicateurs financiers. Depuis 2018, la banque, dans le cadre de sa stratégie de développement, a commencé à changer activement de cap technologique et a décidé une transition progressive vers le développement interne des systèmes informatiques. Avant cela, la plupart des systèmes et solutions étaient fournis par des fournisseurs. Maintenant, il est devenu important d'améliorer la qualité, la sécurité et la rapidité des livraisons en formant des équipes internes et en construisant notre propre processus informatique de production. Tout semble simple et clair: il y a des cas, il y a des solutions - prendre et mettre en œuvre.
Mais en réalité, tout est beaucoup plus compliqué. Sur cette voie, la banque a dû faire face à de nombreuses difficultés. Igor Shvakov, chef du département d'automatisation des processus de développement de VTB, en a parlé dans son rapport.
Le principal défi est le caractère unique de VTB en termes d'IT. Historiquement, la banque s'est développée grâce à l'acquisition et à l'intégration de grands acteurs, chacun disposant de sa propre architecture informatique, matériel, processus métier, etc. Depuis 2018, VTB, VTB24 et la Banque de Moscou sont devenus une seule VTB avec sa propre informatique unique paysage, infrastructure hétérogène et quelque part isolée. Naturellement, pour effectuer des changements transformationnels, construire simultanément une entreprise (telle est une stratégie commerciale) et mettre en œuvre DevOps (et surtout DevSecOps) dans de telles conditions, c'est une histoire non triviale.
La première difficulté qui a surgi au tout début est un grand nombre de fournisseurs et, par conséquent, une compétence propre étroite. Nous devions transférer des sous-traitants externes travaillant hors du périmètre vers l'infrastructure et les processus de la banque. La deuxième difficulté est que les clients professionnels ont exigé le développement actif de systèmes informatiques pour assurer la réalisation de performances commerciales élevées. Par conséquent, nous avons dû travailler dans une situation d'activité transactionnelle croissante des clients et de forte dépendance d'intégration des systèmes.
Au départ, nous avions prévu de faire la transition vers des rails internes progressivement: sélectionner les systèmes et définir les objectifs, puis préparer les équipes et les infrastructures, et au dernier stade, sélectionner les outils et configurer le pipeline DevSecOps. Mais en réalité, nous devions tout faire en même temps, et en même temps résoudre les problèmes qui se posent.
Expérience de réplication du système
Comme nous n'avions pas l'infrastructure pour le développement interne, il a été décidé de tout virtualiser et de passer à l'architecture x86 pour minimiser les coûts et les dépenses. En conséquence, une plateforme d'infrastructure a été construite sur la base de la solution hyperconvergée Nutanix déjà existante, et nous y avons transféré tous les outils de développement autant que possible.
Mais le fer est du fer et les gens y travaillent. À cet égard, la question s'est posée de savoir comment former des équipes. Nous avons décidé de nous concentrer sur les relations suivantes: deux développeurs internes devraient avoir un technologue, une équipe de 10 développeurs devrait avoir un ingénieur DevOps et deux testeurs d'automatisation. C'est ce que nous en sommes venus à notre propre expérience, en travaillant avec plus de deux douzaines de systèmes. Et cette approche a été très efficace.
La prochaine question intéressante est de savoir comment transférer les systèmes vers le circuit bancaire.
En règle générale, le cycle de traduction standard d'un système prend de 7 à 8 mois. Il se présente comme suit.
- Au cours des deux premiers mois, il y a une sélection de personnel. Dans le même temps, les relations contractuelles avec les prestataires externes sont analysées pour la possibilité de les transférer vers le travail dans le circuit bancaire.
- Au troisième mois, la compétence de base du système est en cours de formation et l'équipe DevOps est terminée en termes de développement, de configuration du pipeline et de tests automatisés. Dans le même temps, l'accès aux systèmes d'information des équipes externes est réglementé et assuré.
- Le quatrième mois - formation de l'équipe et transfert du code au référentiel bancaire du fournisseur.
- Cinquièmement - le développement conjoint des équipes de la banque et d'un entrepreneur externe, le réglage fin du Pipeline et le lancement des premières livraisons sur celui-ci.
- Au cours des sixième et septième mois, les révisions pilotes passent par tout le processus déjà directement sur l'infrastructure de la banque.
- Résultat - pour le septième mois, l'équipe commune travaille déjà au sein de la même boucle de développement de la banque.
L'expérience montre qu'avec cette approche, il est possible d'organiser des équipes bien coordonnées et de mettre en œuvre un grand nombre de projets en un an et demi. En termes, tout se passe bien, mais dans le processus de transition, nous avons eu des problèmes. L'un d'eux est un grand nombre d'équipes d'un fournisseur externe. Par exemple, l'équipe d'un des fournisseurs était composée de plus de 200 développeurs. Aujourd'hui, la plupart d'entre eux travaillent dans un circuit commun sur l'infrastructure bancaire. Et il y avait beaucoup de nuances similaires.
À l'heure actuelle, la banque compte déjà plus de vingt équipes de développement (plus de 500 développeurs à temps plein et externes), chacune utilisant son propre pipeline en termes de CI. Pour la plupart de ces commandes, l'étape CD est implémentée. Il existe également plusieurs systèmes qui utilisent déjà la livraison automatique des modifications aux circuits industriels.
Les approches mises en œuvre ont permis de construire un pipeline et de transférer le développement vers le segment interne, non seulement pour les nouveaux systèmes avec une architecture de microservices flexible, mais aussi pour un grand nombre de systèmes monolithiques complexes basés sur des solutions «box» adaptées aux besoins des banques.
Dès le début, nous n'avons pas cherché de moyens simples et avons prouvé qu'avec les bonnes compétences des employés, vous pouvez mettre en œuvre les pratiques DevOps pour tout système de toute complexité.
Maintenant, le processus prend de l'ampleur, de nouveaux systèmes sont ajoutés, la pile technologique est standardisée, les étapes uniques du pipeline, les rapports, les règles de travail. De plus, l'approche de la reproduction des pratiques dans d'autres équipes et blocs de la banque passe à un nouveau niveau de maturité, les processus sont optimisés, les rôles et compétences nécessaires au sein des équipes et la responsabilité des participants sont spécifiés. En général, le processus de réplication a été mis sur les rails et se transforme du démarrage au sein d'une grande banque en une solution d'entreprise de haute technologie. Ce chemin a été parcouru en un peu plus d'un an et demi entre le moment de l'installation du fer dans le datacenter et le déploiement des changements de mode automatique sur le circuit industriel ou pré-industriel.
Pièges
Dans le cadre de la nouvelle stratégie de VTB, la transition vers les pratiques DevSecOps a été désignée comme l'un des volets stratégiques au niveau de la banque. Alexander Kalabukhov, chef du Centre des pratiques d'ingénierie du Département du développement des systèmes de production informatique et de la maintenance VTB, en a parlé dans son rapport.
Il a été décidé de transformer les services impliqués dans le développement, les tests et l'exploitation en équipes interfonctionnelles travaillant sur la même fonctionnalité métier. Les équipes comprennent des spécialistes de l'architecture et du développement, des technologues, des testeurs et des ingénieurs DevOps. Dans les services centralisés, il ne reste que des compétences uniques ou vit à un rythme unique (24/7) - administration appliquée et système, sécurité de l'information.
Une telle transition vers des équipes interfonctionnelles pose de nouvelles exigences pour les processus de gestion de code (source, test, déploiement, etc.), la gestion des tests et du développement. Là où les lacunes de processus étaient auparavant autorisées, elles deviennent maintenant des obstacles critiques et nous améliorons notre paysage DevSecOps en termes d'outils et de combler les lacunes de processus.
En parlant d'outils. Un problème est que les banques sont soumises à certaines exigences réglementaires liées au secret bancaire et à d'autres restrictions similaires. Tout système de la banque passe le stade des tests d'acceptation de conformité aux exigences de sécurité de l'information, y compris en termes d'outils DevOps. Malheureusement, la plupart des ingénieurs DevOps n'ont jamais travaillé dans un environnement réglementé aussi difficile, et ils savent souvent peu de choses sur l'audit de ces outils, sur la façon dont l'accès au réseau et l'accès aux données doivent être limités, que faire des secrets échangés entre les outils DevOps etc.
La tâche principale du renforcement de la protection des données à l'intérieur de la banque est de garantir qu'aucune personne n'a accès à toutes les données à la fois. C'est pourquoi les développeurs ne peuvent pas exécuter les fonctions d'administrateur d'application et d'administrateur système. Des limitations similaires existent pour les ingénieurs DevSec. Naturellement, aucun de ces spécialistes ne peut être administrateur de la sécurité de l'information. Une fois que tous les rôles et le périmètre de leur autorité sont définis, vous pouvez intégrer le processus standard d'octroi de droits de l'outil DevOps au processus général d'octroi de droits dans une banque.
Un aspect important est la sécurité du réseau. Vous devez respecter la règle selon laquelle une connexion ne peut être établie qu'à partir de circuits plus fiables vers des circuits moins fiables. Si le processus est mené dans la direction opposée, il est nécessaire de combler les lacunes du réseau en utilisant des moyens spéciaux. Les connexions réseau doivent être établies en toute sécurité et toujours cryptées entre elles. Sinon, des virus et autres logiciels malveillants peuvent entrer dans la chaîne, ce qui peut entraîner des fuites de données et des incidents dans les environnements industriels.
Les problèmes de sécurité sont influencés par la façon dont les données sont organisées, car il existe divers environnements de développement et de test, il est nécessaire de rejoindre le circuit de la banque via un VPN afin que les sous-traitants puissent travailler à partir de leurs ordinateurs portables. De plus, il existe des circuits spéciaux où l'accès à un cercle restreint de personnes est autorisé, les données ne doivent pas dépasser ces circuits.
Par conséquent, malgré toute la richesse des outils DevOps existants, il est nécessaire de les standardiser. Avec la bonne approche, la sécurité de l'information dans la banque introduit des restrictions au processus de développement et d'exploitation, mais n'empêche pas l'introduction de nouvelles technologies.
La cybersécurité avant tout
Dans le contexte de la transformation de l'entreprise et d'un délai plus court pour lancer de nouveaux produits numériques sur le marché, le principal défi industriel est d'assurer la sécurité de l'information à toutes les étapes du processus de production en continu. Le sujet de l'intégration des pratiques de développement de logiciels sécurisés dans DevOps a fait l'objet d'un rapport de Yuri Sergeyev, associé directeur de Swordfish Security et leader de l'industrie DevSecOps en Russie.
La mise en œuvre du paradigme de la cybersécurité dans DevOps est un processus assez compliqué, dans lequel la couche de pratiques de sécurité enveloppe tout le cycle d'ingénierie de production. Les pratiques de sécurité de l'information elles-mêmes sont soutenues par une pile instrumentale intégrée à toutes les étapes du processus.
Les pratiques SI nécessaires incluent:
- Contrôle des composants open source lorsqu'ils entrent dans le périmètre de développement (Open Source Analysis, OSA);
- Analyse de code statique (Test d'application de sécurité statique, SAST);
- Suivi de la composition des composants logiciels (Software Composition Analysis, SCA);
- Tous les types d'analyses dynamiques (test de sécurité d'application dynamique, test de sécurité d'application DAST / interactif, test de sécurité d'application IAST / comportemental, BAST);
- Analyse de code binaire et contrôle de la composition des conteneurs (Bytecode and Container Analysis, BCA);
- Implémentation de WAF (Web Application Firewall).
Dans le même temps, les aspects les plus importants lors de la mise à l'échelle et de la transformation des processus DevOps dans le paradigme DevSecOps dérivé sont:
- Utilisation de bibliothèques, de frameworks et de composants logiciels sécurisés par défaut pendant le processus de développement (Secure-by-Default);
- Intégration des pratiques technologiques SI au tout début du pipeline CI / CD (approche Shift-Left);
- Automatisation de tous les processus dans le concept de tout en tant que code;
- Formation d'une communauté de champions de la sécurité qui sont responsables des tâches de sécurité de l'information dans les équipes de production et sont les guides d'une culture de sécurité d'ingénierie;
- Application du modèle de maturité DevSecOps à la fois pour l'évaluation du processus existant et pour l'amélioration continue;
- Assurer la transparence de toutes les activités de sécurité pour tous les participants au processus de production d'ingénierie.
Par ailleurs, il convient de souligner l'importance de la pratique de DevSecOps-orchestration (Application Security Testing Orchestration, ASTO), qui fournit une intégration de bout en bout de la pile d'outils IS avec des outils de développement, une gestion automatisée du pipeline de sécurité (pipelines), ainsi que la collecte, la consolidation et l'analyse de toutes les données en continu processus de développement logiciel sécurisé. La pratique de l'orchestration peut considérablement économiser des ressources et réduire de plus de 10 fois le temps total de mise en œuvre de l'initiative DevSecOps dans des environnements d'ingénierie hétérogènes complexes.
Si nous parlons de la transformation dans son ensemble, nous pouvons distinguer les facteurs clés de succès suivants:
- L'introduction d'un outil ou d'un élément distinct du processus de cybersécurité est, bien sûr, une étape importante, mais en aucun cas une solution miracle pour résoudre les problèmes de sécurité des logiciels développés à l'échelle industrielle. La clé du succès n'est que l'application intégrée de l'ensemble des pratiques de sécurité de l'information.
- L'application de la pratique de l'orchestration protégera les équipes d'ingénieurs et l'équipe de sécurité de l'information du chaos technologique de l'intégration des instruments «à hauteur du genou» et de l'automatisation «patchwork» incontrôlée.
- La collecte de données et la visualisation subséquente des métriques vous permettront de gérer le processus de bout en bout, de réaliser une transparence totale et de créer également la base nécessaire pour l'application de pratiques d'apprentissage automatique à l'avenir.