Willkommen Anmelden
Microsoft Developer Network
Per Mausklick bewerten und Feedback geben
MSDN
MSDN Library
Entwicklerbibliothek
.NET-Entwicklung
Security
 Modul 12 – Datenzugriffssicherheit
Modul 12 – Datenzugriffssicherheit
Aktualisiert: 05. Mai 2004
Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
Einführung in die Datenzugriffssicherheit Einführung in die Datenzugriffssicherheit
Authentifizierung Authentifizierung
Autorisierung Autorisierung
Sichere Kommunikation Sichere Kommunikation
Herstellen der Verbindung mit minimalen Rechten Herstellen der Verbindung mit minimalen Rechten
Erstellen eines Datenbankkontos mit minimalen Rechten Erstellen eines Datenbankkontos mit minimalen Rechten
Sicheres Speichern von Datenbank-Verbindungszeichenfolgen Sicheres Speichern von Datenbank-Verbindungszeichenfolgen
Authentifizieren von Benutzern anhand einer Datenbank Authentifizieren von Benutzern anhand einer Datenbank
SQL Injection-Angriffe SQL Injection-Angriffe
Überwachung Überwachung
Prozessidentität für SQL Server Prozessidentität für SQL Server
Zusammenfassung Zusammenfassung

Modulübersicht

In den meisten verteilten Webanwendungen spielt ein Datenspeicher wie z. B. Microsoft SQL Server 2000 eine wesentliche Rolle. Dieser Datenspeicher kann alle Arten von Daten enthalten, wie zum Beispiel vertrauliche Personal- oder Krankendaten, Überwachungs- und Sicherheitsprotokolle und sogar Anmeldeinformationen, die Benutzer für den Zugriff auf die Anwendung benötigen. Selbstverständlich müssen diese Daten gesichert werden, damit nur Benutzer mit der entsprechenden Autorisierung darauf zugreifen können.

Dieses Modul beschreibt Lösungen zu den wichtigsten Sicherheitsfragen, die mit dem Zugriff auf Datenspeicher verbunden sind, und enthält Empfehlungen für den Zugriff auf Daten aus verteilten Webanwendungen. Dabei liegt der Schwerpunkt auf SQL Server 2000, doch treffen viele der behandelten Themen auch auf andere Datenspeicher zu.

Zielsetzung

Themenbereiche:

  • Erstellen sicherer Datenzugriffskomponenten

  • Verwenden der Windows-Authentifizierung oder SQL Server-Authentifizierung zum Herstellen einer Verbindung zu SQL Server aus ASP.NET

  • Auswahl eines für Ihre Anwendung geeigneten SQL Server 2000-Autorisierungsmechanismus

  • Sichern der Daten mithilfe von SSL oder IPSec während der Übertragung zwischen einer Clientanwendung und einer Datenquelle

  • Erstellen eines Datenbankkontos mit minimalen Rechten für die Verwendung mit SQL Server 2000

  • Sicheres Speichern von Datenbank-Verbindungszeichenfolgen und Anmeldeinformationen

  • Sicheres Speichern von Benutzeranmeldeinformationen zu Authentifizierungszwecken in einer Datenbank mithilfe von Kennworthashes und Salt-Werten

  • Schützen einer SQL-Datenbank vor SQL Injection-Angriffen

  • Aktivieren der Überwachung zu SQL Server 2000

Betrifft

Die Informationen in diesem Modul gelten für folgende Produkte und Technologien:

  • Windows XP oder Windows 2000 Server (mit Service Pack 3) und höhere Betriebssysteme

  • .NET Framework Version 1.0 (mit Service Pack 2) und höhere Versionen

  • Visual C# .NET

  • SQL Server 2000 (mit Service Pack 2) und höhere Versionen

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

  • Sie sollten über Erfahrung in der Programmierung mit Visual C# .NET verfügen.

  • Sie sollten über Erfahrung in der Entwicklung und Konfiguration von ASP.NET-Webanwendungen verfügen.

  • Sie sollten Erfahrung in der Konfiguration von SQL Server 2000-Sicherheit besitzen.

  • Sie sollten über Erfahrung in der Konfiguration der Windows-Sicherheit und dem Erstellen von Benutzerkonten mithilfe der Windows-Verwaltungstools verfügen.

  • Lesen Sie Modul 1, "Einführung". Hier wird die Bedeutung von Authentifizierung, Autorisierung und sicherer Kommunikation für verteilte Webanwendungen erläutert.

  • Lesen Sie Modul 2, "Sicherheitsmodell für ASP.NET-Anwendungen". Hier finden Sie eine Übersicht der Architektur und Technologien, die bei der Erstellung verteilter ASP.NET-Webanwendungen zum Einsatz kommen. Außerdem wird hervorgehoben, wo Sie Authentifizierung, Autorisierung und sicherer Kommunikation in diese Architektur integrieren können.

  • Lesen Sie Modul 3, "Authentifizierung und Autorisierung". Es enthält Informationen zu Identitätswechsel, vertrauenswürdigen Subsystemen und SQL Server 2000-Rollen. Diese Themen werden in diesem Modul näher erläutert.

  • Lesen Sie Modul 4, "Sichere Kommunikation". Es enthält eine Einführung in SSL und IPSec. Diese Technologien können Sie zum Sichern von Kommunikationskanälen zwischen einem Datenspeicher und dessen Clientanwendungen verwenden.

  • Lesen Sie Modul 8, "ASP.NET-Sicherheit". Es enthält eine detaillierte Beschreibung der mit ASP.NET verbundenen Sicherheitsprobleme. Dabei stehen besonders Fragen der Prozessidentität, der Identität des Benutzers und des Identitätswechsels im Mittelpunkt. Diese Fragen wirken sich auf die Optionen aus, die für Ihre ASP.NET-Anwendung zur Authentifizierung bei Ihrem Datenspeicher verfügbar sind.

  • Lesen Sie die folgenden Module. Sie finden hier Hinweise zur Implementierung vieler in diesem Modul behandelter Techniken:

    • "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET"

    • "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern"

    • "Vorgehensweise: Verwenden von SSL zum Sichern der Kommunikation mit SQL Server 2000"

    • "Vorgehensweise: Erstellen einer DPAPI-Bibliothek"

    • "Vorgehensweise: Verwenden von DPAPI (Computerspeicher) von ASP.NET aus"

    • "Vorgehensweise: Verwenden von DPAPI (Benutzerspeicher) von ASP.NET aus mit Enterprise Services"

    • "Vorgehensweise: Speichern von verschlüsselten Verbindungszeichenfolgen in der Registrierung"

    • "Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000"

Einführung in die Datenzugriffssicherheit

In Abbildung 12.1 werden die wichtigsten mit dem Datenzugriff verbundenen Sicherheitsthemen dargestellt.

Wichtigste Sicherheitsthemen beim Datenzugriff

Abbildung 12.1
Wichtigste Sicherheitsthemen beim Datenzugriff

Die in Abbildung 12.1 dargestellten und in diesem Modul nachfolgend erläuterten Themen werden hier kurz zusammengefasst:

  1. Sicheres Speichern von Datenbank-Verbindungszeichenfolgen. Dies ist besonders von Bedeutung, wenn die Anwendung die SQL-Authentifizierung verwendet, um die Verbindung zu SQL Server herzustellen oder zu Datenbanken, die nicht von Microsoft stammen und die explizite Anmeldeinformationen erfordern. In diesen Fällen erhalten die Verbindungszeichenfolgen unverschlüsselte Benutzernamen und Kennwörter.

  2. Verwenden von geeigneten Identitäten für den Zugriff auf die Datenbank. Auf Daten kann man mit der Prozessidentität des aufrufenden Prozesses zugreifen, mithilfe einer oder mehrerer Dienstidentitäten oder mit der Identität des ursprünglichen Benutzers (über den Identitätswechsel oder die Delegierung). Die Auswahl wird durch Ihr Datenzugriffsmodell bestimmt – vertrauenswürdiges Subsystem oder Identitätswechsel/Delegierung.

  3. Sichern von Daten, die über das Netzwerk gesendet werden. Beispielsweise das Sichern von Anmeldeinformationen und vertraulicher Daten, die an und von SQL Server gesendet werden.

    Hinweis: Anmeldeinformationen werden nur dann im Netzwerk offen gelegt, wenn Sie die SQL-Authentifizierung verwenden (nicht bei der Windows-Authentifizierung).

    SQL Server 2000 unterstützt SSL mit Serverzertifikaten. IPSec kann ebenfalls zum Verschlüsseln des Datenverkehrs zwischen dem Clientcomputer (z. B. einem Web- oder Anwendungsserver) und dem Datenbankserver verwendet werden.

  4. Authentifizieren von Benutzern in der Datenbank. SQL Server unterstützt die Windows-Authentifizierung (mit NTLM oder Kerberos) und SQL-Authentifizierung (mithilfe des in SQL Server integrierten Authentifizierungsmechanismus).

  5. Autorisieren von Benutzern in der Datenbank. Einzelnen Datenbankobjekten werden Berechtigungen zugeordnet. Die Berechtigungen können Benutzern, Gruppen oder Rollen zugeordnet werden.

SQL Server-Gatekeeper

In Abbildung 12.2 werden die wichtigsten Gatekeeper für den Datenzugriff auf SQL Server hervorgehoben.

SQL Server-Gatekeeper

Abbildung 12.2
SQL Server-Gatekeeper

Im Folgenden werden die wichtigsten Gatekeeper aufgeführt:

  • Der ausgewählte Datenspeicher, der zum Verwalten der Datenbank-Verbindungszeichenfolge verwendet wird.

  • Die SQL Server-Benutzernamen (durch den Servernamen bestimmt, der in der Verbindungszeichenfolge angegeben ist).

  • Der Datenbankbenutzer (der Benutzerkontext innerhalb der Datenbank, dem der SQL Server-Benutzername zugeordnet ist) und verbundene Datenbankrollen.

  • Einzelnen Datenbankobjekten zugeordnete Berechtigungen.
    Die Berechtigungen können Benutzern, Gruppen oder Rollen zugeordnet werden.

Vertrauenswürdiges Subsystem und Identitätswechsel/Delegierung

Der feinstufige Zugriff auf die Datenbank ist sehr wichtig. Sie müssen überlegen, ob Sie die Autorisierung auf Benutzerebene für die Datenbank wünschen (die das Modell von Identitätswechsel/Delegierung erfordert), oder ob Sie die Anwendungsrollenlogik auf der mittleren Ebene Ihrer Anwendung verwenden, um Benutzer zu autorisieren (erfordert das Modell mit vertrauenswürdigen Subsystemen).

Wenn die Datenbank die Autorisierung auf Benutzerebene erwartet, müssen Sie für den ursprünglichen Benutzer einen Identitätswechsel durchführen. Obwohl das Modell von Identitätswechsel/Delegierung unterstützt wird, empfiehlt es sich, das Modell mit vertrauenswürdigen Subsystemen zu verwenden, bei dem der ursprüngliche Benutzer am IIS/ASP.NET-Gate überprüft, einer Rolle zugeordnet und dann anhand der Rollenmitgliedschaft autorisiert wird. Die Systemressourcen für die Anwendung werden dann über Dienstkonten auf Anwendungs- oder Rollenebene autorisiert, oder es wird die Prozessidentität der Anwendung verwendet (z. B. das Konto ASPNET).

Abbildung 12.3 zeigt diese beiden Modelle.

Das Modell mit vertrauenswürdigen Subsystemen und das Modell mit Identitätswechsel/Delegierung für den Datenbankzugriff

Abbildung 12.3
Das Modell mit vertrauenswürdigen Subsystemen und das Modell mit Identitätswechsel/Delegierung für den Datenbankzugriff

