Ich habe Probleme damit, meinen Benutzern das Ausführen von SSIS-Paketen auf angemessene Weise zu ermöglichen, da unterschiedliche Berechtigungen erforderlich sind.
Das Szenario : Wir haben ein Data Warehouse mit zwei verschiedenen SSIS-Paketen erstellt, die für das Laden der Daten verantwortlich sind. Eines wird automatisch ausgeführt (über einen SQL Agent-Job und funktioniert einwandfrei), und ein anderes muss ausgeführt werden. Bedarf der Benutzer, sobald die vorgelagerten Daten finalisiert und bereinigt wurden usw.
Dieses Paket führt sehr privilegierte Operationen aus, darunter das Sichern der Datenbank zu Beginn des Laufs (um sicher zu sein), das Löschen und Neuerstellen berechneter Tabellen usw.
Ich habe eine gespeicherte Prozedur geschrieben, um diesen Job über die gespeicherten Prozeduren [SSISDB]. [Catalog]. [Create_execution] und [SSISDB]. [Catalog]. [Start_execution] auszuführen (Ich bin ein Sysadmin).
Die gespeicherte Prozedur schlug fehl, wenn sie von einem normalen Benutzer ausgeführt wurde, da in SSISDB und MSDB eine höhere Berechtigungsstufe erforderlich ist, um die Ausführung in die Warteschlange zu stellen, und das Paket selbst schlug fehl, weil es in seinem (wenig) Sicherheitskontext ausgeführt wird.
Was ich versucht habe :
Ich habe versucht, das Problem mithilfe von "Ausführen als" in der gespeicherten Prozedur zu beheben. Dies ist jedoch aufgrund der datenbankübergreifenden Verkettungsprobleme, des Vertrauenswürdigkeitsmerkmals usw. fehlgeschlagen.
Ich habe auch versucht, das Problem zu lösen, indem ich Agent-Jobs zum Ausführen des Pakets und nur den Agent-Job über die gespeicherte Prozedur ausgeführt habe.
- Die Unfähigkeit, Ausführungsberechtigungen auf Jobbasis festzulegen
- In der Hoffnung, diesen Zugriff über eine zentrale Serverrolle konfigurieren zu können, um den sich im Laufe der Zeit ändernden Mitarbeitern gerecht zu werden, und Jobs können nur einen einzigen Benutzer als Eigentümer haben
- Die dunkle Welt der Proxy Accounts, Credentials in Kombination mit sql-auth Logins etc
Pläne C und D
Ich kann mir nur vorstellen, ein dediziertes SQL Server - Login mit erhöhten Berechtigungen zu erstellen und darauf zu vertrauen, dass die Benutzer die Anmeldeinformationen nicht weitergeben oder die Überprüfbarkeit darüber verlieren, wer den Import geplant hat (wie dieses Problem in anderen Bereichen von gelöst wird) oder erstellen Sie ein benutzerdefiniertes Web-Front-End, um es den Benutzern zu ermöglichen, sich als ihr "Serverrollenkonto" zu authentifizieren, und lassen Sie dann die Web-App die gespeicherte Prozedur unter einer zweiten (privilegierten) Verbindung ausführen.
So....
Gibt es da draußen einen Rat, wie man:
- Lassen Sie ein SSIS-Paket privilegierte Vorgänge ausführen
- von einem Benutzer mit geringen Rechten ausgeführt (unter Verwendung eines AD-Windows-Kontos)
- am besten dort, wo der Zugriff zum Ausführen des Jobs über eine zentrale Serverrolle verwaltet wird (ich habe keine einfache Möglichkeit, eine neue Windows-Gruppe für sie zu erstellen)
- und wenn es sich bei neuen Zwischen- / Proxy-Konten um SQL Server-Auth-Konten handelt (wiederum sehr eingeschränkte Möglichkeit, Änderungen an der AD vorzunehmen)
Ich verstehe, dass es hier eine Menge beweglicher Teile gibt (und einige fühlen sich an wie sich drehende Klingen). Lassen Sie mich wissen, wenn Sie weitere Informationen vermissen.
Prost, Tim
Bearbeiten....
Daher habe ich heute eine dedizierte SQL Server-Anmeldung mit den Berechtigungen "ssis_admin" erstellt, drei SQL Server-Agent-Jobs dieses Benutzers erstellt und die gespeicherte Prozedur aktualisiert, die meine Endbenutzer für execute asdiesen Benutzer aufrufen . Dies ist fehlgeschlagen, create executionda keine SQL Server-Anmeldung möglich ist und ein Windows-Konto erforderlich ist.
Ich habe die gespeicherte Benutzerprozedur auf execute asdas Windows-Konto aktualisiert, unter dem SQL Server ausgeführt wird (ein AD-Dienstkonto), habe es gewährt ssis_adminund es schlägt mit dem Fehler fehl
Der aktuelle Sicherheitskontext kann nicht wiederhergestellt werden. Wechseln Sie in die ursprüngliche Datenbank, in der 'Ausführen als' aufgerufen wurde, und versuchen Sie es erneut.
Das geht nirgendwo so schnell :(
create_executionweil ich einen Parameter (einen von drei Werten) vom Sproc an den Job übergeben muss. Ich bin froh, drei Sprocs / Jobs usw. zu haben, wenn dies das Problem löst. 2) Wenn ssis_admin die niedrigste Berechtigungsklasse ist, die mich dorthin befördert, bin ich dafür offen ... es ist zumindest besser als sysadmin und löst sie, wenn sie versehentlich die Warehouse-Tabellen fallen lassen / zerstören, die allgemein verwendet werden.
ssis_adminRolle würde es ihnen ermöglichen, die SSIS-Pakete auszuführen (die Prüfung der Zugehörigkeit zu den Rollen sysadmin oder ssis_admin), aber ich denke, dass sie so ausgeführt werden und daher keine Sicherungen und Ähnliches durchführen können. (Ich müsste das auf jeden Fall testen, kann mich nie erinnern, ob es so läuft wie sie oder das SQL Server-Dienstkonto). Wenn Sie jedoch Mitglied von ssis_admin sind, können Sie Pakete bereitstellen und mit Konfigurationen mischen, die möglicherweise eine gute Sache sind oder nicht. Das Jahr 2016 gibt uns
EXECUTE ASmit denen sie die spezifischen Jobs über ausführen können sp_start_job. Sagt der zufällige Internet-Typ, der schrecklich an der Sicherheit ist
create_executiondh müssen sie bei der Ausführung Parameter für das Szenario "Daten bereit" angeben? 2) Sie können davon ausgehen, dass Sie nicht daran interessiert sind, sie in die Rolle ssis_admin zu übernehmen?