Sicherheitsübersicht

Das Sicherheitsframework in der Windows-Webdienst-API (WWSAPI) bietet Folgendes:

• Nachrichtenintegrität, Vertraulichkeit, Wiedergabeerkennung und Serverauthentifizierung mithilfe der Transportsicherheit.
• Clientauthentifizierung, z. B. Überprüfung von Sicherheitstoken, Zertifikatvertrauens- und Sperrprüfungen usw. mithilfe von SOAP-Nachrichtensicherheit oder Transportsicherheit.

Das Sicherheitsprogrammiermodell

Sicherheit ist Kommunikationskanälen zugeordnet. Das Schützen eines Kanals besteht aus den folgenden Schritten.

• Erstellen und initialisieren Sie eine oder mehrere Sicherheitsbindungen , die den Sicherheitsanforderungen der Anwendung entsprechen.
• Erstellen Sie eine Sicherheitsbeschreibung , die diese Sicherheitsbindungen enthält.
• Erstellen Sie einen Kanal - oder Dienstproxy (auf der Clientseite), oder erstellen Sie einen Listener oder Diensthost (auf der Serverseite), der diese Sicherheitsbeschreibung übergibt.
• Führen Sie die normalen Kanalprogrammierschritte Öffnen, Akzeptieren, Senden, Empfangen, Schließen usw. aus.

Nachrichten, die auf dem Kanal gesendet und empfangen werden, werden gemäß der angegebenen Sicherheitsbeschreibung automatisch von der Runtime gesichert. Optional können diese Schritte optimiert werden, indem sie eine oder mehrere kanalweite Sicherheitseinstellungen in der Sicherheitsbeschreibung oder bindungsweite Sicherheitseinstellungen in einer Sicherheitsbindung angeben.

Jede erforderliche Autorisierung von Absenderidentitäten muss von der Anwendung unter Verwendung der Sicherheitsverarbeitungsergebnisse durchgeführt werden, die an jede empfangene Nachricht angefügt sind. Autorisierungsschritte werden weder in der Sicherheitsbeschreibung angegeben noch von der Runtime automatisch ausgeführt.

Fehler in der Sicherheitsbeschreibung, z. B. nicht unterstützte Bindungen, nicht verwendbare Eigenschaften/Felder, fehlende erforderliche Eigenschaften/Felder oder ungültige Eigenschaften-/Feldwerte, führen dazu, dass die Kanal- oder Listenererstellung fehlschlägt.

Auswählen von Sicherheitsbindungen

Beim Entwerfen von Sicherheit für eine Anwendung ist die primäre Entscheidung die Auswahl der Sicherheitsbindungen, die in die Sicherheitsbeschreibung aufgenommen werden sollen. Im Folgenden finden Sie einige Richtlinien für die Auswahl von Sicherheitsbindungen, die für das Sicherheitsszenario einer Anwendung geeignet sind. Eine nützliche Heuristik besteht darin, zunächst zu verstehen, welche Sicherheitsanmeldeinformationstypen (z . B. X.509-Zertifikate, Windows-Domänenbenutzername/-kennwörter, anwendungsdefinierte Benutzernamen/Kennwörter) für die Anwendung verfügbar sind, und dann eine Sicherheitsbindung auszuwählen, die diesen Anmeldeinformationstyp verwenden kann.

• Die Transportsicherheit, bei der die Sicherheit auf der Transportbytestreamebene (unterhalb der SOAP-Nachrichtengrenzen) angewendet wird, ist die erste Option, die in Betracht gezogen werden sollte.

  • Für Internetszenarien und für Intranetszenarien, in denen ein X.509-Zertifikat auf dem Server bereitgestellt werden kann, kann die Anwendung WS_SSL_TRANSPORT_SECURITY_BINDING verwenden. Im folgenden Beispiel wird diese Option veranschaulicht. Client: HttpClientWithSslExample Server: HttpServerWithSslExample.

    Wenn die Clientauthentifizierung über die HTTP-Headerauthentifizierung gewünscht ist, kann ein WS_HTTP_HEADER_AUTH_SECURITY_BINDING hinzugefügt werden, um diese Funktionalität bereitzustellen.

  • Für Intranetszenarien, in denen integrierte Windows-Authentifizierungsprotokolle wie Kerberos, NTLM und SPNEGO geeignet sind, kann die Anwendung WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING verwenden. Das folgende Beispiel veranschaulicht diese Option: Client: RequestReplyTcpClientWithWindowsTransportSecurityExample Server: RequestReplyTcpServerWithWindowsTransportSecurityExample.

    Client über Named Pipes: RequestReplyNamedPipesClientWithWindowsTransportSecurityExample

    Server über Named Pipes: RequestReplyNamedPipesServerWithWindowsTransportSecurityExample

  • Für lokale Computerszenarien, in denen integrierte Windows-Authentifizierungsprotokolle wie Kerberos, NTLM und SPNEGO geeignet sind, kann die Anwendung WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING oder WS_NAMEDPIPE_SSPI_TRANSPORT_SECURITY_BINDING verwenden. DieWS_NAMEDPIPE_CHANNEL_BINDING wird in solchen Szenarien bevorzugt, da sie garantiert, dass der Datenverkehr den Computer nicht verlässt (dies ist die Eigenschaft von WS_NAMEDPIPE_CHANNEL_BINDING).

