Beveiligingsoverzicht

Het beveiligingsframework in de Windows Web Services-API (WWSAPI) biedt:

• Berichtintegriteit, vertrouwelijkheid, detectie van herhalingen en serververificatie met transportbeveiliging.
• Clientverificatie, zoals validatie van beveiligingstokens, certificaatvertrouwens- en intrekkingscontroles, enzovoort met SOAP-berichtbeveiliging of transportbeveiliging.

Het beveiligingsprogrammamodel

Beveiliging is gekoppeld aan communicatiekanalen. Het beveiligen van een kanaal bestaat uit de volgende stappen.

• Maak en initialiseer een of meer beveiligingsbindingen geschikt voor de beveiligingsvereisten van de toepassing.
• Maak een beveiligingsbeschrijving die deze beveiligingsbindingen bevat.
• Maak een -kanaal of -serviceproxy (aan de clientzijde), of maak een -listener of -servicehost (aan de serverzijde) waarbij je die beveiligingsbeschrijving doorgeeft.
• Doe de normale kanaalprogrammeringsstappen van Openen, Accepteren, Verzenden, Ontvangen, Sluiten, enzovoort.

Berichten die op het kanaal worden verzonden en ontvangen, worden automatisch beveiligd door de runtime volgens de opgegeven beveiligingsbeschrijving. U kunt deze stappen desgewenst verfijnen door een of meer beveiligingsinstellingen voor het hele kanaal op te geven in de beveiligingsbeschrijving of beveiligingsinstellingen voor de hele binding in een beveiligingsbinding.

Elke vereiste autorisatie van afzenderidentiteiten moet worden uitgevoerd door de toepassing met behulp van de beveiligingsverwerkingsresultaten gekoppeld aan elk ontvangen bericht. Autorisatiestappen worden niet opgegeven in de beveiligingsbeschrijving en worden ook niet automatisch uitgevoerd door de runtime.

Fouten in de beschrijving van de beveiliging, zoals niet-ondersteunde bindingen, niet-toepasbare eigenschappen/velden, ontbrekende vereiste eigenschappen/velden of ongeldige eigenschaps-/veldwaarden, leiden ertoe dat het maken van kanalen of listeners mislukt.

Beveiligingsbindingen selecteren

Bij het ontwerpen van beveiliging voor een toepassing is de primaire beslissing de selectie van de beveiligingsbindingen die moeten worden opgenomen in de beveiligingsbeschrijving. Hier volgen enkele richtlijnen voor het kiezen van beveiligingsbindingen die geschikt zijn voor het beveiligingsscenario van een toepassing. Een handige heuristiek is om eerst te begrijpen welke typen beveiligingsreferenties (zoals X.509-certificaten, Windows-domeingebruikersnamen/wachtwoorden, toepassing gedefinieerde gebruikersnaam/wachtwoorden) beschikbaar zijn voor de toepassing en vervolgens een beveiligingsbinding kiezen die dat referentietype kan gebruiken.

• Transportbeveiliging, waarbij beveiliging wordt toegepast op het niveau van de transport bytestroom (onder de SOAP-berichtgrenzen), is de eerste optie om rekening mee te houden.

  • Voor internetscenario's en voor intranetscenario's waarbij een X.509-certificaat op de server kan worden geïmplementeerd, kan de toepassing gebruikmaken van WS_SSL_TRANSPORT_SECURITY_BINDING. In het volgende voorbeeld ziet u deze optie. Client: HttpClientWithSslExample Server: HttpServerWithSslExample.

    Als clientverificatie via HTTP-headerverificatie gewenst is, kan een WS_HTTP_HEADER_AUTH_SECURITY_BINDING worden toegevoegd om die functionaliteit te bieden.

  • Voor intranetscenario's waarbij geïntegreerde Windows-verificatieprotocollen zoals Kerberos, NTLM en SPNEGO geschikt zijn, kan de toepassing gebruikmaken van WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING. In het volgende voorbeeld ziet u deze optie: Client: RequestReplyTcpClientWithWindowsTransportSecurityExample Server: RequestReplyTcpServerWithWindowsTransportSecurityExample.

    Client over named pipes: RequestReplyNamedPipesClientWithWindowsTransportSecurityExample

    Server over named pipes: RequestReplyNamedPipesServerWithWindowsTransportSecurityExample

  • Voor lokale machine-scenario's waar geïntegreerde Windows-verificatieprotocollen zoals Kerberos, NTLM en SPNEGO geschikt zijn, kan de applicatie gebruik maken van WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING of WS_NAMEDPIPE_SSPI_TRANSPORT_SECURITY_BINDING. DeWS_NAMEDPIPE_CHANNEL_BINDING heeft de voorkeur in dergelijke scenario's omdat het verkeer de machine niet verlaat (dit is de eigenschap van WS_NAMEDPIPE_CHANNEL_BINDING).

