Il est essentiel, pour se prémunir des attaques, bugs, et pour profiter des améliorations en tous genres, de tenir sa version Magento à jour. D'autant plus qu'il sera beaucoup plus difficile – voire impossible – de sauter d'une version à une autre, sans passer par toutes les versions intermédiaires qui seraient sorties entre temps.

Mettre à jour Magento peut s'avérer risqué, c'est pourquoi il faut se préparer au pire :

• on sauvegarde la base de données :

  mysqldump -u utilisateur -p"mot_de_passe" nom_de_la_base > sauvegarde_datée.sql

• on sauvegarde l'intégralité du dossier racine de magento.

Ensuite, on se rend dans le dossier de Magento et, en utilisateur root :

./pear mage-setup . (si la permission est rejetée : chmod 755 pear)
./pear install -f magento-core/Mage_All_Latest-stable
rm -rf racine_magento/var/cache/*
rm -rf racine_magento/var/session/*

Il faudra ensuite penser à recréer le cache à partir de l'interface d'administration et régler les éventuelles nouvelles options de configuration.

Afin de protéger l'envoi d'informations sur les pages clients et les pages liées au paiement de votre plateforme hébergée, il est essentiel d'utiliser le chiffrement des données par SSL. Ces certificats sont délivrés par de nombreux organismes, à tous les prix et, pour un site Magento, à peu près n'importe quel certificat fait l'affaire.

 

Pour le module de paiement, il faut nécessairement passer par celui de sa banque, à moins d'avoir la certification PCI-DSS, très coûteuse et difficile à obtenir.

Il peut arriver de perdre son mot de passe d'administrateur Magento, de l'oublier, ou de se resservir d'une ancienne sauvegarde de la base de données dont le mot de passe a été perdu depuis.

Il est heureusement possible de le changer manuellement, en passant directement pas la base de données (manipulation également possible par phpMyAdmin, si vous n'avez pas l'accès ssh sur le serveur hébergeant votre site…).

On se connecte donc à MySQL, puis :

mysql > use nom_de_la_bdd;
mysql > SELECT * FROM `admin_user`;

On trouve dans le résultat de cette commande le nom de l'administrateur dont on veut modifier le mot de passe, puis :

mysql > UPDATE `admin_user` SET `password` = MD5('nouveau_mot_de_passe') WHERE `username` = 'nom _administrateur';

Dans notre protocole de benchmark, on peut remarquer que front office, back office et base de données sont séparés en autant de machines virtuelles. C'est une option qui a été intégrée par les développeurs de Magento pour permettre de répartir la charge entre divers serveurs hébergés.

Il y a deux raisons essentielles à cela :

• La première est une raison tenant à la sécurité. Plus le site est compartimenté, plus il est sécurisé. Dans l'hypothèse ou une faille venait à être exploitée sur l'un d'eux, les deux autres ne seraient pas touchés.
• La seconde est un souci d'optimisation. En effet, cela permet d'allouer à chaque partie du site ses propres ressources, et ainsi de mieux les gérer. Cela met en place une topologie plus souple pouvant aider à la mise en place d'un load balancing, d'une clusterisation... ainsi que d'upgrader, au niveau hardware, une partie du site sans devoir nécessairement toucher au reste.

En plus de cela, cette séparation simplifie considérablement le monitoring, ce qui permet de concevoir des plans d'évolution aussi bien au niveau des performances que de la sécurité.

De très nombreuses extensions sont disponibles pour Magento. Certaines sont payantes, d'autres gratuites (opensource ou non). Certaines d'entre elles ont été développées par Varien, l'éditeur à l'origine de Magento, mais l'immense majorité l'a été pas des tiers.

Il faut garder à l'esprit que Magento reste très sécurisé car il a été conçu et est amélioré sans cesse par une équipe de développeurs compétents, dédiés à plein temps à ce projet. Si la sécurité de la plateforme hébergée s'avérait compromise, il faudrait se poser la question de la fiabilité des éventuelles extensions installées.

En effet, certaines extensions peuvent avoir gagné en popularité du fait qu'elles comblent une lacune de la plateforme Magento, tout en ayant pu être développée à la va-vite. Seul un audit de l'extension peut permettre de savoir si elle ne représente pas une faille éventuelle pour la plateforme.

Une des plus grandes forces de Magento est d'être open-source. Entre autres avantages, cela permet à la communauté de conjuguer ses efforts pour améliorer le code, développer des extensions, mais aussi faciliter l'entre-aide.

Pour autant, cette force peut se révéler être une faiblesse dans le domaine de la sécurité : en partant du principe que tout le monde partage le même code, on peut aisément conclure que tout le monde partage les mêmes failles de sécurité. De sorte que les injections SQL, relativement fréquentes, sont grandement facilitées lorsque l'attaquant connait le nom des tables de la base de données.

Contre cela, Magento intègre un verrou de sécurité, permettant d'utiliser un préfixe pour les tables de la base. Mais cela n'est pas activé par défaut. Cette décision doit être prise conjointement entre l'hébergeur du site magento et l'intégrateur.

Du côté de Magento, il est possible de le faire à l'installation, mais aussi plus tard, dans le fichier racine_magento/app/etc/local.xml, il convient d'insérer le préfixe comme suit :

<table_prefix><![CDATA[votre_préfixe]]></table_prefix>