Styles

mercredi 30 juillet 2008

Les vues et le contrôle d'accès fin aux données

La caractéristique principale d'un développeur est la fainéantise ! Si un développeur n'est pas assez fainéant, il ne se préoccupera pas de minimiser le nombre de lignes de code qui lui sont nécessaires.

Dans le cadre des systèmes d'information, il existe un moyen important à maîtriser pour réduire un maximum le code source redondant, comme le code source servant à vérifier l'accès aux données qu'a le droit de voir l'utilisateur. Nombre d'applications sont complètement sclérosées par du code dupliqué, répété à chaque fois qu'un accès à lieu à la base de données.

Un développeur orienté programme aura tout de suite envie de parler Programmation par Aspect, alors qu'il y a pourtant une méthode bien plus simple et d'ailleurs bien plus éprouvée.

Quand les utilisateurs d'une application ne doivent être autorisés qu'à consulter et modifier qu'une partie des informations existante en base de données, le plus simple est de créer des vues au dessus des tables contenant les données. Cela permet :
- d'encapsuler la logique de sécurité à un seul endroit : la vue

- de masquer la logique de sécurité au code source, permet ainsi de rendre l'application indépendante de la logique de sécurité

- de changer de logique de sécurité sans se soucier des impacts au niveau du code source de l'application.
La vue est un concept très simple à comprendre, mais si peu utilisée malheureusement ! Il n'est pas rare de retrouver le même code alambiqué recodant la même logique de sécurité (la clause WHERE de chaque requête SQL). C'est souvent le cas pour MySQL, car ce SGBD n'offre pas toutes les caractéristiques que l'on attend des vues.

J'ai cherché comment coder proprement avec MySQL, un système de gestion des droits fins d'accès au données, comme on peut le retrouver classiquement dans des systèmes de gestion de bases de données "sérieux". J'en ai fait un article : MySQL 5.0 Fine-Grained Access Control (FGAC).

On peut voir sur le site mysql.com que la notion de Fine Grained Access Control n'est pas comprise dans son acceptation la plus courante. Chez MySQL, elle se contente d'aller jusqu'au contrôle d'accès au niveau des colonnes. Mais quand on parle de Fine Grained access control, on pense à un contrôle d'accès au données au niveau de la ligne ("row level security").

Le contrôle d'accès au niveau ligne peut s'implémenter dans à peu près tous les systèmes offrant des vues, même si certains "se la pètent" plus que d'autre comme SE-postgreSQL :
"Only a few commercial DBMS products provide such functionality."
Euh... non. Même sur PostgreSQL (pas SE-PostgreSQL) on peut le faire avec un système similaire à celui que je propose dans mon article. PostgreSQL est beaucoup plus propre que MySQL au niveau des vues, l'implémentation du FGAC est moins tordue.

Le choix d'un système de vues pour contrôler comment l'application voit des données est une décision qui doit être prise au moment de la conception. Il est intéressant de définir clairement quelles sont les vues, et notamment, dans le dossier de politique sécurité, comment est implémenté le contrôle d'accès fin aux données.

Les vues se retrouvent plus ou moins dans tous les systèmes de gestion de bases de données, avec beaucoup de variantes, SQL ayant certainement la palme de la norme la moins suivi au monde :)

Aucun commentaire: