DevOps vs. DevSecOps: So sah es in einer Bank aus

Die Bank lagert ihre Projekte an viele Auftragnehmer aus. „Externe“ schreiben Code und übermitteln die Ergebnisse dann in einer nicht sehr praktischen Form. Konkret sah der Prozess so aus: Sie übergaben ein Projekt, das die Funktionstests mit ihnen bestand, und wurde dann innerhalb des Bankperimeters auf Integration, Auslastung usw. getestet. Es wurde oft festgestellt, dass Tests fehlschlugen. Dann ging alles zurück zum externen Entwickler. Wie Sie sich vorstellen können, bedeutete dies lange Vorlaufzeiten für Fehlerbehebungen.

Die Bank kam zu dem Schluss, dass es möglich und notwendig sei, die gesamte Pipeline von den Commits bis zur Freigabe unter ihre Fittiche zu nehmen. Damit alles einheitlich ist und unter der Kontrolle der für das Produkt verantwortlichen Teams in der Bank steht. Das heißt, als würde der externe Auftragnehmer einfach irgendwo im Nebenzimmer des Büros arbeiten. Auf dem Unternehmensstapel. Dies ist ein gewöhnlicher Entwickler.

Woher kam Sec? Die Sicherheit der Bank stellt hohe Anforderungen daran, wie ein externer Auftragnehmer im Netzwerksegment arbeiten kann, welchen Zugriff jemand hat, wie und wer mit dem Code arbeitet. Es ist nur so, dass IB noch nicht wusste, dass bei der Arbeit von Auftragnehmern im Freien nur wenige Bankstandards eingehalten werden. Und dann muss in ein paar Tagen jeder anfangen, sie zu beobachten.

Die einfache Entdeckung, dass der Auftragnehmer vollständigen Zugriff auf den Produktcode hatte, hatte ihre Welt bereits auf den Kopf gestellt.

In diesem Moment begann die Geschichte von DevSecOps, von der ich Ihnen erzählen möchte.

Welche praktischen Schlussfolgerungen hat die Bank aus dieser Situation gezogen?

Es gab viele Kontroversen darüber, dass alles falsch gemacht wird. Die Entwickler sagten, dass die Sicherheit nur damit beschäftigt sei, in die Entwicklung einzugreifen, und dass sie wie Wächter versuchen, ohne nachzudenken zu verbieten. Im Gegenzug zögerten Sicherheitsexperten, zwischen den Standpunkten zu wählen: „Entwickler schaffen Schwachstellen in unserem Schaltkreis“ und „Entwickler schaffen keine Schwachstellen, sondern sind sie selbst.“ Der Streit hätte ohne neue Marktanforderungen und das Aufkommen des DevSecOps-Paradigmas noch lange andauern können. Es konnte erklärt werden, dass gerade diese Automatisierung von Prozessen unter Berücksichtigung von Informationssicherheitsanforderungen „out of the box“ dazu beitragen wird, dass alle glücklich bleiben. In dem Sinne, dass die Regeln sofort niedergeschrieben werden und sich während des Spiels nicht ändern (die Informationssicherheit verbietet nichts Unerwartetes), und die Entwickler halten die Informationssicherheit über alles, was passiert, auf dem Laufenden (die Informationssicherheit trifft nicht plötzlich auf etwas). . Jedes Team ist auch für die ultimative Sicherheit verantwortlich und nicht einige abstrakte ältere Brüder.

1. Da externe Mitarbeiter bereits Zugriff auf den Code und eine Reihe interner Systeme haben, ist es wahrscheinlich möglich, die Anforderung „Die Entwicklung muss vollständig auf der Infrastruktur der Bank erfolgen“ aus den Dokumenten zu streichen.
2. Andererseits müssen wir die Kontrolle über das Geschehen stärken.
3. Der Kompromiss bestand in der Schaffung funktionsübergreifender Teams, in denen Mitarbeiter eng mit externen Personen zusammenarbeiten. In diesem Fall müssen Sie sicherstellen, dass das Team mit Tools auf den Servern der Bank arbeitet. Vom Anfang bis zum Ende.

