Sicherer Datenzugriff (ADO.NET)
Aktualisiert: November 2007
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 Features 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 dringend empfohlen, da die dabei verwendete Verbindungszeichenfolge keinerlei Benutzeranmeldeinformationen enthält, sodass diese Informationen vor unbefugtem Zugriff geschützt sind. 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.
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 dazu finden Sie in den folgenden Ressourcen.
Ressource |
Beschreibung |
---|---|
Beschreibt bewährte Methoden und Techniken zum Schutz der Verbindungsinformationen, wie z. B. das Verwenden geschützter Konfigurationen zum Verschlüsseln der Verbindungszeichenfolgen. |
|
Enthält Empfehlungen für das Zugreifen auf Daten und das Ausführen von Datenbankoperationen. |
|
Beschreibt, wie aus Benutzereingabe zur Laufzeit Verbindungszeichenfolgen erstellt werden können. |
|
Beschreibt die SQL Server-Sicherheitsarchitektur. |
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.
Ressource |
Beschreibung |
---|---|
Beschreibt die Verwendung von Parametern mit einem DataAdapter. |
|
Beschreibt das Angeben von Parametern und das Abrufen von Rückgabewerten. |
|
Verwalten von Berechtigungen mit gespeicherten Prozeduren in SQL Server (ADO.NET) |
Beschreibt die Verwendung gespeicherter SQL Server-Prozeduren zum Kapseln des Datenzugriffs. |
Skriptexploits
Ein Skriptexploit ist eine andere Form der Einschleusung, bei der in eine Webseite schädliche Zeichen eingeschleust werden. Der Browser überprüft die eingefügten Zeichen nicht und verarbeitet sie als Teil der Seite.
Weitere Informationen dazu finden Sie in der folgenden Ressource.
Ressource |
Beschreibung |
---|---|
Beschreibt, wie Sie sich vor Skript- und SQL-Anweisung-Exploits schützen können. |
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 dazu finden Sie in den folgenden Ressourcen.
Ressource |
Beschreibung |
---|---|
Beschreibt die grundlegenden Formen der Behandlung von Ausnahmen mit der "try/catch/finally"-Struktur. |
|
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 Sicherheitsfeatures 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.
Weitere Informationen zum Schützen von Access- und Excel-Daten finden Sie in den folgenden Ressourcen.
Ressource |
Beschreibung |
---|---|
Beschreibt die Sicherheitsverfahren von Access 2007, wie die Verschlüsselung von Dateien, die Verwaltung von Kennwörtern und die Umwandlung von Datenbanken in die neuen Formate ACCDB und ACCDE sowie die Verwendung anderer Sicherheitsoptionen. |
|
Beschreibt, wie Sie steuern können, wer auf Ihre Excel 2007-Daten zugreifen und sie ändern darf. |
|
Besser Schützen einer Access-Datenbank und ihrer Objekte mit Sicherheit auf Benutzerebene (MDB) |
Bezieht sich auf Access 2003. Enthält Anweisungen zum Implementieren der Sicherheit auf Benutzerebene zum Schützen von Daten in Access 2003. |
Grundlegend zu der Rolle der Arbeitsgruppeninformationsdateien für Zugriffssicherheit |
Erläutert die Rolle und die Beziehung der Arbeitsgruppeninformationsdatei in der Access 2003-Sicherheit. |
Häufig gestellte Fragen zur Sicherheit in Microsoft Access 2.0 bis 2000 |
Herunterladbare Version der Antworten auf häufig gestellte Fragen (FAQ) zum Thema "Sicherheit in Microsoft Access". |
Informiert über Lösungen für häufig auftretende Sicherheitsprobleme in Excel 2003. |
Enterprise Services
COM+ enthält ein eigenes Sicherheitsmodell, das auf die Windows NT-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.
Weitere Informationen dazu finden Sie in den folgenden Ressourcen.
Ressource |
Beschreibung |
---|---|
Erläutert, wie verwalteter Code mit COM+-Sicherheitsdiensten integriert werden kann. |
|
Erläutert, wie die Klassen im EnterpriseServices-Namespace zum Erstellen von Serviced Components verwendet werden können. |
Interaktion 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 dazu finden Sie in den folgenden Ressourcen.
Ressource |
Beschreibung |
---|---|
Enthält Themen, die beschreiben, wie COM-Komponenten für .NET Framework und .NET Framework-Komponenten für COM verfügbar gemacht werden sollten. |
|
Enthält zusätzliche Themen, in denen es u. a. um primäre Interopassemblys, Threading und benutzerdefiniertes Marshalling geht. |
Siehe auch
Konzepte
Empfehlungen zur Zugriffsstrategie auf Daten
Schützen von Verbindungsinformationen (ADO.NET)
Verbindungszeichenfolgen-Generatoren (ADO.NET)