SQL Server-Sicherheit der ASP.NET2.0-Datenbank

Autor：Eve Cole Aktualisierungszeit：2009-06-30 16:43:56

Bei der Installation von SQL Server gibt es zwei Optionen für den abgesicherten Modus. Der Unterschied besteht darin, welche Software den Authentifizierungsprozess durchführt. Bei der Authentifizierung handelt es sich um den Prozess der Bestätigung der Identität eines Benutzers, der eine Verbindung zu SQL Server herstellt. Sobald die Authentifizierung durchgeführt wurde, kann SQL Server überprüfen, ob der Benutzer berechtigt ist, eine Verbindung zu einer angeforderten Ressource, beispielsweise einer Datenbank, herzustellen. Wenn der Benutzer über die Berechtigung zum Herstellen einer Verbindung mit der Datenbank verfügt, lässt SQL Server zu, dass die Verbindungsanforderung erfolgreich ist. Andernfalls schlägt die Verbindung fehl. Dieser Prozess der Überprüfung der Benutzerberechtigung wird auch Autorisierung genannt.

· Die Windows-Authentifizierung (auch als vertrauenswürdige Authentifizierung oder integrierte Sicherheit bekannt) verwendet die Identität des Windows-Benutzers, der die Verbindungsanforderung stellt, um die Autorisierung für die Datenbank durchzuführen. In diesem Fall muss die Verbindungszeichenfolge keinen expliziten Benutzernamen und kein explizites Kennwort enthalten. ASP.NET wird als lokaler Benutzer mit dem Namen „ASPNET“ (oder „Netzwerkdienst“ in IIS 6.0) ausgeführt. Bei Verwendung der Windows-Authentifizierung prüft SQL daher, ob dieser Benutzer über die Berechtigung zur Verwendung der Datenbank verfügt. Zu diesem Zeitpunkt werden alle ASP.NET-Anwendungen mit demselben Benutzer ausgeführt, sodass sie im abgesicherten Modus gleich behandelt werden. Obwohl es möglich ist, jede Anwendung in einem separaten ASP.NET-Prozess auszuführen (ein separater Benutzer, der jede Anwendung ausführt) oder die Windows-Benutzeridentität des Browser-Clients zu imitieren, der die Verbindungsanforderung stellt, liegen diese nicht im Rahmen dieses Buchs . Der Client-Identitätswechsel ist jedoch die häufigste Verwendung der Windows-Authentifizierung in Webanwendungen.

· Die SQL-Authentifizierung prüft explizit bereitgestellte Benutzernamen und Kennwörter anhand von Benutzern, die in SQL Server konfiguriert sind (ohne Einbeziehung des Betriebssystems). In diesem Fall kann jede Anwendung, die im ASP.NET-Prozess ausgeführt wird, mit einem separaten Zertifikat eine Verbindung zur Datenbank herstellen, wodurch die Anwendungen angemessen isoliert werden (Anwendung A kann keine Verbindung zur Datenbank herstellen, wenn sie nicht über den Benutzernamen und das Kennwort von B verfügt). . Es kann keine Verbindung zur Datenbank von B hergestellt werden. Dies ist der am häufigsten verwendete Authentifizierungsmodus für bereitgestellte Webanwendungen, insbesondere im Fall von Shared Hosting. Ein kleiner Nachteil besteht darin, dass die Anwendung das Kennwort des für die Verbindung verwendeten Benutzerkontos behalten muss. Wenn dieses Kennwort von einem böswilligen Benutzer erhalten wird, ist die Sicherheit der Datenbank gefährdet. Wie Sie jedoch später in diesem Buch sehen werden, bietet ASP.NET eine sichere Möglichkeit, das SQL-Authentifizierungskennwort in einem verschlüsselten Format in der Datei Web.config zu speichern und so das Risiko eines Zugriffs auf das Kennwort zu verringern.

· Der gemischte Modus ist eine Konfiguration von SQL Server, die sowohl Windows-Authentifizierung als auch SQL-Authentifizierung ermöglicht.

Bei der Installation von SQL Server oder SSE müssen Sie einen Authentifizierungsmodus auswählen. In SQL Server gibt es einen Assistenten, der Sie bei der Auswahl der Sicherheitsschritte unterstützt, während in SSE die Standardauswahl Windows-Authentifizierung ist. Wenn Sie die SQL-Authentifizierung installieren möchten, müssen Sie diese explizit konfigurieren. In diesem Artikel wird die Windows-Authentifizierung verwendet.

Wenn Sie SQL Server oder SSE installiert haben, können Sie den angegebenen Authentifizierungsmodus anzeigen, indem Sie RegEdit öffnen (natürlich müssen Sie es zuerst sichern), HKey_Local_Machine/Software/Microsoft/Microsoft SQL Server suchen und nach LoginMode suchen. Ein Registrierungsunterschlüssel mit dem Wert 1 stellt die Windows-Authentifizierung dar, während ein Wert von 2 den gemischten Authentifizierungsmodus darstellt.

Tabelle 3-1 fasst die Unterschiede zwischen diesen Modi zusammen.

Tabelle 3-1

die SQL-Ereignisse und

	Windows-Authentifizierung,	SQL-Authentifizierung,
