Seit 2004: Keine Kompromisse

Out-of-Band-Management auf jeder Maschine

Jeder Server, den wir betreiben, ist ein echter Enterprise-Server mit einem echten Lights-out-Controller: iDRAC Enterprise mit Datacenter-Lizenz bei Dell, iLO Advanced bei HPE, beide über Redfish angesteuert, und jedes Blade-Chassis über seinen Onboard Administrator. Kein White-Box-Mainboard, dessen Vorstellung von Fernwartung ein Einschaltknopf und keine Konsole ist.

Auf dem Blade-Chassis erreicht der Onboard Administrator jeden Controller im Enclosure über die Backplane und ist selbst ein redundantes Paar mit automatischem Failover.

In der Praxis. Als ein Rack voller Blade-Chassis iLO Advanced lizenziert bekommen musste, und auf jedem Blade darin ein Management-Konto angelegt, haben wir uns an keinem einzigen Blade angemeldet. Wir haben es über den Onboard Administrator jedes Chassis ausgerollt, und das Rack war in Minuten fertig, einschließlich Blades, die in derselben Woche eingebaut worden waren und noch keine eigenen Zugangsdaten hatten. Es ist ein Runbook.

Das Management-Netzwerk ist nicht das Produktionsnetzwerk

Der Controller hat seinen eigenen physischen Port und sein eigenes Kabel zu seinem eigenen Switching. Wir partitionieren keine Produktions-Netzwerkkarte, damit sich der Controller eine Scheibe davon leiht, was die übliche Abkürzung ist und der übliche Grund, warum Management am Ende einen Fehler vom Internet entfernt ist. Management lebt auf eigenen Switches, oder auf eigenen VLANs auf Fabrics, die sonst nichts tragen, in privatem Adressraum, der zu keinem Kundennetzwerk hin oder von ihm weg geroutet und nie ins Internet announciert wird.

Wir nennen es Air Gap, weil es sich so verhält. Eine virtuelle Kundenmaschine, selbst eine vollständig kompromittierte, die eine Woche lang mit Leitungsgeschwindigkeit scannt, kann ein iLO oder ein iDRAC überhaupt nicht sehen. Nicht abgewiesen, nicht gefiltert: nicht vorhanden. Es gibt nirgendwo, wohin die Pakete gehen könnten. Das gilt auch in die andere Richtung, und das zählt genauso: Kein Management-Verkehr fährt über ein Kunden-VLAN, also betreten unsere Konsolensitzungen, unser Monitoring und unsere Backups nie die Broadcast-Domäne eines Kunden und konkurrieren nicht um seine Bandbreite. Die Isolation ist real genug, um uns unbequem zu sein, und das ist der Beweis, dass sie real ist: Ein Controller in einem Management-VLAN kann nicht einfach einen internen Webserver erreichen, um ein Firmware-Image zu holen, weil nichts erlaubt ist, was nicht beantragt und aufgeschrieben wurde. Der Ingenieur geht den zusätzlichen Schritt.

Backups reisen auf demselben Weg. Sie werden über das Out-of-Band-Netzwerk gezogen, nie über ein Produktionssegment.

In der Praxis. Eine kanonische Management-Zugriffsliste ist auf jeder Plattform gebunden, die wir betreiben, auf den Login-Lines der Cisco Nexus, pro Routing-Instanz auf den Routern, pro Schnittstelle für SSH und HTTPS auf den Firewalls, und erlaubt nur benannte Management-Subnetze, während Control Plane Policing alles Übrige in Hardware begrenzt.

Die Management-Ebene selbst

Die Management-Ebene ist ein eigenständiges Netzwerk, und wir haben sie wie eines gebaut. Sie läuft auf unserem eigenen verschlüsselten Multi-Site-Backbone: Cisco DMVPN, IPsec mit AES-256, BGP über die Tunnel, und verbindet Athen, Amsterdam und Toronto mit unserem Firmensitz in Zypern, der bewusst in keinem der Gebäude liegt, die er verwaltet. Die Hubs sind redundant, mit Equal-Cost-Pfaden über sie und über diverse Leitungen, und einer Ausfallerkennung, die einen toten Pfad in deutlich unter einer Sekunde bemerkt.

Mitarbeiter erreichen sie auf einem Weg: über VPN-Gateways und Firewalls, die wir selbst besitzen und betreiben, auf OPNsense und Cisco Firepower, dann über Jump Hosts innerhalb der Ebene statt direkt vom Laptop eines Ingenieurs. Verschiedene Vertrauensstufen teilen sich nie ein Firewall-Objekt, sodass die Erweiterung des Zugriffs einer Gruppe nicht stillschweigend den einer anderen erweitern kann.

Gegenüber den Backup- und Disaster-Recovery-Ebenen ist die Richtlinie Deny by Default, und die Daten fließen in eine Richtung. Die Produktion schiebt nie zum Backup. Die Backup-Seite holt. Das wird mit expliziten Deny-Regeln auf den Firewall-Appliances durchgesetzt, nicht mit einer Host-Firewall, die ein kompromittierter Host ändern könnte, und die Backup-Segmente haben überhaupt keine Route ins Internet. Nur der Management-Bereich erreicht sie. Wenn eine Produktionsmaschine vollständig übernommen wird, erlangt der Angreifer kein Wissen über die Backup-Infrastruktur und keinen Pfad dorthin. Von dort, wo er steht, existiert sie nicht.

