Sécurité avec un serveur MySQL/MAriaDB distant

Bonjour,
suite à un dépannage un peu à la hussarde ce matin, j’héberge temporairement un MySQL sur mon infra pour un dolibarr hébergé « autre part ».

Et j’ai découvert au passage - sauf erreur de ma part - que dolibarr ne permet pas de configurer la connexion MySQL / MariaDB sur un canal SSL … snif !

J’ai donc une sécurité uniquement au niveau du firewall par ip distante mais les données se trimbalent en clair sur le réseau.

J’ai ouvert une feature request sur github remote mysql server with ssl transport ? · Issue #24404 · Dolibarr/dolibarr · GitHub et je voulais savoir si ça pouvait intéresser éventuellement d’autres utilisateurs ?

Bonjour,

Créez un réseau privé avec wireguard et votre traffic sera parfaitement sécurisé.

Ce n’est pas vraiment la question ni possible, imaginez par exemple que le dolibarr (les pages php) soit hébergé sur un serveur mutualisé …

MariaDB / MySQL permet d’utiliser un canal ssl pour communiquer, pourquoi passer à côté s’il s’agit d’implémenter quelques lignes dans le fichier de configuration ?

Il me semble que c’est à fait le sujet.
Le réseau privé permet justement de complètement isoler le traffic entre deux ou plusieurs serveurs.
Et vous aurez en plus de meilleures performances avec wireguard qu’à travers un canal ssl.

@pascal_z excusez-moi mais monter des vpn et des infra réseaux c’est une de mes activités favorites et à moins que je sois complètement passé à côté d’une petite révolution je persiste à penser que ça n’est pas possible.

Je vous invite à prendre par exemple un hébergement mutualisé web (vous savez ces hébergements où vous avez juste un FTP pour déposer vos fichiers PHP et un lien mysql à côté) et essayez de monter un wireguard… pas d’accès ssh, pas de paquets, pas d’accès aux interfaces réseaux …

Donc non il y a de nombreuses situations où nous n’avons pas la main sur l’infra et donc l’installation d’outils complexes/complémentaires (vpn/whatelse) ne sont pas possibles alors qu’une simple option dans la configuration php/sql l’est…

Quant à l’affirmation d’avoir des meilleures perfs je me garderais bien d’annoncer des choses comme ça sans avoir un minimum de reculs et de tests dans la besace. Si vous avez des graphes et des analyses qui permettent d’étayer votre position sur une base de données dolibarr je suis preneur !

1 « J'aime »

Vous êtes libre de faire comme bon il vous semble :slight_smile:

Hello,

Wireguard n’est adapté à toutes les situations.
Et la plupart des logiciels PHP acceptent le MYSQL en SSL, vu que PHP Mysqli le permet.

Donc @erics :+1:

Bizarrement, le même jour sur le forum anglais : Dolibarr v14.0.4 not connect to MySQL with a certificate - Installing my Dolibarr - Dolibarr international forum
On avait aussi une question plus ancienne : Connection to MySQL Azure SaaS - Installing my Dolibarr - Dolibarr international forum

C’est drôle ça, promis juré craché ce n’est pas moi qui créé des faux profils :slight_smile: ni demandé à une ia de faire la promo de cette idée !

1 « J'aime »

Bonjour,

Loin de moi l’idée de vouloir polémiquer, chacun fait comme il veut.

Concernant les performances en ssl de mysql c’est selon moi de « notoriété publique » depuis l’étude de percona

Le graphique le plus parlant étant celui-là, où l’on voit que le nombre de connexions par seconde passe de 1000 à un peu moins de 500 via un tunnel ssh et dégringole à 22 avec du ssl.

L’étude date de 2013, il y a eu quelques améliorations depuis mais rien de révolutionnaire si on lit les forums de percona (la meilleure option restant de recompiler mysql avec le support d’openssl).

Quand à l’idée d’héberger sur un mutualisé une application comme Dolibarr qui est souvent stratégique pour le fonctionnement d’une entreprise, comment dire…, disons que j’ai du mal à voir comment mettre en place une stratégie de sauvegarde et un plan de reprise d’activité avec du mutualisé.

1 « J'aime »

Chouette étude,
je l’avais croisé mais compte tenu que c’est > 10 ans je ne l’ai pas gardé dans mes points de références. D’après mon expérience dans ce domaine je me garde de noter ça comme acquis.

Et puis surtout il ne faut pas s’arrêter au 1er graphique qui n’a à mon avis pas grand chose à voir avec la réalité !

Le graphique a été réalisé dans ces conditions:

« which are on the same VLAN of a gigabit Ethernet link, and the test script in use was similar to that from part 1, wherein we attempt to create 100 connections as fast as possible »

Tentatives de créer le plus rapidement 100 connexions sur un lien ethernet gigabit dans un VLAN local …

Alors oui dolibarr est « gourmand » en connexions SQL mais se baser sur un graphique qui analyse la vitesse de création de 100 connexions d’un coup pour choisir une solution technique me semble délicat à argumenter.

Chez percona se trouve aussi cette étude sur l’impact de la bande passante réseau, celui qui m’intéresse dans cet article est la « Benchmark N3. Network encryption » où on voit que le passage sur ssl n’a que peu d’impact sur la bande passante en dessous des 512 threads

Tout ça pour dire que pour ma part ça n’est pas de « notoriété publique » que le support ssl de mysql/mariadb soit pourris au point qu’il faille à tout prix passer sur une infra de type VPN. Je soutiens que le support SSL de mysql/mariadb apporte des réponses tout à fait acceptables dans beaucoup de situations.

Pour ne pas perdre trop de temps j’ai regardé rapidement le changelog du paquet debian de mariadb je vois beaucoup de choses autour de ssl depuis le 1er paquet mariadb (2014) avec des itérations entre la lib-ssl système ou des lib-ssl embarquées etc. ce qui laisse à penser qu’il y a eu probablement pas mal de boulot/remarques/whatelse autour de cet aspect des choses.

Au même titre qu’une boutique en ligne ? Donc tout hébergement de prestashop (ou autre) sur serveur mutualisé serait une hérésie alors ? Je craint que ça ne soit le cas de vraiment beaucoup de monde en vérité ,-)

Pour résumer ma position: un test actualisé avec un vrai dolibarr et une utilisation normale comme dans la vie réelle serait vraiment intéressant.

Je tiens à vous faire remarquer que je n’ai jamais employé le terrme hérésie. Il serait sympa et courtois de ne pas déformer mes propos.

Quand au fait d’héberger des applications stratégiques comme une boutique en ligne sur un serveur mutualisé, disons que c’est jouer avec le feu. Un plan de reprise d’activité est indispensable et un serveur mutualisé est tout sauf adapté pour cela.

Petit extrait

Aucune entreprise n’est à l’abri d’une panne, d’une suppression accidentelle, d’un crash de serveur ou d’un piratage ! Rappelez-vous l’incendie du 10 mars 2021 qui a détruit une partie des datacenters d’OVH Cloud à Strasbourg. Dans son premier communiqué immédiatement après l’incendie, OVH a invité ses clients à « déclencher leur PRA (Plan de Reprise d’activité) ». De très nombreux clients OVH n’en avaient pas et ont tout simplement perdu 100% de leurs données. D’autres, au contraire, ont pu relancer leur activité en moins d’une heure grâce au PRA.

source Backup et PRA : une sécurité indispensable - Groupe Soledis

Pardon de vous avoir choqué avec l’hérésie mais c’est ainsi que j’ai interprété votre sous entendu, cette réponse permet donc de préciser la situation.

Même si on s’éloigne de plus en plus du sujet … PRA et hébergement mutualisé n’ont aucun lien … vraiment je suis navré de vous contredire aussi systématiquement !

Vous pouvez tout à fait bâtir un PRA en prenant en compte que vos données essentielles sont sur un serveur mutualisé. L’extrait de l’article cité ne fait que mettre le doigt sur le fait que certains clients n’avaient pas de PRA et que ceux qui en avaient un ont pu relancer leur activité en moins d’une heure …