-

OPC UA-Sicherheitseinstellungen

Weitere Infos
Lesen und befolgen Sie auch die allgemeinen Security-bezogenen Informationen im Hilfekapitel "Security in PLCnext Engineer".

Die Einstellungen auf der 'Security'-Seite helfen bei der Absicherung der Kommunikation des OPC UA-Servers, indem der Datenaustausch zwischen Applikationsinstanzen in verteilten Umgebungen gegen Manipulation und optional auch gegen Abhören geschützt wird. Im aktuellen Kontext sind diese Anwendungsinstanzen der OPC UA-Server und die OPC UA-Clients. Um eine gesicherte Kommunikation zu ermöglichen, müssen die subscribenden OPC UA-Clients die entsprechenden Einstellungen und Algorithmen ebenfalls unterstützen und verwenden. Jede Anwendung muss ein Zertifikat besitzen, mit dem es sich vor der Kommunikation mit einer anderen Applikation identifiziert.

Beim Aufbau einer Kommunikationsverbindung zwischen dem OPC UA-Server und einem OPC UA-Client ...

Diese gegenseitige Authentifizierung erlaubt das Öffnen eines sicheren Kanals. In einem sicheren Kanal lassen sich eine oder mehrere Kommunikations-Sessions abwickeln.

Weitere Infos
Weitere Informationen zu den in der Tabelle genannten technischen Begriffen finden Sie im Thema "Security-Begriffe und Hintergrundinformationen".

Auf der Seite 'Sicherheit' des 'OPC UA'-ANLAGE-Knotens können Sie Einstellungen zu Zertifikaten und zur Authentifizierung vornehmen. Die Authentifizierung ist notwendig, um eine gesicherte Verbindung zwischen OPC UA-Clients und dem OPC UA-Server herstellen zu können. Außerdem können Sie hier die Verschlüsselungsalgorithmen definieren, die der OPC UA-Server seinen Clients zur Absicherung der übertragenen Daten anbietet.