• Mixed-mode-beveiliging, waarbij transportbeveiliging de verbinding beveiligt en een WS-Security header in het SOAP-bericht clientverificatie biedt, is de volgende optie om rekening mee te houden. De volgende bindingen worden gebruikt in combinatie met een van de transportbeveiligingsbindingen die in de vorige sectie zijn beschreven.

  • Wanneer de client wordt geverifieerd door een gebruikersnaam/wachtwoordpaar op toepassingsniveau, kan de toepassing een WS_USERNAME_MESSAGE_SECURITY_BINDING gebruiken om de verificatiegegevens op te geven. In de volgende voorbeelden ziet u het gebruik van deze binding in combinatie met een WS_SSL_TRANSPORT_SECURITY_BINDING:

    • Client: HttpClientWithUsernameOverSslExample
    • Server: HttpServerMetGebruikersnaamOverSslVoorbeeld

  • Wanneer de client wordt geverifieerd door een Kerberos-ticket, kan de toepassing een WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING gebruiken om de verificatiegegevens op te geven.

  • Wanneer u een beveiligingscontextgebruikt, stelt de client eerst een beveiligingscontext met de server in en gebruikt deze context vervolgens om berichten te verifiëren. Als u deze functionaliteit wilt inschakelen, moet de beveiligingsbeschrijving een WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDINGbevatten. Wanneer ze eenmaal zijn vastgesteld, kunnen beveiligingscontexten worden verzonden door middel van lichte tokens, waardoor het niet nodig is om de mogelijk grote en rekeneenvoudig klantreferenties met elk bericht mee te sturen.

  • In een federatieve beveiliging scenario verkrijgt de client eerst een beveiligingstoken dat is uitgegeven door een beveiligingstokenservice (STS) en geeft het uitgegeven token vervolgens weer aan een service. Clientzijde: Om het beveiligingstoken van de STS te verkrijgen, kan de toepassing WsRequestSecurityTokengebruiken. De toepassing kan ook een beveiligingstokenproviderbibliotheek aan de clientzijde gebruiken, zoals CardSpace of LiveID, en vervolgens hun uitvoer gebruiken om lokaal een beveiligingstoken te maken met behulp van WsCreateXmlSecurityToken. Hoe dan ook, zodra het beveiligingstoken beschikbaar is voor de client, kan het aan de service worden gepresenteerd met behulp van een beveiligingsomschrijving die een WS_XML_TOKEN_MESSAGE_SECURITY_BINDINGbevat. Serverzijde: Als het beveiligingstoken dat is uitgegeven door de STS een SAML-token is, kan de server een beveiligingsbeschrijving met een WS_SAML_MESSAGE_SECURITY_BINDINGgebruiken.

    Notitie

    Windows 7 en Windows Server 2008 R2: WWSAPI ondersteunt alleen Ws-Trust en Ws-SecureConversation zoals gedefinieerd door Lightweight Web Services Security Profile (LWSSP). Zie de sectie MESSAGE Syntax van LWSSP voor meer informatie over de implementatie van Microsoft.

     

