Strategie & Migration

Digitale Souveränität in der IT: Wie du mit Linux und Open Source unabhängiger wirst

Souveränität entsteht nicht durch eine Beschaffungsentscheidung, sondern durch offene Formate, betreibbare Systeme und eigenes Personal. Wer nur den Anbieter tauscht, ohne Know-how aufzubauen, verlagert die Abhängigkeit statt sie aufzulösen.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

IT-Entscheider besprechen eine Infrastruktur-Roadmap im Besprechungsraum

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Warum Abhängigkeit ein Betriebsrisiko ist, kein Beschaffungsthema

Die meisten IT-Landschaften sind über Jahre in eine Richtung gewachsen: proprietäre Verzeichnisdienste, ein Hypervisor mit geänderter Lizenzpolitik, Kollaboration und Identitäten in einer Cloud, deren Betreiber einem fremden Rechtsraum unterliegt. Jede einzelne Entscheidung war zum Zeitpunkt vertretbar. Zusammengenommen entsteht daraus eine Lage, in der Preisänderungen, Produktabkündigungen oder rechtliche Auflagen dich treffen, ohne dass du technisch reagieren kannst. Genau das ist der Kern von fehlender Souveränität: nicht die Herkunft der Software, sondern die fehlende Ausweichoption.

Aktuell wird das Thema von zwei Seiten befeuert. Politisch durch Anforderungen an Datenhaltung, Nachvollziehbarkeit und Exit-Fähigkeit, technisch durch konkrete Anlässe wie die Lizenzumstellung bei VMware, das Support-Ende älterer Enterprise-Distributionen oder die Frage, ob KI-Workloads mit internen Daten überhaupt außer Haus laufen dürfen. Viele Häuser starten deshalb Migrationsprojekte, ohne vorher zu klären, welche Fähigkeiten der eigene Betrieb dafür braucht.

Typische Fehler sind gut dokumentiert. Es wird ein Produkt gegen ein anderes getauscht, statt Schnittstellen und Datenformate zu öffnen, und die neue Abhängigkeit ist nur anders lackiert. Es wird migriert, ohne dass jemand im Team ein Ceph-Cluster, nftables-Regelwerke oder ein systemd-basiertes Service-Management sicher beherrscht, und der erste ernsthafte Störfall macht die Einsparung wieder zunichte. Oder der Umstieg beginnt beim Arbeitsplatz, dem sichtbarsten und politisch heikelsten Teil, während die eigentlichen Klumpenrisiken in Infrastruktur und Datenhaltung unangetastet bleiben.

Miniatur-Szene: Spielbrett, auf dem eine Server-Figur von einer alten auf eine neue Plattform zieht, daneben eine Roadmap

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Souveränitätsebenen und ihre Wechselkosten

01 Arbeitsplatz und Office-Formate
02 Betriebssystem und Systembetrieb
03 Virtualisierung und Storage
04 Container- und Anwendungsplattform
05 Daten, Datenbanken, Schnittstellen
06 Kompetenz im eigenen Team

Was du mitnimmst

Die technischen Hebel, die tatsächlich Unabhängigkeit erzeugen

Souveränität lässt sich in Schichten denken. Jede Schicht hat eigene Wechselkosten, eigene offene Alternativen und einen eigenen Kompetenzbedarf. Sinnvoll ist es, unten anzufangen, wo die Abhängigkeit teuer und der Nutzen sofort messbar ist.

Betriebssystem und Basisbetrieb beherrschen

Ohne solide Linux-Grundlagen bleibt jede Souveränitätsstrategie Papier. Paketmanagement, systemd-Units, Rechte- und Benutzerverwaltung, Logging mit journald sowie Shell-Scripting sind die Werkzeuge, mit denen dein Team Systeme selbst betreibt statt Supportfälle zu eröffnen. Der Weg über LPI01 bis LPI04 oder den Kompaktkurs Linux Systemadministration und Shell-Scripting deckt genau diese Basis ab, die LPIC-1 Komplettausbildung führt sie zur Zertifizierung.

Virtualisierung aus der Lizenzfalle holen

