🏨 💇🏻 💂🏼 DevOps vs DevSecOps: à quoi cela ressemblait dans une banque 🔝 🏐 😃

La banque confie ses projets à de nombreux entrepreneurs. Les "étrangers" écrivent le code, puis transmettent les résultats sous une forme peu pratique. Plus précisément, le processus ressemblait à ceci: ils ont transféré un projet qui a passé avec succès des tests fonctionnels, puis a déjà été testé dans le périmètre bancaire pour l'intégration, la charge, etc. On a souvent découvert que les tests étaient féeriques. Ensuite, tout est retourné au développeur externe. Comme vous pouvez le deviner, cela signifiait beaucoup de temps pour corriger les erreurs.

La banque a décidé qu'il était possible et nécessaire de faire glisser l'ensemble du pipeline «sous l'aile» des commits à la libération. Pour que tout soit cohérent et sous le contrôle des équipes responsables du produit en banque. Autrement dit, comme si l'entrepreneur externe travaillait simplement quelque part dans la pièce voisine du bureau. Sur la pile d'entreprise. Ceci est une devopa ordinaire.

D'où vient Sec? La sécurité bancaire a imposé des exigences élevées sur la façon dont un entrepreneur externe peut travailler dans le segment de réseau, qui a accès, comment et qui travaille avec le code. C’est juste que IB ne savait pas encore que lorsque les entrepreneurs travaillent à l’extérieur, peu de normes bancaires sont respectées. Et ici, dans quelques jours, tout le monde doit commencer à les observer.

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

À ce moment, l'histoire de DevSecOps a commencé, dont je veux parler.

Quelle banque a tiré des conclusions pratiques de cette situation

Il y a eu beaucoup de controverse sur le fait que tout est mal fait. Les développeurs ont déclaré que la sécurité n'était occupée que par des tentatives d'entraver le développement et, en tant que gardiens, ils essayaient d'interdire sans réfléchir. À leur tour, les agents de sécurité ont hésité entre choisir entre des 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 ils le sont eux-mêmes». Le débat durerait longtemps, sinon pour 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 «out of the box» aidera chacun à être satisfait. En ce sens que les règles sont écrites immédiatement et ne changent pas pendant le jeu (le SI n'interdira pas quelque chose de façon inattendue), et les développeurs tiennent le SI informé de tout ce qui se passe (le SI ne rencontre pas soudainement quelque chose).Chaque équipe est responsable de la sécurité ultime, et non certains frères aînés abstraits.

, , « ».
, , .
- , . , . .

Autrement dit, les entrepreneurs peuvent être autorisés, mais vous devez en faire des segments distincts. Pour qu'ils ne traînent pas à l'extérieur d'une sorte d'infection dans l'infrastructure de la banque et qu'ils ne voient pas plus que nécessaire. Eh bien, pour que leurs actions soient enregistrées. DLP pour la protection contre les "puits", tout cela a été appliqué.

En principe, toutes les banques y parviennent tôt ou tard. Ensuite, nous sommes sortis des sentiers battus et nous nous sommes mis d'accord sur les exigences pour de tels environnements où travaillent des «étrangers». Il est apparu un ensemble maximal d'outils de contrôle d'accès, de vérificateurs de vulnérabilité, d'analyses antivirus sur les circuits, les assemblages et les tests. C'est ce qu'ils ont appelé DevSecOps.

Il est soudain devenu clair que si avant cette sécurité bancaire DevSecOps n'avait aucun contrôle sur ce qui se passait 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. Seulement maintenant, il existe des alertes sur les assemblys, le contrôle de bibliothèque, etc.

Il ne reste plus qu'à transférer l'équipe vers un nouveau modèle. Eh bien, créez une infrastructure. Mais ce sont de petites choses, voici comment dessiner un hibou. En fait, nous avons aidé à l'infrastructure et à ce moment les processus de développement ont changé.

Ce qui changeait

Ils ont décidé de le mettre en œuvre par petites étapes, car ils ont réalisé que de nombreux processus s'effondreraient et que de nombreux «étrangers» pourraient ne pas être en mesure de résister aux nouvelles conditions de travail sous la supervision de tout le monde.