Sie sollten eine Reihe von wichtigen Faktoren bedenken, wenn Sie die Verbindung zu SQL Server für den Datenzugriff herstellen. Diese Faktoren werden hier zusammengefasst und in folgenden Abschnitten näher erläutert:

  • Welchen Authentifizierungstyp sollten Sie verwenden? Die Windows-Authentifizierung bietet eine umfangreiche Sicherheit, wobei Firewalls und Probleme mit nicht vertrauenswürdigen Domänen die SQL-Authentifizierung erfordern können. Wenn dies der Fall ist, sollten Sie sicherstellen, dass die SQL-Authentifizierung durch Ihre Anwendung so sicher wie möglich erfolgt, wie es weiter unten in diesem Modul unter "SQL-Authentifizierung" beschrieben wird.

  • Einzelne Benutzerrolle oder mehrere Benutzerrollen. Muss die Anwendung mithilfe eines einzelnen Kontos auf SQL zugreifen, das in der Datenbank über einen festen Satz an Berechtigungen verfügt, oder sind mehrere (rollenbasierte) Konten in Abhängigkeit vom Benutzer der Anwendung erforderlich?

  • Benutzeridentität: Muss die Datenbank die Identität des ursprünglichen Benutzers über den Aufrufkontext erhalten, um entweder die Autorisierung oder die Überwachung durchzuführen, oder können Sie eine oder mehrere vertrauenswürdige Verbindungen verwenden und die Identität des ursprünglichen Benutzers auf der Anwendungsebene übergeben?
    Damit das Betriebssystem die Identität des ursprünglichen Benutzers übermitteln kann, ist ein Identitätswechsel/Delegierung auf der mittleren Ebene erforderlich. Dies verringert die Effektivität des Verbindungspools erheblich. Das Verbindungspooling ist weiterhin aktiviert, führt jedoch zu vielen kleinen Pools (für jeden einzelnen Sicherheitskontext), und das bei geringer oder keiner Wiederverwendung von Verbindungen.

  • Werden vertrauliche Daten an den und vom Datenbankserver gesendet? Die Windows-Authentifizierung bedeutet zwar, dass Sie keine Benutzeranmeldeinformationen über das Netzwerk an den Datenbankserver übergeben, doch sollten Sie vertrauliche Anwendungsdaten (z. B. Mitarbeiter- oder Gehaltsinformationen) über IPSec oder SSL sichern.

Authentifizierung

Dieser Abschnitt beschreibt, wie Clients für SQL Server authentifiziert werden und wie Sie eine Identität auswählen, die vor dem Herstellen einer Verbindung zu SQL Server für den Datenbankzugriff innerhalb der Clientanwendungen verwendet wird.

Windows-Authentifizierung

Die Windows-Authentifizierung ist aus folgenden Gründen sicherer als die SQL-Authentifizierung:

  • Die Anmeldeinformationen werden für Sie verwaltet und nicht über das Netzwerk übertragen.

  • Sie vermeiden das Einbetten von Benutzernamen und Kennwörtern in Verbindungszeichenfolgen.

  • Die Anmeldesicherheit wird über Ablaufzeiten für Kennwörter, minimale Länge und Kontensperrung nach mehreren ungültigen Anmeldeanforderungen verbessert. Dies verringert die Bedrohung durch Verzeichnisangriffe (Wörterbuchangriffe).

Verwenden Sie die Windows-Authentifizierung in den folgenden Szenarios:

  • Sie haben das Modell mit vertrauenswürdigen Subsystemen verwendet und stellen die Verbindung zum SQL Server über eine einzelne feste Identität her. Wenn Sie die Verbindung über ASP.NET herstellen, ist die Webanwendung nicht für den Identitätswechsel konfiguriert.
    Verwenden Sie in diesem Szenario die ASP.NET-Prozessidentität oder eine Serviced Component-Identität (abgerufen von dem Konto, das zum Ausführen einer Enterprise Services-Serveranwendung verwendet wurde).

  • Sie delegieren den Sicherheitskontext des ursprünglichen Benutzers absichtlich, indem Sie die Delegierung verwenden (und sind bereit, die Anwendungsskalierbarkeit zu opfern, indem Sie auf das Datenbankverbindungspooling verzichten).

Bedenken Sie die folgenden wichtigen Punkte, wenn Sie die Windows-Authentifizierung verwenden, um die Verbindung zu SQL Server herzustellen:

  • Verwenden Sie für das ASP.NET-Prozesskonto das Prinzip der minimalen Rechte. Vermeiden Sie es, dem ASP.NET-Prozess das Recht Als Teil des Betriebssystems handeln zu erteilen, um LogonUser-API-Aufrufe zu ermöglichen.

  • Ermitteln Sie, welcher Code zusätzliche Rechte erfordert, und positionieren Sie diesen in Serviced Components, die in prozessexternen Enterprise Services-Anwendungen ausgeführt werden.

Weitere Informationen

Weitere Informationen zum Zugreifen auf Netzwerkressourcen über ASP.NET sowie zum Auswählen und Konfigurieren eines entsprechenden Kontos für das Ausführen von ASP.NET finden Sie in Modul 8, "ASP.NET-Sicherheit".

Verwenden der Windows-Authentifizierung

Sie haben folgende Möglichkeiten, wenn Sie die Windows-Authentifizierung zum Herstellen der Verbindung zu SQL Server über eine ASP.NET-Anwendung (oder einen Webdienst oder eine Remotekomponente, die ASP.NET als Host dient) verwenden.

  • Verwenden der ASP.NET-Prozessidentität

  • Verwenden von festen Identitäten in ASP.NET.

  • Verwenden von Serviced Components.

  • Verwenden der API LogonUser und Durchführen eines Identitätswechsels für eine bestimmte Identität.

  • Verwenden der Identität des ursprünglichen Benutzers.

  • Verwenden des anonymen Internetbenutzerkontos.

Empfehlung

Es wird empfohlen, die lokale ASP.NET-Prozessidentität durch Ändern des Kennworts auf dem Server in einen bekannten Wert zu konfigurieren und ein gespiegeltes Konto auf dem Datenbankserver zu erstellen, indem Sie einen lokalen Benutzer mit demselben Namen und demselben Kennwort erstellen. Weitere Einzelheiten zu diesen und anderen Ansätzen finden Sie im Folgenden.

Verwenden der ASP.NET-Prozessidentität

Wenn Sie die Verbindung zu SQL Server direkt über eine ASP.NET-Anwendung (oder Webdienst oder eine Remotekomponente, die von ASP.NET verwaltet wird) herstellen, verwenden Sie die ASP.NET-Prozessidentität. Hierbei handelt es sich um einen üblichen Ansatz, wobei die Vertrauensgrenze durch die Anwendung definiert wird, d. h. die Datenbank vertraut dem ASP.NET-Konto beim Zugriff auf die Datenbankobjekte.

Sie haben drei Möglichkeiten:

  • Verwenden von gespiegelten lokalen ASPNET-Konten.

  • Verwenden von gespiegelten, benutzerdefinierten lokalen ASPNET-Konten.

  • Verwenden eines benutzerdefinierten Domänenkontos.

Verwenden von gespiegelten lokalen ASPNET-Konten

Dies ist der einfachste Ansatz, der im Allgemeinen verwendet wird, wenn Sie Eigentümer der Zieldatenbank sind (und die Verwaltung lokaler Datenbankserverkonten steuern können). Mit dieser Option nutzen Sie das lokale ASPNET-Konto mit minimalen Rechten, um ASP.NET auszuführen, und erstellen dann ein dupliziertes Konto auf dem Datenbankserver.

Hinweis: Dieser Ansatz bietet den zusätzlichen Vorteil, dass er über nicht vertrauenswürdige Domänen hinweg und durch Firewalls hindurch funktioniert. Die Firewall öffnet möglicherweise nicht genügend Ports, um die Windows-Authentifizierung zu unterstützen.

Verwenden von gespiegelten, benutzerdefinierten lokalen ASPNET-Konten

Dieser Ansatz ähnelt dem vorherigen, mit der Ausnahme, dass Sie nicht das ASPNET-Standardkonto verwenden. Das bedeutet zweierlei:

  • Sie müssen ein benutzerdefiniertes lokales Konto mit den entsprechenden Berechtigungen und Rechten erstellen.
    Weitere Informationen finden Sie unter "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET" in diesem Handbuch.

  • Sie verwenden nicht länger das durch den .NET Framework-Installationsprozess erstellte Standardkonto. Ihr Unternehmen besitzt möglicherweise eine Richtlinie, die Standardinstallationskonten verbietet. Dadurch kann sich die Sicherheit Ihrer Anwendung möglicherweise erhöhen.
    Weitere Informationen finden Sie unter "Sans Top 20, "G2 – Accounts with No Passwords or Weak Passwords" (http://www.sans.org/top20.htm, englisch).

Verwenden eines benutzerdefinierten Domänenkontos

Dieser Ansatz gleicht dem vorherigen, mit der Ausnahme, dass Sie ein Domänenkonto mit minimalen Rechten anstatt eines lokalen Kontos verwenden. Dieser Ansatz setzt voraus, dass sich Client- und Servercomputer in derselben oder in vertrauten Domänen befinden. Der Hauptvorteil besteht darin, dass die Anmeldeinformationen nicht computerübergreifend verwendet werden. Die Computer erteilen lediglich dem Domänenkonto den Zugriff. Darüber hinaus vereinfachen Domänenkonten die Verwaltung.

Implementieren einer gespiegelten ASPNET-Prozessidentität

Sie müssen die folgenden Aktionen durchführen, um gespiegelte Konten zum Herstellen der Verbindung von ASP.NET zu einer Datenbank zu verwenden:

  • Verwenden Sie den Benutzer-Manager auf dem Webserver, um das Kennwort des ASPNET-Kontos auf einen bekannten starken Wert zurückzusetzen.

    Wichtig: Wenn Sie das ASPNET-Kennwort in einen bekannten Wert ändern, stimmt das Kennwort der LSA (Local Security Authority) auf dem lokalen Computer nicht mehr mit dem in der Windows-SAM-(Security Account Manager-)Datenbank gespeicherten Kennwort überein. Wenn Sie zum Standardwert AutoGenerate zurückkehren möchten, müssen Sie Folgendes tun:

    Führen Sie Aspnet_regiis.exe aus, um ASP.NET auf seine Standardkonfiguration zurückzusetzen. Weitere Informationen finden Sie in der Microsoft Knowledge Base im Artikel 306005, "SO WIRD'S GEMACHT: Reparieren der IIS-Zuordnung nach dem Entfernen und erneuten Installieren von IIS". Wenn Sie so vorgehen, erhalten Sie ein neues Konto und eine neue Windows-SID (Security Identifier). Die Berechtigungen für dieses Konto werden auf ihre Standardwerte zurückgesetzt. Daher müssen Sie die Berechtigungen und Rechte, die Sie ursprünglich für das alte ASPNET-Konto festgelegt haben, explizit erneut zuweisen.

  • Legen Sie das Kennwort explizit in der Datei Machine.config fest. Verschlüsseln Sie die <processModel>-Anmeldeinformationen mit dem Dienstprogramm aspnet_setreg.exe in einem sicheren Registrierungsschlüssel. Einzelheiten dazu finden Sie in der Microsoft Knowledge Base im Artikel Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (englischsprachig).

    <processModel
       userName="registry:HKLM\SOFTWARE\YourSecureApp\
                 processModel\ASPNET_SETREG,userName"
       password="registry:HKLM\SOFTWARE\YourSecureApp\
                 processModel\ASPNET_SETREG,password" . . . />

    Schützen Sie die Datei Machine.config vor unberechtigten Zugriffen, indem Sie Windows-ACLs verwenden. Erteilen Sie z. B. nicht dem anonymen IIS-Internetbenutzerkonto den Zugriff auf Machine.config.

  • Erstellen Sie auf dem Datenbankserver ein gespiegeltes Konto (mit demselben Benutzernamen und Kennwort).

  • Erstellen Sie in der SQL-Datenbank einen Serverbenutzernamen für das lokale ASPNET-Konto und ordnen Sie diesem Benutzernamen dann ein Benutzerkonto innerhalb der erforderlichen Datenbank zu. Erstellen Sie dann eine Datenbank-Benutzerrolle, fügen Sie den Datenbankbenutzer zur Rolle hinzu, und konfigurieren Sie die entsprechenden Datenbankberechtigungen für die Rolle.
    Weitere Informationen finden Sie unter "Erstellen eines Datenbankkontos mit minimalen Rechten" weiter unten in diesem Modul.

Herstellen der Verbindung zu SQL Server mithilfe der Windows-Authentifizierung

So stellen Sie die Verbindung zu SQL Server mithilfe der Windows-Authentifizierung her

  • Verwenden Sie in der Clientanwendung eine Verbindungszeichenfolge, die entweder "Trusted_Connection=Yes" oder "Integrierte Sicherheit=SSPI" enthält. Die beiden Zeichenfolgen sind äquivalent und führen beide zur Windows-Authentifizierung (vorausgesetzt, SQL Server ist für die Windows-Authentifizierung konfiguriert). Beispiel:

    SqlConnection conn = new SqlConnection(
          "server=YourServer; database=YourDatabase;" +
          "Trusted_Connection=Yes;");

    – oder –

    SqlConnection conn = new SqlConnection(
          "server=YourServer; database=YourDatabase;" +
          "Integrierte Sicherheit=SSPI;");

    Hinweis: Die Identität des Clients, der die Anforderung erstellt (d. h. der von SQL Server authentifizierte Client), wird vom Threadidentitätswechseltoken (wenn der Thread momentan den Identitätswechsel durchführt) oder vom Prozesstoken des Clients bestimmt.

