À Rhapsodies Digital, on aime construire des solutions numériques (oui oui), et on s’est dit qu’on avait envie de partager dans le détail ce qu’on fait. C’est donc avec une série d’articles que l’on va soulever le capot, et présenter les détails techniques de nos travaux.
On va commencer par parler de notre projet Solertia (car il est tout frais, le MVP vient de sortir), de son archi, le back, le front, et de comment on a fait tout ça.
Solertia, projet visant à lister, catégoriser et présenter des entreprises au savoir-faire exceptionnel, est aussi notre premier vrai projet interne, imaginé et réalisé par une équipe très réduite, mais passionnée !
À première vue, le projet présente une architecture très classique, avec un socle API et base de données consommée par un front.
L’avantage, c’est que si, un jour, on a envie d’exposer et de monétiser nos données, c’est presque déjà fait (bon, moyennant un système d’authentification et de rate-limit bien évidemment…). Et ça tombe bien, car c’est également une des ambitions du projet.
Autre avantage, notre front n’étant qu’une couche de présentation, il ne fera pas d’écriture sur nos données, tout comme les clients potentiels de notre API, on peut donc, sans vergogne, couper en deux nos routes et ajouter une protection supplémentaire sur tout ce qui est POST/PUT et DELETE.
Notre API/Back, sera de plus un proxy pour récupérer et agréger de la data sur nos fameuses entreprises, avec notamment des connexions API avec Pappers (et d’autres sources de données qui arriveront par la suite).
C’est pour cela que le full monolithe (bien qu’avec beaucoup d’avantages, on le rappelle, utilisé par exemple chez Stackoverflow), n’a pas retenu mon attention ici.
Le choix de l’ennui : côté base de données
TL;DR : j’aime bien PGSQL.
Une de mes technos préférées, je dois l’admettre, est PostgreSQL. Robuste, ultra-performante, sécurisée et éprouvée, les nombreuses qualités de cette base de donnée relationnelle open source ne sont plus à présenter.
Son excellente gestion du JSON, avec bon nombre de fonctions et d’opérateurs prêts à l’emploi (on en parlera plus en détails sur la partie backend), peuvent permettre, par exemple, de créer des requêtes dont le résultat est directement mappables sur un DTO.
Concernant le volume de données, quelques milliers d’entreprises, il me paraissait overkill d’utiliser ElasticSearch pour l’instant (qui nécessite son serveur et donc sa maintenance — ou alors des solutions SaaS hors de prix (coucou Algolia/Melisearch)), sachant que PG dispose d’un excellent module de recherche fulltext.
Puisqu’on a évoqué un peu de NoSQL, je n’ai pas retenu cette solution non plus, car on a quand même pas mal de relations à gérer, et n’étant pas non plus un fana des micro-services (quand ce n’est pas nécessaire), je n’avais pas envie de m’embêter à ce niveau-là. PostgreSQL est mon choix rationnel, par défaut, quand je cherche une base de donnée.
Car oui, il faut le reconnaître, le NoSQL est sexy et a d’autres avantages, et match très bien quand on a moultes services qui ont leur propre système de stockage. Mais bien souvent, ce n’est qu’une question de préférence sur la modélisation, au final, on peut très bien faire du NoSQL sur PG.
Comment qu’on se cache
TL;DR : un jour oui, mais pas maintenant.
Actuellement, le projet ne dispose pas d’un système de cache applicatif, autre que ce que les technos choisies font nativement. Nous verrons après le lancement du projet, car on aime bien itérer et donc pour l’instant, on préfère avoir notre BDD en frontal de notre API.
Parce que oui, développer un système de cache, ce n’est pas auto-magique, il ne suffit pas d’installer l’excellent Redis et hop, c’est fait. Il y a du code à écrire, et pas mal de cas à gérer, ainsi qu’une dépendance et un serveur supplémentaire.
Parlons technos applicatives !
Le choix du compilé côté Backend
S’il y a bien une chose que j’ai comprise au cours de mes derniers projets, c’est que l’interprété, c’est pratique, mais c’est coûteux en performance et donc en serveur.
Côté API, il est absolument vital que les performances soient au RDV, car c’est notre backend, c’est ce qui va exposer nos données, et c’est ce qui sera le plus gros bottleneck de notre architecture.
Ce que j’aime bien avec les exécutables, c’est qu’après avoir target une plateforme, on a pratiquement besoin de rien sur le serveur pour le faire tourner, couplé avec supervisord par exemple, on peut également avoir rapidement un système simple, auto-gérable. Le choix de docker en prod est par ailleurs plus envisageable, il suffit d’une alpine vanilla et c’est parti.
Les choix évidents : Rust vs Go
Secrètement, cela fait des années que je me forme au langage Rust, que j’adore et dont j’admire le design. Gestion de la mémoire fine sans garbage collector, syntaxe élégante, typage strict, friendly compilateur, zero-cost abstractions et performances proches du C/C++.
Néanmoins, son gros (et peut-être seul ?) défaut reste son niveau d’adoption professionnelle. Bien qu’on dénombre de plus en plus de success story après un passage à du Rust (Discord, AWS, Kernel Linux, 1Password…), le nombre de développeurs est actuellement limité, et la gymnastique mentale nécessaire pour coder en Rust est importante.
Je suis convaincu que le jour où on sera plus nombreux, je pousserai fort pour que l’on puisse construire nos backend en Rust pour participer également à la popularisation de ce langage.
Surtout que tokio (les créateurs de l’async sur le langage), avance à grands pas avec son framework web ultra-performantaxum, qui je pense va tout éclater sur son passage. À l’heure où j’écris ces lignes, le projet est en v0.9.3.
Le vainqueur rationnel : Go
Et donc oui, spoiler alerte, le backend de Solertia est écrit en Go.
Rebuté par sa syntaxe dans un premier temps, loin d’être élégante, force est de constater que le langage est populaire. Certainement causé par la réécriture de pas mal de backend PHP/Nodejs/Java et avec un Google en back.
Il s’est rapidement imposé, comme un bon compromis simplicité d’utilisation/performances.
Bien qu’on s’écarte sensiblement des performances de Rust, il est sympa de voir que des calls API sont de l’ordre de la milliseconde, avec des appels BDD derrière de la transformation de data. Surtout une belle économie de CPU/RAM, juste parce qu’on utilise mieux les ressources et qu’on a besoin de peu de dépendances (genre curl en fait) sur le serveur.
Côté langage, Go est également typé strictement et se veut surtout une boîte à outils complète côté network. Et là oui, pour faire du web, c’est simple, nativement tout existe déjà dans le STD. De plus, sa gestion de la concurrence le rend très cool à utiliser.Côté librairies/framework, on est aussi très bien, avec bon nombre de choses qui existent (forcément, car le gros du truc est déjà présent dans le langage). Ici, on va juste teaser, en disant qu’on a un framework web (Gin), un semi-ORM un peu naze, mais pratique pour les migrations (Bun) et un truc génial pour auto-générer la documentation OpenAPI à partir de nos DTO d’entrée et de sortie (Huma).
NodeJS et Astro pour le front
Je vais vous l’avouer, je n’ai jamais été très grand partisan de NodeJS (étant plus côté PHP historiquement).
On peut néanmoins reconnaître que son extrême popularité a généré tout un tas de truc quand même bien cool comme Typescript et Astro, excellent framework web que l’on m’a fait découvrir très récemment (big-up à Renaud qui se reconnaitra s’il est dans les parages !). Et également, côté performance, il ne se défend pas si mal que ça. Le souci, c’est qu’on paie ça avec un nombre absolument dingue de dépendance nécessaire.
Mais l’histoire de ce choix est, en réalité, un peu plus complexe que ça.
Un truc que fait très bien Astro, c’est la génération d’un build statique (du pur HTML/CSS avec un très peu de javascript côté client). Et ça, pour le coup, j’aime bien, car ça me rappelle le côté exécutable, presque ennuyeux, prêt à l’hébergement sur un bucket (par exemple), avec 0 dépendances côté serveur et des performances forcément extraordinaires.
Le seul “soucis”, c’est que c’est complexe à mettre en place quand on a du contenu dynamique. On n’a ici pas des masses de choix :
Option A : On (re)génère des portions ou l’intégralité du site via des Hook et autre système automatisé dès que la data change.
Option B : On fait nos appels API côté client.
La deuxième solution ne me plait guère, car cela veut dire que si on veut implémenter un rate-limit pour protéger et monétiser notre API, les conséquences seront subies côté client (ou alors, on ajoute un BFF, mais ça nécessite une autre app et donc de la complexité), et qu’on va nécessairement perdre de la performance et donc l’intérêt d’un build statique.
Donc, je suis plutôt partisan ici de la première solution, sauf que c’est quand même assez compliqué à mettre en place, surtout qu’on a, en plus, un moteur de recherche à implémenter (oui, des solutions pour le build statique existent, mais on verra plus tard !).
Limités par le temps et les ressources de développement, on va donc la jouer interprété côté serveur, avec les technos qui permettent de générer un static, et on migrera vers cette solution par la suite, ça, c’est certain.
Et PHP alors ?
Croyez-moi bien qu’avec mes 8 ans d’xp en développement PHP/Symfony (et j’adore le langage depuis sa version 7), cette piste a été étudiée, finalement rejetée, car j’avais envie d’expérimenter d’autres choses, principalement pour ouvrir mes chakras (bien qu’elle fonctionne très bien !).
De plus, pour la génération de build statique (qui est, rappelons-le, notre cible idéale), on a des solutions qui sont, selon moi, bien moins éprouvées que côté NodeJS. Et de toute façon, on a de l’interactivité forte côté UI, donc on aura forcément besoin de JavaScript.
Le Backoffice
Ce qu’on a dit jusqu’à présent, c’est super, mais il faut quand même à un moment pouvoir administrer nos données, car ça ne se fait pas tout seul (dommage…).
Et bon, ouvrir un éditeur de base de données et faire les modifs comme ça, directement en prod, c’est bien nature, un peu trop à mon goût.
Le p’tit soucis, c’est que faire un back-office, c’est pénible car :
Peu de valeur quand il s’agit d’un CRUD classique (c’est notre cas).
Peu de valeur quand c’est en usage interne, on ne va pas le vendre ni le faire utiliser à d’autres personnes (c’est notre cas).
Les formulaires ajoutent toujours de la complexité, d’autant plus que ça prend du temps.
Oui, on a plein de générateurs de BO qui existent pour se simplifier la vie, mais cela reste une app et donc un truc à maintenir.
Si seulement il existait des solutions qui permettent de faire du drag & drop de composants, de gérer l’authentification et les droits des utilisateurs, de créer des formulaires en 4 clics, plug & play sur n’importe quelle API, ça serait vraiment cool pour notre use case !
Grâce à cet outil et à sa version gratuite, on a pu monter un BO en quelques jours, autour des endpoints d’écriture de notre API. Sa base est solide pour faire des formulaires et des listings simples, sur les résultats de notre API. On définit les endpoints, on map les champs sur les inputs et pouf, ça marche.
Après, il y a quand même des désavantages par rapport à un BO développé maison, certaines choses m’ont bien frustré, comme l’absence de gestion avancée des images par exemple, car le système ne propose qu’un bête input d’upload de fichier, exit donc les jolis croppers et les résolutions fixes en fonction du champ.
Une infra (plutôt) simple
Avant de terminer cet (long) article, j’aimerais tout même partager quelques mots sur l’infra choisie pour l’hébergement du projet.
Étant très sensible à la philosophie Dev Ops, mais avec des connaissances limitées en Infra as Code (IAC) et en administration réseau, j’avais tout même envie d’un environnement propre avec, surtout, de la facilité au niveau du déploiement. L’IAC puisqu’on en parle, est, selon moi, l’un des aspects les plus importants à mettre en place, parce qu’elle constitue une description exhaustive de ce qui est online.
Côté hébergement, cela fait maintenant quelques années également que j’évolue dans des environnements “cloud”, où l’approche budgétaire et la grande flexibilité sous-jacente permettent d’appliquer l’agilité et l’itération plus facilement au domaine du système, notamment encore fois, lorsque les forces vives sont réduites. Il était donc naturel pour moi d’implémenter ces outils pour Solertia.
Le Cloud de Scaleway
Etant plutôt à l’aise avec les services d’AWS, j’ai également voulu innover, et de tester les services de Scaleway, qui est européen par nature.
On retrouve tout ce qu’il faut pour construire ce que l’on désire ici :
Containers “serverless” pour pousser des images docker en prod, sans s’embêter avec Kubernetes (quelques défauts néanmoins, comme un manque de flexibilité sur les paramètres de l’autoscaller, et des healthcheck abstraits).
Containers registry et Bucket (compatible API AWS S3!) pour sauvegarder nos artifacts, backends terraform et par ailleurs assets statiques comme les images.
Base de données managée PGSQL (uniquement en v15 malheureusement, alors que la 16 est dispo depuis presque un an).
SDK terraform plutôt bien documenté, qui m’a permis, en ma qualité de gros n00b de cette techno, de faire mon IAC de façon plutôt fluide.
Monitoring natif sur Grafana, plutôt fourni.
Comme décrit plus haut, j’aime itérer et faire vivre l’architecture, ici, on ne présente que ce qui propulsera le MVP. Il est possible que cela change dans le futur (pourquoi s’en priver ? c’est un des aspects sympa qu’offre le cloud).
Docker couplé avec une CI/CD chez Gitlab
Bon c’est super tout ça, mais je n’aime pas spécialement l’idée de construire mes images docker sur mon poste et de les mettre en prod via la console UI de Scaleway.
Fort heureusement, nous utilisons Gitlab, qui avec sa puissante et beginner-friendly CI/CD m’a permis de mettre en place, pour les deux projets :
La chaîne de lint, test et build
La partie déploiement avec upload de l’image sur le registry, modification du projet terraform avec nouvelle version, apply et migrations, base de données (uniquement côté API).
Le cycle quant à lui est honteusement simple : À chaque nouvelle branche, la CI nous dit si c’est bien (ou pas, très objective qu’elle est), et à chaque nouveau tag sur main, ça déploie.
La full picture
Pour conclure, ce qu’il va falloir améliorer
Voici une mini-liste non exhaustive de ce que j’ai mal/pas fait, et que j’aimerais donc pousser par la suite :
L’auto-scalling et healthcheck côté containers, trop obscure actuellement.
Le cache, mais on en a déjà parlé.
Instant T-Shirt XXL : Faire un build statique pour le front, et donc enlever un serveur traditionnel.
Merci de m’avoir lu !
Écrit par Antoine Belluard – Responsable technique chez Rhapsodies Digital, j’ai une dizaine d’années d’expérience dans le développement informatique. Passionné par la programmation et la technologie, et poussé par un fort impostor-syndrome, je suis en apprentissage continu.
API & SECURITE – Du SI au RSSI
API & SECURITE - Du SI au RSSI
29 octobre 2024
Architecture
Thomas Jardinet
Manager Architecture
Cet article a eu en primo-inspiration mon sentiment qu’IT et Cyber travaillent malheureusement de manière trop souvent silotées. Avec des contraintes de sécurité souvent mal abordées ou insuffisamment partagées. Inspiration également au travers de rencontres de personnes travaillant dans le Cyber, qui peut-être se reconnaîtront.
En effet, la sécurité des API, côté IT, est souvent perçue comme un sujet couvert à partir du moment ou l’on gère bien l’authentification, les droits, et qu’on utilise une API Gateway. Oui bien sûr cela est nécessaire. Mais penser sécurité des API, au regard de ce que ce sujet implique, c’est penser un gros pan de la sécurité de son SI.
Ne venant pas du monde du Cyber, cet article n’aura comme seule prétention d’essayer de se faire rencontrer ces deux mondes. En abordant tous les aspects que la sécurité des API peut couvrir. Et évidemment, cet article est une invitation à vous rapprocher de vos équipes Cyber ! Et de vous fournir une liste de courses aussi synthétique que possible pour échanger entre équipes IT et Cyber. Mais un peu longue quand même. D’où le formalisme très concis choisi pour cet article.
Pour se faire, nous allons dans un premier temps expliciter les risques que nous identifions, pour ensuite aborder la sécurisation des API sur toute leur chaîne de valeur, du DevSecOps aux WAF d’API (WAAP pour Web Application and API Protection). Pour ensuite offrir un panorama de technologies, et enfin finir avec des préconisations. Sur ce, on y va !
Pourquoi la sécurité des API est-elle cruciale ?
Les données exposées sont très souvent sensibles : Les API renvoient souvent des données confidentielles, rendant leur protection indispensable.
C’est un vecteur d’attaque privilégié : En tant que point d’entrée unique des données, les APIs sont des points d’attaque de choix.
Leur complexité est croissante : L’évolution des architectures (microservices, coud, service mesh, …) peut augmenter la surface d’attaque potentielle.
Les API doivent respecter le cadre réglementaire : RGPD, PCI DSS, PSD2, etc…, autant de réglementations qui exigent une exposition sécurisée des API.
Cela n’arrive qu’aux autres? Et bien non.
2019. Facebook. Fuite de données concernant 540 millions d’utilisateurs à cause de serveurs non sécurisés et accessibles via des API.
2018. Twitter. Une mauvaise gestion des autorisations d’accès a rendu disponibles les messages privés de certains utilisateurs.
Maintenant que ces enjeux sont rappelés, nous allons détailler les risques et solutions.
Source : StartUp Stock Photo, Pexels
I. Les risques majeurs liés à la sécurité des API
1.1 Vulnérabilités courantes des API
1.1.1 Injection de code
L’injection de code est l’une des menaces les plus connues, avec
L’injection SQL par exemple,
Mais aussi par commandes avec l’exemple pas si ancien de la faille Log4J.
1.1.2 Authentification et autorisation inadéquates
Il est primordial d’avoir une politique d’authentification et d’autorisation bien appliquée afin de bloquer au mieux les attaquants. On peut retenir comme principes :
Les sessions doivent être bien gérées : Sessions non expirées ou mal révoquées.
Les tokens d’accès doivent être bien sécurisés : Stockage ou transmission non sécurisée des tokens.
Les contrôles d’accès doivent être bien configurés: Permissions mal configurées permettant des accès non autorisés.
1.1.3 Exposition de données sensibles
Les API peuvent involontairement exposer des données sensibles et inutiles si elles ne sont pas correctement définies, configurées ou sécurisées. Les cas typiques sont :
Les réponses API sont trop verbeuses : Inclusion de données non nécessaires dans les réponses.
Les réponses API ne sont pas chiffrées : Transmission de données en clair.
Les erreurs sont mal gérées : Messages d’erreur révélant des informations sensibles sur l’infrastructure.
1.2 Menaces émergentes et sophistiquées
1.2.1 Attaques par force brute et credential stuffing
Stratégie largement connue, consistant à tester des combinaisons de noms d’utilisateur et de mots de passe. Elles sont aussi simples à parer que particulièrement dangereuses car :
Elles peuvent être automatisées à grande échelle.
Elles peuvent aussi exploiter des informations d’identification provenant de fuites de données (évitez d’avoir un seul mot de passe…).
1.2.2 Attaques « Man-in-the-Middle » (MITM)
Une attaque MITM consiste à ce que l’attaquant se place entre le client et l’API Gateway pour intercepter ou modifier les échanges. Les risques incluent :
Le vol de données sensibles : En interceptant des données non chiffrées.
La manipulation de requêtes : En altérant des données échangées entre le client et le serveur.
L’usurpation d’identité : En récupérant les certificats serveurs pour se faire passer pour le serveur légitime.
1.2.3 Attaques DDoS
Ces attaques consistent à avoir un très grand nombre d’appels, afin de rendre indisponible l’API. Elles peuvent prendre plusieurs formes :
Les attaques volumétriques : En saturant la bande passante.
Les attaques au niveau applicatif : En utilisant des vulnérabilités de l’API pour épuiser les ressources du serveur.
Les attaques lentes : Cela consiste à maintenir des connexions ouvertes pour épuiser les ressources du serveur.
1.3 Risques spécifiques aux architectures modernes
1.3.1 Microservices et conteneurisation
La conteneurisation et les microservices ajoutent de nouveaux défis de sécurité :
La complexité exponentielle de la gestion des accès : On doit gérer les exigences de sécurité par microservice.
Les risques liés à l’orchestration des conteneurs : Les outils d’orchestration peuvent avoir aussi leurs propres vulnérabilités.
L’exposition accrue des API internes : Les API internes ne doivent absolument pas être exposées en externe !
1.3.2 API dans le cloud
Le déploiement d’API dans des environnements cloud présente des risques spécifiques :
La mauvaise configuration des services cloud : Exposition involontaire d’API ou de données.
La gestion des identités et des accès complexifiés : Il est nécessaire d’intégrer les mécanismes de sécurité de son cloud provider avec ceux de son API.
La dépendance vis-à-vis de la sécurité du fournisseur cloud : Il est nécessaire de comprendre et de compléter les mesures de sécurité, selon la politique de son cloud provider.
1.3.3 Shadow API et API zombies
Les « shadow API » (non documentées ou non gérées) et les « API zombies » (obsolètes mais toujours actives) représentent des risques significatifs :
Le manque de visibilité : Ce qui engendre des difficultés à identifier et à sécuriser ces API.
Les vulnérabilités non corrigées : Les API obsolètes peuvent contenir des failles de sécurité connues.
Les Accès non contrôlés : Il ya alors un risque d’exploitation par des attaquants sur des systèmes ou des données sensibles.
II. Stratégies et solutions pour sécuriser efficacement les API
2.1 Approche globale de la sécurité des API
2.1.1 Sécurisation de l’API via DevSecOps
L’approche DevSecOps permet de sécuriser une API en amont de son déploiement, via :
Le Shift-left security : Qui intègre les tests de sécurité dès le début.
L’automatisation des tests de sécurité : Grâce à des outils d’analyse de code statique (SAST) et dynamique (DAST).
La gestion continue des vulnérabilités : Code, librairies, dépendances, etc… Tous ces éléments peuvent faillir ou contenir des failles découvertes après coup. Il faut donc les détecter et les corriger.
2.1.2 Gouvernance et politiques de sécurité des API
Que serait-on sans gouvernance ? C’est évidemment un point primordial, sur lequel on sera particulièrement vigilant sur les aspects suivants :
La définition de standards de sécurité : Via documents de bonnes pratiques de développement et de déploiement d’API sécurisées.
La gestion des accès et des identités (IAM) : Pour couvrir la définition de politiques strictes pour l’authentification et l’autorisation.
Des audits réguliers : Afin d’évaluer de manière continue la conformité des API aux politiques de sécurité.
2.1.3 Formation et sensibilisation des équipes
La sécurité des API repose en grande partie sur les compétences et la vigilance de toutes les équipes, qu’elles soient devops, cyber ou dev :
Des programmes de formation : Via des sessions dédiées sur les pratiques de sécurité des API.
Des exercices pratiques : Via des simulations d’attaques et de réponses aux incidents.
Une culture de la sécurité : En encourageant à signaler et à résoudre les problèmes de sécurité.
2.2 Technologies et outils de sécurisation des API
2.2.1 API Gateways et Web Application and API Protection (WAAP)
Les API Gateways (et leurs cousins service mesh et micro-gateway) et les WAAP (WAF pour API, si vous préférez) représentent la première ligne de défense :
En filtrant du trafic : Via blocage des requêtes malveillantes.
En gérant les authentifications : En centralisant et en renforçant les mécanismes d’authentification.
En faisant du rate limiting : En protégeant contre les attaques DDoS.
Et en analysant le trafic : En détectant et en bloquant les comportements suspects.
2.2.2 Solutions de gestion et de protection des API
D’autres outils spécialisés existent, qui ont des fonctionnalités avancées pour la sécurité des API :
Solutions de découverte automatique des API : Afin de détecter les fameuses Shadow API.
Solutions d’analyse comportementale : Afin de détecter les anomalies et des comportements suspects.
Solutions de gestion des versions : Afin de contrôler et de sécuriser les différentes versions d’API.
Solutions de conformité réglementaire : Afin de démontrer la conformité aux règlements de sécurité.
2.2.3 Outils d’analyse de la sécurité des API
Des outils dédiées existent également pour déterminer des failles spécifiques aux API :
Les scanners de vulnérabilités spécifiques aux API : Comme son nom l’indique.
Les solutions de fuzzing d’API : Le fuzzing est une technique de test envoyant des données aléatoires et/ou malformées pour identifier les failles.
Outils d’analyse statique et dynamique : Il existe des SAST et DAST adaptés aux API.
2.3 Meilleures pratiques de sécurisation des API
2.3.1 Authentification et autorisation robustes
Via utilisation de protocoles standards : OAuth 2.0, OpenID Connect.
Via gestion fine des autorisations : Via implémentation du principe du moindre privilège, au travers des API scope.
Via rotation régulière des clés et tokens : Pour limiter l’impact en cas de compromission.
2.3.2 Centralisation et découpage des API Gateway
Une API Gateway est à placer idéalement de manière centrale dans son architecture pour ne pas multiplier les points d’entrée. On peut néanmoins avoir deux API Gateway, une “publique” et une autre “privée” afin de mitiger les risques au mieux :
Point d’entrée unique : Centralisation du trafic API pour une meilleure visibilité et un contrôle accru.
Gestion des versions : Facilitation de la gestion des différentes versions d’API.
Transformation et médiation : Adaptation des requêtes et des réponses pour assurer la compatibilité et la sécurité.
2.3.3 Chiffrement et protection des données
Chiffrement en transit : En utilisant systématiquement le TLS (dans une version non dépréciée). Possiblement aussi signer les données échangées, comme le peut faire Stripe avec son API afin de garantir leur authenticité, intégrité et non-répudiation.
Chiffrement des données sensibles : Que ce soit des données au repos ou en transit.
Gestion sécurisée des clés : En gérant les clés de chiffrement tout au long de leur cycle de vie. Il s’agit notamment de :
l’utilisation de clés solides, générées de manière aléatoire.
la rotation régulière des clés afin de limiter l’impact des violations potentielles.
stocker les clés en toute sécurité dans des “Vault”, séparément des données qu’elles protègent.
mettre en place des contrôles d’accès.
gérer les identités numériques via des certificats grâce à une PKI, couplé à
un HSM pour sécuriser des clés cryptographiques dans un environnement matériel.
2.3.4 Gestion des logs et audit
La journalisation : En enregistrant tous les événements liés à la sécurité.
La conservation des logs : En conservant les logs pendant une période suffisante pour permettre des analyses dans le passé.
L’analyse régulière des logs : En mettant en place des processus d’analyse régulière des logs.
La protection des logs : En empêchant toute modification non autorisée pour garantir leur intégrité en cas d’audit.
2.3.5 Surveillance en temps réel
L’analyse comportementale : Pour détecter les anomalies dans le trafic API.
Les alertes en temps réel : Pour réagir rapidement aux incidents de sécurité.
Le monitoring continu : Pour surveiller en permanence la disponibilité des API et détecter rapidement les attaques.
2.3.6 Tests de pénétration et validation de la sécurité
Des tests réguliers.
Des scénarios réalistes qui s’inspirent de cas réels.
Une validation continue via la chaîne CI/CD.
Conclusion
Comme on peut le voir, la sécurité des API demandent des compétences dans diverses équipes, mais également un engagement de tous. Des solutions informatiques existent, mais elles ne sont rien sans une politique de sécurité partagée à tous et pour tous. Et aussi et surtout l’établissement des bonnes pratiques définies en interne, comme nous l’avons partagées dans cet article.
Le design system qu’est ce que c’est, pourquoi l’adopter ?
Le design system qu’est ce que c’est, pourquoi l’adopter ?
23 octobre 2024
Rhapsodies Digital
Christophe Roselmac
Responsable design Rhapsodies Digital
L’adoption d’un design system est une décision qui nécessite une compréhension approfondie des besoins de l’entreprise et une communication efficiente avec la sa direction. Dans cet article nous allons apporter notre définition à ce qu’est un design system et les gains qu’il peut apporter à une stratégie globale.
Que suppose l’adoption d’un design system ?
Référence centrale pour tous les projets de conception, le design system est le langage commun entre les designers et les développeurs. Il permet de simplifier le travail des équipes tout en préservant une harmonie dans l’expérience utilisateur et une cohérence visuelle.
La mise en place d’un design system est avant tout un travail de compréhension des besoins, des enjeux et de communication entre les équipes.
La compréhension des besoins passe par une recherche approfondie pour analyser les spécificités des produits existants, identifier les problèmes de cohérence et mesurer l’impact sur l’expérience utilisateur.
L’évaluation des enjeux passe par une compréhension des contraintes budgétaires, des ressources disponibles ou encore de l’analyse de la concurrence afin de savoir à quoi nous faisons face. Cela permettra d’être certain qu’un design system est la solution appropriée à mettre en place.
Cette évaluation des enjeux doit être partagée avec la direction de l’entreprise en mettant en évidence les avantages potentiels qu’apporteront l’adoption d’un design system pour améliorer l’efficacité globale.
Des impacts concrets sur le ROI peuvent être mis en avant, comme l’économie des coûts de développement, de réduction du temps de mise sur le marché ou encore l’amélioration de l’expérience utilisateur et constituent autant d’arguments pour des décideurs quant à son adoption.
Le choix de mettre en place un design system est une décision stratégique, tout en étant un projet à part entière qui vit et évolue au rythme de la production de l’entreprise. Cette dernière peut réaliser des gains significatifs en termes d’efficacité et d’efficience des équipes grâce à la cohérence générale de l’organisation et des produits qui en découlent.
À quel moment se demander si un design system peut être utile ?
Chaque projet a ses particularités et suit des phases d’évolutions depuis sa création. Il peut exister plusieurs contextes spécifiques où il y a une nécessité d’établir des normes et des ressources pour la conception cohérente d’interfaces.
Les deux premiers moments clés où un design system devient pertinent sont lors de la croissance de l’entreprise et/ou de son produit et lors du constat de la répétition et de la redondance d’éléments de design.
En effet, la multiplication des types d’écrans et de pages lorsqu’un produit devient plus complexe peut être facilité grâce à un design system aidant à maintenir la cohérence visuelle et fonctionnelle.
L’augmentation de l’équipe de conception peut également initier la mise en place d’un design system, concentré sur des directives claires et des composants standardisés facilitant l’intégration de nouvelles personnes rejoignant l’équipe.
La répétition et la redondance peuvent être drastiquement réduites grâce à la centralisation d’éléments dans un design system. Il sera important de consacrer du temps à sa mise en place, quand on constate que les mêmes design sont recréés dans différentes sections d’un produit ou différents projets.
Enfin, si différents membres de l’équipe produisent des design qui ne sont pas uniformes, un design system permettra d’harmoniser les styles et les éléments.
Les autres moments importants ou un design system devient indispensable sont lors de phases d’évolution importante de l’entreprise et/ou son produit, voici quelques exemples :
La migration technologique : lorsqu’un produit évolue vers un nouveau produit ou un nouveau framework, un design system à toute sa pertinence pour aider l’intégration des nouveaux composants tout en maintenant la cohérence. Cela va de paire avec de nouvelles normes de conception fournissant une base pour appliquer ces changements de manière uniforme à travers le produit.
Améliorer la collaboration : dans les environnements de travail avec des équipes interfonctionnelles ou dispersées géographiquement ou encore suite à l’intégration de nouvelles équipes suite à une acquisition, un design system fournit un langage commun, des ressources partagées et facilite la standardisation et une meilleure collaboration.
Optimiser les process de conception et développement : une documentation centrale pour la formation et la conformité avec les standards de conception issus d’un design system permet de réduire des temps de développements des nouveaux composants et style en réutilisant les éléments existants.
Vous l’aurez compris, le design system est un outil puissant et devient incontournable lorsqu’une organisation nécessite une approche systématique pour maintenir la cohérence, améliorer l’efficacité et faciliter la collaboration entre différentes équipes. Le design system devient particulièrement pertinent lorsque les défis de cohérence et de gestion de l’interface et de l’expérience nécessitent une solution structurée.
DATA Lakehouse – Exploration d’une Architecture de plateforme de données innovante
DATA Lakehouse - Exploration d'une Architecture de plateforme de données innovante
22 octobre 2024
Architecture
Mohammed Bouchta
Consultant Senior Architecture
Après avoir introduit les concepts fondamentaux d’un lakehouse dans notre précédent article, plongeons maintenant dans les détails qui font du lakehouse une solution d’architecture alignée sur les principes d’une modern data plateform.
Nous allons explorer son fonctionnement interne et les technologies clés qui le soutiennent.
Source : Pexels – Tima Miroshnichenko
Fonctionnement d’un Lakehouse
L’architecture lakehouse représente une évolution significative dans le traitement et la gestion des données, cherchant à harmoniser les capacités de stockage d’un datalake avec les fonctionnalités analytiques et transactionnelles avancées d’un data warehouse. Cette convergence vise à créer une plateforme flexible, capable de gérer à la fois l’analyse de données historiques et les opérations transactionnelles, sans faire de compromis sur la performance, la sécurité, ou la qualité des données.
Rôle des métadonnées
Au cœur de cette innovation, l’usage stratégique des métadonnées joue un rôle prépondérant, orchestrant avec la gestion des schémas de données et leur évolution.
Les métadonnées, dans l’écosystème lakehouse, ne se limitent pas à la gouvernance et à la qualité des données, bien que ces aspects soient importants, notamment pour soutenir des transactions fiables. Elles permettent également d’indexer de manière efficiente les données susceptibles d’être requises, facilitant ainsi leur accès et leur analyse.
Cette architecture assure que, même au sein d’un stockage de données bruts et diversifiées, l’information pertinente peut être rapidement localisée et exploitée.
Système de stockage
Le lakehouse exploite les avantages économiques du stockage en DataLake, tel que le système de fichiers distribués HDFS ou les solutions de stockage objet dans le cloud, comme Amazon S3 et Azure Blob Storage. Ces plateformes de stockage, reconnues pour leur coût-efficacité, en grande partie grâce à la séparation du stockage et du calcul, sont complétées par une couche sémantique riche, pilotée par les métadonnées. Cette couche ne se contente pas de cataloguer les données; elle améliore aussi leur traitement et facilite leur accès, optimisant de ce fait l’efficacité générale de la plateforme.
Gestion transactionnelle des données
La fusion réussie de ces éléments au sein d’une architecture lakehouse repose sur l’intégration de principes transactionnels rigoureux, tels que l’atomicité, la cohérence, l’isolation, et la durabilité (ACID). Ces principes sont essentiels pour garantir la fiabilité et l’intégrité des données, permettant de s’appuyer sur le lakehouse pour des opérations critiques sans craindre de compromettre la qualité ou la sécurité des informations traitées.
Meilleure performance qu’un Datalake
Par ailleurs, pour ce qui est de l’amélioration des performances, le lakehouse intègre des mécanismes de mise en cache avancés. Ces systèmes sont conçus pour précharger en mémoire les données les plus sollicitées, accélérant ainsi significativement le temps d’accès et la réactivité de la plateforme.
Technologies Clés
La réalisation d’un lakehouse repose sur des technologies avancées qui permettent de surmonter les défis traditionnels posés par les datalakes et les data warehouses offrant une flexibilité, une fiabilité et des performances accrues pour la gestion et l’analyse des données à grande échelle.
Voici un aperçu de ces technologies clés :
Delta Lake
Delta Lake est une couche de stockage open source conçue pour apporter la gestion transactionnelle ACID aux datalakes. Cette technologie transforme un datalake en un système capable de gérer des opérations de lecture et d’écriture concurrentes, garantissant ainsi l’intégrité des données. Avec Delta Lake, les utilisateurs peuvent effectuer des mises à jour, des suppressions, des insertions, et même des merges (fusion de données) directement sur les données stockées dans un datalake, tout en maintenant un historique complet des modifications. Cela permet une gestion des données plus flexible et robuste, facilitant des cas d’utilisation comme le rollback pour corriger des erreurs ou auditer des modifications. De plus, Delta Lake optimise les requêtes en utilisant le « data skipping » (saut de données non pertinentes), améliorant ainsi la vitesse d’analyse des vastes ensembles de données.
Apache Hudi
Apache Hudi (Hadoop Upserts Deletes and Incrementals) est une autre technologie open source qui révolutionne la gestion des données dans les datalakes. Elle permet des mises à jour et des suppressions rapides, ainsi que des insertions et des requêtes incrémentielles sur de grands ensembles de données. Apache Hudi introduit le concept de « views » (vues) de données, permettant aux utilisateurs de voir des snapshots des données à un moment choisi ou des changements sur une période, rendant ainsi possible la gestion de versions et le time travel (navigation temporelle dans les données). Cette capacité à gérer des modifications de données de manière efficace rend Hudi particulièrement adapté aux environnements où les données changent fréquemment, supportant des cas d’utilisation tels que la capture de données modifiées (Change Data Capture, CDC) et les pipelines de données en temps réel.
Apache Iceberg
Apache Iceberg est un format de table open source qui vise à améliorer la gestion et les performances des requêtes dans les datalakes.
Iceberg traite de nombreux problèmes rencontrés avec les formats de fichiers traditionnels et les modèles de métadonnées dans les datalakes, tels que la complexité de gestion des schémas évoluant dans le temps ou les problèmes de performance des requêtes sur de grandes tables.
Avec Iceberg, les tables sont traitées comme des entités de première classe, supportant des fonctionnalités avancées telles que les schémas évolutifs, les partitions cachées, et les transactions atomiques.
Le format est conçu pour être agnostique au moteur de calcul, permettant ainsi son utilisation avec diverses plateformes d’analyse de données, telles que Spark, Trino et Flink.
Iceberg optimise également les performances des requêtes en utilisant un indexation fine des données, ce qui réduit le volume de données scannées lors des analyses.
Conclusion
En conclusion, le lakehouse émerge comme une solution hautement performante et flexible qui étend la portée et les capacités d’un datalake en combinant le stockage économique des datalakes avec les capacités d’analyse et de gestion transactionnelle des data warehouses, tout en exploitant intelligemment les métadonnées pour la gouvernance, l’indexation, et l’optimisation des accès sans pour autant éclipser le rôle stratégique que peut jouer un datahub dans l’écosystème global de gestion des données au sein du système d’information.
Datalake, Datawarehouse, Datalakehouse… Le métier de la donnée a le don pour créer des noms assez simples à associer au sujet, mais qui peuvent rapidement devenir confusants. Ce billet vise à vulgariser ces 3 concepts, afin de vous permettre de tenir le fil de la discussion lors de vos discussions avec les experts data.
Les patterns historiques
Le Datawarehouse (entrepôt de données) est un pattern de base de données décisionnelles, datant de la fin des années 80 : il agrège des données sélectionnées, mises en qualité, structurées, et historisées afin de permettre de les exploiter dans le cadre de cas d’usage « décisionnels ». Ces données ne sont pas altérables, ce qui garantit qu’un même traitement donnera le même résultat peu importe le nombre de fois et le moment où il sera réalisé. Ce cadre de stockage permet de faire croiser des données issues de systèmes applicatifs distincts, afin de « casser » les silos de données, et permettre une vision transversale de l’entreprise, tout en permettant de comparer différentes périodes. L’inconvénient du Datawarehouse est principalement son coût de stockage élevé, du fait de toutes les étapes de « travail » autour de la donnée.
Le Datalake (lac de données) s’est construit afin de répondre aux faiblesses du Datawarehouse : c’ est un espace de stockage, agrégeant des données (non structurées, semi structurées et structurées), sous leur forme brute (pas de traitement de normalisation / mise en qualité à l’ingestion). L’objectif de cette brique applicative est de proposer un stockage à bas coûts, permettant de mettre à disposition un vaste volume de données, de manière agnostique au regard de leur exploitation future. Ce volume de données permet de nourrir différents types de cas d’usage : alimentation de bases de données spécialisées (par exemple décisionnelles, comme un Datawarehouse), ou exploitation dans le cadre de traitements nécessitant un volume important de données mise à disposition (Data Science, Machine Learning, Intelligence Artificielle…). Il n’a cependant pas ambition à agréger toutes les données de l’entreprise, ou de les stocker n’importe comment, et c’est justement un problème qui a tendance à se développer avec le temps, en l’absence d’un cadre définissant la gouvernance des données, et la politique de rétention de ces dernières. Et là, le Datalake devient le Dataswamp…ce qui rend l’exploitation des données compliquée voir impossible, tout en faisant augmenter les coûts…
Le nouveau venu
Le Data Lakehouse (maison lac… ne cherchez pas de traduction littérale !) est une hybridation de ces 2 composants applicatifs, visant à proposer le meilleur des deux mondes, tout en couvrant l’ensemble des cas d’usages sus mentionnés. Comme le Datalake, il permet d’agréger différents types de données (structurées, semi structurées ou non structurées). Cependant, grâce à l’exploitation d’une couche de métadonnées permettant de faire le lien avec les différentes données agrégées, les transactions ACID (atomicité, cohérence, isolation et durabilité) deviennent possibles. De même, l’ingestion de données en temps réel (streaming) devient possible, ce qui permet de répondre à de nouveaux cas d’usage (pilotage à chaud, exploitation des données IoT). C’est un pattern permettant de conserver un stockage à moindre coût propre au Datalake, ainsi que la capacité d’analyse d’un Datawarehouse.
Dans un second article, nous allons faire un focus sur le Data Lakehouse, en soulevant le capot afin de mieux comprendre son fonctionnement.
Le NoCode Summit 2024 en a été la vitrine et s’est révélé fort intéressant par bien des aspects :
être dans l’ambiance, l’effervescence de cet écosystème qui innove très vite,
percevoir les solutions qui reviennent souvent dans les témoignages, identifier clairement les start-up, et les scale-up,
bénéficier de retours avisés de petits / grands comptes ayant d’ores et déjà adopté ces stacks en Production.
Si vous parlez de NoCode/LowCode…un vaccin des dernières tendances vous sera bénéfique.
NoCode, démarrant par une négation, n’est pas vendeur, braque les développeurs avec pour conséquence un frein à l’adoption de ces technologies…Alors même que le “NoCode” requiert des compétences fondamentales telles que la logique et l’algorithmie. Le “LowCode” quant à lui requiert parfois de coder concrètement pour couvrir le cas d’application souhaité.
Désormais, il conviendra de parler de :
Keyboard Programming – Développement traditionnel dans le langage qui vous plaira,
Visual Programming (ex NoCode / Low Code),
GenAI Programming.
Il s’agissait ici de la troisième édition du Summit, et une belle montée en maturité (Prod ready) des acteurs a été constatée, ne serait-ce que de part leur adoption par des Grands Comptes (ex : BRED, System U, BNPP, Docaposte, CDC, Europ Assistance, LCL, L’Oréal, BPI France) qui témoignent de retours d’expériences très positifs.
Vous constaterez sur les affichages de sponsoring du foisonnement de solutions. Nous assisterons avec quasi certitude à une consolidation de marché dans les années à venir car plusieurs solutions se concurrencent sur les mêmes positionnements, avec bien évidemment des particularités.
Voici un aperçu des différents positionnements constatés :
Solution de BDD avec UI/UX on top : AirTable, baserow
Solution de tests fonctionnels, techniques : MrSuricate
Solution pour développer des outils de productivité en interne (mini JIRA, mini CRM, …) : TimeTonic, DAMAaaS
Solution de monitoring : ncScale
…
Source : Kevin Ku – Pexels
Le choix de l’une ou l’autre des solutions doit se faire de façon éclairée avec une liste de critères / contraintes bien établie, dont voici un petit extrait :
Quels sont mes uses cases ?
Est-ce pour un usage interne ou pour du Customer Facing ?
Quels vont être les utilisateurs (IT ? Business ? Les deux ?) ?
Solution OpenSource ou propriétaire ?
Solution Française only ?
Hosting OnPrem ou Cloud ?
Respect des normes réglementaires ? sécurité ?
Quelle est la maturité et la pérennité de l’éditeur / la solution ?
Quelles sont les capacités de réversibilité ?
Quel est le niveau de couverture technico-fonctionnelle ?
Quel est l’effort pour se Up-Skill et l’utiliser ?
et sans oublier toutes les autres considérations: scalabilité, modèle financier, …
Des stacks commencent d’ores et déjà à se démarquer via les témoignages :
WeWeb en Front, cocorico, solution Française, génère du VueJS exportable,
Xano en Back-end truste le marché, le plus complet, le plus scalable, le plus sécurisé,
Make en orchestration API.
Se lancer dans l’aventure Visual Programming, c’est être conscient des problèmes que vous rencontrez et des bénéfices qu’ils peuvent vous apporter :
Réconcilier le Business et l’IT (Dev): enfin ils peuvent se comprendre de part l’aspect visuel et instantané du développement,
Être en Agilité par défaut,
Accélérer la phase de Build, tout en conservant ou en augmentant la qualité…
… et par conséquent améliorer le TimeToProd,
… et par conséquent diminuer les coûts projets,
Désengorger l’IT en décentralisant (gouvernance requise) certains projets dans les BU,
Redonner une bouffée d’oxygène au BUILD, qui se voit souvent écraser par le poids du RUN et de la gestion de l’obsolescence.
Le NoCode ne rime pas avec NoMethodology. Qu’il s’agisse d’une démarche tactique ou stratégique, il y a des clés de succès :
Associer les différents futurs profils utilisateurs au choix de la stack Visual Programming,
Les phases d’expression de besoin / cadrage / conception d’un projet en Visual Programming ne changent pas et une grande importance doit leur être accordée,
Une Gouvernance doit être définie en cohérence avec votre organisation (NoCode office centralisé? des référents dans les BU?),
Le Visual Programming ne permet pas de tout faire. Un cadre, un arbre d’éligibilité, des bonnes pratiques doivent être établis pour les utiliser à bon escient,
Think BIG, Act SMALL : démarrer petit, sur un scope favorable mais avec des points de douleurs identifiés et revendiqués. Démontrer le succès sur un premier scope attire les autres use cases et la quasi généralisation sur les périmètres éligibles,
Appliquer les mêmes bonnes pratiques que sur un projet de développement classique.
Toute rupture technologique, tout nouvel écosystème apporte avec lui son lot de freins et de réticences:
L’écosystème est assez jeune et la pérennité des solutions pose légitimement question,
Quid du fameux Vendor Lock-in et de la capacité de réversibilité. Pour les mitiger il faut être très mature et Responsable sur la phase de cadrage, conception, documentation de ce qui sera développé.
Le NoCode sacrifie-t-il la Sécurité ? Il faut s’assurer que la Sécurité n’est pas mise de côté et que la plateforme dispose des bonnes certifications (SOC2, ISO 27001, Hipaa, …) ainsi que des mécanismes maintenant bien connue sur la GRC (Governance, Risk, Compliance) de part le contrôle des accès, les permissions fines, les audits logs, la détection des incidents, …
Comment faire pour tester du NoCode quand les plateformes ne proposent pas intrinsèquement ces fonctionnalités ?
Les plateformes disposent-elles de mécanismes pour prévenir et éviter un Burn de facturation sur ce modèle très “as-a-service” ?
Actuellement, moins d’un pourcent de la population mondiale sait programmer. La démocratisation et l’accessibilité introduite par le Visual Programming a le bénéfice d’ouvrir la voie à toute une Diversité de personnes en quête de reconversion.
Mais … comme le souligne très justement Jean-Marc Jancovici également le net inconvénient et le risque majeur d’accentuer significativement une prolifération applicative avec des services digitaux futiles et inutiles. Sur notre planète à ressource finie, le numérique représente 4% des gaz à effet de serre (GES), cette débauche de moyens (énergétiques et intellectuels) sur ces sujets ne fait qu’accroître exponentiellement les usages digitaux… et leurs impacts.
Derrière mon clavier, je visual programme avec modération et sobriété. La consommation digitale excessive est dangereuse pour la planète, ceci est un message de Rhapsodies Conseil.
