Einleitung

Die Modernisierung kritischer Infrastruktur ist kein klassisches Cloud-Projekt. Beim KUNO-System – einer zentralen Plattform zur Bekämpfung von Kartenmissbrauch im deutschen Handel – zeigte sich: Der größte Aufwand liegt nicht in der Cloud-Migration, sondern in der Anwendung selbst. Dieser Praxisbericht zeigt, wie Interlake KUNO modernisiert und auf STACKIT in eine souveräne Cloud überführt hat – inklusive konkreter Learnings für vergleichbare Projekte.

Was ist KUNO – und warum ist es kritisch?

KUNO steht für Kriminalitätsbekämpfung im unbaren Zahlungsverkehr unter Nutzung nichtpolizeilicher Organisationsstrukturen. Hinter diesem Behördennamen steckt eine der stillen, aber systemrelevanten Plattformen des deutschen Zahlungsverkehrs.

Vor rund 20 Jahren schlossen sich das EHI Retail Institute, der Handelsverband Deutschland (HDE) und die Polizei zusammen – gemeinsam mit den Innenministerien aller Bundesländer. Das Ergebnis: eine Plattform, die gestohlene EC-Karten schnell für das Lastschrift- und Unterschriftsverfahren sperren kann. Das klingt nach einem Randproblem, ist es aber nicht.

Wer seine EC-Karte sperren lässt – zum Beispiel über die bekannte Sperr-Hotline 116116 –, der sperrt damit die PIN-basierte Zahlung bei seiner Bank. Was viele nicht wissen: Das Zahlen per Unterschrift und Lastschriftverfahren, das im deutschen Einzelhandel nach wie vor weit verbreitet ist, wird dadurch nicht gesperrt. Genau diese Lücke schließt KUNO.

Die Plattform hat Schnittstellen zu allen 16 LKA der Bundesländer, zu einem großen Teil der deutschen Händler und zu Payment-Service-Providern. Wer nach einem Diebstahl zur Polizei geht und die EC-Kartenfolgenummer nennt – die auf fast jedem Kassenbeleg steht –, kann über KUNO eine Sperre auslösen. Je schneller, desto besser, weil Kartenmissbrauch meist unmittelbar nach dem Diebstahl stattfindet.

Das EHI hat uns mit der Modernisierung und dem Betrieb dieser Plattform betraut. Eine Aufgabe, die wir nicht auf die leichte Schulter nehmen – KUNO ist kein internes Verwaltungssystem, sondern ein Dienst, der täglich im deutschen Handel genutzt wird.

Das eigentliche Problem: 20 Jahre gewachsener Code

Systeme, die zwei Jahrzehnte lang zuverlässig laufen, haben einen Preis: gewachsene Abhängigkeiten, enge Kopplung, technische Schulden, die niemand mehr vollständig überblickt.

Wir bei Interlake sind seit 29 Jahren im Geschäft, sitzen in Potsdam und haben rund 20 Mitarbeiter. Unser Schwerpunkt liegt auf der Entwicklung, Modernisierung und dem 24/7-Betrieb von Anwendungen in der Cloud.

Die Ausgangslage beim KUNO-Projekt war klassisch:

• Klassische on-premise Infrastruktur mit zahlreichen Abhängigkeiten
• .NET als technologische Basis
• Gewachsene Anwendung

Das Ehrlichste, was wir dazu sagen können: Der größte Aufwand in diesem Projekt lag nicht in der Cloud-Migration, sondern in der Anwendung selbst. Wer das bei ähnlichen Vorhaben unterschätzt, riskiert die Projektstabilität.

Was wir tatsächlich modernisiert haben

Wir haben bewusst zwei Workstreams getrennt: Unser Entwicklungsteam hat sich um die Anwendungsmodernisierung gekümmert, unser Cloud Operations Team hat parallel die Infrastruktur in STACKIT aufgebaut. Für uns war das gleichzeitig das erste Projekt auf dieser Plattform – ein bewusster Einstieg, kein Blindflug.

Auf der Anwendungsseite bedeutete Modernisierung konkret:

• Migration von .NET auf .NET Core
• Refactoring der Datenbankabfragen
• Austausch Windows-spezifischer DLLs gegen plattformunabhängige Alternativen
• Anpassung aller Schnittstellen an die neue Zielarchitektur
• Wechsel von SQL Server auf MariaDB – eine relationale Datenbank mit vergleichbarem Funktionsumfang, die auf STACKIT deutlich günstiger ist

