Utilisation de Native SQL et MDX en toute sécurité
Mise à jour : 2009-04-30
Planning Server offre un langage qui vous permet de spécifier facilement des règles de calcul. Ces règles peuvent servir à entrer des données dans un modèle, à déplacer des données dans un modèle ou entre modèles et à calculer de nouvelles valeurs à partir de données existantes, entre autres possibilités. Ces règles peuvent être exécutées par un membre du rôle Modeleur à l'aide de Planning Business Modeler, de deux façons. La première méthode consiste à exécuter une règle en tant qu'élément d'une tâche, qui est alors planifiée ou assignée à un utilisateur d'entreprise. La deuxième méthode consiste à faire exécuter la règle automatiquement par le système chaque fois que des données ont changé. Les membres du rôle Modeleur peuvent également spécifier son exécution dans Microsoft SQL Server 2005 ou MDX, chacun présentant des avantages et des inconvénients en matière de fonctionnalités et de performances.
Dans certaines circonstances, le langage PerformancePoint Expression Language (PEL) risque d'être insuffisant pour les utilisateurs expérimentés. Cela est particulièrement vrai pour nos clients experts sur SQL Server ou MDX qui souhaiteraient améliorer les performances de leurs procédures stockées, utiliser des fonctions intégrées SQL Server que nous ne présentons pas, ou effectuer une opération qui dépasse les possibilités du langage PEL. PEL offre la puissance brute de SQL Server ou MDX, associée à la commodité de notre infrastructure de règles, ce qui permet des styles d'exécution différents.
Pour ce faire, PEL propose une nouvelle implémentation de règles appelée NativeSql et NativeMdxScript. Toutefois, ces nouvelles implémentations peuvent poser un problème de sécurité. Elles pourraient permettre à un utilisateur n'ayant accès qu'à un seul site de modèles d'introduire des modifications radicales dans plusieurs sites de modèles dans l'ensemble de l'application. Plus précisément, Planning Server ne peut faire aucune analyse sur ces règles, car elles sont écrites en SQL ou MDX, que Planning Server ne peut pas facilement analyser. Cela nécessite l'exécution d'une nouvelle implémentation des règles, en tant qu'Identité du service disposant d'autorisations Propriétaire de base de données sur l'ordinateur SQL Server qui contient la base de données d'application. Ceci permettrait à un membre malveillant du rôle Modeleur de modifier des données n'importe où dans l'application, de supprimer des tables, de modifier la piste d'audit et bien d'autres choses encore.
Pour réduire ce risque, il existe deux options : le système d'approbation et l'exécution de toutes les règles en tant qu'utilisateur à faibles privilèges (décrit dans un autre document).
Exemple
La procédure suivante explique comment créer et exécuter une règle native à l'aide du système d'approbation.
Dans Console Administration de planification, un membre du rôle d'administrateur général doit activer la case à cocher Activer les règles SQL/MDX natives. Cela définit l'indicateur correspondant à « True ». L'indicateur est stocké comme un type Booléen sur l'objet Application. Les utilisateurs disposant d'autorisations EditMetadata (modification des métadonnées) au niveau application peuvent les modifier. Cette étape n'est pas nécessaire pour les règles régulières.
Dans Planning Business Modeler, c'est un membre du rôle Modeleur qui doit écrire puis enregistrer une règle brute en état InActive. Chaque fois que des modifications de règles sont enregistrées, y compris des modifications de règles régulières, Planning Server vérifie le type de l'opération EditRules (modification des règles) dans le contexte du modèle dans lequel les règles sont enregistrées. Dans le cas des règles brutes, le serveur vérifie en outre que l'indicateur Activer les règles SQL/MDX natives est activé (case à cocher activée) et que chaque règle native est en état InActive. Aucune règle définie à InActive ne peut être déployée dans la base de données ou le cube OLAP, ni être exécutée.
Dans la base de données SQL Server, un administrateur de base de données doit approuver la règle en définissant l'indicateur « IsActive » sur True pour cette règle. Cet indicateur est stocké dans la table RuleSetsOrRules, colonne IsActivated. L'accès à cette table est contrôlé en fonction des autorisations SQL standard. Cette étape n'est pas nécessaire pour les règles régulières.
Le modèle qui contient la règle doit être déployé par un membre du rôle Modeleur. Cette étape est requise même pour les règles régulières. Dans le cadre du déploiement du modèle, Planning Server vérifie toujours le type d'opération GenerateApplication (génération d'application) en fonction du modèle déployé. En outre, pour les règles brutes, le serveur vérifie si l'indicateur d'application Activer les règles SQL/MDX natives est activé. Les règles régulières et les règles natives ne sont jamais déployées si cet indicateur est défini à InActive.
Un membre du rôle Modeleur est maintenant à même d'exécuter la règle native en utilisant l'un des chemins d'accès standard de l'exécution. En cas d'exécution directe dans Planning Business Modeler, le type de l'opération ExecuteRule (exécution d'une règle) est vérifié dans le contexte du modèle. Si le membre du rôle Modeleur crée une tâche et la planifie ou l'assigne à un utilisateur, le type de l'opération ManageWorkflow (gestion du workflow) sera vérifié en fonction du site de modèles dans lequel se situe le modèle. Si la règle est définie pour être exécutée par le système (ce qui doit avoir été défini lors de la création de la règle), aucun autre type d'opération n'est vérifié. Outre ces vérifications standard qui sont appliquées à toutes les règles, une vérification supplémentaire est effectuée sur l'indicateur Activer les règles SQL/MDX natives chaque fois qu'une règle native est exécutée à partir d'un chemin d'accès codé. Si l'indicateur est « False », l'exécution échoue.
Si des modifications sont apportées à la règle native, elle doit être enregistrée en état InActive, comme indiqué à l'étape 2. Les étapes 3 et 4 doivent être répétées pour ré-approuver la règle. Cela crée un processus d'approbation pour chaque règle native. Dans certains cas, un des membres du rôle Administrateur général peut décider que les règles natives ne sont pas nécessaires pour leur application Planning Server. Ces membres peuvent choisir de ne jamais activer l'indicateur Activer les règles SQL/MDX natives. Par défaut, cet indicateur est défini sur False. Même si l'indicateur est défini sur True, toute règle doit être créée par un membre du rôle Modeleur et approuvée par un administrateur de base de données. Ceci permet aux administrateurs de créer un système de révision, utilisé avant l'activation de la règle. Enfin, si le membre du rôle Administrateur général décide un jour que les règles brutes ne sont plus souhaitables dans le système, il peut désactiver le bit Activer les règles SQL/MDX natives. Dans ce cas, aucune règle native ne peut plus être créée, mise à jour, déployée ou exécutée ; les règles natives peuvent uniquement être supprimées.