ParameterBeschreibung
ZertifikatKonfiguriert die Zertifikateverwaltung auf dem OPC UA-Server:

  • 'Datei auf der Steuerung': Eine Zertifikatsdatei (einschließlich privatem Schlüssel) ist im IdentityStore (Identitätsspeicher) auf der Steuerung gespeichert. Dabei kann es sich um ein CA-signiertes oder ein selbst-signiertes Zertifikat handeln (siehe Definitionen am Ende dieses Themas). Der Dateispeicherort auf der Steuerung ist festgelegt und kann nicht verändert werden.

    Der Transfer des Zertifikats in den IdentityStore auf dem Gerät kann über die WBM-Schnittstelle (webbasiertes Management) der Steuerung oder mit Hilfe des Tools SCP Secure Copy erfolgen (die Übertragung mit PLCnext Engineer ist nicht möglich).

    Details entnehmen Sie dem Steuerungshandbuch zur Ihrem PLCnext Technology-Gerät. In der Tabellenzeile 'TrustStores' finden Sie eine Erläuterung des Begriffs "IdentityStore".

  • 'Selbst-signiert von Steuerung': Der Server verwendet das selbst-signierte Zertifikat, welches er erzeugt und mit seinem eigenen, privaten Schlüssel signiert hat. Die Verwendung des selbst-signierten Zertifikats verursacht einen größeren Aufwand, wenn ein Netzwerk mit vielen Anwendungsinstanzen aufgebaut werden muss, da das Zertifikat manuell an alle beteiligten Instanzen verteilt werden muss.

    Nachdem Sie 'selbst-signiert durch Steuerung' ausgewählt haben, werden die 'Subjekt'-Optionen aktiv, wo Sie das (die) Subjekt(e) des Zertifikats benennen müssen. Das Verändern der Subjekteinstellungen führt zu einem neuen selbst-signierten Zertifikat nach dem nächsten Schreiben des Projekts. In der Tabellenzeile "Subjekttyp" finden Sie weitere Details.

  • 'Verwaltet durch OPC UA GDS': Der im PLCnext Technology-Gerät integrierte OPC UA-Server ist bereit, um via Certificate Push Management (gemäß OPC UA-Standard V1.04, Teil 12) automatisch mit Zertifikaten versorgt zu werden. Dies beinhaltet nach einem Erst-Zertifikat auch alle Nachfolge-Zertifikate (Aktualisierungen).

    Es wird erwartet, dass die Zertifikate automatisch von einem Global Discovery Server (GDS) bereitgestellt werden, der den Push-Mechanismus implementiert. Der Global Discovery Server muss sich als "spezieller" OPC UA-Client mit dem OPC UA-Server im PLCnext Technology-Gerät verbinden.

    Der Global Discovery Server ist nicht Teil von PLCnext Engineer. Es kann dafür jedes geeignete marktübliche Standard-Tool verwendet werden. Dieses muss so konfiguriert werden, dass es sowohl den OPC UA-Server im PLCnext Technology-Gerät als auch alle OPC UA-Clients (d.h. alle relevanten Geräte in Ihrem Netzwerk/Ihrer Security-Domäne) mit Zertifikaten versorgt. Beachten Sie, dass sich der Global Discovery-Server auch in einer anderen Security-Domäne (in einem anderen Subnetz) befinden kann.

    Nachdem Sie die Option 'Verwaltet durch OPC UA GDS' gewählt haben, müssen Sie die Namen des TrustStore (Vertrauensspeichers) und des IdentityStore (Identitätsspeichers) im OPC UA-Server angeben. Diese Namen können frei gewählt werden. Sie können die Inhalte dieser Speicherbereiche (Stores) über die WBM-Schnittstelle (webbasiertes Management) der Steuerung einsehen. Der OPC UA-Server legt in diesen Stores die Daten ab, die er vom Global Discovery Server (GDS) erhält. In dem von Ihnen benannten IdentityStore (Identitätsspeicher) speichert er das Zertifikat und den Schlüssel, mit dem er sich nach Vorgabe des GDS bei den Clients authentifizieren muss. Im TrustStore legt er die vom GDS empfangenen vertrauenswürdigen Zertifikate und Ausstellerzertifikate ab, mit denen er Client-Zertifikate verifiziert.

    Nachdem Sie 'Verwaltet durch OPC UA GDS' ausgewählt haben, werden ebenfalls die 'Subjekt'-Optionen aktiv, wo Sie das (die) Subjekt(e) des Zertifikats benennen müssen. Je nach eingesetztem Global Discovery Server können diese Subjekt-Einstellungen in die Zertifikate integriert werden, die der OPC UA-Server erhält. In der Tabellenzeile "Subjekttyp" finden Sie weitere Details.

Trust Stores (Vertrauensspeicher)Diese Felder sind nur sichtbar, nachdem Sie im Bereich 'Serverzertifikat' den Wert 'Verwaltet durch OPC UA GDS' ausgewählt haben (siehe Zeile oben).

Sie müssen die Namen für den TrustStore (Vertrauensspeicher) und IdentityStore (Identitätsspeicher) definieren, in denen der OPC UA-Server die vom Global Discovery-Server (GDS) empfangenen Daten ablegen soll. Geben Sie beliebige Namen in die Textfelder ein. Sie können den aktuellen Inhalt dieser Speicherbereiche (Stores) über die WBM-Schnittstelle (webbasiertes Management) der PLCnext Technology-Steuerung einsehen.

  • 'Name des IdentityStore': Definiert den Namen des IdentityStore (Identitätsspeicher) auf dem OPC UA-Server im PLCnext Technology-Gerät, in dem der OPC UA-Server sein eigenes Applikations-Zertifikat und den Schlüssel ablegen soll, den er vom Global Discovery-Server erhält und verwenden muss. Mit den Informationen, die im IdentityStore gespeichert sind, authentifiziert sich der OPC UA-Server gegenüber seinen Clients.

    Hintergrundinformationen: IdentityStore

  • 'Name des TrustStore': Definiert den Namen des TrustStore (Vertrauensspeicher) des OPC UA-Servers auf dem PLCnext Technology-Gerät, in dem der OPC UA-Server die vom Global Discovery-Server (GDS) empfangenen Daten ablegt, mit denen er Clients authentifiziert. Mit den Informationen aus dem TrustStore kann der OPC UA-Server die Identität von OPC UA-Clients authentifizieren, die sich mit dem Server verbinden möchten. Er validiert dazu die Echtheit des Zertifikats, das jeder Client präsentiert.

    Lesen Sie hier auch die Tabellenzeile 'Anwendung' unten. Sie müssen das Kontrollkästchen 'Verwendung des TrustStores zur Client-Authentifizierung' aktivieren, damit der Inhalt des TrustStore bei der Client-Authentifizierung berücksichtigt wird.

    Hintergrundinformationen: TrustStore

