Aurora Query, la faille Titan d'un ado de 16 ans et la migration Kafka

Les organisations sportives reposent sur la même plomberie que tout le monde : des stockages d'objets remplis de Parquet, un entrepôt, une base transactionnelle et une file d'attente qui synchronise le tout. Trois articles publiés ces 72 dernières heures racontent cette plomberie qu'on démonte et qu'on remonte. Avec, à la clé, des conséquences sur la vitesse à laquelle un club, une ligue ou un diffuseur transforme un match en chiffre.

Aurora intègre DuckDB, et l'étape ETL disparaît

AWS a annoncé le 30 septembre qu'Aurora PostgreSQL peut désormais interroger des données opérationnelles à côté de données stockées aux formats Apache Iceberg et Parquet, avec les applications et outils PostgreSQL existants, sans pipelines d'extraction, de transformation et de chargement ni duplication de données. Les clients créent des tables étrangères PostgreSQL qui pointent vers des données Iceberg ou Parquet dans Amazon S3, Amazon S3 Tables ou le catalogue de données AWS Glue. Aurora exécute ces requêtes via le moteur de DuckDB, intégré à PostgreSQL, selon le billet What's New d'AWS. La fonctionnalité est disponible en général sur Aurora PostgreSQL 17.11 et 18.6 et versions supérieures dans toutes les régions commerciales AWS et GovCloud (US), sans frais supplémentaires.

Pour une pile d'analyse sportive, c'est la différence entre un traitement par lots nocturne et une requête qui tourne pendant que le match est encore en cours.

Elle supprime aussi un mode de défaillance connu. « Y accéder demandait généralement des pipelines qui copient les données de votre lac de données vers Aurora, ce qui fait grimper les coûts et le travail d'ingénierie à mesure que les schémas évoluent », écrit AWS. AWS précise que les catalogues externes compatibles avec le catalogue REST Iceberg, fédérés via le catalogue de données Glue, fonctionnent aussi. Les charges sensibles à la latence peuvent, elles, matérialiser des données Iceberg ou Parquet dans des tables Aurora PostgreSQL natives en SQL standard, sans pipeline ETL.

Quantum et Kafka : la migration que personne ne veut faire deux fois

Le fournisseur de stockage d'objets Tigris a expliqué le 30 septembre pourquoi il a sorti le travail asynchrone de FoundationDB, la seule base de données qu'il utilise, pour le mettre sur Kafka. Le billet est d'une franchise rare sur les compromis. Il colle de près aux charges de données sportives, où un flux de tracking ne doit pas perdre un événement parce qu'un worker est mort.

Tigris avait implémenté l'article QuiCK, le système de files d'attente qu'Apple utilise pour CloudKit, au-dessus de FoundationDB. Cela fonctionnait, mais l'ordonnancement exigeait de nombreuses écritures et lectures, en concurrence avec les requêtes des utilisateurs, et chaque tâche avait besoin de plusieurs écritures pour aboutir. Les nouveaux ingénieurs devaient apprendre du code maison sans implémentation standard.

L'objection de l'entreprise à Kafka mérite d'être citée en entier, car c'est celle que reconnaîtront la plupart des équipes de données sportives. « Vous êtes-vous déjà senti comme un sac plastique emporté par le vent, incapable de redémarrer à cause de la folie pure qui consiste à passer des mois à permuter des options de JVM pour gratter l'équivalent d'un spectre de performance afin que vos serveurs ne prennent pas feu en permanence ? », demande le billet de Tigris. Il admet ensuite que la migration n'a pas été un simple remplacement : les files restent dans FoundationDB, tandis que des tâches comme le ramasse-miettes sont passées à Kafka. « Nous avons déplacé des tâches asynchrones comme le ramasse-miettes vers Kafka, ce qui réduit la charge de lecture et d'écriture sur FDB et élimine une bonne partie de ce satané code maison », indique le billet.

Quiconque fait tourner un flux de données sportives en direct sur un schéma base de données comme file d'attente devrait le lire.

17 300 milliards de lignes, un ado de 16 ans et une signature manquante

L'article de données le plus lu de la semaine n'est pas un lancement de produit. The Register a rapporté le 30 septembre qu'un chercheur en sécurité de 16 ans nommé Faav a trouvé une faille d'authentification dans Titan, le service d'analyse interne de Microsoft, obtenu un accès administrateur et exécuté du SQL sans identifiants valides. La base qu'il a atteinte contenait environ 17 300 000 000 000 de lignes stockées.

Titan est réservé aux employés de Microsoft via son interface web. Faav, avec un hackbot d'IA qu'il a construit et baptisé Antares, a atteint l'API de Titan via un hôte Azure Cloud Services parce que Titan ne vérifiait pas la signature d'un jeton de connexion. Microsoft a depuis verrouillé l'API et versé une prime de 5 000 dollars. « Il était 2 h du matin », écrit Faav dans un billet de blog sur ses découvertes. « Je voulais crier, ou au moins dire quelque chose à voix haute, mais mes parents dormaient. Alors je suis resté assis à fixer 17 333 335 124 315 en revérifiant le calcul. »

The Register note que Faav a réécrit son billet à la demande de Microsoft, retirant des sections et des chiffres et reformulant l'impact avant publication. La déclaration de Microsoft à Faav, citée dans le même article, indique : « Leur soumission et la divulgation coordonnée de vulnérabilité nous ont aidés à mieux protéger nos clients en renforçant nos services. »

Pour les organisations sportives, la conclusion pertinente n'est pas le nombre de lignes. C'est la leçon que tire Faav : « Titan validait le contenu du JWT (locataire, audience, ID d'application, utilisateur) mais ne vérifiait jamais la signature, la partie la plus importante de tout contrôle d'authentification. » Toute plateforme d'analyse qui ingère des données d'athlètes, médicales ou de supporters repose sur la même vérification de jeton. La même défaillance ne s'annoncerait pas.

Qui possède le pipeline, et qui a le droit de regarder dedans

Trois autres articles cette semaine montrent que la couche de gouvernance autour des données sportives devient plus dure, pas plus simple. The Guardian a rapporté le 29 septembre que le secrétaire américain à la Santé Robert F Kennedy Jr a exposé des projets pour relier des données médicales et de mode de vie et les interroger avec l'IA, citant Medicaid comme « un véhicule vraiment utile » avec « des centaines de millions de vies dedans ». La médecine sportive et les données de capteurs portables sont adjacentes à ce pipeline, et les mêmes questions de consentement et d'usage secondaire s'appliquent.

The Guardian a aussi rapporté le 30 septembre que plus de 44 000 personnes ont déposé des objections juridiques au titre de l'article 21 du RGPD britannique contre la Federated Data Platform de NHS England, propulsée par Palantir, qui traite leurs informations personnelles. Louis Mosley, vice-président exécutif de Palantir pour le Royaume-Uni et l'Europe, a accusé les critiques de « syndrome de dérangement Palantir ». L'entreprise affirme que son logiciel a aidé les trusts à enregistrer 117 000 opérations supplémentaires et une réduction de 14,3 % des retards de sortie pour les patients de longue durée.

Le même jour, 404 Media a rapporté que l'Office of National Drug Control Policy de la Maison-Blanche utilise le programme de subventions HIDTA pour rapatrier des données locales de lecteurs de plaques d'immatriculation de Flock, Axon et d'autres fournisseurs vers des serveurs fédéraux. Dans certains cas, ces données sont transmises au National License Plate Reader Program de la DEA. Jeramie Scott, de l'Electronic Privacy Information Center, a déclaré à 404 Media : « Si Flock vous met en colère, alors ceci devrait vous mettre en colère. »

Et NL Times a rapporté le 30 septembre que la plupart des centres de données européens gardent secret leur impact environnemental. Moins d'un quart des grandes installations néerlandaises publient leurs chiffres de consommation d'électricité et d'eau potable, alors que l'obligation de la directive européenne sur l'efficacité énergétique est en vigueur depuis trois ans. Les centres de données du sport sont soumis au même manque de transparence.

Ce que tout cela donne

La direction technique est claire. Les moteurs de requêtes se déplacent vers les données, les files d'attente se séparent des bases de données, et la copie ETL que les équipes d'analyse sportive construisent depuis dix ans est abandonnée par les fournisseurs eux-mêmes. La direction de la gouvernance est plus confuse : plus de données reliées, plus d'objections déposées, plus d'infrastructures sous-jacentes non divulguées.

Les deux tendances se rejoignent au même endroit. Un club qui peut interroger son lac depuis Aurora en quelques secondes est aussi un club qui détient des données que régulateurs, militants et attaquants traitent désormais comme une cible. Le pipeline s'est accéléré cette semaine. Les débats autour de lui ne se sont pas simplifiés.