Introduzione a Beyond the Edge episodio 6 – cosa è necessario sapere sulle architetture componibili e sui suoi vantaggi in termini di prestazioni e sicurezza
Tom Mount: Salve e benvenuti a Beyond the Edge, dove ci occupiamo delle assicurazioni e delle tendenze che interessano le moderne aziende digitali.
Sono Tom Mount. Sono Senior Solutions Architect presso Edgio. Mi concentro sulla nostra piattaforma applicativa e sulle nostre soluzioni di sicurezza che fanno parte di tale piattaforma. Sono uno sviluppatore web da quasi 20 anni, lavorando principalmente per o con agenzie di marketing digitale. Ha lavorato molto con Higher ed e-commerce, tra cui eBay, American Airlines e l’Università della Pennsylvania.
E oggi mi unisce Howie Ross.
Howie Ross: Ciao, sono Howie Ross. Sono Senior Director of Product Management per la piattaforma Edgio Applications, dove mi concentro sull’accelerazione web, inclusa la CDN e l’edge computing. Ho lavorato per 20 anni nello sviluppo web e nell’architettura cloud e durante questo periodo ho avuto il piacere di lavorare in molti settori, tra cui Fintech ed ECOMM, dove ho lavorato con numerosi marchi tra cui Urban Outfitters, Coach, Verizone M&MS
Tom Mount: Ottimo. Grazie Howie. Oggi vogliamo parlarvi un po’ delle sfide legate alla sicurezza che devono affrontare l’architettura componibile. Nello specifico, ora sappiamo che esistono molte minacce alla sicurezza per i proprietari di siti Web e i gestori di contenuti.
Secondo IBM, c’è uno studio là fuori che dice che il 83% delle aziende statunitensi ha subito una violazione dei dati e che può costare più di 9,4 milioni di dollari negli Stati Uniti. E’ più del doppio della media globale. Okta, sono uno dei più grandi provider di identità single sign-on al mondo. Hanno pubblicato un rapporto secondo cui il 34% di tutti i tentativi di accesso a livello globale erano effettuati da bot. Quindi, si tratta solo di bot che cercano letteralmente di accedere agli account di rete, hanno appena dimostrato che un’organizzazione su quattro ha perso 500.000 dollari a causa di un singolo attacco bot. Quindi la sicurezza è una minaccia enorme. E’ un problema enorme che dobbiamo affrontare.
E quando parliamo di architetture componibili, questo è qualcosa che inizia a diventare un po’ più difficile da affrontare. E così via, questo podcast di oggi, vogliamo dare un’occhiata ad alcune delle minacce che sono là fuori per le architetture componibili e cosa possiamo fare al riguardo.
Quindi, prima di entrare troppo a fondo, Howie, mi chiedo se tu possa definire per noi cos’è l’architettura componibile, cosa significa per te?
Cos’è l’architettura componibile?
Howie Ross: Certo, ci posso provare. E’ una specie di cose che e’ un po’ difficile da definire, ma lo sai quando lo vedi. L’architettura componibile è in realtà una reazione alle piattaforme all-in-one monolitiche che sono state utilizzate, ad esempio nel decennio precedente e alle limitazioni imposte all’esperienza utente e al flusso di lavoro degli sviluppatori.
Con l’architettura componibile, le soluzioni sono composte da strumenti e fornitori in tutto lo stack che consentono di selezionare gli strumenti migliori per soddisfare le esigenze della vostra organizzazione e degli utenti.
Inoltre, la componibilità è spesso associata a front-end headless o disaccoppiati, in cui separiamo il livello di presentazione dal livello di dati e spesso ci affidiamo a microservizi o almeno ad architetture basate su API per facilitare questa architettura disaccoppiata headless e comporre una soluzione completa con vari strumenti.
Tom Mount: Quindi sembra piuttosto flessibile, ma sembra anche che sia un po’ più difficile dal punto di vista tecnico implementare alcuni di questi stack.
Perché scegliere Composable?
Cosa farebbe scegliere un’azienda di scegliere un’architettura componibile rispetto a questo modello più monolitico, sapete, ben consolidato?
Howie Ross: Si’, e’ una bella domanda. Beh, le architetture componibili offrono numerosi vantaggi, tra cui, come ho detto, un’esperienza utente migliorata grazie a minori limitazioni UX, giusto? Quindi, su uno stack monolitico, sarete spesso limitati a, sapete, quali funzionalità sono fornite da quel stack. Tuttavia, con un’architettura componibile, è come se il cielo fosse il limite.
Il team e i progettisti possono immaginare qualsiasi esperienza desiderino e poi si sa che si avrà più agilità in termini di possibilità di distribuire tali funzionalità agli utenti finali.
In effetti, abbiamo visto che organizzazioni come Iceland Air hanno ridotto del 90% i tempi di consegna per implementare nuove funzionalità, incluse le promozioni. In questo modo, avrete ridotto il time-to-market e il time-to-value per il lavoro.
Inoltre, come ho detto, potete scegliere gli strumenti e i fornitori migliori della categoria e creare davvero questa rete di partner dell’ecosistema su cui fare affidamento per creare la vostra soluzione e offrire quel valore.
E poi è un po’ più a prova di futuro rispetto a una pila monolitica, perché è possibile scambiare questi strumenti con e con quelli che si ritiene più opportuno. Quindi, supponiamo che lo strumento di revisione dei clienti non soddisfi più le vostre esigenze. Si desidera utilizzarne uno diverso. Non è necessario sostituire l’intera soluzione. Potete semplicemente sostituire lo strumento specifico e continuare a iterare lo stack e mantenerlo davvero moderno.
Tom Mount: Vedi ora stai parlando un po’ di lingua lì. Il mio background è la creazione di più applicazioni sul Web e, guardando l’architettura di alcune di queste cose, mi piace l’idea, l’idea di dover apprezzare uno stack a prova di futuro in cui è possibile spostare le cose dentro e fuori.
E penso anche che il futuro sembra che si estenda non solo a livello di componente ma anche a livello di infrastruttura, giusto? Voglio dire, stiamo vedendo molto più concentrazione sulle cose fatte alla periferia della rete, le cose fatte senza server nel cloud di quanto non fossimo, sapete, 5 anni fa, 10 anni fa.
Certamente, c’è molta più enfasi su questo e penso che avere un’architettura più flessibile in cui è possibile spostare i componenti da un data center più grande a un altro ovviamente è il cloud, tutto è in un data center, giusto? Capiamo quella parte.
Ma avere qualcosa in cui concentrarti maggiormente sulla periferia e creare elementi specifici per l’elaborazione edge per funzioni senza server e mantenere queste cose veloci e agili è un enorme, enorme vantaggio. E penso anche che la sicurezza sia, è anche qualcosa che trae vantaggio da questo, giusto? Poiché molti dei nostri servizi e altre cose sono stati migrati nel cloud e abbiamo queste soluzioni abilitate per la periferia, la sicurezza è un fattore che va di pari passo.
Quindi possiamo fare molta sicurezza zero-trust direttamente alla periferia della rete, invece di dover tornare indietro in un data center e avere un’architettura componibile ci consente di creare una sicurezza zero-trust direttamente nella struttura dell’applicazione stessa. E io, come ho detto in cima, ho costruito siti web per 20 anni. Ho lavorato con catene di attrezzi ovunque. Una delle cose interessanti che abbiamo visto specialmente con alcuni framework componibili è che molti di questi framework ora hanno funzionalità integrate per la generazione statica di siti.
E questi elementi possono essere semplicemente trasmessi in streaming direttamente nella pipeline di generazione e inviati come parte di questo, è possibile semplicemente sostituire i componenti o le architetture che si desidera. La pipeline costruirà tutto e tutto finisce per essere noto, suddiviso in file statici HTML, CSS, JavaScript, le immagini di cui abbiamo bisogno, indipendentemente da come sono state costruite e da quali pezzi di puzzle si adattano, le pipeline possono rimanere invariate. Le implementazioni possono ancora riflettere questo. Penso che questo sia un aspetto che mi colpisce dal punto di vista dell’architettura come un altro paio di vantaggi che si ottengono dalla capacità di spostare questi componenti dentro e fuori.
Storie di successo dei clienti – Universal Standard
Howie Ross: Sì, questi sono ottimi punti che conoscete, quindi, oltre ai vantaggi per il team di sviluppo e per il cliente, vi sono vantaggi significativi per voi che conoscete il team DevOps e le opzioni che vi offre per l’architettura della vostra infrastruttura.
Sia che si tratti di sfruttare la generazione statica e di costruire il proprio sito per la CDN e per l’edge della rete o di sfruttare senza server e sfruttare appieno i progressi della tecnologia cloud per la scalabilità e la sicurezza. E sapete, così sapete che io e Tom abbiamo avuto il piacere di lavorare con un certo numero di clienti che hanno intrapreso questo viaggio verso la componibilità e che hanno visto vantaggi significativi.
Quindi sapete che i clienti includono che conoscete alcuni di quelli che ho menzionato in precedenza, come Coach e M&M, che sapete di aver completato o che sono in viaggio lungo il loro percorso componibile.
Uno degli altri clienti poco conosciuti si chiama Universal Standard, che ha la missione di essere il marchio di abbigliamento più inclusivo al mondo. E sai per quella missione hanno scelto di andare con un’architettura componibile costruita sulla piattaforma Shopify.
In questo modo, invece di essere un po’ vincolati dalle limitazioni imposte da Shopify in termini di esperienza utente e flusso di lavoro degli sviluppatori, essi sfruttano le API di Shopify Storefront e creano una soluzione componibile utilizzando il framework Nuxt, basato su Vue JS.
E hanno visto che conoscete un significativo miglioramento delle prestazioni, sapete, riducendo i tempi di caricamento delle pagine da più secondi a in molti casi al di sotto del 2° e migliorando, non solo queste metriche tecniche delle prestazioni, ma anche le metriche aziendali effettive.
In effetti, hanno visto un miglioramento del 200% del tasso di conversione come risultato di questo passaggio alla componibile. Questo ovviamente sta davvero influenzando i loro risultati e li sta aiutando nella loro missione.
Storie di successo dei clienti – Carnevale delle scarpe
Tom Mount: Sì, è davvero fantastico. Voglio dire, abbiamo parlato del fatto che sai che le pagine sotto la seconda vengono caricate qui ed e’ sempre gente. Quando parlo con le persone, ho sempre l’occhio laterale come se ne fossi sicuro e no, è vero. Conoscete uno dei clienti che a volte mostro che ha una storia simile, è un’azienda chiamata Shoe Carnival, quindi si sono trasferiti anche a Headless. Avevano la loro architettura precedente. Hanno esaminato in modo specifico i problemi di prestazioni relativi ad aspetti come il caricamento della prima pagina e le transizioni tra le pagine.
Quindi le loro statistiche prima di andare headless, stavano guardando, sapete, 3, 3, 3 1/2 secondi per il caricamento della prima pagina e a volte fino a 6 secondi per il passaggio da una pagina all’altra durante la navigazione. E volevano davvero farlo. E ci sono molte ragioni per cui e’ una grande idea spostare la cosa verso il basso.
Abbiamo molte ricerche di mercato che dimostrano che per ogni secondo in più i clienti attendono mentre la pagina viene caricata, aumentano le loro possibilità di uscire dal sito e andare da qualche altra parte. Quindi, ovviamente, la velocità della pagina e il tasso di conversione sono strettamente legati e lo riconoscono.
Così sono venuti a Edgio in cerca di aiuto e subito hanno finito di passare a headless e hanno fatto alcuni di questi miglioramenti delle prestazioni di cui abbiamo parlato. Hanno preso le loro transizioni e anche la loro prima pagina si carica a un secondo, a volte anche meno di un secondo. Sono fino al 70% più veloci su Edgio. Il tempo medio di caricamento delle pagine è di un secondo, giusto? Quindi stanno assistendo a enormi miglioramenti delle prestazioni come conseguenza della scelta di questa architettura headless e della possibilità di ottimizzare le loro prestazioni a ogni livello dello stack. E anche le pagine caricate, le pagine successive vengono caricate da, sai, una volta che arrivano sul sito, sono in calo del 92% su quella velocità. Sono scesi a 500 millisecondi su alcuni di quei caricamenti di pagina. Quindi sono riusciti a realizzare enormi guadagni di prestazioni.
Ma non sono solo le prestazioni ad essere una caratteristica interessante di Composable. Aderendo al Carnevale delle scarpe. Oltre ai guadagni prestazionali, hanno anche colto l’opportunità di passare alla soluzione componibile per aumentare alcuni dei loro sforzi di sicurezza. E, quello che hanno scoperto è che nei primi 30 giorni dal lancio del loro nuovo sito componibile, avevano rintracciato oltre 8 milioni di richieste dannose bloccate. E voglio concentrarmi, mi assicurerò di ribadire che quelle richieste sono state bloccate.
Non era che, sai, avessero 8 milioni di richieste con cui non sapevano cosa fare, giusto? La soluzione di sicurezza che abbiamo trovato era in grado di bloccare tutte queste richieste e fornire visibilità su ciò che forse non avevano visto prima del volume di richieste dannose che ricevevano.
Vantaggi per la sicurezza di Composable
Questo tipo di transizione mi porta a parlare un po’ dei vantaggi per la sicurezza, perché finora abbiamo parlato di miglioramenti delle prestazioni e sono molto reali. E sapete, noi, seguiamo i nostri clienti quando arrivano, ci piace vedere i loro guadagni prestazionali e abbiamo alcune storie di successo straordinarie.
Ma penso che i guadagni di sicurezza siano un’altra buona ragione per scegliere un’architettura componibile. Mi piace vederla come una sorta di difesa a più livelli, giusto? Vogliamo quindi tenere gli utenti malintenzionati il più lontano possibile dall’origine, da dove si trovano i server effettivi e i dati. E ci si può pensare in termini di, sapete, di mettere una recinzione intorno alla vostra proprietà. Potete avere dei cartelli sul vostro recinto, diciamo, tenetevi fuori, sapete, non dovete reprimere niente. Ma questo non significa necessariamente che non chiuda la porta di notte. Significa solo che volete mettere una barriera di sicurezza il più lontano possibile per tenervi fuori il più possibile.
E quando si sceglie un’architettura componibile, uno dei vantaggi è quello di scegliere e scegliere le funzioni di protezione esistenti e la posizione in cui si trovano tali funzioni di protezione.
E ti consigliamo di avere la sicurezza a tutti i livelli che puoi mettere a posto. Quindi metteremo quella sicurezza all’edge, la metteremo all’origine. Se esistono altre API o servizi, abbiamo detto che diventare componibili significa in genere aumentare il numero di API esposte nel sito. Vogliamo quindi essere certi che queste API abbiano sicurezza e, grazie a un’architettura componibile, ciò diventa davvero semplice. Dovete rendere conto di tutti questi posti, ma potete mettere fuori sicurezza a tutti questi livelli.
Una delle altre cose belle di avere un’architettura componibile, e l’ho già accennato un po’ prima, è la capacità di avere quelle pagine statiche. Ora, le pagine statiche sono ottime per le prestazioni, ma offrono anche un notevole vantaggio per la sicurezza, poiché le pagine statiche riducono al minimo la quantità di trasferimento dati bidirezionale che avviene tra il client e il server.
Se si pensa a un tipo tradizionale di app monolitica, app PHP o qualcosa del genere, qualcuno sta immettendo i dati in questa applicazione e deve reinserirli nel server. Se stai caricando una nuova pagina, il server deve richiedere questi dati e inviarli nuovamente. I dati possono entrare e uscire dai vostri sistemi in molte occasioni. E ovviamente ci sono dei dati che devono venire fuori.
Si desidera assicurarsi che non tutti i dati presenti nei sistemi vengano visualizzati. E’ quella che chiamiamo una violazione dei dati.
Quindi, avere pagine statiche riduce le opportunità per qualcuno di manipolare con il server tramite la pagina visualizzata nel browser Web perché tutto ciò che c’è nella pagina è solo HTML, giusto?
No, ha già i dati. Non si tratta di recuperare quei dati da nessuna parte. E’ stato già costruito pensando a quei dati. Pertanto, avere pagine statiche note, anche se certamente un aumento delle prestazioni può anche essere un aumento della sicurezza e queste pagine statiche possono essere servite direttamente da una CDN.
Penso che questo sia l’ultimo pezzo del puzzle, in quella particolare parte della sicurezza, è che invece di dover tornare ai server per recuperare questi dati ogni volta che la pagina viene caricata con la CDN, quella pagina viene memorizzata nella cache, è disponibile in tutto il mondo e i server non vedono nemmeno quelle richieste perché vengono gestite direttamente all’esterno.
Howie Ross: Sì, è un ottimo punto. E sono d’accordo sul fatto che conoscete uno dei vantaggi principali di una soluzione componibile, sia che abbiate familiarità con la generazione statica di siti o che stiate sfruttando il rendering server-side senza server, è la capacità di sfruttare la CDN in modo più efficace. In questo modo si otterranno tempi di caricamento delle pagine più rapidi, ma anche vantaggi per la sicurezza, oltre a essere sicuri di tenere gli utenti malintenzionati il più lontano possibile.
Sapete dai vostri dati e dai vostri gioielli e sapete anche minimizzare il trasferimento dei dati bidirezionali, ma sapete anche che, sebbene vi siano alcuni vantaggi per la sicurezza, penso che ci siano anche alcune sfide.
Abbiamo parlato di soluzioni componibili, sapete che state selezionando i migliori fornitori e strumenti e questo significa che ci sono, sapete, più strumenti, più fornitori, il che significa che potenzialmente conoscete più modi per entrare nei vostri sistemi e nelle vostre architetture. Quindi è un rischio.
E uno dei modi sempre più comuni per compromettere le organizzazioni è attraverso la conoscenza della rappresentazione, giusto, piuttosto che sapere che mi costringono a entrare nel vostro sito web o nei vostri server. Sto solo per capire come fare ad ingegnerizzare il mio modo di apparire come uno dei tuoi dipendenti. E ora invece di dover violare la vostra rete principale e conoscere gli strumenti aziendali. Potrei essere in grado di violare uno dei tanti strumenti e fornitori che utilizzate per la vostra soluzione componibile, in modo da sapere che la gestione delle identità e degli accessi diventa sempre più importante.
Quindi è e sapete che questo può essere mitigato in diversi modi grazie alla conoscenza di standard, single sign-on e cose del genere. Ma si tratta di qualcosa che si vuole essere, che si conosce bene perché si conosce l’aumento dello skimming dei dati e si sa che si tratta di una classe di vulnerabilità o exploit.
Viene spesso chiamato “carrello mago”, che era uno degli sfruttamenti originali di questo tipo di attacco, in cui si sa che uno script viene inserito in un sito Web da questi aggressori che poi, sapete, screditano le informazioni personali.
In questo caso, si trattava di informazioni sulle carte di credito provenienti principalmente da siti Magento ed era diffusa e sapete, in realtà ha portato in prima linea la criticità e la gravità di questo problema e l’importanza di avere, sapete, la gestione dell’integrità del vostro codice attraverso l’intera catena di fornitura.
Inoltre, sai, ho menzionato l’importanza di prestare molta attenzione alla gestione delle identità e degli accessi, sì, questo ha molto senso.
Tom Mount: Sapete, ovviamente con più strumenti ci sono più opportunità per entrare. Dal punto di vista dell’architettura delle applicazioni, molti siti componibili utilizzano spesso le chiamate API al server per popolare nuove pagine e facilitare una navigazione più rapida. E penso che la sicurezza delle API sia un’altra area in cui bisogna prestare maggiore attenzione a ciò che si sta facendo e a ciò che sta succedendo.
Quindi ovviamente, sai, non voglio la mia pagina quando faccio acquisti su un sito. Non voglio che la mia pagina venga memorizzata nella cache per te e probabilmente non vuoi che il tuo carrello venga memorizzato nella cache per me, perché questo crea confusione e non capisco perché. Sapete perché ho quello che ho nel mio carrello quando lo metto su.
Ovviamente dobbiamo assicurarci di avere pagine reattive veloci, ma vogliamo anche assicurarci che siano personalizzate per il singolo utente e, di solito, ciò avviene attraverso una sorta di accesso API, e molte volte le informazioni del visitatore finiscono nei dati API trasmessi.
Ed è qui che entra in gioco la parte zero-trust della sicurezza in particolare per quanto riguarda l’API, giusto? Quindi possiamo fare cose come la personalizzazione edge in cui raccogliamo i contenuti, memorizziamo i contenuti nella cache dal server, e all’edge invece che nel browser, estraiamo questi dati dal server e li incorporiamo nella risposta finale che inviamo. Questo è un ottimo modo per avere pagine molto veloci e reattive che sono ancora memorizzate nella cache ma contengono anche dati personali.
Un altro modo in cui possiamo fare un po’ di magia sulla sicurezza all’edge è usare qualcosa come, sapete, JSON Web Token per l’autenticazione. Questa è che l’intelligenza artificiale non entrerà nei dettagli di ciò che è perché è uno dei miei progetti preferiti attuali con cui giocare. E potrei parlarne per altri 20 minuti da sola. Ma podcast, si’, faremo, faremo un podcast su JTBTS dopo.
Ma sì, la parte più interessante è che i dati vengono trasmessi in un certo senso in testo chiaro, ma hanno anche una firma crittografata che il server sa come generare la propria versione di quella firma crittografata.
Quindi, è possibile controllare la validità dell’utente che entra per assicurarsi di sapere che non è stato manomesso nulla, che le credenziali sono corrette e che l’utente ha accesso a tutto ciò a cui dice di avere accesso.
È possibile verificare che l’accesso sia ancora valido e corretto. E potete farlo anche all’edge della rete utilizzando, sapete, la funzione surplus o la funzione cloud, cose del genere. Quindi, il completamento delle API sarà davvero fondamentale per affrontare, sai, sia che si utilizzi l’autenticazione zero-trust o qualche altro meccanismo.
La sicurezza API è un must, sì, perché mi dispiace, mi dispiace, vai avanti.
Howie Ross: Quindi questo è uno dei principali compromessi delle architetture componibili, giusto? Quindi sapete che sappiamo che non stiamo costruendo la nostra applicazione per trarre vantaggio dalla CDN e dal computing Edge, ma per mantenere quelle che conoscete quelle esperienze dinamiche che la personalizzazione deve sfruttare le API. Sappiamo che abbiamo una specie di potenziale proliferazione di servizi e API che possono effettivamente aumentare l’area di superficie delle minacce.
Ora è fondamentale sfruttare una soluzione di sicurezza API che sarà un po’ diversa da quella che conoscete, conoscete le soluzioni di sicurezza più convenzionali che stiamo per adottare, sapete che ci accingiamo a toccare per un attimo perché devono essere personalizzate per quel caso di utilizzo API, giusto. E quindi dobbiamo prima di tutto essere sicuri di conoscere tutte le API, giusto?
Pertanto, è consigliabile sfruttare uno strumento che esegue la rilevazione delle API e ti aiuta a trovare e gestire tutte le tue API, assicurandoci di non avere nessuna delle API zombie che sono API sviluppate a un certo punto e che forse non sono più state ripetute e forse non sono più in uso, ma sono ancora disponibili.
Quindi dobbiamo disporre di un inventario completo delle nostre API e della nostra area di superficie delle minacce. E poi vogliamo che tu conosca alcune pratiche di sicurezza di base, come la limitazione della velocità, giusto?
Vogliamo controllare la velocità con cui qualcuno può richiedere dati da queste API e, più specificamente, che un bot o un utente malintenzionato che utilizza l’automazione può richiedere risposte da queste API, in modo da non sovraccaricarle e creare in modo efficace una situazione di Denial of Service.
L’altra cosa che possiamo fare con la sicurezza delle API, che è davvero interessante e sta diventando sempre più accessibile man mano che adottiamo e utilizziamo l’intelligenza artificiale, è quella che chiamiamo convalida degli schemi. Ecco dove andremo, sapete, prima della nostra richiesta, è la vostra API direttamente all’edge, ci assicureremo che questa richiesta sia conforme allo schema delle vostre richieste API, giusto?
Quindi, se non sembra una richiesta API correttamente formata, la bloccheremo al gate, la fermeremo proprio all’edge della rete e non arriverà mai nella vostra, sapete, infrastruttura per essere, si spera, rifiutata lì. Ma sì, sarà fondamentale sfruttare la sicurezza delle API e sta diventando sempre più comune, accessibile e utile.
Tom Mount: Sì, sicuramente. E come sapete, parliamo di alcune delle nostre preoccupazioni specifiche e componibili in materia di sicurezza e dei modi per mitigare alcune di queste cose. Ma penso che sia anche importante non dimenticare le vecchie cose della sicurezza di riserva, giusto? Le cose che ci hanno servito abbastanza bene per un po’.
Ho detto prima che sai che la sicurezza è molto simile a quella che sai avere un mucchio di strati diversi solo perché solo perché chiudi il cancello di notte non significa che lasci la porta spalancata, giusto?
Parliamo ora di alcune delle pratiche di protezione generali che forse sono ancora perfettamente corrette e dovrebbero far parte dell’architettura complessiva anche se non è specificamente orientata verso un’architettura componibile.
BEST practice per migliorare il vostro approccio alla sicurezza
Howie Ross: Certo. Quindi conoscete questo approccio di sicurezza a più livelli che avete menzionato. Spesso la chiamiamo anche difesa in profondità, giusto? Quindi sai tra l’attaccante e i gioielli della corona che spesso saranno conosci i dati della tua azienda e del tuo utente. Vogliamo disporre di più livelli di sicurezza in modo che, nel caso in cui uno venga violato, continuino ad avere questi livelli aggiuntivi. Quindi, ci sono una serie di fattori attenuanti e sistemi che vogliamo mettere in atto.
E la prima cosa che conoscete il vecchio standby di cui avete parlato Tom, che sarà il nostro Web Application Firewall e vogliamo assicurarci di disporre di un WAF robusto con un’ottima serie di ruoli gestiti per bloccare le aspettative di tutte le vulnerabilità note.
E vogliamo essere sicuri che sappiate che stiamo lavorando con un partner che rilascia patch per nuovi ed emergenti exploit zero-day rapidamente, giusto?
Quindi, invece di dover applicare patch individuali a ciascuna delle vostre API, possiamo distribuire una patch sul nostro WAF all’edge della rete e mitigare tale vulnerabilità in tutti i nostri servizi.
E poi, sapete, abbiamo parlato prima dell’impatto dei bot, dell’aumento degli attacchi bot, del numero di richieste bot che si verificano sui nostri sistemi. Ora non tutti i bot sono cattivi, vero? I bot controllano i nostri siti e rendono disponibili i dati per i motori di ricerca. Quindi è fondamentale lasciare che certi bot facciano il loro lavoro e bloccare bot, bot dannosi che stanno cercando di fare cose come la potenziale negazione dell’inventario, giusto? Stanno cercando di comprare tutte le sneakers o tutti i biglietti prima che gli altri utenti possano prenderli.
I bot stanno anche facendo cose come l’acquisizione degli account. Stanno solo provando diverse combinazioni di nomi utente e password o stanno provando nomi utente e password che sono stati violati da un altro sito. Lo stanno provando sul vostro sito potenzialmente perché sanno che molte persone riutilizzano le password. Pertanto, sarà fondamentale disporre della nostra soluzione di gestione dei bot.
Tom Mount: Sì, sicuramente e penso che tu conosca uno degli altri di cui tutti abbiamo sentito parlare conosci le cose di gestione dei bot che vendiamo biglietti come sai che abbiamo avuto problemi con i venditori di biglietti i cui biglietti vanno in vendita e vengono immediatamente presi in giro dai bot, giusto?
Le nuove sneakers sono state ritirate dal produttore e all’improvviso quelle sneakers sono scomparse. E io dico alla gente a volte circa il 50% scherzando che, sai, in 10 anni Internet sarà praticamente solo bot che attaccano altri bot, giusto? E’ tutto qui, giusto? I bot compreranno scarpe da altri bot. Attaccheranno altri siti web.
E dirò anche che, per quanto riguarda gli attacchi bot, ricordo quando ho iniziato nel settore, gli attacchi DDoS erano rari, giusto? Gli attacchi DoS sono stati rari perché ci sono voluti molti soldi e sforzi per spenderli in uno di questi. Non e’ piu’ il caso, vero? Come abbiamo visto attacchi bot. Questa è, credo che questa sia la realtà della situazione odierna, in cui non è necessario essere enormi per essere bersaglio di un attacco Denial of Service e gli autori degli attacchi non devono essere ricchi per eseguire quegli attacchi. I set di strumenti, le toolchain e le risorse di cloud computing per far girare queste cose.
Voglio dire, abbiamo anche visto attacchi Denial-of-service che includono quelle che chiamiamo reti bot, giusto sono solo computer da qualche parte che sono stati coinvolti in questo attacco, incluso probabilmente quello che si trova sul tuo frigorifero intelligente o sulla tua lavatrice, giusto?
Come se fosse una conseguenza del fatto che sempre più cose sono connesse a Internet e che un numero maggiore di computer disponibili in pacchetti più piccoli è più distribuito a livello globale. Abbiamo assistito a un enorme aumento degli attacchi Denial of Service.
E penso che tu sappia, pensando non solo alla sicurezza, ma solo alle BEST practice per costruire un sito web in generale, giusto, è il 2024 a partire da questa registrazione, almeno hai bisogno di una CDN, giusto, perché la CDN sarà davvero il modo migliore per assorbire questi livelli di attacchi e soprattutto questi attacchi distribuiti.
Questo fermerà tutti? Nessuno. Ma sai, negli ultimi cinque anni ho avuto due o tre aziende che non sapevano di essere state attaccate perché la loro CDN era così brava ad assorbire l’attacco.
E’ stato solo dopo l’attacco che sono tornati nei loro registri. E non parlo molto tempo dopo, sai, un paio d’ore o un giorno o due dopo tornano nei loro registri come Wow, abbiamo avuto milioni, milioni e milioni di richieste nell’ultimo.
Mi chiedo cosa sia successo qui. A volte, sai, se gli avvisi sono attivati, possono vedere l’aumento del traffico e non lo vedono mai davvero sul loro sito web. E quindi una CDN è un modo ingannevolmente semplice per gestire questi attacchi Denial of Service.
E quindi sai anche con tutte le nuove opportunità di sicurezza là fuori, come alcune delle cose di sicurezza API sono davvero affascinanti per me. Mi piace parlarne.
Alcuni di questi sistemi di sicurezza a zero trust sono che ci sono cose che stanno accadendo in quel campo che sono semplicemente, sapete, strabilianti alla velocità con cui stiamo avanzando.
Ma sai qual è il vecchio di cui hai ancora bisogno per la CDN, hai ancora bisogno di un WAF, giusto? Voglio dire, questi sono buoni strumenti da avere e continueranno a essere buoni strumenti da avere indipendentemente dal tipo di architettura che deciderete di scegliere man mano che andrete avanti.
E Howie, credo che una delle cose che hai menzionato di tanto in tanto voglia chiamare, perché hai detto di avere un buon partner che capisce queste cose.
Penso che ci fosse una sensazione nella creazione di applicazioni web, specialmente tra le grandi imprese, che dovevamo sempre andare da soli, giusto? Abbiamo bisogno dei nostri esperti interni, abbiamo bisogno della nostra gente interna per farlo. E questo ha portato molte persone in-House a tirare un sacco di ore e diventare davvero molto frustrante e un po’ bruciato.
Quindi, quando si sceglie un’architettura componibile, tenere presente che non è solo l’architettura vera e propria che si può scegliere al meglio. Puoi anche trovare i migliori partner che ti aiuteranno a navigare in questo spazio.
Sai, trova qualcuno che ha già fatto questo prima e che abbia un buon senso delle minacce che stanno accadendo nel modo in cui le cose stanno costruendo e lavora con quel partner e costruisci una relazione con loro per aiutare a garantire prestazioni veloci e a ottenere risultati ottimali.
So che abbiamo parlato molto dei vantaggi dell’esperienza utente rispetto al flusso di lavoro. Sa che ci sono altri punti di vista che ritiene utili da evidenziare mentre concludiamo qui?
Ultimi punti chiave
Howie Ross: Sì, penso che tu abbia toccato i punti salienti di come sai che la componibilità ha molti vantaggi, tra cui l’esperienza utente e il flusso di lavoro, che possono avere impatti tangibili, sai se si tratta di riduzione dei costi o aumento dei ricavi. Ma introduce anche alcuni che conoscete alcune nuove preoccupazioni che abbiamo trattato.
Quindi, sapete che avrete ancora bisogno di, le soluzioni di sicurezza che saprete sfruttare e vogliamo essere certi di avere alcuni dei vostri conoscenti, nuovi strumenti di sicurezza e stiamo prestando molta attenzione anche alla gestione delle identità e degli accessi.
E poi sapete, ripetete che lo sapete, offre l’opportunità non solo di selezionare fornitori, ma anche di selezionare partner che non solo lo hanno già fatto in passato, ma che lo stanno facendo, sapete, con altre aziende, in modo da sapere che potete trarre vantaggio dalla loro vasta esperienza in vari clienti e settori.
Tom Mount: Sì. Beh, grazie Howie per aver trovato il tempo di parlare un po’ con me di questo. E’ stato, e’ stato divertente. Spero che per i nostri ascoltatori e i nostri spettatori là fuori, spero che questo vi abbia fornito alcune buone informazioni su cui riflettere e alcune cose da considerare.
E sapete che Edgio è pronto ad aiutarvi come partner di fiducia per voi e ci piacerebbe condividere con voi alcune delle nostre esperienze e alcuni dei nostri successi.
Grazie a tutti per aver partecipato a Beyond the Edge e ci vediamo la prossima volta.
Per prestazioni più veloci, sicurezza più intelligente e team più felici, rivolgiti oggi stesso a uno degli esperti di Edgio.