Verwenden von festen Identitäten in ASP.NET

Bei diesem Ansatz konfigurieren Sie Ihre ASP.NET-Anwendung so, dass für eine angegebene, feste Identität ein Identitätswechsel durchgeführt wird, indem das <identity>-Element in der Datei Web.config verwendet wird. Im folgenden Beispiel wird das <identity>-Element dargestellt. Die Anmeldeinformationen werden hierbei mithilfe von aspnet_setreg.exe in der Registrierung verschlüsselt (siehe Modul 8, "ASP.NET-Sicherheit"). 

<identity
   impersonate="true"
   userName="registry:HKLM\SOFTWARE\YourSecureApp\
             identity\ASPNET_SETREG,userName"
   password="registry:HKLM\SOFTWARE\YourSecureApp\
             identity\ASPNET_SETREG,password" />

Dies wird zur Standardidentität, die beim Herstellen der Verbindung zu Netzwerkressourcen (einschließlich Datenbanken) verwendet wird.

Der Identitätswechsel zu festen Identitäten wird nicht empfohlen, wenn das .NET Framework 1.0 auf Servern unter Windows 2000 installiert ist. In diesem Fall müssten Sie dem ASP.NET-Prozesskonto das weitreichende Recht Als Teil des Betriebssystems handeln erteilen. Dieses Recht wird vom ASP.NET-Prozess benötigt, da er anhand der von Ihnen angegebenen Anmeldeinformationen einen LogonUser-Aufruf ausführt.

Hinweis: Bei Microsoft Windows .NET Server 2003 wird das Recht Als Teil des Betriebssystems handeln nicht für LogonUser -Aufrufe benötigt.

.NET Framework Version 1.1 stellt außerdem für dieses Szenario unter Windows 2000 eine Erweiterung bereit. Die Anmeldung wird vom IIS-Prozess durchgeführt, damit ASP.NET das Recht Als Teil des Betriebssystems handeln nicht erfordert.

