{"id":617,"date":"2018-07-20T00:40:44","date_gmt":"2018-07-19T22:40:44","guid":{"rendered":"https:\/\/staging.sql.marcus-belz.de\/?p=617"},"modified":"2026-05-07T02:15:26","modified_gmt":"2026-05-07T00:15:26","slug":"ssis-vs-transact-sql-identitatswechsel","status":"publish","type":"post","link":"https:\/\/staging.sql.marcus-belz.de\/?p=617","title":{"rendered":"SSIS vs. SQL – Identit\u00e4tswechsel"},"content":{"rendered":"

\u00dcberblick<\/h2>\n

SQL Server Integration <\/strong>Services (SSIS) ist ein \u00e4u\u00dferst m\u00e4chtiges Toolset f\u00fcr die Entwicklung von ETL-Strecken. Es gibt viele gute Gr\u00fcnde, die f\u00fcr einen Einsatz von SSIS sprechen. Es gibt derer aber auch gen\u00fcgend, die dagegen sprechen. Beschr\u00e4nken wir uns auf den Microsoft Produkt Stack, dann kommt als Alternative f\u00fcr die Entwicklung von komplexen ETL Strecken (im Wesentlichen) nur noch Transact-SQL (T-SQL) in Frage.<\/p>\n

Dieser Artikel geh\u00f6rt zu einer Serie von Artikeln<\/a>, die wichtige Entscheidungskriterien f\u00fcr die Wahl der richtigen Technologie(n) \u2013 SSIS und\/oder T-SQL \u2013 beleuchten.<\/p>\n

Wird ein SQL Agent Job gestartet, dann werden die einzelnen Stepps in dem Job standardm\u00e4\u00dfig in dem Security Kontext des Service-Accounts von dem SQL Server Agent ausgef\u00fchrt.<\/p>\n

Bei der Installation von SQL Server Agent ist ein Service Account anzugeben, unter dem der Dienst SQL Server Agent<\/strong> gestartet werden soll. Der Benutzer hat die Wahl zwischen der Angabe eines expliziten Kontos und der Auswahl des lokalen Systemkontos NT-AUTORIT\u00c4T\\System<\/strong>.<\/p>\n

Mit der Auswahl des Kontos verf\u00fcgt der angegebene Service Account \u00fcber einen Satz an Berechtigungen, die sehr wahrscheinlich nicht f\u00fcr alle SQL Server Agent Jobs entweder ausreichend oder erforderlich sind.<\/p>\n

So verf\u00fcgt das lokale Systemkonto NT-AUTORIT\u00c4T\\System<\/strong> \u00fcber umfassende Berechtigungen an lokalen Ressourcen und ist Mitglied der Windows-Gruppe Administratoren<\/strong>. SQL Server Agent Jobs k\u00f6nnen auf diesem Weg auf Ressourcen zugreifen, die f\u00fcr die Ausf\u00fchrung nicht erforderlich sind und die ggf. sogar vor unbefugtem Zugriff zu sch\u00fctzen sind. Auf der anderen Seite hat das Systemkonto in der Regel keine oder keine ausreichenden Berechtigungen an File Shares, Datenquellen etc.<\/p>\n

Nach dem need-to-know-Prinzip<\/strong> sollte der Benutzer, unter dem ein Job ausgef\u00fchrt wird, nur \u00fcber die erforderlichen Berechtigungen verf\u00fcgen, die f\u00fcr die Erledigung der Aufgabe \u2013 hier das Ausf\u00fchren des SQL Server Agent Jobs \u2013 erforderlich sind.<\/p>\n

Da in dem SQL Server Agent regelm\u00e4\u00dfig zahlreiche Jobs konfiguriert werden, die alle sehr unterschiedliche Aufgaben zu erledigen haben und daf\u00fcr unterschiedliche Ressourcen ben\u00f6tigen, ist es nicht m\u00f6glich den Service Account nach dem need-to-know-Prinzip mit den passenden Rechten auszustatten.<\/p>\n

Microsoft bietet als L\u00f6sung f\u00fcr dieses Problem den Identit\u00e4tswechsel<\/strong> zur Laufzeit an. Der technische Fachbegriff hierf\u00fcr ist die Impersonierung<\/strong>. Die Impersonierung erfolgt auf der Ebene eines SQL Agent Job Stepps, in dem ein SSIS Paket auszuf\u00fchren ist, durch Angabe eines sogenannten Proxy-Users<\/strong>. Dieser wird im SQL Agent in dem Order SQL Server Agent | Proxies | SSIS Package Execution<\/strong> erzeugt und referenziert einen Anmeldeinformationsnamen (Credential<\/strong>-Objekt) einer SQL Server Instanz, der in dem Ordner Security | Credentials<\/strong> der jeweiligen Instanz zu erzeugen ist. Mit dem Anmeldeinformationsnamen ist ein Datenbank-Login (SQL Server Authentifizierung oder Windows Authentifizierung) verbunden, der entsprechend den Anforderungen in der Datenbank, Fileshares, etc. zu berechtigen ist.<\/p>\n

Alle Artefakt-Typen, die als Stepp konfiguriert werden k\u00f6nnen, unterst\u00fctzen die Run As<\/strong> Property, au\u00dfer der Typ Transact-SQL Script<\/strong>. ETL-Strecken, die ausschlie\u00dflich auf der Basis von Transact-SQL erstellt wurden, k\u00f6nnen daher nicht \u00fcber den SQL Server Agent impersoniert werden.<\/p>\n

ETL-Strecken, die als Startpunkt \u00fcber ein SSIS Paket verf\u00fcgen, k\u00f6nnen \u00fcber den SQL Server Agent impersoniert werden. Die Verwendung eines SSIS Paketes als Startpunkt einer ETL-Strecke bedeutet nicht zwangsl\u00e4ufig, dass die komplette ETL-Strecke in SSIS realisiert werden muss. Ebenso gut kann die ETL-Strecke auf der Basis von Transact-SQL realisiert werden. Die Skripte, Stored Procedures, Stored Functions etc. sind in diesem Fall \u00fcber SQL Command Tasks in einem SSIS Paket auszuf\u00fchren.<\/p>\n

Fazit<\/h2>\n