Das heißt, Auftragnehmer können zugelassen werden, ihnen müssen jedoch separate Segmente zugewiesen werden. Damit sie nicht irgendeine Infektion von außen in die Infrastruktur der Bank einschleusen und nicht mehr als das Notwendige sehen. Nun, damit ihre Aktionen protokolliert werden. DLP zum Schutz vor Undichtigkeiten, das alles war inklusive.

Im Prinzip kommen alle Banken früher oder später dazu. Hier sind wir den ausgetretenen Pfaden gefolgt und haben uns auf die Anforderungen für solche Umgebungen geeinigt, in denen „Externe“ arbeiten. Es erschien ein breites Spektrum an Zugriffskontrolltools, Schwachstellenprüfungstools, Antivirenanalysen für Schaltkreise, Baugruppen und Tests. Dies wird DevSecOps genannt.

Plötzlich wurde klar, dass, wenn die Banksicherheit vor DevSecOps keine Kontrolle darüber hatte, was auf Entwicklerseite passiert, Sicherheit im neuen Paradigma auf die gleiche Weise kontrolliert wird wie normale Ereignisse in der Infrastruktur. Erst jetzt gibt es Warnungen zu Baugruppen, zur Kontrolle von Bibliotheken usw.

Bleibt nur noch die Umstellung der Teams auf das neue Modell. Nun, schaffen Sie die Infrastruktur. Aber das sind Kleinigkeiten, es ist, als würde man eine Eule zeichnen. Tatsächlich haben wir bei der Infrastruktur geholfen, und zu dieser Zeit veränderten sich die Entwicklungsprozesse.

Was hat sich verändert

Wir haben uns für die Umsetzung in kleinen Schritten entschieden, weil uns klar war, dass viele Prozesse auseinanderfallen würden und viele „Fremde“ den neuen Arbeitsbedingungen unter der Aufsicht aller möglicherweise nicht standhalten würden.

Zunächst haben wir funktionsübergreifende Teams gebildet und gelernt, Projekte unter Berücksichtigung neuer Anforderungen zu organisieren. Im organisatorischen Sinne haben wir besprochen, welche Prozesse ablaufen. Das Ergebnis war ein Diagramm der Montagepipeline mit allen Verantwortlichen.

• CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• Test: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
• Präsentation (Berichterstattung, Kommunikation): Grafana, Kibana, Jira, Confluence, RocketChat.
• Einkauf & Prozesse (Wartung, Verwaltung): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Ausgewählter Stapel:

• Wissensdatenbank – Atlassian Confluence;
• Aufgabenverfolgung – Atlassian Jira;
• Artefakt-Repository – „Nexus“;
• Kontinuierliches Integrationssystem – „Gitlab CI“;
• Kontinuierliches Analysesystem – „SonarQube“;
• System zur Analyse der Anwendungssicherheit – „Micro Focus Fortify“;
• Kommunikationssystem – „GitLab Mattermost“;
• Konfigurationsmanagementsystem – „Ansible“;
• Überwachungssystem – „ELK“, „TICK Stack“ („InfluxData“).

Sie begannen, ein Team zusammenzustellen, das bereit war, Auftragnehmer hineinzuziehen. Es besteht die Erkenntnis, dass es mehrere wichtige Dinge gibt:

• Zumindest bei der Übertragung von Code sollte alles einheitlich sein. Denn es gab so viele Auftragnehmer, wie es so viele unterschiedliche Entwicklungsprozesse mit ihren eigenen Besonderheiten gab. Es war notwendig, alle in etwa eins unterzubringen, aber mit Optionen.
• Es gibt viele Auftragnehmer und die manuelle Erstellung der Infrastruktur ist nicht geeignet. Jede neue Aufgabe sollte sehr schnell beginnen – das heißt, die Instanz sollte fast sofort bereitgestellt werden, damit Entwickler über eine Reihe von Lösungen zur Verwaltung ihrer Pipeline verfügen.