• Die Sicherheit im gemischten Modus, bei der die Transportsicherheit die Verbindung schützt und ein WS-Security-Header in der SOAP-Nachricht die Clientauthentifizierung bereitstellt, ist die nächste Option, die in Betracht gezogen werden sollte. Die folgenden Bindungen werden in Verbindung mit einer der im vorherigen Abschnitt beschriebenen Transportsicherheitsbindungen verwendet.

  • Wenn der Client durch ein Benutzername/Kennwort-Paar auf Anwendungsebene authentifiziert wird, kann die Anwendung eine WS_USERNAME_MESSAGE_SECURITY_BINDING verwenden, um die Authentifizierungsdaten bereitzustellen. Die folgenden Beispiele veranschaulichen die Verwendung dieser Bindung in Verbindung mit einer WS_SSL_TRANSPORT_SECURITY_BINDING:

    • Client: HttpClientWithUsernameOverSslExample
    • Server: HttpServerWithUsernameOverSslExample

  • Wenn der Client durch ein Kerberos-Ticket authentifiziert wird, kann die Anwendung eine WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING verwenden, um die Authentifizierungsdaten bereitzustellen.

  • Bei Verwendung eines Sicherheitskontexts richtet der Client zunächst einen Sicherheitskontext mit dem Server ein und verwendet diesen Kontext dann zum Authentifizieren von Nachrichten. Um diese Funktionalität zu aktivieren, muss die Sicherheitsbeschreibung eine WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING enthalten. Nach der Einrichtung können Sicherheitskontexte mithilfe von Lightweight-Token übertragen werden, wodurch vermieden wird, dass die potenziell großen und rechenintensiven Clientanmeldeinformationen mit jeder Nachricht gesendet werden müssen.

  • In einem Verbundsicherheitsszenario ruft der Client zuerst ein Sicherheitstoken ab, das von einem Sicherheitstokendienst (Security Token Service, STS) ausgestellt wurde, und stellt das ausgestellte Token dann einem Dienst dar. Clientseitig: Um das Sicherheitstoken vom STS abzurufen, verwendet die Anwendung möglicherweise WsRequestSecurityToken. Alternativ kann die Anwendung eine clientseitige Sicherheitstokenanbieterbibliothek wie CardSpace oder LiveID verwenden und dann ihre Ausgabe verwenden, um mithilfe von WsCreateXmlSecurityToken lokal ein Sicherheitstoken zu erstellen. Wenn das Sicherheitstoken für den Client verfügbar ist, kann es dem Dienst mithilfe einer Sicherheitsbeschreibung angezeigt werden, die eine WS_XML_TOKEN_MESSAGE_SECURITY_BINDING enthält. Serverseitig: Wenn das vom STS ausgegebene Sicherheitstoken ein SAML-Token ist, verwendet der Server möglicherweise eine Sicherheitsbeschreibung mit einem WS_SAML_MESSAGE_SECURITY_BINDING.

    Hinweis

    Windows 7 und Windows Server 2008 R2: WWSAPI unterstützt nur Ws-Trust und Ws-SecureConversation , wie durch Lightweight Web Services Security Profile (LWSSP) definiert. Ausführliche Informationen zur Implementierung von Microsoft finden Sie im Abschnitt MESSAGE Syntax von LWSSP.

     

