Introduction à Beyond the Edge Episode 6 – ce que vous devez savoir sur les architectures composables et leurs avantages en termes de performances et de sécurité
Tom Mount : Bonjour et bienvenue à Beyond the Edge, où nous fouillons dans l’assurance et les ruptures des tendances affectant les entreprises numériques modernes.
Je suis Tom Mount. Je suis architecte de solutions senior chez Edgio. Je me concentre sur notre plate-forme d’applications et nos solutions de sécurité qui en font partie. Je suis développeur web depuis près de 20 ans, travaillant principalement pour ou avec des agences de marketing numérique. Fait beaucoup de travail avec Higher Ed et e-commerce, y compris eBay, American Airlines et l’Université de Pennsylvanie.
Et aujourd’hui, Howie Ross me rejoint.
Howie Ross : Bonjour, je suis Howie Ross. Je suis directeur principal de la gestion des produits pour la plateforme Edgio applications, où je me concentre sur l’accélération Web, y compris notre CDN et l’informatique de bord. Je fais du développement web et de l’architecture cloud depuis 20 ans et pendant ce temps j’ai eu le plaisir de travailler dans de nombreuses industries, y compris Fintech et ecomm, où j’ai travaillé avec de nombreuses marques, y compris Urban Outfitters, Coach, Verizon , et M&M.S.
Tom Mount : très bien. Merci Howie. Aujourd’hui, nous voulons vous parler un peu des défis de sécurité auxquels sont confrontées les architectures composables. Plus précisément maintenant, nous savons qu’il y a beaucoup de menaces de sécurité là-bas pour les propriétaires de sites Web et les gestionnaires de contenu.
Selon IBM, il y a une étude qui dit que 83% des entreprises américaines ont subi une violation de données et cela peut coûter plus de 9,4 millions de dollars aux États-Unis. C’est plus du double de la moyenne mondiale. Okta, c’est l’un des plus grands fournisseurs d’identité Single Sign-on au monde. Ils ont publié un rapport selon lequel 34% de toutes les tentatives de connexion dans le monde étaient effectuées par des bots. Donc, ce sont juste des bots qui essaient littéralement d’entrer dans des comptes réseau qui viennent de montrer qu’une organisation sur quatre a perdu 500 000 $ à cause d’une seule attaque de bot. La sécurité est donc une menace énorme. C’est un énorme problème que nous devons traiter.
Et comme nous parlons d’architectures composables, c’est quelque chose qui commence vraiment à devenir un peu plus difficile à résoudre. Et ainsi de suite, dans ce podcast d’aujourd’hui, nous voulons jeter un coup d’œil sur certaines des menaces qui existent pour les architectures composables et ce que nous pouvons faire pour y remédier.
Donc, avant d’entrer trop profondément dans ce sujet, Howie, je me demande si vous pouvez peut-être définir pour nous ce qu’est l’architecture composable, qu’est-ce que cela signifie pour vous ?
Qu’est-ce que l’architecture composable ?
Howie Ross : bien sûr, je peux essayer. C’est un peu une de ces choses qui est un peu difficile à définir, mais vous le savez quand vous la voyez. L’architecture composable est vraiment une réaction aux plates-formes monolithiques tout-en-un qui ont été utilisées, vous savez pour le disons la décennie précédente et les limites imposées à l’expérience utilisateur et au flux de travail des développeurs.
Ainsi, avec une architecture composable, les solutions sont composées d’outils et de fournisseurs répartis sur l’ensemble de la pile qui vous permettent de sélectionner les meilleurs outils de leur catégorie pour répondre aux besoins de votre entreprise et de vos utilisateurs.
Et composable est souvent associé à des frontaux sans tête ou découplés où nous séparons la couche de présentation de la couche de données et nous nous appuyons souvent sur des microservices ou au moins des architectures pilotées par API pour faciliter cette architecture découplée sans tête et composer une solution complète à partir de divers outils.
Tom Mount : cela semble assez flexible, mais il semble aussi qu’il soit un peu plus difficile techniquement de mettre en œuvre certaines de ces piles.
Pourquoi choisir Composable?
Qu’est-ce qui inciterait une entreprise à choisir d’opter pour une architecture composable par opposition à ce modèle plus monolithique, vous savez, bien établi?
Howie Ross : Oui, c’est une excellente question. Eh bien, il y a de nombreux avantages aux architectures composables, y compris, comme je l’ai mentionné, une expérience utilisateur améliorée en raison de moins de limitations UX, n’est-ce pas ? Donc, sur une pile monolithique, vous allez être souvent limité à, vous savez, quelles sont les capacités fournies par cette pile. Cependant, avec l’architecture composable, c’est un peu comme, vous savez, le ciel est la limite.
L’équipe et les concepteurs peuvent imaginer l’expérience qu’ils souhaitent et vous savez que vous allez bénéficier d’une plus grande agilité en termes de déploiement de ces fonctionnalités pour vos utilisateurs finaux.
En fait, nous avons vu que des organisations telles que Iceland Air ont réduit de 90 % le délai de livraison pour déployer de nouvelles fonctionnalités, y compris des promotions. Ainsi, vous allez avoir moins de temps de commercialisation et de temps de rentabilisation pour le travail.
En outre, comme je l’ai mentionné, vous pouvez sélectionner les meilleurs outils et fournisseurs et vraiment construire ce réseau de partenaires de l’écosystème sur lequel vous pouvez compter pour construire votre solution et fournir cette valeur.
Et puis, il est un peu plus évolutif qu’une pile monolithique parce que vous pouvez échanger ces outils comme bon vous semble. Disons donc que votre outil d’avis client ne répond plus à vos besoins. Vous voulez en utiliser un autre. Vous n’avez pas besoin d’aller remplacer toute votre solution. Vous pouvez simplement remplacer cet outil spécifique et continuer à itérer sur votre pile et la garder vraiment moderne.
Tom Mount : voyez-vous maintenant que vous parlez un peu de langue là-bas. Ma, une grande partie de mon expérience est dans la construction de plus d’applications sur le web et vous savez, en regardant l’architecture de certaines de ces choses, j’aime l’idée, l’idée d’avoir à aimer une pile évolutive où vous pouvez simplement déplacer des choses à l’intérieur et à l’extérieur.
Et je pense aussi que la pérennité semble s’étendre non seulement au niveau des composants, mais aussi au niveau de l’infrastructure, n’est-ce pas ? Je veux dire que nous voyons maintenant beaucoup plus d’attention sur les choses faites à la périphérie, les choses faites des choses sans serveur dans le cloud que nous ne l’étions, vous savez, il y a 5 ans, il y a 10 ans.
Certes, cela est beaucoup plus important et je pense qu’avoir une architecture plus flexible où vous pouvez déplacer les composants d’un centre de données plus important vers un cloud, tout se trouve dans un centre de données, n’est-ce pas ? Nous comprenons cette partie.
Mais avoir quelque chose où vous pouvez vous concentrer davantage sur la périphérie et construire des choses spécifiquement pour le traitement de périphérie pour les fonctions serverless et garder ces choses rapides et agiles est je pense un énorme, un énorme avantage aussi bien. Et je pense aussi que la sécurité est, est-ce aussi quelque chose qui bénéficie de cela, non ? Parce que nous avons migré de plus en plus de services et de choses vers le cloud et avons ces solutions compatibles avec la périphérie, la sécurité vient avec cela.
Donc, nous pouvons faire beaucoup de sécurité zéro confiance à la périphérie, au lieu de devoir revenir tout le chemin dans un centre de données et avoir une architecture composable nous permet, je pense, d’intégrer la sécurité zéro confiance directement dans la structure de l’application elle-même. Et je dirais comme je l’ai dit en haut, je construis des sites Web depuis 20 ans. J’ai travaillé avec des chaînes d’outils partout. Je pense que l’une des bonnes choses que nous avons vues, en particulier avec certains frameworks composables, est que beaucoup de ces frameworks ont maintenant des capacités intégrées pour la génération de sites statiques.
Et ces choses peuvent être simplement diffusées directement dans ce pipeline de construction et repoussées dans le cadre de cela, vous pouvez simplement échanger les composants ou les architectures que vous voulez. Votre pipeline va tout construire et tout finira par être vous savez, distillé dans cela, vous savez les fichiers statiques le HTML, le CSS, le JavaScript, les images dont nous avons besoin indépendamment de la façon dont ils ont été construits et quelles pièces de puzzle s’emboîtent ensemble, les pipelines peuvent encore rester les mêmes. Les déploiements peuvent toujours refléter cela. Je pense donc que c’est un qui me semble, du point de vue de l’architecture, un autre avantage que vous obtenez de pouvoir déplacer ces composants dans et hors.
Témoignages de réussite de clients – norme universelle
Howie Ross : Oui, ce sont des points intéressants que vous connaissez, donc en plus des avantages pour l’équipe de développement et pour le client, il y a des avantages significatifs pour vous connaître l’équipe DevOps et les options qu’elle vous offre pour votre architecture d’infrastructure.
Que ce soit en tirant parti de la génération statique et que vous sachiez vraiment construire votre site pour le CDN et pour la périphérie ou en tirant parti des avancées de la technologie cloud pour votre évolutivité et votre sécurité. Et vous savez donc que Tom et moi avons eu le plaisir de travailler avec un certain nombre de clients qui sont allés sur ce chemin vers composable et qui ont constaté des avantages significatifs.
Vous savez donc que les clients incluent certains de ceux que j’ai mentionnés plus tôt, comme Coach et M&M, qui sont soit terminés, soit en cours de route dans leurs voyages composables.
L’un des autres clients les moins connus s’appelle Universal Standard qui a pour mission d’être la marque de vêtements la plus inclusive au monde. Et vous savez que pour cette mission, ils ont choisi d’opter pour une architecture composable construite sur la plateforme Shopify.
Vous savez donc qu’au lieu d’être un peu contraints par les limitations imposées par Shopify en termes d’expérience utilisateur et de flux de travail des développeurs, ils exploitent les API Shopify Storefront et construisent une solution composable en utilisant le framework Nuxt qui est construit sur vue JS.
Et ils ont vu que vous savez une amélioration significative des performances, vous savez, en ramenant les temps de chargement des pages de plusieurs secondes à dans de nombreux cas en dessous de la 2ème et en améliorant vous savez, pas seulement ces métriques de performance technique mais aussi les métriques commerciales réelles.
En fait, ils ont constaté une amélioration de 200% du taux de conversion suite à ce passage à composable. C’est bien sûr vraiment affectant, leurs résultats financiers et les aider dans leur mission.
Témoignages clients – carnaval de la chaussure
Tom Mount : Oui, c’est vraiment génial. Je veux dire que nous avons parlé de vous savez que la sous-deuxième page se charge ici et c’est les gens toujours. Quand je parle avec des gens, j’ai toujours l’œil de côté comme si tu étais sûr de ça et non, c’est vrai. Vous connaissez un des clients que je montre parfois et qui a une histoire similaire, c’est une société appelée Shoe Carnival, donc ils sont passés à Headless aussi. Ils avaient leur architecture précédente. Ils examinaient spécifiquement les problèmes de performance autour de choses comme le chargement de la première page et les transitions entre les pages.
Donc leurs stats avant qu’ils ne deviennent sans tête, ils regardaient, vous savez, 3, 3, 3 1/2 secondes pour un chargement de la première page et parfois jusqu’à 6 secondes lors de la transition d’une page à l’autre lorsque vous naviguez. Et ils voulaient vraiment faire baisser ça. Et il y a beaucoup de raisons pour lesquelles c’est une excellente idée de déplacer ça vers le bas.
Nous avons beaucoup d’études de marché qui montrent que pour chaque seconde supplémentaire les clients attendent que la page se charge, cela augmente leurs chances de quitter le site et d’aller ailleurs. Donc évidemment , la vitesse de page et le taux de conversion sont assez étroitement liés et ils reconnaissent cela.
Ils sont donc venus chez Edgio pour obtenir de l’aide et ont immédiatement terminé leur transition vers le headless et ils avaient apporté certaines de ces améliorations de performance dont nous parlions. Ils ont pris leurs transitions et même leur première page se charge à une seconde, parfois même moins d’une seconde. Ils sont jusqu’à 70% plus rapides sur Edgio. Leur temps de chargement médian pour les pages est d’une seconde, n’est-ce pas ? Ils constatent donc des gains de performances considérables en choisissant cette architecture sans tête et en optimisant leurs performances à tous les niveaux de la pile. Et même leur page se charge, leur page suivante se charge de, vous savez, une fois qu’ils atterrissent sur le site, ils sont en baisse de 92% sur cette vitesse. Ils sont descendus à 500 millisecondes sur certains de ces chargements de pages. Des gains de performances considérables qu’ils ont pu réaliser.
Mais ce n’est pas seulement la performance qui est une caractéristique attrayante de Composable. S’en tenir au carnaval de la chaussure. En plus des gains de performance, ils ont également profité de l’opportunité d’entrer dans composable pour accélérer certains de leurs efforts de sécurité. Et, ce qu’ils ont découvert, c’est que dans les 30 premiers jours suivant le lancement de leur nouveau site composable, ils avaient suivi plus de 8 millions de requêtes malveillantes qui ont été bloquées. Et je veux me concentrer, je vais m’assurer que je répète que ces demandes ont été bloquées.
Ce n’est pas qu’ils avaient 8 millions de demandes qu’ils ne savaient pas quoi faire, n’est-ce pas ? La solution de sécurité que nous avons trouvée était capable de bloquer toutes ces requêtes et de fournir une visibilité sur ce qu’ils n’avaient peut-être pas vu avant le volume de requêtes malveillantes qu’ils recevaient.
Avantages de Composable en matière de sécurité
Donc, ce genre de choses m’amène à parler un peu des avantages de la sécurité parce que nous avons passé beaucoup de temps à parler des gains de performances et ils sont très réels. Et vous savez, nous, nous suivons nos clients quand ils viennent, nous, nous aimons voir les gains de performance qu’ils ont et nous avons des histoires de réussite étonnantes.
Mais je pense que les gains de sécurité sont une autre bonne raison de choisir une architecture composable. J’aime voir ça comme une sorte de défense à plusieurs niveaux, non ? Nous voulons donc garder les mauvais acteurs aussi loin que possible de votre origine, de l’endroit où se trouvent vos serveurs réels et vos données. Et vous pouvez y penser en termes de, vous savez, mettre une clôture autour de votre propriété. Vous pouvez avoir des signes sur votre clôture, disons, ne pas entrer, vous savez, aucune intrusion quoi que ce soit. Mais cela ne signifie pas nécessairement que vous ne verrouillez pas votre porte la nuit. Cela signifie simplement que vous voulez mettre un garde-corps aussi loin que possible pour tenir dehors autant que vous le pouvez.
Et lorsque vous choisissez une architecture composable, l’un des avantages est que vous pouvez ensuite choisir les fonctions de sécurité que vous avez en place et où ces fonctions de sécurité sont situées.
Et nous vous recommandons d’avoir la sécurité à tous les niveaux que vous pouvez corriger. Donc nous allons mettre cette sécurité à la périphérie, nous allons mettre cette sécurité à l’origine. S’il existe d’autres API ou services, vous savez, nous avons mentionné que devenir composable signifie généralement que vous augmentez, vous savez, le nombre d’API exposées sur votre site. Nous voulons donc nous assurer que ces API sont sécurisées et avec une architecture composable, cela devient vraiment très simple à faire. Vous devez tenir compte de tous ces endroits, mais vous pouvez mettre la sécurité à tous ces différents niveaux.
Une des autres choses agréables à propos d’avoir une architecture composable, et j’ai déjà abordé cela un peu avant, c’est la possibilité d’avoir ces pages statiques. Maintenant, les pages statiques sont excellentes pour la performance, mais elles ont également un avantage très intéressant pour la sécurité car les pages statiques minimiseront la quantité de transfert de données bidirectionnel qui se produit entre le client et le serveur.
Si vous pensez à un type traditionnel d’application monolithique, application PHP, ou quelque chose comme ça, quelqu’un entre des données dans cette application et il doit aller dans l’arrière dans le serveur. Si vous chargez une nouvelle page, le serveur doit aller demander ces données et les renvoyer. Il existe de nombreuses opportunités pour les données d’entrer et de sortir de vos systèmes. Et bien, évidemment, il a des données à sortir.
Vous voulez vous assurer que toutes les données qui se trouvent dans vos systèmes ne sortent pas. C’est ce que nous appelons une violation de données.
Donc avoir des pages statiques réduit les possibilités pour quelqu’un de bricoler avec votre serveur au moyen de la page qui est affichée dans le navigateur Web parce que tout ce qui est sur la page est juste HTML, non?
Il n’y a pas, il a déjà les données. Ce n’est pas récupérer ces données de n’importe où. Il a déjà été construit avec ces données à l’esprit. Donc, avoir des pages statiques, vous le savez, alors que certainement un gain de performance peut également être un gain de sécurité et ces pages statiques peuvent alors être servies directement à partir d’un CDN.
Et donc je pense que c’est le genre de la dernière pièce du puzzle ici dans cette partie particulière de la sécurité est qu’au lieu d’avoir à retourner à vos serveurs pour récupérer ces données chaque fois que la page est chargée avec le CDN, cette page est mise en cache, elle est disponible dans le monde entier et vos serveurs ne voient même pas ces requêtes car elles sont toutes traitées directement à la périphérie externe.
Howie Ross : Oui, c’est un point formidable. Et je suis d’accord pour dire que vous savez que l’un des principaux avantages d’une solution composable, que vous sachiez générer des sites statiques ou exploiter le rendu serveur sans serveur, c’est la capacité à exploiter le CDN de manière plus efficace. Cela va vous fournir des temps de chargement de page améliorés, mais aussi des avantages de sécurité ainsi que vous savez garder les mauvais acteurs aussi loin que possible.
Vous savez de vos données et de vos joyaux de la couronne et aussi vous savez minimiser ce transfert de données bidirectionnel aussi bien, mais vous le savez, alors qu’il ya quelques avantages de sécurité, je pense qu’il ya aussi quelques défis aussi bien.
Vous savez, nous avons parlé des solutions composables, vous savez que vous sélectionnez les meilleurs fournisseurs et outils, ce qui signifie qu’il y a, vous savez, plus d’outils, plus de fournisseurs, ce qui signifie potentiellement que vous connaissez plus de façons d’utiliser vos systèmes et vos architectures. Donc, vous savez, donc c’est un risque.
Et l’une des façons de plus en plus courantes de compromettre les organisations est en vous connaissant l’usurpation d’identité, d’accord, plutôt que vous savez forcer brutalement mon chemin dans votre site Web ou vos serveurs. Je vais juste trouver comment faire de l’ingénierie sociale pour ressembler à un de vos employés. Et maintenant, au lieu d’avoir à briser votre réseau central et vous connaissez vos outils d’entreprise. Il se peut que je ne sois pas en mesure de violer l’un des nombreux outils et fournisseurs que vous utilisez sur votre solution composable, afin que vous sachiez que la gestion des identités et des accès devient de plus en plus importante.
Vous savez que cela peut être atténué de plusieurs façons grâce à des normes et à une connexion unique et à des choses comme ça. Mais c’est quelque chose que vous voulez être, vous savez réfléchi parce que vous connaissez l’essor du skimming de données et vous savez qu’il s’agit d’une classe de vulnérabilités ou d’exploits.
Il est souvent appelé mage cart qui était l’une des exploitations originales de ce type d’attaque où vous savez qu’un script est mis sur un site Web par ces attaquants qui va ensuite, vous savez, éclipser des informations personnelles.
Dans ce cas, il s’agissait d’informations de carte de crédit provenant principalement de sites Magento et il était répandu et vous savez, il a vraiment mis au premier plan la, vous savez, la criticité et la gravité de ce problème et l’importance d’avoir, vous savez, gérer l’intégrité de votre code tout au long de la chaîne logistique.
Et vous savez aussi, j’ai mentionné l’importance d’être vraiment prudent dans la gestion de vos identités et de vos accès, oui, ça a beaucoup de sens.
Tom Mount : vous savez, évidemment, avec plus d’outils, il y a plus d’opportunités d’entrer. Je pense que du point de vue de l’architecture applicative, beaucoup de sites composables utilisent fortement les appels API vers le serveur pour remplir de nouvelles pages afin de faciliter une navigation plus rapide. Et je pense que la sécurité des API est un autre domaine où vous devez prêter plus d’attention à ce que vous faites et à ce qui se passe.
Donc évidemment, vous savez, je ne veux pas ma page quand je fais du shopping sur un site. Je ne veux pas que ma page soit mise en cache pour vous et vous ne voulez probablement pas que votre panier soit mis en cache pour moi parce que c’est juste déroutant et je ne comprends pas pourquoi. Tu sais pourquoi j’ai ce que j’ai dans mon panier quand je le tire vers le haut.
Donc évidemment, nous devons nous assurer que nous avons des pages réactives rapidement, mais nous voulons aussi nous assurer qu’elles sont personnalisées pour l’utilisateur individuel et généralement, cela se fait via une sorte d’accès API, et souvent, les informations du visiteur finissent dans ces données API qui sont transmises.
Et c’est donc là que la partie zéro confiance de la sécurité intervient spécifiquement autour de l’API, n’est-ce pas ? Nous pouvons donc faire des choses comme la personnalisation en périphérie où nous récupérons du contenu, le contenu mis en cache depuis le serveur, et à la périphérie plutôt que dans le navigateur, nous extrayons ces données du serveur et les incorporons dans la réponse finale que nous envoyons. C’est un excellent moyen d’avoir des pages vraiment rapides et vraiment réactives qui sont toujours en cache, mais qui ont aussi des données personnelles sur elles.
Une autre façon de faire un peu de magie de sécurité à la périphérie est d’utiliser quelque chose comme, vous savez, JSON Web Tokens pour l’authentification. C’est l’IA n’entrera pas dans les détails de ce qu’ils sont parce que c’est l’un de mes projets préférés actuels avec lequel jouer. Et je pourrais en parler pendant probablement 20 minutes de plus juste toute seule. Mais podcast, oui, nous le ferons, nous ferons un podcast sur JTBTS plus tard.
Mais oui, ce qui est sympa, c’est que ce sont des données qui sont transmises en clair mais qui ont aussi une signature chiffrée que le serveur sait comment générer sa propre version de cette signature chiffrée.
Et vous pouvez donc vérifier la validité de l’utilisateur entrant pour vous assurer que vous savez que rien n’a été falsifié, que les informations d’identification sont correctes, et que vous savez que l’utilisateur a accès à tout ce qu’il dit qu’il devrait avoir accès.
Vous pouvez vérifier que cet accès est toujours valide et correct. Et vous pouvez le faire aussi à la périphérie en utilisant, vous savez, la fonction excédentaire ou la fonction cloud, des choses comme ça. Donc, envelopper tout cela autour des API va être vraiment essentiel à résoudre, vous savez, que vous utilisiez cette authentification zéro confiance ou un autre mécanisme.
La sécurité API est un must, oui, parce que désolé, je suis désolé, allez-y.
Howie Ross : C’est donc l’un des principaux compromis des architectures composables, n’est-ce pas ? Donc vous savez que nous sommes vous savez que nous ne construisons pas notre application pour tirer parti du CDN et du calcul Edge, mais pour conserver ceux que vous connaissez ces expériences dynamiques que cette personnalisation nous avons pour exploiter les API. Vous savez donc que nous avons une sorte de prolifération potentielle de services et d’API qui peuvent en fait augmenter la surface de la menace.
Il est donc essentiel maintenant de tirer parti d’une solution de sécurité API et celles-ci seront un peu différentes de celles que vous connaissez, vous connaissez les solutions de sécurité plus conventionnelles que nous allons utiliser, vous savez que nous allons aborder brièvement parce qu’ils doivent être adaptés à ce cas d’utilisation API, n’est-ce pas. Et donc nous devons tout d’abord nous assurer que nous connaissons toutes les API correctement?
Vous allez donc vouloir tirer parti d’un outil qui fait la découverte d’API et vous aide à trouver et gérer toutes vos API et à vous assurer que nous n’avons pas de ce que nous aimons appeler des API zombies qui sont des API que vous savez avoir développées à un moment donné et peut-être qu’ils ne sont plus vous savez que vous avez itéré et ils sont peut-être qu’ils ne sont plus utilisés mais ils sont toujours là-bas.
Nous devons donc avoir un inventaire complet de nos API et de notre zone de menace. Et puis, en plus, nous voulons que vous connaissiez certaines pratiques de sécurité de base en place, comme la limitation des tarifs, n’est-ce pas ?
Nous voulons contrôler la vitesse à laquelle quelqu’un peut demander des données à ces API et plus précisément qu’un bot ou un attaquant utilisant l’automatisation peut demander des réponses à ces API afin qu’elles ne soient pas submergées et créent effectivement une situation de déni de service.
Et l’autre chose que nous pouvons faire avec la sécurité API qui est vraiment intéressante et devient de plus en plus accessible à mesure que nous, vous savez, adoptons et exploitons l’IA est ce que nous appelons la validation de schéma. Donc c’est là que nous allons, vous savez, avant notre requête, c’est votre API juste à la périphérie, nous allons nous assurer que cette requête est conforme au schéma de vos requêtes API, n’est-ce pas ?
Donc, si cela ne ressemble pas à une requête API correctement formée, nous allons la bloquer à la porte, nous allons l’arrêter juste à la périphérie du réseau et elle n’arrivera même jamais dans votre infrastructure pour être, vous savez, j’espère qu’il a été rejeté là-bas. Mais oui, il va être essentiel de tirer parti de la sécurité des API et cela devient, vous le savez, de plus en plus commun, accessible et utile.
Tom Mount : Oui, certainement. Et vous savez que nous parlons de certaines de ces préoccupations de sécurité spécifiques composables que nous avons et des façons dont nous pouvons atténuer certaines de ces choses. Mais je pense qu’il est important aussi que nous n’oubliions pas les vieux trucs de sécurité de secours, non ? Les trucs qui nous ont plutôt bien servis pendant un moment.
J’ai mentionné plus tôt que vous savez que la sécurité est un peu comme vous savez avoir un tas de couches différentes juste parce que vous juste parce que vous verrouillez votre portail la nuit ne signifie pas que vous laissez votre porte grande ouverte, non ?
Parlons donc un peu de certaines des pratiques générales de sécurité qui sont peut-être encore parfaitement correctes et qui devraient faire partie de l’architecture globale même si elle n’est pas spécifiquement orientée vers l’architecture composable.
Meilleures pratiques pour améliorer votre posture de sécurité
Howie Ross : bien sûr. Vous connaissez donc cette approche de sécurité en couches que vous avez mentionnée. Nous appelons aussi souvent cela la défense en profondeur, n’est-ce pas ? Ainsi, vous savez entre l’attaquant et les joyaux de la couronne qui va souvent être vous connaissez les données de votre entreprise et de votre utilisateur. Nous voulons avoir plusieurs couches de sécurité de sorte que dans le cas où l’une est violée, nous avons toujours ces couches supplémentaires. Il y a donc un certain nombre d’atténuations et de systèmes que nous voulons avoir en place.
Et le premier, vous connaissez l’ancien standby que vous avez mentionné Tom qui va être notre pare-feu d’application Web et nous allons vouloir nous assurer que nous avons un WAF robuste avec un très bon ensemble de rôles gérés pour bloquer les attentes de tous les vulnérabilités connues.
Et nous allons vouloir nous assurer que vous savez que nous travaillons avec un partenaire qui publie rapidement des correctifs pour ce que nous appelons des exploits zero-day nouveaux et émergents.
Ainsi, plutôt que de devoir faire le tour et appliquer individuellement des correctifs à chacune de vos API, nous pouvons déployer un correctif sur notre WAF à la périphérie et atténuer cette vulnérabilité dans tous nos services.
Et puis en plus, vous savez, nous avons parlé je pense plus tôt de l’impact des bots, de la montée des attaques de bots, du nombre de requêtes de bots qui se produisent sur nos systèmes. Maintenant, tous les bots ne sont pas mauvais, non ? Les bots parcourent nos sites et mettent ces données à la disposition des moteurs de recherche. Il est donc essentiel que nous laissions certains bots faire leur travail et que nous bloquions les bots, les bots malveillants qui essaient de faire des choses comme un éventuel déni d’inventaire, n’est-ce pas ? Ils essaient d’acheter toutes les baskets ou tous les tickets avant que les autres utilisateurs puissent les obtenir.
Les bots font aussi des choses comme la prise de contrôle de compte. Ils essaient simplement différentes combinaisons de noms d’utilisateur et de mots de passe ou ils essaient des noms d’utilisateur et des mots de passe qui ont été violés à partir d’un autre site. Ils l’essaient sur votre site potentiellement parce qu’ils savent que beaucoup de gens réutilisent les mots de passe. Il va donc être essentiel que nous ayons notre solution de gestion des bots en place.
Tom Mount : Oui, certainement et je pense que vous connaissez l’un des autres dont nous avons tous entendu parler vous connaissez les choses de gestion de bots que nous vendons des billets comme vous savez que nous avons eu des problèmes avec les vendeurs de billets dont les billets sont mis en vente et sont immédiatement récupérés par des bots, n’est-ce pas ?
Les nouvelles baskets tombent du fabricant et tout d’un coup ces baskets sont juste disparues. Et je dis parfois aux gens à environ 50% en plaisantant que, vous savez, dans 10 ans, l’Internet va en gros être juste des bots attaquant d’autres bots, n’est-ce pas ? Ça va être ça, n’est-ce pas ? Les bots vont acheter des chaussures à d’autres bots. Ils vont attaquer d’autres sites web.
Et je dirai aussi, vous savez, en ce qui concerne les attaques de bot, je me souviens quand j’ai commencé dans l’industrie, les attaques DDoS étaient rares, n’est-ce pas ? Les attaques par déni de service étaient rares parce qu’il fallait beaucoup d’argent et beaucoup d’efforts pour dépenser sur l’une d’entre elles. Ce n’est plus le cas, n’est-ce pas ? Comme nous avons vu des attaques de bot. C’est, je suppose que c’est la réalité de la situation aujourd’hui, c’est qu’il n’est pas nécessaire d’être énorme pour être la cible d’une attaque par déni de service et que les attaquants n’ont pas besoin d’être riches pour exécuter ces attaques. Les ensembles d’outils, les chaînes d’outils et les ressources de cloud computing pour faire tourner ces choses vers le haut.
Je veux dire, nous avons même vu des attaques par déni de service qui incluent ce que nous appelons des réseaux de bots, c’est juste des ordinateurs quelque part qui ont été enchaînés pour exécuter cette attaque, y compris probablement celle qui est sur votre réfrigérateur intelligent ou votre machine à laver, n’est-ce pas ?
Comme si c’était une conséquence de plus en plus d’objets connectés à Internet et de plus en plus d’ordinateurs disponibles dans des paquets plus petits étant de plus en plus distribués à l’échelle mondiale. Nous avons assisté à une augmentation considérable des attaques par déni de service.
Et je pense que vous savez que nous pensons non seulement à la sécurité mais aussi aux meilleures pratiques pour, pour construire un site web en général, c’est 2024 à partir de cet enregistrement, au moins vous avez besoin d’un CDN, c’est vrai, parce que le CDN va vraiment être le meilleur moyen de vraiment absorber ces niveaux d’attaques et ces attaques surtout ces attaques distribuées.
Cela va-t-il arrêter chacun d’entre eux ? Aucun. Mais vous savez, j’ai eu ces cinq dernières années, j’ai eu deux ou trois compagnies spécifiquement qui ne savaient pas qu’elles avaient été attaquées parce que leur CDN était juste si bon pour absorber l’attaque.
Ce n’est qu’après l’attaque qu’ils sont retournés dans leurs journaux. Et je ne parle pas longtemps après, vous savez, quelques heures ou un jour ou deux plus tard, ils retournent dans leurs journaux comme wow, nous avons juste eu des millions et des millions et des millions de demandes ces derniers temps.
Je me demande ce qui s’est passé ici. Parfois, vous savez, si les alertes sont activées, ils peuvent voir l’augmentation du trafic et ils ne le voient jamais vraiment sur leur site Web. Un CDN est donc un moyen trompeur et simple de gérer ces attaques par déni de service.
Et donc vous savez, même avec toutes les nouvelles opportunités de sécurité disponibles, comme certaines des fonctionnalités de sécurité API sont vraiment fascinantes pour moi. J’adore parler de ces trucs.
Une partie de cette sécurité zéro confiance est qu’il y a des choses qui se passent dans ce domaine qui sont juste, vous savez, époustouflantes à quelle vitesse nous avançons là-dedans.
Mais vous savez l’ancien vous avez toujours besoin de CDN, toujours besoin d’un WAF, non? Je veux dire que ce sont de bons outils à avoir, et ils continueront d’être de bons outils à avoir quel que soit le type d’architecture que vous décidez de choisir à mesure que vous avancez.
Et Howie, je pense que l’une des choses que vous avez mentionnées juste en passant, je veux aussi l’appeler parce que vous avez mentionné avoir un bon partenaire qui comprend ces choses.
Je pense qu’il y avait autrefois un sentiment dans la création d’applications Web, en particulier dans les grandes entreprises, que nous devions toujours faire tout seul, n’est-ce pas ? Nous avons besoin de nos propres experts internes, nous avons besoin de nos propres employés internes pour le faire. Et cela a fait que beaucoup de gens en interne ont pris beaucoup de longues heures et sont vraiment devenus très frustrants et un peu brûlés.
Alors que vous choisissez une architecture composable, gardez à l’esprit que ce n’est pas seulement l’architecture réelle que vous pouvez choisir la meilleure. Vous pouvez également trouver les meilleurs partenaires qui vous aideront à naviguer dans cet espace.
Vous savez trouver quelqu’un qui a déjà fait cela avant qui a une bonne idée des menaces qui existent sur la façon dont les choses se construisent et travaillent avec ce partenaire et construire une relation avec eux pour aider à obtenir votre site et votre architecture sécurisés, les performances et obtenir rapidement ça a poussé.
Je sais que nous avons beaucoup parlé des avantages de l’expérience utilisateur pour le workflow. Vous savez qu’il y a d’autres points à retenir que vous pensez qu’il serait bon de souligner en terminant ici ?
Derniers éléments clés à retenir
Howie Ross : Oui, je veux dire que je pense que vous avez atteint les points forts de la façon dont vous savez que composable a de nombreux avantages, y compris l’expérience utilisateur et le flux de travail qui peuvent avoir des impacts tangibles vous savez s’il s’agit de réduction des coûts ou d’augmentation des revenus. Mais il présente également quelques-uns que vous connaissez de nouvelles préoccupations que nous avons abordées.
Donc, vous savez que vous allez toujours avoir besoin des solutions de sécurité dont nous tirions parti et nous allons vouloir nous assurer que nous disposons de nouveaux outils de sécurité et que nous accordons également une grande attention à notre gestion des identités et des accès.
Et puis, vous savez, rappelez simplement que vous savez que cela donne l’occasion, vous savez, non seulement de sélectionner des fournisseurs, mais aussi de sélectionner des partenaires qui non seulement l’ont fait auparavant, mais qui le font actuellement, vous savez, avec d’autres entreprises afin que vous sachiez que vous pouvez bénéficier de leur vaste expérience auprès de divers clients et industries.
Tom Mount : Oui. Merci Howie d’avoir pris le temps de discuter un peu avec moi à ce sujet. Ça a été, ça a été amusant. J’espère que pour nos auditeurs et nos téléspectateurs, j’espère que cela vous a fourni de bonnes informations sur lesquelles réfléchir et quelques choses à considérer.
Et vous savez qu’Edgio est prêt à vous aider en tant que partenaire de confiance et nous aimerions partager avec vous certaines de nos expériences et certains de nos succès.
Merci à tous de vous joindre à nous sur Beyond the Edge et nous vous reverrons la prochaine fois.
Pour des performances plus rapides, une sécurité plus intelligente et des équipes plus heureuses, parlez dès aujourd’hui à l’un des experts d’Edgio .