Tout d'abord, nous avons créé des équipes interfonctionnelles et appris à organiser des projets en tenant compte des nouvelles exigences. En termes de discussion organisationnelle, quels processus. Il s'est avéré que le pipeline de montage avec tous les responsables.

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

Sélection d'une pile:

Base de connaissances - Atlassian Confluence;
Suivi des tâches - Atlassian Jira;
Dépôt d'objets - "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 la configuration - «Ansible»;
Système de surveillance - «ELK», «TICK Stack» («InfluxData»).

Ils ont commencé à créer une équipe qui serait prête à entraîner les entrepreneurs. La prise de conscience est venue qu'il y a plusieurs choses importantes:

. — . , .
, . — , .

Pour faire le premier pas, il fallait comprendre ce qui se faisait. Et nous avons dû déterminer comment procéder. 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. Nous avions besoin d'une infrastructure, la même pour tous, où les mêmes convoyeurs fonctionneraient. Nous avons proposé des options avec des règlements, pensa la banque, puis nous avons décidé de quoi et de quels moyens il serait construit.

Poursuite de la création du circuit - installation du logiciel, configuration. Développement de scripts pour l'infrastructure de déploiement et la gestion. Vient ensuite la transition vers la prise en charge du pipeline.

Nous avons décidé de tout exécuter sur le pilote. Fait intéressant, lors du pilotage, une certaine pile est apparue dans la banque pour la première fois. Entre autres, un fournisseur national d'une des solutions pour un lancement précoce a été proposé pour le volume du pilote. La sécurité a fait sa connaissance pendant le pilotage, ce qui a laissé une expérience inoubliable. Quand ils ont décidé de changer, heureusement, la couche infrastructure a été remplacée par une solution nutanix qui était déjà en banque auparavant. Et avant cela, c'était pour VDI, et nous l'avons réutilisé pour les services d'infrastructure. Sur de petits volumes, il ne rentre pas dans l'économie, mais sur de gros volumes il devient un excellent environnement de développement et de test.

Le reste de la pile est plus ou moins familier à tout le monde. Des outils d'automatisation dans la partie Ansible ont été utilisés et les agents de sécurité ont travaillé en étroite collaboration avec eux. La pile Atlassinovsky était utilisée par la banque avant le projet. Fortinet Security Tools - Il a été proposé par les agents de sécurité eux-mêmes. Le cadre de test a été créé par la banque, aucune question n'a été posée. Les questions étaient causées par le système de dépôt, je devais m'y habituer.

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

Pas à pas

Étape 1. Tout d'abord, nous avons utilisé la solution d'un fournisseur national, le produit a été basculé vers le segment de réseau DSO nouvellement créé. La plateforme a été sélectionnée pour ses délais de livraison, son évolutivité et ses capacités d'automatisation complètes. 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 de disque, sous-système de 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 deuxième étape (outils DSO, plans de développement de 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.

Résultat - l'équipement fourni ne répond pas aux exigences de la banque en termes de performances et de tolérance aux pannes. DIT Bank a décidé de créer un complexe basé sur PAC Nutanix.

Étape 2. Nous avons pris la pile qui a été définie et écrit des scripts pour l'installation automatisée et la post-configuration de tous les sous-systèmes, afin que tout soit transféré du pilote au circuit cible le plus rapidement possible. Tous les systèmes ont été déployés dans une configuration à tolérance de pannes (où cette fonctionnalité ne se limite pas aux politiques sous licence du fournisseur) et sont connectés aux sous-systèmes pour collecter les mesures et les é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 du sous-système DSO a été effectuée dans un mode entièrement automatisé. Les chemins de développement du SI ont été recréés par les pipelines de l'équipe de développement.

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

Étape 5. Fonctionnement.

Accès à distance

Les équipes de développement ont demandé une flexibilité maximale pour travailler avec le circuit, et la nécessité d'un accès à distance à partir des ordinateurs portables personnels a été posée au tout début du projet. La banque avait déjà un accès à distance, mais il n'était pas adapté aux développeurs. Le fait est que le schéma utilisait une connexion utilisateur à un VDI sécurisé. Cela convenait à ceux qui avaient suffisamment de courrier et un colis de bureau sur le lieu de travail. Les développeurs auraient besoin de clients lourds, performants et disposant de nombreuses ressources. Et bien sûr, ils devaient être statiques, car la perte d'une session utilisateur pour ceux qui travaillent avec VStudio (par exemple) ou un 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 développement. Jira, Wiki, Gitlab, Nexus, stands de montage et de test, infrastructure virtuelle. Les agents de sécurité ont défini des exigences selon lesquelles l'accès ne peut être organisé que sous réserve des éléments suivants:

