DE{CODE}: Perché l'Edge non è un caso Edge

Quando sei al limite, la velocità, la sicurezza e l'integrità del server non possono essere un ripensamento. In questa sessione, Cloudflare VP of Product Sergi Isasi e WP Engine Product Manager Pavan Tirupati discutono perché avere una mentalità edge-first è essenziale per il successo di ogni sito web che costruisci o mantieni

Slide della sessione

Trascrizione del testo completo

PAVAN TIRUPATI : Ciao a tutti. Grazie per esserti unito a noi in questa sessione su come l'età non sia davvero un caso limite. Sono Pavan Tirupati, Product Manager di WP Engine con il team di The Outreach, e sono il principale responsabile della sicurezza, delle prestazioni e dell'affidabilità dell'edge per far crescere e potenziare i clienti di WP Engine.

E si unisce a noi oggi da Cloudflare è Sergi, VP of Product Management. Sergi, vuoi presentarti?

SERGI ISASI : Certo. Grazie per avermi ospitato, Pavan. E grazie a tutti per esservi uniti alla nostra sessione. Quindi, come ha detto Pavan, sono un vicepresidente del prodotto per le prestazioni delle applicazioni presso Cloudflare, concentrato sulle prestazioni e l'affidabilità del nostro vantaggio. Vogliamo rendere le cose veloci e affidabili per tutti i nostri clienti. I prodotti che tratterò sono il modo in cui Cloudflare riceve ed elabora il traffico all'edge, quindi sia a livello 4 che a livello 7. Ciò include la nostra cache, il nostro proxy, lo spettro FL, la tecnologia fondamentale per Cloudflare come i nostri sistemi DNS, i nostri sistemi di gestione dei certificati e il nostro Sistemi di gestione degli indirizzi IP, e poi anche le nuove applicazioni edge, quindi bilanciamento del carico, il nostro nuovissimo prodotto Waiting Room e i nostri prossimi prodotti Web3.

Lavoro in Cloudflare da circa 4 anni e mezzo. E ancora, felice di essere qui oggi.

PAVAN TIRUPATI: Fantastico. E oggi abbiamo una meravigliosa sessione per voi ragazzi mentre scaviamo più a fondo su cosa sia esattamente edge e come sia utile, e come dice il titolo, perché edge non è più un caso limite. L'agenda che abbiamo per voi ragazzi è uno scavo più profondo su cosa sia il vantaggio e quali siano i suoi vantaggi. E dati questi tempi, è fondamentale concentrarsi maggiormente sulla sicurezza.

E parleremo di alcuni esempi e parleremo di alcune minacce alla sicurezza. Vedremo anche come l'edge sarà vantaggioso per il pubblico che è qui e per tutti coloro che hanno una presenza digitale nel mondo. E esamineremo anche alcuni esempi specifici che potrebbero essere utili per le persone che potrebbero affrontare alcune di queste minacce e problemi di sicurezza.

Quindi sarà eccitante, pieno di risorse e perspicace. Quindi iniziamo con l'impostazione di un contesto qui. Voglio stabilire una linea di base di ciò che è edge. E penso che non sia una sorpresa per nessuno quando dico che le aziende stanno vivendo un passaggio a una cultura del costruttore, basata sulla capacità degli sviluppatori di creare e controllare direttamente le esperienze digitali.

Man mano che i siti e le applicazioni passano da build monolitiche a più di un'architettura di microservizi, la capacità di fornire contenuti da diverse fonti diventa sempre più importante. E sappiamo e comprendiamo che il limite fa parte di Internet che è effettivamente il più vicino ai nostri utenti finali, a volte indicato anche come l'ultimo miglio. Ma prima di entrare nello specifico, Sergi, voglio chiarire al pubblico qual è il vantaggio e perché è persino critico.

SERGI ISASI: Certo. Quindi c'è un detto di lunga data nel cloud computing, che è "il cloud è solo il computer di qualcun altro". Mi piace molto questo detto. Significa che è la stessa cosa che avresti sul tuo desktop o laptop, ma è solo che qualcun altro lo sta gestendo. E il bordo è esattamente la stessa cosa, è solo più vicino all'utente.

