openDesk/Nubus im ISMS: Wie sich der Open-Source-Stack BSI-grundschutzkonform einordnen lässt

Warum die ISMS-Frage bei openDesk nicht optional ist

Wer als Behörde openDesk einführt, löst damit ein Souveränitätsproblem – schafft aber gleichzeitig eine neue Pflicht: Jede neue Anwendung, jedes neue System muss sich in das bestehende Informationssicherheits-Managementsystem einfügen. Der BSI-IT-Grundschutz bleibt dabei die maßgebliche Methodik für Bundesbehörden und KRITIS-Betreiber, und mit der Umsetzung von NIS-2 in nationales Recht sowie den seit Januar 2026 geltenden Neuerungen von Grundschutz++ ist der Erwartungsdruck an eine saubere, auditfähige Dokumentation eher gestiegen als gesunken.

Die gute Nachricht vorab: Der IT-Grundschutz ist bewusst werkzeug- und herstellerneutral konzipiert. Open-Source-Lösungen erfüllen die Anforderungen grundsätzlich genauso wie proprietäre Produkte – entscheidend ist nicht, wer die Software geschrieben hat, sondern ob die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit nachweisbar erreicht werden. Für die Verwaltung des ISMS selbst hat sich zudem mit Verinice ein Open-Source-Werkzeug etabliert, das die Grundschutz-Methodik direkt abbildet – Strukturanalyse, Schutzbedarfsfeststellung, Bausteinmodellierung und Risikoanalyse nach den BSI-Standards 200-1 bis 200-3 inklusive.

Den Informationsverbund sauber abgrenzen

Der erste Schritt ist nicht technisch, sondern konzeptionell: Wo genau endet der bestehende Informationsverbund, und wo beginnt openDesk? Für die meisten Behörden ist es sinnvoll, openDesk samt Nubus als eigenen, klar abgegrenzten Geltungsbereich innerhalb des größeren Informationsverbunds zu modellieren – mit definierten Schnittstellen zum bestehenden Netz, zum Identitätsmanagement und zu etwaigen Fachverfahren. Das lohnt sich besonders dann, wenn openDesk zunächst nur für einen Teil der Behörde oder in einer Pilotphase eingeführt wird, denn ein eng abgegrenzter Verbund lässt sich mit überschaubarem Aufwand modellieren und später erweitern, statt die gesamte Behörden-IT auf einen Schlag neu zu strukturieren.

Wichtig für das Betriebsmodell: Wird openDesk selbst betrieben – etwa in einem eigenen Rechenzentrum oder per Docker/Portainer-Kubernetes-Setup wie im Artikel zur SSO-Integration beschrieben –, liegt die volle Verantwortung für die Grundschutz-Bausteine bei der Behörde selbst. Wird openDesk hingegen als Dienstleistung bezogen, verschiebt sich ein Teil der Verantwortung zum Betreiber, muss aber im eigenen ISMS als Outsourcing-Beziehung mit entsprechenden vertraglichen Nachweispflichten dokumentiert werden.

Die openDesk/Nubus-Komponenten auf Grundschutz-Bausteine abbilden

Der IT-Grundschutz gliedert seine Bausteine in thematische Schichten. Für openDesk und Nubus lassen sich die relevantesten davon direkt den bekannten Komponenten zuordnen:

• ORP.4 Identitätsmanagement ist der naheliegendste Baustein für Nubus: Verzeichnisdienst, Keycloak als Identity Provider und die Anbindung an ein bestehendes Active Directory oder LDAP gehören genau in diesen Baustein. Wer die im vorherigen Artikel beschriebene stufenweise AD/LDAP-Migration umsetzt, dokumentiert damit zugleich einen wesentlichen Teil dieses Bausteins.
• APP-Bausteine für die Fachanwendungen decken Nextcloud, Collabora Online, OpenProject, Element und die übrigen openDesk-Module ab. Da jedes dieser neun Projekte einen eigenen Releasezyklus und eigene Sicherheitsmeldungen hat, empfiehlt sich pro Kernanwendung ein eigener, schlanker Baustein-Eintrag statt eines pauschalen „openDesk“-Objekts – nur so bleibt nachvollziehbar, welches Modul welche Schutzmaßnahmen bereits erfüllt.
• OPS Betrieb, insbesondere Patch- und Schwachstellenmanagement, ist bei openDesk kein Nebenschauplatz, sondern der eigentliche Kraftaufwand im Alltag: Neun unabhängige Open-Source-Projekte bedeuten neun Update-Pfade und potenziell neun gleichzeitige Sicherheitsmeldungen. Ein dokumentierter, eingespielter Prozess für zeitnahes Patchen ist deshalb einer der Punkte, auf den Auditoren erfahrungsgemäß besonders genau schauen.
• SYS und NET für die zugrunde liegende Infrastruktur betreffen den Kubernetes-Cluster, auf dem Nubus läuft, samt Ingress, Zertifikatsverwaltung und Netzsegmentierung. Wer openDesk containerisiert über Docker und Portainer betreibt, dokumentiert an dieser Stelle auch die Absicherung des darunterliegenden Kubernetes-in-Docker-Setups.
• DER Detektion und Reaktion deckt Monitoring, Protokollierung und Vorfallbehandlung ab. Nubus liefert über seine Provisioning- und Guardian-Komponenten strukturierte Ereignisse, die sich in ein zentrales Logging- und Monitoring-Konzept einspeisen lassen – Voraussetzung dafür, dass ein Sicherheitsvorfall in einer der neun Anwendungen überhaupt zeitnah auffällt.

Auditfähig machen: worauf es in der Praxis ankommt

Ein Auditor prüft nicht, ob die Technik theoretisch sicher sein könnte, sondern ob die Umsetzung nachweisbar dokumentiert ist. Für openDesk/Nubus heißt das konkret:

Lückenlose Nachweise statt Behauptungen. Für jeden modellierten Baustein braucht es im ISMS-Tool den dokumentierten Umsetzungsstand – umgesetzt, teilweise umgesetzt, nicht umsetzbar mit Begründung. Ein pauschaler Verweis auf „Open Source ist sicher“ ersetzt keinen einzigen Nachweis.

Patch-Historie als durchgehendes Protokoll. Da openDesk in kurzen Abständen Patchreleases veröffentlicht, lohnt sich ein automatisiertes Protokoll, welches Modul wann auf welchen Stand gebracht wurde. Das ist im Ernstfall der schnellste Weg, um im Audit zu belegen, dass Schwachstellen zeitnah geschlossen wurden.

Rollen- und Rechtekonzept aus Nubus direkt referenzieren. Da Guardian die rollenbasierte Zugriffskontrolle über alle Module hinweg steuert, lässt sich das dort hinterlegte Rechtekonzept nahezu unverändert als Nachweis für die Bausteine zur Zugriffskontrolle übernehmen – das spart doppelte Dokumentationsarbeit.

Grenze zwischen eigenem und fremdem Verantwortungsbereich klar ziehen. Gerade bei Docker/Portainer-Betrieb in Eigenregie ist es wichtig, im Sicherheitskonzept eindeutig festzuhalten, was die eigene IT verantwortet und was aus den Upstream-Projekten übernommen wird – etwa Sicherheitspatches, die von den einzelnen Modul-Communities bereitgestellt werden.

Praktisches Vorgehen in vier Schritten

1. Strukturanalyse. openDesk/Nubus als eigenen Geltungsbereich im ISMS-Tool anlegen, alle Komponenten – Identitätsmanagement, Fachanwendungen, Infrastruktur – als Zielobjekte erfassen.
2. Schutzbedarfsfeststellung. Für jede Komponente den Schutzbedarf hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit festlegen; Nubus als Identitätsschicht erhält dabei in der Regel einen höheren Schutzbedarf als eine einzelne Fachanwendung, weil ein Ausfall oder eine Kompromittierung sofort alle angebundenen Module betrifft.
3. Modellierung mit den passenden Bausteinen. Die oben genannten Bausteine (ORP.4, die relevanten APP-Bausteine, OPS, SYS/NET, DER) zuordnen und anhand des IT-Grundschutz-Checks den Soll-Ist-Abgleich durchführen.
4. Regelmäßige Rezertifizierung einplanen. Ein einmal erstelltes Sicherheitskonzept ist kein Freibrief – bei Basis- oder Standard-Absicherung nach BSI-Grundschutz gilt eine Zertifikatslaufzeit von drei Jahren mit jährlichen Überwachungsaudits dazwischen. Gerade weil sich openDesk in monatlichem Takt weiterentwickelt, sollte die ISMS-Dokumentation nicht erst zur Rezertifizierung, sondern laufend mit den Release-Zyklen der Module aktualisiert werden.

Fazit

openDesk und Nubus stehen der BSI-Grundschutz-Konformität nicht im Weg – im Gegenteil: Die klare Aufteilung in Identitätsmanagement, Fachanwendungen und Infrastruktur lässt sich sauber auf etablierte Grundschutz-Bausteine abbilden, und mit Verinice steht dafür sogar ein Open-Source-Werkzeug bereit, das zur Souveränitätsphilosophie von openDesk passt. Der eigentliche Aufwand liegt nicht in der Modellierung selbst, sondern in der laufenden Pflege: Neun eigenständige Projekte mit eigenen Release-Zyklen verlangen ein Patch- und Nachweis-Management, das mit der gleichen Disziplin betrieben wird, mit der die Software selbst entwickelt wird.