🌇 🙋🏼 😵 DevOps vs DevSecOps: wie es in einer Bank aussah 🏅 🧝🏾 👌🏼

Die Bank lagert ihre Projekte an viele Auftragnehmer aus. "Außenseiter" schreiben den Code und übertragen die Ergebnisse in einer nicht sehr bequemen Form. Im Einzelnen sah der Prozess folgendermaßen aus: Sie haben ein Projekt übertragen, das Funktionstests von ihnen bestanden hat, und wurden dann bereits innerhalb des Bankbereichs auf Integration, Auslastung usw. getestet. Oft wurde festgestellt, dass Tests feyl waren. Dann ging alles zurück zum externen Entwickler. Wie Sie sich vorstellen können, bedeutete dies eine lange Zeit, um Fehler zu beheben.

Die Bank entschied, dass es möglich und notwendig ist, die gesamte Pipeline von den Commits bis zur Freigabe „unter die Fittiche“ zu ziehen. Damit alles konsistent ist und unter der Kontrolle der für das Produkt verantwortlichen Teams in der Bank steht. Das heißt, als ob der externe Auftragnehmer einfach irgendwo im nächsten Raum des Büros gearbeitet hätte. Auf dem Firmenstapel. Dies ist ein normaler Devop.

Woher kam Sec? Die Bankensicherheit hat hohe Anforderungen an die Arbeitsweise eines externen Auftragnehmers im Netzwerksegment gestellt, wer Zugriff 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 hier muss in ein paar Tagen jeder anfangen, sie zu beobachten.

Eine einfache Entdeckung, dass der Auftragnehmer uneingeschränkten Zugriff auf den Produktcode hat, hat seine Welt bereits auf den Kopf gestellt.

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

Welche Bank hat aus dieser Situation praktische Schlussfolgerungen gezogen?

Es gab viele Kontroversen darüber, dass alles in der Sphäre falsch gemacht wird. Die Entwickler sagten, dass Sicherheit nur mit Versuchen beschäftigt ist, die Entwicklung zu behindern, und sie als Wächter versuchen, ohne nachzudenken zu verbieten. Im Gegenzug zögerten Sicherheitspersonal zwischen der Wahl zwischen verschiedenen Gesichtspunkten: "Entwickler schaffen Schwachstellen in unserer Schaltung" und "Entwickler schaffen keine Schwachstellen, aber sie selbst sind es." Die Debatte würde lange dauern, wenn nicht die neuen Marktanforderungen und die Entstehung des DevSecOps-Paradigmas berücksichtigt würden. Es konnte erklärt werden, dass gerade diese Automatisierung von Prozessen unter Berücksichtigung der Anforderungen der Informationssicherheit „out of the box“ dazu beiträgt, dass alle zufrieden sind. In dem Sinne, dass die Regeln sofort geschrieben werden und sich während des Spiels nicht ändern (IS wird etwas nicht unerwartet verbieten) und Entwickler IS über alles, was passiert, auf dem Laufenden halten (IS trifft nicht plötzlich auf etwas).Jedes Team ist für die ultimative Sicherheit verantwortlich und nicht einige abstrakte ältere Brüder.

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

Das heißt, Auftragnehmer können zugelassen werden, aber Sie müssen sie zu getrennten Segmenten machen. Damit sie sich nicht außerhalb einer Infektion in die Infrastruktur der Bank hineinziehen und nicht mehr als nötig sehen. Nun, damit ihre Aktionen protokolliert werden. DLP zum Schutz vor "Senken", all dies wurde angewendet.

Grundsätzlich kommen früher oder später alle Banken dazu. Dann gingen wir abseits der ausgetretenen Pfade und einigten uns auf die Anforderungen für solche Umgebungen, in denen "Außenseiter" arbeiten. Es gab eine maximale Anzahl von Tools zur Zugriffskontrolle, Schwachstellenprüfungen, Antivirenanalysen für Schaltkreise, Assemblys und Tests. Das nannten sie DevSecOps.

Plötzlich wurde klar, dass, bevor diese DevSecOps-Bankensicherheit keine Kontrolle darüber hatte, was auf der Seite des Entwicklers geschah, die Sicherheit im neuen Paradigma genauso gesteuert wird wie normale Ereignisse in der Infrastruktur. Erst jetzt gibt es Warnungen zu Assemblys, zur Bibliothekssteuerung usw.

Es bleibt nur, das Team auf ein neues Modell zu übertragen. Erstellen Sie eine Infrastruktur. Aber das sind kleine Dinge, so zeichnet man eine Eule. Tatsächlich haben wir bei der Infrastruktur geholfen, und zu diesem Zeitpunkt haben sich die Entwicklungsprozesse geändert.