Der häufigste konkrete Anlass ist derzeit der Wechsel von VMware zu Proxmox VE. Technisch geht es um KVM und LXC, um Storage-Entscheidungen zwischen ZFS und Ceph, um Cluster-Quorum und um ein Backup-Konzept, das den Namen verdient. Der Proxmox Grundkurs deckt Installation, Storage und Backup ab, der Aufbaukurs behandelt Cluster, Ceph und High Availability, und für den eigentlichen Umzug gibt es den Kurs Migration von VMware zu Proxmox.

Plattform statt Cloud-Lock-in

Container und Kubernetes sind kein Selbstzweck, aber sie sind die derzeit portabelste Art, Anwendungen zu betreiben. Wenn du Manifeste, Helm-Charts und GitOps-Repositories sauber hältst und auf herstellerspezifische Dienste verzichtest, wird der Betriebsort zur Entscheidung statt zum Schicksal. Podman, kubeadm-basierte Cluster, Argo CD oder Flux und der Sonderfall Air-Gapped Kubernetes sind hier die relevanten Bausteine.

Daten in offenen Formaten und im eigenen Zugriff

Datenbestände sind der Teil mit den höchsten Exit-Kosten, weil Schemata, gespeicherte Prozeduren und Schnittstellen mitwandern müssen. PostgreSQL ist die naheliegende offene Zielplattform, inklusive JSONB für halbstrukturierte Daten und pgvector für KI-Anwendungen, die sonst regelmäßig als Argument für externe Dienste herhalten. Grundkurs, Datensicherung und Performance-Tuning bilden dafür eine Kette.

Sicherheit und Nachweisbarkeit selbst in der Hand

Souveränität heißt auch, Vorfälle ohne Hersteller aufklären zu können. Dazu gehören Härtung mit SELinux, Firewalling mit nftables, ein eigener Log-Stack sowie Monitoring mit Prometheus und Grafana. Die SELinux-Reihe von den Grundlagen bis zur Policy-Modul-Entwicklung, der Linux Security Intensivkurs und die Digitale Forensik für Linux und Unix Systeme decken diese Kette ab.

Automatisierung als Voraussetzung, nicht als Kür

Ein selbst betriebener Stack skaliert nur, wenn Konfiguration reproduzierbar ist. Ansible für Konfigurationsmanagement, Git und GitLab CI für Versionierung und Auslieferung sowie Terraform dort, wo Infrastruktur deklarativ beschrieben wird, senken den Personalaufwand deutlich. Ohne diese Ebene wird der Eigenbetrieb teurer als das, was du abgelöst hast.

Tutorial

Souveränität prüfbar machen: Inventar, Exit-Test, eigene Lieferkette

Souveränität lässt sich messen, statt sie zu behaupten. Der Ablauf hier beginnt mit einem Inventar der tatsächlichen Abhängigkeiten, geht über einen echten Exit-Test und endet bei den drei Bausteinen, die den Unterschied machen: eigene Paketversorgung, eigene Schlüssel, reproduzierbarer Betrieb. Alle Schritte laufen auf vorhandenen Systemen, ohne dass du vorher etwas migrieren musst.

Schritt 1: Abhängigkeiten sichtbar machen

Die erste Frage ist nicht, was ihr ersetzen wollt, sondern woran ihr tatsächlich hängt. Das lässt sich auf jedem Host in wenigen Minuten feststellen.

Woher kommt eigentlich die Software?

# RHEL / Rocky / Alma
rpm -qa --qf '%{VENDOR}\n' | sort | uniq -c | sort -rn

# Debian / Ubuntu
grep -rhE '^(deb |Types:|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

# Container: welche Registries ziehen wir?
sudo podman images --format '{{.Repository}}' | cut -d/ -f1 | sort | uniq -c | sort -rn

# Ausgehende Ziele, die im Betrieb erreichbar sein muessen
sudo ss -tnp state established | awk '{print $4, $5}' | sort -u | head -30

Das Ergebnis ist die ehrlichste Antwort auf die Frage nach der Unabhängigkeit. Jede Zeile ist ein Anbieter, dessen Preis-, Lizenz- oder Verfügbarkeitsentscheidung euch direkt trifft. Erst danach lohnt sich die Diskussion über Alternativen.

Sechs Ebenen, sechs Fragen