Weitere Informationen zu diesem weitreichenden Recht finden Sie in der Spalte "Security Briefs" in der Ausgabe von August 1999 des Microsoft Systems Journal (http://www.microsoft.com/msj/0899/security/security0899.aspx, englisch).

.NET Framework Version 1.1 stellt für dieses Szenario unter Windows 2000 eine Erweiterung bereit. Die Anmeldung wird vom IIS-Prozess durchgeführt, damit ASP.NET das Recht Als Teil des Betriebssystems handeln nicht erfordert.

Verwenden von Serviced Components

Sie können eine spezielle Serviced Component entwickeln, die Datenzugriffscode enthält. Bei Serviced Components können Sie auf die Datenbank entweder über das Hosting der Komponente in einer Enterprise Services-(COM+-)Serveranwendung zugreifen, die unter einer bestimmten Identität ausgeführt wird, oder Sie können Code einfügen, der die API LogonUser verwendet, um den Identitätswechsel durchzuführen.

Prozessexterne Serviced Components erhöhen die Sicherheit, da die Prozesshops Angreifern die Arbeit erschweren, insbesondere wenn die Prozesse mit verschiedenen Identitäten ausgeführt werden. Der zweite Vorteil ist, dass Sie Code isolieren können, der vom Rest der Anwendung weitere Rechte erfordert.

Aufrufen von "LogonUser" und Durchführen des Identitätswechsels für eine bestimmte Windows-Identität

Rufen Sie LogonUser nicht direkt über ASP.NET auf. Unter Windows 2000 erfordert dieser Ansatz, dass Sie der ASP.NET-Prozessidentität das Recht Als Teil des Betriebssystems handeln erteilen.

Ein bevorzugter Ansatz besteht darin, LogonUser außerhalb des ASP.NET-Prozesses aufzurufen, indem Sie eine Serviced Component in einer Enterprise Services-Serveranwendung verwenden, wie bereits erläutert.

Verwenden der Identität des ursprünglichen Benutzers

Damit dieser Ansatz funktioniert, müssen Sie die Kerberos-Delegierung verwenden und für den Benutzer einen Identitätswechsel für die Datenbank durchführen, entweder direkt über ASP.NET oder über eine Serviced Component.

Fügen Sie Folgendes über ASP.NET zu der Datei Web.config Ihrer Anwendung hinzu.

<identity impersonate="true" />

Rufen Sie CoImpersonateClient über eine Serviced Component auf. Weitere Informationen zur Verwendung von CoImpersonateClient finden Sie in Modul 9, "Enterprise Services-Sicherheit".

Verwenden des anonymen Internetbenutzerkontos

Als Varianten des vorherigen Ansatzes können Sie für Szenarios, in denen Ihre Anwendung die Formular- oder Passport-Authentifizierung verwendet (impliziert die anonyme IIS-Authentifizierung), den Identitätswechsel in der Datei Web.config der Anwendung aktivieren, um das anonyme Internetbenutzerkonto für den Datenzugriff zu verwenden.

<identity impersonate="true" />

Wenn IIS für die anonyme Authentifizierung konfiguriert ist, führt diese Konfiguration dazu, dass der Code der Webanwendung über den Identitätswechseltoken des anonymen Internetbenutzers ausgeführt wird. In einer Webhostumgebung hat dies den Vorteil, dass Sie den Datenbankzugriff mehrerer Webanwendungen einzeln überwachen und nachverfolgen können.

Weitere Informationen

  • Weitere Informationen und Implementierungsdetails zum Verwenden der Identität des ursprünglichen Benutzers finden Sie unter "Übermitteln des ursprünglichen Benutzers an die Datenbank" in Modul 5, "Intranetsicherheit".

  • Weitere Informationen zum Konfigurieren von IIS für die Verwendung des anonymen Benutzerkontos finden Sie in Modul 8, "ASP.NET-Sicherheit."

Wann kann die Windows-Authentifizierung nicht verwendet werden?

Bestimmte Anwendungsszenarios verhindern möglicherweise die Windows-Authentifizierung. Beispiel:

  • Datenbankclient und Datenbankserver sind durch eine Firewall getrennt, die eine Windows-Authentifizierung verhindert.

  • Die Anwendung muss eine Verbindung zu einer oder mehreren Datenbanken herstellen, wobei mehrere Identitäten verwendet werden.

  • Sie stellen die Verbindung zu Datenbanken her, bei denen es sich nicht um SQL Server handelt.

  • Sie verfügen in ASP.NET nicht über eine sichere Möglichkeit, Code als ein bestimmter Windows-Benutzer auszuführen. Entweder Sie können (oder möchten) den Sicherheitskontext des ursprünglichen Benutzers nicht weiterleiten, oder Sie möchten eher ein dediziertes Dienstkonto verwenden, anstatt Endbenutzern Anmeldungen zu gewähren.

In diesen Szenarios müssen Sie die SQL-Authentifizierung verwenden (oder den eigenen Authentifizierungsmechanismus der Datenbank) und die folgenden Schritte durchführen:

  • Schützen der Datenbank-Benutzeranmeldeinformationen auf dem Anwendungsserver.

  • Schützen der Datenbank-Benutzeranmeldeinformationen, während diese vom Server zur Datenbank übertragen werden.

Wenn Sie die SQL-Authentifizierung verwenden, gibt es zahlreiche Möglichkeiten, wie Sie die SQL-Authentifizierung sicherer gestalten können. Diese werden im nächsten Abschnitt hervorgehoben.

SQL-Authentifizierung

Wenn Ihre Anwendung die SQL-Authentifizierung verwenden muss, sollten Sie die folgenden wichtigen Punkte berücksichtigen:

  • Verwenden Sie ein Konto mit minimalen Rechten, um die Verbindung zu SQL herzustellen.

  • Die Anmeldeinformationen werden über das Netzwerk gesendet, deshalb müssen sie gesichert werden.

  • Die SQL-Verbindungszeichenfolge (die Anmeldeinformationen enthält) muss gesichert werden.

Typen von Verbindungszeichenfolgen

Wenn Sie die Verbindung zu einer SQL Server-Datenbank mithilfe von Anmeldeinformationen (Benutzername und Kennwort) herstellen, sieht die Zeichenfolge folgendermaßen aus:

Using the SQL Server .NET Data Provider:
SqlConnection conn = new SqlConnection(
          "server=YourServer; uid=YourUserName; pwd=YourStrongPwd;" +
          "database=YourDatabase");

Using the OLE DB .NET Data Provider:
OleDbConnection conn = new OleDbConnection(
          "Provider=SQLOLEDB; Data Source=YourServer;" +
          "uid=YourUserName; pwd=YourStrongPwd; Initial Catalog=YourDatabase");

Wenn Sie die Verbindung zu einer speziellen Instanz von SQL Server ausführen müssen, die auf demselben Computer installiert ist (diese Feature ist nur in SQL Server 2000 oder höher verfügbar), sieht die Zeichenfolge folgendermaßen aus:

Using the SQL Server .NET Data Provider:
SqlConnection conn = new SqlConnection(
          "server=YourServer\Instance; uid=YourUserName; pwd=YourStrongPwd;" +
          "database=YourDatabase");

Wenn Sie die Verbindung zu einer Oracle-Datenbank mithilfe expliziter Anmeldeinformationen (Benutzername und Kennwort) herstellen, sieht die Zeichenfolge folgendermaßen aus:

OleDbConnection conn = new OleDbConnection(
          "Provider=MSDAORA; Data Source=YourDatabaseAlias;" +
          "User ID=YourUserName; Password=YourStrongPwd;");

Weitere Informationen

Weitere Informationen zum Verwenden von UDL-Dateien (Universal Data Link) für Verbindungen finden Sie in der Microsoft Knowledge Base im Artikel 308426, "SO WIRD'S GEMACHT: Verwendung von Datenverknüpfungsdateien für das OleDbConnection-Objekt in Visual C# .NET".

Auswählen eines SQL-Kontos für Verbindungen

Verwenden Sie für den Datenzugriff nicht das integrierte Konto sa und kein anderes Mitglied der festen Serverrolle sysadmin von SQL Server oder der festen Datenbankrolle db_owner. Mitglieder von sysadmin können jede beliebige Aktion in SQL Server ausführen. Mitglieder von db_owner besitzen uneingeschränkte Rechte für die Datenbank. Verwenden Sie stattdessen Konten mit minimalen Rechten, jedoch sicherem Kennwort.

Vermeiden Sie die folgende Verbindungszeichenfolge:

SqlConnectionString = "Server=YourServer\Instance;
                       Database=YourDatabase; uid=sa; pwd=;"

Verwenden Sie Konten mit minimalen Rechten, jedoch mit sicherem Kennwort. Beispiel:

SqlConnectionString= "Server=YourServer\Instance;
                      Database=YourDatabase;
                      uid=YourStrongAccount; 
                      pwd=YourStrongPassword;"

Beachten Sie, dass dies nicht das Problem des unverschlüsselten Speicherns der Anmeldeinformationen in den Web.config-Dateien löst. Sie haben bis jetzt nur das Schadensausmaß eingeschränkt, das im Fall eines erfolgreichen Angriffs eintreten könnte, indem Sie ein Konto mit minimalen Rechten verwenden. Wenn Sie die Sicherheit weiter erhöhen möchten, sollten Sie die Anmeldeinformationen verschlüsseln.

Hinweis: Wenn Sie bei der Installation von SQL Server eine Sortierreihenfolge gewählt haben, bei der zwischen Groß- und Kleinschreibung unterschieden wird, wird bei Ihrer Anmelde-ID ebenfalls zwischen Groß- und Kleinschreibung unterschieden.

Übergeben von Anmeldeinformationen über das Netzwerk

Wenn Sie die Verbindung zum SQL Server über die SQL-Authentifizierung herstellen, werden der Benutzername und das Kennwort unverschlüsselt über das Netzwerk übertragen. Dies kann sich als erhebliches Sicherheitsproblem erweisen. Weitere Informationen zum Sichern des Kanals zwischen einer Anwendung oder einem Webserver und einem Datenbankserver finden Sie unter "Sichere Kommunikation" weiter unten in diesem Modul.

Sichern von SQL-Verbindungszeichenfolgen

Benutzernamen und Kennwörter sollten in Konfigurationsdateien nicht unverschlüsselt gespeichert werden. Weitere Informationen zum sicheren Speichern von Verbindungszeichenfolgen finden Sie unter "Sicheres Speichern von Datenbank-Verbindungszeichenfolgen" weiter unten in diesem Modul.

Authentifizieren anhand von Nicht-SQL Server-Datenbanken

Ein typisches Problem, das beim Herstellen der Verbindung zu Datenbanken auftreten kann, die nicht auf SQL basieren, ist mit Szenarien vergleichbar, in denen Sie die SQL-Authentifizierung verwenden müssen. Sie müssen möglicherweise explizite Anmeldeinformationen bereitstellen, wenn die Zielressourcen die Windows-Authentifizierung nicht unterstützen. Um diese Art von Szenario zu sichern, müssen Sie die Verbindungszeichenfolge sicher verwahren und auch die Kommunikation über das Netzwerk sichern (um das Abfangen von Anmeldeinformationen zu verhindern).

Autorisierung

SQL Server bietet für die Autorisierung eine Reihe von rollenbasierten Ansätzen. Diese stehen mit folgenden drei Rollenarten des SQL Servers in Zusammenhang:

  • Benutzerdefinierte Datenbankrollen. Diese Rollen werden dazu verwendet, um Benutzer mit den gleichen Berechtigungen in der Datenbank zu gruppieren. Sie erstellen SQL Server-Benutzernamen und ordnen sie bestimmten Datenbankbenutzern zu. Mit den Rollen fügen Sie anschließend die Datenbankbenutzer zu Datenbankrollen hinzu und richten Berechtigungen für einzelne Datenbankobjekte ein (gespeicherte Prozeduren, Tabellen, Ansichten usw.).

  • Anwendungsrollen. Diese Rollen sind insofern mit Benutzerdatenbankrollen vergleichbar, als sie beim Einrichten von Objektberechtigungen verwendet werden. Im Gegensatz zu diesen enthalten sie jedoch keine Benutzer oder Gruppen. Stattdessen müssen sie durch eine Anwendung mithilfe einer integrierten gespeicherten Prozedur aktiviert werden. Nach der Aktivierung bestimmen die der Rolle erteilten Berechtigungen die Möglichkeiten der Anwendung für den Datenzugriff.
    Anwendungsrollen ermöglichen es Datenbankadministratoren, ausgewählten Anwendungen den Zugriff auf angegebene Datenbanken zu gewähren. Dies ist etwas anderes als das Erteilen von Berechtigungen für Benutzer.

  • Feste Datenbankrollen SQL Server bietet auch feste Serverrollen, z. B. db_datareader und db_datawriter. Diese integrierten Rollen sind in allen Datenbanken enthalten und können verwendet werden, um einem Benutzer schnell eine Reihe von auf den Lesevorgang bezogenen (und andere häufig verwendete) Berechtigungen in der Datenbank zu erteilen.

Weitere Informationen zu diesen verschiedenen Rollenarten (sowie zu festen Serverrollen, die mit festen Datenbankrollen vergleichbar sind, jedoch auf der Server- und nicht auf der Datenbankebene angewendet werden) finden Sie in der Onlinedokumentation zu SQL Server (http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp, englisch).

Verwenden mehrerer Datenbankrollen

Wenn Ihre Anwendung über verschiedene Benutzerkategorien verfügt und die Benutzer in den einzelnen Kategorien dieselben Berechtigungen in der Datenbank erfordern, muss die Anwendung mehrere Rollen verwenden. Für jede Rolle muss ein anderer Berechtigungssatz in der Datenbank erstellt werden. Mitglieder der Rolle "Internetbenutzer" benötigen möglicherweise die Berechtigung für den Lesezugriff auf die meisten Tabellen in der Datenbank, während Mitglieder der Rolle "Administrator" oder "Operator" vermutlich Berechtigungen zum Lesen und zum Schreiben benötigen.

In diesem Szenario können Sie mehrere benutzerdefinierte SQL Server-Datenbankrollen verwenden. Diese Rollen werden dazu verwendet, Berechtigungen für den Zugriff auf Datenbankobjekte an Benutzergruppen zu verteilen, die innerhalb der Datenbank über dieselben Sicherheitsberechtigungen verfügen. Bei diesem Ansatz führen Sie Folgendes durch:

  • Erstellen mehrerer Dienstkonten für den Datenbankzugriff.

  • Erstellen eines SQL Server-Benutzernamens für die einzelnen Konten.

  • Erstellen von Datenbankbenutzern, um den Anmeldezugriff auf die Datenbank zu erteilen.

  • Hinzufügen der einzelnen Datenbankbenutzer zu einer benutzerdefinierten Datenbankrolle.

  • Einrichten der erforderlichen Datenbankberechtigungen für jede Rolle in der Datenbank.

  • Autorisieren der Benutzer in Ihrer Anwendung (ASP.NET-Webanwendung, Webdienst oder Komponente der mittleren Ebene) und anschließendes Verwenden der Anwendungslogik auf der Datenzugriffsebene, um zu ermitteln, mit welchem Konto die Verbindung zur Datenbank hergestellt wird. Dies basiert auf der Rollenmitgliedschaft des Benutzers.
    Sie können einzelne Methoden deklarativ konfigurieren, um nur die Benutzer zuzulassen, die einer Reihe von Rollen angehören. Dann fügen Sie die imperativen Rollenüberprüfungen im Methodencode hinzu, um die genaue Rollenmitgliedschaft zu ermitteln, die die zu verwendende Verbindung bestimmt.

Abbildung 12.4 veranschaulicht diesen Ansatz.

Herstellen der Verbindung zu SQL Server über mehrere SQL-Benutzerdatenbankrollen

Abbildung 12.4
Herstellen der Verbindung zu SQL Server unter Verwendung mehrerer SQL-Benutzerdatenbankrollen

Damit Sie die bevorzugte Windows-Authentifizierung für dieses Szenario verwenden können, entwickeln Sie Code (mithilfe der API LogonUser ) in einer "Out of Process"-Serviced Component, um einen Identitätswechsel für eine der Windows-Identitäten durchzuführen.

Bei der SQL-Authentifizierung verwenden Sie eine andere Verbindungszeichenfolge (die verschiedene Benutzernamen und Kennwörter enthält), die von der rollenbasierten Logik in Ihrer Anwendung abhängt.

Sichere Kommunikation

In den meisten Anwendungsszenarien müssen Sie die Kommunikationsverbindung zwischen dem Anwendungsserver und der Datenbank sichern. Sie müssen Folgendes sicherstellen:

  • Vertraulichkeit von Nachrichten – Die Daten müssen verschlüsselt werden, damit sie nicht unberechtigt eingesehen werden können.

  • Integrität von Nachrichten – Die Daten müssen signiert werden, damit sie nicht geändert werden können.

In einigen Szenarien müssen alle zwischen dem Anwendungsserver und dem Datenbankserver übertragenen Daten gesichert werden, während in anderen Szenarien nur ausgewählte Datenelemente, die über bestimmte Verbindungen gesendet werden, gesichert werden müssen. Beispiel:

  • In einer Intranetanwendung der Personalabteilung sind einige der Mitarbeiterdaten vertraulich, die zwischen dem Client und dem Datenbankserver übergeben werden.

  • In Internetszenarios (z. B. sichere Bankanwendungen) sind alle zwischen dem Anwendungsserver und dem Datenbankserver übergebenen Daten vertraulich und müssen gesichert werden.

  • Wenn Sie die SQL-Authentifizierung verwenden, sollten Sie auch die Kommunikationsverbindung sichern, um sicherzustellen, dass Benutzernamen und Kennwörter nicht mithilfe von Software zur Netzwerküberwachung unberechtigt abgerufen werden können.

Optionen

Es stehen zwei Optionen zum Sichern der Netzwerkverbindung zwischen einem Anwendungsserver und dem Datenbankserver zur Verfügung:

  • IPSec

  • SSL (mithilfe eines Serverzertifikats auf dem SQL Server-Computer)

    Hinweis: Sie müssen SQL Server 2000 ausführen, um SSL zu unterstützen. Frühere Versionen unterstützten SSL nicht. Auf dem Client müssen die Clientbibliotheken von SQL Server 2000 installiert sein.

Auswahl eines Ansatzes

Ob Sie IPSec oder SSL verwenden, hängt von einer Reihe wichtiger Umgebungsfaktoren ab, z. B. von der Firewall, von der Version des Betriebssystems und von Datenbanken usw.

Hinweis: IPSec soll nicht die Sicherheit auf Anwendungsebene ersetzen, sondern wird heute als Tiefenverteidigungsmechanismus oder zum Sichern unsicherer Anwendungen verwendet, ohne diese zu ändern, sowie zum Sichern von anderen Protokollen als TLS (z. B. SSL) vor Angriffen aus dem Netzwerk.

Weitere Informationen

  • Weitere Informationen zum Konfigurieren von IPSec finden Sie unter "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern" in diesem Handbuch.

  • Weitere Informationen zum Konfigurieren von SSL finden Sie unter "Vorgehensweise: Verwenden von SSL zum Sichern der Kommunikation mit SQL Server 2000" in diesem Handbuch.

  • Weitere allgemeine Informationen zu SSL und IPSec erhalten Sie in Modul 4, "Sichere Kommunikation".

Herstellen der Verbindung mit minimalen Rechten

Die Verbindung zur Datenbank mit minimalem Recht bedeutet, dass die von Ihnen eingerichtete Verbindung nur über die minimalen Rechte verfügt, die Sie in der Datenbank benötigen. Einfacher ausgedrückt: Sie verwenden zum Herstellen der Verbindung zur Datenbank nicht das Konto sa, keine Mitglieder der Rolle sysadmin und keine Mitglieder der Rolle db_owner. Idealerweise kann das für die Verbindung (die zu einer Identität zusammengefasst werden kann, die eine bestimmte Rolle darstellt) verwendete Konto keine Datensätze in der Datenbank hinzufügen oder aktualisieren, wenn der aktuelle Benutzer nicht dazu autorisiert ist.

Wenn Sie die Verbindung zu SQL Server herstellen, muss der von Ihnen gewählte Ansatz die Feinstufigkeit unterstützen, die Ihre Datenbankautorisierung erfordert. Sie müssen bedenken, wem die Datenbank vertrauen kann. Sie kann Folgendem vertrauen:

  • Der Anwendung

  • Den anwendungsdefinierten Rollen

  • Dem ursprünglichen Benutzer

Die Datenbank vertraut der Webanwendung

Denken Sie z. B. an eine Finanzanwendung, die Sie mit Ihrer Datenbank autorisieren. Die Finanzanwendung dient zum Verwalten der Benutzerauthentifizierung und dem Autorisieren des Zugriffs. In diesem Fall verwalten Sie Ihre Verbindungen über ein einzelnes vertrauenswürdiges Konto (das entweder einem SQL Server-Benutzernamen entspricht oder einem Windows-Konto, das einem SQL Server-Benutzernamen zugeordnet ist). Wenn Sie die Windows-Authentifizierung verwenden, bedeutet das normalerweise, dass die Prozessidentität der aufrufenden Anwendung (z. B. der ASP.NET-Workerprozess oder die Identität einer Enterprise Services-Serveranwendung) die Möglichkeit erhält, auf die Datenbank zuzugreifen.

Was die Autorisierung anbelangt, ist dieser Ansatz sehr grobstufig, da die Verbindung als Identität ausgeführt wird, die über den Zugriff auf alle von der Anwendung benötigten Datenbankobjekte und Ressourcen verfügt. Die Vorteile dieses Ansatzes liegen darin, dass Sie das Verbindungspooling verwenden und die Verwaltung vereinfachen können, da Sie nur ein einzelnes Konto autorisieren. Der Nachteil ist, dass alle Benutzer mit denselben Verbindungsrechten ausgestattet werden.

Die Datenbank vertraut verschiedenen Rollen

Sie können Pools aus separaten, vertrauenswürdigen Verbindungen zur Datenbank verwenden, die den von der Anwendung definierten Rollen entsprechen, z. B. eine Verbindung für Kassierer, eine weitere für Manager usw.

Diesen Verbindungen steht es frei, die Windows-Authentifizierung zu verwenden. Der Vorteil der Windows-Authentifizierung ist, dass sie die Verwaltung der Anmeldeinformationen übernimmt und diese nicht über das Netzwerk sendet. Während jedoch die Windows-Authentifizierung auf der Prozess- oder Anwendungsebene möglich ist, entstehen aufgrund der Tatsache, dass Sie mehrere Identitäten verwenden müssen (eine pro Rolle), weitere Herausforderungen.

Viele Anwendungen verwenden die API LogonUser , um ein Windows-Zugriffstoken auf Threadebene zum Einrichten eines Sicherheitskontexts zu erstellen. Dabei entstehen Probleme bei der Verwaltung der Anmeldeinformationen, da die Anwendung den Benutzernamen und das Kennwort für das Konto sicher speichern muss. Darüber hinaus treten Probleme bei der Rechtevergabe auf, da dem Prozesskonto das weit reichende Recht Als Teil des Betriebssystems handeln erteilt werden muss.

Auch bei Anwendungen, die die SQL-Authentifizierung verwenden, gibt es Probleme mit der Verwaltung der Anmeldeinformationen. Außerdem ist hier zum Schutz der Anmeldeinformationen ein sicherer Kommunikationskanal zur Datenbank erforderlich.

Die Datenbank vertraut dem ursprünglichen Benutzer

In diesem Fall müssen Sie den ursprünglichen Benutzer über mehrere Ebenen an die Datenbank übermitteln. Das bedeutet, dass Ihre Clients Netzwerkanmeldeinformationen besitzen müssen, damit sie von einem Computer zum nächsten gelangen können. Dazu ist die Kerberos-Delegierung erforderlich.

Obwohl diese Lösung eine feinstufige Autorisierung in der Datenbank bietet, da Ihnen die Identität des ursprünglichen Benutzers bekannt ist und Sie für Datenbankobjekte Berechtigungen auf Benutzerbasis einrichten können, wirkt sie sich nicht auf die Leistung und Skalierbarkeit der Anwendung aus. Das Verbindungspooling (obwohl weiterhin aktiv) wird unwirksam.

Erstellen eines Datenbankkontos mit minimalen Rechten

In den folgenden Schritten wird ein Datenbankkonto mit minimalen Rechten erstellt. Während die meisten Datenbankadministratoren bereits mit diesen Schritten vertraut sind, ist dies bei vielen Entwicklern nicht der Fall, die dann möglicherweise auf das Konto sa zurückgreifen, damit ihre Anwendungen funktionieren.

Dies kann bei einem Wechsel von einer Entwicklungsumgebung zu einer Testumgebung und dem anschließenden Wechsel zu einer Produktionsumgebung zu Problemen führen, da die Anwendung aus einer frei zugänglichen Umgebung in eine umfassender kontrollierte Umgebung gelangt und dann möglicherweise nicht mehr ordnungsgemäß funktioniert.

Sie beginnen mit dem Erstellen eines SQL Server-Benutzernamens entweder für ein SQL-Konto oder für ein Windows-Konto (Benutzer oder Gruppe). Anschließend erteilen Sie dem Benutzernamen Zugriff auf eine Datenbank, indem Sie einen Datenbankbenutzer erstellen, den Datenbankbenutzer zu einer Datenbankbenutzerrolle hinzufügen und der Rolle dann Berechtigungen zuordnen.

  • So richten Sie ein Datenzugriffskonto für SQL ein

    1. Erstellen Sie ein neues Windows-Benutzerkonto und fügen Sie es einer Windows-Gruppe hinzu. Wenn Sie mehrere Benutzer verwalten, verwenden Sie eine Gruppe. Wenn Sie ein einzelnes Anwendungskonto verwenden (z. B. ein dupliziertes ASP.NET-Prozesskonto), fügen Sie das Konto möglicherweise nicht zu einer Windows-Gruppe hinzu.

    2. Erstellen Sie einen SQL Server-Benutzernamen für die Benutzer bzw. für die Gruppe.

      1. Starten Sie den Enterprise Manager, suchen Sie dort Ihren Datenbankserver und erweitern Sie dann den Ordner Sicherheit.

      2. Klicken Sie mit der rechten Maustaste auf Benutzernamen und dann auf Neuer Benutzername.

      3. Geben Sie den Windows-Kontonamen in das Feld Name ein und klicken Sie dann auf OK, um das Dialogfeld SQL Server-Anmeldungseigenschaften zu schließen.

    3. Erstellen Sie in der gewünschten Datenbank einen neuen Datenbankbenutzer, der dem SQL Server-Benutzernamen für den Zugriff auf die Datenbank zugeordnet ist.

      1. Verwenden Sie den Enterprise Manager und erweitern Sie den Ordner Datenbanken. Erweitern Sie dann die gewünschte Datenbank, für die der Benutzername den Zugriff erfordert.

      2. Klicken Sie mit der rechten Maustaste auf Benutzer und dann auf Neuer Datenbankbenutzer.

      3. Wählen Sie den zuvor erstellten Anmeldenamen aus.

      4. Geben Sie einen Benutzernamen ein.

    4. Erstellen Sie eine neue Datenbankrolle, der Berechtigungen zugewiesen werden.

      1. Klicken Sie unter dem Ordner Datenbanken mit der rechten Maustaste auf Rollen und dann auf Neue Datenbankrolle.

      2. Geben Sie einen Rollennamen ein.

      3. Klicken Sie auf Hinzufügen, um den Datenbankbenutzer zur Rolle hinzuzufügen.

      4. Konfigurieren Sie die Berechtigungen wie nachfolgend beschrieben.

    5. Erteilen Sie dem Datenbankbenutzer Select-Berechtigungen für die Tabellen, auf die er zugreifen muss, und Execute-Berechtigungen für relevante gespeicherte Prozeduren.

      Hinweis: Wenn die gespeicherte Prozedur und die Tabelle Eigentum derselben Person sind und der Zugriff auf die Tabelle nur über die gespeicherte Prozedur erfolgt (und kein Zugriff auf die Tabelle erforderlich ist), reicht es aus, wenn Sie nur der gespeicherten Prozedur Ausführungsberechtigungen erteilen. Der Grund hierfür liegt im Konzept der Besitzerkettung. Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation.

    6. Wenn das Benutzerkonto auf alle Ansichten und Tabellen der Datenbank zugreifen soll, fügen Sie es zur festen Datenbankrolle db_datareader hinzu.

      Hinweis: In jeder Datenbank, zu der alle übrigen Datenbankbenutzer und Rollen gehören, ist eine public-Rolle vorhanden, die nicht entfernt werden kann. Heben Sie die Berechtigungen zu dieser Rolle auf oder verweigern Sie sie, so dass die Autorisierung ausschließlich durch die Berechtigungen festgelegt wird, die der benutzerdefinierten Datenbankrolle zugeordnet sind.

Sicheres Speichern von Datenbank-Verbindungszeichenfolgen

Es gibt eine Reihe möglicher Speicherorte und Verfahren zum Speichern von Datenbank-Verbindungszeichenfolgen, wobei diese hinsichtlich der Sicherheit und der Flexibilität der Konfiguration variieren.

Optionen

In der folgenden Liste werden die wichtigsten Optionen zum Speichern von Verbindungszeichenfolgen aufgeführt:

  • Verschlüsselung mit DPAPI

  • Unverschlüsselt in der Datei Web.config oder Machine.config

  • UDL-Dateien

  • Benutzerdefinierte Textdateien

  • Registrierung

  • COM+-Katalog

Verwenden von DPAPI

Mit Windows 2000 und den neueren Betriebssystemen wurde die Win32® Data Protection API (DPAPI) für das Ver- und Entschlüsseln von Daten eingeführt. DPAPI ist Teil der Cryptography API (Crypto API) und in Crypt32.dll implementiert. Die Schnittstelle besteht aus zwei Methoden: CryptProtectData und CryptUnprotectData.

Die DPAPI ist insofern besonders nützlich, als sich hiermit das Schlüsselverwaltungsproblem erübrigt, das ansonsten mit Anwendungen einhergeht, die Kryptografie einsetzen. Mit der Verschlüsselung können Daten zwar gesichert werden, es müssen jedoch weitere Schritte unternommen werden, um auch die Sicherheit des Schlüssels zu gewährleisten. Die DPAPI verwendet das Kennwort des Benutzerkontos, das die DPAPI-Funktionen aufruft, um den Verschlüsselungsschlüssel abzuleiten. Damit verwaltet das Betriebssystem und nicht die Anwendung den Schlüssel.

Warum nicht LSA?

Viele Anwendungen verwenden die LSA (Local Security Authority) zum Speichern von vertraulichen Daten. DPAPI besitzt gegenüber dem LSA-Ansatz die folgenden Vorteile:

  • Damit ein Prozess die LSA verwenden kann, muss er Administratorrechte besitzen. Das lässt hinsichtlich der Sicherheit Bedenken aufkommen, da es das Ausmaß des möglichen Schadens drastisch erhöht, der durch einen erfolgreichen Angriff auf den Prozess angerichtet werden kann.

  • Die LSA bietet zum sicheren Speichern nur eine begrenzte Anzahl von Slots, von denen viele bereits vom System verwendet werden.

Computerspeicher im Vergleich zum Benutzerspeicher

Die DPAPI kann entweder mit dem Computerspeicher oder mit dem Benutzerspeicher arbeiten (was ein geladenes Benutzerprofil voraussetzt). Standardmäßig verwendet die DPAPI den Benutzerspeicher, Sie können jedoch auch festlegen, dass der Computerspeicher verwendet werden soll, indem Sie das Flag CRYPTOPROTECT_LOCAL_MACHINE an die DPAPI-Funktionen übergeben.

Mit dem Benutzerprofil wird eine zusätzliche Sicherheitsschicht eingezogen, da es den Zugriff auf die geheimen Daten weiter einschränkt. Nur der Benutzer, der die Daten verschlüsselt, kann sie auch wieder entschlüsseln. Allerdings erfordert das Benutzerprofils zusätzlichen Entwicklungsaufwand, wenn die DPAPI von einer ASP.NET-Anwendung verwendet werden soll, da Sie explizite Schritte zum Laden und Entladen des Benutzerprofils unternehmen müssen.

Der Computerspeicheransatz ist einfacher zu entwickeln, da er keine Benutzerprofilverwaltung voraussetzt. Wird hierbei jedoch kein zusätzlicher Entropieparameter verwendet, ist dieser Ansatz weniger sicher, da jeder Benutzer des Computers Daten entschlüsseln kann. Unter Entropie wird in diesem Zusammenhang ein Zufallswert verstanden, der das Dechiffrieren der Geheimdaten schwieriger macht. Das Problem bei der Verwendung eines zusätzlichen Entropieparameters besteht darin, dass dieser Wert von der Anwendung ebenfalls sicher gespeichert werden muss, woraus sich wiederum ein Schlüsselverwaltungsproblem ergibt.

Hinweis: Wenn Sie die DPAPI mit dem Computerspeicher verwenden, ist die verschlüsselte Zeichenfolge für den jeweiligen Computer spezifisch. Daher sind die verschlüsselten Daten auf jedem Computer zu erzeugen. Sie können die verschlüsselten Daten nicht auf andere Computer in einer Farm oder in einem Cluster kopieren.

Wenn Sie DPAPI mit dem Benutzerspeicher verwenden, können die Daten auf jedem Computer mit einem servergespeicherten Benutzerprofil entschlüsselt werden.

DPAPI-Implementierungslösungen

In diesem Abschnitt werden zwei Implementierungslösungen vorgestellt, die Ihnen zeigen, wie DPAPI von ASP.NET-Webanwendungen verwendet wird, um eine Verbindungszeichenfolge (oder beliebige vertrauliche Daten) zu sichern. Die folgenden Implementierungslösungen werden in diesem Abschnitt beschrieben:

  • Verwenden von DPAPI über Enterprise Services – Diese Lösung ermöglicht es Ihnen, DPAPI mit dem Benutzerspeicher zu verwenden.

  • Direktes Verwenden von DPAPI über APS.NET – Bei dieser Lösung können Sie DPAPI mit dem Computerspeicher verwenden. Dadurch lässt sich diese Lösung einfacher entwickeln, da DPAPI direkt über eine ASP.NET-Webanwendung aufgerufen werden kann.

Verwenden von DPAPI über Enterprise Services –

Eine ASP.NET-Webanwendung kann DPAPI nicht aufrufen und dann den Benutzerspeicher verwenden, da hierzu ein Benutzerprofil geladen sein muss. Das normalerweise zum Ausführen von Webanwendungen verwendete Konto ASPNET ist ein nicht interaktives Konto und verfügt als solches über keine Benutzerprofile. Außerdem wird der Thread der Webanwendung als momentan authentifizierter Benutzer ausgeführt, der sich von einer Anforderung zur nächsten ändern kann, wenn die ASP.NET-Anwendung einen Identitätswechsel durchführt.

Hieraus ergibt sich für eine ASP.NET-Webanwendung, die die DPAPI verwenden soll, die folgende Problemstellung:

  • Aufrufe der DPAPI von einer ASP.NET-Anwendung, die unter dem standardmäßigen ASPNET-Konto ausgeführt wird, schlagen fehl. Der Grund hierfür ist, dass das ASPNET-Konto über keine Benutzerprofile verfügt, da es nicht für interaktive Anmeldungen verwendet wird.

  • Wenn eine ASP.NET-Webanwendung für einen Identitätswechsel ihrer Benutzer konfiguriert ist, verfügt der Thread der ASP.NET-Anwendung über ein zugeordnetes Threadidentitätswechseltoken. Die Anmeldesitzung, die mit diesem Identitätswechseltoken verbunden ist, ist eine Netzwerkanmeldesitzung (die auf dem Server verwendet wird, um den Benutzer zu repräsentieren). Anmeldesitzungen im Netzwerk führen nicht dazu, dass Benutzerprofile geladen werden.

Zur Beseitigung dieses Problems können Sie eine Serviced Component erstellen (in einer prozessexternen Enterprise Services-(COM+-)Serveranwendung), um die DPAPI aufzurufen. Sie können sicherstellen, dass das Konto, mit dem die Komponente ausgeführt wird, ein Benutzerprofil besitzt und Sie zum automatischen Laden des Profils einen Win32-Dienst verwenden können.

Hinweis: Es ist möglich, die Verwendung eines Win32-Dienstes zu vermeiden, indem Aufrufe von Win32-Profilverwaltungsfunktionen (LoadUserProfile und UnloadUserProfile) innerhalb der Serviced Component positioniert werden.

Dieser Ansatz hat zwei Nachteile. Erstens wirken sich Aufrufe dieser APIs auf Anforderungsbasis erheblich auf die Leistung aus. Zweitens erfordern diese APIs, dass der aufrufende Code auf dem lokalen Computer Administratorrechte besitzt, wodurch das Prinzip der minimalen Rechte für das Enterprise Services-Prozesskonto nicht befolgt wird.

Abbildung 12.5 zeigt die Enterprise Services DPAPI-Lösung.

Die ASP.NET Webanwendung verwendet eine COM+-Serveranwendung für die Interaktion mit der DPAPI.

Abbildung 12.5
Die ASP.NET Webanwendung verwendet eine COM+-Serveranwendung für die Interaktion mit der DPAPI.

Nachstehend die Abfolge der Ereignisse wie in Abbildung 12.5:

  1. Der Dienststeuerungs-Manager von Windows startet den Win32-Dienst und lädt automatisch das Benutzerprofil, das mit dem Konto verbunden ist, unter dem der Dienst ausgeführt wird. Unter demselbenWindows-Konto wird auch die Enterprise Services-Anwendung ausgeführt.

  2. Der Win32-Dienst ruft eine Startmethode für die Serviced Component auf, mit der die Enterprise Services-Anwendung gestartet und die Serviced Component geladen wird.

  3. Die Webanwendung ruft die verschlüsselte Zeichenfolge aus der Datei Web.config ab.
    Sie können die verschlüsselte Zeichenfolge mithilfe des Elements <appSettings> in der Datei Web.config speichern (wie unten gezeigt). Dieses Element unterstützt beliebige Paare aus Schlüssel und Wert.

    <configuration>
 <appSettings>
  <add key="SqlConnString"
       value="AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAABcqc/xCHxki3" />
 </appSettings>
</configuration>

    Sie können die verschlüsselte Zeichenfolge über die folgende Codezeile abrufen:

    string connString = ConfigurationSettings.AppSettings["SqlConnString"];

    Hinweis: Sie können die verschlüsselten Verbindungszeichenfolgen in der Datei Web.config oder Machine.config speichern. Die Datei Machine.config wird dabei bevorzugt, da sie sich in einem Systemverzeichnis außerhalb eines virtuellen Verzeichnisses befindet. Dies wird eingehender im nächsten Abschnitt, "Verwenden der Dateien Web.config und Machine.config", erläutert.

  4. Die Anwendung ruft eine Methode für die Serviced Component auf, um die Verbindungszeichenfolge zu entschlüsseln.

  5. Die Serviced Component arbeitet mit der DPAPI zusammen, um mit P/Invoke die Win32-DPAPI-Funktionen aufzurufen.

  6. Die entschlüsselte Zeichenfolge wird an die Webanwendung zurückgegeben.

Hinweis: Um verschlüsselte Verbindungszeichenfolgen in der Datei Web.config an erster Stelle speichern zu können, schreiben Sie zum Abrufen der verschlüsselten Zeichenfolge eine Hilfsanwendung, die die Verbindungszeichenfolgen übernimmt und die EncryptData -Methode der Serviced Component aufruft. Es ist von wesentlicher Bedeutung, dass Sie diese Hilfsanwendung ausführen, während Sie mit demselben Konto angemeldet sind, das Sie zum Ausführen der Enterprise Services-Serveranwendung verwenden.

Direktes Verwenden von DPAPI über APS.NET

Wenn Sie den Computerspeicher verwenden und die DPAPI-Funktionen mit dem Parameter CRYPTPROTECT_LOCAL_MACHINE aufrufen, können Sie DPAPI-Funktionen direkt über eine ASP.NET-Webanwendung starten (da hierzu kein Benutzerprofil erforderlich ist).

Da Sie den Computerspeicher verwenden, besitzt jedoch jedes Windows-Konto, das sich auf diesem Computer anmelden kann, Zugriff auf die vertraulichen Daten. Ein Ansatz zur Risikominderung ist das Hinzufügen der Entropie, wodurch jedoch die zusätzliche Schlüsselverwaltung erforderlich wird.

Erwägen Sie die folgenden Optionen als Alternativen zur Entropie mit dem Computerspeicher:

  • Verwenden Sie Windows-ACLs, um den Zugriff auf verschlüsselte Daten einzuschränken (unabhängig davon, ob die Daten im Dateisystem oder in der Registrierung gespeichert sind).

  • Erwägen Sie die feste Kodierung des Entropieparameters in der Anwendung, um das Problem der Schlüsselverwaltung zu vermeiden.

Weitere Informationen

  • Weitere Informationen zum Erstellen einer DPAPI-Bibliothek zur Verwendung mit .NET-Webanwendungen finden Sie unter "Vorgehensweise: Erstellen einer DPAPI-Bibliothek" in diesem Handbuch.

  • Eine detaillierte Führung durch die Implementierung, die Ihnen zeigt, wie DPAPI direkt über ASP.NET verwendet wird, finden Sie unter "Vorgehensweise: Verwenden von DPAPI (Computerspeicher) von ASP.NET aus" in diesem Handbuch.

  • Eine detaillierte Führung durch die Implementierung, die Ihnen zeigt, wie DPAPI direkt über Enterprise Services verwendet wird, finden Sie unter "Vorgehensweise: Verwenden von DPAPI (Benutzerspeicher) von ASP.NET aus mit Enterprise Services" in diesem Handbuch.

  • Weitere Informationen zum Windows-Datenschutz mit DPAPI finden Sie in MSDN im Artikel "Windows Data Protection" (englischsprachig).

Verwenden der Dateien Web.config und Machine.config

Es wird nicht empfohlen, unverschlüsselte Kennwörter in der Datei Web.config zu speichern. HttpForbiddenHandler schützt die Datei standardmäßig davor, von unberechtigten Benutzern heruntergeladen und angezeigt zu werden. Dennoch können Benutzer, die direkten Zugriff auf die Ordner besitzen, in denen die Konfigurationsdateien gespeichert werden, weiterhin den Benutzernamen und das Kennwort anzeigen.

Machine.config wird im Vergleich zu Web.config als sicherer Speicherort betrachtet, da sie sich im Systemverzeichnis (mit ACLs) und außerhalb des virtuellen Verzeichnisses einer Webanwendung befindet. Weitere Informationen zum Sichern der Datei Machine.config finden Sie in Modul 8, "ASP.NET-Sicherheit".

Verwenden von UDL-Dateien

Der OLE DB .NET-Datenprovider unterstützt UDL-Dateinamen in seiner Verbindungszeichenfolge. Verwenden Sie innerhalb der Verbindungszeichenfolge den Eintrag "File Name=name.udl", um auf eine UDL-Datei zu verweisen.

Wichtig: Diese Option steht nur zur Verfügung, wenn Sie den OLE DB .NET-Datenprovider verwenden, um die Verbindung zur Datenbank herzustellen. Der SQL Server .NET-Datenprovider verwendet keine UDL-Dateien.

Es wird nicht empfohlen, UDL-Dateien in einem virtuellen Verzeichnis zusammen mit anderen Anwendungsdateien zu speichern. Sie sollten sie außerhalb der virtuellen Verzeichnishierarchie einer Webanwendung speichern und die Datei oder den übergeordneten Ordner mithilfe von Windows-ACLS sichern. Sie sollten auch UDL-Dateien auf einem vom Betriebssystem getrennten logischen Datenträger speichern, um sie vor möglicher Dateivereinheitlichung und Fehlern bei der Verzeichnisdurchquerung zu schützen.

Feinstufigkeit von ACLs

UDL-Dateien (bzw. beliebige Textdateien) bieten im Vergleich zur Datei Machine.config zusätzliche Feinstufigkeit, wenn Sie ACLs anwenden. Die der Datei Machine.config zugeordneten Standard-ACLs gewähren den Zugriff für eine Vielzahl von lokalen und Remotebenutzern. Die Datei Machine.config besitzt z. B. die folgenden Standard-ACLs:

MachineName\ASPNET:R
BUILTIN\Users:R
BUILTIN\Power Users:C
BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F

Dagegen können Sie die UDL-Datei Ihrer eigenen Anwendung umfassender vor Zugriffen schützen. Sie können z. B. den Zugriff auf Administratoren, das Systemkonto und das ASP.NET-Prozesskonto (das den Lesezugriff erfordert) beschränken, wie nachfolgend gezeigt: 

BUILTIN\Administrators:F
MachineName\ASPNET:R
NT AUTHORITY\SYSTEM:F

Hinweis: Da UDL-Dateien extern von beliebigen ADO.NET-Clientanwendungen geändert werden können, werden Verbindungszeichenfolgen, die Verweise auf UDL-Dateien enthalten, bei jedem Öffnen der Verbindung analysiert. Dies kann sich auf die Leistung auswirken. Für eine optimale Leistung wird deshalb die Verwendung einer statischen Verbindungszeichenfolge empfohlen, die keine UDL-Datei enthält.

  • So erstellen Sie eine neue UDL-Datei

    1. Wechseln Sie im Windows Explorer zu dem Ordner, in dem sie die UDL-Datei erstellen möchten.

    2. Klicken Sie mit der rechten Maustaste in den Ordner, wählen Sie den Eintrag Neu aus und klicken Sie dann auf Textdokument.

    3. Stellen Sie einen Dateinamen mit der Dateierweiterung UDL bereit.

    4. Doppelklicken Sie auf die neue Datei, um das Dialogfeld UDL-Eigenschaften anzuzeigen.

Weitere Informationen

Weitere Informationen zum Verwenden von UDL-Dateien des Entwicklungsprogramms Microsoft C#® finden Sie in der Microsoft Knowledge Base im Artikel 308426, "SO WIRD'S GEMACHT: Verwendung von Datenverknüpfungsdateien für das OleDbConnection-Objekt in Visual C# .NET".

Verwenden benutzerdefinierter Textdateien

Viele Anwendungen verwenden benutzerdefinierte Textdateien, um Verbindungszeichenfolgen zu speichern. Wenn Sie diesem Ansatz folgen, berücksichtigen Sie die folgenden Empfehlungen:

  • Speichern Sie benutzerdefinierte Dateien außerhalb der virtuellen Verzeichnishierarchie der Anwendung.

  • Speichern Sie die Dateien auf einem vom Betriebssystem getrennten logischen Datenträger, um sie vor möglicher Dateivereinheitlichung und Fehlern bei der Verzeichnisdurchquerung zu schützen.

  • Schützen Sie die Datei mit einer eingeschränkten ACLs, die dem Prozesskonto Ihrer Anwendung Lesezugriff erteilt.

  • Vermeiden Sie es, die Verbindungszeichenfolge unverschlüsselt in der Datei zu speichern. Stattdessen sollten Sie die DPAPI zum Speichern der verschlüsselten Zeichenfolge verwenden.

Verwenden der Registrierung

Sie können einen benutzerdefinierten Schlüssel in der Windows-Registrierung verwenden, um die Verbindungszeichenfolge zu speichern. Diese gespeicherten Informationen können entweder in der Registrierungsstruktur HKEY_LOCAL_MACHINE (HKLM) oder HKEY_CURRENT_USER (HKCU) eingetragen werden. Für Prozessidentitäten, die nicht über Benutzerprofile verfügen (z. B. das Konto ASPNET), müssen diese Informationen in HKLM gespeichert werden, damit sie vom ASP.NET-Code abgerufen werden können.

Wenn Sie diesen Ansatz verwenden, sollten Sie Folgendes durchführen:

  • Verwenden Sie ACLs, um den Registrierungsschlüssel mit der Datei Regedt32.exe zu schützen.

  • Verschlüsseln Sie die Datei vor dem Speichern.

Weitere Informationen

Weitere Informationen zum Verschlüsseln von Daten in der Registrierung finden Sie unter "Vorgehensweise: Speichern von verschlüsselten Verbindungszeichenfolgen in der Registrierung" in diesem Handbuch.

Verwenden des COM+-Katalogs

Wenn Ihre Webanwendung Serviced Components umfasst, können Sie Verbindungszeichenfolgen im COM+-Katalog als Konstruktorzeichenfolgen speichern. Diese Zeichenfolgen können einfach verwaltet (mit dem Tool für Komponentendienste) und leicht vom Komponentencode abgerufen werden. Die Enterprise Services rufen die Construct-Methode eines Objekts unmittelbar nach dem Erstellen einer Instanz des Objekts auf und übergeben die konfigurierte Erstellungszeichenfolge.

Der COM+-Katalog bietet keine hohe Sicherheit, da die Daten nicht verschlüsselt werden. Durch den zusätzlichen Prozesshop bietet er jedoch eine im Vergleich zu Konfigurationsdateien etwas höhere Sicherheit.

Um den Zugriff auf den Katalog über das Tool für Komponentendienste zu verhindern, beziehen Sie nur die Liste mit den gewünschten Benutzern in die Rollen Administrator und Reader in der Anwendung System ein.

Das folgende Beispiel zeigt, wie eine Objektkonstruktor-Zeichenfolge aus einer Serviced Component abgerufen wird:

[ConstructionEnabled(Default="Standardverbindungszeichenfolge")]
public class YourClass : ServicedComponent 
{
  private string _ConnectionString;
  override protected void Construct(string s) 
  {
    _ConnectionString = s; 
  }
}

Um die Sicherheit zu erhöhen, können Sie Code zum Verschlüsseln der Verbindungszeichenfolge hinzufügen, bevor diese gespeichert und dann innerhalb der Serviced Component wieder entschlüsselt wird.

Weitere Informationen

  • Weitere Informationen zum Verwenden von Verbindungszeichenfolgen finden Sie in de Microsoft Knowledge Base im Artikel Q271284, "HOWTO: Access COM+ Object Constructor String in a Visual Basic Component" (englischsprachig).

  • Ein vom .NET Framework SDK bereitgestelltes vollständiges Codebeispiel finden Sie im Objektkonstruktorbeispiel unter \Programme\Microsoft Visual Studio .NET\FrameworkSDK\Samples\Technologies\ComponentServices\ObjectConstruction.

Authentifizieren von Benutzern anhand einer Datenbank

Wenn Sie eine Anwendung erstellen, die Benutzeranmeldeinformationen anhand eines Datenspeichers überprüfen muss, bedenken Sie die folgenden Punkte:

  • Speichern Sie unidirektionale Kennworthashes (mit einem zufälligen Salt-Wert).

  • Vermeiden Sie SQL Injection beim Überprüfen von Benutzeranmeldeinformationen.

Speichern von unidirektionalen Kennworthashes (mit Salt-Wert)

Webanwendungen, die die Formularauthentifizierung verwenden, müssen häufig Benutzeranmeldeinformationen (einschließlich der Kennwörter) in einer Datenbank speichern. Aus Sicherheitsgründen sollten Kennwörter (unverschlüsselt oder verschlüsselt) nicht in der Datenbank gespeichert werden.

Sie sollten das Speichern verschlüsselter Kennwörter vermeiden, da der Aufwand für die Schlüsselverwaltung erhöht wird. Sie können das Kennwort durch die Verschlüsselung sichern, müssen dann aber bedenken, wie der Verschlüsselungsschlüssel gespeichert wird. Wenn der Schlüssel unberechtigten Personen zugänglich wird, kann ein Angreifer alle Kennwörter in Ihrem Datenspeicher entschlüsseln.

Im Folgenden wird der bevorzugte Ansatz aufgeführt:

  • Speichern eines unidirektionalen Hashes des Kennworts – Berechnen Sie den Hash erneut, wenn das Kennwort überprüft werden muss.

  • Kombinieren des Kennworthashes mit dem Salt-Wert (einer kryptografisch starken, zufälligen Zahl) – Durch die Kombination von Salt-Wert und Kennworthash verringern Sie die Bedrohung durch Verzeichnisangriffe.

Erstellen eines Salt-Wertes

Der folgende Code zeigt, wie ein Salt-Wert mithilfe der Zufallszahlengenerierung erstellt wird, die von der Klasse RNGCryptoServiceProvider im Namespace System.Security.Cryptography bereitgestellt wird.

public static string CreateSalt(int size)
{
  RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
  byte[] buff = new byte[size];
  rng.GetBytes(buff);
  return Convert.ToBase64String(buff);
}
Erstellen eines Hashwertes (mit Salt-Wert)

Das folgende Codefragment zeigt, wie Sie einen Hashwert aus einem bereitgestellten Kennwort und dem Salt-Wert generieren.

public static string CreatePasswordHash(string pwd, string salt)
{
  string saltAndPwd = string.Concat(pwd, salt);
  string hashedPwd = 
        FormsAuthentication.HashPasswordForStoringInConfigFile(
                                             saltAndPwd, "SHA1");
  return hashedPwd;
}
Weitere Informationen

Die ausführlichen Implementierungsdetails dieses Ansatzes finden Sie unter "Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000" in diesem Handbuch.

SQL Injection-Angriffe

Wenn Sie die Formularauthentifizierung anhand einer SQL-Datenbank verwenden, sollten Sie die in diesem Abschnitt beschriebenen Maßnahmen ergreifen, um SQL Injection-Angriffe zu vermeiden. SQL Injection beschreibt das Übergeben zusätzlichen (unberechtigten) SQL-Codes in eine Anwendung, der dabei normalerweise an den in der Anwendung enthaltenen regulären SQL-Code angehängt wird. Alle SQL-Datenbanken sind in unterschiedlichem Maße anfällig für SQL Injection, jedoch konzentriert sich dieses Modul auf SQL Server.

Sie sollten besonders auf potenzielle SQL Injection-Angriffe achten, wenn Sie Benutzereingaben verarbeiten, die Teile eines SQL-Befehls bilden. Wenn Ihr Authentifizierungsschema auf dem Überprüfen von Benutzern anhand einer SQL-Datenbank basiert (z. B. wenn Sie die Formularauthentifizierung anhand von SQL Server verwenden), dann müssen Sie sich vor SQL Injection-Angriffen schützen.

Wenn Sie SQL-Zeichenfolgen aus ungefilterten Eingaben bilden, kann Ihre Anwendung Ziel böswilliger Benutzereingaben werden (denken Sie daran, dass Sie niemals Benutzereingaben vertrauen sollten). Das Risiko besteht darin, dass ein böswilliger Benutzer SQL-Befehle an Ihre geplanten SQL-Anweisungen anhängen kann (mithilfe von Escapezeichen), wenn Sie Benutzereingaben in eine Zeichenfolge einfügen, die zu einer ausführbaren Anweisung wird.

Die Codefragmente in den folgenden Abschnitten verwenden die Datenbank Pubs, die mit SQL Server bereitgestellt wird, um Beispiele für SQL Injection zu veranschaulichen.

Das Problem

Wenn Sie Benutzereingaben oder andere unbekannte Daten in Datenbankabfragen einbeziehen, kann Ihre Anwendung für SQL Injection-Angriffe anfällig sein. Beispielsweise sind die beiden folgenden Codefragmente für Angriffe anfällig.

  • Sie erstellen SQL-Anweisungen aus ungefilterten Benutzereingaben.

    SqlDataAdapter myCommand = new SqlDataAdapter(
          "SELECT au_lname, au_fname FROM authors WHERE au_id = '" + 
          Login.Text + "'", myConnection);

  • Sie rufen eine gespeicherte Prozedur auf, indem Sie eine einzelne Zeichenfolge erstellen, die ungefilterte Benutzereingaben einbezieht.

    SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure '" + 
                               Login.Text + "'", myConnection);

