SQL Server-Sicherheit: Verschlüsselung und SQL Injection

SQL Server unterstützt auch die Verschlüsselung von Daten, die zwischen dem Server und einem Client im Netzwerk übertragen werden. Dies ist besonders nützlich, wenn sich der Client im öffentlich zugänglichen Internet befindet und man befürchtet, dass jemand zwischen Server und Client den Netzwerk-Verkehr abhört und vertrauliche Daten abfängt.

Zur Aktivierung der Verschlüsselung sollten sowohl Client als auch Server die TCP/IP Network Library für die Kommunikation verwenden. Dazu führt man das entsprechende Netzwerk-Utility aus (Start > Programme > Microsoft SQL Server > Server Network Utility auf dem Server und Start > Programme > Microsoft SQL Server > Client Network Utility auf dem Client) und aktiviert das Kontrollkästchen „Force Protocol Encryption“. Alle Verbindungen zwischen Client und Server werden von nun an verschlüsselt.

Die Verschlüsselung hat natürlich ihren Preis. Beim Aufbau einer Verbindung ist einiges an Mehraufwand nötig und sowohl Client als auch Server müssen den Code zur Verschlüsselung und Entschlüsselung der Datenpakete ausführen. Es ist also erhöhter Rechenaufwand erforderlich, was u. U. auch zu messbaren Geschwindigkeitseinbußen bei aktivierter Verschlüsselung führen kann. Doch wenn man die vollständige Kontrolle über die Netzwerkpakete (also die tatsächlich über die Leitung zwischen Client und Server ausgetauschten Daten) verloren hat, ist eine Verschlüsselung wahrscheinlich empfehlenswert.

Verschlüsselung mit Lücken

Es wird vielleicht aufgefallen sein, dass in der Liste der verschlüsselbaren Dinge offensichtlich etwas fehlt: die Daten in den Tabellen. SQL Server bietet von Haus aus keine Unterstützung für die Verschlüsselung solcher Daten vor der Speicherung. Falls man die in SQL Server gespeicherten Daten schützen will, gibt es zwei Möglichkeiten: Einmal kann man mithilfe der Schlüsselwörter GRANT und DENY festlegen, wer Zugriff auf die Daten innerhalb von SQL Server hat, wie in einem früheren Artikel dieser Reihe bereits beschrieben. Wenn Anwender eine Tabelle gar nicht erst öffnen können, spielt es auch keine Rolle, ob die darin enthaltenen Daten verschlüsselt sind oder nicht.

Zweitens: Falls man die Daten tatsächlich verschlüsseln will, sollte man sich keine eigene Verschlüsselungslösung basteln. Es gibt eine Reihe kommerzieller Produkte mit bewährten Verschlüsselungsalgorithmen auf dem Markt, auf die man zurückgreifen kann. Eine gute Übersicht findet sich in den SQLSecurity FAQ.