Freigeben über

Modul 4 – Sichere Kommunikation

  • Artikel

* * *

Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
Vorbereitung Vorbereitung
Ermitteln der zu sichernden Daten Ermitteln der zu sichernden Daten
SSL/TLS SSL/TLS
IPSec IPSec
RPC-Verschlüsselung RPC-Verschlüsselung
Point-to-Point-Sicherheit Point-to-Point-Sicherheit
Auswählen zwischen IPSec und SSL Auswählen zwischen IPSec und SSL
Verwenden von Farmen und Lastenausgleich Verwenden von Farmen und Lastenausgleich
Zusammenfassung Zusammenfassung

Modulübersicht

In verteilten Anwendungen werden regelmäßig sensible Informationen verarbeitet. Zu diesen Informationen zählen die Anmeldeinformationen für die Benutzerauthentifizierung oder vertrauliche Daten über eine Person wie medizinische Daten oder Informationen zum Beschäftigungsverhältnis. Diese Informationen müssen immer sicher bleiben, unabhängig davon, ob sie in einer Datenbank gespeichert sind oder über ein Netzwerk zwischen Komponenten der verteilten Anwendung übertragen werden.

Die sichere Kommunikation zwischen den Komponenten einer verteilten Webanwendung stellt ein wichtiges Element in der Architektur für eine vertiefte Sicherheit dar. Dies gilt insbesondere dann, wenn die Anwendung öffentliche Netzwerke (wie das Internet) für die Übertragung vertraulicher Informationen verwendet.

In diesem Modul werden die Gründe für eine sichere Kommunikation erläutert und die in ASP.NET-Webanwendungen verfügbaren sicheren Kommunikationstechnologien beschrieben.

 

Zielsetzung

Themenbereiche:

  • Gründe für und Vorgehensweise bei der Sicherung der Netzwerkkommunikation zwischen den unterschiedlichen Ebenen Ihrer verteilten .NET-Webanwendungen

  • Zweck, Möglichkeiten und Grenzen der drei wichtigsten Technologien zur Implementierung der sicheren Kommunikation: SSL/TLS-, IPSec- und RPC-Verschlüsselung

  • Festlegen der geeigneten Verschlüsselung (SSL/TLS, IPSec oder RPC) für die Sicherung der Kommunikation zwischen unterschiedlichen Elementen Ihrer verteilten Webanwendung

 

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

  • Microsoft Internetinformationsdienste (IIS) 5.0 und höher

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

 

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

 

Vorbereitung

Zahlreiche Anwendungen leiten vertrauliche Sicherheitsdaten über Netzwerke an und von Endbenutzern und über Zwischenanwendungsknoten weiter. Zu vertraulichen Daten zählen Anmeldeinformationen für die Authentifizierung oder Daten wie Kreditkartennummern oder Details zu Banktransaktionen. Um die unerwünschte Offenlegung von Informationen zu verhindern und die Daten vor unbefugten Änderungen während der Übertragung zu schützen, muss der Kanal zwischen den Endpunkten der Kommunikation gesichert werden.

Die sichere Kommunikation bietet die beiden folgenden Funktionen:

  • Datenschutz. Der Datenschutz sorgt dafür, dass Daten geheim und vertraulich bleiben und bei Lauschangriffen nicht mit einer Netzwerküberwachungssoftware angezeigt werden können. Datenschutz erfolgt in der Regel durch Verschlüsselung.

  • Integrität. Sichere Kommunikationskanäle müssen auch gewährleisten, dass die Daten bei der Übertragung vor versehentlichen oder absichtlichen (böswilligen) Änderungen geschützt werden. Die Integrität wird normalerweise durch Nachrichtenauthentifizierungscodes (Message Authentication Codes oder MACs) bereitgestellt.

