Derzeit implementiert VTB im Rahmen der Umsetzung der Strategie für die Neuentwicklung und die digitale Transformation DevOps aktiv. Dabei wird die Praxis der Entwicklung sicherer Software in den Konstruktionsprozess integriert, der Automatisierungsgrad erhöht und die routinemäßigen Produktionsprozesse optimiert. Der Zweck dieser Änderungen kann in drei Hauptpunkten formuliert werden: Geschwindigkeit, Zuverlässigkeit und Effizienz. Natürlich wird es bei solchen globalen Transformationen wichtig, informelle Meetings abzuhalten, in denen Sie Ihre eigenen Erfahrungen austauschen und die verschiedenen Kreuzungen und Nuancen der Einführung verschiedener Produktionspraktiken diskutieren können. Mitapas sind ein hervorragendes Format, um das allgemeine Engagement, das Bewusstsein und den Erfahrungsaustausch sowohl mit Kollegen aus der Bank als auch mit Partnern aus anderen Unternehmen zu verbessern.
Under the cut - das Interessanteste aus dem ersten VTB-Meeting „DevSecOps: Praktische Antworten auf nicht triviale Fragen“, das im November am Standort WeWork stattfand. Das Treffen wurde von über 200 Fachleuten besucht.
Wie alles begann
Wie Sie wissen, ist die VTB die zweitgrößte Bank in Russland, gemessen an der Anzahl der Kunden, Aktiva und Finanzkennzahlen. Seit 2018 hat die Bank im Rahmen der Entwicklungsstrategie begonnen, ihren technologischen Kurs aktiv zu ändern und sich für einen schrittweisen Übergang zur internen Entwicklung von IT-Systemen entschieden. Zuvor wurden die meisten Systeme und Lösungen von Anbietern geliefert. Jetzt ist es wichtig geworden, die Qualität, Sicherheit und Geschwindigkeit der Lieferungen durch die Bildung interner Teams und den Aufbau eines eigenen IT-Produktionsprozesses zu verbessern. Alles scheint einfach und klar zu sein: Es gibt Fälle, es gibt Lösungen - nehmen und umsetzen.
In Wirklichkeit ist alles viel komplizierter. Auf diesem Weg hatte die Bank mit vielen Schwierigkeiten zu kämpfen. Igor Shvakov, der Leiter der VTB-Abteilung für die Automatisierung von Entwicklungsprozessen, sprach in seinem Bericht darüber.
Die größte Herausforderung ist die Einzigartigkeit der VTB in Bezug auf die IT. Historisch gesehen entwickelte sich die Bank durch die Akquisition und Integration von großen Playern, von denen jeder über eine eigene IT-Architektur, Hardware, Geschäftsprozesse usw. verfügte. Seit 2018 sind VTB, VTB24 und die Bank of Moscow eine VTB mit einer eigenen, einzigartigen IT Landschaft, heterogene und irgendwo isolierte Infrastruktur. Natürlich ist es eine nicht triviale Geschichte, unter solchen Bedingungen gleichzeitig ein Geschäft aufzubauen (so eine Geschäftsstrategie) und DevOps (und insbesondere DevSecOps) umzusetzen.
Die erste Schwierigkeit, die am Anfang auftrat, war eine große Anzahl von Anbietern und folglich eine enge eigene Kompetenz. Wir mussten externe Auftragnehmer, die außerhalb des Perimeters arbeiteten, in die Infrastruktur und Prozesse der Bank überführen. Die zweite Schwierigkeit besteht darin, dass Geschäftskunden die aktive Entwicklung von IT-Systemen forderten, um eine hohe Geschäftsleistung zu erzielen. Daher mussten wir in einer Situation mit zunehmender Transaktionsaktivität der Kunden und einer hohen Abhängigkeit der Systeme von der Integration arbeiten.
Zunächst planten wir den schrittweisen Übergang zu internen Schienen: Wählen Sie Systeme aus und definieren Sie Ziele, bereiten Sie dann Teams und Infrastruktur vor und wählen Sie in der letzten Phase Tools aus und konfigurieren Sie die DevSecOps-Pipeline. In der Realität mussten wir jedoch alles auf einmal tun und gleichzeitig die auftretenden Probleme lösen.
Systemreplikationserfahrung
Da wir nicht über die Infrastruktur für die Eigenentwicklung verfügten, wurde beschlossen, alles zu virtualisieren und auf die x86-Architektur umzustellen, um Kosten und Kosten zu minimieren. Infolgedessen wurde eine Infrastrukturplattform auf der Grundlage der bereits vorhandenen hyperkonvergenten Nutanix-Lösung aufgebaut und wir haben alle Entwicklungstools so weit wie möglich darauf übertragen.
Aber Eisen ist Eisen, und die Leute arbeiten daran. In diesem Zusammenhang stellte sich die Frage, wie man Teams bildet. Wir haben beschlossen, uns auf die folgenden Beziehungen zu konzentrieren: Zwei interne Entwickler sollten einen Technologen haben, ein Team von 10 Entwicklern sollte einen DevOps-Ingenieur und zwei Automatisierungstester haben. Dies haben wir aus eigener Erfahrung mit mehr als zwei Dutzend Systemen erlebt. Und dieser Ansatz war sehr effektiv.
Die nächste interessante Frage ist, wie Systeme in den Bankkreislauf übertragen werden können.
In der Regel dauert der Standard-Übersetzungszyklus eines Systems 7 bis 8 Monate. Es ist wie folgt aufgebaut.
- In den ersten zwei Monaten erfolgt eine Personalauswahl. Gleichzeitig werden die vertraglichen Beziehungen zu externen Auftragnehmern auf die Möglichkeit hin analysiert, sie auf die Arbeit im Bankenkreislauf zu übertragen.
- Im dritten Monat wird die Kernkompetenz des Systems gebildet und das DevOps-Team in Bezug auf Entwicklung, Pipeline-Einrichtung und automatisierte Tests vervollständigt. Gleichzeitig wird der Zugang zu Informationssystemen für externe Teams geregelt und bereitgestellt.
- Der vierte Monat - Schulung des Teams und Übermittlung des Codes vom Verkäufer an das Bankregister.
- Fünftens - gemeinsame Entwicklung durch die Teams der Bank und eines externen Auftragnehmers, Feinabstimmung der Pipeline und der Start der ersten Lieferungen darauf.
- Im sechsten und siebten Monat durchlaufen Pilotrevisionen den gesamten Prozess bereits direkt in der Infrastruktur der Bank.
- Ergebnis - Bereits im siebten Monat arbeitet das gemeinsame Team in der Bank in der gleichen Entwicklungsschleife.
Die Erfahrung zeigt, dass es mit diesem Ansatz möglich ist, gut koordinierte Teams zu organisieren und eine große Anzahl von Projekten in eineinhalb Jahren umzusetzen. In Worten ist alles glatt, aber im Übergangsprozess hatten wir Probleme. Eines davon ist eine große Anzahl von Teams eines externen Anbieters. Zum Beispiel bestand das Team eines der Anbieter aus mehr als 200 Entwicklern. Jetzt arbeiten die meisten innerhalb eines gemeinsamen Kreislaufs für die Bankinfrastruktur. Und es gab viele ähnliche Nuancen.
Derzeit verfügt die Bank bereits über mehr als zwanzig Entwicklungsteams (mehr als 500 Vollzeit- und externe Entwickler), von denen jedes seine eigene Pipeline in Bezug auf CI verwendet. Für die meisten dieser Befehle ist der CD-Schritt implementiert. Es gibt auch mehrere Systeme, die bereits die automatische Übermittlung von Änderungen an industriellen Schaltkreisen verwenden.
Die implementierten Ansätze ermöglichten den Aufbau einer Pipeline und die Übertragung der Entwicklung in das interne Segment, nicht nur für neue Systeme mit einer flexiblen Mikroservice-Architektur, sondern auch für eine große Anzahl komplexer monolithischer Systeme, die auf an die Bankanforderungen angepassten "Boxed" -Lösungen basierten.
Von Anfang an haben wir nicht nach einfachen Wegen gesucht und bewiesen, dass Sie mit den richtigen Kompetenzen der Mitarbeiter DevOps-Praktiken für jedes System mit beliebiger Komplexität implementieren können.
Jetzt gewinnt der Prozess an Fahrt, neue Systeme werden hinzugefügt, der technologische Stack ist standardisiert, einzelne Phasen der Pipeline, Berichterstattung, Arbeitsregeln. Auch der Ansatz, Praktiken auf andere Teams und Blöcke der Bank zu übertragen, erreicht einen neuen Reifegrad, Prozesse werden optimiert, die erforderlichen Rollen und Kompetenzen innerhalb der Teams festgelegt und die Verantwortung der Teilnehmer festgelegt. Im Allgemeinen wurde der Replikationsprozess auf die Schiene gelegt und wird vom Start in einer großen Bank in eine High-Tech-Unternehmenslösung umgewandelt. Dieser Weg war in etwas mehr als eineinhalb Jahren zurückgelegt, vom Moment der Installation von Eisen im Rechenzentrum bis zur Einführung der Änderungen im automatischen Modus in der industriellen oder vorindustriellen Schaltung.
Fallstricke
Als Teil der neuen Strategie der VTB wurde der Übergang zu DevSecOps als einer der strategischen Bereiche auf Bankebene herausgestellt. Alexander Kalabukhov, Leiter des Zentrums für Ingenieurpraxis der Abteilung für Entwicklung von IT-Produktionssystemen und VTB-Wartung, berichtete in seinem Bericht darüber.
Es wurde beschlossen, die an der Entwicklung, dem Testen und dem Betrieb beteiligten Dienste in funktionsübergreifende Teams umzuwandeln, die an derselben Geschäftsfunktionalität arbeiten. Zu den Teams gehören Architektur- und Entwicklungsspezialisten, Technologen, Tester und DevOps-Ingenieure. Bei zentralisierten Diensten bleibt nur das übrig, das eindeutige Kompetenzen besitzt oder in einem eindeutigen Rhythmus (24/7) lebt - angewandte und Systemadministration, Informationssicherheit.
Ein solcher Übergang zu funktionsübergreifenden Teams stellt neue Anforderungen an die Codeverwaltungsprozesse (Quelle, Test, Bereitstellung usw.) sowie an das Test- und Entwicklungsmanagement. Wo zuvor Prozesslücken akzeptabel waren, werden sie jetzt zu kritischen Hürden, und wir verbessern unsere DevSecOps-Landschaft in Bezug auf Tools und die Überbrückung von Prozesslücken.
Apropos Werkzeuge. Ein Problem besteht darin, dass Banken bestimmten aufsichtsrechtlichen Anforderungen im Zusammenhang mit dem Bankgeheimnis und anderen ähnlichen Beschränkungen unterliegen. Jedes System in der Bank besteht die Phase der Akzeptanztests zur Einhaltung der Anforderungen an die Informationssicherheit, einschließlich der DevOps-Tools. Leider haben die meisten DevOps-Ingenieure noch nie in einem so strengen regulierten Umfeld gearbeitet und wissen oft wenig über die Prüfung dieser Tools, darüber, wie der Netzwerkzugriff und der Datenzugriff eingeschränkt werden sollten und was mit den zwischen DevOps-Tools ausgetauschten Geheimnissen zu tun ist usw.
Die Hauptaufgabe beim Aufbau des Datenschutzes in der Bank besteht darin, sicherzustellen, dass niemand auf alle Daten gleichzeitig zugreifen kann. Aus diesem Grund können Entwickler die Funktionen von Anwendungs- und Systemadministratoren nicht ausführen. Ähnliche Einschränkungen bestehen für DevSec-Ingenieure. Natürlich kann keiner dieser Spezialisten ein Informationssicherheitsadministrator sein. Sobald alle Rollen und der Umfang ihrer Berechtigung definiert sind, können Sie den Standardprozess für die Erteilung von DevOps-Tool-Rechten in den allgemeinen Prozess für die Erteilung von Rechten in einer Bank einbetten.
Ein wichtiger Aspekt ist die Netzwerksicherheit. Sie müssen die Regel einhalten, dass eine Verbindung nur von vertrauenswürdigeren zu weniger vertrauenswürdigen Schaltkreisen hergestellt werden kann. Wenn der Prozess in die entgegengesetzte Richtung ausgeführt wird, ist es erforderlich, Netzwerklücken mit speziellen Mitteln bereitzustellen. Netzwerkverbindungen müssen sicher hergestellt und untereinander noch verschlüsselt sein. Andernfalls können Viren und andere schädliche Software in die Kette gelangen, was zu Datenlecks und Vorfällen in Industrieumgebungen führen kann.
Sicherheitsprobleme werden durch die Art und Weise beeinflusst, in der Daten organisiert werden. Da es verschiedene Entwicklungs- und Testumgebungen gibt, muss die Bank über VPN verbunden werden, damit Auftragnehmer von ihren Laptops aus arbeiten können. Außerdem gibt es spezielle Schaltkreise, in denen der Zugriff auf einen begrenzten Personenkreis gestattet ist. Daten sollten diese Schaltkreise nicht überschreiten.
Trotz der Fülle der vorhandenen DevOps-Tools ist es daher erforderlich, sie zu standardisieren. Mit dem richtigen Ansatz führt die Informationssicherheit in der Bank zu Einschränkungen im Entwicklungs- und Betriebsprozess, verhindert jedoch nicht die Einführung neuer Technologien.
Cybersicherheit über alles
Vor dem Hintergrund der geschäftlichen Transformation und einer kürzeren Zeit für die Markteinführung neuer digitaler Produkte besteht die wichtigste industrielle Herausforderung darin, die Informationssicherheit in allen Phasen des kontinuierlichen Produktionsprozesses zu gewährleisten. Das Thema der Integration sicherer Softwareentwicklungspraktiken in DevOps war Gegenstand eines Berichts von Yuri Sergeyev, Managing Partner von Swordfish Security und Marktführer der DevSecOps-Branche in Russland.
Die Implementierung des Cybersicherheitsparadigmas in DevOps ist ein ziemlich komplizierter Prozess, in dem die Sicherheitspraktiken den gesamten Produktionsentwicklungszyklus abdecken. Die Informationssicherheitspraktiken selbst werden durch einen Instrumentenstapel unterstützt, der in alle Phasen des Prozesses integriert ist.
Die erforderlichen IS-Praktiken umfassen:
- Kontrolle von Open Source-Komponenten, wenn diese in den Entwicklungsbereich fallen (Open Source Analysis, OSA);
- Statische Code-Analyse (Static Application Security Testing, SAST);
- Überwachung der Zusammensetzung von Softwarekomponenten (Software Composition Analysis, SCA);
- Alle Arten dynamischer Analysen (Dynamic Application Security Testing, DAST / Interactive Application Security Testing, IAST / Behavioral Application Security Testing, BAST);
- Binärcode-Analyse und Container-Zusammensetzungskontrolle (Bytecode- und Container-Analyse, BCA);
- Implementierung von WAF (Web Application Firewall).
Die wichtigsten Aspekte bei der Skalierung und Transformation von DevOps-Prozessen in das abgeleitete DevSecOps-Paradigma sind:
- Verwendung von sicheren Bibliotheken, Frameworks und Softwarekomponenten standardmäßig während des Entwicklungsprozesses (Secure-by-Default);
- Integration von IS-Technologie-Praktiken zu Beginn der CI / CD-Pipeline (Shift-Left-Ansatz);
- Automatisierung aller Prozesse im Everything-as-a-Code-Konzept;
- Bildung einer Community von Sicherheitsexperten, die für die Aufgaben der Informationssicherheit in Produktionsteams verantwortlich sind und die Leitfäden einer technischen Sicherheitskultur sind;
- Anwendung des DevSecOps-Reifegradmodells sowohl zur Bewertung des bestehenden Prozesses als auch zur kontinuierlichen Verbesserung;
- Gewährleistung der Transparenz aller Sicherheitsaktivitäten für alle Teilnehmer am technischen Produktionsprozess.
Hervorzuheben ist auch die Bedeutung der DevSecOps-Orchestration (Application Security Testing Orchestration, ASTO), die eine durchgängige Integration des IS-Toolstacks in Entwicklungstools, die automatisierte Verwaltung der Sicherheitspipeline (Pipelines) sowie die kontinuierliche Erfassung, Konsolidierung und Analyse aller Daten ermöglicht sicherer Software-Entwicklungsprozess. Durch das Ausführen von Orchestrierung können Ressourcen erheblich gespart und die Gesamtimplementierungszeit der DevSecOps-Initiative in komplexen heterogenen Entwicklungsumgebungen um das Zehnfache verkürzt werden.
Wenn wir über die Transformation als Ganzes sprechen, können wir die folgenden Schlüsselfaktoren für den Erfolg unterscheiden:
- Die Einführung eines separaten Tools oder Elements für den Cybersicherheitsprozess ist natürlich ein wichtiger Schritt, aber in keinem Fall eine Silberkugel, um die Sicherheitsprobleme von entwickelter Software im industriellen Maßstab anzugehen. Der Schlüssel zum Erfolg ist nur die integrierte Anwendung des gesamten Pools an Informationssicherheitspraktiken.
- Die Anwendung der Orchestrierungspraxis schützt Ingenieurteams und das Informationssicherheitsteam vor dem technologischen Chaos der Integration kniehoher Instrumente und der unkontrollierten Patchwork-Automatisierung.
- Durch die Datenerfassung und anschließende Visualisierung von Metriken können Sie den End-to-End-Prozess verwalten, vollständige Transparenz erzielen und die notwendige Grundlage für die Anwendung maschineller Lernmethoden in der Zukunft schaffen.