APIs : Comment automatiser votre sécurité, résilience et conformité

0:09 Bonjour Noémie, bonjour à tous. Donc très heureux, très heureux d'être ici. Je serai votre animateur, votre modérateur pour ces échanges. Donc mon nom est Toufik, je suis expert en cybersécurité. J'ai travaillé pour plusieurs compagnies, notamment des startups de la French Tech, Payfit, Doctolib. Et aujourd'hui, je travaille pour Believe, une entreprise dans le domaine de la musique et en particulier dans la gestion des musiciens. Donc aujourd'hui, on a la chance de rencontrer un panel d'experts avec qui on va parler sécurité des API, gouvernance, compliance et résilience des API. Et ces experts, aujourd'hui, on a Camille Marcini et Olivier Cahagne qui peuvent nous rejoindre. Bonjour à eux. Bonjour Toufik, bonjour tout le monde. Bonjour Toufik, bonjour. Alors aujourd'hui, voilà le sujet qui est posé.

1:14 Donc API, comment automatiser, sécuriser, comment développer de la résilience et de la conformité sur ces API. Mais avant de rentrer dans ce sujet, on va encore présenter nos experts aujourd'hui présents. Donc Camille, qui est manager de l'équipe cybersécurité à Blablacar, et Olivier, qui est solution engineer à Cloudflare, Je vous laisse vous présenter plus en détail. Je laisse la parole à Camille. Je suis en fait manager de l'équipe cyber sécurité chez Blablacar et ce depuis un peu plus d'un an. L'équipe sécurité chez Blablacar, on s'occupe vraiment de protéger les données et les infrastructures de l'ensemble des entités qui constituent Blablacar. Puisqu'il y a à la fois du covoiturage longue distance qui est très connu, mais il y a également du covoiturage courte distance. Et puis un certain nombre d'offres relatives au voyage en bus avec les Blablabus, entre autres. Blablacar est présent à l'international et donc a également des produits de marketplace de bus dans d'autres pays.

2:22 Avant d'arriver chez Blablacar, j'ai vraiment fait toute ma carrière en cybersécurité. Je suis passée par le conseil, comme beaucoup de gens, avant de venir faire de la sécurité, plutôt de protéger les entreprises chez les clients finaux, notamment des entreprises de toutes les tailles. Ça peut aller de la multinationale à la startup. J'ai passé quelques années en Nouvelle-Zélande, où j'ai bossé en startup. Et puis, désormais, je suis à Lyon, après être passée par Paris, Marseille et d'autres villes. Voilà, Olivier. Merci, Kavi. Je découvre plein de choses. Du coup, Olivier Cahagne, moi, je suis Solution Engineer, comme le disait Toufik, chez Cloudflare. Dans mon rôle, depuis maintenant un petit peu plus d'un an, un an et demi, j'aide les clients à se protéger des menaces Internet, donc sécuriser les réseaux, les applications, et puis aussi les utilisateurs. Avant ça, alors moi je suis basé à Paris, j'ai toujours été basé à Paris depuis à peu près 20 ans, et puis avant ça, avant Cloudflare, pardon, je ne travaillais pas forcément nécessairement dans la cybersécurité, je travaillais plutôt sur des aspects réseau, IT, cloud, puisque j'ai travaillé presque 5 ans chez AWS,

3:26 où je m'occupais notamment des mutuelles, des assurances, et puis des opérateurs télécoms. Puis encore avant ça, j'ai travaillé chez VMware, où je travaillais sur les offres, peut-être PCC, Private Cloud, ou Dedicated Cloud chez OVH. Et puis encore avant, mais je vais m'arrêter là, parce que ça trahit mon âge, j'ai travaillé pas mal d'années chez Cisco, plutôt sur des aspects réseau, et là aussi opérateur mobile. Je m'arrête là pour mon intro. Très bien, excellent. Merci beaucoup pour ces présentations très détaillées et exhaustives. Donc, voilà, la scène est à vous. Aujourd'hui, on a un sujet très intéressant. Donc, on va parler des API qui sont en quelque sorte des API. applications web et on va voir plusieurs points, plusieurs aspects, qu'est-ce qu'une API, pourquoi on parle aujourd'hui de sécurité, gouvernance des API, comment on peut les sécuriser via des solutions, comment des entreprises aujourd'hui, des startups, des scale-up utilisent les API, donc tout ça.

4:28 C'est des points qu'on va élaborer. Et pour cela, je pense que pour démarrer ce sujet, la première question, une question assez vague, mais qui va permettre d'entrer dans le vif du sujet, qu'est-ce qu'une API? Voilà, qu'est-ce qu'une Application Programming Interface, API? Pour ça, je vous laisse la parole. Allez, je prends la parole. Du coup, en préparant un petit peu la discussion, avec Camille et Toufik. J'ai un petit peu regardé, tiens, qu'est-ce que c'est une API? Qu'est-ce que Wikipédia ou d'autres sites appellent une API? Et du coup, historiquement, une API, c'est finalement juste une communication entre deux machines. C'est assez vague, et même si on remonte un peu dans le temps, on trouve, ou Wikipédia en tous les cas, dit que même SQL, c'est une API. Ce qui est probablement vrai, parce que ça va être peut-être la définition originale, le sujet dont on va traiter aujourd'hui, c'est vraiment les API finalement assez récentes des 10-15 dernières années, et on va voir que c'est essentiellement, en général,

5:36 des échanges d'informations formatés de façon assez standardisée, et puis aussi communiqués de façon assez standardisée. Pour être encore beaucoup plus clair, ce qu'on appelle souvent une API aujourd'hui, mais je ne veux pas non plus restreindre le sujet, c'est très souvent du formatage JavaScript Object Notation, du JSON, qui est envoyé sur un protocole qui est bien standardisé, qui est bien connu, qui s'appelle HTTP. Ce n'est pas la seule manière de construire une API, mais c'est en général maintenant, on va dire comme ça, au doigt mouillé dans les dix dernières années, un peu la majorité des API qui sont au moins exposées sur Internet. Historiquement, il y en a d'autres. Ça ne veut pas dire qu'on n'a pas le droit de faire de XML pour échanger des informations. C'est juste un format qu'on voit un petit peu moins souvent maintenant. Évidemment, il reste énormément de systèmes qui communiquent en SOAP avec un protocole qui échange du XML. Et on voit en général beaucoup plus souvent. Donc des API de type REST qui échangent du JSON en HTTP.

6:38 En général, les API utilisent la richesse du vocabulaire HTTP pour échanger des informations. Est-ce que l'appel API a été couronné de succès? On envoie le code standard HTTP 200. Est-ce qu'il y a tout d'un coup trop de requêtes pour cette API? Est-ce que l'API est surchargée? On peut retourner à ce moment-là le code retour HTTP 499. Je m'arrête un peu là, c'était peut-être une présentation un peu rapide. Oui, c'est assez exhaustif. Là, cette réponse, elle est assez exhaustive. Est-ce que Camille, peut-être, tu peux donner une définition un peu plus abstraite ou high level de ce qu'est l'API, notamment en termes de services et de données? Je vais essayer, en tout cas, les API dans ma carrière, telles qu'on les utilise au niveau des clients finaux, c'est vraiment des interfaces qui vont permettre à deux composants de dialoguer de façon standardisée.

