DE{CODE} : Pourquoi Edge n'est pas un cas Edge

Lorsque vous êtes à la périphérie, la vitesse, la sécurité et la santé du serveur ne peuvent pas être une réflexion après coup. Au cours de cette session, Sergi Isasi, vice-président produit de Cloudflare, et Pavan Tirupati, chef de produit WP Engine, expliquent pourquoi avoir une mentalité avant tout est essentielle au succès de chaque site Web que vous créez ou maintenez.

Diapositives de la session

Transcription du texte intégral

PAVAN TIRUPATI : Salut, tout le monde. Merci de vous joindre à nous dans cette session sur le fait que l'âge n'est pas vraiment un cas limite. Je suis Pavan Tirupati, chef de produit chez WP Engine avec l'équipe The Outreach, et je suis principalement responsable de la sécurité, des performances et de la fiabilité de la périphérie pour développer et responsabiliser les clients WP Engine.

Et Sergi, vice-président de la gestion des produits, nous rejoint aujourd'hui en provenance de Cloudflare. Sergi, voulez-vous vous présenter ?

SERGI ISASI : Bien sûr. Merci de m'avoir reçu, Pavan. Et merci à tous d'avoir participé à notre session. Donc, comme l'a dit Pavan, je suis vice-président des produits pour les performances des applications chez Cloudflare, axé sur les performances et la fiabilité de notre périphérie. Nous voulons rendre les choses rapides et fiables pour tous nos clients. Les produits que je couvre sont la façon dont Cloudflare reçoit et traite le trafic à la périphérie, donc à la fois aux couches 4 et 7. Cela inclut donc notre cache, notre proxy, le spectre FL, la technologie fondamentale de Cloudflare comme nos systèmes DNS, nos systèmes de gestion de certificats et notre Les systèmes de gestion des adresses IP, et puis aussi les nouvelles applications edge, donc l'équilibrage de charge, notre tout nouveau produit Waiting Room, et nos prochains produits Web3.

Je suis chez Cloudflare depuis environ 4 ans et demi. Et encore une fois, heureux d'être ici aujourd'hui.

PAVAN TIRUPATI : Génial. Et aujourd'hui, nous avons une merveilleuse session pour vous les gars alors que nous approfondissons ce qu'est exactement la périphérie et comment est-elle utile, et comme le titre l'indique, pourquoi la périphérie n'est plus un cas marginal. L'ordre du jour que nous avons pour vous les gars est d'approfondir ce qu'est l'avantage et quels en sont les avantages. Et compte tenu de ces temps, il est essentiel de se concentrer davantage sur la sécurité.

Et nous allons parler de quelques exemples et parler de certaines menaces à la sécurité. Nous verrons également comment Edge sera bénéfique pour le public ici présent et pour tous ceux qui ont une présence numérique dans le monde. Et nous examinerons également des exemples spécifiques qui pourraient être bénéfiques pour les personnes susceptibles de rencontrer certaines de ces menaces et problèmes de sécurité.

Ce sera donc passionnant, ingénieux et perspicace. Alors commençons par mettre un peu de contexte ici. Je veux établir une base de référence de ce qui est bord. Et je pense que ce n'est une surprise pour personne lorsque je dis que les entreprises connaissent une évolution vers une culture de constructeur, une culture qui repose sur la capacité des développeurs à créer et à contrôler directement des expériences numériques.

À mesure que les sites et les applications passent de versions monolithiques à une architecture de microservices, la capacité à diffuser du contenu à partir de diverses sources devient de plus en plus importante. Et nous savons et comprenons que la périphérie fait partie de l'Internet qui est en fait la plus proche de nos utilisateurs finaux, parfois aussi appelée le dernier kilomètre. Mais avant d'entrer dans les détails, Sergi, je veux mettre à niveau le public quant à ce qui est à la limite et pourquoi est-ce même critique.

SERGI ISASI : Bien sûr. Il y a donc un dicton de longue date dans le cloud computing, qui dit "le cloud n'est que l'ordinateur de quelqu'un d'autre". J'aime beaucoup ce dicton. Cela signifie que c'est la même chose que vous auriez sur votre ordinateur de bureau ou portable, mais c'est juste quelqu'un d'autre qui le gère. Et le bord est exactement la même chose, c'est juste plus proche de l'utilisateur.

Pourquoi est-ce important ? Chez Cloudflare, nous voulons que les choses soient aussi proches que possible de l'utilisateur. Et cela revient vraiment à cette déclaration que vous avez dite, qui est le dernier kilomètre. Donc, peu importe à quelle vitesse vous créez votre logiciel, à quel point vous pouvez le rendre efficace, si vous répondez même à quelque chose - si votre logiciel peut fonctionner en moins d'une milliseconde, vous êtes toujours redevable à la vitesse de la lumière. Et si votre logiciel n'est pas sur l'appareil de l'utilisateur ou aussi proche que possible de l'utilisateur, l'utilisateur va subir ce petit peu de latence. Et parfois, cette latence est OK et parfois c'est très, très choquant pour l'utilisateur final. Il s'agit donc d'optimiser ce qui a du sens pour être proche de l'utilisateur final à la périphérie ou ce qui est proche du cœur.

Et ce que Cloudflare fait, c'est que nous essayons de tout mettre à la périphérie. Je pense que l'une des raisons pour lesquelles vous m'avez demandé de faire ce chat est que nous gérons sans doute l'un des plus grands réseaux périphériques au monde et nous en sommes évidemment incroyablement fiers. Cloudflare a un peu plus de 10 ans et nous avons construit ce réseau pendant tout ce temps. Il s'est étendu à 250 villes, 100 pays différents, avec l'objectif – et en fait nous avons atteint cet objectif – d'être à moins de 50 millisecondes de 95 % des internautes à travers le monde. Et cela, encore une fois, le dernier kilomètre - si nous pouvons être dans les 50 millisecondes, nous pouvons être beaucoup plus rapides pour chacun de ces utilisateurs finaux.

L'autre partie consiste à se connecter à d'autres réseaux. Nous nous connectons donc à 10 000 autres réseaux à travers le monde, de nombreux FAI locaux, par exemple, puis nous exploitons également notre propre dorsale, alors faites le backhauling de ce trafic lorsque nous avons besoin d'aller au cœur ou à l'origine, faites que même plus vite. Nous avons terminé 2021 avec un peu plus de 100 térabits par seconde de capacité. Et c'est important lorsqu'il s'agit d'une mise à l'échelle horizontale pour les augmentations de trafic pour nos clients et également pour l'augmentation des attaques contre nos clients et également sur notre propre réseau.

L'une des choses qui ont été intéressantes à propos du calcul au cours des 30 ou 40 dernières années est sa transition, d'avant en arrière, de la périphérie au cœur du client, selon l'endroit où cela avait du sens et où se trouvait toute la puissance de calcul à ce moment-là. Donc, si vous repensez à l'Internet pré-public, vous aviez des mainframes. Vous aviez beaucoup de puissance de calcul au cœur et très peu de puissance de calcul à la périphérie et de très petites quantités de bande passante pour faire la transition dans les deux sens. Donc, vous envoyiez des commandes à l'ordinateur central et il vous renvoyait les résultats de ces commandes sous forme de texte.

Nous sommes passés de là à de nombreuses avancées sur le point de terminaison, vous avez donc eu beaucoup de gros clients - Windows, Microsoft Word, toutes ces choses que vous avez maintenant faites beaucoup de calcul au point de terminaison et que vous avez ensuite renvoyées, généralement, le core pour partager ce contenu.

Au fur et à mesure que la périphérie et le noyau se renforçaient, vous avez commencé à voir des applications cloud. Ainsi, plutôt que d'apporter cette modification sur votre appareil, vous avez effectué la modification dans un navigateur Web et celle-ci a été propagée via d'autres appareils pour le partage. Et cela est devenu très important lorsque nous avions des appareils mobiles, en particulier les premiers appareils mobiles qui avaient moins de calcul mais beaucoup plus de bande passante.

Alors pourquoi est-ce critique? Il s'agit vraiment des attentes des utilisateurs en matière de vitesse. Ainsi, l'utilisateur veut toujours une bonne expérience utilisateur. Et surtout aujourd'hui, l'idée d'une bonne expérience utilisateur est une sorte d'interaction instantanée. Je clique sur un lien, j'appuie sur un bouton, quelque chose se passe, et peu m'importe où cela s'est produit. Je ne sais peut-être même pas où c'est arrivé, mais je veux que ce soit rapide.

L'autre chose qui a changé est l'environnement dans lequel nous nous trouvons. Il y a donc beaucoup plus d'attaques, en grande partie parce que ces appareils sont devenus plus puissants. Et puis, nous voyons beaucoup de réglementations changer alors que la sécurité et la confidentialité deviennent non seulement une priorité pour les utilisateurs, mais aussi pour les gouvernements. Et c'est pourquoi Cloudflare continue d'ajouter des POP. Nous voyons plus d'utilisateurs, nous voyons plus de trafic, nous voyons plus d'attaques et nous voyons plus de cas d'utilisation que nous pourrions mettre à la périphérie et rendre puissants pour ces utilisateurs finaux.

