Почему BULK INSERT считается опасным?

21

Я хотел бы понять, почему группы по кибербезопасности в целом (более чем с одной организацией, с которой я имел дело) не могут предоставить BULK INSERT(например, TSQL) права приложениям и программистам баз данных? Я не могу поверить в оправдание «заправки диска», если я что-то упустил, так как конечный результат ничем не отличается от приложения, выполняющего что-то вроде:

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

и INSERTэто обычная команда DML, которую может выполнить любой пользователь с базовыми правами на запись.

В интересах приложения, BULK INSERTон гораздо эффективнее, быстрее и избавляет программиста от необходимости разбирать файлы вне SQL.

Редактировать: Первоначально я задал этот вопрос на сайте информационной безопасности по причине - не администраторы баз данных против использования BULK INSERT, а «Информационная гарантия» (IA для краткости - ребята из Cybersecurity), которые форсируют проблему. Я оставлю этот вопрос на пару дней, но если массовая операция действительно обходит ограничения или триггеры, я вижу, что это проблема.

— JackLThornton
источник

19

Учитывая, что, вероятно, столько же необоснованных страхов, сколько и неизвестных рисков, я думаю, что трудно действительно сказать, почему существует политика, не спрашивая, кто ее создал, почему они обеспокоены.

Тем не менее, я предполагаю, что это, вероятно, связано с тем, что 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-> конвейер таблицы с настраиваемыми проанализированными числовыми данными, значениями поиска

— Соломон Руцкий
источник

С репликацией на месте есть дополнительные соображения, которые нужно сделать для массовой вставки.

— mustaccio

6

Это как бы упоминалось в более раннем ответе («... отключить триггеры »), но не объясняет, почему отключение было бы нежелательным с точки зрения бизнеса.

Во многих компаниях триггеры на главном столе используются для:

Проверка ограничений целостности (те, у которых бизнес-логика более сложная, чем обычно используется в ограничениях БД)
Что еще более важно, провести аудит данных, в частности, вставить данные в соответствующую таблицу аудита (или обновить поля аудита в основной таблице).

Совершенно очевидно, в чем проблема с первым (ваше приложение может вставлять неверные данные, что отрицательно влияет на последующую обработку). Что касается последнего, если триггер отключен, у вас нет никакой информации об аудите, что создает две проблемы с точки зрения аудита:

Прежде всего, аудит как группа больше не может проверять изменения данных и, следовательно, не может выполнять свою основную функцию внутреннего аудита.
Во-вторых, отсутствие записей аудита может быть нарушением требований аудита, которыми руководствуется компания (например, SAS 70), что может сделать вашу компанию ответственной за нарушение контрактов.

— DVK
источник

Всем привет. Я не согласен с вашим описанием того, что здесь нежелательно, и я очень благодарен за детали, но для справки я в своем ответе заявил, что отключение триггеров было бы нежелательно, если бы были триггеры аудита. Правда, это не подробное объяснение, но не совсем точное, чтобы сказать, что оно «не объяснено». Может быть, лучше сказать, что это было слишком упрощенно или не дало достаточного объяснения относительно триггеров аудита, и не упомянул валидацию (и +1 за упоминание этого, а также за дополнительную информацию в целом). Просто мысль.

— Соломон Руцкий,

@SolomonRutzky - я специально указал, что ответ «не объясняет почему », это проблема :) Если вы не можете определить бизнес-проблему; технические детали часто не имеют значения, особенно для ОП, который ведет деловую дискуссию с ВА. Другими словами, если они скажут: «О, триггеры аудита могут быть отключены», ИА спросит: « Что для нас значит Тат ?» - обычно они не администраторы или разработчики.

— ДВК

хорошо. Наверное, я только что прочитал в первом предложении, что «в другом ответе упоминается отключение триггеров, это нежелательно, но не объясняет почему». и да, я в целом согласен с вами в отношении необходимости правильно определить проблему, я предполагал (возможно, не всегда лучшую политику ;-), что ФП понимал последствия отключения механизма аудита. Если я не прав, то, к счастью, вы предоставили эту информацию здесь. И поэтому я просто обновил свой ответ, чтобы дать ссылку на это для этой цели :)

— Соломон Руцки

6

Другая возможность - это влияние бега BULK INSERT операции.

Обычно такие вещи запускаются в нерабочее время, когда это возможно, чтобы не мешать нормальной деятельности. Массовая вставка может заблокировать таблицу на несколько часов, не допуская других вставок (а также выбора, обновления или удаления).

Или, с точки зрения безопасности, он может привести к результатам, очень похожим на DoS-атаку.

По общему признанию, это можно сделать случайно или намеренно с помощью транзакций и простых INSERTзаявлений. Однако использование процесса массовой вставки по назначению может вызвать этот эффект.

Как правило, я ожидаю, что администратор базы данных будет вовлечен в организацию внеурочной деятельности, поскольку им также необходимо убедиться, что резервные копии и другие запланированные задания выполнены полностью. Если бы люди планировали подобные вещи без достаточного внимания к таким действиям, вы могли бы увидеть сбой резервного копирования - что может быть проблемой по ряду причин.

— RDFozz
источник

2

Одной из причин этого может быть упрощение регистрации действий. Если каждое действие соответствует одной записи в файле журнала, довольно просто увидеть что-то, что вызвало проблему, без каких-либо дополнительных ссылок. Если в вашем файле журнала написано «INSERT FROM external.file», без external.file, вы не можете больше ничего сказать.

Конечно, вы можете изменить работу журналирования, но в качестве отправной точки принудительное выполнение каждого действия, чтобы оно было атомарным даже внутри журналирования, не является ужасной идеей.