7:41 Il y a plusieurs raisons pour lesquelles c'est un standard qui a vraiment pris, qui constitue maintenant, on aura plus de chiffres, mais enfin une majorité des échanges web. Ça permet une interopérabilité entre à la fois des services internes et des prestataires ou des partenaires ou des clients. Quand on met à disposition une API, ça permet vraiment de donner un... Une façon standard de dialoguer entre deux composants qui ne sont pas nécessairement du même système. Et cette API, on va pouvoir la maintenir en fait juste une API qui va pouvoir servir à de multiples d'autres utilisateurs. Donc ça a vraiment une optimisation des coûts de développement qui permet d'éviter de développer une interface pour chaque prestataire ou consommateur de l'API. Je ne sais pas si c'est une explication un peu plus high level, peut-être, par rapport à ce qu'Olivier disait.

8:43 En tout cas, c'est l'utilisation qu'on en a, c'est le pourquoi on utilise des API, disons. J'aime bien ce que tu dis par rapport à la scalabilité. Je pense que c'est un bon point, ça, sur la raison d'être d'une API. Moi, je me demandais peut-être un petit peu, est-ce que vous avez des exemples d'utilisation d'API? Comment ressemble une API classique? Tout à fait. Alors déjà, du coup, chez Blablacar en particulier, on a vraiment... Étant donné qu'on propose des services qui sont hébergés sur le web, on va avoir la majorité de nos développements qui consistent à développer des API, que ce soit pour servir de... Que ce soit pour les communications serveurs. Donc, on a des clients qui vont utiliser des navigateurs, des mobiles. Ces applications clientes vont aller communiquer avec les serveurs via des API.

9:43 C'est très, très classique. Mais on a également, on va pouvoir potentiellement mettre à disposition des API publics à des prestataires. Typiquement, des prestateurs qui veulent, par exemple, des places de marché, qui veulent proposer des trajets. sur Blablacar, et donc ils vont avoir besoin de l'information de quels sont les trajets qui sont disponibles typiquement. Donc là, on va proposer des API pour que ces partenaires puissent aller demander cette information sur le système de façon centralisée. Et enfin, la troisième façon dont Blablacar peut utiliser des API, En fait, on est consommateur de certaines API, et c'est le cas de beaucoup d'entreprises, on est consommateur d'API qui sont mises à la disposition par des partenaires. Par exemple, on va externaliser certaines fonctionnalités, et dans ces cas-là, de recherche, par exemple, de trajet, et dans ces cas-là, on va avoir besoin, nous, d'utiliser l'API du prestataire qui va faire la recherche de trajet pour nous et nous renvoyer sur ce trajet. Donc, c'est vraiment les trois grands modèles d'utilisation d'API chez Blablacar et en général.

10:47 Ce que je peux vous montrer, c'est un exemple qui va permettre d'illustrer un peu à quoi ça ressemble exactement une API quand on parle d'API, qu'est-ce que c'est concrètement. Alors, ce que je vous présente là, c'est la documentation. officielle, enfin officielle, c'est la documentation de l'API qu'on met à disposition de certains prestataires. C'est une documentation qui est publique et que vous pouvez tout à fait retrouver sur le web. Ça va être une API qui va permettre de récupérer la liste des arrêts de bus. Donc concrètement, on va aller appeler en fait un endpoint. Donc, on va aller appeler un endpoint. Je pense que vous le voyez. Ah, c'est vous. Qui va être celui-ci. Et ce endpoint va répondre à un certain nombre d'informations dans un format standardisé. Donc là, on voit toutes les informations qui sont retournées par le endpoints. Ça ressemble à ceci quand on envoie une requête. En fait, comment est-ce qu'on requête une API? On va envoyer une requête HTTP.

11:49 Il peut y avoir différentes méthodes, ça dépend de l'API. Ce qui est essentiel et c'est sur quoi on va revenir, c'est que les API, une des protections les plus importantes, c'est toutes les notions d'authentification, également d'autorisation. Et puis, il peut y avoir de l'identification si c'est nécessaire. Mais donc, dans ces cas-là, par exemple, on va avoir une authorization qui est donnée via ce qu'on appelle une API key qui est, en fait, alors c'est un secret. Un type de secret en tout cas, qui va pouvoir être obtenu via, dans le cas de la BACA, une authentification avec un personnel. Donc, il va falloir que l'utilisateur aille s'authentifier sur le service pour aller récupérer une clé d'API. Et ensuite, on envoie cette clé-là et ça va permettre au serveur de dire, c'est bon, c'est autorisé, cette requête est autorisée. Et potentiellement, il peut y avoir d'autres paramètres. Alors, dans celle que je vous ai montrée ici, on voit les paramètres de réponse. Il peut y avoir des paramètres dans la requête. Tout ça, c'est très standardisé.

12:49 Donc ça permet d'avoir des échanges qui sont vraiment facilement traduisibles par la machine. Donc voilà à quoi ressemble concrètement. une API. Et là, on a l'exemple avec une réponse. Voilà, ça répond à un nom, une timestamp, etc. Donc, c'est très... Alors, ça, c'est vraiment le format un peu... Là, c'est des curls. Mais comment ça va s'utiliser? Dans tout ce qui est... Il y a des scripts, en fait. Tout ce qui est... Il y a des logiciels qui vont appeler ces API et qui vont pouvoir ensuite... Afficher les bonnes informations potentiellement en réponse. Voilà pour comment on utilise les pieds chez Belacard. Excellent. Et si je faisais l'API qui, généralement, c'est le prestataire qui vous la fournit. En l'occurrence, par exemple, ici, dans notre cas, Blablacar, il y a un formulaire et vous contactez, par exemple, l'entreprise pour générer une API.

13:53 C'est une bonne question. L'API, elle va être fournie par le fournisseur de l'API, d'une manière ou d'une autre, mais pas sur le même endpoint. Il va y avoir des premières étapes d'authentification durant lesquelles on va en général fournir soit des secrets de type username, password, plus potentiellement un deuxième facteur, soit un type de token. Et ensuite cette clé va être générée, elle va correspondre à une permission d'utiliser l'API. Et là, dans ce cas-là en particulier, c'est Blablacar qui fournit cette clé. Dans d'autres cas, quand Blablacar est consommateur, d'une API, la clé d'API va être fournie par le fournisseur de l'API. C'est un mécanisme parmi d'autres qui existe d'authentification pour les API. Très bien, je vois. Et alors, aujourd'hui, on a bien compris ce qu'est une API, à quoi elle sert. Elle propose des services, des données. Elle est dans un protocole précis, REST, SOAP, dans un format, disons, XML, on a aussi des technologies comme GraphQL qui sont aussi des API.

