Ich weiß schon seit langem über PML-Verschlüsselung Bescheid, und ich war immer der Meinung, dass dies in den meisten Fällen eine schlechte Idee ist. Das kommt aus der Erfahrung und dem Wissen um die Code-Verschleierung: Im besten Fall ist sie nutzlos (wenn jemand Ihren Code wirklich lesen will, kann er das), und im schlimmsten Fall schadet sie direkt der Qualität Ihres Produkts.
Trotz meiner Einwände stellte ich fest, dass das zentrale Admin team in meinem Unternehmen PML Encryption verwendete und den Quellcode für unsere internen PML-Anwendungen nicht freigeben wollte. Ich hörte sogar von einigen unserer Filialadministratoren, dass ihnen diese Praxis missfiel, und sie fühlten sich durch das Misstrauen, das von unserer Zentrale ausging, sogar beleidigt. Bis zu einem gewissen Grad stimmte ich dem zu, und ich war der Meinung, dass dies zu unnötiger Bürokratie bei der Beantragung von Änderungen und Fehlerbehebungen an diesen Anwendungen führte, da wir sie im Falle eines Fehlers nicht überprüfen konnten.
Schließlich trat ich dem Admin team bei und stellte diese Praxis in Frage. Mit der Zeit verstand ich jedoch, warum unser Team diese Entscheidung traf und warum sie wichtig ist.
Aber zunächst einmal: Wie funktioniert die PML-Verschlüsselung? Nun, nehmen wir an, Sie haben eine nette kleine PML-Datei. Sie müssen eine Lizenz von AVEVA erwerben, um PML Publisher nutzen zu können. Nehmen Sie eine PML-Funktion:
define function .thisFunctionIsEncrypted( )
write 'This function is encrypted.'
endmethod
Sie führen ein kleines Etwas aus:
pmlencrypt "C:\path\thisFunctionIsEncrypted.pmlfnc" "C:\path\encrypted\thisFunctionIsEncrypted.pmlfnc" -rc4
…und voila! Ihre Datei ist verschlüsselt.
--<004>-- Published PML 2.2 >--
return error 99 'Unable to decrypt file in this software version'
$** fbcb609d9d57d847f5f27b3de7bd5a3a
$** QrDB5Y18VpwhIV9LuLWGm8rzchQiHuhM+h-IfeqTMaL9XgDE8DpO6rN0br9w
$** eyQtMZXSE+ZstL3jZ+ndTYK5SX6anTbkq-x1AAfcgJKcKncuiaGqzHMrnDDw
$** aPlGcACq4k8x4UZ7uWN2ek3I6lk3QIU4uEpQ1+4IXkQGc9BNUi7Mh557TPzN
$** ZvntqUxY9B+vTR+7PIqFY5Hn4A--XAgTAsS8OwCpfUb7Denjn3TOtUiBszY0
$** Rr0HeLWnVDX+STRBM42xiFvrdQzafwQsWwwmejfK9-hke6u-35JH7rU5raeF
$** D46lZ2wIgzJYhRIl64btOT+fEIaR0AUCJUq1Rf84F4ybCKyAO-ngJ1JsE1Bq
$** v8h5EWIiDtno8ubPWbWKz-6b8dqqvgzRmgtFUDZJ5ZZsAtpkhGaUpbluIb4V
$** qF5f3fhAtMa4UPphQ4h2tjuFCEZxUhDow8+WDCeT6MgSdXG45YArXsQFyOYC
$** Bui-KGqo2S4GJETw3Nnof0sv3V88OlWYNQ8t0ZaMxPnHPxSedWyyO9AjKTlt
$** Qrdgbrhn3Mlc5yw8X7L
PDMS/E3D liest und verarbeitet die Datei wie gewohnt (Sie können sie in Ihrem eigenen PDMS/E3D testen!), aber der Inhalt ist nicht lesbar und kann natürlich auch nicht bearbeitet werden. Wir haben diesen Schritt in unseren CI-Server integriert, so dass wir uns darüber keine Gedanken mehr machen müssen – wir schieben unseren Code einfach in das Repository und Jenkins generiert unser verschlüsseltes und komprimiertes Paket. Wunderbar! Aber zurück zum Thema: Warum?
Erstens: Versionskonsistenz. PML ist keine kompilierte Sprache, und alle unsere Filialen würden Kopien dieser Dateien erhalten. Die meisten Administratoren (und sogar einige Benutzer) sind fähige Entwickler. Sie würden diese Dateien nehmen und sie so verändern, dass sie ihren Bedürfnissen und Launen entsprechen. Normalerweise ist das in Ordnung – jeder Benutzer sollte die Freiheit haben, seine Arbeit mit den Tools zu automatisieren, die er möchte -, aber es wird zu einem massiven Problem, wenn man an einem globalen Projekt arbeitet und zwei Standorte dieselbe Version einer PML-Anwendung verwenden sollen.
Wenn die Dateien unverschlüsselt sind und die Filialen etwas Kritisches geändert haben, kann es lange dauern, bis jemand herausfindet, dass diese Änderungen vorgenommen wurden, und dann ist Ihr Geschäft gefährdet. Es spielt keine Rolle, ob Sie Ihren Mitarbeitern sagen, dass sie es nicht tun sollen, oder ob Sie ihnen einen strengen Vortrag halten, es ist nur eine Frage der Zeit, bis jemand mit diesen Dateien spielt und ein Geschäftsproblem verursacht. Und jetzt sitzt Ihnen ein verärgerter Projektleiter im Nacken, der Sie fragt, warum Sie seine Ergebnisse verzögern.
Die Deutschen sagen “Vertrauen ist gut, Kontrolle ist besser”. Und jetzt bin ich für Verschlüsselung.
Ein weiterer guter Fall für Verschlüsselung ist die Zusammenarbeit mit Dritten. Wir haben mehrere Anwendungen in unserer Umgebung, die Schnittstellen zu Materialverwaltungssystemen, zur Beschaffung und anderen Bereichen haben. Wenn ein Projekt erfordert, dass wir einige PDMS/E3D-Modellierungen auslagern, müssen wir diese Anwendungen Drittunternehmen zur Verfügung stellen.
Die Verschlüsselung schützt natürlich das geistige Eigentum des Unternehmens, aber Sie können auch Schutzmaßnahmen und zeitlich begrenzte Kontrollen in Ihre Entwicklung einbauen. So können Sie z. B. das aktuelle Banner überprüfen und sicherstellen, dass die Anwendung nur bei Ihrem derzeitigen Partner funktioniert (und niemand den Code woanders hin mitnimmt!):
!banner = BANNER
!company = !banner.company
if (!company.neq('ThirdPartyCompany')) then
return error
endif
Nach der Verschlüsselung ist diese Prüfung nicht mehr änderbar – wenn das Drittunternehmen sie also an jemand anderen weitergibt, wird einfach ein Fehler zurückgegeben. Mit dem gleichen Ansatz ist es auch möglich, diese Dateien mit einer Zeitsperre zu versehen, so dass sie nach einem bestimmten Datum nicht mehr funktionieren.
Sollten Sie also Ihre PML verschlüsseln, sobald sie Ihre Finger verlässt? Es kommt darauf an! Wenn Sie wichtigen Code für Ihr Unternehmen weitergeben und sicherstellen müssen, dass er nicht verändert wird, könnte dies für Sie von großem Nutzen sein. Aber denken Sie daran: Keine Verschlüsselungs- oder Verschleierungsmethode ist 100% sicher, und wie bereits gesagt, wenn jemand Ihren Code unbedingt lesen will, wird er es auch können. Nichtsdestotrotz kann der richtige Einsatz von Verschlüsselung die Sicherheit und Konsistenz Ihres Codes verbessern – etwas, das in “informelleren” Entwicklungsumgebungen leider allzu oft gefährdet ist.