PAVAN TIRUPATI : Génial. Pouvons-nous creuser un peu dans la pop? Qu'est-ce que POP ? Et qu'est-ce qui a changé dans les POP au fil du temps ? Et en creusant spécifiquement dans l'implémentation Cloudflare de POP, qu'est-ce qui est unique ?

SERGI ISASI : Alors merci d'avoir ramené ça. Je dis beaucoup de POP, et je devrais préciser ce que cela veut dire. C'est un Point de Présence Internet. Et dans le cas de Cloudflare et dans la plupart des autres cas, lorsque vous entendez quelqu'un parler d'un POP, cela signifie une pile de serveurs, assis quelque part, qui exécute un logiciel.

En ce qui concerne ce qui a changé au fil du temps, il est en fait plus facile de parler de ce qui a changé que de ce qui n'a pas changé. Et nous y reviendrons un peu. Nous sommes donc sur notre 11e génération de serveurs. Nous écrivons sur chacune de ces itérations sur notre blog. Nous continuons donc à avoir des ordinateurs plus rapides à la périphérie, ce qui est formidable. Cela signifie des coûts inférieurs, cela signifie plus de capacités, cela signifie simplement de meilleures choses pour les utilisateurs finaux.

L'une des choses intéressantes qui a changé au fil du temps est que nous avons en fait mis en œuvre sur trois architectures de processeur différentes - ou en fait deux architectures de processeur différentes, trois fabricants. Nous exécutons donc à la fois Intel et AMD, et nous exécutons également ARM à notre périphérie.

L'autre chose qui a changé au fil du temps, c'est que nous continuons à ajouter des emplacements. Je ne sais pas combien nous en avions lorsque nous avons lancé il y a plus de 10 ans. C'était dans la gamme des dizaines. Mais il y a une histoire amusante de notre CTO qui était un des premiers fans de Cloudflare, connaissait nos fondateurs, mais il a refusé de rejoindre Cloudflare jusqu'à ce qu'il obtienne un POP près de là où il se trouvait en Europe. Il a dit, quand est-ce que ça arrive? Et puis je me joindrai.

Nos emplacements se sont d'abord développés en fonction de la demande. Donc, vous voyez beaucoup de trafic dans une région, il est en fait moins cher, en général, de mettre du matériel dans une région et d'y desservir le trafic. Nous avons donc commencé à le faire au début.

Une fois que nous sommes devenus grands, nous avons commencé à voir des partenaires locaux ou des FAI commencer à nous demander de construire du matériel dans la région pour rendre les choses plus efficaces pour eux et leurs utilisateurs finaux. C'était donc un genre de changement radical intéressant dans le monde de Cloudflare.

Notre objectif initial était d'être à moins de 100 millisecondes des utilisateurs finaux. Et puis on s'est rendu compte qu'on pouvait faire mieux. Alors maintenant, nous avons l'objectif de 50 millisecondes. Et je ne serais pas surpris si vous voyez cela diminuer encore plus au fil des années.

Ce qui n'a pas changé, c'est que nous avons, très tôt, fait un choix unique et assez fatidique, à savoir que nous exécuterions le même logiciel sur chaque serveur périphérique à chaque emplacement. Cela a fini par être un choix plus facile pour la plupart de nos équipes d'ingénierie. Nous savons ce qui s'exécute sur chaque appareil et vous pouvez en quelque sorte dépanner et exécuter les choses un peu plus efficacement là-bas. Certaines de nos équipes d'ingénieurs ont également beaucoup plus de travail à cause de cela.

Cela rend les choses beaucoup plus faciles à mettre à l'échelle, à long terme et à court terme. À court terme, cela nous permet de déplacer des ressources vers différents services selon les besoins en fonction de la charge et de ce qui se passe à cet endroit à ce moment précis. Nous pouvons évoluer horizontalement sur chaque machine.

À long terme, cela nous permet de décider de manière proactive où les nouvelles machines doivent aller, car nous savons que nous devons exécuter l'ensemble de la pile. L'autre grand avantage, pour nos équipes d'ingénierie et plus particulièrement pour nos équipes d'ingénierie produit, est que nous avons des performances constantes sur tous les services. Nous ne craignons pas qu'un emplacement soit plus proche de certains types d'utilisateurs et donc qu'il soit plus rapide et ait une expérience différente. Cela va être cohérent sur tous les serveurs et à travers le monde.