15:05 Une API, ça peut être de la communication machine to machine ou humain vers machine. Souvent, si on a une interface web, une interface graphique, souvent derrière, vous avez une API qui fait office de ce qu'on appelle un back-end, donc une infrastructure qui... Perçoit les requêtes et renvoie des réponses. Alors, maintenant, une fois que ça c'est dit, rentrons dans la partie cybersécurité. Et notamment, commençons par se demander peut-être, pourquoi a-t-on besoin de sécuriser ces API? Contre quoi est-ce qu'on souhaite se protéger? Quelle est votre expérience par rapport à cela, avec la vision que vous avez dans vos organisations, et une vision aussi plus personnelle, votre expertise, vous en tant qu'expert en cybersécurité? Voilà, comment sécuriser une API? Alors, je vais juste commencer et ensuite je te repasse la parole, Olivier.

16:09 Déjà, pourquoi doit-on sécuriser les API? C'est parce que par définition, enfin pas par définition, mais de par leur fonction, les API, c'est souvent des éléments qui sont extrêmement exposés, puisque le but, c'est que ce soit possible d'aller requêter une API depuis Internet. Donc, ça va être vraiment la surface d'attaque qui est exposée. Donc, à partir de là, il y a vraiment des mémas qui sont très spécifiques au web. Et Olivier, je te laisse déplier. Je bois tes paroles. Oui, effectivement, à partir du moment où on expose quelque chose sur Internet, que ce soit une API ou autre, forcément, on se heurte à potentiellement un certain nombre d'attaques possibles. Du coup, j'ai préparé quelques petites données. Quand je dis j'ai, Cloudflare sort énormément de rapports qui sont complètement publics sur les données que voit Cloudflare à travers son réseau. Par exemple, on a publié, c'est vraiment un hasard, mi-janvier 2024, on a publié un rapport sur quelles sont les menaces, quelles sont les attaques que nos clients ou nos utilisateurs voient sur Cloudflare.

17:17 Et du coup, c'est assez intéressant parce qu'on voit qu'il y a, comme l'a dit Camille à l'instant, que la surface d'attaque exposée, enfin la surface plutôt d'exposition des API, mène à des attaques qui sont de temps en temps relativement classiques. Par exemple, on a vu que sur la plupart du trafic API que voit passer Cloudflare, finalement, on voit aussi passer des attaques très classiques qui attaqueraient aussi des sites web très classiques en HTTP. C'est par exemple ici ce qu'on a mis en HTTP Anomaly, ça va être par exemple des paquets mal formés, des gens qui vont essayer de spoofé des user agents. Bref, il y a pas mal d'attaques purement sur la couche HTTP qui se trouve aussi attaquer les API. Alors, plus étonnamment, mais c'est peut-être pas une surprise, pour certains d'entre vous, mais on continue de voir quand même aussi des attaques de type injection SQL, cross-site scripting, même si ça a moins de sens sur la partie API, on en voit quand même passer. Et puis en préparant un petit peu ce webinar, on a vu qu'évidemment les API souffrent ou sont aussi sujettes à du brute force.

18:25 Si tout simplement une API est utilisée pour se loguer sur un site, finalement les attaquants vont aller essayer de faire du brute force. Peu importe que le formulaire renvoie les données en JSON, en HTTP, ce qui donnerait une définition d'API, ou bien s'il renvoie les données de façon un peu plus brute, ça reste de toute façon une attaque de type brute force. Ce qui fait qu'on voit très souvent les API endpoints souffrir de surcharge de trafic. Donc finalement, un des premiers codes d'erreur qu'on voit le plus souvent, tout à l'heure j'ai fait une petite erreur, j'avais parlé de code 489, c'était le code 429, quand un endpoint est surchargé, en général il envoie en retour un code HTTP 429 indiquant qu'il y a une surcharge de trafic. Et du coup, un des moyens les plus simples pour protéger une API, déjà, c'est qu'on peut mettre en place tout simplement du rate limiting, donc pour limiter le trafic sur une API. Évidemment, il ne faut pas le mettre trop bas pour ne pas pénaliser les utilisateurs, mais si on sait qu'une API, par exemple, va avoir...

19:30 une certaine limite, peut-être à un million de requêtes par minute, on peut très bien placer un rate limiting qui soit peu ou prou un million de requêtes par minute, de manière à ne pas surcharger l'API et de manière à la rendre toujours disponible quoi qu'il arrive. On voit qu'il y a des menaces qui sont assez classiques, liées au fait que les API travaillent sur HTTP, des menaces de type attaque par déni de service ou déni de service distribué, des attaques un peu plus ciblées sur lesquelles on peut... se protéger avec un WAF, donc un Web Application Firewall, quelque chose qui va inspecter les requêtes HTTP, HTTPS, et puis essayer de nettoyer le trafic malicieux. Et puis, on va voir que tout au long de la discussion, Cloudflare a aussi travaillé sur davantage de protections spécifiquement liées aux API. Donc spécifiquement liées à cette partie JSON. Je pense qu'on va en reparler un petit peu tout au long de la discussion. Alors pourquoi on a fait ça? Pour cette raison-là, on voit que le trafic API représente une très grosse partie du trafic total vu par Cloudflare.

20:39 Je vais être très précis. Évidemment, il y a du trafic que je vais appeler du trafic statique qui peut être caché par Cloudflare. C'est très souvent des images du JavaScript, etc., du HTML. En revanche, sur le trafic dynamique, qui est en général renvoyé à l'origine, donc renvoyé au site ou à l'Endpoint API, plus de la moitié de ce trafic dynamique est composé d'API. Très souvent, si je prenais ma définition un peu arbitraire, c'est du JSON sur HTTP. Je m'arrêterai là pour l'instant, parce qu'on va revoir d'autres mécanismes pour sécuriser les API, mais on va en reparler tout au long de la discussion. Du coup, je vais repasser la parole à Toufiq ou Camille. Je vais essayer de montrer déjà des aspects assez classiques HTTP, et puis petit à petit, on rentrera un peu dans les API. Alors éventuellement, j'ai juste une question. Le rating meeting que tu as mentionné, Olivier, effectivement, c'est une des protections de base qui existe depuis longtemps sur les API.

21:39 En revanche, ce n'est pas toujours facile à mettre en place, puisque quand il n'y a pas d'intelligence, en gros, et Blablacar, c'est un bon exemple, il peut y avoir des pics saisonniers ou des pics non prévus. Et dans ces cas-là, C'est un peu compliqué de mettre un recleaming qui soit à la fois performant et efficace sur le long terme, mais qui ne pénalise pas le business quand il y a des pics imprévus. Est-ce que c'est quelque chose que vous... Je peux aussi te répondre à cette question. Avec deux aspects. Un premier aspect, c'est important d'aller observer ce qui se passe et donc déjà comprendre un peu quelle est la typologie de trafic, y compris pendant les pics. Peu importe, Cloudflare a des fonctionnalités qui permettent justement de regarder un petit peu et de comprendre peut-être le trafic répétitif qui arrive depuis certains critères. Est-ce que c'est la même adresse IP? Est-ce que c'est peut-être un autre critère? Par exemple, une même empreinte JA3. Une empreinte JA3, c'est une empreinte qui est faite à la fois de la signature SSL TLS d'un utilisateur et puis aussi d'autres attributs HTTP.

