Безопасное использование собственного кода SQL и многомерных выражений
Обновлено: 2009-04-30
В Сервер планирования предусмотрен язык, позволяющий просто создавать правила вычислений. Эти правила можно использовать для ввода данных в модель, для перемещения данных внутри модели или между моделями, для вычисления новых значений по существующим данным и т.д. Эти правила могут быть запущены администратором моделей с помощью Бизнес-моделирование двумя способами. Первый способ – запустить правило в составе задания, которое планируется ищи назначается бизнес-пользователю. Второй способ – включить автоматический запуск правила системой при каждом изменении данных. Администраторы моделей также могут указать выполнение инструкций Microsoft SQL Server 2005 или MDX: оба способа имеют свои достоинства и недостатки как в производительности, так и в функциональности.
В некоторых условиях язык выражений PerformancePoint (PEL) может быть слишком ограниченным для опытных пользователей. Это наиболее вероятно для пользователей с отличным знанием SQL Server или MDX, которые хотят изменить хранимые процедуры для повышения их производительности, использовать встроенные функции SQL Server, которые мы не показываем, или сделать что-то, для чего возможностей PEL недостаточно. Язык PEL предоставляет все возможности необработанных операций SQL Server и MDX вместе с удобной инфраструктурой правил, допускающей различные стили выполнения.
Для этого PEL использует новые реализации правил, называемые NativeSql и NativeMdxScript. Однако эти новые реализации могут создавать риск для безопасности. Они могут позволить пользователю, имеющему доступ только к одному узлу моделей, внести значительные изменения во множество узлов моделей во всем приложении. Сервер планирования не может анализировать эти правила, поскольку они написаны на языках SQL или MDX, которые Сервер планирования не может разобрать. Для этого требуется, чтобы новая реализация правил запускалась с учетной записью удостоверения служб, обладающей разрешениями владельца базы данных на компьютере с SQL, где содержится база данных приложения. Это позволит злоумышленнику с ролью администратора моделей изменять данные везде в приложении, удалять таблицы, изменять журнал аудита и многое другое.
Чтобы снизить риск можно использовать два пути: применять систему утверждения или запускать все правила от имени пользователя с ограниченными правами (описывается в другом документе).
Пример
Ниже описано создание и запуск встроенного правила с помощью системы утверждения.
В Консоль администрирования глобальный администратор должен установить флажок Allow Native SQL\MDX Rules. При этом соответствующему флагу устанавливается значение «True». Флаг хранится как логическое значение в объекте приложения. Пользователи, имеющие разрешения EditMetadata на уровне приложений, могут изменять его. Этот шаг не требуется для обычных правил.
В Бизнес-моделирование администратор моделей должен написать и сохранить правило в неактивном состоянии. При каждом сохранении правил после изменения, включая изменение обычных правил, Сервер планирования проверяет тип операции EditRules в контексте модели, в которой правила были сохранены. В случае новых правил сервер дополнительно проверяет состояние флага «Allow Native SQL\MDX Rules» (флажок установлен) и неактивное состояние каждого встроенного правила. Любое правило, находящееся в неактивном состоянии, не может быть развернуто в базе данных или кубе OLAP и не может быть выполнено.
В базе данных SQL Server администратор базы данных должен утвердить правило, установив для него флаг «IsActive» в состояние «True». Этот флаг хранится в таблице RuleSetsOrRules в столбце IsActivated. Доступ к этой таблице определяется стандартными разрешениями SQL. Этот шаг не требуется для обычных правил.
Модель, содержащая правила, должна быть развернута администратором моделей. Этот шаг требуется даже для обычных правил. При развертывании модели Сервер планирования проверит тип операции GenerateApplication в области развертываемой модели. Кроме того, для новых правил сервер проверит, включен ли флаг «Allow Native SQL\MDX Rules». И обычные, и встроенные правила не развертываются, если этот флаг имеет значение «InActive».
Теперь администратор моделей может выполнять встроенное правило с помощью любого из стандартных путей выполнения. При выполнении непосредственно в Бизнес-моделирование тип операции ExecuteRule будет проверен в контексте модели. Если администратор моделей создает задание и планирует его или назначает его пользователю, тип операции ManageWorkflow будет проверен с областью узла моделей, в котором находится модель. Если правило будет выполняться системой (это должно быть задано при создании правила), дополнительные типы операций не будут проверены. Помимо стандартных проверок, применяемых ко всем правил, есть дополнительная проверка для флага «Allow Native SQL\MDX Rules», которая выполняется всегда, когда встроенное правило выполняется по любому пути. Если флаг имеет значение «False», выполнение будет невозможно.
Если встроенное правило изменено, его следует сохранить в неактивном состоянии, как описано на шаге 2. Для повторного утверждения правила следует повторить шаги 3 и 4. При этом для каждого встроенного правила создается процесс утверждения. В некоторых случаях глобальный администратор может решить, что встроенные правила не требуются для приложения планирования. В этом случае они могут не включать флаг «Allow Native SQL\MDX Rules». По умолчанию этот флаг имеет значение «False». Даже если этот флаг имеет значение «True», каждое правило должно быть создано участником роли администратора моделей и утверждено администратором баз данных. Это дает возможность администраторам создать систему проверки до включения правила. И наконец, если глобальный администратор решит, что встроенные правила в системе больше не нужны, можно выключить бит «Allow Native SQL\MDX Rules». При этом встроенные правила нельзя будет создавать, обновлять, развертывать или выполнять: их можно будет только удалить.