Freigeben über

Sichern von Diensten

Die Sicherheit eines Windows Communication Foundation (WCF)-Diensts besteht aus zwei hauptanforderungen: Übertragungssicherheit und Autorisierung. (Eine dritte Anforderung, Überwachung von Sicherheitsereignissen, wird in der Überwachung beschrieben.) Kurz gesagt umfasst die Übertragungssicherheit die Authentifizierung (Überprüfen der Identität des Diensts und des Clients), vertraulichkeit (Nachrichtenverschlüsselung) und Integrität (digitale Signatur zur Erkennung von Manipulationen). Die Autorisierung ist die Steuerung des Zugriffs auf Ressourcen, z. B. das Zulassen, dass nur privilegierte Benutzer eine Datei lesen können. Mithilfe von Features von WCF sind die beiden primären Anforderungen einfach implementiert.

Mit Ausnahme der BasicHttpBinding Klasse (oder des <basicHttpBinding-Elements> in der Konfiguration) ist die Übertragungssicherheit für alle vordefinierten Bindungen standardmäßig aktiviert. Die Themen in diesem Abschnitt umfassen zwei grundlegende Szenarien: Implementieren von Übertragungssicherheit und Autorisierung für einen Intranetdienst, der in Internetinformationsdienste (INTERNET Information Services, IIS) gehostet wird, und Implementieren von Übertragungssicherheit und Autorisierung für einen in IIS gehosteten Dienst.

Sicherheitsgrundlagen

Sicherheit basiert auf Anmeldeinformationen. Ein Nachweis beweist, dass eine Entität diejenige ist, als die sie sich ausgibt. (Eine Entität kann eine Person, ein Softwareprozess, ein Unternehmen oder alles sein, was autorisiert werden kann.) Beispielsweise stellt ein Client eines Diensts einen Identitätsanspruch dar, und die Anmeldeinformationen belegen, dass dieser Anspruch in irgendeiner Weise besteht. In einem typischen Szenario tritt ein Austausch von Anmeldeinformationen auf. Ein Dienst macht einen Identitätsanspruch geltend und beweist dem Client seine Identität mit einem Nachweis. Umgekehrt erklärt der Client einen Identitätsanspruch und legt dem Dienst seine Anmeldeinformationen vor. Wenn beide Parteien den Anmeldeinformationen des anderen vertrauen, kann ein sicherer Kontext eingerichtet werden, in dem alle Nachrichten vertraulich ausgetauscht werden, und alle Nachrichten werden signiert, um ihre Integrität zu schützen. Nachdem der Dienst die Identität des Clients eingerichtet hat, kann er die Ansprüche in den Anmeldeinformationen mit einer Rolle oder Mitgliedschaft in einer Gruppe abgleichen. In beiden Fällen autorisiert der Dienst mithilfe der Rolle oder der Gruppe, zu der der Client gehört, einen begrenzten Satz von Vorgängen basierend auf den Rollen- oder Gruppenrechten auszuführen.

Windows-Sicherheitsmechanismen

Wenn sich der Client und der Dienstcomputer beide in einer Windows-Domäne befinden, für die sich beide beim Netzwerk anmelden müssen, werden die Anmeldeinformationen von der Windows-Infrastruktur bereitgestellt. In diesem Fall werden die Anmeldeinformationen eingerichtet, wenn sich ein Computerbenutzer beim Netzwerk anmeldet. Jeder Benutzer und jeder Computer im Netzwerk muss als Teil der vertrauenswürdigen Gruppe von Benutzern und Computern validiert werden. Auf einem Windows-System werden jeder derartige Benutzer und Computer auch als Sicherheitsprinzipalbezeichnet.

Auf einer Windows-Domäne, die von einem Kerberos-Controller unterstützt wird, verwendet der Kerberos-Controller ein Schema, das auf der Gewährung von Tickets für jeden Sicherheitsprinzipal basiert. Die Tickets, die der Controller gewährt, werden von anderen Ticketern im System als vertrauenswürdig eingestuft. Jedes Mal, wenn eine Entität versucht, einen Vorgang auszuführen oder auf eine Ressource zuzugreifen (z. B. eine Datei oder ein Verzeichnis auf einem Computer), wird das Ticket auf seine Gültigkeit überprüft und, wenn sie besteht, dem Prinzipal ein weiteres Ticket für den Vorgang gewährt. Diese Methode der Ticketgewährung ist effizienter als die Überprüfung des Prinzipals bei jedem Vorgang.