22:45 Donc du coup, l'idée, c'est peut-être pas de mettre en place un rate limiting un peu brut qui dise au-delà d'un million de requêtes par minute, c'était mon exemple de tout à l'heure, on drop le trafic, mais peut-être de rate limiter plus spécifiquement, peut-être un trafic qui provient peut-être d'une adresse IP ou en utilisant d'autres critères par exemple, on pourrait réclimiter, ce qu'on voit souvent chez des clients qui ont des pages de login, un truc assez classique, on va réclimiter en fonction du code retour de l'origine. Concrètement, un même adresse IP va essayer de faire du bruit de force, il va très probablement utiliser, alors pas tout le temps la même adresse IP pour passer sous les radars, mais en tous les cas, il va peut-être utiliser la même empreinte JA3, peut-être... d'autres attributs qui reviennent, et puis surtout, il va très souvent se prendre des authentifications incorrectes. Donc ça, ça peut être intéressant de récliner, non pas sur la base d'un volume de trafic, mais vraiment d'aspects beaucoup plus spécifiques, la réponse de l'Endpoint API, la réponse du serveur, et puis d'autres aspects, pour

23:47 justement ne pas bloquer un peu trop violemment tous les utilisateurs légitimes. Je crois que ça peut se faire aussi, notamment sur des divisions uniques du civilisateur, par exemple, qui permettraient d'être limitées sur les actions d'un utilisateur. C'est un sujet assez complexe, donc je voulais approfondir ça, parce que je sais que ce n'est pas facile à mettre en place. C'est facile dans le concept, et en général, quand on essaie de l'appliquer, on se rend compte que c'est beaucoup plus facile. Oui, je suis complètement d'accord avec toi. Ce n'est pas simple à mettre en place, et du coup, c'est pour ça que c'est assez important d'observer ce qui se passe déjà dans une vie classique d'API, y compris pendant les pics. C'est extrêmement intéressant. C'est exactement ce que j'allais aussi dire. Vous avez tout à fait raison de préciser que les dénis de service sont des attaques, finalement, pour l'attaquant assez simple à mettre en œuvre, mais pour le défenseur complexe à identifier et à décorréler d'un flux légitime. Et les différentes méthodes que vous venez de citer, elles sont très intéressantes.

24:52 Utiliser notamment le JA3, c'est vraiment très intéressant. On voit qu'il y a de la recherche et du développement. pour avoir de nouveaux leviers, de nouveaux moyens de détection, de fingerprinting, l'utilisation de l'identifiant du client, Toutes ces méthodes-là, en fait, finalement, là, on est sur la partie déni de service, donc des attaques massives sur un nombre de requêtes qui puissent faire tomber, finalement, l'application et flouder, on appelle ça aussi, ou inonder l'application. Et finalement, les défenses, elles sont subtiles. Il faut bien comprendre le flux entrant pour le décorréler de ce qui va être légitime. Donc, c'est bien joué pour le coup. Après, je peux juste finir de rebondir sur une attaque peut-être un peu plus spécifique, Gizan, et puis après je repasserai un peu la main à Camille, parce que là on voit surtout des défenses qu'on va appeler externes, une fois que l'API a été développée, elle est exposée sur Internet, comment on la défend?

25:58 On a vu qu'il y a des protections anti-DDoS, basées sur soit des empreintes IA3, on a aussi évidemment de l'intelligence artificielle pour essayer de détecter des patterns d'attaques inconnus jusqu'ici, bref, qui n'utilisent pas de signature connue. Plus spécifiquement pour la partie API, je vais juste présenter un aspect particulier des API. Tout à l'heure, je disais pas mal de fois qu'on utilisait des données formatées en JSON. Par exemple, on peut très bien utiliser un schéma d'API. Souvent, un schéma par exemple issu de Swagger ou un schéma conforme à OpenAPI 3.0, on l'upload sur la partie WAF, Edge, enfin bref, les protections externes de Cloudflare. Et l'idée, c'est que ça devient finalement un modèle de sécurité positive dans le sens où tout ce qui sort du schéma classique, c'est-à-dire si un utilisateur envoie une requête GET au lieu d'un poste, même si c'est le bon chemin et les bonnes datas, le GET n'était pas attendu, on attendait un poste, à ce moment-là, le WAF ou la fonction Cloudflare va dropper ce trafic, donc va jeter ce trafic puisqu'il n'est pas conforme stricto sensu

27:10 au schéma d'API qui a été uploadé côté Cloudflare. Ça, c'était juste un exemple. Je m'arrêterai là parce que c'est encore une fois des défenses externes. On n'a pas que les défenses externes, il y a aussi évidemment la conception d'une API qui est assez importante. Là, pour le coup, je ne suis pas pertinent. C'est plus Camille qui est capable de traiter ce sujet. Complètement. En fait, c'est vrai qu'il faut bien voir que les défenses externes, alors déjà, c'est un peu le modèle du château fort sur la sécurité où on a un paramètre de défense externe qui est très important, mais qui ne devrait certainement pas être le seul. Ensuite, les API, vu la multiplicité de leurs utilisations, elles ne sont pas toutes exposées sur Internet, elles ne sont pas toutes exposées au même risque et il va y avoir potentiellement des niveaux de protection différents sur lesquels on va pouvoir jouer. En particulier, ce qui est important de prendre en compte quand on veut sécuriser, ces API, c'est que finalement, une API, c'est du développement. Donc, on retombe sur les concepts de sécurité du code. Et dans l'automatisation, on va plutôt parler de DevSecOps.

28:11 Et d'ailleurs, j'en profite pour préciser que sur Tech.Rocks, il y a un groupe de réflexion. Qui publie des articles sur le BFCOS dont je fais partie. Donc, il y a un certain nombre d'articles qui vont guider sur l'automatisation de tous ces mécanismes dont on va parler. N'hésitez pas à jeter un coup d'œil. Donc, pour revenir sur le lifecycle, je vais juste partager mon écran. Donc, très basique, plutôt très classique en fait. Il n'y a rien qui différencie une API dans le développement d'un autre type de logiciel. Donc, au niveau de la sécurité, on va essayer de vraiment prendre en compte des contrôles de sécurité à toutes les phases de développement. On va commencer design. Ensuite, développement, conception, déploiement, opération et jusqu'à la fin de vie de l'API, donc des conditions. En termes de design, je n'ai pas préparé tous les slides qui détaillent, mais en termes de design, là où on va commencer, c'est vraiment par essayer d'identifier les menaces qui sont vraiment relatives à ce qu'on essaye de développer.