Für den TrustStore wie auch den IdentityStore gilt:
  • Die enthaltenen Daten werden im Dateisystem des PLCnext Technology-Geräts gespeichert und können dort optional durch Hardware-Maßnahmen geschützt werden. Standardmäßig können herstellerseitige TrustStores und IdentityStores implementiert sein.
    Beispiel: Ein vordefinierter TrustStore mit Daten zur Prüfung der Authentizität des Proficloud-Servers beim Verbindungsaufbau zur Proficloud oder ein IdentityStore zur Authentifizierung beim HTTPS-Server oder beim Remoting-Server des Geräts.
  • Auf TrustStores und IdentityStores im PLCnext Technology-Gerät kann über die WBM-Schnittstelle (webbasiertes Management) zugegriffen werden.
  • In der aktuellen Version enthält der OPC UA-Server drei einsatzbereite TrustStores und drei IdentityStores. Der OPC UA-Server unterstützt gegenwärtig nur den gleichzeitigen Einsatz eines TrustStore und eines IdentityStore. Welcher verwendet wird, hängt von der OPC UA-Server-Konfiguration ab.

    IdentityStores:

    1. Ein IdentityStore mit festem Namen für das selbst-signierte Zertifikat. Dieser Store wird verwendet, wenn die Konfigurationsoption 'selbst-signiert durch Steuerung' gewählt wurde.
    2. Ein IdentityStore mit festem Namen für die Zertifikatsdatei. Dieser Store wird verwendet, wenn die Konfigurationsoption 'Datei auf der Steuerung' gewählt wurde.
    3. Ein IdentityStore, dessen Name in PLCnext Engineer festgelegt wurde, für das vom GDS gelieferte Zertifikat. Dieser Store wird verwendet, wenn die Konfigurationsoption 'Verwaltet durch OPC UA GDS' gewählt wurde.

    TrustStores:

    1. Ein TrustStore mit festem Namen für die Verwendung mit der Zertifikatsdatei. Dieser Store wird verwendet, wenn die Konfigurationsoption 'Datei auf der Steuerung' oder 'selbst-signiert durch Steuerung' gewählt wurde.
    2. Ein TrustStore, dessen Name in PLCnext Engineer festgelegt wurde, für die vom GDS gelieferten Informationen. Dieser Store wird verwendet, wenn die Konfigurationsoption 'Verwaltet durch OPC UA GDS' gewählt wurde.

      In diesem Fall gilt: Falls noch nicht definiert (z.B. über WBM), können Sie einfach einen neuen TrustStore oder IdentityStore erzeugen, indem Sie in die Eingabefelder beliebige Namen eintippen. Dadurch wird der entsprechende Store mit dem eingegebenen Namen auf dem Gerät angelegt, wenn der OPC UA-Server das Projekt ausführt. Nachdem er angelegt wurde, ist der Store nach wie vor leer, aber im WBM sichtbar.

    Hinweis
    Solange der TrustStore leer ist, vertraut der OPC UA-Server allen Clients.

  • Der Inhalt sowohl des TrustStore als auch des IdentityStore kann über die WBM-Schnittstelle geändert werden. Auf diesem Weg können Sie den TrustStore manuell "vorbelegen", damit der OPC UA-Server dem Global Discovery-Server trauen kann, der ihn dann mit weiteren Zertifikaten versorgen wird. Sie können außerdem den IdentityStore mit einem Server-Zertifikat vorbelegen, damit sich der Server als vertrauenswürdiges Mitglied Ihrer Security-Domäne ausweisen kann, beispielsweise beim Global Discovery-Server.
  • Konfigurieren Sie den Global Discovery-Server entsprechend, so dass dieser dem OPC UA-Server vertraut (damit eine Verbindung zwischen OPC UA-Server und GDS aufgebaut werden kann). Richten Sie dann den GDS so ein, dass er zyklisch die erforderlichen Security-Daten in den TrustStore und den IdentityStore des OPC UA-Servers schreibt.

