Discussion :

[elekaj34]

Bonjour,

Je vous explique la problématique. Je cherche à sécuriser un serveur MySQL, pour qu'en cas de panne ou pire attaque, les données stockées ne soit pas perdues.
Actuellement, j'ai une sauvegarde journalière du système et de la base de données, mais cela n'est pas suffisant. Dans le cadre de notre applicatif, perdre une journée, c'est beaucoup trop !

Donc j'ai mis en place un serveur SQL de secours en SLAVE. Le master réplique les données sur le second, j'ai en quelques sorte une sauvegarde temps réel !
Si le master crash, je n'ai pas perdu de données puisqu'elles sont sur le slave.

Mais en cas de hack, exemple : un hacker drop l'ensemble des bases (ou supprime certaines données des tables) alors le slave sera lui aussi "corrompu" et les données supprimées via la réplication.
Je cherche donc à sécuriser ce point.

Avez vous des idées ?
Les connexions entre le master et le slave sont déjà sécurisées par SSL.

Merci à vous pour votre aide

[Artemus24]

Salut elekaj34.

Actuellement, j'ai une sauvegarde journalière du système et de la base de données, mais cela n'est pas suffisant.

Pourquoi n'est-ce pas suffisant ?

Dans le cadre de notre applicatif, perdre une journée, c'est beaucoup trop !

A bon, parce que les banques quand ils perdent une journée, ce n'est rien ?
Et pourtant, ils ont eu aussi un backup quotidien.

Donc j'ai mis en place un serveur SQL de secours en SLAVE. Le master réplique les données sur le second, j'ai en quelques sorte une sauvegarde temps réel !

Une réplication n'est pas à proprement parlé une sauvegarde. C'est juste une technique pour obtenir une tolérance de panne.

Si le master crash, je n'ai pas perdu de données puisqu'elles sont sur le slave.

Faudrait encore définir ce que vous entendez par "crash" ?

Je cherche donc à sécuriser ce point.

Faire en sorte que la partie physique de votre serveur, ne soit pas accessible par votre pirate !

Mettre le répertoire "c:/WAMP" sur un disque ou seulement l'administrateur système soit autorisé à accéder.
Tous les autres accès se feront au travers du serveur mysql ou de phpmyadmin.
Changer le compte "root" en un autre nom, moins évident à trouver.
Changer régulièrement le mot de passe de ce nouveau compte.

Interdire les ordres "drop database" ou drop table" dans votre serveur, si c'est cela qui vous tracasse.

Tous les accès à vos tables doivent se faire avec un compte, autre que celui root", et ayant juste les permissions "select, insert, delete et update".

Les connexions entre le master et le slave sont déjà sécurisées par SSL.

Je doute fortement que le SSL, qui permet de chiffrer vos échanges, soit l'ultime sécurité. Mais bon, c'est une autre histoire.

La norme veut aujourd'hui un certificat SSL V3 avec le descriptif du nom du site et des adresses ip.
Le sha1 est devenu obsolète depuis janvier 2017 avec la version google chrome 58.
Il est préférable d'utiliser sha256 à la place.

@+