• De laatste optie die u kunt overwegen, is het gebruik van verificatiebindingen zonder een beveiligingsbinding zoals WS_SSL_TRANSPORT_SECURITY_BINDINGte gebruiken. Dit leidt ertoe dat de referenties in duidelijke tekst worden verzonden en dat dit gevolgen kan hebben voor de beveiliging. Het gebruik van deze optie moet zorgvuldig worden geëvalueerd om ervoor te zorgen dat er geen beveiligingsproblemen als gevolg hiervan zijn. Een voorbeeld van een potentieel gebruik is het uitwisselen van berichten tussen back-endservers via een beveiligd particulier netwerk. De volgende configuraties ondersteunen deze optie.

  • WS_HTTP_HEADER_AUTH_SECURITY_BINDING ondersteunt deze optie in alle configuraties.
  • WS_USERNAME_MESSAGE_SECURITY_BINDING ondersteunt deze optie op de server wanneer u HTTP als transport gebruikt.
  • WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING ondersteunt deze optie op de server wanneer u HTTP als transport gebruikt.
  • WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING ondersteunt deze optie op de server wanneer u HTTP als transport gebruikt.
  • WS_SAML_MESSAGE_SECURITY_BINDING ondersteunt deze optie op de server bij gebruik van HTTP als transport.

  Als u deze optie inschakelt, moet u de WS_PROTECTION_LEVEL expliciet instellen op een andere waarde dan WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT.

Kanalen en beveiliging

Zoals hierboven vermeld, is beveiliging gericht op kanalen. Bovendien worden kanaalbewerkingen consistent toegewezen aan beveiligingsstappen voor alle beveiligingsbindingen.

• Kanaal maken: de set beveiligingsbindingen die zijn opgegeven in de beveiligingsbeschrijving, wordt gevalideerd en blijft daarna vast voor het kanaal. De vorm van de kanaalstack, inclusief eventuele zijkanalen die moeten worden gebruikt voor onderhandelingen op basis van WS-Trust, wordt ook bepaald.
• Kanaal geopend: referenties die worden opgegeven als onderdeel van beveiligingsbindingen worden geladen en beveiligingssessies worden tot stand gebracht. Over het algemeen bevat een open kanaal een actuele beveiligingsstatus. Het openen van een clientkanaal specificeert ook het eindpuntadres van de server waartegen serververificatie door de runtime zal worden uitgevoerd.
• Tussen kanaal geopend en gesloten: berichten kunnen tijdens deze fase veilig worden verzonden en ontvangen.
• Bericht verzenden: Tokens voor beveiligingscontext worden naar behoefte verkregen of vernieuwd en de beveiliging wordt toegepast op elk verzonden bericht volgens de beveiligingsbeschrijving. Fouten die optreden bij het toepassen van beveiliging, worden als verzendfouten geretourneerd naar de toepassing.
• Bericht ontvangen: De veiligheid wordt geverifieerd op elk ontvangen bericht volgens de veiligheidsbeschrijving. Eventuele beveiligingsfouten van berichten worden geretourneerd naar de toepassing als ontvangen fouten. Deze fouten per bericht hebben geen invloed op de kanaalstatus of volgende ontvangst. De toepassing kan een mislukte ontvangst negeren en een ontvangst opnieuw starten voor een ander bericht.
• Kanaal wordt afgebroken: het kanaal kan op elk gewenst moment worden afgebroken om alle I/O op het kanaal te stoppen. Bij het afbreken krijgt het kanaal een foutieve status en staat het niet meer toe dat er verzonden of ontvangen worden. Het kanaal kan echter nog steeds een 'live' beveiligingsstatus behouden, dus het afsluiten van het kanaal is noodzakelijk om de status correct op te ruimen.
• Kanaal sluiten: de beveiligingsstatus die bij openen is gemaakt, wordt verwijderd en sessies worden afgebroken. Tokens voor beveiligingscontext worden geannuleerd. De kanaalstack blijft behouden, maar bevat geen 'live' veiligheidsstatus of geladen inloggegevens.
• Kanaal vrijgegeven: de kanaalstack die is gebouwd bij aanmaak, samen met alle beveiligingsbronnen, wordt vrijgemaakt.

