Зважаючи на те, що, мабуть, існує стільки ж необгрунтованих побоювань, скільки є невідомих ризиків, я думаю, що важко реально сказати, чому така політика діє, не запитуючи того, хто створив політику, для чого їх хвилює.
Однак я б припустив, що це, мабуть, має щось спільне з тим, що BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)хтось дозволяє, а саме:
- відключити обмеження (
CHECK, DEFAULTі FOREIGN KEYя вважаю)
- вимкнути тригери (якщо є тригери аудиту, їх проходження, ймовірно, вважатиметься небажаним; для більш детального пояснення з цього питання див. відповідь @DVK )
Різні варіанти описані в наступній документації:
Я не згадав проблему блокування таблиці , зазначену @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 Login, цей обліковий запис 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-> конвеєр таблиці зі спеціальними проаналізованими числовими даними, значеннями пошуку