Учитывая, что, вероятно, столько же необоснованных страхов, сколько и неизвестных рисков, я думаю, что трудно действительно сказать, почему существует политика, не спрашивая, кто ее создал, почему они обеспокоены.
Тем не менее, я предполагаю, что это, вероятно, связано с тем, что BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)позволяет кому-либо делать, а именно:
- отключить ограничения (
CHECK, DEFAULTиFOREIGN KEY я считаю)
- отключить триггеры (если есть триггеры аудита, обход их, вероятно, будет сочтен нежелательным; более подробное описание этой конкретной проблемы см. в ответе @DVKs ).
Различные варианты описаны в следующей документации:
Я не упомянул проблему блокировки таблиц, отмеченную @RDFozz, поскольку она не является специфической для BULK INSERT: любой может поставить таблицу TABLOCK / XLOCK или установить TRANSACTION ISOLATION LEVELв SERIALIZABLE.
ОБНОВИТЬ
Я наткнулся на две дополнительные части информации, которые могут помочь сузить это:
Вопросы возможности для отключения триггеров, отключают ограничений и набора IDENTITY_INSERT ONмогут не быть подавляющей причиной , чтобы увидеть ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONS(начиная с SQL Server 2017), или bulkadminроли сервера в качестве угрозы. Причина в том, что для выполнения любой из этих трех только что упомянутых задач пользователю необходимо иметь ALTER TABLEразрешения для этой таблицы или схемы, в которой эта таблица существует. Цепочка владения не распространяется на модификации DDL. Так что, если у пользователя нет ALTER TABLE, то способность выполнять эти три вещи не является проблемой.
Что не обсуждается до сих пор, и что в конечном итоге может быть проблема безопасности является то , что оба и доступа к внешним ресурсам, вне SQL Server. При доступе к SQL Server через учетную запись Windows эта учетная запись Windows будет олицетворена (даже если вы переключите контекст безопасности с помощью ) для доступа к файловой системе. Это означает, что вы можете читать только те файлы, на которые у вас есть разрешение на чтение. В этом нет ничего плохого.BULK INSERTOPENROWSET(BULK...EXECUTE AS LOGIN='...'
НО, при доступе к SQL Server через имя входа SQL Server, внешний доступ осуществляется в контексте учетной записи службы SQL Server. Это означает, что кто-то с таким разрешением может читать файлы, которые в противном случае он не мог бы читать, и в папках, к которым у него не должно быть доступа.
Как минимум, если SQL Server был настроен для работы в качестве учетной записи, созданной только для SQL Server (предпочтительный метод), то такой пользователь мог читать только те файлы, к которым имеет доступ учетная запись «SQL Server». Хотя это ограниченная проблема, она по-прежнему позволяет читать файлы, такие как файлы журнала SQL Server (и я протестировал следующий пример, и он работает):
SELECT tmp.[Col1]
FROM OPENROWSET(BULK
N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
SINGLE_NCLOB) tmp([Col1]);
У большинства людей нет доступа к MSSQL \ Log папке , так что это способ обойти существующие ограничения безопасности.
И, если SQL Server работает как Local System учетная запись, то я подозреваю, что масштаб проблемы только увеличивается, и что пользователь с таким разрешением сможет читать широкий спектр системных файлов.
И, вероятно, поэтому другие методы массового импорта - BCP и SqlBulkCopy- не требуют bulkadminразрешения / роли: они инициируются вне SQL Server и будут обрабатывать разрешения файловой системы самостоятельно. В этих случаях SQL Server никогда не читает файл (или выходит за пределы SQL Server), он просто получает данные для импорта из файла, который читается внешним процессом.
Помимо возможных последствий, было сказано в вопросе:
В интересах приложения BULK INSERT намного эффективнее, быстрее, ..
Хорошо, продолжай ...
и избавляет программиста от необходимости разбирать файлы вне SQL.
Вау, Нелли. Давайте остановимся прямо здесь. T-SQL обычно не лучший выбор языков для разбора. Часто лучше выполнить синтаксический анализ, прежде чем вставлять данные в БД. Один из способов сделать это - использовать табличные параметры (TVP). Пожалуйста, смотрите мой ответ на другой вопрос (здесь, на DBA.StackExchange), который касается темы предварительного анализа и проверки наряду с эффективным массовым импортом указанных данных:
T-SQL: CSV-> конвейер таблицы с настраиваемыми проанализированными числовыми данными, значениями поиска
Это как бы упоминалось в более раннем ответе («... отключить триггеры »), но не объясняет, почему отключение было бы нежелательным с точки зрения бизнеса.
Во многих компаниях триггеры на главном столе используются для:
Проверка ограничений целостности (те, у которых бизнес-логика более сложная, чем обычно используется в ограничениях БД)
Что еще более важно, провести аудит данных, в частности, вставить данные в соответствующую таблицу аудита (или обновить поля аудита в основной таблице).
Совершенно очевидно, в чем проблема с первым (ваше приложение может вставлять неверные данные, что отрицательно влияет на последующую обработку). Что касается последнего, если триггер отключен, у вас нет никакой информации об аудите, что создает две проблемы с точки зрения аудита:
Прежде всего, аудит как группа больше не может проверять изменения данных и, следовательно, не может выполнять свою основную функцию внутреннего аудита.
Во-вторых, отсутствие записей аудита может быть нарушением требований аудита, которыми руководствуется компания (например, SAS 70), что может сделать вашу компанию ответственной за нарушение контрактов.
источник
Другая возможность - это влияние бега
BULK INSERTоперации.Обычно такие вещи запускаются в нерабочее время, когда это возможно, чтобы не мешать нормальной деятельности. Массовая вставка может заблокировать таблицу на несколько часов, не допуская других вставок (а также выбора, обновления или удаления).
Или, с точки зрения безопасности, он может привести к результатам, очень похожим на DoS-атаку.
По общему признанию, это можно сделать случайно или намеренно с помощью транзакций и простых
INSERTзаявлений. Однако использование процесса массовой вставки по назначению может вызвать этот эффект.Как правило, я ожидаю, что администратор базы данных будет вовлечен в организацию внеурочной деятельности, поскольку им также необходимо убедиться, что резервные копии и другие запланированные задания выполнены полностью. Если бы люди планировали подобные вещи без достаточного внимания к таким действиям, вы могли бы увидеть сбой резервного копирования - что может быть проблемой по ряду причин.
источник
Одной из причин этого может быть упрощение регистрации действий. Если каждое действие соответствует одной записи в файле журнала, довольно просто увидеть что-то, что вызвало проблему, без каких-либо дополнительных ссылок. Если в вашем файле журнала написано «INSERT FROM external.file», без external.file, вы не можете больше ничего сказать.
Конечно, вы можете изменить работу журналирования, но в качестве отправной точки принудительное выполнение каждого действия, чтобы оно было атомарным даже внутри журналирования, не является ужасной идеей.
источник