Et l'un des grands changements que nous avons eu - cela fait probablement trois ans à ce stade - est que nous permettons désormais à nos clients d'exécuter leur code à notre périphérie via notre produit Workers. Et le bel avantage est que lorsque ce client choisit de déployer son produit, il sélectionne en fait la région du monde. Nous ne les forçons pas à dire, je veux courir dans l'Ouest des États-Unis ou quoi que ce soit d'autre. Leur logiciel est déployé sur tous les sites et fonctionne aussi près que possible de leur globe oculaire.

PAVAN TIRUPATI : Génial. Alors, comment le bord se compare-t-il au noyau?

SERGI ISASI : Bien sûr. Cela dépend donc de votre architecture. Et pour certaines architectures, la périphérie est le cœur et le cœur est la périphérie. Si vous n'avez qu'un seul endroit, vous faites en quelque sorte tout à la fois.

En règle générale, cependant, la périphérie sera plus rapide et plus efficace pour le calcul et le cœur est l'endroit où vous conservez les secrets et la configuration et vous transférez les données du cœur vers la périphérie.

PAVAN TIRUPATI : Et Cloudflare a-t-il un noyau ? Et si c'est le cas, comment est-il mis en œuvre ?

SERGI ISASI : Dès le premier jour, oui. Et on n'en parle pas beaucoup. C'est plutôt intéressant. Mais si vous y réfléchissez, nous avons été fondés en 2009, et donc tout gérer à la périphérie était incroyablement peu pratique en 2009 et, pour certaines choses, peu pratique maintenant.

Alors, que courons-nous au cœur? Gestion de la configuration - nous devons donc sortir le logiciel. et nous devons le faire depuis quelque part, donc nous poussons toujours le logiciel Cloudflare, toutes nos nouvelles versions, nous poussons notre code, chaque jour, de notre cœur à notre périphérie. Et puis nous exécutons également une configuration client qui communique toujours avec nos centres de données principaux. Et ça va de là jusqu'au bord. Et c'est en fait une histoire intéressante ici de WP Engine et de notre logiciel DNS.

Ainsi, au début, Cloudflare utilisait PowerDNS, un logiciel DNS open source. Et nous avons commencé à construire quelque chose que nous appelons en interne RR DNS, notre propre logiciel DNS, en 2013. Et un logiciel très efficace. Nous avions des zones qui comportaient des centaines de milliers d'enregistrements et tout se déroulait relativement bien avec ces exigences. Et puis WP est arrivé et ils ont dit que nous avions peut-être plus d'un million d'enregistrements dans notre zone. Et la vitesse de mise à jour, donc la capacité d'apporter un changement et de le pousser à notre périphérie, était extrêmement critique car cela signifiait qu'un client était intégré et qu'il avait besoin de cette expérience. Et c'était un véritable cas limite pour nous. Nous avons donc examiné cela et dit, OK, nous devons évidemment retravailler la façon dont nous gérons notre cœur et envoyer ce trafic vers la périphérie pour gérer à la fois la taille de ce contenu et la vitesse et la fréquence à laquelle vous le mettez à jour.

Ainsi, en 2016, l'un de nos ingénieurs DNS, Tom Arnfeld, a demandé s'il pouvait s'asseoir avec WP Engine pour comprendre réellement ce que vous vouliez et pourquoi vous le vouliez, et à quoi cela ressemblerait en 2017, et à quoi cela ressemblerait dans 2022, maintenant que nous sommes dans cinq ans. Et donc ce que nous avons fait en 2017 a été en fait de réécrire l'intégralité des structures de données de notre logiciel DNS pour faire en sorte, à la demande de notre PDG, de déplacer les données depuis la périphérie comme par magie. Et c'était en fait l'une de ces choses où nous avions un client avec un besoin, nous voulions répondre à ce besoin, mais nous avons dû repenser la façon dont nous déplaçons les données du cœur vers la périphérie.

Une autre chose que nous faisons encore au cœur est l'analyse. Ainsi, la télémétrie vient du bord vers le noyau. Nos clients, lorsqu'ils consultent leurs analyses, accèdent à un tableau de bord ou à une API, et tout est servi depuis le cœur.

