Azure SQL : Microsoft s’arme face aux agents IA et à la menace quantique

Vers une gestion plus fine des identités, des accès et des rôles

En ce sens, Microsoft pousse l’usage d’Entra (ex-Azure ID), compatible avec l’ensemble des produits Azure Database. Il s’agit de centraliser la gestion des identités tout en supprimant la rédaction et les échanges incontrôlés de mots de passe.

Le fournisseur a annoncé en juin dernier la disponibilité générale d’Entra Server Principals et Server Roles pour Azure SQL Database. Ces fonctions placent la gestion des identités cloud au niveau du serveur logique. Les identités (utilisateurs, groupes, etc.) sont créées comme des connexions dans la base de données virtuelle maîtresse. Il est possible de leur attribuer des rôles fixes. L’objectif est de simplifier la délégation des accès, de rapprocher le fonctionnement d’Azure SQL Database de celui de SQL Server tout en donnant la visibilité des identités aux équipes SOC.

« Avec Azure SQL Database, nous prenions en charge l’authentification Microsoft Entra, mais les utilisateurs étaient créés en tant qu’utilisateurs de base de données contenue », rappelle Sravani Saluru, responsable produit senior SQL Server chez Microsoft. « Cela représentait donc une charge supplémentaire. Chaque fois qu’une nouvelle base de données était ajoutée, il fallait créer ces utilisateurs et leur accorder les autorisations nécessaires », poursuit-elle. « Par exemple, si vous disposez de répliques géographiques, il fallait les recréer ».

Il faut encore attribuer le niveau de permission adéquat aux différents usagers. « Par exemple, votre équipe de développeurs peut se voir attribuer un rôle au niveau du serveur pour gérer la création des bases de données ou la définition des schémas, ce qui peut être géré au niveau du serveur logique », illustre Sravani Saluru. De même, les responsables des audits de sécurité n’ont plus besoin d’être « db_owner » pour accéder à la télémétrie d’Azure SQL.

« En cas de problème, il suffit de désactiver ou de supprimer les connexions de la console d’administration », assure-t-elle.

C’est une application de la logique du moindre privilège. Un principe que Microsoft doit encore généraliser dans ces outils. Par exemple, le rôle bulkadmin n’existait pas pour SQL Server sur Linux. C’est chose faite depuis le 21 septembre dans les éditions SQL Server 2025 CU3 et SQL Server 2024 CU24.

« Cela nous était demandé depuis plusieurs années. Auparavant, il fallait disposer des autorisations sysadmin pour effectuer les opérations d’insertion en lots liées aux flux ETL », précise Sravani Saluru.

De fait, un système agentique doté de privilèges trop élevés étend la surface d’attaque et accélère potentiellement la compromission du système. « Commencez par ne rien accorder à vos agents, à l’exception peut-être d’un accès en lecture seule, mais ne leur accordez en aucun cas des droits de propriétaire de base de données ou d’administrateur système », martèle Pieter Vanhove.

Un Hub pour mieux piloter la posture de sécurité des bases de données Azure

Il faut également minimiser l’accès aux données sensibles. Pour cela, Azure SQL permet d’appliquer des labels au niveau des colonnes afin d’en refuser l’accès. Cette classification doit être revue et appliquée à chaque évolution du schéma de la base de données.

De plus, Microsoft encourage ses clients à utiliser une fonction de masquage dynamique des données. Elle permet de cacher les informations sensibles dans les résultats des requêtes SQL en fonction du niveau de permission de la personne ou de l’agent.

En la matière, Microsoft ne prenait en charge que des patterns de masquage fixe. En préversion publique, la commande REGEXP_REPLACE() doit permettre de définir des règles de masquage plus « flexibles ». « Certains clients considéraient que le masquage dynamique était limité. Nous les avons écoutés », assure Pieter Vanhove. Il s’agit par exemple de sélectionner des portions de mails distincts, des tronçons de numéros de téléphone différents à cacher. Cette fonctionnalité remplace des éléments par des astérisques, mais les données ne sont pas chiffrées.

Pour mieux anticiper ces différents aspects, le fournisseur propose à ses clients d’adopter gratuitement Database Hub. Ce portail intégré à Microsoft Fabric permet d’inventorier la majorité des bases de données de son cru (dont Azure SQL et SQL Server), dans le cloud et sur site et d’y gérer la posture de sécurité.

« Le hub offre une vue d’ensemble de la posture de sécurité de toutes vos ressources et affiche des indicateurs clés : utilisation de l’authentification Microsoft Entra versus celle d’Azure SQL, état de l’audit, etc. », liste Sravani Saluru. « Il propose également une remédiation guidée. Il explique pourquoi une fonctionnalité est nécessaire et comment l’activer. Vous gérez tout depuis un point unique, et bientôt, des agents IA automatiseront ces actions pour plus d’efficacité », promet-elle. Il demeure actuellement en préversion privée.

Azure SQL passe au chiffrement postquantique

