{"id":16384,"date":"2025-12-16T13:11:42","date_gmt":"2025-12-16T12:11:42","guid":{"rendered":"https:\/\/www.cloudandheat.com\/?p=16384"},"modified":"2025-12-16T21:19:36","modified_gmt":"2025-12-16T20:19:36","slug":"digital-sovereignty-under-the-microscope-what-can-the-analysis-of-an-it-infrastructure-look-like","status":"publish","type":"post","link":"https:\/\/www.cloudandheat.com\/en\/digitale-souveraenitaet-unter-der-lupe-wie-kann-die-analyse-einer-it-infrastruktur-aussehen\/","title":{"rendered":"Digital sovereignty under the magnifier \u2013 What does the analysis of an IT infrastructure look like?"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In einer Zeit, in der digitale Souver\u00e4nit\u00e4t zu einem beliebten Marketingbegriff geworden ist, nimmt auch das Souver\u00e4nit\u00e4ts-Washing<\/strong> zu: Anbieter werben mit gro\u00dfen Versprechen von Unabh\u00e4ngigkeit, Transparenz und Kontrolle, ohne diese in der Praxis tats\u00e4chlich einzul\u00f6sen. F\u00fcr Unternehmen wird es dadurch immer schwieriger, echte Souver\u00e4nit\u00e4t von blo\u00dfer Rhetorik zu unterscheiden.<\/p>

Genau hier setzt DISQU GmbH<\/a> an und bietet umfassende Analyse- und Bewertungsservices, um digitale Souver\u00e4nit\u00e4t belastbar zu quantifizieren. Mit Unterst\u00fctzung von UhuruTec AG<\/a> und Cloud&Heat Technologies GmbH \u2013 zwei Unternehmen, die mit ihren L\u00f6sungen echte digitale Souver\u00e4nit\u00e4t in der Cloud erm\u00f6glichen wollen \u2013 wurde eine vereinfachte Version in der Form einer Checkliste<\/a> ver\u00f6ffentlicht. Die Checklist ist eine strukturierte, verst\u00e4ndliche M\u00f6glichkeit, den Reifegrad digitaler Souver\u00e4nit\u00e4t einer Infrastruktur initial einzusch\u00e4tzen. Sie hilft Organisationen, relevante Kriterien zu erkennen, versteckte Abh\u00e4ngigkeiten aufzudecken und oberfl\u00e4chliche Versprechen kritisch zu hinterfragen.<\/p>

In diesem Blogpost zeigen wir anhand eines fiktiven Unternehmens, wie sich die Checkliste in der Praxis anwenden l\u00e4sst. Die beispielhafte IT-Infrastruktur der 42 Rides GmbH wird umfassend im Hinblick auf digitale Souver\u00e4nit\u00e4t analysiert.<\/strong><\/p>

Dabei wird untersucht, wie unabh\u00e4ngig das Unternehmen von externen Anbietern ist, welche technologischen und rechtlichen Risiken bestehen und inwieweit die aktuellen Systeme langfristige Handlungsf\u00e4higkeit gew\u00e4hrleisten. Auf Basis der Checkliste werden die eingesetzten Technologien, Prozesse und organisatorischen Strukturen bewertet und daraus strategische Empfehlungen formuliert, mit denen die 42 Rides GmbH ihre digitale Souver\u00e4nit\u00e4t nachhaltig st\u00e4rken kann.<\/p>

Die einzelnen Fragestellungen der Checkliste k\u00f6nnen dabei in drei Stufen beantwortet werden: vollst\u00e4ndig erf\u00fcllt, teilweise erf\u00fcllt und nicht erf\u00fcllt.<\/p>

[x][ ][ ] vollst\u00e4ndig erf\u00fcllt\n[ ][x][ ] teilweise erf\u00fcllt\n[ ][ ][x] nicht erf\u00fcllt<\/pre>
Die 42 Rides GmbH arbeitet unter dem Motto: \u201eWir sind die Antwort auf alle deine Verkehrsprobleme\u201c und betreiben f\u00fcr dieses ehrw\u00fcrdige Ziel einen umfassenden, appbasierten Vermittlungsdienst f\u00fcr Taxifahrten. Dabei k\u00f6nnen Endkunden \u00fcber die App Fahrten mit einem definierten Start- und Endpunkt buchen, welche anschlie\u00dfend einem Taxifahrer zugeordnet werden. Um diesen Service anbieten zu k\u00f6nnen, wird neben den beiden Apps f\u00fcr Endkunden und Taxifahrer ein Backend betrieben, welches die Buchungen an zentraler Stelle b\u00fcndelt, verwaltet sowie die Gesch\u00e4ftslogik der Buchungsplattform ausf\u00fchrt.<\/p>
Obwohl die 42 Rides GmbH eine engagierte und technisch versierte IT-Abteilung besitzt, r\u00fcckte das Thema digitale Souver\u00e4nit\u00e4t erst sp\u00e4t in den Fokus, weil vorher noch die Antworten auf s\u00e4mtliche andere weltbewegende Fragen gefunden werden mussten. Lange stand deshalb vor allem die kurzfristige Funktionalit\u00e4t der Systeme im Vordergrund, wodurch sich im Laufe der Zeit gewisse Abh\u00e4ngigkeiten von externen Anbietern einschleichen konnten, deren Risiken nun immer deutlicher hervortreten. Vor diesem Hintergrund wurde eine Analyse der Infrastruktur angesto\u00dfen, um die aktuelle Souver\u00e4nit\u00e4tssituation zu bewerten und m\u00f6gliche Ma\u00dfnahmen zur langfristigen Unabh\u00e4ngigkeit zu identifizieren.<\/p>
Das technische Setup sieht dabei folgenderma\u00dfen aus: Beide Apps, sowohl f\u00fcr Endkunden als auch Taxifahrer, werden von der 42 Rides GmbH selbst entwickelt. Die Anwendungen werden zum aktuellen Zeitpunkt nativ f\u00fcr das Android Betriebssystem in der Programmiersprache Kotlin geschrieben. Um die Nutzererfahrung in den Apps zu analysieren ist Booble Analytics im Einsatz. Die Verbreitung der Apps erfolgt ausschlie\u00dflich kostenfrei \u00fcber den digitalen Marktplatz \u201eBooble Play Store\u201c. F\u00fcr die Entgegennahme von Zahlungen der Endkunden wird auf den Zahlungsdienstleister \u201eStrike\u201c gesetzt. Taxifahrer bekommen ihre Einnahmen monatlich per Bank\u00fcberweisung ausgezahlt. Zur Entwicklung der Apps wird auf einige externe Libraries gesetzt.<\/p>
Das Backend wird ebenfalls durch die 42 Rides GmbH selbst entwickelt. Die Entwicklung erfolgt in der Programmiersprache Python unter Verwendung des Frameworks FastAPI. Die Anwendung wird als Docker Container gebaut und \u00fcber Tropical Web Services gehostet. Dazu wird das Containerimage in die Tropical Container Registry geladen, mit mehreren Instanzen als Tropical Container Service ausgef\u00fchrt und durch einen TWS Elastic Load Balancer aus dem Internet erreichbar gemacht. Die ben\u00f6tigte Datenbank wird \u00fcber ein TWS Managed PostgreSQL-Cluster bezogen.<\/p>
Die 42 Rides GmbH nutzt Github Team, um s\u00e4mtlichen Quellcode im Team gemeinschaftlich zu entwickeln.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
1. Technologische Unabh\u00e4ngigkeit:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Aus technologischer Perspektive ist zun\u00e4chst festzustellen, dass die 42 Rides GmbH im Kern auf solide Open-Source-Komponenten setzt. Die Entscheidung f\u00fcr Python, FastAPI und PostgreSQL bildet eine robuste Grundlage, da diese Technologien einer aktiven und verl\u00e4sslichen Community entstammen, kontinuierlich weiterentwickelt werden und als offen standardisierte Bausteine gelten. Gleiches gilt f\u00fcr Kotlin im App-Bereich und f\u00fcr Docker als containerisierte Basistechnologie, die sich stark an offenen Standards orientiert. Die Vorteile liegen auf der Hand: Die Funktionsweise dieser Komponenten ist transparent, die Migrationsm\u00f6glichkeiten zu alternativen Plattformen sind gegeben, und das Unternehmen kann grunds\u00e4tzlich frei entscheiden, ob es die Systeme selbst oder in fremdgehosteten Umgebungen betreiben m\u00f6chte. Gleichzeitig fallen jedoch propriet\u00e4re Abh\u00e4ngigkeiten auf. Die Verwendung von Booble Analytics, die ausschlie\u00dfliche Distribution \u00fcber den Booble Play Store und der Einsatz von Strike als zentralem Zahlungsdienst f\u00fchren zu technologischen Blackboxes, deren Austauschbarkeit nur eingeschr\u00e4nkt m\u00f6glich ist und tiefgreifende Anpassungen erfordern w\u00fcrde.<\/p>
[ ][x][ ] Einsatz von Open Source:<\/strong> Sind die Komponenten der IT-Infrastruktur quelloffen und unterliegen vereinbarten Standards der Open Source Community?

[x][ ][ ] Stabilit\u00e4t der Open Source Community:<\/strong> Werden die eingesetzten Open Source Komponenten von einer stabilen und aktiven Community gepflegt und weiterentwickelt?

[ ][x][ ] Vermeidung von Blackbox-Komponenten:<\/strong> Systeme deren Funktionsweise und Abh\u00e4ngigkeiten nicht einsehbar sind werden vermieden?

[x][ ][ ] Migrationsm\u00f6glichkeit zu alternativen Komponenten:<\/strong> Gibt es kompatible Alternativen f\u00fcr wichtige Software, Hardware oder Services mit vergleichbarer Funktionalit\u00e4t?

[ ][x][ ] Autonom steuerbare Build-Pipeline: <\/strong>Werden eigene CI\/CD oder kontrollierbarer Build aus vertrauensw\u00fcrdigen Quellen verwendet?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
2. Unabh\u00e4ngigkeit von Anbietern:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Noch deutlicher werden die Abh\u00e4ngigkeiten bei der Betrachtung der Anbieterunabh\u00e4ngigkeit. Das Backend ist vollst\u00e4ndig auf Tropical Web Services aufgebaut und nutzt dort eine ganze Kette eng verzahnter Services: Container werden \u00fcber Tropical Container Services betrieben, Images werden in der Tropical Container Registry gespeichert, und das Tropical Managed Postgres stellt die Datenbank in einem geschlossenen \u00d6kosystem bereit. Diese Architektur ist zwar technisch ausgereift und skalierbar, erh\u00f6ht aber gleichzeitig die Bindung an TWS erheblich. Ein Cloud-Wechsel w\u00fcrde nicht nur ein Neuaufsetzen der Infrastruktur erfordern, sondern auch das Umschreiben oder Neuorganisieren verschiedener betriebskritischer Komponenten. Hinzu kommt die Abh\u00e4ngigkeit vom Booble Play Store im mobilen Bereich und von Strike im Zahlungsverkehr. W\u00e4hrend offene Standards im Backend durchaus vorhanden sind, fehlt es auf Plattformebene zunehmend an Wahlfreiheit. Offene Schnittstellen sind vorhanden, doch die eigentlichen Betriebsumgebungen sind fest an einzelne Anbieter gebunden.<\/p>
[x][ ][ ] Vermeidung von Vendor Lock-ins:<\/strong> Propriet\u00e4re Technologien oder Datenformate, die einen Wechsel deutlich erschweren, sind nicht im Einsatz?

[ ][x][ ] Offene Schnittstellen und APIs:<\/strong> Werden offene Schnittstellen und Austauschformate genutzt?

[ ][ ][x] Absicherung kritischer Systeme:<\/strong> Werden unternehmenskritische Komponenten explizit betrachtet und sind notfalls eigenst\u00e4ndig betreib- und wartbar?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
3. Support und Krisenmanagement:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Auch im Bereich Support und Krisenmanagement ergibt die Analyse ein eher durchwachsenes Bild. TWS und Strike bieten prim\u00e4r englischsprachigen Support, der je nach Vertragsmodell unterschiedlich schnell reagiert und bei komplexeren Problemen mit hohen Kosten verbunden sein kann. Booble bietet hingegen kaum Supportoptionen, was im Fall von Ausf\u00e4llen oder pl\u00f6tzlichen Restriktionen ein erhebliches Risiko darstellen kann. Im Unternehmen selbst sind, neben knappen technischen HowTos, keine etablierten Notfallpl\u00e4ne oder Disaster-Recovery-Konzepte dokumentiert. Weder redundante Betriebsumgebungen noch definierte Eskalationsketten, Kommunikationswege oder systematische Ausfallstrategien sind derzeit ersichtlich. Damit besteht die Gefahr, im Krisenfall auf die Gnade externer Anbieter angewiesen zu sein, ohne \u00fcber geeignete interne Prozesse zur Schadensbegrenzung zu verf\u00fcgen.<\/p>
[ ][ ][x] Qualit\u00e4t des Supports:<\/strong> Wird ein (deutschsprachiger) Support angeboten und ist die Reaktion l\u00f6sungsorientiert und hilfreich?

[ ][ ][x] Reaktion des Supports:<\/strong> Ist der Support gut erreichbar, reagiert z\u00fcgig und ist flexibel?

[ ][ ][x] Vorbereitung Krisenmanagement:<\/strong> Liegen dedizierte Notfallpl\u00e4ne und Kontaktm\u00f6glichkeiten f\u00fcr diverse Zwischenf\u00e4lle wie z.B. Ausfall einzelner Komponenten vor?

[ ][x][ ] Umsetzung Krisenmanagement:<\/strong> Kennen beteiligte Personen entsprechende Notfallpl\u00e4ne und k\u00f6nnen diese umsetzen?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
4. Kompetenz und Wissen im Unternehmen:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Die internen Kompetenzen der IT-Abteilung sind grunds\u00e4tzlich gut, was die Weiterentwicklung der Systeme und die t\u00e4gliche Arbeit betrifft. Die Anwendungen werden eigenst\u00e4ndig entwickelt, und die technische Expertise im Bereich der Kerntechnologien (Python, FastAPI, Android-Entwicklung, Docker) ist offensichtlich vorhanden. Dennoch ist unklar, wie breit das Wissen \u00fcber den gesamten technologischen Stack tats\u00e4chlich verteilt ist. Gerade Spezialthemen wie TWS-Betrieb, Cloud-Security, Netzwerksegmentierung, Verschl\u00fcsselungskonzepte oder Rechts- und Compliance-Fragen bez\u00fcglich US-Dienstleistern sind oft personengebunden und werden nicht zwingend dokumentiert. Besonders auff\u00e4llig ist das Fehlen einer strategischen Exit-Planung. Weder existiert eine dokumentierte Roadmap f\u00fcr einen Cloud-Wechsel, noch gibt es einen systematischen Ma\u00dfnahmenkatalog f\u00fcr die Migration der Zahlungs- oder Analysetools. Eine ganzheitliche Strategie f\u00fcr digitale Souver\u00e4nit\u00e4t, die technologische und organisatorische Entscheidungen leitet, fehlt vollst\u00e4ndig.<\/p>
[ ][ ][x] Verantwortungsvolle Nutzung der IT-Infrastruktur:<\/strong> Ist die IT-Infrastruktur und deren Prozesse inklusive der Sicherheitskonzepte nachvollziehbar aufgebaut, personenunabh\u00e4ngig dokumentiert und f\u00fcr alle umsetzbar?

[ ][x][ ] Betrieb der IT-Infrastruktur:<\/strong> Verf\u00fcgen Mitarbeiter oder Dienstleister \u00fcber ausreichendes technologisches Wissen, um den Betrieb unabh\u00e4ngig sicherzustellen?

[ ][x][ ] Stack-Kenntnis:<\/strong> Kennen beteiligte Personen gegebenenfalls den Plattform-Stack vollst\u00e4ndig?

[ ][ ][x] Exit-Strategie: <\/strong>Gibt es einen Ma\u00dfnahmenplan inkl. Datenmigration und Dokumentation f\u00fcr Wechsel-\/Austauschszenarien?

[ ][ ][x] Strategie digitaler Souver\u00e4nit\u00e4t:<\/strong> Gibt es eine umfassende Strategie f\u00fcr die Erh\u00f6hung der digitalen Souver\u00e4nit\u00e4t, die bei allen technologischen und organisatorischen Entscheidungen einbezogen wird?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
5. Vertragsbedingungen:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
In Bezug auf Vertragsbedingungen, Kostenkontrolle und rechtliche Rahmenbedingungen zeigt sich ein weiteres Problemfeld. Die Nutzung von TWS, Booble und Strike bedeutet, dass die 42 Rides GmbH an langfristig schwer kalkulierbare Vertragsbedingungen dieser Anbieter gebunden ist. Die Kostenstrukturen k\u00f6nnen sich jederzeit \u00e4ndern, und gerade im Cloud-Umfeld ist es nicht un\u00fcblich, dass Preisanpassungen kurzfristig auftreten. Ohne ein strukturiertes Controlling droht die Gefahr, dass j\u00e4hrliche Preissteigerungen unentdeckt bleiben und die langfristige Wirtschaftlichkeit der Plattform beeinflussen. Gleichzeitig haben die Anbieter teilweise sehr kleinteilige und komplexe Preismodelle, die nur mit erheblichem Aufwand f\u00fcr die 42 Rides GmbH konkret kalkulierbar sind.<\/p>
[ ][ ][x] Transparenz \u00fcber Vertragsdetails und \u00c4nderungen:<\/strong> Sind Vertrags- und Lizenzbedingungen f\u00fcr die eingesetzten Komponenten transparent formuliert und werden \u00c4nderungen rechtzeitig kommuniziert?

[ ][ ][x] Rechtssicherheit im Problemfall:<\/strong> Sind rechtliche Grauzonen ausgeschlossen, die im Falle eines Problems zu Schwierigkeiten f\u00fchren k\u00f6nnten?

[ ][ ][x] Controlling:<\/strong> Gibt es Monitoring f\u00fcr die Kostenentwicklungen und ein Aktionsszenario f\u00fcr Preissteigerungen von mehr als 20 % j\u00e4hrlich?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
6. Datenhoheit und Schutz:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Einer der kritischsten Punkte betrifft die Datenhoheit und den Datenschutz. Die Backend-Datenbank wird zwar in einem europ\u00e4ischen TWS-Rechenzentrum betrieben, wobei TWS durch den Cloud Act als amerikanisches Unternehmen jedoch jederzeit die gespeicherten Daten an die Regierung herausgeben muss. Dies steht der DSGVO-Konformit\u00e4t entgegen. Die in Booble Analytics verarbeiteten Nutzerdaten werden regelm\u00e4\u00dfig in die USA \u00fcbermittelt und unterliegen US-Recht. Auch Strike f\u00fchrt personenbezogene Zahlungsdaten in einem US-basierten Infrastrukturkontext durch seine Systeme. Die 42 Rides GmbH beh\u00e4lt bei beiden Anbietern keine vollst\u00e4ndige Kontrolle \u00fcber Verschl\u00fcsselung, Schl\u00fcsselhoheit oder Datenverarbeitung. Dadurch ergibt sich ein erhebliches Compliance-Risiko. Dar\u00fcber hinaus ist unklar, wie granular Zugriffsrechte dokumentiert sind, ob eigenst\u00e4ndige Schl\u00fcsselverwaltungsverfahren existieren und ob Exfiltrationsrisiken durch Lizenzserver oder Upstream-Kommunikation ausgeschlossen werden k\u00f6nnen. Beispielsweise werden private Schl\u00fcssel f\u00fcr die TLS-Verschl\u00fcsselung der angebotenen Dienste durch TWS generiert.<\/p>
[ ][ ][x] Standort der Daten:<\/strong> Werden die Daten ausschlie\u00dflich in Deutschland oder der EU gespeichert?

[ ][ ][x] Datenschutz:<\/strong> Werden personenbezogene Daten DSGVO-konform verarbeitet?

[ ][x][ ] Zugriffskontrolle:<\/strong> Ist detailliert geregelt und dokumentiert, wer Zugriff hat, wozu dieser ben\u00f6tigt wird und ist diese Zugriffskontrolle digital unabh\u00e4ngig aufgebaut?

[ ][x][ ] Datenverschl\u00fcsselung:<\/strong> Sind die Daten w\u00e4hrend der Speicherung und \u00dcbertragung mit einem eigenen Schl\u00fcssel (kein Drittanbieter Service) verschl\u00fcsselt?

[ ][ ][x] Vermeidung Exfiltration:<\/strong> Ausschluss von Exfiltration durch Upstream-Dienste (z.B. Entzug von Lizenzen, die permanent \u00fcber Online-Lizenzserver validiert werden m\u00fcssen) m\u00f6glich?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
7. Backup und Archivierung:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Beim Thema Backup und Archivierung l\u00e4sst sich feststellen, dass die TWS Managed Datenbank zwar automatische Backups anbietet, das Unternehmen jedoch kaum Kontrolle \u00fcber die Formate und Abl\u00e4ufe besitzt. Backups bleiben im propriet\u00e4ren TWS-\u00d6kosystem gefangen und sind nur begrenzt interoperabel. Eine umfassende Archivierungsstrategie, inklusive der Frage nach Offsite-Backups au\u00dferhalb der TWS-Welt oder der regelkonformen L\u00f6schung alter Daten, ist derzeit nicht etabliert. Die Abh\u00e4ngigkeit von TWS bleibt damit auch im Katastrophenfall bestehen.<\/p>
[x][ ][ ] Regelm\u00e4\u00dfige Backups:<\/strong> Werden regelm\u00e4\u00dfige Backups der Daten erstellt?

[ ][ ][x] Datensicherung:<\/strong> Werden Backups an einem sicheren Ort unter souver\u00e4ner Zugriffskontrolle aufbewahrt?

[ ][ ][x] Archivierung:<\/strong> Werden Daten, die nicht mehr aktiv genutzt werden, gesch\u00fctzt archiviert?

[ ][ ][x] L\u00f6schung:<\/strong> Werden Daten, die nicht mehr ben\u00f6tigt werden, korrekt und nachvollziehbar gel\u00f6scht?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
8. Monitoring:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Auch im Monitoring wurde kein ganzheitliches Konzept umgesetzt. Moderne Plattformen ben\u00f6tigen kontinuierliches System-, Leistungs- und Sicherheitsmonitoring, idealerweise \u00fcber Open-Source-Stacks. Ebenso wichtig w\u00e4re ein regelm\u00e4\u00dfig durchgef\u00fchrter Souver\u00e4nit\u00e4ts-Check, der feststellt, ob neue Abh\u00e4ngigkeiten entstanden oder bestehende Risiken gewachsen sind.<\/p>
[ ][ ][x] System\u00fcberwachung:<\/strong> Werden die Systeme regelm\u00e4\u00dfig auf Ver\u00e4nderungen \u00fcberwacht?

[ ][ ][x] Leistungs\u00fcberwachung:<\/strong> Wird die Leistung der Systeme konstant \u00fcberwacht?

[ ][ ][x] Sicherheits\u00fcberwachung: <\/strong>Werden die Systeme auf Sicherheitsl\u00fccken \u00fcberwacht?

[ ][ ][x] Souver\u00e4nit\u00e4ts-Check:<\/strong> Wird regelm\u00e4\u00dfig der Souver\u00e4nit\u00e4tsstatus \u00fcberpr\u00fcft?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
9. Zertifizierung und Standardisierung:<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Schlie\u00dflich zeigt sich, dass Standardisierung und Zertifizierung noch nicht adressiert wurden. Ein Unternehmen, das dauerhaft eine digitale Plattform betreiben m\u00f6chte, sollte sich bei der Auswahl von genutzten IT-Services auf unabh\u00e4ngige Standards bzw. weit verbreitete APIs konzentrieren.<\/p>
Da die 42 Rides GmbH sensible Kundendaten verarbeitet, sollte auch \u00fcber eine Ausrichtung anhand von Standards wie beispielsweise dem BSI-Grundschutz oder der ISO 27001 nachgedacht werden.<\/p>
[ ][ ][x] Standards: <\/strong>Werden Standards eingesetzt (u.a. BSI, ISO-Zertifizierung, NIS2, SCS)?

[ ][ ][x] Zertifizierung:<\/strong> Ist die IT-Infrastruktur zertifiziert und wird sie regelm\u00e4\u00dfig aktualisiert?

[ ][ ][x] Audits:<\/strong> Werden regelm\u00e4\u00dfige Audits sicherheitsrelevanter Komponenten und Prozesse durchgef\u00fchrt?<\/pre>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Fazit<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
In der Gesamtbetrachtung ergibt sich ein differenziertes Bild: Die 42 Rides GmbH besitzt eine moderne, leistungsf\u00e4hige und technisch gut entwickelte Plattformarchitektur, die in zentralen Teilen auf offenen Technologien basiert. Gleichzeitig ist die tats\u00e4chliche digitale Souver\u00e4nit\u00e4t eingeschr\u00e4nkt, da zahlreiche Schl\u00fcsselprozesse auf propriet\u00e4ren US-Diensten aufbauen, deren Einfluss sich nicht ohne Weiteres reduzieren l\u00e4sst. Dies liegt auch darin begr\u00fcndet, dass jene diense bewusst propriet\u00e4re Schnittstellen anbieten.<\/p>
Um die digitale Souver\u00e4nit\u00e4t deutlich zu verbessern, sollte die 42 Rides GmbH mehrere Schritte in Betracht ziehen:<\/p>