Um den ersten Schritt zu tun, war es notwendig zu verstehen, was getan wurde. Und wir mussten herausfinden, wie wir dorthin gelangen. Wir begannen damit, dass wir dabei halfen, die Architektur der Ziellösung sowohl in der Infrastruktur als auch in der CI/CD-Automatisierung zu zeichnen. Dann begannen wir mit der Montage dieses Förderers. Wir brauchten eine Infrastruktur, die für alle gleich war und in der die gleichen Förderbänder laufen würden. Wir haben Optionen mit Berechnungen angeboten, dachte die Bank, und dann entschieden sie, was gebaut werden sollte und mit welchen Mitteln.

Als nächstes erfolgt die Erstellung der Schaltung – Installation der Software, Konfiguration. Entwicklung von Skripten für die Bereitstellung und Verwaltung der Infrastruktur. Als nächstes folgt der Übergang zur Förderbandunterstützung.

Wir haben beschlossen, alles am Piloten zu testen. Interessanterweise erschien während der Pilotphase zum ersten Mal ein bestimmter Stapel in der Bank. Unter anderem wurde für den Rahmen des Pilotprojekts ein inländischer Anbieter einer der Lösungen für eine zügige Markteinführung angeboten. Der Sicherheitsdienst lernte ihn als Pilot kennen und es hinterließ einen unvergesslichen Eindruck. Als wir uns für einen Wechsel entschieden, wurde die Infrastrukturschicht glücklicherweise durch eine Nutanix-Lösung ersetzt, die bereits zuvor in der Bank vorhanden war. Darüber hinaus war es vorher für VDI gedacht, aber wir haben es für Infrastrukturdienste wiederverwendet. Bei kleinen Mengen passte es nicht in die Wirtschaft, aber bei großen Mengen wurde es zu einem hervorragenden Umfeld für Entwicklung und Tests.

Der Rest des Stapels ist mehr oder weniger jedem bekannt. Zum Einsatz kamen Automatisierungstools in Ansible, mit denen Sicherheitsspezialisten eng zusammenarbeiteten. Der Atlassin-Stack wurde von der Bank vor dem Projekt verwendet. Fortinet-Sicherheitstools – sie wurden von den Sicherheitsleuten selbst vorgeschlagen. Der Testrahmen wurde von der Bank erstellt, es wurden keine Fragen gestellt. Das Repository-System warf Fragen auf, ich musste mich daran gewöhnen.

Die Auftragnehmer erhielten einen neuen Stapel. Sie gaben uns Zeit, es für GitlabCI neu zu schreiben, Jira in das Banking-Segment zu migrieren und so weiter.

Schritt für Schritt

Schritt 1. Zuerst nutzten wir eine Lösung eines inländischen Anbieters, das Produkt wurde an ein neu geschaffenes DSO-Netzwerksegment angeschlossen. Die Plattform wurde aufgrund ihrer Lieferzeit, Skalierungsflexibilität und der Möglichkeit einer vollständigen Automatisierung ausgewählt. Durchgeführte Tests:

• Möglichkeit der flexiblen und vollautomatischen Verwaltung der Infrastruktur der Virtualisierungsplattform (Netzwerk, Festplatten-Subsystem, Rechenressourcen-Subsystem).
• Automatisierung des Lebenszyklusmanagements virtueller Maschinen (Vorlagen, Snapshots, Backups).

Nach der Installation und Grundkonfiguration der Plattform diente sie als Platzierungspunkt für die Subsysteme der zweiten Stufe (DSO-Tools, Entwicklungsskizzen für Einzelhandelssysteme). Die notwendigen Pipeline-Sets wurden erstellt – Erstellung, Löschung, Änderung, Sicherung virtueller Maschinen. Diese Pipelines wurden als erste Stufe des Bereitstellungsprozesses verwendet.

Die Folge ist, dass die bereitgestellten Geräte nicht den Anforderungen der Bank an Leistung und Fehlertoleranz entsprechen. Das DIT der Bank beschloss, einen Komplex auf Basis des Nutanix-Softwarepakets zu erstellen.

