IIS-Sicherheit
In diesem Thema wird beschrieben, wie Microsoft SQL Server Compact 3.5 mit folgenden Funktionen zusammenwirkt:
IIS-Authentifizierung
IIS-Autorisierung
IIS-Verschlüsselung
IIS-Authentifizierung
Bei der Konfiguration des Server-Agents für SQL Server Compact 3.5 geben Sie an, ob Clients beim Herstellen einer Verbindung mit dem Server-Agent für SQL Server Compact 3.5 die Authentifizierung für Microsoft Internetinformationsdienste (Internet Information Services, IIS) ausführen müssen. Es gibt drei Arten der IIS-Authentifizierung:
Anonymer Zugriff
Standardauthentifizierung
Integrierte Windows-Authentifizierung
Normalerweise verwenden die meisten Internetanwendungen die Standardauthentifizierung und die SSL-Verschlüsselung (Secure Sockets Layer).
Anonymer Zugriff
Bei einem anonymen Zugriff führt IIS keine Clientauthentifizierung aus. Alle Aktionen, die der Server-Agent für SQL Server Compact 3.5 für den Client ausführt, erfolgen unter der Identität des Internetgastkontos. Standardmäßig ist IUSR_computername das Internetgastkonto, Sie können aber auch ein anderes Windows-Benutzerkonto als Internetgastkonto festlegen.
Standardauthentifizierung
Bei der Standardauthentifizierung muss der SQL Server Compact 3.5-Client einen Benutzernamen und ein Kennwort für ein gültiges Windows-Konto angeben. Die Anmeldung erfolgt dann durch IIS mithilfe des angegebenen Benutzernamens und des Kennworts. Bei einem erfolgreichen Anmeldeversuch werden alle Aktionen des Server-Agents für SQL Server Compact 3.5 unter der Identität des angegebenen Windows-Benutzerkontos ausgeführt. Schlägt der Anmeldeversuch fehl, wird die Clientanforderung zurückgewiesen. Die Standardauthentifizierung kann für Internet- und Intranetanwendungen verwendet werden. Für die Standardauthentifizierung benötigt jeder Client ein gültiges Windows-Konto mit entsprechendem Benutzernamen und Kennwort.
Wichtig
Standardmäßig werden der Benutzername und das Kennwort bei der Standardauthentifizierung im Netzwerk in Base64-Codierung übertragen. Dies kann ein Sicherheitsrisiko darstellen, wenn der Kennwortaustausch abgehört wird, da die Base64-Codierung leicht decodiert werden kann. Zum Schutz des Benutzerkennworts sollte bei der Standardauthentifizierung stets die SSL-Verschlüsselung verwendet werden. Weitere Informationen finden Sie unter "Konfigurieren der SSL-Verschlüsselung".
Integrierte Windows-Authentifizierung
Die integrierte Windows-Authentifizierung funktioniert ähnlich wie die Standardauthentifizierung. Der SQL Server Compact 3.5-Client muss einen Benutzernamen und ein Kennwort für ein gültiges Windows-Konto angeben. Die Anmeldung erfolgt dann durch IIS mithilfe des angegebenen Benutzernamens und Kennworts. Bei einem erfolgreichen Anmeldeversuch werden alle Aktionen des Server-Agents für SQL Server Compact 3.5 unter der Identität des Windows-Benutzerkontos ausgeführt. Schlägt der Anmeldeversuch fehl, wird die Synchronisierungsanforderung des Clients zurückgewiesen. Die integrierte Windows-Authentifizierung weist einen wichtigen Vorteil gegenüber der Standardauthentifizierung auf: Im Gegensatz zur Standardauthentifizierung werden bei der integrierten Windows-Authentifizierung der Benutzername und das Kennwort des Clients im Netzwerk verschlüsselt übertragen. Damit wird das Risiko umgangen, dass das Kennwort abgefangen wird. Die integrierte Windows-Authentifizierung eignet sich am besten für Intranetanwendungen. Die integrierte Windows-Authentifizierung wird selten für Internetanwendungen verwendet, weil sie nicht über einen Proxyserver oder eine Firewall ausgeführt werden kann.
Hinweis
Da Microsoft Windows CE 4.2 die Digestauthentifizierung nicht unterstützt, wird diese Form der Authentifizierung auch nicht von den Konnektivitätslösungen von SQL Server Compact 3.5 unterstützt.
IIS-Autorisierung
Nach der Authentifizierung des IIS-Clients wird über die IIS-Autorisierung ermittelt, ob der Client den Server-Agent für SQL Server Compact 3.5 aufrufen kann. Sie können steuern, wer die SQL Server Compact 3.5-Konnektivität ausführen darf, indem Sie die Clients steuern, die auf den Server-Agent für SQL Server Compact 3.5 zugreifen können.
IIS stellt die folgenden Mechanismen für die Zugriffssteuerung bereit:
IIS prüft zuerst, ob für die Adresse des Clients konfigurierte Beschränkungen für IP-Adressen gelten. Sie können den Webserver so konfigurieren, dass bestimmte Computer, Computergruppen oder ganze Netzwerke nicht auf den Server-Agent für SQL Server Compact 3.5 zugreifen können. Beim ersten Zugriffsversuch eines Clients auf den Server-Agent für SQL Server Compact 3.5 überprüft IIS, ob die IP-Adresse des Clients den Beschränkungen für IP-Adressen auf dem Server entspricht. Wenn der Zugriff aufgrund der IP-Adresse verweigert wird, wird die Synchronisierungsanforderung des Clients mit folgender Fehlermeldung zurückgewiesen: "403 Zugriff verweigert".
Wenn IIS so konfiguriert ist, dass eine Authentifizierung erforderlich ist, prüft IIS, ob der Client über ein gültiges Windows-Benutzerkonto verfügt. Genauere Erläuterungen dazu finden Sie im Abschnitt zur IIS-Authentifizierung in diesem Dokument. Wenn es sich um ein ungültiges Benutzerkonto handelt, wird die Synchronisierungsanforderung des Clients mit folgender Fehlermeldung zurückgewiesen: "403 Zugriff verweigert".
IIS prüft dann die Webberechtigungen. Diese IIS-Sicherheitsprüfung ist für Konnektivitätslösungen von SQL Server Compact 3.5 nicht relevant.
Anschließend überprüft IIS die NTFS-Berechtigungen für den Server-Agent für SQL Server Compact 3.5, um sicherzustellen, dass der jeweilige Benutzer über die entsprechenden Berechtigungen verfügt.
Hinweis
IIS kann zwar auch mit einem Dateisystem mit File Allocation Table (FAT - Dateizuordnungstabelle) verwendet werden, die Verwendung von NTFS wird jedoch dringend empfohlen. NTFS ermöglicht die Verwendung von Zugriffssteuerungslisten (Access Control List, ACL), die den Zugriff auf den Server-Agent für SQL Server Compact 3.5 und auf die Eingabe- und Ausgabenachrichtendateien auf dem IIS-System gewähren oder verweigern.
IIS-Verschlüsselung
Beim Konfigurieren des Server-Agents für SQL Server Compact 3.5 können Sie die SSL-Verschlüsselung angeben. Bei Verwendung der SSL-Verschlüsselung wird die gesamte Kommunikation zwischen dem Client-Agent für SQL Server Compact 3.5 und dem Server-Agent für SQL Server Compact 3.5 verschlüsselt. Weitere Informationen finden Sie unter Konfigurieren der SSL-Verschlüsselung.
Die SSL-Verschlüsselung sollte in folgenden Situationen verwendet werden:
Wenn IIS mit der Standardauthentifizierung konfiguriert wird.
Dies ist für die Geheimhaltung des Internetkennworts des Benutzers von größter Bedeutung. Standardmäßig werden der Benutzername und das Kennwort bei der Standardauthentifizierung im Netzwerk in Base64-Codierung weitergeleitet. Dies kann ein Sicherheitsrisiko darstellen, wenn der Kennwortaustausch abgehört wird, da die Base64-Codierung leicht decodiert werden kann. Bei der Standardauthentifizierung sollte stets die SSL-Verschlüsselung verwendet werden, um das Internetkennwort des Benutzers zu schützen.
Nur für RDA: wenn von der Anwendung ein OLEDBConnectionString-Parameter mit einem Kennwort angegeben wird.
Für die RDA-Methoden Pull, Push und SubmitSQL ist ein OLEDBConnectionString-Parameter erforderlich. Diese Verbindungszeichenfolge wird im Netzwerk im Klartextformat weitergeleitet. Wenn der Kennwortaustausch abgehört wird, kann dies ein Sicherheitsrisiko darstellen.
Nur für die Replikation: wenn der SQL Server-Verleger oder -Verteiler die SQL Server-Authentifizierung verwendet.
Der Verteiler verwendet die SQL Server-Authentifizierung, wenn für die DistributorSecurityMode-Eigenschaft der Wert DB_AUTHENTICATION angegeben wird. Der Verleger verwendet die SQL Server-Authentifizierung, wenn für die PublisherSecurityMode-Eigenschaft der Wert DB_AUTHENTICATION angegeben wird. Wenn die SQL Server-Authentifizierung verwendet wird, werden DistributorPassword und PublisherPassword im Netzwerk im Klartextformat übertragen. Wenn der Kennwortaustausch abgehört wird, kann dies ein Sicherheitsrisiko darstellen. Bei Verwendung der SQL Server-Authentifizierung sollte immer die SSL-Verschlüsselung verwendet werden, um den Schutz für DistributorPassword und PublisherPassword sicherzustellen.