У меня возникают проблемы с разрешением моим пользователям выполнять пакеты служб SSIS разумным образом из-за различных уровней привилегий.
Сценарий : мы создали хранилище данных с двумя различными пакетами служб SSIS, отвечающими за загрузку его с данными, один должен запускаться автоматически (через задание агента SQL и работает нормально), а другой должен выполняться на спрос пользователей после того, как вышестоящие данные будут завершены, очищены и т. д.
Этот пакет выполняет очень привилегированные операции, включая резервное копирование базы данных в начале выполнения (чтобы быть уверенным, чтобы быть уверенным), удаление и воссоздание вычисленных таблиц и т. Д.
Я написал хранимую процедуру для выполнения этого задания через хранимые процедуры [SSISDB]. [Catalog]. [Create_execution] и [SSISDB]. [Catalog]. [Start_execution] .... это отлично работает при запуске под моей учетной записью (Я сисадмин).
Сбой хранимой процедуры при запуске обычным пользователем из-за более высокого уровня разрешений, требуемых в SSISDB и MSDB для постановки в очередь на выполнение, а сам пакет не выполнен, поскольку он работает в их (низком) контексте безопасности.
Что я пробовал :
Я попытался решить проблему с помощью «Выполнить как» в хранимой процедуре, однако это не удалось из-за проблем цепочки между базами данных, флага «Надежность» и т. Д.
Я также попытался решить проблему, имея задания агента для запуска пакета и просто запустив задание агента из хранимой процедуры, однако я быстро попал в мир боли, включающий:
- Невозможность установить разрешения на выполнение для каждого задания
- Надеемся настроить этот доступ через центральную роль сервера, чтобы обеспечить смену персонала с течением времени, а задания могут иметь только одного пользователя в качестве владельца.
- Темный мир учетных записей прокси, учетных данных в сочетании с входами в систему sql-auth и т. Д.
Планы C и D
Единственные варианты, которые я могу придумать, - это создать выделенную учетную запись SQL Server с повышенными разрешениями и доверить пользователям, что они не будут передавать учетные данные или потерять возможность проверки того, кто запланировал импорт (как эта проблема решается в других областях. организации) или пользовательскую сборку веб-интерфейса исключительно для того, чтобы пользователи могли проходить аутентификацию в качестве своей учетной записи «Роль сервера», а затем разрешать веб-приложению запускать хранимую процедуру при втором (привилегированном) соединении.
Так....
Есть ли какой-нибудь совет, как:
- иметь пакет служб SSIS для выполнения привилегированных операций
- выполняется пользователем с низким уровнем привилегий (используя учетную запись Windows AD)
- предпочтительно, когда доступ к запуску задания управляется через центральную роль сервера (у меня нет легкой возможности создать для них новую группу окон)
- и где любые новые промежуточные / прокси-учетные записи являются учетными записями SQL Server Auth (опять же, очень ограниченная возможность вносить изменения в AD)
Я понимаю, что здесь есть много движущихся частей (и некоторые чувствуют себя как вращающиеся лезвия), поэтому дайте мне знать, есть ли какая-то другая информация, которую вы чувствуете, я пропустил.
Ура, Тим
Редактировать....
Итак, сегодня я создал выделенную учетную запись SQL Server с разрешениями ssis_admin, создал три задания агента SQL Server, принадлежащие этому пользователю, и обновил хранимую процедуру, которую мои конечные пользователи вызывают для execute asэтого пользователя. Это не удалось из-за невозможности вызова create executionв качестве имени входа SQL Server, требуется учетная запись Windows.
Я обновил хранимую процедуру пользователей до execute asучетной записи Windows, на которой запущен SQL Server (учетная запись службы AD), предоставил ее ssis_adminи завершился с ошибкой
Текущий контекст безопасности не может быть восстановлен. Пожалуйста, переключитесь на исходную базу данных, где был вызван «Выполнить как», и попробуйте снова.
Это никуда не денется быстро :(
create_executionпотому что мне нужно передать параметр (одно из трех значений) из sproc в задание. Я счастлив иметь три sprocs / jobs и т. Д., Если это решит это. 2) Если ssis_admin - это роль с наименьшими привилегиями, которая позволяет мне быть там, я открыт для нее ... это лучше, чем sysadmin, по крайней мере, и решает их случайным удалением / уничтожением таблиц хранилища в общем использовании.
ssis_adminРоль позволит им запускать пакеты SSIS (в прок проверить на членство в системного администратора или ssis_admin роли) , но я думаю , что это будет работать , как и они , и , следовательно , не в состоянии делать резервное копирование и тому подобное. (Я должен был проверить это наверняка, никогда не вспомню, работает ли он как они или учетная запись службы SQL Server). Тем не менее, членство в ssis_admin позволяет им развертывать пакеты и использовать конфигурации, которые могут или не могут быть полезными. 2016 дает нам более детализированные роли, но, очевидно, здесь не так уж много пользы
EXECUTE ASзапретить их , создать три процесса, которые позволят им запускать определенные задания sp_start_job. Говорит случайный интернет-парень, который ужасен в безопасности
create_executionт. Е. Нужно ли им указывать параметры при выполнении для их «сценария готовности данных?» 2) Можно предположить, что вы не заинтересованы в том, чтобы поместить их в роль ssis_admin?