C'est un peu la même finalité en fait : offrir un contrôle d'accès durci aux données, mais pas les même moyens.
sepsql via SELinux va imposer via les mécanismes du noyau un contrôle d'accès MAC très fin aux données.
cryptdb lui, va cloisonner les données par de la crypto.
L'un repose sur la robustesse du noyau, l'autre sur le fait que les clefs restent secrètes.
La solution crypto est plus robuste, mais je pense qu'elle est moins souple sur ce qui est protégé (ex: OPE pour les relations d'ordres ne me semble marcher que si toute la colonne est protégée). Je n'ai pas regardé donc je ne sais pas comment est géré le multiutilisateur dans une table ... Ca suppose aussi que la machine ne soit pas complètement corrompue, car si c'est le cas, l'admin pourra récupérer la clef des opérations crypto faites en local.
sepsql est plus souple mais n'offre de cloisonnemnt crypto au cas ou il serait bypassé (m'enfin à ce niveau, on doit être déjà marron ;) ). Et comme il marche dans la bdd, il ne faut pas oublier de mettre des acl selinux sur les fichiers physiques pour éviter que l'admin parte avec :)
edit: je ne connaissais pas sepsql, j'ai regardé la doc développeur, j'aime bien :)
[^] # Re: SELinux
Posté par oinkoink_daotter . En réponse au journal CryptDB : un bond en avant pour la sécurité des base de données. Évalué à 2. Dernière modification le 20 décembre 2011 à 22:15.
C'est un peu la même finalité en fait : offrir un contrôle d'accès durci aux données, mais pas les même moyens.
sepsql via SELinux va imposer via les mécanismes du noyau un contrôle d'accès MAC très fin aux données.
cryptdb lui, va cloisonner les données par de la crypto.
L'un repose sur la robustesse du noyau, l'autre sur le fait que les clefs restent secrètes.
La solution crypto est plus robuste, mais je pense qu'elle est moins souple sur ce qui est protégé (ex: OPE pour les relations d'ordres ne me semble marcher que si toute la colonne est protégée). Je n'ai pas regardé donc je ne sais pas comment est géré le multiutilisateur dans une table ... Ca suppose aussi que la machine ne soit pas complètement corrompue, car si c'est le cas, l'admin pourra récupérer la clef des opérations crypto faites en local.
sepsql est plus souple mais n'offre de cloisonnemnt crypto au cas ou il serait bypassé (m'enfin à ce niveau, on doit être déjà marron ;) ). Et comme il marche dans la bdd, il ne faut pas oublier de mettre des acl selinux sur les fichiers physiques pour éviter que l'admin parte avec :)
edit: je ne connaissais pas sepsql, j'ai regardé la doc développeur, j'aime bien :)