Perché è importante? Vogliamo che le cose, in Cloudflare, siano il più vicino possibile all'utente. E si riduce davvero a quell'affermazione che hai detto, che è l'ultimo miglio. Quindi, non importa quanto velocemente crei il tuo software, quanto efficiente puoi renderlo, se rispondi anche a qualcosa, se il tuo software può funzionare in meno di un millisecondo, sei ancora legato alla velocità della luce. E se il tuo software non si trova sul dispositivo dell'utente o il più vicino possibile all'utente, l'utente sperimenterà quel po 'di latenza. E a volte quella latenza va bene ea volte è molto, molto fastidiosa per l'utente finale. Quindi il punto è ottimizzare ciò che ha senso essere vicino all'utente finale sul bordo o ciò che è vicino al nucleo.

E quello che fa Cloudflare è cercare di mettere tutto al limite. Penso che uno dei motivi per cui mi hai chiesto di fare questa chat sia perché gestiamo probabilmente una delle più grandi reti edge del mondo e ne siamo ovviamente incredibilmente orgogliosi. Cloudflare ha poco più di 10 anni e abbiamo costruito questa rete per tutto questo tempo. È cresciuto fino a essere presente in 250 città, 100 paesi diversi, con l'obiettivo – e in realtà l'abbiamo raggiunto – di essere entro 50 millisecondi dal 95% degli utenti Internet in tutto il mondo. E quello, ancora una volta, l'ultimo miglio: se riusciamo a essere entro 50 millisecondi, possiamo essere molto più veloci per ciascuno di quegli utenti finali.

L'altra parte è connettersi ad altre reti. Quindi ci colleghiamo ad altre 10.000 reti in tutto il mondo, molti ISP locali, ad esempio, e poi gestiamo anche la nostra dorsale, quindi esegui il backhauling di quel traffico per quando abbiamo bisogno di andare al core o all'origine, fai in modo che ancora più veloce. Abbiamo chiuso il 2021 con poco più di 100 terabit al secondo di capacità. E questo è importante quando si tratta di ridimensionamento orizzontale sia per l'aumento del traffico per i nostri clienti sia per l'aumento degli attacchi ai nostri clienti e anche alla nostra rete.

Una delle cose interessanti del calcolo negli ultimi 30, 40 anni è la sua transizione, avanti e indietro, dall'edge al core al client, a seconda di dove aveva senso e dove si trovava tutta la potenza di calcolo in quel momento. Quindi, se pensi a Internet pre-pubblico, avevi i mainframe. Avevi molta potenza di calcolo al centro e pochissima potenza di calcolo all'edge e quantità davvero ridotte di larghezza di banda per la transizione avanti e indietro. Quindi stavi inviando comandi al mainframe e ti avrebbe restituito i risultati di quei comandi nel testo.

Da lì siamo passati a molti progressi sull'endpoint in modo da ottenere molti client grassi: Windows, Microsoft Word, tutte quelle cose che ora hai elaborato molto sull'endpoint e poi le hai inviate indietro, in genere, al core per condividere quel contenuto.

Man mano che l'edge e il core sono diventati più forti, hai iniziato a vedere le app cloud. Quindi, invece di apportare quella modifica sul tuo dispositivo, hai apportato la modifica in un browser Web e questa è stata propagata attraverso altri dispositivi per la condivisione. E questo è diventato davvero importante quando abbiamo avuto dispositivi mobili, in particolare i primi dispositivi mobili che avevano meno capacità di calcolo ma molta più larghezza di banda.

Allora perché questo è critico? Riguarda davvero le aspettative degli utenti in termini di velocità. Quindi l'utente desidera sempre una buona esperienza utente. E soprattutto oggi, l'idea di una buona esperienza utente è una sorta di interazione istantanea. Clicco su un collegamento, premo un pulsante, succede qualcosa e non mi interessa davvero dove sia successo. Potrei anche non sapere dove sia successo, ma voglio che sia veloce.

L'altra cosa che è cambiata è l'ambiente in cui ci troviamo. Quindi ci sono molti più attacchi, soprattutto perché quei dispositivi sono diventati più potenti. E poi vediamo un sacco di regolamenti che cambiano mentre la sicurezza e la privacy non solo diventano al primo posto per gli utenti ma anche per i governi. Ed è per questo che Cloudflare continua ad aggiungere POP. Vediamo più utenti, vediamo più traffico, vediamo più attacchi e vediamo più casi d'uso che potremmo mettere al limite e rendere potenti per quegli utenti finali.

