Sicherer Datenzugriff
Wenn Sie sicheren ADO.NET-Code schreiben möchten, müssen Sie die Sicherheitsmechanismen kennen, die im zugrunde liegenden Datenspeicher oder der zugrundeliegenden Datenbank verfügbar sind. Außerdem müssen Sie die Auswirkungen anderer in Ihrer Anwendung enthaltenen Funktionen oder Komponenten auf die Sicherheit berücksichtigen.
Authentifizierung, Autorisierung und Berechtigungen
Beim Herstellen einer Verbindung mit Microsoft SQL Server können Sie die Windows-Authentifizierung (auch als "Integrierte Sicherheit" bezeichnet) verwenden, bei der nicht die Benutzer-ID und das Kennwort übermittelt werden, sondern die Identität des jeweils aktiven Windows-Benutzers verwendet wird. Die Verwendung der Windows-Authentifizierung wird für lokale Datenbanken dringend empfohlen, da die dabei verwendete Verbindungszeichenfolge keinerlei Benutzeranmeldeinformationen enthält. Wenn Sie für die Herstellung von Verbindungen mit SQL Server nicht auf die Windows-Authentifizierung zurückgreifen können, sollten Sie erwägen, die Verbindungszeichenfolgen zur Laufzeit mit dem SqlConnectionStringBuilder zu erstellen.
Wichtig
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Wenn Sie eine Verbindung mit Azure SQL herstellen, ist Managed Identities for Azure Resources die empfohlene Authentifizierungsmethode.
Die zur Authentifizierung verwendeten Anmeldeinformationen müssen je nach der Art der Anwendung unterschiedlich behandelt werden. In einer Windows Forms-Anwendung kann ein Benutzer beispielsweise aufgefordert werden, Authentifizierungsinformationen einzugeben, oder es können dessen Windows-Anmeldeinformationen verwendet werden. Eine Webanwendung hingegen greift auf Daten mithilfe von Anmeldeinformationen zu, die von der Anwendung selbst und nicht vom Benutzer bereitgestellt werden.
Welche Aktionen die Benutzer nach der Authentifizierung ausführen dürfen, hängt von den Berechtigungen ab, die ihnen erteilt wurden. Befolgen Sie dabei strikt das Prinzip der minimalen Rechtegewährung: Gewähren Sie immer nur die Berechtigungen, die absolut notwendig sind.
Weitere Informationen finden Sie in den folgenden Ressourcen.
| Resource | Beschreibung |
|---|---|
| Schützen von Verbindungsinformationen | Beschreibt bewährte Methoden und Techniken zum Schützen von Verbindungsinformationen, z. B. das Verwenden der geschützten Konfiguration zur Verschlüsselung von Verbindungszeichenfolgen. |
| Verbindungszeichenfolgen-Generatoren | Beschreibt, wie aus Benutzereingabe zur Laufzeit Verbindungszeichenfolgen erstellt werden können. |
| Sicherheit für SQL Server-Datenbank-Engine und Azure SQL-Datenbank | Stelle Links bereit, über die Sie Informationen zu Sicherheit und Schutz in SQL Server Database Engine und Azure SQL Database finden können. |
Parametrisierte Befehle und SQL Injection
Die Verwendung parametrisierter Befehle hilft beim Schutz vor SQL Injection-Angriffen, bei denen ein Angreifer einen SQL-Befehl in eine SQL-Anweisung einschleust, der die Sicherheit auf dem Server gefährdet. Parametrisierte Befehle schützen vor solchen Angriffen, indem sie dafür sorgen, dass Werte aus einer externen Quelle lediglich als Werte und nicht als Bestandteil einer Transact-SQL-Anweisung weitergeleitet werden. In einen Wert eingefügte Transact-SQL-Befehle werden daher nicht in der Datenquelle ausgeführt. Stattdessen werden sie nur als Parameterwert ausgewertet. Parametrisierte Befehle sind aber nicht nur aus Sicherheitsgründen vorteilhaft, sondern sie stellen auch eine bequeme Methode zum Organisieren von Werten dar, die mit einer Transact-SQL-Anweisung weitergeleitet bzw. an eine gespeicherte Prozedur übergeben werden.
Weitere Informationen zur Verwendung parametrisierter Befehle finden Sie in den folgenden Ressourcen.
| Resource | Beschreibung |
|---|---|
| DataAdapter-Parameter | Beschreibt die Verwendung von Parametern mit einem DataAdapter. |
| Ändern von Daten mit gespeicherten Prozeduren | Beschreibt das Angeben von Parametern und das Abrufen von Rückgabewerten. |
| Gespeicherte Prozeduren (Datenbank-Engine) | Beschreibt die Vorteile der Verwendung gespeicherter Prozeduren und der verschiedenen Arten gespeicherter Prozeduren. |
Angriffe anhand von ausgewerteten Fehlerinformationen
Angreifer verwenden für ihre Angriffe häufig Informationen aus Fehlermeldungen. Diese können z. B. Aufschluss über den Namen des Servers, der Datenbank oder der Tabelle geben. Da Fehlermeldungen spezifische Informationen über eine Anwendung bzw. Datenquelle enthalten können, können Sie die Anwendung bzw. Datenquelle besser schützen, indem Sie lediglich Informationen verfügbar machen, die vom Client explizit angefordert werden.
Weitere Informationen finden Sie in den folgenden Ressourcen.
| Resource | Beschreibung |
|---|---|
| Behandeln und Auslösen von Ausnahmen in .NET | Beschreibt die grundlegenden Formen der Behandlung von Ausnahmen mit der "try/catch/finally"-Struktur. |
| Bewährte Methoden für Ausnahmen | Beschreibt bewährte Vorgehensweisen bei der Behandlung von Ausnahmen. |
Schützen von Microsoft Access- und Excel-Datenquellen
Microsoft Access und Microsoft Excel können dort, wo die Sicherheitsanforderungen nur minimal sind, als Datenspeicher für ADO.NET-Anwendungen fungieren. Deren Sicherheitsfunktionen sind zwar zur Abschreckung unwissender Benutzer geeignet, können aber von erfahrenen Angreifern durchaus umgangen werden. Die physischen Datendateien für Access und Excel befinden sich im Dateisystem, und der Zugriff darauf muss für alle Benutzer gewährleistet sein. Sie sind daher für Angriffe anfällig, bei denen Daten gestohlen oder zerstört werden, denn sie können problemlos kopiert oder bearbeitet werden. Wenn also eine robustere Sicherheit verlangt wird, verwenden Sie SQL Server oder eine andere serverbasierte Datenbank, in der die physischen Datendateien nicht aus dem Dateisystem gelesen werden können.
Enterprise Services
COM+ enthält ein eigenes Sicherheitsmodell, das auf die Windows-Konten und den Prozess-/Threadidentitätswechsel zurückgreift. Der System.EnterpriseServices-Namespace stellt Wrapper bereit, die es .NET-Anwendungen ermöglichen, über die ServicedComponent-Klasse verwalteten Code mit COM+-Sicherheitsdiensten zu integrieren.
Interoperabilität mit nicht verwaltetem Code
.NET Framework ermöglicht die Interaktion mit nicht verwaltetem Code, darunter COM-Komponenten, COM+-Diensten, externen Typbibliotheken und vielen Betriebssystemdiensten. Beim Arbeiten mit nicht verwaltetem Code wird die "Sicherheitszone" des verwalteten Codes verlassen. Sowohl Ihr Code als auch jeder Code, der Ihren Code aufruft, muss eine Berechtigung für nicht verwalteten Code besitzen (SecurityPermission mit UnmanagedCode-Flag). Nicht verwalteter Code kann für Ihre Anwendung unbeabsichtigte Sicherheitslücken bedeuten. Deshalb sollten Sie mit nicht verwaltetem Code nur interagieren, wenn dies absolut notwendig ist.
Weitere Informationen finden Sie unter Interoperation mit nicht verwaltetem Code.