Au fil du temps, la taille des clients et la sophistication accrue des attaques nous ont fait repenser notre façon de faire de la télémétrie. Nous avions l'habitude d'exécuter auparavant, par exemple, tous nos logiciels de détection DDoS au cœur. Ainsi, la télémétrie viendrait de la périphérie, dirait le noyau, cela ressemble à un DDoS, et elle renverrait les données à la périphérie pour atténuer. C'est suffisant pour certaines attaques DDoS, mais pour d'autres, nous devons réellement prendre cette décision à la périphérie. Nous avons donc augmenté notre système Gatebot d'origine, qui exécute le cœur avec quelques nouveaux systèmes, au milieu de l'année dernière, qui fonctionnent en fait à la périphérie, et prennent des décisions indépendantes du cœur, puis font rapport, donc en quelque sorte continuellement s'adapter à l'attaque surface.

La dernière chose dont je parlerai au cœur est que nous faisons la plupart de notre apprentissage automatique au cœur aujourd'hui. Nous nous appuyons fortement sur l'apprentissage automatique pour, en particulier, les produits de sécurité. Mais nous voulons en faire plus à la périphérie car nous constatons probablement un schéma similaire avec le système DDoS. Nous nous sommes donc associés à NVIDIA pour commencer à exécuter davantage notre ML à la périphérie également.

PAVAN TIRUPATI : Sergi, vous avez mentionné les DDoS et la sécurité. Je veux creuser un peu cela, en particulier parce que la sécurité est très critique. Quelles sont certaines des tendances et des choses que vous voyez ?

SERGI ISASI : Bien sûr, c'est un peu un record battu de notre part, mais les attaques DDoS battent des records. Nous battons ce record année après année. La raison en est que les botnets augmentent en taille et exploitent des appareils plus puissants. Donc, si vous pensez à la vitesse actuelle de votre téléphone portable ou de votre ordinateur par rapport à l'année précédente, il est logique qu'ils obtiennent de plus en plus de capacité pour lancer à la fois de grandes attaques, un débit si important, nous avons combattu un Attaque « 2 téraoctets par seconde » il y a peu de temps – C'est la deuxième plus grande dont nous ayons entendu parler – et puis aussi des attaques plus intelligentes qui peuvent faire des choses sans beaucoup de débit, mais peut-être beaucoup de requêtes et de requêtes coûteuses.

Vraiment, ce dont nous parlons ici, c'est d'une plus grande sophistication des attaques. Et la statistique que je trouve la plus intéressante, quelque chose que nous

dont nous venons de parler, c'est que 8 % du trafic sur notre périphérie est atténué. Donc, avant que nous ne mettions en place des règles ou quoi que ce soit du genre, 8 % sont simplement supprimés, ce qui signifie que, pour un client qui envisage de faire de la sécurité à la périphérie, il peut rapidement se débarrasser de beaucoup de transactions et d'interactions avec son application. dont ils ne veulent tout simplement pas ou dont ils n'ont pas besoin parce que c'est une sorte d'attaque.

PAVAN TIRUPATI : Oui, et chez WP Engine, nous essayons de faire de Advanced Network, qui est l'une de nos offres de réseau, une valeur par défaut pour tous nos clients afin qu'ils puissent tirer parti de cette couche de sécurité supplémentaire. Et nous assistons également à une croissance sans précédent avec notre offre de sécurité, GES, qui est plus adaptée aux clients qui recherchent des niveaux et des couches de sécurité supplémentaires. Et cela vient avec - GES est quelque chose qui vient avec un pare-feu d'application Web et Argo Smart Routing.

Mais une chose que je veux souligner ici est que 65% des clients WP Engine ne sont actuellement dans aucun de ces réseaux. Argo Smart Routing et WAF sont quelque chose dont ils pourraient certainement bénéficier. Cela vous dérangerait-il de développer un peu la façon dont ce routage intelligent et le WAF fonctionnent dans une perspective Cloudflare.

SERGI ISASI : Bien sûr. Argo est donc un produit très intéressant. C'est très unique à Cloudflare et c'est quelque chose qui est un peu hallucinant si vous n'êtes pas familier avec. Donc, Argo prend cette télémétrie dont je parlais, la télémétrie périphérique, et recherche en fait de meilleurs itinéraires sur Internet. Il y a un dicton, en interne, c'est comme le Waze pour Internet, ce qui, je suppose, fonctionne en quelque sorte. Ce n'est pas mon analogie préférée, mais elle est raisonnable.

Parce que parfois les itinéraires sont inefficaces et ce n'est pas cohérent. Donc aujourd'hui, il peut être plus rapide d'aller directement à l'origine et parfois ce n'est pas le cas. Parfois, il est plus logique pour nous de passer d'un bord Cloudflare à un autre pour contourner en quelque sorte la congestion Internet.

