Qualifying Observation Integrity for Selective Authorization in PostgreSQL

Dans le monde numérique, les bases de données agissent comme la mémoire centrale de tout, des comptes bancaires aux paniers d'achat en ligne. Elles stockent l'état actuel du monde : combien d'argent se trouve sur un compte, quels articles sont en stock, ou si un utilisateur a la permission d'entrer dans un bâtiment. Lorsqu'un programme informatique demande à une base de données la permission d'effectuer une action, la base de données vérifie les faits actuels. Si les faits ont changé depuis la dernière vérification, la réponse pourrait être différente. Par exemple, un achat peut être approuvé lorsqu'un utilisateur a assez d'argent, mais si une autre transaction dépense cet argent une fraction de seconde plus tard, l'approbation devrait être révoquée. Pour rester en sécurité, les systèmes re-vérifient souvent les faits chaque fois qu'une action est sur le point de se produire. C'est fiable, mais cela peut être lent, surtout lorsque les mêmes faits sont vérifiés des milliers de fois de suite sans changer.

Les chercheurs cherchent depuis longtemps des moyens d'accélérer cela en se souvenant de la dernière fois que les faits ont été vérifiés. Si le système peut prouver que les données sous-jacentes n'ont pas changé, il peut réutiliser l'ancienne permission sans demander à nouveau. C'est ce qu'on appelle l'autorisation sélective. Cependant, ce raccourci ne fonctionne que si le système peut être absolument certain que les données n'ont réellement pas changé. Si le système est trompé en lui faisant croire que les données sont stables alors qu'elles sont en réalité en mouvement, il pourrait accorder une permission pour une transaction qui devrait être bloquée. Le défi central n'est pas seulement de vérifier les données, mais de vérifier que les mécanismes mêmes conçus pour suivre les changements fonctionnent correctement et sont visibles par les bonnes personnes.

Un chercheur nommé Aleksandar Mihajlovic a développé une méthode pour vérifier ces mécanismes de suivi au sein d'un type spécifique de système de base de données appelé PostgreSQL. Le but était de créer un ensemble strict de règles qu'une installation de base de données doit suivre pour être digne de confiance avec ce raccourci. Le système, nommé OntoCommit, agit comme un gardien. Avant qu'une base de données ne soit autorisée à réutiliser d'anciennes décisions de permission, ce gardien inspecte le code et la configuration pour s'assurer que chaque changement de données est correctement enregistré et que la personne vérifiant les registres peut réellement voir ces registres. La recherche se concentre sur une frontière spécifique : le moment où un changement est effectué et le moment où il est observé. S'il y a un écart entre les deux, la sécurité de l'ensemble du système est compromise.

L'étude a commencé par identifier la facilité avec laquelle cette confiance pouvait être rompue, même lorsque le code semblait correct en surface. Le chercheur a découvert deux manières spécifiques dont un système pourrait échouer silencieusement. Dans le premier cas, une fonction auxiliaire conçue pour mettre à jour un compteur de changements a vu ses noms d'entrées inversés. Le code s'est exécuté, les types de données qu'il acceptait étaient corrects, mais parce que les noms étaient mélangés, le compteur pour un type de changement a été mis à jour tandis que le compteur pour un autre type est resté bloqué. C'était comme un système de feux de signalisation où le capteur pour la voie nord-sud aurait été accidentellement connecté au bouton est-ouest ; les feux changeraient, mais pas pour les voitures qui en avaient besoin. Dans le second cas, le système était configuré avec une fonction de sécurité qui cachait certaines lignes de données aux utilisateurs réguliers. Le compteur de changements était mis à jour correctement par l'administrateur du système, mais la personne vérifiant la permission était bloquée pour voir cette mise à jour. Pour le vérificateur, le compteur apparaissait à zéro, alors qu'il avait en réalité augmenté. Cela créait un faux sentiment de sécurité.

