IT-Grundschutz

[Draft] Sicherheitskonzept openDesk SaaS

DISCLAIMER:

Das vorliegende Sicherheitskonzept in der aktuellen Form basiert auf den verfügbaren Informationen zum 20.11.2025. Weitergehende Informationen werden erwartet und sukzessive eingearbeitet. Die Validierung der Informationen ist ausstehend. Es handelt sich daher noch um einen Zwischenstand, weshalb dieses Dokument nicht als endgültige Quelle heranzuziehen ist. Bei Bedarf sind weitere Informationen über die entsprechenden Stellen bei der ZenDis anzufragen.

Dieses Sicherheitskonzept und die dazugehörigen Unterlagen befinden sich derzeit in Bearbeitung und sind noch nicht finalisiert. Konkret sind folgende Aufgaben noch nicht abgeschlossen und werden zur Zeit bearbeitet:

Validierung des Big Pictures und der High Level Architektur von openDesk zur Vervollständigung der Bedrohungsanalyse

Vervollständigung der Strukturanalyse, u.a. Zugriffsklärungen, Nutzerbeschreibungen und der Rollenkonzepte

Validierung bzw. Detaillierung u.a. von Schwachstellen, Maßnahmen, Gefährdungen und Risikobehandlung

Verifizierung der organisatorischen und technischen Maßnahmen im Rahmen der Risikoanalyse

Vervollständigung des IT-Grundschutzchecks inkl. modellierter IT-Grundschutz-Bausteine (Plattform & Anwendung)

Die Themenfelder “Schulung und Weiterbildung der Mitarbeiter”, “Allgemeine Themen des IT-Betriebs”, “Themen der baulichen und physischen Sicherheit”, “Bereitstellung von openDesk in einer Confidential Cloud (Vetrauliche Cloudumgebung)”, “Detaillierte Integrationsleistungen der openDesk SaaS-Lösung in ein Kundennetzwerk”, “Kunden-bezogene Penetrationstests und zu testende Konfigurationen” sowie “Lizenz-Themen” werden nicht behandelt.

Versionshistorie

Dokumentation der Änderungen und Aktualisierungen des Sicherheitskonzepts.

Datum	Tätigkeit	Bearbeiter	Versionsnummer
10.01.2024	Erstellung des Dokumentes	Christian Wolter	v0.01
21.01.2025	Erstellen des Inhaltsverzeichnisses, Kapitel “Bedrohungsanalyse” begonnen	Christian Wolter	v0.02
13.02.2025	Kapitel “Strukturanalyse” begonnen Kapitel “Risikoanalyse” begonnen Kapitel “Modellierung der Sicherheitsmaßnahmen” begonnen	Christian Wolter	v0.03
24.02.2025	Kapitel “Definition der Schutzbedarfskategorien”, “Definition STRIDE”, “Erhebung der IT-Systeme von openDesk”, “Schutzbedarfsfeststellung der Zielobjekte im Informationsverbund”, “Schwachstellen” erstellt	Christian Wolter	v0.1.1
31.03.2025	Kapitel “Risikoanalyse” und “Modellierung der Sicherheitsmaßnahmen” bearbeitet und fortgeführt	Christian Wolter	v0.2
19.05.2025	Diverse Optimierungen des Konzepts für die Lesbarkeit	Dirk Loßack	v1.0
30.06.2025	Diverse Optimierungen des Konzepts für die Lesbarkeit	Dirk Loßack	v1.11
29.07.2025	Kapitel “Erhebung der IT-Systeme von openDesk” wurde optimiert; Kapitel “Erhebung der Informationsdaten von openDesk” ist eingepflegt	Dirk Loßack	v1.19
12.09.2025	Behandlung der Risiken wurde entsprechend der Änderungen in der Strukturanalyse angepasst	Dirk Loßack	v1.2
17.10.2025	Detaillierung zur Modellierung der Sicherheitsmaßnahmen auf Anwendungsebene	Dirk Loßack	v1.3
24.11.2025	OpenSource hervorgehoben; Optimierung des Konzepts für die Lesbarkeit; Maßnahme vor die Gefährdungen zur leserlichen Darstellung platziert; B Inhaltsverzeichnis angepasst*	Dirk Loßack	v1.5

Glossar

Begriff	Definition
Informationsverbund	Ein Informationsverbund ist die Gesamtheit aller vernetzten IT-Systeme, Anwendungen und Kommunikationsverbindungen, einschließlich dedizierter abgrenzbarer Teilbereiche, die wesentliche Aufgaben und Geschäftsprozesse einer Institution unterstützen.

Inhaltsverzeichnis

Sicherheitskonzept openDesk

1. Einleitung

Software-as-a-Service (SaaS) Lösungen sind für den IT-Betrieb sowohl in der öffentlichen Verwaltung als auch in der Privatwirtschaft ein integraler Bestandteil. SaaS-Lösungen bieten Flexibilität, Skalierbarkeit, Kosteneffizienz und Kostenkontrolle. Mit der zunehmenden Nutzung von SaaS-Lösungen steigt auch die Notwendigkeit, robuste Sicherheitsmaßnahmen zu implementieren. Die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade) der Daten müssen gewährleistet sein. Weiterhin steigt die Bedrohungslage für IT-Systeme und digitale Infrastrukturen, insbesondere im öffentlichen Bereich, kontinuierlich. Cyberangriffe, Datenlecks und andere sicherheitsrelevante Vorfälle nehmen sowohl in Häufigkeit als auch in Komplexität zu. Daher muss jedes IT-System und jedes Informationssystem über ein robustes und umfassendes Sicherheitskonzept verfügen. Dieses Dokument dient als zentrales Sicherheitskonzept für die Bereitstellung von openDesk als SaaS-Lösung, welche auf der STACKIT-Plattform betrieben wird. In diesem Dokument wird openDesk immer im Kontext der Bereitstellung als SaaS-Lösung betrachtet.

1.1 Umfang und Zielsetzung

openDesk ist ein Open-Source-Entwicklungsprojekt, das vom Bundesministerium des Innern und für Heimat initiiert wurde. Es zielt darauf ab, der öffentlichen Verwaltung eine leistungsstarke Alternative zu proprietären Lösungen im Bereich des digitalen Arbeitsplatzes zu bieten.

Der Browser-basierte Arbeitsplatz von openDesk legt besonderen Wert auf:

Digitale Souveränität: Die Verwendung von Open-Source-Software ermöglicht eine unabhängige und kontrollierte IT-Infrastruktur.
Nutzerfreundlichkeit: Der Arbeitsplatz ist intuitiv und einfach zu bedienen, um die Effizienz der Verwaltung zu steigern.
Zukunftsfähigkeit: Die modulare Architektur ermöglicht die Integration neuer Technologien und die Anpassung an zukünftige Anforderungen.

openDesk unterstützt sowohl alltägliche Geschäfts- und Arbeitsprozesse als auch die virtuelle Zusammenarbeit. Dazu werden marktgängige Open-Source-Komponenten integriert und weiterentwickelt. Die IT-Architektur basiert auf:

Modularität: Die einzelnen Komponenten können unabhängig voneinander entwickelt und aktualisiert werden.
Austauschbarkeit: Die Komponenten können durch andere Open-Source-Lösungen ersetzt werden.
Interoperabilität: Die Komponenten können miteinander kommunizieren und Daten austauschen.

Das Wesen von openDesk besitzt hierzu folgende Merkmale:

Herstellerunabhängigkeit: Einzelne Module können durch Anwendungen anderer Hersteller ersetzt und in die Gesamtlösung integriert werden.
- openDesk ist modular aufgebaut und basiert auf Open-Source-Technologien, wodurch ein besserer Einblick in die Funktionsweisen und Datenhaltung ermöglicht werden kann. Der Modulare Ansatz verringert das Risiko eines Vendor Lock-in und unterstützt eine flexible Anpassung an sich verändernde Anforderungen und technologische Entwicklungen.
Innovationspotenzial: Neue Technologien und Lösungen können mit angemessenem Aufwand integriert werden.
- Die modulare Architektur von openDesk erlaubt eine effiziente Integration neuer Technologien und Funktionen, wobei gleichzeitig Beeinträchtigungen des Gesamtsystems reduziert werden können.
Sicherheit: Die Verwendung von Open-Source-Software erleichtert die Überprüfung der Funktionsweisen wodurch sich die IT-Umgebung zielgerichteter absichern lässt.
- Durch die Offenlegung des Quellcodes der Open-Source-Komponenten wird die Sicherheitsüberprüfung der Komponenten erleichtert, sowie die frühzeitige Erkennung und Behebung von Sicherheitslücken begünstigt.
Flexibilität: Die Verwaltung kann den Arbeitsplatz an ihre individuellen Bedürfnisse anpassen.
- Der modulare Aufbau von openDesk erleichtert eine bedarfsgerechte Bereitstellung und Konfiguration einzelner Komponenten, wodurch eine Integration in bestehende IT-Landschaften vereinfacht wird.

Das Ziel von openDesk ist es, die Zusammenarbeit zwischen den öffentlichen Verwaltungen zu stärken und einen unabhängigen IT-Betrieb zu ermöglichen. Dies umfasst sowohl die Softwarebereitstellung als auch die Informationsverarbeitung.

Innerhalb von openDesk sind hierfür verschiedene IT-Werkzeuge enthalten, z.B. zur Bearbeitung von Dokumenten, zum Dateiaustausch und zur Kommunikation. Dabei verfolgt openDesk einen vollständigen Open-Source Ansatz. Jeglicher Quellcode wird dafür über die Plattform Open CoDE veröffentlicht und regelmäßig aktualisiert. Die Abbildung “openDesk Generelle Architektur High-Level (Entwurf, v0.2)” stellt hierzu die generellen openDesk Architektur dar:

Entwurf_Architektur

Dieses Sicherheitskonzept zielt darauf ab, die wesentlichen Sicherheitsanforderungen und -maßnahmen für openDesk zu definieren. Es beschreibt die Strategien und Technologien, die eingesetzt werden, um potenzielle Bedrohungen zu identifizieren, zu verhindern und zu mitigieren. Darüber hinaus werden die Prozesse und Verantwortlichkeiten festgelegt. Sicherheitsvorfälle können effektiv gemanagt werden und erfüllen sowohl die gesetzlichen als auch die regulatorischen Anforderungen. Hierzu wird openDesk immer als ein Gesamtsystem betrachtet, sodass eine gesamtheitliche Betrachtung aller Bestandteile und bestehender Systemabhängigkeiten von openDesk erfolgt. Dies umfasst die Cloud Infrastruktur, die Plattform, als auch die einzelnen Applikationen der Software.

Ein sicherer, stabiler und leistungsfähiger Betrieb von openDesk kann nur bei Einhaltung der hier beschriebenen Maßnahmen und Vorkehrungen gewährleistet werden. Der Betreiber hat die genannten Sicherheitsvorkehrungen zu beachten, das System gemäß diesen Anforderungen zu betreiben und weiterzuentwickeln.

1.2 Adressatenkreis

Primär ist dieses Sicherheitskonzept an die Verantwortlichen von openDesk gerichtet, welche u.a. folgende Zielgruppen umfasst:

Das entscheidungstragende Management für die IT-Sicherheit im Rahmen der Zustandsüberwachung.
Mitarbeiter, welche für die Entwicklung, Implementierung und Wartung der Sicherheitsaktivitäten verantwortlich sind.
Systemingenieure und -architekten, die für den Entwurf, die Implementierung und die Modifizierung verantwortlich sind.
Systemadministratoren, welche für die Aufrechterhaltung des täglichen Betriebs verantwortlich sind.
Abteilungen der jeweiligen Softwareeigentümer der Module von openDesk.
Weitere potenziell interessierte Parteien, wie z.B. interne und externe Prüfer.

1.3 Dokumentenaufbau

Im Rahmen dieses Sicherheitskonzepts werden folgende Themengebiete behandelt:

Strukturanalyse: Eine detaillierte Untersuchung der Systemarchitektur und dessen Komponenten, um potenzielle Schwachstellen zu identifizieren.
Bedrohungsanalyse: Die Identifikation und Bewertung möglicher Sicherheitsbedrohungen.
Risikoanalyse: Eine systematische Bewertung der identifizierten Risiken, um deren potenzielle Auswirkungen und Eintrittswahrscheinlichkeiten zu bestimmen.
Modellierung von Anforderungen: Die Definition und Spezifikation von Sicherheitsanforderungen, die zur Absicherung von openDesk notwendig sind.
Sicherheitsmaßnahmen: Die Implementierung konkreter technischer, organisatorischer und personeller Sicherheitsmaßnahmen der identifizieren Risiken zu mitigieren, sowie die Sicherheitsanforderungen zu erfüllen.

1.4 Angewendete Standards

Für die Gewährleistung eines robusten, zuverlässigen und sicheren Betriebes des digitalen Arbeitsplatzes ist die Einhaltung etablierter Standards essenziell. Diese Standards dienen als Maßstab für die organisatorischen und technischen Anforderungen und bieten Richtlinien und Rahmenbedingungen. Diese unterstützen Sicherheitsrisiken zu erkennen und abzuschwächen. Die unten beschriebenen Standards sind auf nationaler Ebene fester Bestandteil einer jeder IT-Umgebung und zum Teil auch international anerkannt und etabliert. Dazu gehören national der BSI IT-Grundschutz und der BSI C5. International gehört der CIS-Benchmark (für Linux Server und Kubernetes), The Twelve-Factor App (Die Zwölf-Faktor-App), Top Threats to Cloud Computing 2024 (Die größten Bedrohungen für Cloud Computing 2024) und OWASP Top 10 dazu. Jeder dieser Standards befasst sich mit speziellen Sicherheitsaspekten, die von allgemeinen Best Practices bis hin zu spezifischen Richtlinien für bestimmte Technologien oder Branchen reichen.
In der Tabelle “Angewendete Standards” sind diese mit einer kurzen Beschreibung aufgeführt.

Standard	Notwendigkeit openDesk SaaS
BSI C5	Der BSI C5 (Cloud Computing Compliance Controls Catalogue) ist ein vom BSI entwickelter Kriterienkatalog. Der Kriterienkatalog definiert die Anforderungen an die Informationssicherheit von Cloud-Diensten. Der C5-Katalog dient als Leitfaden für Cloud-Anbieter und -Nutzer, so dass die angebotenen Cloud-Dienste den hohen Sicherheitsstandards entsprechen. Dies umfasst unter anderem Maßnahmen zur Datensicherheit, der Zugriffskontrollen und dem Notfallmanagement. Durch die Einhaltung des C5-Katalogs werden Cloud-Anbieter ihren Kunden gegenüber in die Lage versetzt transparent die getroffenen Sicherheitsmaßnahmen und -kontrollen darzulegen. Außerdem unterstützt der BSI C5 dabei, diese weiteren unternehmerische Anforderungen zu erfüllen und erleichtert damit die Nachweispflicht z.B. gegenüber Aufsichtsbehörden. Risiken werden im Zusammenhang mit der Nutzung von Cloud-Diensten identifiziert und mitigiert.
BSI IT-Grundschutz	Der BSI IT-Grundschutz ist ein auf nationaler Ebene bewährtes Rahmenwerk für IT-Sicherheit. Dieser wird vom Bundesamt für Sicherheit in der Informationstechnik (BSI) erstellt, das als deutsche Behörde für die IT-Sicherheit des Bundes zuständig ist. Der BSI IT-Grundschutz bietet eine systematische und strukturierte Herangehensweise an die IT-Sicherheit, um Risiken zu erkennen und zu minimieren. Das Rahmenwerk unterstützt dabei, die Effizienz von IT-Sicherheitsmaßnahmen durch eine klare Strukturierung und Priorisierung von Maßnahmen zu verbessern. Es ist jedoch an die individuellen Bedürfnisse und Anforderungen einer IT-Umgebung anpassbar, so dass es keine genauen Vorgaben für ihre Umsetzung gibt.
CIS-Benchmark	Der CIS-Benchmark (Center for Internet Security) ist ein weltweit anerkannter Standard zur Systemhärtung. Diese Benchmarks bestehen aus Best Practices von Sicherheitsexperten und Anbietern von Härtungsspezifikationen. Sie sind für eine Vielzahl von Betriebssystemen, Anwendungen und Netzwerkgeräten verfügbar und enthalten detaillierte Anweisungen zur Konfiguration von Sicherheitseinstellungen. Ziel der Benchmarks ist es, mögliche Schwachstellen zu identifizieren und zu schließen. Ein weiterer Vorteil der CIS-Benchmarks ist ihre regelmäßige Aktualisierung und die Reaktion auf neue Bedrohungen und Schwachstellen. Wenn ein System gemäß CIS gehärtet wurde, werden zahlreiche Testmethoden bereitgestellt.
MITRE ATT&CK Framework	MITRE ATT&CK steht als Akronym für Adversarial Tactics, Techniques and Common Knowledge. Es handelt sich um ein wissensbasiertes Framework, das reale Angriffsverhaltensweisen systematisch dokumentiert und kategorisiert. Im Mittelpunkt stehen Taktiken, welche die strategischen Ziele eines Angreifers beschreiben, sowie Techniken, welche die konkrete Umsetzung dieser Ziele darstellen. Das Framework basiert auf empirisch beobachteten Angriffsmethoden und entwickelt sich kontinuierlich weiter. Das MITRE ATT&CK Framework wird im Rahmen der Threat Analyse eingesetzt, um Angriffsvektoren strukturiert zu erfassen und ihre Auswirkungen auf Sicherheitsziele zu bewerten.
OWASP Top 10	Das Open Worldwide Application Security Project (OWASP) ist eine gemeinnützige Organisation, die sich der Verbesserung der Sicherheit von Anwendungen, Diensten und Software widmet. Von ihr werden individuelle, auf diverse IT-Bereichen und Softwareentwicklung angepasste Top 10 gepflegt und veröffentlicht.
The Twelve-Factor App	Die Twelve-Factor App (Zwölf-Faktoren-App) ist eine anerkannte Methodik für die Entwicklung sicherer Webanwendungen mit dem Schwerpunkt auf dem Hosting in einem Kubernetes-Cluster. Sie listet mehrere Best Practices für die sichere und zuverlässige Softwareentwicklung und das Hosting auf und ist auf jede Programmiersprache und jede Verwendung von unterstützenden Diensten anwendbar, z.B. Middleware-Dienste, Gateways oder Datenbanken.
Top Threats to Cloud Computing 2024	Die Cloud Security Alliance (CSA), eine Non-Profit-Organisation mit 48.000 Mitgliedern weltweit, veröffentlicht jährlich eine Rangliste der Sicherheitsbedrohungen im Cloud Computing. Diese Rangliste dient Unternehmen und Organisationen sich über die aktuellen und sich entwickelnden Bedrohungen zu informieren und ihnen zu helfen, ihre Sicherheitsstrategien entsprechend anzupassen und zu verbessern. Neben nationaler Betrachtung von Bedrohungen, dient dieser Standard für openDesk als internationaler Vergleich für die Vorbereitung auf Risiken, sowie die Mitigierung dieser.

1.5 Definition Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade)

Die CIA-Triade sind die drei grundlegenden Prinzipien der Informationssicherheit und das allgemeine Schutzziel für jedes IT-System: C für Confidentiality (Vertraulichkeit), I für Integrity (Integrität) und A für Availability (Verfügbarkeit) werden im Folgenden kurz beschrieben und klassifiziert. Auswirkungen beschreibt Faktoren wie z. B. finanzieller Art, Reputation, geistiges Eigentum oder Compliance im Rahmen der eigens gesetzten Schutzziele der Institution.

1.5.1 Vertraulichkeit

Das Kriterium der Vertraulichkeit entspricht der geschäftlichen Notwendigkeit, den Zugang zu Informationen freigeben oder einschränken zu können. Dies bedingt auch die Befähigung Einschränkungen kontrollieren zu können.

Klassifikation Vertraulichkeit	Definition
normal	Informationen, deren Offenlegung keine wesentlichen negativen Auswirkungen auf das Unternehmen oder seine Partner hätte.
hoch	Informationen, deren unbefugte Offenlegung moderate negative Auswirkungen auf das Unternehmen oder seine Partner haben könnte.
sehr hoch	Informationen, deren unbefugte Offenlegung erhebliche negative Auswirkungen auf das Unternehmen oder seine Partner haben könnte.

1.5.2 Integrität

Das Kriterium der Integrität entspricht der geschäftlichen Notwendigkeit, Änderungen an den Informationen zu kontrollieren. Diese Kontrollfunktion erfordert wiederum den Schutz der Richtigkeit und Vollständigkeit dieser Informationen.

Klassifikation Integrität	Definition
normal	Informationen, die von jedem Nutzer, der im Rahmen seiner normalen Geschäftstätigkeit Zugang zu diesen Daten hat, geändert werden können.
hoch	Änderungen an diesen Informationen sind nur im Rahmen eines formalisierten Änderungsprozesses möglich.
sehr hoch	Informationen in diesen Klassifizierungen müssen sicherstellen, dass sie nicht verändert oder manipuliert werden können.

1.5.3 Verfügbarkeit

Das Kriterium der Verfügbarkeit bedingt eine stetige Erreichbarkeit von IT-Systemen, sowie stetig abrufbare Informationen für die befugten Personen.

Klassifikation Verfügbarkeit	Definition
normal	Informationen, deren Beibehaltung wünschenswert ist, deren Verlust jedoch das Tagesgeschäft des Unternehmens nicht gefährden würde.
hoch	Die meisten Informationen oder Systeme unterliegen dieser Einstufung und werden gemäß den üblichen Praktiken behandelt, wie z.B. Spiegelung der Festplatten und Aufnahme in bestehende Pläne zur Aufrechterhaltung des Geschäftsbetriebs.
sehr hoch	Auftrags- und Mandats-bezogene kritische Informationen oder Systeme unterliegen dieser Klassifizierung. Ihr Verlust würde sich stark negativ auf das Geschäft auswirken oder die Arbeit unmöglich machen.

1.6 Definition der Schutzbedarfskategorien

Die Schutzbedarfskategorien helfen den notwendigen Schutz für IT-Systeme und Daten festzulegen und zu priorisieren. Eine Einordnung in Schutzbedarfskategorien unterstützt bei der Bewertung möglicher Auswirkungen von Störungen und Vorfällen, wie z. B. die Datensicherheit, die Datenintegrität, die Verfügbarkeit der Dienste, die Anwendungssicherheit, die Vertraulichkeit etc. im Rahmen der eigens gesetzten Schutzziele der Institution, sowie bei der Ergreifung geeigneter Sicherheitsmaßnahmen.

Im Folgenden sind die Schutzbedarfskategorien und ihre Definitionen sowie Beispiele für jede Kategorie aufgeführt:

Schutzbedarfskategorie	Definition	Beispiele
normal	Beeinträchtigung von IT-Systemen und Daten haben eine geringe Auswirkung	kurzfristiger Ausfall der öffentlichen Website
hoch	Beeinträchtigung von IT-Systemen und Daten haben eine moderate Auswirkung	Ausfall von internem E-Mail-Server
sehr hoch	Beeinträchtigung von IT-Systemen und Daten haben eine fundamentale Auswirkung	Verlust und Verbreitung personenbezogener Daten

1.7 Definition STRIDE

STRIDE ist ein Akronym und steht für Spoofing (Nachahmen oder Vortäuschen einer Identität), Tampering (fälschen und manipulieren von Daten), Repudiation (Abstreiten einer Handlung), Information Disclosure (aufdecken, veröffentlichen von Informationen), Denial of Service (erzwungene Nichtverfügbarkeit eines Dienstes) und Elevation Privilege (unzulässige Erweiterung von Rechten). STRIDE wurde 2002 von Microsoft für die Klassifizierung von Angriffsmustern entwickelt. Die folgende Tabelle beschreibt die Bedrohungen und ordnet diese den Kriterien zu, die davor schützen.

Definition der Kriterien:

Authentifizierung ist der Prozess der Überprüfung der Identität eines Benutzers oder Systems, um sicherzustellen, dass die angegebene Identität korrekt ist.
Nichtabstreitbarkeit stellt sicher, dass eine durchgeführte Aktion oder Transaktion nicht im Nachhinein von ihrem Urheber geleugnet werden kann, indem Beweise wie digitale Signaturen verwendet werden.
Autorisierung ist der Prozess der Zuweisung von Rechten und Berechtigungen an einen authentifizierten Benutzer oder ein System, um den Zugriff auf Ressourcen und Dienste zu steuern.
Die Kriterien Integrität, Verfügbarkeit und Vertraulichkeit sind im Kapitel 1.6 definiert.

Kategorie	Beschreibung	Kriterien
Spoofing (Vortäuschung)	Umfasst unberechtigten Zugriff auf und die anschließende Verwendung der Authentifizierungsinformationen eines anderen Benutzers, z.B. Benutzername und Kennwort.	Authentifizierung
Tampering (Manipulation)	Umfasst die böswillige Änderung von Daten. Beispiele sind nicht autorisierte Änderungen von persistenten Daten, z.B. der Daten in einer Datenbank, und die Änderung von Daten bei der Übertragung zwischen zwei Computern über ein offenes Netzwerk wie das Internet.	Integrität
Repudiation (Abstreitung)	Ein Benutzer oder eine Entität streitet die Durchführung eine Tätigkeit ab. Bei unzureichenden Beweisen oder Protokollen kann Repudiation die Nachweisbarkeit und Verantwortlichkeit untergraben. Insbesondere in rechtlichen oder regulatorischen Angelegenheiten ist Repudiation kritisch. Für ein Entgegenwirken können Maßnahmen wie digitale Signaturen, umfassende Protokollierung und Audit-Trails eingesetzt werden. Gerade im Bereich von SaaS-Diensten kann dies unter anderem für kritische Änderungen an Einstellungen in der Anwendung, wie z.B. die Zugriffskontrollen oder Sicherheitskonfigurationen gelten.	Nichtabstreitbarkeit
Information Disclosure (Veröffentlichung von Informationen)	Ein unbefugtes Offenlegen von sensiblen Daten wie persönliche Informationen, Geschäftsgeheimnisse oder vertrauliche Dokumente von unautorisierten Personen gefährden die Vertraulichkeit. Beispielhaft können aufgrund einer Fehlkonfiguration der Zugriffskontrollen nicht autorisierte Benutzer auf Datenbanken zugreifen und sensible Informationen wie Namen, Adressen und Kreditkartendaten einsehen.	Vertraulichkeit
Denial-of-Service (Verweigerung)	Bei DoS-Angriffen (Denial of Service) wird berechtigten Benutzern der Zugriff auf einen Dienst verweigert, indem z.B. ein Webserver vorübergehend nicht verfügbar oder nicht nutzbar gemacht wird. Um die Verfügbarkeit und Zuverlässigkeit aufrecht zu erhalten, muss sich vor DoS-Angriffen geschützt werden.	Verfügbarkeit
Elevation of Privilege (Rechteerweiterung)	Ein nicht autorisierter Benutzer erlangt erweiterte Rechte oder privilegierten Zugriff. Der Benutzer verfügt dann über ausreichende Zugriffsrechte zur Kompromittierung des gesamten Systems. Ein Angreifer nutzt eine Sicherheitslücke, um sich Administratorrechte zu verschaffen. Mit diesen erweiterten Rechten kann der Angreifer auf sensible Daten zugreifen, Sicherheitskonfigurationen ändern und das gesamte System lahmlegen.	Autorisierung

1.8 Definition MITRE

MITRE ATT&CK steht als Akronym für Adversarial Tactics, Techniques and Common Knowledge. Es handelt sich um ein wissensbasiertes Framework, das reale Angriffsverhaltensweisen systematisch dokumentiert und kategorisiert. Im Mittelpunkt stehen Taktiken, welche die strategischen Ziele eines Angreifers beschreiben, sowie Techniken, welche die konkrete Umsetzung dieser Ziele darstellen. Das Framework basiert auf empirisch beobachteten Angriffsmethoden und entwickelt sich kontinuierlich weiter. Das MITRE ATT&CK Framework wird im Rahmen der Threat Analyse eingesetzt, um Angriffsvektoren strukturiert zu erfassen und ihre Auswirkungen auf Sicherheitsziele zu bewerten.

Die folgende Tabelle veranschaulicht die Angriffstaktiken des MITRE ATT&CK Frameworks:

Taktik	Beschreibung
Reconnaissance (Aufklärung)	Sammeln von Informationen über das Zielsystem, Benutzer oder Netzwerk, um Angriffsmöglichkeiten vorzubereiten.
Resource Development (Ressourcenaufbau)	Beschaffung oder Erstellung von Infrastruktur und Werkzeugen, die für spätere Angriffsschritte benötigt werden.
Initial Access (Erstzugriff)	Erstmaliges Eindringen in ein System, zum Beispiel über Phishing, Schwachstellen oder kompromittierte Zugangsdaten.
Execution (Ausführung)	Ausführen von Schadcode oder Befehlen, etwa durch Skripte, Makros oder Laufzeitumgebungen.
Persistence (Beständigkeit)	Einrichtung dauerhafter Zugriffsmöglichkeiten, die selbst nach Neustarts oder Passwortänderungen bestehen bleiben.
Privilege Escalation (Privilegienausweitung)	Erweiterung der Zugriffsrechte, um administrative oder privilegierte Aktionen ausführen zu können.
Defense Evasion (Schutzumgehung)	Vermeidung, Täuschung oder Deaktivierung von Sicherheitsmechanismen wie Monitoring oder Protokollierung.
Credential Access (Anmeldeinformationszugriff)	Beschaffung von Zugangsdaten wie Passwörtern, Zertifikaten oder Tokens zur weiteren Kompromittierung.
Discovery (Erkundung)	Analyse der Umgebung, um Systeme, Dienste, Berechtigungen und Netzwerkstrukturen zu identifizieren.
Lateral Movement (Seitliche Bewegung)	Bewegung innerhalb der Netzwerkumgebung, zum Beispiel über Remote Services oder gestohlene Zugangsdaten.
Collection (Datensammlung)	Sammeln und Organisieren von sensiblen Informationen zur Vorbereitung weiterer Schritte.
Command and Control (Kommando und Kontrolle)	Aufbau und Nutzung einer Kommunikationsverbindung, um kompromittierte Systeme fernzusteuern.
Exfiltration (Datenabfluss)	Entwendung von Daten über verdeckte oder verschlüsselte Übertragungswege.
Impact (Schadenwirkung)	Schädigung von Systemen oder Daten, zum Beispiel durch Manipulation, Verschlüsselung oder Löschung.

2. Festlegung des Informationsverbunds im Rahmen des Sicherheitskonzeptes für openDesk

Die Festlegung des Informationsverbunds ist ein zentraler Bestandteil des Sicherheitskonzept. Mehrere einzelne containerisierte Anwendungen, die das endgültige Produkt openDesk vervollständigt, liegen der Betrachtung des vorliegenden Sicherheitskonzepts zugrunde, wobei der Fokus auf openDesk als SaaS-Endprodukt liegt. Weitere Betrachtungen unterliegen den jeweiligen Verantwortlichen der einzelnen Komponenten, wie u.a. der physischen Infrastruktur, der virtuellen Infrastruktur usw.

2.1 Informationsdomäne

Dieses Sicherheitskonzept bezieht sich auf die Bereitstellung von openDesk als SaaS-Lösung und umfasst die damit zusammenhängende Informationsdomänen, wie Kundendaten, Anwendungsdaten und Mitarbeiterdaten. Im Informationsverbund werden die Sicherheitsfunktionen sowie die Grundkonfiguration der SaaS-Lösung openDesk als Ganzes betrachtet.

2.2 Abgrenzung

Dieses Sicherheitskonzept stellt die Sicherheitsanforderungen für openDesk als SaaS-Lösung dar. Es enthält jedoch keine Anforderungen oder Implementierungen für Themen, die nicht direkt auf die openDesk SaaS-Lösung anwendbar sind. Unter anderem betrifft dies folgende Themen:

Schulung und Weiterbildung der Mitarbeiter

Eine Berücksichtigung der Schulung und Weiterbildung von Mitarbeitern findet in diesem Dokument nicht statt. Die Verantwortung für die Qualifizierung der Mitarbeiter liegt beim Betreiber der SaaS-Lösung von openDesk, sodass die geforderten Sicherheitsrichtlinien und -bestimmungen verstanden und umgesetzt werden. Darunter fallen z. B. Phishing Simulation oder Cyber Awareness Training.
Allgemeine Themen des IT-Betriebs

Alltägliche Betriebsabläufe und die Verwaltung der IT-Infrastruktur, die Teil der allgemeinen Themen des IT-Betriebs sind, werden nicht betrachtet, wie z. B. die Anwendung des ITIL Frameworks, Operational Excellence oder ähnliches. Diese Aspekte sind unabhängig von der SaaS-Lösung und werden internen IT-Prozesse des Betriebs abgedeckt. Das Dokument konzentriert sich auf die Bereitstellung der SaaS-Lösung und nicht auf die Verwaltung der gesamten IT-Umgebung.
Themen der baulichen und physischen Sicherheit

Bauliche und physische Sicherheitsmaßnahmen, wie Zugangskontrollen, Überwachungstechnologie oder Sicherheitsprotokollierungen, sind nicht Teil des Sicherheitskonzepts. Es wird vorausgesetzt, dass die SaaS-Lösung auf eine konforme Hyperscaler Umgebung betrieben wird.
Bereitstellung von openDesk in einer Confidential Cloud (vertrauliche Cloud-Umgebung)

Die Bereitstellung von openDesk in einer Confidential Cloud wird nicht betrachtet. Die SaaS-Lösung wird zentral auf die vorgegebene Hyperscaler Umgebung bereitgestellt.
Detaillierte Integrationsleistungen der openDesk SaaS-Lösung in ein Kundennetzwerk

Die Integration in ein Kundennetzwerk hängt stark von der spezifischen Netzwerkarchitektur und den Sicherheitsanforderungen des Kunden abhängt. Der Kunde ist verantwortlich für die sichere Integration von openDesk in seine bestehende IT-Umgebung, einschließlich der Konfiguration von Firewalls und anderen Sicherheitsvorkehrungen.
Kunden-Bezogene Penetrationstests und zu testende Konfigurationen

Dies erfordert spezifische Tests, Anpassungen und Abstimmungen auf die individuelle IT-Umgebung des Kunden. Es liegt in der Verantwortung des Kunden regelmäßig Penetrationstests durchführen.
Lizenz-Themen

Lizenz-Themen beziehen sich auf die rechtlichen und vertraglichen Aspekte der Nutzung der SaaS-Lösung. Für die Einhaltung der Lizenzbedingungen und die Verwaltung der Lizenzen gilt gemäß der vertraglichen Vereinbarungen zwischen den jeweiligen Parteien und weiteren Dritten.

Dieses Dokument stellt zudem keine detaillierten Konzepte einzelner Systeme oder Anwendungen vor, sondern weist lediglich auf Sicherheitsaspekte hin, die für den zukünftigen Betrieb berücksichtigt werden müssen Diese sind weiteren organisatorischen oder technischen Konzepten untergeordnet, wie z.B. einem Disaster-Recovery-Konzept, einem Netzwerkkonzept, einem Backup-Konzept, einem Betriebshandbuch, einem Staging-Konzept und weiteren Bedarfs-bedingten Konzepten.

3. Strukturanalyse als Basis des Sicherheitskonzeptes für openDesk

Erhebung von Informationen, die für die weitere Vorgehensweise in der Erstellung des Sicherheitskonzeptes benötigt werden. Dabei geht es um die Erfassung folgender Bestandteile:

Anwendungen, Container, IT-Systeme und sicherheitsrelevante IT-Komponenten.

Allzu oft werden Container hierbei mit virtuellen Maschinen verwechselt oder gleichgesetzt und dadurch irreführende Annahmen hinsichtlich Sicherheit und Isolierung gemacht, weshalb an dieser Stelle zuerst eine Einordnung erfolgt.

Virtuelle Maschinen (VM) simulieren quasi ein komplettes Betriebssystem, indem sie einen physischen Server emulieren und damit virtualisiert bereitstellen, sodass Anwendungen darin betrieben werden können. Von außen betrachtet sieht eine virtuelle Maschine so aus und verhält sich auch so wie ein komplett separater, “echter” Server im Netzwerk. Bei einer solchen virtuellen Maschine handelt es sich meist um eine einzige Datei, welche auch den notwendige Festplattenspeicher beinhaltet, um Betriebssystem, Anwendungen und Daten zu speichern.

Bei Containern handelt es sich um leichtgewichtige Alternativen zu virtuellen Maschinen, jedoch mit ein paar Einschränkungen. Container und virtuelle Maschinen haben gemeinsam, dass sie Ressourcen des Host Systems verwenden. Während bei virtuellen Maschinen eine Emulation und Virtualisierung der für den Betrieb notwendigen Hardware stattfindet, ist dies so bei Containern nicht der Fall. Stattdessen nutzen Container direkt die vom Host bereitgestellten Ressourcen wie CPU, Arbeitsspeicher und ggf. Festplattenspeicher. Daher spricht man bei Containern von einer Isolierung auf Prozessebene, nicht von einer Virtualisierung. Daher können Container ohne weitere Maßnahmen kein vergleichbares Schutzniveau wie virtuelle Maschinen bieten.

Virtuelle Maschinen bieten daher designbedingt eine höhere Isolierung und Kapselung von der darunterliegenden Infrastruktur. Sollte ein Angreifer Zugriff auf eine virtuelle Maschine bekommen, so ist er zunächst in dieser “eingesperrt” und hat bei richtiger Konfiguration keinen oder sehr wenigen Zugriff auf die darunterliegende Infrastruktur, also den physischen Server oder das Netzwerk. Hat ein Angreifer dagegen einen ungehärteten Container kompromittiert, hat er meistens tiefgreifenderen Zugriff bzw. kann er sich diesen schneller und leichter verschaffen als bei einer VM.

Als Angriffsvektor formuliert bedeutet das, dass eine virtuelle Maschine gewöhnlich mehr Angriffsfläche bietet als ein ungehärteter Container, aber im Falle einer Kompromittierung die darunterliegende Infrastruktur bei einem Container weniger stark geschützt ist als bei einer virtuellen Maschine.

In vielen Fällen ist die Triebfeder hinter den Bemühungen zur Container-Härtung eine angestrebte Zertifizierung nach branchenüblichen Standards, jedoch sollte jeder auch ohne diese Zielsetzung das vitale Interesse haben, einen sicheren Betrieb gewährleisten zu können. Neben den Maßnahmen zur Absicherung und Härtung der Plattform, auf welcher openDesk betrieben werden soll, stellt der containerisierte Betrieb von openDesk eine zusätzliche Herausforderung dar. Die Härtung von Containern ist dabei nur ein Teil; die Unterstützung des Betriebs der Container durch zusätzliche Sicherungsmaßnahmen wie Richtlinien, die das gewünschte Verhalten der containerisierten Anwendungen erzwingen, trägt einen ebenso wichtigen Teil bei.

Der Container-Härtung kommen daher drei Aufgaben zu, um die maximale Sicherheit von openDesk zu gewährleisten:

Schutz der im Container betriebenen Komponenten von openDesk selbst
Schutz anderer Anwendungen bzw. weiterer Komponenten von openDesk auf der gleichen Plattform
Schutz der zugrundeliegenden Infrastruktur, wodurch weitreichender Zugriff und damit erhöhte Gefahr für alle Anwendungen und Komponenten von openDesk besteht

In allen drei Fällen gilt es, Attacken und Einbrüche abzuwehren, um Ausfälle zu verhindern und Datenkorruption oder -diebstahl zu vermeiden. Hierbei ist es wichtig, die Gesamtheit zu betrachten. Bleibt eine vermeintlich unwichtige Komponente von openDesk ungeschützt, so kann ein Angreifer diese kompromittieren, sich so Zugriff auf die Plattform beschaffen und damit nicht “von außen”, sondern “von innen” weitere Komponenten von openDesk kompromittieren, welche ggf. nur gegen Angriffe “von außen” geschützt waren. Insbesondere in geteilten Umgebungen mit unzureichendem Schutz der Plattform erhöht sich dieses Risiko erheblich.

Im Gegensatz zur Härtung von virtuellen Maschinen gibt es für die Container-Härtung keinen echten Standard, gemäß welchem man zuverlässig festmachen kann, ob ein Container adäquat gehärtet ist. Vielmehr existieren Best-Practices zur Härtung, auf welche im Folgenden eingegangen werden wird.

Im Gegensatz zur Härtung von Servern, virtuellen Maschinen oder Container-Plattformen existieren für Container selbst keine echten Standards, sondern lediglich Best-Practices. Diese zielen auf die sichere und nachhaltige Entwicklung von Software, hier openDesk, als auch auf den sicheren Betrieb und die zuverlässige Wartung ab. Aber auch der Schutz der darunterliegenden Plattform wird durch die Best-Practices indirekt mit betrachtet. Idealerweise werden diese Best-Practices, zusammen mit anderen Regeln für Plattform selbst, nicht nur passiv eingehalten, sondern aktiv erzwungen. Konkret an einem Beispiel, dass Container nicht mit Root-Rechten laufen sollen, bedeutet dies, dass auf der einen Seite die Software so entwickelt werden muss, dass sie diese Rechte nicht benötigt, aber auf der anderen Seite die Plattform die Ausführung der Software dann auch aktiv unterbindet, sollte sie z.B. durch einen Konfigurationsfehler oder aber einen gezielten Angriff mit Root-Rechten versuchen zu laufen.

3.1 Integrierte Anwendungen in openDesk

openDesk ist modular aufgebaut und besteht aus einer Vielzahl von Container-basierten Softwarekomponenten auf Basis von Open-Source Lösungen, welche durch Kubernetes orchestriert werden. Die Funktionalitäten von openDesk beinhalten:

ID	Anwendung	Funktionsmodul	Hersteller
1.	Collabora	Weboffice	Collabora Ltd.
2.	CryptPad	Diagram Editor	XWiki SAS
3.	Element	Textnachrichten-, Audio- und Videokommunikationsdienst (TAV)	Element GmbH
4.	Jitsi Meet	virtuelle Besprechungen	Nordeck IT + Consulting GmbH
5.	Nextcloud	File Management	Nextcloud GmbH
6.	Nubus	Identity- und Accessmanagament (IAM), Application Access Portal	Univention GmbH
7.	OpenProject	Projektmanagement	OpenProject GmbH
8.	OX App Suite	Groupware	Open-Xchange AG
9.	XWiki	Knowledge Management	XWiki SAS
10.	Notes	Journal	DINUM & ZenDiS

Hieraus ergibt sich die folgende Software High-Level Architektur:

Entwurf_Software High-Level Architektur

1. Collabora - WebOffice (Webbasierte Büroanwendung)

Um Office-Dokumente wie Rich-Text-Dokumente, Tabellenkalkulationen und Präsentationen zu bearbeiten, wird WebOffice als Modul verwendet. Diese Integration ermöglicht es, Dokumente direkt im Browser zu erstellen, zu bearbeiten und gemeinsam zu nutzen.

2. CryptPad - Diagram Editor

Um diagrams.net-Dokumente zu bearbeiten, wird der Diagram Editor genutzt, um Benutzern zu ermöglichen, Diagramme und grafische Darstellungen direkt im Browser zu erstellen, zu bearbeiten und gemeinsam zu nutzen.

3. Element - TAV

Das Modul TAV wird für diverse Kommunikationszwecke eingesetzt, einschließlich Textnachrichten sowie direkter Audio- und Videoanrufe für eine nahtlose und effiziente Interaktion.

4. Jitsi Meet - virtuelle Besprechungen

Das Modul wird für digitale Meetings genutzt, um kollaborativ ortsunabhängig und kosteneffizient miteinander zu arbeiten.

5. Nextcloud - File Management (Dateiverwaltung)

Als eine Plattform für Dateispeicherung und -synchronisation mit leistungsstarken Kollaborationsfunktionen, die über Desktop-, Mobil- und Webschnittstellen zugänglich sind, bietet das File Management die zentrale Verwaltung, den sicheren Austausch und die Synchronisation von Dateien in Echtzeit.

6. Nubus - Identity- und Accessmanagament (IAM, Identitäts- und Zugriffsmanagement), Application Access Portal (Zugriffsportal auf die Anwendungen)

Das Modul IAM stellt Funktionen Zentralisierung und Vereinfachung des Identitätsmanagements in IT-Umgebungen. Folgende Funktionen werden durch das Modul bereitgestellt:

Identity Provider (IdP, Identitätsanbieter): Mit der Open-Source Softwarelösung Keycloak fungiert dieser als zentraler IdP, verwaltet die Authentifizierungstoken für Anwendungen und übernimmt die Benutzerauthentifizierung.
Access Control Layer (Ebene der Zugriffskontrolle): Durch die Nutzung von RBAC wird sichergestellt, dass ein Zugriff auf dedizierte Systeme, Dienste oder APIs nur durch autorisierte Benutzer erfolgen kann.
Integrations-Hub: Dieser synchronisiert Identitäts- und Zugriffsdaten zwischen Anwendungen, um Konsistenz zu gewährleisten.
User Provisioning (Benutzerbereitstellung): Auf Grundlage der organisatorischen Abläufe, erfolgt die Erstellung, Aktualisierung und Deaktivierung von Benutzerkonten in integrierten Systemen automatisiert.
IAM-Administration: Per vereinfachter Version der Univention Management Console (UMC) werden Benutzer-, Gruppen- und Berechtigungsinformationen verwaltet.
Frontend Integration Authentication (Authentifizierungsintegration im Frontend): Über den der Intercom Service / Silent Login ist sichergestellt, dass das Frontend anwendungsübergreifend die API eines anderen Dienstes aufrufen kann, welcher ebenfalls eine Benutzerauthentifizierung benötigt.
Application Access Portal (Portal für den Anwendungszugriff): Für den Zugriff auf einzelnen Anwendungen, ist über bereitgestellte Application Access Portal zu nutzen.

7. OpenProject - Project Management (Projektverwaltung)

Das Project Management bietet eine Vielzahl von Funktionen, darunter agiles Projektmanagement, Issue-Tracking, Zeit- und Kostenmanagement, sowie die Verwaltung von Projektplänen und Meilensteinen.

8. OX App Suite - Groupware

Groupware wird für E-Mail, Kalender, Adressbuch und das persönliche Aufgabenmanagement verwendet und alle wichtigen Kommunikations- und Organisationsfunktionen in einer einzigen Anwendung ab.

9. XWiki - Knowledge Management

Das Knowledge Management bietet eine umfassende Wissensplattform an, um Inhalte innerhalb der Organisation zu erstellen, zu teilen und zu verwalten, so dass wertvolle Informationen leicht zugänglich und zentralisiert sind.

10. Notes - Journal

Journal dient dem strukturierten Erfassen und Organisieren von Gedanken, Aufgaben und Informationen. Sie bietet eine klare Oberfläche, Offline-Bearbeitung mit Versionskontrolle.

3.2 Erhebung der IT-Systeme von openDesk

Für openDesk als SaaS-Lösung arbeiten mehrere IT-Systeme und Komponenten zusammen, um die Bereitstellung des Dienstes zu gewährleisten.

Darunter fallen folgende IT-Systeme und Komponenten:

(AS01): Infrastruktur
Die Infrastruktur umfasst alle physischen und virtuellen Komponenten, die für den Betrieb von openDesk als SaaS-Lösung erforderlich sind. Dazu gehören Server, Netzwerke, virtuelle Maschinen, Speicherlösungen und Firewalls. Diese Komponenten bilden die Grundlage für die Bereitstellung und den sicheren Betrieb der gesamten Lösung.
(AS01.1): Kubernetes Cluster
Der Kubernetes-Cluster ist zentraler Bestandteil von openDesk, da er die Grundlage für den Betrieb der Plattform bildet. Er besteht aus einem Master Node, der die Verwaltung des Clusters übernimmt, und mehreren Worker Nodes, die die containerisierten Anwendungen ausführen. Diese Struktur ermöglicht eine effiziente Verwaltung, Skalierung und Automatisierung der Anwendungen, wodurch openDesk zuverlässig und flexibel betrieben werden kann.
(AS01.2): Backup- und Wiederherstellungssysteme
Diese Systeme sind integraler Bestandteil der Infrastruktur und umfassen sowohl hardware- als auch softwarebasierte Lösungen. Sie sorgen für die regelmäßige Sicherung kritischer Daten und Systeme und ermöglichen eine zügige Wiederherstellung durch inkrementelle oder vollständige Backups, um Ausfallzeiten zu minimieren.
(AS02) Anwendungen:
Die Anwendungen sind die zentralen Softwarelösungen, die das SaaS-Lösung openDesk den Endbenutzern spezifische Funktionen und Dienste bieten. Darunter fallen die einzelnen Module selbst, einschließlich des Codes und der Konfigurationen.
(AS03): Identity and Access Management
Authentifizierungs- und Autorisierungsmechanismen, wie Single Sign-On (SSO), Multi-Faktor-Authentifizierung (MFA) und rollenbasierte Zugriffskontrollen (RBAC), sind Teil der Infrastruktur. Ein zentraler Identity Provider (IdP) wird für die Benutzerverwaltung und -authentifizierung verwendet. Zusätzlich werden Privileged Access Management (PAM) und Privileged Access Workstations (PAW) eingesetzt, um privilegierte Konten zu überwachen und zu verwalten.

3.3 Erhebung der Informationsdaten von openDesk

Protokolle und Überwachungsdaten:

Protokolle und Überwachungsdaten, die im Rahmen des BSI-Grundschutzes genutzt werden, umfassen unter anderem System- und Anwendungsprotokolle, Sicherheitsereignisse, Benutzeraktivitäten und Netzwerkverkehr. Diese Daten dienen dazu, die Systemleistung zu überwachen und Sicherheitsvorfälle zu erkennen. Durch die systematische Erfassung und Analyse dieser Informationen können Schwachstellen identifiziert und die Sicherheit der IT-Infrastruktur verbessert werden.

(IO01) Protokollierungsdaten:
Protokollierungsdaten sind Informationen, die bei der Aufzeichnung von System- und Anwendungsaktivitäten entstehen. Sie dienen dazu, Abläufe nachzuvollziehen, Fehler zu analysieren und Sicherheitsvorfälle zu erkennen.
(IO02) Konfigurationsdaten:
Konfigurationsdaten beschreiben die Einstellungen und Parameter von IT-Systemen und Anwendungen. Sie sind notwendig, um die Funktionsfähigkeit und Sicherheit der Systeme sicherzustellen.
(IO03) Authentifizierungsdaten
Authentifizierungsdaten ermöglichen die Identifikation und Anmeldung von Benutzern oder Systemen. Dazu gehören beispielsweise Benutzerkennungen, Passwörter oder digitale Zertifikate.
(IO04) Nutzdaten:
Nutzdaten sind die eigentlichen Inhalte, die im Rahmen der Geschäftsprozesse verarbeitet werden. Sie umfassen Dokumente, Dateien und andere Informationen, die für die Aufgabenerfüllung erforderlich sind.

4. Schutzbedarfsfeststellung der Zielobjekte im Informationsverbund

Die für openDesk als SaaS-Lösung erforderliche Schutzbedarfsanalyse dient als Ermittlung des erforderlichen Schutzes für die Geschäftsprozesse, die verarbeiteten Informationen und die eingesetzte Informationstechnik. Basierend auf den Ergebnissen der Schutzbedarfsanalyse wird in den folgenden Kapiteln eine Bedrohungs- und Risikoanalyse durchgeführt. Es werden weder dedizierten Technologien, Konfigurationen (z.B. in Form einer Configuration Management Database (CMDB)) oder ähnliches abgebildet. Detaillierte Informationen sind den einzelnen Betriebsdokumentationen zu entnehmen.

DISCLAIMER:

Die Einordnung der IT-Systeme und Informationsdaten in die Kritikalitätsstufen werden im Folgenden für openDesk als SaaS-Lösung festgelegt. Bei einer Inbetriebnahme und Sicherheitsbetrachtung als On-Premise-Version können diese Einstufungen abweichen und müssen eigenständig separat bewertet werden.

4.1 Schutzbedarfsfeststellung

Im Folgenden werden die Schutzbedarfsfeststellungen aufgelistet. Eine Einordnung erfolgt anhand der in Kapitel 1.5 dargelegten Definitionen.

IT-System	Beschreibung	Vertraulichkeit	Integrität	Verfügbarkeit
(AS01)	Infrastruktur	hoch	hoch	sehr hoch
(AS01.1)	Kubernetes Cluster	hoch	normal	hoch
(AS01.2)	Backup- und Wiederherstellungssysteme	sehr hoch	hoch	hoch
(AS01.3)	Benutzerzugänge	sehr hoch	hoch	hoch
(AS02)	Anwendungen	hoch	hoch	sehr hoch
(AS03)	Identity and Access Management	hoch	hoch	sehr hoch

Informationsdaten	Beschreibung	Vertraulichkeit	Integrität	Verfügbarkeit
(IO01)	Protokollierungsdaten	hoch	hoch	sehr hoch
(IO02)	Konfigurationsdaten	sehr hoch	hoch	hoch
(IO03)	Authentifizierungsdaten	hoch	hoch	hoch
(IO04)	Nutzdaten	sehr hoch	hoch	hoch

5. Bedrohungsanalyse

Die Bedrohungsanalyse ist ein zentraler Bestandteil eines Sicherheitskonzepts. Dies dient zur Identifizierung von Sicherheitsrisiken und deren Mitigation. Dabei sind potenzielle Bedrohungen wie DDoS-Angriffe, SQL-Injection oder unsichere APIs zu analysieren. Die Bewertung dieser Bedrohungen hinsichtlich ihrer Wahrscheinlichkeit und Auswirkungen ermöglicht es für openDesk als SaaS-Lösung, gezielte Gegenmaßnahmen wie Multi-Faktor-Authentifizierung, Verschlüsselung und regelmäßige Penetrationstests zu entwickeln. Für die Bedrohungsanalyse werden Bedrohungen für das Einsatzszenario “die Bereitstellung von openDesk als SaaS-Lösung, die auf der STACKIT-Plattform bereitgestellt wird und über Kubernetes orchestriert wird” nach dem STRIDE-Modell beschrieben. Es bietet ein systematisches und umfassendes Modell zur Identifizierung und Klassifizierung von Sicherheitsbedrohungen, welche dabei hilft, potenzielle Schwachstellen frühzeitig zu erkennen und geeignete Gegenmaßnahmen zu entwickeln.

5.1 Einführung “Threat Model”

Das Threat Model (Bedrohungsmodell) ist ein systematischer Ansatz zur Identifikation, Bewertung, Priorisierung und der Implementierung von Gegenmaßnahmen. Es dient dazu, potenzielle Schwachstellen und Angriffsvektoren zu erkennen, die die Vertraulichkeit, Integrität und Verfügbarkeit (CIA) von openDesk gefährden könnten. Zum besseren Verständnis der Umgebung gilt folgendes Threat Model in Anlehnung an die STRIDE Methodik.

5.2 Schwachstellen

In diesem Kapitel werden die möglichen Schwachstellen des beschriebenen Informationsverbundes detailliert analysiert, basierend auf dem MITRE-Framework und der STRIDE-Methodik. Aus Gründen der Lesbarkeit und Nachvollziehbarkeit wurde auf ein Mapping verzichtet. Die Schwachstellen sind in organisatorische (OS) und technische (TS) Kategorien unterteilt und fortlaufend nummeriert, um eine umfassende und strukturierte Analyse sicherzustellen.

5.2.1 Organisatorische Schwachstellen

Folgende potenzielle organisatorische Schwachstellen sind zu betrachten:

(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung:
Unklare oder fehlende Definitionen der Projektanforderungen – insbesondere zu Sicherheits- und Gesetzesvorgaben – sowie die unzureichende Einbindung von Entwicklungs- und Administrationsteams wirken sich direkt auf die Stabilität und Sicherheit einer openDesk-Implementierung aus. Werden Anforderungen wie DSGVO-Konformität, Zugriffskontrollen oder Verschlüsselungsrichtlinien nicht präzise festgelegt, entstehen fehlerhafte Konfigurationen und Sicherheitslücken. Ebenso führt die fehlende Beteiligung der technischen Teams dazu, dass notwendige Sicherheitsmechanismen (z. B. für Authentifizierung, Rollenmanagement oder Backup-Prozesse) nicht rechtzeitig berücksichtigt werden. Die Konsequenz sind Verzögerungen bei der Umsetzung, erhöhter Aufwand für Nachbesserungen und ein deutlich gesteigertes Risiko für Sicherheitsvorfälle.

(OS02) Effektives Risikomanagement und Überprüfungsprozesse:
Fehlt ein strukturiertes Risikomanagement mit regelmäßigen Prüfungen, bleiben potenzielle Bedrohungen und Schwachstellen oft unentdeckt. Im Umfeld von openDesk betrifft dies die gesamte Plattform und ihre integrierten Dienste, die ohne klare Prozesse anfällig für Sicherheitslücken sind. Werden Risiken nicht frühzeitig erkannt, verzögern sich Sicherheitsupdates, was zu gravierenden Folgen führen kann: Angreifer nutzen offene Lücken aus, kritische Funktionen fallen aus oder die Stabilität der Plattform wird beeinträchtigt.

(OS03) Umfassende Schulung und Sensibilisierung des Personals:
Fehlen regelmäßige und umfassende Schulungen sowie Informationsveranstaltungen, sind Mitarbeitende oft nicht ausreichend über aktuelle Sicherheitsbedrohungen und geltende Richtlinien informiert. Unzureichende Sensibilisierung führt dazu, dass Sicherheitsvorgaben innerhalb der openDesk-Umgebung nicht korrekt umgesetzt werden. Dies kann dazu führen, dass Schutzmechanismen umgangen, sensible Daten offengelegt oder Schadsoftware eingeschleust wird.

(OS04) Unklare Rollen und Verantwortlichkeiten:
Unklare Definitionen von Rollen und Berechtigungen führen dazu, dass Zuständigkeiten nicht eindeutig geregelt sind. Dies verursacht Verwirrung und ineffiziente Abläufe im Betrieb der openDesk-Plattform. Fehlende Klarheit kann Sicherheitsmaßnahmen verzögern, die Nachvollziehbarkeit von Änderungen erschweren und das Risiko unautorisierter Zugriffe oder fehlerhafter Konfigurationen erhöhen. Auch die Zusammenarbeit zwischen Projektteams, Dienstleistern und internen Administratoren wird dadurch beeinträchtigt.

(OS05) Mangelhafte Durchsetzung der Rollendefinitionen:
Wenn Rollentrennung nicht konsequent umgesetzt wird, steigt die Gefahr einer übermäßigen Verteilung privilegierter Rechte. Dies macht die Plattform anfälliger für Fehlkonfigurationen und Missbrauch. Werden beispielsweise Administratorrechte ohne Einschränkungen vergeben, kann eine einzelne Person Zugriff auf sämtliche sicherheitskritischen Funktionen erhalten. Dadurch erhöht sich das Risiko unautorisierter Änderungen, Datenmanipulation oder vollständiger Systemkompromittierung.

(OS06) Need-to-know-Prinzip nicht angewendet:
Wird das Need-to-know-Prinzip nicht konsequent umgesetzt, erhalten Personen Zugriff auf Informationen, die für ihre Aufgaben nicht erforderlich sind. Dies erhöht die Wahrscheinlichkeit, dass vertrauliche Inhalte in unbefugte Hände gelangen. Solche Zugriffe können zu Sicherheitsverletzungen, rechtlichen Konsequenzen und einem erheblichen Vertrauensverlust führen. Besonders kritisch ist dies in Umgebungen, in denen sensible Daten wie interne Konfigurationsdetails oder geschützte Dokumente verarbeitet werden.

(OS07) Unzureichende Trennung von Zuständigkeiten:
Fehlt eine klare Abgrenzung der Zuständigkeiten, können Personen gleichzeitig Konfigurations-, Entwicklungs- und Kontrollaufgaben übernehmen. In einer modularen Plattform wie openDesk führt dies dazu, dass kritische Änderungen unbemerkt bleiben. Die fehlende Trennung begünstigt Manipulationen, erhöht die Wahrscheinlichkeit von Sicherheitsvorfällen und kann die Stabilität der gesamten Umgebung gefährden. Besonders problematisch ist dies bei Prozessen, die eine unabhängige Kontrolle erfordern, etwa bei Änderungen an sicherheitsrelevanten Einstellungen oder bei der Freigabe neuer Funktionen.

(OS08) Mangelndes Sicherheitsbewusstsein:
Fehlt das Sicherheitsbewusstsein bei Nutzern einer Plattform mit verteilten Zugriffsrechten, steigt die Gefahr eines unsicheren Umgangs mit sensiblen Informationen. Dazu gehören das Weitergeben von Zugangsdaten, das Öffnen manipulierter Dateien oder die unbedachte Weitergabe vertraulicher Inhalte. Solche Verhaltensweisen begünstigen Angriffe, Datenverlust und unbefugte Zugriffe, was die Integrität und Verfügbarkeit der gesamten Plattform gefährden kann. Besonders kritisch ist dies in Umgebungen, in denen mehrere Rollen und Berechtigungen verteilt sind und ein einzelner Fehler weitreichende Folgen haben kann.

(OS09) Provisionierung von Benutzern:
Fehlen klare Kontrollen und definierte Prozesse bei der Provisionierung von Benutzern, entstehen Risiken für die Sicherheit und Konsistenz der Plattform. Beispiele hierfür sind:

Vergabe von Nutzerberechtigungen mit unzureichenden oder übermäßigen Zugriffsrechten, was Fehlerpotenziale und Sicherheitsrisiken erhöht.
Inkonsistenzen und Sicherheitslücken durch zeitliche oder inhaltliche Verzögerungen bei der Synchronisation zwischen IT-Systemkomponenten.
Das Erstellen unabhängiger, asynchroner Kopien von Identitätsdaten, wodurch Verwaltung und Sicherung dieser Daten erschwert werden.
Die Möglichkeit, dass Anmeldeinformationen während des Bereitstellungsprozesses abgefangen werden können.

(OS10) De-Provisionierung von Benutzern:
Unzureichende Prozesse bei der De-Provisionierung führen dazu, dass Zugänge in einer Umgebung nicht zeitnah entfernt werden. Da openDesk eine Plattform mit verteilten Zugriffsrechten und mehreren integrierten Diensten ist, können ehemalige Nutzer oder Personen mit geänderter Rolle weiterhin Zugriff auf vertrauliche Informationen behalten. Dies erhöht die Gefahr von unbefugter Nutzung, Weitergabe sensibler Daten und möglichen rechtlichen Konsequenzen.

(OS11) Zugriffskontrollen:
Um sicherzustellen, dass nur autorisierte Benutzer und Systeme auf sensible Daten und Systeme zugreifen können, sind strenge Zugriffskontrollen im Informationsverbund erforderlich. Fehlende oder unzureichende Zugriffskontrollen können dazu führen, dass unautorisierte Benutzer oder Systeme Zugang zu sensiblen Daten und Systemen erhalten. Dies kann zu Datenverlust, Datenmissbrauch oder Sicherheitsverletzungen führen.

(OS12) Fehlende oder unzureichende Sicherheitsrichtlinien:
Fehlen verbindliche Sicherheitsrichtlinien oder wird deren Umsetzung nicht ausreichend kontrolliert, steigt die Gefahr, dass Schutzmaßnahmen umgangen werden. Dies begünstigt einen fahrlässigen oder sogar böswilligen Umgang mit sicherheitsrelevanten Informationen. Werden beispielsweise keine klaren Regeln zur Passwortsicherheit oder zur Nutzung von Mehr-Faktor-Authentifizierung festgelegt, erhöht sich das Risiko von Kontoübernahmen und Datenverlust erheblich. In einer Umgebung mit verteilten Rollen und mehreren Zugriffsebenen sind solche Vorgaben besonders wichtig, um die Integrität und Vertraulichkeit zu wahren.

(OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien:
Werden Sicherheitsrichtlinien nicht konsequent überwacht, besteht die Gefahr, dass definierte Maßnahmen nur teilweise oder gar nicht umgesetzt werden. Fehlen regelmäßige Überprüfungen und Audits, bleiben Sicherheitslücken oft unerkannt und können ausgenutzt werden. Dies führt nicht nur zu potenziellen finanziellen Schäden, sondern beeinträchtigt auch die Stabilität und Verfügbarkeit einer Plattform mit verteilten Rollen und mehreren Zugriffsebenen.

(OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen:
Protokolle bzw. Sicherheitsereignisse dokumentieren technische und fachliche Vorgänge auf IT-Systemen. Im Kontext von openDesk betrifft dies insbesondere die integrierten Komponenten wie Nextcloud, Collabora Online, Open-Xchange, Element und Keycloak, die sicherheitsrelevante Ereignisse erzeugen (z. B. Anmeldeversuche, Dateioperationen, Rollenänderungen, API-Zugriffe). Durch Auswertung dieser Ereignisse kann eine nicht sachgerechte Nutzung erkannt und mitigiert werden. Für eine angemessene Sicherheitsüberwachung sind geeignete Verfahren und Aufbewahrungsregelungen zu etablieren, die auch die zentralisierte Sammlung und Korrelation der Logs aus allen openDesk-Diensten berücksichtigen. Fehlen solche Verfahren und Regelungen, kann dies dazu führen, dass sicherheitsrelevante Vorfälle wie unautorisierte Zugriffe auf Nextcloud-Dateien, Manipulation von Benutzerrollen in Keycloak oder verdächtige Aktivitäten in Element-Chats nicht rechtzeitig erkannt und behandelt werden. Dies erhöht das Risiko von unentdeckten Sicherheitslücken und Missbrauch, was die Integrität und Vertraulichkeit der in openDesk verwalteten Daten gefährdet.

(OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets:
Eine präzise und vollständige Inventarisierung aller eingesetzten Assets ist für die Sicherheit der openDesk-Umgebung unverzichtbar. Dazu gehören nicht nur die Kernplattform, sondern auch sämtliche angebundenen Dienste wie Nextcloud, Collabora Online, Open-Xchange, Matrix/Element, OpenProject sowie die zugrunde liegende Infrastruktur (Container, Datenbanken, Reverse-Proxies). Fehlt diese Transparenz, entstehen gravierende Risiken: Schwachstellen in einzelnen Komponenten oder deren Abhängigkeiten – etwa ein veraltetes Nextcloud-Plugin oder eine fehlerhafte Keycloak-Konfiguration – bleiben unerkannt. Dadurch können notwendige Schutzmaßnahmen wie regelmäßige Patches, Härtung der Systeme oder Monitoring nicht gezielt umgesetzt werden. Hinzu kommt: Ohne eine lückenlose Übersicht gestaltet es sich schwierig, ungewöhnliche Aktivitäten oder Angriffe frühzeitig zu identifizieren. Angreifer nutzen solche Lücken gezielt aus, indem sie unregistrierte Dienste oder vergessene Instanzen kompromittieren. Eine unvollständige Asset-Dokumentation macht die gesamte openDesk-Installation zu einem attraktiven Angriffsziel.

(OS16) Fehlende oder unzureichende Klassifizierung der Assets:
Damit openDesk sicher betrieben werden kann, müssen alle eingesetzten Komponenten nach ihrem Schutzbedarf bewertet werden. Diese Bewertung betrifft nicht nur die Hauptdienste wie Nextcloud, Collabora Online und Keycloak, sondern auch unterstützende Systeme wie Container, Datenbanken und Schnittstellen. Wird diese Klassifizierung nicht durchgeführt oder bleibt sie ungenau, entstehen zwei gegensätzliche Probleme: Einerseits können weniger kritische Systeme übermäßig geschützt werden, was zu erhöhtem Aufwand und Kosten führt. Andererseits besteht die Gefahr, dass besonders sensible Bereiche – beispielsweise die Identitätsverwaltung in Keycloak oder die Dokumentenspeicherung in Nextcloud – nicht ausreichend abgesichert sind. Das Ergebnis ist eine Sicherheitsarchitektur, die weder effizient noch zuverlässig ist und dadurch die Vertraulichkeit und Integrität der openDesk-Daten gefährdet.

(OS17) Unklarer Besitz von Assets:
Wenn nicht klar geregelt ist, wem ein bestimmtes Asset gehört, entstehen Lücken in der Verantwortung. In einer openDesk-Installation betrifft das sowohl zentrale Dienste als auch unterstützende Infrastruktur. Kommt es zu einer Sicherheitslücke oder einem notwendigen Update, bleibt oft unklar, wer handeln muss. Ein fehlendes Patch für die Authentifizierungskomponente oder eine veraltete Kollaborationsanwendung kann dadurch länger unbehoben bleiben. Die Folge: Verzögerte Reaktionen erhöhen das Risiko von Angriffen und Systemausfällen. Eine eindeutige Zuweisung von Verantwortlichkeiten ist daher unverzichtbar, um Aktualität und Sicherheit sicherzustellen.

(OS18) Ungeeignetes Vorgehens-Modell für die Softwareentwicklung:
Die Wahl des falschen Entwicklungsmodells kann den gesamten Lebenszyklus einer openDesk-Implementierung negativ beeinflussen. Wird beispielsweise ein stark sequenzielles Modell genutzt, bleiben Anpassungen an neue Anforderungen oft aus, was zu Verzögerungen und erhöhtem Aufwand führt. Umgekehrt kann ein zu agiles Vorgehen bei komplexen Integrationen – etwa bei der Anbindung von Authentifizierung oder Kollaborationsdiensten – dazu führen, dass Sicherheitsaspekte nicht ausreichend berücksichtigt werden. Ein passendes Modell muss daher sowohl die Besonderheiten verteilter openDesk-Komponenten als auch die Anforderungen an Stabilität und Compliance einbeziehen, um Risiken wie Terminüberschreitungen oder Sicherheitslücken zu vermeiden.

(OS19) Unzureichendes Release und Deployment Management:
Fehlen klare Abläufe für die Bereitstellung neuer Versionen, entstehen erhebliche Risiken für den Betrieb von openDesk. Werden Updates ohne definierte Prüf- und Freigabeschritte ausgerollt, gelangen fehlerhafte oder unvollständig getestete Komponenten in die produktive Umgebung. Dies kann sich beispielsweise in einer fehlerhaften Authentifizierung nach einem Keycloak-Update oder in nicht funktionierenden Kollaborationsfunktionen nach einer Collabora-Aktualisierung äußern. Solche Probleme beeinträchtigen nicht nur die Verfügbarkeit, sondern können auch Sicherheitslücken öffnen. Ein strukturiertes Release- und Deployment-Management ist daher notwendig, um sicherzustellen, dass neue Versionen geprüft, dokumentiert und kontrolliert eingeführt werden.

(OS20) Unzureichendes Configuration und Change-Management:
Fehlt ein klar definiertes Verfahren für Konfigurations- und Änderungsmanagement, steigt das Risiko von Inkompatibilitäten und Betriebsstörungen. Werden Anpassungen ohne abgestimmte Planung umgesetzt, können kritische Komponenten der openDesk-Umgebung instabil werden oder ganz ausfallen. Auf Grund der Komplexität von openDesk ist ein mögliches Szenario: Ein Update für die Kollaborationsplattform wird eingespielt, ohne die Kompatibilität mit der eingesetzten Container-Orchestrierung oder dem zugrunde liegenden Betriebssystem zu prüfen. Solche Fehler führen nicht nur zu Unterbrechungen, sondern können auch Sicherheitsmechanismen außer Kraft setzen. Ein strukturiertes Change-Management ist daher unerlässlich, um sicherzustellen, dass Änderungen getestet, dokumentiert und koordiniert erfolgen.

(OS21) Mangelnder und ungetesteter Business Continuity und Disaster Recovery Plan:
Ein Ausfall oder schwerwiegender Vorfall kann den Betrieb von openDesk erheblich beeinträchtigen, wenn keine klaren Strategien für Business Continuity und Disaster Recovery existieren. Ohne definierte Abläufe zur Wiederherstellung bleiben Systeme nach einem Hardwaredefekt, einer Datenbankkorruption oder einem Sicherheitsvorfall oft über längere Zeit nicht verfügbar. Noch problematischer ist es, wenn vorhandene Pläne nie getestet wurden: In solchen Situationen verlaufen Wiederherstellungen unkoordiniert, was zu Datenverlusten und verlängerten Ausfallzeiten führt. Um diese Risiken zu minimieren, müssen Wiederanlaufprozesse regelmäßig überprüft und praktisch erprobt werden, damit openDesk-Dienste im Notfall schnell und zuverlässig wiederhergestellt werden können.

(OS22) Planung von Ressourcen:
Eine durchdachte Ressourcenplanung ist entscheidend, um die Stabilität und Leistungsfähigkeit einer openDesk-Umgebung sicherzustellen. Dabei geht es nicht nur um Rechenleistung und Speicher, sondern auch um Netzwerkbandbreite und die Kapazität der zugrunde liegenden Infrastruktur. Werden benötigte Ressourcen nicht rechtzeitig bereitgestellt oder skaliert, können Dienste wie Dateiablage, Kollaboration oder Authentifizierung spürbar langsamer reagieren oder ganz ausfallen. Solche Engpässe beeinträchtigen nicht nur die Verfügbarkeit, sondern auch die Nutzererfahrung und können im schlimmsten Fall Sicherheitsmechanismen unterbrechen. Regelmäßige Kapazitätsanalysen und eine vorausschauende Planung sind daher unverzichtbar, um openDesk zuverlässig und performant zu betreiben.

(OS23) Backup:
Eine umfassende Backup-Strategie ist entscheidend, um SaaS-Dienste wie openDesk vor Datenverlusten durch Cyberangriffe, Hardwaredefekte oder andere unvorhersehbare Ereignisse zu schützen. Wenn keine geeigneten Maßnahmen zur Sicherung und Wiederherstellung getroffen werden, ist die Integrität und Verfügbarkeit der Daten gefährdet – bis hin zum vollständigen Verlust. Fehlende oder ungetestete Backups führen dazu, dass Wiederherstellungen im Ernstfall scheitern. Das kann nicht nur zu langen Ausfallzeiten, sondern auch zu irreversiblen Datenverlusten führen.

(OS24) Auswahl und Management von Dienstleistern:
Die sorgfältige Auswahl und Verwaltung von Dienstleistern ist ein zentraler Faktor für die Sicherheit und Integrationsfähigkeit einer openDesk-Umgebung. Externe Anbieter übernehmen häufig kritische Aufgaben wie Hosting, Support oder die Bereitstellung von SaaS-Diensten. Werden Dienstleister ohne klare Sicherheitsanforderungen oder vertraglich geregelte Prozesse eingebunden, können Schwachstellen entstehen, die die Integrität und Verfügbarkeit der Plattform gefährden. Fehlende Abstimmung führt zudem zu Problemen bei Updates, Incident-Management oder Compliance-Prüfungen. Eine strukturierte Zusammenarbeit mit definierten Rollen, Sicherheitsstandards und regelmäßigen Audits ist daher notwendig, um die Hochverfügbarkeit und den Schutz sensibler Daten sicherzustellen.

(OS25) Multi-Sourcing-Strategie:
Eine durchdachte Multi-Sourcing-Strategie stellt sicher, dass mehrere Dienstleister für den Betrieb der openDesk-Plattform verfügbar sind. Fällt ein Anbieter aus – etwa ein Hosting-Partner oder ein Support-Dienstleister –, kann ein anderer übernehmen, ohne dass die Verfügbarkeit der SaaS-Dienste gefährdet wird. Diese Vorgehensweise reduziert die Abhängigkeit von einem einzelnen Anbieter und erhöht die Resilienz der gesamten Umgebung. Gleichzeitig ermöglicht sie eine flexible Anpassung an neue Anforderungen, ohne die Integrität und Sicherheit der Daten zu kompromittieren.

(OS26) Management von Drittanbieter-Ressourcen:
Die Nutzung von Drittanbieter-Ressourcen wie externem Code oder Open-Source-Bibliotheken ist für den Betrieb von openDesk grundlegend, birgt jedoch Risiken in der Lieferkette. Ohne ein wirksames Cybersecurity Supply Chain Risk Management (C-CSRM) können Schwachstellen in Abhängigkeiten unentdeckt bleiben und die Integrität sowie Verfügbarkeit der Plattform gefährden. Beispiele sind fehlerhafte Bibliotheken für Authentifizierung oder unsichere Module in Kollaborationsdiensten, die Angreifern Einfallstore bieten. Um diese Risiken zu minimieren, müssen alle Drittanbieter-Komponenten regelmäßig geprüft, dokumentiert und überwacht werden. Ergänzend sind Prozesse zur Bewertung neuer Abhängigkeiten und zur schnellen Reaktion auf Sicherheitsmeldungen erforderlich.

(OS27) Vertraulichkeitsvereinbarungen (NDA):
Ein fachgerechter Umgang mit dem Austausch und der Weitergabe von Informationen durch Dienstleister und Kooperationspartner ist die Grundlage für eine sichere Zusammenarbeit. Im Umfeld von openDesk betrifft dies insbesondere sensible Daten wie Konfigurationsinformationen, Zugangsdaten oder interne Dokumente, die im Rahmen von Support, Hosting oder Integrationsprojekten verarbeitet werden. Fehlen klare Vertraulichkeitsvereinbarungen, besteht die Gefahr, dass vertrauliche Inhalte ungeschützt weitergegeben oder unbefugt genutzt werden. Dies kann nicht nur die Integrität und Verfügbarkeit der Plattform gefährden, sondern auch rechtliche und vertragliche Verpflichtungen verletzen. Verbindliche NDAs und deren regelmäßige Überprüfung sind daher unerlässlich, um sicherzustellen, dass alle beteiligten Parteien den Schutz sensibler Informationen gewährleisten und Compliance-Anforderungen eingehalten werden.

(OS28) Kundenmanagement:
Eine gründliche Identifikation und Prüfung von Kunden bzw. Serviceabonnenten ist entscheidend, um die Sicherheit und Integrität der openDesk-Umgebung zu gewährleisten. Dies betrifft insbesondere SaaS-Betriebsmodelle, bei denen externe Organisationen Zugriff auf Plattformfunktionen erhalten. Fehlen klare Prozesse zur Verifizierung, können unberechtigte oder nicht ausreichend geprüfte Kunden Zugriff auf sensible Daten oder administrative Funktionen erhalten. Dies erhöht das Risiko von Datenmissbrauch, Manipulation oder unbefugten Änderungen an Konfigurationen.

5.2.2 Technische Schwachstellen

Folgende potenzielle technische Schwachstellen sind zu betrachten:

(TS01) Hypervisor-Schwachstellen:
Angriffe auf den Hypervisor sind besonders attraktiv, da der Hypervisor die physischen Ressourcen und die darauf laufenden virtuellen Maschinen (VMs) vollständig kontrolliert. Jede Schwachstelle in dieser Ebend es Cloud-Providers StackIT ist daher äußerst kritisch. Die Ausnutzung des Hypervisors bedeutet potenziell die Ausnutzung jeder VM, die auf ihm läuft:

Ein typisches Szenario, das durch die Ausnutzung einer Hypervisor-Schwachstelle ermöglicht wird, ist der sogenannte “Virtual Machine Escape” (Ausbruch aus einer virtuellen Maschine).
Ein weiteres Szenario ist “VM-Hopping” (der Wechsel von einer VM zu einer anderen VM), bei dem ein Angreifer zunächst eine VM mit einer Standardmethode hackt und dann, unter Ausnutzung einer Hypervisor-Schwachstelle, die Kontrolle über andere VMs übernimmt, die auf demselben Hypervisor laufen.

(TS02) Fehlende Netzwerkverschlüsselung:
Um die Vertraulichkeit und Integrität von Daten während der Übertragung zu gewährleisten, ist es entscheidend, dass alle Datenübertragungen innerhalb des Cloud-Providers StackIT, dem Kubernetes-Cluster und zwischen den containerisierten Anwendungen ordnungsgemäß verschlüsselt sind. Dies umfasst die Nutzung von sicheren Protokollen wie TLS, SSL und VPNs. Der Schutz von Daten während Übertragung ist besonders wichtig, da sie dann anfällig für Abhör- und Manipulationsangriffe sind. Bei unzureichender oder fehlender Netzwerkverschlüsselung bestehen folgende Gefährdungen:

MITM-Angriffe: Wenn Daten über Netzwerke ohne Verschlüsselung übertragen werden, können sie von Angreifern abgefangen und gelesen werden. Bei einem MITM-Angriff kann der Angreifer den Datenverkehr zwischen zwei Kommunikationspartnern abfangen und möglicherweise manipulieren.
Datenverlust und Datenmanipulation: Unverschlüsselte Datenübertragungen sind anfällig für Abhörangriffe, bei denen sensible Informationen wie Passwörter, Kreditkartendaten und persönliche Daten gestohlen werden können. Angreifer können auch die übertragenen Daten manipulieren, was zu Datenverlust und Sicherheitsverletzungen führen kann.
Datenschutzverletzungen: Fehlende Netzwerkverschlüsselung kann zu erheblichen Datenschutzverletzungen führen, da vertrauliche Informationen während der Übertragung kompromittiert werden können. Dies kann zu finanziellen Verlusten und Reputations-Schäden führen.

(TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers:
Um die Vertraulichkeit und Integrität von Daten während der Verarbeitung zu gewährleisten, ist es entscheidend, dass alle Daten im Arbeitsspeicher (RAM, Random Access Memory) und anderen temporären Speicherorten ordnungsgemäß geschützt sind. Dies betrifft vor allem den Cloud-Provider StackIT. Der Arbeitsspeicher ist ein kritischer Bereich, in dem Daten aktiv verarbeitet werden und er kann sensible Informationen wie Passwörter, Verschlüsselungsschlüssel und andere vertrauliche Daten enthalten. Genauso zu betrachten ist der Schutz der Prozessoren (CPU, Central Processing Unit). Sie sind die zentrale Verarbeitungseinheit ist und ebenfalls anfällig für Sicherheitslücken. Folgende Gefährdungen sind möglich:

Memory Dump (Auszug des Arbeitsspeichers): Angreifer können Techniken wie Memory-Dumping verwenden, um den Inhalt des Arbeitsspeichers auszulesen und sensible Informationen zu extrahieren. Dies kann durch physische Zugriffe oder durch Malware (Schadsoftware) geschehen, die den Arbeitsspeicher ausliest.
Datenverlust und Sicherheitsverletzungen: Ohne ausreichenden Schutz können sensible Daten im Arbeitsspeicher von Angreifern extrahiert werden. Dies führt zu Datenverlust und Sicherheitsverletzungen, da vertrauliche Informationen wie Passwörter und Verschlüsselungsschlüssel kompromittiert werden. Es wird gegen das Prinzip der Vertraulichkeit verstoßen.
CPU-Meltdown (Zusammenbruch der CPU): Meltdown ermöglicht den Zugriff auf sensible Daten im Speicher. Diese sind durch die CPU geschützt sein, jedoch werden Schwachstellen in der spekulativen Ausführung von Befehlen ausgeführt, um den Zugriff zu ermöglichen. Dadurch können vertrauliche Informationen wie Passwörter und Verschlüsselungsschlüssel extrahiert werden.

(TS04) Mangelhaftes & unsicheres Ressourcenmanagement:
Eine mangelhafte Trennung (Segregation), also eine nicht ausreichende Isolierung von Ressourcen und Anwendungen auf den verschiedenen Ebenen der SaaS-Lösung openDesk, erleichtert den unbefugten Zugriff auf Informationen sowie den Missbrauch von Ressourcen, wie beispielsweise Schwachstellen im Sicherheitsmodell des Hypervisors. Darüber hinaus können fehlerhafte Algorithmen und -prozeduren zum Ressourcenmanagement zu einer unerwarteten Ressourcenerschöpfung führen. Die Folge sind Systemausfälle und Dienstunterbrechungen. Schwachstellen ermöglicht es den Angreifern, die Ressourcenverteilung zu manipulieren, was zu ineffizienter Ressourcennutzung und potenziellen Sicherheitsvorfällen führt.

(TS05) Fehlende Ressourcenisolierung:
Infrastructure-as-a-Service (IaaS), hier die StackIT, Container-as-a-Service (CaaS), Platform-as-a-Service (PaaS), hier der bereitgestellte Kubernetes-Cluster der StackIT, und Software-as-a-Service (SaaS)- Lösungen, hier die gesamte openDesk-Umgebung, basieren häufig auf Architekturen und Umgebungen, bei denen physische Ressourcen von mehreren virtuellen Maschinen und damit mehreren Benutzern gemeinsam genutzt werden. Der Ressourcenverbrauch eines Benutzers kann sich auf den Ressourcenverbrauch eines anderen Benutzers auswirken.

Überbuchung von Ressourcen: Es ist möglich, dass Benutzer mehr Ressourcen verbrauchen als ihnen zugewiesen wurde. Dies kann die Leistung und Verfügbarkeit der Dienste für andere Benutzer beeinträchtigen. Beispielsweise kann ein Benutzer, der eine ressourcenintensive Anwendung ausführt, die CPU, den Speicher oder die Netzwerkbandbreite übermäßig beanspruchen, was zu einer Verlangsamung oder einem Ausfall der Dienste für andere Benutzer führt.
Mangelnde Isolation von Netzwerkressourcen: Durch fehlende Isolation von Netzwerkressourcen besteht die Möglichkeit, dass ein Angreifer den Netzwerkverkehr anderer Benutzer abhört oder manipuliert. Dies kann zu Datenverlusten, Sicherheitsverletzungen und einer Beeinträchtigung der Integrität und Vertraulichkeit der Daten führen.
Seitenkanalangriff (Side channel attack): Durch die Beobachtung von Ressourcenverbrauchsmustern können Angreifer Informationen über andere Benutzer oder deren Anwendungen gewinnen kann. Dies kann z.B. über Angriffe des Cache erfolgen, bei dem ein Angreifer durch die Analyse von Cache-Zugriffsmustern sensible Informationen wie kryptografische Schlüssel extrahieren kann.
Störender-Nachbar-Effekt (“Noisy Neighbor”-Effekt): Der “Noisy Neighbor-Effekt” tritt auf, wenn ein Benutzer durch übermäßigen Ressourcenverbrauch die Leistung und Verfügbarkeit der Dienste für andere Benutzer beeinträchtigt.
Sicherheitsverletzungen durch gemeinsame Nutzung von Ressourcen: Eine gemeinsame Nutzung physischer Ressourcen von mehreren Benutzern kann das Risiko beinhalten, dass ein Angreifer Schwachstellen in der Ressourcenverwaltung ausnutzt, um auf die Daten oder Anwendungen anderer Benutzer zuzugreifen. Ein Beispiel hierfür ist die Ausnutzung von Schwachstellen in der Virtualisierungsschicht.

(TS06) Unsichere Managementinterfaces:
Managementinterfaces sind Schnittstellen, die Administratoren und IT-Personal zur Verwaltung und Konfiguration von IT-Infrastrukturen verwenden. Diese Schnittstellen, u. a. innerhalb der genutzten Kubernetes-Cluster für openDesk und besonders zwischen den einzelnen Modulen, bieten umfangreiche APIs, mit denen der IT-Dienstleister proprietäre Management-, Bereitstellungs- und Reporting-Schnittstellen entwickelt, die den Benutzern zur Verfügung stehen. Schwachstellen im Sicherheitsmodell dieser Schnittstellen in der openDesk SaaS-Umgebung können zu unbefugtem Zugriff auf Benutzerinformationen führen. Beispielsweise können Angreifer durch Schwachstellen in den Managementschnittstellen die Konfigurationsdaten manipulieren, was zu einer Eskalation von Zugriffsrechten führt. Dies ermöglicht es Angreifern, auf höher privilegierte Ressourcen zuzugreifen und diese zu missbrauchen.

Die unsichere oder unzureichende Überwachung von Managementschnittstellen über das zentrale Logging & Monitoring begünstigt die Eskalation von Zugriffsrechten, die fahrlässige oder auch böswillige Manipulation von Konfigurationsdaten, sowie den fahrlässigen oder auch böswilligen Missbrauch von virtuellen oder physischen Ressourcen. Darüber hinaus kann es eine Schwachstelle auf dieser Ebene ebenfalls einem Angreifer ermöglichen, die Assets innerhalb der IT-Infrastruktur zu manipulieren. Dies kann zu Denial-of-Service-Angriffen führen, bei denen laufende virtuelle Maschinen heruntergefahren werden, zu Datenlecks, bei denen Daten kopiert und außerhalb der virtuellen Maschinen übertragen werden, zu Kompromittierungen von Daten, bei denen virtuelle Maschinen durch modifizierte Kopien ersetzt werden, oder zu direkten finanziellen Schäden, indem viele Kopien der virtuellen Maschinen gestartet werden.

Fehlende Kontrollen der IT-Infrastruktur und Cross-Side-Channel-Schwachstellen können ebenfalls erhebliche Risiken für die Sicherheit der Managementinterfaces mit sich bringen. Wenn die Überwachung und Protokollierung der Aktivitäten auf diesen Schnittstellen unzureichend sind, können Angreifer ihre Aktivitäten verschleiern und unentdeckt bleiben. Dies erschwert die rechtzeitige Erkennung und Abwehr von Angriffen. Das Fehlen von Tools zur Durchsetzung von Terms of Service (ToS, Nutzungsbedingungen) oder spezifischer Service Level Agreements (SLA, Dienstleistungs-Güte-Vereinbarung, d.h. ein Rahmenvertrag für wiederkehrende IT-Dienstleistungen) wie Quality of Service (QoS, Qualität und Güte eines Dienstes) oder Distributed Resource Scheduling (DRS, Ressourcenplanung in verteilten Systemen) kann dazu führen, dass ein Benutzer die IT-Infrastruktur übermäßig beansprucht. Dies kann sich negativ auf andere Benutzer auswirken, indem es zu unzureichender Leistung oder gar dem Ausfall des Dienstes oder der Infrastruktur führt.

(TS07) Unsichere Kommunikationskanäle:
Über Kommunikationskanäle erfolgt die Übertragung von Daten zwischen Systemen und Benutzern. Eine unzureichende kryptographische Sicherung von Kommunikationsendpunkten, -kanälen und -protokollen z. B. zwischen den Anwendungscontainer von openDesk sind Schwachstellen für Angreifern, die es ermöglicht Kommunikationssitzungen abzuhören und zu übernehmen. Unsichere Authentifizierungsmechanismen und die Verwendung selbst-signierter Zertifikate erhöhen das Risiko, dass Angreifer Kommunikationssitzungen übernehmen und sich als legitime Benutzer ausgeben können. Diese Angriffe werden durch unsichere Authentifizierungsmechanismen oder die Akzeptanz selbst-signierter Software-Zertifikate zusätzlich begünstigt.

(TS08) Unsichere Mandantenfähigkeit:
Wenn die Trennung der Daten und Ressourcen zwischen den Mandanten, z. B. dargestellt in den unterschiedlichen Tenants der StackIT oder den Namespaces im Kubernetes-Cluster, nicht strikt umgesetzt wird, haben Angreifer Zugriff auf die Daten anderer Mandanten. Zudem können unzureichend konfigurierte Mandanten-Umgebungen zu sogenannten “Noisy Neighbor”-Effekten (Störender-Nachbar-Effekt) führen, bei denen die Aktivitäten eines Mandanten die Leistung und Verfügbarkeit der gesamten Umgebung beeinträchtigen.

(TS09) Fernzugriff auf die Managementoberfläche:
Der Fernzugriff auf die Managementoberfläche auf die zentralen Dienste von openDesk und das Produkt selbst begünstigt das Ausnutzen von Schwachstellen in Endgeräten, z.B. im Kontext des Internets der Dinge (IoT, Internet of Things) und der IT-Infrastruktur (Einzelkunde oder IT-Anbieter). Solche Schwachstellen können durch schwache Authentifizierungsmechanismen oder unzureichende Verschlüsselung entstehen. Diese Schwachstellen betreffen die Möglichkeit, Daten während der Übertragung abzufangen und zu lesen, beispielsweise durch MITM-Angriffe. Weitere Risiken ergeben sich durch die Akzeptanz von selbstsignierten Zertifikaten.

(TS10) Unzureichende Sicherheit von Kubernetes-Umgebungen:
Eine unzureichende Sicherheit von Kubernetes-Umgebungen mittels mangelhafter Authentifizierung und Autorisierung in der Control Plane birgt Sicherheitsrisiken. Administrierende und toolgestützte Bereitstellungen benötigen administrative Zugänge. Obwohl Mechanismen zur Authentifizierung und Autorisierung, häufig vorhanden sind, sind sie nicht immer standardmäßig aktiviert. Unbefugte, die auf das Netzwerk oder die Nodes (Knoten) zugreifen, können über ungeschützte administrative Zugänge Befehle ausführen, die der Verfügbarkeit, Vertraulichkeit und Integrität der verarbeiteten Daten schaden können.

Ein weiteres Risiko ist der Vertraulichkeitsverlust von Zugangsdaten. Pods benötigen Zugangsdaten (Access Tokens) zur API von Kubernetes. Wenn ein Pod angegriffen wird, können diese Zugangsdaten in unbefugte Hände gelangen. Mit diesen Zugangsdaten können Angreifer authentifiziert mit der Control Plane interagieren und, sofern die Berechtigungen ausreichen, Veränderungen an der Orchestrierung vornehmen.

Ressourcenkonflikte führen dazu, dass einzelne Pods den Node oder die Orchestrierung überlasten können. Die Verfügbarkeit aller anderen Pods auf dem Node oder den Betrieb des Nodes selbst ist dadurch gefährdet.

Die Automatisierung per Continuous Integration / Continuous Deployment Pipelines (CI/CD-Pipelines, d.h. Automatisierungen zur kontinuierlichen Integrierung und kontinuierlichen Auslieferung von Software und Diensten) und die daraus folgende Notwendigkeit, den Werkzeugen privilegierte Zugangsberechtigungen zu erteilen, birgt das Risiko unautorisierter Änderungen am Kubernetes Cluster.

Durch unberechtigte Kommunikation zwischen Pods und Nodes im Cluster, sowie mit externen IT-Systemen, hat ein Angreifer die Möglichkeit, die Control Plane, andere Pods oder die Nodes zu kompromittieren. Pods im Cluster können unerwünscht von außen erreichbar sein, was Angriffe gegen Dienste ermöglicht, die eigentlich nur intern erreichbar sein sollten. Diese Gefährdung wird durch die geringere Aufmerksamkeit verschlimmert, die internen Diensten oft entgegengebracht wird. Eine Verwundbarkeit auf einem nur intern eingesetzten Dienst, der von außen erreichbar ist, gefährdet die gesamten Cluster erheblich.

(TS11) Unzureichende Container-Sicherheit:
Container werden vorrangig auf Basis von vorgefertigten Images erstellt, die selbst erstellt, aber auch aus dem Internet bezogen werden können. Die in den Images enthaltenen Anwendungen von openDesk kann verwundbar sein und die aus dem Image gestarteten Container können dadurch angreifbar werden. Zudem können Images absichtlich integrierte Schadsoftware enthalten. Sollte ein Angreifer in der Lage sein, im Container eigenen Code auszuführen, kann er die Isolation des Containers überwinden und auf andere Container, das Host-System oder die Infrastruktur zugreifen (Container-Ausbruch), sofern diese nicht richtig abgesichert sind. Dies kann zum Verlust der Vertraulichkeit, Integrität und Verfügbarkeit aller auf diesem Host ausgeführten Container sowie des Hosts selbst führen, falls der Angreifer dort erhöhte Privilegien erlangen kann.

(TS12) Unzureichende Datenbanksicherheit:
Die von openDesk benötigten Datenbankenprodukte PostgresSQL, MariaDB und Redis können durch Schadprogramme infiziert werden, die unautorisierten Zugriff ermöglichen, Daten durchsickern lassen oder entfernen und die Verfügbarkeit der Datenbankdienste beeinträchtigen. Überlastungen und Kapazitätsengpässe beeinträchtigen die Nutzung der Datenbank durch autorisierte Benutzer. Sicherheitsanfälligkeiten in der Datenbanksoftware können zu unautorisierten Rechteausweitungen, Datenverlust oder -verfälschung und Leistungsabbau führen. Ungültige Daten oder Befehle, Fehler in Administrationsprozessen oder Sabotage können die Integrität der Daten beeinträchtigen.

(TS13) Unzureichende Sicherheit von Applikationen:
Durch unsichere Programmierung der einzelnen Module von openDesk, veraltete Bibliotheken oder unzureichende Eingabevalidierung haben Angreifer die Chance, den unautorisierten Zugriff auf sensible Daten unter anderem in der Groupware (OX App Suite) und dem Identity- and Access-Management (IAM) (Nubus) zu erlangen, die Integrität der Applikation zu kompromittieren oder Denial-of-Service-Angriffe durchzuführen. Besonders kritisch sind Schwachstellen wie SQL-Injection, Cross-Site Scripting (XSS, webseitenübergreifendes Scripting) und unsichere Authentifizierungsmechanismen, die es Angreifern ermöglichen, sich als legitime Benutzer auszugeben.

(TS14) Fehlende Input-Validierung:
Angreifer können manipulierte Daten in openDesk, z. B. über das File Management (Nextcloud) eingeben, um dessen Funktionalität zu beeinträchtigen oder unbefugten Zugriff zu erlangen, wenn die Input-Validierung unzureichend ist. Typische Angriffe sind:

Buffer Overflow (Pufferüberlauf): Übermäßige Datenmengen führen zu Systemabstürzen und ermöglichen Schadcode-Ausführung.
Canonicalization Attack (Angriff durch Kanonisierung): Manipulation von Dateipfaden gewährt unbefugten Zugriff.
XSS: Bösartige Skripte werden in vertrauenswürdige Webseiten eingebettet.
SQL Injection: Eingabe von SQL-Code, um Datenbanken zu manipulieren oder auszulesen.

(TS15) Unzureichend gesicherter Einsatz von Entwicklungsumgebungen:
Durch eine unzureichend gesicherte Entwicklungsumgebung besteht die Gefahr der Softwaremanipulation der einzelnen Komponenten von openDesk, welches das gesamte Produkt openDesk betrifft. Ohne klare Zugriffsprotokolle werden Änderungen nicht nachvollzogen. Fehlende Versionsverwaltung erschwert die Nachverfolgung von Änderungen und die Wiederherstellung funktionierender Versionen. Unzureichender Schutz des Quellcodes kann zu Beschädigungen und Datenverlust innerhalb der zentralen Dienste zum Deployment von openDesk führen, was die Weiterentwicklung der Software behindern kann. Eine neue Version einer Anwendung, die nicht ausreichend getestet ist oder den Freigabeprozess nicht durchlaufen hat, kann durch unzureichendes Management von Berechtigungen der CI/CD-Umgebung dazu führen, dass diese anfälliger für Sicherheitsvorfällen ist. Außerdem können kompromittierten Builds unbemerkt produktiv gehen. Fehlende Versionskontrolle erschwert die Wiederherstellung sicherer Zustände. Weitergehende Folgen können Verzögerungen von Releases sein, erhöhte Kosten für Incident-Response und potenzieller Vertrauensverlust bei den Nutzern von openDesk.

(TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen):
Unsichere APIs dienen als Einfallstor für Angriffe dienen. Typische Sicherheitslücken sind:

Autorisierung und Authentifizierung:
Schwachstellen in der Autorisierung und Authentifizierung im Identity and Access Management (IAM) (Nubus) kann ohne die Berechtigungen der Verbindung zu anderen Schnittstellen ausreichend zu überprüfen, dass Angreifer unberechtigten Zugriff auf Daten erhalten. Zudem können Lücken in der Authentifizierungslogik ausgenutzt werden, indem Authentifizierungstokens missbraucht werden. Durch eine unzureichende Trennung zwischen administrativen und betrieblichen Funktionen führt dazu, dass Angreifer privilegierte administrative Rechte erlangen können.
Datenexposition und -verarbeitung:
Die Weitergabe von sensiblen Daten z. b. über die Groupware (OX App Suite) ohne vorherige Filterung an Kunden können das Risiko ungewollter Datenänderungen erhöhen.
Ressourcenmanagement und Ratenbegrenzung:
Kein Rate Limiting (Begrenzung von Anfragen) ermöglicht z.B. Brute-Force- und DoS-Angriffe (Denial of Service Angriffe), was die Verfügbarkeit von openDesk beeinträchtigt.
Fehlkonfiguration und Verwaltung:
Unsichere Standardeinstellungen, z.B. bei Cloud-Speichern oder HTTPS-Headern, können z. B. für einen unbefugten Zugriff ausgenutzt werden. Fehlende Betriebsdokumentation über das gesamte SaaS-Konstrukt bei openDesk führt zur versehentlichen Freigabe unsicherer APIs, was das Risiko von Sicherheitslücken erhöht.
Injektion und Angriffsvektoren:
APIs sind anfällig für SQL-Injection-Angriffe, bei denen Angreifer schädlichen Code einschleusen, um Daten, wie z. B. beim Videokonferenzen (Jitsi) zu manipulieren oder zu stehlen.
Überwachung und Protokollierung:
Mangelnde Protokollierung und Überwachung der Umgebung von openDesk als SaaS-Lösung ist als gesamtes Produkt möglicherweise betroffen. Das verzögert das Erkennen von Angriffen, was es Angreifern ermöglicht, länger unentdeckt zu bleiben und größeren Schaden anzurichten.

(TS17) Fehlende oder unzureichende Test- und Freigabeverfahren:
Fehlende oder unzureichende Test- und Freigabeverfahren bei Versionsänderungen, Updates und Patches jeder einzelnen Komponente von openDesk und deren zentralen Dienste führen zu Fehlfunktionen und externen Angriffen. Ohne gründliche Tests und eine kontrollierte Freigabe der einzelnen Komponenten, zentralen Dienste und openDesk an sich können Änderungen unbeabsichtigte Nebenwirkungen haben, die die Stabilität und Sicherheit des Informationsverbundes beeinträchtigen. Beispielsweise kann ein nicht ausreichend getestetes Update zu einem Systemabsturz oder einer Sicherheitslücke führen. Infolgedessen können schützenswerte Informationen offengelegt, manipuliert oder zerstört werden.

(TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses:
Eine fehlende oder unzureichende Qualitätssicherung während der Software-Entwicklung kann zu Verzögerungen oder sogar zum Scheitern des Produkts openDesk führen. Ohne gründliche Überprüfung der Sicherheit der entwickelten Software können Schwachstellen in der finalen Version verbleiben. Angriffe auf gespeicherte Dokumente oder Benutzerkonten

(TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA):
Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) fördern Risiken wie unbefugtem Zugriff, Datenverlust und anderen Sicherheitsvorfällen. IAA-Mechanismen sind wesentliche Sicherheitsprozesse zur Sicherstellung des Zugriffs von autorisierten Benutzern und Systemen auf dedizierte Daten und Ressourcen. Diese Mechanismen bei openDesk, sowohl in der Anwendung selber als auch im Betrieb, sind entscheidend, um die Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Ressourcen zu gewährleisten.

Schwache Passwörter, fehlende Multi-Faktor-Authentifizierung (MFA), unzureichende Passwort-Management-Richtlinien, unsichere Speicherung von Anmeldeinformationen, fehlende oder unzureichende Zugriffskontrollen sowie Schwachstellen in Authentifizierungsprotokollen sind typische Schwachstellen unsicherer IAA-Mechanismen. Ohne zusätzliche Authentifizierungsfaktoren wie SMS-Codes oder biometrische Daten und nur die Verwendung von Passwörtern, besonders die schwach sind und/oder wieder verwendet werden, erleichtert es Angreifern, Zugriff auf die Systeme zu erhalten. Unzureichende Passwort-Management-Richtlinien, wie das Fehlen von Richtlinien zur regelmäßigen Änderung von Passwörtern oder zur Vermeidung der Wiederverwendung von Passwörtern, erhöhen das Risiko. Angreifer greifen bei einem Datenleck auf Anmeldeinformationen zu, wenn die Speicherung von Passwörtern in Klartext oder die Verwendung unsicherer Hashing-Algorithmen erfolgt. Ohne Role-based Access Control (RBAC, rollenbasierte Zugriffskontrollen) oder regelmäßige Überprüfung der Zugriffsrechte haben Benutzer unbefugten Zugriff auf Informationen, Daten und Ressourcen. Die Verwendung unsicherer oder veralteter Authentifizierungsprotokolle beherbergen Risiko von Angriffen wie Replay-Angriffen (Angriff durch erneutes Einspielen bzw. Abspielen von zuvor aufgezeichneten Authentifizierungs- oder Autorisierungs-Daten) oder Man-in-the-Middle-Angriffen bzw. Machine-in-the-Middle-Angriffen (MITM, Angriff durch einen Mittelsmann in der Übertragungskette zwischen Kommunikationspartnern).

Die möglichen Folgen unsicherer IAA-Mechanismen sind vielfältig. Angreifer können sich Zugang zu sensiblen Daten in der Groupware (OX App Suite) oder Filemanagements (Nextcloud) und Ressourcen verschaffen, was zu Datenverlust, Datenmanipulation oder Datenlecks führen kann. Sie können ihre Zugriffsrechte im I erhöhen und auf höher privilegierte Ressourcen zugreifen, was zu schwerwiegenderen Sicherheitsvorfällen führen kann. Unsichere IAA-Mechanismen können es Angreifern ermöglichen, ihre Aktivitäten zu verschleiern und unentdeckt zu bleiben. Zudem können sie die Fähigkeit zur Überwachung und Erkennung von sicherheitsrelevanten Ereignissen beeinträchtigen, was die Reaktionszeit auf Sicherheitsvorfälle verlängert.

(TS20) Unsichere Biometrische Verfahren:
Unsichere biometrische Verfahren werden oft als primäre Authentifizierungsmethode verwendet. Wenn biometrische Systeme bei openDesk genutzt werden und diese nicht ausreichend gesichert sind, haben Angreifer die Change Systeme zu überlisten und unbefugten Zugriff zu erlangen. Beispielsweise können gefälschte Fingerabdrücke verwendet werden, um biometrische Systeme zu täuschen. Typische Sicherheitslücken und Risiken umfassen:

Gefälschte biometrische Merkmale: Angreifer können gefälschte Fingerabdrücke oder Gesichtsbilder verwenden, um Authentifizierungssysteme zu überlisten.
Deepfakes (d.h. täuschend echte, gründliche Fälschung): Durch den Einsatz von künstlicher Intelligenz können Personen durch eine technische Täuschung realitätsnah kopiert werden können.
Speicherung biometrischer Daten: Wenn biometrische Daten in der Cloud oder auf unsicheren Servern gespeichert werden, besteht die Gefahr, dass diese Daten im Rahmen eines Datenlecks offengelegt werden.
Missbrauch durch Dritte: Hinterlegte biometrische Merkmale anderer Personen auf einem Gerät können das Risiko erhöhen, dass Unbefugte das System überlisten.

(TS21) Automatisierte Überwachungstools:
Das Fehlen oder eine unzureichende Aggregation und Korrelation von Systemaktivitäten in einem zentralen Informationssicherheitsmonitor wird die rechtzeitige Entdeckung und Abwehr des Missbrauchs von Ressourcen oder externer Angriffe behindert. Ohne ein effektives Sicherheitssystem können sicherheitsrelevante Ereignisse unbemerkt bleiben, was die Reaktionszeit auf Sicherheitsvorfälle verlängert und die Wahrscheinlichkeit von Datenverlust und Systemkompromittierungen erhöht.

Darüber hinaus behindern unzureichende forensische Mittel und Fähigkeiten die Entdeckung und Abwehr externer Angriffe. Forensische Fähigkeiten sind entscheidend, um nach einem Sicherheitsvorfall Beweise zu sammeln und zu analysieren. Wenn die forensischen Mittel und Fähigkeiten unzureichend sind, haben es Angreifer leichter ihre Spuren zu verwischen und somit unentdeckt zu bleiben. Dies erschwert die Identifizierung der Angreifer und die Wiederherstellung der betroffenen Systeme und Daten. Schädliche Aktivitäten können getarnt werden oder Logdaten innerhalb von openDesk und ihrer einzelnen Module, besonders Identity and Access Management (IAM) (Nubus), manipuliert werden. Ohne zentrale Korrelation können koordinierte Angriffe wie APTs (Advanced Persistent Threats) lange unbemerkt aktiv sein. Mit Folgen für Datenverlust bis hin zum Reputationsverlust.

(TS22) Unzureichende Schwachstellen-Tests:
Mit unzureichende Schwachstellen-Tests können potenzielle Sicherheitslücken in der Konfiguration und Administration von der Cloud-Plattform hin zur SaaS-Anwendung möglicherweise nicht identifiziert und behandelt werden. Regelmäßige und umfassende Schwachstellen-Tests sind durchzuführen, bevor sie von Angreifern ausgenutzt werden können. Ohne diese Tests besteht ein erhöhtes Risiko, dass unsichere Netzwerkarchitekturen oder unzureichende Segmentierungen unentdeckt bleiben. Dies ermöglicht Angreifern unbefugten Zugriff auf Systeme und Daten zu erlangen. Auch besteht das Risiko, dass Angreifer sich lateral innerhalb des Netzwerks bewegen und auf weitere Ressourcen zugreifen können. Angreifer können unentdeckt bleiben und ihre Aktivitäten fortsetzen. Datenverlust u. a. innerhalb des Filemanagements (Nextcloud), finanziellen Schäden für den Betreiber und die Verantwortlichen für openDesk als SaaS-Lösung und Reputationsverlust im Ganzen sind die Folgen. Möglicherweise werden dadurch Compliance-Anforderungen nicht erfüllt werden, so dass zusätzlich mit rechtlichen Konsequenzen und Strafen gerechnet werden könnte.

(TS23) Fehlende Implementierung einer Web Application Firewall (WAF):
Eine WAF ist entscheidend, um Webanwendungen vor einer Vielzahl von Web-basierten Angriffen zu schützen, darunter SQL-Injection, Cross-Site Scripting (XSS, Webseitenübergreifendes Scripting) und andere Bedrohungen. Ohne eine angemessene WAF sind Webanwendungen anfällig für diese Angriffe, was zu Datenverlust, Datenmanipulation und unautorisiertem Zugriff auf sensible Informationen führen kann. Darunter u. a. sensible Nutzerinformationen im Identity and Access Management (IAM) (Nubus). SQL-Injection-Angriffe ermöglichen es Angreifern, schädlichen SQL-Code in eine Abfrage einzufügen, um auf die betriebenen Datenbanken (PostgresSQL, MariaDB und Redis) zuzugreifen oder diese zu manipulieren. XSS ermöglicht es Angreifern, schädlichen Code in Webseiten einzubetten, der dann von anderen Benutzern ausgeführt wird. Beide Angriffsarten können schwerwiegende Folgen haben, einschließlich des Verlusts vertraulicher Daten und der Kompromittierung von Benutzerkonten.

(TS24) Zertifikatslaufzeiten:
Wenn Zertifikate ablaufen oder veraltet sind, führt das zu Ausfallzeiten, da verschlüsselte Verbindungen nicht mehr als sicher erkannt werden. Zudem erhöht sich das Risiko von MITM-Angriffen und Schlüsseldiebstahl, da Angreifer veraltete oder kompromittierte Zertifikate ausnutzen können. Wesentliche zentrale Module, wie u.a. Identity and Access Management (IAM) (Nubus) oder Groupware (OX App Suite), sind nicht mehr erreichbar. Möglicherweise werden dadurch Compliance-Anforderungen & Sicherheitsstandards (z. B. ISO 27001, DSGVO) verstoßen.

(TS25) Fehlende Sicherung der Datenträger:
Um die Integrität und Vertraulichkeit von Daten im Ruhezustand zu gewährleisten, ist es entscheidend, dass alle gespeicherten Daten ordnungsgemäß gesichert und verschlüsselt sind. Dies umfasst die Verschlüsselung von Festplatten, Datenbanken und Backup-Medien usw. Besonders Datenträgern sind bei unzureichender Sicherung leicht zugänglich:

Unbefugter Zugriff: Ohne ausreichende Verschlüsselung können unbefugte Personen, die Zugang zu den Datenträgern erhalten, sensible Daten auslesen und manipulieren.
Datenverlust und Sicherheitsverletzungen: Sensible Informationen können kompromittiert werden, was zu finanziellen Verlusten und Reputationsschäden führen kann.

openDesk als SaaS viele personenbezogene Daten (E-Mails, Dokumente, Kalender, Chats) verarbeitet, könnten diese ohne Verschlüsselung vollständig kopiert und analysiert werden.

(TS26) Unzureichende Wartung:
Regelmäßige Wartungsmaßnahmen, wie das regelmäßige Einspielen von Sicherheitsupdates oder -patches, sind entscheidend, um Systeme und Anwendungen sicher und funktionsfähig zu halten. Wenn Sicherheitsupdates und -patches nicht zeitnah eingespielt werden, bleiben Schwachstellen in der Software unentdeckt und nicht behoben. Angreifer können bekannte Schwachstellen ausnutzen, um unbefugten Zugriff auf Kundendaten innerhalb der Groupware (OX App Suite) oder / und Administrationsfunktionen im Identity and Access Management (IAM) (Nubus) erlangen. Datenverlust, Manipulation oder Serviceunterbrechungen sind die Folgen.

6. Modellierung der Sicherheitsmaßnahmen (Plattform)

Dieses Kapitel beschreibt die Modellierung der Sicherheitsmaßnahmen für openDesk als SaaS-Lösung mit dem Fokus auf die Plattform. Dabei erfolgt die Identifikation geeigneter Sicherheitsanforderungen und die Umsetzung entsprechender Maßnahmen für den Informationsverbund durch die Auswahl passender Bausteine aus dem IT-Grundschutz-Kompendium, siehe hierzu die separate Datei “20251029_openDesk_Checklists_IT-Grundschutz”.

6.1. Organisatorische Sicherheitsmaßnahmen

In diesem Kapitel werden die organisatorischen Maßnahmen beschrieben, welches für openDesk als SaaS definiert, umgesetzt und gepflegt werden. Hinweis: Hier genannte Tools sind keine Empfehlungen, sondern stellen lediglich vergleichbare Produkte dar.

(OM01.01) Einhaltung Sicherheitskonzept:
Die Umsetzung und der Betrieb der openDesk als SaaS-Lösung entspricht vollständig dem definierten Sicherheitskonzept, welches auf Basis der Anforderungen durch den BSI IT-Grundschutz angefertigt wurde. Dies wird regelmäßig, aber mindestens jährlich, überprüft und der Prüfungsbericht wird zentral auf Open Code abgelegt.

(OM02.01) Integration in BCM/ITSCM:
openDesk als SaaS-Lösung ist in die Prozesse und Planungen des Business Continuity Management (BCM) und IT Service Continuity Management (ITSCM) integriert. Unter Berücksichtigung der verschiedenen Systeme, Dienste und Anwendungen, welche in der Umgebung eingesetzt werden. Es werden in der gesamten Umgebung Redundanzen und Cluster-Technologien benutzt. Des Weiteren besteht eine Unabhängigkeit hinsichtlich des Cloud Service Providers (CSP) und weiteren Technologie-Vendoren. So ist ein direkter Umzug der Umgebung auf einen anderen Hyperscaler jederzeit möglich, was dazu führt, dass die Umgebung zeitnah wiederhergestellt werden kann. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A5, APP.2.3.A10, APP.3.1.A8, APP.4.3.A19 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Open-Xchange, OpenProject, xWiki, Univention

(OM02.02) Prüfung Business Continuity Prozesse:
Mindestens einmal jährlich werden die Business-Continuity-Prozesse für die Plattformumgebung geprüft, die mehrere integrierte Dienste und verteilte Rollen umfasst. Ziel ist es sicherzustellen, dass bei Ausfällen oder Notfällen alle Komponenten zuverlässig wiederhergestellt werden können. Die Ergebnisse dieser Tests werden dokumentiert und ausgewertet, um Anpassungen vorzunehmen, die die Verfügbarkeit und Integrität der gesamten Plattform gewährleisten. Durch die Analyse lassen sich Schwachstellen erkennen und kontinuierliche Verbesserungen ableiten, sodass auch komplexe Abhängigkeiten zwischen Diensten berücksichtigt werden.

(OM03.01) Ressourcenplanung:
Die Ressourcen für openDesk als SaaS-Lösung sind ausreichend dimensioniert, passend ausgewählt und individuell anpassbar. Hierfür erfolgt in regelmäßigen Abständen, aber mindestens monatlich, eine Überprüfung der Ressourcen und der erwartete Ressourcenbedarf und -wachstum. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A11 ####### Betroffene Module:
Nextcloud

(OM03.02) Kapazitätsplanung:
Die Verfügbarkeit, Qualität und ausreichende Kapazität von openDesk als SaaS sind geplant, vorbereitet und gemessen, um die erforderliche Verfügbarkeit zu erbringen. Zudem werden regelmäßige Prognosen über den künftigen Kapazitätsbedarf erstellt, um das Risiko einer Systemüberlastung zu verringern. Hierzu ist ein entsprechendes, angemessenes und End-to-End Monitoring etabliert, welches über vordefinierte Tresholds verfügt.

(OM03.03) Asset Management:
Alle bereitgestellten Systeme und Dienste werden vollständig im Asset Management erfasst. Hierfür wird ein zentrales Tool verwendet. Die Vollständigkeit und Genauigkeit der Liste wird regelmäßig durch die Organisation und den Betrieb von openDesk, mindestens jedoch monatlich, überprüft. Notwendige Änderungen müssen direkt durchgeführt werden und intern kommuniziert werden.

Alle bereitgestellten Systeme und Dienste werden in einem Asset-Management-Tool festgehalten und dokumentiert. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.6.A8, APP.6.A9, OPS.1.1.1.A6, OPS.1.1.1.A8 ####### Betroffene Module:
xWiki, Cryptpad, Collabora, Nextcloud, Open-Xchange, OpenProject

(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten:
Die openDesk als SaaS verwendet und nutzt ausschließlich zertifizierte oder testierte Infrastrukturen und Plattformen, welche gemäß des BSI IT-Grundschutz, Cloud Computing Compliance Criteria Catalogue (C5) und weiteren gängigen oder äquivalenten Standards geprüft und/oder konform sind.

Die eingesetzten Umgebungen verfügen über gültige Zertifizierungen wie ISO 27001, C5 oder BSI Grundschutz und werden regelmäßig durch unabhängige Stellen auditiert. Prüfberichte und Zertifikate werden dokumentiert und sind für Compliance und Nachweiszwecke verfügbar. Dienste ohne gültige Zertifizierung werden nicht für den Betrieb von openDesk zugelassen.

(OM03.05) Open-Source:
openDesk setzt vollständig auf Open-Source Komponenten. Dies führt zu einer großen Transparenz über alle Bestandteile und die Architektur von openDesk. Da der Quellcode von Open-Source Software offen zugänglich ist, kann dieser durch jeden überprüft und auditiert werden. Dies sorgt dafür, dass Sicherheitsprobleme schneller erkannt, offen kommuniziert und Verbesserungen und Fehlerbehebungen schnell und transparent umgesetzt werden können. Durch den Einsatz offener Standards wird zudem ein Vendor Lock-In vermieden, da einzelne Komponenten der Lösung austauschbar sind, ggf. durch sogenannte “Drop-In-Replacements”, d.h. dass eine Softwarekomponente 1:1 durch eine andere ersetzt werden kann, da z.B. die API-Schnittstelle exakt identisch ist.

Alle eingesetzten Open Source Komponenten wie Nextcloud, Collabora, OpenProject oder CryptPad verfügen über öffentlich einsehbare Sicherheitsdokumentation, Roadmaps und Issue Tracker, wodurch Schwachstellen und Updates transparent nachvollzogen und geprüft werden können. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A6, APP.6.A1, APP.6.A2, APP.6.A3, APP.6.A4, APP.6.A5, APP.6.A6, APP.6.A7, SYS.1.8.A7 ####### Betroffene Module:
NextCloud, Wiki, Cryptpad, Collabora, OpenProject

(OM04.01) Bestimmung von Nutzungsbedingungen:
Nutzungsbedingungen für openDesk als SaaS sind definiert und den Benutzern frei zugänglich. Nur Benutzer, welche diese Bedingungen akzeptieren, erhalten einen Zugriff auf die Umgebung. Nur Benutzer, die den Nutzungsbedingungen explizit zugestimmt haben, werden im Identitäts und Zugriffssystem freigeschaltet, der Zustimmungsstatus wird dort revisionssicher protokolliert. Die Nutzungsbedingungen sind zentral hinterlegt, jederzeit abrufbar und werden bei Änderungen erneut zur Bestätigung vorgelegt.

(OM05.01) Ticketsystem:
Zur strukturierten Dokumentation, Priorisierung und zeitgerechten Bearbeitung von Vorfällen und Rückfragen in der openDesk-Plattform wird ein zentrales Ticketsystem eingesetzt. Dies ist besonders wichtig, da openDesk eine modulare Umgebung mit mehreren integrierten Diensten und verteilten Rollen darstellt. Alle Anfragen, Vorfälle und Änderungen werden im System mit Status, Verantwortlichem, Zeitstempel und Priorität erfasst. Dadurch lassen sich Eskalationen steuern und die Bearbeitung anhand definierter Service Levels überwachen. Die Auswertung von Reports aus dem Ticketsystem unterstützt die kontinuierliche Verbesserung der Servicequalität und die Optimierung von Prozessen. Zur Sicherstellung einheitlicher Standards werden Best Practices wie ITIL angewendet, um Reaktionszeiten zu optimieren und die Stabilität der openDesk-Plattform zu gewährleisten.

(OM06.01) Datensicherung:
Zur Sicherstellung der Datensicherung von der openDesk-Umgebung und dessen Dienste ist ein Prozess definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens monatlich, überprüft. Alle relevanten Daten werden regelmäßig gesichert und können im Falle eines Datenverlusts wiederhergestellt werden.

Um die Datenwiederherstellung sicherzustellen und Ausfallzeiten im Falle eines Datenverlusts zu minimieren, enthält das Dokument feste Vorgaben zu der Backup-Methode, den ausführenden Intervallen und festen Termine der Wiederherstellungstest.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.3.A9, CON.1.A2, CON.3.A1, CON.3.A9, CON.3.A12, CON.3.A5, CON.3.A6, CON.3.A2 ####### Betroffene Module:
Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki, Nubus

(OM06.02) Zuverlässigkeit von Backups durch regelmäßige Prüfung:
Die Zuverlässigkeit der Backups wird durch regelmäßige Prüfungen der Backup-Funktionalität, z. B. in einer gleichwertigen Testumgebung, sichergestellt. Die Prüfungen werden dokumentiert und analysiert. Im Nachgang werden mögliche Schwachstellen identifiziert und behoben.

Backup Wiederherstellungstests werden regelmäßig in einer Testumgebung durchgeführt, dabei wird geprüft, ob Daten vollständig, fehlerfrei und innerhalb der definierten Wiederherstellungszeit verfügbar sind. Die Ergebnisse werden dokumentiert und zur Identifikation und Behebung von Schwachstellen genutzt. Erkenntnisse fließen in die Optimierung der Backup Strategie ein.

(OM06.03) Sicherung von Produktionsdaten:
Die Sicherung von Produktionsdaten werden entsprechend den festgelegten Backup Prozessen durchgeführt. Eine Replizierung von gesicherten Produktionsdaten auf einen anderen Backup-Speicher ist nicht gestattet und Bedarf einer separaten Freigabe. Produktionsdaten dürfen nicht in nicht-produktiven Umgebungen verwendet oder eingespielt werden.

Produktionsdaten werden gemäß den definierten Backup Verfahren ausschließlich im dafür vorgesehenen Speichersystem gesichert und verbleiben innerhalb der zugelassenen Infrastruktur. Eine Nutzung dieser Daten in Test oder Entwicklungsumgebungen ist grundsätzlich untersagt und nur nach gesonderter Autorisierung zulässig. Jede Datenentnahme oder Kopie aus der produktiven Umgebung wird protokolliert und kontrolliert.

(OM06.04) Physisch getrennte Backup-Speichermedien:
Damit das Risiko zur gleichzeitigen Gefährdung von System- und Backup-Daten mitigiert werden kann, sind die Backup-Speichermedien vom CSP physisch getrennt von den zentralen Komponenten platziert. Die Backup-Speichermedien werden hierzu zudem an einem separaten Standort aufbewahrt. Zusätzlich schützt die Nutzung mehrerer physisch getrennter Backup-Standorte zur weiteren Risikominimierung.

Durch die physische Trennung der Backup Speicher verringert sich das Risiko, dass Daten durch einen einzelnen Vorfall gleichzeitig mit den Produktionssystemen verloren gehen, zum Beispiel bei Stromausfällen, Ransomware Befall, Brand oder technischer Störung. Zudem bleibt die Wiederherstellung der Umgebung auch dann möglich, wenn ein Standort vollständig ausfällt. Dadurch steigt insgesamt die Ausfallsicherheit und Verfügbarkeit der Dienste deutlich.

(OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen:
Backups und die zugehörige Umgebung sind durch umfassende Sicherheitsmaßnahmen wie Sicherung der Zugriffe durch Benutzer und einem adäquatem Rechte- und Rollenkonzept gesichert. Es ist eine Mandantenfähigkeit des Backup-Sicherungstools und des Backup-Speichers sichergestellt.

(OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups:
Die Sicherheit und Vertraulichkeit der Daten wird durch die Verschlüsselung sämtlicher Daten-Backups gewährleistet. Diese Maßnahme dient der Risikominderung und ist unabhängig von der physischen Sicherheit der Backups. Die Verschlüsselung erfolgt nach aktuellen Sicherheitsstandards des BSI und wird regelmäßig, mindestens jährlich, überprüft und aktualisiert.

Bei Backups aus Anwendungen wie Nextcloud oder Univention wird die Verschlüsselung automatisch angewendet, sodass sensible Dateien und Benutzerinformationen auch außerhalb des Systems geschützt bleiben.

####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.3.A13, APP.3.3.A12 ####### Betroffene Module:
NextCloud, Univention

(OM06.07) Absicherung der Wiederherstellbarkeit von Backups:
Backups werden in einem standardisierten Format gesichert, so dass die Daten zuverlässig wiederhergestellt werden können und keine Abhängigkeiten zu einem Datensicherungssoftware Vendoren besteht. Die Überprüfung der Backup-Daten erfolgt sowohl auf physischer als auch auf logischer Ebene. Die Sicherungen erfolgen nach festgelegten Verfahren, die regelmäßige Tests der Wiederherstellbarkeit beinhalten, um die Integrität und Funktionalität der Daten zu gewährleisten. Durchgeführte Tests werden dokumentiert und analysiert, um die Wiederherstellungsprozesse stetig zu verbessern.

Die Backups werden in einem herstellerunabhängigen Format gesichert, damit sie auch ohne die ursprüngliche Software wiederhergestellt werden können.

(OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne:
Für die Wiederherstellung von openDesk werden strikt definierten Wiederanlauf- und Notfallpläne befolgt. Diese beinhalten die Wiederherstellung von Backups, um die Anwendung auf den Zustand vor dem Vorfall zurückzusetzen und die Betriebsfähigkeit sowie die Datenintegrität zu gewährleisten. Die Wiederherstellungspläne sind definiert und dokumentiert, um im Ernstfall eine schnelle und effiziente Wiederherstellung zu ermöglichen. Die Pläne werden regelmäßig getestet und aktualisiert, sodass sie den aktuellen Anforderungen und Best Practices entsprechen.

Für das Modul Nubus ist definiert, welche Dienste priorisiert wiederhergestellt werden müssen, damit zentrale Funktionen von openDesk schnell wieder nutzbar sind.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A16, APP.4.3.A22, CON.3.A4, DER.2.3.A2 ####### Betroffene Module:
Nubus

(OM07.01) Rollen- und Berechtigungskonzept:
Gemäß dem Least-Privilege-Prinzip sind alle Rollen und deren Berechtigungen innerhalb der openDesk-Plattform auf die minimal erforderlichen Rechte beschränkt. Dies gilt sowohl für Benutzer als auch für Administratoren, um sicherzustellen, dass nur die Zugriffe gewährt werden, die für die jeweilige Aufgabe notwendig sind.

####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.5.A12, SYS.1.5.A2

(OM07.02) Dokumentation von Rollen und Verantwortlichkeiten:
Rollen und Verantwortlichkeiten von Dienstleistern, Mitarbeitenden und sonstigen Dritten, die Administratoren sind, werden in Bezug auf Informationsbestände und Sicherheit dokumentiert und an einer zentralen Stelle abgelegt.

(OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten:
Alle beteiligten Dienstleister, internen Mitarbeitenden und sonstigen Dritten, die administrative Aufgaben in der openDesk-Plattform übernehmen, müssen über ihre Rollen und Verantwortlichkeiten informiert und geschult sein. Dies umfasst insbesondere den sicheren Umgang mit Berechtigungen, die Einhaltung des Rollen- und Rechtekonzepts sowie die Umsetzung der definierten Sicherheitsrichtlinien. Die Unterweisung stellt sicher, dass Administratoren die Auswirkungen ihrer Handlungen in einer modularen Plattform mit verteilten Diensten verstehen. So wird eine geschützte Arbeitsumgebung gewährleistet und die Einhaltung bestehender Richtlinien, Verfahren sowie gesetzlicher und regulatorischer Compliance-Vorgaben unterstützt.

Alle Administratoren werden gezielt geschult und regelmäßig erinnert, welche Verantwortung sie im Umgang mit den openDesk Systemen haben, damit Sicherheitsvorgaben bewusst eingehalten werden.

(OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung:
Für die openDesk-Plattform als SaaS-Lösung sind verbindliche Richtlinien und Verfahren definiert, die den sicheren Benutzerzugriff gewährleisten. Ergänzend wurden unterstützende Geschäftsprozesse und technische Maßnahmen umgesetzt, um sicherzustellen, dass interne Benutzer, Dienstleister und Kunden eine angemessene Verwaltung von Identitäten, Berechtigungen und Zugriffen erhalten. Folgende Richtlinien, Verfahren, Prozesse und Maßnahmen stellen dies sicher:

Verfahren, Rollen und Verantwortlichkeiten für die Provisionierung und De-Provisionierung von Benutzerkonten und dessen Berechtigungen. Dies erfolgt nach dem Least-Privilege-Prinzip.
Segmentierung von Sitzungen und Daten in mandantenfähigen Architekturen durch Dritte (z.B. Dienstleister).
Identity Trust Verifikation sowie die Interoperabilität von Service-to-Service-Anwendungen (APIs) und Informationsverarbeitungssystemen, wie z.B. Single Sign-On (SSO) und Föderation.
Von der Erstellung bis zum Widerruf das Account Credential Lifecycle Management
Wiederverwendung von Zugangsdaten und/oder Identitätsspeichern oder die Minimierung derer.
Regeln für Authentifizierung, Autorisierung und Abrechnung (AAA) für den Zugriff auf Daten und Sitzungen, einschließlich u.a. Verschlüsselung und multi-Faktor-Authentifizierung
Berechtigungen und Unterstützungsfunktionen zur Kontrolle der Authentifizierungs-, Autorisierungs- und Abrechnungsregeln (AAA) durch Dienstleister für den Zugriff auf Daten und Sitzungen.
Erfüllung der anwendbaren gesetzlichen und regulatorischen Compliance-Vorgaben.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A1, APP.2.1.A3, APP.2.1.A6, APP.3.1.A1, APP.2.1.A11, APP.2.1.A17, APP.2.1.A19, APP.2.1.A20 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Open-Xchange, OpenProject, xWiki

(OM07.05) Segregation von Tätigkeiten:
In der openDesk-Plattform wird die Trennung von Aufgaben durch festgelegte Richtlinien und Verfahren für den Benutzerzugriff sichergestellt. Diese Vorgaben beinhalten organisatorische Prozesse und technische Maßnahmen, die Zugriffsrechte strikt nach der definierten Rollenverteilung begrenzen. So wird verhindert, dass eine Person gleichzeitig mehrere kritische Tätigkeiten ausführt, was Interessenkonflikte und damit verbundene Risiken wie Manipulationen oder Fehlkonfigurationen reduzieren hilft.

(OM07.06) Provisionierung von Benutzern:
Die Provisionierung von Benutzern sind durch standardisierte Prozesse definiert. Benutzerkonten werden bei Beginn des Arbeitsverhältnisses ordnungsgemäß erstellt und mit den entsprechenden Berechtigungen versehen. Ein Onboarding-Prozess für neue Benutzer ist für eine sicherheitstechnische einwandfreie Ausführung der geforderten Tätigkeiten etabliert.

Die Erstellung und Freischaltung der Benutzer erfolgt über einen festgelegten Onboarding Prozess, bei dem Identität, Rolle und erforderliche Rechte eindeutig geprüft und dokumentiert werden, bevor der Zugriff auf openDesk Komponenten wie Nextcloud oder OpenProject gewährt wird.

(OM07.07) De-Provisionierung von Benutzern:
Die De-Provisionierung von Benutzern ist durch standardisierte Prozesse definiert. Benutzerkonten sind bei Beendigung des Arbeitsverhältnisses oder bei einem Tätigkeits- bzw. Rollenwechsel umgehend und ordnungsgemäß deaktiviert und werden gemäß den Anforderungen auch entfernt.

(OM07.08) Kontenverwaltung:
Persönliche Konten innerhalb zum Betrieb und der Verwaltung von openDesk werden über einen zentralen Identity Provider verwaltet. Nicht personenbezogene Konten, wie z.B. “root”, werden mittels Privileged Access Management (PAM) auf persönliche Konten abgebildet.

(OM07.09) Benutzerdokumentation:
Es wird eine Dokumentation über autorisierte Benutzer zum Betrieb und Verwaltung der openDesk Umgebung und dessen Rechte geführt, welche regelmäßig, aber mindestens monatlich, überprüft wird.

(OM07.10) Benutzertrennung:
Zur effizienten Trennung von Benutzern zum Betrieb und Verwaltung der openDesk Umgebung ist ein Prozess definiert, dokumentiert, genehmigt und wird regelmäßig, aber mindestens monatlich, überprüft.

(OM08.01) Hintergrundüberprüfung:
Mitarbeitende, Dienstleister und weitere Dritte unterliegen einer Hintergrundüberprüfung durch die Verantwortlichen von openDesk. Diese entspricht den lokalen Gesetzen, Vorschriften, Ethikrichtlinien und vertraglichen Beschränkungen. Entsprechend der Überprüfung muss eine verhältnismäßige Einordnung zur erforderlichen Datenklassifikation, den Geschäftsanforderungen und dem akzeptablen Risiko erfolgen.

(OM08.02) Vergabe von Zugriffsrechten:
Zur Vergabe von Zugriffsrechten ist ein Prozess definiert, dokumentiert, genehmigt und wird regelmäßig, aber mindestens monatlich, überprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A3, APP.2.1.A17, APP.2.1.A19 ####### Betroffene Module:
Nubus

(OM08.03) Standardisierter Abstimmungsprozess von Zugriffsrechten:
Zur Abstimmung von Zugriffsrechten auf openDesk und seine Umgebung ist ein Standardabstimmungsprozess definiert, dokumentiert, genehmigt und wird regelmäßig, aber mindestens monatlich, überprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A3, APP.2.1.A17, APP.2.1.A19 ####### Betroffene Module:
Nubus

(OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen:
Die Zuweisung, Kommunikation und die Fortführung der bestehenden Dokumentation von Rollen und Verantwortlichkeiten bei der Beendigung oder Änderung von Arbeitsverhältnissen ist elementar und zu gewährleisten. Hierzu ist ein entsprechender Joiner - Mover - Leaver Prozess etabliert.

(OM09.02) Aktivitätenerfassung abstimmen:
Alle Maßnahmen und Prozesse zur Erfassung der Aktivitäten von Personen innerhalb der openDesk Umgebung erfolgen in Abstimmung gemäß der internen Unternehmensrichtlinien. Hierdurch kann nachvollzogen werden, welche Änderungen am System vorgenommen wurden. Die Aktivitätenerfassung erfolgt gemäß der Datenschutzbestimmung.

####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.2.A1 ####### Betroffene Module:
openDesk (Prozess-Bausteine)

(OM09.03) Speicherung und Löschung von Benutzerdaten:
Zur Speicherung und sicheren Löschung von Benutzerdaten ist ein Prozess definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens jährlich, überprüft.

(OM09.04) Speicherung und Zugriff auf Identitäten:
Richtlinien und Verfahren werden für die Regelung der Speicherung und des Zugriffs auf Benutzeridentitäten von openDesk definiert. Der Zugriff ist ausschließlich auf Benutzer zu beschränken, die ausdrücklich als geschäftlich erforderlich definiert sind. Methoden wie rollenbasierte Zugriffskontrolle (RBAC), dem Least-Privilege-Prinzip, regelmäßige Überprüfung der Zugriffsrechte und die Implementierung von Multi-Faktor-Authentifizierung (MFA) werden eingesetzt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A1, APP.2.1.A11, APP.2.1.A17, APP.2.1.A19 ####### Betroffene Module:
NextCloud, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki, Jitsi

(OM10.01) Passwortsicherheit:
Bei der Verwendung von Passwörtern für die openDesk Umgebung, werden nach den internen Sicherheitsrichtlinien erstellt und gesichert. Diese sind nach den geltenden Standards erstellt, z.B. BSI IT Grundschutz oder Center for Internet Security (CIS). Es dürfen keine Anmeldedaten oder Passwörter in Klartext gespeichert oder weitergegeben werden. Jeder Benutzer verwendet hierzu eine Passwort-Manager-Software (z.B. Keepass) zur Verwaltung aller Informationen ihrer Accounts.

(OM11.01) Outsourcing:
Outsourcing erfolgt durch einen definierten und überwachten Prozess durch die Verantwortlichen von openDesk. Hierbei wird sichergestellt, dass alle externen Dienstleister und ähnliche Parteien gemäß dem BSI den festgelegten Sicherheitsrichtlinien und -anforderungen entsprechen. Der Prozess wird für jeden externen Dienstleister und ähnliche Parteien dokumentiert und zentral abgelegt.

(OM11.02) Autorisierung von Dienstleistern:
Dienstleister und ähnlichen Partner müssen durch die Verantwortlichen von openDesk autorisiert sein. Erst danach erhalten diese, gemäß der Verhältnismäßigkeit, Zugriff zu benötigten Informationen.

(OM11.03) Einhaltungen von vertraglichen Vereinbarungen:
Drittanbieter sind von den Verantwortlichen von openDesk verpflichtet, die Einhaltung der in den Verträgen festgelegten Vereinbarungen zu Informationssicherheit, Vertraulichkeit, Service-Definitionen und Lieferstufen bei Bedarf nachzuweisen. Berichte, Aufzeichnungen und Dienstleistungen von Drittanbietern müssen regelmäßig, aber mindestens einmal jährlich, überprüft werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A6, APP.3.1.A9, APP.6.A14, CON.9.A2, CON.9.A9 ####### Betroffene Module:
NextCloud, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki, Jitsi

(OM11.04) Service Level Agreements mit Dienstleister:
Service Level Agreements (SLAs) sind mit jedem Dienstleister durch die Verantwortlichen von openDesk anhand unternehmensinterner Richtlinien unter Berücksichtigung bestehender Prozesse und Anforderungen zu definieren und auszuarbeiten. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.6.A14, CON.9.A1 ####### Betroffene Module:
Cryptpad, Nextcloud, Open-Xchange, OpenProject, xWiki

(OM11.05) Beendigung von Dienstleistungsverhältnissen:
Die Beendigung von Dienstleistungsverhältnissen durch die Verantwortlichen mit Kunden, Dienstleistern und ähnlichen Parteien sind durch einen standardisierten Prozess definiert, dokumentiert, genehmigt und werden regelmäßig, aber mindestens jährlich, überprüft. Umgebungen, Zugriffsrechte werden gemäß Vereinbarungen entzogen. Eine Übertragung der vertraulichen gespeicherten Daten sind abzustimmen oder vorher individuell zu sichern. ####### IT-Grundschutz-Baustein ID-Anforderungen:

(OM12.01) Staging Umgebung:
Die openDesk als SaaS-Lösung wird mindestens in Produktion und Nicht-Produktion getrennt (2-stufiges Staging). Dies erfordert mindestens zwei separate und autarke openDesk als SaaS Umgebungen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.3.A19 ####### Betroffene Module:
Nubus

(OM13.01) Änderungsdokumentation:
Dokumentationen von Änderungen von der openDesk Umgebung und dessen Komponenten sind definiert, dokumentiert, genehmigt und werden regelmäßig, mindestens monatlich, überprüft. Patches, Updates und Upgrades werden gemäß eines Staging Prozesses (mindestens zweistufig) getestet, überprüft und dokumentiert.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A12, APP.2.1.A5, OPS.1.1.3.A1 ####### Betroffene Module:
NextCloud, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

(OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung:
Dokumentationen, Handbücher und Richtlinien werden regelmäßig, aber mindestens jährlich, überprüft, um die kontinuierliche Sicherheit der openDesk als SaaS zu gewährleisten. ####### IT-Grundschutz-Baustein ID-Anforderungen:

(OM13.03) Schulung des Betriebs und der Administration:
Für den sicheren Betrieb und die Administration der Umgebung und der Systeme von openDesk erhalten alle Mitarbeitenden eine entsprechend auf die Aufgabe zugeschnittene Schulung. Die Schulung enthält alle relevanten Themen, die den sicheren Betrieb und die Administration der Umgebung gewährleisten. Dies muss u.a. eine Sicherheitsunterweisung umfassen, sowie der Umgang mit der Umgebung, seiner Systeme sowie die Technologie dahinter und aufzeigen der notwendigen Dokumentationen und Handbücher. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.3.A19, CON.8.A14, CON.9.A3, CON.9.A4, CON.9.A5, CON.9.A6, CON.9.A7, CON.9.A8, OPS.1.1.1.A16 ####### Betroffene Module:
NextCloud, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

(OM14.01) Kommunikation von Sicherheitsmaßnahmen:
Die Kommunikation von Sicherheitsmaßnahmen im Rahmen des Betriebs und der Verwaltung von openDesk ist regelmäßig und systematisch. Alle Mitarbeitende, Dienstleister und weitere Dritte werden über aktuelle Sicherheitsrichtlinien und -verfahren informiert. Dies umfasst Schulungen, regelmäßige Updates und die Bereitstellung von leicht zugänglichen Informationsressourcen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.3.A1, APP.6.A10, CON.10.A12, DER.2.1.A1, DER.1.A1 ####### Betroffene Module:
Nubus, xWiki, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject

(OM14.02) Schwachstellenmanagement:
Richtlinien und Verfahren für die Erkennung von Schwachstellen sind definiert, dokumentiert, genehmigt und werden regelmäßig, mindestens jährlich, überprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
DER.2.1.A1, OPS.1.1.1.A10, ISMS.1.A10, NET.3.4.A2 ####### Betroffene Module:
Collabora, Cryptpad, Element, Nubus, Openproject, OpenXchange, xWiki

(OM14.03) Erkennung von Schwachstellen:
Für eine frühzeitige Erkennung von Schwachstellen innerhalb von openDesk und seine zentralen Dienste sind technische Maßnahmen und unterstützende Prozesse mit dem Schwachstellenmanagement auszuarbeiten. Hierbei sind zudem false-positive Fälle zu berücksichtigen, da auch diese die Verfügbarkeit und Sicherheit der Umgebung und ihre Dienste verringert. ####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.1.1.A10, OPS.1.1.1.A20 ####### Betroffene Module:
Collabora, Cryptpad, Element, Nubus, Openproject, OpenXchange, xWiki

(OM14.04) Vorfallmanagement:
Nach der Identifizierung eines Sicherheitsvorfalls im Betrieb von openDesk müssen die zuständigen Mitarbeitenden die Ursache analysieren und betroffene System isolieren. Es sind passende Maßnahmen zur Behebung auszuwählen und diese gemäß den internen Richtlinien des Unternehmens zu genehmigen. Dabei ist es essenziell bereits während der Analyse einen Schwerpunkt zwischen Eindämmung des Schadens oder einer detaillierten Ursachenforschung und Untersuchung zu setzen. Ein standardisierter Prozess zur Nachbereitung ist definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens jährlich, überprüft. Dieser Prozess beinhaltet hierbei entsprechende Rollen und auch Kommunikationswege und -reihenfolgen. Das ist in folgendem System.

####### IT-Grundschutz-Baustein ID-Anforderungen:
DER.2.1.A18, DER.2.1.A17, DER.2.1.A5, DER.2.1.A10

(OM15.01) Bestimmung der Akzeptanzniveaus:
Jegliche Risiken sind auf ein vertretbares Niveau begrenzt. Die auf Risikokriterien basierenden Akzeptanzniveaus sind festgelegt und dokumentiert. Hierzu stimmen diese mit den angemessenen Lösungszeiträumen und der Zustimmung der Interessengruppen gemäß der Unternehmensrichtlinien überein. ####### IT-Grundschutz-Baustein ID-Anforderungen:

(OM15.02) Risikobewertungen:
Risikobewertungen im Zusammenhang mit den Anforderungen an die Datenverwaltung, u. A. dem File Management (Nubus) sind wie folgt durchzuführen:

Eine Sensibilisierung für den Speicherort von sensiblen Daten und ihren Übertragungsweg.
Die Komponenten, Datenbanken, Container und Kubernetes-Infrastrukturen.
Gewährleistung der Einhaltung von definierten Aufbewahrungsfristen und Entsorgungsvorschriften am Ende der Nutzungsdauer.
Klassifizierung von Daten und Schutzmaßnahmen gegen unbefugte Nutzung, unbefugten Zugriff, Datenverlust, Datenzerstörung und Datenverfälschung. Die Durchführung und/oder Prüfung der Risikobewertung hat mindestens einmal pro Jahr zu erfolgen.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A8, APP.4.3.A1, APP.4.3.A12, APP.4.3.A13, APP.4.3.A16, APP.4.3.A25 ####### Betroffene Module:
Nubus, NextCloud

(OM15.03) Informationen zu Sicherheitsproblemen:
Informationen zu Sicherheitsproblemen zur openDesk Umgebung werden im Rahmen der etablierten Prozesse entsprechend den Vorgaben, z.B. des BSI und ENISA, eingeholt und überprüft.

(OM15.04) Verstoß gegen Sicherheitsrichtlinien:
Eine formelle Disziplinar- oder Sanktionsrichtlinie für Mitarbeitende der openDesk Umgebung, die gegen Sicherheitsrichtlinien und -verfahren verstoßen, ist implementiert. Mitarbeitende werden im Vorfeld über die möglichen Konsequenzen eines Verstoßes informiert. Die Richtlinien legen die Disziplinarmaßnahmen eindeutig fest und werden den Mitarbeitenden bekannt gemacht, z.B. im OnBoarding Prozess.

(OM15.05) Alarmierung sicherheitsrelevanter Ereignisse:
Ein Prozess zur Alarmierung bei sicherheitsrelevanten Ereignissen in der Umgebung, sowie derer Dienste von openDesk ist definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens monatlich, überprüft. Im Falle eines sicherheitsrelevanten Ereignisses werden alle betroffenen internen Mitarbeitenden und externen Dritten sofort benachrichtigt. Es ist gemäß den internen Unternehmensrichtlinien zu prüfen, ob ähnliche Parteien wie Datenschutzbeauftragte, Rechtsabteilung usw. mit einzubeziehen sind. Ein Einhalten der Meldepflichten gegenüber Behörden und ähnlichen Parteien ist essenziell.

####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.2.A1, DER.2.1.A4 ####### Betroffene Module:
openDesk (Prozess-Bausteine)

(OM15.06) Statuskommunikation:
Alle Administratoren, Benutzende und weitere Drittparteien der openDesk Umgebung sind über Störungen, Notfälle, Krisen, geplante Updates und den allgemeinen Status der IaaS- und PaaS-Services regelmäßig zu informieren. Hierzu ist ein Kommunikationsplan inkl. der technischen Umsetzung definiert, dokumentiert und wird regelmäßig überprüft.

(OM15.07) Forensische Untersuchungen:
Forensische Verfahren, einschließlich der Beweismittelkette (Chain of Custody), müssen strikt bei dem Betrieb und der Verwaltung von openDesk eingehalten werden, um nach einem Vorfall Beweise zu sammeln, die den Anforderungen der jeweiligen Gerichtsbarkeit entsprechen. Betroffene Benutzer und externe Partner sollen die Möglichkeit erhalten, an diesen Untersuchungen teilzunehmen, soweit dies gesetzlich zulässig ist.

####### IT-Grundschutz-Baustein ID-Anforderungen:
DER.2.1.A7

(OM16.01) Log-Dateien Überprüfung:
Ein Prozess zur Prüfung aller Log-Dateien der openDesk Umgebung, sowie derer Dienste ist definiert, dokumentiert, genehmigt und wird regelmäßig automatisiert überprüft.

(OM16.02) Protokollierungsprozess:
Ein Prozess der Protokollierung und der Analyse der openDesk Umgebung, sowie derer Dienste ist definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens monatlich, überprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A12 ####### Betroffene Module:
Nubus

(OM16.03) Audit-Tools:
Zugriffe und die Nutzung von Audit-Tools für die openDesk Umgebung müssen segmentiert und eingeschränkt werden. Dies soll den Missbrauch von Protokolldaten vermeiden.

(OM16.04) Audit-Protokolle:
Audit-Protokolle im Rahmen des Betriebs und der Verwaltung von openDesk müssen unter höheren Sicherheitsstandards geschützt, aufbewahrt und verwaltet werden und haben die gesetzlichen und regulatorischen Compliance-Verpflichtungen einzuhalten. Die Audit-Protokolle haben einer dedizierten Verantwortung von Benutzern zu stehen. Außerdem müssen diese bei einer forensischen Untersuchung unterstützen. Deshalb sind u.a. Kennzahlen wie Performance, Kapazitätsplanung und False-Positive Analysen festzuhalten.

(OM16.05) Wirkungsanalyse Service-Ausfall:
Die Wirkungsanalyse muss für alle Komponenten, Dienste und weitere Services von openDesk durchgeführt werden. Dadurch sind frühzeitig Risiken erkennbar, um mögliche Wirkungen zu minieren und Reputationsschäden einzudämmen.

(OM17.01) Bereitstellung von Diensten:
Die Bereitstellung von Diensten in der Umgebung von openDesk sind für die Provisionierung und De-Provisionierung klar definiert, dokumentiert, genehmigt und werden regelmäßig, mindestens jährlich, überprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A6, APP.2.1.A8, APP.2.1.A9, APP.2.3.A1, APP.2.1.A14, APP.3.1.A8, APP.3.1.A9, APP.3.3.A3, APP.3.3.A15, APP.3.3.A6, APP.3.3.A7, APP.4.3.A12, APP.4.3.A4, APP.6.A12, APP.6.A14, APP.6.A2, APP.6.A3, APP.6.A4, APP.6.A5, APP.6.A6, APP.6.A7, APP.6.A8, APP.6.A13 ####### Betroffene Module:
Nubus, NextCloud, xWiki, Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject

(OM17.02) Änderung und Aktualisierung von Diensten:
Ein Prozess für die Änderung oder Aktualisierung aller Dienste von openDesk ist definiert, dokumentiert, genehmigt und wird regelmäßig überprüft. Eine Verwaltung der Umgebung und dessen Dienste durch Managementsysteme muss nach dem 4-Augen-Prinzip erfolgen.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A5, APP.2.3.A1, APP.2.3.A10, APP.2.1.A12, APP.2.1.A9, APP.4.3.A4 ####### Betroffene Module:
Nubus

(OM17.03) Dienstdokumentation:
Die Dokumentation der bereitgestellten Dienste in der Umgebung von openDesk ist gemäß den Anforderungen, die Automatisierungsplanung, die Eingabevalidierung, die Authentifizierung und Verschlüsselung, die Rollen und Rechte, die Überwachung und Protokollierung sowie die Sicherheitseinstellungen erstellt.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A1, APP.2.1.A6, APP.2.1.A8, APP.2.1.A13, APP.2.1.A14, APP.2.1.A18, APP.2.1.A19, APP.2.1.A2, APP.2.3.A1, APP.2.3.A3, APP.2.3.A4, APP.2.3.A5, APP.2.3.A6, APP.2.3.A8, APP.2.3.A9, APP.2.1.A9, APP.3.1.A4, APP.3.1.A8, APP.3.3.A7, APP.3.3.A14, APP.4.3.A24, APP.4.3.A4, APP.6.A12, APP.6.A14, APP.6.A2, APP.6.A3, APP.6.A4, APP.6.A5, APP.6.A6, APP.6.A7, APP.6.A8, APP.6.A9, APP.6.A13 ####### Betroffene Module:
Nubus, NextCloud, xWiki, Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject

(OM17.04) Portabilität von Diensten gewährleisten:
Ein Prozess für die Übertragbarkeit von Diensten und Daten der openDesk Umgebung in Gänze auf eine andere Umgebung ist definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens jährlich, überprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.3.A1, APP.2.1.A15 ####### Betroffene Module:
Nubus

(OM17.05) Migration von Anwendungen:
Migrationen von Anwendungen in openDesk müssen werden vorab einer Bewertung unterzogen. Migrationen müssen adäquat vorbereitet und geplant, besonders im Rahmen des Identity- and Access Management (IAM) (Nubus) werden. Geltende Sicherheitsmaßnahmen werden in die Migrationsstrategie integriert, um Daten und Systeme zu schützen. Relevante Stakeholder werden frühzeitig eingebunden, um die die Migration reibungslos zu gewährleisten. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A15, APP.4.3.A17 ####### Betroffene Module:
Nubus

(OM18.01) Image-Provenance (Container):
Ein Aspekt zum sicheren Betrieb von openDesk ist die Image-Provenance. Sie umfasst die Verwendung als auch die Verteilung sicherer Container-Images aus vertrauenswürdigen Quellen, wie es auch durch BSI IT-Grundschutz SYS.1.6.A6 und BSI IT-Grundschutz SYS.1.6.A12 gefordert ist. Konkret bedeutet dies, dass bei der Erstellung der Container und der Helm-Charts zur Bereitstellung von openDesk nicht blind öffentlichen Container-Images und Helm-Charts vertraut wurde, sondern dass diese entweder selbst erstellt worden sind oder ausführlich geprüft wurden, um sicherzustellen, dass nur das wirklich Notwendigste enthalten ist. Gerade mit Bezug auf die Verwendung von Containern, egal ob zur Nutzung als Basis-Container oder zur Umsetzung gewisser Fähigkeiten, sei darauf hingewiesen, dass auch minimale Container-Images aus nicht-vertrauenswürdigen Quellen stammen können und somit ein Sicherheitsrisiko darstellen.

Bei der Erstellung von openDesk wurden nur Container-Images und Softwarekomponenten aus als vertrauenswürdig klassifizierten Quellen verwendet oder eigenständig implementiert. Die Bereitstellung für den produktiven Betrieb geschieht im Rahmen von SaaS über eine Plattform-interne Container-Registry als vertrauenswürdige Quelle. Mit Blick auf die Implementierung selbst wurden anerkannte Standards zur Implementierung sicherer Software umgesetzt. Alle Schritte und Prozesse sind entsprechend dokumentiert.

Die Container-Images von openDesk sind mit entsprechenden Metadaten versehen, um die Funktion und die Historie des Container-Images bei Bedarf nachvollziehen zu können. Darüber hinaus gewährleisten digitale Signaturen, dass die Container-Images unverändert, die im Kubernetes-Cluster der Plattform zum Betrieb von openDesk als SaaS verwendet werden, unverändert sind und dem “Auslieferungszustand” von openDesk in der jeweiligen Version entsprechen. Nur Container, die eine valide Signatur aufweisen, werden zum Betrieb von openDesk als SaaS verwendet. Dadurch kann sichergestellt werden, dass zwischen Bereitstellung der Container und Nutzung der Container kein Angreifer schadhaften Code einschleusen kann.

Wie durch BSI IT-Grundschutz SYS.1.6.A13 gefordert, durchlaufen alle Container-Images und damit openDesk als Software für den produktiven Betrieb einen Test- und Freigabeprozess gemäß des Bausteins BSI IT-Grundschutz OPS.1.1.6. Nur Container, welche diesen Prozess erfolgreich durchlaufen haben, erhalten eine entsprechende Signatur, sodass diese als Nachweis für die durchgeführte Qualitätskontrolle dient. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.6.A6, SYS.1.6.A12, SYS.1.6.A13 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

(OM18.02) Regelmäßige Updates (Container):
Veraltete Software kann Sicherheitslücken enthalten, die es einem Angreifer ermöglichen, die Software zu kompromittieren, Daten zu stehlen oder zu manipulieren, oder im “besten” Fall lediglich die Verfügbarkeit der Anwendung zu stören. Daher ist die regelmäßige Aktualisierung der openDesk Umgebung unerlässlich. Für den Fall der Nutzung von openDesk als SaaS bedeutet dies ganz konkret, dass der Hersteller von openDesk regelmäßig, aber im Notfall auch außerordentliche Aktualisierungen von openDesk bereitstellt. Für den Betrieb in einer Container-Plattform bedeutet dies, dass aktualisierte Container der Komponenten von openDesk erzeugt und bereitgestellt werden. Hierbei werden zwei Ebene betrachtet, welche auf dem aktuellen Stand gehalten werden müssen: zum einen openDesk selbst, d.h. die Pakete und Abhängigkeiten, welche zur Erstellung der jeweiligen openDesk Komponente selbst notwendig sind, aber auch das Basis-Betriebssystems des Containers, d.h. das Basis-Image, auf welchem die openDesk Komponenten aufsetzten. Um hier den Überblick zu behalten, wird zu jedem Container mit jedem neuen Release eine sogenannte Software Bill of Materials (SBOM) erzeugt. BSI IT-Grundschutz SYS.1.6.A14 sieht hierzu ein Konzept für das Patch- und Änderungsmanagement gemäß BSI IT-Grundschutz OPS.1.1.3 vor, welches erstellt worden ist und welches genau beschreibt, wann und wie die Updates der Container-Images der Komponenten von openDesk ausgerollt werden. Aber auch die Container-Umgebung selbst muss regelmäßig überprüft und aktualisiert werden. Dies liegt jedoch in der Verantwortung des Hyperscalers der Container-Umgebung. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.6.A14 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

(OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container):
Gemäß der Redewendung “Vertrauen ist gut, Kontrolle ist besser” werden umfassende Überwachungs- und Auditierungssysteme auf Plattformebene durch den Hyperscaler genutzt, um die Komponenten von openDesk während des Betriebs hinsichtlich Verfügbarkeit und Performanz, aber auch mit Blick auf ungewöhnliche Aktivitäten, Engpässe und auch der Einhaltung der Richtlinien und der Härtungsmaßnahmen hinsichtlich Industriestandards zu überwachen. Die regelmäßige Prüfung auf Schadsoftware sowie bekannte Schwachstellen oder Hintertüren gehört selbstverständlich dazu. Alle Schritte wurden vollständig dokumentiert und auditierbar aufbereitet. Regelmäßige Sicherheitsscans und Schwachstellenprüfungen, sowohl auf Quellcode als auch auf Container-Ebene, werden vollständig automatisiert durchgeführt und die Ergebnisse überwacht, ausgewertet und die notwendigen Anpassungen abgeleitet und umgesetzt. Dies umfasst eine Überprüfung auf bekannte Schwachstellen, sogenannte CVE-Scans, also auch die Überprüfung des Quellcodes mittels statischer Code-Analyse sowie die dynamische Code-Analyse bis hin zu Penetrationstests von openDesk.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.1.A22, APP.4.3.A3, APP.4.3.A21, APP.4.3.A25 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(OM18.04) Sichere Entwicklung und sichere Deployments (Container):
Nicht nur während des Betriebs, sondern auch bei der Entwicklung der openDesk-Komponenten und der Erstellung der Container ist auf die Einhaltung der Richtlinien zur Härtung, der Überprüfung hinsichtlich Schwachstellen und der Absicherung der Software Supply Chain geachtet worden. Das bedeutet, dass unter anderem die openDesk Komponenten ohne erweiterte Rechte auskommen, dass sie nicht erst vor der Auslieferung, sondern regelmäßig auf Schwachstellen überprüft werden und dass die Abhängigkeiten zu anderen Paketen und Bibliotheken sorgfältig ausgewählt worden sind, um eine robuste Entwicklungsbasis zu schaffen. Aber auch die Manifeste und Helm Charts für das Deployment der openDesk Komponenten kann Schwachstellen enthalten. Meist handelt es sich hier um die unbeabsichtigte Preisgabe von sensitiven Informationen (z.B. hart-kodierte Zugangsdaten, statt wie durch BSI IT-Grundschutz SYS.1.6.A8 gefordert ein externes Schlüsselmanagement-System und/oder Kubernetes Secrets einzusetzen, um diese Informationen besonders geschützt und außerhalb des Container Images zu speichern und zu verwalten sowie nur berechtigten Personen Zugriff zu erlauben). Aber auch der Betrieb von openDesk an sich kann beeinträchtigt werden, wenn z.B. durch fehlende Healthchecks der Zustand der Container zur Laufzeit nicht überprüft werden kann und somit die regulierenden und korrigierenden Mechanismen von Kubernetes nicht zum Einsatz kommen (können), um die Aufrechterhaltung des Betriebs zu unterstützen.

Bei der Entwicklung und dem Betrieb einer Software wird nach höchsten Sicherheitsmaßnahmen gearbeitet und die eingesetzte Software auf das Wesentliche reduziert. Die Kompilierung der Software erfolgt entweder außerhalb des eigentlichen Erstellungsprozesses der Container oder die Container werden via Multi-Stage-Build erstellt, d.h. in einem oder mehreren Schritten werden in Containern die Artefakte, also die Komponenten von openDesk, kompiliert und dann als letzten Schritt in den finalen, minimalen Container kopiert. Dadurch sind nur die wirklich notwendigen Artefakte und keine zusätzliche und unnötige Software im finalen Container enthalten, sondern nur die eigentliche openDesk Komponente und der zur Laufzeit benötigte Abhängigkeiten.

Ohne angemessene Sicherheitsmaßnahmen können Schwachstellen im Quellcode selbst oder in der Konfiguration der Container ausgenutzt werden, die zu Datenverlust, Ausfallzeiten oder Sicherheitsverletzungen führen. Ungehärtete Container oder openDesk selbst stellen dann ein leichtes Angriffsziel dar. Damit Sicherheit nicht erst zuletzt während der Entwicklung betrachtet und “nachgerüstet” wird, sondern von Beginn an essenzieller Bestandteil der Entwicklung ist, werden in einem kontinuierlichen DevSecOps-Prozess alle Bestandteile von openDesk automatisiert gegen die Policies und Best-Practices geprüft und gehärtet, um potenzielle Angriffsvektoren zu minimieren. Folgende Maßnahmen sind im Rahmen von openDesk für eine zuverlässige und strukturierte Entwicklung inkl. Tests umgesetzt worden:

Die Basis-Images werden mindestens monatlich aktualisiert, sodass die aktuellen Sicherheitsupdates eingespielt werden.
Es wird auf die Verwendung des Tags latest verzichtet, sondern mit konkreten Tags, also Versionen der Container Images gearbeitet, da latest veränderlich ist und damit keine stabile Basis gewährleistet werden kann. Ein Image, was gestern erzeugt wurde und den Tag latest bekam, kann heute ein ganz anderes Image sein, aber trotzdem latest heißen. Dadurch ist im Nachhinein völlig unklar, was genau alles im Image mit dem Tag latest enthalten war und was nicht.
Überprüfung der Deployment-Manifeste, der Helm Charts und der Dockerfiles auf problematische Konfigurationen und, sofern die Prüfung fehlerhafte Konfigurationen zu Tage fördert, Abbruch des Erstellungsprozesses der openDesk Komponente. Eine fehlerhafte Konfiguration kann trotz fehlerfreien Quellcodes neue, bisher unbekannte Angriffsvektoren ermöglichen. Gemäß BSI IT-Grundschutz SYS.1.6.A8 beinhalten diese Überprüfungen, ob eventuell Zugangsdaten oder andere sensitiven und vertrauenswürdigen Informationen wie “Passwörter jeglicher Accounts, API-Keys für von der Anwendung genutzte Dienste, Schlüssel für symmetrische Verschlüsselungen sowie private Schlüssel bei Public-Key-Authentisierung” in den Container Images, dem Quellcode oder den Manifesten und Helm Charts enthalten sind.
Erstellung einer Software Bill of Material (SBOM) zur Sicherstellung der Supply Chain, zur Lizenzprüfung der verwendeten Abhängigkeiten und als Vorstufe zur Prüfung auf bekannte Schwachstellen (CVEs).
Durchführung der CVE-Prüfung und, sofern diese zu viele oder zu schwere Abhängigkeiten aufweist, Abbruch des Erstellungsprozesses der openDesk Komponente.
Durchführung der statischen Code-Analyse und, sofern diese Prüfung Auffälligkeiten oder Schwächen aufweist, Abbruch des Erstellungsprozesses der openDesk Komponente.
Durchführung der Härtungsmaßnahmen vor den fachlichen Test, damit diese nicht gegen eine nachträglich veränderte Basis und Konfiguration durchgeführt werden.
Durchführung der fachlichen Tests und sogenannter Unit-Test (keine QA-Tests) zur Überprüfung, ob sich die openDesk Komponente nach allen Härtungsmaßnahmen noch immer gemäß den Spezifikationen verhält.
Durchführung von Penetrationstests inkl. Dokumentierung der Ergebnisse
Sofern alle Überprüfungen erfolgreich bestanden werden, werden das entsprechende Container Image als auch die für das Deployment notwendigen Manifeste oder Helm Charts automatisiert signiert und in der vertrauenswürdigen Container Registry für die Produktivumgebung freigegeben.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.3.A3, APP.4.3.A3, APP.4.3.A19, APP.4.3.A20, APP.4.3.A21, CON.10.A11, CON.10.A12, SYS.1.6.A8 ####### Betroffene Module:
Nubus, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, Openproject, Cryptpad, xWiki

6.2. Technische Sicherheitsmaßnahmen

In diesem Kapitel werden die technischen Maßnahmen (TM) beschrieben, welche durch openDesk als SaaS-Lösung bereitgestellt und implementiert sind. Hinweis: Hier genannte Tools sind keine Empfehlungen, sondern stellen lediglich vergleichbare Produkte dar.

(TM01.01) Ressourcen Management:
Das Ressourcenmanagement zur Bereitstellung, Betrieb und der Verwaltung von openDesk erfolgt durch eine Kombination aus automatisierten und manuellen Prozessen. Hierzu werden Methoden wie die kontinuierliche Überwachung und Analyse der Ressourcennutzung genutzt, um Engpässe frühzeitig zu erkennen und zu beheben. Prinzipien wie die Least Privilege Policy werden angewendet, um sicherzustellen, dass nur autorisierte Benutzer Zugriff auf kritische Ressourcen haben. Zudem werden regelmäßige Audits durchgeführt, um die Einhaltung der Sicherheitsrichtlinien zu überprüfen und potenzielle Schwachstellen zu identifizieren. Die Nutzung von Cloud-basierten Lösungen ermöglicht eine flexible Skalierung der Ressourcen, um den aktuellen Anforderungen gerecht zu werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A11, APP.6.A10 ####### Betroffene Module:
xWiki, Cryptpad, Collabora, NextCloud, Open-Xchange, OpenProject

(TM01.02) Patch Management:
Der technische Prozess zur zeitnahen Installation von sicherheitsrelevanten Patches und Updates für alle Komponenten und Dienste von openDesk wird nach den internen Unternehmensrichtlinien unverzüglich eingeleitet. Dies umfasst infrastrukturell auch Firewalls, Netzwerkkomponenten, Serverbetriebssysteme und Plattform-Softwaremodule. Update-Freigaben müssen genehmigt werden und sind nur aus sicheren Quellen zu verwenden.

Die Umgebung und die zugehörigen Services werden gesamtheitlich in das bestehende Patch-Management integriert, sodass alle Komponenten regelmäßig aktualisiert und sicherheitsrelevante Patches zeitnah installiert werden.

Alle Softwarepakete und Containerdateien dürfen ausschließlich aus geprüften sicheren und vertrauenswürdigen Quellen installiert werden. Eine entsprechende Freigabe der Quelle wird dazu zentral dokumentiert und den beteiligten Personen bereitgestellt. Alle Installationen werden außerdem regelmäßig auf ihre Herkunft und Integrität überprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.3.A10, APP.3.1.A22, OPS.1.1.3.A13, OPS.1.1.3.A10, OPS.1.1.3.A15, OPS.1.1.3.A1 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM01.03) Quotas, Request & Limits (Kubernetes):
Quotas, Requests und Limits werden für alle Dienste und Workloads in den Kubernetes-Clustern festgelegt, besonders für das File Management (Nextcloud) von openDesk. Diese Maßnahmen setzen klare Grenzen für die Nutzung von CPU und Speicher. Es unterstützt die Cluster und deren Workloads effizient zu verwalten und bei Problemen neu zu starten. Quotas werden zudem für eine kontrollierte Ressourcennutzung pro Namespace festgelegt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A11, APP.4.4.A4 ####### Betroffene Module:
Nextcloud

(TM02.01) Charakteristiken der IaaS- und PaaS-Services:
Die Umgebung IaaS- und PaaS-Services, hier der StackIT, weisen folgende Charakteristiken auf:

Die Bereitstellung von Ressourcen wie Rechenleistung, Speicher und Netzwerken erfolgt automatisiert und mit minimaler Interaktion. Alle genutzten Systeme und Services können hierfür über eine API angesteuert werden. Zudem erfolgt die Verwendung von Self-Service-Portalen, um Abhängigkeiten zum CSP so gering wie möglich zu halten.
Services müssen über Standardschnittstellen wie HTTPS verfügbar sein und von verschiedenen Clients genutzt werden können.
Die Bereitstellung von Diensten und Anwendung hat hochgradig automatisiert zu erfolgen.

(TM03.01) Härtung:
Eingesetzten Betriebssysteme, Container und Plattformen sind mindestens nachdem internationalen Standard des CIS-Benchmarks Level 1 oder einem vergleichbaren Standard gehärtet. Dies gilt für alle Systeme, welche innerhalb von openDesk betrieben werden, als auch für Systeme, welche für die Bereitstellung von openDesk genutzt werden. u.a. betrifft dies Compute Nodes, Kubernetes Cluster, Third-Party Supporting Dienste, wie OpenCode, ArgoCD und HashiCorp Vault.

(TM03.02) Härtung (Kubernetes):
Die Control Plane Nodes zum Betrieb und Verwaltung von openDesk, die die Managementkomponenten des Clusters wie API-Server, Controller Manager, Scheduler und ETCD hosten, müssen mindestens gemäß den BSI-Standards gehärtet werden, optimalerweise nach internationalen Standards wie CIS. Dies umfasst die Implementierung dedizierter Nutzerzugriffe, wie beispielsweise ein dedizierter Nutzer für ETCD und ein root Benutzer für die verbleibenden Komponenten, um sicherzustellen, dass Änderungen am Cluster nur auf Knotenebene vorgenommen werden können.

Die Worker Nodes sind unerwünschten Konfigurationsänderungen zu schützen. Dies kann beispielsweise durch die Vergabe dedizierter Berechtigungen und die Änderung der Eigentümerschaft der jeweiligen Konfigurations- und Zertifikatsdateien erfolgen, sodass nur der root-Benutzer diese ändern kann.

Um die Kubelet-Komponente in Kubernetes zu härten, muss sie vor Man-in-the-Middle-Angriffen, kompromittierten oder veralteten Zertifikaten und Fehlkonfigurationen geschützt werden. Der betriebene Kubelet ist vor unbefugtem und anonymem Zugriff sowie unbefugten Änderungen über seine API geschützt. Kommunikationskanäle und Schnittstellen werden eingeschränkt, Zertifikatsabläufe verhindert und kryptografische Verschlüsselungen eingesetzt.

Die Kommunikation muss zu anderen Cluster-Komponenten mittels TLS-Verschlüsselung gesichert werden, um Man-in-the-Middle-Angriffe zu verhindern und eine abhörsichere Kommunikation zu gewährleisten. Anonymer, unautorisierter und unsicherer Zugriff muss deaktiviert werden. Role-Based Access Control (RBAC) muss aktiviert sein, um den Zugriff auf den Cluster zu beschränken und zu sichern.

Es müssen Kommunikationskanäle und Schnittstellen eingeschränkt sowie TLS-Verschlüsselung implementiert sein. Es muss eine Trennung der Service Benutzer auf Controller-Ebene implementiert und eine regelmäßige Zertifikatsrotation durchgeführt werden.

Der Scheduler muss sicherstellen, dass neu erstellte Workloads auf die zweckdienlichsten Nodes verteilt werden. Es müssen Kommunikationskanäle und Schnittstellen eingeschränkt werden, um unbefugten, anonymen und unkontrollierten Zugriff zu verhindern.

Es ist eine dediziert Zertifizierungsstelle (CA) für ETCD (verteilter Key-Value-Store) zu verwenden. TLS muss genutzt werden und die Nutzung von Zertifikaten, die von dieser CA ausgestellt wurden, erzwungen werden. Die gespeicherten Daten sind zu verschlüsseln.

CIS Kubernetes benchmark v1.23, OPS.1.1.1.A5, OWASP Kubernetes Top 10: K09:2022,SYS.1.3.A17 ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A13, APP.4.4.A17, APP.4.3.A21 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

(TM03.03) Common Vulnerabilities und Exposures (CVE):
Es werden regelmäßig alle Systeme und Services von openDesk auf bekannte CVE-Schwachstellen geprüft und gegebenenfalls werden geeignete Maßnahmen ergriffen, um diese Schwachstellen zu beseitigen. Darüber hinaus werden Kunden proaktiv über die gefundene Schwachstelle und deren Behebung informiert. Entsprechende Schwachstellen-Scanner sind in der CI/CD Pipeline integriert, z.B. über das Tool trivy, um eine automatisierte Überprüfung zu gewährleisten.

Sicherheitspatches für CVEs mit einem Score von 8 und größer werden direkt in die produktive Umgebung eingespielt, um das Risiko von Sicherheitsvorfällen zu minimieren. Sicherheitspatches für CVEs unter 8 werden zuerst in den entsprechenden Test-Stage eingespielt und dort gemäß des definierten Patch Management verprobt.

OWASP Kubernetes Top 10: K02:2022, OWASP Kubernetes Top 10: K10:2022 ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.1.A22 ####### Betroffene Module:
Nubus, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM04.01) Zentrales Logging und Monitoring:
Alle Systeme und Services von openDesk als SaaS-Umgebung sind an das zentrale Logging & Monitoring der Umgebung angebunden, um ein End-to-End Monitoring gewährleisten zu können. Sollte ein System oder Service nicht an das zentrale Logging & Monitoring angebunden sein, dann ist dieses umgehend aus dem Informationsverbund zu entfernen.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.3.A18 ####### Betroffene Module:
Nubus

(TM04.02) Auswertung der Ereignisprotokollierung:
Automatisierte Überwachungstools, wie z.B. ein Security Information and Event Management (SIEM) System, hier SysDig in der openDesk Umgebung, IDS und IPS-Komponenten, werden zur regelmäßigen Überprüfung der Logging und Monitoring-Dateien der Dienste und Systeme eingesetzt, um sicherheitsrelevante Ereignisse frühzeitig zu erkennen. Angepasste Kenngrößen werden entsprechend der Anforderung eingesetzt. Sicherheitsrelevante Ereignisse werden anonym protokolliert und überprüft. Die verantwortlichen Personen werden benachrichtigt, um potenzielle Bedrohungen frühzeitig zu erkennen und zu verhindern.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A12, APP.4.3.A18, APP.4.3.A21, SYS.1.5.A21, SYS.1.5.A17, OPS.1.1.7.A15, OPS.1.1.5.A9, OPS.1.1.5.A6, OPS.1.1.5.A13, OPS.1.1.4.A3, OPS.1.1.2.A29, OPS.1.1.1.A9, OPS.1.1.1.A21, OPS.1.1.4.A2, OPS.1.1.5.A3 ####### Betroffene Module:
Collabora, Cryptpad, Element, Nubus, Openproject, OpenXchange, xWiki

(TM04.03) Logging, Monitoring & Auditing (Kubernetes):
Alle Cluster, Cluster-Dienste und openDesk selbst werden an das zentrale Monitoring- und Logging-System angebunden. Das Audit Logging innerhalb von Kubernetes ist aktiviert. Außerdem müssen regelmäßige Audits von openDesk, des Clusters und der Cluster-Dienste durch Schwachstellen- und Policy-Scanner, wie z.B. Trivy, durchgeführt werden, um die Workload und den Cluster hinsichtlich der Einhaltung der Vorgaben durch den BSI IT-Grundschutz zu überwachen (u.a. Compliance mit CIS Kubernetes Benchmark) und transparent zu machen und im zentralen Monitoring und Logging zugänglich zu machen.

[OWASP Kubernetes Top 10: K05:2022, OWASP Kubernetes Top 10: K09:2022, CIS Kubernetes benchmark v1.23] ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.3.A21, APP.4.4.A13, APP.4.4.A17 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Collabora, Element, Open-Xchange, OpenProject, xWiki

(TM04.04) Löschung von Protokolldaten:
Es wird sichergestellt, dass Administratoren der openDesk Umgebung, die Protokollierungsfunktionen ausführen, nicht berechtigt sind, die aufgezeichneten Daten zu ändern oder zu löschen, um die Authentizität und Zuverlässigkeit der Protokollierung zu gewährleisten. Hierfür ist ein rollenbasiertes Zugriffskontrollkonzept implementiert, welches bei dem der Zugriff auf die aufgezeichneten Daten separat gesteuert werden kann.

####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.6.A1

(TM04.05) Ausführliche Protokollierung zur Sicherung der Archive:
Eine ausführliche Protokollierung der Zugriffe auf elektronische Archive innerhalb der openDesk Umgebung ist zu implementieren. Unter anderem sind mindestens Parameter wie Datum, Uhrzeit, Benutzer, Client, ausgeführte Aktionen und Fehlermeldungen zu erfassen.

####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.2.2.A8, OPS.1.1.5.A13, OPS.1.1.5.A8 ####### Betroffene Module:
Nubus, openDesk, Collabora, Element, Open-Xchange, OpenProject, xWiki

(TM04.06) Whitelisting:
Gemäß Whitelisting werden Infrastruktur, Services und Dienste von openDesk durch sogenannte Sicherheitsgruppen und klar definierte Sicherheitsrichtlinien geschützt. Das konfigurierte Whitelisting ist regelmäßig zu überprüfen und in den entsprechenden Betriebshandbüchern zu dokumentieren und zu aktualisieren.

(TM05.01) Mandanten-Trennung und Multi-Mandantenfähigkeit:
Verwendete und eingesetzte Systeme, Plattformen und Dienste von openDesk verfügen über eine Multi-Mandantenfähigkeit. Datenzugriffe, über das Identity- and Access Management (IAM) (Nubus) von openDesk geregelt, erfolgen nur durch die jeweilige Komponente, welche auch einen Zugriff auf diese benötigt.

Die technische Separierung von Kunden, welchen denselben Kubernetes Cluster nutzen, erfolgt über die Verwendung von Namespaces. Die Funktionalitäten des Namespaces stellen hierbei sicher, dass die Ressourcen jedes Kunden logisch isoliert und dass keine unbefugten Zugriffe zwischen den Kundenumgebungen erfolgen kann. Hierfür werden unter anderem StorageClasses mit namespace-spezifischen Attributen genutzt, um jede Anwendung und/oder jeden Dienst logisch voneinander zu trennen.

Falls eine Separierung der Kunden nicht über Namespaces erfolgen kann oder darf, wird hierfür ein separater Kubernetes Cluster bereitgestellt. Dies führt auch dazu, dass alle Third-Parties Dienste separat bereitgestellt werden, um Abhängigkeiten zwischen verschieden Kubernetes-Clustern zu vermeiden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A14 ####### Betroffene Module:
Nubus

(TM05.02) Authentifizierung & Autorisierung:
Sämtliche Services von openDesk verfügen über einen Autorisierungs- und Authentifizierungsmechanismus, wobei die Authentifizierung immer am zentralen Verzeichnisdienst erfolgt und die Autorisierung immer direkt im jeweiligen System. Hierzu verfügt jeder Dienst zusätzlich über gängige Authentifizierung- und Authentifizierungsfunktionalitäten, wie beispielsweise Multi-Faktor-Authentifizierung (MFA), Single Sign On (SSO) und die Nutzung von rollenbasierten Zugriffskontrollen (RBAC). Dadurch erfolgt die Umsetzung einer feingranularen Rechtestruktur. Zusätzlich ist der direkte Zugriff auf den Cluster auf die Administratoren und das Automatisierungs- und CI/CD-System beschränkt. Hierzu wird durchgehend das “Least-Privilege” Prinzip angewendet. Änderungen an den RBAC-Regeln dürfen nur durch den verantwortlichen Kubernetes-Betrieb vorgenommen werden.

Für den Zugriff auf die Kubernetes Cluster sind granulare Zugriffskontrollen implementiert, um den Zugriff basierend auf Benutzerrollen zu steuern. Die Umsetzung dieser erfolgt am definierten Rollen- und Rechtekonzept.

[OWASP Kubernetes Top 10: K03:2022, OWASP Kubernetes Top 10: K06:2022] ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A1, APP.2.1.A11, APP.2.3.A6, APP.4.4.A3, APP.4.4.A7, APP.4.4.A9, APP.4.4.A10, APP.4.4.A12, APP.4.4.A17, APP.5.4.A5 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM05.03) Benutzerauthentifizierung:
Die Umgebung, Dienste und Anwendungen von openDesk für den Zugriff müssen eine grundlegende Benutzerauthentifizierung (1-Faktor) implementiert haben, während privilegierte Benutzer eine 2-Faktoren-Authentifizierung (MFA) erfordern. Es sind nur Benutzer gemäß “Least-privilege principle” zu erstellen, die für den Betrieb und die Verwaltung erforderlich sind. Der Zugriff auf die Umgebungen muss ausschließlich über das SSH-Protokoll erfolgen, wobei personalisierte, passwortgeschützte SSH-Schlüssel für jeden Benutzer verwendet werden, um eine eindeutige Zuordnung und zusätzliche Sicherheit zu gewährleisten. Es ist zu empfehlen, dass der Zugriff auf eine PAW (Privileged Access Workstations) über ein Privileged Access Management (PAM) erfolgt. Die Benutzer sind zentral im Identitätsmanagementsystem zu verwalten.

Der Zugriff auf Protokolldateien soll dem “need to know”-Prinzip folgen und ein rollenbasiertes Zugriffskontrollkonzept (RBAC) implementiert werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.10.A16, OPS.1.1.2.A27, OPS.1.1.7.A26, OPS.1.2.5.A3, OPS.1.2.5.A25, NET.1.2.A21, SYS.1.3.A6, SYS.1.5.A12, SYS.1.5.A5, OPS.1.1.7.A26, OPS.1.2.5.A3, OPS.1.2.5.A25, NET.1.2.A21, SYS.1.3.A8 ####### Betroffene Module:
Collabora, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki, Nubus

(TM05.04) Protokollierung der Zugriffe:
Alle Zugriffs- und Änderungsaktivitäten innerhalb der openDesk Umgebung werden über die Audit-Logs protokolliert. Administrative Zugriffe auf kritische Systeme sind zudem visuell aufzuzeichnen und verschlüsselt zu sichern.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.3.A21

(TM05.05) User, Rollen und Rechte (Kubernetes):
Die definierten Rollen, Rechte und die User innerhalb von Kubernetes für den Betrieb und die Verwaltung von openDesk werden nur dediziert im Cluster verwendet. Zudem werden keine Berechtigungen auf Knotenebene erhalten oder sogar außerhalb des Clusters genutzt.

(TM05.06) Automations-User und personalisierte User (Kubernetes):
Plattform-Administratoren zum Betrieb von openDesk erhalten einen Service User zur Administration der Umgebung, welcher die Möglichkeit besitzt mit dem Cluster zu kommunizieren. Dieser User ist nicht für tägliche Operationen zu verwenden und bedarf immer einer 4-Augen Überprüfung oder Freigabe. Die Anmeldeinformationen ist auf ein Minimum an vertrauenswürdigen Administratoren zu beschränken.

Zur Nutzung von Tools zur Verwaltung des Quellcodes (OpenCode) sowie die Nutzung einer CI/CD-Pipeline (z.B. Tekton o.ä.) benötigt einen nicht-menschlichen Service User zur Automatisierung administrativ-ähnliche Zugriffsrechte gemäß Least-Privilege Prinzip auf die Cluster.

Menschliche Benutzer müssen sich mit personalisierten Anmeldeinformationen authentifizieren. Dies ermöglicht die Prüfung von Interaktionen mit Clustern oder Konfigurationsänderungen. Ein Zugriff durch anonymisiert User, nicht authentifizierter oder nachgeahmter Zugriff auf die Cluster ist strikt untersagt. Ein interner Identity Provider (z.B. Keycloak) muss verwendet werden, um menschliche Benutzer zu verwalten und ihnen individuelle, Cluster-interne Servicekonten zuzuweisen, die an spezifische Rollen gebunden sind. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A10 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM06.01) Verwendung von Benutzerdaten:
Alle Benutzerdaten werden anonymisiert oder pseudonymisiert, bevor diese in der nicht-produktiven Umgebungen von openDesk verwendet werden. Die Verwendung von Benutzerdaten im produktionsfreien Umfeld entspricht strikt den Anforderungen des Datenschutzes.

Es sind Sicherheitsmaßnahmen implementiert, wie die Verschlüsselung von Daten sowohl im Ruhezustand (Encryption at Rest) als auch während der Übertragung (Encryption in Transit), als auch die Implementierung dedizierter Zugriffe, damit Benutzerdaten ausreichend geschützt sind. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.1.A14, APP.3.3.A12, APP.4.3.A23, CON.2.A1 ####### Betroffene Module:
Nubus, NextCloud, openDesk (Prozess-Bausteine), Collabora, Element, Open-Xchange, OpenProject, xWiki

(TM06.02) Secret Verwaltung:
Für die Speicherung von Secrets, wie z.B. Zugangsdaten und Zertifikaten, wird der StackIT Secrets Manager, eingesetzt. Die Richtlinien und Verfahren für die kryptografische Schlüsselverwaltung entsprechend den zentralen Vorgaben des BSI und es werden ausschließlich kryptografische Methoden genutzt, welche als sicher gelten und gemäß den geltenden Standards zugelassen und empfohlen sind. Darunter fällt die “Technischen Richtlinien (TR) - Kryptografische Verfahren: Empfehlungen und Schlüssellängen” des BSI, welche auf den NIST Spezifikationen basiert. Diese Spezifikationen werden regelmäßig, mindestens jährlich, überprüft. Die eingesetzten kryptografischen Methoden und die damit verbundenen Prozesse sind in den Konzepten des verwendeten Systems zu dokumentieren.

Für die zentrale Verwaltung von autorisierten Benutzern mit Zugriff auf Anwendungen und Dienste muss einen Security Token Service Provider, z.B. Keycloak, verwendet werden.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.1.A1, APP.3.1.A14, APP.4.3.A16, CON.1.A1, CON.1.A10, CON.1.A15, CON.1.A19, CON.1.A2, CON.1.A4, CON.1.A5, CON.1.A9, CON.1.A20, OPS.1.1.7.A6, OPS.1.2.5.A8 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM06.03) Kubernetes Secret Management:
Secrets im Bereich Kubernetes werden als Dateien und nicht als Umgebungsvariablen konsumiert, soweit möglich. Zudem müssen Secrets für die Verwaltung und den Betrieb von openDesk vor dem Commit in das Versionskontrollsystem mit SOPS (Secrets OPerationS) verschlüsselt und die Verschlüsselung von ETCD aktiviert werden.

OWASP Kubernetes Top 10: K08:2022, CIS Kubernetes benchmark v1.23

(TM07.01) Hochverfügbarkeit:
Jegliche Systeme und Services, welche für die Bereitstellung und den Betrieb von openDesk als SaaS genutzt werden, werden hochverfügbar bereitgestellt. Dies erfolgt präferiert durch die Nutzung von Active-Active Funktionalitäten. Bei der Verwendung von Active-Passiv Funktionalitäten ist zu gewährleisten, dass eine minimale Ausfallzeit während des Failover Prozesses erfolgt. Zudem erfolgt jeder Failover Prozess automatisiert und Bedarf keiner manuellen Eingriffe. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A21 ####### Betroffene Module:
Nubus

(TM07.02) Kubernetes Resilienz:
Der Kubernetes Cluster, wie er durch den Hyperscaler als PaaS für openDesk bereitgestellt wird, wird hochverfügbar und redundant betrieben. Hierfür werden für jeden Kubernetes Cluster mindestens 3 Control und ETCD Nodes betrieben und mindestens 2 Worker Node pro Cluster. Jegliche Cluster-Dienste verwenden zudem geeignete Readiness- und Liveness-Probes, sodass die jeweiligen Dienste bei einem Ausfall automatisch neu starten. Diese Konfiguration stellt sicher, dass der Ausfall einer Maschine die Gesamtfunktionalität und Leistung des Clusters nicht beeinträchtigt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A13, APP.4.4.A11, APP.4.4.A14, APP.4.4.A19 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Jitsi, Open-Xchange, OpenProject, xWiki

(TM07.03) Replikation von Daten:
Jede StorageClass wird mit mindestens einem Replikationsfaktor von drei verwendet, welches für das File Management (Nextcloud) von openDesk entscheidend ist.Diese sind analog über mindestens drei verschiedene Nodes des jeweiligen Clusters zu verteilen. Durch Vorgaben von Aversionen (Anti-Affinity-Rule) wird verhindert, dass alle Replikate auf demselben Node gespeichert werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A13, APP.3.3.A14, SYS.1.8.A22 ####### Betroffene Module:
Nextcloud

(TM07.04) Cluster: Data-at-Rest Verschlüsselung (Kubernetes):
Die Verschlüsselung Data-at-Rest erfolgt auf mehreren Ebenen. Die Dateisysteme der zugrunde liegenden Knoten, die Cluster-Datenbank (ETCD) und dynamisch bereitgestellten Volumes durch Block-Storage-System für Kubernetes wie Longhorn usw., die den Pods der Dienste und Workloads zugeordnet sind, werden verschlüsselt. Dies erfolgt für openDesk Namespace übergreifend. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A12, APP.4.3.A21, APP.4.3.A24, APP.4.4.A20, SYS.1.8.A23 ####### Betroffene Module:
Nubus, NextCloud, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM08.01) Generelle Netzwerksicherheit:
Die Netzwerksicherheit und die Sicherheit bei der Datenübertragung werden durch umfassende Verschlüsselungsmaßnahmen für einen sicheren Betrieb von openDesk gewährleistet. Für die interne und externe Kommunikation kommen ausschließlich sichere und durch das BSI geprüfte Übertragungsprotokolle wie SSH und TLS (Transport Layer Security) ab Version 1.3 zum Einsatz. Dies stellt sicher, dass alle Informationen, insbesondere sensible Daten, verschlüsselt werden, um die Datensicherheit zu erhöhen und vor unbefugtem Zugriff und Abhörversuchen zu schützen.

Zusätzlich werden Backend-Systeme und Anwendungen durch verschlüsselte Verbindungen wie TLS und VPNs (Virtual Private Networks) gesichert. Anwendungen innerhalb der Plattform verfügen durchgehend über sichere Kommunikationsprotokolle wie SSL/TLS und sind nur über diese zugänglich. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A13, APP.3.1.A11, APP.3.3.A12 ####### Betroffene Module:
Nubus, NextCloud, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM08.02) Verschlüsselung des Kubernetes Netzwerks innerhalb der Cluster:
In jedem Kubernetes-Cluster der openDesk Umgebung wird ein Service-Mesh, z.B. umgesetzt durch Linkerd, Istio oder Consul, implementiert, um mutual TLS (mTLS) für alle Kommunikationen innerhalb der Cluster zu ermöglichen und abhörsichere Kommunikation zu gewährleisten. Hierzu ist jedes Service-Mesh mit dem internen Cluster-Dienst namens cert-manager verbunden, der als zentrale Stelle für die Konfiguration, Ausstellung und Widerruf von Zertifikaten fungiert. Der cert-manager arbeitet zusammen mit dem trust-manager, der zur Verwaltung von Zertifizierungsstellen in den Clustern verwendet wird, und automatisiert effektiv die administrative Interaktion in Bezug auf die allgemeine Zertifikatsverwaltung sowie die spezifische Handhabung von mTLS-Verbindungen, Ingress-Routen usw. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A13, APP.4.4.A12, OPS.1.1.5.A12 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM08.03) Netzwerk Segmentierung:
Die gesamte Umgebung verfügt über entsprechende Netzwerk Segmentierungen, sodass für verschiedene Aufgaben zum Betrieb von openDesk auch verschiedene Netzwerke genutzt werden. Eine stateful Firewall wird verwendet, um die gesamte Kommunikation zwischen diesen Segmenten zu kontrollieren, zu überwachen und freizugeben. Dies stellt sicher, dass nur autorisierter und notwendiger Datenverkehr zugelassen wird, was die Sicherheit und Integrität des gesamten Netzwerks erhöht.

Zusätzlich werden die Kubernetes Control Planes von openDesk mehrerer Cluster mit individuellen Managementnetzwerken verbunden. Der Zugriff auf die Dienste und Workloads erfolgt dafür über eigene, dedizierte Netzwerke. Hierfür werden spezifische Netzwerke für dediziert Aufgaben verwendet.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A7 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM08.04) Netzwerk: Dokumentation, Betrieb und Sicherstellung:
Die gesamte Umgebung von openDesk verfügt über eine umfassende Dokumentation für die gesamte Netzwerkumgebung. Diese Dokumentation enthält eine detaillierte Netzwerktopologie, Konfigurationen und Verbindungen innerhalb der Umgebung, um Klarheit über die Netzwerkstruktur zu gewährleisten und eine effiziente Verwaltung und Sicherheitsüberwachung zu ermöglichen. Zur Absicherung des öffentlichen Der Betrieb des gesamten Netzwerkes erfolgt vollständig automatisiert und zentralisiert. Jegliche Netzwerkkonfigurationen werden in dem zentralen Versionskontrollsystem hinterlegt. Internetverkehrs muss die Infrastruktur durch ein Application Layer Gateway (ALG) geschützt werden.

Für die openDesk als SaaS-Lösung wird Infrastructure as a Service (IaaS) des Hyperscalers genutzt. Dieser Dienst des Hyperscalers unterliegt den Sicherheitsanforderungen der openDesk als SaaS-Lösung und wird regelmäßig, mindestens jährlich, hinsichtlich der Einhaltung der Vorgaben geprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A11 ####### Betroffene Module:
Nubus

(TM08.05) Dienst- und Anwendungstrennung:
Für die Dienste- und Anwendungstrennung innerhalb der Kubernetes-Cluster von openDesk, sowie für die Mikrosegmentierung, werden Network Policies konfiguriert, sodass eine strikte Trennung der Netzwerke zwischen den Namespaces eingehalten wird. Diese Policies enthalten eine “deny all”-Regel, welche jegliche externe und inter-namespace Kommunikation verbietet und dadurch eine Isolation der Workloads und Dienste bis auf Pod-Ebene erfolgt. Nur die unbedingt erforderlichen Kommunikationswege dürfen mittels einer “Allow List” zugelassen werden (White Listing). Jegliche Änderungen an den Network Policies dürfen ausschließlich von den dedizierten verantwortlichen Administratoren des Betriebs von openDesk vorgenommen werden.

[OWASP Kubernetes Top 10: K07:2022] ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A1, APP.4.4.A18 ####### Betroffene Module:
openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM09.01) Tests von Backup und Wiederherstellung:
Für einen sicheren Betrieb von openDesk werden regelmäßige, mindestens jährliche, Tests von Backup und Wiederherstellungsprozessen durchgeführt, dokumentiert und auf Angemessenheit geprüft. Dies geschieht sowohl für einzelne Dienste von openDesk als auch für die gesamte Umgebung. Diese Prüfung wird hierfür in einer zur Produktionsumgebung äquivalenten Umgebung geprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.3.A2

(TM09.02) Verschlüsselung Backup:
Alle Backups von openDesk, seinen zentral genutzen Diensten und seine Module werden verschlüsselt auf den Backup System abgelegt, wobei das entsprechende Verschlüsselungsprotokoll mindestens dem aktuellen BSI-Standard entspricht. Dies wird regelmäßig, mindestens jährlich, geprüft.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.3.A12 ####### Betroffene Module:
NextCloud

(TM09.03) Kubernetes Backup:
Backups der persistenten Volumes von openDesk, welche auch u.a. von Element oder Jitsi benötigt werden, werden regelmäßig und automatisiert auf einer S3-kompatible Speicherlösung gesichert. Die Konfigurationsoptionen der Kubernetes-Cluster und der installierten Addons werden im internen Versionskontrollsystem gespeichert und durch dieses gesichert. Zusätzlich werden ETCD-Snapshots regelmäßig gesichert und wiederhergestellt. Die Backup- und Wiederherstellungsfunktionen von den jeweiligen Services sind anhand des zentralen Backup-Konzeptes auszugestalten. Alle genannten Backup-Quellen werden regelmäßig und automatisch gemäß einem geeigneten Backup-Schema gesichert.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A5, APP.4.4.A8, APP.4.4.A12 ####### Betroffene Module:
openDesk (Prozess-Bausteine), Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM10.01) Regelmäßige Penetrationstests:
Die Umgebung, die Dienste und die einzelnen Module von openDesk werden regelmäßig, mindestens jährlich, durch Penetrationstests überprüft. Hierfür werden sowohl automatisierte als auch manuelle Penetrationstests durchgeführt, um potenzielle Schwachstellen zu identifizieren und um diese anschließend beheben zu können. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.1.A22, APP.3.1.A22, OPS.1.1.1.A20, OPS.1.1.1.A22, OPS.1.1.1.A23, OPS.1.1.6.A14 ####### Betroffene Module:
Nubus, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM10.02) Isolierung bei APT-Vorfällen:
Im Falle eines APT-Vorfalls (Advanced Persistent Threat) sind die betroffenen Netzwerkabschnitte sofort und vollständig zu isolieren, um die Ausbreitung der Bedrohung innerhalb von openDesk zu stoppen. Dies umfasst insbesondere die Trennung vom externen und öffentlichen Netzwerk direkt vom Cloud Provider, um den restlichen Teil des Netzwerks zu schützen.

DER.2.3.A3, siehe STACKIT C5 ####### IT-Grundschutz-Baustein ID-Anforderungen:

(TM10.03) Unverzügliche Passwortänderung nach Sicherheitsvorfällen:
Nach einem Sicherheitsvorfall sind für den Betrieb und die Verwaltung von openDesk und seine zentralen Dienste alle Zugangsdaten unverzüglich zu ändern.

DER.2.3.A4, siehe STACKIT C5

####### IT-Grundschutz-Baustein ID-Anforderungen:

(TM10.04) Sicherheitsbedingte Neuinstallation der Systeme:
Die von einem Sicherheitsvorfall betroffenen Systeme von openDesk müssen einer umfassenden Neuinstallation unterzogen werden. Um wiederkehrende Sicherheitsverletzungen und kontinuierlichen Datenverlust zu verhindern, sind diese Maßnahmen für den kontinuierlichen, sicheren Betrieb essenziell. Zudem müssen Backups vorab in einer Sandbox Umgebung ausreichend geprüft und freigegeben werden, bevor diese wieder in den produktiven Betrieb hinzugefügt werden können.

####### IT-Grundschutz-Baustein ID-Anforderungen:
DER.2.3.A2

(TM11.01) Härtung der Anwendungscontainer (Container):
Zur Härtung von Containern innerhalb der openDesk Umgebung ist die Minimierung der Angriffsfläche zwingend erforderlich, um Kompromittierung, Datenverluste oder Datenmanipulationen zu vermeiden. Durch die Minimierung der Angriffsfläche wird die Hürde, die ein Angreifer nehmen muss, hoch gesetzt, sodass ein erfolgreicher Angriff unwahrscheinlicher wird. Die Angriffsfläche setzt sich aus mehreren internen und externen Faktoren auf verschiedenen Ebenen zusammen. Im Vergleich zu einer virtuellen Maschine können Container eine wesentlich geringere Angriffsfläche haben, indem man folgende Regeln beachtet:

Nur ein Dienst pro Container: In jedem Container von openDesk wird stets nur ein Dienst von openDesk bereitgestellt. Dies ist so auch gemäß BSI IT-Grundschutz SYS.1.6.A11 gefordert. Ein Dienst kann im Kontext von openDesk eine Software wie Nextcloud, eine Datenbank wie PostgreSQL oder auch nur ein Teil eines größeren Verbundes sein, z.B. Software, die aus Microservices besteht. Wenngleich es technisch möglich wäre, mehrere Dienste mit einem Container abzubilden, ist hierauf verzichtet worden, um die Prozessisolierung (ein Container stellt auf Betriebssystemebene einen Prozess dar) zu gewährleisten. Außerdem begünstigt die Ein-Prozess-pro-Container-Politik die Umsetzung der nachfolgenden Maßnahme: minimale Basis-Images.
Verwendung minimaler Basis-Images und Entfernung unnötiger Komponenten: Die Idee hinter dieser Best-Practice ist denkbar einfach. Große Basis-Images, wie z.B. ein vollwertiges Ubuntu oder Debian, etc. enthalten eine Vielzahl an vorinstallierten Software-Komponenten, Pakete und Bibliotheken, welche für den Betrieb der eigentlichen openDesk-Software-Komponente nicht benötigt werden. Jede Software, ob aktiv genutzt oder nicht, kann Sicherheitslücken und generell einen möglichen Angriffsvektor bieten. Daher gilt: je weniger in einem Container steckt, desto besser. Daher basieren die Container von openDesk auf sogenannten minimalen Basis-Images, d.h. Images, welche nur die minimal notwendigen Pakete und Bibliotheken enthalten, damit die entsprechende openDesk-Komponente lauffähig ist. Des Weiteren wurde bei der Erstellung der Container darauf geachtet, dass keine Pakete, Bibliotheken oder andere Komponenten, die nur zum Kompilieren, aber nicht zur Laufzeit benötigt werden, im finalen Container der openDesk-Komponente enthalten sind. Durch beide Maßnahmen werden die Container-Images die auszuführende Anwendung reduziert und somit die Angriffsfläche signifikant verkleinert.
Anstreben von Distroless-Container: Klassische Container enthalten stets Abhängigkeiten, Pakete und Bibliotheken einer konkreten Linux-Distribution, z.B. Ubuntu oder Debian, etc. Die maximale Reduzierung auf das wesentliche besteht darin, all diese Betriebssystem-spezifischen “Altlasten” loszuwerden und so die Angriffsfläche noch weiter zu reduzieren, indem wirklich nur die Bibliotheken und Pakete im Container vorhanden sind, die zur Laufzeit des Prozesses der openDesk-Komponente erforderlich sind und alle anderen Abhängigkeiten an ein (im Container bereitgestelltes, klassisches) Betriebssystem entfallen. Daher auch der Name “Distroless”, also ein Container “ohne Distribution”. Hier zeigt sich auch der Hauptunterschied zwischen Containern und virtuellen Maschinen: virtuelle Maschinen müssen immer auf einem Betriebssystem basieren, Container müssen dies nicht. openDesk basiert aktuell jedoch noch nicht auf Distroless-Containern.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.3.A11, SYS.1.6.A11 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

(TM11.02) Sichere Konfiguration (Container):
Container können auf zwei Arten konfiguriert werden: zum Zeitpunkt ihrer Erstellung oder beim Deployment durch sogenannte Configmaps oder Umgebungsvariablen. In beiden Fällen können fehlerhafte Konfigurationen dazu führen, dass die in Containern betriebene Software, hier openDesk und seine mitgelieferten Module, kompromittiert wird und dass Daten manipuliert oder gelöscht werden. Die Durchsetzung der folgenden Maßnahmen ist mindestens durch organisatorische Maßnahmen auf Seiten des Hyperscalers der Container-Plattform, idealerweise aber automatisiert durch ein Policy-System ebenfalls durch den Hyperscaler technisch umgesetzt.

Ausführung von Containern ohne Privilegien: Wie gemäß BSI IT-Grundschutz SYS.1.6.A17 gefordert, benötigen die Komponenten von openDesk keine erweiterten Rechte, im folgenden Root-Rechte genannt. Ausgestattet mit solchen Rechten und Privilegien kann ein Container auch auf dem darunterliegenden Host Root-Rechte erlangen, was einem Angreifer im Falle einer Kompromittierung einen umfassenden Zugriff auf die Systeme auch außerhalb des Containers ermöglicht, z.B. Nachinstallation von Software, Einschleusen von Schadcode oder Deaktivierung von Sicherheitsmechanismen - nicht nur im Container, sondern auch direkt auf dem Host-System. Um dies ausschließen zu können, verzichten alle Container von openDesk, sofern nicht zwingend erforderlich, auf den Einsatz des Root Users (Nutzer-ID 0) innerhalb der Container. Auf der Container-Ebene, also auf Ebene der durch den Hyperscaler bereitgestellten PaaS-Plattform, ist durch eben diesen sicherzustellen, dass die verwendeten Non-Root User, also die Nutzer mit einer ID größer als 0, nicht auf Nutzer auf dem Host abgebildet werden, welche erweiterte Rechte erlangen könnten. Ausnahmen, für welche der Einsatz von Root-Rechten oder die sogenannten Privilege Escalation, auch Rechteausweitung genannt, unumgänglich ist, sind angemessen dokumentiert. Hierbei ist auch darauf geachtet worden, dass erweiterte Rechte nicht pauschal vergeben worden sind, sondern gemäß der innerhalb von Kubernetes zur Verfügung stehenden Mitteln beim Deployment von openDesk die jeweils erforderlichen Privilegien auf das absolute Minimum begrenzt wurden. Ebenfalls auf der Ebene der Container-Plattform ist sicherzustellen, dass die Container-Runtime als auch die instanziierten Container von einem System-Account des darunterliegenden Betriebssystems ausgeführt werden, welcher nicht direkt über erweiterte Rechte verfügt und dem es auch nicht möglich ist, erweiterte Rechte indirekt über sogenannte Rechteausweitung zu erhalten. Auch ist durch den Hyperscaler sicherzustellen, dass die Container-Runtime z.B. durch die Verwendung der Virtualisierungs-Erweiterungen von CPUs gekapselt werden. Die vom Hyperscaler durchgeführten Maßnahmen sind dokumentiert und attestiert.
Zugriffe auf das Host-System: Gemäß BSI IT-Grundschutz SYS.1.6.A18 und BSI IT-Grundschutz SYS.1.6.A19 sind die Zugriffe auf das Host-System zu begrenzen. Dies umfasst neben den Nutzern innerhalb des Containers, welche über keine Root-Rechte verfügen dürfen, auch direkte Zugriff auf Dateien und Ordner außerhalb des jeweiligen Containers auf dem Host-System. Alle im Kontext von openDesk verwendeten Container verzichten auf den direkten Zugriff auf die darunterliegenden Host-Systeme. Sofern aus betrieblichen Gründen doch Zugriffe oder Berechtigungen notwendig sein sollten, sind die hierfür notwendigen System-Accounts dem darunterliegenden Host bekannt und entsprechend aussagekräftig dokumentiert. Persistenter Massenspeicher, auf welche die Komponenten von openDesk zur Sicherung von Daten angewiesen sind, wird von einem persistenten Speichersystem bezogen, d.h. die einzelnen Anwendungen haben keinen direkten Zugriff auf den Massenspeicher des Host-Systems oder auf befindlichen Verzeichnissen auf dem Host-System selbst. Entsprechende Berechtigungen bzw. Zugriffsbeschränkungen sind auf dem persistenten Speichersystem durch den Hyperscaler gesetzt. Die vom Hyperscaler durchgeführten Maßnahmen sind dokumentiert und attestiert.
Isolation der einzelnen Komponenten von openDesk: Beim Deployment von openDesk sind die durch die Container-Plattform gegebenen Isolationsmechanismen genutzt worden, d.h. einzelne Komponenten von openDesk sind in logischen Einheiten gruppiert und prozess-seitig über sogenannte Namespaces sowie netzwerk-seitig über sogenannte Network Policies (vergleichbar mit einer software-basierten Firewall) separiert worden. Zugriffe von einem Namespace auf den anderen sind nicht pauschal möglich, sondern nur vorab fest definierte Zugriffe über fest definierte Ports und fest definierte Services sind möglich. Die Anzahl der freigegebenen Ports ist auf das Minimum reduziert worden. Darüber hinaus gehende Netzwerkzugriffe wurden beim Deployment verboten.
Beschränkung der nutzbaren Ressourcen pro Container bzw. openDesk Komponenten: Im Kontext von Kubernetes, der zugrundeliegenden Container-Plattform der SaaS-Variante von openDesk, wurden wie durch BSI IT-Grundschutz SYS.1.6.A15 gefordert die den Containern zur Verfügung stehenden Ressourcen reserviert, aber auch eingeschränkt. Besonders letzteres ist zwar gemäß aktueller Best-Practices mindestens umstritten, jedoch überwiegen die mit dieser Vorgabe einhergehenden Vorteile. Auf der einen Seite kann man argumentieren, dass die nach oben unbeschränkte Ressourcennutzung innerhalb eines Namespaces, welcher trotzdem mit einer Quota und damit einer oberen Grenze für CPU, Arbeitsspeicher, Massenspeicher, etc. für alle in ihm befindlichen Komponenten versehen ist, mehr Spielraum bei der Ressourcennutzung und damit eine tendenziell bessere Ressourcenauslastung bietet. Dagegen spricht jedoch, dass ohne Limitierung einzelne Container einer Anwendungskomponente im Fehler- oder Angriffsfall zu viele Ressourcen beanspruchen können, was zur Einschränkung der Verfügbarkeit oder gar dem Ausfall der entsprechenden Komponenten führt. Die Limitierung sorgt dafür, dass Kubernetes regulierend eingreifen kann und automatisch den Neustart der betroffenen Komponente auslösen kann. Ebenfalls wurde die untere Ressourcengrenze für alle Anwendungen festgelegt, sodass für jede Anwendung die minimal notwendigen Ressourcen definiert und reserviert sind, um einen reibungslosen Betrieb zu gewährleisten. Untere und obere Ressourcengrenze, im Kubernetes-Kontext auch Requests und Limits genannt, sorgen darüber hinaus dafür, dass Kubernetes die einzelnen Container optimal auf die zur Verfügung stehenden Knoten des Clusters verteilen kann, was die Plattform-Stabilität an sich als auch die Hochverfügbarkeit der Anwendungen selbst erhöht.
Absicherung der administrativen Zugänge und Absicherung der Konfiguration: Gemäß BSI IT-Grundschutz SYS.1.6.A16 enthalten die Container der openDesk Anwendungen keine Werkzeuge für administrative Fernzugriff bzw. generell keine Fernwartungszugänge. Jegliche administrativen Zugriffe erfolgen stets über direkt oder indirekt über die Container-Runtime durch den Hyperscaler. Vorgenommene Änderungen werden nachvollziehbar dokumentiert und in einem Versionskontrollsystem gemäß BSI IT-Grundschutz SYS.1.6.A20 versioniert abgelegt.

####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A6, APP.2.3.A11, APP.3.1.A12, CON.10.A12, SYS.1.6.A15, SYS.1.6.A16, SYS.1.6.A17, SYS.1.6.A18, SYS.1.6.A19, SYS.1.6.A20 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM11.03) Durchsetzung von Richtlinien (Container):
Im Abschnitt der Best-Practices sind viele Maßnahmen genannt, welche laut BSI IT-Grundschutz umgesetzt werden sollen oder müssen, jedoch wird nie explizit gefordert, dass Technik eingesetzt wird, um die Umsetzung der Maßnahmen und der Richtlinien zu erzwingen, z.B. mit Hilfe eines Policy Systems wie Open Policy Agent (OPA) oder Kyverno und ggf. auch in Kombination mit Bordmitteln der Plattform, hier Kubernetes für openDesk. Genau hier setzt der Baustein BSI IT-Grundschutz SYS.1.6.A21 an. Er fordert nicht nur, dass mit Hilfe erweiterter Sicherheitsrichtlinien die Berechtigungen von Containern weiter eingeschränkt werden, sondern auch, dass es Systeme, idealerweise ein zentrales System gibt, was all diese Einschränkungen und Maßnahmen erzwingt, d.h. ein Deployment, welches nicht erlaubte Berechtigungen verlangt, wird abgelehnt und dessen Start aktiv verhindert. Die genannten Policy Systeme verfügen darüber hinaus über ein integriertes Monitoring, welches an ein zentrales Monitoring angeschlossen ist, sodass Verstöße gegen die Richtlinien oder auch regulierende Eingriffe des jeweiligen Policy Systems dokumentiert und transparent gemeldet werden.

Konkret werden durch das BSI die folgenden drei Einschränkungen gefordert; eine beispielhafte Möglichkeit der Durchsetzung sei hier mit angegeben:

eingehende und ausgehende Netzverbindungen: NetworkPolicies in Kombination mit Kyverno oder OPA zur dynamischen Überwachung, ob die Policies gesetzt sind und damit sie bei Bedarf automatisch neu gesetzt werden. Hinweis: Die korrekte Einstellung der NetworkPolicy, d.h. dass sie auch wirklich den Netzwerk-Verkehr blockt, den sie blocken soll, kann so nicht überprüft werden. Hierfür sind andere Systeme und Maßnahmen (z.B. Einsatz von Sonden und deren Monitoring) erforderlich.
Dateisystem-Zugriffe: Durch sogenannte “Validating Policies” und “Mutating Policies” (beides im Fall von Kyverno, für OPA heißen sie vergleichbar) können Deployments, also im Fall von Kubernetes die Beschreibungen, wie eine Anwendung ausgerollt und betrieben wird, überprüft werden, ob sie den Richtlinien entsprechen (“validating”) und sofern diese Prüfung fehlschlägt, ein Deployment abgelehnt werden bzw. auch aktiv geändert werden (“mutating”) und damit von einem nicht-konformen Deployment intransparent und in Hintergrund in ein konformes Deployment überführt werden.
Kernel-Anfragen (Syscalls): analog zu “Dateisystem-Zugriffe”.

Darüber hinaus sind noch weitere, sehr granulare Einschränkungen der Berechtigungen auf möglich. Die folgende Liste stellt eine nicht abschließende Sammlung an Maßnahmen dar, welche über die Forderungen des BSI hinaus gehen:

Intern arbeitet Kubernetes Namens- und Label-basiert, d.h. Zusammenhänge und Verknüpfungen z.B. von Containern zu darunterliegenden Knoten, werden über entsprechende Label sichergestellt. Daher ist es nur dem Hyperscaler der Kubernetes Plattform gestattet, die Label der darunterliegenden Knoten zu ändern, damit Container einzelner Kunden sauber und isoliert auf dedizierten Knoten betrieben werden können. Darüber hinaus wird grundsätzlich erzwungen, dass Deployments über Labels verfügen.
Der Hyperscaler stellt darüber hinaus durch eine entsprechend erzwungene Policy sicher, dass nur Container aus vertrauenswürdigen Quellen (Registries) eingesetzt werden können, dass diese über eine valide Signatur verfügen müssen, und dass der Zugriff auf die vertrauenswürdigen Registries immer authentifiziert und niemals anonym geschehen darf. Alle Container werden regelmäßig auf bekannte Schwachstellen überprüft, zu alte Container oder welche mit einer zu hohen oder zu gravierenden Anzahl an bekannten Schwachstellen können erst gar nicht mehr ausgeführt und betrieben werden. Zur Umsetzung dieser Maßnahmen und um darüber hinaus auch das Einschmuggeln von Containern mit Schadcode an den bekannten und vertrauenswürdigen Registries vorbei zu unterbinden, wird mit Hilfe einer sogenannten ImagePullPolicy sichergestellt, dass Container Images immer und ausnahmslos gegen die bekannten Registries geprüft werden bzw. stets neu bei Abweichungen aus diesen bezogen werden.
Die mögliche Interaktion von Containern mit der darunterliegenden Infrastruktur wird weitgehend unterbunden, d.h. Zugriffe auf die Container Runtime, jeglicher Zugriff auf das Dateisystem der darunterliegenden Server oder virtuellen Maschinen (egal ob “echte” Ordner wie / oder “unechte” Ordner wie /proc), die Nutzung von als unsicher eingestuften Volumes zur Datenspeicherung, Änderungen an Kernel-Parametern als auch die direkte Nutzung und die Freigabe von Ports sind verboten und die Einhaltung dieser Regeln wird erzwungen.
Darüber hinaus werden auch aktiv die Zugriffe auf Ressourcen, die durch den Kubernetes Cluster selbst bereitgestellt werden, eingeschränkt, wie z.B. die Nutzung des default Namespace zum Betrieb von openDesk oder die standardmäßig aktivierte Bereitstellung der Credentials zur Kommunikation mit dem Kubernetes Cluster selbst sind technisch mittel Policy unterbunden worden. Durch den zwingenden Einsatz sogenannter Quotas auf Ressourcen wie CPU, Arbeitsspeicher, Massenspeicher, etc. werden im Cluster verfügbare Ressourcen fest zugeordnet und beschränkt, was die Systemstabilität im Allgemeinen erhöht.
Die Nutzung von SELinux oder AppArmor wird erzwungen und das eingesetzte Profil fixiert. Eine Policy erzwingt die Verwendung eingeschränkter Nutzer (Non-Root), die Verwendung des Root-Nutzers oder privilegierter Container an sich wird policy-seitig unterbunden ebenso wie jegliche nachträgliche Rechteausweitungen (privilege escalation). Sogenannte Kernel Capabilities, mit deren Hilfe auch eingeschränkte Nutzer vorab mit administrativen Rechten ausgestattet werden können, werden durch eine entsprechende Policy aktiv unterdrückt. Sogenannte Network Policies stellen sicher, dass einzelnen Komponenten von openDesk oder einzelne Kunden netzwerk-seitig isoliert werden und dass die Kommunikation der Komponenten untereinander als auch “nach außen” nur über wohldefinierte Schnittstellen stattfinden kann und auf das notwendige Minimum reduziert ist.

Der Hyperscaler der Plattform stellt sicher, dass Policy Systeme eingesetzt und mindestens gemäß der genannten Maßnahmen eingerichtet sind und überwacht werden. Ausnahmen von all den geschilderten Maßnahmen sind ausführlich dokumentiert, im Einzelfall geprüft und nur begründbar erlaubt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.1.A11, SYS.1.6.A21 ####### Betroffene Module:
Nubus, Collabora, Element, Nextcloud, Jitsi, OpenProject, xWiki

(TM11.04) Hostbasierte Angriffserkennung (Container):
Zur weiteren Absicherung vor eventuellen Angriffen auf oder gar den Ausbrüchen aus einem Container sind durch den Hyperscaler der Container-Plattform geeignete Maßnahmen ergriffen worden, um auf Ebene der Hosts das Verhalten der Container zu überwachen. Wie in BSI IT-Grundschutz SYS.1.6.A24 gefordert, sind diese sogenannten Security-Agenten an das zentrale Monitoring und Logging angeschlossen, um Abweichungen vom Normalverhalten erkennen zu können. Diese Meldungen werden über den zentralen Prozess des Hyperscalers zur Behandlung von Sicherheitsvorfällen angemessen behandelt. Durch den Hyperscaler werden folgende Bereiche überwacht:

Netzverbindungen
erstellte Prozesse
Dateisystem-Zugriffe
Kernel-Anfragen (Syscalls)

Der Hyperscaler stellt sicher, dass die notwendigen Security-Agenten installiert, konfiguriert und gewartet werden, dass sie korrekt an das zentrale Monitoring angeschlossen sind und dass der Prozess zum Umgang mit Vorfällen umgesetzt und etabliert ist und dass bei Vorfällen angemessen kommuniziert wird. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.6.A24 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM11.05) Vorsorge für Untersuchungen (Container):
Der Hyperscaler der Container-Plattform für openDesk stellt gemäß BSI IT-Grundschutz SYS.1.6.A22 sicher, dass in regelmäßigen Abständen von einem Monat vollständige Backups der Container erstellt sowie gegen Datenverlust gesichert und idealerweise verschlüsselt abgelegt werden, damit diese im Bedarfsfall für eine spätere Untersuchung verfügbar sind. Da im Fall von Kubernetes Teile der Konfigurationen von Containern in Configmaps und Secrets ausgelagert oder im Rahmen der Deployment-Manifeste oder Helm Charts anderweitig (aber unter Versionskontrolle) vorgenommen werden, werden auch hiervon in gleichem Turnus vollständige Sicherungen durchzuführen und wie zuvor gesichert abgelegt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.6.A22 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM11.06) Unveränderlichkeit (Container):
Beim Deployment von openDesk werden gemäß BSI IT-Grundschutz SYS.1.6.A23 die Dateisysteme innerhalb des Containers als “read-only”, also ohne Schreibrechte und damit nur lesbar für den Container selbst eingebunden. Lediglich die persistenten Datenspeicher, welche über das verteilte Speicherbackend zur Verfügung stehen, sind als schreibbare Speicherorte verfügbar. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.6.A23 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM11.07) Hochverfügbarkeit von containerisierten Anwendungen (Container):
Gemäß BSI IT-Grundschutz SYS.1.6.A25 werden alle Komponenten von openDesk auf Kubernetes-Ebene hochverfügbar bereitgestellt, indem mittels Replikation und Load-Balancern mehrere Instanzen der jeweiligen Komponente zur Verfügung stehen und dadurch, dass die Replikas auf mehrere Zonen verteilt werden, auch beim Ausfall ganzer Abschnitte die Verfügbarkeit von openDesk nicht gefährdet wird. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.2.1.A18, APP.2.1.A21, APP.3.3.A13, SYS.1.6.A25 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM11.08) Weitergehende Isolation und Kapselung (Container):
Gemäß BSI IT-Grundschutz SYS.1.6.A26 können einzelne Kunden der openDesk SaaS-Variante eine dedizierte Zuordnung der eigenen SaaS-Instanz auf einzelnen Hosts fest zuzuordnen. Ein dedizierter Betrieb der Container mit Hypervisoren oder gar der festen Zuordnung eines einzelnen Containers zu einem einzelnen Container-Host ist nicht vorgesehen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.6.A26 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject, xWiki

(TM12.01): Container Plattform (Kubernetes)
Für die openDesk als SaaS-Lösung wird die Kubernetes Platform as a Service (PaaS) Lösung des Hyperscalers genutzt. Dieser Dienst des Hyperscalers unterliegt den Sicherheitsanforderungen der openDesk als SaaS-Lösung und wird regelmäßig, mindestens jährlich, hinsichtlich der Einhaltung der nachfolgenden Vorgaben geprüft.

(TM12.02) Durchsetzung von Richtlinien (Kubernetes):
Da erforderliche Richtlinien standardmäßig von Kubernetes, wie den Pod Security Admission Controller, nicht durchgesetzt werden können, wird für das Umsetzen des Policy-Managements ein Tool, z.B. Kyverno, in den jeweiligen Clustern von openDesk und seinen zentralen Diensten verwendet.

OWASP Kubernetes Top 10: K04:2022, CIS Kubernetes benchmark v1.23

(TM12.03) Kubernetes Nodes:
Alle Cluster-Dienste werden im sogenannten Management-Cluster, einem dedizierten Kubernetes-Cluster, ausgeführt, welcher durch die StackIT bereitgestellt wird. Alle Workload-Komponenten werden in einem separaten Cluster, den Workload-Clustern, betrieben. Es sind dedizierte Kubernetes Nodes für verschiedene Zwecke zu erstellen: Control Plane Nodes, ETCD Nodes und Worker Nodes. Die Nodes werden durch entsprechende Firewall-Regeln voneinander isoliert. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A14, APP.4.4.A15 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM12.04) Automatisierung und Versionskontrolle:
Einrichtungs- und Wartungsaufgaben sind automatisiert durchzuführen. Hierfür werden vordefinierte Pipelines verwendet, um mit den Kubernetes-Clustern der openDesk-Umgebung zu interagieren. Das Automatisierungssystem muss dazu Zugriff auf ein Versionskontrollsystem haben, in dem alle Konfigurationen der Kubernetes-Cluster, der Cluster-Dienste und der Workloads gespeichert sind, und git-basierte Workflows für Authentifizierung, Autorisierung, Genehmigung und Wartung vollständig unterstützen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A2, APP.4.4.A8, APP.4.4.A16 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM12.05) Lebenszyklus eines Pods:
Für die Initialisierung von Pods werden Init-Container verwendet, um den Start des Hauptcontainers vorzubereiten. Die Init-Container laufen nacheinander und stellen sicher, dass der Hauptcontainer erst gestartet wird, wenn alle Init-Container erfolgreich abgeschlossen sind. Zusätzlich werden Sidecars eingesetzt, um bestimmte Aufgaben wie mTLS durch Proxies zu realisieren und die Trennung von Aufgaben zu unterstützen.

Um sicherzustellen, dass nur autorisierte Container gestartet werden, werden die Images zudem nur aus einer internen Container-Registry bezogen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A6 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM12.06) Trennung und Sicherheit von Pods und Containern:
Gemäß “Least-privilege Prinzip” werden Pods und Container der Kubernetes-Cluster, auf dem openDesk und seine zentralen Dienste aufgesetzt wird, mit einem minimalen Satz an Berechtigungen für Benutzende betrieben. Privilegierte Benutzer auf Containern und solche mit root Rechten sind auf das Mindestmaß zu reduzieren. Nur bei ausgewählte Cluster-Dienste dürfen Benutzende mit erweiterten Rechten ausgestattet werden, wenn dies unbedingt erforderlich ist. Alle Workload Container, z. B. Cryptpad oder Nubus, müssen unprivilegiert betrieben werden. Auszuschließen ist eine Rechteausweitung. Die Richtlinien müssen durch die Verwendung von SecurityContext, schreibgeschützten Dateisystemen und der Deaktivierung von Host-Namespace-Sharing durchgesetzt werden. Alle diese Maßnahmen müssen allen Clustern mittels Policy-Management-Tool implementiert werden.

[OWASP Kubernetes Top 10: K01:2022] ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A4 ####### Betroffene Module:
Nubus, openDesk (Prozess-Bausteine), Cryptpad, Collabora, Element, Jitsi, Open-Xchange, OpenProject, xWiki

(TM13.01) Datenbanksysteme:
Die Zugriffe auf die genutzten Datenbankprodukte PostgresSQL, MariaDB und Redis sind strenger Richtlinien und Kontrollen unterlegen, wie z.B. über rollenbasierte Zugriffskontrollen (RBAC). Nur autorisierte Benutzer können auf Datenbanken und die Inhalte der Datenbanken zugreifen. Alle Zugriffe und Zugriffsversuche werden protokolliert. Anomalien sind zu prüfen, zu analysieren und entsprechend geeigneten Maßnahmen zu ergreifen. Für den Erhalt der Integrität von Datenbanken müssen regelmäßige Integritätsprüfungen und Validierungen der Daten durchgeführt werden und technische Maßnahmen implementiert werden, wie Transaktionsprotokollierung.

Zudem sind System und Dienst interne Datenbanken, welche für die Bereitstellung von openDesk als SaaS notwendig sind, nicht an das Netzwerk angebunden und somit von äußerlichem Zugriff geschützt. Diese Datenbanken werden nicht von Kunden benutzt und sind somit auch nicht für diese zugänglich. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.3.A1, APP.3.3.A9, APP.4.3.A12, APP.4.3.A13, APP.4.3.A16, APP.4.3.A17, APP.4.3.A18, APP.4.3.A19, APP.4.3.A20, APP.4.3.A21, APP.4.3.A24 ####### Betroffene Module:
Nubus, Nextcloud

(TM13.02) Sicherheitsanforderungen an Webanwendungen:
Für eine ausreichende Sicherung von openDesk als Webservice sind alle eingehenden und ausgehenden Daten auf Richtigkeit, Vollständigkeit und Authentizität zu überprüfen. Die integrierten Anwendungen innerhalb von openDesk müssen den aktuellen Sicherheitsanforderungen, wie bspw. OWASP Top Ten, entsprechen, regelmäßige Sicherheitsüberprüfungen unterzogen und Penetrationstests ausgesetzt werden. Für die Konfiguration all dieser Webanwendunge, z. B. Element oder Jitsi, muss die Implementierung von Sicherheitsheadern und regelmäßigen Sicherheitsüberprüfungen erfolgen. Dazu gehört auch die Deaktivierung nicht verwendeter HTTP-Methoden. Sie sind so zu konfigurieren, dass sie keine sicherheitsrelevanten Informationen preisgeben. Dazu gehört u.a. die Maskierung von Fehlermeldungen, die keine sensiblen Daten enthalten dürfen, sowie die Implementierung von Sicherheitsheadern und Verschlüsselungstechniken. Zugangskontrollmaßnahmen in Form von Authentifizierungs- und Autorisierungsmechanismen wie bspw. OAuth müssen implementiert sein, sowie das Least-Privilege Prinzips durchgesetzt werden. Mit Implementierung von Maßnahmen wie Rate Limiting oder Traffic Filtering müssen Webanwendungen durch Denial-of-Service (DoS)-Angriffe gesichert werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.1.A1, APP.3.1.A4, APP.3.1.A7, APP.3.1.A11, APP.3.1.A12, APP.3.1.A14, APP.3.1.A20, APP.3.1.A21, APP.3.1.A22, CON.10.A1, CON.10.A10, CON.10.A13, CON.10.A14, CON.10.A15, CON.10.A17, CON.10.A18, CON.10.A2, CON.10.A3, CON.10.A4, CON.10.A5, CON.10.A6, CON.10.A7, CON.10.A8, CON.10.A9, OPS.1.1.1.A20, OPS.1.1.1.A22, OPS.1.1.1.A23 ####### Betroffene Module:
Nubus, xWiki, Cryptpad, Collabora, Element, Nextcloud, Jitsi, Open-Xchange, OpenProject

7. Modellierung der Sicherheitsmaßnahmen (Anwendung)

####### DISCLAIMER: Das Sicherheitskonzept in der aktuellen Form basiert auf den verfügbaren Informationen zum 21.11.2025. Weitergehende Informationen werden erwartet und sukzessive eingearbeitet. Die Validierung der Informationen ist ausstehend.

Dieses Kapitel beschreibt die Modellierung der Sicherheitsmaßnahmen für openDesk mit dem Fokus auf die Software openDesk selbst, d.h. dieses Kapitel kann sowohl für die SaaS- als auch die On-Premises-Variante herangezogen werden. Für die On-Premise-Variante gelten die in diesem Kapitel beschriebenen ID-Anforderungen sowie zusätzlich die Anforderungen aus Kapitel 8 (SaaS). Es beinhaltet die Identifizierung geeigneter Sicherheitsanforderungen sowie die Umsetzung entsprechender Maßnahmen für den Informationsverbund durch die Auswahl passender Bausteine aus dem IT-Grundschutz-Kompendium. Weitere Details finden Sie in der separaten Datei “20251029_openDesk_Checklists_IT-Grundschutz”.

7.1 Organisatorische Sicherheitsmaßnahmen

(OMS1.01) Organisation und Rollen im Entwicklungsprozess der Module
Wenn bei der Entwicklung und Betrieb kein geeignetes Vorgehensmodell oder keine geeignete Entwicklungsumgebung gewählt wird oder die Qualitätssicherung fehlt, entstehen unklare Verantwortlichkeiten - niemand überwacht die Sicherheitsanforderungen oder prüft Architektur- und Testqualität. Dies führt zu Konzeptionsfehlern und gefährdet die Informationssicherheit. Die Institution benennt eine gesamtverantwortliche Person für den Prozess. Die Rollen werden verbindlich definiert (Anforderungsmanagement, Architektur, Informationssicherheit, Implementierung, Test…). Für jedes Projekt wird eine verantwortliche Person für die Informationssicherheit festgelegt. Diese Struktur wird dokumentiert und regelmäßig überprüft.

Nubus (Univention) steuert Benutzer-, Gruppen- und Rollenverwaltung. Hier wird das Least-Privilege-Prinzip zentral umgesetzt, indem nur die absolut notwendigen administrativen und organisatorischen Rechte vergeben werden. Nextcloud setzt Least-Privilege um, indem Benutzende nur auf jene Dateien, Ordner und Funktionen zugreifen dürfen, die sie für ihre Arbeit benötigen. In OpenProject werden projektbezogene Rollen so vergeben, dass Nutzer nur die benötigten Funktionen wie Lesen, Bearbeiten oder Administrieren eines Projekts erhalten. In CryptPad werden Zugriffsrechte pro Pad oder Ordner vergeben. Schreib- und Administratorrechte werden strikt auf die Personen begrenzt, die sie benötigen, um den Schutz sensibler und verschlüsselter Daten konsequent zu gewährleisten. In Open-Xchange werden Freigabe-, Lese- und Bearbeitungsrechte auf Kalender, Postfächer und Kontakte nur nach tatsächlichem Bedarf vergeben. Administrative Rechte für die Mail- oder Groupware-Verwaltung bleiben ausschließlich autorisierten Fachadministratoren vorbehalten. ####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.8.A1, CON.8.A2, CON.8.A3, CON.8.A11, OPS.1.1.1.A1 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(OMS1.02) Schulung und Qualifikation des Betriebspersonals
Fehlendes Know-how oder Personalmangel führen zu Betriebsstörungen und gefährden die Informationssicherheit. Wenn nur einzelne Personen über kritisches Wissen verfügen, entsteht Abhängigkeit und Ausfallrisiko. Unzureichend geschultes Personal kann Fehlkonfigurationen, Ausfälle oder Sicherheitslücken verursachen und damit Verfügbarkeit, Integrität und Vertraulichkeit beeinträchtigen. Ein Schulungsplan stellt sicher, dass mehrere Personen alle wichtigen IT-Komponenten und Betriebsmittel kompetent betreiben können. Schulungen decken Themen wie Härtung, Standardkonfigurationen, Sicherheitsfunktionen, Prozessschnittstellen und Abhängigkeiten ab. Bei Einführung neuer Systeme wird das Schulungsbudget frühzeitig eingeplant, und das Wissen regelmäßig aktualisiert, um Ausfälle und Fehlhandlungen zu vermeiden.

Die openDesk-Hersteller liefern eine Beschreibung bzw. Dokumentation eines Schulungsplans für den IT-Betrieb, der sicherstellt, dass für alle IT-Komponenten und Betriebsmittel jeweils mehrere Personen über die erforderlichen Fähigkeiten und Qualifikationen verfügen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.1.1.A16 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(OMS1.03) Verpflichtungsmaßnahmen der Benutzenden zur IT-Sicherheit
Sowohl menschliche Fehlhandlungen als auch Schadprogramme stellen erhebliche Risiken für die Informationssicherheit dar. Fehlende Kenntnisse über Sicherheitsregelungen, mangelnde Schulung oder eine unzureichende Sensibilisierung führen häufig zu Sicherheitsvorfällen. Gleichzeitig können infizierte Webseiten, manipulierte E-Mails oder unsichere Geräte Schadsoftware einschleusen, die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen gefährdet. Besonders Ransomware kann Systeme lahmlegen, während Botnetze oder infizierte IoT-Geräte den Betrieb und das Ansehen der Institution beeinträchtigen. Die Institutionsleitung wird aktiv für Informationssicherheit sensibilisiert und unterstützt Schulungsmaßnahmen organisatorisch und kommunikativ. Alle Mitarbeitenden und externen Nutzenden werden regelmäßig über aktuelle Bedrohungen und sichere Verhaltensweisen informiert. Schulungen und Informationskampagnen vermitteln praxisnah, wie verdächtige E-Mails, Webseiten oder Dateien erkannt und gemieden werden. Sie kennen die zuständigen Kontaktpersonen und melden jeden Verdacht auf Schadsoftware umgehend. Ergänzend sorgen technische Schutzmechanismen für die automatische Erkennung, Blockierung und zentrale Meldung von Infektionen. Diese Meldungen werden dokumentiert, ausgewertet und das Vorgehen regelmäßig getestet. Ein zielgruppenorientiertes Schulungsprogramm zur Informationssicherheit wird konzipiert, kontinuierlich aktualisiert und auf die jeweiligen Aufgaben angepasst. Es vermittelt das notwendige Wissen zur Umsetzung der Sicherheitsrichtlinien und des IT-Grundschutzes. Besonders exponierte Personen (z. B. Führungskräfte oder Administrierende) erhalten vertiefende Spezialschulungen über gezielte Angriffe und angemessene Schutzmaßnahmen. Der Lernerfolg wird regelmäßig gemessen und zur Verbesserung der Maßnahmen genutzt. Zum Beispiel: Schulungen zeigen, wie wichtig sichere Passwörter und MFA sind, da Nubus als zentraler Identity Provider alle anderen Dienste schützt. Schulungen beim Nextcloud vermitteln, wie Nutzer verdächtige Dateien erkennen (z. B. unerwartete Office-Dokumente mit Makros). Die Mitarbeiter von Element werden über interne Kanäle auf dem Laufenden gehalten. Element-Kunden können unsere Sicherheits-Update-E-Mails abonnieren. Bei XWiki sind die Mitarbeiter mit den Bedrohungen durch Malware bestens vertraut. Interne Kanäle (Matrix Rooms) werden genutzt, um neue Bedrohungen zu melden und im Falle von Risiken für das Unternehmen geeignete Gegenmaßnahmen einzuleiten. Nextcloud bietet mit seiner ICAP-Schnittstelle die Möglichkeit, hochgeladene Dateien durch einen vom Betreiber bereitgestellten ICAP-Service prüfen und bei Bedarf löschen zu lassen. Schadhafte Dateien können nicht hochgeladen werden, und der Benutzer erhält eine entsprechende Fehlermeldung. ####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.1.4.A7, OPS.1.1.4.A9, ORP.3.A1, ORP.3.A3, ORP.3.A4, ORP.3.A6, ORP.3.A7, ORP.3.A8, ORP.3.A9, SYS.1.1.A9 ####### Betroffene Module:
xWiki, Collabora, Element, Nubus, OpenProject, OpenXchange, Cryptpad

(OMS1.04) Benutzerverwaltung, Rollenverwaltung und Berechtigungsmanagement
Fehlende oder unzureichende Prozesse im Identitäts- und Berechtigungsmanagement führen dazu, dass Zugriffe nicht auf das erforderliche Maß beschränkt sind. Ohne klar definierte Abläufe kann der IT-Betrieb beispielsweise keine zeitnahen Informationen über personelle Veränderungen erhalten, wodurch ausgeschiedene Mitarbeitende weiterhin Zugriff auf vertrauliche Daten behalten. Ebenso besteht die Gefahr, dass Mitarbeitende durch Abteilungswechsel übermäßig viele Berechtigungen ansammeln. Eine sichere Authentisierung ist notwendig, um unbefugten Zugriff auf sensible Bereiche und Module zu verhindern. Unzureichend geregelte Benutzer- und Rollenverwaltungen können zu übermäßigen oder falsch vergebenen Rechten führen, wodurch vertrauliche Informationen offengelegt, manipuliert oder gelöscht werden können. Fehlende Transparenz über bestehende Berechtigungen erschwert zudem die Nachvollziehbarkeit von Änderungen und gefährdet die Integrität sowie die Verfügbarkeit des IT-Betriebs. Unkontrollierter Zugriff kann darüber hinaus sensible Informationen preisgeben und die Systemleistung beeinträchtigen. Für alle Benutzerkonten werden Rollen und Berechtigungen klar definiert, dokumentiert und regelmäßig überprüft.

Zur sicheren Verwaltung der Zugriffsrechte sollte ein zentraler netzbasierter Authentisierungsdienst implementiert werden. Dieser ermöglicht eine einheitliche Steuerung und zentrale Deaktivierung von Konten über alle Systeme hinweg. Das Identitäts- und Berechtigungsmanagement-System ist ein zentraler Bestandteil der IT-Infrastruktur. Daher sollte geprüft werden, welche Auswirkungen ein Ausfall auf die Geschäftsprozesse hat.Es sind Vorkehrungen zu treffen, um bei einem Ausfall des Systems arbeitsfähig zu bleiben (z.B. durch redundante IDM-Komponenten, Notfallbenutzende oder Offline-Zugriffsmechanismen). Nubus fungiert als zentraler Identity Provider für openDesk und kommuniziert mit Diensten wie Nextcloud, Element und OpenProject

Berechtigungen dürfen nur nach dem Prinzip der geringsten Berechtigung (Least Privilege, Need-to-Know) vergeben werden. Erweiterte Rechte sind nur nach schriftlicher Begründung und Prüfung zulässig. Zum Beispiel, Zugriff auf Pads, Ordner und Teams nur über Eigentümer- und Bearbeiterrechte; Benutzer sehen nur Nextcloud Ordner/Dateien, die explizit freigegeben wurden; OpenXchange Kalender-, Mail- und Ordnerfreigaben werden granular vergeben; OpenProject-Rollen wie “Mitglied”, “Manager”, “Projektadmin” definieren exakt benötigte Rechte.

Passwörter müssen komplex, aber benutzerfreundlich gestaltet sein, damit sie sowohl sicher als auch praktikabel im Arbeitsalltag einsetzbar sind. Mehrfache Passwortverwendung ist unzulässig. Passwörter sind kryptografisch zu sichern und vor unbefugtem Zugriff geschützt zu speichern.

Für privilegierte Konten (z.B. Administratoren) sollte Mehr-Faktor-Authentisierung (MFA) eingesetzt werden. Zudem ist ein Authentisierungskonzept zu definieren, das für jedes IT-System die geforderten Sicherheitsmechanismen, Passwortregeln und Authentisierungsverfahren beschreibt.

Bei personellen Änderungen müssen nicht mehr benötigte Berechtigungen sofort entzogen werden. Zudem ist sicherzustellen, dass unvereinbare Aufgaben organisatorisch und technisch getrennt werden, um Interessenskonflikte zu vermeiden.
Administrationszugänge werden ausschließlich über dedizierte, abgesicherte Systeme und Netze bereitgestellt. Alle eingerichteten Kennungen, Gruppen und Rechteprofile müssen vollständig dokumentiert werden. Es ist festzulegen, welche Zutritts-, Zugangs- und Zugriffsrechte einzelnen Funktionen zugeordnet sind und wie deren Entzug erfolgt. Alle Änderungen an Rollen und Berechtigungen werden nachvollziehbar protokolliert und regelmäßig durch den IT-Betrieb oder den ISB geprüft. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.2.A5, APP.3.2.A13, APP.5.4.A13, APP.5.4.A17, OPS.1.1.1.A1, OPS.1.1.1.A18, OPS.1.1.2.A5, OPS.1.1.2.A6, OPS.1.1.2.A21, OPS.1.1.2.A22, OPS.1.1.2.A7, OPS.1.1.2.A8, OPS.1.1.2.A11, OPS.1.1.2.A23, OPS.1.1.2.A16, OPS.1.1.2.A24, OPS.1.1.3.A2, OPS.1.1.5.A1, OPS.1.1.7.A2, OPS.1.1.7.A5, OPS.1.1.7.A6, ORP.4.A1, ORP.4.A10, ORP.4.A11, ORP.4.A12, ORP.4.A13, ORP.4.A14, ORP.4.A15, ORP.4.A16, ORP.4.A17, ORP.4.A18, ORP.4.A19, ORP.4.A2, ORP.4.A20, ORP.4.A21, ORP.4.A22, ORP.4.A23, ORP.4.A24, ORP.4.A3, ORP.4.A4, ORP.4.A5, ORP.4.A6, ORP.4.A7, ORP.4.A8, ORP.4.A9, SYS.1.1.A2, SYS.1.3.A6, SYS.2.1.A1, SYS.2.1.A13, SYS.2.1.A37 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(OMS2.01) Richtlinie und Dokumentation der Module
Fehlende oder unzureichende Dokumentation und Richtlinien erschweren Fehlersuche, Wartung und Anpassung. Ohne nachvollziehbare Architektur- und Schnittstellenbeschreibungen können Sicherheitslücken oder Abhängigkeiten nicht erkannt werden. Projekt-, Funktions- und Schnittstellendokumentationen werden während des Entwicklungszyklus gepflegt. Fehlt eine einheitliche Richtlinie, arbeitet jedes Team individuell – das begünstigt unklare Prozesse, mangelnde Qualitätssicherung und uneinheitliche Werkzeugnutzung. Eine verbindliche Richtlinie legt Standards fest, die Informationssicherheit, Dokumentation und Qualität dauerhaft sicherstellen. Sie definiert Benennungs- und Codierkonventionen, verbotene Elemente sowie sicherheitsrelevante Vorgaben. Die Betriebsdokumentation umfasst Sicherheitshinweise für Installation und Betrieb. Die Dokumentation der Softwarearchitektur und Bedrohungsmodellierung ist verpflichtend. Sie wird im Vorgehensmodell verankert und zentral versioniert. Beim Nubus werden Rollen- und Berechtigungsmodelle dokumentiert, um Abhängigkeiten und Sicherheitsrisiken (z. B. fehlerhafte Synchronisation) nachvollziehen zu können. Eine standardisierte API-Dokumentation legt fest, wie Dienste Identitäten abfragen und die Provisionierung durchführen. Beim Collabora beschreibt die Dokumentation, wie Collabora die Dateizugriffe aus Nextcloud übernimmt und welche Sicherheitsmechanismen die Ausführung von Makros verhindern. Für Nextcloud existieren verbindliche Betriebshandbücher, die Konfiguration, Härtung (z. B. App-Whitelists) und Performance-Parameter dokumentieren. Beim CryptPad legen Richtlinien fest, wie Team-Spaces zu konfigurieren sind, damit keine unbeabsichtigten Offenlegungen von Schlüsseln erfolgen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.8.A10, CON.8.A11, CON.8.A12, CON.8.A16, CON.8.A22, OPS.1.1.1.A12, OPS.1.1.3.A11, OPS.1.1.5.A1, OPS.1.1.7.A7, SYS.1.1.A39, SYS.2.1.A40 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(OMS2.02) Betriebsorganisation und Ressourcenplanung
Fehlende oder veraltete Betriebshandbücher sowie unzureichend geplante Ressourcen gefährden die Stabilität des IT-Betriebs. Ohne dokumentierte Abläufe und klare Zuständigkeiten können Aufgaben fehlerhaft oder gar nicht ausgeführt werden. Personalmangel, fehlende Redundanz oder unzureichende Betriebsmittel führen zu Ausfällen, eingeschränkter Verfügbarkeit und Know-how-Abhängigkeiten von Einzelpersonen. Ebenso gehen betriebsrelevante Informationen verloren, wenn Dokumentationen oder Ressourcen unvollständig sind. Für alle IT-Komponenten werden Betriebshandbücher erstellt, die Konfiguration, Rollen, Härtung, Monitoring, Datensicherung und Notfallprozesse enthalten. So legt das Betriebshandbuch für Jitsi beispielsweise die Authentifizierungsmechanismen, die Raumverwaltung sowie die Moderator- und Adminrollen verbindlich fest. Das Betriebshandbuch für Nextcloud beschreibt detailliert die Konfiguration der Apps, die Freigaberegeln und die Rollenmodelle. Das Betriebshandbuch für Nubus dokumentiert die Konfiguration der Verwaltungsoberfläche sowie die Rollen- und Berechtigungsstrukturen im openDesk-Kontext. Sie sind jederzeit verfügbar und werden regelmäßig überprüft und aktualisiert. Der IT-Betrieb plant Personal- und Sachressourcen mit ausreichender Vertretung oder Redundanz. Für alle Aufgaben wird der Zeit- und Materialbedarf ermittelt. Ressourcenplanung und Dokumentation werden regelmäßig angepasst, um Kapazitätsengpässe und Betriebsunterbrechungen zu vermeiden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.1.1.A2, OPS.1.1.1.A3, OPS.1.1.1.A4, OPS.1.1.1.A17, OPS.1.1.1.A18, OPS.1.1.1.A25, OPS.1.1.2.A2, OPS.1.1.2.A4, OPS.1.1.2.A5, OPS.1.1.2.A17, OPS.1.1.6.A7, SYS.1.1.A35 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(OMS2.03) Strukturiertes Änderungsmanagement und Integration in Geschäftsprozesse
Ein geregelter Umgang mit Änderungsanforderungen ist essenziell, um Fehlentscheidungen, Sicherheitslücken und betriebliche Störungen zu verhindern. Werden Änderungen ohne strukturierte Erfassung, Bewertung oder Abstimmung umgesetzt, besteht das Risiko, dass sicherheitsrelevante Aspekte übersehen oder fachliche Abhängigkeiten nicht berücksichtigt werden. Dies kann dazu führen, dass Geschäftsprozesse beeinträchtigt, Systeme instabil werden oder Schwachstellen in die Produktivumgebung gelangen. Änderungen an der Nextcloud-Umgebung, wie die Aktivierung neuer Apps – etwa Tasks oder Deck – oder die Anpassung von Freigaberichtlinien, erfordern eine sorgfältige Prüfung, da ungeprüfte Eingriffe erhebliche Sicherheits- und Betriebsrisiken mit sich bringen. Ebenso kritisch sind Änderungen im Bereich Collabora Online, beispielsweise ein Versionsupdate oder Anpassungen an der WOPI-Schnittstelle zur Nextcloud. Ohne vorherige Bewertung und Testung besteht hier das Risiko, dass Office-Dokumente nicht mehr geöffnet werden können, Formatierungsfehler auftreten oder die Echtzeitbearbeitung ausfällt. Eine mangelnde Koordination zwischen IT und Fachabteilungen schwächt die Informationssicherheit, während fehlende Transparenz im Prozess die Nachvollziehbarkeit und Priorisierung erschwert. Alle Änderungsanforderungen sollten zentral erfasst, dokumentiert und von fachverantwortlichen Personen hinsichtlich Informationssicherheit überprüft werden. Der Abstimmungsprozess muss sicherstellen, dass alle betroffenen Zielgruppen einbezogen und ihre Rückmeldungen nachvollziehbar dokumentiert werden. Das Änderungsmanagement ist zudem fest in die Geschäftsprozesse einzubinden: Fachabteilungen müssen über geplante Anpassungen informiert werden, und deren aktuelle Prozesslage ist bei der Umsetzung zu berücksichtigen. Im Änderungsmanagementprozess sollte durch geeignete Verfahren sichergestellt werden, dass auch vorübergehend oder längerfristig nicht erreichbare Systeme die erforderlichen Patches und Änderungen zeitnah erhalten oder längerfristig nicht erreichbare Geräte die Patches und Änderungen erhalten. ####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.1.3.A5, OPS.1.1.3.A6, OPS.1.1.3.A7, OPS.1.1.3.A11, OPS.1.1.3.A14, OPS.1.1.6.A6, SYS.2.1.A44 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(OMS3.01) Governance und Compliance eines Webservers – Inhaltliche Anforderungen
Bei der Veröffentlichung von Inhalten oder dem Anbieten von Diensten über den Webserver müssen gesetzliche Vorgaben eingehalten werden, um rechtliche Konsequenzen zu vermeiden. Fehlende Zuständigkeiten und Meldeprozesse können dazu führen, dass Sicherheitsvorfälle unbemerkt bleiben oder verspätet behandelt werden. In xWiki müssen Verantwortliche für redaktionelle Qualität und Rechteverwaltung benannt werden, um fehlerhafte oder rechtswidrige Inhalte frühzeitig zu erkennen. In Element ist insbesondere die Moderation öffentlicher Räume, der Umgang mit Chat-Inhalten und die Meldung sicherheitsrelevanter Ereignisse organisatorisch zu regeln. Für Jitsi müssen Prozesse für die Moderation, den Umgang mit Aufzeichnungen und die Absicherung der Meetingräume festgelegt werden. In Nextcloud sind Verantwortlichkeiten für Dateifreigaben, externe Links, App-Nutzung und die rechtlich korrekte Veröffentlichung von Dokumenten unverzichtbar. Eine klare Benennung von Ansprechpersonen und Prozessen erhöht die Rechtssicherheit und Reaktionsfähigkeit der Institution. Die Institution beachtet alle einschlägigen Telemedien-, Datenschutz- und Urheberrechtsvorgaben. Für umfangreiche Webangebote werden zentrale Ansprechpersonen benannt, und Prozesse zur Behandlung von Problemen oder Sicherheitsvorfällen werden definiert. Auf der Webseite wird eine Kontaktmöglichkeit für externe Sicherheitsmeldungen bereitgestellt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.2.A7, APP.3.2.A20 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(OMS4.01) Wartung und Instandhaltung
Fehlende oder unklare Regelungen zu Wartung und Instandhaltung führen zu Ausfällen, Informationsverlust oder Sicherheitslücken. Wenn Wartungsarbeiten unkoordiniert durchgeführt oder nicht dokumentiert werden, kann es zu Fehlkonfigurationen, unbefugten Eingriffen und eingeschränkter Systemverfügbarkeit kommen. Mangelhafte oder unregelmäßige Instandhaltung erhöht zudem das Risiko technischer Defekte und verhindert eine stabile IT-Betriebsfähigkeit. Für alle IT-Komponenten werden verbindliche Verfahren zur Wartung und Reparatur definiert. In xWiki sind regelmäßige Prüfungen der Datenbankkonsistenz, Updates der Erweiterungen und Backups der Wissensinhalte notwendig. Bei Collabora müssen Software-Updates, die Funktion der WOPI-Schnittstelle und die Renderqualität der Dokumente regelmäßig getestet werden. CryptPad erfordert turnusmäßige Updates der Serverkomponenten, Überprüfung der Speicher- und Schlüsselverwaltung sowie das Monitoring der Verschlüsselungsmechanismen. Zuständigkeiten und Sicherheitsaspekte sind klar festgelegt, und alle Arbeiten werden dokumentiert. Wartung durch externe Dienstleister erfolgt nur nach Abstimmung mit dem IT-Betrieb, der autorisierte interne Ansprechpartner benennt und die Durchführung überwacht. Ergänzend werden vorbeugende Instandhaltungsmaßnahmen in festen Intervallen eingeplant. Bei kritischen Systemen wird geprüft, ob vorausschauende Instandhaltung (Predictive Maintenance) sinnvoll ist, um Störungen frühzeitig zu erkennen und Ausfälle zu vermeiden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.1.1.A19, OPS.1.1.1.A26, OPS.1.1.2.A25, SYS.2.1.A41 ####### Betroffene Module:
xWiki, Collabora, CryptPad, Element, Nubus, OpenProject, OpenXchange, Nextcloud

(OMS4.02) Regelmäßige Aktualisierung von IT-Systemen und Software
Ein strukturiertes Patch- und Änderungsmanagement ist erforderlich, um Risiken wie verspätete Updates, unklare Zuständigkeiten, Kommunikationsmängel oder fehlerhafte Verteilungen zu vermeiden. Ohne definierte Prozesse und Verantwortlichkeiten können sicherheitsrelevante Patches zu spät oder gar nicht eingespielt werden, wodurch bekannte Schwachstellen bestehen bleiben. Dienste wie Nextcloud, OpenProject, Element, xWiki, CryptPad, Collabora, Open-Xchange und Nubus setzen auf unterschiedliche Technologien und Release-Zyklen – ohne klare Prozesse würden Updates verspätet, unkoordiniert oder fehlerhaft erfolgen. Dies kann zu Systemausfällen, Manipulationen oder Datenverlust führen und beeinträchtigt direkt die Verfügbarkeit, Integrität und Vertraulichkeit der IT-Systeme. In wirksames Patch- und Änderungsmanagement verlangt, dass automatische Update-Mechanismen sicher konfiguriert, kontrolliert und auf ihre Funktionsweise geprüft werden. Innerhalb der Organisation sollte klar definiert sein, wer für Bewertung, Priorisierung und Freigabe von Patches zuständig ist. Alle Updates sind regelmäßig zu prüfen und zeitnah nach Veröffentlichung zu installieren, sofern keine berechtigten Gründe dagegen sprechen. Entscheidungen über das Nicht-Einspielen von Patches müssen nachvollziehbar dokumentiert werden. Systeme, für die kein Herstellersupport mehr besteht, dürfen nur weiterbetrieben werden, wenn ein sicheres Betriebskonzept nachgewiesen werden kann. ####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.1.3.A3, OPS.1.1.3.A15, OPS.1.1.4.A6, OPS.1.1.7.A2, SYS.2.1.A3 ####### Betroffene Module:
xWiki, Collabora, CryptPad, Element, Nubus, OpenProject, OpenXchange, Nextcloud

7.2 Technische Sicherheitsmaßnahmen

(TMS1.01) Installation und Konfiguration der Module:
Module oder IT-Komponenten sollten nur mit den erforderlichen und zugelassenen Funktionen konfiguriert werden, um unnötige Dienste, Datenübertragungen oder potenzielle Sicherheitslücken zu vermeiden. Eine sorgfältige Konfiguration schützt vor Datenverlust, unbefugtem Zugriff und rechtlichen Verstößen. Bei der Installation und Konfiguration der Softwaremodule von openDesk, muss sichergestellt werden, dass diese nur mit dem geringsten, für den Betrieb des Moduls und davon abhängiger Module, Funktionsumfang installiert wird. Beispielsweise wird Nubus ausschließlich mit den erforderlichen Identity-Funktionen wie OIDC/OAuth2 und SCIM betrieben, während nicht benötigte SSO-Connectoren und Debug-Endpunkte deaktiviert bleiben. Dadurch bleiben nur die minimal notwendigen Authentifizierungs- und Provisionierungsprozesse aktiv. Open-Xchange wird ebenfalls auf die wesentlichen Kernfunktionen wie E-Mail, Kalender und Kontakte reduziert, während Social-Media-Integrationen und optionale Zusatzmodule deaktiviert werden. So werden unnötige Dienste vermieden und die Kommunikationsumgebung wirksam geschützt. Für die Ausführung Software Module ist sicherzustellen dass diese nur die absolut notwendigen Funktionen während der Laufzeit verwenden. Es ist eine Auflistung der zwingend benötigten Funktion für jedes benötigte Modul der Umgebung anzufertigen. Während der Beschaffung und Einrichtung der IT-Komponenten ist zu dokumentieren, welche Zertifikate für den ordnungsgemäßen Betrieb erforderlich sind. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.6.A4, APP.3.2.A8, APP.3.2.A1, APP.3.2.A10, APP.5.4.A4, APP.5.4.A15, APP.1.1.A12, OPS.1.1.1.A15, OPS.1.1.4.A5, SYS.1.1.A6, SYS.1.1.A31, SYS.1.1.A33, SYS.2.1.A42, SYS.2.1.A15, SYS.2.1.A16, SYS.2.1.A35 ####### Betroffene Module:
Nubus, Cryptpad, xWiki, Collabora, Open-Xchange, OpenProject, Jitsi, Element, Collabora

(TMS1.02) Auswahl und Bewertung der Module:
Die Auswahl und Bewertung von Software oder Werkzeugen ist entscheidend, um sicherzustellen, dass sie funktional, sicher und vertrauenswürdig ist. Werden ungeeignete oder aus unsicheren Quellen stammende IT-Komponenten eingesetzt oder falsch genutzt, kann dies zu Betriebsstörungen, Sicherheitslücken und Datenverlust führen. Eine sorgfältige Prüfung schützt somit die Integrität, Verfügbarkeit und Vertraulichkeit der Systeme und Daten. Module sollten anhand eines klaren Anforderungskatalogs gesichtet und mit einer Bewertungsskala verglichen werden. Module, die in die engere Auswahl kommen, müssen die Anforderungen erfüllen und zusätzlich hinsichtlich Benutzerakzeptanz, Schulungsaufwand und Migration bewertet werden, bevor Fachverantwortliche und IT gemeinsam eine Entscheidung treffen. openDesk basiert auf Open-Source-Software, die nach Kriterien wie Stabilität, Größe der Community, Reaktionszeit auf Sicherheitslücken und Transparenz der Entwicklungsprozesse ausgewählt wird. Darüber hinaus wird geprüft, wie gut die Komponenten innerhalb der openDesk-Architektur zusammenspielen: Nubus übernimmt die zentrale Identitäts- und Provisionierungsfunktion, Nextcloud bindet Collabora und Dateiablagen ein, OpenProject nutzt die gemeinsame Authentifizierung über Nubus, und OpenXchange integriert sich in bestehende Mail-Services. CryptPad und xWiki ergänzen die Umgebung als eigenständige, aber kompatible Wissens- und Dokumentdienste. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.6.A7, APP.3.2.A10, OPS.1.1.3.A8, OPS.1.1.3.A9, OPS.1.1.4.A3 ####### Betroffene Module:
Nubus, Cryptpad, xWiki, Nextcloud, Open-Xchange, OpenProject

(TMS1.03) Regelung zur Bereitstellung und Verfügbarkeit von Installationsdateien
Die Verfügbarkeit von Installations- und Konfigurationsdateien ist essenziell, um Softwareinstallationen reproduzierbar und zuverlässig durchführen zu können – etwa bei Neuinstallationen, Updates oder Wiederherstellungen nach Systemausfällen. Der IT-Betrieb sollte Installationsdateien entweder zentral sichern oder deren dauerhafte Verfügbarkeit über vertrauenswürdige Bezugsquellen sicherstellen. Konfigurationsdateien sollten ebenfalls gesichert oder die Konfiguration nachvollziehbar dokumentiert werden. Diese Maßnahmen sollten ins Datensicherungskonzept der Institution integriert werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.6.A8, OPS.1.1.6.A15 ####### Betroffene Module:
Nubus, Cryptpad, xWiki, Nextcloud, Open-Xchange, OpenProject

(TMS1.04) Inventarisierung von Module
Software sollte inventarisiert und in einem Bestandsverzeichnis dokumentiert werden, einschließlich Systeme, Lizenzen und bei Bedarf sicherheitsrelevanter Einstellungen. Abweichungen von Standardkonfigurationen sind festzuhalten, und das Verzeichnis sollte bei Änderungen, insbesondere bei Installationen, aktualisiert werden. Es muss so strukturiert sein, dass im Falle von Sicherheitsvorfällen eine schnelle und vollständige Übersicht möglich ist. Zudem dürfen nur Lizenzen verwendet werden, die dem Einsatzzweck und den vertraglichen Bestimmungen entsprechen. Die Bereitstellung und Verfügbarkeit der Installationsdateien für die openDesk-Komponenten wird als zuverlässig und langfristig gesichert bewertet. Alle verwendeten Module - wie Nubus, CryptPad, xWiki, Nextcloud, Open-Xchange und OpenProject - stellen ihre Pakete über stabile, öffentlich zugängliche Open-Source-Repositories bereit. Diese werden regelmäßig aktualisiert, kryptografisch signiert und versioniert, sodass Integrität und Nachvollziehbarkeit jederzeit gewährleistet sind. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.6.A9 ####### Betroffene Module:
Nubus, Cryptpad, xWiki, Nextcloud, Open-Xchange, OpenProject

(TMS1.05) Geregelte Außerbetriebnahme der Module
Bei der Außerbetriebnahme von Module ist eine enge Abstimmung zwischen IT-Betrieb und Fachverantwortlichen notwendig, um den Ablauf und die Information der Benutzenden zu regeln. Dabei wird geprüft, ob weiterhin funktionale Anforderungen bestehen und wie diese sichergestellt werden können. Ziel ist ein geordneter und sicherer Übergang, bei dem keine wichtigen Funktionen verloren gehen und Arbeitsprozesse ungestört weiterlaufen. So wird gewährleistet, dass Benutzende informiert bleiben und benötigte Funktionen weiterhin verfügbar sind. Für Nubus wird beispielsweise geprüft, welche abhängigen Dienste (Nextcloud, Element, OpenProject, OpenXchange) weiterhin eine zentrale Identitäts- und Provisionierungsfunktion benötigen und wie ein sicherer Übergang gewährleistet werden kann. Bei der Außerbetriebnahme von Nextcloud wird geprüft, wie Dateiablagen, Freigaben und eventuelle Collabora-Dokumente migriert werden können, sodass produktive Arbeitsabläufe ungestört weiterlaufen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.6.A12 ####### Betroffene Module:
Nubus, Cryptpad, xWiki, Nextcloud, Open-Xchange, OpenProject

(TMS1.06) Festlegung einer Sicherheitsrichtlinie und Sicherheitsorientierte Systemarchitekturplanung
Eine Sicherheitsrichtlinie ist notwendig, um klare Verantwortlichkeiten und verbindliche Sicherheitsmaßnahmen festzulegen. Ohne definierte Vorgaben besteht ein erhöhtes Risiko für Manipulationen, Datenverlust oder Reputationsschäden. Die Richtlinie dient als Grundlage für ein konsistentes und nachvollziehbares Sicherheitsmanagement. Die Umsetzung erfolgt durch die Erstellung eines strukturierten Dokuments, das Zuständigkeiten, Schutzmaßnahmen und Reaktionsprozesse bei Sicherheitsvorfällen definiert. Aktuelle Sicherheitsinformationen sollen regelmäßig eingeholt und in die Richtlinie eingearbeitet werden. Die Richtlinie ist periodisch zu prüfen und an neue Bedrohungslagen anzupassen. Für Nextcloud regelt sie den Umgang mit Dateiablagen, Freigaben, Storage-Integrationen und den Schutz der WebDAV-Schnittstellen. Die Richtlinie legt zudem fest, wie E2E-Dienste wie CryptPad betrieben werden, einschließlich Vorgaben zur Schlüsselverwaltung, zum Schutz sensibler Inhalte und zum sicheren Export von Daten. Für xWiki beschreibt sie, wie Skriptermöglichkeiten, Makros und Zugriffsrechte gehärtet und nur für berechtigte Rollen freigeschaltet werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.2.A9, APP.3.1.A8, APP.5.4.A1, APP.5.4.A2, APP.3.2.A18, APP.6.A10, OPS.1.1.1.A11, OPS.1.1.1.A5, OPS.1.1.4.A1, OPS.1.1.7.A1, OPS.1.1.7.A2, SYS.1.1.A11, SYS.2.1.A9, SYS.2.1.A20, SYS.2.1.A33 ####### Betroffene Module:
xWiki, Cryptpad, Collabora, Element, Jitsi, Nexcloud, Nubus, OpenProject, OpenXchange

(TMS2.01) Protokollierung, Überwachung und Prüfung der Module
Die Protokollierung stellt sicher, dass sicherheitsrelevante Ereignisse erkannt und analysiert werden können. Ohne regelmäßige Prüfungen und Revisionen könnten Sicherheitslücken unentdeckt bleiben und die Stabilität der Module gefährden. Eine strukturierte Auswertung der Protokolle und die Nachverfolgung von Abweichungen stärken Transparenz und Sicherheit. Die Systemzeit aller IT-Systeme und Anwendungen, die Protokolle erzeugen, muss stets synchronisiert sein. Ebenso muss sichergestellt werden, dass Datum und Zeit in allen Protokolldateien einheitlich formatiert sind. Zur Echtzeitanalyse sollten die Protokollierungsdaten in kurzen Zeitabständen zentral von den protokollierenden IT-Systemen und Anwendungen übertragen und gespeichert werden. Die zentrale Protokollierung sollte eine ganzheitliche Auswertung über den gesamten Informationsverbund ermöglichen. Systeme oder Anwendungen, die keine zentrale Protokollierung unterstützen, sollten bei erhöhtem Schutzbedarf nicht eingesetzt werden. Alle im Rahmen der Protokollierung durchgeführten Sicherheitsüberprüfungen und Revisionen sollten dokumentiert, geschützt und dem Informationssicherheitsbeauftragten vorgelegt werden. Auffälligkeiten sind nachvollziehbar zu analysieren und durch geeignete Maßnahmen zur Risikominimierung zu beheben ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.2.A4, APP.3.2.A16, OPS.1.1.1.A20, OPS.1.1.1.A24, OPS.1.1.2.A18, OPS.1.1.2.A28, OPS.1.1.2.A29, OPS.1.1.2.A30, OPS.1.1.3.A5, OPS.1.1.3.A13, OPS.1.1.5.A4, OPS.1.1.5.A5, OPS.1.1.5.A11, OPS.1.1.7.A2, OPS.1.1.7.A3, SYS.1.1.A10, SYS.1.1.A23, SYS.1.1.A27, SYS.2.1.A29, SYS.2.1.A45 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(TMS2.02) Planung, Beschaffung und sichere Installation von Servern
Server sind zentrale und sicherheitskritische Bestandteile der IT-Infrastruktur. Eine unzureichende Planung oder fehlerhafte Konfiguration kann schwerwiegende Auswirkungen auf Verfügbarkeit, Integrität und Vertraulichkeit der gesamten Systemlandschaft haben. Werden Server ohne abgestimmte Plattformwahl, unklare Hardware-Dimensionierung oder fehlende Sicherheitsvorgaben installiert, können Fehlkonfigurationen und Schwachstellen entstehen, die von Angreifenden leicht ausgenutzt werden. Unzureichend geschulte Administratoren oder fehlende Standardisierung führen zu Konfigurationsabweichungen zwischen vergleichbaren Systemen (Konfigurationsdrift). Dies erschwert eine ganzheitliche Sicherheitsbewertung und erhöht das Risiko unentdeckter Schwächen. Vor dem Einsatz eines Servers muss eine umfassende Planung (Auswahl geeigneter Hardware- oder Virtualisierungsplattformen; Dimensionierung von Leistung, Speicher, Bandbreite; Festlegung der Kommunikationsschnittstellen und administrativen Zugänge; Definition der Anforderungen an Protokollierung, Datensicherung und Systemintegration, Stromversorgung, lokaler Paketfilter…) erfolgen. Vor der Beschaffung von Servern ist eine Anforderungsliste zu erstellen, anhand derer geeignete Produkte am Markt bewertet werden können. Die Installation und Konfiguration müssen in einer abgeschotteten Umgebung erfolgen, getrennt von Produktivsystemen. Mehrere kritische Rollen und Dienste sollten nicht auf demselben Server betrieben, sondern getrennt verteilt werden. Für Nubus müssen Server so dimensioniert werden, dass Authentifizierungs- und Provisionierungsvorgänge performant und hochverfügbar bereitgestellt werden. Nextcloud erfordert separate Server bzw. Cluster für PHP-Runtime, Webserver, Datenbanken und Storage-Backends, um Dateizugriffe, Freigaben und WebDAV-Verbindungen zuverlässig und skalierbar abzubilden. Für Open-Xchange (Mail, Kalender, Kontakte) sind beispielweise dedizierte Serverrollen notwendig, beispielsweise für IMAP/SMTP-Anbindungen, OX-Middleware und Datenbanken. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.1.A12, SYS.1.1.A13, SYS.1.1.A15, SYS.1.1.A16, SYS.1.1.A19, SYS.1.1.A21, SYS.1.1.A30, SYS.2.1.A31, SYS.2.1.A39 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(TMS2.03) Sicherheitsvorfallmanagement und Notfallplanung
Für jeden IT - Komponenten werden die notwendigen Notfallanforderungen definiert, beispielsweise zulässige Ausfallzeiten, Wiederanlaufprioritäten und Abhängigkeiten zu anderen Systemen. Basierend darauf werden Wiederanlauf- und Wiederherstellungspläne erstellt, die klare Verantwortlichkeiten, Kommunikationswege und technische Schritte zur Wiederinbetriebnahme enthalten. Passwörter, kryptografische Schlüssel und Systemzugänge werden sicher und revisionssicher hinterlegt, z.B. in einem verschlüsselten Passworttresor oder über ein zentrales Secret-Management-System. Die Notfallmaßnahmen (z.B. Backup-Wiederherstellung, Ersatzhardware, Virtualisierungs- oder Cloud-Fallback) werden regelmäßig getestet und dokumentiert, um ihre Wirksamkeit zu gewährleisten. Detaillierte Fehlermeldungen können vertrauliche Systeminformationen offenlegen und Angreifenden Hinweise auf Schwachstellen geben. Dies gefährdet die Integrität und Sicherheit des Servers und kann zu Angriffen oder Manipulationen führen. Eine kontrollierte Fehlerausgabe reduziert diese Risiken und gewährleistet einen stabilen Betriebszustand. Der Webserver wird so konfiguriert, dass nur allgemeine Fehlermeldungen ohne technische Details ausgegeben werden. Jede Fehlermeldung enthält ein eindeutiges Merkmal zur internen Nachvollziehbarkeit, während der des Webservers bei unerwarteten Fehlern automatisch in einen sicheren Zustand übergeht. Für jede openDesk-Komponente werden spezifische Notfallanforderungen festgelegt, darunter zulässige Ausfallzeiten, Wiederanlaufprioritäten und Abhängigkeiten zu anderen Diensten. Nubus erhält dabei eine besonders hohe Priorität, da Authentifizierung und Provisionierung für Nextcloud, Element, OpenProject und OpenXchange von diesem Dienst abhängen. Nextcloud, Open-Xchange und OpenProject definieren eigene Wiederanlaufreihenfolgen auf Basis ihrer Datenbanken und Anwendungsserver, während Echtzeitdienste wie Jitsi und Element zusätzliche Latenz- und Stabilitätsanforderungen besitzen. xWiki und Collabora folgen einer Wiederherstellungsstrategie, die sicherstellt, dass Wissensinhalte und Office-Dokumentbearbeitung zügig zur Verfügung stehen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.2.A12, SYS.1.1.A22, SYS.1.1.A25, SYS.2.1.A38 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(TMS2.04) Verfügbarkeit und Redundanz
Eine redundante Auslegung der IT- Komponenten gewährleistet die Verfügbarkeit und Stabilität auch bei technischen Ausfällen. Ohne Redundanz kann bereits ein einzelner System- oder Verbindungsfehler zu einem kompletten Dienstausfall führen. Redundanz minimiert Ausfallzeiten und stellt einen kontinuierlichen Betrieb sicher. Z. B. benötigt Nubus eine hohe Verfügbarkeit, da alle Dienste von seiner Authentifizierung und Provisionierung abhängen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.2.A15, APP.5.4.A11, APP.5.4.A12, OPS.1.1.2.A19, OPS.1.1.5.A13, SYS.1.1.A28 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(TMS3.01) Kontrolle aktiver Inhalte & externer Quellen

Dateien enthalten häufig aktive Inhalte wie Makros oder Skripte, die Schadsoftware einschleusen oder Systeme manipulieren können. Werden solche Inhalte automatisch ausgeführt, entsteht ein erhebliches Risiko für Datenverlust und Kompromittierung interner IT-Systeme. Auch externe Dokumente stellen eine Gefahr dar, wenn sie ungeprüft geöffnet werden. Fehlendes Bewusstsein bei Nutzenden führt zusätzlich dazu, dass unsichere Dateien leichtfertig ausgeführt werden. Module sollen so konfiguriert werden, dass aktive Inhalte nur aus vertrauenswürdigen Quellen ausgeführt werden können. Dokumente von extern müssen vor dem Öffnen auf Schadsoftware geprüft und problematische Dateiformate blockiert werden. Verdächtige Dateien sollten ergänzend in isolierten Umgebungen (z. B. Sandbox oder virtuelle Systeme) automatisch überprüft werden. Standardmäßig werden Dateien dabei nur in geschützten oder Ansichtsmodi geöffnet, um Risiken zu minimieren. Benutzende sollen regelmäßig geschult werden, um verdächtige Inhalte zu erkennen und Sicherheitsfunktionen korrekt zu nutzen.Beispiel: xWiki wird so konfiguriert, dass aktive Inhalte wie Skripte, Makros und serverseitige Codefragmente ausschließlich von vertrauenswürdigen Nutzerrollen ausgeführt werden können; Collabora wird so betrieben, dass Office-Makros und eingebettete Skripte nicht automatisch ausgeführt werden und nur signierte bzw. explizit freigegebene Makros zugelassen werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.1.1.A2, APP.1.1.A3, APP.1.1.A13, APP.1.1.A17, APP.3.2.A10, OPS.1.1.4.A10, OPS.1.1.4.A13, SYS.1.1.A37, SYS.2.1.A24, SYS.2.1.A27, SYS.2.1.A34 ####### Betroffene Module:
xWiki, Collabora, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(TMS3.02) Test & Freigabe von Software und Erweiterungen
Ungetestete Softwareversionen oder Add-ons können Sicherheitslücken verursachen oder die Stabilität von Systemen gefährden. Besonders Eigenentwicklungen durch Endbenutzende stellen ein Risiko dar, da sie oft ohne Freigabe oder Dokumentation eingesetzt werden. Fehlende Prüfverfahren erhöhen die Wahrscheinlichkeit für Fehlfunktionen und Schadcode-Infektionen. Software, Erweiterungen und Module müssen vor Einsatz in isolierten Testumgebungen überprüft werden. Dabei sind definierte Testpläne anzuwenden, die Kompatibilität und Sicherheit sicherstellen. Die Testfälle sind so zu gestalten, dass sie die zentralen Funktionen der Software umfassend abbilden und auch Fehlverhalten gezielt prüfen. Die Testumgebung sollte die in der Institution genutzten Systeme und Betriebssysteme realistisch nachbilden, um Kompatibilität und zuverlässige Funktion sicherzustellen. Werden für Softwaretests Produktivdaten eingesetzt, die schutzwürdige Informationen enthalten, so sind diese Testdaten angemessen zu sichern. Enthalten sie personenbezogene Daten, müssen diese mindestens pseudonymisiert werden. Wenn es technisch möglich und vertretbar ist, sollten die Daten vollständig anonymisiert werden, um jeglichen Personenbezug auszuschließen. Lässt sich ein Personenbezug dennoch nicht ausschließen oder ableiten, ist die Einbindung der Datenschutzbeauftragten sowie gegebenenfalls der Personalvertretung erforderlich. Für Softwares sollen verbindliche Richtlinien existieren, die Verantwortlichkeiten, Freigabeprozesse und Dokumentationspflichten regeln. Für OpenXchange werden beispielweise Updates des Groupware-Stacks, Add-ons und Integrationen (Mail, Kalender, Drive, Office) vor Produktivsetzung in einer realitätsnahen Testumgebung evaluiert. Testpläne prüfen Protokollkompatibilität, Nutzer-Workflows, API-Integrationen und die Stabilität der Collaboration-Funktionen. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.1.1.A6, APP.1.1.A10, APP.1.1.A11, CON.8.A7, OPS.1.1.6.A1, OPS.1.1.6.A2, OPS.1.1.6.A3, OPS.1.1.6.A4, OPS.1.1.6.A5, OPS.1.1.6.A10, OPS.1.1.6.A11, SYS.2.1.A30 ####### Betroffene Module:
xWiki, Collabora, Element, Nextcloud, Nubus, Openproject, OpenXchange, Cryptpad

(TMS3.03) Erweiterte Schutzmaßnahmen gegen Schadprogramme
Die Gefährdungslage zeigt, dass Schadprogramme immer komplexer werden und klassische Schutzmechanismen wie einfache Virenscanner häufig nicht ausreichen. Angreifende nutzen Softwareschwachstellen, manipulierte Webseiten oder gezielte Social-Engineering-Methoden, um Schadcode einzuschleusen. Besonders gefährlich sind Ransomware und maßgeschneiderte Schadprogramme, die herkömmliche Schutzsysteme umgehen. Auch über externe Datenträger oder vernetzte Geräte kann Schadsoftware in die Infrastruktur gelangen. Verdächtige Dateien werden in einer isolierten Analyseumgebung (Sandbox oder separate virtuelle Systeme) geprüft, bevor sie im Produktivnetz geöffnet werden. So kann Schadverhalten sicher erkannt werden, ohne Produktionssysteme zu gefährden. Für besonders kritische Systeme, wie E-Mail- oder Datei-Gateways, werden Virenschutzlösungen mit mehreren Scan-Engines eingesetzt, um die Erkennungsrate zu erhöhen und Schwächen einzelner Anbieter zu kompensieren. Externe Datenträger, insbesondere von Dritten, werden ausschließlich über eine Datenträgerschleuse mit aktueller Signaturprüfung und eingeschränkten Berechtigungen verbunden. Dadurch wird verhindert, dass infizierte Medien Schadsoftware ins interne Netz einbringen. Zusätzlich werden erweiterte Cyber-Sicherheitsprodukte geprüft und eingesetzt, z. B. Lösungen zur Prozesskapselung, Client-Härtung oder EDR-Systeme (Endpoint Detection & Response), die über die reine Signaturprüfung hinausgehen. Vor einer Einführung erfolgt eine Kompatibilitäts- und Wirksamkeitsprüfung in der Testumgebung. xWiki verarbeitet Dateien und eingebettete Inhalte, daher werden Uploads vor dem Import über Malware-Scanner mit Mehrfach-Engines geprüft und bei Verdacht automatisiert in einer Sandbox analysiert. OpenProject empfängt projektbezogene Dokumente und Dateien, die vor Speicherung durch mehrere Scan-Engines und bei Bedarf durch eine Sandbox analysiert werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
OPS.1.1.4.A10, OPS.1.1.4.A11, OPS.1.1.4.A12, OPS.1.1.4.A14, SYS.2.1.A6, SYS.2.1.A8, SYS.2.1.A32 ####### Betroffene Module:
xWiki, Collabora, Element, Nextcloud, Nubus, Openproject, OpenXchange, Cryptpad

(TMS4.01) Dokument- und Inhaltsintegrität
Manipulierte oder unverschlüsselte Dokumente gefährden Vertraulichkeit und Nachvollziehbarkeit. Ohne Schutz gegen Veränderungen oder Integritätsprüfung kann nicht sichergestellt werden, dass Inhalte echt und unverändert sind. Dokumente mit erhöhtem Schutzbedarf sollen gegen nachträgliche Änderungen geschützt, verschlüsselt gespeichert und digital signiert werden. Ergänzend sollten kryptografische Verfahren zur Integritätsprüfung eingesetzt werden, um Manipulationen zu erkennen und die Echtheit sicherzustellen. Beim Einsatz von Werkzeugen für das Änderungsmanagement ist sicherzustellen, dass Änderungen nachvollziehbar geplant, geprüft und gesteuert erfolgen. Die Werkzeuge müssen Unterbrechungs- oder Rücksetzpunkte (Rollback Points) unterstützen, damit fehlerhafte Änderungen automatisch gestoppt oder rückgängig gemacht werden können. Zusätzlich sollten Integritätsprüfungen und Protokollfunktionen eingesetzt werden, um Manipulationen oder unbeabsichtigte Änderungen frühzeitig zu erkennen und die Nachvollziehbarkeit des gesamten Prozesses zu gewährleisten. xWiki speichert und versioniert Dokumente zentral, daher werden Inhalte mit erhöhtem Schutzbedarf verschlüsselt abgelegt. Die integrierte Versionskontrolle wird so konfiguriert, dass Änderungen nur über nachvollziehbare, dokumentierte Freigabeprozesse erfolgen und Rollback-Funktionen jederzeit einsetzbar sind. Da Collabora Office-Dokumente verändert und speichert, werden Dateien mit hohem Schutzbedarf verschlüsselt abgelegt und über digitale Signaturen gegen unautorisierte Änderungen gesichert. Collabora unterstützt Rollback-Funktionen über die angebundenen Storage-Systeme, sodass fehlerhafte Bearbeitungen zurückgesetzt werden können. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.1.1.A14, APP.1.1.A15, APP.1.1.A16, APP.3.2.A2, APP.3.2.A3, APP.3.2.A14, OPS.1.1.3.A12, OPS.1.1.5.A10, OPS.1.1.5.A12, SYS.1.1.A34, SYS.1.1.A36, SYS.1.1.A38 ####### Betroffene Module:
xWiki, Collabora, CryptPad, Element, Nubus, Openproject, OpenXchange

(TMS5.01) Prüfung und kontinuierliche Sicherheitsbewertung der Module
Auch nach einer sicheren Implementierung können neue Schwachstellen auftreten. Unzureichende oder fehlende Testverfahren können dazu führen, dass Softwarefehler und Installationsprobleme unerkannt bleiben. Das Testen mit Produktivdaten kann ebenfalls zu Datenverlust oder Betriebsstörungen führen. Eine saubere, geplante Teststrategie stellt sicher, dass Tests repräsentativ, kontrolliert und getrennt von Produktivsystemen durchgeführt werden. Vor Testbeginn werden Rahmenbedingungen, Testumgebung, Testfälle und Verantwortlichkeiten klar definiert. Testende prüfen sämtliche Softwarefunktionen unter realistischen, jedoch isolierten Bedingungen. Penetrationstests und Revisionen werden regelmäßig durchgeführt; die Ergebnisse werden dokumentiert, geschützt und an den Informationssicherheitsbeauftragten (ISB) gemeldet. Element-Clients und Matrix-Serverkomponenten werden in getrennten Test- und Staging-Umgebungen geprüft, um Fehlfunktionen in Verschlüsselung, Geräteverifikation, Medienhandling und Synchronisationsprozessen frühzeitig zu erkennen. Penetrationstests betrachten insbesondere E2E-Krypto, Schlüsselverwaltung und Federation-Schnittstellen. Testdaten enthalten keine produktiven Kommunikationsinhalte. In Element – Modul “Olm/Megolm E2E Encryption” werden Integrität, Schlüsselaustausch und Federation-Reaktionen unter realitätsnahen, jedoch kontrollierten Bedingungen getestet. Die Nextcloud-Software wird im Rahmen der Entwicklung durch Hersteller getestet. Die OpenProject-Kernanwendung sowie die erstellten Container werden automatischen und manuellen Sicherheitstests unterzogen, um Schwachstellen idealerweise vor einem Software-Release zu identifizieren. Die OpenProject-Container werden regelmäßig gemäß dem Testleitfaden des Herstellers überprüft. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.3.1.A20, APP.3.1.A22, OPS.1.1.6.A1, OPS.1.1.6.A2, OPS.1.1.6.A7, OPS.1.1.6.A11, OPS.1.1.6.A12, OPS.1.1.6.A13, OPS.1.1.6.A16, APP.5.4.A3, OPS.1.1.1.A20, OPS.1.1.4.A10, SYS.1.1.A24, SYS.2.1.A43 ####### Betroffene Module:
xWiki, Collabora, CryptPad, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(TMS6.01) Separierung und Stabilität der Kubernetes-Umgebung
Pods können übermäßig Ressourcen beanspruchen und so ganze Nodes oder den Cluster destabilisieren. Ebenso können unberechtigte oder fehlerhafte Verbindungen zwischen Pods zu Angriffen auf Control Plane oder andere Anwendungen führen. Fehlt eine geplante Separierung, können Anwendungen mit unterschiedlichem Schutzbedarf auf demselben Cluster laufen, was die Folgen eines Angriffs vervielfacht. Laufen Pods zudem unbegrenzt, erhöht sich das Risiko, dass fehlerhafte oder kompromittierte Prozesse aktiv bleiben und Angriffe unbemerkt fortgesetzt werden. Die Trennung und regelmäßige Erneuerung der Pods begrenzen daher die Auswirkungen von Fehlkonfigurationen, Angriffen und Ressourcenkonflikten. Vor der Inbetriebnahme wird festgelegt, wie Anwendungen, Test- und Produktionsumgebungen voneinander getrennt werden. Auf Basis des Schutzbedarfs werden Architektur, Namespaces, Cluster- und Netzstruktur sowie CPU-, Speicher- und Netztrennung definiert und mit dem Netzzonenkonzept abgestimmt. Bei erhöhtem Risiko oder sehr hohem Schutzbedarf sind Pods regelmäßig neu zu starten, vorzugsweise innerhalb von 24 Stunden, um potenziell kompromittierte Laufzeitumgebungen zu bereinigen, ohne die Verfügbarkeit zu beeinträchtigen. Die Hersteller der openDesk-Komponenten (Cryptpad, Element, Collabora, Nextcloud, Nubus, OpenProject, OpenXchange, xWiki) stellen eine Dokumentation bereit, die die verwendeten Namespaces beschreibt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.4.4.A1, APP.4.4.A21 ####### Betroffene Module:
Cryptpad, Element, Collabora, Nextcloud, Nubus, OpenProject, OpenXchange, xWiki

(TMS7.01) Ende-zu-Ende-Sicherheit und Überwachung der Kommunikation
Unverschlüsselte Kommunikation und fehlende Überwachung erlauben Abhören oder Manipulation und verhindern die Erkennung von Angriffen. Alle Signalisierungs- und Mediendaten werden Ende-zu-Ende verschlüsselt. Zentrale UCC-Komponenten werden in das institutionelle Security-Monitoring eingebunden und Ereignisse in Echtzeit ausgewertet. Die openDesk-Komponenten verwenden TLS in der Version 1.2 und/oder 1.3. Die Hersteller der openDesk-Komponenten unterstützen die in der aktuellen Fassung der Technischen Richtlinie TR-02102-2 empfohlenen kryptografischen Verfahren und Algorithmen, die Perfect Forward Secrecy (PFS) gewährleisten. ####### IT-Grundschutz-Baustein ID-Anforderungen:
APP.5.4.A14, APP.5.4.A18, APP.3.2.A11, APP.5.4.A6, APP.5.4.A7, APP.5.4.A8, APP.5.4.A16, OPS.1.1.7.A4, SYS.2.1.A18, SYS.2.1.A23, OPS.1.1.1.A13, BDB.DP.SouvAP.05.A01, BDB.DP.SouvAP.05.A02 ####### Betroffene Module:
xWiki, Collabora, CryptPad, Element, Jitsi, Nextcloud, Nubus, Openproject, OpenXchange

(TMS7.02) Physische Sicherheit & Kryptohardware-Verfügbarkeit
Ein unautorisierter Zugriff auf Betriebsmittel kann zu Sicherheitslücken führen. Es müssen klare Zuständigkeiten und Verfahren zur Zugriffskontrolle festgelegt sowie zusätzliche Schutzmaßnahmen implementiert und regelmäßig überprüft und aktualisiert werden. Störungen oder Ausfälle technischer Komponenten können dazu führen, dass verschlüsselte Informationen nicht mehr entschlüsselt oder kryptografische Dienste nicht mehr bereitgestellt werden können. Dies gefährdet die Verfügbarkeit und Kontinuität der Geschäftsprozesse. Im Kryptokonzept ist festzuhalten, welche Ersatzgeräte und Betriebsmittel vorgehalten werden und nach welchem Verfahren ein Austausch im Bedarfsfall zu erfolgen hat. In der openDesk-Architektur gibt es eine zentrale Identity-Provider-(IdP)-Schicht, über die die Authentifizierung erfolgt. Für viele Komponenten - darunter OpenProject, Nextcloud und weitere Dienste - werden Authentifizierung und Single Sign-On (SSO) über diesen IdP (z. B. Keycloak oder die openDesk-IAM-Lösung) mittels OAuth2/OpenID Connect bereitgestellt. Wenn der IdP so konfiguriert ist, dass MFA (z. B. WebAuthn/Hardware-Token) für die Anmeldung erforderlich ist, profitieren alle nachgelagerten openDesk-Anwendungen, die ihre Authentifizierung über diesen IdP beziehen, ebenfalls von MFA. Dadurch kann die Anmeldung mit Hardware-Token in vielen oder sogar allen openDesk-Komponenten unterstützt werden - abhängig von der jeweiligen Konfiguration. ####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.1.A11, CON.1.A16, CON.1.A17, CON.1.A18, OPS.1.1.1.A13, SYS.1.1.A1, SYS.1.1.A5, SYS.2.1.A21, SYS.2.1.A28 ####### Betroffene Module:
xWiki, Collabora, CryptPad, Element, Nubus, OpenProject, OpenXchange, Nextcloud

(TMS7.03) Sicheres Design, vertrauenswürdige Komponenten und Bedrohungsmodellierung
Unsichere Entwicklungswerkzeuge, ungeprüfte externe Bibliotheken und ein mangelhaftes Systemdesign zählen zu den zentralen Ursachen für Sicherheitslücken in Anwendungen. Fehlerhafte oder unvalidierte Eingaben, unsichere Standardkonfigurationen und unzureichende Protokollierung können die Integrität und Vertraulichkeit der Daten gefährden. Auch nicht geprüfte externe Komponenten oder Bibliotheken aus unzuverlässigen Quellen erhöhen das Risiko von Schadcode, Supply-Chain-Manipulationen und Kompatibilitätskonflikten. Eine Bedrohungsmodellierung ermöglicht, Risiken frühzeitig zu erkennen und gezielt zu mitigieren. Durch die Analyse potenzieller Angriffsvektoren und Schwachstellen im Entwurf werden spätere Korrekturen und Sicherheitsvorfälle vermieden. Bereits in der Entwurfsphase wird ein strukturiertes Sicherheitskonzept umgesetzt. Alle Eingaben werden validiert, Datenübertragungen verschlüsselt und Programme mit minimalen Privilegien betrieben. Standardkonfigurationen sind sicher voreingestellt, Fehlermeldungen geben keine sensiblen Informationen preis, und sicherheitsrelevante Ereignisse werden protokolliert. Für die Entwicklung werden ausschließlich Werkzeuge mit nachgewiesenen Sicherheitseigenschaften eingesetzt. Externe Bibliotheken und Komponenten werden nur aus vertrauenswürdigen, signierten Quellen bezogen. Ihre Integrität wird durch kryptografische Prüfsummen oder Zertifikate nachgewiesen. In der Entwurfsphase wird zusätzlich eine Bedrohungsmodellierung durchgeführt. Auf Grundlage des Anforderungskatalogs und des Schutzbedarfs werden potenzielle Bedrohungen identifiziert, bewertet und in das Design eingearbeitet. Die Ergebnisse fließen in die Architektur- und Sicherheitsdokumentation ein und werden regelmäßig aktualisiert. xWiki setzt strikte, rechtebasierte Richtlinien ein, um unsichere Inhalte wie Skripte oder aktives HTML zu verhindern. Nextcloud bietet die umfangreichsten Schutzmechanismen gegen unzuverlässige Quellen, darunter App-Signaturen (nur signierte Apps und Plugins sind zugelassen), MIME- und Dateiscans mit Antivirus-Integration (ClamAV), Prüfungen auf unsichere externe Speicher oder untrusted Shares, Content Security Policies (CSP) zur Blockierung externer Inhalte sowie ausschließlich signierte Updates aus vertrauenswürdigen Kanälen. OpenProject verwendet vor allem offizielle, geprüfte Plugin-Signaturen aus dem Marketplace und setzt eingeschränkte Upload-Richtlinien (Dateiformate und MIME-Validierung) ein. Collabora Online öffnet ausschließlich Dateien aus vertrauenswürdigen Nextcloud- oder openDesk-Quellen und verwendet signierte Container des Herstellers. ####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.8.A5, CON.8.A6, CON.8.A8, CON.8.A17, CON.8.A18, CON.8.A19, CON.8.A20, CON.8.A21, APP.5.4.A2, APP.3.2.A18, APP.6.A11, OPS.1.1.1.A14, OPS.1.1.1.A7, OPS.1.1.3.A6, OPS.1.1.7.A2, SYS.2.1.A10, SYS.2.1.A11 ####### Betroffene Module:
xWiki, Collabora, CryptPad, Element, Nubus, OpenProject, OpenXchange, Nextcloud

(TMS7.02) Sicherheitsaudits & Integritätsprüfung der Entwicklungsumgebung
Eine unzureichend geschützte Entwicklungsumgebung kann manipuliert werden, ohne dass dies bemerkt wird. Fehlende Zugriffskontrollen oder Integritätsprüfungen führen zu unbemerkten Änderungen am Quellcode oder an Build-Prozessen. Regelmäßige Audits und kryptografische Prüfungen sind erforderlich, um Manipulationen, Fehlkonfigurationen und Sicherheitslücken frühzeitig zu erkennen. Sicherheitsaudits prüfen regelmäßig Konfiguration, Zugriffsrechte und Softwarestände der Entwicklungs- und Testumgebungen. Integritätsprüfungen werden mit kryptografischen Verfahren durchgeführt, Prüfsummen und Tools sind manipulationsgeschützt. Auffälligkeiten werden dokumentiert und unverzüglich analysiert. Alle openDesk-Komponenten werden unter Verwendung externer Bibliotheken entwickelt, die aus den originalen Registries heruntergeladen werden. Vor der Auswahl einer Bibliothek oder eines Pakets wird jede Abhängigkeit einer separaten Prüfung unterzogen (einschließlich bestehender Schwachstellen, Aktivitätsgrad, Größe der Community usw.). Darüber hinaus werden diese Abhängigkeiten und Bibliotheken regelmäßig auf bekannte und veröffentlichte Schwachstellen überprüft und im Rahmen der monatlichen Wartungs-Releases aktualisiert, sofern neue Versionen verfügbar sind, die entsprechende Sicherheitslücken beheben. ####### IT-Grundschutz-Baustein ID-Anforderungen:
CON.8.A6, CON.8.A18, CON.8.A19, CON.8.A20, CON.8.A22 ####### Betroffene Module:
xWiki, Collabora, CryptPad, Element, Nubus, OpenProject, OpenXchange, Nextcloud

(TMS8.01) Verhinderung von initialen Angriffsvektoren auf Linux/Unix-Servern
Wenn IT-Systeme automatisch auf Wechseldatenträger zugreifen, besteht die Gefahr, dass Schadprogramme oder manipulierte Daten unbemerkt auf das System gelangen. Ebenso kann Software aus Drittquellen fehlerhaft oder mit Schadfunktionen versehen sein. Durch Skriptumgebungen und das dynamische Laden von Bibliotheken können Angreifende Funktionen des Systems verändern oder missbrauchen. Auch das Ausspähen von System- und Benutzungsinformationen ist möglich, wenn keine ausreichenden Schutzmaßnahmen bestehen. Um diese Risiken zu vermeiden und die Integrität des Systems zu bewahren, ist es notwendig, die entsprechenden Maßnahmen konsequent umzusetzen. Wechseldatenträger dürfen nicht automatisch eingebunden werden, sondern nur nach bewusster Freigabe durch autorisierte Personen. Software, die installiert werden soll, darf nur unter einem unprivilegierten Konto entpackt, konfiguriert und übersetzt werden. Sie darf nicht unkontrolliert in das Wurzeldateisystem installiert werden. Die verwendeten Parameter sollen dokumentiert werden, damit die Installation jederzeit nachvollziehbar und reproduzierbar bleibt. Alle weiteren Installationsschritte sollen ebenfalls dokumentiert werden, um eine sichere und überprüfbare Systemumgebung zu gewährleisten. OpenProject, OpenXchange und xWiki stellen Richtlinien bzw. Dokumentationen bereit, die erläutern, wie sichergestellt wird, dass das Entpacken, Konfigurieren und Übersetzen von Software innerhalb von Containern ausschließlich unter einem nicht privilegierten Konto erfolgt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.3.A3, SYS.1.3.A5
####### Betroffene Module:
OpenProject, OpenXchange, xWiki

(TMS8.02) Konsistente Verwaltung von Benutzer- und Gruppenkennungen auf Linux/Unix-Servern
Eine unstrukturierte oder inkonsistente Vergabe von Benutzer- und Gruppenkennungen kann zu erheblichen Sicherheitsrisiken führen. Wenn identische Benutzer-IDs (UIDs) oder Gruppen-IDs (GIDs) mehrfach vorkommen, kann dies dazu führen, dass Benutzer unbeabsichtigt auf fremde Dateien oder Ressourcen zugreifen können. Bei vernetzten Systemen besteht zusätzlich die Gefahr, dass unterschiedliche Konten mit derselben UID oder GID verwechselt werden, was zu unautorisierten Zugriffen im Systemverbund führen kann. Um diese Risiken zu vermeiden und die Nachvollziehbarkeit sowie Integrität der Benutzerverwaltung sicherzustellen, müssen eindeutige und konsistente IDs vergeben und geeignete Verwaltungswerkzeuge genutzt werden. Jede Benutzerkennung und jede Gruppen-ID darf nur einmal im System existieren. Bei der Einrichtung neuer Konten ist sicherzustellen, dass die UID und GID eindeutig vergeben werden und dass jedes Konto mindestens einer Gruppe zugeordnet ist. Alle in der Datei /etc/passwd aufgeführten Gruppenkennungen müssen in der Datei /etc/group definiert sein. Gruppen sollten nur die Benutzer enthalten, die für die jeweilige Funktion zwingend erforderlich sind, um unnötige Rechteverteilungen zu vermeiden. Für die tägliche Administration sollten ausschließlich die vorgesehenen Verwaltungswerkzeuge verwendet werden. Eine direkte manuelle Bearbeitung der Dateien /etc/passwd, /etc/shadow, /etc/group und /etc/sudoers sollte vermieden werden, da dies zu Syntaxfehlern, Berechtigungsproblemen oder ungewollten Inkonsistenzen führen kann. Element, Nubus, Openproject, OpenXchange und xWiki stellen Vorgaben bzw. Dokumentationen für Container bereit, aus denen hervorgeht, dass innerhalb eines Containers jeder Login-Name, jede User-ID (UID) und jede Gruppen-ID (GID) nur einmal vorkommt. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.3.A2, SYS.1.3.A6
####### Betroffene Module:
Element, Nubus, Openproject, OpenXchange, xWiki

(TMS8.03) Schutz vor Ausnutzung von Schwachstellen auf Linux/Unix-Servern
Schwachstellen in Anwendungen und Betriebssystemkomponenten stellen eines der größten Risiken für Server dar, da sie Angreifenden ermöglichen können, Schadcode auszuführen, unberechtigten Zugriff zu erlangen oder Systemfunktionen zu manipulieren. Auch unverschlüsselte oder nur schwach gesicherte Netzwerkverbindungen stellen ein erhebliches Risiko dar: Bei der Verwendung unsicherer Protokolle können Anmeldedaten und Befehle im Klartext mitgelesen oder manipuliert werden. Darüber hinaus können nicht gehärtete Kernel-Varianten oder fehlende Schutzmaßnahmen im Speicher- und Dateisystembereich dazu führen, dass Angreifende selbst nach einer erfolgreichen Kompromittierung ihre Kontrolle im System ausweiten können. Auf allen Servern müssen die sicherheitsrelevanten Kernel-Mechanismen ASLR und DEP/NX aktiviert sein. Sicherheitsfunktionen des Kernels und der Standardbibliotheken, wie Heap- und Stackschutz, dürfen nicht deaktiviert werden. Zur Absicherung der Systemkommunikation soll ausschließlich Secure Shell (SSH) verwendet werden. Alle anderen Protokolle, deren Funktionalität durch SSH abgedeckt wird, sind vollständig zu deaktivieren. Für die Authentifizierung sollten bevorzugt Zertifikate oder Schlüsselpaare anstelle von Passwörtern eingesetzt werden, um Brute-Force- oder Phishing-Angriffe zu verhindern. Zusätzlich sollte der Kernel durch spezialisierte Härtungsmechanismen verstärkt werden. Die openDesk-Hersteller stellen Vorgaben, Richtlinien bzw. Dokumentationen bereit, die Schutzmaßnahmen zur Verhinderung der Ausnutzung von Schwachstellen auf Linux/Unix-Servern erläutern. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.3.A4, SYS.1.3.A8, SYS.1.3.A14, SYS.1.3.A17
####### Betroffene Module:
Element, Nubus, Openproject, OpenXchange, xWiki

(TMS8.04) Verhinderung der Ausbreitung bei der Ausnutzung von Schwachstellen in Anwendungen und Betriebssystemkomponenten
Wird eine Schwachstelle in einem Dienst oder einer Anwendung erfolgreich ausgenutzt, besteht die Gefahr, dass Angreifende ihre Kontrolle im System ausweiten und dadurch weitere Komponenten kompromittieren. Ohne geeignete Isolationsmechanismen können Angriffe aus einer einzelnen Anwendung heraus auf das gesamte Betriebssystem übergreifen. Dienste und Anwendungen sollten daher grundsätzlich innerhalb einer individuellen Sicherheitsarchitektur betrieben werden. Mechanismen wie AppArmor oder SELinux sind zu aktivieren und korrekt zu konfigurieren, um die Ausführung von Prozessen, den Zugriff auf Dateien sowie die Nutzung von Systemressourcen gezielt zu kontrollieren. Es ist sicherzustellen, dass die mitgelieferten Standardprofile oder -regeln aktiviert sind und die wesentlichen Schutzfunktionen abdecken. Für besonders exponierte oder sicherheitskritische Dienste empfiehlt sich der zusätzliche Einsatz von chroot-Umgebungen, LXC-Containern oder Docker-Containern, um die Auswirkungen eines Angriffs auf einen begrenzten Bereich zu beschränken. Dabei ist darauf zu achten, dass Containerumgebungen keine übermäßigen Berechtigungen besitzen und keine unnötigen Host-Ressourcen freigeben. Die Nutzung von Systemaufrufen sollte insbesondere bei öffentlich erreichbaren Diensten auf das unbedingt Notwendige reduziert werden. Standardprofile von AppArmor oder SELinux sind regelmäßig manuell zu prüfen und, falls erforderlich, an die unternehmensinternen Sicherheitsrichtlinien anzupassen. Wo nötig, sollten neue, spezifische Regeln oder Profile erstellt werden, um den Schutzgrad weiter zu erhöhen. Zusätzlich sind im Betriebssystem die sicherheitsrelevanten Schutzmechanismen ASLR und DEP/NX zu aktivieren, um die Ausnutzung von Speicherfehlern zu erschweren. Auf Systemen mit UEFI-Firmware ist der Startvorgang durch SecureBoot abzusichern. Das Trusted Platform Module (TPM) ist nur zu aktivieren, wenn es für die Systemarchitektur oder für kryptografische Funktionen tatsächlich benötigt wird. Die openDesk-Hersteller stellen Vorgaben, Richtlinien bzw. Dokumentationen bereit, die Schutzmaßnahmen zur Verhinderung der Ausbreitung bei der Ausnutzung von Schwachstellen in Anwendungen und Betriebssystemkomponenten erläutern. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.3.A10, SYS.1.3.A16, SYS.2.1.A26, SYS.2.1.A36 ####### Betroffene Module:
Element, Nubus, Openproject, OpenXchange, xWiki

(TMS09.01) Management von Container-Umgebungen:
Der Einsatz von Containern bringt erhebliche Vorteile in Bezug auf Skalierbarkeit, Effizienz und Flexibilität, gleichzeitig entstehen jedoch neue Sicherheitsrisiken. Container basieren häufig auf externen Images, deren Herkunft und Integrität nicht immer nachvollziehbar ist. Solche Images können verwundbare Software oder Schadprogramme enthalten, die sich durch Vervielfachung in vielen Instanzen schnell verbreiten. Ohne eine kontrollierte Verwaltung drohen unsichere administrative Zugänge, Ressourcenkonflikte, unautorisierte Kommunikation zwischen Containern sowie Datenverluste bei abruptem Herunterfahren. Auch der Verlust von Zugangsdaten durch unsichere Speicherung in Images oder Skripten gefährdet die Vertraulichkeit. Schließlich führt eine ungeordnete Bereitstellung und Verteilung von Images zu einem Verlust der Kontrolle über eingesetzte Softwarestände. Vor der Einführung von Containern sind Ziele und Anwendungsfälle (z. B. Skalierung, Sicherheit, CI/CD) festzulegen. Die Planung umfasst Installations-, Betriebs- und Abschaltprozesse, den Betriebsaufwand im Mischbetrieb sowie die Sicherheitsanforderungen an Host, Netzwerk und Verwaltung. Nur Anwendungen, die für den Container-Betrieb geeignet sind, dürfen eingesetzt werden. Die Verwaltung erfolgt ausschließlich über autorisierte Verwaltungssoftware, die den gesamten Lebenszyklus der Container abdeckt – von der Inbetriebnahme bis zur Außerbetriebnahme inklusive Updates. Der Prozess zur Bereitstellung und Verteilung von Images ist definiert und dokumentiert. Nur signierte und geprüfte Images aus vertrauenswürdigen Quellen dürfen verwendet werden. Änderungen erfordern eine automatische Validierung und eindeutige Versionskontrolle. Protokolldaten der Container müssen außerhalb des Containers, mindestens auf dem Host oder in zentralen Logsystemen, gespeichert werden. Eine verbindliche Betriebsrichtlinie legt fest, welche Images, Sicherheitsstandards und Update-Prozesse zulässig sind. Diese Richtlinie regelt auch den Umgang mit Sicherheitsvorfällen, das Logmanagement und Zugriffsbeschränkungen. Durch strukturierte Planung, zentrale Verwaltung, geprüfte Images, externe Logspeicherung und eine verbindliche Betriebsrichtlinie kann die Containerumgebung sicher, nachvollziehbar und stabil betrieben werden. Alle Entscheidungen werden dokumentiert, um spätere Anpassungen und Nachvollziehbarkeit zu gewährleisten. Die openDesk-Hersteller stellen Richtlinien - bei Bedarf zur Einsicht verfügbar - bereit, die beschreiben, wie Containerumgebungen verwaltet werden sollen, beispielsweise wie die Meldung von Sicherheitslücken erfolgt, wenn solche Schwachstellen vom Betreiber entdeckt werden. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.6.A1, SYS.1.6.A2, SYS.1.6.A4, SYS.1.6.A7, SYS.1.6.A9, SYS.1.6.A10 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

(TMS09.02) Sicherer Betrieb und Netztrennung von Container-Umgebungen:
Containerisierte IT-Systeme bringen neue Risiken durch mangelnde Isolation, fehlerhafte Netzkonfiguration und unzureichend getrennte Verwaltungszugänge mit sich. Werden Container und Host-Systeme nicht klar voneinander abgegrenzt, können Schwachstellen in einem Container genutzt werden, um in andere Container oder das Host-System einzudringen. Ebenso kann eine unzureichende Trennung von Verwaltungs- und Anwendungsnetzen zu Missbrauch von Administrationsrechten oder Datenabflüssen führen. Für den sicheren Einsatz containerisierter IT-Systeme muss geprüft werden, wie sich die Containerisierung auf bestehende Anwendungen und Systeme auswirkt. Auf Grundlage des Schutzbedarfs der Anwendungen ist zu bewerten, ob die Isolation und Kapselung der Container sowie ihrer virtuellen Netze ausreichend gewährleistet sind. Dabei werden auch betriebssystemeigene Sicherheitsmechanismen einbezogen. Containerisierte Systeme müssen die Anforderungen an Verfügbarkeit, Performance und Datendurchsatz erfüllen; Leistungsüberwachung und Ressourcensteuerung sind kontinuierlich durchzuführen. Administrations- und Zugangsnetze sind zu trennen. Die Administration des Hosts darf ausschließlich aus einem dedizierten Administrationsnetz erfolgen. Für Container-Administration und Nutzerzugänge sind eigene logische Segmente zu definieren, sodass nur notwendige Kommunikationsbeziehungen zwischen den Netzen zugelassen sind. Die openDesk-Komponenten werden in gehärteten Docker-Containern ausgeliefert, die den branchenüblichen Best Practices für Isolation, unprivilegierte Ausführung und sichere Kapselung entsprechen. Die Container sind sicherheitsoptimiert und bewusst minimal gehalten, um die Wartung zu erleichtern. Alle betrieblichen Sicherheitsmaßnahmen – wie die Härtung des Container-Hosts, Netzwerkschutz und Sicherheitsprüfungen - müssen vom IT-Betrieb umgesetzt und überprüft werden. Gesundheitsprüfungen für Start und Laufzeit (Liveness und Readiness) sind bereits in den Helm-Charts der Komponenten enthalten und standardmäßig aktiviert. ####### IT-Grundschutz-Baustein ID-Anforderungen:
SYS.1.6.A3, SYS.1.6.A5 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

(TMS10.01) Sicherer Betrieb und Verwaltung von Keycloak:
Der Einsatz von Keycloak als zentrales Authentifizierungs- und Autorisierungssystem muss sorgfältig geplant und dokumentiert werden. Dabei sind insbesondere das Betriebsmodell (z.B. Container, Application Server), die anzubindenden Systeme, verwendete Protokolle (OIDC, SAML, Social Logins) sowie Verfahren für Backup und Recovery zu definieren. Die Dokumentation muss nachvollziehbar, aktuell und an die institutionellen Anforderungen angepasst sein. Administrative Schnittstellen und Konsolen dürfen nicht öffentlich im Internet verfügbar sein. Der Zugriff auf Endpunkte wie /auth/admin ist auf vertrauenswürdige IP-Adressen oder separate Ports zu beschränken. Zum Schutz vor Brute-Force-Angriffen sollte eine automatische Sperrung nach mehrfach fehlgeschlagenen Logins aktiviert werden. Gegen Clickjacking-Angriffe sind die HTTP-Header X-Frame-Options und Content-Security-Policy korrekt zu konfigurieren. Die gesamte Kommunikation zwischen Clients und Keycloak muss über TLS-verschlüsselte Verbindungen erfolgen. Weiterleitungs-URIs sind möglichst spezifisch zu konfigurieren, um Missbrauch durch gefälschte Clients zu verhindern. Access- und Refresh-Token sollten zeitlich begrenzt sein, um Risiken kompromittierter Sitzungen zu minimieren. Auch Authorization Codes dürfen nur wenige Sekunden gültig sein. Tokens sollen zudem nur notwendige Rollen und Berechtigungen enthalten, um den Schaden bei einer Kompromittierung zu begrenzen. Die Keycloak-Instanz ist in ein zentrales Monitoring- und Logmanagement einzubinden. Dabei sind Verfügbarkeit, Auslastung und Fehlerzustände kontinuierlich zu überwachen. Audit-Logs müssen aktiviert werden, um sicherheitsrelevante Aktivitäten wie mehrfache Login-Versuche zu erkennen. Für den produktiven Betrieb ist eine Hochverfügbarkeits-Architektur vorzusehen. Bei Virtualisierung oder Containerisierung sollen die Instanzen auf unterschiedlichen Hosts betrieben werden und automatische Neustart-Mechanismen (restart-on-failure) konfiguriert sein. Persistente User-Attribute sind als read-only zu definieren, um Manipulationen durch Benutzer oder Administratoren zu verhindern. In Umgebungen mit geringem Vertrauensniveau sollte die Token-Audience gezielt eingeschränkt werden, um Missbrauch von delegierten Rechten zu vermeiden. Nubus (Univention) wird als die IAM- und Portallösung für openDesk beschrieben, wobei Keycloak als der dafür vorgesehene Identity Provider (IdP) dient. Innerhalb von Nubus unterstützt Keycloak SAML und OpenID Connect für die Authentifizierung, integriert sich über das Lightweight Directory Access Protocol (LDAP) in das zentrale Verzeichnis und fungiert als zentraler Identity Provider für mehrere Dienste. Dies ermöglicht eine einheitliche Authentifizierung und reduziert die Notwendigkeit separater Anmeldedaten für einzelne Anwendungen. Die Integration “Nubus IAM / Directory Importer / Ad Hoc Provisioning” zeigt darüber hinaus, dass Benutzer- und Gruppenverwaltung, Provisionierung und Synchronisation in kontrollierter Weise durchgeführt werden können, wodurch ein sicheres Identity-Lifecycle-Management unterstützt wird. ####### IT-Grundschutz-Baustein ID-Anforderungen:
bB.0104.A1, bB.0104.A2, bB.0104.A3, bB.0104.A4, bB.0104.A5, bB.0104.A6, bB.0104.A7, bB.0104.A8, bB.0104.A9, bB.0104.A10, bB.0104.A11, bB.0104.A12, bB.0104.A13
####### Betroffene Module:
Nubus

(TMS10.02) Sicherer Einsatz von Transport Layer Security (TLS):
Ohne aktuelle TLS-Versionen und geprüfte kryptografische Verfahren besteht ein hohes Risiko, dass Kommunikationsverbindungen manipuliert, mitgelesen oder kompromittiert werden. Veraltete Protokolle wie SSLv3 oder TLS 1.0/1.1 gelten als unsicher, da sie keine ausreichende Verschlüsselung und Authentisierung mehr gewährleisten. Ebenso können schwache Cipher Suites oder fehlende Forward Secrecy den Schutz sensibler Daten gefährden. Insbesondere öffentliche Webserver und Schnittstellen, die TLS-Verbindungen über unsichere Netze bereitstellen, sind stark gefährdet. Fehlkonfigurationen oder der Einsatz nicht konformer Verfahren können zudem zu Reputationsverlusten, Compliance-Verstößen oder Datenschutzverletzungen führen. Die Institution muss TLS ausschließlich in den Versionen 1.2 oder 1.3 einsetzen. Ältere Versionen sind zu deaktivieren, und bei Neuanschaffungen ist die Kompatibilität zu TLS 1.3 sicherzustellen. Für alle Kommunikationsverbindungen – insbesondere zwischen Webservern, Clients und Anwendungen – sind nur vom BSI in der TR-02102-2 empfohlenen kryptografischen Verfahren zu verwenden, die die Eigenschaft Perfect Forward Secrecy (PFS) erfüllen. Webserver müssen sämtliche Verbindungen über HTTPS absichern, und es dürfen keine gemischten Inhalte (Mixed Content) ausgeliefert werden. Wird aus technischen Gründen von diesen Vorgaben abgewichen, muss die Abweichung begründet, bewertet, dokumentiert und im Risikomanagement behandelt werden. Bei nicht konformen TLS-Versionen oder kryptografischen Verfahren ist ein Risikobehandlungsprozess durchzuführen:Risiko identifizieren, bewerten und dokumentieren; Maßnahmen zur Reduzierung umsetzen; Restrisiko und Ablösungsplan festhalten und der Leitung zur Zustimmung vorlegen. Für Projekte des Bundes ist zusätzlich Authentisierung zu berücksichtigen. Die openDesk-Komponenten verwenden TLS in der Version 1.2 und/oder 1.3. Die Hersteller der openDesk-Komponenten unterstützen die in der aktuellen Fassung der Technischen Richtlinie TR-02102-2 empfohlenen kryptografischen Verfahren und Algorithmen, die Perfect Forward Secrecy (PFS) gewährleisten. ####### IT-Grundschutz-Baustein ID-Anforderungen:
BDB.DP.SouvAP.05.A01, BDB.DP.SouvAP.05.A02, BDB.DP.SouvAP.05.A03, BDB.DP.SouvAP.05.A04, BDB.DP.SouvAP.05.A05 ####### Betroffene Module:
Nubus, Cryptpad, Collabora, Element, Open-Xchange, OpenProject, xWiki

8. Risikoanalyse

Die hier dargestellte Risikoanalyse zielt darauf ab, potenzielle Sicherheitsrisiken und Schwachstellen zu identifizieren, zu bewerten und geeignete Maßnahmen zur Risiko-Mitigierung einzusetzen. Die Risikobewertung erfolgt in Anlehnung an den BSI-Standard 200-3. Dabei werden sowohl die Eintrittswahrscheinlichkeit als auch die mögliche Schadensauswirkung von identifizierten Risiken berücksichtigt, welche auf den zuvor dargestellten technischen und organisatorischen Schwachstellen basieren. Zur Risiko-Mitigierung werden sowohl technische als auch organisatorische Maßnahmen erfasst, siehe dazu Kapitel 6 & 7.

8.1. Erstellung einer Gefährdungsübersicht

In diesem Kapitel werden mögliche Gefährdungen mit dem Kürzel “GE” aufgelistet.

(GE01) Vendor-Lock-In
Die fehlende Verfügbarkeit von Standarddatenformaten oder Serviceschnittstellen beeinträchtigt die Daten- und Serviceportabilität. Dies kann zu erheblichen Problemen führen, wenn ein Anbieterwechsel oder eine Migration aus der internen IT-Umgebung erforderlich wird.

(GE02) Unzureichende Kenntnis über Regelungen
Das bloße Festlegen von Regelungen stellt nicht sicher, dass diese auch eingehalten werden und einen reibungslosen Betrieb sicherstellen. Alle Mitarbeitenden, insbesondere die Leitenden, müssen die geltenden Regelungen kennen. Schäden, die durch Unkenntnis dieser Regelungen entstehen, dürfen nicht durch eigene Aussagen über Unwissenheit entschuldigt werden.

(GE03) Ausfall der Dienstverfügbarkeit
Ein Ausfall der Dienstverfügbarkeit kann durch verschiedene Ursachen wie Hardwarefehler, Softwarefehler, Netzwerkprobleme oder menschliches Versagen verursacht werden. Solche Ausfälle können zu erheblichen Betriebsunterbrechungen führen.

(GE04) Beendigung oder Ausfall von IT-Diensten
Wenn der IT-Anbieter aus dem Geschäft ausscheidet oder seine Dienste einstellt, kann dies dramatische Auswirkungen auf die Benutzerseite haben. Dies kann zu einem plötzlichen Verlust des Zugriffs auf wichtige Dienste und Daten führen. Die Folgen sind möglicherweise unter anderem erhebliche Betriebsunterbrechungen und finanzielle Verluste.

(GE05) Akquisition von IT-Anbietern
Die Übernahme eines IT-Anbieters könnte die Wahrscheinlichkeit eines strategischen Wandels erhöhen. Unverbindliche Vereinbarungen könnten gefährden sein, wie beispielsweise Softwareschnittstellen, Sicherheitsinvestitionen und außervertragliche Sicherheitskontrollen.

(GE06) Compliance-Kontrollverlust
Die Auslagerung IT-Bestandteile auf externe IT-Services kann sich auf die eigenen erworbenen Zertifizierungen und die von Dritten, sowie auf die gesetzlichen Anforderungen auswirken.

(GE07) Beeinflussung der geschäftlichen Reputation durch Aktivitäten andere Nutzende
Die Nutzung gemeinsamer virtueller Ressourcen und virtueller Infrastrukturen kann zu einer Beeinträchtigung der Dienste führen. Besonders bei böswilligen Aktivitäten bei einem einzigen Konsumenten.

(GE08) Unbeeinflussbare Änderungen in der Lieferkette
Wenn ein IT-Betrieb spezialisierte Aufgaben an externe Dienstleister auslagert, kann das Sicherheitsniveau des gesamten Systems von der Sicherheit dieser Drittanbieter abhängen. Jede Schwachstelle bei einem externen Partner kann die Sicherheit des IT-Betriebs gefährden.

(GE09) Ineffizientes Management der virtuellen Ressourcen
Ineffizientes Ressourcenmanagement kann zu erheblichen Problemen führen. Eine Unterbereitstellung von Ressourcen kann die Leistung und Verfügbarkeit der Dienste beeinträchtigen, während eine Überbereitstellung die Wirtschaftlichkeit und Reputation beeinträchtigen kann.

(GE10) Versagen der Mandantenfähigkeit
Die Nutzung gemeinsamer virtueller Rechen-, Speicher- und Netzwerkkapazitäten in einer mandantenfähigen Umgebung bedeutet, dass mehrere Benutzer dieselben Ressourcen teilen. Wenn die Mechanismen zur Trennung dieser Ressourcen versagen, kann dies die Verfügbarkeit und Vertraulichkeit der Daten jedes einzelnen Benutzers direkt beeinträchtigen.

(GE11) Missbrauch von Rollen und Rechten
Bei Ausführung bösartiger Aktivitäten ausführt kann sich dies auf sämtliche Daten, Dienste und die Reputation des Unternehmens auswirken.

(GE12) Datenabgriff während der Übermittlung
In einer verteilten Architektur erfolgt der Datentransfer zwischen verschiedenen IT-Komponenten, besonders wenn externe IT-Infrastrukturen genutzt werden. Es besteht die Gefahr, dass Daten während der Übertragung abgefangen und kompromittiert werden.

(GE13) Datenabgriff bis hin zum Verlust beim Hoch-/Herunterladen innerhalb der IT-Infrastruktur
Bei einem Datentransfer zwischen IT-Anbieter und Benutzer zwischen verschiedenen IT-Komponenten besteht die Gefahr, dass Daten während der Übertragung abgefangen und kompromittiert werden.

(GE14) Distributed denial of service (DDoS)
Erreichbare Schnittstellen zum Internet macht die Umgebung anfällig für Denial-of-Service-Angriffe.

(GE15) Verlust von Schlüsseln zur Verschlüsselung
Unbefugtes Erlangen von geheimen Schlüsseln (wie SSL) oder Passwörtern durch Dritte, sowie die Gefahr des Verlusts oder der Beschädigung dieser Schlüssel, was ihre Funktion zur sicheren Authentifizierung und digitalen Signatur beeinträchtigen kann.

(GE16) Anforderungsdifferenzen an die IT-Umgebung und die der Benutzer
Das Versagen von Benutzer, ihre Umgebungen ordnungsgemäß zu schützen, kann eine Schwachstelle für die IT-Plattform darstellen, wenn der IT-Anbieter nicht die notwendigen Schritte zur Isolierung unternommen hat. Dazu zählt auch eine unklare Definition der Anforderungen.

(GE17) Datenschutzrisiken
Als Datenschutzverantwortlicher kann eine Überprüfung der Datenverarbeitungsprozesse des IT-Anbieters herausfordernd sein. Neben Gefahr von Datensicherheitsverletzungen, besteht die Gefahr die Meldepflicht zu verletzen.

(GE18) Lizenzrisiken
Lizenz und dessen Bedingungen können in einer IT-Umgebung unbrauchbar werden.

(GE19) Unbefugte Berechtigungsausweitung
Fehlkonfigurationen von Rollen und Zugriffsrechten, fehlende Software-Updates oder unbekannte Schwachstellen können dazu führen, dass Benutzerrechte ungewollt ausgeweitet werden.

(GE20) Angriffe durch Social Engineering
Durch Social Engineering können Angreifer sensible Zugangsdaten wie Benutzernamen und Passwörter erlangen. Typische Angriffsstrategien beinhalten das Täuschen von Opfern, indem sie sich als vertrauenswürdige IT-Mitarbeiter oder Vorgesetzte ausgeben, um vertrauliche Informationen zu sammeln.

(GE21) Gefährdung und Verlust von Log-Daten
Ohne vollständige und unverfälschte Log-Daten wird es schwierig, Sicherheitsvorfälle zu identifizieren, zu analysieren und darauf zu reagieren. Dies kann die Fähigkeit zur Aufrechterhaltung der Systemintegrität und zur Durchführung von Audits erheblich einschränken.

(GE22) Verlust oder Gefährdung von Sicherheitsprotokollen
Sicherheitsprotokolle sind unter anderem für die forensische Untersuchung von Sicherheitsvorfällen unerlässlich. Der Verlust oder die Kompromittierung dieser Protokolle könnte die Fähigkeit zur effektiven Untersuchung und Reaktion auf Sicherheitsvorfälle erheblich behindern.

(GE23) Verlust oder Diebstahl von Backups
Gestohlene oder verlorene Backups können zu einem vollständigen Datenverlust führen, insbesondere wenn die Daten nicht verschlüsselt sind. Angreifer könnten erpressen und sensible Informationen kompromittieren.

8.2. Risikobewertung

Das in diesem Sicherheitskonzept angewendete Verfahren zur Bewertung der Risiken lehnt sich an den BSI-Standard 200-3 an und umfasst demnach bei der Bewertung zum einen die Eintrittswahrscheinlichkeit und zum anderen die mögliche Schadensauswirkung.

Die X-Achse spiegelt die Eintrittshäufigkeit wider, welche in vier Häufigkeiten kategorisiert ist. Diese Kategorien bieten eine Grundlage zur Bewertung der Eintrittswahrscheinlichkeit eines Risikos.

Selten: Das Risiko tritt sehr unwahrscheinlich und selten auf.
Mittel: Das Risiko ist möglich und kann gelegentlich auftreten.
Häufig: Das Risiko ist wahrscheinlich und tritt häufig auf.
Sehr häufig: Das Risiko ist sehr wahrscheinlich und tritt sehr häufig auf.

Die Y-Achse ist auch in vier Kategorien unterteilt, die die Auswirkungen des Risikos einordnen.

Vernachlässigbar: Die Schadensauswirkungen sind so gering, dass sie vernachlässigt werden können.
Begrenzt: Die Auswirkungen des Schadens sind begrenzt und kontrollierbar.
Beträchtlich: Die Auswirkungen des Schadens können umfangreich sein.
Existenzbedrohend: Die Auswirkungen des Schadens können existenziell bedrohlich und essenziell sein.

Die Risikoeinstufung ist das Ergebnis aus der Kategorie der Eintrittshäufigkeit und Auswirkungen. Die Risikokategorien helfen, die Bedrohungsgrade und die Wirksamkeit der vorgesehenen Sicherheitsmaßnahmen zu bewerten. Folgende Risikoeinstufungen sind bestimmt:

gering: In der Praxis werden geringe Risiken akzeptiert und weiter beobachtet. Die bisher realisierten oder im Sicherheitskonzept vorgesehenen Maßnahmen ermöglichen einen angemessenen Schutz.
mittel: Eventuell bieten die implementierten oder im Sicherheitskonzept vorgesehenen Maßnahmen nicht genügend Schutz.
hoch: Keinen hinreichenden Schutz gegen die jeweilige Bedrohung bieten die umgesetzten oder im Sicherheitskonzept geplanten Sicherheitsmaßnahmen.
sehr hoch: Keinen ausreichenden Schutz vor der jeweiligen Gefährdung bieten die bereits umgesetzten oder zumindest im Sicherheitskonzept vorgesehenen Sicherheitsmaßnahmen.

Für die Analyse gelten folgende Bewertungskriterien:

Eintrittshäufigkeit / Auswirkungen	selten	mittel	häufig	sehr häufig
vernachlässigbar	gering	gering	gering	gering
begrenzt	gering	mittel	mittel	hoch
beträchtlich	mittel	mittel	hoch	sehr hoch
existenzbedrohend	hoch	hoch	sehr hoch	sehr hoch

8.3. Behandlung der Risiken

Die Behandlung der Risiken umfasst die systematische Identifikation und Bewertung potenzieller Bedrohungen sowie die Entwicklung geeigneter Gegenmaßnahmen. Dabei fließen sowohl organisatorische als auch technische Maßnahmen mit ein. Eine detaillierte Auflistung der Maßnahmen zur Risikobehandlung werden in Kapitel 7 & 6 aufgelistet.

(GE01) Vendor-Lock-In

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	existenzbedrohend
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS27) Vertraulichkeitsvereinbarungen (NDA)
Betroffene Assets	(AS01) Infrastruktur
Gesamtrisiko	hoch
Maßnahmen	(OM01.01) Einhaltung Sicherheitskonzept (OM03.03) Asset Management (OM03.05) Open-Source (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (TM01.01) Ressourcen Management
Restrisiko	gering
Begründung	Die IT-Architektur basiert auf Modularität, Austauschbarkeit und Interoperabilität.

(GE02) Unzureichende Kenntnis über Regelungen

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	begrenzt
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS09) Provisionierung von Benutzern (OS10) De-Provisionierung von Benutzern (OS17) Unklarer Besitz von Assets (TS10) Unzureichende Sicherheit von Kubernetes-Umgebungen (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen
Betroffene Assets	(AS1.2) Backup- und Wiederherstellungssysteme (AS02) Anwendungen (AS03) Identity and Access Management
Betroffene Informationsdaten	(IO01) Protokollierungsdaten
Gesamtrisiko	mittel
Maßnahmen	(OM01.01) Einhaltung Sicherheitskonzept (OM05.01) Ticketsystem (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.05) Segregation von Tätigkeiten (OM08.01) Hintergrundüberprüfung (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.04) Vorfallmanagement (TM02.01) Charakteristiken der IaaS- und PaaS-Services (TM03.03) Common Vulnerabilities und Exposures (CVE) (TM04.06) Whitelisting (TM11.02) Sichere Konfiguration (Container) (TM11.03) Durchsetzung von Richtlinien (Container)
Restrisiko	gering
Begründung	Fortlaufende Schulungen und die Verfügbarkeit einer aktuellen und zugänglichen Dokumentation der Regelungen und Richtlinien sind zu gewährleisten, so dass alle Mitarbeiter über die notwendigen Kenntnisse verfügen.

(GE03) Ausfall der Dienstverfügbarkeit:

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	beträchtlich
Schwachstellen	(OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets (OS16) Fehlende oder unzureichende Klassifizierung der Assets (OS19) Unzureichendes Release und Deployment Management (OS20) Unzureichendes Configuration und Changemanagement (OS21) Mangelnder und ungetesteter Business Continuity und Disaster Recovery Plan (OS22) Planung von Ressourcen (OS23) Backup (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS08) Unsichere Mandantenfähigkeit (TS10) Unzureichende Sicherheit von Kubernetes-Umgebungen (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren (TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses (TS21) Automatisierte Überwachungstools (TS22) Unzureichende Schwachstellentests (TS23) Fehlende Implementierung einer Web Application Firewall (WAF) (TS23) Fehlende Implementierung einer Web Application Firewall (WAF) (TS26) Unzureichende Wartung
Betroffene Assets	(AS01) Infrastruktur (AS02) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM02.01) Integration in BCM/ITSCM (OM02.02) Prüfung Business Continuity Prozesse (OM03.01) Ressourcenplanung (OM03.02) Kapazitätsplanung (OM03.03) Asset Management (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM12.01): Staging Umgebung (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.03) Erkennung von Schwachstellen (OM15.01) Bestimmung der Akzeptanzniveaus (OM15.03) Informationen zu Sicherheitsproblemen (OM16.05) Wirkungsanalyse Service-Ausfall (OM17.04): Portabilität von Diensten gewährleisten (OM18.01) Image-Provenance (Container) (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.01) Ressourcen Management (TM01.02) Patch Management (TM03.01) Härtung (TM03.02) Härtung (Kubernetes) (TM04.01) Zentrales Logging und Monitoring (TM04.03) Logging, Monitoring & Auditing (Kubernetes) (TM04.06) Whitelisting (TM05.01) Mandantentrennung und Multi-Mandantenfähigkeit (TM07.01) Hochverfügbarkeit (TM07.02) Kubernetes Resilienz (TM08.01) Generelle Netzwerksicherheit (TM11.01) Härtung der Anwendungscontainer (Container) (TM11.02) Sichere Konfiguration (Container) (TM11.04) Host-basierte Angriffserkennung (Container) (TM11.05) Vorsorge für Untersuchungen (Container) (TM11.07) Hochverfügbarkeit von containerisierten Anwendungen (Container) (TM12.02) Durchsetzung von Richtlinien (Kubernetes) (TM12.03) Kubernetes Nodes (TM12.04) Automatisierung und Versionskontrolle
Restrisiko	gering
Begründung	Hochverfügbarkeitslösungen und kontinuierliche Überwachung der Systeme gewährleisten eine schnelle Wiederherstellung der Dienstverfügbarkeit im Falle eines Ausfalls.

(GE04) Beendigung oder Ausfall von IT-Diensten

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	existenzbedrohend
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS21) Mangelnder und ungetesteter Business Continuity und Disaster Recovery Plan (OS23) Backup (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS26) Management von Drittanbieter-Ressourcen (TS21) Automatisierte Überwachungstools (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS1.2) Backup- und Wiederherstellungssysteme (AS03) Identity and Access Management
Gesamtrisiko	hoch
Maßnahmen	(OM02.01) Integration in BCM/ITSCM (OM03.03) Asset Management (OM06.01) Datensicherung (OM06.02) Zuverlässigkeit von Backups durch regelmäßige Prüfung (OM06.03) Sicherung von Produktionsdaten (OM06.04) Physisch getrennte Backup-Speichermedien (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM06.07) Absicherung der Wiederherstellbarkeit von Backups (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.04) Service Level Agreements mit Dienstleister (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (TM04.06) Whitelisting (OM17.02) Änderung und Aktualisierung von Diensten (OM17.03) Dienstdokumentation (OM17.04) Portabilität von Diensten gewährleisten (OM18.01) Image-Provenance (Container) (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM09.01) Tests von Backup und Wiederherstellung (TM11.05) Vorsorge für Untersuchungen (Container)
Begründung	Geordnete Prozesse bei Beendigung von Diensten, sowie die Portabilität, Flexibilität und Backup-Funktionalitäten stellen den Betrieb auch bei beendeten oder ausgefallenen IT-Dienste wieder.
Restrisiko	gering

(GE05) Akquisition von IT-Anbietern

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS21) Mangelnder und ungetesteter Business Continuity und Disaster Recovery Plan (OS23) Backup (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS26) Management von Drittanbieter-Ressourcen (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS01) Infrastruktur (AS02) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.01) Datensicherung (OM06.02) Zuverlässigkeit von Backups durch regelmäßige Prüfung (OM06.03) Sicherung von Produktionsdaten (OM06.07) Absicherung der Wiederherstellbarkeit von Backups (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.04) Service Level Agreements mit Dienstleister (OM17.02) Änderung und Aktualisierung von Diensten (OM17.03) Dienstdokumentation (OM17.04) Portabilität von Diensten gewährleisten (OM17.05) Migration von Anwendungen (TM02.01) Charakteristiken der IaaS- und PaaS-Services (TM07.03) Replikation von Daten (TM08.05) Dienst- und Anwendungstrennung
Restrisiko	gering
Begründung	Definierte Service Level Agreements, geordnete Prozesse bei Änderungen von Diensten, sowie die Portabilität, Flexibilität und Backup-Funktionalitäten sichern den Betrieb auch bei geänderten Umständen beim IT-Anbieter.

(GE06) Compliance-Kontrollverlust

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	begrenzt
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS06) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS26) Management von Drittanbieter-Ressourcen (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren
Betroffene Assets	(AS01) Infrastruktur (AS02) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM01.01) Einhaltung Sicherheitskonzept (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM04.01) Bestimmung von Nutzungsbedingungen (TM04.06) Whitelisting (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.01) Hintergrundüberprüfung (OM08.02) Vergabe von Zugriffsrechten (OM09.02) Aktivitätenerfassung abstimmen (OM09.04) Speicherung und Zugriff auf Identitäten (OM11.01) Outsourcing (OM11.02) Autorisierung von Dienstleistern (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.03) Schulung des Betriebs und der Administration (OM15.04) Verstoß gegen Sicherheitsrichtlinien (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM08.05) Dienst- und Anwendungstrennung
Restrisiko	gering
Begründung	Die Gefahr des Kontrollverlustes über die eigene Compliance wird eingedämmt, indem einerseits organisatorische Absicherungen vereinbart sind. Andererseits sorgen technische Maßnahmen dafür nur bestimmte Bereiche angesteuert werden können und zudem eine Protokollierung von Zugriffen erfolgt.

(GE07) Beeinflussung der geschäftlichen Reputation durch Aktivitäten anderer Nutzende

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	beträchtlich
Schwachstellen	(OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS09) Provisionierung von Benutzern (OS10) De-Provisionierung von Benutzern (OS11) Zugriffskontrollen (TS08) Unsichere Mandantenfähigkeit (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren
Betroffene Assets	(AS01) Infrastruktur (AS02) Anwendungen (AS03) Identity and Access Management
Gesamtrisiko	mittel
Maßnahmen	(OM03.01) Ressourcenplanung (OM03.02) Kapazitätsplanung (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM04.01) Bestimmung von Nutzungsbedingungen (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern (OM07.08) Kontenverwaltung (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.02) Vergabe von Zugriffsrechten (OM08.03) Standardisierter Abstimmungsprozess von Zugriffsrechten (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen (OM09.02) Aktivitätenerfassung abstimmen (OM09.04) Speicherung und Zugriff auf Identitäten (OM10.01) Passwortsicherheit (OM13.03) Schulung des Betriebs und der Administration (OM14.02) Schwachstellenmanagement (OM14.03) Erkennung von Schwachstellen (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM15.06) Statuskommunikation (TM01.01) Ressourcen Management (TM02.01) Charakteristiken der IaaS- und PaaS-Services (TM05.01) Mandantentrennung und Multi-Mandantenfähigkeit (TM05.02) Authentifizierung & Autorisierung (TM05.03) Benutzerauthentifizierung (TM05.05) User, Rollen und Rechte (Kubernetes) (TM05.06) Automations-User und personalisierte User (Kubernetes) (TM11.03) Durchsetzung von Richtlinien (Container) (TM11.08) Weitergehende Isolation und Kapselung (Container)
Begründung	Durch die Sicherstellung der technischen und organisatorischen Ressourcen-, und Kapazitätsplanung, Zugriffsverwaltung und der Benutzerzugriffe ist ein Risiko dahingehend mitigiert.
Restrisiko	gering

(GE08) Unbeeinflussbare Änderungen in der Lieferkette

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	begrenzt
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS26) Management von Drittanbieter-Ressourcen (TS04) Mangelhaftes & unsicheres Ressourcenmanagement
Betroffene Assets	(AS01) Infrastruktur (AS02) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.01) Hintergrundüberprüfung (OM08.02) Vergabe von Zugriffsrechten (OM09.02) Aktivitätenerfassung abstimmen (OM09.04) Speicherung und Zugriff auf Identitäten (OM11.02) Autorisierung von Dienstleistern (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.03) Schulung des Betriebs und der Administration (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM18.01) Image-Provenance (Container) (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM08.05) Dienst- und Anwendungstrennung
Restrisiko	gering
Begründung	Um unkontrollierbare Änderungen in der Lieferkette zu minimieren, wurden sowohl organisatorische als auch technische Maßnahmen vorgenommen. Die getroffenen organisatorische Maßnahmen bieten Absicherung auf nicht-technischer Ebene, während technische Vorkehrungen sicherstellen, dass nur bestimmte Bereiche zugänglich sind und alle Zugriffe protokolliert werden.

(GE09) Ineffizientes Management der virtuellen Ressourcen

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	begrenzt
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets (OS18) Ungeeignetes Vorgehensmodell für die Softwareentwicklung (OS22) Planung von Ressourcen (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung
Betroffene Assets	(AS01) Infrastruktur (AS1.2) Backup- und Wiederherstellungssysteme (AS02) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM03.01) Ressourcenplanung (OM03.02) Kapazitätsplanung (OM03.03) Asset Management (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.09) Benutzerdokumentation (OM09.02) Aktivitätenerfassung abstimmen (OM13.01) Änderungsdokumentation (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM17.01) Bereitstellung von Diensten (OM17.02) Änderung und Aktualisierung von Diensten (OM17.03) Dienstdokumentation (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.01) Ressourcen Management (TM01.03) Quotas, Request & Limits (Kubernetes) (TM04.01) Zentrales Logging und Monitoring (TM11.02) Sichere Konfiguration (Container)
Begründung	Durch die Sicherstellung der dedizierten Planung von virtuellen Ressourcen anhand des dokumentierten IT-Betriebs, sowie die technische Umsetzung der Dokumentation inkl. dedizierter Verantwortlichkeiten, sind virtuelle Ressourcen effizient gemanaged.
Restrisiko	gering

(GE10) Versagen der Mandantenfähigkeit

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	beträchtlich
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS08) Mangelndes Sicherheitsbewusstsein (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets (OS17) Unklarer Besitz von Assets (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS08) Unsichere Mandantenfähigkeit
Betroffene Assets	(AS01) Infrastruktur (AS1.2) Backup- und Wiederherstellungssysteme* (AS02) Anwendungen (AS03) Identity and Access Management
Gesamtrisiko	hoch
Maßnahmen	(OM03.03) Asset Management (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM14.03) Erkennung von Schwachstellen (OM15.06) Statuskommunikation (OM17.01) Bereitstellung von Diensten (OM17.02) Änderung und Aktualisierung von Diensten (OM17.03) Dienstdokumentation (TM01.01) Ressourcen Management (TM05.01) Mandantentrennung und Multi-Mandantenfähigkeit (TM11.03) Durchsetzung von Richtlinien (Container) (TM11.08) Weitergehende Isolation und Kapselung (Container)
Begründung	Das Versagen der Mandantenfähigkeit wir durch die Gestaltung von openDesk als SaaS-Lösung mitigiert.
Restrisiko	gering

(GE11) Missbrauch von Rollen und Rechten

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS09) Provisionierung von Benutzern (OS10) De-Provisionierung von Benutzern (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS17) Unklarer Besitz von Assets (OS28) Kundenmanagement (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS06) Unsichere Managementinterfaces (TS07) Unsichere Kommunikationskanäle (TS08) Unsichere Mandantenfähigkeit (TS15) Unzureichend gesicherter Einsatz von Entwicklungsumgebungen (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren (TS21) Automatisierte Überwachungstools (TS22) Unzureichende Schwachstellentests
Betroffene Assets	(AS01) Infrastruktur (AS1.2) Backup- und Wiederherstellungssysteme* (AS02) Anwendungen (AS03) Identity and Access Management
Gesamtrisiko	mittel
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern (OM07.08) Kontenverwaltung (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.01) Hintergrundüberprüfung (OM08.02) Vergabe von Zugriffsrechten (OM08.03) Standardisierter Abstimmungsprozess von Zugriffsrechten (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen (OM09.02) Aktivitätenerfassung abstimmen (OM09.03) Speicherung und Löschung von Benutzerdaten (OM09.04) Speicherung und Zugriff auf Identitäten (OM10.01) Passwortsicherheit (OM11.02) Autorisierung von Dienstleistern (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.02) Schwachstellenmanagement (OM14.03) Erkennung von Schwachstellen (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM15.06) Statuskommunikation (TM01.01) Ressourcen Management (TM03.01) Härtung (TM04.04) Löschung von Protokolldaten (TM04.06) Whitelisting (TM05.02) Authentifizierung & Autorisierung (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM05.05) User, Rollen und Rechte (Kubernetes) (TM05.06) Automations-User und personalisierte User (Kubernetes) (TM06.02) Secret Verwaltung (TM06.03) Kubernetes Secret Management (TM11.02) Sichere Konfiguration (Container) (TM11.06) Unveränderlichkeit (Container) (TM10.03) Unverzügliche Passwortänderung nach Sicherheitsvorfällen (TM12.02) Durchsetzung von Richtlinien (Kubernetes) (TM12.04) Automatisierung und Versionskontrolle (TM12.06) Trennung und Sicherheit von Pods und Containern (TM13.01) Datenbanksysteme (TM13.02) Sicherheitsanforderungen an Webanwendungen
Begründung	Eine umfassende Rollen- und Rechtestruktur, sowohl auf organisatorischer als auch auf technischer, lässt den Missbrauch von Rollen und Rechten auf ein geringes Risiko eindämmen.
Restrisiko	gering

(GE12) Datenabgriff während der Übermittlung

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	existenzbedrohend
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen (OS20) Unzureichendes Configuration und Changemanagement (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS06) Unsichere Managementinterfaces (TS07) Unsichere Kommunikationskanäle (TS09) Fernzugriff auf die Managementoberfläche (TS10) Unzureichende Sicherheit von Kubernetes-Umgebungen (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen (TS14) Fehlende Input-Validierung (TS15) Unzureichend gesicherter Einsatz von Entwicklungsumgebungen (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren (TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses (TS21) Automatisierte Überwachungstools
Betroffene Assets	(AS1.2) Backup- und Wiederherstellungssysteme (AS02) Anwendungen (AS03) Identity and Access Management
Betroffene Informations daten	(IO01) Protokollierungsdaten
Gesamtrisiko	sehr hoch
Maßnahmen	(OM01.01) Einhaltung Sicherheitskonzept (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.02) Schwachstellenmanagement (OM14.03) Erkennung von Schwachstellen (OM14.04) Vorfallmanagement (OM15.02) Risikobewertungen (OM15.03) Informationen zu Sicherheitsproblemen (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.06) Statuskommunikation (OM15.07) Forensische Untersuchungen (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (OM16.04) Audit-Protokolle (OM18.01) Image-Provenance (Container) (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.02) Patch Management (TM03.01) Härtung (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM04.03) Logging, Monitoring & Auditing (Kubernetes) (TM04.06) Whitelisting (TM07.04) Cluster: Data-at-Rest Verschlüsselung (Kubernetes) (TM08.01) Generelle Netzwerksicherheit (TM08.02) Verschlüsselung des Kubernetes Netzwerks innerhalb der Cluster (TM08.03) Netzwerk Segmentierung (TM08.04) Netzwerk: Dokumentation, Betrieb und Sicherstellung (TM08.05) Dienst- und Anwendungstrennung (TM09.02) Verschlüsselung Backup (TM10.01) Regelmäßige Penetrationstests (TM10.02) Isolierung bei APT-Vorfällen (TM10.04) Sicherheitsbedingte Neuinstallation der Systeme (TM12.01) Container Plattform (Kubernetes) (TM12.05) Lebenszyklus eines Pods (TM12.06) Trennung und Sicherheit von Pods und Containern (TM13.01) Datenbanksysteme (TM13.02) Sicherheitsanforderungen an Webanwendungen
Begründung	Dedizierte getroffene organisatorische und technische Maßnahmen auf IaaS, PaaS und SaaS-Ebene mitigieren das Risiko des Datenabgriffs während der Übermittlung.
Restrisiko	gering

(GE13) Datenabgriff bis hin zum Verlust beim Hoch-/Herunterladen innerhalb der IT-Infrastruktur

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	existenzbedrohend
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS06) Unsichere Managementinterfaces (TS07) Unsichere Kommunikationskanäle (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS21) Automatisierte Überwachungstools
Betroffene Assets	(AS01) Infrastruktur (AS1.2) Backup- und Wiederherstellungssysteme (AS03) Identity and Access Management
Betroffene Informationsdaten	(IO01) Protokollierungsdaten
Gesamtrisiko	sehr hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.02) Schwachstellenmanagement (OM14.03) Erkennung von Schwachstellen (OM14.04) Vorfallmanagement (OM15.02) Risikobewertungen (OM15.03) Informationen zu Sicherheitsproblemen (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.06) Statuskommunikation (OM15.07) Forensische Untersuchungen (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (OM16.04) Audit-Protokolle (OM18.01) Image-Provenance (Container) (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.02) Patch Management (TM03.01) Härtung (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM04.03) Logging, Monitoring & Auditing (Kubernetes) (TM04.06) Whitelisting (TM07.04) Cluster: Data-at-Rest Verschlüsselung (Kubernetes) (TM08.01) Generelle Netzwerksicherheit (TM08.02) Verschlüsselung des Kubernetes Netzwerks innerhalb der Cluster (TM08.03) Netzwerk Segmentierung (TM08.04) Netzwerk: Dokumentation, Betrieb und Sicherstellung (TM09.02) Verschlüsselung Backup (TM10.01) Regelmäßige Penetrationstests (TM10.02) Isolierung bei APT-Vorfällen
Begründung	Der Informationsverbund wird auf einer ISO 27001 zertifizierten und C5 Testat-2 konformen Hyperscaler Umgebung betrieben.
Restrisiko	gering

(GE14) Distributed denial of service (DDoS)

Kategorie	Wert
Eintrittswahrscheinlichkeit	sehr häufig
Auswirkung	beträchtlich
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (TS05) Fehlende Ressourcenisolierung (TS13) Unzureichende Sicherheit von Applikationen (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren (TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses (TS22) Unzureichende Schwachstellentests (TS23) Fehlende Implementierung einer Web Application Firewall (WAF) (TS26) Unzureichende Wartung
Betroffene Assets	(AS02) Anwendungen
Gesamtrisiko	sehr hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.03) Erkennung von Schwachstellen (OM15.01) Bestimmung der Akzeptanzniveaus (OM15.02) Risikobewertungen (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.07) Forensische Untersuchungen (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.03) Quotas, Request & Limits (Kubernetes) (TM03.03) Common Vulnerabilities und Exposures (CVE) (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM08.04) Netzwerk: Dokumentation, Betrieb und Sicherstellung (TM10.02) Isolierung bei APT-Vorfällen (TM11.07) Hochverfügbarkeit von containerisierten Anwendungen (Container) (TM13.02) Sicherheitsanforderungen an Webanwendungen
Begründung	Eine skalierfähige Plattform, sowie die Überwachung der Umgebung bis hin zu sicheren Webanwendung lassen das Risiko abschwächen.
Restrisiko	gering

(GE15) Verlust von Schlüsseln zur Verschlüsselung

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	beträchtlich
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS08) Mangelndes Sicherheitsbewusstsein (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS01) Infrastruktur (AS1.2) Backup- und Wiederherstellungssysteme (AS02) Anwendungen (AS03) Identity and Access Management (AS05) Protokolle und Überwachungsdaten
Betroffene Informationsdaten	(IO01) Protokollierungsdaten
Gesamtrisiko	hoch
Maßnahmen	(OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.04) Vorfallmanagement (OM15.02) Risikobewertungen (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM15.06) Statuskommunikation (TM05.05) User, Rollen und Rechte (Kubernetes) (TM05.06) Automations-User und personalisierte User (Kubernetes) (TM06.02) Secret Verwaltung* (TM06.03) Kubernetes Secret Management (TM07.04) Cluster: Data-at-Rest Verschlüsselung (Kubernetes) (TM08.01) Generelle Netzwerksicherheit (TM08.02) Verschlüsselung des Kubernetes Netzwerks innerhalb der Cluster (TM08.03) Netzwerk Segmentierung (TM09.02) Verschlüsselung Backup (TM10.03) Unverzügliche Passwortänderung nach Sicherheitsvorfällen (TM10.04) Sicherheitsbedingte Neuinstallation der Systeme (TM12.06) Trennung und Sicherheit von Pods und Containern (TM13.01) Datenbanksysteme
Begründung	Durch die dedizierte Segmentierung der verschiedenen Layern, sowie u.a. die Verwaltung des Secrets für dedizierte Bereiche lassen das Risiko abschwächen. Weitere Maßnahmen wie Änderungen von Schlüsseln oder Neuinstallationen der Systeme lassen selbst bei einem Vorfall schnelle Reaktionen zu.
Restrisiko	gering

(GE16) Anforderungsdifferenzen an die IT-Umgebung und die der Benutzer

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	beträchtlich
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS28) Kundenmanagement (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS07) Unsichere Kommunikationskanäle (TS08) Unsichere Mandantenfähigkeit (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren
Betroffene Assets	(AS01) Infrastruktur (AS1.2) Backup- und Wiederherstellungssysteme (AS03) Identity and Access Management (AS05) Protokolle und Überwachungsdaten
Betroffene Informationsdaten	(IO01) Prtokollierungsdaten
Gesamtrisiko	hoch
Maßnahmen	(OM03.03) Asset Management (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM04.01) Bestimmung von Nutzungsbedingungen (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.05) Segregation von Tätigkeiten (OM07.08) Kontenverwaltung (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM11.02) Autorisierung von Dienstleistern (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM18.01) Image-Provenance (Container) (TM01.01) Ressourcen Management (TM02.01) Charakteristiken der IaaS- und PaaS-Services (TM05.01) Mandantentrennung und Multi-Mandantenfähigkeit (TM05.03) Benutzerauthentifizierung (TM07.01) Hochverfügbarkeit
Begründung	Die Sicherung der Umgebung erfolgt nach technischen Vorgaben. Etwaige Änderungen von Anforderungen werden valide geprüft. Auch die Umsetzung der Anforderungen, um die Sicherheit der Umgebung nicht zu gefährden.
Restrisiko	gering

(GE17) Datenschutzrisiken

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS02) Anwendungen (AS03) Identity and Access Management
Betroffene Informationsdaten	(IO01) Protokollierungsdaten
Gesamtrisiko	hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM09.03) Speicherung und Löschung von Benutzerdaten (OM09.04) Speicherung und Zugriff auf Identitäten (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.04) Vorfallmanagement (OM15.03) Informationen zu Sicherheitsproblemen (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.06) Statuskommunikation (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (OM16.03) Audit-Tools (OM16.04) Audit-Protokolle (OM18.01) Image-Provenance (Container) (TM04.01) Zentrales Logging und Monitoring (TM04.04) Löschung von Protokolldaten (TM05.04) Protokollierung der Zugriffe (TM06.01) Verwendung von Benutzerdaten (TM13.01) Datenbanksysteme (TM13.02) Sicherheitsanforderungen an Webanwendungen
Begründung	Das Risiko des Verstoßes gegen den Datenschutz werden durch eine Vielzahl organisatorischer und technischer Maßnahmen mitigiert, u.a. durch die Protokollierungen von Zugriffen, Sicherungen von Datenbanken und Webanwendungen selber.
Restrisiko	gering

(GE18) Lizenzrisiken

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	existenzbedrohend
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein
Betroffene Assets	(AS02) Anwendungen
Gesamtrisiko	hoch
Maßnahmen	(OM03.05) Open-Source (OM15.06) Statuskommunikation (OM17.03) Dienstdokumentation (OM17.04) Portabilität von Diensten gewährleisten (OM17.05) Migration von Anwendungen
Begründung	openDesk ist ein Open-Source-Entwicklungsprojekt, welches portabel in andere Umgebungen integriert werden kann. Selbst bei möglichen Risiken von Lizenzverstößen, ist eine Migration ungestört möglich.
Restrisiko	gering

(GE19) Unbefugte Berechtigungsausweitung

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	beträchtlich
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS09) Provisionierung von Benutzern (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (TS06) Unsichere Managementinterfaces (TS07) Unsichere Kommunikationskanäle (TS09) Fernzugriff auf die Managementoberfläche (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren (TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren (TS21) Automatisierte Überwachungstools (TS22) Unzureichende Schwachstellentests (TS26) Unzureichende Wartung
Betroffene Assets	(AS01) Infrastruktur (AS1.2) Backup- und Wiederherstellungssysteme (AS02) Anwendungen (AS03) Identity and Access Management
Gesamtrisiko	hoch
Maßnahmen	(OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern * (OM07.08) Kontenverwaltung (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.02) Vergabe von Zugriffsrechten (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen* (OM09.02) Aktivitätenerfassung abstimmen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.01) Kommunikation von Sicherheitsmaßnahmen* (OM14.02) Schwachstellenmanagement (OM14.04) Vorfallmanagement (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (TM01.02) Patch Management (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM04.05) Ausführliche Protokollierung zur Sicherung der Archive (TM04.06) Whitelisting (TM05.02) Authentifizierung & Autorisierung (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM05.05) User, Rollen und Rechte (Kubernetes) (TM05.06) Automations-User und personalisierte User (Kubernetes) (TM11.02) Sichere Konfiguration (Container) (TM11.06) Unveränderlichkeit (Container)
Begründung	Eine strikte organisatorische Trennung und eine technische Trennung von Benutzerzugriffen, lassen dedizierte Nutzerzugriffe steuern und eine Ausweitung eindämmen.
Restrisiko	gering

(GE20) Angriffe durch Social Engineering

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	existenzbedrohend
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS09) Provisionierung von Benutzern (OS10) De-Provisionierung von Benutzern (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS27) Vertraulichkeitsvereinbarungen (NDA) (OS28) Kundenmanagement (TS09) Fernzugriff auf die Managementoberfläche (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren (TS21) Automatisierte Überwachungstools
Betroffene Assets	(AS03) Identity and Access Management
Gesamtrisiko	sehr hoch
Maßnahmen	(OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM08.01) Hintergrundüberprüfung (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen (OM09.02) Aktivitätenerfassung abstimmen (OM10.01) Passwortsicherheit (OM11.02) Autorisierung von Dienstleistern (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.04) Vorfallmanagement (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.07) Forensische Untersuchungen (OM16.02) Protokollierungsprozess (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM10.03) Unverzügliche Passwortänderung nach Sicherheitsvorfällen (TM10.04) Sicherheitsbedingte Neuinstallation der Systeme
Begründung	Die Unterteilung der Zugriffe auf technischer Ebene, aber auch die Verteilung der Verantwortung in der Organisation, schmälern das Risiko des Social Engineerings.
Restrisiko	gering

(GE21) Gefährdung und Verlust von Log-Daten

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS08) Mangelndes Sicherheitsbewusstsein (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS12) Unzureichende Datenbanksicherheit (TS21) Automatisierte Überwachungstools (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS1.2) Backup- und Wiederherstellungssysteme
Betroffene Informationsdaten	(IO01) Protokollierungsdaten
Gesamtrisiko	hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.01) Datensicherung (OM06.03) Sicherung von Produktionsdaten (OM06.04) Physisch getrennte Backup-Speichermedien (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM16.01) Log-Dateien Überprüfung (OM16.03) Audit-Tools (TM05.04) Protokollierung der Zugriffe (TM06.02) Secret Verwaltung
Begründung	Dedizierte, Verschlüsselte Zugriffe mitigieren das Risiko der Gefährdung von Log-Daten. Selbst bei Verlust sind die Daten kurzfristig wiederherzustellen.
Restrisiko	gering

(GE22) Verlust oder Gefährdung von Sicherheitsprotokollen

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS08) Mangelndes Sicherheitsbewusstsein (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS12) Unzureichende Datenbanksicherheit (TS21) Automatisierte Überwachungstools (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS1.2) Backup- und Wiederherstellungssysteme
Betroffene Informationsdaten	(IO01) Protokollierungsdaten
Gesamtrisiko	mittel
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.01) Datensicherung (OM06.03) Sicherung von Produktionsdaten (OM06.04) Physisch getrennte Backup-Speichermedien (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM16.02) Protokollierungsprozess (OM16.04) Audit-Protokolle (TM04.02) Auswertung der Ereignisprotokollierung (TM04.04) Löschung von Protokolldaten (TM05.04) Protokollierung der Zugriffe (TM06.02) Secret Verwaltung
Begründung	Dedizierte, Verschlüsselte Zugriffe mitigieren das Risiko der Gefährdung von Sicherheitsprotokollen. Selbst bei Verlust sind die Daten kurzfristig wiederherzustellen.
Restrisiko	gering

(GE23) Verlust oder Diebstahl von Backups

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	existenzbedrohend
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS08) Mangelndes Sicherheitsbewusstsein (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS23) Backup (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS21) Automatisierte Überwachungstools
Betroffene Assets	(AS02) Anwendungen
Betroffene Informationsdaten	(IO01) Protokollierungsdaten
Gesamtrisiko	hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.01) Datensicherung (OM06.02) Zuverlässigkeit von Backups durch regelmäßige Prüfung (OM06.03) Sicherung von Produktionsdaten (OM06.04) Physisch getrennte Backup-Speichermedien (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM06.07) Absicherung der Wiederherstellbarkeit von Backups (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (TM04.05) Ausführliche Protokollierung zur Sicherung der Archive (TM05.04) Protokollierung der Zugriffe (TM06.02) Secret Verwaltung (TM09.02) Verschlüsselung Backup (TM09.03) Kubernetes Backup
Begründung	Widerstandsfähige Wiederherstellungspläne mitigieren das Risiko des Verlustes oder des Diebstahls von Backup. Das ausgearbeitete Backup-Konzept stellt einen gesicherten Zugriff auf die verschlüsselten Backup dar.
Restrisiko	gering

9. IT-Grundschutzcheck für den modellierten Informationsverbund

Ermittlung des Status des bestehenden und nach IT-Grundschutz modellierten Informationsverbundes in Bezug auf den Umsetzungsgrad der Sicherheitsanforderungen des IT-Grundschutz-Kompendiums.

Der Soll-Ist Vergleich wird im Dokument “20251124_Entwurf_openDesk_Checklisten_IT-Grundschutz_v0.01.pdf” dargestellt. Das Sicherheitskonzept openDesk als SaaS gilt nur als vollständig, wenn auch diese Datei vorliegend ist.

Abkürzungsverzeichnis

Abkürzung	Bedeutung
ABAP	Advanced Business Application Programming
ACL	Access Control Lists
ACME	Automatic Certificate Management Environment
AD	Active Directory
AES	Advanced Encryption Standard
AI	Artificial Intelligence
AIDE	Advanced Intrusion Detection Environment
ALG	Application-Level Gateway
API	Application Programming Interface
APT	Advanced Persistent Threat
ASLR	Address Space Layout Randomization
BACS	Building Automation and Control Systems
BIOS	Basic Input/Output System
BSI	Bundesamt für Sicherheit in der Informationstechnologie
C-CSRM	Cybersecurity Supply Chain Risk Management
CA	Certificate Authority
CARP	Common Address Redundancy Protocol
CI/CD	Continuous Integration / Continuous Deployment
CIA	Confidentiality (Vertraulichkeit), Integrity (Integrität) und Availability (Verfügbarkeit)
CIS	Center for Internet Security
CISA	Cybersecurity and Infrastructure Security Agency
CNI	Container Network Interface
CORS	Cross-Origin Resource Sharing
CPU	Central Processing Unit
CSA	Cloud Security Alliance
CTR	Cybersecurity Technical Report
CUPS	Computer Printing System
CVE	Common Vulnerabilities and Exposures, ein Programm zur Identifizierung, Definition und Katalogisierung von Schwachstellen
CVSS	Common Vulnerability Scoring System
DCCP	Datagram Congestion Control Protocol
DDoS	Distributed Denial of Service
DGUV	Deutsche Gesetzliche Unfallversicherung
DHCP	Dynamic Host Control Protocol
DMA	Direct Memory Access
DNS	Domain Name Server
DoS	Denial-of-Service
DRS	Distributed Resource Scheduling
E2EE	Ende-zu-Ende-Verschlüsselung
ERP	Enterprise Resource Planning
EU	Europäische Union
FDE	Full Disk Encryption, Festplattenverschlüsselung
FTP	File Transfer Protocol
GDM	Gnome Display Manager
GID	Group ID, die Identifikationsnummer einer Gruppe
GNOME	Graphical User Desktop Environment for Linux
GNU	GNU ist ein rekursives Akronym für “GNU’s Not Unix!”
GPG	GNU Privacy Guard
GPS	Global Positioning System,
HCI	Hyper-converged Infrastruktur
HIDS	Host-based Intrusion Detection System
HMACSHA512	Hash-based Message Authentication Code Secure Hash Algorithm 512
HSM	Hardware Security Module
HTML	Hypertext Markup Language
HTTP	Hypertext Transfer Protocol
IAM	Identity and Access Management
ICMP	Internet Control Message Protocol
ICS	Industrial Control System
IdP	Identity Provider
IDPS	Intrusion Detection and Prevention System
IDS	Intrusion Detection Systems
iLO	Integrated Lights-Out, ein System zur Administrierung und Fernwartung von Servern
IMAC	Install (Installieren), Move (Verschieben), Add (Hinzufügen), Change (Ändern)
IMAP	Internet Message Access Protocol
IO	Input/Output, Eingabe/Ausgabe
IoT	Internet of Things, Internet der Dinge
IP	Internetprotokoll
IPC	Inter-Process Communication, Inter-Prozess-Kommunikation
IPS	Intrusion Prevention System,
ISMS	Information Security Management System, Informationssicherheitsmanagementsystem
IT	Informationstechnologie
KMS	Key Management System
KVM	Kernel-basierte Virtuelle Maschine
LACP	Link Aggregation Control Protocol
LAN	Local Area Network, lokales Netzwerk
LB	Load Balancer
LDAP	Lightweight Directory Access Protocol
LTS	Long Term Support, Langzeitsupport
LUKS	Linux Unified Key Setup
LUN	Logical Unit Number
MaaS	Metal as a Service,
MAC	Mandatory Access Control
MDM	Mobile Device Management
MFA	Multi-Faktor Authentifizierung
mTLS	Mutual TLS, siehe auch TLS
NAT	Network Address Translation
NFS	Network File System
NGFW	Next-Generation Firewall
NIS2	Direktive (EU) 2022/2555 des Europäischen Parlaments und des Europäischen Rats vom 14.12.2022 zur Steigerung der Cybersicherheit in der Europäischen Union als Erweiterung der Regularie (EU) No 910/2014 und der Direktive (EU) 2018/1972, welche Direktive (EU) 2016/1148 ersetzt
NIS Server	Network Information Service Server
NIST	Nationales Institut für Standards and Technologien
NTP	Network Time Protocol
NW	Netzwerk
OAuth	Open Authorization
OoB	Out-of-Band
OS	Operation System, Betriebssystem
OSS	Open Source Software
OWASP	Open Worldwide Application Security Project
PAM	Privileged Access Management
PAW	Privileged Access Workstation
PBKDF2	Password-based Key Derivation Function Version 2
PCI	Peripheral Component Interconnect
PGP	Pretty Good Privacy
PKI	Public Key Infrastructure
PLC	Programmable Logic Controller
POP3	Post Office Protocol Version 3
PXE	Pre-Boot Execution Environment
QoS	Quality of Service
RAID	Redundant Array of Independent Disks
RAM	Random Access Memory
RBAC	Role-based Access Control, rollenbasierte Zugriffskontrolle
RDBMS	Relational Database Management System
RDS	Relational Database Service
RPC	Remote Procedure Call
RSH	Remote Shell
S3	Simple Storage Service, ein Protokoll für Objektspeicher
SaaS	Software as a Service
SAML	Security Assertion Markup Language
SAN	Storage Area Network
SBOM	Software Bill of Material
SCTP	Stream Control Transmission Protocol
SDN	Software-defined Network, Software-definiertes Netzwerk
SDS	Software-defined Storage, Software-definierter Speicher
SGID	Sticky GID, siehe auch GID
SHA	Secure Hash Algorithm
SIEM	Security Information and Event Management
SLA	Service Level Agreement
SNMP	Simple Network Management Protocol
SOPS	Secrets Operations
SQL	Structured Query Language
SSD	Solid State Disk
SSH	Secure Shell, ein Protokoll zur Netzwerkverbindung über unsichere Verbindungen
SSL	Secure Sockets Layer
STRIDE	Spoofing, Tampering, Repudiation (Verleugnung), Information disclosure, Denial of service, Elevation of privilege
SUID	Sticky UID, siehe auch UID
TBM	Technical Building Management
TCP	Transmission Control Protocol
TCP SYN Cookies	TCP SYN Cookie ist eine Technik, um sogenannten SYN Flood Attacken, einer Art von Denial-of-Service Angriffen zu widerstehen
TIPC	Transparent Inter-Process Communication
TLS	Transport Layer Security
TOR	Top-Of-Rack
ToS	Terms of Service
TPM	Trusted Platform Module
UDP	User Datagram Protocol
UEFI	Unified Extensible Firmware Interface
UID	User ID, die Identifikationsnummer eines Benutzers
UPS	Uninterruptible Power Supply, unterbrechungsfreie Stromversorgung
USB	Universal Serial Bus
VIP	Virtual IP, virtuelle IP, siehe auch IP
VM	Virtuelle Maschine
VNC	Virtual Network Computing
VoIP	Voice over IP, siehe auch IP
VPC	Virtual Port Channel
VPN	Virtuelles Privates Netzwerk
VSA	Verschlusssachenanweisung
VS-NfD	Verschlusssache - nur für den Dienstgebrauch
WAF	Web Application Firewall
WLAN	Wireless Local Area Network, Funknetzwerk
XDCMP	X Display Manager Control Protocol