Antworten auf einen Anforderungskatalog zur Plattformsicherheit

Sicherheitsanforderungen kommen als nummerierte Liste. Jemand muss Zeile für Zeile sagen, ob die Plattform das kann, ob es enthalten ist und welchen Nachweis es dazu gibt. Diese Antwort wird meist für jede Ausschreibung neu gebaut, was für uns langsam ist und für dich, während du darauf wartest, noch langsamer.

Also steht sie hier einmal, für eine von VSHN betriebene OpenShift-Plattform. Jede Kontrolle sagt, welches von drei Dingen sie ist: enthalten in der betreuten Plattform, Zusatzmodul, das separat bestellt und verrechnet wird, oder deins. Eine Seite, die diese drei vermischt, nützt genau für den Zweck nichts, für den du sie liest.

Der letzte Abschnitt nennt die Kontrollen, die diese Seite noch nicht beantwortet, statt Schweigen als Nein wirken zu lassen.

Netzwerksegmentierung

Enthalten. Managed OpenShift nutzt Cilium als Standard-CNI, Network-Policy-Enforcement gehört also zur Plattform und wird nicht nachträglich angebaut. Namespaces, RBAC und Security Context Constraints kommen von OpenShift selbst.

Zusatzmodul: Isovalent Enterprise Platform. Wenn eine Anforderung mehr verlangt als Policy auf Netzwerkebene, kommen hier identitätsbasierte Mikrosegmentierung, Policy-Enforcement über L3, L4 und L7, transparente IPsec- oder WireGuard-Verschlüsselung zwischen Knoten und ein Egress-Gateway für Workloads dazu, die den Cluster über eine bekannte Adresse verlassen müssen.

Verrechnet wird pro Funktion und pro Knotenkapazität, in zwei Stufen, und die aktuellen Ansätze sind publiziert statt pro Geschäft offeriert. Lies sie dort und nicht hier: es sind Richtwerte, die die effektive Verrechnung nach tatsächlichem Verbrauch nachführt, und ein auf eine zweite Seite kopierter Preis veraltet, ohne dass es jemand merkt. Was Isovalent als Beta kennzeichnet, und nicht standardisierte Konfiguration, unterstützt VSHN nur, wenn das ausdrücklich vereinbart ist.

Kontakt

Administrativer Zugriff

Enthalten, und vor dem Formulieren der Anforderung lesenswert. VSHN betreibt die Plattform mit Automation, die Systeme müssen also jederzeit erreichbar sein, ohne dass ein Mensch dazwischensteht. Manuelle Zugangswege sind darum ausgeschlossen: persönliche VPN-Clients, Remote-Desktop-Sprungserver, Hardware-Token, die einem Engineer in die Hand gedrückt werden, und Zugriff, der am Notebook einer Person hängt.

Das heisst nicht, dass wir deine Zugangskontrollen ablehnen. VSHN kann die nötigen SSH- und VPN-Jumphosts selbst bereitstellen und erfüllt damit in der Praxis die meisten Informationssicherheitsvorgaben. Konten von VSHN-Mitarbeitenden und Dienstkonten werden ausschliesslich über das VSHN Configuration Management verwaltet, es gibt also eine Stelle, an der Zugriff erteilt und entzogen wird.

Der Unterschied, auf den es in deinem Katalog ankommt: ein Jumphost, den Automation unbeaufsichtigt passieren kann, funktioniert. Einer, der pro Sitzung eine menschliche Freigabe braucht, nicht. Wenn deine Anforderung die zweite Art meint, sag es früh. Das ist eine Architekturfrage und keine Konfigurationsfrage, und sie hat schon grössere Infrastrukturprojekte aus der Spur gebracht als dieses.

Logging, SIEM-Export und Forensik

Enthalten. Cluster-internes Logging, gesammelt und verfügbar, um Dienstfehler zu debuggen.

Zusatzmodul, in derselben Isovalent-Plattform wie oben. Hubble liefert identitätsbewusste Flow-Logs, die das Policy-Verdikt zur Verbindung mitschreiben. Eine Logzeile sagt damit nicht nur, was passiert ist, sondern welche Policy es erlaubt oder verweigert hat. Hubble Timescape hält diese Historie zur späteren Auswertung. SIEM Export liefert diese Ereignisse in dein eigenes SIEM, als eigene Position auf der Networking-Stufe und nicht als Einzelkauf. Tetragon ergänzt Runtime Security und korreliert Prozessereignisse mit Netzwerkereignissen, was eine forensische Frage üblicherweise braucht.

Das ist die ehrliche Form der Antwort: einen SIEM-Feed gibt es, er ist ein benanntes Produkt mit publiziertem Ansatz, und er wird bestellt statt vorausgesetzt.

Monitoring und Störungsbehandlung

Enthalten, und das Niveau wählst du. Das Service-Level-Profil entscheidet:

VSHN überwacht die Plattform und reagiert im Fenster, das du gekauft hast, auf SLA-relevante Alarme. Beachte: Überwachung und Störungsbehandlung rund um die Uhr ist das, was die 24/7-Profile enthalten. Ein benannter Pikettdienst für deine eigene Applikation ist ein separater Plan, und die beiden zu verwechseln ist der häufigste Lesefehler in so einer Tabelle.

Alle Profildetails, inklusive Messung der Verfügbarkeit und Berechnung der Credits: VSHN Service Levels.

Backups

Enthalten. Backups laufen täglich. Die Standardaufbewahrung behält die letzten sieben täglichen Backups plus vier wöchentliche, ein anderer Zeitplan inklusive mehrerer Läufe pro Tag ist als Option verfügbar. Die Daten werden auf dem Client verschlüsselt, bevor sie die Maschine verlassen, und dann über eine TLS-Verbindung an ein Off-Site-Ziel in Schweizer Rechenzentren übertragen, das VSHN auswählt. Eigene Standorte gibt es auf Anfrage.

Der Punkt, nach dem du jeden Anbieter fragen solltest: der Backup-Erfolg wird selbst überwacht. Tage ohne erfolgreiches Backup sind ein gemessener Indikator mit einem Schwellenwert von einem Tag auf den höheren Profilen und drei Tagen auf Baseline. Ein still scheiterndes Backup wird damit zur Störung und nicht zur Entdeckung während einer Wiederherstellung.

Deins. Deine Aufbewahrungs- und Klassifizierungsvorgaben und der Wiederherstellungspunkt, den dein Geschäft wirklich braucht. Das ist eine Eingabe in die Auslegung und kein Ergebnis daraus.

Härtung des Betriebssystems

Enthalten. Die Maschinen unter der Plattform werden per Konfiguration gehärtet und nicht per einmaliger Checkliste: SSHd-Konfiguration, IPtables als lokale Firewall, sudo-Einschränkungen, erzwungene Paketquellen, NTP und DNS-Resolver, halbautomatische wöchentliche Paketupdates und 0-Day-Mitigation ausserhalb dieses Zyklus, wenn nötig. Weil es Konfigurationsmanagement ist und kein Build-Schritt, wird Drift laufend korrigiert und der Zustand berichtet statt angenommen.

Vier Kontrollen, die nicht auf Clusterebene liegen

Der Rest eines typischen Katalogs fragt nach Dingen, die eine Plattform allein nicht beantworten kann, weil sie Eigenschaften deiner Architektur sind und nicht eines Clusters. Zu benennen, welche das sind und warum, erspart später in der Evaluation eine Diskussion.

Disaster Recovery mit ausgewiesenem RPO und RTO. Ob du Cold-, Warm- oder Hot-Standby brauchst, ergibt sich aus deiner Gesamtarchitektur und nicht aus dem Cluster darunter. Ein publizierter Wiederherstellungspunkt wäre deshalb für die meisten Leserinnen und Leser dieser Seite falsch, das Konzept entsteht also kundenspezifisch. Was sich vorher sagen lässt, ist, was es einschränkt: meist entscheiden die Replikationsgrenzen des gewählten Schweizer Anbieters, und Georedundanz über zwei Standorte wird gebaut und nicht bestellt.

Vier-Augen-Prinzip und Funktionstrennung. Durchgesetzt auf Quellcode-Ebene über die Freigabe von Merge Requests, nicht auf der Plattform. Das ist Absicht und keine Lücke. Auf einer von VSHN betriebenen Plattform soll nichts von Hand geändert werden. Ein plattformseitiges Freigabetor würde also einen Weg bewachen, den niemand benutzen soll, während die Änderung, die tatsächlich in Produktion geht, daneben vorbeiläuft. Die Kontrolle gehört dorthin, wo die Änderung geschrieben wird.

Zentrale Logspeicherung über Cluster hinweg. Ebenfalls eine Architekturfrage und keine Clusterfrage. Wo Logs zusammenlaufen, wie lange sie bleiben und unter wessen Aufbewahrungsregeln, hängt davon ab, was du sonst noch betreibst. Das wird mit dir entworfen und nicht als Vorgabe geliefert.

Cloud Security Posture Management und Anbindung an deine eigene PKI oder Zertifizierungsstelle. Kundenspezifisch gebaut. Beides gibt es, und beides ist nicht Teil des Standardpakets. Diese Unterscheidung gehört vor dem Vertrag schriftlich festgehalten und nicht danach.

Steht eines davon in deinem Katalog, frag nach. Die Antwort ist ein Architekturgespräch, und ein kurzes.

Weiterlesen: was VSHN betreibt und was bei dir bleibt und Souveränität für Gerichtsstand, Eigentümerschaft und den CLOUD Act.