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.
oui, mais je t'invite à lire au moins le pdf qui a servi pour la conférence, tu en tirera des élements intéressants, j'en doute pas. Par exemple, dans le cas de sepsql il n'a pas de notion de délégation de droits (les réels) : l'admindb ou le sysadmin continue d'avoir un full-accès à la base, assez facilement (y compris si le fs ou la base est/sont chiffrées). Avec cryptdb ce n'est plus le cas. Et ce n'est qu'un exemple des différences entre les deux.
[^] # Re: SELinux
Posté par bubar🦥 . 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 21 décembre 2011 à 03:17.
oui, mais je t'invite à lire au moins le pdf qui a servi pour la conférence, tu en tirera des élements intéressants, j'en doute pas. Par exemple, dans le cas de sepsql il n'a pas de notion de délégation de droits (les réels) : l'admindb ou le sysadmin continue d'avoir un full-accès à la base, assez facilement (y compris si le fs ou la base est/sont chiffrées). Avec cryptdb ce n'est plus le cas. Et ce n'est qu'un exemple des différences entre les deux.