wie wir unsere Informationssicherheitsdienste nach dem Weggang ausländischer Anbieter gerettet haben / Sudo Null IT News

Der Kampf ist vorbei, das Feuer ist erloschen und es ist nichts mehr übrig,

Und wir leben, und wir haben das Glück, dich zu ärgern.

Agatha Christie, „Wie im Krieg“

m/w "Madagaskar"m/w “Madagaskar”

Für viele russische Unternehmen war der Weggang ausländischer Software- und Hardwareanbieter, gelinde gesagt, ein Schlag in die Magengrube. Dienstleister hatten es doppelt schwer: Sie mussten nicht nur für sich selbst, sondern auch für ihre Kunden eine Sauerstoffmaske mit der nötigen Software bereitstellen. Ein großer Teil unserer Informationssicherheitsdienste basierte auf westlichen Lösungen. Etwas begann mit einem verkürzten Satz von Funktionen zu funktionieren, und etwas wurde aufgrund des Widerrufs von Lizenzen einfach zu einem Ziegelstein. Für eine lange Suche nach einer Alternative blieb keine Zeit, einige Unternehmen wurden bereits angegriffen. Was wir erlebt haben, als ausländische Anbieter begannen, Lizenzen zu widerrufen und den technischen Support einzuschränken, wie sie nach einem Ersatz für sie suchten und was sie taten, als sie ohne Orchestrator blieben – wir werden in diesem Beitrag erzählen.

Es tut weh, aber erträglich

Fast jeder, der diesen Beitrag jetzt liest, ist auf einige der beschriebenen Probleme gestoßen. Der erste und offensichtlichste stand im Zusammenhang mit der Schließung lokaler Niederlassungen ausländischer Anbieter und der Einstellung des vollwertigen technischen Supports. Deshalb haben wir uns entschieden, beim Menschen anzufangen: Wir haben unsere technischen Teams für Entwicklung und Betrieb verstärkt. So haben wir den dringenden Bedarf an externem Know-how abgeschafft und können diese Aufgaben nun in Eigenregie erledigen.

Bei Hardware-Plattformen war es schwieriger. Hier half uns ein architektonischer Ansatz mit mehrfacher Redundanz jeder der Komponenten (im “normalen Leben” können Sie so die Last auf der Plattform verteilen und die Dienste stabiler machen). Darüber hinaus haben wir die Dienste von Anfang an mit einer soliden Versorgung mit Hardware-Ressourcen konzipiert, um ihre hohe Leistung sicherzustellen. Dank dessen können die von uns verwendeten Plattformen drei Jahre lang „autonom leben“.

Auch bei Softwarelizenzen gab es natürlich Schwierigkeiten. Wie bei den Hardwarekapazitäten haben wir Lizenzen mit einer großen Marge gekauft und planen für die Zukunft. Einige Lösungen innerhalb der Plattformen basieren auf einer Right-to-Use-Lizenzierung, d. h. es gibt einfach keine technische Widerrufsmöglichkeit. Also halten wir vorerst an und suchen nach alternativer Software.

Aber Sie können upgraden … Nun, wie können Sie? Auch wenn Sie es über Umwege geschafft haben, das Update herunterzuladen, gibt es wohl kein Vertrauen in neue Versionen. Unter den gegenwärtigen Bedingungen scheint das Entstehen von nicht deklarierten Gelegenheiten in ihnen sehr wahrscheinlich. Daher lohnt es sich jetzt, 100 Mal nachzudenken, bevor Sie dieses oder jenes Update herunterladen. Wenn Sie nur ein Update installieren müssen, führen wir natürlich Funktions- und Belastungstests durch, um die Risiken zu minimieren, aber leider ist es unmöglich, sie vollständig zu eliminieren.

Dann war da noch die Eisenfrage. Wie werden Ersatzgeräte (Ersatzteile) beschafft und Rechen- und Netzwerkkapazitäten erweitert? Hier gibt es nur wenige Möglichkeiten: Suchen Sie nach alternativen Ansätzen zum Aufbau von Lieferketten oder erarbeiten Sie Ersatz für Server- und Netzwerkgeräte. Bisher spart der vorhandene Sicherheitsspielraum: Eine große Ausrüstungsressource ermöglicht den Austausch jeder Komponente für etwa drei Jahre.