Aufbau eines Injection-Angriffs mit SQL Script

Wenn Sie ungefilterte Benutzereingabewerte (wie oben veranschaulicht) in Ihrer Anwendung akzeptieren, kann ein böswilliger Benutzer Escapezeichen verwenden, um eigene Befehle anzuhängen.

Stellen Sie sich eine SQL-Abfrage vor, die vom Benutzer eine Eingabe in Form einer Rentenversicherungsnummer erfordert, z. B. 172-32-xxxx, was zu einer Abfrage wie der folgenden führt:

SELECT au_lname, au_fname FROM authors WHERE au_id = '172-32-xxxx'

Ein böswilliger Benutzer kann den folgenden Text in das Eingabefeld der Anwendung eingeben (z. B. in ein Textfeldsteuerelement).

' ; INSERT INTO jobs (job_desc, min_lvl, max_lvl) VALUES ('Important Job', 25, 
100)  -

In diesem Beispiel wird die INSERT-Anweisung eingefügt (es kann jedoch jede Anweisung ausgeführt werden, die für das Konto zugelassen ist, das zum Herstellen der Verbindung zu SQL Server verwendet wird). Der Code kann besonders schädlich sein, wenn das Konto Mitglied der Rolle sysadmin ist (dies ermöglicht Shellbefehle, die über xp_cmdshell ausgeführt werden können) und SQL Server unter einem Domänenkonto ausgeführt wird, das Zugriff auf andere Netzwerkressourcen hat.