Stufe 2. Wir haben den definierten Stack genommen und automatisierte Installations- und Nachkonfigurationsskripte für alle Subsysteme geschrieben, damit alles so schnell wie möglich vom Pilot- auf den Zielschaltkreis übertragen werden konnte. Alle Systeme wurden in einer fehlertoleranten Konfiguration bereitgestellt (wobei diese Fähigkeit nicht durch die Lizenzrichtlinien des Anbieters eingeschränkt ist) und mit Metriken und Subsystemen zur Ereigniserfassung verbunden. IB analysierte die Einhaltung seiner Anforderungen und gab grünes Licht.

Stufe 3. Migration aller Subsysteme und ihrer Einstellungen auf das neue PAC. Skripte zur Infrastrukturautomatisierung wurden neu geschrieben und die Migration der DSO-Subsysteme wurde in einem vollständig automatisierten Modus abgeschlossen. Die Konturen der IP-Entwicklung wurden durch die Pipelines der Entwicklungsteams nachgebildet.

Schritt 4. Automatisierung der Installation von Anwendungssoftware. Diese Aufgaben wurden von den Teamleitern der neuen Teams gestellt.

Schritt 5. Ausbeutung.

Fernzugriff

Die Entwicklungsteams forderten maximale Flexibilität bei der Arbeit mit der Schaltung und die Anforderung eines Fernzugriffs von persönlichen Laptops aus wurde gleich zu Beginn des Projekts erhoben. Die Bank verfügte bereits über einen Fernzugriff, der jedoch für Entwickler nicht geeignet war. Tatsache ist, dass das Schema die Verbindung des Benutzers zu einem geschützten VDI nutzte. Dies war für diejenigen geeignet, die an ihrem Arbeitsplatz nur Post und ein Büropaket benötigten. Entwickler würden umfangreiche Clients mit hoher Leistung und vielen Ressourcen benötigen. Und natürlich mussten sie statisch sein, da der Verlust der Benutzersitzung für diejenigen, die beispielsweise mit VStudio oder einem anderen SDK arbeiten, inakzeptabel ist. Durch die Organisation einer großen Anzahl dicker statischer VDIs für alle Entwicklungsteams stiegen die Kosten der bestehenden VDI-Lösung erheblich.

Wir haben uns entschieden, an einem Fernzugriff direkt auf die Ressourcen des Entwicklungssegments zu arbeiten. Jira, Wiki, Gitlab, Nexus, Build- und Prüfstände, virtuelle Infrastruktur. Sicherheitskräfte haben gefordert, dass der Zutritt nur unter folgenden Voraussetzungen gewährt werden darf:

1. Nutzung bereits in der Bank vorhandener Technologien.
2. Die Infrastruktur sollte keine vorhandenen Domänencontroller verwenden, die Datensätze produktiver Kontoobjekte speichern.
3. Der Zugriff sollte nur auf die Ressourcen beschränkt sein, die von einem bestimmten Team benötigt werden (damit ein Produktteam nicht auf die Ressourcen eines anderen Teams zugreifen kann).
4. Maximale Kontrolle über RBAC in Systemen.

Daher wurde für dieses Segment eine eigene Domain erstellt. In dieser Domäne waren alle Ressourcen des Entwicklungssegments untergebracht, sowohl Benutzeranmeldeinformationen als auch Infrastruktur. Der Lebenszyklus der Datensätze in dieser Domäne wird mithilfe des in der Bank vorhandenen IdM verwaltet.

Der direkte Fernzugriff wurde auf Basis der vorhandenen Ausstattung der Bank organisiert. Die Zugriffskontrolle wurde in AD-Gruppen unterteilt, denen kontextbezogene Regeln entsprachen (eine Produktgruppe = eine Regelgruppe).

VM-Vorlagenverwaltung

Die Geschwindigkeit beim Erstellen einer Montage- und Testschleife ist einer der wichtigsten KPIs, die vom Leiter der Entwicklungseinheit festgelegt werden, da sich die Geschwindigkeit bei der Vorbereitung der Umgebung direkt auf die Gesamtausführungszeit der Pipeline auswirkt. Es wurden zwei Optionen zur Vorbereitung von Basis-VM-Images in Betracht gezogen. Das erste sind die minimalen Bildgrößen, Standard für alle Systemprodukte, maximale Einhaltung der Richtlinien der Bank bezüglich der Einstellungen. Das zweite ist das Basis-Image, das ein leistungsstarkes POPPO installiert enthält, dessen Installationszeit die Ausführungsgeschwindigkeit der Pipeline stark beeinflussen könnte.

