Início / dba / Perguntas / 189676
Accepted
JackLThornton
Asked: 2017-10-31 07:14:38 +0800 CST

Por que o BULK INSERT é considerado perigoso?

  • 772

Gostaria de entender por que as equipes de segurança cibernética em geral (mais de uma organização com quem lidei) são totalmente contra a concessão BULK INSERT(por exemplo, TSQL) de direitos a aplicativos e programadores de banco de dados? Não posso acreditar na desculpa de "preencher o abuso do disco", a menos que esteja faltando alguma coisa, pois o resultado final não é diferente de um aplicativo fazendo algo como:

for (long i = 0; i < LONG_MAX; ++i)
    executeSQL("INSERT INTO table VALUES(...)");

e INSERTé um comando DML comum que qualquer pessoa com permissão de gravação básica pode executar.

Para benefício de um aplicativo, BULK INSERTé muito mais eficiente, rápido e alivia o programador da necessidade de analisar arquivos fora do SQL.

Edit: Eu originalmente fiz essa pergunta no site de segurança da informação por um motivo - não são os DBAs que são contra o uso de BULK INSERT, é a "Garantia de Informações" (IA para abreviar - o pessoal de segurança cibernética) que está forçando o problema. Vou deixar essa questão ficar por mais um ou dois dias, mas se a operação em massa realmente ignorar restrições ou gatilhos, posso ver que isso é um problema.

sql-server permissions