PAVAN TIRUPATI: Fantastico. Possiamo scavare un po' nel pop? Cos'è POP? E cosa è cambiato nei POP nel tempo? E in particolare scavando nell'implementazione Cloudflare di POP, cos'è unico?

SERGI ISASI: Quindi grazie per averlo riportato. Dico spesso POP e dovrei specificare cosa significa. È un Internet Point of Presence. E nel caso di Cloudflare e nella maggior parte degli altri casi, quando senti qualcuno parlare di un POP, ciò che significa è una pila di server, seduti da qualche parte, che eseguono software.

Per quanto riguarda ciò che è cambiato nel tempo, in realtà è più facile parlare di ciò che è cambiato rispetto a ciò che non è cambiato. E ne parleremo un po'. Quindi siamo alla nostra undicesima generazione di server. Scriviamo di ciascuna di queste iterazioni sul nostro blog. Quindi continuiamo a ottenere computer più veloci all'edge, il che è fantastico. Significa costi inferiori, significa più capacità, significa solo cose generalmente migliori per gli utenti finali.

Una delle cose interessanti che è cambiata nel tempo è che abbiamo effettivamente implementato tre diverse architetture di CPU, o in realtà due diverse architetture di CPU, tre produttori. Quindi eseguiamo sia Intel che AMD e eseguiamo anche ARM sul nostro vantaggio.

L'altra cosa che è cambiata nel tempo è che continuiamo ad aggiungere località. Non mi è chiaro quanti ne avessimo quando abbiamo lanciato più di 10 anni fa. Era nella gamma delle dozzine. Ma c'è una storia divertente del nostro CTO che era uno dei primi fan di Cloudflare, conosceva i nostri fondatori, ma si è rifiutato di unirsi a Cloudflare fino a quando non ha ottenuto un POP vicino a dove si trovava in Europa. Ha detto, quando arriverà? E poi mi unirò.

Le nostre sedi sono cresciute prima in base alla domanda. Quindi vedi molto traffico in una regione, in realtà è meno costoso, generalmente, mettere l'hardware in una regione e servire il traffico lì. Quindi abbiamo iniziato a farlo all'inizio.

Una volta diventati grandi, abbiamo iniziato a vedere i partner locali o gli ISP iniziare a chiederci di costruire hardware nella regione per rendere le cose più efficienti per loro e per i loro utenti finali. Quindi quello è stato un tipo interessante di cambiamento epocale nel mondo di Cloudflare.

Il nostro obiettivo originale era essere entro 100 millisecondi dagli utenti finali. E poi ci siamo resi conto che potevamo fare di meglio. Quindi ora abbiamo l'obiettivo dei 50 millisecondi. E non sarei sorpreso se lo vedessi diventare ancora più piccolo man mano che gli anni avanzano.

Ciò che non è cambiato è che, molto presto, abbiamo fatto una scelta unica per noi e piuttosto fatidica, ovvero che avremmo eseguito lo stesso software su ogni edge server in ogni posizione. Questa si è rivelata una scelta più semplice per la maggior parte dei nostri team di ingegneri. Sappiamo cosa è in esecuzione su ciascun dispositivo e puoi in qualche modo risolvere i problemi ed eseguire le cose in modo un po' più efficiente lì. Alcuni dei nostri team di ingegneri hanno molto più lavoro anche per questo motivo.

Rende le cose molto più facili da ridimensionare, sia a lungo che a breve termine. A breve termine, ci consente di spostare le risorse su diversi servizi secondo necessità, a seconda del carico e di ciò che sta accadendo in quel luogo in quel momento. Possiamo scalare orizzontalmente su ogni macchina.

A lungo termine, ci consente di decidere in modo proattivo dove devono andare le nuove macchine perché sappiamo che dobbiamo eseguire l'intero stack. L'altro grande vantaggio, per i nostri team di ingegneri e in particolare per i nostri team di ingegneri di prodotto, è che abbiamo prestazioni costanti in tutti i servizi. Non siamo preoccupati che alcune località siano più vicine a determinati tipi di utenti e quindi siano più veloci e abbiano un'esperienza diversa. Sarà coerente tra i server e in tutto il mondo.

E uno dei grandi cambiamenti che abbiamo avuto - questo è probabilmente vecchio di tre anni a questo punto - è che ora consentiamo ai nostri clienti di eseguire il loro codice sul nostro perimetro attraverso il nostro prodotto Workers. E il bel vantaggio che c'è quando quel cliente sceglie di implementare il proprio prodotto, in realtà seleziona la regione del mondo. Non li costringiamo a dire, voglio correre negli Stati Uniti occidentali o cosa hai. Il loro software è distribuito in tutte le sedi e funziona il più vicino possibile al loro bulbo oculare.