In diesem Modul werden die folgenden sicheren Kommunikationstechnologien behandelt:

  • Secure Sockets Layer/Transport Layer Security (SSL/TLS). Dies ist die am häufigsten eingesetzte Technologie zur Sicherung des Kanals zwischen einem Browser und einem Webserver. Sie kann jedoch auch zur Sicherung von Webdienstnachrichten und Kommunikationsvorgängen an und von einem Datenbankserver verwendet werden, auf dem Microsoft® SQL Server™ 2000 ausgeführt wird.

  • Internet Protocol Security (IPSec). IPSec bietet eine Lösung für die sichere Kommunikation auf der Transportebene und kann verwendet werden, um die Daten zu sichern, die zwischen zwei Computern ausgetauscht werden, beispielsweise zwischen einem Anwendungsserver und einem Datenbankserver.

  • Verschlüsselung durch Remote Procedure Call (RPC oder Remoteprozeduraufruf). Das von Distributed COM (DCOM) verwendete RPC-Protokoll bietet eine Authentifizierungsstufe (Paketsicherheit), die alle zwischen einem Client und einem Server ausgetauschten Datenpakete verschlüsselt.

 

Ermitteln der zu sichernden Daten

Wenn eine Webanforderung über die physischen Bereitstellungsebenen Ihrer Anwendung übermittelt wird, wird sie über mehrere Kommunikationskanäle übertragen. Ein häufig verwendetes Modell für die Bereitstellung von Webanwendungen wird in Abbildung 4.1 dargestellt.

Ein gängiges Modell für die Webbereitstellung

Abbildung 4.1
Ein gängiges Modell für die Webbereitstellung

In diesem gängigen Bereitstellungsmodell wird eine Anforderung über drei unterschiedliche Kanäle übermittelt. Die Verbindung vom Client zum Webserver kann über das Internet oder über das Intranet des Unternehmens erfolgen. Hierfür wird in der Regel HTTP verwendet. Die beiden anderen Verbindungen werden zwischen internen Servern in der Domäne Ihres Unternehmens hergestellt. Dennoch stellen alle drei Verbindungen potenzielle Sicherheitsrisiken dar. Viele rein intranetbasierte Anwendungen übermitteln vertrauliche Sicherheitsdaten zwischen unterschiedlichen Ebenen. Hierbei kann es sich beispielsweise um Human Resources- oder Buchhaltungsanwendungen handeln, in denen vertrauliche Mitarbeiterdaten verarbeitet werden.

In Abbildung 4.2 wird dargestellt, wie die einzelnen Kanäle durch eine Kombination aus SSL-, IPSec- und RPC-Verschlüsselung gesichert werden können.

Ein gängiges Modell für die Webbereitstellung mit sicherer Kommunikation

Abbildung 4.2
Ein gängiges Modell für die Webbereitstellung mit sicherer Kommunikation

Die Auswahl der Technologie hängt von mehreren Faktoren ab. Dazu zählen das Transportprotokoll, die Endpunkttechnologien und umgebungsbezogene Faktoren (wie Hardware, Betriebssystemversionen, Firewalls usw.).

 

SSL/TLS

SSL/TLS wird verwendet, um einen verschlüsselten Kommunikationskanal zwischen Clients und Servern einzurichten. Der für die Erstellung des sicheren Kanals verwendete Handshake-Mechanismus wurde ausführlich dokumentiert. Detaillierte Informationen hierzu finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

Verwenden von SSL