Beveiligings-API's

De API-documentatie voor beveiliging is gegroepeerd in de volgende onderwerpen.

• beveiligingsbeschrijving
  • Beveiligingskanaalinstellingen
  • Beveiligingskoppelingen
    • beveiligingsgegevens
    • Beveiligingsbindingsinstellingen
• federatieve
• beveiligingscontext
• Eindpuntidentiteit
• Resultaten van Beveiligingsverwerking

Veiligheid

Wanneer u de WWSAPI Security-API gebruikt, lopen toepassingen verschillende beveiligingsrisico's:

onbedoelde onjuiste configuratie

WWSAPI ondersteunt een reeks beveiligingsconfiguratieopties. Zie bijvoorbeeld WS_SECURITY_BINDING_PROPERTY_ID. Sommige van deze opties, zoals WS_SECURITY_BINDING_PROPERTY_ALLOW_ANONYMOUS_CLIENTS toestaan dat de toepassing het standaardniveau van beveiliging verlaagt dat wordt geboden door de verschillende beveiligingsbindingen. Het gebruik van dergelijke opties moet zorgvuldig worden geëvalueerd om ervoor te zorgen dat er geen resulterende aanvalsvectoren zijn.

Bovendien kan een toepassing, zoals hierboven beschreven, bepaalde stappen, die nodig zijn om een berichtenuitwisseling volledig te beveiligen, uitschakelen, zoals het uitschakelen van versleuteling toestaan, zelfs wanneer beveiligingsreferenties worden verzonden. Dit is toegestaan om bepaalde specifieke scenario's in te schakelen en mag niet worden gebruikt voor algemene communicatie. De WS_PROTECTION_LEVEL moet specifiek worden verlaagd om deze scenario's mogelijk te maken en toepassingen mogen deze waarde niet wijzigen, tenzij dit absoluut noodzakelijk is, omdat hierdoor veel controles worden uitgeschakeld die zijn ontworpen om een veilige configuratie te garanderen.

vertrouwelijke informatie opslaan in het geheugen

Vertrouwelijke informatie, zoals wachtwoorden, die zijn opgeslagen in het geheugen, is kwetsbaar voor het uitgepakt worden door een bevoegde aanvaller door bijvoorbeeld het paginabestand. WWSAPI maakt een kopie van opgegeven referenties en versleutelt die kopie, waardoor de oorspronkelijke gegevens onbeveiligd blijven. Het is de verantwoordelijkheid van de toepassing om het oorspronkelijke exemplaar te beveiligen. Bovendien wordt de versleutelde kopie kort ontsleuteld tijdens het gebruik, waarbij een venster wordt geopend om het te extraheren.

Denial-of-Service-aanval

Beveiligingsverwerking kan aanzienlijke resources verbruiken. Elke extra beveiligingsbinding verhoogt deze kosten. WWSAPI aborteert de beveiligingsverwerking zodra er een fout in beveiligingsverificatie optreedt, maar bepaalde controles, zoals autorisatiebeslissingen, kunnen pas plaatsvinden nadat er aanzienlijk werk is uitgevoerd.

Terwijl een bericht op de server wordt verwerkt, wordt de beveiligingsstatus opgeslagen op de heap van het bericht. De toepassing kan het geheugenverbruik tijdens de beveiligingsverwerking beperken door de grootte van die heap via WS_MESSAGE_PROPERTY_HEAP_PROPERTIES te verminderen. Daarnaast kunnen bepaalde beveiligingsbindingen, zoals de WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING ervoor zorgen dat de server resources toewijst namens de client. De limieten voor deze resources kunnen worden geconfigureerd met behulp van de volgende WS_SECURITY_BINDING_PROPERTY_ID waarden:

• 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

Als u deze limieten instelt op lage waarden, vermindert u het maximale geheugenverbruik, maar kan dit ertoe leiden dat legitieme clients worden geweigerd wanneer het quotum wordt bereikt.