Essbase : chiffrement des paramètres de connexion des scripts MaxL

Sébastien Roux

Cet article décrit les options de chiffrement proposées par la ligne de commande MaxL à partir de la version 9.3.1 d'Essbase. Ces options permettent de masquer les paramètres de connexion aussi bien dans le script que dans son compte-rendu d'exécution en apportant ainsi une bien meilleure sécurité.

Commentez

- Titre : Essbase : chiffrement des paramètres de connexion des scripts MaxL

- Auteur : Sébastien Roux

- Parution : 2 juillet 2009

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2009 Sébastien Roux. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Génération des clés

- II-A. Rappel du principe de chiffrement par clé publique et clé privée

- II-B. Cas pratique appliqué à MaxL

- III. Chiffrement d'un script MaxL

- III-A. Support d'exercice

- III-B. Chiffrement du script à partir de la clé publique

- IV. Chiffrement d'une chaîne de caractères

- V. Exécution d'un script MaxL chiffré

- VI. Conclusion

I - Introduction

Cet article aborde les différentes options de chiffrement apportées par MaxL, il vient enrichir l'article MaxL et ESSCMD, les langages d'administration d'Essbase réalisé par mon confrère Antoun.

MaxL est un des langages d'administration d'Essbase qui est apparu en 2001, avec le lancement de la version 6.1 du serveur MOLAP alors édité par la société Hyperion.
MaxL ou Multi-dimensional (M) Access (AX) Language (L) est accessible à travers une interface en ligne de commande et permet d'administrer le moteur (propriétés etc...) ainsi que les bases (caches, alimentation, export, sécurité etc...).
Si vous souhaitez plus de précisions au sujet d'Essbase je vous invite à consulter la présentation d'Oracle Hyperion Essbase.

Un des reproches qui peut être fait à MaxL concerne son manque de sécurité. Il arrive souvent que les paramètres de connexion soient stockés en dur dans le script ; ceux-ci comprennent le compte utilisateur, s'agissant souvent d'un compte administrateur, ainsi que le mot de passe associé. Par ailleurs le compte-rendu d'exécution, en interactif, dans le shell, ou redirigé vers un fichier (cf commande spool), restitue toutes ces informations en clair.

Exemple de compte-rendu d'un script MaxL

Essbase MaxL Shell - Release 11.1.1 (ESB11.1.1.2.0B110)
Copyright (c) 2000, 2008, Oracle and/or its affiliates.
All rights reserved.

MAXL> login 'admin' 'password' on 'sr-dev';

OK/INFO - 1051034 - Logging in user [admin].
OK/INFO - 1051035 - Last login on Sunday, April 19, 2009 3:19:26 PM.
...
OK/INFO - 1007067 - Total Restructure Elapsed Time : [1.062] seconds.
OK/INFO - 1013273 - Database Demo.Basic altered.

MAXL> alter application 'Demo' unload database 'Basic';

OK/INFO - 1056013 - Application Demo altered.

MAXL> logout;

User admin is logged out

MaxL Shell completed

A partir de la version 9.3.1 d'Essbase, MaxL propose des fonctionnalités de chiffrement des paramètres de connexion, nom d'utilisateur et mot de passe. Le principe reste relativement simple, deux clés sont générées, la première servant au chiffrement du script MaxL existant, la seconde permettant son exécution sécurisée.

Tout au long de cet article nous aborderons la démarche de chiffrement/déchiffrement qui se résume aux étapes suivantes :

1. génération des clés,

2. production des versions chiffrées (.mxls) des scripts existants (.mxl),

3. exécution des scripts chiffrés à l'aide de la clé de déchiffrage.

II - Génération des clés

II-A - Rappel du principe de chiffrement par clé publique et clé privée

Je vous invite à consulter l'article de ram-0000 intitulé : Introduction à la cryptographie. Le chapitre 8 aborde les algorithmes asymétriques employés par MaxL à partir de la version 9.3.1 d'Essbase.
Nous y apprenons que l'algorithme asymétrique comprend l'utilisation de deux clés liées mathématiquement entre elles, une pour le chiffrement et l'autre pour le déchiffrement du message. On parle alors de clé publique et de clé privée.
Précisons que l'on peut également chiffrer à partir d'une clé privée et déchiffrer à partir d'un clé publique, on parle alors de signature.

II-B - Cas pratique appliqué à MaxL

