MaxL Benutzername- und Passwort Verschlüsslung

Warum ein Blog über ein so altes Thema, werden sie sich fragen. Nun, es kommt noch immer vor, dass MaxL Dateien in Prozesse einen Benutzernamen und Passwort in Klartext haben. Ja, solche MaxL Dateien liegen meistens auf einem gesicherten Laufwerk und es gibt noch mindestens 100 andere Ausreden, warum diese nicht verschlüsselt sind. Dieser Beitrag sollte zeigen, wie einfach es ist. Planen sie es als internen Change ein und führen sie es durch.

Alle Sicherheitsmaßnahmen kosten Arbeit und 100%ige Sicherheit gibt es nicht. Man sollte es den Kriminellen aber nicht zu einfach machen. Legen sie den Haustürschlüssel auch unter die Fußmatte wenn sie in den Urlaub fahren? Nein, warum verschlüsseln sie dann nicht den Benutzernamen und Password in den MaxL Skripten der Firma? So wie ihre Privatversicherung bei Fahrlässigkeit nicht zahlt, wird sie auch in der Firma niemand beneiden, wenn die Gründe für einen Einbruch auf die Essbase Server in dem Umgang mit Klartext Benutzername und Passwort liegen.

Wie wird es gemacht?

Schritt 1. Ich erzeuge einen öffentlichen und einen geheimen Schlüssel. Ich rufe MaxL auf mit essmsh und verwende die Parameter –gk.

Abbildung 1: Erzeugen von einem privaten und öffentlichen Schlüssel

C:\startMaxl.bat -gk

Der „Public Key” wird zum Verschlüsseln und der „Private Key“ zum Entschlüsseln verwendet.

In dem Schritt 2 erstelle ich als Beispiel ein einfaches MaxL Skript mit einem Text-Editor. In diesem Skript melde ich mich am Essbase Server an und lass mir die Variablen anzeigen. Danach melde ich mich wieder ab und schließe MaxL. Ich nenne dieses Skript login.txt und lege es auf C:\

login admin password on 2008SR2SRV;

display variable;

logout;

exit;

Der nächste Schritt ist dass ich dieses Skript mit MaxL und dem öffentlichen Schlüssel dann verarbeite. Hierzu wird das essmsh mit dem Parameter –E verwendet.

Abbildung 2: Erstellen der Logindetails mit dem öffentlichen Schlüssel

C:\startMaxl.bat -E „c:\login.txt“ 32321,1957532383

Es erscheint eine Nachricht, dass dieses geschehen ist und es gibt jetzt eine neue Datei. Diese hat denselben Namen, nur ein „s“ wurde angehängt. In unserem Fall ist der Name login.txts

Abbildung 3: Eine neue Datei mit dem Namen login.txts

Wenn wir uns dann die Datei ansehen, dann wurden darin der Benutzername und das Passwort durch Schlüssel umgewandelt.

Abbildung 4: Datei mit verschlüsseltem Benutzernamen und Passwort.

Diese Login Zeile kann in alle weiteren MaxL Skripte kopiert werden. Es ist nicht nötig, jedes MaxL Skript einzeln zu verschlüsseln, solange man den privaten Schlüssel hat, um die Skripte auszuführen.

Der letzte Schritt ist, dass wir dieses verschlüsselte MaxL Skript mit dem privaten Schlüssel ausführen. Dieses kommt als Parameter hinter dem Dateinamen im Aufruf.

Abbildung 5: Login mit den Schlüsseln.

essmsh -D „c:\login.txts“ 661584641,1957532383

Es ist also wichtig, die Schlüsselpaare vertraulich und gut gesichert zu haben.

 

Passwortänderung

Sollte das Passwort des Benutzers verändert werden, dann muss ein neuer Satz Schlüssel erzeugt werden. Hiermit erzeugt man einmalig einen neuen Login mit dem verschlüsselten Benutzername und Passwort.

Dieser muss dann erneut in alle MaxL Skripte kopiert werden.

Auch in dem Aufruf muss dann der neue private Schlüssel aufgenommen werden.

Dieses ist doch unter Umständen mit Aufwand verbunden. Sicherheit gibt es eben nicht zum Nulltarif.

 

Zum Abschluss

Eine wertvolle Erweiterung wäre der Ansatz, den es im Oracle Planning gibt. Hier kann eine Password Datei erstellt werden, in der das verschlüsselte Passwort liegt. Dieses geht einfach mit

D:\Oracle\Middleware\user_projects\foundation1\Planning\planning1\PasswordEncryption.cmd

D:\Oracle\Middleware\user_projects\foundation1\Planning\planning1\Password\password.txt

In einem CalcManagerLaunch Befehl gibt man als Parameter den Benutzernamen und den Pfad und Namen der Password Datei an. Hierdurch ist es viel einfacher, die Skripte von Server zu Server zu bewegen und regelmäßig das Password zu ändern.

Bei Kunden sehe ich oft, dass eine UserID für alle Applikationen und alle Skripte verwendet wird. Oft hat dieser User auch Essbase Administrator Rechte, oder sogar Administrator Rechte auf dem gesamten EPM System. Wenn dieser User in Skripte nur Daten lädt dann könnten die Rechte ja vielleicht heruntergesetzt werden auf z.B. die „Database Manager“ Rolle.

Wenn Essbase eine CPU-Lizenz hat, wäre es auch möglich, verschiedene Benutzer für verschiedene Applikationen zu verwenden. Damit kann der unerlaubte Zugriff mit einem fälschlicherweise erhaltenen UserID und Password beschränkt werden.

 

Ihr Philip Hulsebosch