IT-Audit in der Fertigung: ERP, MES, Integrationen und Legacy-Systeme prüfen
Ein IT-Audit in der Fertigung soll in der Regel zwei grundlegende Fragen beantworten: Was läuft aktuell tatsächlich in der Produktion und im Backoffice? Und wie kommunizieren all diese Systeme miteinander? Um das herauszufinden, sind meist technische Forensik – etwa das Prüfen von Konfigurationsdateien und das Nachverfolgen von Batch-Jobs – sowie eine Art organisatorische Archäologie erforderlich, beispielsweise um zu verstehen, warum eine Tabelle aus dem Jahr 2019 noch immer als verbindliche Datenquelle gilt.
Das Chudovo-Team ist diesen Herausforderungen bereits bei Audits von Fertigungs-IT-Infrastrukturen begegnet. In diesem Leitfaden zeigen wir, wie das Team solche Systemlandschaften untersucht hat, und beleuchten dabei Beispiele aus der Praxis sowie typische Probleme, die während eines Audits zum Vorschein kommen.
Wo anfangen?
Fertigungs-IT-Landschaften umfassen in der Regel verschiedene Bereiche: Geschäftssysteme wie ERP- und Finanzlösungen, Produktionssysteme wie MES, SCADA und Historian-Systeme, Lager- und Logistikplattformen sowie individuelle Anwendungen, die Lücken zwischen diesen Systemen schließen. Um all diese Bereiche abzudecken, beginnt das Chudovo-Team die Analyse der Fertigungs-IT-Landschaft in der Regel mit der Erstellung einer Ist-Zustandsübersicht. Eine erste grobe Version sieht beispielsweise wie in der folgenden Abbildung aus:
Für die Erstellung dieser Übersicht können zunächst erste Interviews geführt werden. Anschließend sollte das Team die dabei gewonnenen Informationen jedoch anhand von Anwendungseinstellungen, Serverinventaren, Netzwerkregeln, geplanten Jobs, Datenbankverbindungen, API-Gateways, Monitoring-Tools und Quellcode-Repositories überprüfen.
Bei einem Software-Audit in der Fertigung ist es außerdem sinnvoll, die wichtigsten Informationen zu jedem System zu dokumentieren. Dazu gehören beispielsweise Hauptzweck, Verantwortliche, Hosting-Standort, Version, Supportstatus, Authentifizierungsmethode, Produktionskritikalität und Abhängigkeiten. Dabei können auch Anwendungen zum Vorschein kommen, die weiterhin produktiv genutzt werden, obwohl sie offiziell niemand mehr betreut, ihr Quellcode nicht mehr verfügbar ist oder der Vertrag mit dem Anbieter bereits ausgelaufen ist. Netzwerk- und Datenbankaktivitäten können zudem Integrationen sichtbar machen, die in der offiziellen Dokumentation nie erfasst wurden.
Infrastruktur und Standortvernetzung prüfen
Die Übersicht zeigt nur einen Teil des Gesamtbildes. Im nächsten Schritt folgt eine gezielte Bewertung der IT-Infrastruktur, bei der dokumentiert wird, wo jedes kritische System betrieben wird. Dazu gehören das jeweilige Betriebssystem, die Netzwerkzone sowie Verbindungen zu physischen Servern, virtuellen Maschinen, Cloud-Ressourcen oder Industrie-PCs. Ebenso wichtig ist es, die Netzwerkpfade zwischen Produktionssystemen, Büros, Lagern und Cloud-Diensten nachzuverfolgen. Ein MES kann beispielsweise über redundante Anwendungsserver verfügen und dennoch von einem einzigen Switch, DNS-Server, einer Firewall oder einem VPN abhängig sein.
Auch Zertifikats- und Zeitsynchronisierungsdienste können die Authentifizierung oder Ereignisverarbeitung zum Stillstand bringen, obwohl alle Anwendungen auf den ersten Blick weiterhin ordnungsgemäß laufen.
Ein weiterer wichtiger Bestandteil eines IT-Infrastruktur-Audits in der Fertigung ist die Erfassung der IT/OT-Schnittstellen. Dazu sollte das Team Anbieter-VPNs, Jump-Server, Supportkonten und Firewall-Regeln separat prüfen. Für jede Verbindung sollte dokumentiert werden, wer dafür verantwortlich ist, ob Aktivitäten protokolliert werden und wie sich der Zugriff bei Bedarf widerrufen lässt. Intrusive Scans oder aktive Tests an SPS-Systemen erfordern eine separate Planung.
Abhängigkeiten zwischen Produktions- und Geschäftssystemen
Abhängigkeiten verlaufen nicht immer nur in eine Richtung. Ein MES kann beispielsweise Fertigungsaufträge aus einem ERP erhalten und Produktionsdaten für die Kostenrechnung zurückgeben, während SCADA Zählerstände über das MES oder über eine undokumentierte separate Integration übermittelt. Solche Abläufe sind nicht immer offensichtlich oder ausreichend dokumentiert und können daher im Auditbericht übersehen werden. Aus diesem Grund sollten Abhängigkeiten immer in beide Richtungen nachverfolgt werden.
Ebenso wichtig ist es, mögliche Fehlerpfade zu berücksichtigen. Eine Verbindung kann jederzeit ausfallen. Daher muss geklärt werden, ob die Produktion in diesem Fall stoppt, vorübergehend weiterläuft oder Daten erzeugt, die später abgeglichen werden müssen. Nur so lässt sich beurteilen, wie sich das System nach einem schwerwiegenden Ausfall wiederherstellen lässt.
Prüfung der Integrationsschicht
In Fertigungsumgebungen sammeln sich im Laufe der Zeit häufig unterschiedliche Integrationsmethoden an. Das geschieht meist schrittweise: Eine neue Integration wird hinzugefügt, während die alte nur selten entfernt wird. Bei der Überprüfung von Systemintegrationen in der Fertigung findet sich daher häufig eine Mischung verschiedener Ansätze: REST- oder SOAP-APIs zwischen neueren Systemen, Middleware-Plattformen wie MuleSoft oder Boomi sowie unternehmenseigene Message-Busse, direkte Datenbankverbindungen, bei denen ein System Daten direkt aus den Tabellen eines anderen Systems liest oder dort hineinschreibt, Batch-Jobs, die häufig über Nacht CSV- oder Fixed-Width-Dateien zwischen Servern übertragen, sowie manuelle Dateiaustausche – etwa wenn jemand einen Bericht exportiert und per E-Mail versendet oder auf einem gemeinsamen Laufwerk ablegt.
Ein sinnvoller Ausgangspunkt ist eine Liste aller geplanten Jobs zusammen mit den wichtigsten Metadaten. Dazu gehören beispielsweise Verantwortliche, Trigger, Ein- und Ausgaben, Zugangsdaten, nachgelagerte Abhängigkeiten, Wiederholungslogik bei Fehlern, die letzte erfolgreiche Ausführung und die Konfiguration von Warnmeldungen.
Das Team sollte außerdem weitere Hintergrundprozesse wie Windows Task Scheduler, SQL Server Agent, Kubernetes CronJobs und ERP-Scheduler prüfen. Auch Middleware-Workflows sowie andere externe Orchestrierungsplattformen innerhalb des Auditumfangs müssen berücksichtigt werden. Sobald die entsprechenden Definitionen erfasst sind, sollten sie mit den zugehörigen Skripten, Ausführungsprotokollen, Servicekonten sowie den Systemen abgeglichen werden, aus denen sie Daten lesen oder in die sie Daten schreiben.
Direkte Datenbankverbindungen verdienen besondere Aufmerksamkeit. Wenn System A direkt in die Datenbank von System B schreibt, ist ein Upgrade von System B nicht mehr nur eine Frage des Deployments. Es wird zu einer Koordinationsaufgabe.
Nicht unterstützte Technologien und Legacy-Komponenten identifizieren
Produktionsanlagen sind oft über Jahrzehnte hinweg im Einsatz. Die Software, die diese Anlagen steuert, bleibt daher häufig deutlich länger in Betrieb, als sie vom Hersteller unterstützt wird. Aufgrund dieser unterschiedlichen Erneuerungszyklen lassen sich Legacy-Systeme in der Fertigung nicht allein anhand ihres Alters bewerten.
Bei einem Audit sollte unter anderem auf folgende Punkte geachtet werden:
- Betriebssysteme, deren Support bereits ausgelaufen ist, beispielsweise Windows Server 2008 oder nicht mehr unterstützte Installationen von Windows Server 2012.
- Datenbankversionen, für die keine Sicherheitsupdates mehr bereitgestellt werden.
- SCADA-/HMI-Software, die an bestimmte Hardware gebunden ist und sich nicht ohne eine umfassende Aktualisierung der Produktionslinie ersetzen lässt.
- Individuelle Anwendungen, für die intern kein entsprechendes Fachwissen mehr vorhanden ist.
Der Erneuerungszyklus von Produktionsanlagen ist deutlich länger als der klassischer Büro-IT. Das macht eine solche Umgebung nicht automatisch gut oder schlecht. Ein Audit sollte vielmehr ermitteln, welche Systeme sich nicht ohne erhebliche Risiken verändern lassen und welche problemlos noch einen weiteren Zyklus weiterbetrieben werden können.
Datenflüsse, Duplikate und Inkonsistenzen
Sobald eine Übersicht der Integrationen vorliegt, muss im Rahmen des Audits geklärt werden, wo die Daten tatsächlich gespeichert sind und ob dieselben Informationen an mehreren Stellen vorliegen. Kundendaten befinden sich beispielsweise häufig sowohl im ERP- als auch im CRM-System, ohne dass zwischen beiden ein geregelter Abgleich stattfindet. Wenn eine Synchronisierung nur einmal täglich erfolgt, können die Bestandsdaten im WMS und im ERP voneinander abweichen. Produktstammdaten werden mitunter separat in MES und ERP gepflegt, wodurch sich über Monate hinweg Abweichungen entwickeln können.
Das Chudovo-Team verwendet hierfür eine einfache Audit-Methode: Fünf oder sechs kritische Datenobjekte – beispielsweise Materialstammdaten, Fertigungsaufträge, Lagerorte, Kunden und Lieferanten – werden ausgewählt und anschließend über die gesamte IT-Landschaft hinweg nachverfolgt. Dabei wird dokumentiert, wo die jeweiligen Daten erstellt, aktualisiert und gelesen werden.
Die folgende Abfrage vergleicht beispielsweise Bestands-Snapshots, die aus ERP und WMS exportiert wurden:
SELECT
COALESCE(erp.material_id, wms.material_id) AS material_id,
erp.quantity AS erp_quantity,
wms.quantity AS wms_quantity,
COALESCE(erp.quantity, 0) - COALESCE(wms.quantity, 0) AS difference
FROM erp_inventory_snapshot erp
FULL OUTER JOIN wms_inventory_snapshot wms
ON erp.material_id = wms.material_id
AND erp.location_id = wms.location_id
WHERE COALESCE(erp.quantity, 0) <> COALESCE(wms.quantity, 0);Authentifizierung, Berechtigungen und Systemzugriffe
Die Zugriffskontrolle ist ein gutes Beispiel dafür, dass Fertigungsumgebungen der klassischen Büro-IT in diesem Bereich häufig um Jahre hinterherhinken. Bei Audits zeigt sich beispielsweise oft, dass ein einziges Servicekonto für mehrere Integrationen verwendet wird. Dadurch lässt sich später nicht mehr nachvollziehen, welcher Job eine bestimmte Änderung vorgenommen hat. Ein weiteres typisches Problem sind generische Benutzerkonten für Terminals in der Produktion, deren Sitzungen ohne zeitliche Begrenzung geöffnet bleiben.
Zentrale Identity Provider, die die Anmeldung bei ERP, MES und WMS bündeln, sind eher die Ausnahme als die Regel. API-Schlüssel werden teilweise direkt in Skripten hinterlegt und liegen im Klartext auf gemeinsam genutzten Laufwerken, wo sie für andere Benutzer zugänglich sein können.
Was sollte zuerst geprüft werden? Zunächst muss erfasst werden, wer oder was auf die einzelnen Systeme zugreifen kann und welche Zugangsdaten dafür verwendet werden. Unzureichend abgegrenzte Zugriffsrechte stellen nicht nur ein Sicherheitsrisiko dar. Sie erschweren auch die Modernisierung: Änderungen an einem System mit unklaren Zugriffsstrukturen verlangsamen Tests und erhöhen die Risiken bei einem Rollback.
Single Points of Failure
In vielen Fertigungs-IT-Landschaften lassen sich kritische Prozesse finden, die unbemerkt von einem einzigen Server, Skript oder einer einzelnen Person abhängen. Beispiele dafür sind ein einzelner On-Premises-Datenbankserver, auf dem sowohl das MES als auch der Historian laufen, ein VPN-Tunnel, über den der gesamte Datenverkehr zwischen Werk und Cloud geleitet wird, oder ein einzelner Entwickler, der vor Jahren die Middleware-Schicht aufgebaut, aber nie dokumentiert hat. Entscheidend ist, was passiert, wenn eine dieser Komponenten ausfällt oder die verantwortliche Person nicht erreichbar ist. Wenn die Produktion in einem solchen Fall schlicht zum Stillstand kommt, sollte dieser Befund ganz oben auf der Prioritätenliste stehen.
Deployment, Monitoring, Backups und Disaster Recovery
Dieser Bereich ist genauso wichtig wie die Integrationsdiagramme – in manchen Fällen sogar wichtiger. Zunächst sollte geprüft werden, wie Code- und Konfigurationsänderungen in die Produktionsumgebung ausgerollt werden und ob dieser Prozess dokumentiert ist.
Außerdem muss geklärt werden, ob kritische Integrationen überwacht werden oder ob Fehler erst auffallen, wenn beispielsweise drei Tage später fehlende Daten bemerkt werden.
Auch die Häufigkeit von Backups sollte separat analysiert werden. Noch wichtiger ist die Frage, ob die Wiederherstellung tatsächlich getestet wurde. Während für ERP-Systeme häufig solide Backup-Richtlinien vorhanden sind, fehlen für MES oder Historian-Datenbanken nicht selten entsprechende Backup- und Wiederherstellungspläne.
Technische Schulden als Hindernis für die Modernisierung
Ergebnisse priorisieren
Die Priorität sollte nicht allein anhand des technischen Schweregrads bestimmt werden. Jeder Befund sollte auch im jeweiligen betrieblichen Kontext bewertet und durch konkrete Nachweise belegt werden.
Ein sinnvoller Ansatz ist ein praxisorientiertes Risikoregister, in dem für jedes betroffene System relevante Informationen erfasst werden, etwa die technische Ursache, vor- und nachgelagerte Abhängigkeiten, die fachlich verantwortliche Person sowie verfügbare Workarounds. Sobald alle Befunde erfasst sind, kann das Team sie bewerten und daraus die Reihenfolge der Bearbeitung ableiten. Dabei können verschiedene Faktoren berücksichtigt werden: Auswirkungen auf die Produktion, Ausfallwahrscheinlichkeit, Erkennung und Wiederherstellung, Umfang der Abhängigkeiten – also betroffene Systeme, Standorte, Produktionslinien und Teams –, Wartbarkeit und Supportfähigkeit einschließlich Herstellersupport, Dokumentation und intern verfügbarem Fachwissen sowie die Auswirkungen auf Modernisierungsvorhaben, beispielsweise ob ein Problem Änderungen an ERP, MES oder Infrastruktur blockiert.
Modernisierungs-Roadmap
Eine sinnvolle Roadmap lässt sich in vier Phasen unterteilen:
Stabilisieren
Im ersten Schritt werden Lücken bei der Wiederherstellung, ablaufende Zertifikate, nicht mehr unterstützte Komponenten mit unmittelbarem Risiko, fehleranfällige Jobs sowie nicht überwachte produktionskritische Integrationen adressiert.
Dokumentieren und isolieren
In dieser Phase werden Verantwortlichkeiten festgelegt, unnötige Zugriffe eingeschränkt, Betriebsabläufe dokumentiert und Systeme isoliert, die noch nicht ersetzt werden können.
Entkoppeln
Direkte Datenbankzugriffe und Punkt-zu-Punkt-Skripte werden durch unterstützte APIs, Queues oder klar definierte Middleware-Schnittstellen ersetzt, sofern dies einen konkreten Vorteil für die geplante Migration bietet.
Modernisieren
Im letzten Schritt werden ERP, MES, Infrastruktur und individuelle Anwendungen entsprechend ihrer Abhängigkeiten migriert. Anschließend können temporäre Übergangslösungen und redundante Datenspeicher außer Betrieb genommen werden.
Mehrere Punkte der Roadmap können von derselben technischen Änderung abhängen. Ein ERP-Audit kann beispielsweise zeigen, dass die neue Plattform grundsätzlich einsatzbereit ist, während undokumentierte Anwendungen oder Prozesse, die direkt auf die Datenbank zugreifen, einen sicheren Umstieg weiterhin verhindern. Diese Abhängigkeiten müssen zunächst identifiziert und auf die neue Lösung umgestellt werden, bevor das alte ERP außer Betrieb genommen werden kann.
Die Modernisierung von Legacy-Systemen in der Fertigung lässt sich nur selten in einem einzigen großen Release umsetzen. Produktionsstandorte haben Wartungsfenster, Produktionsziele und Vorgaben von Anbietern, während bestimmte Anlagen noch über Jahre hinweg in Betrieb bleiben können. Eine gute Roadmap sollte diese Rahmenbedingungen berücksichtigen und nach jeder Phase einen sicheren Zwischenzustand definieren – nicht nur den angestrebten Endzustand.