Auch Infrastruktur- und Sicherheitsanforderungen wurden bei der Entwicklung berücksichtigt – Aktualisierung der Bilder (Patches etc.), Integration mit SIEM, Sicherheitseinstellungen nach Bankstandards.

Aus diesem Grund wurde beschlossen, möglichst wenige Bilder zu verwenden, um die Kosten für deren Aktualisierung zu minimieren. Es ist viel einfacher, das Basisbetriebssystem zu aktualisieren, als jedes Image für neue Versionen von POPPO zu patchen.

Basierend auf den Ergebnissen wurde eine Liste der mindestens erforderlichen Betriebssysteme erstellt, deren Aktualisierung vom Betriebsteam durchgeführt wird, und Skripte aus der Pipeline sind vollständig für die Aktualisierung der Software und gegebenenfalls für die Änderung der Version verantwortlich der installierten Software - übertragen Sie einfach das erforderliche Tag in die Pipeline. Ja, das erfordert, dass das DevOps-Produktteam komplexere Bereitstellungsszenarien hat, aber es reduziert die Betriebszeit, die für die Unterstützung von Basis-Images erforderlich ist, die andernfalls mehr als hundert Basis-VM-Images erfordern könnten, erheblich.

Internetzugang

Ein weiterer Stolperstein bei der Banksicherheit war der Zugriff auf Internetressourcen aus der Entwicklungsumgebung. Darüber hinaus kann dieser Zugriff in zwei Kategorien unterteilt werden:

1. Zugang zur Infrastruktur.
2. Entwicklerzugriff.

Der Infrastrukturzugriff wurde durch Proxying externer Repositories mit Nexus organisiert. Das heißt, ein direkter Zugriff von virtuellen Maschinen war nicht vorgesehen. Dadurch konnte ein Kompromiss bei der Informationssicherheit erzielt werden, der sich kategorisch gegen die Gewährung jeglichen Zugangs zur Außenwelt aus dem Entwicklungsbereich aussprach.

Entwickler benötigten aus offensichtlichen Gründen Zugang zum Internet (Stackoverflow). Und obwohl alle Befehle, wie oben erwähnt, Fernzugriff auf die Schaltung hatten, ist es nicht immer praktisch, wenn Sie Strg+V nicht vom Entwicklerarbeitsplatz in der Bank in der IDE aus ausführen können.

Mit IS wurde vereinbart, dass zunächst in der Testphase der Zugriff über einen Bank-Proxy auf Basis einer Whitelist erfolgen soll. Nach Abschluss des Projekts wird der Zugriff auf die schwarze Liste übertragen. Es wurden umfangreiche Zugriffstabellen erstellt, die die wichtigsten Ressourcen und Repositories aufzeigten, auf die zu Beginn des Projekts Zugriff erforderlich war. Die Koordinierung dieser Zugriffe nahm einen erheblichen Zeitaufwand in Anspruch, so dass auf einen schnellstmöglichen Übergang zu Sperrlisten gedrängt werden konnte.

Ergebnisse

Das Projekt endete vor etwas weniger als einem Jahr. Seltsamerweise stellten alle Auftragnehmer pünktlich auf den neuen Stapel um und aufgrund der neuen Automatisierung verließ niemand das Unternehmen. IB hat es nicht eilig, positives Feedback zu geben, beschwert sich aber auch nicht, woraus wir schließen können, dass es ihnen gefällt. Konflikte haben nachgelassen, weil sich die Informationssicherheit wieder unter Kontrolle fühlt, aber nicht in Entwicklungsprozesse eingreift. Den Teams wurde mehr Verantwortung übertragen und die allgemeine Einstellung zur Informationssicherheit wurde besser. Die Bank verstand, dass der Übergang zu DevSecOps nahezu unvermeidlich war, und hat ihn meiner Meinung nach auf die sanfteste und korrekteste Weise durchgeführt.

Alexander Shubin, Systemarchitekt.

Source: habr.com