Sie sind auf Seite 1von 24

DISKUSSIONSPAPIER

Sichere Kommunikation für Industrie 4.0


Impressum

Herausgeber Das Bundesministerium für Wirtschaft und


Bundesministerium für Wirtschaft Energie ist mit dem audit berufundfamilie®
und Energie (BMWi) für seine familienfreundliche Personalpolitik
Öffentlichkeitsarbeit ausgezeichnet worden. Das Zertifikat wird von
11019 Berlin der berufundfamilie gGmbH, einer Initiative
www.bmwi.de der Gemeinnützigen Hertie-Stiftung, verliehen.
Redaktionelle Verantwortung
Plattform Industrie 4.0
Bertolt-Brecht-Platz 3
10117 Berlin
Gestaltung und Produktion
PRpetuum GmbH, München
Stand
Juni 2017
Bildnachweis
Mimi Potter – Fotolia (Titel)
Diese und weitere Broschüren erhalten Sie bei:
Bundesministerium für Wirtschaft und Energie
Diese Broschüre ist Teil der Öffentlichkeitsarbeit des Referat Öffentlichkeitsarbeit
Bundes­ministeriums für Wirtschaft und Energie. E-Mail: publikationen@bundesregierung.de
Sie wird kostenlos abgegeben und ist nicht zum www.bmwi.de
Verkauf bestimmt. Nicht zulässig ist die Verteilung
auf Wahlveranstaltungen und an Informationsständen Zentraler Bestellservice:
der Parteien sowie das Einlegen, Aufdrucken oder Telefon: 030 182722721
Aufkleben von Informationen oder Werbemitteln. Bestellfax: 030 18102722721
2

Inhalt

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Was ist neu bei Industrie 4.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Kommunikationsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Allgemeine Anforderungen an die Kommunikation und Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Industrie 4.0-Komponenten tauschen sich aus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Kommunikationsstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Ende-zu-Ende-Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Kommunikation über Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Publish-Subscribe-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Kommunikation mit dem Netzwerk als Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Verwendbarkeit verschiedener Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Sicherheitsanforderungen und -mechanismen auf den Schichten der Kommunikationsstacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


Netzwerks-Zugangs-Schicht (Data-Link Layer und Physical Layer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Netzwerkschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Transportschicht und Ende-zu-Ende-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Prozess- und Businesslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Anwendungsbeispiel: Auftragsgesteuerte Produktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Abbildungsverzeichnis

Abbildung 1: Kommunikationsbeziehungen bei Industrie 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3


Abbildung 2: Office-Bereich und Produktionsebene wirken verstärkt zusammen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Abbildung 3: Security Policy für Industrie 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Abbildung 4: Industrie 4.0-Komponente verwendet Protokollstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Abbildung 5: Kommunikationsaspekte nach Com4.0-Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Abbildung 6: Industrie 4.0-Komponenten kommunizieren Ende-zu-Ende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Abbildung 7: Industrie 4.0-Komponenten kommunizieren über Firewalls, Proxys oder Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Abbildung 8: Anbindung weiterer Komponenten über Industrie 4.0-Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Abbildung 9: Publish-Subscribe-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Abbildung 10: Industrie 4.0-Komponenten kommunizieren mit dem Netzwerk über erforderliche Eigenschaften . . . 11
Abbildung 11: Pluralität von Netzwerkprotokollen in Industrie 4.0-Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Abbildung 12: OPC UA hebt Security auf Applikationsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Abbildung 13: Auftragsgesteuerte Produktion eines kundenindividuellen Fahrradlenkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Abbildung 14: Kommunikationssequenz der Auftragsabwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Abbildung 15: Kommunikationsschritt 1 – Mögliche Übertragung einer Ausschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3

Einleitung

Industrie 4.0 schafft mit innovativen Konzepten und Vor- Was ist neu bei Industrie 4.0?
gehensweisen völlig neue Möglichkeiten in der Zusammen-
arbeit – insbesondere auch auf technischer Ebene. Anlagen, Während Automatisierungskomponenten wie zum Beispiel
Maschinen und Produkte interagieren, tauschen Daten aus Sensoren in Industrie 3.0 meistens im unternehmenseigenen
und korrespondieren stets. Dabei spielt es keine Rolle, ob Umfeld, also innerhalb der internen Sicherheitsdomäne,
mit einer Maschine in derselben Fabrikhalle oder mit einer kommunizieren, interagieren sie bei Industrie 4.0 über Unter­
Anlage in einem Betrieb auf der anderen Seite der Welt nehmensgrenzen hinweg (1) (Abbildung 1). Dabei müssen
kommuniziert wird. Doch das funktioniert nur, wenn tech- Kommunikationsbeziehungen erlauben, zwischen allen
nische Kommunikationsmechanismen dafür sorgen, dass Beteiligten Informationen auszutauschen oder Services
Industrie 4.0-Komponenten (Assets) sicher und interopera- bereitzustellen. Services sind beispielsweise Aktionen wie:
bel in Kontakt treten können. „Bitte messe die Temperatur“ oder „Fahre den Schlitten zehn
Zentimeter vor“. Eine Ende-zu-Ende-Netzwerkverbindung
Eine solche Industrie 4.0-konforme Kommunikation zu ist dabei jedoch nicht zwingend Voraussetzung.
erörtern – das ist Ziel des vorliegenden Diskussionspapiers.
Dabei liegt der Fokus klar auf den technischen Aspekten Funktionalität und Sicherheit – das sind die ausschlagge-
der sicheren Kommunikation. Anforderungen an die benden Aspekte, die die Kommunikation berücksichtigen
Organisation werden weitestgehend nicht betrachtet. Das muss. Im vorliegenden Dokument wird genau das disku-
Dokument richtet sich an Entscheider und Anwender im tiert: Wie muss die Art der Kommunikation ausgeprägt
Industrie 4.0-Kontext. Neben Rahmenbedingungen und sein, um zu funktionieren und sicher zu sein? Berücksich-
Leitprinzipien werden ihnen exemplarisch gewonnene tigt werden der Office-Bereich (Information Technology
Erkenntnisse zur Industrie 4.0-Kommunikation dargestellt, (IT)) und die Produktionsebene (Operations Technology
die die Ansprüche an eine sichere IT-Infrastruktur berück- (OT)). Die IT-Security des Office-Bereichs sichert die unter-
sichtigen. nehmensbezogenen Aufgaben und orientiert sich bei der

Abbildung 1: Kommunikationsbeziehungen bei Industrie 4.0

Unternehmen B Unternehmen A

Maschine
Maschine
Komponente Produkt Komponente
Produkt
Produkt

Komponente
Verwaltungs-
schale
CA
CA
Mensch

Trust
Center
Verwaltungs -
Daten Verwaltungs-
Unternehmen C schale
Verwaltungs
schale - Prozesse
schale

CA

Produkt

Stärker bei
Industrie 3.0 Industrie 4.0 Industrie 4.0 vertraut
4 EINLEITUNG

Kommunikation bisher vor allem auf den Schutz der Daten. schlüsselung verbieten. Werden globale Ende-zu-Ende-
Die Produktionsebene hingegen deckt die Automatisie- Security-Lösungen implementiert, müssen Vertrauensbe-
rungsaufgaben ab, bei denen vor allem die Kommunikation ziehungen neu definiert werden und für die Beteiligten
im Vordergrund steht, die echtzeitfähig und verfügbar sein transparent erkennbar und behandelbar sein. Vorhandene
muss. Denn: Ohne Kommunikation keine Produktion. Bei Kommunikationstechnologien werden zu einem globalen
Industrie 4.0 interagieren diese Bereiche immer stärker und industriellen Vertrauensmodell weiterentwickelt. Dabei gilt
wachsen zunehmend zusammen. Neben den bestehenden es, alle Seiten zu berücksichtigen: die Sicherheitsbedürf-
Anforderungen an die Sicherheit in beiden Bereichen ent- nisse der industriellen Partner und die Ansprüche auf nati-
stehen durch Industrie 4.0 weitere spezifische Bedarfe. Der onaler Ebene.
Grund: Die Kommunikation läuft verstärkt automatisiert
und unternehmensübergreifend ab (Abbildung 2). Die Herausforderung für eine sichere Industrie 4.0-Kom-
munikation: Es müssen Lösungen gefunden werden, die
einerseits auf vertrauenswürdigen Standards aufbauen, die
Herausforderungen langfristig mit der gesetzlich geregelten Norm übereinstim-
men. Andererseits müssen die Lösungen ausreichend flexi-
So wird die Art der Kommunikation zwischen verschiede- bel sein, um die Industrie mit ihren neuen Geschäftsmo-
nen Unternehmen, Staaten und Kontinenten zum kriti- dellen zu unterstützen. Daher ist es wichtig, regelmäßig
schen Erfolgsfaktor: Sichere, vertrauenswürdige technische neue Angriffsmöglichkeiten im Blick zu haben und zu
Prozesse bzw. Protokollstrukturen bei künftigen, durch die behandeln.
Vernetzung ermöglichten „Connected Services“ (zum Bei-
spiel vorausschauende Wartung) nehmen eine Schlüsselrolle Ergänzend bauen Maschine-zu-Maschine-Kommunikatio-
ein. Dabei sind neue nationale Einflüsse einzelner Handels- nen (M2M) künftig auf global anerkannten und durchgän-
partner auf technische Sicherheits- und Vertrauensregeln gigen Sicherheitskonzepten auf. Dazu erhalten Komponen-
von Bedeutung: Es gibt Länder, die beispielsweise Ver- ten, die als vertrauenswürdig eingestuft werden, definierte

Abbildung 2: Office-Bereich und Produktionsebene wirken verstärkt zusammen

IT/Office-Bereich OT/Produktionsebene
Vertraulichkeit von Daten Echtzeitfähigkeit
Integrität von Daten Verfügbarkeit der Dienste
Verfügbarkeit von Daten Integrität der Dienste
Vertraulichkeit der Daten

Industrie 4.0
Integritätsnachweis der Kommunikation
Authentizität der Kommunikationspartner
Vertrauenswürdige Verbindungen
Konfigurationsnachweise
Prüfungsnachweise
Isolation von Diensten
Hardware-basierte Sicherheit
Vorhersagbarkeit der Kommunikation
EINLEITUNG 5

Kennzeichen, so dass andere Anlagen oder Maschinen in lage künftiger Business Continuity für Unternehmen. Denn
Produktions- und Wertschöpfungsketten sie als geeignet sie stellen den Fortbestand der Unternehmen im Sinne
und sicher identifizieren können. Anhand dieser Kennzei- ökonomischer Nachhaltigkeit sicher. Folglich sind natio-
chen wird nachgewiesen, ob sie sich anforderungskonform nale Alleingänge riskant: Isolation und keine Möglichkeit,
verhalten und somit eine Kommunikation stattfinden an globalen hochautomatisierten Wertschöpfungsketten
kann und soll. In sicheren und hochverfügbaren Kommu- und Mehrwertdiensten teilzuhaben, können die Folge sein.
nikationsinfrastrukturen sind sie daher wesentliche Grund-

Wie begegnen wir dieser Herausforderung?

Idealerweise sind Plattform-Services direkter Bestandteil sicherer Kommunikation und können künftig selbst Produk­
tionsdaten wirksam vor unerwünschter Einsichtnahme oder Veränderung schützen bzw. Knowhow- und IP-Schutz auf
der Basis vertrauenswürdiger Digital-Rights-Management-Technologien (DRM) durchsetzen. Vertrauensanforderungen
in elektronische Verträge zwischen Maschinen einzubetten – dies wird künftig in der M2M-Kommunikation eine ent-
scheidende Rolle spielen 1.

Darüber hinaus wird es immer wichtiger, während und auch nach einer Kommunikation technisch zu erkennen, ob
sich die beteiligten Entitäten vertrauenswürdig verhalten – und nicht nur vor beziehungsweise während des Kommu­
nikationsaufbaus. Vor allem zum Schutz der Kommunikationspartner rückt die durchgängige, automatisierte Überwa-
chung der Semantik stärker in den Fokus. Sie beschreibt, was mit der jeweiligen Kommunikation bezweckt werden soll.
Globale Trust- und Plattform-Services müssen dafür sorgen, dass Hersteller, Systeme und Komponenten technisch
bewertet werden (Scoring), um vor, während, aber auch nach einer erfolgten Kommunikation automatisiert Gefahren-
quellen, wie eingeschleuste Viren, zu erkennen.

1 OpenFog Consortium (https://www.openfogconsortium.org/) – [Draft work on machine contracting]


6

Kommunikationsbeziehungen

Im Leitfaden für Geräteprofile in der Automatisierungstech- ●● Data access: rollenspezifischer Zugriff (Lesen, Lesen/
nik IEC TR 62390 (3) werden Profile für eine Geräteklasse Schreiben, Schreiben)
(zum Beispiel Temperatursensor) mit einer gemeinsamen
Menge von Funktionalitäten in einem vorgegebenen indus- ●● Communication interface (Ebene 5 – 7): OPC UA
triellen Gebiet definiert. In Anlehnung daran hat die Unter-
arbeitsgruppe „UAG Sichere Kommunikation für Industrie ●● Communication protocol (Ebenen 1 – 4): TLS
4.0“ das Verständnis für eine Sicherheitsrichtlinie (Security
Policy) für Industrie 4.0 entwickelt (Abbildung 3). Für Industrie 4.0-Komponenten, die durch ihre Verwal-
tungsschalen (VWS) abgebildet werden, ist es nicht mehr
Die Security Policy spricht alle Beziehungsebenen zwischen ausreichend, die Kommunikation auf Protokollebene abzu-
Industrie 4.0-Komponenten an. Sie soll die Interoperabilität stimmen (Abbildung 3). Auch Vereinbarungen über Rechte
auf allen Ebenen, die der IEC TR 62390 adressiert, sicherstel- (Wer darf was?), Vertrauensanker (zum Beispiel elektroni-
len. Beispielhafte Ausprägungen für diese Interoperabilität sche Schüssel) und Security-Profile sind notwendig.
wären:
Um eine Kooperation starten zu können, muss die Verwal-
●● Dynamic behaviour: Vertrauen in den gleichen neutralen tungsschale Informationen über die Security-Fähigkeiten
Trustanker, Security-Profile der Industrie 4.0-Komponenten bereitstellen. Nur so kann
gegenseitig geprüft werden, ob eine Zusammenarbeit mög-
●● Application functionality: Rechte eines Tenants/ lich ist (etwa bezüglich des noch zu definierenden Niveaus
Mandanten der Vertrauenswürdigkeit/Trustworthiness, wie im Doku-
ment „Security der Verwaltungsschale“, Plattform Industrie
●● Parameter semantics: Benutzer- und Rollenmodell 4.0/ZVEI 2017, diskutiert (4)).

●● Data types: Zertifikate, Security-Token Security-Anforderungen können technisch und soweit erfor­
derlich auch auf organisatorischer Ebene, zum Beispiel
durch Richtlinien, umgesetzt werden.

Abbildung 3: Security Policy für Industrie 4.0

Security Policy
Compatibility levels
Interchangeable Komponenten-
VWS Manager
Rechte-
Interoperable Manager

Interworkable
Interconnectable
Coexistent Asset
Device
feature Incompatible
Dynamic behavior (X) (X)
Application functionality X (X)
Parameter semantics X (X) Device profile
Data types X X (X)
Data access X X X (X) Communication
Communication interface profile
X X X X
Communication protocol X X X X X
KO M M U N I K AT I O N S B E Z I E H U N G E N 7

Um eine Industrie 4.0-konforme Kommunikation zu be­­ Allgemeine Anforderungen an die


schreiben, muss künftig ein Industrie 4.0-Kommunika­ Kommunikation und Architektur
tionsstack betrachtet werden (Abbildung 11), der sich nicht
ausschließlich auf die unteren Schichten des OSI-Schich- Die Kommunikationsbeziehungen zwischen Industrie
tenmodells beschränkt. Vielmehr gilt es, verstärkt die 4.0-Komponenten müssen eine Interaktion ermöglichen,
gesamte Interaktion und die ausgetauschten Inhalte zu die es den Komponenten gestattet, Daten auszutauschen
betrachten (Abbildung 4). und Dienste, die eine Automatisierung erlauben, mit den
notwendigen Eigenschaften bereitzustellen. Die vorliegen-
Ein Beispiel: Ein Messwert soll von Maschine A zu Maschine den Arbeiten hierzu beziehen sich auf das Interaktionsmo-
B übertragen werden. Um den Wert auf Netzwerkebene dell (5), die Netzkommunikation (6) und Servicearchitektu-
zuverlässig und sicher zu übertragen, stehen verschiedenste ren (7). Ausgangspunkt ist die Abbildung jeder Industrie
Protokolle zur Verfügung. Der Messwert könnte nun zum 4.0-Komponente durch deren Verwaltungsschale (8), die die
Beispiel durch eine sichere Übertragung und einen beglau- Industrie 4.0-Komponente beschreibt und Angebote wie
bigten Empfang authentifiziert werden. Die Beglaubigung Daten, Informationen und Dienste bereitstellt. Um diese
findet bereits an der Quelle statt, so dass die übertragene Angebote zu verwenden, gibt es bestimmte Anforderungen
Nachricht nicht nur den Messwert selbst, sondern auch die an die Kommunikation:
Beglaubigung enthält und somit die Echtheit des Mess-
werts bestätigt. Dadurch wäre es möglich, Anforderungen ●● Prinzipiell kann davon ausgegangen werden, dass der
an die sichere Übertragung zu reduzieren. Die Auswahl wesentliche Teil der Kommunikation über ein TCP/IP-
einer geeigneten Kombination von Sicherheit der Informa- Netzwerk erfolgen wird. Auf der Netzwerkschicht wird
tion und Sicherheit des Transports hängt vom Anwendungs­ zukünftig das Protokoll IPv6 eingesetzt (heute überwie-
fall ab. Im genannten Beispiel könnten es Informa­tionen gend noch das Protokoll IPv4). Dieses Protokoll ist die
beziehungsweise Bedingungen zum Zeitverhalten oder zur Basis für die Vernetzung von Industrie 4.0-Netzwerken,
verfügbaren Rechenleistung sein oder die Möglichkeiten denn es ermöglicht, dass beliebige Systeme des Office-
der späteren Nachweisführung. Bereichs und der Produktionsebene lokal und global

Abbildung 4: Industrie 4.0-Komponente verwendet Protokollstack

Protokollstack
Äußeres Protokoll
Komponenten-
VWS
UPC UA, ebXML, ...
Merkmale
Manager
Rechte-
Interaktion

Manager Services Oberes Security-Layer


Multi-Tier? UA Secure Conversation,
WS Secure Conversation

Identifikation

Inneres Protokoll
UA TCP, SOAP, ...
Authentifikation
API?

Kommunikationsprotokoll
HTTP, SMTP, ...
Netzwerkkommunikation

Qualitäten

Asset Vertraulichkeit
Integrität
Verfügbarkeit OSI-Layer 1-7
Unteres Security Layer
TLS, IPsec, ...
Latenz
Jitter
...

Echtzeit
TSN, Feldbusse

Physical Layer
Leitung, Funk, ...
8 KO M M U N I K AT I O N S B E Z I E H U N G E N

kommunizieren können. Auf dem IP-Protokoll setzen Industrie 4.0-Komponenten tauschen sich aus
verschiedene Protokolle der TCP/IP-Protokoll-Suite
auf. Über TCP oder UDP können Daten zuverlässig oder Sobald eine Ende-zu-Ende-Verbindung auf Netzwerk- und
un­zuverlässig übertragen werden. Weitere Protokolle Transportschicht besteht – indem TCP/IP und etwa OPC
erlauben es darüber hinaus, erste Interaktionsmodelle UA verwendet wurde –, können die logischen Schnittstellen
abzubilden. Architekturen wie OPC UA in der Produk­ der Industrie 4.0-Kommunikation – die Verwaltungsscha-
tionsebene oder Technologien wie Webservices und len – miteinander in Kontakt treten. Auch hier muss ein
SOAP sorgen dafür, dass formatierte Daten weitergege- Augenmerk auf Sicherheit und Effizienz gelegt werden.
ben und Aktionen angestoßen werden. Wer auf die Angebote (Daten, Informationen und Services)
der Verwaltungsschale zugreifen darf, wird durch ein Rech-
●● Da die grundlegende Netzwerkstruktur der TCP/IP- temodell geregelt (4), das im Konzept der Verwaltungs-
Netzwerke für Industrie 4.0-Kommunikation übernom- schale enthalten ist. Dafür muss der Kommunikationspart-
men wird, sind auch die damit zusammenhängenden ner identifiziert und authentifiziert werden. Wichtig ist
Voraussetzungen und Sicherheitsgedanken zu beachten. also, dass das zu verwendende Kommunikationsprotokoll
Im Office-Bereich existieren bereits jahrzehntelang etab- und der einzusetzende Kommunikationsstack entspre-
lierte Modelle, um diese Netze zu verwalten und zu chende Sicherheitsmechanismen bereitstellen.
sichern (siehe Abschnitt „Verwendbarkeit verschiedener
Protokolle“). Netzplanerische Aspekte wie eine restrik- Wie genau Kommunikationsbeziehungen aussehen, wird
tive Netzwerksegmentierung durch Firewalls, Access- über Anforderungen geregelt, die sich zum Beispiel im Zeit-
Control-Lists, VLANs und Network Access Control sind verhalten oder in Security-Anforderungen zu Vertraulich-
ebenso zu betrachten wie eine effektive operative Ereig- keit oder Integrität ausdrücken. Diese Anforderungen, wie
nisüberwachung, mit der das Netzwerk systematisch etwa „Ich brauche eine Antwort unter einer Millisekunde
beobachtet wird, um bei Auffälligkeiten zu reagieren. und sie muss digital signiert sein“, müssen sich, falls not-
Zusätzlich spielt auch die Sicherheit der unteren Schich- wendig, im Kommunikationsstack einstellen und während
ten im ISO/OSI-Modell eine Rolle (beispielsweise Ver- des gesamten Kommunikationsprozesses prüfen lassen: bei
schlüsselung von drahtlosen Netzwerken und Verbin- Aufbau, Verwendung (Statusabfrage) und nach Beendigung
dungen über öffentliche Netzwerke wie VPN). der Verbindung (Protokollierung). Das Kommunikations-

Abbildung 5: Kommunikationsaspekte nach Com4.0-Basic

Semantic Layer Services Models Data Structures

Message Model Data Streaming


Interaction Layer Transmission Interaction Publishing System
System System System .....

Transmission Layer Transmission System


(Communication System)
KO M M U N I K AT I O N S B E Z I E H U N G E N 9

stack muss dabei auch die Aushandlung/Bewertung höher- notwendige Infrastruktur aus Netzwerk und unterstützen-
wertiger Eigenschaften wie zum Beispiel die eines Sicher- den Diensten bereitgestellt werden – etwa zur Namensauf-
heitsprofils des Kommunikationspartners im Sinn einer lösung in IP-Adressen oder zum Identitätsmanagement.
„Vertrauenswürdigkeit/Trustworthiness“ (1) unterstützen
und sie mit dem Rechtemanagement der Verwaltungs-
schale (VWS) verknüpfen. Kommunikation über Gateways
In vielen Organisationen wird Kommunikation über Gate-
Im Dokument zu Kommunikationsmodellen des OpenAAS- ways geleitet, die ermöglichen, dass der Datenfluss kontrol-
Pro­­jekts, Com4.0-Basic (9), ist eine solche Struktur definiert liert und Domänen getrennt werden (Abbildung 7).
(Abbildung 5). Es gilt nun, die darin genannten „Interaction
und Transmission“-Layer in der weiteren Diskussion mit Komponenten oder Teilsysteme, die selbst nicht Industrie
der Darstellung in Abbildung 4 zu betrachten und zu einem 4.0-konform kommunizieren, können über entsprechende
abgestimmten Gesamtbild weiterzuentwickeln. Industrie 4.0-Gateways angebunden werden (Abbildung 8).
Diese Art der Anbindung ist notwendig, um bereits existie-
rende Installationen in die zukünftige Industrie 4.0-Welt zu
Kommunikationsstrukturen überführen.

In der Praxis ergeben sich unterschiedlichste Strukturen, Ein weiterer Fall: Es gibt Komponenten, die zu wenig
die die Kommunikation unterstützen muss – je nach Rechenleistung und Speicher haben, um selbst aufwändig
Anforderungen und eingesetzten Anwendungen. zu kommunizieren. Speziell im lokalen Umfeld kann es
hier sinnvoll sein, andere Protokolle zu nutzen. Dabei muss
berücksichtigt werden, dass diese Komponenten in den
Ende-zu-Ende-Kommunikation Netzwerken vor einem entsprechenden Industrie 4.0-Gate-
Im einfachsten Fall kommunizieren zwei Industrie 4.0-Kom­­ way selbst keine oder nur eingeschränkte Eigenschaften
ponenten direkt miteinander (Abbildung 6). Dafür muss die einer eigenständigen Industrie 4.0-Komponente aufweisen

Abbildung 6: Industrie 4.0-Komponenten kommunizieren Ende-zu-Ende

VWS 1 VWS 2

Asset 1 Asset 2

Abbildung 7: Industrie 4.0-Komponenten kommunizieren über Firewalls, Proxys oder Gateways

Logische Verbindung

VWS 1 VWS 2

Asset 1 Asset 2
10 KO M M U N I K AT I O N S B E Z I E H U N G E N

Abbildung 8: Anbindung weiterer Komponenten über Industrie 4.0-Gateways

Logische Verbindung

VWS 1 VWS 2

Asset 2a Asset 2b Asset 2c


Asset 1 Asset 2
Gateway

und daher das Industrie 4.0-Gateway entsprechend die Publish-Subscribe-Modell


Kommunikation unterstützen muss. Industrie 4.0-Gate- Um Informationen an mehrere Partner zu verteilen, bieten
ways bieten sich ferner an, wenn z. B. kleine und mittlere sich Publish-Subscriber-Modelle an. Die Empfänger (Sub­
Unternehmen nicht die Ressourcen für Einführung und scriber) melden sich beim Sender (Publisher) oder einem
Betrieb von Industrie 4.0-Komponenten im Hause haben, Verteildienst an, um am Informationsfluss teilzunehmen.
aber dennoch daran partizipieren möchten. In diesem Fall Die Empfänger wählen die Nachrichtentypen aus, die sie
kann ein Industrie 4.0-Gateway zum sicheren Datenaus- empfangen möchten (Abbildung 9). Durch die lose Kopp-
tausch von einem Dienstleister betrieben werden. lung zwischen Sender und Empfänger, bei dem es tech-
nisch keine Rolle spielt, wie viele Empfänger sich anmel-
Grundsätzlich müssen Industrie 4.0-Gateways in der Lage den, lässt sich die Informationsverteilung gut skalieren.
sein, alle dahinterliegenden Systeme zu schützen. Das Entsprechende Modelle verwenden häufig Datentele-
schließt nicht aus, dass ein Industrie 4.0-Gateway selbst gramme ohne Quittung (UDP) und sind daher entweder so
hinter einem anderen Gateway im Netzwerk liegen kann. gestaltet, dass verlorene Telegramme toleriert werden, wie

Abbildung 9: Publish-Subscribe-Modell

VWS 1

on
pti Asset 1
scri
Sub VWS 2
es
ag
M ess

n
Subscriptio Asset 2
VWS Publisher Message Messages
Messages Oriented
Middleware
Subscrip VWS 3
tion

Asset Message
Sub s
Publisher scr
ipti
on
Me Asset 3
ssa
ges
VWS N

Asset N
KO M M U N I K AT I O N S B E Z I E H U N G E N 11

bei Audio- oder Video-Anwendungen, oder dass sie eine sches Zeitverhalten). Sie werden heute im Engineering, also
sehr zuverlässige Netzwerkinfrastruktur voraussetzen, wie in der Planung und Umsetzung der Automatisierungsan-
sie in der Automatisierung häufig durch hohe Bandbreiten- wendung, festgelegt und in alle Komponenten einschließ-
reserven geschaffen wird. Ergänzend gibt es einen sicheren lich der betroffenen Netzwerkkomponenten eingestellt.
Modus, in dem der Empfänger alle bisher nicht abgeholten
Telegramme konsistent empfangen kann. Diese Kommuni- Da Industrie 4.0-Konzepte hochflexibel sind, müssen
kationsmethode ist allerdings zeitaufwändiger und wird Industrie 4.0-Komponenten die besonderen Eigenschaften
üblicherweise in echtzeitunkritischen Anwendungen beim Netzwerk anfordern können. Daher ist es sinnvoll,
genutzt, in denen allein die Datenkonsistenz von Bedeu- dass die Netzwerkinfrastruktur eine eigene Industrie
tung ist (Business-Prozesse, Verträge, Produktionsaufträge, 4.0-konforme Schnittstelle in Form einer Verwaltungs-
Alarmmeldungen). schale bereitstellt (10) (Abbildung 10). So kann die Infra-
struktur vollständig in die Industrie 4.0-Welt integriert
werden. Je nach Anwendungsfall können auch einzelne
Kommunikation mit dem Netzwerk als Partner Netzwerkelemente, etwa Router oder Switches, durch
Zeitkritische Automatisierungsanwendungen, die zum Bei- eigene Verwaltungsschalen repräsentiert sein. Beispiele
spiel synchron laufen müssen, um zusammenarbeiten zu hierfür sind im Bereich von TSN (Time Sensitive Network),
können, verlangen häufig besondere Netzwerkeigenschaf- SDN (Software Defined Networks) oder NFV (Network
ten wie etwa Latenz (Verzögerung) oder Jitter (deterministi- Function Virtualization) zu finden.

Abbildung 10: Industrie 4.0-Komponenten kommunizieren mit dem Netzwerk über erforderliche Eigenschaften

VWS Network

VWS 1 VWS 2

Asset 1 Asset 2
12

Verwendbarkeit verschiedener Protokolle

Seit Jahrzehnten wird die Netzwerkkommunikation erfolg- echtzeitfähige TSN-Ethernet-Netzwerke zu kommuni­


reich in Protokollschichten und Protokollen gegliedert. Die zieren
Protokollschichten beschreiben Dienste, die die Protokolle,
die auf diesen Schichten implementiert sind, erbringen ●● Für den Datenverkehr mit geringeren Anforderungen
müssen. Die Protokolle stellen je nach Zweck oder Umge- an eine deterministische Kommunikation, bei dem es
bung passende Dienste bereit. Dazu gehört zum Beispiel die nicht so wichtig ist, ob ein Datenpaket zu einem vordefi-
Namens­auflösung. In der Regel sind die Schnittstellen zwi- nierten Zeitpunkt eintrifft, sind leistungsfähige Ethernet-
schen den einzelnen Protokollschichten generisch, sodass Netzwerke ohne TSN oder flexible drahtlose Netzwerke
mehrere mögliche Kombinationen aus verschiedenen Pro- mit WLAN sinnvoll.
tokollen verwendet werden können. So ist es zum Beispiel
möglich, eine TCP/IP-Kommunikation sowohl über kabel- ●● In Anwendungen, in denen vor allem lange Laufzeiten
gebundene Netzwerktypen wie zum Beispiel IEEE 802.3 von batteriebetriebenen Geräten nötig sind (Sensoren
Ethernet als auch über drahtlose Netzwerke wie etwa IEEE oder smarte Geräte-Tags), wird aller Voraussicht auf
802.11 WLAN aufzubauen – ohne die darüberliegenden 802.15.4 Low-Power-Netzwerke in Kombination mit
Protokolle und Anwendungslogiken ändern zu müssen. Low-Power-Netzwerkprotokollen wie zum Beispiel
Diese Pluralität der Protokolle wird auch ein Teil von 6LoWPAN und COAP gesetzt werden müssen.
Industrie 4.0 sein, da es erforderlich sein wird, einheitlich
zwischen Verwaltungsschalen über verschiedenste Netz- Selbst Technologien (etwa deterministische Funkkommu-
werktypen zu kommunizieren – das machen auch Anwen- nikation), die heute noch nicht verfügbar sind, können
dungsfälle der Industrie deutlich: durch ein klares Schichtenmodell bereits berücksichtigt
und später problemlos eingeführt werden. Auf der Anwen-
●● Für eine schnelle Kommunikation in Closed-Loop-­ dungsschicht werden verschiedene Protokolle und Archi-
Systemen beispielsweise kann es bedeutend sein, über tekturen parallel existieren, da domänenspezifisch entwe-

Abbildung 11: Pluralität von Netzwerkprotokollen in Industrie 4.0-Anwendungen

Business-Prozesse Industrie 4.0

Prozesse, Logik Industrie- IT- IoT-


und Analyse Anwendungen Anwendungen Anwendungen

Interaktion und OPC UA Web-Services, MQTT,


... REST, ... COAP,
Semantik ...

Punkt-zu-Punkt- DTLS
TLS/HTTP(S) DTLS for C. D.
Sicherheit

Transportprotokoll TCP UDP

Netzwerkprotokoll IPv4 / IPv6 DETNET 6LoWPAN

Time IEEE IEEE


Lokales Netzwerk Sensitive 802.3 802.11 IEEE
802.15.4
Networks Ethernet WLAN

Physik Kabel Funk

Einige Protokolle und Standards erstrecken sich über mehrere Schichten des Kommunikationsstacks. In der Grafik wurden die
von OPC UA verwendeten Schichten und Protokolle exemplarisch gelb dargestellt.
VERWENDBARKEIT VERSCHIEDENER PROTOKOLLE 13

der vornehmlich Technologien des Office-Bereichs (zum munikationsstacks sind denkbar und nicht unwahrschein-
Beispiel Webservices) oder der Automatisierungstechnik lich.)
(zum Beispiel OPC UA) eingesetzt werden.
Aus Sicht der Protokollpluralität ist es wichtig, die Sicher-
In der Automatisierung und der IT haben sich unterschied- heitsmechanismen, die auf den einzelnen Schichten ver-
liche Technologien durchgesetzt, die aus technischen und fügbar sind, effektiv einzusetzen. Generell erlauben es viele
menschlichen Gründen nicht einfach zu ändern sind. Daher dieser Protokolle, Authentifizierung, Verschlüsselung und
ist auch hier anzunehmen, dass es unterschiedliche Proto- Integritätsschutz einzusetzen. Zusätzlich dazu können auf
kolle und Architekturen parallel geben wird (Pluralismus). den Schichten verschiedene Mechanismen eingerichtet
werden, die den Zugriff kontrollieren.
Es scheint, dass die obige Beschreibung eines Protokollplu-
ralismus chaotisch und unnötig komplex ist. Doch: Auf- Abbildung 12 zeigt den geschichteten Aufbau von OPC UA.
grund klarer Übergabepunkte an den Protokollschichten Auch hier wird deutlich: OPC UA bedient sich der Funktio-
lassen sich die Protokolle gut miteinander kombinieren nen verschiedener Schichten. Selbst innerhalb dieses Stan-
und betreiben. In der Praxis gibt es daneben aber auch dards gibt es gleichberechtigte austauschbare Protokolle
bereits Kommunikationsmöglichkeiten zwischen den (zum Beispiel SOAP und UA TCP). In den unteren Schich-
Domänen: So sieht OPC UA bereits Interaktionen zum ten bedient sich OPC UA ebenfalls der Funktionen von
Office-Bereich vor und setzt diese um – wie etwa die Ver- TCP/IP-Netzwerken. Da OPC UA unabhängig von spezifi-
wendung von Webservices und den Einsatz des Sicherheits- schen Netzwerktypen (Ethernet oder WLAN) spezifiziert ist,
protokolls TLS. lässt sich OPC UA in vielen Umgebungen einsetzen. Die
Mindestanforderung für den Betrieb ist lediglich, dass ein
Wie Kommunikationsstacks ausgeprägt sein können, zeigt IP-Netzwerk verfügbar ist. In den meisten industriellen
Abbildung 11. (Weitere Protokolle innerhalb dieser Kom- Anwendungen lässt sich das bewerkstelligen.

Abbildung 12: OPC UA hebt Security auf Applikationsebene

Binary Hybrid Webservice

UA Binary Encoding UA XML Encoding

WS Secure Interaktion und


UA Secure
Semantik
Conversation Conversation

UA-TCP SOAP

HTTP Punkt-zu-Punkt-
SSL/TLS Sicherheit
TCP Transportprotokoll
IP Netzwerkprotokoll

TCP Portonummer
4840 443 443 80 4840: opcua-tcp, https,
80: http, 443: https
14

Sicherheitsanforderungen und -mechanismen


auf den Schichten der Kommunikationsstacks
Die Sicherheit eines Gesamtsystems kann nicht auf einer große Bedeutung zu. Geeignete Schutzmaßnahmen reichen
einzigen Schicht oder an einer einzigen Stelle gewährleistet von abschließbaren Schränken für Netzwerkgeräte bis hin
werden. Stattdessen müssen alle Stellen des Kommunika­ zum Abschalten von nicht verwendeten Ethernet-Ports in
tionsstacks sicher gestaltet sein. Das bedeutet: Sowohl die der Software.
Funktionen und Managementmechanismen der Protokolle
als auch die Vertraulichkeit und Integrität der Daten, die Die Netzwerk-Zugangs-Schicht hat eine weitere wichtige
mittels der Protokolle transportiert werden, sind zu be­­rück­ Aufgabe: Sie muss die Quality of Service-Merkmale erfül-
sichtigen. Wie Sicherheitsanforderungen und -mechanis- len. Mit Technologien wie TSN ist es zum Beispiel möglich,
men der einzelnen Schichten aussehen können, wird im Datenpakete in echtzeitkritischen Applikationen determi-
Folgenden skizziert: nistisch auszuliefern. Jedoch sind auch hier Sicherheitsme-
chanismen einzubauen, um den echtzeitkritischen Verkehr
vor Überlastungen durch andere Verkehrsarten zu schüt-
Netzwerks-Zugangs-Schicht zen. Denn: Ein „Klassiker“ in der Automatisierungswelt ist
(Data-Link Layer und Physical Layer) eine fehlerhafte Komponente, die durch ein Übermaß an
Die Netzwerk-Zugangs-Schicht (OSI-Layer 1+2) umspannt Datenverkehr eine Netzwerküberlast erzeugt und damit die
die physische Übertragung eines Signals und die Vermitt- Produktion lahmlegt.
lung von Daten in einem lokalen Netzwerk. Dominante
Technologien in OSI-Layer 1+2 sind IEEE 802.3 (Ethernet), Weitere mögliche Ziele eines Angreifers sind Protokolle, die
IEEE 802.11 (Wireless LAN) sowie IEEE 802.15.4. die Vorgänge in der Netzwerk-Zugangs-Schicht verwalten.
Manipuliert ein Angreifer diese Protokolle, kann das die
Funktion eines Netzwerks empfindlich stören. Daher müs-
sen Funktionen der Verwaltungsprotokolle wie zum Bei-
Lokales Time
Sensitive
IEEE
802.3
IEEE
802.11 IEEE spiel das Address Resolution Protocol (ARP), das Dynamic
802.15.4
Netzwerk Networks Ethernet WLAN
Host Configuration Protocol (DHCP), Multicast-Protokolle
und QoS-Protokolle mithilfe geeigneter Maßnahmen (bei-
Physik Kabel Funk
spielsweise Port Security und DHCP snooping) vor Verän-
derungen und Störungen geschützt werden.

Wie auf allen anderen Schichten fallen auf der Netzwerk-


Eine zentrale sicherheitsrelevante Frage ist es, Zugangs-Schicht Betriebsdaten an, die wichtige Hinweise
welche Geräte am Netzwerk teilnehmen dürfen. geben, um Angriffe zu erkennen. Sie zeichnen beispiels-
Es muss sichergestellt werden, dass nur berech- weise auf, wann ein Gerät wo mit dem Netzwerk verbun-
tigte Teilnehmer Daten- oder Netzwerkpakete an das Netz- den war oder welche anderen Netzwerkteilnehmer Pakete
werk senden bzw. Daten vom Netzwerk empfangen kön- von einem Gerät erhalten (haben).
nen. Eine Verschlüsselung der Datenkommunikation (wie
zum Beispiel bei WLAN) sowie die Authentisierung der
Teilnehmer (beispielsweise über IEEE 802.1X/RADIUS) kön- Netzwerkschicht
nen dafür sorgen. Ein neuer Netzwerkteilnehmer weist sich Die Netzwerkschicht mit ihrem prominenten Vertreter
zum Beispiel mit einer teilnehmerspezifischen Benutzer- Internet Protocol (IP) verbindet einzelne IP-fähige Geräte
kennung und einem Passwort oder Zertifikat gegenüber auch über Netzwerkgrenzen hinweg: Durch sie können
dem Netzwerk aus. Greifen die Netzwerkzugangskontroll- Geräte unternehmens- oder weltweit adressiert und
mechanismen, dann können unberechtigte Teilnehmer erreicht werden. Umso unerlässlicher ist es, gewollte und
(etwa ein Angreifer mit einem eigenen Laptop) nicht am nötige von ungewollten und gegebenenfalls schädlichen
Netzwerk teilnehmen beziehungsweise den Datenverkehr Kommunikationsverbindungen zu trennen.
im Netzwerk nicht entschlüsseln.

Auch der physischen Sicherheit (zum Beispiel Zugang zu


Routern, Switches und Endsystemen durch unbefugte Per-
Netzwerk- IPv4 / IPv6 DETNET 6LoWPAN
sonen) kommt auf der Netzwerk-Zugangs-Schicht eine
protokoll
SICHERHEITSANFORDERUNGEN UND -MECHANISMEN AUF DEN SCHICHTEN DER KOMMUNIKATIONSSTACKS 15

Um diese Verbindungen restriktiv zu gestalten, Im Internet haben sich zwei starke Vertreter für
werden zum Beispiel Access Control Lists, Firewalls sichere Transportschicht-Verbindungen etabliert:
und Gateways eingesetzt. Mithilfe dieser Techno- die Protokolle Transport Layer Security (TLS)
logien und Geräte lassen sich Schutzkonzepte (zum Beispiel und Datagram Transport Layer Security (DTLS). Auch
Zones & Conduits) wie in ISO/IEC 62443 beschrieben um­­ Industrieprotokolle (wie zum Beispiel OPC UA) sind in der
setzen. Geräte werden zu sinnvollen Funktionsgruppen Lage, diese Protokolle zu verwenden.
zusammengefasst (zum Beispiel alle Geräte eines speziellen
Anlagenteils), in denen die Kommunikation zwischen den Die genannten Protokolle verwenden X.509-Zertifikate, um
Geräten selektiv erlaubt wird. Gleichzeitig kann die Kom- die Identität eines Endsystems und die Zugehörigkeit zu
munikation mit anderen Geräten unterbunden werden, wie einer bestimmten Organisation kryptografisch sicher zu
etwa mit dem Notebook des Angreifers, auch wenn er sich bestimmen. Zwischen den so authentifizierten Kommuni-
im gleichen Unternehmen befindet. Diese Einteilung kationsendpunkten wird eine Ende-zu-Ende-Verschlüsse-
schränkt die Bewegungsmöglichkeiten des Angreifers im lung bzw. ein Ende-zu-Ende-Integritätsschutz etabliert. Das
Netzwerk stark ein und schützt verwundbare Systeme davor, verhindert Angriffsversuche: Das Abhören von Verbindun-
dass sie durch kompromittierte Komponenten beeinflusst gen sowie die Veränderung von Daten durch einen Angrei-
werden. Das Eindringen in das System wird deutlich fer kann – bei geeigneter Wahl der kryptografischen
erschwert. Mechanismen – effektiv abgewehrt werden.

Darüber hinaus gibt es die Möglichkeit, auf der Netzwerk- Die Ende-zu-Ende-Verschlüsselung birgt jedoch nicht nur
schicht verschiedene sichere Netzwerke über unsichere Vorteile für die Sicherheit: Geräte wie Firewalls, die den
Netzwerke zu verbinden: mithilfe von Virtual Private Net- weiterzuleitenden Verkehr auf Widrigkeiten untersuchen,
work (VPN)-Technologien. So lassen sich zum Beispiel können aufgrund der Verschlüsselung den weiterzuleiten-
Außenstellen einer Anlage über das Internet per VPN an den Verkehr nicht einsehen und so Angriffsmuster nicht
eine zentrale Stelle im Unternehmen – meist bei der zent- mehr erkennen. Angriffe bleiben unentdeckt. Um eine
ralen IT – anbinden. Auch hier ist darauf zu achten, dass die Ende-zu-Ende-Sicherheit und gleichzeitig die Inspizierbar-
einzelnen Kommunikationsbeziehungen segmentiert wer- keit des Verkehrs zu erreichen, gibt es Mittelwege: Der Ver-
den (zum Beispiel durch Firewalls und Gateways). kehr kann in einem vertrauenswürdigen Gateway ent-
schlüsselt werden. Dafür bricht das Gateway die gesicherte
Auch auf der Netzwerkschicht fallen Daten an, die für den Verbindung auf und inspiziert die Daten. Dieser Ansatz hat
sicheren Betrieb relevant sind. Sie können dazu verwendet jedoch Schwächen, vor allem bei der Frage, welchem Gate-
werden, um Angriffe zu erkennen. Wenn etwa ungewöhnli- way zu trauen ist. Darüber hinaus ist er nicht für alle Proto-
che Kommunikation zwischen Geräten ohne Funktionsbe- kolle verfügbar.
zug stattfindet oder ungewöhnliche Kommunikationsmus-
ter auftreten, ist Vorsicht geboten – das können Hinweise Auch auf der Transportschicht fallen Daten an, die für
auf einen Angriff sein. Überwachung und Angriffserkennung genutzt werden
können. Dies sind insbesondere die Identitäten der Kom-
munikationsendpunkte und ihre Kommunikationsmus-
Transportschicht und Ende-zu-Ende-Sicherheit ter.
Die Transportschicht verbindet einzelne Anwendungen auf
unterschiedlichen Geräten. Um auf ihr Sicherheit zu gewähr­
leisten, ist die Frage der Identität von Geräten und Diens- Prozess- und Businesslogik
ten essenziell. Oberhalb der beschriebenen Schichten befinden sich die
Teile der Industrie 4.0-Kommunikation, die anwendungs-
spezifisch sind. Dazu gehören die Prozesslogik bzw. model-
lierte Geschäftsprozesse.
Punkt-zu-Punkt- TLS/HTTP(S) DTLS
DTLS
for C. D.
Sicherheit
Transport- TCP UDP
protokoll
16 SICHERHEITSANFORDERUNGEN UND -MECHANISMEN AUF DEN SCHICHTEN DER KOMMUNIKATIONSSTACKS

4.0-Kommunikation einbezogen sind, ihre Rollen und


Business-Prozesse Industrie 4.0 Rechte zentral. Da auf den oberen Schichten Industriepro-
zesse und Geschäftslogik modelliert und umgesetzt werden,
Prozesse, Logik Industrie- IT- IoT- sind geeignete Maßnahmen essenziell, die Zuverlässigkeit
Anwen- Anwen- Anwen- und Rechtssicherheit schaffen. Insbesondere müssen Vor-
und Analyse dungen dungen dungen
gänge auditierbar und das System oder eine Partei nach-
weisbar vertrauenswürdig sein.

Schon seit Jahren existieren Darstellungsweisen, Da bereits viele Unternehmenssysteme existieren, die Ge­­
mit denen Prozess- und Businesslogiken genormt schäftsprozesse und Informationen verwalten und model-
beschrieben und ausgetauscht werden, zum Bei- lieren, müssen hier gegebenenfalls viele bestehende
spiel UML (Unified Modeling Language), BPMN (Business Legacy-Systeme durch Adapter und Gateways miteinan-
Process Model and Notation) und BPEL (Business Process der verbunden werden. Wichtig ist: Bei einer solchen Ver-
Execution Language). Darüber hinaus haben sich in der bindung gilt es, Sicherheitseigenschaften und die Nachvoll-
Industrie entsprechende Modelle im Office-Bereich und ziehbarkeit von Aktionen zu erhalten. Also zu erfahren, wer
auf der Produktionsebene etabliert, wie etwa SOA (Service- wann mit wem und worüber kommuniziert hat.
oriented Architecture) und wesentlich digitalisierte Aus-
führungssysteme wie MES (Manufacturing Execution Sys- Teile der Prozess- und Businesslogik können auch unter-
tem) und ERP (Enterprise Resource Planning). nehmensübergreifend implementiert werden. Denkbar ist,
dass IT-Systeme anderer Unternehmen (zum Beispiel Zulie-
Eine einheitliche Form, um in der Industrie 4.0 mit den ferer oder Kunden) oder Systeme von Drittanbietern (zum
Vorgängen und Daten dieser Schichten umzugehen, ist die Beispiel Cloud-Systeme) auf dieser Ebene mit den eigenen
Verwaltungsschale (Administration Shell). Sie verbindet Anwendungen verwoben werden. Insbesondere bei der
Daten- und Interaktionsmodelle und stellt essenzielle unternehmensübergreifenden Kommunikation ist darauf
Sicherheitsfunktionen zur Verfügung (zum Beispiel Authen­ zu achten, dass geeignete Schutzmechanismen existieren,
tisierung, Integritätsschutz, Zugriffsschutz und Ereignis- dass die Kommunikationsvorgänge und Transaktionen
protokollierung). Auch auf diesen beiden Schichten sind nachvollzogen werden können und dass das Unternehmen
Identitäten der Teilnehmer, die in eine Industrie in einem rechtssicheren Rahmen agiert.
17

Anwendungsbeispiel:
Auftragsgesteuerte Produktion
Auf den vorherigen Seiten wurden Kommunikationsstacks Schritt 3: Interessierte Zulieferer unterbreiten Angebote an
und mögliche Protokolle betrachtet. Doch um sicherzustel- Vermittlungsdienst
len, dass alle zentralen Aspekte der sicheren Kommunikation
berücksichtigt werden, gilt es auch, relevante Industrie 4.0- Schritt 4: V
 ermittlungsdienst übermittelt vorgefilterte
An­­­wendungsfälle genauer zu betrachten. Angebote an den Fahrradhersteller

Das Anwendungsbeispiel zeigt unter anderem die Kommu- Schritt 5: Fahrradhersteller (Auftraggeber) erteilt Auftrag
nikationsbeziehungen einer „Auftragsgesteuerten Produktion direkt an ausgewählten Zulieferer (Auftragnehmer)
eines individuellen Fahrradlenkers“ der Plattform Industrie
4.0 (11) (Abbildung 13 2). In Abbildung 14 ist das Sequenz- Schritt 6: A
 uftragnehmer übermittelt dem Auftraggeber
diagramm für die Kommunikationsschritte dargestellt: zugesagte Daten über das individuell gefertigte
Produkt als Teil des Produktgedächtnisses
Schritt 1: Fahrradhersteller überträgt Ausschreibung an
Vermittlungsdienst Schritt 7: Physisches Produkt wird ausgeliefert

Schritt 2: Vermittlungsdienst verteilt Ausschreibung an


mögliche Zulieferer

Abbildung 13: Auftragsgesteuerte Produktion eines kundenindividuellen Fahrradlenkers

Auftraggeber

Auftragnehmer

2 Im Anwendungsbeispiel wird eine Ausschreibung betrachtet, die neben den technischen Anforderungen an das Produkt auch alle kommerzi-
ellen und rechtlichen Randbedingungen enthält. Diese Ausschreibung wird vom Vermittlungsdienst, häufig auch als Broker bezeichnet, an
mögliche Zulieferer weiterverteilt. Die möglichen Zulieferer sind vorab vom Vermittlungsdienst qualifiziert, was auch eine Bewertung der
Vertrauenswürdigkeit/Trustworthiness bezüglich der IT-Security beinhaltet. Schließlich sind viele der ausgetauschten Daten, u. a. die
3D-Druckdaten des kundenindividuellen Fahrradlenkers, schützenswerte Informationen.
18 A N W E N D U N G S B E I S P I E L : A U F T R A G S G E S T E U E RT E P R O D U K T I O N

Für jeden dieser Schritte können nun Anforderungen an halten bestehen, sind für den hier betrachteten Fall weni-
die Kommunikation beschrieben werden. So lässt sich fest- ger relevant. Die Abwicklung darf mehrere Sekunden dau-
stellen, welche Protokolle sich eignen. Außerdem können ern, ohne dass der Ablauf dadurch scheitert.
anhand dieser Schritte entsprechende Weiterentwicklun-
gen bestehender Protokolle angegangen werden. Um die Ausschreibung zu übertragen, ist sicherzustellen,
dass die darin enthaltenen Daten in allen Belangen integri-
Wie die Ausschreibung vom Fahrradhersteller an den Ver- tätsgeschützt und gegebenenfalls durch eine elektronische
mittlungsdienst übertragen wird (erster Kommunikations- Unterschrift authentifiziert sind. So wird gewährleistet,
schritt), wurde beispielhaft in Abbildung 15 betrachtet. Es dass die Ausschreibung nicht verfälscht werden kann –
wird deutlich: Für die rechtssichere Abwicklung sind haupt­ weder bei der Übertragung an den Vermittlungsdienst
sächlich Security-Themen relevant. Technische Anforde- noch bei der Weiterverteilung an die möglichen Zulieferer.
rungen an den Kommunikationsprozess hingegen, wie sie Darüber hinaus kann es sinnvoll sein, auf der Übertra-
im automationsnahen Bereich typischerweise im Zeitver- gungsstrecke zum Vermittlungsdienst und bei der anschlie-

Abbildung 14: Kommunikationssequenz der Auftragsabwicklung

Vermitt-
AG lungs- AN
dienst

AG Ausschrei-
bung Vermittlungsdienst
Ausschrei-
bung AN

1 2
Indiv.
Design Ausschrei- Ausschrei-
bung bung

Prüfung
Angebotserstellung

Ausschrei- 3
bung Angebot
Angebot Angebot Angebot
Angebot Angebot Angebot
Angebot

Vorauswahl Angebot
Nur gültige Angebote
Angebot
Angebot
4

Finale Auswahl
3D-
Auftrag Drucker

5
Auftrag

Teil von Auftrag


Produkt-
gedächtnis
6
Teil von
Produkt-
gedächtnis 7 Produkt Produkt-
gedächtnis
A N W E N D U N G S B E I S P I E L : AU F T R A G S G E S T E U E RT E P R O D U K T I O N 19

ßenden Weiterverteilung auf eine vertrauliche Übermitt- Protokolle, die im Bereich des Electronic Business einge-
lung zu setzen. Allerdings sollten dabei die Anforderungen setzt werden, ohne tiefergehend zu betrachten, ob sie sich
und Umsetzungen getrennt betrachtet und für die einge- tatsächlich eignen.): Im ersten Schritt wird die Ausschrei-
setzten Protokolle bewertet werden: zum einen die der bung als Nachricht erstellt und digital signiert. Auf dem
Vertraulichkeit auf dem Kommunikationsweg, zum ande- Weg zum Vermittlungsdienst wird diese Nachricht ver-
ren die des Integritätsschutzes der Information selbst. schlüsselt. Da die digitale Signatur der Ausschreibung
immer zur Verfügung steht, bleiben sowohl beim Vermitt-
Abbildung 15 zeigt eine Möglichkeit, wie das technisch lungsdienst als auch bei einer weiteren Übertragung Integ-
umgesetzt werden könnte (Hinweis: Sie nennt beispielhaft rität und Authentizität immer erhalten.

Abbildung 15: Kommunikationsschritt 1 – Mögliche Übertragung einer Ausschreibung

koll
s Proto
Äußere , RosettaNet,
M L
AG X
z. B. eb IFACT, ...
ED
Type

Rahmen-
Type Instanz bedingun- kommerziell
Konfigurator gen

rechtlich
Ausschrei-
Produkt Produkt bung

Multi-Tier?
technisch

Type Instanz versiegelt/


Instanz signiert

Bauteil Indiv.
Bauteil
Ausschrei-
koll
s Proto
ng

bung
Innere , ebMS, ...
rga

S O A P
z. B.
vo
ns
tio

Inte
rakt
ika

ion tokoll
un

erkpro
Netzw (S), SMTP, ...
m
om

T p
z. B. HT
nK

Net OSI-Layer 1-7


zwe
gin

rkko
Be

mm
unik
atio
n
20

Zusammenfassung und Ausblick

Das Diskussionspapier zeigt: Um eine sichere Kommunika- Daher soll in der weiteren UAG-Arbeit unter anderem ein
tion zu gewährleisten, müssen die verschiedenen Schichten Szenario auf der Automatisierungsebene beschrieben und
der Kommunikationsprotokolle betrachtet werden. Wichtig untersucht werden, bei dem Echtzeitkommunikation und
ist, dass dafür viele verschiedene Anwendungsfälle analysiert das Zusammenwirken von Systemen verschiedener Herstel-
werden, denn nur so lassen sich mögliche Protokolle und ler relevant sind. Darüber hinaus wird ein weiterer wichti-
Umsetzungsstrukturen vergleichen und bewerten, um die ger Baustein sein, unternehmensübergreifende Kommuni-
Kriterien für Industrie 4.0-konforme Kommunikation zu kation und die Einbindung von Cloud-Diensten genauer zu
erarbeiten. beleuchten. Denn hier steht die Industriewelt vor der Her-
ausforderung, die Kommunikation so zu gestalten, dass sie
Das oben dargestellte Beispiel aus dem Anwendungsszenario flexibel ist und organisatorische, also manuelle, Aufgaben
„Auftragsgesteuerte Produktion“ behandelt einen Geschäfts­ im Betrieb minimiert. Dabei empfiehlt es sich, die Erkennt-
vorfall. Kommen technische Prozesse hinzu, dann werden nisse anderer Expertengruppen zum Thema, wie etwa das
darüber hinaus weitere Aspekte wichtig sein, die besonders IIC Connectivity Framework (12), das IIC Security Frame-
die sicherheitstechnische und laufzeitdynamische Ausgestal­ work (13) oder die Referenzarchitektur des Industrial Data
tung der Kommunikation (zum Beispiel Latenz) beeinflussen. Space (14), in die künftigen Betrachtungen einzubeziehen.

Literaturverzeichnis
1. Technischer Überblick „Sichere unternehmensübergreifende 9. Com4.0-Basic: Basic Models of Communication. Aachen:
Kommunikation“. Berlin: Plattform Industrie 4.0, 2016. RWTH Aachen, 2016.

2. Facilitating International Cooperation for Secure Industrial 10. Network-based Communication for Industrie 4.0: Propo-
Internet of Things/Industrie 4.0. Berlin: Plattform Industrie sal for an Administration Shell. Berlin: Plattform Industrie
4.0, 2017. 4.0, 2016.

3. Common automation device – Profile guideline. IEC TR 11. Anwendungsszenario trifft Praxis: Auftragsgesteuerte Pro-
62390:2005. duktion eines individuellen Fahrradlenkers. Berlin: Plattform
Industrie 4.0, 2017.
4. Security der Verwaltungsschale. Berlin/Frankfurt:
Plattform Industrie 4.0/ZVEI, 2017. 12. The Industrial Internet of Things/Volume G5: Connecti-
vity Framework. Needham, MA, USA: Industrial Internet
5. Interaktionsmodell für Industrie 4.0-Komponenten. Consortium, 2017.
Berlin: Plattform Industrie 4.0, 2016.
13. Industrial Internet of Things/Volume G4: Security Frame-
6. Netzkommunikation für Industrie 4.0. Berlin: Plattform work. Needham, MA, USA: Industrial Internet Consortium,
Industrie 4.0, 2016. 2016.

7. Reference Model for Industrie 4.0 Service architectures – 14. Reference Architecture Model for the Industrial Data
Basic concepts of an interaction-based architecture. DIN Space. München/Berlin: Fraunhofer Gesellschaft/Industrial
SPEC 16593, 2017. Data Space e. V., 2017.

8. Technischer Überblick „Struktur der Verwaltungsschale“.


s.l.: Plattform Industrie 4.0, 2016.
AUTOREN:
Prof. Dr. Tobias Heer, Hirschmann Automation & Control GmbH; Markus Heintel, Siemens AG; Stefan Hiensch, Bundes-
netzagentur; Dr. Lutz Jänicke (Leitung), Phoenix Contact GmbH & Co KG; Michael Jochem, Robert Bosch GmbH; Bernd
Kärcher, Festo AG & Co. KG; Marcel Kisch, IBM Deutschland GmbH; Jens Mehrfeld, Bundesamt für Sicherheit in der
Informationstechnik; Gerhard Oeynhausen, Telekom AG; Tobias Pfeiffer, Festo AG & Co. KG; Frank Schewe, Phoenix
Contact Electronics GmbH; Dr. Michael Schmitt, SAP SE; Dr. Dirk Schulz, ABB AG; Detlef Tenhagen, HARTING AG & Co
KG; Klaus Theuerkauf, IFAK Institut für Automation und Kommunikation e. V.; Andreas Teuscher, SICK AG; Thomas
Walloschke, Fujitsu Technology Solutions GmbH

Diese Publikation ist ein gemeinsames Ergebnis der Arbeitsgruppen „Sicherheit vernetzter Systeme“ und
„Referenzarchitekturen, Standards und Normung“ (Plattform Industrie 4.0).
www.plattform-i40.de