Einführung
Systemvoraussetzungen
Betriebssystem:
- Um alle Funktionen zum Schutz der Anwendungssoftware nutzen zu können, ist mindestens Windows 7 (bzw. dessen Embedded-Version) erforderlich. Windows XP und Windows CE (Windows Embedded Compact) unterstützen weder die Verschlüsselung der Boot-Datei noch OEM-Lizenzen.
TwinCAT-Version:
- Die beschriebenen Funktionalitäten erfordern mindestens TwinCAT 3.1 Build 4022.
 | Sicherer Schutz nur bei Verwendung der neuesten TwinCAT-3-Version Verwenden Sie für einen sicheren Schutz (z. B. eine sichere Verschlüsselung) immer die neueste TwinCAT-3-Version. Diese bietet die höchste Sicherheit. Verwenden Sie mindestens TwinCAT 3.1 Build 4024.x. |
| Download-Link: Planungstabelle für Gruppenrechte und Object Protection Level Eine Excel-Tabelle zur einfachen Planung von Gruppenrechten und Zugriffsberechtigungsgruppensets (Object Protection Level) können Sie hier herunterladen. |
TwinCAT Benutzerzugriffsrechte
- Zugriffsrechte werden im TwinCAT 3 Engineering Gruppen zugewiesen.
- Benutzer können mehreren Gruppen zugewiesen werden.
- Gruppen können Mitglied einer anderen Gruppe sein.
Hinweis: Für eine bessere Übersicht wird empfohlen, Gruppen nicht einer anderen Gruppe zuzuordnen, sondern die Gruppe am besten komplett eigenständig mit Rechten zu versehen.
Rechte sind im TwinCAT 3 Engineering in zwei Hauptkategorien aufgeteilt:
- Allgemeine Rechte im Projekt (z. B. das Recht, Dateien zu signieren). Diese sind Benutzergruppen einzeln zugeordnet, da sie immer für das gesamte Projekt gelten.
- Komponenten-spezifische Rechte („View“, „Delete“, „Modify“ und „Add/Remove Children“).
Da diese für verschiedene Komponenten eines Projekts je nach Gruppenzugehörigkeit unterschiedlich sein können, sind sie in einem „Rechte-Set“ organisiert, dass die einzelnen Rechte aller Gruppen unter einer Bezeichnung zusammenfasst.
Im Bild oben ausgegraute Rechte sind im aktuellen Stand „für zukünftige Verwendung“ vorgesehen und noch nicht implementiert.
Ein solches Rechte-Set wird als „Object Protection Level“ bezeichnet, und stellt eine Matrix aus den vorhandenen Gruppen und deren Rechten für ein Objekt dar. Mit einem Object Protection Level kann man einzelne Projektkomponenten komfortabel mit vorgefertigten Rechte-Sets für jeweils alle Gruppen auf einmal versehen, und muss diese nicht gruppenweise jeder Projektkomponente zuordnen.
Wenn sich die Objekte eines Projekts nicht bezüglich des Sets an Zugriffsrechten unterscheiden (einfachster Anwendungsfall), reicht die Definition und Nutzung eines einzigen Object Protection Level aus. Dieser wird dann allen Objekten des Projektes zugewiesen.
Im Beispiel oben darf die Gruppe Entwickler alles, außer Änderungen an der Datenbank zu machen, die Gruppe Administrator darf nur Änderungen an der Datenbank machen, und die Gruppe Guest darf gar nichts (nicht einmal das Projekt laden).
Beachten Sie dabei die Mitgliedschaft von Gruppen in anderen Gruppen!
Beispiel 1
Im folgenden Beispiel soll eine neue Gruppe „GRP_OEMService“ hinzugefügt werden.
(Das Erstellen einer neuen Gruppe und die Zuweisung der Rechte ist hier beschrieben.)
Die neue Gruppe darf alles sehen, aber nichts ändern, und darf das Projekt aktivieren.
Um das Projekt ansehen zu können, muss die Gruppe das Recht „Decrypt Project Files“ haben (sonst kann Visual Studio die verschlüsselten Teile des Projektes nicht laden).
Für das Aktivieren des Projektes ist es neben dem Recht „Activate Configuration“ erforderlich, die Projektdatei modifizieren zu können (da dort beim Aktivieren bestimmte Informationen hinterlegt werden), als auch das verschlüsselte Speichern dieser Änderungen. Daher sind noch die Rechte „Change Project File“ und „Encrypt Project Files“ erforderlich.
Bei den Komponenten-spezifischen Rechten ist nur „View“ notwendig.
Ein neuer Object Protection Level muss nicht erstellt werden, da dieses Rechte-Set immer für das gesamte Projekt gelten soll.
Beispiel 2
Im nächsten Beispiel soll die Gruppe „GRP_OEMService“ nur noch definierte Komponenten des Projektes ansehen können.
Dazu ist es erforderlich, ein neues Gruppenrechteset, also einen neuen Object Protection Level (OPL), anzulegen, um die jeweilige Rechtezuweisung für eine bestimmte Projektkomponente differenzieren zu können. Den neuen OPL nennen wir „OPL_OEMService“.
(Das Erstellen eines neuen Object Protection Levels ist hier beschrieben.)
Das View-Recht für die Gruppe GRP_OEMService wird nun aus dem „OPL_OEMDev“ herausgenommen und im neuen „OPL_OEMService“ hinzugefügt:
Da die Gruppe „GRP_OEMDev“ auch im neuen „OPL_OEMService“ alles machen darf, wurden dort für diese Gruppe ebenfalls alle Rechte (View, Modify, …) eingetragen.
Beispiel 3
Im nächsten Beispiel soll die Gruppe GRP_OEMService zusätzlich bei bestimmten Projektkomponenten auch Änderungen vornehmen dürfen. (Sie darf allerdings (weiterhin) keine Projektkomponenten löschen oder hinzufügen.)
Dafür muss ein weiterer neuer Object Protection Level (OPL) angelegt werden. Wir nennen ihn „OPL_OEMServiceEdit“:
Gegenüber OPL_OEMService kommt hier nur das Recht „Modify“ hinzu, der Rest ist identisch.
Projektkomponenten, die dem OPL_OEMServiceEdit zugeordnet werden, dürfen nun von Benutzern der Gruppe GRP_OEMService auch verändert werden.
Zuweisung der Object Protection Level im Projekt
Nun müssen wir die in den vorherigen Beispielen erstellten OPLs nur noch den Projektkomponenten zuweisen. (Wie die Zuweisung des OPLs genau im TwinCAT Engineering erfolgt, ist hier beschrieben.)
| OPL wird vererbt Der der Wurzel des PLC-Projektes zugewiesene OPL wird in die darunter liegenden Knoten vererbt. Nur die Knoten, die eine andere Einstellung als die PLC Projekt-Wurzel benötigen, müssen individuell mit dem erforderlichen OPL konfiguriert werden. |
Beispiel 4
Im folgenden Beispiel soll der Fall behandelt werden, dass der Servicemitarbeiter ein Projekt aktivieren, aber nicht einsehen darf.
Da hier eine spezielle Rechtekonfiguration nur für den Root des PLC-Projektes erforderlich ist, benötigen wir hierfür einen eigenen Object Protection Level. Wir nennen ihn „OPL_OEMServAct“:
Im Unterschied zum Beispiel 2 hat hier die Gruppe „GRP_OEMService“ nur Modify-, aber keine View-Rechte. „View“ ist nicht in „Modify“ enthalten.
Visual Studio benötigt das „Modify“-Recht für die Projektdatei, da dort bei der Aktivierung Änderungen erfolgen müssen.
Bei der Zuweisung der OPLs wird die Projektwurzel nun mit dem „OPL_OEMServAct“ versehen.
Da sich diese Eigenschaft aber an die unterhalb der Wurzel liegenden Projektkomponenten weitervererbt (sofern dort keine expliziten individuellen Einstellungen gemacht wurden), müssen die unterhalb der Wurzel liegenden Projektkomponenten gegebenenfalls einzeln manuell auf einen anderen OPL umgestellt werden. Die komfortable Vererbungsfunktion der PLC Wurzeleigenschaften kann dann in diesem Fall nicht verwendet werden.