Wie genau war es

Sehen wir uns nun konkrete Beispiele an. Zwei unserer Dienste basierten auf amerikanischen Fortinet-Lösungen: FortiMail wurde für den E-Mail-Schutz (SEG) und FortiGate für den Schutz vor Netzwerkbedrohungen (UTM) verwendet. Anfang März entzog das Unternehmen umgehend seine Lizenzen, obwohl es bis zuletzt behauptete, es wolle den russischen Markt nicht verlassen.

UTM wurde zu einem Ziegelstein

Der Dienst zum Schutz vor Netzwerkbedrohungen verwandelte sich aufgrund von Lizenzierungsfunktionen sofort in einen Kürbis (einer der wenigen, der nicht nach dem Right-to-Use-Prinzip implementiert wurde). Wir haben mit dem Anbieter gemäß dem für MSS-Anbieter vorgesehenen Schema – Cloud-Lizenzierung – zusammengearbeitet. An diese Lizenz wurden Punkte zur Nutzung durch die virtuellen FortiGate-Maschinen unserer Kunden gebunden. Als Lizenzserver kam ein lokal bereitgestellter FortiManager in HA-Konfiguration zum Einsatz, der ständig mit der FortiGuard-Cloud kommunizierte, um die Lizenz zu validieren und den verbrauchten Punktestand abzuschreiben. Dadurch war es möglich, den Dienst für jeden Kunden flexibler zu konfigurieren und nur für das nachgefragte Funktionspaket zu bezahlen. Zusätzliche Optionen können bei Bedarf online zu- und abgeschaltet werden. Darüber hinaus erlaubte uns diese Art von Lizenz, keine zusätzlichen Ressourcen auszugeben – weder unsere noch die des Kunden. Im Allgemeinen war dies alles vorerst sehr praktisch. Wenn die Gültigkeit der Lizenz nicht überprüft werden konnte, stoppte die Firewall das Routing des Datenverkehrs vollständig, wodurch Kundeninformationssysteme unzugänglich wurden.

Glücklicherweise war Fortinet, obwohl es am meisten nachgefragt wurde, nicht unser einziger Anbieter für den UTM-Dienst. Insbesondere befanden wir uns in der Endphase des Tests des heimischen UserGate. Infolgedessen haben wir innerhalb von ein bis zwei Tagen einen Notfallwechsel zu einem russischen Anbieter implementiert. Dabei half uns, dass wir bereits Parity-Lösungen zum Austausch hatten. Wir hatten (und haben immer noch) den israelischen Kontrollpunkt in unserem Arsenal.

Fast kein SEG

Der E-Mail-Schutzdienst hatte etwas mehr Glück – die Briefe gingen weiter durch. Aufgrund des Widerrufs von Lizenzen verlor die Lösung jedoch die Möglichkeit, ihre Signaturen und Regeln online zu aktualisieren. Dadurch konnten wir unseren Kunden keinen hochwertigen E-Mail-Schutz garantieren. Ja, wir hatten die technische Möglichkeit, einige der funktionalen Schutzmodule offline zu aktualisieren, was die Vorteile eines Cloud-Dienstes vollständig entwerten würde.

Trotzdem wurde SEG nicht zu einem Ziegelstein, was uns die Gelegenheit gab, einen Ersatz für die Basislösung zu erarbeiten. Wir haben uns nach und nach mit diesem Thema beschäftigt, aber es gab keine so fertige Antwort wie bei UTM. Momentan werden Anschlussmöglichkeiten von russischen Anbietern ausgearbeitet.

VM ohne Cloud verlassen

Ein weiterer Dienst, der sich nach dem Entzug von Lizenzen als nicht verfügbar herausstellte, ist der Dienst Vulnerability Management (VM). Dafür haben wir den Cloud-Scanner von American Qualys verwendet. Hier war alles relativ einfach: keine Lizenz, kein Zugriff auf den Scanner. Es war offensichtlich, dass die Lösung unter den neuen Bedingungen nur durch eine heimische Cloud ersetzt werden konnte. Wir arbeiten bereits mit einem der russischen Anbieter zusammen, sodass Kunden nicht ohne Perimeter-Scanning dastehen. Bisher konzentriert sich der Service eher auf mittlere und große Massenunternehmen. In naher Zukunft gibt es jedoch Pläne, die Cloud zu erweitern, um die Anforderungen eines großen Enterprise-Segments zu erfüllen.