Les responsables produits n’oublient pas de se pencher sur une seconde menace : les attaques de type « Harvest Now, decrypt Later ». Celle-ci consiste à « aspirer » des données chiffrées de systèmes d’entreprises, puis de les stocker en attendant d’acquérir la puissance de calcul suffisante.

Jusqu’alors, les chercheurs estimaient que le temps nécessaire pour briser une clé de chiffrement RSA 2048 bits était d’environ 13,8 milliards d’années, soit l’âge actuel de l’Univers. Or, un ordinateur quantique, puisqu’il est pensé pour résoudre ce type d’équation (en exécutant l’algorithme de Shor), ferait tomber ce délai à quelques années, voire quelques mois à l’horizon 2030-2035.

Un problème pris très au sérieux par la NSA. L’agence responsable du renseignement et la sécurité des SI du gouvernement américain, a annoncé le 1^er octobre que l’ensemble des nouveaux systèmes de sécurité nationale commerciaux – les logiciels et plateformes achetés par une agence gouvernementale étatsunienne – devront prendre en charge des algorithmes résistant au calcul quantique dès 2027.

Microsoft utilise justement des clés RSA dans le cadre du chiffrement des données, des logs et des backups des bases de données Azure SQL (à travers la fonction Transparent Data Encryption ou TDE).

Ce choix est justifié par la nature asymétrique du mécanisme de chiffrement d’enveloppe de TDE. Des clés symétriques nommées DEK (Database Encryption Key) sont utilisées pour chiffrer les données elles-mêmes à l’aide de l’algorithme AES 256 bits. Elles sont stockées en mémoire vive.

Ces clés sont elles-mêmes chiffrées par une clé asymétrique nommée protecteur de clé TDE, en s’appuyant sur l’algorithme RSA 2048 bits ou 3072 bits. Ce protecteur réside au sein des HSM utilisés en lien avec le KMS Azure Key Vault.

Or, contrairement à RSA, les clés AES 256 bits sont dites résistantes au calcul quantique. L’algorithme de Grover divise la longueur de la clé par deux, mais il faudrait des milliers de milliards d’années pour en venir à bout. Du chiffrement asymétrique, Microsoft, tout comme AWS, passe donc au chiffrement symétrique. Il n’y a pas besoin de rechiffrer les données, seulement l’enveloppe, c’est-à-dire la DEK.

Ce mécanisme, le fournisseur se l’est appliqué à lui-même et aux clients qui utilisent les HSM managés, mais certains de ceux qui s’appuient sur un HSM dédié ou un service de chiffrement tiers devront opérer la rotation de clés par eux-mêmes. Ce processus administratif était pénible.

D’où l’introduction des clés « versionless » en disponibilité générale depuis mars. « Avant, il fallait spécifier manuellement la version exacte de chaque clé versionnée », indique Pieter Vanhove. « Maintenant, avec les clés sans version, le système récupère automatiquement la dernière version active, en utilisant le nom de référence de la clé. C’est plus simple à gérer ». Les équipes de Microsoft ont retroporté cette fonctionnalité mise en place par défaut dans la plateforme unifiée Microsoft Fabric.

Tout n’est pas prêt. « Les clés AES sont actuellement en préversion publique pour Azure Key Vault et Azure Premium Key Vault, et sont déjà disponibles pour tous les utilisateurs dans Managed HSM », ajoute-t-il. Les clés RSA demeurent disponibles pour les clients qui le souhaitent, mais ne sont plus recommandées. Le géant du cloud met surtout en avant son offre premium. Elle est moins chère que la gestion manuelle des HSM, mais induit une perte de contrôle sur l’infrastructure.

Généraliser les protocoles TLS 1.3 et IPv6

Cela n’écarte pas d’autres menaces. Il reste très difficile de s’introduire dans un HSM, mais le vol de clés demeure un risque, surtout lorsque la gestion du chiffrement est inefficiente.

En outre, il faut se préparer à la fin du support des versions 1.0 et 1.1 du protocole TLS. 

TLS 1.2 est désormais le protocole de protection des données en transit par défaut et TLS 1.3 est prise en charge dans les versions les plus récentes d’Azure SQL. « TLS 1.3 offre un chiffrement plus fort en transit, donc envisagez son implémentation dans vos applications », recommande Sravani Saluru. Ici, les ingénieurs ont sur leur feuille de route l’usage d’algorithme post-quantique comme ML-KEM, en lien avec Let’s Encrypt. Oracle a déjà présenté sa feuille de route pour la prise en charge de ML-KEM dans les versions LTS de Java.

Enfin, Microsoft entend généraliser la prise en charge d’IPv6 avec Azure SQL à travers Azure Private Link. Une fonctionnalité attendue de (très) longue date. « Vous pouvez faire fonctionner certaines applications en IPv4 avec Private Link, tandis que d’autres, plus modernes, fonctionnent déjà en IPv6 ou sont en cours de migration vers ce protocole », précise la responsable.

Outre les coûts d’implémentation, de telles migrations demeurent des défis de tailles pour les équipes IT.