PAVAN TIRUPATI: Fantastico. Quindi come si confronta il bordo con il core?

SERGI ISASI: Certo. Quindi dipende dalla tua architettura. E per alcune architetture, il bordo è il nucleo e il nucleo è il bordo. Se hai solo un posto, stai facendo tutto in una volta.

In generale, tuttavia, l'edge sarà più veloce ed efficiente per il calcolo e il core è dove mantieni i segreti e la configurazione e spingi i dati dal core all'edge.

PAVAN TIRUPATI: E Cloudflare ha un nucleo? E se lo fa, come viene implementato?

SERGI ISASI: Dal primo giorno, sì. E non ne parliamo molto. È piuttosto interessante. Ma se ci pensi, siamo stati fondati nel 2009, quindi gestire tutto al limite era incredibilmente poco pratico nel 2009 e, per alcune cose, poco pratico adesso.

Quindi cosa eseguiamo al centro? Gestione della configurazione, quindi dobbiamo eliminare il software. e dobbiamo farlo da qualche parte, quindi spingiamo ancora il software Cloudflare, tutte le nostre nuove versioni, spingiamo il nostro codice, ogni giorno, dal nostro core al nostro edge. E poi eseguiamo anche la configurazione del cliente che comunica ancora con i nostri data center principali. E va da lì fino al limite. Ed è in realtà una storia interessante qui da WP Engine e dal nostro software DNS.

Quindi, all'inizio, Cloudflare utilizzava PowerDNS, un software DNS open source. E abbiamo iniziato a costruire qualcosa che chiamiamo internamente RR DNS, il nostro software DNS, nel 2013. E un software molto efficiente. Avevamo alcune zone che erano nel tipo di centinaia di migliaia di record e tutto si stava muovendo relativamente bene con quei requisiti. E poi è arrivato WP e hanno detto che abbiamo più di un milione di dischi nella nostra zona. E la velocità di aggiornamento, quindi la capacità di apportare una modifica e spingerla oltre il nostro limite, era incredibilmente critica perché significava che un cliente veniva inserito e che aveva bisogno di quell'esperienza. E questo è stato un vero caso limite per noi. Quindi l'abbiamo esaminato e abbiamo detto, OK, ovviamente dobbiamo rielaborare il modo in cui gestiamo il nostro core e inviamo quel traffico verso l'edge per gestire sia la dimensione di quel contenuto che la velocità e la frequenza con cui lo aggiorni.

Quindi, nel 2016, uno dei nostri ingegneri DNS, Tom Arnfeld, ha chiesto se poteva sedersi con WP Engine per capire effettivamente cosa volevi e perché lo volevi, e come sarebbe stato nel 2017, e come sarebbe stato in 2022, ora che sono trascorsi cinque anni. E così quello che abbiamo fatto nel 2017 è stato in realtà riscrivere l'intera struttura dei dati per il nostro software DNS per fare in modo che, su richiesta del nostro CEO, spostasse i dati dall'edge come per magia. Ed era in realtà una di quelle cose in cui avevamo un cliente con un'esigenza, volevamo soddisfare tale esigenza, ma dovevamo ripensare a come spostiamo i dati dal core all'edge.

Un'altra cosa che facciamo ancora al centro è l'analisi. Quindi la telemetria arriva dal bordo al nucleo. I nostri clienti, quando visualizzano le loro analisi, accedono a una dashboard o a un'API, e tutto viene servito dal core.

Nel corso del tempo, le dimensioni dei clienti e la maggiore sofisticazione degli attacchi ci hanno fatto ripensare al modo in cui eseguivamo la telemetria. Prima eseguivamo, ad esempio, tutto il nostro software di rilevamento DDoS al centro. Quindi la telemetria entrerebbe dall'edge, direbbe il core, che sembra un DDoS, e invierebbe i dati all'edge per mitigare. Questo è sufficiente per alcuni attacchi DDoS, ma per altri dobbiamo effettivamente prendere questa decisione al limite. Quindi abbiamo potenziato il nostro sistema Gatebot originale, che esegue il core con un paio di nuovi sistemi, a metà dell'anno scorso, che funzionano effettivamente all'edge e prendono decisioni indipendenti dal core, quindi riferiscono, quindi si adattano continuamente all'attacco superficie.

L'ultima cosa di cui parlerò al centro è che oggi facciamo la maggior parte del nostro apprendimento automatico al centro. Facciamo molto affidamento sull'apprendimento automatico per, in particolare, i prodotti di sicurezza. Ma vogliamo fare di più all'edge perché vediamo, probabilmente, un modello simile con il sistema DDoS. Quindi abbiamo collaborato con NVIDIA per iniziare a eseguire più del nostro ML anche all'edge.

PAVAN TIRUPATI: Sergi, hai menzionato DDoS e sicurezza. Voglio approfondire un po' la questione, in particolare perché la sicurezza è estremamente critica. Quali sono alcune delle tendenze e delle cose che stai vedendo?

SERGI ISASI: Certo, quindi un po' un record rotto da parte nostra, ma gli attacchi DDoS sono da record. Battiamo quel record anno dopo anno. Il motivo è che le botnet stanno effettivamente crescendo di dimensioni e sfruttando dispositivi più potenti. Quindi, se pensi a quanto è più veloce il tuo cellulare ora o il tuo computer rispetto all'anno precedente, ha senso solo che stiano ottenendo sempre più capacità per lanciare entrambi attacchi di grandi dimensioni, un throughput così significativo, abbiamo combattuto un L'attacco "2 terabyte al secondo" di poco tempo fa - è il secondo più grande di cui abbiamo sentito parlare - e poi anche attacchi più intelligenti che possono fare cose senza molto throughput, ma forse con molte richieste e richieste costose.

In realtà ciò di cui stiamo parlando qui è più sofisticazione dagli attacchi. E la statistica che penso sia più interessante, qualcosa che noi

di cui si è appena parlato, è che l'8% del traffico sul nostro bordo è mitigato. Quindi, prima di applicare qualsiasi tipo di regola o qualcosa del genere, l'8% viene eliminato del tutto, il che significa che, per un cliente che sta pensando di fare sicurezza all'edge, può sbarazzarsi rapidamente di molte transazioni e interazioni con la sua applicazione che semplicemente non vogliono o non hanno bisogno perché è una sorta di attacco.

PAVAN TIRUPATI: Sì, e in WP Engine, stiamo cercando di rendere Advanced Network, che è una delle nostre offerte di rete, l'impostazione predefinita per tutti i nostri clienti in modo che possano sfruttare questo ulteriore livello di sicurezza. E stiamo anche assistendo a una crescita mai vista prima con la nostra offerta di sicurezza, GES, che è correlata, più in sintonia con i clienti che cercano livelli e livelli di sicurezza aggiuntivi. E viene fornito con: GES è qualcosa che viene fornito con un firewall per applicazioni Web e Argo Smart Routing.

Ma una cosa che voglio evidenziare qui è che il 65% dei clienti di WP Engine attualmente non si trova in nessuna di queste reti. Argo Smart Routing e WAF sono qualcosa di cui potrebbero sicuramente trarre vantaggio. Quindi ti dispiacerebbe espandere un po 'il modo in cui il routing intelligente e il WAF funzionano in una prospettiva Cloudflare.

SERGI ISASI: Certo. Quindi Argo è un prodotto molto interessante. È davvero unico per Cloudflare ed è qualcosa che è un po' strabiliante se non lo conosci bene. Quindi Argo prende quella telemetria di cui stavo parlando, la telemetria edge, e in realtà cerca percorsi migliori su Internet. C'è un detto, internamente, è come Waze per Internet, che immagino funzioni. Non è la mia analogia preferita, ma è ragionevole.

Perché a volte i percorsi sono inefficienti e non sono coerenti. Quindi oggi potrebbe essere più veloce andare direttamente all'origine e talvolta non lo è. A volte ha più senso per noi passare effettivamente da un bordo di Cloudflare a un altro per aggirare una certa congestione di Internet.

Il grande punto di Argo è che riduce l'efficienza dell'ultimo miglio sia dall'utente all'edge che dall'edge all'origine, perché probabilmente oggi non stai servendo tutti i tuoi contenuti dall'edge, del 40%. E questo è un enorme aumento semplicemente premendo un pulsante e non richiedendo alcun tipo di modifica del codice per l'applicazione.

