Con l’accelerazione del percorso di digital transformation, molte organizzazioni si stanno domandando: "Dovremmo lanciare un canale di API pubbliche?"
Possiamo immaginare la reazione dei nostri stakeholder nel momento in cui capiscono che partner e competitor stanno già utilizzando le API per alimentare le loro offerte senza alcun meccanismo per addebitare o addirittura monitorare tale utilizzo.
Quello di cui molte aziende non si rendono conto è che hanno già un canale API pubblico che viene utilizzato da potenziali partner e persino competitor perché gli attuali modelli di sviluppo delle applicazioni nei gruppi IT si basano su API pubbliche per potenziare le applicazioni web e mobile.
Se disponiamo di un'app mobile rivolta ai consumatori, disponiamo di un'API. Se abbiamo un sito web, abbiamo un'API. Potrebbe non essere monitorato o “consumato” facilmente, ma ciò non significa che non sia disponibile e venga utilizzato.
Piuttosto che aspettare le conseguenze dell'utilizzo di API non gestite, è il momento di uscire dall’idea della negazione dell'API pubblica e creare un canale intenzionale.
Negli ultimi anni, MuleSoft ha aiutato le aziende di tutto il mondo a tracciare i propri percorsi per portare sul mercato un portale API rivolto al pubblico.
Sebbene ogni azienda abbia un contesto diverso e una visione unica su come generare valore per i clienti e per l'impresa, esiste un aspetto che le accomuna: hanno già un programma API pubblico di cui non erano a conoscenza.
Un Canale Non Così Invisibile
Com'è possibile che le grandi aziende dispongano di un canale API pubblico che non conoscono? In realtà, scopriamo che esiste una backdoor “non così invisibile” incorporata anche nei siti web e nelle app mobile rivolte al pubblico.
Non solo questa backdoor è disponibile per qualsiasi sviluppatore abbastanza motivato da cercarla, ma è una pratica ampiamente accettata che è approvata dai professionisti della tecnologia e dalle imprese.
Il problema non è che le aziende utilizzano le API per promuovere le proprie applicazioni web e mobile. E non riguarda nemmeno il fatto che gli indirizzi URL siano facilmente accessibili da parti esterne.
Il problema a cui fa riferimento MuleSoft è che una vasta gamma di leader aziendali e tecnologici non è a conoscenza del fatto che hanno reso pubblicamente disponibile la propria infrastruttura API che può essere utilizzata da chiunque gratuitamente.
L’emergere del programma di API pubblico di basso profilo è iniziato 20 anni fa quando AJAX (Asynchronous JavaScript and XML) è diventato disponibile per la prima volta e ha dato il via a quello che allora era noto come “web 2.0”.
Le tecnologie sono state perfezionate e rinominate, ma le basi del modello sono diventate lo standard di fatto per la creazione di applicazioni web altamente reattive e sono state applicate per diventare anche la base delle comunicazioni delle applicazioni mobile.
Che si tratti di una pagina web, un'applicazione mobile o una pagina web incapsulata in un'applicazione mobile nativa, i dettagli degli endpoint API e le credenziali del cliente sono spesso disponibili in pochi minuti per uno sviluppatore interessato a reperire queste informazioni.
Per una serie di ragioni, le tecniche avanzate di offuscamento e i programmi di difesa strategica dal web scraping molto spesso non sono ottimizzate.
Il risultato finale è che molte organizzazioni hanno offerte di shadow API che essenzialmente non sono né gestite né monitorate.
Di seguito, un diagramma di flusso di orientamento per comprendere la gestione delle API pubbliche.
Anche il Modello BFF ha Bisogno di Buoni Perimetri
Una volta che un'organizzazione inizia a sviluppare esperienze mobile ricche di dati o una strategia omnichannel che offre esperienze coerenti tra i punti di contatto del pubblico, emerge la necessità di una strategia API composita.
Le aziende di tutto il mondo stanno scoprendo questa esigenza mentre la spinta alla digital transformation diventa più prevalente in ogni contesto industriale.
Che sia intenzionale o fortuito, il desiderio di conservare i cicli operativi e di sviluppo ha spinto il modello architetturale Back-end for Front-end (BFF), reso popolare da Sam Newman e Phil Calçado, a diventare la norma in un insieme sempre più ampio di imprese e startup.
Mentre i modelli BFF (e le API che li alimentano) sono diventati popolari tra le organizzazioni di sviluppo, la presenza del modello non sempre consente di gestire l'inevitabile fuga di dati che proviene dalle esperienze fornite digitalmente.
La criticità principale sta proprio in questo, quindi riuscire a proteggere i dati che mantengono un’azienda competitiva sul mercato.
Questa vulnerabilità non è nuova per tutti. Molte media properties hanno strategie di difesa dal web scraping che non escludono i modelli BFF. Un modello frequente è quello in cui sono presenti pagine che accedono ai dati tramite server call piuttosto che client call, il che consente alle aziende di mettere in atto "elenchi di autorizzazioni" aprendo contemporaneamente portali API gestiti.
Il Lusso di Ieri è la Necessità di Oggi
Troppo spesso i team IT adottano proposte di team aziendali che trascurano di tenere conto delle realtà del mondo moderno.
I team di business rivendicano il dominio sul "cosa" e presumono di avere la miglior opinione su quali capacità sono necessarie e quali sono opzionabili. Questo modello di processo decisionale che enfatizza le vittorie a breve termine a scapito delle preoccupazioni a lungo termine è più sbilanciato rispetto al passato perché:
- La tecnologia evolve sempre più rapidamente e il business ha accelerato e continua ad accelerare, il che significa che “le preoccupazioni considerate a lungo termine si manifestano in tempi molto più rapidi”;
- il trend del “elementi di fase 2 che non ce l’hanno fatta” è lo status quo quotidiano in molte aziende nel mondo.
Con questo nuovo contesto in mente, alcune capacità che una volta erano considerate un lusso, adesso dovrebbero far parte delle necessità.
Ciò significa che le misure di sicurezza dei dati per mitigare il rischio di estrazione delle API (ad esempio, gestione delle API, limitazione della velocità, abilitazione delle policy “security by design”, monitoraggio del traffico specifico delle API, pratiche di sicurezza "difesa in profondità" incorporate nella rete e/o nell'infrastruttura, ecc.) devono rientrare tra le attività necessarie e prioritarie.
Nel contesto della definizione delle priorità delle capacità aziendali, può essere difficile avere la persistenza necessaria per spostare la posizione dei team distribuiti sull'equilibrio tra capacità architetturali e generazione di entrate.
Allo stesso tempo, la necessità di elevare il tema della sicurezza dei dati sta diventando ogni giorno più evidente poiché le violazioni dei dati diventano sempre più frequenti.
Anche nel contesto delle API "interne", piccoli errori e passi falsi possono rendere un’azienda vulnerabile alla fuga di dati preziosi o sensibili.
Se vuoi avere maggiori informazioni su come proteggere le API pubbliche della tua azienda e vuoi scoprire di più sulle potenzialità di MuleSoft Anypoint Platform, invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250.
Visita la pagina dedicata sul nostro sito per ricevere ulteriore materiale informativo o per richiedere una demo gratuita della soluzione.
In alternativa, puoi compilare il form sottostante con la tua domanda.