Bei der Verwendung von SSL sollte Ihnen Folgendes bewusst sein:

  • Wenn SSL angewendet wird, verwendet der Client das Protokoll HTTPS (und gibt einen URL an, der mit "https://" beginnt). Darüber hinaus fragt der Server den TCP-Anschluss 443 ab.

  • Wenn Sie SSL aktivieren, sollten Sie die Leistung Ihrer Anwendung überwachen.
    SSL verwendet komplexe kryptografische Funktionen für die Verschlüsselung und Entschlüsselung von Daten. Dadurch wird die Leistung Ihrer Anwendung beeinträchtigt. Die stärkste Leistungsminderung findet während des anfänglichen Handshake statt, bei dem eine asymmetrische Verschlüsselung mit öffentlichem und privatem Schlüssel ausgeführt wird. Anschließend (nach erfolgter Generierung eines sicheren Sitzungsschlüssels und dessen Austausch) wird die schnellere symmetrische Verschlüsselung für die Anwendungsdaten verwendet.

  • Die Seiten, auf denen SSL verwendet wird, sollten optimiert werden, indem darauf weniger Text und einfachere Grafiken verwendet werden.

  • Da der mit SSL verbundene Leistungseinbruch bei der Herstellung der Sitzung am größten ist, müssen Sie sicherstellen, dass für Ihre Verbindungen keine Zeitüberschreitung eintritt.
    Hier können Sie eine Feinabstimmung vornehmen, indem Sie den Wert für den Registrierungseintrag ServerCacheTime erhöhen. Weitere Informationen hierzu finden Sie in Artikel Q247658, "HOW TO: Configure Secure Sockets Layer Server and Client Cache Elements" (englischsprachig) in der Microsoft Knowledge Base.

  • Für SSL ist die Installation eines Serverauthentifizierungszertifikats auf dem Webserver (oder Datenbankserver, falls Sie SSL für die Kommunikation mit SQL Server 2000 verwenden) erforderlich. Weitere Informationen über das Installieren von Serverauthentifizierungszertifikaten finden Sie in diesem Handbuch unter "Vorgehensweise: Einrichten von SSL auf einem Webserver".

 

IPSec

Mit IPSec können die zwischen zwei Computern, z. B. einem Anwendungsserver und einem Datenbankserver, gesendeten Daten gesichert werden. IPSec ist für Anwendungen vollkommen transparent, da Verschlüsselungs-, Integritäts- und Authentifizierungsdienste auf der Transportebene implementiert sind. Die Anwendungen kommunizieren weiterhin in normaler Weise über TCP- und UDP-Anschlüsse.

IPSec zeichnet sich durch die folgenden Merkmale aus:

  • Bereitstellen der Vertraulichkeit von Nachrichten, indem alle zwischen zwei Computern gesendeten Daten verschlüsselt werden.

  • Bereitstellen der Integrität von Nachrichten zwischen zwei Computern (ohne Verschlüsselung der Daten).

  • Bereitstellen einer gegenseitigen Authentifizierung zwischen zwei Computern (nicht Benutzern). Sie können beispielsweise einen Datenbankserver sichern, indem Sie eine Richtlinie erstellen, die Anforderungen nur von einem bestimmten Clientcomputer zulässt (z. B. einer Anwendung oder einem Webserver).

  • Einschränken, welche Computer miteinander kommunizieren können. Die Kommunikation kann auch auf bestimmte IP-Protokolle und TCP/UDP-Anschlüsse beschränkt werden.

Hinweis: IPSec ist nicht als Ersatz für die Sicherheit auf Anwendungsebene gedacht. Es wird als Mechanismus zur Tiefenverteidigung, zum Sichern unsicherer Anwendungen, ohne sie zu ändern, und zum Schutz von Nicht-TLS-Protokollen vor Angriffen aus dem Internet verwendet.

Verwenden von IPSec

Bei der Verwendung von IPSec sollte Ihnen Folgendes bewusst sein:

  • IPSec kann sowohl zur Authentifizierung als auch zur Verschlüsselung verwendet werden.

  • Für Entwickler sind keine IPSec-APIs zur programmatischen Steuerung der Einstellungen vorhanden. IPSec wird vollständig über das IPSec-Snap-In in der MMC für die lokale Sicherheitsrichtlinie gesteuert und konfiguriert.

  • Durch IPSec können im Betriebssystem Microsoft Windows® 2000 nicht alle Typen des IP-Datenverkehrs gesichert werden.
    Es kann insbesondere nicht für die Sicherung von Broadcast-, Multicast-, Internetschlüsselaustausch- oder Kerberos-Datenverkehr (dies ist bereits ein sicheres Protokoll) verwendet werden.

    Weitere Informationen hierzu finden Sie in Artikel Q253169, "Traffic That Can--and Cannot--Be Secured by IPSec" (englischsprachig) in der Microsoft Knowledge Base.

  • Verwenden Sie IPSec-Filter, um zu steuern, wann IPSec angewendet werden soll.
    Verwenden Sie IPSec Monitor zum Testen der IPSec-Richtlinien. IPSec Monitor (Ipsecmon.exe) stellt Informationen dazu bereit, welche IPSec-Richtlinie aktiv ist und ob ein sicherer Kanal zwischen den Computern erstellt wurde.

    Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln:

  • Zur Herstellung eines Vertrauensverhältnisses zwischen zwei Servern kann IPSec mit gegenseitiger Authentifizierung verwendet werden. Dabei werden Zertifikate für die Authentifizierung beider Computer verwendet.

    Weitere Informationen finden Sie in den folgenden Microsoft Knowledge Base-Artikeln:

  • Wenn Sie IPSec verwenden müssen, um die Kommunikation zwischen zwei Computern zu sichern, die durch eine Firewall voneinander getrennt sind, sollten Sie sicherstellen, dass die Firewall nicht NAT (Network Address Translation) verwendet. IPSec kann nicht mit NAT-basierten Geräten verwendet werden.

    Weitere Informationen hierzu und die einzelnen Konfigurationsschritte finden Sie in Artikel Q233256, "HOW TO Enable IPSec Traffic through a Firewall" (englischsprachig) in der Microsoft Knowledge Base und im Abschnitt "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern" in diesem Handbuch.

 

RPC-Verschlüsselung

RPC ist der von DCOM verwendete zugrunde liegende Transportmechanismus. RPC stellt eine Reihe konfigurierbarer Authentifizierungsstufen bereit, die von keiner Authentifizierung (ohne Datenschutz) bis zur vollständigen Verschlüsselung des Parameterstatus reichen.

Bei der sichersten Stufe (RPC-Paketdatensicherheit) wird der Parameterstatus für jeden Remoteprozeduraufruf (und dadurch auch jeden DCOM-Methodenaufruf) verschlüsselt. Die Stufe der RPC-Verschlüsselung, 40-Bit bzw. 128-Bit, ist von der Version des Windows-Betriebssytems abhängig, das auf den Client- und Servercomputern ausgeführt wird.

Verwenden der RPC-Verschlüsselung

In der Regel verwenden Sie die RPC-Verschlüsselung, wenn Ihre webbasierte Anwendung mit Serviced Components (innerhalb der Enterprise Services-Serveranwendungen) kommuniziert, die sich auf Remotecomputern befinden.

In diesem Fall müssen Sie sowohl den Client als auch den Server konfigurieren, um die Authentifizierung mit RPC-Paketdatensicherheit (und Verschlüsselung) verwenden zu können. Der Client und der Server handeln dabei Obergrenzen aus, die sicherstellen, dass die höheren der beiden (Client- und Server-) Einstellungen verwendet werden.

Die Servereinstellungen können Sie auf der Anwendungsebene (Enterprise Services) definieren, indem Sie entweder .NET-Attribute innerhalb der Serviced Component-Assembly verwenden oder zum Zeitpunkt der Bereitstellung das Verwaltungsprogramm für Komponentendienste nutzen.

Wenn der Client eine ASP.NET-Webanwendung oder ein Webdienst ist, wird die vom Client angewendete Authentifizierungsstufe über das Attribut comAuthenticationLevel für das Element <processModel> in Machine.config konfiguriert. Dadurch wird die Standardauthentifizierungsstufe für alle ASP.NET-Anwendungen bereitgestellt, die auf dem Webserver ausgeführt werden.

Weitere Informationen

Weitere Informationen zur Aushandlung der RPC-Authentifizierungsstufe und zur Konfiguration von Dienstkomponenten finden Sie in Modul 9, "Enterprise Services-Sicherheit".

 

Point-to-Point-Sicherheit

Point-to-Point-Kommunikationsszenarios lassen sich grob den folgenden Themen zuordnen:

  • Browser zu Webserver

  • Webserver zu Remote-Anwendungsserver

  • Anwendungsserver zu Datenbankserver

Browser zu Webserver

Um vertrauliche Daten zu sichern, die von einem Browser an einen Webserver gesendet werden, verwenden Sie SSL. SSL muss in folgenden Situationen verwendet werden:

  • Sie verwenden die Formularauthentifizierung und müssen die in Klartext vorliegenden Anmeldeinformationen schützen, die über ein Anmeldeformular an einen Webserver gesendet werden.
    In diesem Szenario sollten Sie SSL verwenden, um den Zugriff auf alle Seiten (nicht nur auf die Anmeldeseite) zu sichern und zu gewährleisten, dass das Authentifizierungs-Cookie, das im Rahmen des anfänglichen Authentifizierungsprozesses generiert wird, über die gesamte Dauer der Browsersitzung des Clients sicher bleibt.

  • Sie verwenden die Standardauthentifizierung und müssen die in Klartext vorliegenden (Base64-codierten) Anmeldeinformationen schützen.
    Sie sollten SSL verwenden, um den Zugriff auf alle Seiten (nicht nur auf die Anmeldeseite) zu sichern, da bei der Standardauthentifizierung die Anmeldeinformationen in Klartext zusammen mit allen Anforderungen für die Anwendung (nicht nur mit der anfänglichen) an den Webserver gesendet werden.

    Hinweis: Base64 wird verwendet, um Binärdaten als druckbaren ASCII-Text zu codieren. Im Gegensatz zur Verschlüsselung wird dadurch die Integrität oder der Datenschutz der Nachricht nicht gewährleistet.

  • Ihre Anwendung leitet vertrauliche Daten zwischen dem Browser und dem Webserver (und umgekehrt) weiter, beispielsweise Kreditkartennummern oder Informationen zu Bankkonten.

Webserver zu Remote-Anwendungsserver

Der Transportkanal zwischen einem Webserver und einem Remote-Anwendungsserver sollte mithilfe der IPSec-, SSL- oder RPC-Verschlüsselung gesichert werden. Die Auswahl ist von den Transportprotokollen und von umgebungsbezogenen Faktoren (Betriebssystemversionen, Firewalls usw.) abhängig.

  • Enterprise Services. Wenn Ihr Remoteserver als Host für eine oder mehrere Serviced Components (in einer Enterprise Services-Serveranwendung) fungiert und Sie mit DCOM eine direkte Kommunikation herstellen, verwenden Sie die Verschlüsselung für die RPC-Paketdatensicherheit.

    Weitere Informationen zur Konfiguration der RPC-Verschlüsselung zwischen einer Webanwendung und einer Remote-Serviced Component finden Sie in Modul 9, "Enterprise Services-Sicherheit".

  • Webdienste. Wenn Ihr Remoteserver als Host für einen Webdienst fungiert, haben Sie die Wahl zwischen IPSec und SSL.
    In der Regel sollten Sie SSL auswählen, da der Webdienst den HTTP-Transport bereits verwendet. Zudem ermöglicht SSL, nur die Daten zu verschlüsseln, die an den Webdienst bzw. vom Webdienst aus gesendet werden (es muss also nicht der gesamte zwischen zwei Computern ausgetauschte Datenverkehr verschlüsselt werden). Mit IPSec wird der gesamte Datenverkehr zwischen den beiden Computern verschlüsselt.

    Hinweis: Die Sicherheit auf der Nachrichtenebene (einschließlich Datenverschlüsselung) wird von der Initiative Global XML Web Services Architecture (GXA) und insbesondere durch die WS-Sicherheitsspezifikation gewährleistet. Microsoft stellt das Web Services Development Toolkit bereit, damit Sie Lösungen für die Sicherheit auf der Nachrichtenebene entwickeln können. Dieses Toolkit steht unter https://msdn.microsoft.com/webservices/building/wsdk/ zum Download zur Verfügung.

  • .NET-Komponenten (mit .NET Remoting). Wenn der Remoteserver als Host für eine oder mehrere .NET-Komponenten fungiert und über den TCP-Kanal eine Verbindung zu diesen Komponenten herstellt, können Sie mithilfe von IPSec eine sichere Kommunikationsverbindung bereitstellen. Wenn ASP.NET als Host für die .NET-Komponenten fungiert, können Sie SSL verwenden (Konfiguration mit IIS).

