Panoramica della sicurezza

Il framework di sicurezza nell'API servizi Web Windows (WWSAPI) offre:

• Integrità dei messaggi, riservatezza, rilevamento della riproduzione e autenticazione del server utilizzando la sicurezza dei trasporti.
• Autenticazione client, ad esempio la convalida dei token di sicurezza, i controlli di attendibilità e revoca dei certificati e così via tramite la sicurezza dei messaggi SOAP o la sicurezza del trasporto.

Modello di programmazione della sicurezza

La sicurezza è associata ai canali di comunicazione . La protezione di un canale è costituita dai passaggi seguenti.

• Creare e inizializzare una o più associazioni di sicurezza appropriate per i requisiti di sicurezza dell'applicazione.
• Creare una descrizione di sicurezza contenente tali associazioni di sicurezza.
• Creare un canale o un proxy del servizio (sul lato client), oppure creare un listener o un host del servizio (sul lato server) passando tale descrizione di sicurezza.
• Eseguire i normali passaggi di programmazione del canale di Open, Accept, Send, Receive, Close e così via.

I messaggi inviati e ricevuti sul canale vengono protetti automaticamente dal runtime in base alla descrizione di sicurezza fornita. Facoltativamente, questi passaggi possono essere perfezionati specificando una o più impostazioni di sicurezza a livello di canale nella descrizione della sicurezza o impostazioni di sicurezza a livello di vincolo in un vincolo di sicurezza.

Qualsiasi autorizzazione richiesta delle identità del mittente deve essere eseguita dall'applicazione usando i risultati dell'elaborazione della sicurezza allegati a ogni messaggio ricevuto. I passaggi di autorizzazione non vengono specificati nella descrizione della sicurezza, né vengono eseguiti automaticamente dal runtime.

Errori nella descrizione della sicurezza, come associazioni non supportate, proprietà/campi inapplicabili, mancanza di proprietà/campi obbligatori o valori di proprietà/campo non validi, faranno fallire la creazione del canale o del listener.

Selezione di vincoli di sicurezza

Quando si progetta la sicurezza per un'applicazione, la decisione principale è la selezione delle associazioni di sicurezza da includere nella descrizione della sicurezza. Di seguito sono riportate alcune linee guida per la scelta delle associazioni di sicurezza adatte per lo scenario di sicurezza di un'applicazione. Un'euristica utile consiste innanzitutto nel comprendere quali tipi di credenziali di sicurezza (ad esempio certificati X.509, nome utente/password del dominio Windows, nome utente/password definite dall'applicazione) saranno disponibili per l'applicazione e quindi scegliere un'associazione di sicurezza che possa usare tale tipo di credenziale.

• La sicurezza del trasporto, in cui la sicurezza viene applicata a livello di flusso dei byte di trasporto (al di sotto dei limiti del messaggio SOAP), è la prima opzione da considerare.

  • Per gli scenari Internet e per gli scenari Intranet in cui è possibile distribuire un certificato X.509 nel server, l'applicazione può usare WS_SSL_TRANSPORT_SECURITY_BINDING. Nell'esempio seguente viene illustrata questa opzione. Client: HttpClientWithSslExample Server: HttpServerWithSslExample.

    Se si desidera l'autenticazione client tramite l'autenticazione dell'intestazione HTTP, è possibile aggiungere un WS_HTTP_HEADER_AUTH_SECURITY_BINDING per fornire tale funzionalità.

  • Per gli scenari Intranet in cui sono appropriati protocolli di autenticazione integrata di Windows, ad esempio Kerberos, NTLM e SPNEGO, l'applicazione può usare WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING. L'esempio seguente illustra questa opzione: Client: RequestReplyTcpClientWithWindowsTransportSecurityExample Server: RequestReplyTcpServerWithWindowsTransportSecurityExample.

    Client tramite pipe denominate: RequestReplyNamedPipesClientWithWindowsTransportSecurityExample

    Server su named pipe: RequestReplyNamedPipesServerWithWindowsTransportSecurityExample

  • Per scenari di computer locali in cui sono appropriati protocolli di autenticazione integrata di Windows, ad esempio Kerberos, NTLM e SPNEGO, l'applicazione può usare WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING o WS_NAMEDPIPE_SSPI_TRANSPORT_SECURITY_BINDING. IlWS_NAMEDPIPE_CHANNEL_BINDING è preferibile in questi scenari perché garantisce che il traffico non lasci il computer (questa è la proprietà di WS_NAMEDPIPE_CHANNEL_BINDING).

