Cloud-Autonomie, BSI-Kriterien C3A und KI „Kompetenzhoheit ist der Schlüssel zur Cloud-Souveränität“

Anbieter zum Thema

Telekom Deutschland GmbH

Hyland Software Germany GmbH

Flexera Software GmbH

Yorizon GmbH & Co. KG

Cloud-Sicherheit allein reicht nicht aus, um digitale Abhängigkeiten zu vermeiden. Mit den C3A-Kriterien erweitert das BSI den Blick auf Daten-, Betriebs- und Technologiehoheit. Im Interview erklärt Lars Neumann von der Deutschen Telekom, warum Unternehmen zusätzlich ihre eigene Kompetenzhoheit sichern müssen.

Die Cloud ist für Unternehmen längst ein zentraler Bestandteil ihrer digitalen Infrastruktur. Gleichzeitig wächst die Abhängigkeit von einzelnen Anbietern, proprietären Technologien und externem Know-how. Die C3A-Kriterien des Bundesamts für Sicherheit in der Informationstechnik (BSI) sollen deshalb nicht nur die Sicherheit von Cloud-Diensten bewerten, sondern auch Fragen der Cloud-Autonomie und -Souveränität stärker in den Mittelpunkt rücken. Im Gespräch mit CloudComputing-Insider erläutert Lars Neumann, SVP T Cloud bei der Deutschen Telekom, worauf Unternehmen darüber hinaus noch achten sollten und warum sie ihre Cloud-Architektur, Risiken und Handlungsmöglichkeiten jederzeit selbst verstehen müssen.

CloudComputing-Insider: Die Kriterien des BSI sollen Cloud-Autonomie anhand von Daten-, Betriebs- und Technologiehoheit greifbarer machen. Was verändert sich dadurch in der Praxis für Unternehmen? Welche Entscheidungen zur Cloud-Nutzung können sie dadurch besser treffen?

Lars Neumann: C3A erweitert die C5-Kriterien, bei denen es primär um Sicherheit ging. C3A betrachtet nun, wie autonom und souverän Unternehmen eine Cloud betreiben und nutzen können. Dafür müssen sie sich fragen: Wo befinden sich unsere Daten? Wer betreibt unsere Systeme, mit wem arbeiten wir zusammen? Wer kann auf die Daten zugreifen? Welche rechtlichen Rahmenbedingungen gelten? Dabei geht es auch um mögliche gesetzliche Einflussnahmen und die Risiken, die sich daraus ergeben können. C3A liefert Unternehmen eine zusätzliche Orientierung, um diese Fragen strukturierter zu beantworten und bewusste Entscheidungen zu treffen. Spätestens dadurch ist das Thema nicht mehr ausschließlich eine IT-Frage. Damit müssen sich der CIO, der CFO, der CEO und der CISO beschäftigen. Digitalisierung ist inzwischen ein Kernbereich der Unternehmensführung – und mit künstlicher Intelligenz – KI – kommt eine weitere Dimension hinzu.

Besteht nicht die Gefahr, dass Unternehmen C3A lediglich als weiteres Zertifizierungs- oder Compliance-Thema betrachten? Wie lässt sich vermitteln, dass die Kriterien tatsächlich bei der Auswahl von Cloud-Anbietern helfen?

Neumann: Die Fragestellung von C3A ist eine andere als die von C5. C5 betrachtet vor allem, ob der Betrieb der Cloud sicher ist. C3A ist eine Erweiterung und fragt zusätzlich, wie autonom und souverän diese Cloud betrieben wird und welche Wahlmöglichkeiten das Unternehmen hat. Der Kriterienkatalog soll nicht nur eine weitere formale Prüfung sein. Er soll Unternehmen bei der Risikoabsicherung und bei ihren strategischen Entscheidungen unterstützen. Viele Unternehmen fragen nach Leitfäden oder sogenannten Guardrails, an denen sie sich orientieren können: Genau dafür ist C3A aus meiner Sicht eine sinnvolle Ergänzung. Unternehmen können damit viel besser einschätzen, welche Abhängigkeiten und Risiken möglicherweise mit einem bestimmten Anbieter verbunden sind und wie viel Kontrolle und Wahlfreiheit das Unternehmen behält.

Cloud-Autonomie wird meist mit dem Datenstandort, Vertragsbedingungen und der Kontrolle über den Cloud-Betrieb verbunden. Gibt es darüber hinaus weitere Aspekte?

Neumann: Ja – und der wichtigste ist für mich: die Kompetenzhoheit. Unternehmen müssen ihre Cloud-Architektur kennen. Sie müssen beurteilen können, ob dieses Wissen noch im eigenen Haus vorhanden ist oder vollständig an einen externen Dienstleister abgewandert ist. Leider erlebe ich häufig, dass Unternehmen ihre eigene Cloud-Architektur nicht mehr vollständig erklären können. Gerade im Rahmen einer Migration geht dieses Wissen oft an den Dienstleister über. Werden zusätzlich proprietäre Systeme eingesetzt, verstärkt sich die Abhängigkeit. Für tatsächliche Unabhängigkeit reicht es aber nicht aus, Daten und Systeme kontrollieren zu können. Unternehmen müssen auch in der Lage sein, wichtige Entscheidungen selbst zu treffen und strategisch zu handeln. Deshalb halte ich Kompetenzhoheit für so wichtig.

Wie kommt es zu diesem Kompetenzverlust? Liegt es daran, dass wichtige Mitarbeiter das Unternehmen verlassen, oder müssen Unternehmen grundsätzlich anders mit ihren Dienstleistern zusammenarbeiten?

Neumann: Das kann verschiedene Ursachen haben. Häufig ist es eine Kombination mehrerer Faktoren. Ein typischer Verlauf beginnt damit, dass einzelne Workloads in die Cloud migriert werden. Mitunter führen Fachbereiche auch eigenständig SaaS-Produkte ein. So entsteht zunächst eine Schatten-IT, die später formalisiert und in die Unternehmens-IT integriert wird. Daraus kann sich auch eine Multi-Cloud-Umgebung entwickeln. Im Zuge von Transformationsprojekten geht das Wissen über die Architektur häufig an den Dienstleister über. Viele Unternehmen bauen keinen eigenen Architekten auf, der die verschiedenen Cloud-Umgebungen übergreifend versteht und weiterentwickelt. Wenn beim Dienstleister anschließend der Ansprechpartner wechselt, kann zusätzliches Know-how verloren gehen darüber, wie die Architektur aufgebaut ist oder wo die Risiken liegen. Die Unternehmen müssten gezielt dafür sorgen, dass das Wissen im eigenen Haus gebündelt und dauerhaft verfügbar ist.

Gibt es im Gespräch mit IT-Entscheidenden bestimmte Anzeichen dafür, dass ein Unternehmen die Kontrolle über seine Cloud-Umgebung bereits weitgehend verloren hat?

Neumann: Ja, dafür gibt es konkrete Prüfsteine. Zunächst kann man fragen: Kennst du deine Architektur? Kannst du sie einem neuen Lieferanten erklären? Wer ist im Unternehmen dafür verantwortlich? Danach geht es um die Abhängigkeiten: Sind die wesentlichen Abhängigkeiten bekannt? Weiß das Unternehmen, welche strategischen Entscheidungen zur Cloud getroffen wurden? Kann es diese Entscheidungen ohne externe Unterstützung nachvollziehen und weiterentwickeln? Ein weiterer wichtiger Punkt ist der Umgang mit einem Incident: Wissen die eigenen Mitarbeiter, was im Krisenfall zu tun ist? Können sie selbst erste Maßnahmen einleiten, statt für jeden Schritt den Dienstleister kontaktieren zu müssen? Wenn eine dieser Fragen mit Nein beantwortet wird, ist das ein deutlicher Hinweis darauf, dass wertvolles Wissen verloren gegangen ist. Dann muss sich das Unternehmen fragen, wie es diese Kompetenz zurückgewinnen und seine strategische Handlungsfähigkeit wiederherstellen kann.

Die EU und andere Organisationen arbeiten an Frameworks zur Cloud-Souveränität. Lässt sich auch der Grad der Kompetenzhoheit festlegen und messen?

Neumann: Das ist bislang noch nicht ausreichend geregelt. Ich halte es aber für notwendig, dass Unternehmen sich mit dieser Frage beschäftigen und Kompetenzhoheit messbar machen. Ein pragmatischer Ansatz wäre die Beantwortung der Frage, ob sich die eigene Cloud-Architektur innerhalb von zwei Wochen – zum Beispiel in mehreren Workshops – einem neuen Anbieter erklären ließe. Außerdem sollten Unternehmen wissen, was ein Anbieterwechsel kosten würde und wie groß der damit verbundene Aufwand wäre. Eine ungefähre Größenordnung zu kennen, ist bereits eine wichtige Messgröße. Das sind keine besonders schwierigen Fragen. Wenn ein Unternehmen sie nicht beantworten kann, ist das ein deutlicher Hinweis auf ein Kompetenzproblem. Deshalb sollte Kompetenzhoheit neben den bereits veröffentlichten Kriterien berücksichtigt werden.

Souveräne Cloud

Warum Datenschutz und Souveränität bei der Cloud zusammengehören

Wer sollte die Verantwortung für diese Kompetenz und das Architekturwissen übernehmen, also den „Hut aufhaben“?

Neumann: Für mich ist das eine naheliegende Rolle für den CTO. Er sollte sich mindestens einmal im Jahr mit seinem Team zusammensetzen, die Architektur überprüfen und klären, wie mögliche Exit-Szenarien aussehen. Man muss dabei das Zusammenspiel von CIO und CTO eindeutig definieren. Wichtig ist vor allem, festzulegen, wer der Owner der Architektur ist. Diese Person muss über das notwendige Wissen verfügen, das als konkretes Ergebnis oder Deliverable formuliert werden sollte. Regelmäßige Architektur-Reviews und die Bewertung von Exit-Szenarien sollten verbindlich vorgesehen werden. Kompetenzhoheit sollte für Unternehmen ein Muss und ein Kernthema sein – neben Datenschutz und Informationssicherheit.

Wie sollte ein Unternehmen vorgehen, wenn es feststellt, dass dieses Wissen nicht ausreichend im eigenen Haus vorhanden ist?

Neumann: Man beginnt am besten damit, in den eigenen Teams zu fragen, ob jemand den notwendigen Überblick besitzt. Vielleicht gibt es bereits einen Architekturverantwortlichen. Aber kann dieser die zentralen Fragen tatsächlich beantworten? Wenn nicht, sollte man den Dienstleister mit einbeziehen und um eine detaillierte Erklärung bitten: Wer ist dort für die Umgebung verantwortlich? Ist diese Person bereits seit Beginn des Projekts beteiligt oder handelt es sich um einen neuen Ansprechpartner? Wie wird das Wissen über die bestehende Architektur dokumentiert und weitergegeben? Auf diese Weise kann das Unternehmen auch seinen Anbieter überprüfen und versuchen, das notwendige Wissen zurück ins eigene Haus zu holen. Ich würde deshalb dreistufig vorgehen: zuerst das eigene Team, dann den Dienstleister und schließlich – falls die Antworten nicht ausreichen – externe Unterstützung. Wenn auch der Anbieter keinen vollständigen Überblick mehr hat, ist wahrscheinlich zusätzlich externe Expertise notwendig.

Kompetenz ist als Begriff schwer zu fassen und zu definieren. Wie verhindert man, dass sie in einem Framework lediglich zu einem weichen Faktor wird?

Neumann: Wenn Kompetenzhoheit in ein Framework aufgenommen wird, muss sie anhand konkreter Kriterien beschrieben werden. Aus meiner Sicht sind das drei Bereiche. Erstens: Gibt es ein ausreichendes Verständnis der eigenen Architektur? Zweitens: Können wir die eingegangenen Risiken und Abhängigkeiten bewerten? Drittens: Welche Gestaltungsmöglichkeit haben wir noch, können wir strategische Entscheidungen ohne externe Hilfe treffen? Diese drei Punkte sollten um einem konkreten Fragenkatalog ergänzt werden. Unternehmen könnten damit ihre eigenen Teams prüfen. Am Ende sollte eine Matrix zeigen, ob ein Unternehmen gut aufgestellt ist, welche Defizite bestehen oder ob dringender Handlungsbedarf vorliegt. So würde aus dem zunächst abstrakten Begriff Kompetenzhoheit eine praktische Orientierungshilfe.

Welche Rolle spielt die Kompetenzhoheit beim Einsatz künstlicher Intelligenz?

Neumann: Mit KI kommt eine neue Dimension hinzu. Unternehmen müssen klären, welche Governance-Regeln gelten, welche Anbieter und Modelle eingesetzt werden und für welche Workloads sie geeignet sind. Außerdem müssen sie wissen, welche Risiken sie eingehen und wie sie zwischen verschiedenen Modellen oder Anbietern wechseln können. Wir erleben bereits, dass KI-Modelle teilweise unkontrolliert in Unternehmen eingesetzt werden. Solange man selbst nicht betroffen ist, kann man das vielleicht beobachten oder darüber schmunzeln. Wenn aber plötzlich Unternehmensdaten gefährdet sind, ist das nicht mehr nur ein technisches Problem. Dann kann die Fortführung des Unternehmens gefährdet sein. Deshalb müssen sich Unternehmen bewusst mit diesen Risiken auseinandersetzen. KI darf nicht so eingeführt werden wie manche Cloud-Anwendung in der Vergangenheit – nach dem Motto: Wir übernehmen einfach den bestehenden Prozess und verlagern ihn in eine neue Technologie. KI erfordert eine echte Transformation der Geschäftsmodelle und Prozesse. Dafür braucht es klare Verantwortlichkeiten, ausreichende Kompetenz und Regeln, die eine unkontrollierte Schatten-KI verhindern.

EU legt Maßstäbe für digitale Souveränität fest

Was ist das Cloud Sovereignty Framework der EU?

Demnächst findet wieder die Digital X in Köln statt. Welche Botschaft sollen die Besucherinnen und Besucher der Digital X mitnehmen?

Neumann: Die wichtigste Botschaft ist, dass sich Unternehmen inhaltlich mit der gesamten Thematik beschäftigen müssen – mit Cloud, Sicherheit, Souveränität und künstlicher Intelligenz. Das ist kein Thema, das ausschließlich die IT-Abteilung betrifft. Unternehmen müssen klären: Wie sieht unsere Cloud-Architektur aus? Wie steht es um unsere KI-Kompetenz? Wer trägt dafür die Verantwortung? Und wie verhindern wir, dass unkontrollierte Anwendungen und Abhängigkeiten entstehen? ‚What’s next‘ bedeutet nicht nur eine kleine Transformation innerhalb der IT. Es geht um eine umfassende Veränderung des Unternehmens, seiner Geschäftsmodelle und seiner Prozesse. Das hat auch Konsequenzen für die Mitarbeiterinnen und Mitarbeiter. Deshalb ist das Thema zugleich ein großes HR- und Change-Programm. Die Beschäftigten müssen einbezogen und auf die Veränderungen vorbereitet werden. Es darf nicht nur Angst entstehen, sondern es müssen Perspektiven und Möglichkeiten zur Weiterentwicklung geschaffen werden. Mein Wunsch wäre, dass die Teilnehmerinnen und Teilnehmer die Diskussion anschließend in ihre Unternehmen tragen und sagen: Wir müssen uns regelmäßig damit beschäftigen. Diese Themen gehören auf die Agenda der Geschäftsführung. Unternehmen müssen sich fragen, wie sie künftig relevant bleiben – am Markt und auch für ihre eigenen Mitarbeiter. Die Deutsche Telekom kann diese Aufgabe aber nicht allein lösen. Dafür braucht es alle Beteiligten im Markt.

Podcast: Wie Europa seine digitale Souveränität zurückerobern will

8ra – 10.000 Knoten für Europas Super-Cloud

(ID:50942555)