Utiliser les technologies déjà disponibles dans la banque.
L'infrastructure ne doit pas utiliser de contrôleurs de domaine existants qui stockent des enregistrements de comptes / objets productifs.
L'accès doit être limité uniquement aux ressources requises par une équipe particulière (afin qu'une équipe d'un produit ne puisse pas accéder aux ressources d'une autre équipe).
Contrôle maximal sur RBAC dans les systèmes.

Par conséquent, un domaine distinct a été créé pour ce segment. Ce domaine hébergeait 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.

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

Gérer les modèles de VM

La vitesse de création du circuit d'assemblage et de test est l'un des principaux KPI fixés par le chef de l'unité de développement, car la vitesse de préparation de l'environnement affecte directement le temps d'exécution global du pipeline. Deux options pour la préparation d'images de base de VM ont été envisagées. Le premier est la taille d'image minimale, par défaut pour tous les produits / systèmes, la conformité maximale avec les politiques bancaires pour les paramètres. La seconde est une image de base contenant le logiciel / logiciel lourd installé, dont le temps d'installation pourrait affecter considérablement la vitesse du pipeline.

Les exigences d'infrastructure et de sécurité ont également été prises en compte lors du développement - maintien à jour des images (correctifs, etc.), intégration avec SIEM, paramétrage de sécurité selon les normes adoptées par la banque.

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 d'installer des correctifs dans chaque image pour les nouvelles versions de logiciels / logiciels.

Sur la base des résultats, une liste a été compilée de l'ensemble minimal requis de systèmes d'exploitation, dont la mise à jour est effectuée par l'équipe d'exploitation, et les scripts du pipeline sont entièrement responsables de la mise à jour du logiciel / logiciel et, si nécessaire, de la modification de la version du logiciel installé - il suffit de transférer la balise souhaitée dans le pipeline. Oui, cela nécessite une équipe de produits devops'a des scénarios de déploiement plus complexes, mais réduit considérablement le temps de fonctionnement pour prendre en charge les images de base, qui pourraient tomber sur le service plus d'une centaine d'images de base de VM.

Accès à Internet

Un autre obstacle à la sécurité bancaire a été l'accès de l'environnement de développement aux ressources Internet. De plus, cet accès peut être divisé en deux catégories:

Accès à l'infrastructure.
Accès aux développeurs.

L'accès à l'infrastructure a été organisé par procuration de référentiels externes par Nexus. Autrement dit, l'accès direct à partir des machines virtuelles n'a pas été fourni. Cela a permis de faire des compromis avec l'EI, ce qui était catégoriquement opposé à tout accès au monde extérieur à partir du segment du développement.

L'accès à Internet pour les développeurs était nécessaire pour des raisons évidentes (stackoverflow). Et bien que toutes les équipes, comme mentionné ci-dessus, aient accès à distance au circuit, 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 dans l'IDE.

Il a été convenu avec IS qu'initialement, au stade des tests, l'accès sera fourni via un proxy bancaire basé sur une liste blanche. À la fin du projet - 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 qui avaient besoin d'accès au début du projet. La coordination de ces accès a pris un temps décent, ce qui nous a permis d'insister sur la transition la plus rapide vers les listes noires.

résultats

Le projet s'est terminé il y a un peu moins d'un an. Curieusement, mais tous les entrepreneurs à l'heure sont passés à la nouvelle pile et personne n'est parti à cause de la nouvelle automatisation. IB n'est pas pressé de partager des critiques positives, mais il ne se plaint pas, dont nous pouvons conclure qu'ils aiment. Les conflits se sont apaisés, car l'EI ressent à nouveau le contrôle, mais en même temps n'interfère pas avec les processus de développement. Les équipes ont davantage de responsabilités et, en général, l'attitude envers 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, à mon avis, l'a fait de la manière la plus douce et correcte.

Alexander Shubin, architecte de systèmes.

DevOps vs DevSecOps: à quoi cela ressemblait dans une banque