Digitale Souveränität

Der weite Weg

Schon nicht mehr neu, aber mit brachialer Wucht nimmt das Buzzword der Digitalen Souveränität Fahrt auf im Bereich „Governance, Risk, Compliance“ (GRC).

Was bedeutet der Begriff?
Das Bundesministerium für Digitales und Staatsmodernisierung (BMDS) definiert ihn so:

„Digitale Souveränität“ beschreibt „die Fähigkeiten und Möglichkeiten von Individuen und Institutionen, ihre Rolle(n) in der digitalen Welt selbstständig, selbstbestimmt und sicher ausüben zu können“

https://bmds.bund.de/themen/digitale-souveraenitaet/digitale-souveraenitaet-in-der-oeffentlichen-verwaltung

Bei Heise findet man folgende Auffassung zur tieferen Bedeutung des Begriffes:

Letztlich bedeutet digitale Souveränität nämlich, in Kenntnis von Sach- und Rechtslage, eine souveräne Entscheidung zu treffen. Gerade im Cloud-Bereich mag das keine einfache Aufgabe sein, aber eine lösbare.

https://www.heise.de/hintergrund/Digitale-Souveraenitaet-Wie-souveraen-sind-die-EU-Angebote-der-Hyperscaler-10461972.html

Außer der Frage, was Digitale Souveränität nun konkret ist bleiben eine Menge weiterer Fragen offen, zum Beispiel: warum wollen wir das? Und wie geht man damit um?

Externer Druck und Compliance

Die Faktenlage ist klar: Organisationen in der EU befinden sich in einer starken technologischen Abhängigkeit von (überwiegend) nordamerikanischen IT-Lieferanten. Dazu gehören Hardware-, Software- und seit etwa zehn Jahren auch Cloud-Anbieter.
Für die Die Zukunft ist absehbar, dass die aktuelle US-Administration diese Abhängigkeit als Werkzeug nutzt, um politischen Druck auszuüben.

Über äußere Umstände hinaus liefert die Notwendigkeit zur Gesetzestreue (Compliance) gute Gründe, die Verlässlichkeit und Vertrauenswürdigkeit von Technologie-Anbietern zu hinterfragen. Die NIS-2 Richtlinie, die DORA-Verordnung (für Finanz- und Versicherungsdienstleister) der EU fordern ebenso wie die DSGVO Maßnahmen zur Transparenz und Kontrolle über den Umgang mit Informationen, die speziell mancher US-Anbieter bei strenger Betrachtung eben nicht erfüllt.

Wenn EU-Organisationen wie Firmen oder öffentliche Verwaltungen sich diesem Druck entziehen möchten, haben sie auf technischer Ebene folgende Handlungsoptionen: Nutzung nicht-amerikanischer Hard- und Software bzw. Umzug in europäische Clouds.

Was so einfach klingt, ist von größter Brisanz – denn die daraus erwachsenden Projekte sind technisch und organisatorisch komplex.

Im Grunde läuft der Prozess in etwa so:

Die technischen Kernprobleme (bei IaaS) sind Schnittstellen, nämlich sowohl solche zu anderen Anwendungen als auch interne APIs zu Cloud-Diensten. Speziell die APIs haben die häßliche Eigenschaft, anbieterspezifisch zu sein. Daraus ergibt sich die gefürchtete Abhängigkeit vom Anbieter, ein Vendor-LockIn. Sie besteht zwischen den großen Hyperscalern (aws, Azure, Google Cloud) ebenso wie zu (und zwischen) europäischen Cloud-Anbietern oder privaten Clouds (sogenannte Cloud-Exits sind in Wahrheit fast immer Umzüge in eigene, also private Clouds).¹

Bei SaaS ist es nicht damit getan, die Informationen aus dem Bestandssystem „herauszuholen“ – meist steht ein Systemwechsel zu Diskussion.

Wichtig: Methode und Fokus!

Ein Umzugsprojekt auf (egal welche) andere Technologie muss sich daher daraus fokussieren, wie die Applikationsumgebungen abgebildet werden können. Wie oben gesagt, ist der Schlüssel dazu die Kenntnis und Umsetzung von Schnittstellen.
Die Aufwände abzuschätzen ist schwierig, denn sie hängen von der jeweiligen Software-Architektur ab. Da braucht man Sachkenntnis und es zeigt sich hier bereits, wie aufwendig das Unterfangen wird.

Aufgrund der bereits im Rahmen von BCM oder ISMS ermittelten Relevanz der Anwendungen für die Kernprozesse der Organisation² sollte daher abgewogen werden, ob der Umzugsaufwand für alle Cloud-abhängigen Applikationen lohnt.

Für den Umzug einer Applikation von hoher Relevanz sind Fragen wie Rückfall- oder RollBack-Szenarien oder akzeptable Ausfallzeiten (Down-Times) zu klären – aber als „wir“ uns vor zehn Jahren auf den Weg in die Cloud machten, war schon reichlich Gelegenheit, den Umgang damit zu üben.

Diese und weitere Überlegungen wie z.B. die Risiken der Ziel-Anbieter und ggfs. Ziel-Architektur fließen in eine Risiko-Abschätzung ein, die schließlich in einen priorisierten Maßnahmenkatalog mündet.³

<kes> zu alternativen Anbietern:

„Beim Risikomanagement für Drittanbieter gilt es, klare Kriterien zu definieren: Rechtszuständigkeit, Kontrollmöglichkeiten, Transparenz, Support und Zertifizierungen wie SOC-2 sind wichtige Prüfpunkte. Automatisierte Bewertungsprozesse und kontinuierliches Monitoring helfen, Risiken frühzeitig zu erkennen und zu adressieren. Geofencing und technische Kontrollmechanismen sichern den Zugriff auch bei mobilen oder cloudbasierten Lösungen ab.“

https://www.kes-informationssicherheit.de/artikel/digitale-souveraenitaet-anforderungen-chancen-und-praxis-fuer-unternehmen/

Übrigens: bewährte Risiko-Strategien greifen auch im Bereich der Digitalen Souveränität – speziell Risikostreuung, im IT-Umfeld besonders mit dem Schlagwort „Multi-Vendor-Strategie“ verknüpft.

Interessanterweise ist der Ansatz der Vielfalt auch im Bereich der technischen Umsetzung, der Cybersicherheit, allgemein üblich⁴ und Bestrebungen großer Hersteller, sich als „One-Stop-Shopping“-Plattformen zu etablieren, haben sich noch nicht flächendeckend durchgesetzt – vielleicht gut so.

Doch nur ein anderes Wort für Resilienz?

Digitale Souveränität wird zuweilen abgetan mit dem Verweis auf Cyber-Resilienz, ein bekanntes Schlagwort mit dem man die Fähigkeit beschreibt, die Folgen von Cyberangriffen zu mindern oder abzufedern.

Im Falle eines Cyberangriffes ist es unerheblich, ob man selbständig, selbstbestimmt und sicher (siehe Zitat ganz oben) in der digitalen Welt unterwegs war – man muss mit den Folgen klarkommen – oder wie Heise es ausdrückt:

Resilienz hingegen kommt dann ins Spiel, wenn der Angriff bereits erfolgt ist und man den Betrieb trotzdem weiterführen oder zumindest möglichst schnell wieder aufnehmen muss.

https://www.heise.de/hintergrund/Was-ist-eigentlich-Cyber-Resilienz-Eine-Begriffsklaerung-11108539.html

Man kann also theoretisch Digitale Souveränität erreichen ohne eine Spur von Cyber-Resilizenz – und umgekehrt!

Die Begriffe sind nicht austauschbar.

Kann KI das nicht erledigen?

Natürlich kann KI dabei helfen, die Voraussetzungen für einen Applikationsumzug zu schaffen und die durchführung vereinfachen.
Es ist allerdings nicht trivial und erspart bestenfalls Teile der vorbereitenden Analysearbeit, die unter dem Motto steht: „entdecke Deine eigene IT“ – Merke: ohne solide Faktenbasis ist auch die Einsichtsfähigkeit einer KI begrenzt.

Um bei solchen Vorhaben einen systematisch korrekten Ansatz zu wählen, bietet sich ein methoden-kompetenter Partner an, gewissermaßen die natürliche Intelligenz (NI) als Gegengewicht zur KI 😉

Sprechen Sie uns einfach an.

Die <kes> sieht Digitale Souveränität nicht als Ziel, das man mit Glück irgendwann erreicht – sondern als Weg.

„Digitale Souveränität ist kein Zustand, sondern ein fortlaufender Prozess. Unternehmen und Behörden müssen kontinuierlich ihre Risiken bewerten, ihre Strategien anpassen und neue Technologien integrieren. Der Weg führt über Transparenz, klare Governance, den gezielten Einsatz von Technologie und die Einhaltung regulatorischer Vorgaben. Kooperation, Absicherung und Eigenständigkeit müssen sich ergänzen – nicht ausschließen.“

https://www.kes-informationssicherheit.de/artikel/digitale-souveraenitaet-anforderungen-chancen-und-praxis-fuer-unternehmen/

Weiterführendes Material

Wer sich mit den konkreten Anforderungen an „digital souverände“ Clouds näher befassen möchte, dem sei das Positionspapier der Datenschutzkonferenz (2023) empfohlen:
https://datenschutzkonferenz-online.de/media/weitere_dokumente/2023-05-11_DSK-Positionspapier_Kritierien-Souv-Clouds.pdf

1. Übrigens sind Lift-and-Shift-Ansätze bei Cloud-Exits, ganz ähnlich wie beim umgekehrten Weg, technisch meist nicht vorteilhafte Herangehensweisen für einen Applikations-Umzug ↩︎
2. natürlich sind aus den prozessen die Informationsarten abzuleiten und eine Informationsklassifizierung umzusetzen ↩︎
3. die vielen Zwischenschritte von der Einbindung von Stakeholdern bis zur Maßnahmenpriorisierung sollen nicht verschwiegen werden, aber diese Darstellung soll damit auch nicht überfrachtet werden ↩︎
4. Prüfen Sie selbst: Von wem stammen ihre Malware-Protection, Firewall & VPN, IAM-Tools, Backup-Management, Monitoring, MDM…? ↩︎