Praxisleitfaden 05 / 05
IT-Sicherheit für Behörden muss im entscheidenden Moment funktionieren: wenn ein Konto kompromittiert ist, ein Update Probleme verursacht oder ein kritischer Dienst ausfällt. Ein Sicherheitskonzept ist dafür notwendig, aber erst getestete technische und organisatorische Maßnahmen machen es wirksam.
Die kurze Antwort: drei Fähigkeiten gemeinsam aufbauen
Begrenzen Sie Zugriffe, kontrollieren Sie die Softwarelieferung und erproben Sie den Wiederanlauf. NIST beschreibt Zero Trust als Ansatz, der Ressourcen schützt und Vertrauen nicht pauschal aus dem Netzwerkstandort ableitet. [1] Daraus folgt kein Zwang, sofort die gesamte Infrastruktur zu ersetzen. Ein kritischer Dienst ist ein sinnvoller erster Prüfumfang.
Die Frage hinter dem Sicherheitsbudget
Kann ein einzelnes Konto mehr erreichen als für seine Aufgabe nötig? Wissen Sie, welche Softwareversion tatsächlich läuft? Und haben Sie geprüft, ob ein Backup unter realistischen Bedingungen verwendbar ist? Diese Fragen verbinden Sicherheitsarchitektur mit der Arbeitsfähigkeit der Verwaltung.
Digitale Souveränität bedeutet hier: Die Organisation behält die Kontrolle über Zugriff, Veränderung und Wiederherstellung ihrer Systeme.
Wo Sicherheitsmaßnahmen im Behördenbetrieb auseinanderfallen
Der Netzzugang ersetzt die Berechtigungsprüfung
Ein VPN kann die Verbindung absichern, sagt aber noch nicht, auf welche Daten eine Person oder ein Dienst zugreifen soll. Dauerhafte Administrationsrechte und gemeinsam genutzte Konten erschweren die Begrenzung und Nachvollziehbarkeit. Prüfen Sie deshalb Benutzer, Geräte und technische Identitäten entlang realer Datenflüsse.
Zwischen Quellcode und Produktion fehlt die Beweiskette
Ein Sicherheitscheck im Repository belegt nicht, dass genau dieser Stand produktiv läuft. Abhängigkeiten, Build-Umgebung, Artefakte und Deployment können sich unterscheiden. Eine Software-Stückliste schafft Transparenz über Komponenten; sie beweist allein weder Schwachstellenfreiheit noch sicheren Betrieb. Auch eine Signatur belegt Herkunft und Integrität, nicht automatisch Unschädlichkeit.
Die Sicherung ist erfolgreich, die Wiederherstellung unbekannt
Ein grüner Backup-Status beantwortet nicht, ob Daten, Schlüssel, Identitäten und Schnittstellen gemeinsam wieder anlaufen. Die Wiederherstellung kann an einer Abhängigkeit scheitern, die im Notfall ebenfalls nicht verfügbar ist. Der Test muss daher den vollständigen Dienst und seine fachliche Nutzbarkeit betrachten.
Priorisierung: Beginnen Sie mit einem Verwaltungsdienst, dessen Ausfall oder Datenverlust konkrete Folgen hätte. Ein begrenzter, vollständig geprüfter Dienst liefert mehr Erkenntnis als eine unvollständige Liste aller Sicherheitstools.
Die Lösung: drei verbundene Schutzschichten
1. Rechte nachvollziehbar begrenzen
Ordnen Sie jeder Rolle und jedem Dienstkonto eine Aufgabe zu. Entfernen Sie nicht benötigte Rechte, begrenzen Sie administrative Freigaben zeitlich und prüfen Sie Zugriffe auf sensible Ressourcen separat. Eine Segmentierung wird anhand notwendiger Verbindungen eingeführt; ungetestetes Abschalten kann sonst selbst die Verfügbarkeit gefährden.
2. Software reproduzierbar ausliefern
Verbinden Sie Versionsstand, Abhängigkeiten, Sicherheitsprüfungen, Build-Artefakt und Freigabe. NIST SSDF ordnet sichere Entwicklungspraktiken über den gesamten Softwarelebenszyklus ein. [2] Für einen konkreten Dienst kann das signierte Artefakte, kontrollierte Registries, Komponentenlisten und eine Freigabeprüfung vor dem Deployment bedeuten. Nicht freigegebene Artefakte werden nicht allein aufgrund eines passenden Dateinamens akzeptiert.
3. Erkennen und Wiederherstellen zusammen planen
Definieren Sie, welche Ereignisse einen Alarm auslösen und wer darauf reagiert. Sichern Sie Wiederherstellungsinformationen und notwendige Schlüssel angemessen getrennt ab. Erproben Sie den Wiederanlauf inklusive fachlicher Kontrollen. Wiederherstellung aus einem möglicherweise kompromittierten Stand benötigt zusätzliche Prüfung; nur schnell wieder online zu sein ist kein ausreichendes Ziel.
Verantwortlichkeiten sind Teil der Architektur. Der NIST-Planungsleitfaden zu Zero Trust hebt die Zusammenarbeit verschiedener Beteiligter hervor. [3] Ein Produkt allein ersetzt weder Risikoverantwortung noch den Entscheidungsweg im Sicherheitsvorfall.
Ein umsetzbarer Prüf- und Verbesserungsplan
1. Dienst und Abhängigkeiten erfassen
Dokumentieren Sie fachliche Aufgabe, Betreiber, kritische Daten, Identitäten, Schnittstellen und Softwarelieferanten. Vereinbaren Sie tolerierbare Unterbrechung und Datenverlust mit dem Fachbereich. Die Zielwerte müssen zur Aufgabe passen; pauschale Zahlen aus einer Produktbroschüre sind kein ausreichender Maßstab.
2. Kontrollen an realen Szenarien prüfen
Testen Sie im freigegebenen Umfang: Ein nicht berechtigter Nutzer erhält keinen Datenzugriff. Ein abgelaufenes Dienstkonto verliert seine Berechtigung. Ein nicht freigegebenes Release wird gestoppt. Ein Alarm erreicht eine zuständige Person. Solche Nachweise sollten reproduzierbar und zeitlich zuordenbar sein.
3. Einen Wiederanlauf wirklich ausführen
Wählen Sie eine geschützte Testumgebung. Stellen Sie Daten und Anwendung wieder her und prüfen Sie Integrität, Rechte und wesentliche Fachfunktionen. Messen Sie die tatsächlich benötigte Zeit. Halten Sie fest, welche Informationen oder Kompetenzen fehlten. Eine Besprechung am Tisch ergänzt diesen Test, ersetzt ihn aber nicht.
4. Den Sicherheitszyklus schließen
Ein relevanter Befund erzeugt ein Ticket mit Risiko, Zuständigkeit und Frist. Nach Behebung folgt ein erneuter Test. Erst dessen Ergebnis schließt den Befund. Automatisierung kann Befunde sammeln, Aufgaben zuordnen und Nachweise aktualisieren; risikorelevante Änderungen behalten definierte Freigaben.
Liefergegenstände: Abhängigkeitskarte, Rechte-Matrix, priorisierte Maßnahmen, Release-Nachweise, Wiederanlaufprotokoll und verbleibende Risiken. Jeder Restpunkt braucht einen Eigentümer – nicht nur einen Status im Dashboard.
Sicherheit beschaffen: Wirksamkeit statt pauschaler Versprechen
Fragen Sie nach dem Geltungsbereich einer Prüfung und nach den Aufgaben, die bei Ihrer Organisation verbleiben. Im Cloud-Kontext stellt das BSI ausdrücklich klar, dass ein C5-Testat allein nicht alle Anforderungen seines Mindeststandards erfüllt. [4] Übertragen Sie diese Denkweise auf die Beschaffung: Welcher konkrete Dienst, welche Kontrolle und welcher Zeitraum sind tatsächlich belegt?
Nutzen mit sinnvollen Kennzahlen bewerten
Geeignet sind beispielsweise der Anteil geprüfter administrativer Konten, die Zeit bis zur Behebung relevanter Befunde und der Anteil erfolgreich wiederhergestellter kritischer Dienste im vereinbarten Testumfang. Eine steigende Zahl entdeckter Schwachstellen kann zunächst bessere Sichtbarkeit bedeuten; die reine Fundzahl ist deshalb kein verlässlicher Erfolgsmaßstab.
Ein illustratives Abnahmeszenario: Für einen Dienst werden acht Stunden Wiederanlauf und höchstens vier Stunden Datenverlust vereinbart. Der Test benötigt elf Stunden. Damit ist das Wiederanlaufziel nicht erreicht, auch wenn der Dienst am Ende verfügbar ist. Aus der Abweichung entsteht ein konkreter Verbesserungsauftrag. Die Werte sind frei gewählte Beispiele, keine allgemeine Empfehlung.
Ein erster Sicherheits-Check mit Insight42
Lassen Sie die Schutz- und Wiederanlauffähigkeit eines kritischen Dienstes gemeinsam betrachten. Insight42 nennt Cloud-Sicherheit, Verschlüsselung und technischen Plattformbetrieb als Leistungsfelder. [5] Ein begrenzter Auftrag kann Kontrollen, Nachweise und Abhängigkeiten zusammenführen und einen priorisierten Umsetzungsplan liefern. Er ist keine automatische Zertifizierung oder behördliche Freigabe.
Kontakt: support@insight42.com. Beschreiben Sie Dienst, Schutzbedarf und bekannte Betriebshürden abstrakt. Zugangsdaten, Schwachstellendetails und sensible Pläne gehören erst in einen vereinbarten sicheren Austausch.
Häufige Fragen zur IT-Sicherheit für Behörden
Ersetzt Zero Trust den IT-Grundschutz?
Nein. Zero Trust ist ein Architekturansatz, kein Ersatz für das Informationssicherheitsmanagement oder alle Anforderungen einer Organisation. Bestehende IT-Grundschutz-Arbeiten sollten mit den konkreten Zugriffskontrollen und Betriebsnachweisen verbunden werden.
Reicht eine Software-Stückliste aus?
Nein. Eine SBOM schafft Transparenz über Komponenten. Sie braucht ein Verfahren zur Bewertung, Behebung und Nachprüfung relevanter Risiken. Ohne Verbindung zur tatsächlich ausgelieferten Version kann selbst eine vollständige Liste am Betrieb vorbeigehen.
Müssen wir sofort alles ersetzen?
Nein. Beginnen Sie mit einem abgegrenzten Dienst und den wichtigsten Risiken. Bestehende Werkzeuge können weiter genutzt werden, sofern sie die geforderten Kontrollen und Nachweise ermöglichen. Werkzeugkonsolidierung ist eine Option, nicht der Startpunkt jeder Sicherheitsinitiative.
Gilt das auch für Bundeswehr-Vorhaben?
Die beschriebenen Engineering-Prinzipien können als Diskussionsgrundlage dienen. Daraus folgt jedoch keine Eignung für Verschlusssachen oder eine bestimmte Bundeswehr-Umgebung. Schutzbedarf, besondere Vorgaben und erforderliche Freigaben sind im konkreten Auftrag gesondert zu klären.
Fazit: Ein sicherer Dienst lässt sich nicht nur beschreiben. Seine Zugriffsgrenzen, Softwareherkunft und Wiederherstellung lassen sich im vereinbarten Umfang prüfen.
Quellen und fachliche Referenzen
[1] NIST: SP 800-207, Zero Trust Architecture
[2] NIST: SP 800-218, Secure Software Development Framework 1.1
[3] NIST: CSWP 20, Planning for a Zero Trust Architecture
[4] BSI: FAQ zum Mindeststandard Externe Cloud-Dienste
[5] Insight42: Leistungsprofil
Quellenstand: 27.09.2026. Rechenbeispiele und Diagramme dienen der Erläuterung.