austauschbarer Name,	vertrauenswürdige Authentifizierung Integrierte Sicherheit	Nein, aber die Authentifizierung im gemischten Modus ermöglicht die Verwendung der Windows- oder SQL-Authentifizierung.
Bei	der Standardinstallation	muss die
Installationsverbindungszeichenfolge	„	Trusted_connection
=	true
“	angegeben	werden
=wahrer	Benutzer=Benutzername; Passwort=Passwort
Benutzer von ASP.NET-Webanwendungen	, ASP.NET-Prozessen, ASPNET- (IIS 5.x) oder Netzwerkdiensten (IIS 6)	SQL-Benutzer
können	die	Windows-Aktivitätsverfolgung besser steuern	kann unabhängig vom Betriebssystem auf dem Host-Computer bereitgestellt werden, ohne dass ein neues Konto erstellt werden muss Für die gehostete Intranet-Site sind nur mäßige Kenntnisse erforderlich Bietet eine flexiblere Möglichkeit für Anwendungen, mit unterschiedlichen Zertifikaten eine Verbindung zu jeder Datenbank herzustellen.
Nachteile	Die Bereitstellung eines Windows-Zertifikats für eine Webanwendung kann dazu führen, dass der Umfang der Berechtigungen im Betriebssystem zu groß wird.	Passwörter werden in der Webanwendung gespeichert (was nicht der Fall ist). Fall bei der Windows-Authentifizierung). Bestätigen Sie, dass das Passwort in der Datei Web.config gespeichert und verschlüsselt ist. Ermöglicht Low-Level-Vorgänge für Webanwendungen mithilfe von SA-Zertifikaten. Erstellen Sie immer neue Zertifikate für ASP.NET-Webanwendungen und erteilen Sie nur die erforderlichen Berechtigungen

Nachdem wir nun wissen, wie man SQL sicher verwendet, wollen wir uns überlegen, wie der Datenkonsument (DataSource-Steuerelement) die Anforderungen erfüllt. Verwenden Sie zunächst die von VWD und dem VWD-Webserver (Cassini) erhaltenen Daten, hauptsächlich während des Entwurfs und des Tests. Zweitens sollte nach der Bereitstellung über IIS auf die Daten zugegriffen werden. Die beiden Datenkonsumenten haben unterschiedliche Benutzernamen. VWD und VWD Web Server verwenden den Namen der bei Windows angemeldeten Person, während das IIS-Programm den Namen ASPNET verwendet.

Wenn SQL Server die Windows-Authentifizierung verwendet, muss das SqlDataSource-Steuerelement den folgenden Code in die Verbindungszeichenfolge aufnehmen: Integrated Security=true (oder Trusted_connection=true). Dieser Parameter weist SQL Server an, Datenanforderungen basierend auf dem Windows-Anmeldekonto des Anforderers zu authentifizieren. Wenn Sie als der Benutzer angemeldet sind, der SSE installiert hat, gewährt sein Zertifikat Zugriff auf SSE. Mit VWD und VWD Web Server läuft alles reibungslos, da Benutzer von VW Web Server als bei Windows angemeldete Programmierer gelten und daher über Konten bei SSE verfügen. Auch wenn die Anwendung außerhalb von VWD einwandfrei funktioniert, funktioniert sie bei der Migration der Site zu IIS nicht ordnungsgemäß. IIS wird unter einem Benutzerkonto namens ASPNET (oder Netzwerkdienst in IIS6/Windows 2003 Server) ausgeführt. Daher muss der Administrator des Computers, auf dem IIS ausgeführt wird, den ASP.NET-Benutzer hinzufügen und ihm Berechtigungen erteilen. Dieser Vorgang geht über den Rahmen dieses Buches hinaus, wird jedoch in vielen IIS-Administratorhandbüchern ausführlich beschrieben. Zusammenfassend gilt: Wenn SQL Server die Windows-Authentifizierung verwendet, können Sie VWD und VWD Web Server verwenden, um die Übungen in diesem Buch durchzuführen. Ihre Seite kann nur auf IIS ausgeführt werden, nachdem Sie dem ASP.NET-Prozesskonto, das auf die Datenbank zugreift, die Berechtigung erteilt haben.

Wenn SQL Server die SQL-Authentifizierung verwendet, führt SQL seinen eigenen Authentifizierungsprozess durch. Dieser Vorgang ist nicht auf die Windows-Benutzerliste angewiesen. Die Verbindungszeichenfolge enthält zwei Parameter: Benutzer=Benutzername, Passwort=Passwort. Die Seite kann nun von VWD, VWD Web Server oder IIS aus genutzt werden, da kein Benutzerkonto in Windows erstellt werden muss. Wir müssen jedoch auch ein Konto in SQL Server verwenden. Das einzige Standardkonto ist sa. Vor der Bereitstellung sollte in SQL Server ein weiteres Konto erstellt werden, das nur die Berechtigung zum Ausführen von ASPX-Seiten hat. Wenn kein anderes Konto als das SA (und kein Passwort zum Schutz des SA) erstellt wird, bleibt die Website einer der bekanntesten und am einfachsten auszunutzenden Sicherheitslücken ausgesetzt. Jeder Hacker weiß, dass er sich mit userID='sa' und einem leeren Passwort anmelden kann.

Bei beiden Authentifizierungsmodi meldet sich der Benutzer bei Verwendung der zuvor beschriebenen Verbindungszeichenfolge mit dem ursprünglichen Konto bei SQL Server an. Dieses Konto ist sa, was Systemadministrator bedeutet. Wie aus dem Namen hervorgeht, verfügt es über alle Berechtigungen für alle Objekte. In der aktuellen Version von SQL Server kann der Dienst nicht mit sa und einem NULL-Passwort installiert werden. In SSE muss es mit dem Parameter SAPWD="MyStrongPassword" installiert werden. Ein sicheres Passwort bedeutet hier zumindest nicht NULL. Verwenden Sie am besten mindestens sieben Zeichen und achten Sie darauf, eine Mischung aus Buchstaben, Zahlen und Symbolen zu verwenden. Außerhalb von Studierendenübungen muss in den meisten Fällen jeder Datenbank und Anwendung ein Konto zugewiesen werden. Es sollte vermieden werden, einer Anwendung die Berechtigung zum Zugriff auf Daten anderer Anwendungen zu erteilen.