La qualification SecNumCloud 3.2 de l’offre PREMI3NS de S3NS, fin 2025, a déclenché une vague de controverses dans le paysage IT.

Suffisamment pour que Vincent Strubel, le directeur général de l’ANSSI, prenne la plume pour publier une longue tribune sur LinkedIn. Un exercice de déminage pédagogique pour répondre aux  « interrogations voire (aux) incompréhensions sur ce que fait et ne fait pas la qualification SecNumCloud ».

« Ce n’est pas une médaille en chocolat »

Premier rappel du patron de l’agence nationale de cybersécurité : SecNumCloud n’est ni une décision arbitraire, ni un choix politique. La qualification découle d’un processus formalisé d’évaluation sur la base d’exigences strictes. « Les règles, le processus et le niveau d’exigence sont les mêmes pour tous », martèle Vincent Strubel.

La procédure ? Longue et exigeante. Près de 1 200 points de contrôle vérifiés in situ par un évaluateur indépendant, sous le regard scrutateur de l’ANSSI qui « ne se prive pas de demander parfois à l’évaluateur d’approfondir son travail ou de réévaluer de manière plus stricte ses conclusions ». Un référentiel actualisé constamment depuis plus de dix ans. « Bref, ce n’est pas une médaille en chocolat, et ce n’est pas pour tout le monde », résume le directeur.

Se protéger du CLOUD Act… et du « kill switch »

Les risques liés au droit extra-territorial ? C’est le sujet qui monopolise l’attention. Vincent Strubel rappelle l’enjeu : éviter que les données hébergées dans le cloud ne tombent sous le coup du CLOUD Act américain ou de la loi chinoise sur le renseignement de 2017, qui permettent aux autorités d’exiger l’accès aux données de clients européens.

La parade de SecNumCloud : un prestataire européen qui contrôle seul les données. Même si l’offre est « hybride » et repose sur une technologie américaine, « le fournisseur de la technologie cloud est soumis aux lois américaines, mais n’a pas accès aux données et ne peut par conséquent pas donner suite à une injonction », explique le patron de l’ANSSI.

Autre protection : le scénario du « kill switch », cette coupure brutale du service imposée à certains clients. Vincent Strubel cite l’exemple récent de magistrats de la Cour Pénale Internationale privés d’accès aux services numériques américains. Avec SecNumCloud, le sous-traitant non européen « ne dispose pas de la capacité à couper le service à tel ou tel client, car ce n’est pas lui qui administre la solution ».

L’autarcie complète, une illusion

Vincent Strubel le reconnaît sans détour : SecNumCloud ne signifie pas l’absence de dépendance. Une offre « hybride » est « sans doute plus exposée à ce risque, « mais imaginer qu’il existe des offres 100% européennes relève de la pure vue de l’esprit qui ne résiste pas à la confrontation aux faits ».

Tous les fournisseurs de cloud dépendent de composants électroniques et logiciels non maîtrisés à 100% en Europe. L’open source ? « Une plus grande liberté d’action », certes, mais « pas la panacée » : aucun acteur ne peut prétendre maîtriser entièrement toute la stack technologique du cloud.

« Si nous sommes un jour privés de l’accès à la technologie américaine, chinoise, ou plus généralement non européenne, nous aurons un problème global de dégradation du niveau de sécurité », prévient le directeur de l’ANSSI. Un problème qui dépasserait largement les seules offres hybrides.

Les cyberattaques, la vraie menace

Vincent Strubel le martèle : les critères liés à la nationalité du prestataire ne représentent
« qu’une petite partie des exigences » du référentiel. La vraie menace ? Les cyberattaques, qui demeurent « la menace la plus tangible pesant sur les usages sensibles du cloud ».

Les prestataires, « quelle que soit leur nationalité », sont des «cibles à très haute valeur ajoutée » qui « subissent en permanence des tentatives d’attaque, y compris particulièrement avancées, dont certaines réussissent forcément ». Hyperscalers américains comme acteurs européens, personne n’est épargné.

D’où des exigences techniques drastiques : cloisonnement fort entre clients, chaîne d’administration isolée, gestion sécurisée des mises à jour, chiffrement systématique. « Ces exigences ne sont généralement pas toutes satisfaites par une offre de cloud standard, quelle que soit son origine », note le directeur de l’ANSSI.

Le référentiel prend même en compte le risque humain : corruption, contrainte ou infiltration d’employés du prestataire. Un chapitre entier y est consacré.

« Souverain », mais pas baguette magique

SecNumCloud est-il un label de souveraineté ? Vincent Strubel botte en touche :  « Il est difficile de répondre à cette question, vu que le concept de souveraineté numérique n’est quasiment jamais défini, et que tout le monde lui donne un sens différent ».

Pour l’ANSSI, la souveraineté numérique couvre trois enjeux : ne pas être une victime facile des cyberattaques, faire appliquer nos règles plutôt que subir celles des autres, et disposer d’une liberté de choix technologique. SecNumCloud répond aux deux premiers et contribue au troisième.

« Les offres qualifiées SecNumCloud sont donc, sans le moindre doute, souveraines, et cette qualification est un levier indispensable pour défendre notre souveraineté numérique », affirme Vincent Strubel. Mais il avertit aussitôt : cette qualification « ne va pas faire naître des solutions alternatives ou des briques technologiques maîtrisées »».  « C’est un outil de cybersécurité, pas de politique industrielle. »

Hybride ou non, même combat

Le directeur de l’ANSSI tord le cou à une idée reçue : les offres « hybrides » qualifiées « satisfont exactement les mêmes exigences que les autres ». La distinction entre hybride et non-hybride ? « Assez artificielle », tranche-t-il. « Il n’y a pas d’un côté des offres totalement dépendantes de fournisseurs non européens et de l’autre des offres 100% européennes. »

Certains réclament un label light, reprenant uniquement les critères capitalistiques sans les exigences techniques. Vincent Strubel balaie l’idée : « Du point de vue de la cybersécurité, ça n’aurait aucun sens de couvrir uniquement certaines menaces, et pas d’autres.» Une solution doit couvrir tous les risques, « car les attaquants visent toujours le maillon faible ».

Son image choc : « Un cloud échappant au droit non européen, mais à la merci des cyberattaques, ça n’a pas plus de sens qu’une maison avec des volets blindés et des barreaux aux fenêtres, mais dont la porte serait fermée par un rideau.»

Même refus pour un label purement technique : impossible de couvrir les risques juridiques par la seule technique. Le chiffrement des données, par exemple, « ne protège pas du CLOUD Act : le prestataire de cloud a forcément, tôt ou tard, accès à la clé de chiffrement ».

Photo : © DR

The post Le patron de l’ANSSI sur SecNumCloud : « Pas une médaille en chocolat » appeared first on Silicon.fr.

Urgence pour le système de découverte de services : la capacité actuelle du plan de contrôle pourrait être épuisée à l’horizon 2025.

LinkedIn avait fait ce constat à l’été 2022. En conséquence, il avait lancé un chantier de modernisation.

Élasticité, compatibilité… Le plan de contrôle ZooKeeper arrivait à ses limites

Le plan de contrôle reposait alors sur ZooKeeper. Il avait une structure plate. Les applications serveur y enregistraient leurs points de terminaison en tant que nœuds éphémères, sous forme d’URI D2 (Dynamic Discovery). Les applications clientes lui adressaient des requêtes en lecture pour suivre les clusters qui les intéressaient.

Cette approche présentait des limites en termes d’élasticité. ZooKeeper étant un système à cohérence forte, toutes les lectures et les écritures, ainsi que les vérifications d’intégrité des nœuds, passaient par la même file d’attente. Les requêtes étaient donc susceptibles de s’accumuler jusqu’au moment où certaines ne pourraient plus être traitées. En parallèle, des sessions pourraient être fermées en cas de timeout sur la vérification d’intégrité. S’ensuivraient une perte de capacité côté serveur et, in fine, des indisponibilités d’applications.

