Protezione dei Web Services

Una panoramica sui metodi usati per la protezione dell’accesso alle applicazioni

di Roberto Bellucci
Orbyta Basedue
Senior System Programmer

Web Service e Web API

La differenza tra Web Service (WS) e Web API (API) è molto tecnica ma la loro utilità è la stessa, ossia consentire lo scambio di dati tra le applicazioni attraverso il protocollo di trasporto HTTP(S), indipendentemente dal sistema operativo su cui girano e dal linguaggio usato.

Grazie ai WS ed alle API, le aziende connettono tra loro i servizi e trasferiscono i dati. L’aspetto tecnico è molto importante ed è utile sapere che i Web Service si basano su standard molto rigidi e devono sottostare ad un insieme di regole che definiscono la struttura (WSDL) dei messaggi scambiati che possono essere solo in formato XML, mentre le Web API accettano i dati anche in JSON ed essendo molto più snelle sono più adatte ad essere impiegate su dispositivi con banda limitata. Da un punto di vista tecnico queste sono le differenze principali, tuttavia come ho detto prima, l’utilità delle due soluzioni è la stessa, quindi per semplicità userò in questo articolo indifferentemente i termini Web Service(WS), Web API e API, come fossero sinonimi per parlare della loro “messa in sicurezza”.

La API Economy

“Le aziende di oggi si stanno trasformando e uno degli imperativi è quello di ottenere o fornire servizi e informazioni alle persone attraverso il Web.” Ho scritto questa frase quando stavo preparando la presentazione del seminario dallo stesso titolo destinato ai colleghi di Orbyta e benché l’evento si sia svolto in modalità webinar a causa della crisi già in atto, non mi è venuto in mente all’epoca di enfatizzarla come sto per fare ora, per sottolineare il fatto che a causa di quanto stiamo vivendo, la trasformazione a cui accennavo, stia prendendo un’accelerazione ancora più importante e che non ci saremmo mai aspettati!

Viene stimolata una nuova economia, denominata appunto API Economy, in cui l’Application Programmig Interface consente un accesso a servizi, applicazioni e sistemi per condividere le informazioni in maniera innovativa.

Per poter operare in queste nuove realtà è quanto mai necessario che l’accesso ai dati e ai servizi risulti protetto.

WS/API Gateway

Sappiamo che i Firewall tradizionali proteggono solamente il traffico a livello IP controllando il traffico solamente in base alla porta. Per questo risultano incapaci di difendersi da attacchi sempre più sofisticati che si celano dentro payload applicativi, trasportati dai pacchetti IP che attraversano i firewall in un tunnel HTTP(S) esponendo le aziende a sempre nuovi attacchi.

E’ quindi indispensabile assicurarsi che passino solamente richieste valide, per servizi validi, da altrettanti validi clienti; ed ecco che entrano in gioco i Web Service & API Gateway, ovvero i firewall delle applicazioni. Vediamo cosa sono e come svolgono il loro compito.

Esistono molti tipi di WS e API Gateway, alcuni sono degli appliance, altri sono solo in versione virtuale e in cloud. I vendor che offrono queste soluzioni sono molti, tuttavia non sono tanti quelli che possono vantare livelli di sicurezza e prestazioni di alto livello.

La mia esperienza in questo campo si basa sulla conoscenza dell’appliance IBM DataPower® Gateway considerato da molti uno dei leader del mercato.

Detto in poche parole il DataPower® Gateway funge da proxy tra le applicazioni di front-end (FE) e le API di back-end (BE); in pratica le applicazioni di FE non chiameranno direttamente le API ma il Datapower che ha il compito di intercettare tutte le Request alle API ed eseguire svariate funzioni di sicurezza ma non solo come vedremo, prima di inoltrare al server di BE dove risiedono le API le richieste alle quali erano indirizzate.

Tra le funzioni più comuni che un API Gateway deve fare e che il DataPower® svolge molto bene, troviamo la gestione della connessione SSL/TLS, l’autenticazione attraverso i certificati, il controllo della grandezza del payload, lo schema-validation se si tratta di WS,  la limitazione di velocità, il routing, la conversione di protocolli, ad esempio da XML a JSON e viceversa ma anche CSV, Cobol, binary eccetera.

Il DataPower® inoltre, offre un’ampia scelta sul fronte dell’integrazione, permettendo la connessione al Mainframe e al Cics, a molti database quali Oracle, MS SQL, Sybase, DB2 e IMS.

Molte funzionalità, come ad esempio l’autenticazione e lo schema-validation, sono feature già pre configurate e vengono attivate con semplici comandi dalla GUI, altre funzioni come ad esempio la conversione di protocolli necessitano invece di un’attività di implementazione a cura del sistemista attraverso la programmazione con linguaggi di scripting come Java Script e XSLT, quest’ultimo più adatto a gestire payload in formato XML.

Dunque, grazie ai linguaggi JavaScript e XSLT, si è in grado di personalizzare ciascun WS e API esposti dal DataPower®, consentendoci di innescare qualsiasi azione sia a fronte del messaggio in ingresso dal FE che durante la fase di ricezione del messaggio di risposta da parte dell’API. Ad esempio, oltre al già citato caso della conversione dei protocolli, pensiamo a quanto potrebbe essere utile tracciare “chi fa che cosa”, ovvero salvare le Request e le Response relative ai WS, scrivendo su un DB tutta una serie di informazioni utili ai fini di audit e debug, il tutto, vi posso assicurare, con tempi medi di esecuzione di pochissimi millisecondi soprattutto nel caso di trasformazioni XML grazie alla capacità del Datapower di gestire queste operazioni come si suol dire “at wirespeed”.

Vorrei concludere dicendo che in base alla mia esperienza, considero  l’impatto di queste tematiche assolutamente trasversale e non limitato al solo ambito sistemistico, e perciò ritengo che sia molto importante sottolineare che la loro conoscenza possa e debba interessare anche i colleghi Applicativi, specialmente coloro i quali ricoprono un ruolo di progettazione.

Roberto Bellucci

Senior System Programmer 

Inizia come sistemista Mainframe al CED della Olivetti, dopo qualche anno lascia l’azienda di Ivrea per dedicarsi alla consulenza, in seguito alcune iniziative imprenditoriali lo porteranno alla co-fondazione di Basedue. Dopo 15 anni lascia l’esperienza imprenditoriale e torna a dedicarsi alla consulenza. Attualmente fa parte di Orbyta Basedue e svolge la sua attività di consulenza in IntesaSanpaolo.