Início / dba / Perguntas / 283218
Accepted
atevm
Asked: 2021-01-15 02:00:01 +0800 CST

O uso do CLR para expressões regulares é mais seguro do que o uso de scripts externos?

  • 772

Problema

O principal problema que precisamos é usar a expressão regular no MS SQL Server 2019, com capacidade de pelo menos o nível da expressão regular POSIX.

Soluções possíveis

Este Q/A do stackoverflow conclui corretamente que, se a consulta deve depender de expressões regulares, você deve usar o CLR. Este artigo Readgate elabora mais essa abordagem. Então, um de meus colegas e eu propusemos essa solução, mas meu outro colega afirmou categoricamente que usar CLR aqui seria um grande risco para segurança e estabilidade, e usar script externo (Python ou R) é mais seguro.

Esta parece ser uma afirmação duvidosa, uma vez que o código do usuário no CLR pode ser gerenciado , então talvez o contrário seja verdade, mas não consegui convencer meu colega.

Na minha outra pergunta que escrevi em meu desespero porque fui forçado a usar script externo e ainda produzir uma consulta extremamente rápida. O usuário do SQLpro afirma em seu comentário que:

Usar Python ou R pode ser pior em termos de segurança do que usar CLR!

Que eu costumo acreditar.

Perguntas

Então eu tenho duas perguntas:

  1. Qual solução Regexp é script externo mais seguro ou baseado em CLR (conforme descrito aqui )? E porque?

  2. Também propus executar o código python no mesmo Windows Server (deve ser o mesmo servidor, por causa de uma política) mas com o python intrepeter instalado no SO. Porque os resultados são exportados para arquivos CSV de qualquer maneira e armazenados no SQL Server. Então eu poderia usar o módulo de multiprocessamento do Python para obter o desempenho certo. A resposta foi a mesma que executar o Python dentro do SQL Server é mais seguro do que em um aplicativo externo. O que também é uma afirmação questionável.

sql-server python

2 respostas

  1. meu outro colega afirmou categoricamente que usar o CLR aqui seria um grande risco para a segurança e a estabilidade

    Bem, seu colega está categoricamente errado (a menos que eles possam oferecer provas reais de tais alegações).

    Segurança

    Desde que o SQLCLR foi introduzido no SQL Server 2005, as pessoas dizem que ele é "inseguro". No entanto, eu ainda tenho que ver alguém realmente provar que é realmente inseguro. A única suposta "prova" que vi é alguém carregando um assembly que grava um arquivo em disco com a alegação de que, como pode gravar em disco, é uma vulnerabilidade de segurança. Mas, isso é uma afirmação falsa devido a:

    1. a pessoa já tinha permissão para criar a montagem
    2. o assembly já tinha permissão para acessar recursos externos por meio TRUSTWORTHYde ser habilitado ou uma assinatura/certificado sendo usado.

    Isso não é prova de obter permissões elevadas se você já tiver permissões elevadas para a) criar e b) executar o código necessário para fazer parecer que você estava obtendo permissões elevadas.

    SQLCLR não é inerentemente inseguro. Claro, pode ser usado incorretamente para permitir acidentalmente que alguém obtenha permissões elevadas, etc., mas por si só é seguro e protegido. E é bastante fácil introduzir uma vulnerabilidade de segurança simplesmente usando EXECUTE AS 'dbo'um procedimento armazenado ou função, e isso é T-SQL puro.

    Aqui estão vários artigos que escrevi sobre o tópico de segurança SQLCLR:

    Dito isto, dentro do contexto do uso de expressões regulares, SQLCLR e Scripts Externos são "seguros" (assumindo que você não está permitindo acesso ad hoc aos usuários para enviar qualquer código Python aleatório que desejarem).

    Usabilidade

    Aqui está uma grande diferença: Scripts Externos são executados por meio de um procedimento armazenado. Ou seja, você pode executar seu RegEx em um único valor. Se for possível integrar a função RegEx nas cláusulas SELECTe/ou WHERE(eu sei que você pode passar uma consulta e retornar um conjunto de resultados), então é na melhor das hipóteses desajeitado e certamente não é fácil de manter. Considerando que com o SQLCLR, você pode criar funções escalares e funções com valor de tabela que são muito fáceis de integrar em consultas para soluções baseadas em conjuntos adequados (e lembre-se: funções escalares SQLCLR codificadas corretamente que não fazem nenhum acesso a dados podem participar de planos paralelos ).

    Se você deseja funções RegEx sem precisar compilar nada, existem algumas disponíveis na versão gratuita do SQL# (SQLsharp) , uma biblioteca SQLCLR que escrevi.

    Para obter mais informações sobre como trabalhar com SQLCLR em geral, visite meu site: SQLCLR Info

    • 5
  2. Best Answer

    PRIMEIRO : o nível de segurança do SQL CLR é algo como airbag + ABS + Lane Sense para um carro. Ao usar os três dispositivos, você está no nível mais alto em termos de segurança. Esse é o nível SEGURO do SQL CLR. Quando um destes descartes não é utilizado você está em EXTERNAL_ACCESS e sem nenhum destes você está em UNSAFE.

    SEGUNDO : não existe esse nível de segurança em nenhum outro idioma, fazendo acreditar que esses outros idiomas são seguros, o que não é verdade.... Se você quiser dirigir um carro e todos os dispositivos anteriores estiverem faltando, então não há indicação de qualquer nível de segurança neste carro... este carro é seguro?

    Por exemplo , os processos SQL CLR podem ser descartados em uma sandbox em caso de mau comportamento. Isso não é verdade para outros idiomas! Eu sempre faço o mesmo truque para provar: usando SQL CLR com uma recursão infinita. O processo será disparado e o serviço SQL Server sobreviverá. Usar uma máquina Java externa para fazer o mesmo, fará com que seu SQL Server fique inativo porque o Java adquirirá toda a memória em detrimento do SQL Server ...

    Agora você tem a escolha!

    • 2

relate perguntas