Discussion :

[deudtens]

J'ai une question cote securite, et je suis pes expert :
Je dois developper une nouvelle version d'une sorte de CMS avec une BD pouvant gerer plusieurs sites appartenant a des clients differents. Ainsi, pour simplifier, il y a une table Page dans laquelle il y a une cle etrangere vers la table Client. Et donc les donnees des clients sont toutes "melangees" dans ces tables. Ca me fait un peu peur. J'aimerais avoir votre avis pour savoir si je peux garder cette structure moyennant renforts au niveau securite (ca m'arrangerait que la reponse soit oui).

pour securiser l'ajout/suppression/modif de donnees : je compte faire le maximum de tests en PHP. Mais j'aimerais savoir si ya pas moyen de faire autre chose en plus.

pour securiser la visibilite des infos : aucune idee. je peux isoler la table client dans un schema a part, vu que ca, meme les clients ne verront pas leurs propres infos, mais pour la table page, je sais pas.

Donc si vous avez des conseils...

[estofilo]

Pour faire du droit d'accès à granularité plus fine que la table, il y a un projet qui s'appelle Veil:
http://pgfoundry.org/projects/veil/

Et le projet SE-PostgreSQL inspiré de SE-Linux (SE=security enhanced)
http://wiki.postgresql.org/wiki/SEPostgreSQL

Mais personnellement je n'ai essayé aucun des deux.

[GrandFather]

Bonjour,

pour securiser l'ajout/suppression/modif de donnees : je compte faire le maximum de tests en PHP. Mais j'aimerais savoir si ya pas moyen de faire autre chose en plus.

Essaie d'implémenter le maximum de contrôles en utilisant les contraintes sur les définitions de champs (CHECK), en définissant des triggers et des contraintes d'intégrité référentielle (clés étrangères). N'implémente en PHP que les contrôles qui ne peuvent pas être couverts par les fonctionnalités citées (il ne devrait pas y en avoir beaucoup).

pour securiser la visibilite des infos : aucune idee. je peux isoler la table client dans un schema a part, vu que ca, meme les clients ne verront pas leurs propres infos, mais pour la table page, je sais pas.

Ce qu'il faut sécuriser, ce sont les opérations sur la table Pages en s'assurant que l'utilisateur (au sens Postgres) qui fait l'opération désigne le bon client. Tu peux verrouiller cela en créant un rôle de connexion par client, et en enregistrant le nom de ce rôle dans la table Clients pour chacun d'entre eux. Tu places ensuite un trigger sur la table Pages qui se déclenche en cas d'insertion/modification/suppression, qui va aller rechercher l'ID du client dans la table Clients en fonction du nom de l'utilisateur connecté ; l'ID du client n'est donc pas communiqué dans la requête SQL, et on est sûr que le client propriétaire de la page est bien celui qui fait la requête.

Au pire, si un rôle de connexion est compromis, les dégats éventuels n'impacteront qu'un client (celui pour qui est défini le rôle), le reste du site sera préservé.