29:21 Et à la fonctionnalité de l'API, on va bien prendre en compte. Donc, ce straight modeling, il est... Il est un peu plus compliqué, de mon expérience, en tout cas, il est un peu plus compliqué à automatiser. Les différentes... J'ai vu... Il y avait notamment un article que Slack avait publié il y a quelques années sur la façon dont eux avaient automatisé leur threat modeling avec un genre de risk assessment automatique sur lequel les équipes, à chaque développement de feature, allaient mettre quels étaient les nouveaux changements, etc. Et ça leur donnait une analyse de risque automatisée. C'était Slack qui avait publié ça. Mais ça reste, comparé à d'autres étapes de développement où on va pouvoir automatiser de façon plus fluide, ça reste quand même assez compliqué à automatiser au niveau du traitement des limites. Le design, c'est aussi là où on va devoir se poser des questions du type, quels sont les contrôles d'authentification que je vais mettre en place? Quelles sont les permissions?

30:21 Est-ce qu'il y a différents rôles? Comment je m'assure que cette fonctionnalité, elle est accédée que par ceux qui ont le droit d'y accéder? Et donc, si on commence une API depuis le début, il va falloir mettre en place ces contrôles d'authentification-là. En général, dans une entreprise, C'est déjà des briques qui existent, donc il faut s'assurer qu'elles soient bien intégrées. Et puis, est-ce qu'il y a des third parties à intégrer? Est-ce qu'on va utiliser l'API d'un third party? Auquel cas, on va se poser la question de comment est-ce qu'on s'assure qu'il n'y a pas d'abus possible de cette API. Notamment, il y a des API de... De vendeurs qui sont payantes, et donc il y a des modèles de licences au volume de requêtes, comment est-ce qu'on s'assure qu'il n'y a personne qui peut utiliser ça pour aller requêter à notre place les vendeurs, et donc ça serait potentiellement une perte financière sèche pour l'entreprise. Donc toutes ces questions-là, il faut vraiment se les poser dès la phase de design, pour être sûr que les contrôles sont intégrés dans le code. On reviendra potentiellement, Olivier, est-ce que ces contrôles-là qui doivent être pensés au niveau du design, est-ce qu'on peut...

31:30 vérifier qu'ils sont bien en place au niveau du Edge ? Oui, alors tu me tends un peu la perche, mais oui, on peut le vérifier au niveau Edge, parce que soit tu arrives à trouver des critères qui permettent d'identifier un partenaire, par exemple payant, comme tu disais, qui peut consommer jusqu'à 500 000 appels par jour de l'API. À ce moment-là, si tu arrives à trouver les bons critères, tu peux au moins observer que la limite est bien respectée, éventuellement renforcer la limite, je ne trouve pas le bon terme en français, mais ça doit parler à tout le monde, renforcer le point. Et puis après, si jamais on n'arrive pas forcément à trouver un critère qui identifie le partenaire, évidemment, on peut utiliser soit un peu d'inspection de trafic pour regarder la clé d'API, Ce n'est peut-être pas la bonne méthode. Ou alors, on peut utiliser une authentification un petit peu plus forte. Je pensais à des mécanismes de type MTLS, par exemple, donc authentification mutuelle TLS.

32:33 Ça peut être un moyen, pour le coup, d'authentifier de façon très forte un partenaire et puis aussi de gérer très facilement la révocation d'un certificat. Si un partenaire se présente ou des devices IoT se présentent avec des certificats qui ont été révoqués, c'est quelque chose qui est assez simple à bloquer avant que ça n'impacte l'Endpoint API. Dernier point, on peut aussi gérer des authentifications sur les API avec des tokens Jolt. Alors, ça ne se prononce pas du tout comme ça s'écrit. du JWT, du JSON Web Token, les spécialistes prononcent ça JOLT, enfin les anglais en tous les cas, les anglophones, donc on peut aussi utiliser ces mécanismes de protection d'API en imposant un token et puis en vérifiant ce token à l'edge, ce que j'appelle edge, c'est avant que ça n'arrive sur l'API endpoint, donc essayer de soulager l'API endpoint, pour le dédier à ce qu'il sait bien faire, servir des API, router des API, ne pas avoir à gérer le surplus de trafic, les attaques volumétriques des DOS, etc.

33:36 Merci, je pense que ça répond totalement à ma question. Et en fait, je pense que c'est vraiment important que les questions qu'on se pose en phase de design, qu'on s'assure qu'il y ait des contrôles techniques derrière pour s'assurer que les équipes aient effectivement implémenté ces contrôles. Alors, idéalement, il vaut mieux, si ce n'est pas le cas, il vaut mieux s'en rendre compte avant la mise en production. Mais quand on opère à l'échelle, en fait, avec des centaines d'équipes de service, on ne peut pas maîtriser de bout en bout parfois toute l'implémentation. Donc, c'est important d'avoir une automatisation à tous les niveaux. Et donc, si on peut utiliser... La défense d'Edge pour pouvoir vérifier que tout est en place, c'est optimal. Pour continuer sur le lifecycle, le cycle de vie d'une API, on passe ensuite sur le développement. Et là, ça va être également très classique. On est sur du développement sécurisé. On prend en compte évidemment toutes les recommandations de l'OASP pour éviter tout ce qui est validation des entrées, etc. Et puis, c'est là aussi qu'on va pouvoir vérifier qu'on utilise des tendances qui sont bien à jour, etc.

34:46 En termes d'automatisation de la sécurité dans les développements, Là, ce qu'on voit arriver, évidemment, c'est tout ce qui est code généré par un ségeance artificielle. Il y a des... Il y a des nouvelles problématiques qui arrivent avec ça. C'est notamment que ces intelligences se basent sur des bases de données de code qui existent déjà. Donc, votre niveau de sécurité du code généré va dépendre beaucoup du niveau de sécurité du code qui a été ingéré pour éduquer l'intelligence artificielle. Si vous utilisez des outils comme Copilot, etc., ce n'est pas ça qui va garantir que vous avez un code sécurisé. Donc attention là-dessus. Et ensuite, on passe sur la phase de déploiement et c'est là où on va pouvoir automatiser certains contrôles, notamment en rajoutant des étapes de scan. Donc ça peut être des scans de code pour aller vérifier que des entrées sont validées, etc. Des scans de dépendance. Pour vérifier qu'aucune des dépendances utilisées par le code ne contient de vulnérabilité publique.

35:51 Et tous les types de scans qui existent à l'heure actuelle, il y a même des scans dynamiques, et il peut y avoir des scans de qualité aussi qui peuvent se mettre en place à ce moment-là. Donc en termes d'automatisation, on est plutôt sur des étapes ajoutées dans le plan de delivery. Et enfin, on arrive sur les opérations. Et alors, opération, c'est le run un peu. Donc là, on a effectivement la protection principale au niveau du run, ça va être les protections de... d'edge en fait, qui vont prendre en compte Tout ce qui est, on en a déjà pas mal parlé, WAF, DDoS, anti-DDoS, Right Limiting, Quelque chose dont on a un peu moins parlé, c'est tout ce qui est protection contre la fraude. Et Olivier, peut-être que tu peux nous toucher dessus. Protection contre la fraude, on va par exemple utiliser différents mécanismes.

