Cenni preliminari sulla sicurezza

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

• Integrità dei messaggi, riservatezza, rilevamento della riproduzione e autenticazione server usando la sicurezza del trasporto.
• Autenticazione client, ad esempio la convalida dei token di sicurezza, i controlli di attendibilità e revoca dei certificati e così via, usando 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 ottimizzati specificando una o più impostazioni di sicurezza a livello di canale nella descrizione della sicurezza o nelle impostazioni di sicurezza a livello di associazione in un'associazione di sicurezza.

Qualsiasi autorizzazione richiesta delle identità del mittente deve essere eseguita dall'applicazione usando i risultati dell'elaborazione della sicurezza associati 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, ad esempio associazioni non supportate, proprietà/campi non validi, mancanza di proprietà/campi obbligatori o valori di proprietà/campo non validi, causerà l'esito negativo della creazione del canale o del listener.

Selezione di associazioni 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 definiti dall'applicazione) saranno disponibili per l'applicazione e quindi scegliere un'associazione di sicurezza in grado di 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 dei messaggi 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 i protocolli di autenticazione integrata di Windows, ad esempio Kerberos, NTLM e SPNEGO sono appropriati, l'applicazione può usare WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING. L'esempio seguente illustra questa opzione: Client: RequestReplyTcpClientWithWindowsTransportSecurityExample Server: RequestReplyTcpServerWithWindowsTransportSecurityExample.

    Client tramite named pipe: RequestReplyNamedPipesClientWithWindowsTransportSecurityExample

    Server tramite named pipe: RequestReplyNamedPipesServerWithWindowsTransportSecurityExample

  • Per gli 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 lascerà il computer (si tratta della 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 insieme a 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. Gli esempi seguenti illustrano l'utilizzo di questa associazione insieme a 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 stabilito, i contesti di sicurezza possono essere trasmessi tramite token leggeri, evitando di dover inviare le credenziali client potenzialmente di grandi dimensioni e dispendiose dal calcolo con ogni messaggio.

  • In uno scenario di sicurezza federato , il client ottiene prima un token di sicurezza emesso da un servizio token di sicurezza e quindi presenta il token rilasciato a un servizio. Lato client: per ottenere il token di sicurezza dal servizio token di sicurezza, 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. 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 informazioni dettagliate sull'implementazione di Microsoft, vedere la sezione Sintassi MESSAGE 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 garantire 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.

  L'abilitazione di questa opzione richiede l'impostazione esplicita del WS_PROTECTION_LEVEL su un valore diverso da WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT.

Canali e sicurezza

Come indicato in precedenza, la sicurezza ha come ambito i canali. Inoltre, le operazioni del canale sono mappate ai passaggi di sicurezza in modo coerente in tutte le associazioni di sicurezza.

• Creazione del canale: il set di associazioni di sicurezza specificate nella descrizione della sicurezza viene convalidato e rimane fisso per il canale in seguito. Viene determinata anche la forma dello stack di canali, inclusi i canali laterali da utilizzare per i negoziati basati su WS-Trust.
• Canale aperto: tutte le credenziali fornite come parte delle associazioni di sicurezza vengono caricate e vengono stabilite sessioni di sicurezza. In generale, un canale aperto contiene lo stato di sicurezza "live". 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 successive ricevute. L'applicazione può rimuovere 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 ricevute. Tuttavia, il canale potrebbe comunque mantenere uno stato di sicurezza "live", quindi sarà necessario chiudere un canale successivo per eliminare tutti gli stati 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 del canale di sicurezza
  • Associazioni di sicurezza
    • Credenziali di protezione
    • Impostazioni di associazione di sicurezza
• Federazione
• Contesto di sicurezza
• Identità endpoint
• Risultati dell'elaborazione della sicurezza

Sicurezza

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

Configurazione accidentale errata

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 siano presenti 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 consentendo 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.

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.

Denial of Service

L'elaborazione della sicurezza può utilizzare risorse significative. Ogni associazione di sicurezza aggiuntiva 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 del messaggio. L'applicazione può limitare il consumo di memoria durante l'elaborazione della 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ò causare il rifiuto dei client legittimi quando viene raggiunta la quota.