Ein älterer, weniger sicherer Mechanismus für Windows-Domänen ist NT LAN Manager (NTLM). In Fällen, in denen Kerberos nicht verwendet werden kann (in der Regel außerhalb einer Windows-Domäne, z. B. in einer Arbeitsgruppe), kann NTLM als Alternative verwendet werden. NTLM ist auch als Sicherheitsoption für IIS verfügbar.

Auf einem Windows-System funktioniert die Autorisierung, indem jedem Computer und Benutzer eine Reihe von Rollen und Gruppen zugewiesen wird. Beispielsweise muss jeder Windows-Computer in der Rolle des Administrators von einer Person (oder Gruppe von Personen) eingerichtet und gesteuert werden. Eine weitere Rolle ist die des Benutzers, der über einen viel eingeschränkteren Satz von Berechtigungen verfügt. Zusätzlich zur Rolle werden Benutzern Gruppen zugewiesen. Eine Gruppe ermöglicht mehreren Benutzern die Ausführung in derselben Rolle. Daher wird ein Windows-Computer in der Praxis durch Zuweisen von Benutzern zu Gruppen verwaltet. Beispielsweise können mehrere Benutzer der Gruppe von Benutzern eines Computers zugewiesen werden, und eine viel eingeschränktere Gruppe von Benutzern kann der Gruppe der Administratoren zugewiesen werden. Auf einem lokalen Computer kann ein Administrator auch neue Gruppen erstellen und der Gruppe andere Benutzer (oder sogar andere Gruppen) zuweisen.

Auf einem Computer unter Windows kann jeder Ordner in einem Verzeichnis geschützt werden. Das heißt, Sie können einen Ordner auswählen und steuern, wer auf die Dateien zugreifen kann, und ob sie die Datei kopieren oder (im privilegiertesten Fall) eine Datei ändern, eine Datei löschen oder dem Ordner Dateien hinzufügen können. Dies wird als Zugriffssteuerung bezeichnet, und der Mechanismus dafür wird als Zugriffssteuerungsliste (Access Control List, ACL) bezeichnet. Beim Erstellen der ACL können Sie allen Gruppen oder Gruppen Sowie einzelnen Mitgliedern einer Domäne Zugriffsberechtigungen zuweisen.

Die WCF-Infrastruktur wurde entwickelt, um diese Windows-Sicherheitsmechanismen zu verwenden. Wenn Sie also einen Dienst erstellen, der in einem Intranet bereitgestellt wird und deren Clients auf Mitglieder der Windows-Domäne beschränkt sind, ist die Sicherheit einfach implementiert. Nur gültige Benutzer können sich bei der Domäne anmelden. Nachdem Benutzer angemeldet sind, ermöglicht der Kerberos-Controller jedem Benutzer, sichere Kontexte mit jedem anderen Computer oder einer anderen Anwendung einzurichten. Auf einem lokalen Computer können Gruppen einfach erstellt werden, und beim Schützen bestimmter Ordner können diese Gruppen verwendet werden, um Zugriffsberechtigungen auf dem Computer zuzuweisen.

Implementieren von Windows-Sicherheit für Intranetdienste

Um eine Anwendung zu sichern, die ausschließlich in einer Windows-Domäne ausgeführt wird, können Sie die Standardsicherheitseinstellungen der WSHttpBinding-Bindung oder der NetTcpBinding-Bindung verwenden. Standardmäßig kann jeder in derselben Windows-Domäne auf WCF-Dienste zugreifen. Da sich diese Benutzer beim Netzwerk angemeldet haben, sind sie vertrauenswürdig. Die Nachrichten zwischen einem Dienst und einem Client werden zur Vertraulichkeit verschlüsselt und für die Integrität signiert. Weitere Informationen zum Erstellen eines Diensts, der Windows-Sicherheit verwendet, finden Sie unter How to: Secure a Service with Windows Credentials.

Autorisierung mithilfe der PrincipalPermissionAttribute-Klasse

Wenn Sie den Zugriff auf Ressourcen auf einem Computer einschränken müssen, besteht die einfachste Möglichkeit darin, die PrincipalPermissionAttribute Klasse zu verwenden. Mit diesem Attribut können Sie den Aufruf von Dienstvorgängen einschränken, indem Sie verlangen, dass sich der Benutzer in einer bestimmten Windows-Gruppe oder -Rolle befindet oder ein bestimmter Benutzer ist. Weitere Informationen finden Sie unter How to: Restrict Access with the PrincipalPermissionAttribute Class.

Nachahmung