Hinweis
Der OPC UA-Standard verwendet eine etwas andere Terminologie: Der Standard erwähnt eine TrustList, deren Inhalt dem des TrustStore eines PLCnext Technology-Geräts sehr ähnlich ist. Der Standard spezifiziert eine CertificateGroup, deren Inhalt dem des IdentityStore eines PLCnext Technology-Geräts sehr ähnlich ist.

SubjekttypDiese Felder sind nur sichtbar, wenn für 'Serverzertifikat' entweder 'Selbst-signiert durch Steuerung' oder 'Verwaltet durch OPC UA GDS' eingestellt wurde.

Hinweis
Bei 'Verwaltet durch OPC UA GDS' hängt es von der Implementierung des verwendeten Global Discovery-Servers ab, ob die hier getätigten Subjekt-Einstellungen berücksichtigt werden oder nicht.

Das Subjekt gibt den Inhaber des Zertifikats an. Ein Subjekt kann durch alternative Namen ergänzt werden. In einem Zertifikat gemäß X.509-Standard werden diese Namen mit sogenannten "subjAltName"-Erweiterung im Zertifikat aufgenommen.

Mit diesen Eingabefeldern können Sie alternative Namen für den OPC UA-Server spezifizieren, die der Server entweder in das selbst-signierte Zertifikate aufnimmt, oder in den Zertifikatsantrag (Certificate Signing Request) schreibt, den er für den Global Discovery-Server erzeugt.
Sie können bis zu fünf alternative Namen angeben. Jeder alternative Name sollte einen DNS-Namen oder eine IP-Adresse beschreiben, unter dem/der der OPC UA-Server erreichbar ist. Der OPC UA-Server verwendet automatisch auch den in den Grundeinstellungen definierten DNS-Namen als alternativen Namen, unabhängig von den Einstellungen hier.

Auf diese Weise ermöglichen Sie bis zu vier Kommunikationspfade (vorausgesetzt, Ihre Netzwerkarchitektur unterstützt dies, z.B. durch Einsatz eines Routers mit Portweiterleitung (Firewall im Router zum OPC UA-Server) und implementiertem lokalen DynDNS).

Beim Verbindungsaufbau verifizieren die OPC UA-Clients, ob die Adresse (DNS-Name oder IP-Adresse) der URL, die Sie kontaktieren möchten, im Server-Zertifikat enthalten ist.
Wenn mehrere Möglichkeiten zum Verbinden mit dem OPC UA-Server vorhanden sind (von außerhalb und innerhalb der Domäne), dann muss jeder in Frage kommende Adressteil der URL im Zertifikat enthalten sein. Andernfalls scheitert die Authentifizierung.

Jeder spezifizierte DNS-Name bzw. jede IP-Adresse (je nach Auswahl im Feld 'Subjekttyp') wird in das selbst-signierte Zertifikat geschrieben. Ist im Subjektfeld 'nicht gesetzt' eingestellt, dann ignoriert der Server dieses Feld beim Erzeugen des Zertifikats. Wenn Sie für alle Subjekte den Wert 'Nicht gesetzt' auswählen, dann wird kein alternativer Name in das selbst-signierte Zertifikat geschrieben, außer dem DNS-Namen aus den Grundeinstellungen, der immer verwendet wird.