L'argument gk (generate keys) permet de générer deux clés, une publique et une privée, destinées, respectivement, au chiffrement ou au déchiffrement des paramètres de connexion (nom d'utilisateur et mot de passe) du script MaxL.

Syntaxe de génération des clés publique et privée

essmsh -gk

Compte-rendu de la génération des clés

Essbase MaxL Shell - Release 11.1.1 (ESB11.1.1.2.0B110)
Copyright (c) 2000, 2008, Oracle and/or its affiliates.
All rights reserved.

Public Key for Encryption: 31457,2452005869
Private Key for Decryption: 1886885153,2452005869

MaxL Shell completed

Dans cet exemple, la chaîne numérique 31457,2452005869 désigne la clé publique (Public Key for Encryption).
La chaîne 1886885153,2452005869 désigne la clé privée (Private Key for Decryption).

III - Chiffrement d'un script MaxL

III-A - Support d'exercice

Nous travaillerons à partir de l'exemple suivant :

Exemple de script Maxl

/*
* Script MaxL (essmsh)
* Nom : test_encrypt.mxl
* Description : retructuration dense de la database
*/

/* Connexion */
login 'admin' 'password' on 'sr-dev';

/* Démarrage base */
alter application 'Demo' load database 'Basic';
/* Restructuration */
alter database 'Demo'.'Basic' force restructure;
/* Arrêt database */
alter application 'Demo' unload database 'Basic';

/* Deconnexion */
logout;

Ce script complet permet d'effectuer une restructuration dense de la base Basic de l'application Demo après son démarrage. La base est ensuite arrêtée.
La partie qui nous intéresse ici concerne la chaîne de connexion login. En effet, dans MaxL, toute exécution de commandes visant le serveur, les applications ou les bases requiert au préalable une identification grâce à la commande login. Cette commande prend en arguments le nom de l'utilisateur, le mot de passe ainsi que le serveur concerné.

Les paramètres de connexion, nom d'utilisateur et mot de passe, sont en clair dans le script, c'est à dire qu'il ne sont pas chiffrés et sont donc accessibles et "réutilisables" à souhait par tout utilisateur, mal intentionné ou pas, accédant au code source.
Il est possible de passer au script MaxL les identifiants de connexion sous forme de paramètres, cependant le compte-rendu les restituera en clair comme évoqué plus haut.

III-B - Chiffrement du script à partir de la clé publique

Une fois la clé publique générée, le script MaxL peut être chiffré.

Chiffrement d'un script MaxL (test_encrypt.mxl)

essmsh -E nom_du_script clé_publique

essmsh -E test_encrypt.mxl 31457,2452005869

L'argument E (encrypt) chiffre le script passé en paramètre ainsi que les scripts imbriqués (scripts appelés à partir du script principal).
L'argument Em (manual encrypt) ne chiffre en revanche que le script passé en paramètre en laissant le choix de chiffrer manuellement les scripts imbriqués.
Lors du chiffrement, l'extension du script est renommée en mxls (secured).

Script MaxL chiffré (test_encrypt.mxls)

/*
* Script MaxL (essmsh.exe)
* Nom script: test_encrypt.mxl
* Description : retructuration dense de la database
*/

/* Connexion */
login $key 981630429104940329104883561011 $key 5333125661686864888155234409808770538781 on 'sr-dev';

/* Démarrage base */
alter application 'Demo' load database 'Basic';
/* Restructuration */
alter database 'Demo'.'Basic' force restructure;
/* Arrêt database */
alter application 'Demo' unload database 'Basic';

/* Deconnexion */
logout;

Nous pouvons constater que seuls les arguments de la commande de connexion sont chiffrés.

Chaînes de connexion chiffrées

/* Connexion */
login $key 981630429104940329104883561011 $key 5333125661686864888155234409808770538781 on 'sr-dev';

Pour information, l'absence de la commande login dans le script n'est pas bloquante pour le bon déroulement de l'opération de chiffrement. Dans ce cas le chiffrement perd alors tout son intérêt...

IV - Chiffrement d'une chaîne de caractères

MaxL propose également une option pour chiffrer une chaîne de caractère au choix.

Chiffrement d'une chaîne de caractères

essmsh -ep ma_chaîne clé_publique

essmsh -ep admin 31457,2452005869

Compte-rendu d'exécution du chiffrement d'une chaîne de caractères

Essbase MaxL Shell - Release 11.1.1 (ESB11.1.1.2.0B110)
Copyright (c) 2000, 2008, Oracle and/or its affiliates.
All rights reserved.