Identitätswechsel ist ein weiterer Mechanismus, mit dem Sie den Zugriff auf Ressourcen steuern können. Standardmäßig wird ein von IIS gehosteter Dienst unter der Identität des ASPNET-Kontos ausgeführt. Das ASPNET-Konto kann nur auf die Ressourcen zugreifen, für die es über die Berechtigung verfügt. Es ist jedoch möglich, die ACL für einen Ordner so festzulegen, dass das ASPNET-Dienstkonto ausgeschlossen wird, aber bestimmte andere Identitäten auf den Ordner zugreifen können. Die Frage wird dann, wie diese Benutzer auf den Ordner zugreifen können, wenn das ASPNET-Konto dies nicht gestattet. Dies wird durch den Identitätswechsel ermöglicht, bei dem der Dienst die Anmeldeinformationen des Clients für den Zugriff auf eine bestimmte Ressource verwenden darf. Ein weiteres Beispiel ist der Zugriff auf eine SQL Server-Datenbank, für die nur bestimmte Benutzer über die Berechtigung verfügen. Weitere Informationen zur Verwendung des Identitätswechsels finden Sie unter Vorgehensweise: Annahme der Clientidentität durch einen Dienst und Delegierung und Identitätswechsel.

Sicherheit im Internet

Sicherheit im Internet besteht aus den gleichen Anforderungen wie Sicherheit in einem Intranet. Ein Dienst muss seine Anmeldeinformationen präsentieren, um seine Authentizität zu beweisen, und Clients müssen ihre Identität für den Dienst nachweisen. Sobald die Identität eines Clients nachgewiesen wurde, kann der Dienst steuern, wie viel Zugriff der Client auf Ressourcen hat. Aufgrund der heterogenen Natur des Internets unterscheiden sich die dargestellten Anmeldeinformationen jedoch von denen, die in einer Windows-Domäne verwendet werden. Während ein Kerberos-Controller die Authentifizierung von Benutzern in einer Domäne mit Tickets für Anmeldeinformationen verarbeitet, nutzen Dienste und Clients im Internet eine der mehreren verschiedenen Möglichkeiten zur Angabe von Anmeldeinformationen. Ziel dieses Themas ist es jedoch, einen gemeinsamen Ansatz darzustellen, mit dem Sie einen WCF-Dienst erstellen können, auf den im Internet zugegriffen werden kann.

Verwenden von IIS und ASP.NET

Die Anforderungen an die Internetsicherheit und die Mechanismen zur Lösung dieser Probleme sind nicht neu. IIS ist der Webserver von Microsoft für das Internet und verfügt über viele Sicherheitsfeatures, die diese Probleme beheben; darüber hinaus umfasst ASP.NET Sicherheitsfeatures, die WCF-Dienste verwenden können. Um diese Sicherheitsfeatures nutzen zu können, hosten Sie einen WCF-Dienst in IIS.

Verwenden von ASP.NET Mitgliedschafts- und Rollenanbietern

ASP.NET umfasst einen Mitgliedschafts- und Rollenanbieter. Der Anbieter ist eine Datenbank mit Benutzernamen-/Kennwortpaaren für die Authentifizierung von Anrufern, mit denen Sie auch die Zugriffsberechtigungen jedes Anrufers angeben können. Mit WCF können Sie problemlos einen bereits vorhandenen Mitgliedschafts- und Rollenanbieter über die Konfiguration verwenden. Eine Beispielanwendung, die dies veranschaulicht, finden Sie im Beispiel " Mitgliedschafts- und Rollenanbieter" .

Von IIS verwendete Anmeldeinformationen

Im Gegensatz zu einer Windows-Domäne, die von einem Kerberos-Controller unterstützt wird, ist das Internet eine Umgebung ohne einen einzelnen Controller, um die Millionen von Benutzern zu verwalten, die sich jederzeit anmelden. Stattdessen befinden sich Anmeldeinformationen im Internet am häufigsten in Form von X.509-Zertifikaten (auch als Secure Sockets Layer oder SSL, Zertifikate bezeichnet). Diese Zertifikate werden in der Regel von einer Zertifizierungsstelle ausgestellt, die ein Drittanbieterunternehmen sein kann, das für die Echtheit des Zertifikats und die Person, an die es ausgestellt wurde, verfügt. Um Ihren Dienst im Internet verfügbar zu machen, müssen Sie auch ein solches vertrauenswürdiges Zertifikat bereitstellen, um Ihren Dienst zu authentifizieren.

