Por que o BULK INSERT é considerado perigoso?

Eu gostaria de entender por que as equipes de cibersegurança em geral (mais de uma organização com a qual lidei) estão prontas para conceder BULK INSERT(por exemplo, TSQL) direitos a aplicativos e programadores de banco de dados? Não acredito na desculpa "preenchendo o abuso de disco", a menos que esteja faltando alguma coisa, pois o resultado final não é diferente de um aplicativo que faz 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 básica de gravação pode executar.

Para o 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 DBA que são contra o uso do BULK INSERT, é a "Information Assurance" (IA, abreviação - o pessoal da cibersegurança) que está forçando o problema. Deixarei essa pergunta continuar por mais um ou dois dias, mas se a operação em massa de fato ignorar restrições ou gatilhos, posso ver que isso é um problema.

Dado que provavelmente existem tantos medos infundados quanto riscos desconhecidos, eu acho que é realmente difícil 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. desativar restrições ( CHECK, DEFAULTe FOREIGN KEYeu acredito)
2. desativar gatilhos (se houver gatilhos de auditoria, ignorá -los provavelmente seria considerado indesejável; para obter mais explicações sobre esse problema específico, consulte a resposta do @DVKs )

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

• SqlBulkCopyOptions Enum
• INSERÇÃO A GRANEL

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

ATUALIZAR

Me deparei com duas informações adicionais que podem ajudar a restringir isso:

1. As questões de ser capaz de desativar os gatilhos, desative restrições e conjunto IDENTITY_INSERT ONpode não ser uma razão esmagadora para ver ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONS(começando com o SQL Server 2017) o ou bulkadminfunção de servidor como uma ameaça. O motivo é que, para executar 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 é um problema.

2. O que não foi discutido até agora, e que pode vir a ser o problema de segurança é que ambos BULK INSERTe OPENROWSET(BULK...de acesso aos recursos externos, fora do SQL Server. Ao acessar o SQL Server por meio de um logon do Windows, essa conta do Windows será representada (mesmo que você alterne o contexto de segurança EXECUTE AS LOGIN='...') para fazer o acesso ao sistema de arquivos. Isso significa que você só pode ler arquivos aos quais você 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 conseguiriam 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 preferido), esse Usuário poderá ler apenas os arquivos aos quais a conta "SQL Server" tem acesso. Embora esse seja um problema limitado, ele ainda permite a leitura de arquivos como os arquivos de log do SQL Server (e eu testei o exemplo a seguir e 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ó aumente e que um Usuário com essa permissão possa 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: 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 a serem importados 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, o BULK INSERT é muito mais eficiente, mais rápido, ..

Ok, continue ...

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

Whoa Nelly. Vamos parar por aqui. O T-SQL geralmente não é a melhor escolha de idiomas para análise. Geralmente, é melhor fazer a análise antes de inserir itens 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, juntamente com a importação em massa eficiente desses dados:

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

Isso foi mencionado em uma resposta anterior ("... desativar 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 complicadas do que geralmente são usadas nas restrições de banco de dados)

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

É bastante óbvio quais são os problemas com o primeiro (seu aplicativo pode inserir dados incorretos que têm efeitos negativos no processamento a jusante). Quanto ao último, se um gatilho estiver desativado, você não terá nenhuma informação de auditoria, o que coloca dois problemas da perspectiva da auditoria:

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

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

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

Normalmente, esse tipo de coisa fica fora do horário de 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 ocorram (além de selecionar, atualizar ou excluir).

Ou, de uma perspectiva de segurança, pode produzir resultados muito semelhantes a um ataque de negação de serviço.

É certo que se pode fazer isso acidental ou deliberadamente com transações e INSERTinstruções simples . No entanto, o uso de um processo de inserção em massa como pretendido pode causar esse efeito.

Geralmente, eu esperaria que um DBA estivesse envolvido na organização de atividades fora do horário comercial, 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.

Uma razão para isso pode ser a clarificação do registro de ações. Se toda ação corresponde a uma entrada em um arquivo de log, é bastante trivial ver algo que causou um problema sem nenhuma referência adicional. Se o seu arquivo de log disser "INSERT FROM external.file", sem external.file, você não poderá contar mais nada.

Obviamente, você pode modificar o funcionamento do log, mas como ponto de partida, impor toda ação a ser atômica, mesmo dentro do log, não é uma péssima idéia.