• Die letzte zu berücksichtigende Option ist die Verwendung von Authentifizierungsbindungen, ohne eine Schutzbindung wie WS_SSL_TRANSPORT_SECURITY_BINDING zu verwenden. Dies führt dazu, dass die Anmeldeinformationen in Klartext übertragen werden und auswirkungen auf die Sicherheit haben können. Die Verwendung dieser Option sollte sorgfältig geprüft werden, um sicherzustellen, dass es keine Sicherheitsrisiken gibt. Ein Beispiel für eine mögliche Verwendung ist der Austausch von Nachrichten zwischen Back-End-Servern über ein sicheres privates Netzwerk. Die folgenden Konfigurationen unterstützen diese Option.

  • WS_HTTP_HEADER_AUTH_SECURITY_BINDING unterstützt diese Option in allen Konfigurationen.
  • WS_USERNAME_MESSAGE_SECURITY_BINDING unterstützt diese Option auf dem Server, wenn HTTP als Transport verwendet wird.
  • WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING unterstützt diese Option auf dem Server, wenn HTTP als Transport verwendet wird.
  • WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING unterstützt diese Option auf dem Server, wenn HTTP als Transport verwendet wird.
  • WS_SAML_MESSAGE_SECURITY_BINDING unterstützt diese Option auf dem Server, wenn HTTP als Transport verwendet wird.

  Zum Aktivieren dieser Option muss die WS_PROTECTION_LEVEL explizit auf einen anderen Wert als WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT festgelegt werden.

Kanäle und Sicherheit

Wie oben erwähnt, ist die Sicherheit auf Kanäle ausgerichtet. Darüber hinaus werden Kanalvorgänge allen Sicherheitsschritten konsistent über alle Sicherheitsbindungen hinweg zugeordnet.

• Kanalerstellung: Die in der Sicherheitsbeschreibung angegebene Gruppe von Sicherheitsbindungen wird überprüft und bleibt anschließend für den Kanal behoben. Die Form des Kanalstapels, einschließlich aller Seitenkanäle, die für WS-Trust basierte Verhandlungen verwendet werden sollen, wird ebenfalls bestimmt.
• Kanal geöffnet: Alle Anmeldeinformationen, die als Teil von Sicherheitsbindungen angegeben werden, werden geladen, und Es werden Sicherheitssitzungen eingerichtet. Im Allgemeinen enthält ein geöffneter Kanal den Sicherheitsstatus "live". Das Öffnen eines Clientkanals gibt auch die Endpunktadresse des Servers an, für die die Serverauthentifizierung von der Runtime durchgeführt wird.
• Zwischen Kanal öffnen und schließen: Nachrichten können in dieser Phase sicher gesendet und empfangen werden.
• Senden von Nachrichten: Sicherheitskontexttoken werden nach Bedarf abgerufen oder erneuert, und die Sicherheit wird gemäß der Sicherheitsbeschreibung auf jede übertragene Nachricht angewendet. Fehler, die beim Anwenden von Sicherheit auftreten, werden als Sendefehler an die Anwendung zurückgegeben.
• Nachrichten empfangen: Die Sicherheit wird für jede empfangene Nachricht gemäß der Sicherheitsbeschreibung überprüft. Alle Fehler bei der Nachrichtensicherheitsüberprüfung werden als Empfangsfehler an die Anwendung zurückgegeben. Diese Fehler pro Nachricht wirken sich nicht auf den Kanalstatus oder nachfolgende Empfangsvorgänge aus. Die Anwendung verwirft möglicherweise einen fehlgeschlagenen Empfang und startet einen Empfang für eine andere Nachricht neu.
• Kanalabbruch: Der Kanal kann jederzeit abgebrochen werden, um alle E/A-Vorgänge auf dem Kanal anzuhalten. Beim Abbrechen wechselt der Kanal in einen fehlerhaften Zustand und lässt keine weiteren Sende- oder Empfangsvorgänge mehr zu. Der Kanal behält jedoch möglicherweise weiterhin einen "Live"-Sicherheitsstatus bei, sodass ein nachfolgendes Schließen des Kanals erforderlich ist, um den gesamten Zustand sauber zu entfernen.
• Kanal schließen: Der bei geöffnet erstellte Sicherheitsstatus wird entfernt, und Sitzungen werden abgerissen. Sicherheitskontexttoken werden abgebrochen. Der Kanalstapel bleibt erhalten, enthält aber keinen "Live"-Sicherheitsstatus oder geladene Anmeldeinformationen.
• Kanalfrei: Der bei create erstellte Kanalstapel wird zusammen mit allen Sicherheitsressourcen freigegeben.

Sicherheits-APIs