Die Frage stellt sich an diesem Punkt, wie erhalten Sie ein solches Zertifikat? Ein Ansatz besteht darin, zu einer Drittanbieterzertifizierungsstelle zu wechseln, z. B. Authenticode oder VeriSign, wenn Sie bereit sind, Ihren Dienst bereitzustellen und ein Zertifikat für Ihren Dienst zu erwerben. Wenn Sie sich jedoch in der Entwicklungsphase mit WCF befinden und noch nicht bereit sind, ein Zertifikat zu erwerben, gibt es Tools und Techniken zum Erstellen von X.509-Zertifikaten, die Sie zum Simulieren einer Produktionsbereitstellung verwenden können. Weitere Informationen finden Sie unter Arbeiten mit Zertifikaten.

Sicherheitsmodi

Die Programmierung der WCF-Sicherheit beinhaltet einige wichtige Entscheidungspunkte. Einer der grundlegendsten ist die Wahl des Sicherheitsmodus. Die beiden wichtigsten Sicherheitsmodi sind Transportmodus und Nachrichtenmodus.

Ein dritter Modus, der die Semantik beider Hauptmodi kombiniert, ist der Transportmodus mit Nachrichtenauthentifizierung.

Der Sicherheitsmodus bestimmt, wie Nachrichten gesichert werden, und jede Auswahl hat Vor- und Nachteile, wie unten erläutert. Weitere Informationen zum Festlegen des Sicherheitsmodus finden Sie unter How to: Set the Security Mode.

Transportmodus

Es gibt mehrere Ebenen zwischen dem Netzwerk und der Anwendung. Eine davon ist die Transportschicht *,* die die Übertragung von Nachrichten zwischen Endpunkten verwaltet. Für den vorliegenden Zweck ist es nur erforderlich, dass Sie verstehen, dass WCF mehrere Transportprotokolle verwendet, von denen jeder die Übertragung von Nachrichten sichern kann. (Weitere Informationen zu Transporten finden Sie unter Transporte.)

Ein häufig verwendetes Protokoll ist HTTP; ein weiteres ist TCP. Jedes dieser Protokolle kann die Nachrichtenübertragung durch einen Mechanismus (oder Mechanismen) sichern, der speziell für das Protokoll gilt. Beispielsweise wird das HTTP-Protokoll mit SSL über HTTP gesichert, häufig als "HTTPS" abgekürzt. Wenn Sie den Transportmodus für die Sicherheit auswählen, entscheiden Sie sich daher dafür, den Mechanismus wie vom Protokoll vorgegeben zu verwenden. Wenn Sie beispielsweise die WSHttpBinding Klasse auswählen und den Sicherheitsmodus auf "Transport" festlegen, wählen Sie SSL über HTTP (HTTPS) als Sicherheitsmechanismus aus. Der Vorteil des Transportmodus besteht darin, dass er effizienter ist als der Nachrichtenmodus, da die Sicherheit auf einem vergleichsweise niedrigen Niveau integriert ist. Bei Der Verwendung des Transportmodus muss der Sicherheitsmechanismus gemäß der Spezifikation für den Transport implementiert werden, und damit können Nachrichten sicher nur von Punkt zu Punkt über den Transport fließen.

Nachrichtenmodus

Im Gegensatz dazu bietet der Nachrichtenmodus Sicherheit, indem die Sicherheitsdaten als Teil jeder Nachricht eingeschlossen werden. Mit XML- und SOAP-Sicherheitsheadern werden die Anmeldeinformationen und anderen Daten, die erforderlich sind, um die Integrität und Vertraulichkeit der Nachricht sicherzustellen, jeder Nachricht beigefügt. Jede Nachricht enthält Sicherheitsdaten, sodass es zu einer Belastung der Leistung führt, da jede Nachricht einzeln verarbeitet werden muss. (Im Transportmodus fließen alle Nachrichten frei, sobald die Transportschicht gesichert ist.) Die Nachrichtensicherheit hat jedoch einen Vorteil gegenüber der Transportsicherheit: Sie ist flexibler. Das heißt, die Sicherheitsanforderungen werden nicht vom Transport bestimmt. Sie können beliebige Client-Anmeldedaten verwenden, um die Nachricht zu sichern. (Im Transportmodus bestimmt das Transportprotokoll den Typ der Clientanmeldeinformationen, die Sie verwenden können.)

Transport mit Nachrichtenanmeldeinformationen

Der dritte Modus kombiniert das Beste aus Transport- und Nachrichtensicherheit. In diesem Modus wird die Transportsicherheit verwendet, um die Vertraulichkeit und Integrität jeder Nachricht effizient sicherzustellen. Gleichzeitig enthält jede Nachricht ihre Anmeldeinformationen, wodurch die Nachricht authentifiziert werden kann. Mit der Authentifizierung kann auch die Autorisierung implementiert werden. Durch die Authentifizierung eines Absenders kann der Zugriff auf Ressourcen gemäß der Identität des Absenders gewährt (oder verweigert werden).

