Strategie & Migration

Digitale Souveränität: unabhängiger werden mit Open Source

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

5 Kapitel mit allen Befehlen
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

  1. 01 Arbeitsplatz und Office-Formate
  2. 02 Betriebssystem und Systembetrieb
  3. 03 Virtualisierung und Storage
  4. 04 Container- und Anwendungsplattform
  5. 05 Daten, Datenbanken, Schnittstellen
  6. 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.

01

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 müssen
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

EbeneTypische BindungAusweg, der wirklich trägt
BetriebssystemSupportvertrag, ZertifizierungsmatrixZweite Distribution im Betrieb halten, Konfiguration in Ansible statt im Klickpfad
VirtualisierungLizenzmodell, ManagementschichtKVM-basierte Plattform, VM-Platten in offenen Formaten
DatenProprietäres Dateiformat, exklusive APIExport in offene Formate, regelmäßig zurückgespielt
IdentitätCloudverzeichnis als einziger AnmeldewegEigener Identity-Provider mit OIDC und SAML
VerschlüsselungSchlüssel im Hersteller-KMSSchlüssel im eigenen Zugriff, LUKS mit eigenem Tang-Server, eigene PKI
BetriebWissen liegt beim DienstleisterRunbooks im eigenen Git, mindestens zwei Personen pro System
02

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: lässt 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.
03

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 übernehmen 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. Wer selbst Produkte mit digitalen Elementen auf den Markt bringt, muss nach dem Cyber Resilience Act ab Dezember 2027 ohnehin eine Stückliste führen. Alle anderen brauchen sie, um von Lieferanten eine Stückliste zu verlangen und die Antwort prüfen zu können.

04

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.
05

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
# Läuft die Beschreibung des Soll-Zustands noch gegen die Realität?
ansible-playbook -i inventory site.yml --check --diff

# Gibt es die Installationsbeschreibung überhaupt 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.
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Passender Lernpfad

Karrierepfad

Dein Weg zum Linux Junior Administrator (LPIC-1)

Du willst Linux im Arbeitsalltag sicher bedienen, Systeme zuverlässig verwalten und dich gezielt auf die LPIC-1 Prüfung vorbereiten? In diesem Lernpfad baust du Schritt für Schritt das Wissen auf, das du als Linux Junior Administrator brauchst: von der Kommandozeile über Benutzer- und Rechteverwaltung bis zu Netzwerkgrundlagen und Systemdiensten.

Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Guter Einstieg, der alle wichtigen Vokabeln aus dem Themenbereich erklärt, um "Fachchinesisch" zu verstehen und gleichzeitig Lust auf mehr Linux macht.
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Gut zu wissen

Häufige Fragen zu digitaler Souveränität

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

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.
Reicht es, in eine souveräne Cloud zu wechseln?
Nur, wenn der Anbieter alle vier Fragen beantwortet: wo die Daten liegen, wer sie betreibt, wem die Technologie gehört und welchem Recht der Betreiber unterliegt. Viele Angebote lösen nur den Standort, die Technologie bleibt proprietär und der Ausstieg so schwer wie vorher. Welche Anbieter welche Stufe erreichen, ordnet die Seite Souveräne Cloud: Anbieter im Überblick ein. Hier geht es um den anderen Teil, die Linux- und Open-Source-Bausteine, die du selbst betreiben kannst, im eigenen Rechenzentrum oder bei einem Hoster deiner Wahl. Wie Behörden den Umstieg organisieren, beschreibt der Fahrplan für Open Source in Behörden.

Zuletzt geprüft am 05. Oktober 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick

Passt thematisch dazu

Wo beschafft statt selbst gebaut wird, entsteht die nächste Abhängigkeit bereits in der Leistungsbeschreibung, und im Vergabevermerk fehlt dann regelmäßig die Begründung, die jede Verengung des Bieterkreises braucht .

Für Cloud-Dienste hat der Exit-Test inzwischen eine rechtliche Stütze, und für die Vertragsverhandlung lohnt sich der Blick darauf, was der EU Data Act beim Anbieterwechsel verlangt .

Aus einem anderen Bereich von cmt: Weiterbildung für den öffentlichen Dienst

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

Yves Hoppe

Weiterbildung & Beratung

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

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

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

Nächster Schritt

Souveränität braucht Leute, die den Stack betreiben können

Wenn du gerade eine Migration planst oder erst einmal sortieren willst, welche Abhängigkeit dich am härtesten trifft, sprich mit uns über den passenden Ausbildungsweg für dein Team. Wir stellen aus dem bestehenden Linux-, Proxmox-, Kubernetes- und PostgreSQL-Programm eine Reihenfolge zusammen, die zu deinem Zeitplan passt, wahlweise Live-Online, im Schulungszentrum oder als Inhouse-Kurs auf deiner eigenen Umgebung.