Sicheres Verwenden von systemeigenem SQL und MDX
Aktualisiert: 2009-04-30
Planning Server unterstützt eine Sprache, mit der Sie unkompliziert Berechnungsregeln angeben können. Diese Regeln können unter anderem verwendet werden, um Daten in ein Modell einzugeben, Daten innerhalb von oder zwischen Modellen zu verschieben und neue Werte aus vorhandenen Daten zu berechnen. Diese Regeln können von einem Mitglied der Modelliererrolle mithilfe von Planning Business Modeler auf zwei Arten ausgeführt werden. Die erste Möglichkeit, eine Regel auszuführen, ist als Teil eines Auftrags, der dann geplant oder einem Geschäftsbenutzer zugewiesen wird. Die zweite Methode ist, die Regel bei jeder Datenänderung automatisch vom System ausführen zu lassen. Mitglieder der Modelliererrolle können auch festlegen, dass die Ausführung in Microsoft SQL Server 2005 oder MDX erfolgt. Jede dieser Möglichkeiten hat bezüglich Funktionalität und Leistung ihre Vor- und Nachteile.
Unter bestimmten Bedingungen ist die PerformancePoint Expression Language (PEL) für fortgeschrittene Benutzer möglicherweise zu eingeschränkt. Dies gilt insbesondere für SQL Server- oder MDX-Experten, die die Leistung ihrer gespeicherten Prozeduren verbessern möchten, integrierte SQL Server-Funktionen verwenden möchten, die hier nicht offen gelegt werden, oder Aktionen durchführen möchten, die nicht durch die PEL-Funktionen abgedeckt sind. PEL bietet die Leistungsfähigkeit von unformatiertem SQL oder MDX, zusammen mit unserer vertrauten Regelinfrastruktur, die unterschiedliche Ausführungsstile ermöglicht.
Hierfür wird in PEL eine neue Implementierung der NativeSql-Regel und der NativeMdxScript-Regel zur Verfügung gestellt. Diese neuen Implementierungen können jedoch ein Sicherheitsrisiko darstellen. Ein Benutzer, der nur Zugriff auf eine Modellsite hat, könnte möglicherweise umfassende Änderungen in mehreren Modellsites in der gesamten Anwendung vornehmen. Insbesondere können diese Regeln in Planning Server nicht analysiert werden, da sie in SQL oder MDX geschrieben sind, was Planning Server nicht problemlos analysieren kann. Dies erfordert eine neue Implementierung von Regeln, die als Dienstidentität ausgeführt wird, die auf dem SQL Server-Computer mit der Anwendungsdatenbank über Berechtigungen als Datenbankbesitzer verfügt. Dadurch könnte ein böswilliges Mitglied der Modelliererrolle Daten überall in der Anwendung ändern, Tabellen ablegen, den Audit-Trail ändern und Vieles mehr.
Es gibt zwei Optionen, mit denen sich dieses Risiko eindämmen lässt: das Genehmigungssystem und die Ausführung aller Regeln als gering privilegierter Benutzer (in einem anderen Dokument beschrieben).
Beispiel
In den folgenden Schritten wird beschrieben, wie eine systemeigene Regel mithilfe des Genehmigungssystems erstellt und ausgeführt werden kann.
In der Planning-Verwaltungskonsole muss ein Mitglied der globalen Administratorrolle das Kontrollkästchen Systemeigene SQL/MDX-Regeln aktivieren aktivieren. Dadurch wird das entsprechende Kennzeichen auf True gesetzt. Das Kennzeichen wird als boolescher Wert im Anwendungsobjekt gespeichert. Benutzer mit EditMetadata-Berechtigungen auf Anwendungsebene können Änderungen vornehmen. Dieser Schritt ist für reguläre Regeln nicht erforderlich.
In Planning Business Modeler muss ein Mitglied der Modelliererrolle eine interne Regel in inaktivem Zustand schreiben und anschließend speichern. Bei jedem Speichern von Regeländerungen, einschließlich Bearbeitungen von regulären Regeln, überprüft Planning Server den EditRules-Vorgangstyp im Kontext des Modells, in dem die Regeln gespeichert werden. Bei internen Regeln überprüft der Server außerdem, ob das Kennzeichen Systemeigene SQL/MDX-Regeln aktivieren aktiviert ist (das Kontrollkästchen ist markiert) und ob alle systemeigenen Regeln inaktiv sind. Alle Regeln, die inaktiv sind, können weder in der Datenbank noch im OLAP-Cube bereitgestellt werden und auch nicht ausgeführt werden.
In der SQL Server-Datenbank muss ein Datenbankadministrator die Regel genehmigen, indem er das IsActive-Kennzeichen für die Regel auf True setzt. Dieses Kennzeichen wird in der RuleSetsOrRules-Tabelle in der IsActivated-Spalte gespeichert. Der Zugriff auf diese Tabelle wird entsprechend den SQL-Standardberechtigungen gesteuert. Dieser Schritt ist für reguläre Regeln nicht erforderlich.
Das Modell, das die Regel enthält, muss durch ein Mitglied der Modelliererrolle bereitgestellt werden. Dieser Schritt ist auch für reguläre Regeln erforderlich. Als Teil der Bereitstellung des Modells überprüft Planning Server immer den GenerateApplication-Vorgangstyp im Bereich des bereitgestellten Modells. Außerdem überprüft der Server bei internen Regeln, ob das Anwendungskennzeichen Systemeigene SQL/MDX-Regeln aktivieren aktiviert ist. Reguläre und systemeigene Regeln werden niemals bereitgestellt, wenn dieses Kennzeichen auf InActive festgelegt ist.
Ein Mitglied der Modelliererrolle kann die systemeigene Regel nun mithilfe eines der standardmäßigen Ausführungspfade ausführen. Bei der Ausführung direkt in Planning Business Modeler wird der ExecuteRule-Vorgangstyp im Kontext des Modells überprüft. Wenn das Mitglied der Modelliererrolle einen Auftrag erstellt und plant oder einem Benutzer zuweist, wird der ManageWorkflow-Vorgangstyp mit dem Bereich der Modellsite, in dem sich das Modell befindet, überprüft. Wenn festgelegt ist, dass die Regel vom System ausgeführt werden soll (diese Festlegung muss bei der Erstellung der Regel erfolgen), werden keine weiteren Vorgangstypen überprüft. Zusätzlich zu den Standardüberprüfungen, die auf alle Regeln angewendet werden, gibt es für das Kennzeichen Systemeigene SQL/MDX-Regeln aktivieren immer eine zusätzliche Prüfung, wenn eine systemeigene Regel aus einem Codepfad ausgeführt wird. Wenn das Kennzeichen False lautet, schlägt die Ausführung fehl.
Wenn an der systemeigenen Regel Änderungen vorgenommen werden, muss sie im inaktiven Zustand gespeichert werden, wie in Schritt 2 beschrieben. Die Schritte 3 und 4 müssen zur erneuten Genehmigung der Regel wiederholt werden. Somit gibt es bei jeder systemeigenen Regel einen Genehmigungsprozess. In einigen Fällen entscheiden globale Administratormitglieder, dass systemeigene Regeln für ihre Planning-Anwendung nicht erforderlich sind. Sie können bestimmen, dass das Kennzeichen Systemeigene SQL/MDX-Regeln aktivieren niemals aktiviert wird. Standardmäßig ist dieses Kennzeichen auf False festgelegt. Selbst wenn das Kennzeichen auf True festgelegt ist, muss jede Regel von einem Mitglied der Modelliererrolle erstellt und von einem Datenbankadministrator genehmigt werden. So können Administratoren ein Überprüfungssystem erstellen, das vor der Regelaktivierung verwendet wird. Wenn das globale Administratormitglied entscheidet, dass interne Regeln im System nicht mehr benötigt werden, kann das Kennzeichen Systemeigene SQL/MDX-Regeln aktivieren jederzeit deaktiviert werden. Wenn dies geschieht, können systemeigene Regeln nicht mehr erstellt, aktualisiert, bereitgestellt oder ausgeführt werden; sie können nur gelöscht werden.