Le gros point d'Argo est qu'il réduit l'efficacité du dernier kilomètre à la fois de l'utilisateur à la périphérie et de la périphérie à l'origine - car vous ne diffusez probablement pas tout votre contenu à partir de la périphérie aujourd'hui - de 40 %. Et c'est une augmentation massive en appuyant essentiellement sur un bouton et en ne nécessitant aucune sorte de changement de code pour l'application.

PAVAN TIRUPATI: C'est en fait assez perspicace. Merci Sergi. Quels changements avez-vous constatés pour votre clientèle ? Quel est l'impact pratique de l'augmentation des attaques et la surface réelle des attaques ?

SERGI ISASI : Je pense donc que le grand changement en 2020 et en 2021 est que nous avons commencé à voir la montée des attaques de ransomwares et un autre type de ransomware, donc pas celui qui a pris le contrôle du terminal et l'a chiffré, mais plutôt nous allons attaquer vous et vous faire descendre si vous ne nous payez pas.

En 2020, nous en avons vu pas mal. En 2021, nous avons constaté une augmentation mais un changement de modèle. Et le changement de modèle était, plutôt que de trouver une cible de manière générique, il s'agissait de trouver une cible dans la même industrie. Donc, ce qui est intéressant, c'est que nous avons vu beaucoup d'entreprises de voix sur IP et de téléconférence être ciblées. Genre de sens, non? Donc, comme tout le monde travaillait davantage à distance, ces services étaient essentiels. Et il était important pour les utilisateurs et les fournisseurs de rester en ligne, de sorte que l'attaquant avait une cible très évidente là-bas.

Une chose qui reste vraie est que l'intelligence partagée est importante. Alors que nous voyions chaque client ciblé, nous voyions les mêmes modèles entrer et le même modèle d'attaque aller vers ces applications, ce qui facilite la tâche de quelqu'un comme nous qui voit ce trafic - nous facilite le blocage.

PAVAN TIRUPATI : Oui, la prévisibilité ou les modèles sont en fait bons pour comprendre les données, donc je comprends. Mais comment et où les développeurs de cet appel devraient-ils penser à la protection en général ? Quel est le pire scénario que vous avez vu dans le passé et que vous pouvez partager ici ?

SERGI ISASI : Bien sûr. Ainsi, le pire scénario est une attaque ciblée. Donc, si quelqu'un veut vraiment vous déconnecter, il est extrêmement difficile de gérer ce type d'attaquant motivé. C'est donc quelque chose à considérer si vous exécutez une application qui est d'une certaine manière controversée ou qui peut avoir une sorte d'ennemi. Et c'est beaucoup de choses de nos jours.

L'attaque que j'ai ici est un exemple où Adidas avait 17,2 millions de requêtes par seconde. Il ne s'agit donc pas de débit, il s'agit simplement de requêtes HTTP légitimes. Ceux-ci n'ont pas été amplifiés ou usurpés. Cet attaquant avait donc accès à suffisamment d'appareils capables d'établir ces connexions et de les faire paraître légitimes - ou en fait, elles étaient légitimes. Attaque extrêmement distribuée. Il y avait une certaine concentration dans certaines régions, mais on l'a vu dans la grande majorité de nos emplacements.

Et le pire scénario est que l'atténuation était coûteuse. Cela a été fait à la couche 7. Nous avons donc dû accepter la connexion. Nous avons dû mettre fin à SSL, ce qui représente un certain nombre de poignées de main dans les deux sens, avant de pouvoir repousser et identifier l'attaque par rapport au trafic légitime. C'est donc le genre de chose qui, si vous essayez de l'exécuter sur un WAF sur site ou quelque chose comme ça, ça va juste être très, très cher juste pour trouver le trafic, et encore moins l'atténuer.

PAVAN TIRUPATI : Génial. Merci Sergi. S'en tenir à la sécurité, en temps de guerre, comme nous le constatons actuellement avec la Russie et l'Ukraine, on s'attend à une recrudescence des cyberattaques. En fait, la CIA et le FBI ont publié un avis conjoint sur la nature destructrice de ces attaques et sur la vulnérabilité des actifs et des données critiques pendant ces périodes. Ils recommandent à toutes les organisations, quelle que soit leur taille, d'adopter une posture de sécurité renforcée. Et chez WP, nous constatons également cette tendance à la hausse des attaques.

Que pensez-vous de la préparation à des événements comme celui-ci ? Et comment se préparer à de telles situations ? Certains des autres grands événements autres que la guerre russo-ukrainienne qui me viennent à l'esprit sont l'événement Log4shell auquel nous avons assisté l'année dernière, qui a eu un impact sur un grand nombre d'applications dans le monde.