36:51 Ça peut être tout simplement regarder si, par exemple, si je prends une API qui permet à un utilisateur de se loguer sur un site web, mais très souvent il y a un formulaire et qui ensuite... Enfin, formulaire. Si il y a un formulaire, qu'il soit dans une application mobile ou une application web, on voit un petit formulaire et très souvent le code sous-jacent repart en JSON vers une API. Du coup, ça fait sens d'avoir des vérifications, par exemple, d'identifiant fuité. Ça peut faire partie des mécanismes qui peuvent être appliqués sur des API. Par exemple, regardez si le login mot de passe qui a été passé par un utilisateur est connu pour avoir fuité sur Internet. Ce n'est peut-être pas forcément pertinent de regarder si le login a fuité sur Internet, parce que le mien, par exemple, a fuité de nombreuses fois via tous les data leaks passés. En revanche, ce qui est intéressant, c'est vraiment de voir le couple login mot de passe. Comme on voit passer le mot de passe, j'ai envie de dire en déchiffrant le trafic, HTTPS, on est capable de regarder si ce login et ce mot de passe ont fuité récemment.

37:53 Donc ça, ça peut être un des mécanismes pour se protéger contre la fraude. Et puis après, on retrouve d'autres mécanismes. soit basé sur du rate limiting, soit de la détection de trafic automatisé, et comme le disait Camille tout à l'heure, qui s'appuie à la fois sur des mécanismes de signature, et puis aussi des mécanismes de machine learning. On ne sait pas ce qu'on ne sait pas, mais un moteur de machine learning, justement, son rôle, c'est de pouvoir sortir un espèce de poids ou d'indicateur pour savoir si un trafic ressemble à du trafic automatisé ou pas. C'est vraiment de tout traiter, de ne surtout pas se poser de questions. 100% du trafic doit passer par les mailles, par les tamis d'une protection à l'aide, que ce soit WAF ou autre chose. L'idée, c'est vraiment d'analyser tout le trafic et puis ensuite de pouvoir noter ce trafic avec un certain score d'automatisation et puis prendre une décision sur l'ensemble de ces critères. Les critères, j'ai envie de dire, statiques de la requête HTTP, puis aussi les critères dynamiques.

38:56 Quel est son score d'automatisation? Est-ce que ça ressemble à un bot? Est-ce que la réputation de l'IP a mauvaise réputation? Il y a pas mal de mécanismes qui permettent de se protéger contre la fraude, qui marchent aussi pour les API. Je te repasse la balle. Excellent. Excellent. Permettez-moi de résumer pour nos participants et en même temps pour essayer de condenser tout ce qui vient de se dire. C'était extrêmement intéressant. Je vais essayer de résumer sous votre contrôle. Donc les protections Edge, c'est ce que l'on... on va trouver à la bordure du périmètre de nos applicatifs. Donc, notre organisation, elle va être protégée, par exemple, par une protection Edge chez Cloudflare. Parmi ces protections, on va trouver essentiellement de l'anti-dénit de service et de l'anti- attaque applicative, ce qu'on va appeler l'anti-DDoS ou l'anti-DOS, et le WAF, Web Application Firewall.

39:59 Ce que vous avez en ce moment, suite mentionné qui est très intéressant, c'est Camille, tu as parlé de Security by Design, c'est-à-dire qu'en complémentarité de ces protections à la bordure, on veut s'assurer aussi que le cœur du réacteur soit proprement designé et proprement développé. Et avec le Security by Design, tu as notamment mentionné un petit peu les limites, mais en même temps l'importance. Donc les limites notamment, c'est l'effort cognitif qu'il faut réaliser. Et peut-être avec l'intelligence artificielle, aujourd'hui, on pourrait réussir à automatiser du threat modeling pour identifier les menaces et trouver les bonnes mesures. Peut-être qu'il y a aussi, alors dans le threat modeling, il y a cette vocation aussi à nourrir. Tous les playbooks qui vont être intégrés dans le Edge, notamment, Olivier, tu as parlé de fraud detection, etc. Tu es rentré dans le détail et en détectant, en identifiant déjà les menaces, dans le design, on pourra nourrir des playbooks, des règles, des rule sets qui vont être déployés sur ces protections WAF, par exemple.

41:10 Et donc, c'est assez complet finalement. Vous avez fait le tour, vous êtes parti de la bordure, vous avez parlé en même temps du cœur. Il y a aussi un point que j'ai soulevé intéressant, c'est concernant les FinOps pour Financial Operation. Et donc, c'est le fait typiquement d'aller... pas mais un appel, une requête chez un prestataire et que ça va nous coûter une somme importante. La plus connue, c'est concernant tous les endpoints liés au SMS. Donc, si vous pouvez envoyer un million de SMS juste inutilement, bien sûr, parce que la personne, elle a juste lancé un déni de service sur cet endpoint. Donc, ça va tout de même générer une facture chez le prestataire. Et voilà. Et vous avez aussi parlé... Je pense que j'ai fait le tour. Je pense que là, j'ai résumé à peu près... J'ai essayé de résumer en tout cas ce que vous avez mentionné. Je pense qu'il y a juste un tout dernier point qui a tendance à souvent être oublié, donc jusqu'à ce qu'on prenne le temps de le mentionner, c'est vraiment la décommission des API, la fin de vie.

42:21 Parce qu'en fait, ce qu'on a tendance à voir, c'est vraiment les API qui restent vivantes et que tout le monde oublie. Et qui sont derrière les portes d'entrée idéales, puisqu'en termes de maintenance, update, etc., ça devient des maillons faibles. Donc, Olivier, là, tu as peut-être aussi une solution? Je suis d'accord avec toi, et c'est vraiment le retour qu'on voit de beaucoup de clients, qui veulent se protéger ou qui veulent comprendre s'il y a du shadow API. Soit du temporaire qui dure, une API qui aurait dû éteindre et qui n'a pas été décommissionnée, comme tu le disais tout à l'heure, ou alors ça peut être au contraire des... API de développement, mais qui sont publiées sur Internet, une V3, une V4, une V5, etc., juste pour tester un truc. Mais ça peut ouvrir potentiellement une faille. Et là, l'idée, c'est... Là non plus, c'est bien d'avoir des mécanismes très simples et très bêtes. C'est-à-dire, en permanence, on regarde les flux qui passent, Et puis si on découvre des nouveaux endpoints, par exemple une V4 sur api.société.com, on le découvre et on le signale dans une interface de configuration.

43:29 On dit tiens, attention, il y a probablement une V4 qui a été publiée ici, alors que jusque-là on était à la V2. Est-ce que c'est normal ou pas? Et puis du coup, on continue, comme d'habitude, d'analyser ce trafic, de le protéger contre les... Contre les dédosses, etc. C'est le cercle. Est-ce que vous pouvez préciser la différence entre ce qui est le décommissionnement et le deprecated? Par exemple, Camille, dans l'exemple au tout début, on a vu une variable et il y avait écrit deprecated. Mais j'imagine qu'en fait, c'est une transition vers un décommissionnement. Alors, je ne pensais pas que ça passerait d'une personne, mais en fait, c'est parce que mon screenshot vient d'une version précédente. Et donc, effectivement, c'est une version qui n'est plus utilisée. Alors, elle n'est pas pour autant décommissionnée. En fait, elle est plus recommandée comme étant celle à utiliser pour de nouveaux développements. Le fait est que chez Blablacar, notamment, on va supporter une base très large de versions mobiles Android. Et donc, parfois, c'est...