Angeben des Client-Anmeldedatentyps und des Anmeldedatenwerts

Nachdem Sie einen Sicherheitsmodus ausgewählt haben, können Sie auch einen Clientanmeldeinformationstyp angeben. Der Clientanmeldeinformationstyp gibt an, welchen Typ ein Client verwenden muss, um sich selbst beim Server zu authentifizieren.

Allerdings erfordern nicht alle Szenarien einen Clientanmeldeinformationstyp. Mithilfe von SSL über HTTP (HTTPS) authentifiziert sich ein Dienst für den Client. Im Rahmen dieser Authentifizierung wird das Zertifikat des Diensts in einem Prozess, der als Aushandlung bezeichnet wird, an den Client gesendet. Der SSL-gesicherte Transport stellt sicher, dass alle Nachrichten vertraulich sind.

Wenn Sie einen Dienst erstellen, der erfordert, dass der Client authentifiziert wird, hängt die Auswahl eines Clientanmeldeinformationstyps vom ausgewählten Transport und Modus ab. Wenn Sie beispielsweise den HTTP-Transport verwenden und den Transportmodus auswählen, stehen Ihnen verschiedene Optionen zur Verfügung, z. B. "Einfach", "Digest" und andere. (Weitere Informationen zu diesen Anmeldeinformationstypen finden Sie unter Grundlegendes zur HTTP-Authentifizierung.)

Wenn Sie einen Dienst in einer Windows-Domäne erstellen, der nur für andere Benutzer des Netzwerks verfügbar ist, ist die einfachste Verwendung der Windows-Clientanmeldeinformationstyp. Möglicherweise müssen Sie jedoch auch einen Dienst mit einem Zertifikat bereitstellen. Dieser Vorgang wird in How to: Specify Client Credential Valuesbeschrieben.

Anmeldeinformationswerte

Ein Berechtigungswert ist die tatsächliche Berechtigung, die der Dienst verwendet. Nachdem Sie einen Anmeldeinformationstyp angegeben haben, müssen Sie Ihren Dienst möglicherweise auch mit den tatsächlichen Anmeldeinformationen konfigurieren. Wenn Sie Windows ausgewählt haben (und der Dienst in einer Windows-Domäne ausgeführt wird), geben Sie keinen tatsächlichen Anmeldeinformationswert an.

Identität

In WCF hat der Begriff Identität unterschiedliche Bedeutungen für den Server und den Client. Kurz gesagt wird beim Ausführen eines Diensts nach der Authentifizierung eine Identität dem Sicherheitskontext zugewiesen. Um die tatsächliche Identität anzuzeigen, überprüfen Sie die WindowsIdentity und PrimaryIdentity Eigenschaften der ServiceSecurityContext Klasse. Weitere Informationen finden Sie unter How to: Examine the Security Context.

Im Gegensatz dazu wird auf dem Client die Identität verwendet, um den Dienst zu überprüfen. Zur Entwurfszeit kann ein Cliententwickler das <Identitätselement> auf einen Wert festlegen, der vom Dienst abgerufen wird. Zur Laufzeit überprüft der Client den Wert des Elements anhand der tatsächlichen Identität des Diensts. Wenn die Überprüfung fehlschlägt, beendet der Client die Kommunikation. Der Wert kann ein Benutzerprinzipalname (User Principal Name, UPN) sein, wenn der Dienst unter der Identität eines bestimmten Benutzers oder einem Dienstprinzipalnamen (Service Principal Name, SPN) ausgeführt wird, wenn der Dienst unter einem Computerkonto ausgeführt wird. Weitere Informationen finden Sie unter Dienstidentität und Authentifizierung. Die Anmeldeinformationen können auch ein Zertifikat oder ein Feld auf einem Zertifikat sein, mit dem das Zertifikat identifiziert wird.

Schutzebenen

Die ProtectionLevel Eigenschaft tritt für mehrere Attributklassen auf (z. B. die ServiceContractAttribute Und die OperationContractAttribute Klassen). Die Schutzebene ist ein Wert, der angibt, ob die Nachrichten (oder Nachrichtenteile), die einen Dienst unterstützen, signiert, signiert und verschlüsselt oder ohne Signaturen oder Verschlüsselung gesendet werden. Weitere Informationen zur Eigenschaft finden Sie unter Understanding Protection Level und für Programmierbeispiele unter How to: Set the ProtectionLevel Property. Weitere Informationen zum Entwerfen eines Servicevertrags im ProtectionLevel Kontext finden Sie unter Entwerfen von Serviceverträgen.

Siehe auch

  • Last updated on