En bref : l'authentification à deux facteurs pour les accès administrateur fait en sorte qu'un mot de passe volé ou deviné ne suffise pas à lui seul. Elle doit s'appliquer partout où quelqu'un peut modifier votre site ou votre serveur : CMS, hébergement, panneau, SSH, domaine, DNS et boîtes e-mail des admins. Aussi importants que la mise en place sont les codes de secours et une règle claire sur qui dispose de quel accès personnel.
Pourquoi les mots de passe seuls ne suffisent pas pour les admins
Les mots de passe se perdent de nombreuses façons : par des e-mails d'hameçonnage, des logiciels malveillants sur un poste de travail, des fuites de données chez d'autres services ou simplement par réutilisation. Des attaques automatisées essaient sans cesse des identifiants volés contre des pages de connexion connues.
Avec un second facteur, un attaquant a besoin en plus de quelque chose que seul l'utilisateur autorisé possède, par exemple un smartphone avec une application d'authentification ou une clé de sécurité. Cela relève nettement la barrière, surtout pour les comptes aux droits étendus.
Pour la direction, une distinction est importante : l'authentification à deux facteurs protège les accès, pas le logiciel qui se trouve derrière. Une faille comme PHP2Shell, qui permet l'exécution de code sans authentification, n'est pas comblée par ce moyen. Les deux vont ensemble : un logiciel à jour et des accès bien protégés.
Quelles méthodes à deux facteurs conviennent
Les méthodes diffèrent par la sécurité et le confort d'utilisation. Pour les comptes administrateur, vous devriez employer au moins des applications d'authentification, et pour les accès particulièrement critiques des clés de sécurité ou des passkeys.
| Méthode | Protection contre le hameçonnage | Adéquation pour les admins |
|---|---|---|
| Code SMS | faible | seulement comme transition |
| Application d'authentification (TOTP) | moyenne | bon standard |
| Confirmation push | moyenne, vulnérable aux attaques par fatigue | adaptée avec correspondance de numéro |
| Clé de sécurité ou passkey (FIDO2/WebAuthn) | élevée | recommandée pour les accès critiques |
| Clé SSH avec phrase secrète | élevée | standard pour les accès serveur |
Les codes à usage unique d'une application peuvent être interceptés sur une page d'hameçonnage trompeusement fidèle et réutilisés immédiatement. Les méthodes FIDO2, en revanche, vérifient l'adresse de la page et ne fonctionnent pas sur une page falsifiée. C'est la raison pour laquelle elles sont le meilleur choix pour les admins ayant accès à de nombreux systèmes.
Authentification à deux facteurs pour les accès administrateur : la liste complète
Les attaquants choisissent l'accès le plus faible. Passez donc en revue tous les endroits où quelqu'un peut modifier votre site, votre serveur ou votre domaine :
- CMS et back-end de boutique : WordPress, Shopware, TYPO3 et d'autres proposent l'authentification à deux facteurs dans le noyau ou via des extensions maintenues. La variante recommandée figure dans la documentation de l'éditeur.
- Compte client de l'hébergeur : qui y entre peut souvent réinitialiser des mots de passe, télécharger des sauvegardes ou réinstaller le serveur.
- Panneau du serveur comme Plesk ou cPanel, s'il existe.
- SSH et SFTP : clés au lieu de mot de passe, voir la section suivante.
- Bureau d'enregistrement du domaine et DNS : un réglage DNS modifié redirige vos visiteurs et vos e-mails sans que le serveur soit concerné.
- Boîtes e-mail des admins : c'est par elles que passent les réinitialisations de mot de passe de presque tous les autres services.
- Dépôt de code et déploiement : qui peut y écrire peut déployer du code malveillant.
- CDN, WAF, Google Search Console et prestataires de paiement.
Consignez pour chaque entrée qui y a accès, si le second facteur est actif et où se trouvent les codes de récupération. Cette liste est en même temps une partie importante de votre plan d'urgence, car après un incident, précisément ces accès doivent être vérifiés et renouvelés en peu de temps.
SSH : des clés au lieu d'un mot de passe
Pour les accès serveur, la connexion par clé SSH est la protection forte habituelle. La clé privée se trouve sur l'appareil de l'admin et est protégée par une phrase secrète ; pour les serveurs particulièrement sensibles, elle peut se trouver sur une clé matérielle. Une fois la connexion par clé mise en place et testée pour tous les admins, désactivez la connexion par mot de passe :
# /etc/ssh/sshd_config (extrait)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Vérifier la configuration avant de recharger le service
sshd -t && systemctl reload ssh # sous les systèmes RHEL : sshd
Lors du changement, laissez une session existante ouverte et testez la connexion dans une deuxième fenêtre. Ainsi, en cas d'erreur, vous ne vous verrouillez pas. Chaque admin reçoit sa propre clé ; des clés communes à toute une équipe ne se retirent pas proprement lors du départ de personnes isolées. Le guide Sécuriser soi-même serveurs dédiés et vServers décrit d'autres bases.
Accès de secours et codes de récupération
Une bonne introduction prévoit aussi la panne. Les smartphones se perdent, les collaborateurs quittent l'entreprise, les clés de sécurité se cassent. Sans plan, personne ne dispose alors de l'accès au mauvais moment.
Enregistrez deux facteurs pour chaque compte critique, par exemple une clé de sécurité au bureau et une application d'authentification, et conservez les codes de récupération séparément du mot de passe.
Autres règles qui ont fait leurs preuves :
- Des comptes personnels plutôt que des connexions administrateur partagées, afin que les modifications restent traçables.
- Un accès de secours documenté avec des identifiants conservés séparément, dont l'utilisation se remarque et est journalisée.
- Lors du départ de collaborateurs ou de prestataires, retirer tous les accès et clés le jour même.
- Après un incident de sécurité, vérifier non seulement les mots de passe, mais aussi les facteurs enregistrés et les sessions actives.
Lors du déploiement dans l'équipe, un déroulement clair a fait ses preuves. Commencez par les comptes qui peuvent causer le plus de dégâts : hébergement, domaine, DNS et boîtes e-mail des admins. Viennent ensuite les serveurs, le CMS et les services. Fixez une date butoir à partir de laquelle les connexions sans second facteur ne sont plus possibles, et assurez-vous au préalable que toutes les personnes concernées sont configurées.
Expliquez brièvement à l'équipe pourquoi le changement est nécessaire et comment il fonctionne au quotidien. Un mode d'emploi d'une page avec des captures d'écran réduit nettement les questions. Les prestataires externes et les agences devraient recevoir des accès personnels propres avec second facteur plutôt qu'une connexion commune, afin que les accès restent attribuables et puissent être retirés proprement à la fin du projet.
Le guide Protéger les connexions administrateur contre la force brute explique comment protéger en outre les pages de connexion contre les tentatives automatisées.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons avec vous une liste complète de tous les accès administrateur et montrons où le second facteur manque.
- Nous convertissons les accès serveur aux clés SSH et désactivons de façon contrôlée les connexions par mot de passe dans le cadre du renforcement de serveur.
- Nous documentons les accès de secours et les voies de récupération de façon qu'ils fonctionnent en cas d'urgence.
- Dans le contrat de maintenance de sécurité, nous vérifions régulièrement les accès et supprimons les comptes orphelins.
Questions fréquentes
Quelle méthode à deux facteurs est la plus sûre ?
Les clés de sécurité matérielles et les passkeys selon la norme FIDO2 sont considérées comme particulièrement résistantes au hameçonnage, car elles sont liées à la véritable adresse. Les applications d'authentification avec codes à usage unique constituent un bon standard. Le SMS vaut mieux que rien, mais reste la variante la plus faible.
Que se passe-t-il si le smartphone avec l'application d'authentification est perdu ?
Pour cela existent des codes de récupération affichés lors de la configuration. Ils doivent être conservés en lieu sûr, par exemple dans un coffre-fort ou un gestionnaire de mots de passe protégé. En outre, au moins un deuxième admin devrait pouvoir réinitialiser l'accès.
L'authentification à deux facteurs protège-t-elle aussi contre PHP2Shell ?
Non. PHP2Shell permet l'exécution de code sans authentification, la connexion n'est alors même pas utilisée. Contre PHP2Shell, seule aide la mise à jour vers une version de PHP corrigée avec redémarrage de tous les workers. L'authentification à deux facteurs protège contre les mots de passe volés ou devinés.
L'authentification à deux facteurs dans le CMS suffit-elle ?
Non, un attaquant choisit l'accès le plus faible. Le compte d'hébergement, le panneau du serveur, SSH, la gestion du domaine, le DNS et les boîtes e-mail des admins doivent être protégés de la même façon, sinon la protection du CMS peut être contournée.