On-Premise heißt auch: Der Hersteller kommt nicht rein

"On-Premise" wird meistens mit einem Satz verkauft: Die Software läuft bei Ihnen im Haus, die Daten verlassen Ihr Rechenzentrum nicht. Das beantwortet die Frage, wo die Daten liegen. Es beantwortet nicht die Frage, wer an sie herankommt.

Für eine IT-Leitung oder einen Datenschutzbeauftragten sind drei andere Fragen ergiebiger: Kommt der Hersteller an die Maschine? Über welchen Weg? Und wer merkt es, wenn er es tut?

Wo die Daten liegen, ist die leichte Frage

Ein System kann vollständig im eigenen Haus stehen und trotzdem einen Weg nach außen offenhalten, über den jemand hineinkommt. Typische Formen sind ein dauerhaft eingerichteter Fernwartungszugang, ein Update- oder Verwaltungsdienst, den der Hersteller betreibt und mit dem die Installation ständig verbunden ist, eine Anmeldung, die über einen Dienst des Herstellers läuft, oder eine Vernetzung, deren Steuerung beim Dienstleister liegt.

Keine dieser Konstruktionen ist per se unzulässig, und für manche gibt es gute Gründe. Aber jede verschiebt die Frage, wer Kontrolle über das System hat. Und eine zentrale Steuerung, über die ein Dienstleister viele Einrichtungen erreicht, ist auch ein zentraler Angriffspunkt: Wird sie kompromittiert, betrifft das jeden Standort, der an ihr hängt.

Was ein Zugang rechtlich bedeutet

Die Datenschutzkonferenz der deutschen Aufsichtsbehörden ordnet Fernwartung in ihrem Kurzpapier Nr. 13 (Auftragsverarbeitung, Stand 17.12.2018) eindeutig ein: Besteht bei Wartung oder Fernwartung die "Notwendigkeit oder Möglichkeit des Zugriffs auf personenbezogene Daten", handelt es sich um eine Form der Auftragsverarbeitung, und die Anforderungen des Art. 28 DSGVO, etwa ein Vertrag zur Auftragsverarbeitung, sind umzusetzen. Als Beispiel nennt das Papier ausdrücklich Fernwartung und externen Support, "wenn bei diesen Tätigkeiten ein Zugriff auf personenbezogene Daten nicht ausgeschlossen werden kann".

Entscheidend ist das Wort Möglichkeit. Es kommt nicht darauf an, ob der Hersteller tatsächlich Patientendaten ansieht, sondern ob er es technisch könnte. Ein Vertrag regelt, was der Hersteller darf. Was er kann, regelt die Technik - und die Pflicht, die Vertraulichkeit der Systeme "auf Dauer sicherzustellen", steht bei Ihnen (Art. 32 Abs. 1 lit. b DSGVO).

Wie wir es bei uns selbst gebaut haben

Wir haben diese Frage zuerst an uns selbst beantwortet. Unsere Entwicklung und unsere Auslieferung laufen auf getrennten Maschinen: Auf der einen Seite liegen Quellcode, Tests und das Bauen der Software. Auf der anderen laufen diese Website und unsere Demo-Instanz, die ausschließlich mit erfundenen Daten arbeitet.

Die Netzregeln zwischen beiden sind bewusst einseitig. Die Auslieferungsseite darf die Entwicklungsseite über einen einzigen, eng geschnittenen Weg erreichen: um fertige Pakete abzuholen und um Tickets zu schreiben, beides mit eigenen Zugangsschlüsseln, die auf genau diesen Zweck beschränkt sind. In der Gegenrichtung gibt es keinen Weg. Von der Entwicklungsseite aus kann niemand eine Datei auf der ausgelieferten Seite ändern, sich dort anmelden oder eine neue Version einspielen.

Der Grund ist einfach: Ein Entwicklungsrechner ist die Maschine, auf der am meisten fremder Code läuft - Abhängigkeiten, Werkzeuge, Testumgebungen. Wird er kompromittiert, soll das nicht automatisch bis zur Auslieferung durchgreifen.

Eine neue Version kommt deshalb nicht per Knopfdruck auf die Auslieferungsseite. Die Entwicklungsseite meldet eine fertige, getestete Version. Die Auslieferungsseite holt sie ab, sichert vorher die Datenbank, spielt sie ein und prüft sie - und zwar erst, nachdem ein Mensch ausdrücklich freigegeben hat. Danach meldet sie die gemessenen Prüfsummen der eingespielten Pakete zurück. Die Entwicklungsseite hält ihre eigenen Werte bis dahin bewusst zurück und vergleicht erst dann. Damit ist "Wer merkt es?" keine Vertrauensfrage mehr: Jeder Schritt hinterlässt einen schriftlichen Eintrag, und eine Abweichung fällt beim Vergleich auf, nicht erst bei einem Vorfall.

Was es kostet

Im Alltag ist diese Trennung lästig, und das soll hier nicht verschwiegen werden. Wer auf der Entwicklungsseite einen Fehler auf der Website bemerkt, kann ihn nicht einfach beheben. Er schreibt ein Ticket, und die Korrektur geschieht auf der anderen Seite. Das gilt für eine veraltete Versionsangabe genauso wie für einen fehlenden Link.

Spürbarer wird es bei Fehlern, die nur im Betrieb auftreten. Vor Kurzem lieferte eine Funktion unserer Demo nach einem Modellwechsel keine Antwort mehr. Die Fehlermeldung stand im Protokoll der Auslieferungsseite, und die Entwicklungsseite konnte sie nicht einsehen. Bis der Fehler behoben war, brauchte es ein Ticket, eine neue Version und mehrere Übergaben in beide Richtungen. Eine anschließende Rückfrage zu den Zahlen in der Antwort lief genauso: als schriftliche Datenanfrage, beantwortet auf der anderen Seite. Mit direktem Zugriff wäre beides schneller gegangen.

Das ist der Preis, und wir halten ihn für richtig. Gerade weil die Trennung uns regelmäßig Umwege abverlangt, ist sie ein brauchbarer Beleg: Stünde sie nur auf dem Papier, hätten wir sie längst aufgeweicht.

Und auf Ihren Systemen?

Dasselbe Prinzip steckt in Linumed Base, unserer Infrastrukturgrundlage für Krankenhäuser. Alle Verwaltungsoberflächen lauschen nur lokal auf der Maschine selbst und sind ausschließlich über einen SSH-Tunnel erreichbar. Es gibt keinen mitgelieferten Anmeldedienst und keine Vernetzung, deren Steuerung wir betreiben. Die Begründung steht öffentlich in ADR 0003, einschließlich der Nachteile, die wir dafür in Kauf nehmen: Ohne einen Rechner mit SSH-Schlüssel lässt sich keine Störung diagnostizieren, und es gibt keine zentrale Sperre von Zugängen.

Das heißt nicht, dass externe Wartung ausgeschlossen ist. Wenn eine Einrichtung einen Dienstleister hereinlassen will, kann sie das tun - über ihr eigenes VPN, einen Sprungserver oder das Kliniknetz. Der Unterschied ist, wer darüber entscheidet: Der Weg gehört der Einrichtung, nicht dem Hersteller.

Was Sie prüfen sollten

Die folgenden Fragen gelten für jede Software, die bei Ihnen im Haus läuft, nicht nur für unsere. Sie lassen sich meist ohne Herstellerbeteiligung beantworten:

• Welche Verbindungen baut das System selbst nach außen auf? Lassen Sie sich die Liste geben und gleichen Sie sie mit den Protokollen Ihrer Firewall ab. Eine ausgehende Verbindung, die dauerhaft offen bleibt, kann auch ein Weg nach innen sein.
• Gibt es eine Komponente, die der Hersteller betreibt und ohne die das System nicht funktioniert? Ein Lizenzserver, ein Update-Dienst, eine zentrale Anmeldung. Fragen Sie, was passiert, wenn sie ausfällt, und wen es betrifft, wenn sie kompromittiert wird.
• Wer schaltet einen Fernwartungszugang frei, und wann? Ein Zugang, der pro Fall von Ihnen geöffnet und danach wieder geschlossen wird, ist etwas anderes als ein dauerhaft eingerichteter Tunnel.
• Wo steht, wer wann im System war - und bei wem? Ein Protokoll, das nur beim Hersteller liegt, hilft Ihnen bei einem Vorfall wenig.
• Deckt Ihr Vertrag zur Auftragsverarbeitung ab, was technisch möglich ist, oder nur, was vorgesehen ist? Maßgeblich ist nach der Einordnung der Aufsichtsbehörden die Möglichkeit des Zugriffs, nicht die Absicht.

Die überzeugendste Antwort auf diese Fragen ist keine Zusicherung, sondern eine, die Sie selbst nachmessen können. Wenn ein Hersteller Ihnen dabei hilft, ist das ein gutes Zeichen. Wenn er es schwer macht, ist es ein Punkt für Ihre Risikoanalyse.

Die Einordnung der Fernwartung stammt aus dem Kurzpapier Nr. 13 "Auftragsverarbeitung, Art. 28 DS-GVO" der Datenschutzkonferenz, Stand 17.12.2018, abgerufen am 8. Oktober 2026. Kurzpapiere geben die Auffassung der deutschen Aufsichtsbehörden wieder und stehen unter dem Vorbehalt einer abweichenden Auslegung durch den Europäischen Datenschutzausschuss.