PAVAN TIRUPATI: In realtà è abbastanza perspicace. Grazie, Sergio. Quali cambiamenti hai visto per la tua base di clienti? Qual è l'impatto pratico dell'aumento degli attacchi e l'effettiva superficie degli attacchi?

SERGI ISASI: Quindi penso che il grande cambiamento nel 2020 e nel 2021 sia che abbiamo iniziato a vedere l'aumento degli attacchi ransomware e un diverso tipo di ransomware, quindi non uno che ha preso il controllo dell'endpoint e lo ha crittografato, ma piuttosto attaccheremo e abbatterti se non ci paghi.

Nel 2020 ne abbiamo visti parecchi. Nel 2021 abbiamo assistito a un aumento ma a un cambiamento di modello. E il cambio di modello è stato, piuttosto che trovare genericamente un obiettivo, stava trovando un obiettivo nello stesso settore. Quindi la cosa interessante è che abbiamo visto molte società di voiceover IP e di teleconferenza essere prese di mira. In un certo senso ha senso, giusto? Quindi, poiché tutti lavoravano di più da remoto, questi servizi erano fondamentali. Ed era importante che sia gli utenti che i provider rimanessero online, in modo che l'aggressore avesse un obiettivo molto ovvio lì.

Una cosa che rimane ancora vera è che l'intelligenza condivisa è importante. Mentre vedevamo ogni singolo cliente essere preso di mira, vedevamo gli stessi schemi entrare e lo stesso schema di attacco andare a quelle applicazioni, il che rende più facile per qualcuno come noi che vede quel traffico, rende più facile per noi bloccare.

PAVAN TIRUPATI: Sì, la prevedibilità o gli schemi sono effettivamente utili per comprendere i dati, quindi lo capisco. Ma come e dove dovrebbero pensare gli sviluppatori di questa chiamata alla protezione in generale? Qual è lo scenario peggiore che hai visto in passato che puoi condividere qui?

SERGI ISASI: Certo. Quindi uno scenario peggiore è un attacco mirato. Quindi, se qualcuno vuole davvero portarti offline, è estremamente difficile gestire quel tipo di aggressore motivato. Quindi è qualcosa da considerare se stai eseguendo un'applicazione che è in qualche modo controversa o che può avere qualche tipo di nemico. E questo è un sacco di cose in questi giorni.

L'attacco che ho qui è un esempio di Adidas che ha ricevuto 17,2 milioni di richieste al secondo. Quindi questo non è il throughput, questa è solo una vera e propria richiesta HTTP legittima. Questi non sono stati amplificati o contraffatti. Quindi questo utente malintenzionato ha avuto accesso a un numero sufficiente di dispositivi che potrebbero effettuare queste connessioni e farle sembrare legittime o, in realtà, erano legittime. Attacco estremamente distribuito. Ha avuto una certa concentrazione in alcune regioni, ma è stato visto nella stragrande maggioranza delle nostre sedi.

E lo scenario peggiore è che la mitigazione fosse costosa. È stato fatto al livello 7. Quindi abbiamo dovuto accettare la connessione. Abbiamo dovuto terminare l'SSL, quindi è necessario un numero di strette di mano avanti e indietro, prima di poter respingere e identificare l'attacco rispetto al traffico legittimo. Quindi questo è il genere di cose che, se stai cercando di eseguirlo su un WAF on-premise o qualcosa del genere, sarà molto, molto costoso anche solo trovare il traffico, tanto meno mitigarlo.

PAVAN TIRUPATI: Fantastico. Grazie, Sergio. Rimanendo con la sicurezza, durante i tempi di guerra, come stiamo assistendo con Russia e Ucraina in questo momento, è previsto un aumento degli attacchi informatici. In effetti, CIA e FBI hanno emesso un avviso congiunto sulla natura distruttiva di questi attacchi e su quanto possano essere vulnerabili risorse e dati critici in questi tempi. Raccomandano che tutte le organizzazioni, indipendentemente dalle dimensioni, adottino una posizione di sicurezza più elevata. E al WP, stiamo assistendo a questa tendenza al rialzo anche negli attacchi.

Qual è la tua opinione sulla preparazione per eventi come questo? E come possiamo prepararci per tali situazioni? Alcuni degli altri grandi eventi oltre alla guerra Russia-Ucraina che mi viene in mente è l'evento Log4shell a cui abbiamo assistito l'anno scorso, che ha avuto un impatto su molte applicazioni in tutto il mondo.