4 respostas

  1. Best Answer

    Dado que provavelmente há tantos medos infundados quanto riscos desconhecidos, eu acho que é difícil realmente dizer por que uma política está em vigor sem perguntar a quem criou a política por que eles estão preocupados.

    No entanto, eu acho que provavelmente tem algo a ver com o que BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)permite que alguém faça, a saber:

    1. desabilitar restrições ( CHECK, DEFAULT, e FOREIGN KEYeu acredito)
    2. desabilitar gatilhos (se houver gatilhos de auditoria, contorná-los provavelmente seria considerado indesejável; para obter mais explicações sobre esse problema específico, consulte @DVKs answer )

    As várias opções são descritas na documentação a seguir:

    Eu não mencionei o problema de bloqueio de tabela observado pelo @RDFozz, pois isso não é específico para BULK INSERT: qualquer um pode tabelar um TABLOCK/XLOCK ou definir TRANSACTION ISOLATION LEVELcomo SERIALIZABLE.

    ATUALIZAR

    Encontrei duas informações adicionais que podem ajudar a diminuir isso:

    1. Os problemas de poder desabilitar gatilhos, desabilitar restrições e definir IDENTITY_INSERT ONpodem não ser uma razão esmagadora para ver ADMINISTER BULK OPERATIONS( ADMINISTER DATABASE BULK OPERATIONScomeçando com o SQL Server 2017) ou a bulkadminfunção de servidor como uma ameaça. A razão é que, para fazer qualquer uma dessas três coisas mencionadas, o usuário precisa ter ALTER TABLEpermissões nessa Tabela ou no Esquema em que a Tabela existe. O encadeamento de propriedade não cobre modificações de DDL. Portanto, se o usuário não tiver ALTER TABLE, a capacidade de fazer essas três coisas não será um problema.

    2. O que não foi discutido até agora e o que pode ser o problema de segurança é que ambos BULK INSERTacessam OPENROWSET(BULK...recursos externos, fora do SQL Server. Ao acessar o SQL Server por meio de um login do Windows, essa conta do Windows será representada (mesmo que você alterne o contexto de segurança usando EXECUTE AS LOGIN='...') para acessar o sistema de arquivos. Isso significa que você só pode ler arquivos para os quais recebeu permissão para ler. Nada de errado com isso.

      MAS, ao acessar o SQL Server por meio de um logon do SQL Server, o acesso externo é feito no contexto da conta de serviço do SQL Server. Isso significa que alguém com essa permissão pode ler arquivos que, de outra forma, não conseguiria ler e em pastas às quais não deveria ter acesso.

      No mínimo, se o SQL Server foi configurado para ser executado como uma conta criada apenas para o SQL Server (o método preferencial), esse usuário poderá ler apenas os arquivos aos quais a conta "SQL Server" tem acesso. Embora este seja um problema limitado, ele ainda permite a leitura de arquivos como arquivos de log do SQL Server (e eu testei o exemplo a seguir e ele funciona):

      SELECT tmp.[Col1]
FROM   OPENROWSET(BULK
   N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
                  SINGLE_NCLOB) tmp([Col1]);

      A maioria das pessoas não terá acesso à pasta MSSQL\Log , portanto, essa seria uma maneira de contornar as restrições de segurança existentes.

      E, se o SQL Server estiver sendo executado como a Local Systemconta, suspeito que o escopo do problema só aumenta e que um usuário com essa permissão seria capaz de ler uma ampla variedade de arquivos relacionados ao sistema.

      E, provavelmente, é por isso que os outros métodos de importação em massa — BCP e SqlBulkCopy— não exigem a bulkadminpermissão/função: eles são iniciados fora do SQL Server e manipularão as permissões do sistema de arquivos por conta própria. Nesses casos, o SQL Server nunca lê o arquivo (ou alcança fora do SQL Server), apenas recebe os dados para importar do arquivo que está sendo lido pelo processo externo.

    Possíveis implicações à parte, foi dito na pergunta:

    Para o benefício de um aplicativo, BULK INSERT é muito mais eficiente, rápido e...

    Tudo bem, continue...

    e alivia o programador da necessidade de analisar arquivos fora do SQL.

    Oi Nelly. Vamos parar aqui. O T-SQL geralmente não é a melhor escolha de linguagens para análise. Muitas vezes, é melhor fazer a análise antes de inserir coisas no banco de dados. Uma maneira de fazer isso é usar parâmetros com valor de tabela (TVPs). Por favor, veja minha resposta para outra pergunta (aqui no DBA.StackExchange) que trata do tópico de pré-análise e validação junto com a importação em massa eficiente dos referidos dados:

    T-SQL: CSV-> pipeline de tabela com dados numéricos analisados ​​personalizados, valores de pesquisa

    • 21

  2. Outra possibilidade é o impacto da execução de uma BULK INSERToperação.

    Normalmente, esse tipo de coisa seria executado fora do expediente quando possível, para não interferir na atividade normal. Uma inserção em massa pode bloquear uma tabela por horas, impedindo que outras inserções aconteçam (assim como selecionar, atualizar ou excluir).

    Ou, do ponto de vista da segurança, pode produzir resultados muito semelhantes a um ataque DoS.

    Reconhecidamente, pode-se fazer isso acidentalmente ou deliberadamente com transações e INSERTinstruções simples. No entanto, usar um processo de inserção em massa conforme pretendido pode causar esse efeito.

    Geralmente, eu esperaria que um DBA estivesse envolvido na organização de atividades fora do expediente, pois eles também precisam garantir que os backups e outros trabalhos agendados sejam concluídos. Se as pessoas agendassem esse tipo de coisa sem consideração suficiente para essas atividades, você poderia ver os backups falharem - o que pode ser um problema por vários motivos.

    • 6

  3. Isso foi meio aludido em uma resposta anterior ("... desabilitar gatilhos "), mas não explica por que a desativação seria indesejável do ponto de vista comercial.

    Em muitas empresas, os gatilhos na tabela principal são usados ​​para:

    1. Validar restrições de integridade (aquelas com lógica de negócios mais complicada do que normalmente é usada em restrições de banco de dados)

    2. Mais importante, para auditar os dados, especificamente para inserir dados na tabela de auditoria correspondente (ou atualizar campos de auditoria na tabela principal).

    É bastante óbvio quais são os problemas com o primeiro (seu aplicativo é suscetível de inserir dados ruins que têm efeitos negativos no processamento downstream). Quanto ao último, se um gatilho estiver desabilitado, você não terá nenhuma informação de auditoria, o que apresenta dois problemas do ponto de vista da auditoria:

    • Em primeiro lugar, a auditoria como um grupo não pode mais auditar as alterações de dados e, portanto, não pode desempenhar sua função principal como Auditoria Interna.

    • Em segundo lugar, a falta de registros de auditoria pode ser uma violação dos requisitos de auditoria pelos quais uma empresa é regida (por exemplo, SAS 70) - o que pode tornar sua empresa responsável por violar os contratos.

    • 6

  4. Uma razão para isso pode ser tornar o registro de ações claro. Se cada ação corresponde a uma entrada em um arquivo de log, é bastante trivial ver algo que causou um problema sem qualquer referência adicional. Se o seu arquivo de log diz "INSERT FROM external.file", sem external.file, você não pode dizer mais nada.

    Claro, você pode modificar como o registro funciona, mas como ponto de partida, impor que cada ação seja atômica mesmo dentro do registro não é uma ideia terrível.

    • 2

relate perguntas