Freigeben über


Verwalten von Berechtigungen mit gespeicherten Prozeduren in SQL Server (ADO.NET)

Aktualisiert: November 2007

Eine Möglichkeit, eine Bastion aus mehreren Verteidigungslinien um Ihre Datenbank aufzubauen, besteht darin, den Zugriff auf Daten so zu implementieren, dass er nur über gespeicherte Prozeduren oder benutzerdefinierten Funktionen läuft. Sie können alle Berechtigungen für die zugrunde liegenden Objekte, z. B. Tabellen, widerrufen oder verweigern, und Sie können EXECUTE-Berechtigungen für gespeicherte Prozeduren gewähren. Auf diese Weise wird um Ihre Daten und Datenbankobjekte herum ein wirksamer Sicherheitszaun aufgebaut.

Vorteile gespeicherter Prozeduren

Gespeicherte Prozeduren bieten die folgenden Vorteile:

  • Datenlogik und Geschäftsregeln können gekapselt werden, sodass die Benutzer so auf die Daten und Objekte zugreifen, wie das von den Entwicklern und Datenbankadministratoren beabsichtigt ist.

  • Zur Abwehr von Angriffen durch Einschleusung von SQL-Befehlen (SQL Injection-Angriffe) können parametrisierte gespeicherte Prozeduren verwendet werden, die alle Benutzereingaben validieren. Bei Verwendung von dynamischem SQL sollten Sie Ihre Befehle unbedingt parametrisieren und auf keinen Fall Parameterwerte direkt in eine Abfragezeichenfolge aufnehmen.

  • Es ist möglich, Ad-hoc-Abfragen und Datenänderungen nicht zuzulassen. So werden die Benutzer daran gehindert, vorsätzlich oder unbeabsichtigt Daten zu zerstören oder Abfragen auszuführen, die die Leistung auf dem Server oder im Netzwerk negativ beeinflussen.

  • Fehler können in prozeduralem Code und ohne direkte Weitergabe an Clientanwendungen behandelt werden. So wird verhindert, dass Fehlermeldungen zurückgegeben werden, die von Angreifern ausgewertet werden könnten. Protokollieren Sie Fehler, und lassen Sie sie auf dem Server behandeln.

  • Einmal geschriebene gespeicherte Prozeduren stehen für viele Anwendungen zur Verfügung.

  • Clientanwendungen müssen nichts über die zugrunde liegenden Datenstrukturen wissen. Code in gespeicherten Prozeduren kann geändert werden, ohne dass Änderungen in den Clientanwendungen erforderlich sind, so lange die Änderungen sich nicht auf Parameterlisten oder zurückgegebene Datentypen auswirken.

  • Gespeicherte Prozeduren können Netzwerkverkehr reduzieren, da sie in einem Prozeduraufruf mehrere Vorgänge kombinieren.

Ausführung gespeicherter Prozeduren

Gespeicherte Prozeduren profitieren beim Datenzugriff von der Besitzverkettung, sodass die Benutzer keine explizite Zugriffsberechtigung für die Datenbankobjekte benötigen. Eine Besitzkette ist vorhanden, wenn Objekte, die sequenziell aufeinander zugreifen, demselben Benutzer gehören. So kann eine gespeicherte Prozedur z. B. andere gespeicherte Prozeduren aufrufen oder auf mehrere Tabellen zugreifen. Wenn alle Objekte in einer Ausführungskette demselben Besitzer gehören, prüft SQL Server nur die EXECUTE-Berechtigungen für den Aufrufer, nicht aber die Berechtigungen des Aufrufers für die anderen Objekte. Sie müssen daher bei gespeicherten Prozeduren nur die EXECUTE-Berechtigungen gewähren. Sämtliche Berechtigungen für die zugrunde liegenden Tabellen können Sie widerrufen oder verweigern.

Bewährte Vorgehensweisen

Für eine hinreichende Absicherung Ihrer Anwendung reicht es nicht aus, einfach nur gespeicherte Prozeduren zu schreiben. Sie sollten darüber hinaus auch auf die folgenden potenziellen Sicherheitslücken eingehen.

  • Erteilen Sie EXECUTE-Berechtigungen für die gespeicherten Prozeduren für die Datenbankrollen, die auf die Daten zugreifen können sollen.

  • Widerrufen oder verweigern Sie alle Berechtigungen für die zugrunde liegenden Tabellen, und zwar für alle Rollen und Benutzer in der Datenbank, darunter auch für die public-Rolle. Alle Benutzer erben die Berechtigungen der public-Rolle. Wenn Sie also die Berechtigungen für public verweigern, erhalten nur die Besitzer und die sysadmin-Member Zugriff. Alle anderen Benutzer können aus ihrer Zugehörigkeit zu anderen Rollen keine Berechtigungen erben.

  • Fügen Sie den Rollen sysadmin und db_owner keine Benutzer oder Rollen hinzu. Systemadministratoren und Datenbankbesitzer können auf alle Datenbankobjekte zugreifen.

  • Deaktivieren Sie das guest-Konto. So wird verhindert, dass anonyme Benutzer eine Verbindung mit der Datenbank herstellen können. Das Gastkonto ist in neuen Datenbanken standardmäßig deaktiviert.

  • Implementieren Sie Fehlerbehandlungsmechanismen, und protokollieren Sie Fehler.

  • Erstellen Sie parametrisierte gespeicherte Prozeduren, die alle Benutzereingaben validieren. Behandeln Sie alle Benutzereingaben als nicht vertrauenswürdig.

  • Verwenden Sie dynamisches SQL nur, wenn das unbedingt notwendig ist. Verwenden Sie die Transact-SQL-QUOTENAME()-Funktion, um Zeichenfolgenwerte zu begrenzen, und maskieren Sie sämtliche Vorkommen des Trennzeichens in der Eingabezeichenfolge.

Externe Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

Ressource

Beschreibung

Gespeicherte Prozeduren und SQL Injection in der SQL Server 2008-Onlinedokumentation

In diesen Themen wird beschrieben, wie Sie gespeicherte Prozeduren erstellen können und wie die Einschleusung von SQL-Befehlen bei SQL Injection-Angriffen funktioniert.

Gespeicherte Prozeduren und SQL Injection in der SQL Server 2005-Onlinedokumentation

In den Themen wird beschrieben, wie Sie gespeicherte Prozeduren erstellen können und wie die Einschleusung von SQL-Befehlen bei SQL Injection-Angriffen funktioniert.

Gespeicherte Prozeduren und Verwenden von Besitzketten in der SQL Server 2000-Onlinedokumentation

In diesen Themen wird beschrieben, wie Sie gespeicherte Prozeduren erstellen und die Besitzketten in SQL Server 2000 zu Ihrem Vorteil nutzen können.

Siehe auch

Konzepte

Anwendungssicherheitsszenarien in SQL Server (ADO.NET)

Schreiben von sicherem dynamischen SQL in SQL Server (ADO.NET)

Signieren gespeicherter Prozeduren in SQL Server (ADO.NET)

Anpassen von Berechtigungen mit Identitätswechsel in SQL Server (ADO.NET)

Ändern von Daten mit gespeicherten Prozeduren (ADO.NET)

Weitere Ressourcen

Sichern von ADO.NET-Anwendungen

Übersicht über die SQL Server-Sicherheit (ADO.NET)