44:30 Ces utilisateurs ont des téléphones qui sont anciens et ne peuvent pas avoir un cycle de mise à jour de leurs applications qui est nécessairement à jour. Et donc, en fait, c'est des versions qui sont encore... Elles sont encore vivantes, mais elles sont encore maintenues en termes de updates, de dépendance, etc. Mais elles ne sont plus conseillées. Oui, c'est ça. Donc, elles ne sont pas encore totalement décommissionnées, mais elles sont présentes. Et on invite... les utilisateurs à migrer. Du coup, c'est pour peut-être laisser le temps de migrer aussi les utilisateurs. Oui, parce que c'est notamment sur le mobile où on ne peut pas forcément forcer les updates, où en fait on peut le faire rarement et ce n'est pas une expérience utilisateur très agréable. Donc, c'est vrai que ça prend du temps de migrer vers des versions fluentes. D'où le fait de monitorer et de s'assurer de faire ce décommissionnement et pour le coup avoir un bon monitoring, j'imagine.

45:34 Peut-être que ça permet d'identifier ces anciens endpoints qui, suite à une promesse de décommissionnement, restent encore en production. Et c'est ça qu'on appelle le shadow API. C'est... Quel est... L'espace, c'est le... D'accord. Oui, oui, c'est vraiment... Le chef de l'API. Vas-y, vas-y. C'est tout simplement une API qui est publiée sur Internet. J'invente l'indéfinition en live. Mais pour moi, c'est une API qui est probablement publiée sur Internet. Sinon, elle n'est pas spécialement attaquable. Je simplifie un peu trop. Et c'est une API qui est publiée sur Internet sans l'aval ou sans l'approval de la sécurité. Donc, quelque part, ça peut être un point d'entrée d'attaquant. Bref, ça augmente la surface d'exposition sur Internet, probablement de façon inutile ou au moins de façon non contrôlée. C'est vraiment ça qu'on appelle une shadow API. Elle est dans l'ombre parce qu'elle n'est pas connue des services de sécurité. Un bon exemple pour ça, Olivier, c'est souvent lorsque les entreprises réalisent des hackathons ou des journées d'innovation avec plein de projets.

46:43 Et souvent, côté sécurité, c'est un peu compliqué de s'assurer que l'innovation ne prend pas le pas sur la sécurité. C'est là où potentiellement on va se retrouver avec des endpoints qui ont été mis en projection. Sans aval de la sécurité, et c'est bien d'avoir un peu une liste de ce qui est en cours. Et c'est là où, c'est bien non plus que la, enfin c'est exactement ce que tu disais, la sécurité ne soit pas un frein à l'innovation. Au moins, si l'API est publiée avec une nouvelle version, très bien, si l'edge, si les protections de sécurité ne sont pas au courant du schéma, ce n'est pas très grave, il ne faut pas qu'on empêche la publication d'une nouvelle API. En revanche, si dès le départ, on est certain qu'on a une protection déjà volumétrique, un peu de protection contre le brute force, c'est toujours ça de pris. C'est toujours bien. J'ai une question justement. Est-ce que les systèmes type Swagger ou OpenAPI, lorsqu'ils vont cartographier une API, est-ce qu'ils prennent en compte ce shadow API ou est-ce qu'il est en dehors de cette cartographie? De votre expérience.

47:46 Quand vous avez généré vos cartographies d'API, est-ce que le shadow API était inclus ou pas? Alors, c'est un bon point. En fait, il n'est pas inclus parce que justement, si tu as un modèle de sécurité positive, l'edge, la sécurité, sait ce qu'elle doit regarder. Le shadow API, justement, on ne sait pas ce qui est en dehors de ce schéma. L'idée, c'est de découvrir en permanence s'il y a des appels API qui sont effectués sur ces endpoints, mais qui sont différents de ceux du schéma de référence. Excellent, excellent. Est-ce que vous voulez encore aborder un sujet avant de passer aux questions? Et notamment, nous avons deux questions dans le chat. Peut-être juste un dernier mot sur la conformité qui était notamment mentionnée dans le titre. Globalement, le respect des standards... Tout au long, à la fois du cycle de développement et puis lors de la vie de l'API, du Hall Run, ça va permettre d'être compliant

48:54 aux réglementations, excusez-moi de mon anglais, donc de respecter les réglementations en vigueur, que ce soit des réglementations gouvernementales du style RGPD ou des réglementations contractuelles comme la PCI DSS, qui en général demandent un respect des standards de l'industrie en termes de sécurité. Donc, voilà. C'est le petit mot sur la conformité. Oui, c'est important. Et nous avons tous des anglicismes, mais c'est vrai que par rapport à la gouvernance, oui, c'est un point extrêmement important. Si je peux parler d'une expérience personnelle récemment suite à ça, c'est suite à un pentest et notamment une organisation qui est PCIDSS. Et on se rend compte que dans les API, parfois, il y a des données qui peuvent contredire un peu cette certification dans le sens où on peut avoir des non-conformités. Avec les données qui sortent en output de ces API.

49:55 Donc, c'est effectivement très important de rester attentif. aux données qui sont transmises. Très bien. Un dernier mot peut-être sur l'intelligence artificielle, sur une autre chose, une autre technologie ou autre. Peut-être l'avenir de la sécurité des API. Comment vous voyez les choses? Je peux commencer éventuellement. En ce moment, on peut difficilement parler d'avenir sans parler d'intelligence artificielle. L'intelligence artificielle, à mon sens, c'est quand même quelque chose qui est très utilisé dans les outils de sécurité, et ce, depuis quelques années maintenant. Ce n'est pas nécessairement nouveau, mais en tout cas, ça ouvre des portes à l'automatisation de la sécurité bien en amont. Puisque ce qu'on était capable de détecter, c'était plutôt des anomalies de comportement. Sur les requêtes, etc.

50:55 Maintenant, ce qu'on va être capable de faire potentiellement, c'est vraiment de générer du code qui soit vraiment sécurisé, d'enlever la charge. Pour le moment, le modèle qui est appliqué dans mon expérience, c'est vraiment d'essayer d'impliquer les développeurs pour qu'eux-mêmes soient très au courant de ce qui se fait en sécurité et puissent appliquer les principes de sécurité. En fait, à terme, est-ce qu'on ne peut pas espérer que les principes de sécurité soient vraiment appliqués presque de façon abstraite par rapport aux développeurs? Évidemment, il sera toujours nécessaire qu'ils aient une conscience de la sécurité, mais qu'ils aient moins besoin de vraiment avoir une expertise sur le secure coding, etc. et qu'ils puissent juste faire confiance à leurs outils pour pouvoir générer du code qui soit déjà sécurisé, pour pouvoir avoir du threat modeling qui soit automatisé. Ça, je pense qu'automatiser la sécurité plus en amont dans le cycle de développement, ce serait vachement intéressant comme futur. Tu en penses quoi Olivier? Et notamment, j'ai vu que Cloudflare a récemment aussi sorti une protection pour les large language models, LLM.