Ebene	Typische Bindung	Ausweg, der wirklich trägt
Betriebssystem	Supportvertrag, Zertifizierungsmatrix	Zweite Distribution im Betrieb halten, Konfiguration in Ansible statt im Klickpfad
Virtualisierung	Lizenzmodell, Managementschicht	KVM-basierte Plattform, VM-Platten in offenen Formaten
Daten	Proprietäres Dateiformat, exklusive API	Export in offene Formate, regelmäßig zurückgespielt
Identität	Cloudverzeichnis als einziger Anmeldeweg	Eigener Identity-Provider mit OIDC und SAML
Verschlüsselung	Schlüssel im Hersteller-KMS	Schlüssel im eigenen Zugriff, LUKS mit eigenem Tang-Server, eigene PKI
Betrieb	Wissen liegt beim Dienstleister	Runbooks im eigenen Git, mindestens zwei Personen pro System

Schritt 2: Den Exit-Test wirklich durchführen

Ein Ausstiegsplan, den nie jemand ausprobiert hat, ist eine Absichtserklärung. Der Test besteht aus zwei Teilen: Kommen die Daten raus, und laufen sie woanders wieder an?

Daten in ein Format bringen, das ohne den Hersteller lesbar bleibt

# Datenbanken
pg_dump -Fc -d crm -f /srv/exit/crm.dump
mysqldump --single-transaction --routines --events crm > /srv/exit/crm.sql

# Dokumente stapelweise nach ODF wandeln
find /srv/fileserver -name '*.docx' -print0 \
  | xargs -0 -n 50 soffice --headless --convert-to odt --outdir /srv/exit/odf

# Gegenprobe: laesst sich der Dump wirklich einspielen?
createdb crm_restoretest
pg_restore -d crm_restoretest /srv/exit/crm.dump
psql -d crm_restoretest -c '\dt' | head

Der letzte Block ist der eigentliche Test. Ein Export ohne erfolgreichen Restore ist eine Datei, kein Ausweg.

Bedingungen, die der Test erfüllen muss

Wiederherstellung auf eigener Hardware ohne HerstellerportalManche Produkte brauchen zum Starten eine Aktivierung oder einen Lizenzserver im Netz des Herstellers. Das merkst du erst, wenn du es abschaltest.
Aufbau ohne Internetzugang durchspielenWenn im Ernstfall die Leitung fehlt, hilft ein Paketspiegel im Haus. Der Test zeigt, welche Downloads mitten im Aufbau doch noch nach außen greifen.
Der Test wird von jemandem gefahren, der das System nicht gebaut hatDamit prüfst du gleichzeitig die Dokumentation. Wo die zweite Person hängenbleibt, fehlt eine Zeile im Runbook.
Fester Termin, mindestens einmal im JahrOhne Termin verfällt der Plan mit dem nächsten Versionswechsel. Ein geübter Ausstieg ist außerdem das stärkste Argument in jeder Vertragsverhandlung.

Schritt 3: Die eigene Versorgungskette aufbauen

Ein System ist erst dann betreibbar, wenn du es auch dann installieren und aktualisieren kannst, wenn die Leitung nach draußen fehlt oder ein Repo verschwindet.

Pakete und Images ins eigene Netz spiegeln

# RPM-Spiegel
sudo dnf install -y dnf-plugins-core createrepo_c
sudo dnf reposync --repoid=baseos --repoid=appstream \
     --newest-only --download-metadata -p /srv/mirror

# Debian/Ubuntu: aptly oder debmirror uebernehmen dieselbe Aufgabe

# Container-Images in die eigene Registry holen
skopeo copy --all docker://docker.io/library/nginx:stable \
     docker://registry.intern.example/library/nginx:stable
skopeo inspect docker://registry.intern.example/library/nginx:stable | grep -i digest

--newest-only hält den Spiegel klein, ohne dass du auf Sicherheitsupdates verzichtest. Bei Images gilt: Tags sind veränderlich, Digests nicht. Für Produktivsysteme referenzierst du image@sha256:..., dann bekommst du morgen dasselbe Image wie heute.

Stückliste führen und auswerten

syft registry.intern.example/library/nginx:stable \
     -o cyclonedx-json > /srv/sbom/nginx.cdx.json
grype sbom:/srv/sbom/nginx.cdx.json

Mit einer gepflegten Software-Stückliste beantwortest du die Frage sind wir betroffen in Minuten statt in Tagen. Der Cyber Resilience Act macht die Stückliste für Produkte mit digitalen Elementen ohnehin verbindlich, ihr baut sie also nicht auf Vorrat.