SERGI ISASI : Oui, je veux dire, nous devons répondre. C'est le monde dans lequel nous vivons. Des choses se produisent, et des choses vraiment, vraiment terribles se produisent, et nous devons y réagir. En ce qui concerne l'Ukraine, nous ne pouvons pas partager une tonne d'informations, mais l'une des choses que nous pouvons partager est que, bien que le trafic en Ukraine soit resté relativement constant du point de vue global des utilisateurs, nous avons vu les atténuations du pare-feu augmenter considérablement.

Il est donc passé des 8 % habituels dont nous avons parlé plus tôt à 30 % du nombre total de demandes. Et donc cela signifie qu'il y a juste plus de trafic d'attaque mélangé au trafic utilisateur normal. Et encore une fois, tout comme dans l'exemple précédent, ce sont des mesures d'atténuation coûteuses, des choses qui doivent être faites à la couche 7 car il est difficile de les identifier à partir d'attaques régulières basées uniquement sur la couche 4.

Nous parlons de Log4shell, c'était probablement le plus grand événement dont je me souvienne depuis longtemps. Cela a donc durement touché l'industrie. Je me souviens de beaucoup de personnes, toutes deux chez Cloudflare, lisant la discussion interne, et je me souviens juste d'avoir dit, oh, oh mon Dieu, c'est énorme.

Et c'était une vulnérabilité et un logiciel très courant qui permettait à l'attaquant d'insérer des caractères arbitraires, puis la présence de ces caractères obligeait le logiciel à envoyer une requête git pour une URL insérée par l'attaquant. Alors tout le monde se bousculait. Vous ne connaissez peut-être pas vos dépendances. C'est en quelque sorte la première leçon, c'est connaître vos dépendances, savoir quel logiciel vous utilisez et quel logiciel ce logiciel exécute.

Mais le plus important, c'est qu'il y avait beaucoup d'exploits vraiment intelligents ici. Ainsi, lorsque nous atténuions cela pour nos clients - et pour vos clients - nous avions de nombreuses variantes différentes de nos règles de pare-feu qui continuaient à être déployées en raison de la présence de contenu et de différentes façons de coder ce contenu.

L'une des choses que je pensais être la chose la plus intéressante de Log4j est que nous l'avons vu dans le pipeline de journalisation. Ainsi, même si vous pensiez que votre application était suffisamment protégée par un pare-feu pour ne pas recevoir de connexion du monde extérieur, si vous extrayiez un événement de journal contenant ces caractères, il continuerait à faire cette demande. Un simple pare-feu ne suffisait donc pas.

Edge est important ici et très utile car il vous permet d'avoir un moyen rapide et facile d'initier des contrôles, que vous soyez sûr d'être vulnérable ou non. Il n'y a aucun inconvénient à mettre les contrôles en place, ce qui est une autre raison pour laquelle nous les avons déployés même pour nos clients gratuits. Ainsi, le point de contrôle unique est en fait très utile dans ce scénario.

PAVAN TIRUPATI : Et quels sont certains des outils ou techniques dont disposent les clients pour faire évoluer le trafic dans ce scénario ?

SERGI ISASI : Bien sûr, donc pour n'importe quel scénario, nous avons des travailleurs sur Cloudflare. Cela vous permet d'exécuter votre code à la périphérie et vous pouvez créer ce que vous voulez sans vous soucier de la mise à l'échelle horizontale.

Nous avons également introduit un produit, début 2021, appelé Waiting Room. La salle d'attente est quelque chose que vous connaissez probablement. Vous êtes allé acheter quelque chose et vous avez été mis dans une file d'attente pour décider s'il y avait assez de cette chose à acheter. Cela peut aussi fonctionner pour une application. Pouvez-vous vous connecter au site et avoir une bonne expérience ? Ou faut-il attendre ?

C'est en fait un produit vraiment intéressant que nous avons construit. Nous l'avons construit en périphérie et en utilisant les travailleurs Cloudflare. Et c'était difficile. C'est probablement un produit plus simple à construire au cœur. Ce n'est pas l'ADN de Cloudflare. Nous pouvons construire des choses à la pointe, et nous cherchions vraiment à évoluer. Si vous essayez de mettre à l'échelle quelque chose au cœur, cela devient beaucoup plus difficile.

Le gros problème que nous avons eu lors de la construction de la salle d'attente est le partage de l'état. Vous vouliez donc que les utilisateurs aient une seule expérience de salle d'attente, à l'échelle mondiale. Et nous parlions de plus de 200 emplacements. Ce n'est pas facile.