Anwendungsserver zu Datenbankserver

Um die Daten zu sichern, die zwischen einem Anwendungsserver und einem Datenbankserver übertragen werden, können Sie IPSec verwenden. Wenn auf dem Datenbankserver SQL Server 2000 ausgeführt wird (und die SQL Server 2000-Netzwerkbibliotheken auf dem Anwendungsserver installiert sind), können Sie SSL verwenden. Bei der letzten Option muss im Speicher des Datenbankservercomputers ein Serverauthentifizierungszertifikat installiert sein.

Die Sicherung der Verbindung zum Datenbankserver kann in folgenden Situationen erforderlich sein:

  • Sie stellen eine Verbindung zum Datenbankserver her und verwenden keine Windows-Authentifizierung. Sie verwenden beispielsweise die SQL-Authentifizierung bei SQL Server oder stellen eine Verbindung zu einer anderen Datenbank als SQL Server her. In diesen Fällen werden die Anmeldeinformationen unverschlüsselt übertragen, sodass ein erhebliches Sicherheitsrisiko entstehen kann.

    Hinweis: Einer der Hauptvorteile der Windows-Authentifizierung bei SQL Server liegt darin, dass die Anmeldeinformationen niemals über das Netzwerk übertragen werden. Weitere Informationen zur SQL Server-Authentifizierung finden Sie in Modul 12, "Datenzugriffssicherheit".

  • Die Anwendung sendet und empfängt vertrauliche Daten von der Datenbank (z. B. Gehaltsinformationen).

Verwenden von SSL zu SQL Server

Berücksichtigen Sie die folgenden Punkte, wenn Sie den Kanal zu einer SQL Server-Datenbank mit SSL sichern:

  • Damit SSL funktioniert, müssen Sie im Computerspeicher des Datenbankservercomputers ein Serverauthentifizierungszertifikat speichern. Darüber hinaus muss der Clientcomputer über ein Stammzertifikat derselben (bzw. einer vertrauenden) Zertifizierungsstelle verfügen, von der das Serverzertifikat ausgestellt wurde.

  • Auf den Clients müssen die SQL Server 2000-Verbindungsbibliotheken installiert sein. Frühere Versionen oder generische Bibliotheken funktionieren nicht.

  • SSL funktioniert nur für TCP/IP (das empfohlene Kommunikationsprotokoll für SQL Server) und Named Pipes.

  • Sie können den Server so konfigurieren, dass die Verwendung der Verschlüsselung für alle Verbindungen (von allen Clients) erzwungen wird.

  • Auf dem Client bestehen die folgenden Möglichkeiten:

    • Erzwingen der Verschlüsselung für alle ausgehenden Verbindungen.

    • Clientanwendungen sollen anhand der Verbindungszeichenfolge auswählen, ob sie die Verschlüsselung für einzelne Verbindungen verwenden.

  • Im Gegensatz zu IPSec sind mit SSL keine Konfigurationsänderungen erforderlich, wenn sich die IP-Adressen von Clients oder Servern ändern.

Weitere Informationen

Weitere Informationen zur Verwendung von SSL beim SQL Server finden Sie in den folgenden Ressourcen:

 

Auswählen zwischen IPSec und SSL

