У мене виникають проблеми з дозволом моїм користувачам виконувати пакети SSIS розумним чином через різний рівень необхідних привілеїв.
Сценарій : ми створили сховище даних з двома різними пакетами SSIS, відповідальними за завантаження його даними, один повинен запускатися автоматично (через завдання агента SQL і працює нормально), а інший, який потрібно запускати, попит користувачів після того, як доопрацьовані дані будуть доопрацьовані та очищені тощо.
Цей пакет виконує дуже привілейовані операції, включаючи резервне копіювання бази даних на початку запуску (щоб бути впевненим, щоб бути впевненим), скидання та відтворення розрахованих таблиць тощо.
Я написав збережену процедуру для виконання цього завдання через [SSISDB]. [Каталог]. [Create_execution] та [SSISDB]. [Каталог]. [Start_execution] збережені процедури .... це добре працює при запуску під мій обліковий запис (Я сисадмін).
Збережена процедура не вдалася, коли її запустив звичайний користувач, через більш високий рівень дозволів, необхідних для SSISDB та MSDB для виконання виконання, а сам пакет не вдався, оскільки він працює в їх (низькому) контексті безпеки.
Що я спробував :
Я намагався вирішити проблему за допомогою "Execute As" у збереженій процедурі, однак це не вдалося через проблеми з ланцюжком міжбазових даних, надійний прапор тощо.
Я також намагався вирішити проблему, маючи завдання агента для запуску пакету та просто запуск агента із збереженої процедури, проте я швидко ввійшов у світ болю, що включає:
- Неможливість встановлення дозволів на виконання на основі роботи
- Сподівання налаштувати цей доступ через центральну роль сервера, щоб забезпечити зміну персоналу з часом, а робочі місця може мати лише один користувач як власник
- Темний світ облікових записів проксі, облікових даних у поєднанні з sql-auth входами тощо
Плани C і D
Єдині варіанти, які я можу залишити для мене, - це створити виділений вхід на SQL Server із підвищеними дозволами та довіряти користувачам не передавати облікові дані / втрачати аудиторію того, хто запланував імпорт (як ця проблема вирішується в інших областях організація) або власноруч створити веб-передумови лише для того, щоб дозволити користувачам аутентифікувати свій обліковий запис "Роль сервера", а потім дозволити веб-додатку запускати збережену процедуру під другим (привілейованим) з'єднанням.
Так....
Чи є там поради, як:
- мати пакет SSIS для виконання пільгових операцій
- виконується користувачем з низькими пільгами (за допомогою облікового запису вікна AD)
- бажано, коли доступ до запуску завдання управляється через центральну роль сервера (у мене немає простої можливості створити для них нову групу Windows)
- і де будь-які нові, проміжні / проксі-акаунти - це автентичні облікові записи SQL Server (знову ж таки, дуже обмежена можливість внесення змін до AD)
Я розумію, що тут багато рухомих частин (а деякі відчувають, як прядильні леза), тому дайте мені знати, чи є інша інформація, яку ви відчуваєте, що я пропустив.
Ура, Тім
Редагувати ....
Тому сьогодні я створив спеціальний вхід на SQL Server з дозволами ssis_admin, створив три завдання агента SQL Server, що належать цьому користувачеві, та оновив збережену процедуру, яку мої кінцеві користувачі викликають до execute asцього користувача. Це не вдалося через неможливість викликати create executionвхід у систему SQL Server, для цього потрібен обліковий запис Windows.
Я оновив збережену для користувачів процедуру до execute asоблікового запису Windows SQL Server працює як (обліковий запис служби AD), надав її, ssis_adminі вона не працює з помилкою
Поточний контекст безпеки неможливо повернути. Перейдіть до оригінальної бази даних, куди було викликано "Виконати як", і спробуйте її ще раз.
Це нікуди не йде швидко :(
create_executionтому що мені потрібно передати параметр (одне з трьох значень) від проростка до завдання. Я радий мати три проростки / роботу тощо, якщо це вирішить. 2) Якщо ssis_admin - це найнижча привілейована роль, яка мене туди дістає, я до неї відкритий ... це краще, ніж принаймні sysadmin, і вирішує їх випадково скидаючи / забиваючи складові таблиці загального користування.
ssis_adminроль дозволила б їм запускати пакети SSIS (перевіряти програми на приналежність до ролей sysadmin або ssis_admin), але я думаю, що він буде працювати як їх, і тому не в змозі робити резервні копії та інше . (Мені доведеться перевірити це напевно, ніколи не пам'ятаю, чи працює він як обліковий запис або обліковий запис служби SQL Server). Однак, будучи членом ssis_admin, дозволяє їм розгортати пакети та плутати з конфігураціями, які можуть бути, а можуть і не бути гарною справою. 2016 рік дає нам більш детальні ролі, але, очевидно, тут не дуже
EXECUTE ASдля того, щоб вони могли виконувати конкретні завдання через sp_start_job. Каже, випадковий хлопець в Інтернеті, який жахливий у безпеці
create_executionтобто чи потрібно вказувати параметри виконання для "сценарію готовості даних?" 2) Можна припустити, що вам не цікаво ставити їх у ролі ssis_admin?