Die obigen Befehle ergeben die folgende kombinierte SQL-Zeichenfolge:

SELECT au_lname, au_fname FROM authors WHERE au_id = '';INSERT INTO jobs 
(job_desc, min_lvl, max_lvl) VALUES ('Important Job', 25, 100)  --

In diesem Fall beendet das Zeichen ' (einfaches Anführungszeichen), das die unberechtigte Eingabe anführt, das aktuelle Zeichenfolgenliteral in Ihrer SQL-Anweisung. Es schließt die aktuelle Anweisung nur, wenn das folgende analysierte Token als Fortsetzung der aktuellen Anweisung keinen Sinn macht, jedoch als Beginn einer neuen Anweisung geeignet ist.

SELECT au_lname, au_fname FROM authors WHERE au_id = ' '

Das Zeichen ; (Semikolon) teilt SQL mit, dass Sie eine neue Anweisung beginnen, auf die dann der unberechtigte SQL-Code folgt:

; INSERT INTO jobs (job_desc, min_lvl, max_lvl) VALUES ('Important Job', 25, 100)

Hinweis: Das Semikolon ist nicht unbedingt erforderlich, um SQL-Anweisungen voneinander zu trennen. Dies hängt vom Anbieter oder von der Implementierung ab, wird jedoch nicht von SQL Server erwartet. Der folgende Code wird z. B. von SQL Server als zwei separate Anweisungen analysiert.