Beachten Sie bei der Wahl zwischen IPSec und SSL die folgenden Punkte:

  • Mit IPSec kann der gesamte IP-Datenverkehr zwischen Computern gesichert werden; SSL gilt für eine einzelne Anwendung.

  • Bei IPSec handelt es sich um eine für den gesamten Computer geltende Einstellung, die nicht die ausschließliche Verschlüsselung spezieller Netzwerkverbindungen unterstützt. Die Sites können jedoch so partitioniert werden, dass SSL verwendet wird oder nicht. Wenn Sie SSL für Verbindungen zum SQL Server verwenden, können Sie weiterhin für einzelne Verbindungen (von der Clientanwendung) auswählen, ob SSL genutzt werden soll.

  • IPSec verhält sich Anwendungen gegenüber transparent; es kann daher zusammen mit sicheren Protokollen verwendet werden, die oberhalb von IP liegen, wie HTTP, FTP und SMTP. SSL/TLS hingegen ist eng an die Anwendung gebunden.

  • IPSec lässt sich neben der Verschlüsselung auch für die Authentifizierung von Computern verwenden. Dies ist insbesondere für Szenarios mit vertrauenswürdigen Subsystemen von Bedeutung, in denen die Datenbank eine feste Identität einer bestimmten Anwendung (die auf einem bestimmten Computer ausgeführt wird) autorisiert. Mit IPSec stellen Sie sicher, dass nur der jeweilige Anwendungsserver eine Verbindung zum Datenbankserver herstellen kann, um Angriffe von anderen Computern zu verhindern.

  • Bei der Verwendung von IPSec muss auf beiden Computern Windows 2000 oder höher installiert sein.

  • SSL kann im Gegensatz zu IPSec über eine NAT-basierte Firewall hinweg verwendet werden.

 

Verwenden von Farmen und Lastenausgleich

Wenn Sie SSL zusammen mit mehreren virtuellen Websites verwenden, müssen Sie eindeutige IP-Adressen oder eindeutige Anschlussnummern verwenden. Sie können nicht mehrere Websites mit derselben IP-Adresse und derselben Anschlussnummer verwenden. Bei einem Lastenausgleich können Sie die IP-Adresse problemlos mit der Serveraffinitätseinstellung kombinieren.

Weitere Informationen

Weitere Informationen hierzu finden Sie in Artikel Q187504, "HTTP 1.1 Host Headers Are Not Supported When You Use SSL" (englischsprachig) in der Microsoft Knowledge Base.

 

Zusammenfassung

In diesem Modul wurde beschrieben, wie mit einer Kombination aus SSL-, IPSec- und RPC-Verschlüsselung eine durchgehend sichere Kommunikationslösung für verteilte Anwendungen bereitgestellt werden kann. Zusammengefasst:

  • Die Kanalsicherheit ist für Daten von Bedeutung, die über das Internet und im Firmenintranet übertragen werden.

  • Berücksichtigen Sie die Sicherheitsanforderungen der Verbindungen vom Webbrowser zum Webserver, vom Webserver zum Anwendungsserver und vom Anwendungsserver zum Datenbankserver.

  • Eine sichere Kommunikation sorgt für Datensicherheit und Integrität. Sie schützt jedoch nicht vor der Ablehnung (verwenden Sie hierfür Zertifikate).

  • Als Optionen für die Kanalsicherheit stehen die SSL-, die IPSec- und die RPC-Verschlüsselung zur Verfügung. Die letzte Option trifft zu, wenn die Anwendung DCOM für die Kommunikation mit Remote-Serviced Components verwendet.

  • Wenn Sie SSL für die Kommunikation mit SQL Server verwenden, kann die Anwendung für einzelne Verbindungen auswählen, ob sie verschlüsselt werden sollen.

  • IPSec verschlüsselt den gesamten IP-Datenverkehr zwischen zwei Computern.

  • Die Auswahl des Sicherheitsmechanismus ist abhängig vom Transportprotokoll, den Betriebssystemversionen und den Netzwerkgegebenheiten (z. B. Firewalls).

  • Zwischen sicherer Kommunikation und Leistung muss immer ein Kompromiss gefunden werden. Wählen Sie die für die Anforderungen geeignete Sicherheitsstufe aus.