Cloud-Scanning, Telemetrie und Updates in VS-NfD-Umgebungen
Man stelle sich einen geschützten Projektarbeitsplatz vor: Eine Sicherheitssoftware erkennt dort eine verdächtige Datei. Sie blockiert die Ausführung, erstellt einen Befund und übermittelt das Dateimuster zur genaueren Analyse an einen Cloud-Dienst. In einem gewöhnlichen Unternehmensnetz kann genau diese Automatisierung sinnvoll sein. Wird auf dem System jedoch VS-NUR FÜR DEN DIENSTGEBRAUCH (VS-NfD) verarbeitet, kann derselbe Vorgang ein Geheimschutzproblem auslösen. Nicht weil die Software versagt, sondern weil eine an sich nützliche Schutzfunktion eine unzulässige Datenbewegung verursachen kann.
Moderne Endpoint-Security ist längst mehr als ein lokaler Virenscanner. EDR-Systeme analysieren Prozessabläufe, bewerten verdächtiges Verhalten, korrelieren Ereignisse über mehrere Geräte und nutzen gegebenenfalls Cloud-Dienste für zusätzliche Untersuchungen. Dafür benötigen sie Informationen über das, was auf einem Endgerät geschieht. Genau an diesem Punkt treffen zwei berechtigte Sicherheitsziele aufeinander: Angriffe möglichst früh erkennen und Verschlusssachen innerhalb eines kontrollierten Informationsraums halten.
Wenn ein Schutzmechanismus zum Datenkanal wird
Ein mögliches Szenario: Ein Entwicklungsunternehmen bearbeitet in seiner VS-NfD-Umgebung eine eingestufte Tabelle mit technischen Parametern. Die Sicherheitssoftware stuft ein Makro als verdächtig ein. Ist eine Funktion zur automatischen Musterübermittlung aktiv, kann nun eine Kopie der Datei an einen externen Analysedienst gehen. Ob und welche Dateien übertragen werden, hängt vom Produkt und seiner Konfiguration ab. Dass solche Funktionen grundsätzlich existieren, ist dokumentiert: Microsoft beschreibt für Defender Antivirus das Zusammenspiel von Cloudschutz und automatischer Übermittlung von Dateimustern. Für den normalen IT-Betrieb ist das ein Sicherheitsmerkmal. In der VS-NfD-Verarbeitung muss es anders bewertet werden.
Weniger offensichtlich ist das zweite Beispiel: die Telemetrie. Sicherheitsagenten und Diagnosefunktionen können Dateipfade, Prozessnamen, Benutzerkennungen, Kommunikationsziele oder technische Ereignisse erfassen. Auch ohne Übertragung eines vollständigen Dokuments können daraus Projektbezeichnungen, Arbeitsbeziehungen oder zeitliche Abläufe erkennbar werden. Nicht jedes Protokoll ist deshalb automatisch selbst eine Verschlusssache. Aber niemand sollte ungeprüft voraussetzen, dass Metadaten stets harmlos sind.
Das dritte Risiko entsteht im laufenden Betrieb. Sicherheitssoftware wird häufig aktualisiert: neue Erkennungsmodelle, neue Module, geänderte Schnittstellen. Ein Update kann Funktionen oder Kommunikationsverhalten verändern. Eine Konfiguration, die bei der Inbetriebnahme geprüft wurde, ist deshalb keine dauerhafte Garantie. Die entscheidende Frage lautet nicht nur, ob ein Daten-Upload deaktiviert wurde, sondern ob diese Sperre nach einer Aktualisierung weiterhin nachweisbar wirkt.
Was das VS-NfD-Merkblatt verlangt
Die Problematik ist keine bloße theoretische Ableitung. Das VS-NfD-Merkblatt (Anlage 4 zum Geheimschutzhandbuch) regelt in Teil 3, Ziffer 2.2, die Anforderungen für VS-NfD-Netze mit Verbindungen zu Netzwerksegmenten, die die VS-NfD-Anforderungen nicht erfüllen. In diesem Anwendungsfall darf die eingesetzte Schadcode-Erkennung keine Prüfung außerhalb des VS-NfD-Netzes durchführen, beispielsweise in der Cloud. Auch nach außen gerichtete Kommunikationsverbindungen und Softwareaktualisierungen sind entsprechend zu kontrollieren.
Die BMWE-FAQ zum VS-NfD-Merkblatt, Stand Mai 2026, wird noch konkreter: Unerwünschte Telemetrieübertragungen sind fortlaufend auszuschließen. Ein Virenscanner mit Online-Datenprüfung darf nur eingesetzt werden, wenn sich der Upload von Daten nachweislich deaktivieren lässt; nach jedem Softwareupdate ist diese Funktion erneut zu prüfen. Maßgeblich bleiben die einschlägige Systemarchitektur, das Merkblatt und die konkreten Anforderungen des Auftraggebers.
Das bedeutet nicht, dass Unternehmen auf wirksamen Schadcode-Schutz verzichten sollen. Ebenso wenig ist damit jede Cloud-Nutzung im VS-NfD-Kontext pauschal untersagt. Der Unterschied liegt darin, welche Informationen wo und in welcher Form verarbeitet werden. Eine Cloud-basierte Inhaltsanalyse im Klartext ist nicht mit einer reinen Cloud-Ablage unter den vom BMWE beschriebenen strengen Voraussetzungen, einschließlich geeigneter BSI-konformer Verschlüsselung, gleichzusetzen.
Was Sicherheitsverantwortliche und IT konkret tun können
Am Anfang sollte keine Produktdiskussion stehen, sondern eine Bestandsaufnahme der tatsächlichen Datenflüsse. Welche Sicherheitsagenten laufen innerhalb der VS-NfD-Umgebung? Welche Funktionen senden Daten, Dateien oder Diagnoseinformationen nach außen? Gibt es automatische Dateimusterübermittlungen, cloudgestützte Analysen, Remote-Support-Funktionen oder zentral angebundene EDR-Konsolen? Und was geschieht, wenn ein Gerät offline ist? Der Werbesatz „Cloud Security“ beantwortet keine dieser Fragen.
Die benannte VS-NfD-verantwortliche Person sollte diese Fragen gemeinsam mit IT-Betrieb und Informationssicherheit klären, bevor ein Produkt freigegeben wird. Dafür braucht es eine dokumentierte Soll-Konfiguration, nachvollziehbare Herstellerinformationen und klar definierte Kommunikationswege. Wo sich unerwünschte Uploads abschalten lassen, muss das nicht nur im Menü erkennbar sein, sondern mit geeigneten Tests und Kontrollen belegbar werden. Solche Prüfungen gehören in eine Testumgebung mit unkritischen Testdaten, nicht in ein Experiment mit echten Verschlusssachen.
Nach jedem relevanten Update sollte kontrolliert werden, ob die festgelegten Einstellungen und ausgehenden Verbindungen unverändert geblieben sind. Für isolierte Umgebungen sind sichere Verfahren zur Versorgung mit Signaturen und Softwareaktualisierungen vorzusehen. Lässt sich eine für den Geheimschutz problematische Kernfunktion eines Produkts nicht zuverlässig deaktivieren, muss eine andere Betriebsvariante oder ein anderes geeignetes Produkt geprüft werden. Einfach den Malware-Schutz abzuschalten, wäre keine verantwortbare Lösung.
Fazit: Schutzwirkung ist nicht dasselbe wie Geheimschutztauglichkeit
Eine Sicherheitslösung kann technisch hervorragend sein und trotzdem nicht zu einer bestimmten VS-NfD-Architektur passen. Entscheidend ist deshalb nicht allein, wie viele Angriffe ein Produkt erkennt, sondern auch, welche Daten es dabei verarbeitet, an wen es sie übermittelt und wer diese Vorgänge kontrollieren kann. Geheimschutz beginnt nicht erst bei der Verschlüsselung einer Datei. Er beginnt bei der Kenntnis aller Systeme, die mit dieser Datei in Berührung kommen – einschließlich der Software, die sie eigentlich schützen soll.
Quellen und weiterführende Informationen
BMWE: VS-NfD-Merkblatt, Anlage 4 zum Geheimschutzhandbuch
BMWE: FAQ zum VS-NfD-Merkblatt, Stand 05/2026
Microsoft Learn: Cloudschutz und Musterübermittlung.
Die technischen Beispiele sind als mögliche Szenarien formuliert und die erwähnten Cloud-Schutzfunktionen sind durch Herstellerunterlagen belegt.
Weiterlesen: Warum Netztrennung bei VS-NfD mehr ist als eine regulatorische Pflicht.
