Discussion :

[sloshy]

Bonjour,
Je crée actuellement une web application (classique LAMP).
Mes plus grands impératifs pour cette application sont la sécurité (Authenticité, infalsifiable, inaltérabilité, irrévocabilité) et une haute disponibilité (99.999%).

Tous le contenu de ma/mes bases (cf plus bas) sera donc chiffré. les données applicatif avec un mot de passe que je détient et les données utilisateurs par un mélange entre ce mots de passe et leur mot de passe (cela implique donc de ne pouvoir retrouver ni changer leur mot de passe dans le cas d'une perte). Si j'ai bien fais mes recherches MySQL propose un chiffrement AES 128 bits et une possibilité d'AES 256bits en recompilant le serveur. (ce que je compte faire).

Mon premier soucis concerne l'architecture de mes tables/bases.
Je dispose d'environs 500 clients qui taperont un millier de fois en écriture chaque jour dans la base (et plusieurs milliers de fois en lecture) et les données doivent rester accessible dans le temps (jusqu'à 7 ans, après je peux réaliser des backups). Mon application nécessite environs une 20aine de table.
- Est il préférable de mélanger tous les clients dans une seule base ou de faire une base par client? (en terme de performance).
- Comment dimensionner correctement le serveur physique et configurer correcteur le serveur MySQL afin d'obtenir de bonne performance? (j'ai bien sur lu la doc à ce sujet sur la configuration de MySQL mais beaucoup d'option me semble toujours fort obscure, surtout avec les moteurs de stockage et les variables de caches en tout genre).

