Security-Begriffe und Hintergrundinformationen

• Integrität: Sind die Daten unverändert?

  Grundsätzlich kann Integrität erreicht werden, indem man Daten mit einem Schlüsselpaar (privater und öffentlicher Schlüssel) verschlüsselt/entschlüsselt: Zur Verschlüsselung wird der öffentliche Schlüssel verwendet. Um diese Daten wieder zu Klardaten zu entschlüsseln, muss der zugehörige private Schlüssel eingesetzt werden. Auf diese Weise verhindert die Verschlüsselung die nicht autorisierte Einsicht.

  Außerdem wird die Integrität veröffentlichter Bibliotheken in PLCnext Engineer durch Prüfsummen verifiziert. Weitere Informationen finden Sie unter "Manipulationsschutz für Bibliotheken".

• Authentifizierung: Woher kommen die Daten?

  In PLCnext Engineer werden Zertifikate zur Authentifizierung verwendet (siehe Thema "Netzwerk-Security: Zertifikate ermöglichen gesicherte Verbindungen"). In diesem Zusammenhang ist das Paar aus öffentlichem und privatem Schlüssel relevant.

  Darüber hinaus wird in PLCnext Engineer ein Zertifikat zur 'Code-Signierung' (Code Signing) mit einem privaten Schlüssel benötigt, um sicherheitsbezogene C-Funktionsbaustein-POEs mit nachladbarem C-Funktionscode als Bibliothek veröffentlichen zu können. Mit Hilfe der daraus resultierenden Signatur kann sowohl die Integrität als auch die Authentizität der Bibliothek verifiziert werden.

• Autorisierung: Besteht eine Zugriffsberechtigung?

  In PLCnext Engineer müssen eine Benutzerrolle und ein Kennwort eingegeben werden, um auf die Steuerung zugreifen zu können.

  Außerdem müssen sich Anwender im sicherheitsbezogenen Bereich anmelden, um sicherheitsbezogene Projektteile bearbeiten zu können.

Asymmetrische Kryptografie basiert auf individuellen Schlüsselpaaren. Jede Kommunikationspartei besitzt einen eigenen, eindeutigen, privaten Schlüssel, der zu genau einem öffentlichen Schlüssel passt.

Den privaten Schlüssel muss eine Partei (Inhaber) geheim halten. Der öffentliche Schlüssel kann mit Hilfe eines Zertifikats verteilt werden. Indem das Zertifikat mit dem darin enthaltenen öffentlichen Schlüssel an andere Parteien weitergegeben wird, können diese Empfänger die Identität des Inhabers verifizieren.
Lesen Sie hierzu den folgenden Abschnitt.

Ein Zertifikat ist ein elektronisches, digital signiertes und fälschungssicheres Identitätsdokument (Datenstruktur).
Ein Zertifikat...Authentifizierung mit Hilfe von Zertifikaten:

Nach der gegenseitigen Verifizierung der Anwendungen kann ein gesicherter Kommunikationskanal zwischen den authentifizierten Anwendungen geöffnet werden.

Der Inhalt von Zertifikaten ist nicht verschlüsselt sondern Klartext. Dank ihrer Signatur müssen Zertifikate nicht gesichert werden. Daher dürfen sie z.B. per E-Mail verteilt werden (an beteiligte Anwendungen/Administratoren).

Eine Certificate Authority (CA) ist ein Administrator, eine Organisation oder eine Anwendung, die Zertifikate ausstellt, d.h. Zertifikate für andere Inhaber erzeugt und mit Hilfe des privaten Schlüssels der CA signiert. Inhaber (Subjekt bzw. Besitzer) und Aussteller des Zertifikats sind nicht identisch. Die ausstellende CA schreibt anstelle ihres eigenen öffentlichen Schlüssels (wie sie es beim "Selbst-signieren" macht), den öffentlichen Schlüssel des Inhabers, für den das Zertifikat erstellt werden soll, in das Zertifikat.

Ein selbst-signiertes Zertifikat entsteht, wenn eine Anwendung ihr eigenes Zertifikat ausstellt und es mit ihrem eigenen privaten Schlüssel signiert. In einem selbst-signierten Zertifikat sind Subjekt (Inhaber, Besitzer) und Aussteller identisch. Zur Sicherung der Kommunikation zwischen einer kleinen Anzahl von Anwendungen kann die Verwendung selbst-signierter Zertifikate praktikabel sein. Um die Kommunikation in großen verteilten Netzwerken mit vielen Anwendungen zu sichern, empfehlen sich Zertifikate, die durch eine Certificate Authority (CA), d.h. eine Zertifizierungsstelle, ausgestellt wurden. Es sind auch hierarchische Zertifizierungsstrukturen mit einem oder mehreren Ausstellern und Subaussteller-Ebenen möglich.

Hinweis Für die Kommunikation zwischen PLCnext Technology-Steuerung und PLCnext Engineer, können keine selbst-signierten Zertifikate eingesetzt werden.