• La sicurezza in modalità mista, in cui la sicurezza del trasporto protegge la connessione e un'intestazione WS-Security nel messaggio SOAP fornisce l'autenticazione client, è l'opzione successiva da considerare. Le associazioni seguenti vengono utilizzate in combinazione con una delle associazioni di sicurezza del trasporto descritte nella sezione precedente.

  • Quando il client viene autenticato da una coppia nome utente/password a livello di applicazione, l'applicazione può usare un WS_USERNAME_MESSAGE_SECURITY_BINDING per fornire i dati di autenticazione. Negli esempi seguenti viene illustrato l'utilizzo di questa associazione in combinazione con un WS_SSL_TRANSPORT_SECURITY_BINDING:

    • Client: HttpClientWithUsernameOverSslExample
    • Server: HttpServerWithUsernameOverSslExample

  • Quando il client viene autenticato da un ticket Kerberos, l'applicazione può usare un WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING per fornire i dati di autenticazione.

  • Quando si usa un contesto di sicurezza , il client stabilisce innanzitutto un contesto di sicurezza con il server e quindi usa tale contesto per autenticare i messaggi. Per abilitare questa funzionalità, la descrizione della sicurezza deve contenere un WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING. Una volta stabiliti, i contesti di sicurezza possono essere trasmessi tramite token leggeri, evitando di dover inviare le credenziali del client, che potrebbero essere grandi e onerose dal punto di vista computazionale, con ogni messaggio.

  • In un scenario di sicurezza federata, il client ottiene prima un token di sicurezza emesso da un servizio di token di sicurezza (STS), e quindi presenta il token rilasciato a un servizio. All'interno dell'applicazione client: per ottenere il token di sicurezza dall'STS, l'applicazione può usare WsRequestSecurityToken. In alternativa, l'applicazione può usare una libreria del provider di token di sicurezza lato client, ad esempio CardSpace o LiveID, e quindi usare il relativo output per creare localmente un token di sicurezza usando WsCreateXmlSecurityToken. In entrambi i casi, una volta che il token di sicurezza è disponibile per il client, può essere presentato al servizio usando una descrizione di sicurezza contenente un WS_XML_TOKEN_MESSAGE_SECURITY_BINDING. Nel lato server: se il token di sicurezza rilasciato dal Servizio Token di Sicurezza è un token SAML, il server può usare una descrizione di sicurezza con un WS_SAML_MESSAGE_SECURITY_BINDING.

    Nota

    Windows 7 e Windows Server 2008 R2: WWSAPI supporta solo Ws-Trust e Ws-SecureConversation come definito da Lightweight Web Services Security Profile (LWSSP). Per dettagli riguardanti l'implementazione di Microsoft, consultare la sezione Sintassi del messaggio di LWSSP.

     

• L'opzione finale da considerare consiste nell'usare associazioni di autenticazione senza usare un'associazione di protezione, ad esempio WS_SSL_TRANSPORT_SECURITY_BINDING. Ciò comporterà la trasmissione delle credenziali in testo non crittografato e può avere implicazioni per la sicurezza. L'uso di questa opzione deve essere valutato attentamente per assicurarsi che non vi siano vulnerabilità di conseguenza. Un esempio di potenziale utilizzo consiste nello scambio di messaggi tra server back-end tramite una rete privata sicura. Le configurazioni seguenti supportano questa opzione.

  • WS_HTTP_HEADER_AUTH_SECURITY_BINDING supporta questa opzione in tutte le configurazioni.
  • WS_USERNAME_MESSAGE_SECURITY_BINDING supporta questa opzione nel server quando si usa HTTP come trasporto.
  • WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING supporta questa opzione nel server quando si usa HTTP come trasporto.
  • WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING supporta questa opzione nel server quando si usa HTTP come trasporto.
  • WS_SAML_MESSAGE_SECURITY_BINDING supporta questa opzione nel server quando si usa HTTP come trasporto.

  Per abilitare questa opzione è necessario impostare in modo esplicito il WS_PROTECTION_LEVEL su un valore diverso da WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT.

Canali e sicurezza

Come indicato in precedenza, la sicurezza è limitata ai canali. Inoltre, le operazioni del canale sono mappate ai passaggi di sicurezza in modo coerente in tutte le associazioni di sicurezza.

• Creazione del canale: le associazioni di sicurezza specificate nella descrizione della sicurezza vengono convalidate e rimangono fisse per il canale successivamente. Viene determinata anche la struttura dei canali, inclusi i canali secondari da utilizzare per i negoziati basati su WS-Trust.
• Canale aperto: tutte le credenziali fornite come parte dei binding di sicurezza vengono caricate e le sessioni di sicurezza vengono stabilite. In generale, un canale aperto contiene uno stato di sicurezza attivo. L'apertura di un canale client specifica anche l'indirizzo dell'endpoint del server in base al quale verrà eseguita l'autenticazione server dal runtime.
• Tra canale aperto e chiudi: i messaggi possono essere inviati e ricevuti in modo sicuro durante questa fase.
• Invio di messaggi: i token del contesto di sicurezza vengono ottenuti o rinnovati in base alle esigenze e la sicurezza viene applicata a ogni messaggio trasmesso in base alla descrizione della sicurezza. Gli errori rilevati durante l'applicazione della sicurezza vengono restituiti all'applicazione come errori di invio.
• Ricezione messaggio: la sicurezza viene verificata in ogni messaggio ricevuto in base alla descrizione della sicurezza. Eventuali errori di verifica della sicurezza dei messaggi vengono restituiti all'applicazione come errori di ricezione. Questi errori per messaggio non influiscono sullo stato del canale o sulle ricezioni successive. L'applicazione può eliminare una ricezione non riuscita e riavviare una ricezione per un altro messaggio.
• Interruzione del canale: il canale può essere interrotto in qualsiasi momento per interrompere tutte le operazioni di I/O nel canale. In caso di interruzione, il canale passerà in uno stato di errore e non consentirà altri invii o ricevere. Tuttavia, il canale potrebbe comunque mantenere uno stato di sicurezza attivo, quindi sarà necessario chiudere nuovamente il canale per eliminare tutto lo stato in modo pulito.
• Chiusura del canale: lo stato di sicurezza creato all'apertura viene eliminato e le sessioni vengono eliminate. I token del contesto di sicurezza vengono annullati. Lo stack di canali rimane, ma non contiene alcuno stato di sicurezza "live" o credenziali caricate.
• Canale gratuito: lo stack di canali creato in fase di creazione, insieme a tutte le risorse di sicurezza, viene liberato.

API di sicurezza

La documentazione dell'API per la sicurezza è raggruppata negli argomenti seguenti.

• Descrizione della sicurezza
  • Impostazioni Canale di Sicurezza
  • vincoli di sicurezza
    • credenziali di sicurezza
    • Impostazioni di vincolo di sicurezza
• Federazione
• contesto di sicurezza
• 'identità dell'endpoint
• Risultati dell'Elaborazione di Sicurezza

Sicurezza

Quando si usa l'API di sicurezza WWSAPI, le applicazioni devono affrontare diversi rischi per la sicurezza:

errata configurazione accidentale

WWSAPI supporta una gamma di opzioni di configurazione correlate alla sicurezza. Vedere ad esempio WS_SECURITY_BINDING_PROPERTY_ID. Alcune di queste opzioni, ad esempio WS_SECURITY_BINDING_PROPERTY_ALLOW_ANONYMOUS_CLIENTS consentono all'applicazione di ridurre il livello di sicurezza predefinito fornito dalle varie associazioni di sicurezza. L'uso di tali opzioni deve essere valutato attentamente per garantire che non ci siano vettori di attacco risultanti.

Inoltre, come descritto in precedenza, WWSAPI consente a un'applicazione di disabilitare deliberatamente determinati passaggi necessari per proteggere completamente uno scambio di messaggi, ad esempio consentire di disabilitare la crittografia anche se le credenziali di sicurezza vengono trasmesse. Ciò consente di abilitare determinati scenari specifici e non deve essere usato per la comunicazione generale. Il WS_PROTECTION_LEVEL deve essere ridotto in modo specifico per abilitare questi scenari e le applicazioni non devono modificare tale valore, a meno che non sia assolutamente necessario, perché in questo modo verranno disabilitati molti controlli progettati per garantire una configurazione sicura.

l'archiviazione di informazioni riservate in memoria

Le informazioni riservate, ad esempio le password, archiviate in memoria sono vulnerabili all'estrazione da parte di un utente malintenzionato con privilegi, ad esempio il file di pagina. WWSAPI crea una copia delle credenziali fornite e crittografa tale copia, lasciando i dati originali non protetti. È responsabilità dell'applicazione proteggere l'istanza originale. Inoltre, la copia crittografata viene brevemente decrittografata durante l'uso, aprendo una finestra per estrarla.

Negazione del servizio

L'elaborazione della sicurezza può utilizzare risorse significative. Ogni vincolo di sicurezza aggiuntivo aumenta tali costi. WWSAPI interrompe l'elaborazione della sicurezza non appena viene rilevato un errore di verifica della sicurezza, ma alcuni controlli, ad esempio le decisioni di autorizzazione, potrebbero non avvenire fino a quando non viene eseguito un lavoro significativo.

Durante l'elaborazione di un messaggio nel server, lo stato di sicurezza viene archiviato nell'heap dei messaggi. L'applicazione può limitare il consumo di memoria durante l'elaborazione di sicurezza riducendo le dimensioni dell'heap tramite WS_MESSAGE_PROPERTY_HEAP_PROPERTIES. Inoltre, alcune associazioni di sicurezza, ad esempio il WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING, possono causare l'allocazione delle risorse da parte del server per conto del client. I limiti per tali risorse possono essere configurati tramite i valori di WS_SECURITY_BINDING_PROPERTY_ID seguenti:

• 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

L'impostazione di tali limiti su valori bassi riduce il consumo massimo di memoria, ma può portare a client legittimi rifiutati quando viene raggiunta la quota.