SERGI ISASI: Sì, voglio dire, dobbiamo rispondere. Questo è il mondo in cui ci troviamo. Le cose accadono e accadono cose davvero terribili e dobbiamo reagire. Per quanto riguarda l'Ucraina, non possiamo condividere un sacco di informazioni, ma una delle cose che possiamo condividere è che, mentre il traffico in Ucraina è rimasto relativamente coerente dal punto di vista dell'utente generale, abbiamo visto aumentare considerevolmente le mitigazioni del firewall.

Quindi è passato dal tipico 8% di cui abbiamo parlato prima fino al 30% delle richieste totali. Ciò significa che c'è solo più traffico di attacco mescolato al normale traffico degli utenti. E ancora, proprio come nell'esempio precedente, si tratta di mitigazioni costose, cose che devono essere fatte al livello 7 perché è difficile identificarle dagli attacchi regolari basati solo sul livello 4.

Parliamo di Log4shell, quello è stato probabilmente il più grande evento che io ricordi da molto tempo. Quindi questo ha colpito l'industria piuttosto duramente. Ricordo che molte persone, sia in Cloudflare, che leggevano la discussione interna, e ricordo che dicevano, oh, oh dio, è enorme.

Ed è stata una vulnerabilità e un bit di software molto comune che ha permesso all'attaccante di inserire alcuni caratteri arbitrari, e quindi la presenza di quei caratteri avrebbe fatto sì che il software andasse a inviare una richiesta git per un URL inserito dall'attaccante. Quindi tutti stavano rimescolando. Potresti non conoscere le tue dipendenze. Questa è una specie di lezione uno, è conoscere le tue dipendenze, sapere quale software stai eseguendo e quale software sta eseguendo quel software.

Ma la cosa importante è che ci sono stati molti exploit davvero intelligenti qui. Quindi, quando stavamo mitigando questo per i nostri clienti e per i tuoi clienti, avevamo molte varianti diverse delle nostre regole firewall che continuavano a dover essere implementate perché c'era la presenza di contenuto e diversi modi in cui puoi codificare quel contenuto.

Una delle cose che ho pensato fosse la cosa più interessante di Log4j è che l'abbiamo visto nella pipeline di registrazione. Quindi, anche se pensavi che la tua applicazione fosse sufficientemente protetta da firewall da non ricevere una connessione dal mondo esterno, se estrai un evento di registro che contiene questi caratteri, andrebbe comunque a fare quella richiesta. Quindi un semplice firewall non era sufficiente.

Edge è importante qui e molto utile perché ti consente di avere un modo rapido e semplice per avviare i controlli indipendentemente dal fatto che tu sia sicuro di essere vulnerabile o meno. Non ci sono svantaggi nell'istituire i controlli, che è un altro motivo per cui l'abbiamo distribuito anche ai nostri clienti gratuiti. Quindi il singolo punto di controllo è davvero molto utile in quello scenario.

PAVAN TIRUPATI: E quali sono alcuni degli strumenti o delle tecniche a disposizione dei clienti per ridimensionare il traffico in questo scenario?

SERGI ISASI: Certo, quindi per qualsiasi scenario, abbiamo lavoratori su Cloudflare. Ciò ti consente di eseguire il tuo codice sul nostro vantaggio e puoi creare tutto ciò che desideri senza preoccuparti del ridimensionamento orizzontale.

Abbiamo anche introdotto un prodotto, all'inizio del 2021, chiamato Waiting Room. La sala d'attesa è qualcosa che probabilmente conosci. Sei andato a comprare qualcosa e sei stato messo in coda per decidere se ce n'era abbastanza di quella cosa da comprare. Può anche funzionare per un'applicazione. Puoi connetterti al sito e avere una buona esperienza? O dovresti aspettare?

Questo è in realtà un prodotto davvero interessante che abbiamo costruito. L'abbiamo costruito sull'edge e utilizzando i lavoratori di Cloudflare. E questo è stato difficile. Probabilmente è un prodotto più semplice da costruire al centro. Questo non è il DNA di Cloudflare. Possiamo costruire cose al limite e in realtà stavamo cercando di ridimensionare. Se provi a ridimensionare qualcosa al centro, diventa molto più difficile.