Encrypted Data: 981630429104940329104883561011

MaxL Shell completed

L'argument ep (encrypt input data) permet de chiffrer une chaîne de caractères. La chaîne cryptée peut être récupérée à partir des commandes cut, grep, awk etc. accessibles à partir des shells Unix/Linux (shell, korn shell etc.), des langages de scripts (Perl, VBScript etc.), ou même à partir de la ligne de commande Windows (SFU, GnuWin32).

V - Exécution d'un script MaxL chiffré

Le script chiffré est déchiffré puis exécuté grâce à la clé privée préalablement générée.

Déchiffrement et exécution d'un script MaxL chiffré (test_encrypt.mxls)

essmsh.exe -D nom_du_script clé_privée

essmsh -D test_encrypt.mxls 1886885153,2452005869

L'argument D (decrypt) permet de déchiffrer les paramètres chiffrés puis d'exécuter le script.

Compte-rendu d'exécution du script MaxL chiffré

MAXL> login $key 981630429104940329104883561011 $key 533312566168686488815523440
9808770538781 on 'sr-dev';

OK/INFO - 1051034 - Logging in user [admin].
OK/INFO - 1051035 - Last login on Saturday, April 18, 2009 11:19:27 AM.
OK/INFO - 1241001 - Logged in to Essbase.

MAXL> alter application 'Demo' load database 'Basic';

OK/INFO - 1056013 - Application Demo altered.

MAXL> alter database 'Demo'.'Basic' force restructure;

OK/INFO - 1019017 - Reading Parameters For Database [Drxxxxxx].
OK/INFO - 1019013 - Writing Outline For Database [Basic].
...
OK/INFO - 1007067 - Total Restructure Elapsed Time : [0.25] seconds.
OK/INFO - 1013273 - Database Demo.Basic altered.

MAXL> alter application 'Demo' unload database 'Basic';

OK/INFO - 1056013 - Application Demo altered.

MAXL> logout;

User admin is logged out

Comme nous pouvons le constater dans le compte-rendu d'exécution, les paramètres de connexion sont bel et bien chiffrés. Cela permet d'éviter de retoucher la sortie pour en supprimer les chaînes de connexion.

VI - Conclusion

Cet article était l'occasion de présenter en détail les différentes fonctionnalités de chiffrement proposées par la ligne de commande MaxL.

Quelle est exactement la protection apportée par ce système de chiffrement ? Classiquement, l'intérêt des algorithmes à clé publique est d'éviter le problème de la transmission des clés ; autrement dit, Alice et Bernard n'ont pas besoin d'échanger leurs clés privées pour communiquer de manière sécurisée. En l'espèce, comme les scripts chiffrés (.MXLS) doivent être envoyés au serveur Essbase avec la clé de déchiffrement (clé privée), on voit que la sécurisation ne couvre pas la communication entre l'opérateur (ou l'ordonnanceur) et le serveur Essbase. Cela n'est pas forcément un problème, dans la mesure où cette communication est généralement couverte par la sécurité réseau (notamment le protocole SSL) ; mais on voit qu'en fait l'algorithme de chiffrement asymétrique est sous-utilisé, ou plus précisément que sa sécurité est dégradée au niveau d'un algorithme de chiffrement standard par un processus ne respectant pas les principes de l'infrastructure à clé publique (PKI).

En fait, ce qui est sécurisé, ce sont les éléments persistants : les scripts chiffrés d'un côté, les comptes-rendus d'exécution de l'autre, avec la limite que la clé privée doit elle aussi être stockée côté client (même si on peut imaginer qu'il est plus facile de sécuriser ce stockage d'une clé que celui de scripts et comptes-rendus intégraux). Cette fonctionnalité de chiffrement, apportée par la version 9.3.1, vient ainsi combler la grosse faille de sécurité évidente de MaxL, mais sans aller au-delà. Il en irait tout autrement si une PKI était mise en place, où le serveur Essbase garderait sa clé privée pour lui, en ne transmettant que sa clé publique. Etant donné le peu d'adaptation nécessaire, on peut raisonnablement espérer que cela sera mis en place dans une future version.

Je remercie Antoun pour cette brillante conclusion ainsi pour que sa relecture et ses conseils toujours aussi avisés. Je remercie également ram-0000 pour sa relecture et ses retours au sujet des problématiques de chiffrement asymétrique.