Hinweis
Wenn Clients kurze URLs verwenden (weil sie sich in derselben Domäne wie der OPC UA-Server befinden), verwenden Sie diese Kurznamen als alternative Namen.

SicherheitsrichtlinienIn den Sicherheitsrichtlinien legen Sie die zu verwendenden Algorithmen und die Schlüssellängen fest. Gemäß der OPC UA-Spezifikation sind die verfügbaren Algorithmen hier aufgelistet und können ausgewählt werden.

Die Auswahl definiert die Verschlüsselungsalgorithmen (Cipher Suite), die der OPC UA-Server seinen Clients anbietet. Der Verschlüsselungsalgorithmus sichert den Datentransfer zwischen OPC UA-Server und Client.

Indem Sie in einer der Auswahlliste 'Ja' auswählen, steht den Clients der betreffende Algorithmus zur Verfügung. Die Einstellung 'Nein' bedeutet, dass der Verschlüsselungsalgorithmus in den Einstellungen des OPC UA-Client nicht ausgewählt werden kann.

Die Verschlüsselungs- und Signaturstärke nimmt in der Liste von oben nach unten zu.
  • 'Basis 128 RSA15 Algorithmus aktivieren'
    Dieser Basis 128 RSA15-Algorithmus ist veraltet und deshalb auf 'Nein' voreingestellt. Verwenden Sie diese Einstellung nur, wenn der OPC UA-Client keine höhere Verschlüsselung unterstützt.
  • 'Basis 256 Algorithmus aktivieren'
    Dieser Basis 256-Algorithmus ist veraltet und deshalb auf 'Nein' voreingestellt. Verwenden Sie diese Einstellung nur, wenn der OPC UA-Client keine höhere Verschlüsselung unterstützt.
  • 'Basis 256 SHA256 Algorithmus aktivieren'
    Dieser Basis 256 SHA256-Algorithmus ist veraltet und deshalb auf 'Nein' voreingestellt. Verwenden Sie diese Einstellung nur, wenn der OPC UA-Client keine höhere Verschlüsselung unterstützt.
  • 'AES 128 SHA256 RSA OAEP Algorithmus aktivieren'
  • 'AES 256 SHA256 RSA PSS Algorithmus aktivieren'
Anwendung
  • 'Trust Store zur Client-Authentifizierung verwenden' (Voreinstellung 'Ja')

    Falls aktiviert, werden der TrustStore (TrustList im Sinne der OPC UA-Spez.) sowie die Zertifikatsperrliste (Certificate Revocation List, CRL) bei der Authentifizierung aller OPC UA-Clients verwendet, die sich mit dem OPC UA-Server verbinden möchten. Folglich können sich nur Clients verbinden, deren Zertifikat im TrustStore abgelegt ist. Sowohl der TrustStore als auch die CRL können im WBM der Steuerung eingesehen und bearbeitet werden.
    Eine Beschreibung des TrustStore finden Sie weiter oben in dieser Tabelle. Weitere Informationen zur CRL finden Sie im Thema "Security-Begriffe und Hintergrundinformationen" (Link über dieser Tabelle).

    Wir empfehlen, die Voreinstellung zu belassen. Falls hier 'Nein' ausgewählt ist, werden der TrustStore und die Zertifikatsperrliste nicht angewendet.

  • 'Anwendungs-URI gegen Client-Zertifikat prüfen' (Voreinstellung 'Ja')

    Falls aktiviert, verifiziert der OPC UA-Server die ApplicationURI aus der ApplicationDescription, indem er sie mit dem SubjectAlternativeName.URI im Client-Zertifikat vergleicht. Beide URIs werden vom OPC UA-Client an den Server übergeben, wenn der Verbindungsaufbau initiiert wird.

    Wir empfehlen, die Voreinstellung zu belassen. Falls hier 'Nein' eingestellt ist, werden Unterschiede zwischen der Anwendungs-URI aus der ApplicationDescription und der im Client-Zertifikat enthaltenen URI vom OPC UA-Server ignoriert.