Purdue-Modell
Das Purdue-Modell ordnet die Fabrik in Ebenen: unten die Sensorik, oben die Büro-IT — dazwischen die DMZ als Schleuse.
Das Purdue-Modell ordnet eine Fabrik in Ebenen: unten die Sensoren und Aktoren (Level 0), oben die Unternehmens-IT (Level 4/5).
// Teste dich
Wie dürfen Daten im Purdue-Modell fliessen?
In 30 Sekunden
Das Purdue-Modell ist die klassische Referenzarchitektur für Industrie-Netzwerke. Es teilt eine Fabrik in Ebenen ein: von den Sensoren und Aktoren (Level 0) über Steuerungen, Leitsysteme und Betriebsleitebene bis zur Unternehmens-IT (Level 4/5). Die Kernregel: Daten fliessen nur zwischen benachbarten Ebenen, nie quer durch. Zwischen Produktion (OT) und Büro-IT liegt mit Level 3.5 eine DMZ (entmilitarisierte Zone) als kontrollierte Schleuse. Das Modell ist über dreissig Jahre alt — und trotzdem bis heute die gemeinsame Denk-Landkarte, wenn IT- und OT-Leute über Netztrennung sprechen.
Stellen Sie sich ein Werksgebäude mit Stockwerken und genau einem Empfang vor. In der Werkstatt im Erdgeschoss wird gearbeitet, oben sitzt die Verwaltung. Post von aussen landet nie direkt an der Werkbank, sondern immer zuerst beim Empfang, der sie prüft und weiterreicht. Genau so funktioniert die DMZ im Purdue-Modell: Sie ist der Empfang zwischen Büro-IT und Produktion — wer sie umgeht, steht unangemeldet an der Maschine.
Wo trifft man Purdue-Modell an?
Netz-Segmentierung in der Fertigung
Der Hauptanwendungsfall: Das Produktionsnetz wird nach Ebenen in Firewall-Zonen unterteilt. Beispiel: Die SPS-Ebene ist vom Büronetz getrennt, Fernzugriffe laufen nur über einen Sprungserver in der DMZ.
Energie und Versorger
Leittechnik und Verwaltungs-IT werden strikt getrennt. Beispiel: Das SCADA-System eines Wasserwerks tauscht Daten mit der Verwaltung nur über gespiegelte Server in der Schleuse aus.
Pharma, Chemie und Lebensmittel
Die Betriebsleitebene (MES, Manufacturing Execution System) auf Level 3 verbindet Rezeptur- und Chargendaten mit der Produktion — sauber getrennt vom ERP auf Level 4. Beispiel: Chargenfreigaben wandern kontrolliert über die DMZ.
Sicherheits-Audits und Risikoanalysen
Das Modell dient als Referenzbild, um Ist-Netze zu bewerten. Beispiel: Ein Audit zeichnet alle Verbindungen ein und markiert jede Quer-Verbindung, die Ebenen überspringt, als Befund.
Neu- und Umbauprojekte
Bei neuen Anlagen oder Modernisierungen liefert das Modell die Zielarchitektur. Beispiel: Der Integrator plant von Anfang an, welche Systeme in welche Ebene gehören und wo die Schleuse sitzt.
Verständigung zwischen IT und OT
Als gemeinsame Landkarte in Projekten und Schulungen. Beispiel: «Das gehört auf Level 2» ist für beide Seiten sofort verständlich — ohne Diskussion über Herstellernamen.
Gut geeignet für
- Für den Einstieg in OT-Security, weil das Modell mit wenigen Ebenen ein klares, leicht erklärbares Denkmodell liefert.
- Als gemeinsame Sprache zwischen IT- und OT-Verantwortlichen, weil die Ebenen-Begriffe herstellerneutral und seit Jahrzehnten etabliert sind.
- Für Segmentierungs-Projekte, weil sich die Ebenen direkt auf Firewall-Zonen und Netzbereiche abbilden lassen.
- Für Audits und Risikoanalysen, weil verbotene Quer-Verbindungen (etwa Büro-IT direkt auf die SPS) im Ebenen-Bild sofort auffallen.
- Als Vorstufe zu IEC 62443, weil das Ebenen-Denken die Grundlage für das dortige Zonen- und Conduit-Konzept legt.
Weniger geeignet für
- Für Cloud- und IIoT-Architekturen mit Direktverbindungen vom Sensor in die Cloud, weil diese das strenge Nachbar-Ebenen-Prinzip bewusst umgehen; besser ergänzend Zero-Trust-Prinzipien und IEC-62443-Zonen anwenden.
- Als konkreter Massnahmenkatalog, weil das Modell nur eine Architektur beschreibt, aber keine Sicherheitsanforderungen definiert; dafür ist IEC 62443 die richtige Referenz.
- Als 1:1-Bauplan für historisch gewachsene, flache Netze, weil sich ein voller Ebenen-Stapel dort selten nachrüsten lässt; besser schrittweise Zonen bilden und zuerst die OT/IT-Schleuse einziehen.
- Für sehr kleine Anlagen mit einer Handvoll Geräten, weil sechs Ebenen dort Overkill sind; besser eine einfache Zwei-Zonen-Trennung mit Firewall.
Fakten
- Purdue Enterprise Reference Architecture (PERA)
- Theodore J. Williams, Purdue University, frühe 1990er-Jahre
- Feldebene: Sensoren und Aktoren am physischen Prozess
- Steuerung: SPS/PLC, die den Prozess in Echtzeit regeln
- Leitebene: HMI und SCADA — beobachten und bedienen
- Betriebsleitebene: MES, Historian, Produktionsplanung
- DMZ: kontrollierte Schleuse zwischen OT und IT (nachträglich ergänzt)
- Unternehmens-IT und Internet: ERP, E-Mail, Web
Im Detail
Woher das Modell kommt
Das Purdue-Modell stammt aus der Purdue Enterprise Reference Architecture (PERA), die Theodore J. Williams in den frühen 1990er-Jahren an der Purdue University entwickelte. Ursprünglich ging es gar nicht um Security, sondern um die saubere Gliederung von Produktionsunternehmen. Die Ebenen-Idee floss später in die Norm ISA-95/IEC 62264 ein — und wurde zur Standard-Landkarte, als Fabriknetze plötzlich mit Büronetzen und dem Internet verbunden wurden.
Die Ebenen im Überblick
Level 0 ist die physische Welt: Sensoren messen, Aktoren bewegen. Level 1 sind die Steuerungen (SPS, speicherprogrammierbare Steuerungen), die den Prozess im Millisekunden-Takt regeln. Level 2 ist die Leitebene mit HMI (Bedienbildschirmen) und SCADA-Systemen, von der aus Menschen beobachten und eingreifen. Level 3 ist die Betriebsleitebene mit MES und Datenarchiven (Historian), die Aufträge, Rezepte und Auswertungen verwaltet. Ganz oben, auf Level 4 und 5, liegen ERP, E-Mail und der Weg ins Internet — die klassische Büro-IT.
Die wichtigste Ebene ist eine halbe: Level 3.5
Die DMZ (entmilitarisierte Zone) zwischen OT und IT wurde dem Modell nachträglich hinzugefügt — als klar wurde, dass genau dieser Übergang der gefährlichste ist. In der DMZ stehen Systeme, die beide Seiten brauchen: gespiegelte Datenserver, Patch- und Update-Verteiler, Sprungserver für Fernwartung. Jede Verbindung endet in der DMZ und wird dort neu aufgebaut — es gibt keinen durchgehenden Kanal von der Büro-IT bis zur Steuerung. Wer Daten aus der Produktion will, holt sie von der Kopie in der Schleuse, nicht vom Original.
Die Kernregel: nur Nachbarn reden miteinander
Verkehr fliesst im Purdue-Modell nur zwischen benachbarten Ebenen. Ein ERP-System fragt nie direkt eine SPS ab, ein Sensor liefert nie direkt an die Büro-IT. Jede Ebene ist damit eine eigene Verteidigungslinie: Ein Angreifer, der ins Büronetz eindringt, steht nicht automatisch vor der Steuerung, sondern muss mehrere kontrollierte Übergänge überwinden. Genau diese Staffelung fehlte bei vielen realen Vorfällen — flache Netze, in denen ein verseuchter Büro-PC direkt die Anlage erreichte.
Grenzen: Cloud, IIoT und die flache Realität
Moderne Architekturen weichen das Modell auf: IIoT-Sensoren funken direkt in die Cloud, Edge-Gateways verbinden Maschinen mit Analyse-Plattformen, Fernwartung kommt per Mobilfunk an der DMZ vorbei. Das macht das Modell nicht wertlos — aber man darf es nicht als starres Gesetz lesen. Jeder gewollte Direktweg braucht einen eigenen, kontrollierten Übergang: authentifiziert, verschlüsselt, überwacht. Das Ebenen-Denken bleibt; die Schleusen wandern dorthin, wo die Daten tatsächlich fliessen.
Für die Praxis heisst das: Das Purdue-Modell ist der Startpunkt, nicht das Ziel. Wer seine Anlage einordnen will, zeichnet zuerst die eigenen Systeme auf die Ebenen und markiert jede Verbindung, die Ebenen überspringt. Danach liefert IEC 62443 mit Zonen, Conduits und Security Leveln das Werkzeug, um daraus konkrete Anforderungen zu machen.