Il grosso problema che abbiamo avuto quando stavamo costruendo la sala d'attesa è la condivisione dello stato. Quindi volevi che gli utenti avessero un'esperienza di sala d'attesa, a livello globale. E stavamo parlando di oltre 200 località. Non è facile.

Quindi ti faccio un esempio. Diciamo che c'è un concerto qui nella Bay Area. La maggior parte degli acquirenti per quel concerto si troverà nella Bay Area e probabilmente si connetteranno al nostro data center di San Jose. Tuttavia, alcuni non lo sono. Avrai una manciata o una certa percentuale di acquirenti che saranno in tutto il mondo che voleranno per il concerto o forse saranno in viaggio in quel momento.

Quindi come lo rendi equo? Non puoi avere una coda per gli utenti nella Bay Area e una coda per gli utenti è in ogni altra posizione. Ciò ci ha richiesto di pensare a come condividere lo stato oltre il limite. E penso che questo sia il punto in cui il futuro sta andando al limite.

E utilizziamo il nostro prodotto Durable Objects (puoi vederlo qui nella diapositiva) per sincronizzare e condividere lo stato in tutte le sedi. Ma poiché noi, come industria, cerchiamo di risolvere più di questi problemi al limite, penso che inizierai a vedere molti più casi d'uso del software al limite in cui la condivisione dello stato è ancora difficile, e cosa fai sulla coerenza, che sia un po' eventuale o immediata? E penso che questo sia il futuro del nostro software.

PAVAN TIRUPATI: Fantastico. Grazie, Sergio. So che in WP Engine abbiamo questa mentalità all'avanguardia per garantire prestazioni e sicurezza ai nostri clienti. Sergi, quali sono i tuoi ultimi pensieri o parole di consiglio o le migliori considerazioni o suggerimenti per gli sviluppatori in chiamata che stanno costruendo all'edge?

SERGI ISASI: Quindi penso, prima di tutto, che tu stia costruendo nel posto giusto. E in secondo luogo, penso che sia essere creativi. Ci sono un sacco di cose che se mi avessi chiesto, un anno fa, se potevamo farle al limite, avrei detto, eh, non lo so. Non credo. E c'è solo un ritmo di innovazione più veloce che stai trovando qui e molti sviluppatori creativi che pensano ai problemi a cui stai pensando e trovano soluzioni sia dal lato del cliente che del prodotto.

Un'altra cosa interessante è comunicare e condividere. Abbiamo visto molto movimento, in particolare negli sviluppatori Discords, per trovare nuovi modi creativi per risolvere i problemi e costruire più cose al limite. Penso, infine, come plug per Cloudflare, se c'è qualcosa che non puoi fare, trova un product manager di Cloudflare. Inviaci un'e-mail, trovaci su Twitter o qualsiasi altra cosa e facci sapere cosa stai cercando di costruire e vedremo se non possiamo aiutarti a costruirlo.

PAVAN TIRUPATI: È fantastico. E penso sia giusto dire che l'edge non è più un caso limite, perché se la sicurezza e le prestazioni sono il tuo obiettivo, allora l'edge è il posto dove stare.

Quindi grazie, Sergi, per quelle belle parole sull'edge. Spero che abbiate trovato utile questa sessione. Grazie per aver dedicato del tempo e per esserti unito a noi. Spero che tu abbia un buon resto della giornata.

PRESENTATORE: E questa è una conclusione per DE{CODE} 2022. Spero che tu l'abbia trovato d'ispirazione e che te ne vada con più esperienza su WordPress e nuove connessioni con la community. Cerca i contenuti registrati sul sito da venerdì per recuperare tutto ciò che potresti aver perso o guardare di nuovo un video.

Voglio ringraziare i nostri partner sponsor: Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios e 10Up. Un enorme grazie per aver donato alla nostra raccolta fondi DECODE. Apprezziamo molto la tua generosità.

Ora per tutti coloro che hanno interagito con noi nel nostro Hub dei partecipanti e nelle nostre sessioni, sceglieremo i primi tre vincitori e ti faremo sapere come richiedere il tuo premio alla fine di DE{COD}E. Non vediamo l'ora di rivederti per i nostri eventi futuri, di persona o virtualmente. Non vediamo l'ora di offrirti di più sulle ultime tendenze di sviluppo di WordPress e su come implementarle per creare siti WordPress più velocemente. Questo è tutto da parte mia. Grazie mille per esserti unito a noi e abbi cura di te.