Ma deuxième question vient sur la réplication.
Je dispose de 3 serveurs distinct (qui ne communique entre eux que via le WAN). le serveur A et B doivent rester identique en temps réel (avec un ipfailover automatique en cas de défaillance). le serveur C est un serveur de dev et de backup. Je souhaite mettre une réplication actif/actif entre le serveur A et B et une réplication master/slave entre B et C.
- Est-ce une bonne idée ou existe-t-il d'autre alternative?
- Est-il possible de chiffrer directement via MySQL les réplications ou dois-je faire passer ces connexions par un VPN? (il n'est pas question de laisser les données passée en claire sur le WAN).

merci d'avoir pris le temps de me lire.

[sloshy]

mhhh, j'aime pas trop faire ça mais ... un petit up

[SQLpro]

Bonjour,
Je crée actuellement une web application (classique LAMP).
Mes plus grands impératifs pour cette application sont la sécurité (Authenticité, infalsifiable, inaltérabilité, irrévocabilité) et une haute disponibilité (99.999%).

La je rigole déjà !!!
MySQL est le plus instable des SGBDR et ne propose aucune solution intégrée de haute dispo; Il est déjà difficile de garantir du 99%

Tous le contenu de ma/mes bases (cf plus bas) sera donc chiffré. les données applicatif avec un mot de passe que je détient et les données utilisateurs par un mélange entre ce mots de passe et leur mot de passe (cela implique donc de ne pouvoir retrouver ni changer leur mot de passe dans le cas d'une perte). Si j'ai bien fais mes recherches MySQL propose un chiffrement AES 128 bits et une possibilité d'AES 256bits en recompilant le serveur. (ce que je compte faire).

Et la je suis mort de rire.... A partir du moment ou vous mettez toutes vos données cryptées plus aucune recherche n'est possible sans décryptage préalable ! Bonjour les performances. Même un tableur sous DOS sera mille fois plus rapide !

Mon premier soucis concerne l'architecture de mes tables/bases.
Je dispose d'environs 500 clients qui taperont un millier de fois en écriture chaque jour dans la base (et plusieurs milliers de fois en lecture) et les données doivent rester accessible dans le temps (jusqu'à 7 ans, après je peux réaliser des backups). Mon application nécessite environs une 20aine de table.
- Est il préférable de mélanger tous les clients dans une seule base ou de faire une base par client? (en terme de performance).
[/CODE]Une seule base[CODE]
- Comment dimensionner correctement le serveur physique et configurer correcteur le serveur MySQL afin d'obtenir de bonne performance? (j'ai bien sur lu la doc à ce sujet sur la configuration de MySQL mais beaucoup d'option me semble toujours fort obscure, surtout avec les moteurs de stockage et les variables de caches en tout genre).

cela dépend de la volumétrie du stockage et du nombre de transactions par minute. Vous devez estimer cela préalablement pour pouvoir dimensionner votre serveur. Du fait du cryptage, posez un coefficient x 10000 (vous avez bien lu DIX MILLE) si vous voulez des performances correctes. Bref, préparez votre carnet de chéque !

Ma deuxième question vient sur la réplication.
Je dispose de 3 serveurs distinct (qui ne communique entre eux que via le WAN). le serveur A et B doivent rester identique en temps réel (avec un ipfailover automatique en cas de défaillance). le serveur C est un serveur de dev et de backup. Je souhaite mettre une réplication actif/actif entre le serveur A et B et une réplication master/slave entre B et C.
- Est-ce une bonne idée ou existe-t-il d'autre alternative?
- Est-il possible de chiffrer directement via MySQL les réplications ou dois-je faire passer ces connexions par un VPN? (il n'est pas question de laisser les données passée en claire sur le WAN).

merci d'avoir pris le temps de me lire.

je pense que vous faites fausse route et que même si vous mainteniez votre solution, MySQL ne serait pas du tout le SGBDR à prendre en considération (à lire : MySQL un ersatz de SGBDR). Pour ce faire il faudrait au moins que le SGBDR implémente TDE (Transparent Database Encryption) pour avoir à la fois un cryptage intégral des données et de bonnes performances. Or ces solutions n'existent que sous Oracle ou SQL Server et ne sont pas près d'arriver dans les SGBDR free du fait qu'ils ne gèrent pas le stockage des données en interne...


A +

[sloshy]

Bonjour,
Merci pour les informations. Est-il néanmoins indispensable de prendre ce ton de mépris pour les donner? Loin d'être un expert en SGBD, je ne sais que me renseigner et mettre en avant mes besoins et les solutions auquel je pense.

Je viens de parcourir votre papier, il comporte lui même quelques erreurs flagrante. Dois-je les communiquer à travers un billet acerbe remettant en doute tout ce que vous dite ou juste les transmettre cordialement?

[ericd69]

salut,

en terme de perf c'est vrai que tu vas concurrencera pas les sgbd payant

quelques soient les sgbd free aucun n'implémente ça en interne mais en fait tu peux le contourner...

je suppose que tu fais ça pour un projet tutorisé et pas l'implémenter dans un environnement de travail réel...

tu peux contourner le fait de ne pas décrypter/crypter à la volée...

comme les fonctions de cryptage sont des bijections tu es sur de l'unicité des donnée cryptées...
toutes tes colonnes devront du coup être de type varchar ou varbinary (mieux je pense car il me semble que ça simplifie les règles de collation) avec une taille suffisante pour contenir le cryptage...
pour chercher une donnée ce sera donc de la recherche de texte... peu performant sauf à avoir des index sur les colonnes fréquemment utilisées pour les recherches...
je te conseille un subterfuge pour gagner en perf en permettant l'utilisation des index malgré les fonctions d'encryptage, une procédure stockée qui encapsule chaque requête qui y sera sous forme d'un requête préparée genre:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
delimiter $$
drop procedure if exists cherche$$
create procedure cherche(in param1 varchar(255),in param2 varchar(255),in keyenc varchar(255))
begin
  declare val1 varchar(255) default aes_encrypt(param1,keyenc);
  declare val2 varchar(255) default aes_encrypt(param2,keyenc);
  set @req=concat('select t1.machin from tatable t1 inner join tatable2 t2 on t1.truc=t2.id and t2.machinchose="',val2,'" where t1.bidule="',val1,'"');
  prepare act from @req;
  execute act;
 deallocate prepare act;
end$$

les performances seront un peu meilleures car tu n'as pas de fonctions qui apparaisse main une constante donc l'utilisation d'index si ils existe reste préservée ici pour les colonnes bidule de t1 et machinchose de t2...

pose toi la question de la réelle nécessité de tout rendre anonyme (crypter)... en général c'est rarement utile...

il me semble que mysql peut fonctionner en forçant des connexions ssl regarde la doc au niveau des fichier de configuration avant de t'attaquer à un éventuel tunneling style vpn