Using Native SQL and MDX securely
Atualizado em: 2009-04-30
O Planning Server inclui uma linguagem que permite especificar facilmente as regras de cálculo. Essas regras podem ser usadas para inserir dados em um modelo, mover dados em ou entre modelos e calcular novos valores com base em dados existentes, entre outros recursos. Essas regras podem ser executadas por um membro da função de modelador usando o Planning Business Modeler de duas maneiras. A primeira maneira de executar uma regra é como parte de um trabalho, o qual, por sua vez, é agendado ou atribuído a um usuário empresarial. O segundo método é a execução automática da regra pelo sistema sempre que houver alteração de dados. Os membros da função de modelador também podem especificar a execução no Microsoft SQL Server ou no MDX, sendo que cada um deles tem vantagens e desvantagens em funcionalidade e desempenho.
Sob algumas condições, a PEL (PerformancePoint Expression Language) pode ser restritiva demais para usuários avançados. Isso acontece especialmente com clientes especialistas no SQL Server ou no MDX que queiram aprimorar o desempenho de seus procedimentos armazenados, utilizar funções internas do SQL Server que não expomos ou fazer algo fora dos recursos da PEL. A PEL oferece a capacidade do SQL Server ou do MDX bruto, juntamente com a conveniência de nossa infra-estrutura de regras, as quais permitem estilos diferentes de execução.
Para isso, a PEL expõe a nova implementação das regras chamadas NativeSql e NativeMdxScript. No entanto, essas novas implementações podem representar um risco à segurança. Elas podem permitir que um usuário que tenha acesso apenas a um site modelo faça alterações drásticas em vários sites modelo em todo o aplicativo. Especificamente, o Planning Server não pode fazer qualquer análise nessas regras porque elas são criadas em SQL ou MDX, o que dificulta a análise pelo Planning Server. Isso requer uma nova implementação das regras para executar como identidade do serviço, que tem permissões de proprietário de banco de dados no computador SQL Server que contém o banco de dados de aplicativo. Isso permitiria a um membro mal-intencionado da função de modelador alterar dados em qualquer lugar no aplicativo, descartar tabelas, modificar a trilha de auditoria e muitas outras coisas.
Para reduzir esse risco, há duas opções: o sistema de aprovação e a execução de todas as regras como um usuário com poucos privilégios (descrito em outro documento).
Exemplo
As etapas a seguir descrevem como criar e executar uma regra nativa usando o sistema de aprovação.
No Console de Administração do Planning, um membro da função de administrador global deve selecionar a caixa de seleção Allow Native SQL\MDX Rules (Permitir Regras Nativas do SQL\MDX). Isso define o sinalizador correspondente como "True". O sinalizador é armazenado como um valor booleano no objeto de aplicativo. Os usuários que têm permissões EditMetadata no nível do aplicativo têm acesso para modificá-lo. Essa etapa não será necessária para regras regulares.
No Planning Business Modeler, um membro da função de modelador deve gravar e salvar uma regra bruta em um estado InActive. Sempre que qualquer edição de regra for salva, incluindo edições de regras regulares, o Planning Server verificará o tipo de operação EditRules no contexto do modelo no qual as regras estão sendo salvas. No caso de regras brutas, o servidor também verificará se o sinalizador Allow Native SQL\MDX Rules do aplicativo está habilitado (caixa de seleção marcada) e se cada regra nativa está no estado InActive. Qualquer regra definida como InActive não poderá ser implantada no banco de dados nem no cubo OLAP e não poderá ser executada.
No banco de dados do SQL Server, um administrador de banco de dados deve aprovar a regra definindo a configuração do sinalizador “IsActive” como true para a regra. Esse sinalizador é armazenado na coluna IsActivated da tabela RuleSetsOrRules. O acesso a essa tabela é controlado de acordo com as permissões padrão do SQL. Essa etapa não será necessária para regras regulares.
O modelo que contém a regra deve ser implantado por um membro da função de modelador. Essa etapa é necessária mesmo para regras regulares. Como parte da implantação do modelo, o Planning Server sempre verificará o tipo operação GenerateApplication no escopo do modelo que está sendo implantado. Além disso, para regras brutas, o servidor verificará se o sinalizador Allow Native SQL\MDX Rules do aplicativo está habilitado. Tanto as regras regulares quanto as nativas nunca serão implantadas se esse sinalizador estiver definido como InActive.
Um membro da função de modelador agora pode executar a regra nativa usando qualquer um dos caminhos de execução padrão. Se executado diretamente no Planning Business Modeler, o tipo de operação ExecuteRule será verificado no contexto do modelo. Se o membro da função de modelador criar um trabalho e agendá-lo ou atribuí-lo a um usuário, o tipo de operação ManageWorkflow será verificado com o escopo do site modelo no qual o modelo está. Se a regra estiver definida para ser executada pelo sistema (isso tem que ser feito quando a regra é criada), nenhum outro tipo de operação será verificado. Além das verificações padrão aqui incluídas, que são aplicadas a todas as regras, há uma verificação adicional do sinalizador Allow Native SQL\MDX Rules sempre que uma regra nativa é executada em qualquer caminho de código. Se o sinalizador for "false", a execução irá falhará.
Se alguma alteração for feita na regra nativa, ela deverá ser salva em um estado InActive, conforme descrito na etapa 2. As etapas 3 e 4 devem ser repetidas para reaprovar a regra. Isso cria uma processo de aprovação para cada regra nativa. Em alguns casos, um membro da função de administrador global pode decidir se as regras nativas não são necessárias para seus aplicativos do Planning. Eles podem selecionar a opção que não habilita o sinalizador Allow Native SQL\MDX Rules. Por padrão, esse sinalizador está definido como False. Mesmo que o sinalizador esteja definido como True, cada regra deve ser criada por um membro da função de modelador e aprovada por um administrador de banco de dados. Isso dá aos administradores a oportunidade de criar um sistema de revisão, para uso antes de a regra ser habilitada. Finalmente, se o membro da função de administrador global decidir que não deseja mais regras brutas no sistema, ele poderá desabilitar o bit de Allow Native SQL\MDX Rules. Se fizer isso, não será possível criar, atualizar, implantar ou executar regras nativas; elas só poderão ser excluídas.