Mam problemy z umożliwieniem moim użytkownikom wykonywania pakietów SSIS w rozsądny sposób ze względu na różne poziomy wymaganych uprawnień.
Scenariusz : stworzyliśmy hurtownię danych z dwoma różnymi pakietami SSIS odpowiedzialnymi za ładowanie danych, jeden ma być uruchamiany automatycznie (za pośrednictwem zadania agenta SQL i działa dobrze), a drugi musi być uruchamiany na- żądanie użytkowników po sfinalizowaniu i oczyszczeniu danych wyjściowych itp.
Ten pakiet wykonuje bardzo uprzywilejowane operacje, w tym tworzenie kopii zapasowej bazy danych na początku uruchomienia (dla pewności, dla pewności), upuszczanie i odtwarzanie tabel obliczeniowych itp.
Napisałem procedurę składowaną, aby wykonać to zadanie za pomocą [SSISDB]. [Katalog]. [Create_execution] i [SSISDB]. [Katalog]. [Start_execution] procedury składowane .... to działa dobrze, gdy działa na moim koncie (Jestem administratorem systemu).
Procedura składowana nie powiodła się, gdy została uruchomiona przez zwykłego użytkownika z powodu wyższego poziomu uprawnień wymaganych w SSISDB i MSDB do kolejkowania wykonania, a sam pakiet nie powiódł się, ponieważ działa w swoim (niskim) kontekście bezpieczeństwa.
Co próbowałem :
Próbowałem rozwiązać problem przy użyciu opcji „Wykonaj jako” w procedurze przechowywanej, jednak nie powiodło się to z powodu problemów z łańcuchem między bazami danych, flagi godnej zaufania itp.
Próbowałem również rozwiązać ten problem, uruchamiając pakiet Agenta i uruchamiając go z procedury przechowywanej, jednak szybko wkroczyłem w świat bólu obejmujący:
- Niemożność ustawienia uprawnień do wykonywania dla poszczególnych zadań
- Nadzieję skonfigurować ten dostęp za pośrednictwem centralnej roli serwera, aby zaspokoić zmiany personelu w czasie, a zadania mogą mieć tylko jednego użytkownika jako właściciela
- Ciemny świat kont proxy, poświadczeń w połączeniu z loginami sql-auth itp
Plany C i D.
Jedyne opcje, o których mogę myśleć, to utworzenie dedykowanego logowania do SQL Server z podwyższonymi uprawnieniami i ufanie użytkownikom, że nie przekażą poświadczeń / stracą kontrolę nad tym, kto zaplanował import (w jaki sposób problem został rozwiązany w innych obszarach organizacji) lub niestandardowe zbudowanie interfejsu użytkownika wyłącznie w celu umożliwienia użytkownikom uwierzytelnienia się jako konta „roli serwera”, a następnie umożliwienia aplikacji internetowej uruchomienia procedury składowanej w ramach drugiego (uprzywilejowanego) połączenia.
Więc....
Czy jest jakaś rada, jak:
- zlecić pakietowi SSIS wykonywanie operacji uprzywilejowanych
- wykonywane przez słabo uprzywilejowanego użytkownika (przy użyciu konta systemu Windows AD)
- najlepiej tam, gdzie dostęp do uruchomienia zadania jest zarządzany przez centralną rolę serwera (nie mam łatwej możliwości utworzenia dla nich nowej grupy okien)
- i gdzie wszelkie nowe konta pośrednie / proxy są kontami uwierzytelniania SQL Server (ponownie bardzo ograniczona możliwość wprowadzania zmian w AD)
Rozumiem, że jest tu wiele ruchomych części (a niektóre mają ochotę wirować ostrza), więc daj mi znać, jeśli zauważyłem jakieś inne informacje, które przegapiłem.
Pozdrawiam, Tim
Edytować....
Więc dzisiaj utworzyłem dedykowany login SQL Server z uprawnieniami ssis_admin, utworzyłem trzy zadania SQL Server Agent należące do tego użytkownika i zaktualizowałem procedurę przechowywaną, którą moi użytkownicy końcowi wywołują do execute astego użytkownika. Nie powiodło się to z powodu niemożności wywołania create executionjako loginu SQL Server, wymaga konta Windows.
Zaktualizowałem procedurę przechowywaną użytkowników do execute askonta Windows SQL Server działa jako (konto usługi AD), przyznałem to ssis_admini kończy się niepowodzeniem z błędem
Obecnego kontekstu bezpieczeństwa nie można przywrócić. Przejdź do oryginalnej bazy danych, w której wywołano „Execute As”, i spróbuj ponownie.
To nigdzie nie idzie szybko :(
create_executionponieważ muszę przekazać parametr (jedną z trzech wartości) ze sproc do zadania. Cieszę się, że mam trzy sproki / zadania itp., Jeśli to rozwiązuje. 2) Jeśli ssis_admin jest najniższą rolą przywilejów, która mnie tam prowadzi, jestem otwarty na to ... to jest lepsze niż przynajmniej sysadmin i rozwiązuje je przypadkowo upuszczając / nukując tabele magazynu w powszechnym użyciu.
ssis_adminrola pozwoliłaby im uruchamiać pakiety SSIS (sprawdzanie przez procs członkostwa w rolach sysadmin lub ssis_admin), ale myślę, że będzie działać jak one i dlatego nie będzie w stanie wykonywać kopii zapasowych i tym podobne. (Musiałbym to przetestować na pewno, nigdy nie pamiętam, czy działa jak oni, czy konto usługi SQL Server). Jednak bycie członkiem ssis_admin pozwala im wdrażać pakiety i wprowadzać zamieszanie w konfiguracjach, które mogą, ale nie muszą, być dobrą rzeczą. 2016 daje nam bardziej szczegółowe role, ale oczywiście niewiele tu
EXECUTE ASdać tym użytkownikom możliwość uruchamiania zadań, czy też wykluczyć to, stworzyć trzy procesy, które pozwolą im uruchamiać określone zadania za pośrednictwem sp_start_job. Mówi przypadkowy facet od Internetu, który jest straszny pod względem bezpieczeństwa
create_executiontj. Czy muszą określać parametry przy wykonywaniu dla „scenariusza gotowości danych?” 2) Można bezpiecznie założyć, że nie jesteś zainteresowany umieszczeniem ich w roli ssis_admin?