Refactoring der Bank-IT-Infrastruktur und wie wir Freunde des IT-Teams mit dem IB-Team waren



    Eine Bank, die russische Niederlassung einer großen europäischen Bankengruppe, hat es sich zur Aufgabe gemacht, das Netzwerk zu segmentieren . Die Server befanden sich in unseren Rechenzentren. Zum Zeitpunkt des Arbeitsbeginns verfügte der Kunde über eine separate Infrastruktur für die eigentlichen Finanzvorgänge und ein großes Peer-to-Peer-Netzwerk von Benutzern, die für einige große Knoten und viele Niederlassungen physisch voneinander getrennt waren. Der erste arbeitete wie eine Uhr, und der zweite hatte Schwierigkeiten. Darüber hinaus hat die interne Umstrukturierung unter den Anforderungen von 152-Euro für personenbezogene Daten gerade erst begonnen.

    Um zu verstehen, wie ein neues Netzwerk besser organisiert werden kann, haben wir den Abgleich von IP-Adressen und Diensten auf diesen angefordert. Genauer gesagt brauchten wir am Ende eine Karte, auf der stand, was und wohin der Verkehr fuhr, damit klar war, was zu gestatten und was zu verbieten ist.

    Zu diesem Zeitpunkt sagte der IS, dass sie solche Dokumente nicht einreichen könnten. Und sie schlugen vor, selbst eine Verkehrskarte zu erstellen, weil sie sich erstens selbst für das wirkliche Bild des Netzwerkgeschehens interessieren und zweitens die Beschreibung des Verkehrs und der Anwendungen im Netzwerk bislang nur in ihren Plänen enthalten ist. Einfach ausgedrückt, war unser Auftritt für sie eine hervorragende Gelegenheit, das Bild des Datenverkehrs im Netzwerk zu aktualisieren - es scheint, dass die IT häufig eine Verbindung hergestellt und vergessen hat, IS darüber zu informieren.

    Also haben wir begonnen, den gesamten Netzwerkverkehr zu analysieren.

    Die erste Stufe: "Freund oder Feind"


    Wir haben die Ausrüstung mitgebracht, um sicherzustellen, dass der "gute" Verkehr vom "linken" Verkehr etwas früher abgeschnitten und im Spiegelmodus verbunden wurde. Dies ist eine Standardfunktion, mit der Sie im Voraus für eine vollständige Kopie des Datenverkehrs feststellen können, ob die Einstellungen ordnungsgemäß funktionieren. In diesem Modus können Sie sehen, was abgeschnitten ist und was nicht. In unserem Fall war es zwar nicht erforderlich, die Anwendungen zu identifizieren, Statistiken zu erfassen und Transaktionen zu kennzeichnen.

    Wir haben uns auf die Implementierung in dem Moment geeinigt, in dem 95% des Verkehrs in zwei Wochen unter die Regeln fallen. Der Rest (in der Regel kleine einmalige Transaktionen von mehreren Kilobyte) wurde zu Tausenden gemessen, und die Eingabe war schwierig. Man konnte sein ganzes Leben damit verbringen, diesen Verkehr zu studieren: Er verhielt sich wie ein unendlicher, nicht periodischer Bruchteil - er veränderte sich ständig. Es wurde davon ausgegangen, dass, wenn mit diesen kleinen Dingen etwas schief geht (ich erinnere mich an das Benutzersubnetz), nur eine neue Regel für die Firewall benötigt wird. Der gesamte beschriebene Datenverkehr wurde zu den Berechtigungen für die Firewall hinzugefügt. Wenn etwas Neues auftaucht, wird es standardmäßig abgeschnitten und dem IT-Team und den Spezialisten für Informationssicherheit zur Analyse angeboten.

    Sie fingen an, Informationen zu sammeln - wer geht wohin und nach welchen Protokollen. Nach den Ergebnissen der ersten Woche hatten wir eine Tabelle mit IP-Adressen und dem Verkehrsaufkommen. Im Allgemeinen haben wir begonnen, typische Verbindungen zu überwachen, um ein vollständiges Netzwerkprofil zu erstellen. Jede Verbindung, die wir als das Verhalten einer Anwendung definiert haben, wurde dann (auf unsere Anfrage) vom IT-Team als bekannter Dienst bezeichnet. In 99% der Fälle - erfolgreich und richtig.

    Im Zoo gab es viele Überraschungen. Noch wichtiger ist, dass sich selbst große Verkehrsmengen nicht periodisch verhielten und sich einige Dienste bei weitem nicht sofort zeigten. Erst nach 4 Wochen erreichten wir nach den Ergebnissen der Woche 95% in der Tabelle und nach drei Monaten erreichten wir, dass in den neuen Wochen nichts Unerwartetes passierte.

    Eine Woche lang flitzten ungefähr ein paar Terabit Verkehr durch die Firewall. Die Natur änderte sich ziemlich oft und da der Verkehr bestimmt wurde, waren ständig neue Regelsätze erforderlich. Zum Beispiel hatten wir mehrere Wochen lang keinen Datenverkehr zu einer der Gruppen von IP-Adressen, und dann ging es unerwartet. Es stellte sich heraus, dass es sich um Server mit Videoüberwachungsdaten handelte: Höchstwahrscheinlich war irgendjemand in unserem riesigen Land nervig, und es dauerte mehrere Wochen, bis die Videos von der Zentrale durchgebrochen waren. Dies führte natürlich zu einer ungewohnten Belastung des Netzwerks. Oder es gab eine Filiale, die zum Beispiel alle paar Wochen ihre Akten in Backups ablegte, und deshalb war es für einen einwöchigen Zeitraum möglich, diese wichtige Operation für ihn nicht zu fangen.

    Sicherheitspersonal unterteilt die Dienste in kritische und nicht so priorisierte Risiken.



    Zweite Stufe: wie man teilt


    Das Ergebnis war eine große Matrix, die tatsächlich die Regeln für die Firewall enthielt. Übrigens, wir haben ein sehr praktisches Skript geschrieben, das aus der XLS-Datei für Informationssicherheits- und IT-Teams, nachdem sie unterschrieben hatten, eine Reihe von Regeln für die direkte Implementierung auf der Firewall erstellte. Sie haben ein Plus in die Excel-Tabelle eingefügt - sie haben Verkehr zugelassen, ein Minus eingefügt - wir haben ihn abgeschnitten.

    Als die prognostizierte Betriebsart zur Abdeckung von 95% des Verkehrs mit der tatsächlichen (als Teil einer Spiegelverbindung) übereinstimmte, wurde klar, dass die Arbeiten zur Bestimmung des Verkehrs abgeschlossen waren. Die Sicherheitsbeamten erhielten eine Reihe von Unterlagen darüber, was und wohin sie wollten (und waren anscheinend sehr froh, dass jemand alles für sie erledigt hatte). Der IT-Service war auch sehr froh, dass es möglich war, den Indikator in angemessener Zeit zu erreichen.

    Nun musste das Netzwerk aufgeteilt werden. In solchen Fällen gibt es mehrere grundlegende Ansätze:

    1. Klassisch in der Geografie: Jedes Büro hat ein eigenes Subnetz, sie werden zu regionalen Subnetzen zusammengefasst und gelangen dann in das allgemeine Netzwerk des Unternehmens.
    2. Legacy-Ansatz, es ist "nach dem bestehenden Netzwerkprojekt". Manchmal ist das rational, aber in der Regel bedroht es bei großen Unternehmen das Meer mit Krücken. Tatsache ist, dass sich beispielsweise in der Vergangenheit herausstellen könnte, dass die Stockwerke vom ersten bis zum vierten Büro in Moskau und Petersburg ein Netzwerk und das fünfte Stockwerk und Jekaterinburg ein anderes sind. Und der dritte Stock hat das Recht, den fünften Drucker zu benutzen.
    3. Vereinfachte Segmentierung: Oberteile und alles, was für ein Subnetz wichtig ist, Benutzer für ein anderes.
    4. Atomare Segmentierung bedeutet, dass jeder Untergruppe ein eigenes Subnetz zugewiesen wird. Zum Beispiel sitzen 2-3 Personen in einem Raum, die nur mit der Wartung einer Sache beschäftigt sind - einmal das Subnetz. Ihre Nachbarn sind zwei Subgrids und so weiter. Dies ist in der Tat ein Paradies für Sicherheitspersonal - es ist für sie am bequemsten, Menschen zu kontrollieren, aber die Hölle für diejenigen, die es unterstützen müssen.
    5. Funktionale Segmentierung: Benutzer werden nach ihren Möglichkeiten und Möglichkeiten (unabhängig von der geografischen Lage) zusammengeführt, dh es werden 6 bis 10 Hauptrollen zugewiesen.

    Sie gaben den bisherigen Ansatz und die Geografie fast sofort auf, da das Netzwerk es natürlich ermöglichte, die Adressierung unabhängig von der Stadt so einzustellen, dass die Geräte sich gegenseitig als in der Nähe „sahen“. Die vereinfachte Segmentierung wurde zu vereinfacht. Es blieb funktional (Rolle) und sein kritischer Fall - atomar. Natürlich hat das Sicherheitsteam die maximale Aufteilung in Subnetze gewählt. Wir haben die Erfahrung festgelegt und gezeigt, wie oft die Konfiguration wächst und wie man sie unterstützt. Sie gingen zum Nachdenken und kehrten mit der Erlaubnis zurück, ein Rollensystem zu erstellen.

    Wir rekrutierten eine Personalabteilung, die Personal bereitstellte. Gemeinsam mit IT und IS haben wir die Rollen jedes Mitarbeiters festgelegt, ihm sein Subnetz zugewiesen - und die Regeln für das "große Stück Eisen" erneut ergänzt. Auch hier haben wir uns einige Wochen lang den Spiegelverkehr angesehen, um festzustellen, ob alles korrekt verarbeitet wird.

    Zusätzlich zu den "menschlichen" Rollen hatten wir andere Rollen - zum Beispiel Drucker in der Gruppe "Drucker", Server in der Gruppe "Server" und so weiter. Jede Ressource wurde bisher als kritisch für Geschäftsprozesse eingestuft. Beispielsweise wurden die Dateifreigabe-, DNS- und Radius-Server als normale Server erkannt, und die Server, deren Ausfall beispielsweise die Buchhaltungsabteilung "störte", waren kritisch.

    Stufe drei: Implementierung


    Da wir jedes Mal, wenn wir neue Informationen erhielten, diese einfach mit unserem wunderbaren Skript aus dem "lesbaren" XLS in die Regeln für die Firewall eingegeben haben, hatten wir immer die aktuellste Version der Netzwerkrichtlinien. Die Firewall befand sich immer noch im Spiegelmodus, das heißt, sie leitete den gesamten Datenverkehr leise durch sich selbst, wurde jedoch auf Kopien für uns, IT und IS angezeigt, sodass sie im Kampfmodus abgeschnitten wurde. In dem Moment, in dem alles für jedermann passierte, hat uns das IT-Team ein Fenster für die Arbeit am Wochenende zugewiesen. Warum am Wochenende - damit im Falle einer Überraschung dann eine Pressemitteilung nicht funktioniert.

    Überraschung nicht geschehen, der Wechsel wurde erwartet wie erwartet. Wir haben die Executive-Dokumentation mit den Einstellungen geschrieben und das System in Betrieb genommen.

    Als wir ein wenig zurückkamen, gab es zu diesem Zeitpunkt nur eine kleine Schwierigkeit: Das IT-Team glaubte, dass die Firewall ihr Netzwerkknoten war, und sie steuerte sie. Die Sicherheitsbeamten sahen darin einen Zugangskontrollknoten (so etwas wie ein ACS für Daten) und hielten es für ihr gesamtes Gerät. Glücklicherweise haben wir beide mit den erforderlichen Rollen auf der Hardware konfiguriert: Sicherheitskräfte berühren Netzwerkkonfigurationen nicht und das IT-Team kann keine unerwarteten neuen Berechtigungen für die Informationssicherheit vorschreiben (in solchen Fällen mussten die Sicherheitskräfte eine aktuelle Verkehrskarte erstellen - Viele Dinge wurden "in der heißen Beta" hinter sich gelassen und blieben für immer in der Produktion.

    Der endgültige Zeitplan lautet wie folgt:
    KünstlernameDauerKommentar

    Erstellung eines technischen und kaufmännischen Angebots



    1 Woche



    Es ist sehr schnell für den Integrator.



    Vertragsunterzeichnung



    1 Woche



    Es ist sehr schnell für die Bank.



    Entwicklung von Konstruktionsunterlagen



    1 Monat



    + Zeit für die Abstimmung mit dem Kunden (dies sind 2-3 Wochen), einschließlich der Anpassung von Dokumenten. Hier haben wir gleichzeitig das Netzwerk überwacht, das 4 Wochen dauerte. Änderungen wurden sofort in der Dokumentation festgehalten.



    Installation und Inbetriebnahme von Geräten



    3 Wochen



    Da die Arbeiten an 4 Standorten des Kunden in den vereinbarten „Fenstern“ durchgeführt wurden, hat der Vorgang eine solche Zeit in Anspruch genommen



    Probebetrieb



    3 Monate



    Um die Ziele zu erreichen, musste ein iterativer Prozess zur Festlegung von Regeln für die ITU durchgeführt werden



    Abschlusstests, Inbetriebnahme



    1 Tag



    Schalten



    Endgültige Architektur:



    Das Hauptstück der Hardware ist Palo Alto 3020. Es gibt 6 davon an 4 Standorten. Zwei Teile für große Büros (durch ein Failover-Cluster verbunden), jeweils eines für Rechenzentren (dies sind zwei unserer Rechenzentren, in denen sich die IT-Infrastruktur der Bank befindet). In Rechenzentren werden Firewalls in einem transparenten Modus und nicht in einem Cluster verbunden, da die Architektur von zwei Rechenzentren an sich im Wesentlichen ein großer Cluster ist.

    Referenzen:


    Unser Skriptcode zur Umsetzung von Kundenanforderungen in Netzwerkregeln wurde von unseren Ingenieuren Hand in Hand erstellt - eine coole Sache, die Zeit spart.

    Jetzt auch beliebt: