In den meisten Diskussionen zum Thema Souveränität steht im Mittelpunkt, was Anbieter über ihre Produkte sagen. Viel aufschlussreicher ist es jedoch, sich darauf zu konzentrieren, was Anbieter tatsächlich umgesetzt haben. Architektur lässt sich schwerer vortäuschen als Marketing. Die Designentscheidungen, die ein Anbieter bereits Jahre vor dem Aufkommen von Souveränität als Beschaffungsanforderung getroffen hat, entscheiden oft darüber, ob Souveränität in der Praxis umgesetzt werden kann oder lediglich in einem Vertrag beschrieben wird.

Manche Designentscheidungen bewahren die Kontrolle des Kunden. Andere geben sie preis. Sobald ein System auf der Grundlage bestimmter Entscheidungen aufgebaut ist, lässt sich die daraus resultierende Souveränitätslage nicht mehr durch vertragliche Nachträge oder juristische Spielchen nachträglich ändern. Die Architektur ist die Antwort.

Die Frage nach dem kryptografischen Schlüssel ist der eindeutigste Test

Der eindeutigste architektonische Maßstab für Souveränität ist die Frage, wer die kryptografischen Schlüssel besitzt. Nicht, wer vertraglich verpflichtet ist, sie nicht zu verwenden, oder wer sich bereit erklärt hat, sie unter normalen Umständen nicht preiszugeben, sondern wer sie tatsächlich besitzt.

Zwei Architekturansätze führen zu zwei grundlegend unterschiedlichen Haltungen in Bezug auf die Souveränität.

Vom Anbieter verwahrte Schlüssel. Der Anbieter verwahrt als Betreiber des Dienstes die Schlüssel, die die Kundendaten schützen. Der Anbieter verpflichtet sich vertraglich, diese Schlüssel nicht für andere Zwecke als die Erbringung der Dienstleistung zu verwenden. Der Schutz des Kunden wird durch den Vertrag, die Richtlinien des Anbieters und die operative Integrität des Anbieters gewährleistet.

Vom Kunden verwahrte Schlüssel. Der Kunde verwahrt die Schlüssel in einer von ihm kontrollierten Schlüsselverwaltungsinfrastruktur. Der Anbieter hat als Betreiber des Dienstes keine technische Möglichkeit, auf die geschützten Daten zuzugreifen – selbst wenn er von einer Justizbehörde dazu gezwungen wird, selbst bei internen Sicherheitsverletzungen und selbst bei Beendigung des Vertrags.

Im ersten Modell hängt die Vertraulichkeit der Kundendaten von der fortgesetzten Zusammenarbeit, der Integrität und der Widerstandsfähigkeit des Anbieters gegenüber Zwangsmaßnahmen ab. Im zweiten Modell hängt sie von der eigenen Schlüsselverwaltung des Kunden ab.

Dies ist vor allem unter widrigen Umständen von Bedeutung: bei rechtlichem Zwang, Kompromittierung des Anbieters, Vertragsstreitigkeiten oder geopolitischen Störungen. Im Normalbetrieb sehen die beiden Architekturen identisch aus. Unter Belastung unterscheiden sie sich jedoch deutlich. Ein Anbieter, der die Schlüssel verwahrt, kann durch einen Gerichtsbeschluss in seinem Zuständigkeitsbereich, durch staatlichen Zwang oder durch einen ausreichend ausgeklügelten Angriff auf seine Schlüsselverwaltungsinfrastruktur zur Offenlegung von Daten gezwungen werden. Ein Anbieter, der die Schlüssel nie verwahrt hat, kann nichts offenlegen, auf das er keinen Zugriff hat.

Für Kunden, denen Souveränität besonders wichtig ist, trägt diese eine architektonische Entscheidung mehr zur Souveränität bei als die meisten vertraglichen Formulierungen zusammen. Und diese Entscheidung muss bereits in einer frühen Phase der Systemkonzeption getroffen werden. Die Einbindung von kundenseitigen Schlüsseln in eine Architektur mit herstellerseitigen Schlüsseln ist keine Umgestaltung, sondern eine Neuprogrammierung.

Die Bereitstellungstopologie bestimmt die operative Souveränität

Der zweite architektonische Test besteht darin, zu prüfen, ob das System unabhängig von der Cloud-Infrastruktur des Anbieters betrieben werden kann.

Eine reine SaaS-Architektur, bei der der Kunde einen vom Anbieter betriebenen Cloud-Dienst abonniert, bietet dem Kunden Komfort und verleiht dem Anbieter dauerhafte Betriebshoheit. Der Kunde kann das System nicht betreiben. Dies ist ausschließlich dem Anbieter vorbehalten. Die Kontinuität des Kunden hängt von der Kontinuität des Anbieters ab. Die Compliance des Kunden hängt von der Compliance-Situation des Anbieters ab. Der geografische Standort der Daten des Kunden hängt davon ab, welche Konfigurationsoptionen der Anbieter innerhalb seiner Cloud anbietet. Der Kunde ist strukturell gesehen ein Mandant, und die betriebliche Souveränität wurde auf den Anbieter übertragen.

Eine Bereitstellungstopologie, die lokal betriebene, vom Kunden verwaltete Konfigurationen umfasst, bei denen der Kunde das System in seiner eigenen Infrastruktur, mit seinem eigenen Betriebsteam, in seinem eigenen Rechtsraum und auf seiner eigenen Hardware betreiben kann, führt zu einer strukturell anderen Souveränitätslage. Der Kunde kann das System vollständig vom öffentlichen Internet isolieren. Der Kunde kann das System auch während Phasen mit Verbindungsstörungen weiterbetreiben. Der Kunde kann das System seinen eigenen Prüfungen, seiner eigenen Änderungskontrolle und seiner eigenen Governance unterwerfen. Der Anbieter liefert die Software. Der Kunde betreibt sie.

Die Lösungen, die die Souveränität am stärksten wahren, gehen sogar noch einen Schritt weiter. „Air-Gapped“-Konfigurationen, bei denen das System in einer Kundenumgebung läuft, die zu betrieblichen Zwecken keinerlei Verbindung zur Infrastruktur des Anbieters aufweist, stellen die maximale operative Kontrolle dar, die ein Anbieter bieten kann. Der Kunde ist betrieblich unabhängig. Updates werden über kontrollierte Kanäle übertragen, die der Kunde verwaltet. Etwaige Telemetriedaten werden über vom Kunden kontrollierte Pfade übertragen. Das Fortbestehen des Anbieters ist keine Voraussetzung für den fortgesetzten Betrieb des Kunden.

Dieses Spektrum an Bereitstellungstopologien – von reinem SaaS auf der einen Seite bis hin zu einer vollständig isolierten Umgebung auf der anderen Seite – bildet die Achse der operativen Souveränität. Bei den meisten Diskussionen über Souveränität geht es darum, wo auf dieser Achse ein bestimmter Kunde angesiedelt sein muss und ob die Architektur des Anbieters diese Position unterstützt.

Ein Anbieter, dessen Architektur ausschließlich SaaS unterstützt und keine Option für eine lokale Bereitstellung bietet, schränkt die operative Souveränität des Kunden grundlegend ein – ganz gleich, wie sicher seine Cloud auch sein mag. Ein Anbieter, dessen Architektur das gesamte Spektrum abdeckt – SaaS für Kunden, die Komfort wünschen, lokale Bereitstellung für Kunden, die operative Kontrolle benötigen, und Air-Gapped-Lösungen für Kunden, die in geheimen oder kritischen Umgebungen tätig sind –, gibt dem Kunden die Wahl, wie er seine Souveränität gestalten möchte. Der architektonische Unterschied ist das Ergebnis jahrzehntelanger Investitionen und nicht nur eine Frage der Konfiguration.

Die Frage nach der operativen Einheit trennt das Marketing vom Wesentlichen

Über die technische Architektur hinaus gibt es eine organisatorische Entscheidung, die oft noch entscheidender ist: Wer ist die eigentliche operative Einheit für Kunden, bei denen Fragen der Souveränität eine Rolle spielen, und inwieweit verfügt diese Einheit über operative Substanz?

Bevor diese Frage von Bedeutung ist, muss eine andere Frage beantwortet werden: Erfüllt die Rechtsordnung des Mutterunternehmens des Anbieters die rechtlichen Mindestanforderungen des Kunden? Die Bewertung der Rechtshoheit wird von einer Behörde, einer Beschaffungsstelle, einer Aufsichtsbehörde oder einem Gremium durchgeführt, deren Zuständigkeit definiert, was als ausländisches rechtliches Risiko gilt. Der „Operating-Entity-Test“ ist besonders nützlich für Anbieter, deren Muttergesellschaftsrecht im Rahmenwerk des Kunden akzeptabel ist. Wenn die Rechtsordnung der Muttergesellschaft ein für den Kunden ausländisches rechtliches Risiko darstellt (Anbieter mit Hauptsitz in den USA, die im Rahmen von Beschaffungsverfahren unter EU-Hoheitsrecht verkaufen, sind das am häufigsten diskutierte Beispiel, doch dieselbe Logik gilt symmetrisch auch in umgekehrter Richtung für jede grenzüberschreitende Beschaffung), steht die Frage nach der operativen Einheit erst nach einer Schwelle, die bereits nicht erreicht wurde. Die operative Substanz ändert nichts an dem rechtlichen Risiko einer ausländischen Rechtsordnung, das die Muttergesellschaft aufgrund ihrer Gründung behält.

Die operative Einheit gibt oft Aufschluss darüber, ob Souveränität in der Praxis besteht oder nur auf dem Papier. Ein gängiges Muster ist, dass ein Anbieter mit Hauptsitz in einem Rechtsraum eine Tochtergesellschaft in einem souveränitätsrelevanten Rechtsraum gründet (typischerweise in der EU, zunehmend auch in anderen Regionen). Die Tochtergesellschaft wird als lokaler souveräner Anker präsentiert. Die Kunden schließen Verträge mit der Tochtergesellschaft ab. Die Tochtergesellschaft verfügt über die lokalen Zertifizierungen. Die Tochtergesellschaft wird in Marketingmaterialien namentlich genannt.

Die Frage, die den Unterschied zwischen Substanz und Fassade ausmacht, lautet: Was macht die Tochtergesellschaft eigentlich?

Tochtergesellschaften mit geringem Substanzgehalt dienen in erster Linie der Vertragsabwicklung und der Einhaltung gesetzlicher Vorschriften. Sie beschäftigen nur wenige Mitarbeiter, die überwiegend in den Bereichen Vertrieb und Kundenbetreuung tätig sind. Die technische Entwicklung erfolgt bei der Muttergesellschaft. Der Aufbau der Infrastruktur erfolgt im Rechtsgebiet der Muttergesellschaft. Software-Updates stammen aus von der Muttergesellschaft betriebenen Pipelines. Die Tochtergesellschaft unterzeichnet den Vertrag. Die Muttergesellschaft betreibt den Dienst. Wäre die Muttergesellschaft nicht verfügbar, könnte die Tochtergesellschaft den Betrieb nicht fortsetzen. Die Tochtergesellschaft ist eine juristische Hülle, keine operative Einheit.

Substanzstarke Tochtergesellschaften haben erhebliches operatives Gewicht. Sie beschäftigen Ingenieure, die an der Code-Basis mitarbeiten, die an lokale Kunden ausgeliefert wird. Sie betreiben die Build-Infrastruktur im jeweiligen Land unter lokalen Kontrollmechanismen. Sie steuern die Bereitstellungs- und Update-Kanäle für die Bereitstellung lokaler Varianten. Sie verfügen über die technischen und vertraglichen Voraussetzungen, um den Dienst für lokale Kunden weiter zu betreiben, falls die Muttergesellschaft ausfallen sollte. Die Tochtergesellschaft ist nicht nur als Auftragnehmer tätig, sondern betreibt den Dienst selbst.

Im Marketing ist dieser Unterschied selten erkennbar. Beide Arten von Tochtergesellschaften beschreiben sich auf dieselbe Weise. Der Unterschied zeigt sich in operativen Fragen: Wo arbeiten die Ingenieure, wo verläuft die Build-Pipeline, was ist die verlässliche Quelle für Updates, die an Behördenkunden ausgeliefert werden, und was würde passieren, wenn die Muttergesellschaft nicht mehr zur Verfügung stünde?

Für Kunden, denen Souveränität ernsthaft am Herzen liegt, sind dies die Fragen, die einen Anbieter mit einer echten, souveränen Betriebseinheit von einem Anbieter mit einer Fassade in Form einer Unternehmensstruktur unterscheiden. Und das lässt sich nicht von heute auf morgen aufbauen. Der Aufbau einer substanzstarken Tochtergesellschaft erfordert jahrelange Investitionen in technische Kapazitäten, den Aufbau von Infrastruktur, Zertifizierungsmaßnahmen und operative Autonomie. Ein Anbieter, der diese Investitionen nicht getätigt hat, bis Souveränität zu einem Beschaffungskriterium wird, kann dies nicht im Rahmen von Vertragsbedingungen nachholen.

Der Umfang der Zertifizierung als Nachweis für die operative Integrität

Zertifizierungen werden im Marketing oft als eine Liste von Logos betrachtet, die Seriosität suggerieren. Die entscheidende Frage ist jedoch nicht, wie viele Zertifizierungen ein Anbieter vorweisen kann, sondern was diese Zertifizierungen tatsächlich bestätigen.

Zertifizierungen zur Validierung des Betriebsablaufs stellen die für die Bewertung der Souveränität interessantere Kategorie dar. Dazu gehören die folgenden.

Zertifizierungen, die die Betriebsintegrität bei der Nutzung unter Geheimhaltungsauflagen bestätigen. Wenn eine nationale Sicherheitsbehörde ein System für den Einsatz mit Verschlusssachen akkreditiert, erstreckt sich die Akkreditierung auf die betriebliche Substanz und nicht nur auf den architektonischen Entwurf. Sie umfasst das System in seiner bereitgestellten Form mit seinen Betriebsabläufen, seinem Aktualisierungsmodell, seinen Zugriffskontrollen und seiner betrieblichen Lieferkette. Die Akkreditierung „NATO Restricted“, die NSA-Richtlinie „Commercial Solutions for Classified“, Zertifizierungen des BSI auf Bundesebene sowie gleichwertige Akkreditierungen von Verbündeten haben diese Tragweite.

Zertifizierungen, die den kontinuierlichen Betrieb bestätigen. Rahmenwerke zur kontinuierlichen Überwachung wie FedRAMP Klasse D (High) erfordern den fortlaufenden Nachweis der Betriebssicherheit und keine punktuelle Bewertung. SOC 2 Typ 2 bescheinigt, dass die Kontrollmaßnahmen über einen Bewertungszeitraum hinweg wirksam funktionieren und nicht nur auf dem Papier existieren. Die ISO 22301 zertifiziert speziell die Geschäftskontinuitätsmaßnahmen.

Zertifizierungen, die die kryptografische Sicherheit und die Plattformsicherheit bestätigen. Die Bewertung nach den Common Criteria auf höheren Evaluation Assurance Levels bestätigt die Angaben zur kryptografischen und Plattformsicherheit eines Produkts durch unabhängige Labortests durch Dritte.

Die Anzahl der Zertifizierungen, über die ein Anbieter verfügt, ist weniger interessant als die Frage, um welche Zertifizierungen es sich handelt und was jede einzelne davon bescheinigt. Ein Anbieter mit einer langen Liste von Zertifizierungen, die sich ausschließlich auf die Architektur beziehen, unterscheidet sich grundlegend von einem Anbieter mit einer kürzeren Liste von Zertifizierungen, die den Betrieb in mehreren Rechtsräumen bestätigen.

Das für die Souveränität relevanteste Muster ist die operative Zertifizierung durch mehrere Rechtsordnungen: Zertifizierungen mehrerer verbündeter Regierungen, die den Betrieb in geheimen oder sensiblen Einsatzbereichen bestätigen und gleichzeitig auf einer integrierten Plattform gelten. Dieses Muster ist selten und schwer zu erreichen. Es erfordert eine kontinuierliche operative Zusammenarbeit mit mehreren nationalen Sicherheitsbehörden, von denen jede ihre eigenen Bewertungsverfahren, Bedrohungsmodelle und operativen Standards hat. Ein Anbieter, der über eine operative Akkreditierung auf NATO-Ebene, eine Zertifizierung für US-Geheimhaltungsstufen sowie Zertifizierungen von verbündeten Regierungen auf Bundesebene für ein und dieselbe Produktplattform verfügt, hat operative Integrität in einer Weise unter Beweis gestellt, wie es keine einzelne Zertifizierung allein könnte.

Ein solches Zertifizierungsportfolio entsteht selten zufällig. Es spiegelt die jahrelange Zusammenarbeit mit Kunden aus dem Bereich der nationalen Sicherheit, wiederholte Bewertungszyklen und eine Architektur wider, die stabil genug ist, um die Anforderungen mehrerer Behörden gleichzeitig zu erfüllen.

Transparenz in der Lieferkette als strukturelles Merkmal

Das in modernen Rahmenwerken am stärksten gewichtete Souveränitätsziel ist die Lieferkette. Der Grund dafür ist, dass die Lieferkette der dauerhafteste Prüfstein für Souveränität ist. Der rechtliche Status kann sich durch einen Vertrag ändern. Der operative Fußabdruck kann verlagert werden. Marketingaussagen können aktualisiert werden. Wo Software entworfen, entwickelt und ausgeliefert wird, lässt sich hingegen nur schwer umgestalten.

Das architektonische Muster, das die Souveränität der Lieferkette unterstützt, ist strukturierte Transparenz. Im Einzelnen:

Die Infrastruktur sollte in der für den Kunden relevanten Rechtsordnung aufgebaut werden. Bei Bereitstellungen für einen Kunden, bei dem Fragen der Hoheitsrechte eine Rolle spielen, sollte die Build-Pipeline, die die in der Umgebung dieses Kunden ausgeführte Software erzeugt, in einer für die jeweilige Rechtsordnung geeigneten Infrastruktur laufen. Dies ist eine von der Frage nach der Rechtsordnung des Hauptsitzes getrennte Angelegenheit; letztere ist eine rechtliche Grundvoraussetzung, die an anderer Stelle im Rahmen einer gründlichen Bewertung behandelt wird. Bei der Frage zur Build-Pipeline geht es darum, wo die Build-Artefakte erstellt und signiert werden, wer Zugriff auf diese Pipeline hat und welcher rechtliche Schutz für die Artefakte selbst gilt. Beide Fragen müssen beantwortet werden. Ein Anbieter, der nur eine der beiden Anforderungen erfüllt, liefert nur eine unvollständige Antwort.

Hardware-Souveränität für kryptografische Anker. Die HSMs (Hardware-Sicherheitsmodule), die die kryptografische Infrastruktur von souveränitätsrelevanten Einsatzumgebungen verankern, sollten von Anbietern bezogen werden, deren eigene Rechtsordnung die Souveränitätsanforderungen des Kunden unterstützt. HSMs unter EU-Rechtsordnung (Thales Frankreich, Utimaco Deutschland und ähnliche) unterscheiden sich strukturell von HSMs außerhalb der EU-Rechtsordnung, selbst wenn die technischen Spezifikationen gleichwertig sind.

Quellcode-Hinterlegung und Zugriff zu Prüfzwecken. Kunden in geheimhaltungsrelevanten Bereitstellungen verlangen häufig als Vertrauensgrundlage die Möglichkeit, den Quellcode zu prüfen oder hinterlegen zu lassen. Ein Anbieter, dessen Architektur die Hinterlegung von Quellcode im Rahmen staatlich zertifizierter Kundenprogramme unterstützt, bietet dem Kunden die Möglichkeit einer unabhängigen Überprüfung. Ein Anbieter, dessen Architektur dies nicht unterstützt – typischerweise, weil die Codebasis zu eng mit einer proprietären Cloud-Infrastruktur verzahnt ist, um sinnvoll hinterlegt werden zu können –, schränkt die Optionen des Kunden ein.

OpenChain oder eine gleichwertige Compliance-Lösung für die Lieferkette. Die OpenChain-Konformität (ISO/IEC 5230) ist ein strukturiertes Rahmenwerk für die Transparenz in der Software-Lieferkette. Anbieter, die OpenChain-konform sind, haben durch ein externes Audit nachgewiesen, dass ihre Praktiken in der Lieferkette einem definierten Standard entsprechen. Dies ist ein struktureller Nachweis für die Disziplin in der Lieferkette.

Diese Strukturen sind architektonischer Natur und nicht vertraglicher Art. Ein Anbieter hat seine Lieferkette entweder so aufgebaut, dass sie überprüfbar ist, oder eben nicht. Ist dies der Fall, können Kunden mit hohen Anforderungen an die Souveränität eine Zusammenarbeit eingehen. Ist dies nicht der Fall, kann kein Vertrag eine Transparenz in der Lieferkette schaffen, die in der Architektur nicht vorhanden ist.

Die Frage nach dem Ausstieg aus dem Anbietergeschäft, die kaum jemand anspricht

Bei Diskussionen zum Thema Souveränität liegt der Fokus in der Regel auf dem Einstieg in eine Anbieterbeziehung: Wie wird der Anbieter ausgewählt, wie wird dessen Haltung zur Souveränität bewertet und welche Schutzmaßnahmen sind bei Vertragsunterzeichnung vorgesehen? Der Ausstieg wird selten mit derselben Gründlichkeit behandelt, ist jedoch für die langfristige Souveränität des Kunden strukturell ebenso wichtig.

Die architektonischen Aspekte, die die Ausstiegskosten bestimmen, sind die folgenden.

Sind Protokolle offen oder proprietär? Ein Anbieter, der offene, standardbasierte Protokolle verwendet, hat es dem Kunden strukturell ermöglicht, zu einem anderen Anbieter zu wechseln, der dieselben Standards unterstützt. Ein Anbieter, der proprietäre Protokolle verwendet, hat den Kunden strukturell an sich gebunden, und zwar in dem Maße, in dem die proprietären Protokolle in die Betriebsabläufe des Kunden integriert sind.

Sind Datenformate übertragbar? Kundendaten, die in herstellerspezifischen Formaten gespeichert sind und für die es weder einen dokumentierten Exportweg noch ein gleichwertiges Standardformat gibt, sind in der Praxis nicht zugänglich . Kundendaten, die in offenen Formaten oder mit dokumentierten Exportwegen gespeichert sind, sind übertragbar.

Sind Integrationen austauschbar? Ein Anbieter, dessen Wert für den Kunden von eng verzahnten Integrationen mit seinen anderen Produkten abhängt, hat strukturell Wechselkosten geschaffen, die mit der Zeit steigen, je mehr Integrationen hinzukommen. Ein Anbieter, dessen Produkt mit Alternativen von Drittanbietern kompatibel ist, hat dies nicht getan.

Lässt sich die Architektur extrahieren? In den Fällen, in denen die Souveränität am stärksten im Vordergrund steht, benötigen Kunden möglicherweise die Möglichkeit, das gesamte System – einschließlich Software, Daten, Konfigurationen und Betriebsabläufe – zu extrahieren und den Betrieb eigenständig fortzusetzen. Anbieter, deren Architektur dies unterstützt (durch Lizenzvereinbarungen, die Bereitstellung des Quellcodes oder offene Architekturen), gewähren dem Kunden echte Ausstiegssouveränität. Anbieter, deren Architektur dies nicht unterstützt, behalten strukturell die Kontrolle über den weiteren Betrieb des Kunden.

Ein Anbieter, der auf die Souveränität der Kunden ausgerichtet ist, konzipiert den Ausstieg als einen Fall von gleicher Bedeutung wie alle anderen. Ein Anbieter, dessen Geschäftsmodell auf Kundenbindung beruht, tut dies nicht. Die langfristige Souveränität des Kunden hängt davon ab, für welche Art von Anbieter er sich entschieden hat.

Das Strukturmuster – eine Zusammenfassung

Die Kunden, die schon seit langem Systeme auf Souveränitätsniveau erwerben – nationale Sicherheitsbehörden, Verteidigungsministerien und Betreiber geheimer Kommunikationssysteme –, haben sich im Laufe der Zeit auf ein strukturelles Muster geeinigt, das definiert, wie echte Souveränität in der Architektur aussieht. Das Muster beginnt mit einer rechtlichen Mindestanforderung und baut darauf auf. Die Frage nach der rechtlichen Grundvoraussetzung lautet: Führt die Rechtsordnung des Mutterunternehmens des Anbieters zu einer rechtlichen Verpflichtung, die außerhalb der eigenen Rechtsordnung des Kunden liegt? Ist dies der Fall, so liegen die nachfolgenden architektonischen Stärken unterhalb einer Grundvoraussetzung, die bei der spezifischen Bewertung dieses Kunden bereits nicht erfüllt wurde. Innerhalb dieser Grundvoraussetzung umfasst das Muster:

• Vom Kunden verwahrte kryptografische Schlüssel – aufgrund der Architektur, nicht aufgrund eines Versprechens

• Multimodale Bereitstellungstopologie mit Optionen für die lokale Installation und Air-Gapped-Lösungen

• Operative Einheiten in für den Kunden relevanten Rechtsräumen, die über echte technische und betriebliche Substanz verfügen

• Behördenübergreifende Betriebszertifizierungen, die das eingesetzte System bestätigen

• Überprüfbare Lieferketten mit Transparenz in der Build-Pipeline, Hardware-Souveränität für kryptografische Anker, Bestimmungen zum Quellcode und Rahmenwerke zur Einhaltung von Lieferkettenvorschriften

• Offene Protokolle und portable Datenformate, die die Entscheidungsfreiheit der Kunden wahren

Anbieter, die die rechtlichen Mindestanforderungen des Kunden erfüllen und ihre Produkte auf diesem Muster aufgebaut haben, können Souveränität als operative Realität umsetzen. Anbieter, die die rechtlichen Mindestanforderungen nicht erfüllen, können diesem Kunden keine Souveränität gewährleisten – unabhängig von der architektonischen Stärke in anderen Bereichen, da diese Mindestanforderungen über der architektonischen Ebene angesiedelt sind. Anbieter, die zwar die rechtlichen Mindestanforderungen erfüllen, ihre Produkte jedoch auf alternativen Mustern, anbietergeführten Schlüsseln, einer rein SaaS-basierten Bereitstellung, lokalen Tochtergesellschaften mit geringer Substanz, Zertifizierungen für eine einzige Rechtsordnung, undurchsichtigen Lieferketten und proprietären Bindungen basieren, können Souveränität ebenfalls nicht als operative Realität gewährleisten – ganz gleich, wie stark sie dies im Marketing betonen.

Die architektonischen Entscheidungen wurden bereits vor Jahren getroffen. Die Debatte um Souveränität, die nun auch im Beschaffungswesen Einzug hält, bringt im Grunde sowohl die rechtlichen Positionen der Anbieter als auch die architektonischen Entscheidungen ans Licht, die diese getroffen haben, lange bevor der Begriff „Souveränität“ in den Beschaffungswortschatz aufgenommen wurde. Kunden, denen Souveränität ernsthaft am Herzen liegt, blicken zunehmend hinter die Marketingfassade und stellen nacheinander die strukturellen Fragen: In welcher Beziehung steht die übergeordnete Rechtsordnung zu unserer, wer hat die Kontrolle, wo kann das System betrieben werden, wer betreibt die lokale Einheit tatsächlich, was bestätigt die jeweilige Zertifizierung, wo befindet sich die Build-Pipeline, und können wir aussteigen?

Kunden, denen Souveränität ernst am Herzen liegt, stellen zunehmend andere Fragen: Wer verwahrt die Schlüssel, wo kann das System betrieben werden, wer betreibt es tatsächlich, was bestätigen die Zertifizierungen, wo befindet sich die Build-Pipeline und können wir aussteigen? Die Antworten verraten weit mehr als jede noch so große Behauptung zur Souveränität auf einer Website.

Siehe auch:
Souveränität bekommt eine Bewertung: Was SEAL ist und warum es über die Cloud hinaus von Bedeutung ist
Souveränität ist keine Option mehr: Wie Regierungen und Unternehmen über Kontrolle nachdenken sollten