Wie wir ohne einen Orchestrator zurückblieben

Wir waren also bereit, Kunden zu migrieren, aber in diesem Moment kam es zu einem Unfall mit unserem hochrangigen Orchestrator, durch den wir Services für Kunden bereitstellen und Serviceparameter ändern, einschließlich des Austauschs einer Lösung durch eine andere. Wahrscheinlich hätten wir bei solchen Bedingungen einen Unfall nicht vermieden, so sehr wir uns auch bemüht hätten.

Erstens wurden wir von einem starken Zustrom von Kunden getroffen, die dringend Schutz vor allem auf einmal benötigten. Außerdem mussten wir für die Anbindung zusätzliche Serverkapazitäten bereitstellen, die normalerweise für das Management von Cloud-Komponenten reserviert sind. Außerdem migrierten wir Dienste auf die aktualisierte Plattform, was zusätzliche Kapazitäten erforderte. Nun, zum Teufel – neue Lösungen erforderten mehr Leistung als beispielsweise das gleiche FortiGate.

Kurz gesagt, wir hatten kein Tool zur Verwaltung von Diensten innerhalb der Serviceplattform, es gab keine Gelegenheit, auf seine Wiederherstellung zu warten: Niemand hat Verpflichtungen gegenüber Kunden gekündigt. Daher hat das Team unserer Ingenieure die vorhandenen Automatisierungsdeskriptoren, die vom externen Orchestrator der Plattform in Playbooks außerhalb der Plattform gezogen werden, schnell überarbeitet. Dadurch konnten wir den Dienst mit dem gleichen Automatisierungsgrad bereitstellen, aber den Orchestrator umgehen. Kurz gesagt, wir haben Playbooks vorbereitet, einen Zeitplan vereinbart und manuell Arbeiten durchgeführt, um sie durch alternative Lösungen zu ersetzen.

Im Allgemeinen erfolgt die Bereitstellung des Dienstes vollständig automatisiert. Auf Knopfdruck werden dedizierte Mandanten auf allen Ebenen der Plattform bereitgestellt, ein dediziertes logisches Netzwerk und eine Computerinfrastruktur erstellt, die erforderlichen VNF-Netzwerkfunktionen bereitgestellt und Verbindungen zwischen Komponenten innerhalb der SDN-/SD-WAN-Teile bereitgestellt die Plattform entsprechend dem Design des gewünschten Dienstes organisiert, die VNFs selbst konfiguriert, fehlertolerante Konfigurationen erstellt usw. Und das sind Tausende von Codezeilen.

Gehen wir ohne den alten Rechen

Das Erlebnis einer extremen Umstellung auf neue Anbieter war natürlich unvergesslich, aber ich möchte es keinesfalls wiederholen. Daher ist es jetzt offensichtlich, dass wir bei der Auswahl von Technologien für unsere Dienstleistungen heimischen Lösungen den Vorzug geben werden.

Wir haben auch noch einmal darauf geachtet, dass alle Lösungen in unsere eigene Infrastruktur integriert und ausschließlich auf unserer eigenen Cloud bereitgestellt werden müssen, damit wir immer Zugriff auf alle Technologien haben, die wir verwenden. So haben wir immer die volle Kontrolle über die Infrastruktur der Dienste. Wie wir oben geschrieben haben, besteht jedoch immer ein Risiko für verschiedene NDV – dieses Risiko wird durch die FSTEC-Zertifizierung verringert.

Und natürlich müssen wir unseren Kunden Tribut zollen, die uns mit Verständnis für die Situation auch auf halbem Weg entgegenkamen, nicht viel fluchten und das notwendige Feedback gaben. Jetzt ist das Problem der Verfügbarkeit von Diensten und der Sicherheit der Kunden gelöst. Importe wurden durch %@&# ersetzt, wie man so schön sagt!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *