Wer in einer Werkstatt des VW-Konzerns Diagnosetester betreut, kennt die Stelle: ODIS soll auf eine neue Version, und der Vorgang verlangt Rechte, die der Mechaniker an der Hebebühne nicht hat und auch nicht haben soll. Dieser Beitrag ordnet ein, warum das so ist und welche Wege es gibt.
Warum ODIS überhaupt Systemrechte braucht
Installation, Update und Deinstallation von ODIS greifen an Stellen des Systems ein, die einem gewöhnlichen Benutzerkonto verschlossen sind: Programmverzeichnisse, Dienste, Registrierung, Gerätetreiber für das Fahrzeug-Interface. Das ist keine Schikane, sondern genau die Trennung, die verhindert, dass beliebige Anwendungen am System schrauben.
Die Folge im Alltag: Der Vorgang bleibt am Personal hängen, das die Rechte hat – der IT oder einem Dienstleister. Der Tester steht so lange, oder jemand fährt hin.
Die drei üblichen Wege im Betrieb
1. Jemand mit Adminrechten meldet sich an
Der direkteste und im Ergebnis teuerste Weg. Er bindet für jeden einzelnen Tester Zeit von jemandem, der sie an anderer Stelle braucht, und skaliert nicht: Bei zwanzig Testern an drei Standorten wird aus einem Releasewechsel eine Tagesaufgabe.
2. Das Adminkennwort wandert in die Werkstatt
Kommt vor, und man versteht warum. Nur: Ein Kennwort, das mehrere Personen kennen, ist keines mehr. Es steht dann irgendwann auf einem Zettel am Monitor, gilt womöglich auf allen Testern, und niemand kann später nachvollziehen, wer was installiert hat. Für einen Betrieb, der auf Nachweisbarkeit angewiesen ist, ist das die schlechteste der drei Möglichkeiten.
3. Ein Dienst erledigt die Ausführung
Der Weg, den Softwareverteilung seit jeher geht: Auf dem Rechner läuft ein Dienst im Systemkontext. Der angemeldete Benutzer stößt den Vorgang nur an – ausgeführt wird er vom Dienst. Der Benutzer bekommt dadurch keine erweiterten Rechte; er darf lediglich eine genau umrissene Aufgabe auslösen.
Damit ist die Trennung sauber: Rechte bleiben, wo sie hingehören, und die Arbeit findet dort statt, wo der Tester steht.
Worauf es dabei ankommt: Ein solcher Dienst darf nicht beliebige Programme starten können, sonst hat man die Rechtetrennung durch die Hintertür wieder aufgehoben. Er sollte ausschließlich definierte Vorgänge ausführen und nur Dateien verarbeiten, deren Herkunft überprüfbar ist.
Woher die Installationsdateien kommen
Die Dateien liegen im Konzernumfeld auf dem Mirrorserver beziehungsweise der D³ EdgeBox. Von Hand bedeutet das: sich durch die WebDAV-Verzeichnisse klicken, die richtige Fassung finden, herunterladen, an den Tester bringen. Automatisiert holt der Dienst sie direkt.
Wichtig ist in beiden Fällen die Prüfung des Herausgeberzertifikats: Nur so ist sichergestellt, dass die Datei tatsächlich vom Hersteller stammt und unterwegs nicht verändert wurde. Mehr dazu im Beitrag über D³ EdgeBox und Mirrorserver.
Der blinde Fleck: Werkstattausrüstung oder IT?
Hier liegt der eigentliche Kern – und er hat wenig mit Bequemlichkeit zu tun. In vielen Betrieben laufen Diagnosetester unter „Werkstattausrüstung". Sie wurden mit der Hebebühne und dem Achsmessgerät beschafft, stehen in der Anlagenbuchhaltung neben dem Bremsenprüfstand und tauchen in der IT-Betrachtung nicht auf.
Technisch ist ein Diagnosetester aber genau das, was ein IT-Sicherheitsbeauftragter sonst sehr genau anschaut: ein Windows-Rechner im Firmennetz, mit Zugang zu Herstellersystemen – und mit privilegiertem Zugriff auf die Fahrzeugelektronik. Er ist damit Werkzeug und Angriffsfläche zugleich.
Was daraus in der Praxis folgt, kennt jeder, der einmal hingesehen hat:
Keiner weiß, wie viele es sind. Diagnosetester stehen selten vollständig in der Bestandsführung. Wer sie zählen will, geht durch die Werkstatt.
Der Stand ist unbekannt. Welche Version läuft wo, seit wann, mit welchen Marken? Ohne zentrale Übersicht ist das eine Frage, die man nur vor Ort beantwortet.
Zugänge sind geteilt. Damit die Werkstatt arbeitsfähig bleibt, kursiert das Adminkennwort – oft dasselbe auf allen Geräten, oft seit Jahren.
Niemand fühlt sich zuständig. Die IT sagt Werkstatt, die Werkstatt sagt IT. Das Gerät fällt zwischen die Stühle – und mit ihm die Absicherung.
Das ist die Definition von Schatten-IT, nur ohne den üblichen Beigeschmack: Niemand hat sich hier an der IT vorbei etwas beschafft. Das Gerät wurde nur nie als IT eingeordnet.
Warum das mehr ist als ein Ordnungsproblem
Ein Diagnosetester hat eine Eigenschaft, die ihn von jedem Büro-PC unterscheidet: Er darf Steuergeräte beschreiben. Wer ihn kontrolliert, steht nicht vor der Fahrzeugelektronik, sondern hat bereits das Werkzeug in der Hand, mit dem sie verändert wird. Dazu kommt der Zugang zu Herstellersystemen und die auf dem Gerät liegende Lizenz.
Ein Gerät, das niemand inventarisiert, dessen Softwarestand niemand kennt und dessen Administratorkennwort mehrere Leute kennen, ist deshalb kein Randthema. Es ist die Verbindung zwischen Ihrem Netz und dem Fahrzeug des Kunden.
Was die Regulatorik dazu sagt – und was nicht
Zwei UNECE-Regelungen prägen das Umfeld: UN R155 verlangt vom Fahrzeughersteller ein Managementsystem für Cybersicherheit, UN R156 eines für Software-Updates. Beide sind seit 2021 in Kraft und Voraussetzung für die Typgenehmigung.
Der Ehrlichkeit halber: Adressat dieser Regelungen ist der Hersteller, nicht Ihr Betrieb. Sie werden als Werkstatt nicht nach R155 oder R156 zertifiziert. Wer Ihnen etwas anderes erzählt, verkauft Ihnen etwas.
Relevant ist der Umweg: Der Hersteller muss nachweisen, dass Software kontrolliert und nachvollziehbar ins Fahrzeug gelangt – und im Servicefall führt dieser Weg über Ihren Diagnosetester. Was der Hersteller belegen muss, gibt er als Anforderung an den Handel weiter. Deshalb wird die Aktualität von ODIS abgefragt, deshalb hängen Werkstattbonus und Anerkennung im Gewährleistungsfall daran.
Wer im Konzernumfeld zusätzlich mit sensiblen Daten arbeitet, kennt TISAX aus einer anderen Richtung – dort geht es um ein Informationssicherheits-Managementsystem nach dem Vorbild der ISO 27001. Auch das trifft nicht jeden Handelsbetrieb, verschiebt aber die Erwartungshaltung: Nachweisbarkeit wird zur Normalität.
Was ein ITSB konkret sehen will
Wenn Sie das Thema intern vorbringen, sind es erfahrungsgemäß vier Fragen – und alle vier lassen sich ohne großes Projekt beantworten:
Vollständiger Bestand. Welche Geräte gibt es, an welchem Standort, seit wann zuletzt gesehen?
Bekannter Softwarestand. Welche Version läuft, wie alt ist sie, welche Geräte hängen zurück?
Keine geteilten Administratorkonten. Aktualisieren, ohne Rechte weiterzugeben – das ist der Punkt, an dem die technische Lösung und die Sicherheitsanforderung zusammenfallen.
Nachvollziehbarkeit. Wer hat wann welche Version aufgespielt? Diese Frage kommt nicht im Alltag, sondern im Streitfall.
Bemerkenswert ist, dass genau die Maßnahme, die der Werkstatt Zeit spart – Aktualisieren ohne Administratoranmeldung –, zugleich die ist, die der Sicherheitsbeauftragte sehen will. Solche Fälle sind selten. Meistens stehen sich Bequemlichkeit und Absicherung im Weg.
Was nach dem Update oft vergessen wird
Drei Punkte, die im Tagesgeschäft regelmäßig liegen bleiben:
Aufräumen der Altfassung. Reste der vorherigen Version bleiben sonst liegen und führen später zu Fehlerbildern, die niemand mehr zuordnet.
Nachsehen, ob es geklappt hat. Ein Update, das durchgelaufen zu sein scheint, ist noch keines. Ohne Kontrolle der tatsächlich installierten Version fällt es erst auf, wenn ein Fahrzeug am Tester hängt.
Festhalten, was gemacht wurde. Wer wann welche Version installiert hat, ist genau dann gefragt, wenn ein Gewährleistungsfall zur Diskussion steht.
Warum sich der Aufwand lohnt
Die Hersteller erwarten für Arbeiten im Service- und Gewährleistungsumfeld eine aktuelle ODIS-Version. Bleiben Updates liegen, kann das die Anerkennung durch den Hersteller beeinträchtigen; bei Gewährleistungsfällen sind Abzüge möglich. Die genauen Vorgaben unterscheiden sich je nach Hersteller und Vertrag – ein Blick in die eigenen Unterlagen lohnt sich.
Der Aufwand dafür ist kein Nebenschauplatz. Wie er sich zusammensetzt, steht im Beitrag Was ein ODIS-Releasewechsel wirklich kostet.