SELECT * FROM MyTable DELETE FROM MyTable

Abschließend weist die Zeichenfolge -- (doppelter Strich) SQL an, den Rest des Textes zu ignorieren, wodurch in diesem Fall das abschließende Zeichen ' (einfaches Anführungszeichen) ignoriert wird (das ansonsten zu einem SQL-Analysefehler führen würde).

Der vollständige Text, den SQL als Ergebnis der obigen Anweisung ausführt, lautet wie folgt:

SELECT au_lname, au_fname FROM authors WHERE au_id = '' ; INSERT INTO jobs 
(job_desc, min_lvl, max_lvl) VALUES ('Important Job', 25, 100) --'

Die Lösung

Sie können die folgenden Ansätze verwenden, um SQL sicher über Ihre Anwendung aufzurufen.

  • Verwenden Sie die Parameters-Auflistung, wenn Sie die SQL-Anweisungen erstellen.

    SqlDataAdapter myCommand = new SqlDataAdapter(
        "SELECT au_lname, au_fname FROM Authors WHERE au_id= @au_id", 
        myConnection);

SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
                                             "@au_id",
                                             SqlDbType.VarChar, 11);
parm.Value= Login.Text;

  • Verwenden Sie die Parameters-Auflistung beim Aufrufen einer gespeicherten Prozedur.

    // "AuthorLogin" ist eine gespeicherte Prozedur, die einen Parameter mit der Bezeichung "Login" akzeptiert
SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", myConnection);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
                                "@LoginId", SqlDbType.VarChar,11);
parm.Value=Login.Text;

    Wenn Sie die Parameters-Auflistung verwenden, wird die Eingabe als Literal behandelt, unabhängig davon, was ein böswilliger Benutzer als Eingabe einschließt. Ein weiterer Vorteil bei der Verwendung der Parameters-Auflistung ist, dass Sie Typ- und Längenüberprüfungen erzwingen können. Werte, die sich außerhalb des Bereichs befinden, lösen eine Ausnahmebedingung aus. Dies ist ein gutes Beispiel für Tiefenverteidigung.

  • Filtern Sie SQL-Zeichen aus Benutzereingaben. Die folgende Methode zeigt, wie Sie sicherstellen, dass ein in einer einfachen SQL-Vergleichsanweisung (ist gleich, kleiner als, größer als) verwendetes Zeichenfolgenliteral sicher ist. Dies erfolgt dadurch, dass ein in der Zeichenfolge verwendetes Anführungszeichen durch ein weiteres Anführungszeichen außer Kraft gesetzt wird. In einem SQL-Zeichenfolgenliteral werden zwei aufeinander folgende Anführungszeichen als Instanz des Anführungszeichens innerhalb der Zeichenfolge behandelt und nicht als Trennzeichen.

    private string SafeSqlLiteral(string inputSQL)
{
  return inputSQL.Replace("'", "''");
}
...
string safeSQL = SafeSqlLiteral(Login.Text);
SqlDataAdapter myCommand = new SqlDataAdapter(
       "SELECT au_lname, au_fname FROM authors WHERE au_id = '" + 
       safeSQL + "'", myConnection);

Weitere empfohlene Vorgehensweisen

Im Folgenden finden Sie einige zusätzliche Maßnahmen, mit denen Sie die Möglichkeit einschränken können, dass Ihr Code unberechtigt geändert wird, und mit denen Sie auch das Ausmaß eines potenziellen Schadens einschränken können:

  • Verhindern Sie ungültige Eingaben am Gate (die Front-End-Anwendung), indem Sie die Größe und den Typ der Eingabe einschränken. Durch die Einschränkung der Größe und des Typs der Eingabe verringern Sie die Möglichkeit, dass Schaden angerichtet wird. Wenn das Suchfeld der Datenbank z. B. eine Länge von elf Zeichen besitzt und nur aus numerischen Zeichen besteht, sollten Sie eine Eingabe in dieser Form erzwingen.

  • Führen Sie SQL-Code mit einem Konto aus, das minimale Rechte besitzt. Dadurch wird das Ausmaß möglicher Schäden erheblich verringert.
    Wenn ein unberechtigter Benutzer z. B. eine SQL-Anweisung so verändert hat, dass diese versucht, eine Tabelle über den Befehl DROP aus einer Datenbank zu entfernen, die SQL-Verbindung jedoch ein Konto verwendet, das nicht über die entsprechenden Berechtigungen verfügt, so schlägt der SQL-Code fehl. Dies ist ein weiterer Grund dafür, nicht das Konto sa oder Mitglieder der Rollen sysadmin oder db_owner für die SQL-Verbindungen Ihrer Anwendung zu verwenden.

  • Zeigen Sie dem Endbenutzer nicht die von der Datenbank ausgelösten SQL-Fehler an, wenn im SQL-Code eine Ausnahmebedingung auftritt. Protokollieren Sie die Fehlerinformationen, und zeigen Sie nur benutzerfreundliche Informationen an. Dadurch wird verhindert, dass unnötig Details offen gelegt werden, die einem Angreifer weiterhelfen könnten.

Schützen von Anweisungen für den Mustervergleich

Wenn Eingaben innerhalb eines Zeichenfolgenliterals in einer LIKE-Klausel verwendet werden sollen, besitzen Zeichen, bei denen es sich nicht um das Anführungszeichen handelt, eine bestimmte Bedeutung für den Mustervergleich.

In einer LIKE-Klausel bedeutet z. B. das Zeichen % "Übereinstimmung mit null oder mehr Zeichen". Damit diese Zeichen in der Eingabe als Literalzeichen ohne besondere Bedeutung behandelt werden, müssen sie ebenfalls außer Kraft gesetzt werden. Wenn sie nicht auf besondere Weise behandelt werden, kann die Abfrage falsche Ergebnisse liefern. Ein nicht außer Kraft gesetztes Zeichen für den Mustervergleich kann auch die Indexerstellung verhindern, wenn es am Anfang einer Zeichenfolge steht.

Für SQL Server sollte die folgende Methode verwendet werden, um zulässige Eingaben sicherzustellen:

private string SafeSqlLikeClauseLiteral(string inputSQL)
{
  // Nehmen Sie folgende Ersetzungen vor:
  // '  wird zu  ''
  // [  wird zu  [[]
  // %  wird zu  [%]
  // _  wird zu  [_]

  string s = inputSQL;
  s = inputSQL.Replace("'", "''");
  s = s.Replace("[", "[[]");
  s = s.Replace("%", "[%]");
  s = s.Replace("_", "[_]");
  return s;
}

Überwachung

Die Überwachung von Anmeldevorgängen ist in SQL Server nicht standardmäßig aktiviert. Sie können dies entweder über den SQL Server Enterprise Manager oder in der Registrierung konfigurieren. Das Dialogfeld in Abbildung 12.6 zeigt an, dass die Überwachung sowohl für erfolgreiche als auch für fehlgeschlagene Anmeldeversuche aktiviert ist.

Die Protokolleinträge werden in die SQL-Protokolldateien geschrieben, die sich standardmäßig im Verzeichnis C:\Programme\Microsoft SQL Server\MSSQL\LOG befinden. Sie können ein beliebiges Textprogramm verwenden, um die Einträge anzuzeigen, z. B. den Editor von Windows.

Dialogfeld SQL Server-Eigenschaften mit den Einstellungen für die Überwachungsebene

Abbildung 12.6
Dialogfeld SQL Server-Eigenschaften mit den Einstellungen für die Überwachungsebene

Sie können die Überwachung für SQL Server auch in der Systemregistrierung aktivieren. Wenn Sie die Überwachung für SQL Server aktivieren möchten, erstellen Sie den folgenden AuditLevel-Schlüssel in der Systemregistrierung, und legen Sie als Wert einen der im Folgenden angegebenen REG_DWORD-Werte fest:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\AuditLevel

Sie können einen der folgenden Werte auswählen, mit denen Sie die gewünschte Detailebene bestimmen:

3 – Erfasst sowohl erfolgreiche als auch fehlgeschlagene Anmeldeversuche

2 – Erfasst nur fehlgeschlagene Anmeldeversuche

1 – Erfasst nur erfolgreiche Anmeldeversuche

0 – Erfasst keine Anmeldeversuche

Es wird empfohlen, dass Sie die Überprüfung auf fehlerhafte Anmeldeversuche aktivieren, da Sie es so ermitteln können, wenn versucht wird, einen Brute-Force-Angriff auf einen SQL Server zu unternehmen. Die Leistungsbeeinträchtigung durch die Protokollierung von fehlgeschlagenen Überwachungsversuchen ist minimal, es sei denn, Sie werden gerade angegriffen, aber in diesem Fall müssen Sie es ohnehin wissen.

Sie können auch ein Skript für SQL Database Management Objects (DMO, Datenbankverwaltungsobjekte) erstellen. Das folgende Codefragment zeigt einen VBScript-Beispielcode.

Sub SetAuditLevel(Server As String, NewAuditLevel As SQLDMO_AUDIT_TYPE)
    Dim objServer As New SQLServer2  
    objServer.LoginSecure = True     'Integrierte Sicherheit verwenden
    objServer.Connect Server        'Verbindung mit Ziel-SQL Server herstellen
    'Set the audit level
    objServer.IntegratedSecurity.AuditLevel = NewAuditLevel       
    Set objServer = Nothing
End Sub

Gemäß der SQL Server-Onlinedokumentation lauten die Mitglieder des Aufzählungstyps SQLDMO_AUDIT_TYPE wie folgt:

SQLDMOAudit_All      3  Alle Authentifizierungsversuche protokollieren, egal, ob sie erfolgreich
                        waren oder nicht 
SQLDMOAudit_Failure  2  Fehlgeschlagene Authentifizierung protokollieren 
SQLDMOAudit_Success  1  Erfolgreiche Authentifizierung protokollieren 
SQLDMOAudit_None     0  Authentfizierungsversuche nicht protokollieren

Prozessidentität für SQL Server

Führen Sie SQL Server mithilfe eines Domänenkontos mit minimalen Rechten aus. Bei der Installation von SQL Server haben Sie die Möglichkeit, den SQL Server-Dienst mit dem lokalen Konto SYSTEM oder mit einem angegebenen Konto auszuführen.

Verwenden Sie nicht das Konto SYSTEM oder ein Administratorkonto. Verwenden Sie stattdessen ein Domänenkonto mit minimalen Rechten. Sie müssen diesem Konto keine speziellen Rechte erteilen, da dem Konto bei der Installation (oder über SQL Server Enterprise Manager, wenn Sie den SQL-Dienst nach der Installation erneut konfigurieren) die erforderlichen Rechte erteilt werden.

Wenn SQL Server auf Remotecomputer zugreifen muss, z. B. zur Netzwerksicherung und zur Wiederherstellung oder Replizierung von Daten, müssen Sie ein Domänenkonto mit minimalen Rechten verwenden oder ein doppeltes lokales Kontos mit demselben Benutzernamen und Kennwort auf dem Remoteserver erstellen. Zur Kennwortsynchronisierung können Sie ein Skript erstellen. Das doppelte Konto ist ein notwendiger Ansatz, wenn Sie auf Server in anderen Domänen zugreifen müssen, die keine Vertrauensstellung besitzen.

Zusammenfassung

Nachfolgend finden Sie eine Zusammenfassung, in der die Empfehlungen für den Datenzugriff in .NET-Webanwendungen hervorgehoben sind:

  • Verwenden Sie für den SQL Server die Windows-Authentifizierung.

  • Verwenden Sie in der Datenbank Konten mit minimalen Rechten.

  • Verwenden Sie zum Ausführen von ASP.NET/Enterprise Services lokale Konten mit minimalen Rechten, wenn Sie die Verbindung zu SQL Server herstellen.

  • Verwenden Sie in der Datenbank benutzerdefinierte Datenbankrollen für die Autorisierung.

  • Wenn Sie die SQL-Authentifizierung verwenden, führen Sie die folgenden Schritte durch, um die Sicherheit zu erhöhen:

    • Verwenden Sie benutzerdefinierte Konten mit sicheren Kennwörtern.

    • Schränken Sie die Berechtigungen der einzelnen Konten in SQL Server mithilfe von Datenbankrollen ein.

    • Fügen Sie ACLs zu Dateien hinzu, in denen Verbindungszeichenfolgen gespeichert werden.

    • Verschlüsseln Sie Verbindungszeichenfolgen.

    • Verwenden Sie DPAPI zum Speichern von Anmeldeinformationen.

  • Wenn Sie die Formularauthentifizierung verwenden, treffen Sie Maßnahmen, um SQL Injection-Angriffe zu vermeiden.

  • Speichern Sie Kennwörter zur Überprüfung von Benutzern nicht in Datenbanken. Anstatt unverschlüsselte oder verschlüsselte Kennwörter zu verwenden, speichern Sie Kennworthashes mit einem Salt-Wert.

  • Schützen Sie vertrauliche Daten, die an oder von SQL Server über das Netzwerk gesendet werden.

    • Die Windows-Authentifizierung schützt Anmeldeinformationen, jedoch keine Anwendungsdaten.

    • Verwenden Sie IPSec oder SSL.