Sto riscontrando problemi nel consentire ai miei utenti di eseguire i pacchetti SSIS in modo ragionevole a causa dei diversi livelli di privilegio richiesti.
Lo scenario : abbiamo creato un data warehouse, con due diversi pacchetti SSIS responsabili del caricamento con dati, uno deve essere eseguito automaticamente (tramite un processo SQL Agent e funziona correttamente) e un altro che deve essere eseguito su- domanda da parte degli utenti una volta finalizzati e puliti i dati a monte, ecc.
Questo pacchetto esegue operazioni molto privilegiate tra cui il backup del database all'inizio dell'esecuzione (per sicurezza, per sicurezza), l'eliminazione e la ricreazione di tabelle calcolate ecc.
Ho scritto una procedura memorizzata per eseguire questo lavoro tramite [SSISDB]. [Catalog]. [Create_execution] e [SSISDB]. [Catalog]. [Start_execution] stored procedure ... funziona benissimo quando eseguito con il mio account (Sono un amministratore di sistema).
La procedura memorizzata non è riuscita quando è stata eseguita da un utente normale a causa del livello più elevato di autorizzazioni richiesto in SSISDB e MSDB per accodare l'esecuzione e il pacchetto stesso non è riuscito perché è in esecuzione nel loro (modesto) contesto di sicurezza.
Cosa ho provato :
Ho tentato di risolvere il problema utilizzando 'Esegui come' nella procedura memorizzata, tuttavia questo non è riuscito a causa di problemi di concatenamento tra database, flag affidabile, ecc.
Ho anche tentato di risolvere il problema avendo i processi Agent per eseguire il pacchetto e semplicemente eseguendo il processo agent dalla procedura memorizzata, tuttavia sono rapidamente entrato in un mondo di dolore che comporta:
- L'impossibilità di impostare le autorizzazioni di esecuzione in base al lavoro
- La speranza di configurare questo accesso tramite un ruolo server centrale per soddisfare il cambiamento del personale nel tempo e che i lavori possano avere un solo utente come proprietario
- Il mondo oscuro di account proxy, credenziali in combinazione con accessi sql-auth ecc
Piani C e D
Le uniche opzioni che posso pensare di rimanere per me sono la creazione di un accesso SQL Server dedicato con autorizzazioni elevate e la fiducia degli utenti a non trasferire le credenziali o perdere la verificabilità di chi ha pianificato l'importazione (in che modo questo problema viene risolto in altre aree di l'organizzazione) o creare un front-end Web puramente per consentire agli utenti di autenticarsi come account "Ruolo server", quindi consentire all'app Web di eseguire la procedura memorizzata con una seconda connessione (privilegiata).
Così....
C'è qualche consiglio là fuori su come:
- fare in modo che un pacchetto SSIS esegua operazioni privilegiate
- eseguito da un utente con privilegi limitati (utilizzando un account Windows AD)
- preferibilmente laddove l'accesso per eseguire il lavoro è gestito tramite un ruolo server centrale (non ho la possibilità di creare un nuovo gruppo di finestre per loro)
- e dove qualsiasi nuovo account intermedio / proxy sono account Auth di SQL Server (di nuovo, capacità molto limitata di apportare modifiche all'AD)
Capisco che ci sono molte parti in movimento qui (e alcune hanno la sensazione di girare le pale) quindi fammi sapere se ci sono altre informazioni che ritieni mi siano perse.
Saluti, Tim
Modificare....
Così oggi ho creato un accesso SQL Server dedicato con autorizzazioni ssis_admin, creato tre lavori di SQL Server Agent di proprietà di quell'utente e aggiornato la procedura memorizzata che i miei utenti finali chiamano per execute asquell'utente. Questo non è riuscito a causa dell'impossibilità di chiamare create executioncome accesso a SQL Server, richiede un account Windows.
Ho aggiornato la procedura memorizzata dagli utenti con execute asl'account Windows in cui SQL Server è in esecuzione come (un account del servizio AD), l'ho concesso ssis_admine non riesce con l'errore
L'attuale contesto di sicurezza non può essere ripristinato. Passare al database originale in cui è stato chiamato "Execute As" e riprovare.
Questo non sta andando da nessuna parte veloce :(
create_executionperché devo passare un parametro (uno dei tre valori) dallo sproc al lavoro. Sono felice di avere tre sprocs / lavori ecc se questo lo risolve. 2) Se ssis_admin è il ruolo di privilegio più basso che mi porta lì, sono aperto ad esso ... è meglio di sysadmin almeno e li risolve accidentalmente facendo cadere / nuking i tavoli del magazzino in uso generale.
ssis_adminruolo consentirebbe loro di eseguire i pacchetti SSIS (i procs controllano l'appartenenza ai ruoli sysadmin o ssis_admin) ma penso che funzionerà come loro e quindi non sarà in grado di eseguire backup e simili. (Dovrei testarlo di sicuro, non ricordo mai se funziona come loro o l'account del servizio SQL Server). Tuttavia, essere membro di ssis_admin consente loro di distribuire pacchetti e confondere con configurazioni che possono essere o meno una buona cosa. Il 2016 ci offre ruoli più granulari ma ovviamente non è molto utile qui
EXECUTE ASconsentono di eseguire i lavori specifici tramite sp_start_job. Dice il ragazzo di Internet a caso che è terribile in sicurezza
create_executionie devono specificare i parametri in esecuzione per il loro "scenario pronto per i dati?" 2) Sicuro di non essere interessato a metterli nel ruolo ssis_admin?