Schritt 4: Schlüssel und Anmeldung im eigenen Zugriff

Wer die Schlüssel nicht hat, betreibt die Daten nicht. Das ist die Ebene, auf der Souveränität am konkretesten wird, und gleichzeitig die, die am leichtesten übersehen wird.

Plattenverschlüsselung mit eigenem Schlüsselserver

sudo cryptsetup luksDump /dev/nvme0n1p3 | head -20

# Netzgebundenes Entsperren gegen einen Tang-Server im eigenen Netz
sudo dnf install -y clevis clevis-luks clevis-dracut
sudo clevis luks bind -d /dev/nvme0n1p3 tang '{"url":"http://tang01.intern.example"}'
sudo dracut -fv --regenerate-all
sudo clevis luks list -d /dev/nvme0n1p3

Netzgebundene Entschlüsselung nimmt dir das Passwortproblem beim Reboot ab, ohne dass ein Schlüssel bei einem Cloudanbieter liegt. Die LUKS-Passphrase gehört trotzdem in den Tresor: Ohne Netzverbindung zum Tang-Server bootet die Maschine nicht durch.

Vier Punkte auf derselben Ebene

Ein eigener Identity-Provider mit OIDC und SAML entkoppelt die Anmeldung vom Cloudverzeichnis. Solange der einzige Anmeldeweg bei einem Anbieter liegt, ist jeder Ausfall dort ein Totalausfall bei euch.
Eine eigene interne PKI kostet wenig und ersetzt gekaufte Zertifikate für alles, was nicht öffentlich erreichbar ist. Wichtig ist die Automatisierung der Erneuerung, sonst tauschst du ein Abhängigkeitsproblem gegen ein Ablaufproblem.
Backupverschlüsselung mit eigenem Schlüssel. Ein Backup, das nur der Anbieter entschlüsseln kann, ist im Streitfall kein Backup.
Schlüsselwechsel geübt, nicht nur dokumentiert. Der Ernstfall für einen Schlüsselwechsel ist immer ein schlechter Zeitpunkt zum Lesen der Anleitung.

Schritt 5: Betrieb, der ohne Einzelpersonen funktioniert

Der letzte und härteste Baustein ist kein Produkt. Souveränität scheitert im Alltag selten an der Technik, sondern daran, dass genau eine Person weiß, wie ein System wieder hochkommt.

Reproduzierbarkeit nachweisen

# Laeuft die Beschreibung des Soll-Zustands noch gegen die Realitaet?
ansible-playbook -i inventory site.yml --check --diff

# Gibt es die Installationsbeschreibung ueberhaupt noch?
sudo head -40 /root/anaconda-ks.cfg          # RHEL / Rocky / Alma
ls -l /var/log/installer/autoinstall-user-data 2>/dev/null   # Ubuntu

git -C /srv/infra log --oneline -5

Ein --check --diff-Lauf gegen die Produktion ist der billigste Souveränitätstest, den es gibt: Er zeigt dir in einer Ausgabe, wie weit die dokumentierte Beschreibung vom laufenden System abweicht. Jede Abweichung ist Wissen, das nur im Kopf existiert.

Woran du merkst, dass es trägt

Jedes kritische System ist aus Code neu aufbaubarSolange der Neuaufbau Handarbeit ist, hängt der Betrieb an Personen und Erinnerung. Aus Code aufgebaut, ist er wiederholbar und prüfbar.
Konfiguration liegt im eigenen Git, nicht nur im HerstellerportalEin Portal, auf das ihr keinen Zugriff mehr habt, nimmt sonst die gesamte Betriebsdokumentation mit.
Runbooks für die fünf häufigsten StörungenDie Fälle, die nachts anfallen, sind fast immer dieselben. Fünf gute Runbooks bringen mehr als ein Handbuch, das niemand liest.
Mindestens zwei Personen pro kritischem SystemEin Bus-Faktor von eins ist die härteste Abhängigkeit überhaupt, und es ist die einzige, gegen die kein Vertrag hilft.
Qualifizierung ist eingeplant, nicht Reaktion auf den AusfallDer Wechsel auf offene Systeme verschiebt Aufwand vom Lizenzbudget in den Betrieb. Ohne eigenes Können tauscht ihr nur den Anbieter, dem ihr ausgeliefert seid.

Passende Kurse