Backbone-Änderungen werden live gegen das laufende System verifiziert, eine Hälfte eines redundanten Paars nach der anderen, weshalb wir mitten an einem Arbeitstag am Backbone arbeiten können.

In der Praxis. Wir haben den gesamten Site-to-Site-VPN-Bestand eines Kunden in einer einzigen Sitzung von einem Land in ein anderes verlegt, vor einer festen Frist. Der Hub wurde geklont, hinübergetragen und parallel zum Original hochgefahren, sodass beide gleichzeitig live waren und die Tunnel immer irgendwo sein konnten. Die Zweigstellen-Router wurden einer nach dem anderen umgezogen, jeder als erreichbar verifiziert, bevor der nächste angefasst wurde, jeder mit sauberem Failover unterwegs. Niemand ist in eine Zweigstelle gefahren.

Die Hardening-Baseline auf jedem Host

Jede Maschine, die wir bauen, startet von derselben Baseline, und die Baseline steht nicht zur Verhandlung. SELinux ist im Enforcing-Modus, und wir schalten es nicht ab, damit eine Anwendung mitspielt, wir schreiben stattdessen die Policy. Dateisysteme sind XFS.

Das Patchen hängt von niemand anderem ab. Wir betreiben unseren eigenen Paket-Mirror in unserem eigenen Rechenzentrum, mit den Repositories, aus denen unsere Flotte installiert, Upstream-Signaturen intakt, nur aus unseren eigenen Adressbereichen erreichbar. Ein öffentlicher Mirror, der einen schlechten Tag hat, ist hier kein Ereignis, und ein Server, der absichtlich nicht mit dem Internet sprechen kann, ist immer noch ein Server, den wir vollständig patchen können.

In der Praxis. Als eine kritische Schwachstelle in einer weit verbreiteten Laufzeitumgebung veröffentlicht wurde, waren die korrigierten Pakete noch am selben Tag auf jedem betroffenen Server in Produktion, vor dem Ende derselben Nacht. Nicht von Hand und nicht in Eile: Der Rollout nimmt ein Backup, aktualisiert einen Host nach dem anderen, prüft echte Websites auf diesem Host vorher und nachher auf eine gesunde Antwort und stoppt den gesamten Durchlauf automatisch, wenn eine nicht korrekt zurückkommt. Schnell und sorgfältig sind keine Gegensätze, wenn man das Werkzeug baut, das es für einen erledigt.

Maschinenlogs rein, und nichts darf verstummen

Die ernsten Schweregrade gehen direkt in den Betriebs-Chat, in dem der Bereitschaftsingenieur ohnehin ist, und erreichen in Sekunden einen Menschen, und wir wissen, dass es Sekunden sind, weil wir es mit einem echten Alarm gestoppt haben. Am Edge lesen dedizierte Sensoren gespiegelten Verkehr von den Border-Routern und achten kontinuierlich auf volumetrische und Denial-of-Service-Muster.

Ein Gerät kann von seiner eigenen Kommandozeile aus völlig gesund aussehen, während es still nichts an den Collector sendet, also ist «Logging ist konfiguriert» hier kein Beweis. Wir bestätigen, dass das Log ankommt, am anderen Ende, in dem Stream, zu dem es gehört, nach jeder Änderung, die es gestört haben könnte. Die Monitoring-Systeme haben ihre eigenen Watchdogs auf separaten Maschinen, sodass «das, was zugesehen hat, hat aufgehört zuzusehen» selbst ein Alarm ist. Stille ist nie eine gute Nachricht.

In der Praxis. Unser routinemäßiger Gesundheitscheck prüft auch zwei Dinge, die die meisten Checks auslassen: ob jedes Gerät seine Logs noch wirklich verschickt, und ob seine Konfiguration noch wirklich gesichert wird. Diese beiden sind die Ausfälle, die die anderen verstecken.

Echtzeitanalyse auf unseren eigenen NVIDIA A100

Die meisten Anbieter sammeln Logs in einem Bucket und durchsuchen ihn, nachdem etwas bereits kaputtgegangen ist. Wir setzen den Stream an die Arbeit. Einfache Regeln entfernen zuerst das bekannte Rauschen, dann wird alles, was übrig bleibt, von Routern, Switches, Firewalls, Storage-Arrays und Servern, beim Eintreffen von KI-Modellen analysiert, die auf einem Verbund unserer eigenen NVIDIA-A100-GPUs laufen, in unserem eigenen Rechenzentrum.

Die Modelle lesen geräteübergreifend, nicht eine Logzeile nach der anderen: Ein Storage-Pfadfehler, eine flatternde Schnittstelle und eine steigende Temperatur im selben Rack werden zu einer Geschichte statt zu drei unzusammenhängenden Meldungen. Sie erkennen die Muster, die eine statische Regel nie erkennen wird, die langsame Drift und die ungewöhnliche Kombination, die einem Ausfall vorausgeht, und jeder Alarm erreicht den Ingenieur mit einer bereits angehängten zweiten Meinung. Maschinendaten hören auf, ein Haufen Text zum Durchsuchen zu sein, und werden zu einer Frühwarnung.

Nichts davon verlässt unser Netzwerk. Die Modelle, die GPUs und die Daten gehören alle uns, und keine Logzeile wird je an einen externen KI-Dienst gesendet.

Ein CTO, der uns bewertet, darf gern nach der Zugriffsliste, dem Runbook und dem Alarm-Routing fragen. Wir zeigen Ihnen alle drei.