In questa lezione forniremo una prima descrizione dei principali meccanismi di sicurezza per Web Services, differenziati in base al livello sul quale operano, che verranno approfonditi nei successivi capitoli. Questa parte è invece orientata a fornire una visione comparativa che aiuti a fare le prime valutazioni circa l’opportunità di adottare l’uno o l’altro livello di protezione se non entrambi.
Sicurezza a livello trasporto
La soluzione più immediata e matura per affrontare i problemi che abbiamo descritto consiste nell’instaurare un meccanismo di sicurezza a livello trasporto. A livello trasporto possiamo contare su protocolli come SSL (Secure Socket Layer) e TLS (Transport Layer Security), in grado di fornire autenticazione, protezione dei dati, supporto a token di crittografia, garantendo integrità e confidenzialità.
SSL e TSL
SSL utilizza un sistema di crittografia basato su chiave pubblica e privata. Tramite firma digitale si punta a evitare modifiche non autorizzate dei dati. L’autenticazione tra client e server consente di stabilire che si sta comunicando con l’entità appropriata; esso è comunemente supportato dai principali browser.
TLS è un protocollo basato su SSL. Utilizza certificati per autenticare gli utenti e i client TLS adottano chiavi pubbliche fornite dal server per criptare un numero randomico da rinviare al server. Quest'ultimo, combinato con numeri precedentemente scambiati, viene impiegato per garantire una chiave di sessione per criptare il successivo scambio di messaggi. Gli URL che richiedono una connessione SSL cominciano per https invece che per http.
Il client di un Web Service utilizza SSL per instaurare una socket sicura verso di esso, inviando e ricevendo messaggi SOAP. L’implementazione SSL si occupa di assicurare privacy e autenticazione, eventualmente basandosi su un’autorità di certificazione per autenticare il Web Service e il client. Abitualmente HTTPS lavora con certificati lato server, ciò significa che il client può autenticare il server, ma non può avvenire il contrario. Associando un meccanismo di autenticazione basico (nome utente e password) o basato su firma nel messaggio, si può aggirare questo problema, una soluzione però più debole rispetto all’utilizzo di certificati da entrambi i lati. Pertanto, in caso di vincoli di sicurezza estremamente stringenti, si può richiedere che anche il client abbia un proprio certificato.
Anche se si tratta di un sistema estremamente diffuso, esistono diversi limiti di SSL.
- è un meccanismo di sicurezza punto-punto, mentre nei Web services necessitiamo di un end-to-end, gli intermediari potranno consultare i messaggi in chiaro;
- opera a livello trasporto e non messaggio,una volta a destinazione i dati saranno registrati in chiaro (anche da eventuali sistemi di logging) a meno di non fornire un ulteriore meccanismo di criptografia a sé stante;
- come conseguenza del fatto che opera a livello trasporto, la granularità offerta sarà minore rispetto a quella offerta da un sistema basato su messaggio. Come esempio, si potrebbe desiderare di criptare parti diverse del messaggio con chiavi differenti per distribuirlo a più utenti, o criptare solo alcune sezioni lasciando in chiaro il grosso del messaggio, ma ciò non è fattibile se si lavora con il messaggio preso a scatola chiusa;
- HTTPS non supporta il meccanismo di non ripudio critico nei Web Services.
Altro problema, i Web services possono richiedere il supporto di diversi protocolli oltre ad HTTP (FTP, SMTP..). Ogni protocollo ha i propri meccanismi di scambio delle credenziali e gestione della protezione dei messaggi, per cui l’utilizzo di SSL tende ad aggiungere un ulteriore vincolo limitando uno dei punti di forza dei Web services.
Sicurezza a livello messaggio
Come descritto, tramite SSL è possibile instaurare sicurezza a livello trasporto ma non a livello applicazione. A livello applicazione si ricorre a meccanismi a livello messaggio. Caratteristiche offerte a questo livello sono utili soprattutto operando con sistemi destinati a lavorare con code asincrone, in generale con meccanismi di pubblicazione/sottoscrizione, e soluzioni nelle quali la sicurezza è un aspetto prioritario, in cui scambi di messaggi includono normalmente diversi path e potenziali utilizzatori, anche con scambi tra nodi che adottano diversi protocolli di comunicazione.
Comunicazioni basate su SOAP possono quindi richiedere sicurezza a livello messaggio. L’idea è che le informazioni riguardanti gli aspetti di sicurezza possono viaggiare nel messaggio SOAP stesso, il che consente di variare senza fine i possibili schemi di sicurezza impiegati. Per esempio, una porzione di messaggio potrebbe essere firmata e criptata per uno specifico utente, di modo che per altri (o intermediari) risulti opaca, mentre altre sezioni potrebbero esser criptate con una chiave comune a diversi utenti e le restanti parti non criptate in modo da ridurre i tempi richiesti per la criptazione.
Un simile meccanismo è chiamato per tale ragione end-to-end. Per instaurarlo sono però necessari diversi standard di sicurezza, questa volta a livello XML, come XML Encryption, XML Digital Signature, XKMS (XML Key Management Specification).
Ne consegue che la sicurezza a livello messaggio fornisce un ventaglio di possibilità decisamente più ampio di quella a livello trasporto, ma si basa in compenso su un set di standard e tecnologie non ancora mature né uniformemente adottate. Nell’articolo Apache Santuario, crittografia e firma XML in Java abbiamo visto che la criptografia XML non è ancora supportata a livello nativo in Java e richiede librerie esterne. Altra problematica è connessa con il fattore tempo. Una cosa è elaborare in blocco un messaggio come si fa in SSL/TLS, altra è eseguire elaborazioni che tengano conto della struttura del messaggio e operino in base a essa.
Un aspetto da non sottovalutare riguarda l’impatto dei meccanismi di sicurezza sul WSDL, agendo a livello trasporto esso è praticamente nullo. A livello trasporto ci si potrebbe chiedere se il WSDL debba contenere o meno le informazioni sulle misure di sicurezza adottate. Secondo una corrente di pensiero il WSDL deve limitarsi a fare da linguaggio di interfaccia e questo lo esula dal contenere informazioni circa la sicurezza. Per altri invece le problematiche di interfaccia riguardano anche i meccanismi di sicurezza, per cui queste informazioni devono essere esposte nel WSDL; nasce l’esigenza di prevedere un’estensione di WSDL standard in grado di esporre tali informazioni.
WS-Security è una specifica che definisce un’estensione di SOAP che implementa autenticazione, integrità e confidenzialità a livello messaggio per integrare SOAP con soluzioni esistenti, essa si basa su un header SOAP, <Security>, contenente i dati sulla sicurezza e le informazioni per implementare i meccanismi di firma e criptazione. E’ possibile diversificare gli utenti, detti attori (actors).
Ma WS-Security non è l’unico standard riguardante la sicurezza a livello applicazione, un altro è WS-SecurityPolicy che punta a definire un’estensione del WSDL per consentire di esporre le politiche di sicurezza. Ve ne poi altri sui quali tali standard si basano o li completano. Da notare che nel caso di Web services RESTFul niente di tutto ciò è disponibile ed eventuali soluzioni sono a carico degli sviluppatori.
Soluzioni a confronto e best practices
Nella seguente tabella sono riassunte le principali caratteristiche dei due sistemi di sicurezza a confronto.
| Livello trasporto | Livello messaggio |
|---|---|
| Aumenta l’accoppiamento con il livello trasporto | Indipendente dal livello trasporto |
| Protezione punto-punto | Protezione a livello applicazione |
| Ubiquità | Standard ancora in sviluppo e tecnologie non mature |
Tali vantaggi sembrano andare quasi tutti verso la sicurezza a livello messaggio, ma la scarsa maturità degli standard è un aspetto da non sottovalutare; l’utilizzo di sicurezza a livello di messaggio può comportare limiti di interoperabilità in quanto non tutti gli utilizzatori potrebbero implementare i meccanismi di gestione necessari. Nei prossimi capitoli vedremo che client nativi Java possono supportare senza problemi il livello trasporto, mentre per la sicurezza a livello messaggio saranno necessarie estensioni e librerie aggiuntive.
La maggiore granularità della sicurezza a livello messaggio porta a tempi di calcolo maggiori. In generale quando l’applicazione interagisce direttamente con il Web Service è sufficiente utilizzare un meccanismo a livello trasporto. Al contrario, in caso di intermediari, code o richieste peculiari, è consigliabile un meccanismo a livello di messaggio.
Se si considera la presenza di firewall, i meccanismi a livello messaggio normalmente non ne risentono, mentre per il livello trasporto è piuttosto usuale che il porto 443 sia aperto al traffico HTTPS, per cui di norma la presenza di firewall non costituisce un problema.
Nel caso in cui per i web services ci sia richiesta di supporto per diversi protocolli (FTP, TCP, HTTP..) la sicurezza a livello messaggio non andrà ad impattare sul protocollo, mentre risulta complicato fornire un’adeguata sicurezza a livello trasporto.
Infine, occorre considerare che se il Web service è progettato per gestire alti carichi concorrenti, è possibile migliorare le performance a livello trasporto direttamente tramite componenti hardware. Per contro, i security token del livello messaggio consentono di instaurare facilmente sessioni di comunicazione, ma risultano pesanti da gestire in un simile contesto.
Non c’è una risposta definitiva su quale meccanismo usare e non si può dire che le soluzioni siano mutuamente esclusive. In alcuni contesti possono essere utilizzate entrambe, magari sfruttando il livello trasporto per la confidenzialità e il livello messaggio per comunicare tramite l’header l’identità degli utenti, evitando di dover utilizzare algoritmi di crittografia a livello messaggio onerosi per la CPU. In generale però è sufficiente uno dei due meccanismi e per decidere quale livello utilizzare occorrerà stabilire i requisiti del sistema e in base a questi valutare la soluzione ottimale. Infine, la scelta non andrà considerata come definitiva ma occorrerà monitorare eventuali minacce e mantenere un livello di sicurezza sufficientemente alto. Il tutto con un occhio al budget a disposizione.