Kurse zu digitaler Souveränität bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Linux Grundkurs (LPI01) 3 Tage Präsenz oder Live-Online nächster Termin 24.08.2026 Garantietermin Zum Kurs Linux Systemadministration und Shell-Scripting - Kompaktkurs 5 Tage Präsenz nächster Termin 30.11.2026 Zum Kurs Proxmox Grundkurs: KVM, LXC, Storage und Backup 3 Tage Präsenz nächster Termin 21.09.2026 Garantietermin Zum Kurs Migration von VMware zu Proxmox 3 Tage Präsenz oder Live-Online nächster Termin 21.09.2026 Garantietermin Zum Kurs Kubernetes Grundkurs 3 Tage Präsenz nächster Termin 02.11.2026 Zum Kurs

Unverbindlich beraten lassen Alle LPI-Kurse ansehen

Gut zu wissen

Häufige Fragen zu digitaler Souveränität

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Was bedeutet digitale Souveränität in der IT konkret?

Digitale Souveränität bedeutet, dass du über Daten, Systeme und deren Weiterentwicklung selbst bestimmen kannst. Praktisch heißt das: offene Datenformate und dokumentierte Schnittstellen, die Möglichkeit, Software im eigenen Rechenzentrum oder bei einem Anbieter deiner Wahl zu betreiben, Einsicht in den Quellcode kritischer Komponenten und ausreichend eigenes Personal, um im Störfall handlungsfähig zu bleiben. Open Source ist dabei ein Mittel, kein automatischer Nachweis.

Ist Open Source automatisch souverän?

Nein. Auch quelloffene Software kann von einem einzelnen Anbieter kontrolliert werden, etwa über Lizenzwechsel, ein proprietäres Management-Frontend oder einen Managed Service, aus dem du deine Daten nur mühsam herausbekommst. Entscheidend sind die Fragen, ob du die Software ohne den Hersteller betreiben könntest, ob deine Daten in einem lesbaren Format vorliegen und ob jemand im Haus den Stack versteht. Sind diese drei Punkte erfüllt, ist der Lizenztext zweitrangig.

Wo fängt man bei einer Migration sinnvoll an?

In der Regel dort, wo die Abhängigkeit teuer ist und die Nutzerzahl klein bleibt, also in der Infrastruktur. Ein Wechsel der Virtualisierungsplattform oder der Datenbank betrifft ein überschaubares Team, hat aber unmittelbaren Effekt auf Lizenzkosten und Betriebshoheit. Der Arbeitsplatz ist der schwierigste Teil, weil dort Gewohnheiten, Fachverfahren und Dokumentvorlagen hängen, und er sollte erst angegangen werden, wenn Betrieb und Support tragfähig sind.

Wie hoch ist der Schulungsaufwand für ein Team, das bisher Windows-lastig arbeitet?

Für den Einstieg in den Linux-Betrieb sind erfahrungsgemäß mehrere aufeinander aufbauende Wochen nötig, verteilt über einige Monate. Ein üblicher Weg führt über Grundlagen und Systemadministration, dann Shell-Scripting und Netzwerkdienste, danach die Spezialthemen wie Virtualisierung, Container oder Datenbanken. Wichtig ist, dass zwischen den Blöcken echte Systeme betreut werden, weil Wissen ohne Anwendung schnell verfällt. Alle Kurse gibt es bei cmt Live-Online oder vor Ort.

Was ist der Unterschied zwischen dieser Seite und euren Angeboten für Behörden?

Die Seiten zur Digitalisierung in Behörden und zum öffentlichen Dienst beschreiben Rahmenbedingungen, Zielgruppen und Beschaffungswege. Diese Seite betrachtet dasselbe Thema aus der technischen Perspektive und ordnet ein, welche Linux- und Open-Source-Bausteine welchen Teil der Abhängigkeit auflösen. Beides ergänzt sich, ist aber für unterschiedliche Rollen geschrieben.

Quellen

ZenDiS: Zentrum für Digitale Souveränität

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.

Rückmeldung aus dem Kurs „Kubernetes Grundkurs“

“

Erwartungen wurden erfüllt. Angekündigte Themen in hinreichender Tiefe bearbeitet. Zudem gutes Zeitmanagement.

Rückmeldung aus dem Kurs „Source Code Management und CI / CD (DO4)“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.