Was hat sich geändert?

Sie beschlossen, es in kleinen Schritten umzusetzen, weil sie erkannten, dass viele Prozesse auseinanderfallen würden und viele „Außenseiter“ möglicherweise nicht in der Lage sind, den neuen Arbeitsbedingungen unter der Aufsicht aller zu widerstehen.

Zunächst haben wir funktionsübergreifende Teams gebildet und gelernt, Projekte unter Berücksichtigung neuer Anforderungen zu organisieren. In Bezug auf die organisatorische Diskussion, welche Prozesse. Es stellte sich heraus, dass die Montage-Pipeline 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, Selen: MF Fortify, Leistungszentrum, MF UFT, Atascama.
Präsentation (Berichterstattung, Kommunikation): Grafana, Kibana, Jira, Confluence, RocketChat.
Operationen : Ansible, Zabbix, Prometheus, Elastic + Logstash, MF-Servicemanager, Jira, Confluence, MS-Projekt.

Stapel ausgewählt:

Wissensdatenbank - Atlassian Confluence;
Task Tracker - Atlassian Jira;
Aufbewahrungsort für Artefakte - "Nexus";
Kontinuierliches Integrationssystem - „Gitlab CI“;
Kontinuierliches Analysesystem - „SonarQube“;
Anwendungssicherheits-Analysesystem - „Micro Focus Fortify“;
Kommunikationssystem - "GitLab Mattermost";
Konfigurationsmanagementsystem - "Ansible";
Überwachungssystem - "ELK", "TICK Stack" ("InfluxData").

Sie begannen, ein Team zusammenzustellen, das bereit war, Auftragnehmer einzubeziehen. Die Erkenntnis ist gekommen, dass es mehrere wichtige Dinge gibt:

. — . , .
, . — , .

Um den ersten Schritt zu machen, musste man verstehen, was getan wurde. Und wir mussten bestimmen, wie wir vorgehen sollten. Wir haben zunächst dazu beigetragen, die Architektur der Ziellösung sowohl in der Infrastruktur als auch in der CI / CD-Automatisierung zu zeichnen. Dann fingen wir an, diesen Förderer zusammenzubauen. Wir brauchten eine Infrastruktur, die für alle gleich war und auf der dieselben Förderer betrieben wurden. Wir haben Optionen mit Abrechnungen angeboten, dachte die Bank, und dann entschieden, was und auf welche Weise es gebaut wird.

Weitere Erstellung der Schaltung - Installation, Konfiguration der Software. Entwicklung von Skripten für die Bereitstellungsinfrastruktur und -verwaltung. Als nächstes folgt der Übergang zur Pipeline-Unterstützung.

Wir haben beschlossen, alles auf dem Piloten laufen zu lassen. Interessanterweise erschien während der Pilotierung zum ersten Mal ein bestimmter Stapel in der Bank. Für das Volumen des Piloten wurde unter anderem ein inländischer Anbieter einer der Lösungen für einen frühen Start vorgeschlagen. Die Sicherheit lernte ihn während des Pilotierens kennen und dies hinterließ ein unvergessliches Erlebnis. Als sie sich für einen Wechsel entschieden, wurde glücklicherweise die Infrastrukturschicht durch eine Nutanix-Lösung ersetzt, die bereits zuvor in der Bank war. Davor war es für VDI und 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 jedem mehr oder weniger vertraut. Es wurden Automatisierungstools im Ansible-Teil verwendet, mit denen Sicherheitspersonal eng zusammenarbeitete. Der Atlassinovsky-Stapel wurde vor dem Projekt von der Bank verwendet. Fortinet-Sicherheitstools - Dies wurde von den Sicherheitskräften selbst vorgeschlagen. Der Testrahmen wurde von der Bank erstellt, ohne dass Fragen gestellt wurden. Fragen wurden vom Repository-System verursacht, ich musste mich daran gewöhnen.

Die Auftragnehmer erhielten einen neuen Stapel. Sie gaben Zeit, um unter GitlabCI neu zu schreiben und Jira in das Banksegment zu migrieren und so weiter.

Schritt für Schritt

Stufe 1. Zuerst verwendeten wir die Lösung eines inländischen Anbieters, das Produkt wurde auf das neu geschaffene DSO-Netzwerksegment umgestellt. Die Plattform wurde aufgrund ihrer Lieferzeiten, Skalierbarkeit und vollständigen Automatisierungsfunktionen ausgewählt. Durchgeführte Tests:

Möglichkeit einer flexiblen und vollautomatisierten Verwaltung der Infrastruktur der Virtualisierungsplattform (Netzwerk, Festplattensubsystem, Rechenressourcensubsystem).
Automatisierung des Lebenszyklusmanagements virtueller Maschinen (Vorlagen, Snapshots, Backups).

Nach der Installation und Grundkonfiguration der Plattform wurde sie als Platzierungspunkt für die Subsysteme der zweiten Stufe (DSO-Tools, Umrisse der Entwicklung von Einzelhandelssystemen) verwendet. Die erforderlichen Pipelines wurden erstellt - Erstellen, Löschen, Ändern und Sichern von virtuellen Maschinen. Diese Pipelines wurden als erste Phase des Bereitstellungsprozesses verwendet.

Ergebnis - Die bereitgestellte Ausrüstung entspricht nicht den Anforderungen der Bank an Leistung und Fehlertoleranz. Die DIT Bank hat beschlossen, einen Komplex auf Basis von PAC Nutanix zu schaffen.

Stufe 2. Wir haben den definierten Stack verwendet und Skripte für die automatisierte Installation und Nachkonfiguration aller Subsysteme geschrieben, damit alles so schnell wie möglich vom Piloten auf die Zielschaltung übertragen wird. Alle Systeme wurden in einer fehlertoleranten Konfiguration bereitgestellt (wobei diese Funktion nicht auf die lizenzierten Richtlinien des Anbieters beschränkt ist) und sind mit den Subsystemen verbunden, um Metriken und Ereignisse zu erfassen. IB analysierte die Einhaltung seiner Anforderungen und gab grünes Licht.

Stufe 3 . Migration aller Subsysteme und ihrer Einstellungen in das neue PAC. Die Skripts für die Infrastrukturautomatisierung wurden neu geschrieben, und die Migration des DSO-Subsystems wurde in einem vollautomatisierten Modus durchgeführt. Die IS-Entwicklungspfade wurden durch Pipelines des Entwicklungsteams neu erstellt.

Stufe 4. Automatisierung der Installation der Anwendungssoftware. Diese Aufgaben wurden von Teamleitern neuer Teams festgelegt.

Stufe 5. Betrieb.

Fernzugriff

Entwicklungsteams forderten maximale Flexibilität bei der Arbeit mit der Schaltung, und die Anforderung für den Fernzugriff von persönlichen Laptops wurde zu Beginn des Projekts gestellt. Die Bank hatte bereits Fernzugriff, war aber nicht für Entwickler geeignet. Tatsache ist, dass das Schema eine Benutzerverbindung zu einem sicheren VDI verwendete. Dies war für diejenigen geeignet, die am Arbeitsplatz genügend Post und ein Büropaket hatten. Entwickler würden starke Kunden mit hoher Leistung und vielen Ressourcen benötigen. Und natürlich mussten sie statisch sein, da der Verlust einer Benutzersitzung für diejenigen, die beispielsweise mit VStudio oder einem anderen SDK arbeiten, nicht akzeptabel ist. Die Organisation einer großen Anzahl dicker statischer VDIs für alle Entwicklungsteams erhöhte die Kosten der vorhandenen VDI-Lösung erheblich.

Wir haben uns entschlossen, den Fernzugriff direkt auf die Ressourcen des Entwicklungssegments zu erarbeiten. Jira, Wiki, Gitlab, Nexus, Montage- und Prüfstände, virtuelle Infrastruktur. Sicherheitspersonal hat Anforderungen festgelegt, dass der Zugriff nur unter folgenden Bedingungen organisiert werden kann:

Nutzung der bereits in der Bank verfügbaren Technologien.
Die Infrastruktur sollte keine vorhandenen Domänencontroller verwenden, in denen Datensätze produktiver Konten / Objekte gespeichert sind.
Der Zugriff sollte nur auf die Ressourcen beschränkt sein, die von einem bestimmten Team benötigt werden (damit ein Team eines Produkts nicht auf die Ressourcen eines anderen Teams zugreifen kann).
Maximale Kontrolle über RBAC in Systemen.

Infolgedessen wurde für dieses Segment eine separate Domäne erstellt. Diese Domäne enthielt alle Ressourcen des Entwicklungssegments, sowohl Benutzeranmeldeinformationen als auch Infrastruktur. Der Lebenszyklus von Datensätzen in dieser Domäne wird mithilfe des in der Bank vorhandenen IdM verwaltet.

Der direkte Fernzugriff wurde auf der Grundlage der vorhandenen Bankausrüstung organisiert. Die Zugriffskontrolle wurde in AD-Gruppen unterteilt, die den Regeln in den Kontexten entsprachen (eine Produktgruppe = eine Regelgruppe).

VM-Vorlagen verwalten

