Anwendungssicherheitsszenarios in SQL Server (ADO.NET)
Für das Erstellen einer sicheren SQL Server-Clientanwendung gibt es kein Patentrezept. Jede Anwendung hat spezifische Anforderungen, eine spezielle Bereitstellungsumgebung und einen eigenen Benutzerkreis. Eine Anwendung, die zum Zeitpunkt ihrer Bereitstellung angemessen sicher ist, kann im Laufe der Zeit weniger sicher werden. Es ist unmöglich, genau vorherzusagen, welche Bedrohungen zukünftig entstehen können.
SQL Server, als Produkt, wurde im Laufe der Zeit ständig um die jeweils neuesten Sicherheitsfunktionen erweitert, um Entwicklern das Erstellen sicherer Datenbankanwendungen zu ermöglichen. Dennoch ist Sicherheit nicht einfach "ab Werk" zu haben; sie erfordert eine ständige Überwachung und Aktualisierung.
Allgemeine Bedrohungen
Entwickler müssen die Sicherheitsbedrohungen und die Tools zu deren Abwehr kennen, und sie müssen wissen, wie selbst zu verantwortende Sicherheitslücken vermieden werden können. Sicherheit ist wie eine Kette – Mängel in einem Glied bringen die Festigkeit der gesamten Kette in Gefahr. In der folgenden Liste finden Sie eine Übersicht über die häufigsten Sicherheitsbedrohungen. Eine ausführliche Erläuterung dieser Bedrohungen folgt dann in den einzelnen Themen in diesem Abschnitt.
SQL Injection-Angriffe
Bei einem SQL Injection-Angriff schleust ein Angreifer statt gültiger Eingaben Transact-SQL-Anweisungen ein. Wenn die Eingabe direkt und ohne Validierung an den Server weitergeleitet wird und die Anwendung den eingeschleusten Code ausführt, können auf diese Weise Daten beschädigt oder sogar zerstört werden. Sie können die Einschleusung von SQL Server-Befehlen vereiteln, indem Sie gespeicherte Prozeduren und parametrisierte Befehle verwenden, dynamisches SQL vermeiden und den Benutzern nur eingeschränkte Berechtigungen gewähren.
Angriffe durch Rechteerweiterung
Von einem Angriff durch Rechteerweiterung wird gesprochen, wenn sich ein Benutzer Zugang zu den Privilegien eines vertrauenswürdigen Kontos, z. B. als Besitzer oder Administrator, verschafft hat und diese für schädliche Aktionen nutzt. Arbeiten Sie immer nur mit Konten der untersten Berechtigungsebene, und weisen Sie nur die Berechtigungen zu, die wirklich benötigt werden. Vermeiden Sie es, zum Ausführen von Code administrative oder Besitzerkonten zu verwenden. Auf diese Weise dämmen Sie den potenziellen Schaden ein, den ein erfolgreicher Angriff verursachen kann. Verwenden Sie beim Ausführen von Aufgaben, die zusätzliche Berechtigungen erfordern, Prozedursignatur oder Identitätswechsel nur so lange, wie Sie sie für die Aufgabe benötigen. Mit der Einführung von SQL Server 2005 können Sie gespeicherte Prozeduren mit Zertifikaten signieren oder zur vorübergehenden Zuweisung von Berechtigungen mit Identitätswechsel arbeiten.
Angriffe durch Auswertung von Fehlermeldungen und intelligente Beobachtung
Angreifer können durch die Auswertung der von einer Anwendung generierten Fehlermeldungen Rückschlüsse auf eventuelle Sicherheitslücken ziehen. Implementieren Sie daher in prozeduralem Code immer auch eine Fehlerbehandlungsroutine, damit der Endbenutzer keine SQL Server-Fehlerinformationen angezeigt bekommt.
Authentifizierungsangriffe
Angreifer können die Verwendung von SQL Server-Anmeldungen ausnutzen, bei denen zur Laufzeit eine auf einer Benutzereingabe basierende Verbindungszeichenfolge konstruiert wird. Wenn die Verbindungszeichenfolge nicht auf gültige Schlüsselwortpaare überprüft wird, hat der Angreifer u. U. die Möglichkeit, zusätzliche Zeichen einzuschleusen, die es ihm erlauben, auf sicherheitsrelevante Daten oder andere Ressourcen auf dem Server zuzugreifen. Verwenden Sie daher nach Möglichkeit die Windows-Authentifizierung. Wenn Sie mit SQL Server-Anmeldungen arbeiten müssen, verwenden Sie zum Erstellen und Validieren der Verbindungszeichenfolgen zur Laufzeit den Verbindungszeichenfolgen-Generator (SqlConnectionStringBuilder).
Kennwortangriffe
Viele Angriffe sind erfolgreich, weil es dem Angreifer gelungen ist, das Kennwort eines Benutzers auszuspionieren oder zu erraten. Kennwörter bilden die erste Verteidigungslinie gegen Angriffe, daher ist die Festlegung starker Kennwörter für die Sicherheit Ihres Systems von entscheidender Bedeutung. Seit SQL Server 2005 können Sie Kennwortrichtlinien für die Authentifizierung im gemischten Modus erstellen und durchsetzen.
Weisen Sie dem sa-Konto immer, auch bei Verwendung der Windows-Authentifizierung, ein starkes Kennwort zu.
Inhalt dieses Abschnitts
Verwalten von Berechtigungen mit gespeicherten Prozeduren in SQL Server (ADO.NET)
Beschreibt, wie gespeicherte Prozeduren zur Verwaltung von Berechtigungen und zum Steuern des Datenzugriffs verwendet werden können. Die Verwendung gespeicherter Prozeduren bietet einen effektiven Schutz vor einer ganzen Reihe von Sicherheitsbedrohungen.Schreiben von sicherem dynamischen SQL in SQL Server (ADO.NET)
Beschreibt Verfahren zum Schreiben von sicherem dynamischen SQL-Code unter Verwendung gespeicherter Prozeduren.Signieren gespeicherter Prozeduren in SQL Server (ADO.NET)
Beschreibt die Vorgehensweise zum Signieren gespeicherter Prozeduren mit einem Zertifikat, sodass die Benutzer mit Daten arbeiten können, auf die sie keinen direkten Zugriff haben. Auf diese Weise können gespeicherte Prozeduren Vorgänge ausführen, die der Aufrufer seinen Berechtigungen zufolge nicht direkt ausführen darf.Anpassen von Berechtigungen mit Identitätswechsel in SQL Server (ADO.NET)
Beschreibt, wie mithilfe der EXECUTE AS-Klausel die Identität eines anderen Benutzers angenommen werden kann. Beim Identitätswechsel wechselt der Ausführungskontext vom Aufrufer zum angegebenen Benutzer.Gewähren zeilenspezifischer Berechtigungen in SQL Server (ADO.NET)
Beschreibt die Implementierung von zeilenspezifischen Berechtigungen zur Einschränkung des Datenzugriffs.Erstellen von Anwendungsrollen in SQL Server (ADO.NET)
Beschreibt die Funktionen und die Funktionalität von Anwendungsrollen.Aktivieren des datenbankübergreifenden Zugriffs in SQL Server (ADO.NET)
Beschreibt, wie der Zugriff auf mehrere Datenbanken bereitgestellt werden kann, ohne dabei die Sicherheit zu gefährden.
Siehe auch
Weitere Ressourcen
SQL Server-Sicherheit (ADO.NET)