Autre limite : les entités D2 étant liées à des schémas spécifiques à LinkedIn, elles étaient incompatibles avec des data planes modernes comme gRPC et Envoy. De plus, l’implémentation de la logique de lecture/écriture dans les conteneurs applicatifs était focalisée sur Java. Par ailleurs, l’absence d’une couche intermédiaire entre le registre de services et les instances applicatives empêchait de développer des techniques de gestion RPC centralisées, par exemple pour le load balancing.

Kafka côté serveur, gRPC côté client

Le nouveau plan de contrôle introduit des composantes Kafka et Observer.

Kafka réceptionne les requêtes en écriture des serveurs et les informations d’intégrité sous forme d’événements, appelés URI de découverte de services.

La brique Observer consomme ces URI et les conserve en mémoire. Les applications clientes s’y abonnent en ouvrant un flux gRPC. Elles envoient leurs requêtes via le protocole xDS.

Les configurations D2 restent stockées dans ZooKeeper. Elles sont converties en entités xDS par les propriétaires d’applications puis distribuées à l’« observateur » de la même manière que les URI.

Les readiness probes de Kubernetes en ligne de mire

Dans cette architecture, l’élasticité et la disponibilité ont la priorité sur la cohérence. L’observateur, écrit en Go avec une concurrence forte, peut gérer 40 000 flux clients et 10 000 mises à jour par seconde tout en consommant 11 000 événements Kafka par seconde, selon LinkedIn.

Pour gagner encore en élasticité, il serait possible, au-delà d’augmenter le nombre d’observateurs, d’en créer deux types. D’un côté, des instances consommant les événements Kafka. De l’autre, des instances répondant aux requêtes des clients.

Comme il utilise xDS, le plan de contrôle est compatible avec Envoy ; ce qui ouvre la porte à un support multilangage. Et avec l’introduction de cette couche intermédiaire, il devient possible d’intégrer des fonctionnalités autour des maillages de services. Voire d’exploiter les readiness probes de Kubernetes pour faire passer les serveurs en mode passif et ainsi fiabiliser le système.

La latence P50 amenée sous la seconde

Le déploiement a été compliqué par la variété des clients (dépendances, accès réseau, SSL…). Pour beaucoup, il était difficile de prévoir le niveau de compatibilité.

Il a de surcroît fallu mener le chantier parallèlement sur les lectures et sur les écritures. Dans les grandes lignes, sans les unes, la migration des autres était bloquée. L’infrastructure d’origine a donc été conservée, dans une approche dual mode, Kafka étant la source primaire et ZooKeeper le backup (utilisé en cas d’absence de données Kafka). Une tâche cron a permis de jauger le niveau de dépendance des applications à ZooKeeper et de prioriser les migrations en conséquence.

Pour les lectures, les principaux éléments évalués côté client furent le délai entre l’envoi d’une requête d’abonnement et la réception des données, les erreurs de résolution de ces requêtes, ainsi que la cohérence entre la data de ZooKeeper et celle de Kafka. Côté observateur, LinkedIn a examiné le type, le nombre et la capacité des connexions clients, le délai entre la réception des requêtes et l’envoi des données vers la file d’attente, ainsi que les taux d’utilisation de ressources.

Pour les écritures, ont principalement été mesurés :

• Latence et pertes de connexion sur ZooKeeper et kafka
• Score de similarité des URI entre ZooKeeper et Kafka
• Délai de propagation du cache (temps entre réception des données et mise à jour du cache)

LinkedIn affirme que 50 % des clients obtiennent désormais les données en moins de 1 seconde et 99 % en moins de 5 secondes. Sur le plan de contrôle ZooKeeper, les latences P50 et P99 étaient respectivement à 10 et 30 secondes.

À consulter en complément, d’autres retex impliquant Kafka et/ou ZooKeeper :

Unification des déploiements de configuration chez Uber
Optimisation des coûts Kafka sur AWS chez Grab
Mise à l’échelle de Kafka chez PayPal
Passage à l’architecture cellulaire chez Slack

Illustration © Danloe – Adobe Stock

The post LinkedIn associe Kafka et gRPC pour la découverte de services appeared first on Silicon.fr.