Pour prévenir ces défaillances, le chercheur a construit un outil de qualification qui vérifie l'installation de la base de données avant qu'elle ne soit autorisée à utiliser le raccourci. Cet outil ne se contente pas de chercher la présence de code ; il vérifie la liaison exacte des noms de fonctions, la propriété des tables et les paramètres de visibilité pour chaque rôle d'utilisateur. Il exige que le code responsable de la mise à jour des compteurs de changements corresponde exactement à la signature attendue par le système. Il interdit également l'utilisation de la sécurité au niveau des lignes sur les tables spécifiques qui suivent ces changements, garantissant que la personne vérifiant la permission puisse toujours voir l'état réel du compteur. L'outil agit comme un inspecteur rigoureux, rejetant toute installation qui tente d'utiliser des variations non supportées ou qui cache les preuves de changement.

Le chercheur a testé cette approche en utilisant un environnement contrôlé qui simulait un processus d'achat complet. Le système a été configuré pour gérer un scénario où un utilisateur tente d'acheter quelque chose, vérifiant le solde de son compte et toute retenue existante sur ses fonds. L'expérience a comparé deux méthodes : une où le système réévalue l'intégralité de la politique à partir de zéro à chaque fois, et une autre où le système utilise le raccourci de l'autorisation sélective. Les tests ont été effectués sur une version standard du logiciel de base de données, mais dans un environnement informatique simulé pour assurer un contrôle précis sur les conditions. L'étude comprenait un ensemble de cent huit paires de configurations différentes, certaines conçues pour être sûres et d'autres pour être dangereuses, afin de voir si l'outil de qualification pouvait faire la différence.

Les résultats ont montré que l'outil de qualification était très efficace pour identifier les configurations dangereuses. Il a rejeté avec succès les cinq configurations délibérément non sûres, y compris celles avec des noms de paramètres inversés et des lignes de données cachées. Parallèlement, il a accepté les quarante-huit configurations valides et sûres. Il a également refusé correctement deux configurations qui étaient sûres mais ne correspondaient pas aux règles strictes de l'outil, démontrant qu'il donne la priorité à la sécurité sur la commodité. Dans les tests de performance, la méthode de l'autorisation sélective s'est avérée nettement plus rapide lorsque les données restaient inchangées. Pour un ensemble de données de dix mille lignes, le système utilisant le raccourci a terminé le cycle en un temps médian de soixante-six millisecondes, tandis que le système re-vérifiant tout a pris quatre-vingt-sept millisecondes. Cela représentait une réduction de vingt-quatre pour cent du temps. Cependant, l'étude a également constaté que lorsque les données changeaient réellement, le raccourci n'offrait aucun avantage de vitesse et pouvait même être légèrement plus lent, car le système devait réévaluer la politique.

La recherche a également mis en évidence les limites des tests. Le chercheur a démontré que le simple fait de lancer quelques tests pour voir si le système fonctionne ne suffit pas à garantir qu'il fonctionnera toujours. Il est possible de construire un scénario où un système réussit tous les tests mais échoue tout de même sous une condition spécifique et invisible. L'étude a montré qu'un système pouvait passer une série de vérifications tout en cachant encore un changement critique à l'observateur. Cela signifie que la seule façon de garantir la sécurité est d'imposer des règles strictes sur la façon dont le système est construit, plutôt que de compter uniquement sur les tests pour trouver des erreurs. L'outil ne prétend pas prouver que le système est parfait dans tous les univers possibles, mais il fournit un contrat vérifiable que l'installation suit un modèle spécifique et sûr.

En fin de compte, ce travail offre une méthode pratique pour rendre les bases de données plus rapides sans sacrifier la sécurité. En définissant un ensemble clair de règles sur la façon dont le suivi des changements doit être implémenté et vérifié, le chercheur a créé un moyen de croire que la base de données dit la vérité sur son propre état. L'étude ne prétend pas résoudre tous les problèmes de sécurité des bases de données, ni suggère qu'on doive utiliser cette méthode dans toutes les situations. C'est une solution spécialisée pour un type spécifique de configuration de base de données, qui échange une partie de la flexibilité contre un degré de certitude plus élevé. Les conclusions suggèrent que pour les applications où la vitesse et la sécurité sont toutes deux critiques, comme les transactions financières, un système soigneusement qualifié peut offrir un raccourci fiable. La recherche conclut que la sécurité de ces raccourcis dépend entièrement de l'intégrité du chemin d'observation, du moment où un changement est effectué au moment où il est vu, et que ce chemin doit être vérifié avec la même rigueur que les données elles-mêmes.