Eine Certificate Authority (CA) erzeugt und signiert ein Zertifikat nur auf Anfrage. Diese Anfrage wird als Zertifikatsantrag (Certificate Signing Request, CSR) bezeichnet. Mit dem CSR empfängt die CA detaillierte Informationen über den Inhaber, der das Zertifikat anfordert (Inhaber-/Besitzer-Attribute) sowie den öffentlichen Schlüssel des Inhabers, um diese Daten in das Zertifikat zu integrieren.

Wenn eine CA für einen bestimmten Inhaber ein Zertifikat ausstellt, muss sie die zukünftigen Fähigkeiten des Inhabers definieren. Entweder kann das Zertifikat nur zur Authentifizierung verwendet werden, oder es macht seinen Inhaber (durch Bewilligung weiterer Fähigkeiten, wie z.B. "Certificate Sign" oder "CRL Sign") selbst zum Aussteller, der anderen Inhabern ebenfalls Zertifikate ausstellen darf. Auf diese Weise kann eine hierarchische Zertifizierungsstruktur gebildet werden.

In einer hierarchischen Zertifizierungsstruktur wird die CA als Wurzelknoten betrachtet. Das CA-Zertifikat (Wurzelzertifikat) wird "Trusted Anchor" genannt. In der Ebene darunter können weitere Aussteller (Sub-CAs) folgen, jeder mit dem Recht, ebenfalls Zertifikate auszustellen. Deren eigene Zertifikate werden Ausstellerzertifikate genannt. Weitere Unterebenen mit Subsub-CAs sind möglich. Die Zertifikate auf Anwendungsebene (z.B. Steuerung und PLCnext Engineer oder OPC UA-Server und Clients) werden Anwendungszertifikate genannt.

In einer hierarchischen Zertifizierungsstruktur kann ein Zertifikat (z.B. das Gerätezertifikat einer PLCnext Technology-Steuerung oder das Anwendungszertifikat eines OPC UA-Client) nur verifiziert werden, indem der gesamte Zertifizierungspfad ab diesem bestimmten Zertifikat bis zum Trusted Anchor (Wurzelzertifikat) authentifiziert wird.

Für die Kommunikation zwischen PLCnext Technology-Steuerung und PLCnext Engineer erfolgt dies durch

Eine Zertifikatsperrliste (CRL) ist eine Liste, welche die Ungültigkeit von Zertifikaten beschreibt. Eine CRL spezifiziert Zertifikate, die von Anwendungsinstanzen oder Geräten nicht akzeptiert werden dürfen. Ein Zertifikat kann widerrufen werden, wenn der entsprechende private Schlüssel (der dem Zertifikatsinhaber gehört) kompromittiert wurde oder falls das Zertifikat nicht mehr gültigen Inhalte enthält (z.B. veralteter Anwendungsinstanz-URI nach Migration der Anwendung auf einen anderen Computer).

CRLs können von Ausstellern erstellt werden (CA oder Sub-CA), die mit den Rechten für das Ausstellen von CRLs ("Sign CRL") ausgestattet sind. Um ein Zertifikat zu widerrufen, fügt die CA die entsprechende Seriennummer des Zertifikats (und möglicherweise mehr) zur CRL hinzu. Um die CRL zu sichern, wird sie ebenfalls von der CA mit ihrem privaten Schlüssel signiert und erhält einen Zeitstempel. Dadurch können Anwendungen die Authentifizierung, Integrität und Gültigkeit einer CRL prüfen, bevor sie deren Inhalt auswerten.

Da die Authentifizierung normalerweise nur während des Verbindungsaufbaus erfolgt, wertet eine Anwendungsinstanz die CRL nur bei jeder Authentifizierung eines Zertifikats aus.

Folglich werden bestehende Verbindungen nicht getrennt, wenn ein Zertifikat, welches während des Verbindungsaufbaus verwendet wurde, später widerrufen wird. Solche Verbindungen müssen manuell getrennt werden, z.B. wenn ein privater Schlüssel kompromittiert oder gestohlen wurde. Die Verbindung kann auch durch einen Neustart der betroffenen Geräte oder Anwendungsinstanzen getrennt werden.

Eine CA hat auf Anfrage Zertifikate für einen Server und eine Client-Anwendung ausgestellt. Dies stellt eine Zertifizierungshierarchie auf zwei Ebenen dar.

Gegenseitige Authentifizierung: Um ihre Identitäten zu authentifizieren, prüft jede Anwendung das Zertifikat der anderen Anwendung unter Verwendung des öffentlichen Schlüssels der anderen Anwendung. Nach erfolgreicher Authentifizierung kann ein sicherer Kommunikationskanal geöffnet werden.

Die CA hat zusätzlich eine CRL ausgestellt. Die Anwendung kann diese CRL während der Authentifizierung auswerten, um sicherzustellen, dass ein zu authentifizierendes Zertifikat nicht widerrufen wurde. Eine Kommunikation wird nur aufgebaut, wenn das beteiligte Zertifikat nicht in der CRL gelistet ist.