Die API-Dokumentation zur Sicherheit ist in den folgenden Themen gruppiert.

• Sicherheitsbeschreibung
  • Sicherheitskanaleinstellungen
  • Sicherheitsbindungen
    • Sicherheitsanmeldeinformationen
    • Sicherheitsbindungseinstellungen
• Verbund
• Sicherheitskontext
• Endpunktidentität
• Ergebnisse der Sicherheitsverarbeitung

Sicherheit

Bei Verwendung der WWSAPI-Sicherheits-API sind Anwendungen mit mehreren Sicherheitsrisiken konfrontiert:

Versehentliche Fehlkonfiguration

WWSAPI unterstützt eine Reihe sicherheitsbezogener Konfigurationsoptionen. Weitere Informationen finden Sie unter WS_SECURITY_BINDING_PROPERTY_ID. Einige dieser Optionen, z. B. WS_SECURITY_BINDING_PROPERTY_ALLOW_ANONYMOUS_CLIENTS ermöglichen es der Anwendung, die Standardsicherheitsebene zu senken, die von den verschiedenen Sicherheitsbindungen bereitgestellt wird. Die Verwendung solcher Optionen sollte sorgfältig bewertet werden, um sicherzustellen, dass es keine resultierenden Angriffsvektoren gibt.

Darüber hinaus ermöglicht WWSAPI einer Anwendung, wie oben beschrieben, absichtlich bestimmte Schritte zu deaktivieren, die zum vollständigen Schutz eines Nachrichtenaustauschs erforderlich sind, z. B. das Deaktivieren der Verschlüsselung, obwohl Sicherheitsanmeldeinformationen übertragen werden. Dies ist zulässig, um bestimmte spezifische Szenarien zu ermöglichen und sollte nicht für die allgemeine Kommunikation verwendet werden. Die WS_PROTECTION_LEVEL muss speziell gesenkt werden, um diese Szenarien zu ermöglichen, und Anwendungen sollten diesen Wert nur ändern, wenn dies absolut erforderlich ist, da dadurch viele Überprüfungen deaktiviert werden, die für eine sichere Konfiguration konzipiert sind.

Speichern vertraulicher Informationen im Arbeitsspeicher

Vertrauliche Informationen, z. B. Kennwörter, die im Arbeitsspeicher gespeichert sind, sind anfällig für die Extraktion durch einen privilegierten Angreifer, z. B. durch die Auslagerungsdatei. WWSAPI erstellt eine Kopie der bereitgestellten Anmeldeinformationen und verschlüsselt diese Kopie, sodass die ursprünglichen Daten nicht geschützt sind. Es liegt in der Verantwortung der Anwendung, die ursprüngliche instance zu schützen. Darüber hinaus wird die verschlüsselte Kopie kurz entschlüsselt, während sie verwendet wird, und öffnet ein Fenster, um sie zu extrahieren.

Denial-of-Service

Die Sicherheitsverarbeitung kann erhebliche Ressourcen beanspruchen. Jede zusätzliche Sicherheitsbindung erhöht diese Kosten. WWSAPI bricht die Sicherheitsverarbeitung ab, sobald ein Fehler bei der Sicherheitsüberprüfung auftritt, aber bestimmte Überprüfungen wie Autorisierungsentscheidungen werden möglicherweise erst durchgeführt, nachdem wichtige Arbeiten ausgeführt wurden.

Während eine Nachricht auf dem Server verarbeitet wird, wird der Sicherheitsstatus auf dem Nachrichtenheap gespeichert. Die Anwendung kann den Arbeitsspeicherverbrauch während der Sicherheitsverarbeitung einschränken, indem sie die Größe dieses Heaps bis WS_MESSAGE_PROPERTY_HEAP_PROPERTIES reduziert. Darüber hinaus können bestimmte Sicherheitsbindungen wie die WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING dazu führen, dass der Server Ressourcen im Auftrag des Clients zuordnet. Die Grenzwerte für diese Ressourcen können mithilfe der folgenden WS_SECURITY_BINDING_PROPERTY_ID Werte konfiguriert werden:

• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_PENDING_CONTEXTS
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_ACTIVE_CONTEXTS
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_RENEWAL_INTERVAL
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_ROLLOVER_INTERVAL

Das Festlegen dieser Grenzwerte auf niedrige Werte reduziert den maximalen Arbeitsspeicherverbrauch, kann jedoch dazu führen, dass legitime Clients abgelehnt werden, wenn das Kontingent erreicht wird.