Die Geschwindigkeit beim Erstellen der Montage- und Testschaltung ist einer der wichtigsten KPIs, die vom Leiter der Entwicklungseinheit festgelegt werden, da sich die Geschwindigkeit der Vorbereitung der Umgebung direkt auf die Gesamtausführungszeit der Pipeline auswirkt. Zwei Optionen zum Vorbereiten grundlegender VM-Images wurden in Betracht gezogen. Die erste ist die minimale Bildgröße, Standard für alle Produkte / Systeme, die maximale Einhaltung der Bankrichtlinien für die Einstellungen. Das zweite ist ein Basis-Image, das die installierte Schwergewichts-Software / Software enthält, deren Installationszeit die Geschwindigkeit der Pipeline stark beeinflussen kann.

Bei der Entwicklung wurden auch Infrastruktur- und Sicherheitsanforderungen berücksichtigt - Aktualisierung der Images (Patches usw.), Integration in SIEM, Sicherheitseinstellungen gemäß den von der Bank festgelegten Standards.

Infolgedessen wurde beschlossen, nur minimale Bilder zu verwenden, um die Kosten für die Aktualisierung zu minimieren. Es ist viel einfacher, das Basisbetriebssystem zu aktualisieren, als Patches in jedem Image für neue Versionen von Software / Software zu installieren.

Basierend auf den Ergebnissen wurde eine Liste aus den mindestens erforderlichen Betriebssystemen erstellt, deren Aktualisierung vom Betriebsteam durchgeführt wird. Die Skripte aus der Pipeline sind vollständig für die Aktualisierung der Software / Software verantwortlich. Falls erforderlich, reicht es aus, die Version der installierten Software zu ändern, um das gewünschte Tag in die Pipeline zu übertragen. Ja, dies erfordert komplexere Bereitstellungsszenarien von devops 'einem Produktteam, verkürzt jedoch die Betriebszeit für die Unterstützung von Basisimages erheblich, was zu mehr als hundert grundlegenden VM-Images führen kann.

Zugang zum Internet

Ein weiteres Hindernis für die Bankensicherheit war der Zugriff von der Entwicklungsumgebung auf Internetressourcen. Darüber hinaus kann dieser Zugang in zwei Kategorien unterteilt werden:

Zugang zur Infrastruktur.
Zugang zu Entwicklern.

Der Zugriff auf die Infrastruktur wurde durch Proxysignation externer Repositorys durch Nexus organisiert. Das heißt, ein direkter Zugriff von virtuellen Maschinen wurde nicht bereitgestellt. Dies ermöglichte es, Kompromisse mit dem IS einzugehen, was kategorisch gegen einen Zugang des Entwicklungssegments zur Außenwelt war.

Aus offensichtlichen Gründen war ein Internetzugang für Entwickler erforderlich (Stackoverflow). Und obwohl alle Teams, wie oben erwähnt, Fernzugriff auf die Schaltung hatten, ist es nicht immer praktisch, wenn Sie nicht vom Arbeitsplatz des Entwicklers in der Bank in der IDE aus Strg + V ausführen können.

Mit IS wurde vereinbart, dass der Zugang zunächst in der Testphase über einen Bank-Proxy auf der Grundlage einer weißen Liste erfolgt. Am Ende des Projekts wird der Zugriff auf die schwarze Liste übertragen. Es wurden umfangreiche Zugriffstabellen erstellt, in denen die wichtigsten Ressourcen und Repositorys aufgeführt waren, auf die zu Beginn des Projekts zugegriffen werden musste. Die Koordination dieser Zugriffe nahm eine angemessene Zeit in Anspruch, so dass wir auf dem schnellsten Übergang zu schwarzen Listen bestehen konnten.

Ergebnisse

Das Projekt endete vor etwas weniger als einem Jahr. Seltsamerweise, aber alle Auftragnehmer wechselten pünktlich zum neuen Stack und niemand ging wegen der neuen Automatisierung. IB hat es nicht eilig, positive Bewertungen zu teilen, aber er beschwert sich nicht, woraus wir schließen können, dass sie gefallen. Konflikte ließen nach, weil IS sich wieder kontrolliert fühlt, aber gleichzeitig die Entwicklungsprozesse nicht stört. Die Teams haben mehr Verantwortung übernommen, und im Allgemeinen ist die Einstellung zur Informationssicherheit besser geworden. Die Bank verstand, dass der Übergang zu DevSecOps fast unvermeidlich war, und meiner Meinung nach tat er dies am sanftesten und korrektesten.

Alexander Shubin, Systemarchitekt.

DevOps vs DevSecOps: wie es in einer Bank aussah