Der Wechsel auf MariaDB war kein Qualitätskompromiss. Er war das Ergebnis eines Kostenvergleichs: Wer eine neue Cloud-Plattform mit bestehenden Diensten befüllt, ohne die Alternativen zu prüfen, vergleicht Äpfel mit Birnen. Wir haben dies zu Beginn selbst gemacht und unseren initialen Kostenvergleich korrigieren müssen.

Auf der Infrastrukturseite haben dann alle Komponenten aufgesetzt: Netzwerk, Sicherheitsrelevante Servcies, Plattformdienste wie Cloud Foundry, den Managed Kubernetes Service von STACKIT, als auch betriebliche Prozesse wie CI/CD-Prozesse angepasst. Danach sind wir viele Wochen in den Parallelbetrieb gegangen – erst ohne Produktivdaten, dann mit – bis wir im Februar 2026 den finalen Switch machen konnten.

Ein weiteres Learning aus der Praxis: CI/CD ist kein Detail. Ein stabiler, reproduzierbarer Deployment-Prozess ist die Grundlage für ruhigen Betrieb. Der Aufwand, den wir dort hineingesteckt haben, hat sich bezahlt gemacht.

Warum wir uns für STACKIT entschieden haben

Unsere Entscheidung war keine Einzelfaktor-Entscheidung. Drei Anforderungen waren nicht verhandelbar:

1. Kubernetes-Basis und kein Vendor Lock-in Wir haben viel Erfahrung mit Kubernetes-basierten Referenzarchitekturen und wollten genau das einsetzen. Gleichzeitig war Open Source keine Nice-to-have-Anforderung, sondern eine harte Bedingung. Eine Exit-Strategie muss für jede kritische Infrastruktur realisierbar sein. STACKIT basiert auf OpenStack und setzt konsequent auf Open-Source-Komponenten.
2. Rechtliche Klarheit für kritische Daten KUNO verarbeitet sensible Daten mit direktem Bezug zur Strafverfolgung. Relevant war deshalb, dass rechtliche Klarheit vorliegt und die Rechenzentren innerhalb der EU betrieben werden. Alle STACKIT-Rechenzentren stehen aktuell in Deutschland und Österreich.
3. Operative Partnerschaft auf Augenhöhe Wir bauen und betreiben die Plattform. Dafür brauchen wir einen Infrastrukturpartner mit kurzen Wegen, gutem Support und erreichbaren Architekten. Das hat sich bei STACKIT bestätigt – der Einstieg war unkomplizierter als erwartet.

Unsere Learnings – zusammengefasst

Drei Punkte, die wir aus diesem Projekt mitnehmen und gerne weitergeben:

Der Hauptaufwand liegt in der Anwendung, nicht in der Infrastruktur. Sonderlogiken, die niemand mehr im Kopf hatte, können erheblich Zeit kosten. Der Aufbau von Infrastruktur (auch auf einer für einen neuen Plattform) birgt weitaus weniger Überraschungen.

Vergleicht die richtigen Dinge. Viele Dienste können dieselbe fachliche Funktion erfüllen – zu grundlegend unterschiedlichen Kosten. Ein 1:1-Mapping der bestehenden Services/Produkte auf eine neue Plattform führt möglicherweise zu falschen Kostenschätzungen.

Der Lernaufwand bei einem Plattformwechsel ist beherrschbar. Cloud-Konzepte ähneln sich stark. Der meiste Lernaufwand bei uns steckte im Cloud Foundry-Service, nicht in den IaaS-Grundlagen. Wer containerbasiert unterwegs ist, findet sich schnell zurecht.

STACKIT: Was steckt hinter der Plattform?

Für alle, die STACKIT noch nicht kennen: Es ist die Public Cloud der Schwarz Digits, dem IT-Arm der Schwarz-Gruppe – bekannt vor allem durch Lidl und Kaufland.

Einige Zahlen, die die Dimension einordnen:

• Über 8.000 IT-Mitarbeiter an 34 IT-Standorten weltweit
• Über 600.000 Mitarbeiter in der Gesamtgruppe, 14.000 Filialen
• 4 eigene öffentliche Rechenzentren, weitere in Planung

Der wichtige Punkt dabei: Lidl- und Kaufland-Kassensysteme laufen auf derselben Plattform, die als Public Cloud angeboten wird. Neuheiten werden intern validiert, bevor sie Kundenreife erreichen. Das ist kein Marketingargument, sondern ein technisches Qualitätssignal.

Das Rechenzentrum Lübbenau

STACKIT investiert 11 Milliarden Euro in ein neues Rechenzentrum in Lübbenau (Brandenburg). Mit einer geplanten Spitzenanschlussleistung von 200 Megawatt wäre es bei Inbetriebnahme das leistungsstärkste Rechenzentrum Deutschlands in dieser Kennzahl. Der primäre Anwendungsfall ist KI-Infrastruktur; Colocation ist ebenfalls möglich.

Weitere deutsche Standorte sind in Planung oder im Aufbau. Die Expansion läuft außerdem in die Schweiz, nach Rumänien, Bulgarien, Benelux und Spanien – jeweils mit eigenen Mitarbeitern vor Ort, kein Outsourcing.

Was „souveräne Cloud“ bei STACKIT konkret bedeutet

Der Begriff wird inflationär verwendet. STACKIT definiert Souveränität entlang von drei Dimensionen:

• Wirtschaftliche Souveränität:
  Kein Vendor Lock-in durch proprietäre Dienste. Ingress und Egress sind aktuell kostenfrei. Das Pricing-Modell ist transparent kalkulierbar.
• Politische Souveränität:
  Alle Rechenzentren im europäischen Rechtsraum. Keine Anknüpfungspunkte an den US Cloud Act oder andere außereuropäische Gesetzgebung.
• Technologische Souveränität:
  OpenStack-Basis, Open-Source-Komponenten, Beteiligung an der Alasca-Initiative und der Neonfoss Foundation.

Preisvergleich: ehrliche Einschätzung

Aus unseren eigenen Kalkulationen: Bei einem echten Äpfel-zu-Äpfel-Vergleich lagen die Kosten auf STACKIT im schlechtesten beobachteten Fall rund 10 bis 15 Prozent über US-Hyperscalern. Häufig sind die Preise aber vergleichbar – abhängig vom genutzten Service-Mix. Wer ausschließlich auf den Preis schaut, findet möglicherweise günstigere Alternativen. Das sollte aber nicht der einzige Entscheidungsfaktor sein.

Zertifizierungen

• BSI C5 Type 2 für IaaS- und PaaS-Layer
• ISO-Zertifizierungen vorhanden
• VSNFD-Fähigkeit möglich, aber immer projektspezifisch in Abstimmung mit dem Kunden

Für wen ist das relevant?

Aus unserer täglichen Projektarbeit heraus sehen wir zwei Anwendungsfälle, bei denen eine souveräne Cloud-Infrastruktur besonders sinnvoll ist:

Erstens Anwendungen mit besonders schützenswerten Daten, bei denen rechtliche Klarheit über den Speicherort und die Zugriffsmöglichkeiten nicht verhandelbar ist.

Zweitens Anwendungen, bei denen Business Continuity im Vordergrund steht – Systeme, die nicht davon abhängen dürfen, dass ein externer Anbieter seine Konditionen oder seinen Rechtsstatus ändert.

Für Anwendungen, die sehr stark auf proprietäre, schlüsselfertige Services etablierter US-Hyperscaler aufbauen, ist ein Wechsel zu STACKIT mit mehr Aufwand verbunden. STACKIT verzichtet bewusst auf solche Dienste und setzt stattdessen auf Open-Source-Komponenten. Das ist eine Stärke im Sinne der Souveränität, bedeutet aber, dass man als Betreiber bereit sein muss, mehr selbst zusammenzubauen.

Fazit

Das KUNO-Projekt war kein reines Cloud-Migrations-Vorhaben. Es war eine strategische Modernisierung unter echten Rahmenbedingungen: kritische Daten, regulatorische Anforderungen, gewachsene Architektur. Unsere Entscheidung für STACKIT war das Ergebnis klar definierter Anforderungen – keine ideologische Präferenz für europäische Cloud-Anbieter.

Das System läuft. Das EHI hat eine nachhaltige Infrastruktur und rechtliche Klarheit über seine Daten. Und wir haben als Team auf einer neuen Plattform gelernt, dass der Einstieg unkomplizierter ist als erwartet – wenn man weiß, welche Fragen man stellen muss.

Alle in diesem Artikel genannten Zahlen und Fakten zu STACKIT wurden im Rahmen des @SIBB-Webinars von STACKIT / Schwarz Digits kommuniziert. Für Fragen zu unserer Arbeit und zu ähnlichen Projekten stehen wir gerne zur Verfügung.