Es scheint mir, dass Sie in der Antwort auf Ihre Frage nicht auf einen SQL-Code warten. Der Hauptaspekt Ihrer Frage ist der Sicherheitsaspekt. Was sollten Sie tun, um Ihre Anforderung ohne sysadmin zu implementieren Privilegien und ohne neue Sicherheitslücke? Das ist Ihre eigentliche Frage, denke ich.
Ich sehe mindestens 3 Möglichkeiten, um Ihr Problem zu lösen. Aber zuerst einmal eine kurze Erklärung, warum es in allen Lösungen, die auf Extended Stored Procedures basieren, Sysadmin-Privilegien gibt . Erweiterte gespeicherte Prozeduren wie xp_cmdshell sind sehr alt. Sie existierten mindestens vor SQL Server 4.2, dem ersten Microsoft SQL Server, der unter dem ersten Windows NT (NT 3.1) lief. In der alten Version von SQL Server gab es keine Sicherheitsbeschränkung, solche Prozeduren auszuführen, aber später machte man solche Beschränkungen. Es ist wichtig zu verstehen, dass alle allgemeinen Zweck Prozeduren, die es ermöglichen, jeden Prozess zu starten unter einem SQL Server-Konto wie xp_cmdshell und sp_OACreate müssen haben sysadmin Privilegien Einschränkung. Nur aufgabenorientiert Verfahren mit klarem Nutzungsbereich und rollenbasierten Berechtigungen können das Problem ohne Sicherheitslücke lösen. Das sind also die 3 Lösungswege, die ich zuvor versprochen habe:
- Sie erstellen ein neues SQL-Konto auf Ihrem SQL-Server mit sysadmin Privilegien. Dann erstellen Sie eine gespeicherte Prozedur, die einige der erweiterten gespeicherten Prozeduren verwendet wie
xp_cmdshellodersp_OACreateund Ihre Anforderungen technisch umzusetzen (einige Informationen in eine CSV-Datei exportieren). In Bezug auf EXECUTE AS Klausel (siehe http://msdn.microsoft.com/en-us/ library/ms188354.aspx ) konfigurieren Sie die erstellte gespeicherte Prozedur so, dass sie unter dem Konto mit sysadmin läuft Privilegien. Sie delegieren die Ausführung dieses Verfahrens an Benutzer mit einer gewissen SQL-Rolle, um hinsichtlich der Delegierung von Berechtigungen flexibler zu sein. - Sie können gespeicherte CLR-Prozeduren verwenden statt
xp_cmdshellundsp_OACreate. Sie sollten auch rollenbasierte Berechtigungen für das erstellte Verfahren verwenden. - Der Endbenutzer ruft keine von Ihnen erstellte gespeicherte SQL-Prozedur direkt auf. Es gibt eine Software (wie den WCF-Dienst oder eine Website), die Ihre gespeicherte SQL-Prozedur aufruft. Sie können den Export in eine CSV-Datei innerhalb dieser Software und nicht innerhalb einer gespeicherten SQL-Prozedur implementieren.
Bei allen Implementierungsarten sollten Sie genau definieren, wo Sie das Passwort aufbewahren des Kontos, mit dem Sie auf das Dateisystem zugreifen. Es gibt verschiedene Optionen, die Sie haben, alle mit entsprechenden Vor- und Nachteilen. Es ist möglich, Identitätswechsel zu verwenden, um den Zugriff auf das Dateisystem mit dem Konto des Endbenutzers zu ermöglichen. Der beste Weg hängt von der Situation ab, die Sie in Ihrer Umgebung haben.