Je vais donc vous donner un exemple. Disons qu'il y a un concert ici dans la Bay Area. La plupart des acheteurs de ce concert se trouveront dans la Bay Area et se connecteront probablement à notre centre de données de San Jose. Cependant, certains ne le sont pas. Vous allez avoir une poignée ou un certain pourcentage d'acheteurs qui seront dans le monde entier qui prendront l'avion pour le concert ou qui voyageront peut-être à ce moment-là.

Alors, comment le rendre juste ? Vous ne pouvez pas avoir de file d'attente pour les utilisateurs dans la Bay Area et une file d'attente pour les utilisateurs se trouve à tous les autres endroits. Cela nous a obligés à réfléchir à la façon dont nous pouvons partager l'état à travers le bord. Et je pense que c'est là que l'avenir va en quelque sorte vers l'avantage.

Et nous utilisons notre propre produit Durable Objects - vous pouvez en quelque sorte le voir ici sur la diapositive - pour synchroniser et partager l'état sur tous les sites. Mais comme nous, en tant qu'industrie, cherchons à résoudre davantage de ces problèmes à la périphérie, je pense que vous allez commencer à voir beaucoup plus de cas d'utilisation de logiciels à la périphérie où le partage d'état est encore difficile, et que faites-vous sur la cohérence, qu'elle soit éventuelle ou immédiate ? Et je pense que c'est l'avenir de notre logiciel.

PAVAN TIRUPATI : Génial. Merci Sergi. Je sais que chez WP Engine, nous avons cette mentalité avant tout pour nous assurer que nous offrons performances et sécurité à nos clients. Sergi, quelles sont vos dernières réflexions ou conseils ou principales considérations ou suggestions pour les développeurs de l'appel qui construisent à la périphérie ?

SERGI ISASI : Je pense donc, tout d'abord, que vous construisez au bon endroit. Et deuxièmement, je pense que c'est d'être créatif. Il y a plein de choses que si tu m'avais demandé, il y a un an, si on pouvait les faire au bord, j'aurais dit, hein, je ne sais pas. Je ne pense pas. Et il y a juste un rythme d'innovation plus rapide que vous trouvez ici et beaucoup de développeurs créatifs qui réfléchissent aux problèmes auxquels vous pensez et proposent des solutions à la fois du côté client et du côté produit.

Une autre chose intéressante est de communiquer et de partager. Nous avons vu beaucoup de mouvement, en particulier chez les développeurs Discords, pour trouver de nouvelles façons créatives de résoudre les problèmes et de créer plus de choses à la périphérie. Je pense, enfin, en tant que plug-in pour Cloudflare, s'il y a quelque chose que vous ne pouvez pas faire, trouvez un chef de produit Cloudflare. Envoyez-nous un e-mail, trouvez-nous sur Twitter, ou autre, et faites-nous savoir ce que vous cherchez à construire et nous verrons si nous ne pouvons pas vous aider à le construire.

PAVAN TIRUPATI : C'est génial. Et je pense qu'il est juste de dire que la périphérie n'est plus un cas marginal, car si la sécurité et les performances sont votre objectif, alors la périphérie est l'endroit où il faut être.

Alors merci, Sergi, pour ces bons mots sur l'avantage. J'espère que vous avez trouvé cette session utile. Merci d'avoir pris le temps de nous rejoindre. J'espère que tu as une bonne fin de journée.

PRÉSENTATEUR : Et c'est la fin de DE{CODE} 2022. J'espère que vous l'avez trouvé inspirant et que vous repartez avec plus d'expertise WordPress et de nouvelles connexions communautaires. Recherchez le contenu enregistré sur le site à partir de vendredi pour rattraper tout ce que vous avez pu manquer ou revoir une vidéo.

Je tiens à dire un dernier merci à nos partenaires sponsors - Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios et 10Up. Un énorme merci pour votre don à notre collecte de fonds DECODE. Nous apprécions vraiment votre générosité.

Maintenant, pour tous ceux qui ont interagi avec nous dans notre hub des participants et nos sessions, nous sélectionnerons les trois premiers gagnants et vous ferons savoir comment vous pouvez réclamer votre prix à la fin de DE{COD}E. Nous avons hâte de vous revoir lors de nos futurs événements, en personne ou virtuellement. Nous sommes impatients de vous en dire plus sur les dernières tendances de développement WordPress et sur la manière dont vous pouvez les mettre en œuvre pour créer des sites WordPress plus rapidement. C'est tout de moi. Merci beaucoup de vous joindre à nous et prenez soin de vous.