52:00 Donc ma question c'est, est-ce que plus tard les API ne seront pas juste du langage naturel? Est-ce que ça ne deviendra pas juste du langage naturel? Via des LLM ou autre? Tu suis bien l'actualité. Je pense que les machines vont toujours avoir besoin de comprendre quelque chose de standardisé. En revanche, tu as probablement une interface humaine qui est beaucoup plus digeste, qui peut être justement typiquement ce qu'on connaît avec les promptes, qui a été vraiment popularisé, voire lancé par ChatGPT il y a maintenant un an et demi, octobre 2022. Je pense que tu vas conserver une interface un peu agréable, mais en revanche, les données qui sont probablement renvoyées sur le endpoint de ChatGPT ou un autre, Mistral, etc., sont probablement quand même un langage qui est bien codé, un langage bien normé, j'ai envie de dire, ou bien borné. Après, oui, effectivement, il y a...

53:00 du coup, des protections supplémentaires à apporter, enfin des protections. Des inspections supplémentaires peut-être à apporter pour savoir si des employés ne vont pas exfiltrer les données à travers des promptes. Ça peut faire sens d'aller regarder un petit peu ce qui se passe sur les données envoyées à des services de LLM, notamment par le biais des promptes, est-ce qu'on est en train de donner trop d'informations. Même si, évidemment, ça ne concerne pas du tout l'entraînement des modèles, mais juste l'interrogation des modèles par le biais des promptes. Est-ce qu'on pourrait fuiter l'information? Probablement. Là, pour le coup, je n'ai pas de réponse complètement évidente. C'est vraiment un sujet qui est en cours de développement, mais en train d'apprendre en marchant. Très bien, très bien. Très instructif, très intéressant. Alors, on va bientôt être sur le mot de la fin. Avant ça, on a quelques minutes pour répondre à des questions.

54:04 Et nous avons notamment une question de Paul Jeannot qui demande comment techniquement comparer un password déchiffré avec ceux provenant de DataLeak. Oui. Alors, pardon. Non, non, j'ai essayé de répondre un peu en chat, parce que je ne sais pas si tous les participants peuvent rester jusqu'à la fin de la session, mais j'ai essayé de répondre sur cet aspect. C'est donc un service de vérification de... Fuite de login mot de passe, donc on vérifie en fait le couple login et le mot de passe, on ne peut pas vérifier l'un ou l'autre, c'est vraiment le couple. Après c'est vraiment un service qui est complètement automatisé, c'est-à-dire qu'un client ou un administrateur Cloudflare n'a pas accès à ces datas, c'est vraiment un service qui est rendu dans le seul fait d'aller regarder si ce couple identifié en mot de passe a fuité, pourquoi Je dis ça parce que j'anticipe la deuxième question de Paul, qui était est-ce que c'est respectueux de la RGPD ?

55:08 Alors, c'est là où j'atteins un peu mes limites, je ne suis pas juriste. Maintenant, oui, les services de ma société sont RGPD, et on a passé une certification spécifique qui s'appelle EU Cloud of Conduct, qui est assez sympa, puisque ça permet de certifier que ce qu'on annonce dans la RGPD et aussi dans le data processing ad hoc sont effectivement appliqués. Après, ma société adore les certifications, on a aussi passé les 27018, 27701, qui sont des certifications ISO, qui permettent aussi de mettre l'accent sur est-ce que votre règlement de sécurité respecte la RGPD. J'essaie de ne pas faire de réponse de normand et d'être assez précis, parce que le message, une des valeurs clés de Tech.Rocks, c'est no bullshit. Clairement, on peut déchiffrer ces données, c'est un peu le service de base d'un reverse proxy HTTPS, déchiffrer les datas, les inspecter pour voir si la donnée est légitime, le trafic est légitime ou pas. Merci Noémie.

56:10 Et du coup, oui, le service de vérification de leak, Encore une fois, je ne peux pas dire qu'on est compliant RGPD, parce qu'il n'y a pas de notion de compliant RGPD. En revanche, le service est RGPD, et le service de vérification n'opère que ce service-là à ses seules fins de vérification. Les infos ne sont ensuite évidemment pas loguées. Et puis évidemment, je rappelle que Cloudflare ne monétise pas les données des clients. Ça fait vraiment partie de la DPA. Ceux qui sont curieux d'aller voir la RGPD, c'est... Je lis la question de... Il y a une petite question supplémentaire de Philippe Bernery, en même temps, sur la sécurité de... De ce service de vérification des identifiants, en clair, a priori, ne leak pas. Alors, comment est-ce qu'on s'assure que la base de données de ma société ne leak pas? Là, j'ai envie de dire, ça va être... C'est une super bonne question. C'est intéressant.

57:12 Là, j'ai envie de dire, ça va être les contrôles de sécurité de Cloudflare qui font que rien ne doit liquider à l'extérieur. Je prends le point. Pour le coup, encore une fois, je ne suis pas juriste, donc j'atteins mes limites. J'ai beau être no bullshit, j'atteins mes limites aussi de compétence de juriste. Je vais regarder le point et puis je reviendrai sûrement sur le Slack, peut-être en parler de cette partie lead password et relations avec la partie RGPD. Je ne préfère pas dire n'importe quoi. Oui, c'est très touchy. Tous les services de type I have been pounded sont assez touchy niveau légal. Très bien. Alors, je crois qu'on est sur le mot de la fin. Donc, merci à tous. Merci à tous d'avoir écouté cette présentation. Merci pour votre présence. Merci à Camille, merci à Olivier, merci à Tech.Rocks pour avoir organisé tout cela et pour avoir partagé leur expertise.

58:19 Le point que je dois vous dire, c'est premièrement, un formulaire va être partagé dans le chat. C'est un formulaire de feedback. Vous pourrez directement proposer vos feedbacks et c'est l'équipe de Tech.Rocks qui sera heureuse de les recueillir. Et de plus, vous pouvez rester, c'est-à-dire que les échanges continuent dans les autres tables sur cette application remo.co. C'est-à-dire qu'en quittant la table, sans quitter tout l'événement, vous pourrez voir d'autres tables et rejoindre d'autres personnes. Donc normalement, ceux qui resteront, vous pourrez tout simplement continuer la discussion jusqu'à 13h45. Encore 45 minutes. Du coup, Toufik, je sais que tu gardes le mot de la fin, mais par exemple, j'ai vu une question sur les validations de schéma. Je l'adresserai sur une table? Oui, je pense que ça sera...

59:19 Plus judicieux, comme ça on garde, on respecte le temps prévu. Et la personne qui a posé cette question, je vous invite à rejoindre Olivier, et il se fera... Un plaisir de vous aider. Donc merci à tous et j'espère à très bientôt. Merci beaucoup. A tout de suite sur les tables.